Re: [PATCH] cg-history FILE [NTH_PARENT]

[ Ok, time for some serious power-git usage ]

On Tue, 18 Oct 2005, John Ellson wrote:

Actually, you're much better of _not_ using "-p" to generate a patch.

In fact, you don't even want the pretty format that "git-whatchanged" does, you really want the raw output.

Try this instead:

	git-rev-list HEAD | git-diff-tree --stdin -s -r "$ARG"

which will give _just_ a list of the commits that change the file "$ARG".

Here, the "--stdin" to git-diff-tree means that it should take its revision input from stdin (ie obvously the list of commits generated by git-rev-list), and the "-s" stands for "silent", ie git-diff-tree won't actually output the diff itself.

And the "-r" means that it should check the trees "recursively", which is needed since we want the diff-tree to traverse down the tree rather than just look at the top-level ("-p" to generate patches enables recursive by default since patches don't make sense on raw trees, but without the -p you need to do it explicitly).

And since we didn't ask for the header, the only thing you get is the list of commits that changed the file describled by the argument.

So now, you can just pick the n'th such commit, and do something like this

	#
	# Get the "${ARGS[1]}"th commit that changes  file "${ARGS[0]}"
	#
	rev=$(git-rev-list HEAD |
		git-diff-tree --stdin -s -r "${ARGS[0]}" |
		head -n "${ARGS[1]}" |
		tail -1)

	#
	# Pick up the file from that tree
	#
	filerev=$(git-ls-tree -r "$rev" "${ARGS[0]}" |
		cut -f1 |
		cut -d' ' -f3)

	#
	# And show it
	#
	git-cat-file blob $filerev

and you're done (untested, but you should get the idea).

Now, the interesting part about is that you can feed the output from git-diff-tree _back_ to git-diff-tree, so you can do some really fancy footwork like:

	git-rev-list rev1..rev2 |
		git-diff-tree --stdin -s -r "$ARG" |
		git-diff-tree --stdin -M --pretty -p

and what this will do is:

 - generate a list of all commits between rev1 and rev2

 - filter out just the commits that change the file "$ARG", and pass those 
   on.

 - for those commits, show the _whole_ diff, with rename detection and 
   with pretty-printed commit comment headers

In other words, you can basically look at all the full commits that changed one file (or a set of files). Efficiently.

This is kind of like "git-whatchanged", but it shows the full context of what changed. Of course, the second git-diff-tree can be used to limit the context to something else, ie you could do a variation of the above, something like

	git-rev-list v2.6.12.. |
		git-diff-tree --stdin -s -r drivers/usb/ |
		git-diff-tree --stdin -M --pretty -p drivers/ include/

which will show any commit that changed the drivers/usb/ directory after v2.6.12, but then limit the output of those commits to the drivers/ and include/ subdirectories (so anything that was changed in that same commit in a filesystem would _not_ be shown, for example, but if there were changes to drivers/scsi/ at the same time, they _would_ show).

Or, if you want to go really wild, do something like this on the kernel git tree:

	git-rev-list v2.6.12.. |
		git-diff-tree --stdin -s -r drivers/usb/ |
		git-diff-tree --stdin -s -r drivers/scsi/ |
		git-diff-tree --stdin -M --pretty -p drivers/scsi/ drivers/usb/ |
		less -S

which says to print out only those commits that change something _both_ in drivers/usb/ _and_ in drivers/scsi/ at the same time, and then show only those parts of the changes.

Try it out. It really does work, and is extremely powerful. It's even pretty efficient (make sure your tree is packed first, though ;). I can do the above in about three seconds for the current kernel history on my machine. That's 3 _seconds_ to go through what right now is 8005 commits:

	git-rev-list v2.6.12.. | wc -l

and the reason is exactly that the filename-based parsing is very good at efficiently pruning out all the tree information that isn't needed.

Very cool.

However, the "normal" situation is just the standard "git-whatchanged", which is much easier to use than something more complex like the above.

The core git commands are really designed to be scriptable, but "real life" seldom wants the complexity of quite that much flexibility.

		Linus