From: Peter Baumann <waste.manager@gmx.de>
To: Jeff King <peff@peff.net>
Cc: skillzero@gmail.com,
Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>,
Git Mailing List <git@vger.kernel.org>
Subject: Re: git rebase --continue automatic --skip?
Date: Sat, 9 Apr 2011 15:03:09 +0200 [thread overview]
Message-ID: <20110409130309.GC30820@m62s10.vlinux.de> (raw)
In-Reply-To: <20110409000351.GA7445@sigill.intra.peff.net>
On Fri, Apr 08, 2011 at 08:03:51PM -0400, Jeff King wrote:
> On Fri, Apr 08, 2011 at 01:30:01PM -0700, skillzero@gmail.com wrote:
>
> > Is there a way to make git rebase --continue automatically do a --skip
> > if a conflict resolution ends up not needing the patch? Normally, git
> > rebase will just silently skip a patch if it's not needed, but if a
> > patch results in a conflict and I use git mergetool and end up
> > deleting all the changes, git rebase --continue stops and makes me
> > explicitly use --skip.
>
> This is something I have often wanted, too. The patch would look
> something like this:
>
> diff --git a/git-rebase.sh b/git-rebase.sh
> index 7a54bfc..cec15ae 100755
> --- a/git-rebase.sh
> +++ b/git-rebase.sh
> @@ -319,6 +319,11 @@ continue)
> echo "mark them as resolved using git add"
> exit 1
> }
> + if git diff-index --quiet HEAD --; then
> + test -z "$GIT_QUIET" &&
> + echo >&2 "Commit has no changes -- skipping"
> + action=skip
> + fi
> read_basic_state
> run_specific_rebase
> ;;
>
> that is based on what is in "next", as there has been a lot of cleanup
> in git-rebase recently[1].
>
> I put it in rebase and not straight into "git am", as I'm not sure that
> "am" would want to share the same behavior. I'm not sure why we haven't
> done this up until now. Maybe there is some corner case I'm not thinking
> of where the user would want to do something besides skip when we hit
> this situation. I dunno.
>
This was mentioned before on the list (sorry, don't have a reference,
but it was a long time ago). AFAIR the reason it wasn't implemented yet is that
you will lose the commit message, which might contain precious information.
But with reflogs this shouldn't be a problem anymore.
-Peter
> Potentially this should also go into the rebase--am specific script. I
> haven't really thought it through.
>
> -Peff
>
> [1] I hadn't really been following Martin's rebase cleanup, but it is
> _way_ nicer to look at these days.
next prev parent reply other threads:[~2011-04-09 13:03 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-08 20:30 git rebase --continue automatic --skip? skillzero
2011-04-09 0:03 ` Jeff King
2011-04-09 13:03 ` Peter Baumann [this message]
2011-04-10 1:33 ` Junio C Hamano
2011-04-11 6:10 ` Peter Baumann
2011-04-10 1:24 ` Junio C Hamano
2011-04-13 19:02 ` Joshua Juran
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=20110409130309.GC30820@m62s10.vlinux.de \
--to=waste.manager@gmx.de \
--cc=git@vger.kernel.org \
--cc=martin.von.zweigbergk@gmail.com \
--cc=peff@peff.net \
--cc=skillzero@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.