Subject: Re: git rebase --continue automatic --skip?

From: Peter Baumann <[email-masked]>
Date: Sat, 9 Apr 2011 15:03:09 +0200

On Fri, Apr 08, 2011 at 08:03:51PM -0400, Jeff King wrote:
> On Fri, Apr 08, 2011 at 01:30:01PM -0700, [email-masked] 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.