{"thread":{"id":"3716","subject":"Effective difference between git-rebase and git-resolve","startedAt":"2006-03-25T03:54:23Z","lastAt":"2006-03-26T20:29:28Z","messageCount":10,"participants":["Marc Singer","Linus Torvalds","Junio C Hamano","Johannes Schindelin","Mark Wooding","J. Bruce Fields"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"17903","messageId":"20060325035423.GB31504@buici.com","threadId":"3716","inReplyTo":null,"subject":"Effective difference between git-rebase and git-resolve","fromName":"Marc Singer","fromEmail":"elf@buici.com","sentAt":"2006-03-25T03:54:23Z","receivedAt":"2006-03-25T03:54:23Z","isPatch":false,"sender":{"key":"elf@buici.com","avatar":null},"body":"The process I've been using to keep my patches current with the latest\ndevelopment is this:\n\n git checkout linus && git pull linus\n git checkout work\n\nWhen I'm ready to merge,\n\n git resolve work linus \"Update with head\"\n git tag basis\n\nThis lets me diff against basis even when the linus branch continues\nto follow the latest developments.\n\nToday, I wanted to move everything forward. But the resolve failed to\nmerge some files. In fact, one file was apparently so thorny that\nresolve just gave up and left no working file. Bothersome, but I\nrecovered by moving back to the previous work point.\n\nThen, I found git-rebase which seems to be more what I'd like to use\nsince it moves my patches along on top of the main development line.\n\n git rebase linus\n\nThis time, almost everything merged without a hitch except for the\nthorny file from before. I edited the file, removing the conflict\nmarkers, and started a build. But what I found was that some of the\nchanges I'd made were no longer present. Several files showed no sign\nof the patches even though the kernel versions hadn't changed.\n\nSo, I have a couple of questions:\n\n 1) Am I using rebase correctly?\n 2) If not, did it leave some of my changes uncommitted and hidden\n somewhere? git-ls-files --unmerged shows no sign of them.\n 3) Do I have to pull all of my patches off, apply them to the head\n of the tree, and only use git-rebase to make this work?\n 4) Should I prefer rebase over resolve?\n"},{"id":"17905","messageId":"Pine.LNX.4.64.0603242014160.15714@g5.osdl.org","threadId":"3716","inReplyTo":"20060325035423.GB31504@buici.com","subject":"Re: Effective difference between git-rebase and git-resolve","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-03-25T04:23:04Z","receivedAt":"2006-03-25T04:23:04Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 24 Mar 2006, Marc Singer wrote:\n>\n> The process I've been using to keep my patches current with the latest\n> development is this:\n> \n> git checkout linus && git pull linus\n> git checkout work\n\nYou'd be much more efficient if you just did\n\n\tgit fetch linus\n\nwhich avoids switching back-and-forth (and speeds up the pull too, since \nit doesn't need to update any working directories).\n\n> When I'm ready to merge,\n> \n> git resolve work linus \"Update with head\"\n\nNo, don't do this.\n\n\"git resolve\" is the _old_ stupid merger, which isn't very helpful at all. \nSo please use\n\n\tgit merge \"Merge with Linus\" work linus\n\ninstead, which will use the proper \"recursive\" merge functionality.\n\n> Then, I found git-rebase which seems to be more what I'd like to use\n> since it moves my patches along on top of the main development line.\n> \n> git rebase linus\n> \n> This time, almost everything merged without a hitch except for the\n> thorny file from before. I edited the file, removing the conflict\n> markers, and started a build. But what I found was that some of the\n> changes I'd made were no longer present.\n\nYeah, \"git rebase\" is not _nearly_ as intuitive as doing a real merge.\n\nWhat happened was that you resolved the thorny merge, but the rebase had \nstopped when it hit it, so it never actually did the rest of the rebase. \nWhich explains why some of your changes are no longer present: they are \nstill in the \"rebase queue\".\n\n> 1) Am I using rebase correctly?\n\nYes, but you missed the fact that unlike \"git merge\", rebasing really is a \n\"move one commit at a time\" thing, and it stopped on the middle.\n\n> 4) Should I prefer rebase over resolve?\n\nYou should never do \"resolve\", it's very oldfashioned. If you want to \nmerge, just use \"git merge\", which will do the right thing.\n\nAs to rebase, it often is very nice, but on the other hand, it leaves \nthings in a total mess when it fails, which is a pity. Maybe there's a \nnice way to just continue, but I end up just doing a\n\n\tgit reset --hard ORIG_HEAD\n\nto undo the failed rebase.\n\nJunio, is there some magic to restart a rebase after you've fixed up the \nconflicts?\n\n\t\tLinus\n"},{"id":"17906","messageId":"7v64m3ys3a.fsf@assigned-by-dhcp.cox.net","threadId":"3716","inReplyTo":"Pine.LNX.4.64.0603242014160.15714@g5.osdl.org","subject":"Re: Effective difference between git-rebase and git-resolve","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-03-25T06:08:09Z","receivedAt":"2006-03-25T06:08:09Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> As to rebase, it often is very nice, but on the other hand, it leaves \n> things in a total mess when it fails, which is a pity. Maybe there's a \n> nice way to just continue, but I end up just doing a\n>\n> \tgit reset --hard ORIG_HEAD\n>\n> to undo the failed rebase.\n>\n> Junio, is there some magic to restart a rebase after you've fixed up the \n> conflicts?\n\nThe modern rebase is essentially git-format-patch piped to\ngit-am (with -3 flag to allow falling back to three-way merge),\nand all the familiar \"the patch did not apply -- what now?\"\ntechniques can be employed.\n\nSince the pre-image blobs recorded in the intermediate\nformat-patch output by definition exist in your repository, it\nalways falls back to three-way merge when the patch does not\napply cleanly. Then you can resolve and say \"git am --resolved\"\nto continue.\n"},{"id":"17907","messageId":"7v1wwrys07.fsf@assigned-by-dhcp.cox.net","threadId":"3716","inReplyTo":"20060325043507.GA14644@buici.com","subject":"Re: Effective difference between git-rebase and git-resolve","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-03-25T06:10:00Z","receivedAt":"2006-03-25T06:10:00Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Marc Singer writes:\n\n>> \tgit merge \"Merge with Linus\" work linus\n>> \n>> instead, which will use the proper \"recursive\" merge functionality.\n>\n> OK. I'll see if that is more successful. It would be nice if the\n> resolve command printed a message about the command being deprecated.\n\nThe only reason I didn't do that was because I just did not want\nto disrupt the workflow by Linus. If nobody in the upper\nechelon of kernel people (meaning, longest-time git users) use\ngit-resolve anymore, I think we should mark it deprecated and\nremove it eventually.\n"},{"id":"17910","messageId":"20060325063225.GA13791@buici.com","threadId":"3716","inReplyTo":"7v64m3ys3a.fsf@assigned-by-dhcp.cox.net","subject":"Re: Effective difference between git-rebase and git-resolve","fromName":"Marc Singer","fromEmail":"elf@buici.com","sentAt":"2006-03-25T06:32:25Z","receivedAt":"2006-03-25T06:32:25Z","isPatch":false,"sender":{"key":"elf@buici.com","avatar":null},"body":"On Fri, Mar 24, 2006 at 10:08:09PM -0800, Junio C Hamano wrote:\n> > Junio, is there some magic to restart a rebase after you've fixed up the \n> > conflicts?\n> \n> The modern rebase is essentially git-format-patch piped to\n> git-am (with -3 flag to allow falling back to three-way merge),\n> and all the familiar \"the patch did not apply -- what now?\"\n> techniques can be employed.\n> \n> Since the pre-image blobs recorded in the intermediate\n> format-patch output by definition exist in your repository, it\n> always falls back to three-way merge when the patch does not\n> apply cleanly. Then you can resolve and say \"git am --resolved\"\n> to continue.\n\nBy modern do you mean newer than 1.2.4? I comprehend what you're\nlayin' down here, but I don't know if I need to do something\ndifferent.\n\nMoreover, it isn't clear to me if git-rebase is better than git-merge.\n"},{"id":"17912","messageId":"7vacbfxadu.fsf@assigned-by-dhcp.cox.net","threadId":"3716","inReplyTo":"20060325063225.GA13791@buici.com","subject":"Re: Effective difference between git-rebase and git-resolve","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-03-25T07:15:57Z","receivedAt":"2006-03-25T07:15:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Marc Singer writes:\n\n[I'm shuffling this part to the top]\n\n> Moreover, it isn't clear to me if git-rebase is better than git-merge.\n\nMerge preserves commit ancestry, so if you are hoping it to\nclean up your history, that is not the tool to do it. Both\nrebase and cherry-pick are to help you create a cleaner,\nalternate history. So none is better than the other. They\nserve different purposes.\n\n> On Fri, Mar 24, 2006 at 10:08:09PM -0800, Junio C Hamano wrote:\n>> > Junio, is there some magic to restart a rebase after you've fixed up the \n>> > conflicts?\n>> \n>> The modern rebase is essentially git-format-patch piped to\n>> git-am (with -3 flag to allow falling back to three-way merge),\n>> and all the familiar \"the patch did not apply -- what now?\"\n>> techniques can be employed.\n>...\n> By modern do you mean newer than 1.2.4? I comprehend what you're\n> layin' down here, but I don't know if I need to do something\n> different.\n\nBy modern, I meant v0.99.9-g7f59dbb.\n\ndiff-tree 7f59dbb... (from f9039f3...)\nAuthor: Junio C Hamano \nDate: Mon Nov 14 00:41:53 2005 -0800\n\n Rewrite rebase to use git-format-patch piped to git-am.\n \n The current rebase implementation finds commits in our tree but\n not in the upstream tree using git-cherry, and tries to apply\n them using git-cherry-pick (i.e. always use 3-way) one by one.\n \n Which is fine, but when some of the changes do not apply\n cleanly, it punts, and punts badly.\n \n Suppose you have commits A-B-C-D-E since you forked from the\n upstream and submitted the changes for inclusion. You fetch\n from upstream head U and find that B has been picked up. You\n run git-rebase to update your branch, which tries to apply\n changes contained in A-C-D-E, in this order, but replaying of C\n fails, because the upstream got changes that touch the same area\n from elsewhere.\n \n Now what?\n \n It notes that fact, and goes ahead to apply D and E, and at the\n very end tells you to deal with C by hand. Even if you somehow\n managed to replay C on top of the result, you would now end up\n with ...-B-...-U-A-D-E-C.\n \n Breaking the order between B and others was the conscious\n decision made by the upstream, so we would not worry about it,\n and even if it were worrisome, it is too late for us to fix now.\n What D and E do may well depend on having C applied before them,\n which is a problem for us.\n \n This rewrites rebase to use git-format-patch piped to git-am,\n and when the patch does not apply, have git-am fall back on\n 3-way merge. The updated diff/patch pair knows how to apply\n trivial binary patches as long as the pre- and post-images are\n locally available, so this should work on a repository with\n binary files as well.\n \n The primary benefit of this change is that it makes rebase\n easier to use when some of the changes do not replay cleanly.\n In the \"unapplicable patch in the middle\" case, this \"rebase\"\n works like this:\n \n - A series of patches in e-mail form is created that records\n what A-C-D-E do, and is fed to git-am. This is stored in\n .dotest/ directory, just like the case you tried to apply\n them from your mailbox. Your branch is rewound to the tip of\n upstream U, and the original head is kept in .git/ORIG_HEAD,\n so you could \"git reset --hard ORIG_HEAD\" in case the end\n result is really messy.\n \n - Patch A applies cleanly. This could either be a clean patch\n application on top of rewound head (i.e. same as upstream\n head), or git-am might have internally fell back on 3-way\n (i.e. it would have done the same thing as git-cherry-pick).\n In either case, a rebased commit A is made on top of U.\n \n - Patch C does not apply. git-am stops here, with conflicts to\n be resolved in the working tree. Yet-to-be-applied D and E\n are still kept in .dotest/ directory at this point. What the\n user does is exactly the same as fixing up unapplicable patch\n when running git-am:\n \n - Resolve conflict just like any merge conflicts.\n - \"git am --resolved --3way\" to continue applying the patches.\n \n - This applies the fixed-up patch so by definition it had\n better apply. \"git am\" knows the patch after the fixed-up\n one is D and then E; it applies them, and you will get the\n changes from A-C-D-E commits on top of U, in this order.\n \n I've been using this without noticing any problem, and as people\n may know I do a lot of rebases.\n \n Signed-off-by: Junio C Hamano \n"},{"id":"17920","messageId":"Pine.LNX.4.63.0603251034550.14457@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"3716","inReplyTo":"7v1wwrys07.fsf@assigned-by-dhcp.cox.net","subject":"Re: Effective difference between git-rebase and git-resolve","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-03-25T09:37:09Z","receivedAt":"2006-03-25T09:37:09Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 24 Mar 2006, Junio C Hamano wrote:\n\n> If nobody in the upper echelon of kernel people (meaning, longest-time \n> git users) use git-resolve anymore, I think we should mark it deprecated \n> and remove it eventually.\n\nI am nowhere near kernel people, but I am using git on a machine where it \nis too cumbersome to install python. If git-resolve goes, I am without a \nmerge strategy (at least until git-recursive is ported to C... was that \nnot the plan with git-merge-tree? What happened on that front?).\n\nCiao,\nDscho\n"},{"id":"17932","messageId":"slrne2a94r.cp6.mdw@metalzone.distorted.org.uk","threadId":"3716","inReplyTo":"Pine.LNX.4.63.0603251034550.14457@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Effective difference between git-rebase and git-resolve","fromName":"Mark Wooding","fromEmail":"mdw@distorted.org.uk","sentAt":"2006-03-25T11:08:11Z","receivedAt":"2006-03-25T11:08:11Z","isPatch":false,"sender":{"key":"mdw@distorted.org.uk","avatar":null},"body":"Johannes Schindelin wrote:\n> I am nowhere near kernel people, but I am using git on a machine where it \n> is too cumbersome to install python. If git-resolve goes, I am without a \n> merge strategy (at least until git-recursive is ported to C... was that \n> not the plan with git-merge-tree? What happened on that front?).\n\nErr... git-resolve isn't the same as git-merge-resolve. The latter is a\nstupid merge strategy which fits into the git-merge/git-pull\ninfrastructure. The former is a different program which does merges\nbadly, and you didn't want to use it even if you don't have Python!\n\nI'd forgotten all about git-resolve until it got mentioned just now.\n\n-- [mdw]\n"},{"id":"17933","messageId":"Pine.LNX.4.63.0603251226040.15524@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"3716","inReplyTo":"slrne2a94r.cp6.mdw@metalzone.distorted.org.uk","subject":"Re: Effective difference between git-rebase and git-resolve","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-03-25T11:26:30Z","receivedAt":"2006-03-25T11:26:30Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 25 Mar 2006, Mark Wooding wrote:\n\n> Johannes Schindelin wrote:\n> > I am nowhere near kernel people, but I am using git on a machine where it \n> > is too cumbersome to install python. If git-resolve goes, I am without a \n> > merge strategy (at least until git-recursive is ported to C... was that \n> > not the plan with git-merge-tree? What happened on that front?).\n> \n> Err... git-resolve isn't the same as git-merge-resolve.\n\nOooops.\n\nThank you,\nDscho\n"},{"id":"18007","messageId":"20060326202927.GA6436@fieldses.org","threadId":"3716","inReplyTo":"7vacbfxadu.fsf@assigned-by-dhcp.cox.net","subject":"Re: Effective difference between git-rebase and git-resolve","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2006-03-26T20:29:28Z","receivedAt":"2006-03-26T20:29:28Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Fri, Mar 24, 2006 at 11:15:57PM -0800, Junio C Hamano wrote:\n> - Patch C does not apply. git-am stops here, with conflicts to\n> be resolved in the working tree. Yet-to-be-applied D and E\n> are still kept in .dotest/ directory at this point. What the\n> user does is exactly the same as fixing up unapplicable patch\n> when running git-am:\n> \n> - Resolve conflict just like any merge conflicts.\n> - \"git am --resolved --3way\" to continue applying the patches.\n\nSo, does this sum it up accurately for the man page?\n\n--b.\n\nDocument git-rebase behavior on conflicts.\n\n---\n\n Documentation/git-rebase.txt | 12 ++++++++++++\n 1 files changed, 12 insertions(+), 0 deletions(-)\n\n3ef0c8cc7a505f9023a87e7e1ca22251a91bf188\ndiff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt\nindex b36276c..4a7e67a 100644\n--- a/Documentation/git-rebase.txt\n+++ b/Documentation/git-rebase.txt\n@@ -48,6 +48,18 @@ would be:\n /\n D---E---F---G master\n \n+In case of conflict, git-rebase will stop at the first problematic commit\n+and leave conflict markers in the tree. After resolving the conflict manually\n+and updating the index with the desired resolution, you can continue the\n+rebasing process with\n+\n+ git am --resolved --3way\n+\n+Alternatively, you can undo the git-rebase with\n+\n+ git reset --hard ORIG_HEAD\n+ rm -r .dotest\n+\n OPTIONS\n -------\n ::\n-- \n1.2.4.g0382\n"}]}