* git rebase --continue automatic --skip? @ 2011-04-08 20:30 skillzero 2011-04-09 0:03 ` Jeff King 0 siblings, 1 reply; 7+ messages in thread From: skillzero @ 2011-04-08 20:30 UTC (permalink / raw) To: Git Mailing List 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). ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: git rebase --continue automatic --skip? 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 2011-04-10 1:24 ` Junio C Hamano 0 siblings, 2 replies; 7+ messages in thread From: Jeff King @ 2011-04-09 0:03 UTC (permalink / raw) To: skillzero; +Cc: Martin von Zweigbergk, Git Mailing List 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. 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. ^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: git rebase --continue automatic --skip? 2011-04-09 0:03 ` Jeff King @ 2011-04-09 13:03 ` Peter Baumann 2011-04-10 1:33 ` Junio C Hamano 2011-04-11 6:10 ` Peter Baumann 2011-04-10 1:24 ` Junio C Hamano 1 sibling, 2 replies; 7+ messages in thread From: Peter Baumann @ 2011-04-09 13:03 UTC (permalink / raw) To: Jeff King; +Cc: skillzero, Martin von Zweigbergk, Git Mailing List 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: git rebase --continue automatic --skip? 2011-04-09 13:03 ` Peter Baumann @ 2011-04-10 1:33 ` Junio C Hamano 2011-04-11 6:10 ` Peter Baumann 1 sibling, 0 replies; 7+ messages in thread From: Junio C Hamano @ 2011-04-10 1:33 UTC (permalink / raw) To: Peter Baumann Cc: Jeff King, skillzero, Martin von Zweigbergk, Git Mailing List 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? ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: git rebase --continue automatic --skip? 2011-04-09 13:03 ` Peter Baumann 2011-04-10 1:33 ` Junio C Hamano @ 2011-04-11 6:10 ` Peter Baumann 1 sibling, 0 replies; 7+ messages in thread From: Peter Baumann @ 2011-04-11 6:10 UTC (permalink / raw) To: Jeff King Cc: skillzero, Martin von Zweigbergk, Junio C Hamano, Git Mailing List On Sat, Apr 09, 2011 at 03:03:09PM +0200, Peter Baumann wrote: > 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 ... ] > > > > 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: git rebase --continue automatic --skip? 2011-04-09 0:03 ` Jeff King 2011-04-09 13:03 ` Peter Baumann @ 2011-04-10 1:24 ` Junio C Hamano 2011-04-13 19:02 ` Joshua Juran 1 sibling, 1 reply; 7+ messages in thread From: Junio C Hamano @ 2011-04-10 1:24 UTC (permalink / raw) To: Jeff King; +Cc: skillzero, Martin von Zweigbergk, Git Mailing List 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: git rebase --continue automatic --skip? 2011-04-10 1:24 ` Junio C Hamano @ 2011-04-13 19:02 ` Joshua Juran 0 siblings, 0 replies; 7+ messages in thread From: Joshua Juran @ 2011-04-13 19:02 UTC (permalink / raw) To: Junio C Hamano Cc: Jeff King, skillzero, Martin von Zweigbergk, Git Mailing List On Apr 9, 2011, at 6:24 PM, Junio C Hamano wrote: > 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2011-04-13 19:03 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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 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
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).