On Wed, Jun 3, 2009 at 5:33 PM, Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> On Wed, 3 Jun 2009, Junio C Hamano wrote:
>> E.g. "git log --graph --oneline -- git-clone.sh" shows that the scripted
>> version ceased to exist at 8434c2f
>
> Btw, this example misses the whole point of the original problem.
>
> The original problem was:
>
> - create new file 'x' in branch 'a'
>
> - merge branch 'a' into branch 'b', but because of a merge conflict and
> confurion in the merge, the merge result doesn't contain 'x' any more.
>
> - try to find out what happened to 'x' after-the-fact.
>
> Try it. Git really doesn't make it very easy, because git will notice that
> 'x' didn't exist before the branch either (in branch 'b'), so there will
> be _no_ sign of 'x' actually going away.
Note that full-file deletion is only one particular case of a general
problem. Consider this script:
===
#!/bin/bash
rm -rf testb
mkdir testb
cd testb
git init
echo 'initial a' >a
echo 'initial b' >b
git add a b
git commit -m 'initial commit'
git branch sub
echo 'first a change' >>a
git add a
git commit -m 'modify a'
git checkout sub
echo 'second a change' >>a
git add a
git commit -m 'modify a differently'
git checkout master
git merge -s ours sub
===
"git log -p" will show the addition of the line "second a change" to
a, but it doesn't show that, in fact, this line was later deleted
because of a botched merge. There is no obvious way to find out in
which commit the line was lost. If someone doing a code review is
reviewing all the patches from "git log -p", then they'll miss the
fact that this patch was lost.
('git log -p -- a" doesn't show that the line was added at all - which
is true, in some sense, but it's equally true that, in the example you
gave, 'x' was never added.)
Have fun,
Avery
--
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