git-log to go forward instead of reverse?

git-log to go forward instead of reverse?

[Randal L. Schwartz]

Am I missing an option to have git-log go forward in time rather than
backward?  I'd really like "git-log --pretty=short ORIG_HEAD..HEAD" to show me
a story I can read. :)

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: git-log to go forward instead of reverse?

[Linus Torvalds]

On Mon, 10 Jul 2006, Randal L. Schwartz wrote:
> 
> Am I missing an option to have git-log go forward in time rather than
> backward?  I'd really like "git-log --pretty=short ORIG_HEAD..HEAD" to show me
> a story I can read. :)

Well, as long as you realize that that automatically means that you have 
to walk the whole commit list, and you won't be able to get the 
incremental output that git-log and friends normally are able to give?

But this patch should do it. With it,

	git log --reverse --pretty=short ORIG_HEAD..

should do what you want.

It is _not_ possible to reverse the "gitk" view with this patch, though, 
as this does _not_ reverse parenthood information.

The "--reverse" flag could possibly be renamed. 

		Linus

---
diff --git a/revision.c b/revision.c
index 7df9089..13a3e40 100644
--- a/revision.c
+++ b/revision.c
@@ -698,6 +698,10 @@ int setup_revisions(int argc, const char
 				revs->topo_order = 1;
 				continue;
 			}
