On Wed, 9 May 2007 08:52:09 -0700 (PDT), Linus Torvalds wrote: [Snip good description of rebuilding a branch to meet some "target" state.] That's all really good stuff. And as you mentioned you sometimes use cherry-pick during this rebuilding, one can also use "git add -i" to help with splitting up an ugly commit that should have been multiple commit. For example, a sequence might look like this, (I always use "desired" where you use target): git diff HEAD desired | git apply git add -i git commit git reset --hard # test here and commit --amend as needed And repeat that as needed. It's really no different than your "edit the diff" approach. It's just using "add -i" instead of a text editor. But I do admit that the commit;reset;test;--amend sequence might seem a bit too awkward to some people. > test-things, but since one of them was a filesystem fix, and the other one > was in the kernel, rather than give all the paths explicitly, I'd do > > git commit fs/ > > and it will automatically do the right thing (actually, I often end up > using the two-stage "git add" + "git commit" thing, because one of the > more common cases for me is that I'm going to commit a merge that I fixed > up a conflict in, and then you have to do it that way). This reminds me of a confusing semantic issue that came about with the "new" add. It can be quite natural to commit a single file in one step with: git commit some-file.c or to do that in two steps with: git add some-file.c git commit (which is particularly useful if one wants to add multiple files). I recently found myself wanting to do a similar thing with a directory path. I can commit a path with: git commit path/ but I don't get anything at all like the same semantics if I do: git add path/ git commit (since "git add" will recursively add all untracked files under path/). Now the "recursively add all files" behavior is older, and has been an essential part of git-add forever. But I found it to be not at all what I wanted in this case, (where I'm now trained to say "git add" to stage things into the index). I don't know of any good fix for the problem now. Maybe I'll just need to remember to break out that old "git update-index" for a situation like this, but that sure feels clunky. -Carl
Attachment:
pgpcpq3rpJtlk.pgp
Description: PGP signature
