On Wed, 3 Jun 2009, Junio C Hamano wrote:
> Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes:
>
> > For example, right now there is _no_ way to get even a "show diff relative
> > to first parent". You can do "-m", which will show it relative to _both_
> > parents, but nobody ever wants that. And you can do "-c" or "--cc", but
> > that simplifies away all the paths that match in one.
>
> Actually for that "Where did my file 'x' go across the merge chain", I was
> going to suggest something like
>
> git log --simplify-merges -m --raw -- x
Ok. Not very readable, but it's certainly getting closer.
> > So here's a challenge: in the git repository, get a nice view of what your
> > merges looked like. The closest I can get is
> >
> > git log -c --stat --grep="Merge branch '"
> >
> > which is actually very non-intuitive ("-c" on its own gives no useful
> > output, but "-c --stat" gives nice diffstat against the first parent,
> > which in this case is what we want).
>
> I think the logical place to hook that into is the --first-parent option.
>
> I actually have very hard resisted so far the temptation to do so because
> your mantra has always been "in a merge, all parents are equal."
Oh, I agree. The challenge was just the first step - how to make it do
merges in general sanely would be the issue.
Because if you do just --first-parent, then that won't even show the
test-case that Graham actually had - because the missing file didn't come
in from the first parent of a merge.
The challenge was mainly as a way to point out that even some fairly
simple cases aren't all that simple.
Linus
--
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