{"thread":{"id":"27041","subject":"git rebase --continue automatic --skip?","startedAt":"2011-04-08T20:30:01Z","lastAt":"2011-04-13T19:02:51Z","messageCount":7,"participants":["skillzero@gmail.com","Jeff King","Peter Baumann","Junio C Hamano","Joshua Juran"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"165454","messageId":"BANLkTi=Vc6kB5fvZrqMwDD+yHFb5qENQ8g@mail.gmail.com","threadId":"27041","inReplyTo":null,"subject":"git rebase --continue automatic --skip?","fromName":"","fromEmail":"skillzero@gmail.com","sentAt":"2011-04-08T20:30:01Z","receivedAt":"2011-04-08T20:30:01Z","isPatch":false,"sender":{"key":"skillzero@gmail.com","avatar":null},"body":"Is there a way to make git rebase --continue automatically do a --skip\nif a conflict resolution ends up not needing the patch? Normally, git\nrebase will just silently skip a patch if it's not needed, but if a\npatch results in a conflict and I use git mergetool and end up\ndeleting all the changes, git rebase --continue stops and makes me\nexplicitly use --skip.\n\nIt's a not a big deal, but it happens a lot to me because I do work on\na branch that really should have gone on master, but I don't want to\ndisrupt my branch work (i.e. I'm lazy) so I do it directly on the\nbranch then later clean up those commits by isolating the parts that\nare truly part of the topic vs parts that are unrelated. So I hit a\nconflict, but want to take the version from master (so the commit\ndisappears from the branch).\n"},{"id":"165470","messageId":"20110409000351.GA7445@sigill.intra.peff.net","threadId":"27041","inReplyTo":"BANLkTi=Vc6kB5fvZrqMwDD+yHFb5qENQ8g@mail.gmail.com","subject":"Re: git rebase --continue automatic --skip?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-04-09T00:03:51Z","receivedAt":"2011-04-09T00:03:51Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Apr 08, 2011 at 01:30:01PM -0700, skillzero@gmail.com wrote:\n\n> Is there a way to make git rebase --continue automatically do a --skip\n> if a conflict resolution ends up not needing the patch? Normally, git\n> rebase will just silently skip a patch if it's not needed, but if a\n> patch results in a conflict and I use git mergetool and end up\n> deleting all the changes, git rebase --continue stops and makes me\n> explicitly use --skip.\n\nThis is something I have often wanted, too. The patch would look\nsomething like this:\n\ndiff --git a/git-rebase.sh b/git-rebase.sh\nindex 7a54bfc..cec15ae 100755\n--- a/git-rebase.sh\n+++ b/git-rebase.sh\n@@ -319,6 +319,11 @@ continue)\n \t\techo \"mark them as resolved using git add\"\n \t\texit 1\n \t}\n+\tif git diff-index --quiet HEAD --; then\n+\t\ttest -z \"$GIT_QUIET\" &&\n+\t\t\techo >&2 \"Commit has no changes -- skipping\"\n+\t\taction=skip\n+\tfi\n \tread_basic_state\n \trun_specific_rebase\n \t;;\n\nthat is based on what is in \"next\", as there has been a lot of cleanup\nin git-rebase recently[1].\n\nI put it in rebase and not straight into \"git am\", as I'm not sure that\n\"am\" would want to share the same behavior. I'm not sure why we haven't\ndone this up until now. Maybe there is some corner case I'm not thinking\nof where the user would want to do something besides skip when we hit\nthis situation. I dunno.\n\nPotentially this should also go into the rebase--am specific script. I\nhaven't really thought it through.\n\n-Peff\n\n[1] I hadn't really been following Martin's rebase cleanup, but it is\n    _way_ nicer to look at these days.\n"},{"id":"165486","messageId":"20110409130309.GC30820@m62s10.vlinux.de","threadId":"27041","inReplyTo":"20110409000351.GA7445@sigill.intra.peff.net","subject":"Re: git rebase --continue automatic --skip?","fromName":"Peter Baumann","fromEmail":"waste.manager@gmx.de","sentAt":"2011-04-09T13:03:09Z","receivedAt":"2011-04-09T13:03:09Z","isPatch":false,"sender":{"key":"waste.manager@gmx.de","avatar":null},"body":"On Fri, Apr 08, 2011 at 08:03:51PM -0400, Jeff King wrote:\n> On Fri, Apr 08, 2011 at 01:30:01PM -0700, skillzero@gmail.com wrote:\n> \n> > Is there a way to make git rebase --continue automatically do a --skip\n> > if a conflict resolution ends up not needing the patch? Normally, git\n> > rebase will just silently skip a patch if it's not needed, but if a\n> > patch results in a conflict and I use git mergetool and end up\n> > deleting all the changes, git rebase --continue stops and makes me\n> > explicitly use --skip.\n> \n> This is something I have often wanted, too. The patch would look\n> something like this:\n> \n> diff --git a/git-rebase.sh b/git-rebase.sh\n> index 7a54bfc..cec15ae 100755\n> --- a/git-rebase.sh\n> +++ b/git-rebase.sh\n> @@ -319,6 +319,11 @@ continue)\n>  \t\techo \"mark them as resolved using git add\"\n>  \t\texit 1\n>  \t}\n> +\tif git diff-index --quiet HEAD --; then\n> +\t\ttest -z \"$GIT_QUIET\" &&\n> +\t\t\techo >&2 \"Commit has no changes -- skipping\"\n> +\t\taction=skip\n> +\tfi\n>  \tread_basic_state\n>  \trun_specific_rebase\n>  \t;;\n> \n> that is based on what is in \"next\", as there has been a lot of cleanup\n> in git-rebase recently[1].\n> \n> I put it in rebase and not straight into \"git am\", as I'm not sure that\n> \"am\" would want to share the same behavior. I'm not sure why we haven't\n> done this up until now. Maybe there is some corner case I'm not thinking\n> of where the user would want to do something besides skip when we hit\n> this situation. I dunno.\n> \n\nThis was mentioned before on the list (sorry, don't have a reference, \nbut it was a long time ago). AFAIR the reason it wasn't implemented yet is that\nyou will lose the commit message, which might contain precious information.\nBut with reflogs this shouldn't be a problem anymore.\n\n-Peter\n\n\n\n> Potentially this should also go into the rebase--am specific script. I\n> haven't really thought it through.\n> \n> -Peff\n> \n> [1] I hadn't really been following Martin's rebase cleanup, but it is\n>     _way_ nicer to look at these days.\n"},{"id":"165523","messageId":"7vy63iyk2r.fsf@alter.siamese.dyndns.org","threadId":"27041","inReplyTo":"20110409000351.GA7445@sigill.intra.peff.net","subject":"Re: git rebase --continue automatic --skip?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-04-10T01:24:44Z","receivedAt":"2011-04-10T01:24:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> I put it in rebase and not straight into \"git am\", as I'm not sure that\n> \"am\" would want to share the same behavior. I'm not sure why we haven't\n> done this up until now. Maybe there is some corner case I'm not thinking\n> of where the user would want to do something besides skip when we hit\n> this situation. I dunno.\n\nI think the \"rebase --continue\" behaviour was more or less deliberate (I\ndo not necessarily agree with the reasoning, though).  It is to ensure\nthat the user has a chance to examine the situation and acknowledge that\nit is fine to completely drop the now obsoleted change, as having to\nadjust the change to an updated base, even with conflict resolution, may\nbe common, it is a rare and notable event that the resolution ends up\nbeing empty.\n"},{"id":"165525","messageId":"7vr59ayjns.fsf@alter.siamese.dyndns.org","threadId":"27041","inReplyTo":"20110409130309.GC30820@m62s10.vlinux.de","subject":"Re: git rebase --continue automatic --skip?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-04-10T01:33:43Z","receivedAt":"2011-04-10T01:33:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Peter Baumann <waste.manager@gmx.de> writes:\n\n> This was mentioned before on the list (sorry, don't have a reference, \n> but it was a long time ago). AFAIR the reason it wasn't implemented yet is that\n> you will lose the commit message, which might contain precious information.\n\nI don't recall ever seeing that justification; and I don't agree with it\neither.  As far as the resulting history is concerned, that commit does\nnot even exist and there is no precious information.\n\nThis is a tangent, but I suspect that in the very old days, after a \"git\nrebase\" stopped due to a conflict to have you adjust the change by\nresolving conflicts, \"git rebase --continue\" may have offered you an\nopportunity to edit the commit log message so that you can record what was\nmade unnecessary (or made additionally necessary) compared to the original\npatch due to rebasing.  I don't offhand know when we lost that feature (it\nis possible we never had anything like that and I am misremembering\nthings).\n\nWe may probably want to add it at least as an optional feature.  After\n\"git rebase\" stops due to a conflict, and your resolution ends up to be\nnot an empty change, \"git rebase --continue\" seems to simply reuse the\noriginal description these days.  It might be a good default, but in cases\nwhere the conflict resolution made the change very different from the\noriginal, the old log message may not describe why the change was needed\nand how the change solved that issue properly in the context of the new\nhistory.\n\n\"git commit -a -c .git/rebase-apply/original-commit\" followed by \"git\nrebase --skip\" is a workaround that is too ugly to be called \"workable\"\nfor it.  Perhaps \"git rebase --edit --continue\" or something?\n"},{"id":"165599","messageId":"20110411061052.GD30820@m62s10.vlinux.de","threadId":"27041","inReplyTo":"20110409130309.GC30820@m62s10.vlinux.de","subject":"Re: git rebase --continue automatic --skip?","fromName":"Peter Baumann","fromEmail":"waste.manager@gmx.de","sentAt":"2011-04-11T06:10:52Z","receivedAt":"2011-04-11T06:10:52Z","isPatch":false,"sender":{"key":"waste.manager@gmx.de","avatar":null},"body":"On Sat, Apr 09, 2011 at 03:03:09PM +0200, Peter Baumann wrote:\n> On Fri, Apr 08, 2011 at 08:03:51PM -0400, Jeff King wrote:\n> > On Fri, Apr 08, 2011 at 01:30:01PM -0700, skillzero@gmail.com wrote:\n> > \n> > > Is there a way to make git rebase --continue automatically do a --skip\n> > > if a conflict resolution ends up not needing the patch? Normally, git\n> > > rebase will just silently skip a patch if it's not needed, but if a\n> > > patch results in a conflict and I use git mergetool and end up\n> > > deleting all the changes, git rebase --continue stops and makes me\n> > > explicitly use --skip.\n\n[ ... patch left out ... ]\n\n> > \n> > I put it in rebase and not straight into \"git am\", as I'm not sure that\n> > \"am\" would want to share the same behavior. I'm not sure why we haven't\n> > done this up until now. Maybe there is some corner case I'm not thinking\n> > of where the user would want to do something besides skip when we hit\n> > this situation. I dunno.\n> > \n> \n> This was mentioned before on the list (sorry, don't have a reference, \n> but it was a long time ago). AFAIR the reason it wasn't implemented yet is that\n> you will lose the commit message, which might contain precious information.\n> But with reflogs this shouldn't be a problem anymore.\n> \n\nI actually managed to find the thread I was remembering:\n\nhttp://thread.gmane.org/gmane.comp.version-control.git/62854/focus=62907\n\n-Peter\n"},{"id":"165766","messageId":"D9A445D1-C0B5-4CB4-A847-E44618A6DD90@gmail.com","threadId":"27041","inReplyTo":"7vy63iyk2r.fsf@alter.siamese.dyndns.org","subject":"Re: git rebase --continue automatic --skip?","fromName":"Joshua Juran","fromEmail":"jjuran@gmail.com","sentAt":"2011-04-13T19:02:51Z","receivedAt":"2011-04-13T19:02:51Z","isPatch":false,"sender":{"key":"jjuran@gmail.com","avatar":null},"body":"On Apr 9, 2011, at 6:24 PM, Junio C Hamano wrote:\n\n> Jeff King <peff@peff.net> writes:\n>\n>> I put it in rebase and not straight into \"git am\", as I'm not sure  \n>> that\n>> \"am\" would want to share the same behavior. I'm not sure why we  \n>> haven't\n>> done this up until now. Maybe there is some corner case I'm not  \n>> thinking\n>> of where the user would want to do something besides skip when we hit\n>> this situation. I dunno.\n>\n> I think the \"rebase --continue\" behaviour was more or less  \n> deliberate (I\n> do not necessarily agree with the reasoning, though).  It is to ensure\n> that the user has a chance to examine the situation and acknowledge  \n> that\n> it is fine to completely drop the now obsoleted change, as having to\n> adjust the change to an updated base, even with conflict resolution,  \n> may\n> be common, it is a rare and notable event that the resolution ends up\n> being empty.\n\nRather than changing --continue, the proposed behavior could be added  \nas `git rebase --next`.\n\nJosh\n"}]}