git-log to go forward instead of reverse?

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. :)

On Mon, 10 Jul 2006, Randal L. Schwartz wrote:

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

---

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!

On Mon, 10 Jul 2006, Randal L. Schwartz wrote:

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

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.)

On Mon, 10 Jul 2006, Randal L. Schwartz wrote:

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

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? :)

Linus Torvalds <torvalds@osdl.org> writes:

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

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

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.

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

BTW,

        PAGER=cat
        export PAGER

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

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.

On Mon, 10 Jul 2006, Linus Torvalds wrote:

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