Re: [ANNOUNCE] Git wiki

Petr Baudis [off-list ref] writes:

But the non-obviously important part here to note is that the branch B
merely "corrects a typo on a comment somewhere" - the latest versions in
branch A and branch B are always compared for renames, therefore if
branch A renamed the file and branch B sums up to some larger-scale
changes in the file, it still won't be merged properly.

I probably am guilty of starting this misinformation, but the
code does not compare the latest in A and B for rename
detection; it compares (O, A) and (O, B).

But the end result is the same - what you say is correct.  If a
path (say O to A) that renamed has too big a change, then no
matter how small the changes are on the other path (O to B),
rename detection can be fooled.  We could perhaps alleviate it
by following the whole commit chain.

Dear diary, on Fri, May 05, 2006 at 11:51:01AM CEST, I got a letter
where Junio C Hamano [off-list ref] said that...

Petr Baudis [off-list ref] writes:

quoted

But the non-obviously important part here to note is that the branch B
merely "corrects a typo on a comment somewhere" - the latest versions in
branch A and branch B are always compared for renames, therefore if
branch A renamed the file and branch B sums up to some larger-scale
changes in the file, it still won't be merged properly.

I probably am guilty of starting this misinformation, but the
code does not compare the latest in A and B for rename
detection; it compares (O, A) and (O, B).

Where O = LCA(A,B) (modulo recursiveness)? Yes, that is what I meant to
say but I phrased it wrong, sorry.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time.  I think
I have forgotten this before.

Junio C Hamano wrote:

Petr Baudis [off-list ref] writes:

quoted

But the non-obviously important part here to note is that the branch B
merely "corrects a typo on a comment somewhere" - the latest versions in
branch A and branch B are always compared for renames, therefore if
branch A renamed the file and branch B sums up to some larger-scale
changes in the file, it still won't be merged properly.

I probably am guilty of starting this misinformation, but the
code does not compare the latest in A and B for rename
detection; it compares (O, A) and (O, B).

But the end result is the same - what you say is correct.  If a
path (say O to A) that renamed has too big a change, then no
matter how small the changes are on the other path (O to B),
rename detection can be fooled.  We could perhaps alleviate it
by following the whole commit chain.

Or perhaps by helper information about renames, entered either by git-mv
(and git-cp) or rename detection at commit, e.g. in the following form

        note at <commit-sha1> was-in <pathname>
        note at <commit-sha1> was-in <pathname>

(with the obvious limit of this "note header" solution is that it wouldn't
work for filenames and directory name containing "\n"). I'm not sure if
<pathname> should be just basename, of full pathname.

-- 
Jakub Narebski
Warsaw, Poland

Jakub Narebski wrote:

Junio C Hamano wrote:

quoted

Petr Baudis [off-list ref] writes:

quoted

But the non-obviously important part here to note is that the branch B
merely "corrects a typo on a comment somewhere" - the latest versions in
branch A and branch B are always compared for renames, therefore if
branch A renamed the file and branch B sums up to some larger-scale
changes in the file, it still won't be merged properly.

I probably am guilty of starting this misinformation, but the
code does not compare the latest in A and B for rename
detection; it compares (O, A) and (O, B).

But the end result is the same - what you say is correct.  If a
path (say O to A) that renamed has too big a change, then no
matter how small the changes are on the other path (O to B),
rename detection can be fooled.  We could perhaps alleviate it
by following the whole commit chain.

Or perhaps by helper information about renames, entered either by git-mv
(and git-cp) or rename detection at commit, e.g. in the following form

        note at <commit-sha1> was-in <pathname>
        note at <commit-sha1> was-in <pathname>

(with the obvious limit of this "note header" solution is that it wouldn't
work for filenames and directory name containing "\n"). I'm not sure if
<pathname> should be just basename, of full pathname.

Erm, I'm sorry, forget the implementation which wouldn't work. The idea was
to accumulate renames and contents moving information, and remember at
which commit it occured. But it's place (as a _helper_ information) is
perhaps in separate structure.

-- 
Jakub Narebski
Warsaw, Poland