threads / discuss / 27041

git rebase --continue automatic --skip?

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

## tl;dr

7 messages between Apr 8, 2011 and Apr 13, 2011.

replies: 6people: 5as markdown or json

skillzero@gmail.com· Apr 8, 2011, 20:30 UTC · lore

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.

It's a not a big deal, but it happens a lot to me because I do work on a branch that really should have gone on master, but I don't want to disrupt my branch work (i.e. I'm lazy) so I do it directly on the branch then later clean up those commits by isolating the parts that are truly part of the topic vs parts that are unrelated. So I hit a conflict, but want to take the version from master (so the commit disappears from the branch).

Jeff King· Apr 9, 2011, 00:03 UTC · re: skillzero@gmail.com · lore

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

On Fri, Apr 08, 2011 at 01:30:01PM -0700, skillzero@gmail.com wrote:

Show 6 quoted lines

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

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.

Peter Baumann· Apr 9, 2011, 13:03 UTC · re: Jeff King · lore

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

On Fri, Apr 08, 2011 at 08:03:51PM -0400, Jeff King wrote:

Show 38 quoted lines

> 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

Show 7 quoted lines

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

Junio C Hamano· Apr 10, 2011, 01:33 UTC · re: Peter Baumann · lore

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

Peter Baumann <waste.manager@gmx.de> writes:

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

I don't recall ever seeing that justification; and I don't agree with it either. As far as the resulting history is concerned, that commit does not even exist and there is no precious information.

This is a tangent, but I suspect that in the very old days, after a "git rebase" stopped due to a conflict to have you adjust the change by resolving conflicts, "git rebase --continue" may have offered you an opportunity to edit the commit log message so that you can record what was made unnecessary (or made additionally necessary) compared to the original patch due to rebasing. I don't offhand know when we lost that feature (it is possible we never had anything like that and I am misremembering things).

We may probably want to add it at least as an optional feature. After "git rebase" stops due to a conflict, and your resolution ends up to be not an empty change, "git rebase --continue" seems to simply reuse the original description these days. It might be a good default, but in cases where the conflict resolution made the change very different from the original, the old log message may not describe why the change was needed and how the change solved that issue properly in the context of the new history.

"git commit -a -c .git/rebase-apply/original-commit" followed by "git rebase --skip" is a workaround that is too ugly to be called "workable" for it. Perhaps "git rebase --edit --continue" or something?

Peter Baumann· Apr 11, 2011, 06:10 UTC · re: Peter Baumann · lore

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

On Sat, Apr 09, 2011 at 03:03:09PM +0200, Peter Baumann wrote:

Show 9 quoted lines

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

[ ... patch left out ... ]

Show 13 quoted lines

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

I actually managed to find the thread I was remembering:

http://thread.gmane.org/gmane.comp.version-control.git/62854/focus=62907

-Peter

Junio C Hamano· Apr 10, 2011, 01:24 UTC · re: Jeff King · lore

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

Jeff King <peff@peff.net> writes:

Show 5 quoted lines

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

I think the "rebase --continue" behaviour was more or less deliberate (I do not necessarily agree with the reasoning, though). It is to ensure that the user has a chance to examine the situation and acknowledge that it is fine to completely drop the now obsoleted change, as having to adjust the change to an updated base, even with conflict resolution, may be common, it is a rare and notable event that the resolution ends up being empty.

Joshua Juran· Apr 13, 2011, 19:02 UTC · re: Junio C Hamano · lore

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

On Apr 9, 2011, at 6:24 PM, Junio C Hamano wrote:

Show 21 quoted lines

> Jeff King <peff@peff.net> writes:
>
>> 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.
>
> I think the "rebase --continue" behaviour was more or less  
> deliberate (I
> do not necessarily agree with the reasoning, though).  It is to ensure
> that the user has a chance to examine the situation and acknowledge  
> that
> it is fine to completely drop the now obsoleted change, as having to
> adjust the change to an updated base, even with conflict resolution,  
> may
> be common, it is a rare and notable event that the resolution ends up
> being empty.

Rather than changing --continue, the proposed behavior could be added as `git rebase --next`.

Josh