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 majord...@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
