revert top most commit

revert top most commit

[Keller, Jacob E]

Hi,

I am having trouble using revert. If I attempt to

$ git revert <sha1id>

where sha1id is the same as the HEAD commit, I instead get the output of
what looks like git status.

Is there anything specific about git revert that prevents it from
reverting the most recent commit?

Thanks,
Jake

Re: revert top most commit

[David Turner]

On Wed, 2014-08-27 at 21:14 +0000, Keller, Jacob E wrote:
> Hi,
> 
> I am having trouble using revert. If I attempt to
> 
> $ git revert <sha1id>
> 
> where sha1id is the same as the HEAD commit, I instead get the output of
> what looks like git status.
> 
> Is there anything specific about git revert that prevents it from
> reverting the most recent commit?

Works for me.  What version of git?  Is there a public repo that someone
could test this out on?

Re: revert top most commit

[Keller, Jacob E]

On Wed, 2014-08-27 at 18:15 -0400, David Turner wrote:
> On Wed, 2014-08-27 at 21:14 +0000, Keller, Jacob E wrote:
> > Hi,
> > 
> > I am having trouble using revert. If I attempt to
> > 
> > $ git revert <sha1id>
> > 
> > where sha1id is the same as the HEAD commit, I instead get the output of
> > what looks like git status.
> > 
> > Is there anything specific about git revert that prevents it from
> > reverting the most recent commit?
> 
> Works for me.  What version of git?  Is there a public repo that someone
> could test this out on?
> 

It was version 1.9.3 and it's not a public repo.

It's actually not my repository, I was helping a co-worker, and thought
I'd ask if anyone here knew if it was expected behavior or not.

Thanks,
Jake

Re: revert top most commit

[Jonathan Nieder]

Keller, Jacob E wrote:
>> On Wed, 2014-08-27 at 21:14 +0000, Keller, Jacob E wrote:

>>> I am having trouble using revert. If I attempt to
>>>
>>> $ git revert <sha1id>
>>>
>>> where sha1id is the same as the HEAD commit, I instead get the output of
>>> what looks like git status.
[...]
> It's actually not my repository, I was helping a co-worker, and thought
> I'd ask if anyone here knew if it was expected behavior or not.

More details about the output would help --- otherwise people have to
guess[*].  I'm guessing your co-worker's working tree is not clean.
Commiting or stashing their changes first might get things working.

Hope that helps,
Jonathan

[*] Another nice thing about quoting output is that it becomes more
obvious what about it wasn't helpful, which sometimes leads to patches
from kind people on the list to fix it.

Re: revert top most commit

[Keller, Jacob E]

On Wed, 2014-08-27 at 17:22 -0700, Jonathan Nieder wrote:
> Keller, Jacob E wrote:
> >> On Wed, 2014-08-27 at 21:14 +0000, Keller, Jacob E wrote:
> 
> >>> I am having trouble using revert. If I attempt to
> >>>
> >>> $ git revert <sha1id>
> >>>
> >>> where sha1id is the same as the HEAD commit, I instead get the output of
> >>> what looks like git status.
> [...]
> > It's actually not my repository, I was helping a co-worker, and thought
> > I'd ask if anyone here knew if it was expected behavior or not.
> 
> More details about the output would help --- otherwise people have to
> guess[*].  I'm guessing your co-worker's working tree is not clean.
> Commiting or stashing their changes first might get things working.
> 
> Hope that helps,
> Jonathan
> 
> [*] Another nice thing about quoting output is that it becomes more
> obvious what about it wasn't helpful, which sometimes leads to patches
> from kind people on the list to fix it.
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

I will see if I can get the actual output.

Thanks,
Jake

Re: revert top most commit

[Keller, Jacob E]

On Wed, 2014-08-27 at 17:22 -0700, Jonathan Nieder wrote:
> Keller, Jacob E wrote:
> >> On Wed, 2014-08-27 at 21:14 +0000, Keller, Jacob E wrote:
> 
> >>> I am having trouble using revert. If I attempt to
> >>>
> >>> $ git revert <sha1id>
> >>>
> >>> where sha1id is the same as the HEAD commit, I instead get the output of
> >>> what looks like git status.
> [...]
> > It's actually not my repository, I was helping a co-worker, and thought
> > I'd ask if anyone here knew if it was expected behavior or not.
> 
> More details about the output would help --- otherwise people have to
> guess[*].  I'm guessing your co-worker's working tree is not clean.
> Commiting or stashing their changes first might get things working.
> 
> Hope that helps,
> Jonathan
> 
> [*] Another nice thing about quoting output is that it becomes more
> obvious what about it wasn't helpful, which sometimes leads to patches
> from kind people on the list to fix it.
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

# Command, where  
$git revert b718c4d508204b7f46b147c7c47c51fe7a2c7e31On

# Output
branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean

I also just got one key piece of information regarding this, the patch
itself was blank!

For backstory, the issue is that he pushed to a tree which does not
allow non-fastforward updates (so he can't rewind). He was using stacked
git, and accidentally pushed an empty patch, and wanted to revert it so
that at least the log showed that we had removed it (even though the
patch itself was empty).

At minimum, this output from git revert could be made more clear about
why it's failing on an empty patch.

Regards,
Jake