Hi,
On Fri, 7 Jun 2007, linux@horizon.com wrote:
Show 31 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.
... but if that script should do that, the name "filter"-branch was a misnomer.
It filters the _branch_. In the sense that a branch is one or more perls of commits, uniting in the tip of that branch.
If you want to skip a commit, that is fine. But a commit is _not_ a patch, no sir. It is a revision.
The fact that we actually are able to extract nice patches from any patch series, does not mean that the revisions are actually only deltas with regard to the previous commit. To the contrary: we actually allow -- and encourage -- git-diff between different revisions, be they on the same branch or not. That alone should tell everybody that a revision is a revision is a revision, and _not_ a delta.
So, when you filter commits, you should not expect a certain _patch_ to be skipped when you say "skip" (or maybe "squash", which I actually like better, because it is as unambiguous as you get it), but a _commit_ (AKA revision) to be skipped.
Ciao, Dscho
