Re: Am able to delete a file with no trace in the log

On Wed, Jun 3, 2009 at 5:33 PM, Linus Torvalds
[off-list ref] wrote:

On Wed, 3 Jun 2009, Junio C Hamano wrote:

quoted

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