Re: "git revert" feature suggestion: revert the last commit to a file
- From
- Randy Dunlap <rdunlap@xenotime.net>
- Date
- Feb 5, 2009, 20:54 UTC
- Message-ID
- <498B51E8.8030801@xenotime.net>
- In-Reply-To
- <7vvdrobobc.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
Show 39 quoted lines
> 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.
IMO.
~Randy