From: Daniel Barkalow Date: Wed, 01 Feb 2006 02:19:50 GMT Subject: Re: [Census] So who uses git? Message-ID: In-Reply-To: On Tue, 31 Jan 2006, Linus Torvalds wrote: > So if you do this change (which may be the right one) then please make > sure that "git commit " doesn't work _at_all_ when a merge is in > progress (ie MERGE_HEAD exists), because it would do the wrong thing. Agreed. I suppose it could accept doing a commit of only a few files which weren't touched by the merge, but I don't think even you multitask enough to want to do that; anyway, the user can just ditch the merge, commit their stuff, and try the merge again. (I bet this is a case where new users would be really surprised by the behavior of "git commit filename", except that they wouldn't think it would do anything other than give an error.) > And yes, then I'll just have to force my fingers to do a simple > > git-update-index filename > git commit > > instead. I can do that. > > Oh, one final suggestion: if you give a filename to "git commit", and you > do the new semantics which means something _different_ than "do a > git-update-index on that file and commit", then I'd really suggest that > the _old_ index for that filename should match the parent exactly. > Otherwise, you may have done a > > git diff filename > > and you _thought_ you were committing just a two-line thing (because you > didn't understand about the index), but another, earlier, action caused > the index to be different from the file you had in HEAD, and in reality > you're actually committing a much bigger diff. > > In other words: if you want "git commit " to _not_ care about > the current index, then it should make sure that the index at least > _matches_ the current HEAD in the files mentioned. > > Ie "git-diff-index --cached HEAD " should return empty. Or > something like that. Agreed here, too. -Daniel *This .sig left intentionally blank*