Re: [PATCH 3/3] git checkout --nodwim

[Avery Pennarun <apenwarr@gmail.com>]

On Mon, Oct 26, 2009 at 6:14 PM, Jeff King <peff@peff.net> 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