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

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Jun 19, 2005, 04:26 UTC
Message-ID: <Pine.LNX.4.21.0506182338300.30848-100000@iabervon.org>
In-Reply-To: <tnxis0b1h7g.fsf@arm.com>

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.

Show 5 quoted lines

> Before commenting further on your or Jon's e-mail, I want to clarify
> how I think this tool should be used (this might be misunderstood if
> someone never used quilt before). First of all, a StGIT patch is a
> collection of git commits. This tool *doesn't* remove or modify git
> changesets.

(snip)

Okay; this fits what I thought quilt and StGIT did.

An aside:

> - pushing a patch to the stack when the base changed is done by
>   merging with a diff3 algorithm. I find this slightly superior to a
>   simple 'patch -p1 < file.diff' (well, some people do not agree with
>   this point)

diff3 is clearly superior to patch in how effective it is; the disagreement is only over how useful the output format is. But diff3 gets all the information that patch gets, plus more, so it would have to be buggy if it did worse, aside from by patch getting lucky. (Also, patch can be used in situations where diff3 couldn't, due to having no known common ancestor). IIRC, diff3 can generate .rej files if you tell it to, rather than reporting conflicts inline.

> I don't know whether this is still valid after clarifying the intended
> use of StGIT. When a patch was merged upstream, the local push
> operation should detect that the patch being pushed doesn't change
> anything and, at this point, you can safely delete it.

If you're lucky, it will generate only a warning that changes are present in both trees, the push will have no effect, and StGIT can determine that the rebased patch is now empty. But consider this situation:

You have three patches stacked on a base.

The mainline takes a patch from somewhere else, then the first of your patches, then a second patch from somewhere else. The last of these is based on your first patch (or on mainline after your patch went in).

Then you update.

When you try to push your first patch, merge sees the common base, your change, and the current mainline. There is no way to tell, from the information available, that the correct merge is to ignore your change in favor of mainline's version; the program only sees that there were two different changes to the same area. The information which would resolve this were patches not used would be that there was a mainline commit that merged your first patch; the left side of the merge is an ancestor of the right side, so the merge is the right side. My goal is to get the same information into the system so it can reach the same conclusion when patches are used.

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.

The above situation is not actually particular to StGIT or quilt; any case where something gets exported as a patch and applied to a different base has this problem. 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.

	-Daniel
*This .sig left intentionally blank*