From: Randy Dunlap Date: Thu, 05 Feb 2009 21:03:20 GMT Subject: Re: "git revert" feature suggestion: revert the last commit to a file Message-ID: <498B5418.4050103@xenotime.net> In-Reply-To: <20090205210055.GC21500@elte.hu> Ingo Molnar wrote: > * Randy Dunlap wrote: > >> Junio C Hamano wrote: >>> Ingo Molnar 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 " on the same file more than one time and git will revert then then etc... Or it will always revert , where is relative to the currently used version of the file. Does that help? ~Randy