From: Junio C Hamano <hidden> Date: 2016-06-15 22:48:39
Avery Pennarun [off-list ref] writes:
So what git tries to do is reduce the diff output of a merge commit
down to just the "unexpected" parts: the parts that are different from
what you'd get if you just merged in the individual changes in the
obvious way.
This (and everything you said after this paragraph) is not quite correct.
What is shown is the pieces that do not match either of the parent.
So if you have a conflicted merge and resolve it by taking what one side
did literally (think: "merge -X ours"), that hunk becomes uninteresting
because the end result matches what one of the parents had.
On Thu, Apr 15, 2010 at 8:01 PM, Junio C Hamano [off-list ref] wrote:
Avery Pennarun [off-list ref] writes:
quoted
So what git tries to do is reduce the diff output of a merge commit
down to just the "unexpected" parts: the parts that are different from
what you'd get if you just merged in the individual changes in the
obvious way.
This (and everything you said after this paragraph) is not quite correct.
What is shown is the pieces that do not match either of the parent.
So if you have a conflicted merge and resolve it by taking what one side
did literally (think: "merge -X ours"), that hunk becomes uninteresting
because the end result matches what one of the parents had.
Hmm, but David also said:
quoted
quoted
git show commit:path shows empty file:
$ git show dac6a95f5:facturacion/facturacion/scripts/lineasfacturascli.qs | wc
0 0 0
The output seems to match neither parent in any way, and yet the
simplification has resulted in no diff at all. Strange, no?
Avery
On Thu, Apr 15, 2010 at 8:06 PM, Avery Pennarun [off-list ref] wrote:
On Thu, Apr 15, 2010 at 8:01 PM, Junio C Hamano [off-list ref] wrote:
quoted
Avery Pennarun [off-list ref] writes:
quoted
So what git tries to do is reduce the diff output of a merge commit
down to just the "unexpected" parts: the parts that are different from
what you'd get if you just merged in the individual changes in the
obvious way.
This (and everything you said after this paragraph) is not quite correct.
What is shown is the pieces that do not match either of the parent.
So if you have a conflicted merge and resolve it by taking what one side
did literally (think: "merge -X ours"), that hunk becomes uninteresting
because the end result matches what one of the parents had.
Hmm, but David also said:
quoted
quoted
quoted
git show commit:path shows empty file:
$ git show dac6a95f5:facturacion/facturacion/scripts/lineasfacturascli.qs | wc
0 0 0
The output seems to match neither parent in any way, and yet the
simplification has resulted in no diff at all. Strange, no?
Avery
mkdir testy
cd testy
git init
cp /etc/profile .
git add profile
git commit -m root
git checkout -b a master
cat /etc/profile >>profile
git commit -a -m test1
git checkout -b b master
cat /etc/profile | tr A-Za-z a-zA-Z >profile
git commit -a -m test1b
git merge a
# produces a conflict
true >profile # blank the file
git commit -a -m resolved
git show HEAD:profile
# no output
Note that if you instead replace the file with a nonempty (but
different) file, you get something appropriate as the output.
Have fun,
Avery
From: Jay Soffian <hidden> Date: 2016-06-15 22:48:39
On Thu, Apr 15, 2010 at 8:13 PM, Avery Pennarun [off-list ref] wrote:
true >profile # blank the file
git commit -a -m resolved
git show HEAD:profile
# no output
Well, I wouldn't expect output from show HEAD:profile. But this is odd::
$ git diff HEAD^1 --name-status
M profile
$ git diff HEAD^2 --name-status
M profile
$ git diff-tree HEAD --name-status
<no output>
Hmfph. "git log -m -p -1" at least gives the diffs from each side.
j.
On Thu, Apr 15, 2010 at 8:38 PM, Jay Soffian [off-list ref] wrote:
On Thu, Apr 15, 2010 at 8:13 PM, Avery Pennarun [off-list ref] wrote:
quoted
true >profile # blank the file
git commit -a -m resolved
git show HEAD:profile
# no output
Well, I wouldn't expect output from show HEAD:profile. But this is odd::
$ git diff HEAD^1 --name-status
M profile
$ git diff HEAD^2 --name-status
M profile
$ git diff-tree HEAD --name-status
<no output>
Hmfph. "git log -m -p -1" at least gives the diffs from each side.
Whoops, actually I meant "git show HEAD profile". Totally different,
of course. But it doesn't produce output either :)
Have fun,
Avery
The output seems to match neither parent in any way, and yet the
simplification has resulted in no diff at all. Strange, no?
mkdir testy
cd testy
git init
cp /etc/profile .
git add profile
git commit -m root
git checkout -b a master
cat /etc/profile >>profile
git commit -a -m test1
git checkout -b b master
cat /etc/profile | tr A-Za-z a-zA-Z >profile
git commit -a -m test1b
git merge a
# produces a conflict
true >profile # blank the file
git commit -a -m resolved
git show HEAD:profile
# no output
Note that if you instead replace the file with a nonempty (but
different) file, you get something appropriate as the output.
Hmm. That does seem to be a bug. It's clearly an evil merge that doesn't
match either side, and we should show it as such.
And yes, changing the
true >profile
to
echo 1 >profile
changes it to suddenly show it as such.
I guess the issue is that combine-diff decides that there is nothing in
the result that isn't in either of the sources (because there is nothing
at all in the result), and as such it's not "interesting" after all.
Linus
From: Thomas Rast <hidden> Date: 2016-06-15 22:48:39
Linus Torvalds wrote:
I guess the issue is that combine-diff decides that there is nothing in
the result that isn't in either of the sources (because there is nothing
at all in the result), and as such it's not "interesting" after all.
It does give me a warm and fuzzy feeling when you are devising and
discussing test cases for a bug that I believe I fixed before this
branch of the thread even began:
http://article.gmane.org/gmane.comp.version-control.git/144982
:-)
[scnr]
--
Thomas Rast
trast@{inf,student}.ethz.ch