{"thread":{"id":"25561","subject":"Why the default action for pull is merge, but not rebase?","startedAt":"2010-10-27T16:46:00Z","lastAt":"2010-10-28T07:27:29Z","messageCount":13,"participants":["Eugene Sajine","Jonathan Nieder","Eric Raible","Joshua Jensen","Kevin Ballard","Björn Steinbrink","Stefan Haller"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"154552","messageId":"AANLkTinLbaE6He-bxA_+CT6J5uWmZSgodGs6SXO7eqnr@mail.gmail.com","threadId":"25561","inReplyTo":null,"subject":"Why the default action for pull is merge, but not rebase?","fromName":"Eugene Sajine","fromEmail":"euguess@gmail.com","sentAt":"2010-10-27T16:46:00Z","receivedAt":"2010-10-27T16:46:00Z","isPatch":false,"sender":{"key":"euguess@gmail.com","avatar":null},"body":"Hi,\n\nI'm just curious if there are some downsides that i don't see?\nFor me it seems to have much more sense to automatically rebase vs\nmerge when you do pull. The diverged history will become \"straighter\"\nand cleaner, if the history is not diverged then it will be\nfast-forward. So, why not to rebase?\n\nThanks for your time in advance,\n\nEugene\n"},{"id":"154553","messageId":"20101027165723.GC11069@burratino","threadId":"25561","inReplyTo":"AANLkTinLbaE6He-bxA_+CT6J5uWmZSgodGs6SXO7eqnr@mail.gmail.com","subject":"Re: Why the default action for pull is merge, but not rebase?","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-10-27T16:57:24Z","receivedAt":"2010-10-27T16:57:24Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Eugene Sajine wrote:\n\n> So, why not to rebase?\n\nAn interesting question.\n\nRebasing results in untested commits. If this is a patch series\nfor submission, that's fine, because you will be extensively\ntesting each patch anyway or indicating to reviewers that that\nneeds to be done (right?). But if it's a long-lived branch then\nsuch repeated testing work can be a serious hassle.\nhttps://git.wiki.kernel.org/index.php/GitFaq#What_is_the_difference_between_a_merge_and_a_rebase.3F\n\nA public branch that is regularly rebased is hard to follow\n(\"git log foo@{1}..foo\") and build on.\nhttp://www.kernel.org/pub/software/scm/git/docs/git-rebase.html#_recovering_from_upstream_rebase\n\nCode consumers often want clean history, but that really means\n(a) clean and (b) history.\nhttp://thread.gmane.org/gmane.comp.video.dri.devel/34739/focus=34744\n\nHope that helps.\n"},{"id":"154557","messageId":"AANLkTimoSH2C4dBDDN1KMaFAp_nwAtLy5_uNFfiuz5GR@mail.gmail.com","threadId":"25561","inReplyTo":"20101027165723.GC11069@burratino","subject":"Re: Why the default action for pull is merge, but not rebase?","fromName":"Eugene Sajine","fromEmail":"euguess@gmail.com","sentAt":"2010-10-27T17:21:18Z","receivedAt":"2010-10-27T17:21:18Z","isPatch":false,"sender":{"key":"euguess@gmail.com","avatar":null},"body":"On Wed, Oct 27, 2010 at 12:57 PM, Jonathan Nieder wrote:\n> Eugene Sajine wrote:\n>\n>>               So, why not to rebase?\n>\n> An interesting question.\n>\n> Rebasing results in untested commits.  If this is a patch series\n> for submission, that's fine, because you will be extensively\n> testing each patch anyway or indicating to reviewers that that\n> needs to be done (right?).  But if it's a long-lived branch then\n> such repeated testing work can be a serious hassle.\n> https://git.wiki.kernel.org/index.php/GitFaq#What_is_the_difference_between_a_merge_and_a_rebase.3F\n>\n> A public branch that is regularly rebased is hard to follow\n> (\"git log foo@{1}..foo\") and build on.\n> http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html#_recovering_from_upstream_rebase\n>\n> Code consumers often want clean history, but that really means\n> (a) clean and (b) history.\n> http://thread.gmane.org/gmane.comp.video.dri.devel/34739/focus=34744\n>\n> Hope that helps.\n>\n\nThanks for prompt answer. But let me clarify:\n\nWhen you do pull git performs:\n\nfetch of the remote branch to the FETCH_HEAD\nand then merge of FETCH_HEAD into the local branch\n\nWhat I'm saying is that your local branch should be rebased on top of\nFETCH_HEAD instead\n\nIn this case there is no such thing as \"often rebased public branch\".\n\nif the history got diverged then pull will result in new state that\nshould be tested anyway, so why not to rebase local branch on top of\nthe upstream instead of merging upstream into local branch?\n\ni'm not saying to rebase the upstream published branch on top of the\nlocal changes - that's NO-NO I'm aware of\n\nthanks,\nEugene\n"},{"id":"154560","messageId":"20101027173644.GB15657@burratino","threadId":"25561","inReplyTo":"AANLkTimoSH2C4dBDDN1KMaFAp_nwAtLy5_uNFfiuz5GR@mail.gmail.com","subject":"Re: Why the default action for pull is merge, but not rebase?","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-10-27T17:36:44Z","receivedAt":"2010-10-27T17:36:44Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Eugene Sajine wrote:\n\n> Thanks for prompt answer. But let me clarify:\n>\n> When you do pull git performs:\n>\n> fetch of the remote branch to the FETCH_HEAD\n> and then merge of FETCH_HEAD into the local branch\n>\n> What I'm saying is that your local branch should be rebased on top of\n> FETCH_HEAD instead\n> \n> In this case there is no such thing as \"often rebased public branch\".\n\nAh, but there is.\n\nImagine you are Junio and just received a pull request from Pat.\nThen you might try:\n\n $ git pull pat for-junio\n\nwhich will do all the fetching and merging magic that \"git pull\"\nis known for. Now if pat's for-junio branch is based on the tip\nof your current branch, this will be a fast-forward and it doesn't\nmatter whether you merge or rebase. But what if there are some\nintervening commits?\n\n $ git pull eric for-junio\n $ git pull pat for-junio\n\nIf this pull were the rebasing kind, the result would be for Eric's\ncommits to be rewritten based on Pat's.\n"},{"id":"154561","messageId":"AANLkTinDaYr8fsZiit4VYH-vptO7LtwRggkFGLKMnAhY@mail.gmail.com","threadId":"25561","inReplyTo":"0016e645b8c87a160804939cdc5e@google.com","subject":"Re: Re: Why the default action for pull is merge, but not rebase?","fromName":"Eugene Sajine","fromEmail":"euguess@gmail.com","sentAt":"2010-10-27T17:58:45Z","receivedAt":"2010-10-27T17:58:45Z","isPatch":false,"sender":{"key":"euguess@gmail.com","avatar":null},"body":"On Wed, Oct 27, 2010 at 1:50 PM, wrote:\n> On Oct 27, 2010 1:36pm, Jonathan Nieder wrote:\n>> Eugene Sajine wrote:\n>>\n>>\n>>\n>> > Thanks for prompt answer. But let me clarify:\n>>\n>> >\n>>\n>> > When you do pull git performs:\n>>\n>> >\n>>\n>> > fetch of the remote branch to the FETCH_HEAD\n>>\n>> > and then merge of FETCH_HEAD into the local branch\n>>\n>> >\n>>\n>> > What I'm saying is that your local branch should be rebased on top of\n>>\n>> > FETCH_HEAD instead\n>>\n>> >\n>>\n>> > In this case there is no such thing as \"often rebased public branch\".\n>>\n>>\n>>\n>> Ah, but there is.\n>>\n>>\n>>\n>> Imagine you are Junio and just received a pull request from Pat.\n>>\n>> Then you might try:\n>>\n>>\n>>\n>>  $ git pull pat for-junio\n>>\n>>\n>>\n>> which will do all the fetching and merging magic that \"git pull\"\n>>\n>> is known for.  Now if pat's for-junio branch is based on the tip\n>>\n>> of your current branch, this will be a fast-forward and it doesn't\n>>\n>> matter whether you merge or rebase.  But what if there are some\n>>\n>> intervening commits?\n>>\n>>\n>>\n>>  $ git pull eric for-junio\n>>\n>>  $ git pull pat for-junio\n>>\n>>\n>>\n>> If this pull were the rebasing kind, the result would be for Eric's\n>>\n>> commits to be rewritten based on Pat's.\n>>\n>\n> Oh, I see. In this case you're right.\n> My scenario is probably making more sense for the \"centralized approach\",\n> where the exchange goes via some blessed bare repo on the server.\n> So, I just have to run git pull --rebase to get my scenario working, right?\n>\n>\n> Thanks!\n> Eugene\n\nActually it seems that it will not work as i would expect...\ngit pull --rebase is going to rebase the upstream on top of my local\nbranch, right? Is this really intended behavior? Shouldn't it rebase\nmy local on top of the upstream instead?\n\nThanks,\nEugene\n"},{"id":"154563","messageId":"20101027180541.GA20527@burratino","threadId":"25561","inReplyTo":"0016e645b8c87a160804939cdc5e@google.com","subject":"Re: Re: Why the default action for pull is merge, but not rebase?","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-10-27T18:05:41Z","receivedAt":"2010-10-27T18:05:41Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Eugene Sajine wrote:\n\n> So, I just have to run git pull --rebase to get my scenario working, right?\n\nMaybe the “[branch \"\"] rebase” and “[branch] autosetuprebase”\nconfiguration items could help.\n"},{"id":"154570","messageId":"4CC87DE6.9090604@nextest.com","threadId":"25561","inReplyTo":"20101027180541.GA20527@burratino","subject":"Re: Re: Re: Why the default action for pull is merge, but not rebase?","fromName":"Eric Raible","fromEmail":"raible@nextest.com","sentAt":"2010-10-27T19:30:46Z","receivedAt":"2010-10-27T19:30:46Z","isPatch":false,"sender":{"key":"raible@nextest.com","avatar":null},"body":"On 11:59 AM, Jonathan Nieder wrote:\n> Eugene Sajine wrote:\n> \n>> So, I just have to run git pull --rebase to get my scenario working, right?\n> \n> Maybe the “[branch \"\"] rebase” and “[branch] autosetuprebase”\n> configuration items could help.\n\nOne frustrating aspect of branch..rebase is that AFAIK\nthere's no way for it to preserve merges.\n\nI would much prefer if branch..rebase was allowed to\nspecify the arguments to be passed to rebase:\n\n\tgit config branch.mybranch.rebase \"-i --preserve-merges\"\n\nAnyone else see the value of something like this?\n"},{"id":"154606","messageId":"4CC8E5B5.7050404@workspacewhiz.com","threadId":"25561","inReplyTo":"4CC87DE6.9090604@nextest.com","subject":"Re: Why the default action for pull is merge, but not rebase?","fromName":"Joshua Jensen","fromEmail":"jjensen@workspacewhiz.com","sentAt":"2010-10-28T02:53:41Z","receivedAt":"2010-10-28T02:53:41Z","isPatch":false,"sender":{"key":"jjensen@workspacewhiz.com","avatar":"https://avatars.githubusercontent.com/u/111687?v=4"},"body":"----- Original Message -----\nFrom: Eric Raible\nDate: 10/27/2010 1:30 PM\n> One frustrating aspect of branch..rebase is that AFAIK\n> there's no way for it to preserve merges.\n>\n> I would much prefer if branch..rebase was allowed to\n> specify the arguments to be passed to rebase:\n>\n> \tgit config branch.mybranch.rebase \"-i --preserve-merges\"\n>\n> Anyone else see the value of something like this?\nWhen --preserve-merges actually preserves the merges (perhaps the \nrebase-i-p branch is on the way to finishing this feature?? I couldn't \nget it to apply...), I would like this facility very much. By default, \nI think rebase *should* preserve merges, and the current flattening it \ndoes now should be an option.\n\nJosh\n"},{"id":"154609","messageId":"78EBA946-B3BA-458B-9528-C5F80872B3E0@sb.org","threadId":"25561","inReplyTo":"4CC8E5B5.7050404@workspacewhiz.com","subject":"Re: Why the default action for pull is merge, but not rebase?","fromName":"Kevin Ballard","fromEmail":"kevin@sb.org","sentAt":"2010-10-28T03:27:12Z","receivedAt":"2010-10-28T03:27:12Z","isPatch":false,"sender":{"key":"kevin@sb.org","avatar":"https://avatars.githubusercontent.com/u/714?v=4"},"body":"On Oct 27, 2010, at 7:53 PM, Joshua Jensen wrote:\n\n> ----- Original Message -----\n> From: Eric Raible\n> Date: 10/27/2010 1:30 PM\n>> One frustrating aspect of branch..rebase is that AFAIK\n>> there's no way for it to preserve merges.\n>> \n>> I would much prefer if branch..rebase was allowed to\n>> specify the arguments to be passed to rebase:\n>> \n>> \tgit config branch.mybranch.rebase \"-i --preserve-merges\"\n>> \n>> Anyone else see the value of something like this?\n> When --preserve-merges actually preserves the merges (perhaps the rebase-i-p branch is on the way to finishing this feature?? I couldn't get it to apply...), I would like this facility very much. By default, I think rebase *should* preserve merges, and the current flattening it does now should be an option.\n\nSure would be nice, but that sort of backwards-incompatible change would likely break a lot of people who rely on the current flattening behavior.\n\n-Kevin Ballard"},{"id":"154610","messageId":"20101028061707.GB3009@atjola.homenet","threadId":"25561","inReplyTo":"AANLkTimoSH2C4dBDDN1KMaFAp_nwAtLy5_uNFfiuz5GR@mail.gmail.com","subject":"Re: Why the default action for pull is merge, but not rebase?","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2010-10-28T06:17:07Z","receivedAt":"2010-10-28T06:17:07Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2010.10.27 13:21:18 -0400, Eugene Sajine wrote:\n> On Wed, Oct 27, 2010 at 12:57 PM, Jonathan Nieder wrote:\n> > Eugene Sajine wrote:\n> >\n> >>               So, why not to rebase?\n> >\n> > An interesting question.\n> >\n> > Rebasing results in untested commits.  If this is a patch series\n> > for submission, that's fine, because you will be extensively\n> > testing each patch anyway or indicating to reviewers that that\n> > needs to be done (right?).  But if it's a long-lived branch then\n> > such repeated testing work can be a serious hassle.\n> > https://git.wiki.kernel.org/index.php/GitFaq#What_is_the_difference_between_a_merge_and_a_rebase.3F\n> >\n> > A public branch that is regularly rebased is hard to follow\n> > (\"git log foo@{1}..foo\") and build on.\n> > http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html#_recovering_from_upstream_rebase\n> >\n> > Code consumers often want clean history, but that really means\n> > (a) clean and (b) history.\n> > http://thread.gmane.org/gmane.comp.video.dri.devel/34739/focus=34744\n> \n> Thanks for prompt answer. But let me clarify:\n> \n> When you do pull git performs:\n> \n> fetch of the remote branch to the FETCH_HEAD\n> and then merge of FETCH_HEAD into the local branch\n> \n> What I'm saying is that your local branch should be rebased on top of\n> FETCH_HEAD instead\n> \n> In this case there is no such thing as \"often rebased public branch\".\n\nHow do you know? Right before the pull, you could have run push, so you\nwould be rebasing a public branch.\n\n> if the history got diverged then pull will result in new state that\n> should be tested anyway, so why not to rebase local branch on top of\n> the upstream instead of merging upstream into local branch?\n\nMerging results in either 0 (fast-forward) or 1 (mege) new commit,\nrebase results in 0-N new commits.\n\nLet's say you have this history:\n\nA---B---C (master)\n \\\n D---E---F (topic)\n\nIf you merge topic to master, you get:\n\nA---B---C---M (master)\n \\ /\n D---E---F (topic)\n\nSo there's one new commit to test.\n\nIf you instead rebase topic onto master, you get:\n\n D'--E'--F' (topic)\n /\nA---B---C (master)\n \\\n D---E---F\n\nSo there are three new commits, all untested. And it's not enough to\ntest just F'. Even if that is ok, D' and E' might still be broken.\n\nSimple example:\n - In A there was a function \"int foo(int a)\".\n - In D you added a call to that function.\n - In F you removed that call.\n - B changed the function signature to \"int foo(int a, int b)\"\n\nThe new F' commit will be fine, as there is no call to that function.\nBut D' and E' are broken as they still contains the call to foo with\njust one argument.\n\nHTH\nBjörn\n"},{"id":"154612","messageId":"4CC91AA6.2000301@nextest.com","threadId":"25561","inReplyTo":"78EBA946-B3BA-458B-9528-C5F80872B3E0@sb.org","subject":"Re: Why the default action for pull is merge, but not rebase?","fromName":"Eric Raible","fromEmail":"raible@nextest.com","sentAt":"2010-10-28T06:39:34Z","receivedAt":"2010-10-28T06:39:34Z","isPatch":false,"sender":{"key":"raible@nextest.com","avatar":null},"body":"On 10/27/2010 8:27 PM, Kevin Ballard wrote:\n> On Oct 27, 2010, at 7:53 PM, Joshua Jensen wrote:\n> \n>> ----- Original Message -----\n>> From: Eric Raible\n>> Date: 10/27/2010 1:30 PM\n>>>\n>>> I would much prefer if branch..rebase was allowed to\n>>> specify the arguments to be passed to rebase:\n>>>\n>>> \tgit config branch.mybranch.rebase \"-i --preserve-merges\"\n>>>\n>>> Anyone else see the value of something like this?\n>> When --preserve-merges actually preserves the merges (perhaps the rebase-i-p branch is on the way to finishing this feature?? I couldn't get it to apply...), I would like this facility very much. By default, I think rebase *should* preserve merges, and the current flattening it does now should be an option.\n> \n> Sure would be nice, but that sort of backwards-incompatible change would likely break a lot of people who rely on the current flattening behavior.\n> \n> -Kevin Ballard.\n\nBut it's not backwards incompatible: only true/false are now\nallowed so an arbitrary string would not currently be used.\n\nIn my proposal a string would imply true, and would mean\n\"append the specified value when running rebase\".\n"},{"id":"154613","messageId":"3DEE5D82-AC23-45AD-B02D-DA3D6998CABC@sb.org","threadId":"25561","inReplyTo":"4CC91AA6.2000301@nextest.com","subject":"Re: Why the default action for pull is merge, but not rebase?","fromName":"Kevin Ballard","fromEmail":"kevin@sb.org","sentAt":"2010-10-28T07:13:55Z","receivedAt":"2010-10-28T07:13:55Z","isPatch":false,"sender":{"key":"kevin@sb.org","avatar":"https://avatars.githubusercontent.com/u/714?v=4"},"body":"On Oct 27, 2010, at 11:39 PM, Eric Raible wrote:\n\n> On 10/27/2010 8:27 PM, Kevin Ballard wrote:\n>> On Oct 27, 2010, at 7:53 PM, Joshua Jensen wrote:\n>> \n>>> ----- Original Message -----\n>>> From: Eric Raible\n>>> Date: 10/27/2010 1:30 PM\n>>>> \n>>>> I would much prefer if branch..rebase was allowed to\n>>>> specify the arguments to be passed to rebase:\n>>>> \n>>>> \tgit config branch.mybranch.rebase \"-i --preserve-merges\"\n>>>> \n>>>> Anyone else see the value of something like this?\n>>> When --preserve-merges actually preserves the merges (perhaps the rebase-i-p branch is on the way to finishing this feature?? I couldn't get it to apply...), I would like this facility very much. By default, I think rebase *should* preserve merges, and the current flattening it does now should be an option.\n>> \n>> Sure would be nice, but that sort of backwards-incompatible change would likely break a lot of people who rely on the current flattening behavior.\n>> \n>> -Kevin Ballard.\n> \n> But it's not backwards incompatible: only true/false are now\n> allowed so an arbitrary string would not currently be used.\n> \n> In my proposal a string would imply true, and would mean\n> \"append the specified value when running rebase\".\n\nSorry, I meant making it the default would be a backwards-incompatible change.\n\n-Kevin Ballard"},{"id":"154614","messageId":"1jr2fbt.1sik9wjkrc2tpM%lists@haller-berlin.de","threadId":"25561","inReplyTo":"4CC87DE6.9090604@nextest.com","subject":"Re: Why the default action for pull is merge, but not rebase?","fromName":"Stefan Haller","fromEmail":"lists@haller-berlin.de","sentAt":"2010-10-28T07:27:29Z","receivedAt":"2010-10-28T07:27:29Z","isPatch":false,"sender":{"key":"lists@haller-berlin.de","avatar":null},"body":"Eric Raible wrote:\n\n> On 11:59 AM, Jonathan Nieder wrote:\n>\n> > Maybe the \"[branch \"\"] rebase\" and \"[branch] autosetuprebase\"\n> > configuration items could help.\n> \n> One frustrating aspect of branch..rebase is that AFAIK\n> there's no way for it to preserve merges.\n> \n> I would much prefer if branch..rebase was allowed to\n> specify the arguments to be passed to rebase:\n> \n> git config branch.mybranch.rebase \"-i --preserve-merges\"\n\nFor me it would be good enough if there were some way of making\n\"pull --rebase\" error out in the case that merges are involved. I'll\nthen either do a pull --no-rebase, or deal with the situation in some\nother way; but getting the merge \"flattened\" by \"git pull\" without being\ntold about it is what's frustrating to me.\n\n\n-- \nStefan Haller\nBerlin, Germany\nhttp://www.haller-berlin.de/\n"}]}