I just did an arm merge that needed some (very trivial) manual fixups
(commit ID cce0cac1, in case anybody cares).
As usual, git-diff-tree --cc does a beautiful job on it, but I also
checked the gitweb output, which seems to not do as well (the commit
message about a manual conflict merge doesn't make any sense at all).
Now, in this case, what gitweb shows is actually "sensible": it will show
the diff of what the merge "brought in" to the mainline kernel, and in
that sense I can certainly understand it. It basically diffs the merge
against the first parent.
So looking at that particular example, arguably gitweb does something
"different" from what the commit message is talking about, but in many
ways it's a perfectly logical thing.
However, diffing against the first parent, while it sometimes happens to
be a sane thing to do, really isn't very sane in general. The merge may go
the other way (subdevelopers merging my code), like in commit b2faf597,
and sometimes there might not be a single reference tree, but more of a
"couple of main branches" approach with merging back and forth). Then the
current gitweb behaviour makes no sense at all.
So it would be much nicer if gitweb had some alternate approach to showing
merge diffs. My suggested approach would be to just let the user choose:
have separate "diff against fist/second[/third[/..]] parent" buttons. And
one of the choices would be the "conflict view" that git-diff-tree --cc
gives (I'd argue for that being the default one, because it's the only one
that doesn't have a "preferred parent").
Kay?
Linus
Linus Torvalds wrote:
I just did an arm merge that needed some (very trivial) manual fixups
(commit ID cce0cac1, in case anybody cares).
As usual, git-diff-tree --cc does a beautiful job on it, but I also
checked the gitweb output, which seems to not do as well (the commit
message about a manual conflict merge doesn't make any sense at all).
Now, in this case, what gitweb shows is actually "sensible": it will show
the diff of what the merge "brought in" to the mainline kernel, and in
that sense I can certainly understand it. It basically diffs the merge
against the first parent.
So looking at that particular example, arguably gitweb does something
"different" from what the commit message is talking about, but in many
ways it's a perfectly logical thing.
However, diffing against the first parent, while it sometimes happens to
be a sane thing to do, really isn't very sane in general. The merge may go
the other way (subdevelopers merging my code), like in commit b2faf597,
and sometimes there might not be a single reference tree, but more of a
"couple of main branches" approach with merging back and forth). Then the
current gitweb behaviour makes no sense at all.
So it would be much nicer if gitweb had some alternate approach to showing
merge diffs. My suggested approach would be to just let the user choose:
have separate "diff against fist/second[/third[/..]] parent" buttons. And
one of the choices would be the "conflict view" that git-diff-tree --cc
gives (I'd argue for that being the default one, because it's the only one
that doesn't have a "preferred parent").
Kay?
Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
git-whatchanged doesn't show that merge commit either.
--
Brian Gerst
On Wed, 8 Feb 2006, Brian Gerst wrote:
git-whatchanged doesn't show that merge commit either.
Actually, it does. You just have to ask it.
git-whatchanged --cc
The thing is, "git-whatchanged" is different from "git diff" and other
helpers, in that it by default shows the "raw" git representation. Which
indeed doesn't show that merge as being anything interesting.
But with "--cc", the merge suddenly blossoms.
Now, arguably, the raw format should default to the same kind of "were
there data conflicts" that "-c" does for merges, but it doesn't, so it's
silent ;(
Linus
On Wed, Feb 08, 2006 at 03:44:58PM -0800, Linus Torvalds wrote:
I just did an arm merge that needed some (very trivial) manual fixups
(commit ID cce0cac1, in case anybody cares).
As usual, git-diff-tree --cc does a beautiful job on it, but I also
checked the gitweb output, which seems to not do as well (the commit
message about a manual conflict merge doesn't make any sense at all).
Now, in this case, what gitweb shows is actually "sensible": it will show
the diff of what the merge "brought in" to the mainline kernel, and in
that sense I can certainly understand it. It basically diffs the merge
against the first parent.
So looking at that particular example, arguably gitweb does something
"different" from what the commit message is talking about, but in many
ways it's a perfectly logical thing.
However, diffing against the first parent, while it sometimes happens to
be a sane thing to do, really isn't very sane in general. The merge may go
the other way (subdevelopers merging my code), like in commit b2faf597,
and sometimes there might not be a single reference tree, but more of a
"couple of main branches" approach with merging back and forth). Then the
current gitweb behaviour makes no sense at all.
So it would be much nicer if gitweb had some alternate approach to showing
merge diffs. My suggested approach would be to just let the user choose:
have separate "diff against fist/second[/third[/..]] parent" buttons. And
one of the choices would be the "conflict view" that git-diff-tree --cc
gives (I'd argue for that being the default one, because it's the only one
that doesn't have a "preferred parent").
Hmm, I have no real clue what all the --cc is about. It's not obvious
for someone who never thought about "meta patches" or "complex merges". :)
If nobody else can do the changes to gitweb, sure, I'll do this and try
to understand what is needed, but then I will need it explained in more
details, what functionality we want to see here. At best with some commented
commandline examples that produce the data you want to see. So that I
can imagine what you are looking for and can give it a try ...
On the technical side for the kernel.org installation:
does git diff use /usr/bin/diff?
does git diff create temp files?
how can i specify the location for the temp files?
(wasn't possible some months ago, but needed on kernel.org)
is the temp file naming safe for a lot of git diff running in parallel?
is a --cc capable git already available on the kernel.org boxes?
Thanks,
Kay