Re: git Tutorial?

[ git-list cc'd, since these example things might be useful to others ]

On Fri, 24 Jun 2005, Patrick Mochel wrote:

Indeed. It can be slow if things aren't in cache, but even then it's usually not really slower than something like CVS would be.

You can script it (and if you do so nicely, feel free to send me a patch). Here's the magic long-hand version that does something fairly close to it:

	git-rev-list --header HEAD |
		grep -z author.*torvalds |
		tr '\0\n' '\n:' |
		cut -d: -f1 |
		git-diff-tree --pretty --stdin -p |
		less -S

(That's really hacky, because "cut" and other standard unix tools don't like using '\0' as a record separator, but hey, whatever works..)

The above gives the result in "git-whatchanged" format, ie you get the patch too. If you don't want to see the patch, give the "-s" flag to git-diff-tree instead of the "-p" flag, but if you script it, I'd suggest allowing the user to give that as an option to the script.

Same deal. No nice script, but it's easy to do:

 - find the top-of-tree you want to go back to. If you know this is the 
   parent of the current HEAD, you can use the git-rev-parse helper:

	target=$(git-rev-parse HEAD^)

   to find that.

 - do a "fast-forward" from the current HEAD to the head you want to go 
   to. Never mind that it's a "fast-backward" in this case, that's 
   symmetrical:

	git-read-tree -m -u HEAD $target &&
		(echo $target > .git/HEAD)

   This magic line just says "merge (-m) while keeping the working 
   directory up-to-date with the changes (-u) from my current position 
   (HEAD) to my new position ($target), and if that worked, write the new 
   position into the HEAD file"

 - If you then want to get _rid_ of the old HEAD stuff (ie you know you 
   don't want to go back to it) you can then follow up with a "git prune", 
   which will prune away all the unreachable objects. Be careful, though, 
   that really _will_ throw it all away, and it's gone, gone, gone. Before 
   you did "git prune", you could still get your old data back by just 
   looking for unconnected commits (git-fsck-cache and git-cat-file will
   help you) and doing the above in reverse.

And that was it. You can make it even nicer when scripting by using something like this

	#!/bin/sh

	# get the thing to undo to (default the first parent of the
	# last commit, regardless of whether it was a merge or a
	# regular commit
	# 
	default_target=$(git-rev-parse HEAD^)
	target=$(git-rev-parse --default $default_target --revs-only "$@")

	# Check that it's a valid commit
	git-cat-file commit "$target" > /dev/null || exit 1

	# Do it
	git-read-tree -m -u HEAD $target &&
		(echo $target > .git/HEAD)

and then you can add some fancy flags or whatever.

This one is trivial.

	git-diff-tree --pretty $rev

does exactly that: it shows a single revision, with a pretty changelog.

And if you want to get diffs or ranges, use

	git diff rev1..rev2

or similar.

		Linus