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

From: Avery Pennarun <apenwarr@gmail.com>
Date: Oct 26, 2009, 22:28 UTC
Message-ID: <32541b130910261528s12cbe3c0gda163be6a906bdf6@mail.gmail.com>
In-Reply-To: <20091026221424.GA28184@sigio.peff.net>

On Mon, Oct 26, 2009 at 6:14 PM, Jeff King <peff@peff.net> wrote:

Show 11 quoted lines

> 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!

Show 17 quoted lines

>> > 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