git log history simplification problem

Hi,

I was trying to understand the history of a piece of code in LibreOffice and I'm facing a behaviour of git-log which is not something I can explain. I'm not sure if this is a git bug or a user error. ;)

Here is the situation:

git clone git://anongit.freedesktop.org/libreoffice/core cd core git log --full-history -p -S'mnTitleBarHeight =' sd/source/ui/dlg/PaneDockingWindow.cxx

Here the first output I get from git-log is b390fae1706b9c511158a03e4fd61f263be4e511, where you can see that the commit *added* that string. So it should be there on master, I would assume.

But then I run:

git grep 'mnTitleBarHeight =' sd

and it's not there. Am I missing something, as in e.g. even with --full-history git-log does some simplification?

Thanks,

Miklos

On Tue, Feb 04, 2014 at 06:37:13PM +0100, Miklos Vajna <vmiklos@collabora.co.uk> wrote:

I tried to reproduce this with a repo from scratch, and it seems my problem is the following:

1) "A" creates a feature branch
2) "A" works on it, and in the meantime master progresses as well
3) "A" merges master to the feature branch
4) "A" does some additional changes, and -- in an evil way -- uses "git
commit -a --amend" to squeeze these into the merge commit
5) "B" (that's me) comes and try to find out where a string got deleted,
but can't.

Here is a reproducer script:

---- rm -rf scratch mkdir scratch cd scratch git init echo -e "a\na\na\na\na\na\na\na\n" > a git add a git commit -m init git branch feature echo "b" >> a git add a git commit -m "more master changes" git checkout feature sed -i '1iXXX' a # insert first row git add a git commit -m "feature" git merge -m merge master sed -i '1d' a # delete first row git add a git commit --amend -m "merge" ----

I now know that the XXX got removed by the merge commit, but how can I see it that I'm right? If I run 'git log --all -p' in the result, I see that XXX got inserted by one commit, now I don't have it, but I don't see any deletion, which confuses me.

Any ideas? :-)

Thanks,

Miklos

Hi,

Miklos Vajna wrote:

df76bfb0695d19d201936df80192108e7ce51b8c (a merge) removed it.

Plain 'git log' doesn't notice because in the default mode it skips merges.

Since the culprit commit is not in the first-parent history of HEAD, my usual approach doesn't help, either:

	$ git log -m --first-parent -S'mnTitleBarHeight =' \
		-- sd/source/ui/dlg/PaneDockingWindow.cxx
	$ 

Using -c or --cc produces too many hits.

Luckily '-m -p' without --first-parent worked and the first commit it showed was the right one. It produces more hits than I'd like, too, though.

The -L option doesn't interact well enough with --reverse to handle this case:

	$ git grep -p -e'mnTitleBarHeight =' b390fae1 -- sd/source/ui/dlg/PaneDockingWindow.cxx
	b390fae1:sd/source/ui/dlg/PaneDockingWindow.cxx=void PaneDockingWindow::Layout (void)
	b390fae1:sd/source/ui/dlg/PaneDockingWindow.cxx:    mnTitleBarHeight = GetSettings().GetStyleSettings().GetTitleHeight();
	b390fae1:sd/source/ui/dlg/PaneDockingWindow.cxx:            mnTitleBarHeight = aToolBoxSize.Height();
	b390fae1:sd/source/ui/dlg/PaneDockingWindow.cxx:        mnTitleBarHeight = aToolBoxSize.Height();
	$ git log --reverse b390fae1..HEAD \
		-L:Layout:sd/source/ui/dlg/PaneDockingWindow.cxx
	fatal: -L parameter 'Layout' starting at line 1: no match

Thanks for a useful example. Jonathan

Hi Jonathan,

On Tue, Feb 04, 2014 at 11:48:42AM -0800, Jonathan Nieder <jrnieder@gmail.com> wrote:

Ah, excellent! :-) '-m' does what I need.

Thanks a lot,

Miklos

Miklos Vajna <vmiklos@collabora.co.uk> writes:

Lack of -m is what I would first suspect when somebody misunderstands "merge simplification". I am not saying that will be the issue, but merely pointing out that that is the first thing that jumps at me when I view the above command line.