{"thread":{"id":"10543","subject":"Newbie: report of first experience with git-rebase.","startedAt":"2007-10-31T19:39:06Z","lastAt":"2007-11-02T19:22:18Z","messageCount":20,"participants":["Sergei Organov","Björn Steinbrink","Johannes Schindelin","Alex Riesen","J. Bruce Fields","Junio C Hamano","Steven Grimm","Daniel Barkalow","David Kastrup","Nicolas Pitre","Andreas Ericsson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"57718","messageId":"87d4uv3wh1.fsf@osv.gnss.ru","threadId":"10543","inReplyTo":null,"subject":"Newbie: report of first experience with git-rebase.","fromName":"Sergei Organov","fromEmail":"osv@javad.com","sentAt":"2007-10-31T19:39:06Z","receivedAt":"2007-10-31T19:39:06Z","isPatch":false,"sender":{"key":"osv@javad.com","avatar":null},"body":"Hello,\n\nI've made my first attempt at tracking my changes to upstream git\nrepository using git-fetch/git-rebase workflow. I did three commits to\nmy master branch, and then upstream incorporated two of them in slightly\nmodified form, so that some conflicts are to be expected. I did\ngit-fetch followed by git-rebase, and finally have got the end result I\nhoped for, but there were some confusion along the way. I think I'd post\nthe log of the session here along with my thoughts so that an interested\nperson could see how it works for a newbie (my thoughts and non-git\nactions at the time of rebasing are marked with 'me>' prefix):\n\n$ git fetch\n[...]\n$ git rebase origin\nFirst, rewinding head to replay your work on top of it...\nHEAD is now at 9c51414... Merge branch 'maint' into HEAD\n\nApplying Fix a typo.\n\nWrote tree f5b2feefc021486eae9d2d84c69e0d6ead027a9d\nCommitted: 983e907b1360c17c7ac925d6035d82cc7243f406\n\nApplying Use new syntax (-m option) for git-merge.\n\nerror: patch failed: Documentation/core-tutorial.txt:878\nerror: Documentation/core-tutorial.txt: patch does not apply\nUsing index info to reconstruct a base tree...\nFalling back to patching base and 3-way merge...\nAuto-merged Documentation/core-tutorial.txt\nCONFLICT (content): Merge conflict in Documentation/core-tutorial.txt\nFailed to merge in the changes.\nPatch failed at 0002.\n\nWhen you have resolved this problem run \"git rebase --continue\".\nIf you would prefer to skip this patch, instead run \"git rebase --skip\".\nTo restore the original branch and stop rebasing run \"git rebase --abort\".\n\nme> Nice, this conflict is expected.\nme> Editing Documentation/core-tutorial.txt to resolve the\nme> conflict... Conflict is resolved so that the working file matches\nme> upstream version.\n\n$ git rebase --continue\nYou must edit all merge conflicts and then\nmark them as resolved using git add\n\nme> Nice helpful message, -- need to do git-add\n\n$ git add Documentation/core-tutorial.txt\n$ git rebase --continue\n\nApplying Use new syntax (-m option) for git-merge.\n\nNo changes - did you forget to use 'git add'?\n\nWhen you have resolved this problem run \"git rebase --continue\".\nIf you would prefer to skip this patch, instead run \"git rebase --skip\".\nTo restore the original branch and stop rebasing run \"git rebase --abort\".\n\nme> What?! I just did the git-add! Moreover, before I did git-add, the\nme> error was different and helpful. Something went wrong? \nme> Well, it's unlikely, but maybe I made a mistake of not specifying\nme> the 'origin'?\n\n$ git rebase --continue origin\n\nApplying Use new syntax (-m option) for git-merge.\n\nNo changes - did you forget to use 'git add'?\n\nWhen you have resolved this problem run \"git rebase --continue\".\nIf you would prefer to skip this patch, instead run \"git rebase --skip\".\nTo restore the original branch and stop rebasing run \"git rebase --abort\".\n\nme> No luck :( A few seconds of thinking... Hmm... no-op patch, do I\nme> need to skip it? Let's try the --skip:\n\n$ git rebase --skip\n\nApplying Fix SYNOPSIS.\n\nerror: patch failed: Documentation/git-merge.txt:10\nerror: Documentation/git-merge.txt: patch does not apply\nUsing index info to reconstruct a base tree...\nFalling back to patching base and 3-way merge...\nAuto-merged Documentation/git-merge.txt\nCONFLICT (content): Merge conflict in Documentation/git-merge.txt\nFailed to merge in the changes.\nPatch failed at 0003.\n\nWhen you have resolved this problem run \"git rebase --continue\".\nIf you would prefer to skip this patch, instead run \"git rebase --skip\".\nTo restore the original branch and stop rebasing run \"git rebase --abort\".\n\nme> Aha, that's it! But why git didn't just skip the no-op patch\nme> automatically? Well, anyway , now I have a new expected conflict,\nme> and I'm sure I just want to skip this patch, so let's try exactly\nme> that:\n\n$ git rebase --skip\nDirty index: cannot apply patches (dirty: Documentation/git-merge.txt)\n\nme> No luck :( Well, let's go the long way, -- edit conflicting\nme> Documentation/git-merge.txt (so that it matches upstream),\n\n$ git add Documentation/git-merge.txt\n$ git rebase --skip\nNothing to do.\n\nme> Well, I already knew this will work, but why should I edit the file\nme> and then git-add it just to skip the patch? Is there better way?\nme> Anyway, the \"Nothing to do.\" above is slightly confusing, -- did it\nme> actually skip the patch? So let's check the result:\n\n$ gitk\n\nme> The result is as expected, -- the only patch on top of current origin\nme> HEAD, -- nice.\n\n-- \nSergei.\n"},{"id":"57722","messageId":"20071031195702.GB24332@atjola.homenet","threadId":"10543","inReplyTo":"87d4uv3wh1.fsf@osv.gnss.ru","subject":"Re: Newbie: report of first experience with git-rebase.","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2007-10-31T19:57:02Z","receivedAt":"2007-10-31T19:57:02Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2007.10.31 22:39:06 +0300, Sergei Organov wrote:\n> Hello,\n> \n> I've made my first attempt at tracking my changes to upstream git\n> repository using git-fetch/git-rebase workflow. I did three commits to\n> my master branch, and then upstream incorporated two of them in slightly\n> modified form, so that some conflicts are to be expected. I did\n> git-fetch followed by git-rebase, and finally have got the end result I\n> hoped for, but there were some confusion along the way. I think I'd post\n> the log of the session here along with my thoughts so that an interested\n> person could see how it works for a newbie (my thoughts and non-git\n> actions at the time of rebasing are marked with 'me>' prefix):\n> \n> $ git fetch\n> [...]\n> $ git rebase origin\n> First, rewinding head to replay your work on top of it...\n> HEAD is now at 9c51414... Merge branch 'maint' into HEAD\n> \n> Applying Fix a typo.\n> \n> Wrote tree f5b2feefc021486eae9d2d84c69e0d6ead027a9d\n> Committed: 983e907b1360c17c7ac925d6035d82cc7243f406\n> \n> Applying Use new syntax (-m option) for git-merge.\n> \n> error: patch failed: Documentation/core-tutorial.txt:878\n> error: Documentation/core-tutorial.txt: patch does not apply\n> Using index info to reconstruct a base tree...\n> Falling back to patching base and 3-way merge...\n> Auto-merged Documentation/core-tutorial.txt\n> CONFLICT (content): Merge conflict in Documentation/core-tutorial.txt\n> Failed to merge in the changes.\n> Patch failed at 0002.\n> \n> When you have resolved this problem run \"git rebase --continue\".\n> If you would prefer to skip this patch, instead run \"git rebase --skip\".\n> To restore the original branch and stop rebasing run \"git rebase --abort\".\n> \n> me> Nice, this conflict is expected.\n> me> Editing Documentation/core-tutorial.txt to resolve the\n> me> conflict... Conflict is resolved so that the working file matches\n> me> upstream version.\n> \n> $ git rebase --continue\n> You must edit all merge conflicts and then\n> mark them as resolved using git add\n> \n> me> Nice helpful message, -- need to do git-add\n> \n> $ git add Documentation/core-tutorial.txt\n> $ git rebase --continue\n> \n> Applying Use new syntax (-m option) for git-merge.\n> \n> No changes - did you forget to use 'git add'?\n> \n> When you have resolved this problem run \"git rebase --continue\".\n> If you would prefer to skip this patch, instead run \"git rebase --skip\".\n> To restore the original branch and stop rebasing run \"git rebase --abort\".\n> \n> me> What?! I just did the git-add! Moreover, before I did git-add, the\n> me> error was different and helpful. Something went wrong? \n> me> Well, it's unlikely, but maybe I made a mistake of not specifying\n> me> the 'origin'?\n> \n> $ git rebase --continue origin\n> \n> Applying Use new syntax (-m option) for git-merge.\n> \n> No changes - did you forget to use 'git add'?\n> \n> When you have resolved this problem run \"git rebase --continue\".\n> If you would prefer to skip this patch, instead run \"git rebase --skip\".\n> To restore the original branch and stop rebasing run \"git rebase --abort\".\n> \n> me> No luck :( A few seconds of thinking... Hmm... no-op patch, do I\n> me> need to skip it? Let's try the --skip:\n> \n> $ git rebase --skip\n> \n> Applying Fix SYNOPSIS.\n> \n> error: patch failed: Documentation/git-merge.txt:10\n> error: Documentation/git-merge.txt: patch does not apply\n> Using index info to reconstruct a base tree...\n> Falling back to patching base and 3-way merge...\n> Auto-merged Documentation/git-merge.txt\n> CONFLICT (content): Merge conflict in Documentation/git-merge.txt\n> Failed to merge in the changes.\n> Patch failed at 0003.\n> \n> When you have resolved this problem run \"git rebase --continue\".\n> If you would prefer to skip this patch, instead run \"git rebase --skip\".\n> To restore the original branch and stop rebasing run \"git rebase --abort\".\n> \n> me> Aha, that's it! But why git didn't just skip the no-op patch\n\nIt wasn't a no-op patch. It had conflicts which you resolved to the\nupstream version and _then_ you had a no-op.\n\n> me> automatically? Well, anyway , now I have a new expected conflict,\n> me> and I'm sure I just want to skip this patch, so let's try exactly\n> me> that:\n> \n> $ git rebase --skip\n> Dirty index: cannot apply patches (dirty: Documentation/git-merge.txt)\n> \n> me> No luck :( Well, let's go the long way, -- edit conflicting\n> me> Documentation/git-merge.txt (so that it matches upstream),\n> \n> $ git add Documentation/git-merge.txt\n> $ git rebase --skip\n> Nothing to do.\n> \n> me> Well, I already knew this will work, but why should I edit the file\n> me> and then git-add it just to skip the patch? Is there better way?\n> me> Anyway, the \"Nothing to do.\" above is slightly confusing, -- did it\n> me> actually skip the patch? So let's check the result:\n\nThere seems to be some bug in rebase that makes it fail in this case.\nSomeone on #git also reported that --abort failed to reset his branch to\nthe old head in a similar case, but I didn't manage to reproduce that\nyet (well, I didn't try that hard), so I don't know if it's really a bug\nor a misuse by that guy.\n\nBjörn\n"},{"id":"57728","messageId":"874pg73u6h.fsf@osv.gnss.ru","threadId":"10543","inReplyTo":"20071031195702.GB24332@atjola.homenet","subject":"Re: Newbie: report of first experience with git-rebase.","fromName":"Sergei Organov","fromEmail":"osv@javad.com","sentAt":"2007-10-31T20:28:38Z","receivedAt":"2007-10-31T20:28:38Z","isPatch":false,"sender":{"key":"osv@javad.com","avatar":null},"body":"Björn Steinbrink <B.Steinbrink@gmx.de> writes:\n> On 2007.10.31 22:39:06 +0300, Sergei Organov wrote:\n>> Hello,\n>> \n>> I've made my first attempt at tracking my changes to upstream git\n>> repository using git-fetch/git-rebase workflow. I did three commits to\n>> my master branch, and then upstream incorporated two of them in slightly\n>> modified form, so that some conflicts are to be expected. I did\n>> git-fetch followed by git-rebase, and finally have got the end result I\n>> hoped for, but there were some confusion along the way. I think I'd post\n>> the log of the session here along with my thoughts so that an interested\n>> person could see how it works for a newbie (my thoughts and non-git\n>> actions at the time of rebasing are marked with 'me>' prefix):\n>> \n>> $ git fetch\n>> [...]\n>> $ git rebase origin\n>> First, rewinding head to replay your work on top of it...\n>> HEAD is now at 9c51414... Merge branch 'maint' into HEAD\n>> \n>> Applying Fix a typo.\n>> \n>> Wrote tree f5b2feefc021486eae9d2d84c69e0d6ead027a9d\n>> Committed: 983e907b1360c17c7ac925d6035d82cc7243f406\n>> \n>> Applying Use new syntax (-m option) for git-merge.\n>> \n>> error: patch failed: Documentation/core-tutorial.txt:878\n>> error: Documentation/core-tutorial.txt: patch does not apply\n>> Using index info to reconstruct a base tree...\n>> Falling back to patching base and 3-way merge...\n>> Auto-merged Documentation/core-tutorial.txt\n>> CONFLICT (content): Merge conflict in Documentation/core-tutorial.txt\n>> Failed to merge in the changes.\n>> Patch failed at 0002.\n>> \n>> When you have resolved this problem run \"git rebase --continue\".\n>> If you would prefer to skip this patch, instead run \"git rebase --skip\".\n>> To restore the original branch and stop rebasing run \"git rebase --abort\".\n>> \n>> me> Nice, this conflict is expected.\n>> me> Editing Documentation/core-tutorial.txt to resolve the\n>> me> conflict... Conflict is resolved so that the working file matches\n>> me> upstream version.\n>> \n>> $ git rebase --continue\n>> You must edit all merge conflicts and then\n>> mark them as resolved using git add\n>> \n>> me> Nice helpful message, -- need to do git-add\n>> \n>> $ git add Documentation/core-tutorial.txt\n>> $ git rebase --continue\n>> \n>> Applying Use new syntax (-m option) for git-merge.\n>> \n>> No changes - did you forget to use 'git add'?\n>> \n>> When you have resolved this problem run \"git rebase --continue\".\n>> If you would prefer to skip this patch, instead run \"git rebase --skip\".\n>> To restore the original branch and stop rebasing run \"git rebase --abort\".\n>> \n>> me> What?! I just did the git-add! Moreover, before I did git-add, the\n>> me> error was different and helpful. Something went wrong? \n>> me> Well, it's unlikely, but maybe I made a mistake of not specifying\n>> me> the 'origin'?\n>> \n>> $ git rebase --continue origin\n>> \n>> Applying Use new syntax (-m option) for git-merge.\n>> \n>> No changes - did you forget to use 'git add'?\n>> \n>> When you have resolved this problem run \"git rebase --continue\".\n>> If you would prefer to skip this patch, instead run \"git rebase --skip\".\n>> To restore the original branch and stop rebasing run \"git rebase --abort\".\n>> \n>> me> No luck :( A few seconds of thinking... Hmm... no-op patch, do I\n>> me> need to skip it? Let's try the --skip:\n>> \n>> $ git rebase --skip\n>> \n>> Applying Fix SYNOPSIS.\n>> \n>> error: patch failed: Documentation/git-merge.txt:10\n>> error: Documentation/git-merge.txt: patch does not apply\n>> Using index info to reconstruct a base tree...\n>> Falling back to patching base and 3-way merge...\n>> Auto-merged Documentation/git-merge.txt\n>> CONFLICT (content): Merge conflict in Documentation/git-merge.txt\n>> Failed to merge in the changes.\n>> Patch failed at 0003.\n>> \n>> When you have resolved this problem run \"git rebase --continue\".\n>> If you would prefer to skip this patch, instead run \"git rebase --skip\".\n>> To restore the original branch and stop rebasing run \"git rebase --abort\".\n>> \n>> me> Aha, that's it! But why git didn't just skip the no-op patch\n>\n> It wasn't a no-op patch. It had conflicts which you resolved to the\n> upstream version and _then_ you had a no-op.\n\nYes, and that's the problem. Why 'git --continue' didn't just skip this\npatch that *already became no-op* after conflict resolution and forced\nme to explicitly use 'git --skip' instead?\n\nThis forces one to use 'git --skip' if the patch happens to become a\nno-op after conflict resolution, and 'git --continue' otherwise. Why\nthis complication?\n\n-- \nSergei.\n"},{"id":"57735","messageId":"Pine.LNX.4.64.0710312111170.4362@racer.site","threadId":"10543","inReplyTo":"874pg73u6h.fsf@osv.gnss.ru","subject":"Re: Newbie: report of first experience with git-rebase.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-31T21:12:06Z","receivedAt":"2007-10-31T21:12:06Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 31 Oct 2007, Sergei Organov wrote:\n\n> Yes, and that's the problem. Why 'git --continue' didn't just skip this \n> patch that *already became no-op* after conflict resolution and forced \n> me to explicitly use 'git --skip' instead?\n\nIsn't that obvious?  To prevent you from accidentally losing a commit.\n\nCiao,\nDscho\n"},{"id":"57739","messageId":"20071031212523.GB4255@steel.home","threadId":"10543","inReplyTo":"87d4uv3wh1.fsf@osv.gnss.ru","subject":"Re: Newbie: report of first experience with git-rebase.","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-10-31T21:25:23Z","receivedAt":"2007-10-31T21:25:23Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Sergei Organov, Wed, Oct 31, 2007 20:39:06 +0100:\n> $ git rebase --continue\n> You must edit all merge conflicts and then\n> mark them as resolved using git add\n> \n> me> Nice helpful message, -- need to do git-add\n> \n> $ git add Documentation/core-tutorial.txt\n> $ git rebase --continue\n> \n> Applying Use new syntax (-m option) for git-merge.\n> \n> No changes - did you forget to use 'git add'?\n\nThis \"No changes\" was meant as a hint\n\n> When you have resolved this problem run \"git rebase --continue\".\n> If you would prefer to skip this patch, instead run \"git rebase --skip\".\n> To restore the original branch and stop rebasing run \"git rebase --abort\".\n> \n> me> What?! I just did the git-add! Moreover, before I did git-add, the\n> me> error was different and helpful. Something went wrong? \n\nWell, you edited you tree to look exactly like it already is.\n\n> me> No luck :( A few seconds of thinking... Hmm... no-op patch, do I\n> me> need to skip it? Let's try the --skip:\n> \n> $ git rebase --skip\n\nExactly.\n\n> Applying Fix SYNOPSIS.\n> \n> error: patch failed: Documentation/git-merge.txt:10\n> error: Documentation/git-merge.txt: patch does not apply\n> Using index info to reconstruct a base tree...\n> Falling back to patching base and 3-way merge...\n> Auto-merged Documentation/git-merge.txt\n> CONFLICT (content): Merge conflict in Documentation/git-merge.txt\n> Failed to merge in the changes.\n> Patch failed at 0003.\n> \n> When you have resolved this problem run \"git rebase --continue\".\n> If you would prefer to skip this patch, instead run \"git rebase --skip\".\n> To restore the original branch and stop rebasing run \"git rebase --abort\".\n> \n> me> Aha, that's it! But why git didn't just skip the no-op patch\n> me> automatically? Well, anyway , now I have a new expected conflict,\n\nit was not a noop patch before you resolved the conflict.\n\n> me> and I'm sure I just want to skip this patch, so let's try exactly\n> me> that:\n> \n> $ git rebase --skip\n> Dirty index: cannot apply patches (dirty: Documentation/git-merge.txt)\n\nWell... This one kind of hard: git-rebase _cannot_ know whether it is\nsafe to just drop all changes in the index and work tree (you could\nhave made the changes on purpose). It was decided not to drop\nanything. You always can do\n\n    $ git reset --hard # kills all changes in index and work tree\n    $ git rebase --skip\n\n(or maybe git-rebase is just too careful...)\n\n> me> No luck :( Well, let's go the long way, -- edit conflicting\n> me> Documentation/git-merge.txt (so that it matches upstream),\n> \n> $ git add Documentation/git-merge.txt\n> $ git rebase --skip\n> Nothing to do.\n> \n> me> Well, I already knew this will work, but why should I edit the file\n> me> and then git-add it just to skip the patch? Is there better way?\n> me> Anyway, the \"Nothing to do.\" above is slightly confusing, -- did it\n> me> actually skip the patch? So let's check the result:\n\nYes. It was the last commit. You were just too unlucky to hit all the\nhard cases your first day.\n"},{"id":"57743","messageId":"20071031212923.GL4569@fieldses.org","threadId":"10543","inReplyTo":"Pine.LNX.4.64.0710312111170.4362@racer.site","subject":"Re: Newbie: report of first experience with git-rebase.","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-10-31T21:29:23Z","receivedAt":"2007-10-31T21:29:23Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Wed, Oct 31, 2007 at 09:12:06PM +0000, Johannes Schindelin wrote:\n> Hi,\n> \n> On Wed, 31 Oct 2007, Sergei Organov wrote:\n> \n> > Yes, and that's the problem. Why 'git --continue' didn't just skip this \n> > patch that *already became no-op* after conflict resolution and forced \n> > me to explicitly use 'git --skip' instead?\n> \n> Isn't that obvious?  To prevent you from accidentally losing a commit.\n\nThat would make sense to me if this was a mistake that could easily\nhappen.\n\nI'd assumed that in the case of a conflict that stopped the rebase\nprocess, the index and working tree are always left dirty, so that if\nthey both agree with the HEAD at the time of commit, then it's because\nthe user explicitly made them that way.\n\nI ran into the same confusion as the original poster when starting to\nuse rebase, so I suspect it's common.\n\n--b.\n"},{"id":"57747","messageId":"7vhck7gdzs.fsf@gitster.siamese.dyndns.org","threadId":"10543","inReplyTo":"Pine.LNX.4.64.0710312111170.4362@racer.site","subject":"Re: Newbie: report of first experience with git-rebase.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-10-31T21:39:51Z","receivedAt":"2007-10-31T21:39:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> On Wed, 31 Oct 2007, Sergei Organov wrote:\n>\n>> Yes, and that's the problem. Why 'git --continue' didn't just skip this \n>> patch that *already became no-op* after conflict resolution and forced \n>> me to explicitly use 'git --skip' instead?\n>\n> Isn't that obvious?  To prevent you from accidentally losing a commit.\n\nIn case it is not obvious...\n\nA rebase conflict resolution that results in emptiness is a\nrather rare event (especially because rebase drops upfront the\nidentical changes from the set of commits to be replayed), but\nit does happen.  One could argue that \"rebase --continue\" can\nnotice that the resolved index is identical to the tree of the\nHEAD commit and skip it automatically.\n\nGiven an index that is identical to HEAD, however, it is not\neasy to safely determine if that is because the patch did not\napply at all, or the patch was applied with conflicts _and_ the\nuser decided to make the patch a no-op by resolving.  The\nautomatic droppage of the commit needs to happen only on the\nlatter and never on the former.\n"},{"id":"57752","messageId":"4728FC5C.30709@midwinter.com","threadId":"10543","inReplyTo":"20071031212923.GL4569@fieldses.org","subject":"Re: Newbie: report of first experience with git-rebase.","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-10-31T22:06:20Z","receivedAt":"2007-10-31T22:06:20Z","isPatch":false,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"J. Bruce Fields wrote:\n> I ran into the same confusion as the original poster when starting to\n> use rebase, so I suspect it's common.\n>   \n\nI've been using rebase just about every day for close to a year and it \n*still* annoys me when it happens. Especially the \"Did you forget to git \nadd?\" part of the message. The thought that always goes through my head \nis, \"No, Mr. Rebase, I did NOT forget to git add. I remembered to git \nadd, then you were too stupid to do the right thing after that.\"\n\nJust happened to me this morning, in fact: I had a quick hack in place \nto work around a bug, the bug got fixed for real, and I rebased. In the \nprocess of conflict resolution I saw that my workaround wasn't needed \nany more and accepted the upstream version of that particular part of \nthe file. Ran git-add on it, then rebase --continue, and boom, was \naccused of forgetting to run git-add.\n\nIt is a minor annoyance and nowadays I just sigh a bit and run --skip \ninstead, but it'd be nice if it didn't happen. I don't like having to \ncare whether or not I happened to change other files in a particular \ncommit after I resolve conflicts in one file in favor of the upstream \nversion.\n\n-Steve\n"},{"id":"57756","messageId":"Pine.LNX.4.64.0710311823070.7357@iabervon.org","threadId":"10543","inReplyTo":"4728FC5C.30709@midwinter.com","subject":"Re: Newbie: report of first experience with git-rebase.","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-10-31T22:35:39Z","receivedAt":"2007-10-31T22:35:39Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 31 Oct 2007, Steven Grimm wrote:\n\n> J. Bruce Fields wrote:\n> > I ran into the same confusion as the original poster when starting to\n> > use rebase, so I suspect it's common.\n> >   \n> \n> I've been using rebase just about every day for close to a year and it *still*\n> annoys me when it happens. Especially the \"Did you forget to git add?\" part of\n> the message. The thought that always goes through my head is, \"No, Mr. Rebase,\n> I did NOT forget to git add. I remembered to git add, then you were too stupid\n> to do the right thing after that.\"\n> \n> Just happened to me this morning, in fact: I had a quick hack in place to work\n> around a bug, the bug got fixed for real, and I rebased. In the process of\n> conflict resolution I saw that my workaround wasn't needed any more and\n> accepted the upstream version of that particular part of the file. Ran git-add\n> on it, then rebase --continue, and boom, was accused of forgetting to run\n> git-add.\n> \n> It is a minor annoyance and nowadays I just sigh a bit and run --skip instead,\n> but it'd be nice if it didn't happen. I don't like having to care whether or\n> not I happened to change other files in a particular commit after I resolve\n> conflicts in one file in favor of the upstream version.\n\nI think it's worth requiring you to say --skip in order to acknowledge \nthat you won't have as many commits and you'll lose the commit message. On \nthe other hand, the message should probably suggest that you might want to \nskip this commit instead of suggesting that you come up with some other \nchange to include in it.\n\nCertainly, if \"git diff\" returns no changes, \"git add\" is a bad \nsuggestion, and it would be nicer to suggest something possibly correct.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"57757","messageId":"20071031223819.GN4569@fieldses.org","threadId":"10543","inReplyTo":"4728FC5C.30709@midwinter.com","subject":"Re: Newbie: report of first experience with git-rebase.","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-10-31T22:38:19Z","receivedAt":"2007-10-31T22:38:19Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Wed, Oct 31, 2007 at 03:06:20PM -0700, Steven Grimm wrote:\n> I've been using rebase just about every day for close to a year and it \n> *still* annoys me when it happens. Especially the \"Did you forget to git \n> add?\" part of the message. The thought that always goes through my head is, \n> \"No, Mr. Rebase, I did NOT forget to git add. I remembered to git add, then \n> you were too stupid to do the right thing after that.\"\n>\n> Just happened to me this morning, in fact: I had a quick hack in place to \n> work around a bug, the bug got fixed for real, and I rebased. In the \n> process of conflict resolution I saw that my workaround wasn't needed any \n> more and accepted the upstream version of that particular part of the file. \n> Ran git-add on it, then rebase --continue, and boom, was accused of \n> forgetting to run git-add.\n>\n> It is a minor annoyance and nowadays I just sigh a bit and run --skip \n> instead, but it'd be nice if it didn't happen. I don't like having to care \n> whether or not I happened to change other files in a particular commit \n> after I resolve conflicts in one file in favor of the upstream version.\n\nYeah, I think a message saying \"patch is now empty, skipping...\" would\nbe sufficient to let the user know what's going on.  This doesn't seem\nso perilous to me that it's worth requiring a positive acknowledgement.\n\n--b.\n"},{"id":"57759","messageId":"85d4uux5lk.fsf@lola.goethe.zz","threadId":"10543","inReplyTo":"Pine.LNX.4.64.0710312111170.4362@racer.site","subject":"Re: Newbie: report of first experience with git-rebase.","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-10-31T22:49:11Z","receivedAt":"2007-10-31T22:49:11Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> On Wed, 31 Oct 2007, Sergei Organov wrote:\n>\n>> Yes, and that's the problem. Why 'git --continue' didn't just skip this \n>> patch that *already became no-op* after conflict resolution and forced \n>> me to explicitly use 'git --skip' instead?\n>\n> Isn't that obvious?  To prevent you from accidentally losing a commit.\n\nThe commit would not change anything, so what is there to lose?\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"57760","messageId":"858x5ix5em.fsf@lola.goethe.zz","threadId":"10543","inReplyTo":"7vhck7gdzs.fsf@gitster.siamese.dyndns.org","subject":"Re: Newbie: report of first experience with git-rebase.","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-10-31T22:53:21Z","receivedAt":"2007-10-31T22:53:21Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> A rebase conflict resolution that results in emptiness is a rather\n> rare event (especially because rebase drops upfront the identical\n> changes from the set of commits to be replayed), but it does happen.\n> One could argue that \"rebase --continue\" can notice that the resolved\n> index is identical to the tree of the HEAD commit and skip it\n> automatically.\n>\n> Given an index that is identical to HEAD, however, it is not\n> easy to safely determine if that is because the patch did not\n> apply at all,\n\nWouldn't there be a conflict in the index?  A conflict which can only be\nresolved by adding?  Which then results in a question whether you forgot\nto add?\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"57771","messageId":"alpine.LFD.0.9999.0710312224380.21255@xanadu.home","threadId":"10543","inReplyTo":"7vhck7gdzs.fsf@gitster.siamese.dyndns.org","subject":"Re: Newbie: report of first experience with git-rebase.","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-11-01T02:27:46Z","receivedAt":"2007-11-01T02:27:46Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 31 Oct 2007, Junio C Hamano wrote:\n\n> A rebase conflict resolution that results in emptiness is a\n> rather rare event (especially because rebase drops upfront the\n> identical changes from the set of commits to be replayed), but\n> it does happen.  One could argue that \"rebase --continue\" can\n> notice that the resolved index is identical to the tree of the\n> HEAD commit and skip it automatically.\n> \n> Given an index that is identical to HEAD, however, it is not\n> easy to safely determine if that is because the patch did not\n> apply at all, or the patch was applied with conflicts _and_ the\n> user decided to make the patch a no-op by resolving.  The\n> automatic droppage of the commit needs to happen only on the\n> latter and never on the former.\n\nProbably some additional clue could be displayed for the user benefit.  \nThis might solve the issue nicely.\n\n\nNicolas\n"},{"id":"57811","messageId":"87ve8m2mfn.fsf@osv.gnss.ru","threadId":"10543","inReplyTo":"7vhck7gdzs.fsf@gitster.siamese.dyndns.org","subject":"Re: Newbie: report of first experience with git-rebase.","fromName":"Sergei Organov","fromEmail":"osv@javad.com","sentAt":"2007-11-01T12:13:32Z","receivedAt":"2007-11-01T12:13:32Z","isPatch":false,"sender":{"key":"osv@javad.com","avatar":null},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n>\n>> On Wed, 31 Oct 2007, Sergei Organov wrote:\n>>\n>>> Yes, and that's the problem. Why 'git --continue' didn't just skip this \n>>> patch that *already became no-op* after conflict resolution and forced \n>>> me to explicitly use 'git --skip' instead?\n>>\n>> Isn't that obvious?  To prevent you from accidentally losing a commit.\n>\n> In case it is not obvious...\n>\n> A rebase conflict resolution that results in emptiness is a\n> rather rare event (especially because rebase drops upfront the\n> identical changes from the set of commits to be replayed), but\n> it does happen.\n\nFunny how 2 of my first 3 commits suffer from this \"rather rare event\",\nand it was not Friday, 13 ;)\n\n-- \nSergei.\n"},{"id":"57829","messageId":"Pine.LNX.4.64.0711011423440.4362@racer.site","threadId":"10543","inReplyTo":"87ve8m2mfn.fsf@osv.gnss.ru","subject":"Re: Newbie: report of first experience with git-rebase.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-01T14:24:37Z","receivedAt":"2007-11-01T14:24:37Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 1 Nov 2007, Sergei Organov wrote:\n\n> Junio C Hamano <gitster@pobox.com> writes:\n> \n> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n> >\n> >> On Wed, 31 Oct 2007, Sergei Organov wrote:\n> >>\n> >>> Yes, and that's the problem. Why 'git --continue' didn't just skip this \n> >>> patch that *already became no-op* after conflict resolution and forced \n> >>> me to explicitly use 'git --skip' instead?\n> >>\n> >> Isn't that obvious?  To prevent you from accidentally losing a commit.\n> >\n> > In case it is not obvious...\n> >\n> > A rebase conflict resolution that results in emptiness is a\n> > rather rare event (especially because rebase drops upfront the\n> > identical changes from the set of commits to be replayed), but\n> > it does happen.\n> \n> Funny how 2 of my first 3 commits suffer from this \"rather rare event\",\n> and it was not Friday, 13 ;)\n\nThey are rare events.  In your case I guess that subtly different versions \nwere _actually_ applied (such as white space fixes), which is why such a \nrare event hit you.\n\nCiao,\nDscho\n"},{"id":"57835","messageId":"20071101151016.GA26103@fieldses.org","threadId":"10543","inReplyTo":"Pine.LNX.4.64.0711011423440.4362@racer.site","subject":"Re: Newbie: report of first experience with git-rebase.","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-11-01T15:10:16Z","receivedAt":"2007-11-01T15:10:16Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Thu, Nov 01, 2007 at 02:24:37PM +0000, Johannes Schindelin wrote:\n> Hi,\n> \n> On Thu, 1 Nov 2007, Sergei Organov wrote:\n> \n> > Junio C Hamano <gitster@pobox.com> writes:\n> > \n> > > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n> > >\n> > >> On Wed, 31 Oct 2007, Sergei Organov wrote:\n> > >>\n> > >>> Yes, and that's the problem. Why 'git --continue' didn't just skip this \n> > >>> patch that *already became no-op* after conflict resolution and forced \n> > >>> me to explicitly use 'git --skip' instead?\n> > >>\n> > >> Isn't that obvious?  To prevent you from accidentally losing a commit.\n> > >\n> > > In case it is not obvious...\n> > >\n> > > A rebase conflict resolution that results in emptiness is a\n> > > rather rare event (especially because rebase drops upfront the\n> > > identical changes from the set of commits to be replayed), but\n> > > it does happen.\n> > \n> > Funny how 2 of my first 3 commits suffer from this \"rather rare event\",\n> > and it was not Friday, 13 ;)\n> \n> They are rare events.  In your case I guess that subtly different versions \n> were _actually_ applied (such as white space fixes),\n\nThat's actually pretty common, in my experience.\n\n> which is why such a rare event hit you.\n\nI'm using git to track some changes I submitted to a project that's\nmainly text, and that I only get release tarballs of.  On my most recent\nrebase all my patches got applied, but the text also got re-wrapped and\nre-indented at the same time.  So all but I think one or two of a dozen\npatches ended up with a conflict resolution and then --skip.\n\nWhich may not be a case git's really intended for--fair enough.  But\nI've found it's pretty common in my kernel work too.  Either I'm\nrebasing against changes I made myself, or else a maintainer took my\nchanges but fixed up some minor style problems along the way.\n\n--b.\n"},{"id":"57853","messageId":"7v8x5hbtvv.fsf@gitster.siamese.dyndns.org","threadId":"10543","inReplyTo":"20071101151016.GA26103@fieldses.org","subject":"Re: Newbie: report of first experience with git-rebase.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-01T20:20:04Z","receivedAt":"2007-11-01T20:20:04Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"J. Bruce Fields\" <bfields@fieldses.org> writes:\n\n> On Thu, Nov 01, 2007 at 02:24:37PM +0000, Johannes Schindelin wrote:\n>> \n>> They are rare events.  In your case I guess that subtly different versions \n>> were _actually_ applied (such as white space fixes),\n>\n> That's actually pretty common, in my experience.\n>\n>> which is why such a rare event hit you.\n>\n> I'm using git to track some changes I submitted to a project that's\n> mainly text, and that I only get release tarballs of.  On my most recent\n> rebase all my patches got applied, but the text also got re-wrapped and\n> re-indented at the same time.  So all but I think one or two of a dozen\n> patches ended up with a conflict resolution and then --skip.\n>\n> Which may not be a case git's really intended for--fair enough.  But\n> I've found it's pretty common in my kernel work too.  Either I'm\n> rebasing against changes I made myself, or else a maintainer took my\n> changes but fixed up some minor style problems along the way.\n\nOk, so I retract that \"rare\" comment.\n\nNow, we have established that this is a real problem worth\nsolving, what's next?\n"},{"id":"57958","messageId":"472AF840.1070609@op5.se","threadId":"10543","inReplyTo":"7v8x5hbtvv.fsf@gitster.siamese.dyndns.org","subject":"Re: Newbie: report of first experience with git-rebase.","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-11-02T10:13:20Z","receivedAt":"2007-11-02T10:13:20Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> \"J. Bruce Fields\" <bfields@fieldses.org> writes:\n> \n>> On Thu, Nov 01, 2007 at 02:24:37PM +0000, Johannes Schindelin wrote:\n>>> They are rare events.  In your case I guess that subtly different versions \n>>> were _actually_ applied (such as white space fixes),\n>> That's actually pretty common, in my experience.\n>>\n>>> which is why such a rare event hit you.\n>> I'm using git to track some changes I submitted to a project that's\n>> mainly text, and that I only get release tarballs of.  On my most recent\n>> rebase all my patches got applied, but the text also got re-wrapped and\n>> re-indented at the same time.  So all but I think one or two of a dozen\n>> patches ended up with a conflict resolution and then --skip.\n>>\n>> Which may not be a case git's really intended for--fair enough.  But\n>> I've found it's pretty common in my kernel work too.  Either I'm\n>> rebasing against changes I made myself, or else a maintainer took my\n>> changes but fixed up some minor style problems along the way.\n> \n> Ok, so I retract that \"rare\" comment.\n> \n> Now, we have established that this is a real problem worth\n> solving, what's next?\n\nMake \"git rebase --skip\" skip patches regardless of tree and index state,\nbut still refuse to *start* with dirty tree or index. That way, there's\nno risk of losing anything that can't be re-created unless the user asks\nfor it.\n\nTo be really anal, stash the current mess somewhere, re-apply the same\npatch and diff the two states. If they're identical, do \"git reset --hard\"\nand hop to next patch in rebase-series. If they're not, ask user to say\n\"--force-skip\" instead.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"},{"id":"58021","messageId":"7vtzo431k8.fsf@gitster.siamese.dyndns.org","threadId":"10543","inReplyTo":"472AF840.1070609@op5.se","subject":"Re: Newbie: report of first experience with git-rebase.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-02T19:11:19Z","receivedAt":"2007-11-02T19:11:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andreas Ericsson <ae@op5.se> writes:\n\n> Junio C Hamano wrote:\n>>\n>> Now, we have established that this is a real problem worth\n>> solving, what's next?\n>\n> Make \"git rebase --skip\" skip patches regardless of tree and index state,\n> but still refuse to *start* with dirty tree or index. That way, there's\n> no risk of losing anything that can't be re-created unless the user asks\n> for it.\n\nSounds like a plan.\n"},{"id":"58024","messageId":"472B78EA.6050502@op5.se","threadId":"10543","inReplyTo":"472B77AC.5080507@midwinter.com","subject":"Re: Newbie: report of first experience with git-rebase.","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-11-02T19:22:18Z","receivedAt":"2007-11-02T19:22:18Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Steven Grimm wrote:\n> Junio C Hamano wrote:\n>> Andreas Ericsson <ae@op5.se> writes:\n>>  \n>>> Make \"git rebase --skip\" skip patches regardless of tree and index \n>>> state,\n>>> but still refuse to *start* with dirty tree or index. That way, there's\n>>> no risk of losing anything that can't be re-created unless the user asks\n>>> for it.\n>>>     \n>>\n>> Sounds like a plan.\n>>   \n> \n> I'm unclear how that helps the usability issue here at all, though it \n> doesn't sound like an unreasonable change on its own merit.\n> \n\nBecause 'git commit --skip' will not require the user to first edit the\ntree so the index matches the upstream thing, and he doesn't have to\nmanually run 'git reset --hard' before --skip'ing.\n\nIt's a small improvement, but one that goes in the right direction.\n\nBtw, the above sentence should've read \"but still refuse to *start*\n(as in, start a brand new rebase) with dirty tree or index\"\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"}]}