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

[Thomas Rast <trast@student.ethz.ch>]

[-- Attachment #1: Type: text/plain, Size: 2394 bytes --]

Junio C Hamano wrote:
> 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:

> 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


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]