I frequently come across this workflow pattern: i queue up some new change 
in a topic brach, and there's a test failure within the next 60 minutes or 
so. I know which file causes the breakage - say kernel/softlockup.c - but i 
dont know the precise commit ID. I want to revert the change in the 
integration branch as quickly as possible via a command - without having to 
wade through 'git log' info and cut&paste-ing commit IDs.

I usually know the topic branch name where the breakage originates from, so 
i can do this in the integration branch:

   git revert core/softlockup

and it does the right thing and the tests can continue while i take more 
time in the topic branch to repair the damage there. (at which point i can 
integrate the fixed/updated commit on top of the reverted commit in the 
integration branch.)

But often i have other changes queued up in that topic branch as well - and 
the best, most finegrained information i have about the identity of the 
commit is the filename it went into.

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

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?

Thanks,

	Ingo
--

[ message continues ]

Hi,


For some people I know, this would intuitively mean that the uncommitted 
changes in kernel/softlockup.c should be reverted.

So I am not convinced that this is an intuitive syntax at all.

Instead, I think that something like

	git revert :/!file=kernel/softlockup.c

would be possible, as it

- does not overload an already overloaded term, and

- is useful for something else than revert, too.

Ciao,
Dscho
--

[ message continues ]

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)


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".
--

[ message continues ]

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

--

[ message continues ]

i'm not sure i understand, what do you mean precisely?

	Ingo
--

[ message continues ]

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?

~Randy

--

[ message continues ]

ah, i understand. No, the second time it should revert the revert.

Last commit means last commit - and a revert is just a normal commit. (it 
just happens to be generated as an inverse of an existing commit - but that 
relationship is not actually relied on and a revert can be edited, amended, 
etc.)

	Ingo
--

[ message continues ]

All in the current scope of the integration branch, sure. I.e. the same 
scope of commits that "git log kernel/softlockup.c" uses.

	Ingo
--

[ message continues ]

But that is not how ":/syntax" works, at least right now.  It traverses
from tips of all refs and finds the newest one.  It might make sense to
make the discovery start from the current branch not from all tips.
--

[ message continues ]

Hi,


Yeah, it was a bad design, probably.

As it is, the syntax is not really useful to me, as my patch to make this 
a regular expression was not accepted.

Maybe it is time to rethink that syntax; I am pretty sure that there is no 
user out there.

Ciao,
Dscho

--

[ message continues ]