git-log --full-history renamed-file

git-log --full-history renamed-file

[Jim Meyering]

Hello,

Is there some git-log-like command (or some git-log option)
to print a log of deltas affecting a file across renames?

I know that git-annotate can detect renames (and gitk),
but that's not quite the interface I was looking for.

I've tried with git-log --full-history, with and without --parents,
to no avail.  Adding --parents does make it produce a couple more
log entries, but they are not relevant.

The "Why does git not track renames?" section in the wiki,
http://git.or.cz/gitwiki/Godfry says that "git-log -M"
will do what I want, but that appears to have no effect.

To be precise, I'd like to run a command like this

  git-log <options> current-name

to summarize the commits affecting current-name as well as
those affecting old-name (which I git-mv'd to current-name).

Jim

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

[Linus Torvalds]

[ See toy patch at the end as an example of how you could do somethign 
  like this better. I started out just explaining what git does, but ended 
  up writing a simple patch that kind of shows an example of how it could 
  be implemented ]

On Fri, 9 Mar 2007, Jim Meyering wrote:
> 
> Is there some git-log-like command (or some git-log option)
> to print a log of deltas affecting a file across renames?

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.

> I know that git-annotate can detect renames (and gitk),
> but that's not quite the interface I was looking for.
> 
> I've tried with git-log --full-history, with and without --parents,
> to no avail.  Adding --parents does make it produce a couple more
> log entries, but they are not relevant.

Yeah, those don't really do what you want. They are entirely about the 
"time view" of the commits, they don't move in "space"

[ That's just my personal terminology: git tracks data in two different 
  dimensions: the contents ("space") and the history ("time"). So with 
  "git log" you can limit both the content dimension (by path limiters) 
  and the history dimension (with revision limiters).

  So --full-history and --parents are about showing more detail or 
  changing the limiting in that history dimension, but they do not affect 
  the content dimension. What you want to do is to let the content 
  limiters change over time, and yes, "git annotate" obviously does 
  exactly that, but no, we don't do it in "git log", and the space 
  limiters are entirely static over time right now ]

> The "Why does git not track renames?" section in the wiki,
> http://git.or.cz/gitwiki/Godfry says that "git-log -M"
> will do what I want, but that appears to have no effect.

Actually, it will have effect, but it will have an effect only *within* 
the space limiter (and only when you actually *watch* what happens by 
showing the patches).

So for an example of the effect, do

	git log -p 76cead39 Documentation

(or "git show" with, and without an "-M").

So no, the -M flag does *not* do what you want. Yes, it detects renames, 
but it does so within individual diffs, not over time. So to go back to my 
space/time analogy, "-M" works 100% in space, it's a one-time temporal 
event for showing single commit, it doesn't actually start following 
history down under any other name.

> To be precise, I'd like to run a command like this
> 
>   git-log <options> current-name
> 
> to summarize the commits affecting current-name as well as
> those affecting old-name (which I git-mv'd to current-name).

Yes. Rigth now you *can* emulate this (in a very cumbersome manner!) by 
letting "git show -M" help you see what happened. Eg, in git, many files 
have gotten renamed over time, and you can do something like

	git log builtin-rev-list.c

and when you go to the end of that result, you'll see the first commit 
where it showed up under that name:

	5fb61b8d: Make "git rev-list" be a builtin

and *now* you can use the "-M" flag to let git figure out what happened:

	git show -M 5fb61b8d

which will have

	diff --git a/rev-list.c b/builtin-rev-list.c
	similarity index 99%
	rename from rev-list.c
	rename to builtin-rev-list.c

(there are lots of other options, ie you could have used

	git show -M --name-status --pretty=oneline 5fb61b8d

and it would show the changes in a much condensed manner, but still 
showing the fact that "rev-list.c" got renamed to "builtin-rev-list.c" in 
that commit.

And after that, you could re-start the log from that point on (or rather, 
the parent), and with that older name:

	git log 5fb61b8d^ -- rev-list.c

In other words:

 - git can do it, but doesn't really have the interfaces to do it sanely 
   right now.

 - you can do it by hand

 - it's almost silly, but "git blame" internally really already has all 
   the logic for this, it's just not exposed any sane way to a user.

I'm appending a REALLY UGLY patch that makes

	git blame --log filename.c

work kind of like you'd want. IT IS NOT MEANT TO BE REALLY USED, because 
in particular, it doesn't take the nice log options (so you cannot make it 
show diffs etc, even though we have all the machinery in place for that). 
But it's an example of the fact that yes, git can do this, but we're so 
stupid that we don't really accept it.

(NOTE! It's also almost totally untested. It might not work. I'm sending 
it out as a very rough example, not as a serious contender)

		Linus

---
diff --git a/builtin-blame.c b/builtin-blame.c
index b51cdc7..470f3ae 100644
--- a/builtin-blame.c
+++ b/builtin-blame.c
@@ -41,8 +41,11 @@ static int max_score_digits;
 static int show_root;
 static int blank_boundary;
 static int incremental;
+static int log;
 static int cmd_is_annotate;
 
+static struct rev_info log_rev;
+
 #ifndef DEBUG
 #define DEBUG 0
 #endif
@@ -1376,6 +1379,16 @@ static void found_guilty_entry(struct blame_entry *ent)
 	if (ent->guilty)
 		return;
 	ent->guilty = 1;
+	if (log) {
+		struct origin *suspect = ent->suspect;
+		struct commit *commit = suspect->commit;
+
+		if (commit->object.flags & SHOWN)
+			return;
+		commit->object.flags |= SHOWN;
+		log_tree_commit(&log_rev, commit);
+		return;
+	}
 	if (incremental) {
 		struct origin *suspect = ent->suspect;
 
@@ -2073,7 +2086,7 @@ int cmd_blame(int argc, const char **argv, const char *prefix)
 	cmd_is_annotate = !strcmp(argv[0], "annotate");
 
 	git_config(git_blame_config);
-	save_commit_buffer = 0;
+//	save_commit_buffer = 0;
 
 	opt = 0;
 	seen_dashdash = 0;
@@ -2139,6 +2152,14 @@ int cmd_blame(int argc, const char **argv, const char *prefix)
 			seen_dashdash = 1;
 			i++;
 			break;
+		} if (!strcmp("--log", arg)) {
+			log = 1;
+			init_revisions(&log_rev, NULL);
+			log_rev.diff = 1;
+			log_rev.diffopt.recursive = 1;
+			log_rev.commit_format = CMIT_FMT_DEFAULT;
+			log_rev.verbose_header = 1;
+			log_rev.abbrev = DEFAULT_ABBREV;
 		}
 		else
 			argv[unk++] = arg;
@@ -2336,7 +2357,7 @@ int cmd_blame(int argc, const char **argv, const char *prefix)
 
 	assign_blame(&sb, &revs, opt);
 
-	if (incremental)
+	if (incremental || log)
 		return 0;
 
 	coalesce(&sb);

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

[Junio C Hamano]

Linus Torvalds <torvalds@linux-foundation.org> 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.

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

[Jakub Narebski]

Junio C Hamano wrote:

> Linus Torvalds <torvalds@linux-foundation.org> 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.

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

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

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

> 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 why Linus's proof-of-concept is based on the git-blame
engine.

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

[Linus Torvalds]

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

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

[Andy Parkins]

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

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

[Junio C Hamano]

Linus Torvalds <torvalds@linux-foundation.org> writes:

>  - it's almost silly, but "git blame" internally really already has all 
>    the logic for this, it's just not exposed any sane way to a user.
>
> I'm appending a REALLY UGLY patch that makes
>
> 	git blame --log filename.c
>
> work kind of like you'd want. IT IS NOT MEANT TO BE REALLY USED, because 
> in particular, it doesn't take the nice log options (so you cannot make it 
> show diffs etc, even though we have all the machinery in place for that). 
> But it's an example of the fact that yes, git can do this, but we're so 
> stupid that we don't really accept it.
>
> (NOTE! It's also almost totally untested. It might not work. I'm sending 
> it out as a very rough example, not as a serious contender)
>
> 		Linus

At this point that you call log_tree_commit(), 

> @@ -1376,6 +1379,16 @@ static void found_guilty_entry(struct blame_entry *ent)
>  	if (ent->guilty)
>  		return;
>  	ent->guilty = 1;
> +	if (log) {
> +		struct origin *suspect = ent->suspect;
> +		struct commit *commit = suspect->commit;
> +
> +		if (commit->object.flags & SHOWN)
> +			return;
> +		commit->object.flags |= SHOWN;
> +		log_tree_commit(&log_rev, commit);
> +		return;
> +	}

you have not just the path information _but_ also the line range
in the postimage, so we could use an enhanced version of
log_tree_commit() that also lets us limit its output only to
hunks that touch the affected range.

Also, found_guilty_entry() is called number of times for the
same suspect <commit, path> pair for discontiguous line ranges.
I think a saner thing to do is to collect and coalesce the blame
entry for the same <commit, path> in the above part of the code,
and then do a single log_tree_commit() for the <commit, path>,
perhaps limiting to the hunks that touch the line ranges the
commit is assigned blame for, before continuing to a different
commit (i.e. after the for() loop, which is the only caller of
this found_guilty_entry() function, exits).