Re: [FAQ?] Rationale for git's way to manage the index

On Wed, 9 May 2007, Daniel Barkalow wrote:

Well, I actually think it sounds like a complicated sequence because I tried to explain what I do.

The "script" parts don't really end up being any smaller, and not scripting it actually means that I can (and often do) things outside of a strict scripting environment.

As mentioned, I not only mix it up with "git cherry-pick", but since I just use "git diff", I can - and do - things like pick only a certain set of files to diff and edit the patch on.

So it's an iterative process at several levels (the "outer" level is the act of actually committing each change, and iterating to the next one, while the "inner" level is often a sequence of "git diff" exploration), it's not very fixed.

For example, when I said that I do a 

	git diff -R target > diff

that's not strictly true. The "git diff -R" is useful for comparing the current working tree to another commit, but quite often I actually end up doing it differently, and doing it as

	git diff ..target file > diff
	.. edit ..
	git apply diff

or, if I don't need the edit (ie just the fact that I limit it to a single file is a sufficient "edit" in itself), I might just do

	git checkout target file

instead, which will fetch the whole file from the "target" branch (and also update it in the index, which may or may not actually be what I want, but that's a different issue).

So the "process" as far as I'm concerned is actually much more fluid than necessarily always working with diffs. Git gives you so many ways to do things like this, and I'm pretty comfortable with lots of them.

			Linus