Re: Some advanced index playing

From: Linus Torvalds <torvalds@osdl.org>
Date: Dec 3, 2006, 18:24 UTC
Message-ID: <Pine.LNX.4.64.0612031008360.3476@woody.osdl.org>
In-Reply-To: <200612031701.15594.alan@chandlerfamily.org.uk>

On Sun, 3 Dec 2006, Alan Chandler wrote:

Show 16 quoted lines

>
> With all the discussion about the index file in the last few days I would have 
> thought that this issue would have come up.  But I don't think it has.
> 
> I have been editing a set of files to make a commit, and after editing each 
> one had done a git update-index.
> 
> At this point I am just about to commit when I realise that one of the files 
> has changes in it that really ought to be a separate commit. 
> 
> So effectively, I want to do one of three things
> 
> a) git-commit <that-file>
> 
> Except I can't because there is a safety valve that prevents this and there is 
> no force option.

I think that is actually a misfeature.

This _should_ just work. It's the easy and logical way to do it, and it's the one that matches all the other behaviours of "git commit" these days.

The reason for the safety valve is actually not really "safety" any more, it's purely "historical behaviour". Ie the sanity check is not there because you would be doing anything unsafe, but simply because the behaviour in this area _changed_, so the semantics are different from what they were originally.

But those "original" semantics are now so old and so uninteresting that the safety feature has gone from being a safety feature to just being annoying, and hindering you from doing what you want to do.

Side note: you -can- do what you want to do, but it's insanely stupid. Here's what you'd do:

	git ls-tree HEAD -- that-file | git update-index --index-info
	git commit that-file

but there is no way in hell I will claim that this is a _good_ thing.

[ That said, the whole

	git ls-tree <treeish> -- <file-list> | git update-index --index-info

  is a useful pattern to know. You can basically insert _any_ part of old 
  historical state into the index with this, which can be useful if you 
  want to play games without changing the _other_ parts of the index. ]

So anyway, I would suggest that we just get rid of that partial commit "safety check" in "git commit" for now. It still makes sense for when you're in the middle of a _merge_, but the "verify that index matches" is not worth it.

Or at _least_ there should be a flag to force it.

Junio?