Re: "git revert" feature suggestion: revert the last commit to a file

> Ingo Molnar wrote:
> > * Randy Dunlap <rdunlap@xenotime.net> wrote:
> > 
> >> Junio C Hamano wrote:
> >>> Ingo Molnar <mingo@elte.hu> writes:
> >>>
> >>>> So i have to do something like:
> >>>>
> >>>>    git revert $(git log -1 --pretty=format:"%h" kernel/softlockup.c)
> >>>>
> >>>> (tucked away in a tip-revert-file helper script.)
> >>>>
> >>>> But it would be so much nicer if i could do the intuitive:
> >>>>
> >>>>    git revert kernel/softlockup.c
> >>>>
> >>>> Or at least, to separate it from revision names cleanly, something like:
> >>>>
> >>>>    git revert -- kernel/softlockup.c
> >>> All three shares one issue.  Does the syntax offer you a way to give
> >>> enough information so that you can confidently say that it will find the
> >>> commit that touched the path most recently?  How is the "most recently"
> >>> defined?
> >>>
> >>> At least you can restate the first one to:
> >>>
> >>>     git revert $(git log -1 --pretty=format:"%h" core/softlockup -- kernel/softlockup.c)
> >>>
> >>> to limit to "the one that touched this file _on this topic_".
> >>>
> >>>> Would something like this be possible in generic Git? It would sure be a 
> >>>> nice little touch that i would make use of frequently.
> >>>>
> >>>> Or is it a bad idea perhaps? Or have i, out of sheer ignorance, failed to 
> >>>> discover some nice little shortcut that can give me all of this already?
> >>> The closest I can think of is
> >>>
> >>> 	git revert ':/the title of the commit'
> >>>
> >>> but it shares the exact same issue of "how would I limit the search space
> >>> to make sure it finds the right commit".
> >> And it should revert whatever commit is the last/most recent to the 
> >> currently used file, i.e., not always revert the same commit.
> > 
> > i'm not sure i understand, what do you mean precisely?
> 
> Just that someone should be able to use "git revert <filename>" on the
> same file more than one time and git will revert <last> then <last-1> then
> <last-2> etc...
> 
> Or it will always revert <last>, where <last> is relative to the currently
> used version of the file.
> 
> Does that help?