git log history simplification problem

git log history simplification problem

[Miklos Vajna]

[-- Attachment #1: Type: text/plain, Size: 760 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: git log history simplification problem

[Miklos Vajna]

[-- Attachment #1: Type: text/plain, Size: 1480 bytes --]

On Tue, Feb 04, 2014 at 06:37:13PM +0100, Miklos Vajna <vmiklos@collabora.co.uk> wrote:
> 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?

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: git log history simplification problem

[Jonathan Nieder]

Hi,

Miklos Vajna wrote:

> 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.

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

Re: git log history simplification problem

[Miklos Vajna]

[-- Attachment #1: Type: text/plain, Size: 319 bytes --]

Hi Jonathan,

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

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

Thanks a lot,

Miklos

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: git log history simplification problem

[Junio C Hamano]

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

> 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

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.


>
> 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