Hi, On Fri, 8 Aug 2008, Thomas Rast wrote: > Johannes Schindelin wrote: > > On Fri, 8 Aug 2008, Thomas Rast wrote: > > > > > I think a more careful use of rev-list -1 is actually a correct and > > > easy way to figure out an ancestor. > > > > I have not looked at your patch closely, or at your explanation, but I > > am really certain that every attempt to replace the --boundary with a > > -1 must fail. > > > > Let me show you why I think that. Just look at this history: > > > > A - B - C > > / > > D > > > > > > Where all commits except B touch the inside directory. Two > > > > options: > > 'rev-list' "solves" this problem for us. At the point where we are > rewriting the branch pointers, commits have already been rewritten to > whatever 'git rev-list --parents -- $subdir' told us to make them. I > think there are only two cases for its output: > > (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". But hey, if other people agree with you, and this kind of thinking ends up in Git proper, I can still resort to other DVCSes. Ciao, Dscho -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
