Re: git-log --full-history renamed-file

Linus Torvalds [off-list ref] writes:

There were patches floating around for an option called "--follow" to "git 
log", that would actually follow the renames. 

I don't remember what happened to them - I suspect the implementation 
wasn't up to snuff. But the *concept* is definitely right.

Yes, the concept is good.  It was from Fredrik of
merge-recursive fame.

The patch was not _bad_, but it looked a bit too intrusive back
then and scared me away.

Junio C Hamano wrote:

Linus Torvalds [off-list ref] writes:

quoted

There were patches floating around for an option called "--follow" to "git 
log", that would actually follow the renames. 

I don't remember what happened to them - I suspect the implementation 
wasn't up to snuff. But the *concept* is definitely right.

Yes, the concept is good.  It was from Fredrik of
merge-recursive fame.

The patch was not _bad_, but it looked a bit too intrusive back
then and scared me away.

If I remember correctly it had somewhat unfortunate timing, as it
was around changes in the same area.

By the way, while it is fairly easy to follow one file, it is hard
to follow directory or glob... and there is a trouble that one file
might come from two files (as concatenation for example; but I don't
think git can detect it with default values of rename detection
heuristics). 

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

On Sat, 10 Mar 2007, Jakub Narebski wrote:

By the way, while it is fairly easy to follow one file, it is hard
to follow directory or glob...

Don't even try. Make it clear that the rename-following automatically 
means that you only do the trivially obvious cases. Anything else is 
madness.

If you want to know where something actually comes from, use "blame".

		Linus

On Saturday 2007, March 10, Jakub Narebski wrote:

By the way, while it is fairly easy to follow one file, it is hard
to follow directory or glob... and there is a trouble that one file
might come from two files (as concatenation for example; but I don't
think git can detect it with default values of rename detection
heuristics).

That's not rename detection then though.

I know git is clever and has potential to be able to do rename detection 
even when it was rename-and-modify.  For me though, I always like to 
make the job of the VCS easier by doing the rename in a separate commit 
from the modify.

I'd really like it if git would deal with the easy, 100% rename case, 
even if it didn't deal with the 
rename-two-files-to-be-one-file-and-modify-the-result case. 



Andy
-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com