On Mon, Oct 26, 2009 at 6:14 PM, Jeff King <peff@xxxxxxxx> wrote: > On Mon, Oct 26, 2009 at 06:01:29PM -0400, Avery Pennarun wrote: >> > It's git-update-ref. >> >> That would be similar to git commit, not git checkout, right? Oh >> wait, I see the confusion: git checkout does two things. It switches >> branches, and it checks out files from the index into the work tree. >> I meant the latter meaning. > > Er, sorry, yes. It should be "git symbolic-ref", of course, to change > HEAD, and then probably read-tree and checkout-index. I was just not > thinking when I wrote the other message (hopefully I am doing so now). Wow, I've browsed through the git manpages repeatedly and never found checkout-index. It was exactly the missing building block I was looking for. Thanks! >> > Consider "git commit", for example. Does anyone >> > actually script around "write-tree" and "commit-tree" these days, or do >> > they just script around "git commit"? >> >> Oh, I use those all the time. They're awesome! It allows you to >> create commits without having a working tree, which lets me do very >> interesting tricks. git-subtree uses this heavily. >> >> I'm probably a weirdo, though. > > OK, I should have phrased my statement differently (see, I told you I > wasn't thinking). Yes, there are reasons to script around low-level > building blocks, when you don't want the assumptions associated with the > higher level. But I'm sure there are tons of scripts that munge some > files in a worktree, followed by "git add -A; git commit -m 'automagic > update'". And in that case, nobody would script around "commit-tree" > because it's a lot more work. Unfortunately this is pretty tricky to get perfect; perhaps there's no way to do it. In git-subtree, for example, I *mostly* use write-tree and commit-tree, but when I do the final merge operation (to take the synthetic history and merge it into your "real" history) I use commit. This is because I wanted the default merge handling, commit message, etc for that part. Unfortunately, it's possible that this dragged in a bunch of stuff I *didn't* want. It also makes git-subtree, which otherwise could be used as plumbing, effectively into a porcelain. I don't really know what to do about that. You could introduce an abstraction level somewhere between commit-tree and commit, but surely someone would eventually find a case where that abstraction level is still not right. To bring this around to the original topic of this thread, such an extra level of abstraction is equivalent to the suggested --plumbing (or whatever) option, whether it's presented as an option or a separate command. Have fun, Avery -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html