On Tue, Nov 06, 2007 at 09:06:56PM +0100, Robin Rosenberg wrote:
> 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.
Maybe the documentation could emphasise on how to undo things when the
user makes mistakes.
Sometimes, saving your repo can be as simple as git reset --hard HEAD@{1}.
This is not, unfortunately, a works-for-all-cases command.
Mike
-
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
