Re: [Quilt-dev] Rename patch?

[Andreas Gruenbacher]

On Monday 18 April 2005 22:38, Jean Delvare wrote:
> [Jean Delvare]
>
> > I took my chance on it. Unsurprisingly, it ends up as a simplified
> > version of the fork patch. Differences:
> > 1* Rename can operate on any patch, not only the topmost one. This
> > includes unapplied patches.
> > 2* The new name must be provided, it is never guessed.
> > 3* Of course, the patch file is renamed instead of being duplicated.
>
> [Andreas Gruenbacher]
>
> > Can we unify fork and rename? I'm thinking of one script for both that
> > checks  under which name it was called. The functionality of the two
> > should be _very_  close, the only difference being that fork copies
> > the patch file, while  rename moves it.
>
> My list above shows more differences. Fork applies on the topmost patch
> only, while rename supports named patches. Fork can guess the name of
> the new patch, while rename currently doesn't - but that one might be
> changed.

Right. For rename, the name guessing logic makes little sense, so I don't 
think we want it. It's not wrong per se though. Fork could as well fork 
arbitrary patches, and again, it wouldn't hurt. Right now I don't see where 
it would be needed, though.

> I am not certain there is much to win by merging both patches. They are
> rather small (nothing like pop or push). The common part is the same
> common part all functions have, nothing really special. As a matter of
> fact, the unified diff between the rename and fork scripts currently has
> more lines than either script. This might be improved by dropping a
> couple trivial differences, but not by that much.
>
> So I might reconsider if we add the new-patch-name-guessing feature to
> rename, but for now I would keep rename a separate patch.

Maybe it's better to keep them separate. I'm still not sure.

> [Jean Delvare]
>
> > I think I now understand the point of the fork command, but still
> > believe that it should be better documented.
>
> [Andreas Gruenbacher]
>
> > Documentation improvements are just as welcome as code improvements ;)
>
> As I said, I would contribute a documentation patch for this, but I'd
> need someone who knows the history and typical use of the fork command
> to tell me about it. Documenting the way I think fork works won't be
> really useful, especially if I happen to have guessed wrong.

Ah ... so fork was meant as a way to allow the following work pattern: Create 
a set of patches, create a snapshot (e.g., by tar'ing up series and all 
patches). For the next snapshot, whenever a patch is modified, fork it. That 
way the patches themselves stay the same, and it's immediately obvious what 
changed between two snapshots. Example (S=snapshot; p, q, r are patches):

        S1      S2      S3
        p       p-2     p-2
        q       q       q-2
        r       r       r

That's basically it as far as I remember.

> BTW, if you want me to be listed as a quilt developer on Savannah, feel
> free to proceed.

Okay, I hope I've entered things correctly.

Thanks,
-- 
Andreas Gruenbacher <address@hidden>
SUSE Labs, SUSE LINUX PRODUCTS GMBH