Subject: Re: Stacked GIT 0.1 (a.k.a. quilt for git)

From: Catalin Marinas <[email-masked]>
Date: Sun, 19 Jun 2005 10:24:49 +0100

Daniel Barkalow <[email-masked]> wrote:
> On Sat, 18 Jun 2005, Catalin Marinas wrote:
>> Having different series would be a good idea but it might complicate
>> the tool usage. I will thing about it once I'm sure the basic
>> operations work fine.
>
> You could future-proof yourself a bit by simply saving the base as
> .git/refs/bases/master and making the patches be
> .git/patches/master/. That way, you'd be ready when you start to support
> multiple series.

You are right. I will do this for the next release (0.2, probably of
the end of this week), something like the tree structure below:

.git/refs/bases/<head>
.git/series/<head>/
.git/series/<head>/applied
.git/series/<head>/unapplied
.git/series/<head>/current
.git/series/<head>/patches/*

I don't know whether a git-diff-* command would look into
.git/refs/bases (I can do this in stgit but, this was only for
convenience).

[...]
> Note that it gets more complex if mainline takes only your second patch
> (due to it not requiring your first, and your first not being as
> acceptable). In this case, it needs to entire mainline as a patch, because
> merges can't cherrypick, whereas patches can act arbitrarily. But it would
> be nice to store the information of what happened even with patches that
> cherrypick, such that we have a better chance for managing things
> later.

You can cherry-pick the second patch by first commuting it with the
previous patches. If they are independent, the commuting via diff3
wouldn't generate any conflict. Even with the current stgit, you can
pop all the patches and only push those to be merged upstream. HEAD
would only contain the those patches.

If you want to implement a full-featured patch treacking, you might
end up with something like darcs which doesn't scale to the size of
the Linux kernel. On the other hand, you might not agree with the
changes to your accepted patch and a conflict is welcomed so that you
can choose whether to keep the old version or not.

> But I think that you have the right ideas about how
> patches should be represented, and it would be good to get your
> representation implemented inside git, because operations more central to
> git would benefit from having this information.

Do you mean creating a new git type like the blob, tree or commit? I
would prefer not to modify git or have my own version of git. StGIT
should be a tool running directly on top of an existing installation
of git.

Instead of having a directory for every patch (with bottom, top
etc. files), I could create a git blob to store this information and
the series files (applied/unapplied files) would only contain the blob
id. This could simplify things if, in a future version, stgit would
allow patch cherry-picking.

-- 
Catalin