Bug? Files are losing history after subtree merge

Bug? Files are losing history after subtree merge

[Ralf Thielow]

Hi,

recently I did a merge where a complete repo shall be
merged into a specific directory of another repo. I
tried both the "subtree" merge strategy and the option
"-Xsubtree=<dir>" of "recursive". I noticed that in both
cases somehow the history of single files were lost
during these merges (with history I mean 'git log <file>'
and 'git log --follow <file>'). I've worked around this
by merging without 'subtree' and moving the dirs/files
manually. In this case the file history was there.

I've added a test case below for that behaviour. It doesn't
catch "-S recursive -Xsubtree=<dir>" but it should show
the issue (hopefully:).

Ralf
---
 t/t6029-merge-subtree.sh | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/t/t6029-merge-subtree.sh b/t/t6029-merge-subtree.sh
index 73fc240..e9a97d7 100755
--- a/t/t6029-merge-subtree.sh
+++ b/t/t6029-merge-subtree.sh
@@ -61,6 +61,14 @@ test_expect_success 'initial merge' '
 	test_cmp expected actual
 '
 
+test_expect_failure 'file keeps history after subtree merge' '
+	cd ../git-gui &&
+	git log --follow git-gui.sh >../git/expected &&
+	cd ../git &&
+	git log --follow git-gui/git-gui.sh >actual &&
+	test_cmp expected actual
+'
+
 test_expect_success 'merge update' '
 	cd ../git-gui &&
 	echo git-gui2 > git-gui.sh &&
-- 
1.8.4.652.g0d6e0ce

Re: Bug? Files are losing history after subtree merge

[Matthieu Moy]

Ralf Thielow <ralf.thielow@gmail.com> writes:

> Hi,
>
> recently I did a merge where a complete repo shall be
> merged into a specific directory of another repo. I
> tried both the "subtree" merge strategy and the option
> "-Xsubtree=<dir>" of "recursive". I noticed that in both
> cases somehow the history of single files were lost
> during these merges (with history I mean 'git log <file>'
> and 'git log --follow <file>').

This is a known bug of "git log --follow": it does not follow accross
subtree merge. But your history is still there (try gitk on your project
for example).

Technically, a subtree merge is a merge commit in which files are
renamed compared to the second parent. --follow does not manage this
case.

> diff --git a/t/t6029-merge-subtree.sh b/t/t6029-merge-subtree.sh
> index 73fc240..e9a97d7 100755
> --- a/t/t6029-merge-subtree.sh
> +++ b/t/t6029-merge-subtree.sh
> @@ -61,6 +61,14 @@ test_expect_success 'initial merge' '
>  	test_cmp expected actual
>  '
>  
> +test_expect_failure 'file keeps history after subtree merge' '
> +	cd ../git-gui &&
> +	git log --follow git-gui.sh >../git/expected &&
> +	cd ../git &&
> +	git log --follow git-gui/git-gui.sh >actual &&
> +	test_cmp expected actual
> +'
> +

That would actually be good to add a failing test to "document" the
failure.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: Bug? Files are losing history after subtree merge

[Ralf Thielow]

On Wed, Oct 2, 2013 at 9:42 PM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> Ralf Thielow <ralf.thielow@gmail.com> writes:
>
>> Hi,
>>
>> recently I did a merge where a complete repo shall be
>> merged into a specific directory of another repo. I
>> tried both the "subtree" merge strategy and the option
>> "-Xsubtree=<dir>" of "recursive". I noticed that in both
>> cases somehow the history of single files were lost
>> during these merges (with history I mean 'git log <file>'
>> and 'git log --follow <file>').
>
> This is a known bug of "git log --follow": it does not follow accross
> subtree merge. But your history is still there (try gitk on your project
> for example).
>
> Technically, a subtree merge is a merge commit in which files are
> renamed compared to the second parent. --follow does not manage this
> case.
>

Thanks for explanation.
I knew the history of the repo is there, but the history of single files
(and the ability to look at it) is so important that subtree-merges aren't
an option for us. Such merges are rarely, luckily, but it would be nice
to get it work.

Thanks

>> diff --git a/t/t6029-merge-subtree.sh b/t/t6029-merge-subtree.sh
>> index 73fc240..e9a97d7 100755
>> --- a/t/t6029-merge-subtree.sh
>> +++ b/t/t6029-merge-subtree.sh
>> @@ -61,6 +61,14 @@ test_expect_success 'initial merge' '
>>       test_cmp expected actual
>>  '
>>
>> +test_expect_failure 'file keeps history after subtree merge' '
>> +     cd ../git-gui &&
>> +     git log --follow git-gui.sh >../git/expected &&
>> +     cd ../git &&
>> +     git log --follow git-gui/git-gui.sh >actual &&
>> +     test_cmp expected actual
>> +'
>> +
>
> That would actually be good to add a failing test to "document" the
> failure.
>
> --
> Matthieu Moy
> http://www-verimag.imag.fr/~moy/

Re: Bug? Files are losing history after subtree merge

[Matthieu Moy]

Ralf Thielow <ralf.thielow@gmail.com> writes:

> Thanks for explanation.
> I knew the history of the repo is there, but the history of single files
> (and the ability to look at it)

There is no such thing as "single file history" in Git. Git knows about
the history of the project, and knows which files were there at each
commit. Then, some commands can walk through history following the
history of a file. "git blame" is very good at it, and should work with
subtree merges. "git log --follow" is a quick hack that nobody bothered
to fix up to now (sadly).

You can use workarounds like

  git log -- '*git-gui.sh'

(from the toplevel), to view each commit that touched a file whose name
ends with git-gui.sh. It won't follow actual renames, and may show false
positive if you have several files with the same basename. But it may
help.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: Bug? Files are losing history after subtree merge

[Ralf Thielow]

On Wed, Oct 2, 2013 at 10:21 PM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> Ralf Thielow <ralf.thielow@gmail.com> writes:
>
>> Thanks for explanation.
>> I knew the history of the repo is there, but the history of single files
>> (and the ability to look at it)
>
> There is no such thing as "single file history" in Git. Git knows about
> the history of the project, and knows which files were there at each
> commit. Then, some commands can walk through history following the
> history of a file. "git blame" is very good at it, and should work with
> subtree merges. "git log --follow" is a quick hack that nobody bothered
> to fix up to now (sadly).
>

Yeah
From a user perspective there is a "single file history", isn't it? And in
this case the history is gone. At least in the subtree case...

> You can use workarounds like
>
>   git log -- '*git-gui.sh'
>

"My" users are using gui tools, so there's sadly no chance to change the
commands.
I just wanted to mention the issue but I've worked around it so it's
no problem anymore.

> (from the toplevel), to view each commit that touched a file whose name
> ends with git-gui.sh. It won't follow actual renames, and may show false
> positive if you have several files with the same basename. But it may
> help.
>
> --
> Matthieu Moy
> http://www-verimag.imag.fr/~moy/