Re: Some advanced index playing

From: Junio C Hamano <junkio@cox.net>
Date: Dec 3, 2006, 19:36 UTC
Message-ID: <7vy7powz3k.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.64.0612031008360.3476@woody.osdl.org>

Linus Torvalds <torvalds@osdl.org> writes:

Show 14 quoted lines

> 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.
> ...
> Or at _least_ there should be a flag to force it.
>
> Junio?

I agree that if this sequence:

	$ edit foo
        $ git update-index foo
        $ edit foo
        $ git commit foo
        
is what the user actually gives from the command line, after
this commit is made, the user would want to _lose_ the state of
foo at the update-index after this commit is made, 100% of the
time (not "most likely", nor "usually", but "always").  So I am
very in favor of removing that check.

I am a bit worried if the reason behind this safety valve might have been something else, and we describe the reason as "we would lose data with this sequence otherwise" only to illustrate what's happening behind the scene in technical terms.

In other words, while I think no user would ever want to keep the state of foo at update-index after the above exact sequence as the end-user action, I am worried if a usage sequence that involve a group of operations encapsulated in a larger command (a synthetic command that touches index and working files without making the user painfully aware of the index -- likes of git-mv, git-rm, ...) might have been the true motivation of the safety valve.

I need to be reminded by somebody who went back to the list discussion around the time we introduced --only, and made sure that the "you would lose the snapshot you staged in the index if we allowed it" literally meant only that and nothing else; not some other common sequence that had the above command sequence inside, and keeping the state of 'foo' at update-index time made sense for that usage pattern, although I do not think of anything offhand...