Package: git
Version: 1:2.0~next.20140127-1
Severity: wishlist
Tags: upstream
Control: forwarded -1
http://thread.gmane.org/gmane.comp.version-control.git/241532
Suppose I create a history like this:
git init
echo hi >greeting
git add greeting
git commit -m base
echo more >>greeting
git add greeting
git commit -m A
git reset --keep HEAD^
echo something else >>greeting
git add greeting
git commit -m B
git merge HEAD@{2}
echo something else entirely >greeting
git add greeting
git commit -m 'evil merge'
That is:
base --- A --- evil merge
\ /
B -------
where base, A, and B contain 'hi\n' but the evil merge removes it.
If I run
git log --oneline $'-Shi\n' greeting
to see what happened to 'hi\n', it correctly finds base but doesn't
notice the evil merge. More generally, log -S without -c, --cc, or -m
never blames merges.
Normally -S works by comparing the count of occurences of a string to
the corresponding count from a parent. Which parent should it use for
merges?
Possible start to an answer:
* perform a naive merge in memory[1]
* if the naive merge and actual merge have different numbers of
occurences of the test string, blame the merge (it's an evil
merge and the merge resolution is to blame)
* if the naive merge and actual merge commit have the same number
of occurences of the test string and that number is greater than
the sum of the numbers of occurences in parents, blame the merge
(the combination of the parents is to blame)
* otherwise, ...
An appropriate rule for "..." is not obvious, unfortunately.
[1] this is Thomas Rast's "remerge diff"
http://thread.gmane.org/gmane.comp.version-control.git/241565
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
