Re: [PATCH/RFC] filter-branch: support skipping of commits more easily

From: linux@horizon.com <linux@horizon.com>
Date: Jun 8, 2007, 02:11 UTC
Message-ID: <20070608021157.18066.qmail@science.horizon.com>

Show 20 quoted lines

> I think that is fine; in effect, by saying "skip" B, you are
> squashing B-C into C'.
> 
> Does this mean that, given
> 
>           C---D---E
>          /   /
>         A---B
> 
> and if commit-filter says "skip" on D, the written history would
> look like this?
> 
>           C'------E'
>          /       /
>         A'--B'--'
> 
> The new commit E' would become an evil merge that has difference
> between D and E in the original history?
> 
> I am not objecting; just trying to get a mental picture.

I think, for compatibility with the existing git path limiter,
it should delete D from the history only if:
1) Told to skip D, and
2) Told to skip B or C (or both).

So you could get A--B--E' or A--C--E' or even A--E', but D would only be deleted if it wasn't needed as a merge marker.

That's probably a little more complex to implement, but it feels like The Right Thing.