tisdag 06 november 2007 skrev Johannes Schindelin: > Hi, > > On Mon, 5 Nov 2007, Junio C Hamano wrote: > > > Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > > > > > On Mon, 5 Nov 2007, Junio C Hamano wrote: > > > > > >> Allowing people to revert or cherry pick partially by using paths > > >> limiter is a very good idea; the whole "it comes from a commit so we > > >> also commit" feels an utter nonsense, though. > > > > > > No. > > > > > > When "git revert <commit>" commits the result, "git revert <commit> -- > > > <file>" should, too. > > > > I was not questioning about that part. "If 'git revert <some > > other form> foo' does not talk about commit, it should not > > commit" was what I was referring to. > > Well, I think that _if_ we allow "git revert <path>" to mean "revert the > changes to <path>, relative to the index" (which would be the same as "git > checkout <path>"), then committing that change just does not make sense. > > And it is this behaviour that people are seeking, not "git revert <commit> > <path>". I'm not convince making every command perform enitrely all kinds of actions just because other SCMs interpret a name differently. git revert today creates a *new* commit. Keep it simple. I think its ok that it mentions another comnand when it detects arguments that does not make sense. There is no right or wrong with interepreting reset either way, but not both ways please. The confusion with checkout and reset is enough. -- robin - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
