Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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@xxxxxxxxxxxxxxx
Attachment:
signature.asc
Description: This is a digitally signed message part.
