Re: [RFH] filter-branch: ancestor detection weirdness

From: Thomas Rast <trast@student.ethz.ch>
Date: Aug 9, 2008, 09:25 UTC
Message-ID: <200808091125.48897.trast@student.ethz.ch>
In-Reply-To: <7viqub9dzi.fsf@gitster.siamese.dyndns.org>

Junio C Hamano wrote:

Show 18 quoted lines

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> >> (a) Both A and D bring the same subdirectory contents.  'rev-list
> >>     --parents -- $subdir' drops one side of the merge during pruning. It 
> >>     does not look past the merge to see whether the contents were 
> >>     arrived at via different changesets.  Thus the history becomes
> >> 
> >>       A' -- C'
> >> 
> >>       D'
> >> 
> >>     and even that only if D was reachable by a different ref,
> >>     otherwise D' is simply dropped.
> >
> > And this is what I call wrong.  Simply dropping one side of the equation 
> > is not what I call "sane".
> >
> > If you drop information, you are disagreeing with "content is king".

I wonder why I have to be the devil's advocate here.

Let me emphasise: _This is how filter-branch currently works._ It is not some obscure feature coming with my patch. The user _asks_ for this simplification by using --subdirectory-filter. It is also _happening long before branch rewriting_, and we are discussing a patch to said branch rewriting.

Junio has a point:

Show 7 quoted lines

> I think the aggressive merge simplification that gives "one simplest
> explanation for the contents of the paths specified" is a wrong mode of
> operation to use when you are filtering branches.  It might be a good
> thing to support as an option, but I agree with you that it should not be
> the default.
> 
> Perhaps --full-history is needed to the rev-list call (and the recent

But --full-history cannot solve this problem; it would entirely defeat the point of --subdirectory-filter. (I haven't looked into what --simplify-merges does yet.)

The only thing my patch changes is the behaviour with branches _that the user asked us to rewrite to the subdirectory history_ but that don't point to a precise commit that survived the simplification. Why would rewriting the branch pointer approriately be bad when the user specifically asked for it?

And your _existing_ branch rewriting code had the same thing in mind: move back to an ancestor that roughly fits the ticket. You just missed the problem with 'rev-list ^master ancestor' that has a high chance to break the mechanism with --all.

And broke in Jan's case, which is why we're having this discussion, remember?

- Thomas

-- 
Thomas Rast
trast@student.ethz.ch