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
List information: http://vger.kernel.org/majordomo-info.html
* 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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).