+			if (!strcmp(arg, "--reverse")) {
+				revs->reverse ^= 1;
+				continue;
+			}
 			if (!strcmp(arg, "--parents")) {
 				revs->parents = 1;
 				continue;
@@ -921,7 +925,7 @@ int setup_revisions(int argc, const char
 		add_pending_object(revs, object, def);
 	}
 
-	if (revs->topo_order || revs->unpacked)
+	if (revs->topo_order || revs->unpacked || revs->reverse)
 		revs->limited = 1;
 
 	if (revs->prune_data) {
@@ -941,6 +945,19 @@ int setup_revisions(int argc, const char
 	return left;
 }
 
+static struct commit_list *reverse_commit_list(struct commit_list *p)
+{
+	struct commit_list *result = NULL;
+
+	while (p) {
+		struct commit_list *next = p->next;
+		p->next = result;
+		result = p;
+		p = next;
+	}
+	return result;
+}
+
 void prepare_revision_walk(struct rev_info *revs)
 {
 	int nr = revs->pending.nr;
@@ -968,6 +985,8 @@ void prepare_revision_walk(struct rev_in
 		sort_in_topological_order_fn(&revs->commits, revs->lifo,
 					     revs->topo_setter,
 					     revs->topo_getter);
+	if (revs->reverse)
+		revs->commits = reverse_commit_list(revs->commits);
 }
 
 static int rewrite_one(struct rev_info *revs, struct commit **pp)
diff --git a/revision.h b/revision.h
index c010a08..ff6ce44 100644
--- a/revision.h
+++ b/revision.h
@@ -32,6 +32,7 @@ struct rev_info {
 			remove_empty_trees:1,
 			simplify_history:1,
 			lifo:1,
+			reverse:1,
 			topo_order:1,
 			tag_objects:1,
 			tree_objects:1,

Re: git-log to go forward instead of reverse?

[Randal L. Schwartz]

>>>>> "Linus" == Linus Torvalds <torvalds@osdl.org> writes:

Linus> Well, as long as you realize that that automatically means that you
Linus> have to walk the whole commit list, and you won't be able to get the
Linus> incremental output that git-log and friends normally are able to give?

Wow.  Yes, I think I can live with that for the application.

Linus> But this patch should do it.

Thanks!

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: git-log to go forward instead of reverse?

[Linus Torvalds]

On Mon, 10 Jul 2006, Randal L. Schwartz wrote:
> 
> Linus> Well, as long as you realize that that automatically means that you
> Linus> have to walk the whole commit list, and you won't be able to get the
> Linus> incremental output that git-log and friends normally are able to give?
> 
> Wow.  Yes, I think I can live with that for the application.

It's a big deal for me, I often end up doing things like

	git log -p some-random-file

to see what has happened, and getting the most recent changes basically 
instantaneously (rather than waiting for the thing to traverse all of the 
history) is a big deal.

If you have a fairly small archive, or you don't use pathname limiting, 
the history generation is so fast that you'll never even notice. But with 
the kernel, doing something like

	git log drivers/serial

takes just over two seconds for me, and if I had to wait for two seconds 
before the first data starts arriving, I'd go nuts.

To see this in cold hard numbers:

	// Full log
	[torvalds@g5 linux]$ time git log drivers/serial > /dev/null 

	real    0m2.267s
	user    0m2.204s
	sys     0m0.020s

	// Simulate "get the first screenful"
	[torvalds@g5 linux]$ time git log drivers/serial | head -25 > /dev/null 

	real    0m0.054s
	user    0m0.048s
	sys     0m0.008s

	// Simulate "get the first screenful of reverse output"
	[torvalds@g5 linux]$ time git log --reverse drivers/serial | head > /dev/null 

	real    0m2.218s
	user    0m2.176s
	sys     0m0.044s

and it's the difference between the second and the third case I wanted to 
point out.

The difference between getting the first screenful in 0.054 seconds versus 
it taking 2.218 seconds is quite noticeable, and one of the things I've 
actually spent a fair amount of time on is to make sure that the 
incremental output case is the _common_ one for all the normal operations 
like "git log -p".

			Linus

Re: git-log to go forward instead of reverse?

[Randal L. Schwartz]

>>>>> "Linus" == Linus Torvalds <torvalds@osdl.org> writes:

>> Wow.  Yes, I think I can live with that for the application.

Linus> It's a big deal for me, I often end up doing things like

Linus> 	git log -p some-random-file

Linus> to see what has happened, and getting the most recent changes basically 
Linus> instantaneously (rather than waiting for the thing to traverse all of the 
Linus> history) is a big deal.

Well, this is for a "I'm connected to the net right now: please
refresh all of my git mirrors" script:

        ## (code here to cd to the right dir omitted)
                git-fetch
                if git-status | grep -v 'nothing to commit'
                then echo UPDATE SKIPPED
                else
                    if git-pull . origin | egrep -v 'up-to-date'
                    then git-log --pretty=short ORIG_HEAD..HEAD | cat
                    fi
                fi

The log is just so I can quickly eyeball the interesting changes.  The "cat"
is to keep git-log from starting a pager.  (If there's a switch that does
*that* that I've overlooked, that'd be good too.)

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: git-log to go forward instead of reverse?

[Linus Torvalds]

On Mon, 10 Jul 2006, Randal L. Schwartz wrote:
>
>                     then git-log --pretty=short ORIG_HEAD..HEAD | cat

> The log is just so I can quickly eyeball the interesting changes.  The "cat"
> is to keep git-log from starting a pager.  (If there's a switch that does
> *that* that I've overlooked, that'd be good too.)

Just do

	PAGER= git log --pretty=short ORIG_HEAD..HEAD

instead.

And if you didn't know about "git shortlog" already, I personally actually 
find it easier to read

	git log --no-merges ORIG_HEAD.. | git shortlog

which orders things by author instead.  It also reverses the log messages 
as it does so, so each author will have the one-liners sorted oldest to 
newest the way you wanted to (so you do _not_ want to pass --reverse to 
that git-shortlog invocation).

		Linus

Re: git-log to go forward instead of reverse?

[Randal L. Schwartz]

>>>>> "Linus" == Linus Torvalds <torvalds@osdl.org> writes:

Linus> And if you didn't know about "git shortlog" already, I personally actually 
Linus> find it easier to read

Linus> 	git log --no-merges ORIG_HEAD.. | git shortlog

Linus> which orders things by author instead.  It also reverses the log
Linus> messages as it does so, so each author will have the one-liners sorted
Linus> oldest to newest the way you wanted to (so you do _not_ want to pass
Linus> --reverse to that git-shortlog invocation).

See -- I *knew* there was a shorter way.

Looks like I owe you lunch.  (Again? :)

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: git-log to go forward instead of reverse?

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

> And if you didn't know about "git shortlog" already, I personally actually 
> find it easier to read
>
> 	git log --no-merges ORIG_HEAD.. | git shortlog
>
> which orders things by author instead.

Yes, and you can even have '-p' between git and shortlog in the
latter command if you do want the pager ;-).

BTW, when I prepare the "What's in" messages, I often find it
more useful to have a brother of short-log command that does not
group by author but group by topic branch the commits came from.

Currently I prepare the categorized list by hand, reviewing each
commit in "master..next" shortlog output.  While I do not mind
it too much since that is a good way to remind myself what are
still cooking, it would be nice to have to a command that takes:

	- which branch the output is relative to (defaults
          to "master");

	- list of branches that are "topics";

        - which branch the parts of topics have been merged to
          (optional -- I'd use "next" for my use).

and for each topic:

	- see if the topic branches off from another topic (for
          example, the merge-tree topic branches off from the
          xdiff-common topic like [*1*]); if so, state that and
          use that branch point instead of "master" in the next
          step;

	- list commits that have not made "master" yet;
          optionally, when "next" is given, limit the output
          only to the ones that have made "next" already.


[Footnote]

*1*

$ git show-branch --topics master lt/xdiff-common lt/merge-tree
* [master] git-rev-list: add documentation for --parents, --no-merges
 ! [lt/xdiff-common] xdiff: generate "anti-diffs" aka what is common...
  ! [lt/merge-tree] Improved three-way blob merging code
---
  + [lt/merge-tree] Improved three-way blob merging code
  + [lt/merge-tree^] Prepare "git-merge-tree" for future work
 ++ [lt/xdiff-common] xdiff: generate "anti-diffs" aka what is common...
*++ [master~67] checkout -m: fix read-tree invocation

Re: git-log to go forward instead of reverse?

[Junio C Hamano]

merlyn@stonehenge.com (Randal L. Schwartz) writes:

> Well, this is for a "I'm connected to the net right now: please
> refresh all of my git mirrors" script:
>
>         ## (code here to cd to the right dir omitted)
>                 git-fetch
>                 if git-status | grep -v 'nothing to commit'

git-status exits non-zero for "nothing to commit" case, so do
not grep its output, but check the status of the command, to see
if your tree is in a good shape to do a pull.

>                 then echo UPDATE SKIPPED
>                 else
>                     if git-pull . origin | egrep -v 'up-to-date'
>                     then git-log --pretty=short ORIG_HEAD..HEAD | cat
>                     fi
>                 fi
>
> The log is just so I can quickly eyeball the interesting changes.

Do we not leave ORIG_HEAD when we are already up-to-date?  If so
that would be confusing...  No, we do leave ORIG_HEAD no matter
what, so you do not have to have this inner if to grep
up-to-date (on the other hand, you might want to do intelligent
things when git-pull fails).  So just drop the if and say
something like:

	else
        	PAGER= ; export PAGER
                git pull . origin &&
                git log --pretty ORIG_HEAD..HEAD |
                git shortlog
	fi

> The "cat"
> is to keep git-log from starting a pager.  (If there's a switch that does
> *that* that I've overlooked, that'd be good too.)

BTW,

        PAGER=cat
        export PAGER

This should work as more efficiently -- see pager.c ;-)

Re: git-log to go forward instead of reverse?

[Randal L. Schwartz]

>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:

>> ## (code here to cd to the right dir omitted)
>> git-fetch
>> if git-status | grep -v 'nothing to commit'

Junio> git-status exits non-zero for "nothing to commit" case, so do
Junio> not grep its output, but check the status of the command, to see
Junio> if your tree is in a good shape to do a pull.

No, this is deliberate.  I want to see nothing if we're up to date, but if
not, I want to see *everything else* that git-status said.  This nice "grep
-v" does precisely the right thing.

Junio> Do we not leave ORIG_HEAD when we are already up-to-date?  If so
Junio> that would be confusing...  No, we do leave ORIG_HEAD no matter
Junio> what, so you do not have to have this inner if to grep
Junio> up-to-date (on the other hand, you might want to do intelligent
Junio> things when git-pull fails).  So just drop the if and say
Junio> something like:

Junio> 	else
Junio>         	PAGER= ; export PAGER
Junio>                 git pull . origin &&
Junio>                 git log --pretty ORIG_HEAD..HEAD |
Junio>                 git shortlog
Junio> 	fi

However, this is good to know.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: git-log to go forward instead of reverse?

[Linus Torvalds]

On Mon, 10 Jul 2006, Linus Torvalds wrote:
> 
> The difference between getting the first screenful in 0.054 seconds versus 
> it taking 2.218 seconds is quite noticeable, and one of the things I've 
> actually spent a fair amount of time on is to make sure that the 
> incremental output case is the _common_ one for all the normal operations 
> like "git log -p".

Side note: the good news is that even with the reverse generation, if you 
also generate _diffs_, the diffs will be generated incrementally, so:

	// Full "git log" with diffs
	[torvalds@g5 linux]$ time git log -p drivers/serial > /dev/null 

	real    0m3.409s
	user    0m3.360s
	sys     0m0.052s

	// First screenful of reverse git log with diffs
	[torvalds@g5 linux]$ time git log -p --reverse drivers/serial | head -25 > /dev/null 
	
	real    0m2.228s
	user    0m2.216s
	sys     0m0.012s

	// First screenful of regular git log with diffs
	[torvalds@g5 linux]$ time git log -p drivers/serial | head -25 > /dev/null 
	
	real    0m0.038s
	user    0m0.036s
	sys     0m0.004s

here you can see how the full "git log -p" is obviously more expensive 
than the full "git log" was (the diff generation adds about a second to 
the full time), but because the diffs are generated incrementally as they 
are shown even with "--reverse", the first screenful of the "--reverse" 
case didn't get any more expensive, because we didn't generate all the 
diffs up-front, just the ones we needed.

And the first screenfull of the normal case obviously stays really fast, 
because both history generation _and_ diff generation is all on-the-fly.

			Linus