git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Andreas Lutro <anlutro@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: Fatal bug on revert with --author
Date: Mon, 30 May 2016 14:55:29 -0400	[thread overview]
Message-ID: <20160530185529.GA18074@sigill.intra.peff.net> (raw)
In-Reply-To: <CAKYJjwgkH5gtQHsV_=4O0SGqb6GEXWC=rdFWO9Jv36dL-NaPcw@mail.gmail.com>

On Mon, May 30, 2016 at 04:16:50PM +0200, Andreas Lutro wrote:

> So I learned today that --author is not a supported argument to git
> revert. It took me a long time to realize this, though, because the
> error I got was very cryptic:
> 
>   fatal: BUG: expected exactly one commit from walk
> 
> Here's a very simple reproducible case:
> https://gist.github.com/anlutro/67e0cec1a6a419e6d44131b0bc1deff6
> 
> I was recommended to send this report here by #git on irc.freenode.net.

Hmm. It _is_ a supported command-line argument, as you can pass
arbitrary revision options to revert. So:

  git revert --author peff HEAD

should revert all of my commits (whether that is _useful_, I am not
sure, but it is a consequence of the fact that revert simply passes its
arguments to the regular revision machinery).

But in your example, you pass the author "test", which matches nothing.
And so we end up with nothing to revert. But rather than saying so, we
fall into a backwards-compatibility code path:

        /*
         * If we were called as "git cherry-pick <commit>", just
         * cherry-pick/revert it, set CHERRY_PICK_HEAD /
         * REVERT_HEAD, and don't touch the sequencer state.
         * This means it is possible to cherry-pick in the middle
         * of a cherry-pick sequence.
         */
        if (opts->revs->cmdline.nr == 1 &&
            opts->revs->cmdline.rev->whence == REV_CMD_REV &&
            opts->revs->no_walk &&
            !opts->revs->cmdline.rev->flags) {
                struct commit *cmit;
                if (prepare_revision_walk(opts->revs))
                        die(_("revision walk setup failed"));
                cmit = get_revision(opts->revs);
                if (!cmit || get_revision(opts->revs))
                        die("BUG: expected exactly one commit from walk");
                return single_pick(cmit, opts);
        }

I think this conditional should not be triggering, because even though
we did receive a single argument, we _also_ got options which imply that
the user expected us to walk and find other commits.

-Peff

      reply	other threads:[~2016-05-30 18:55 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-30 14:16 Fatal bug on revert with --author Andreas Lutro
2016-05-30 18:55 ` Jeff King [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160530185529.GA18074@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=anlutro@gmail.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).