{"thread":{"id":"10466","subject":"[PATCH] Teach 'git pull' the '--rebase' option","startedAt":"2007-10-25T22:54:01Z","lastAt":"2007-12-03T13:10:21Z","messageCount":32,"participants":["Johannes Schindelin","Linus Torvalds","Junio C Hamano","Jeff King","Jonathan del Strother","Jakub Narebski","Steven Grimm","Lars Hjemli","Jon Loeliger","J. Bruce Fields","Nicolas Pitre","Andreas Ericsson","Björn Steinbrink","Karl Hasselström"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"57246","messageId":"Pine.LNX.4.64.0710252351130.4362@racer.site","threadId":"10466","inReplyTo":null,"subject":"[PATCH] Teach 'git pull' the '--rebase' option","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-25T22:54:01Z","receivedAt":"2007-10-25T22:54:01Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"\nWhen calling 'git pull' with the '--rebase' option, it performs a\nfetch + rebase instead of a fetch + pull.\n\nThis behavior is more desirable than fetch + pull when a topic branch\nis ready to be submitted.\n\nfetch + rebase might also be considered a better workflow with shared\nrepositories in any case, or for contributors to a centrally managed\nproject, such as Wine -- or Git.\n\nFor your convenience, you can set the default behavior for a branch by\ndefining the config variable branch..rebase, which is\ninterpreted as a bool. This setting can be overridden on the command\nline by --rebase and --no-rebase.\n\nSigned-off-by: Johannes Schindelin \n---\n Documentation/git-pull.txt | 6 ++++++\n git-pull.sh | 11 ++++++++++-\n t/t5520-pull.sh | 22 ++++++++++++++++++++++\n 3 files changed, 38 insertions(+), 1 deletions(-)\n\ndiff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt\nindex e1eb2c1..c3ce8ee 100644\n--- a/Documentation/git-pull.txt\n+++ b/Documentation/git-pull.txt\n@@ -33,6 +33,12 @@ include::urls-remotes.txt[]\n \n include::merge-strategies.txt[]\n \n+\\--rebase::\n+\tInstead of a merge, perform a rebase after fetching.\n+\n+\\--no-rebase::\n+\tOverride earlier \\--rebase.\n+\n DEFAULT BEHAVIOUR\n -----------------\n \ndiff --git a/git-pull.sh b/git-pull.sh\nindex 74bfc16..b5ecb80 100755\n--- a/git-pull.sh\n+++ b/git-pull.sh\n@@ -16,6 +16,9 @@ test -z \"$(git ls-files -u)\" ||\n \tdie \"You are in the middle of a conflicted merge.\"\n \n strategy_args= no_summary= no_commit= squash=\n+curr_branch=$(git symbolic-ref -q HEAD)\n+curr_branch_short=$(echo \"$curr_branch\" | sed \"s|refs/heads/||\")\n+rebase=$(git config --bool branch.$curr_branch_short.rebase)\n while :\n do\n \tcase \"$1\" in\n@@ -43,6 +46,12 @@ do\n \t\tesac\n \t\tstrategy_args=\"${strategy_args}-s $strategy \"\n \t\t;;\n+\t-r|--r|--re|--reb|--reba|--rebas|--rebase)\n+\t\trebase=true\n+\t\t;;\n+\t--no-r|--no-re|--no-reb|--no-reba|--no-rebas|--no-rebase)\n+\t\trebase=false\n+\t\t;;\n \t-h|--h|--he|--hel|--help)\n \t\tusage\n \t\t;;\n@@ -86,7 +95,6 @@ merge_head=$(sed -e '/\tnot-for-merge\t/d' \\\n \n case \"$merge_head\" in\n '')\n-\tcurr_branch=$(git symbolic-ref -q HEAD)\n \tcase $? in\n \t 0) ;;\n \t 1) echo >&2 \"You are not currently on a branch; you must explicitly\"\n@@ -133,5 +141,6 @@ then\n fi\n \n merge_name=$(git fmt-merge-msg <\"$GIT_DIR/FETCH_HEAD\") || exit\n+test true = \"$rebase\" && exec git-rebase $merge_head\n exec git-merge $no_summary $no_commit $squash $strategy_args \\\n \t\"$merge_name\" HEAD $merge_head\ndiff --git a/t/t5520-pull.sh b/t/t5520-pull.sh\nindex 93eaf2c..52b3a0c 100755\n--- a/t/t5520-pull.sh\n+++ b/t/t5520-pull.sh\n@@ -53,4 +53,26 @@ test_expect_success 'the default remote . should not break explicit pull' '\n \ttest `cat file` = modified\n '\n \n+test_expect_success '--rebase' '\n+\tgit branch to-rebase &&\n+\techo modified again > file &&\n+\tgit commit -m file file &&\n+\tgit checkout to-rebase &&\n+\techo new > file2 &&\n+\tgit add file2 &&\n+\tgit commit -m \"new file\" &&\n+\tgit tag before-rebase &&\n+\tgit pull --rebase . copy &&\n+\ttest $(git rev-parse HEAD^) = $(git rev-parse copy) &&\n+\ttest new = $(git show HEAD:file2)\n+'\n+\n+test_expect_success 'branch.to-rebase.rebase' '\n+\tgit reset --hard before-rebase &&\n+\tgit config branch.to-rebase.rebase 1 &&\n+\tgit pull . copy &&\n+\ttest $(git rev-parse HEAD^) = $(git rev-parse copy) &&\n+\ttest new = $(git show HEAD:file2)\n+'\n+\n test_done\n-- \n1.5.3.4.1351.gee906\n"},{"id":"57247","messageId":"alpine.LFD.0.999.0710251602160.30120@woody.linux-foundation.org","threadId":"10466","inReplyTo":"Pine.LNX.4.64.0710252351130.4362@racer.site","subject":"Re: [PATCH] Teach 'git pull' the '--rebase' option","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-10-25T23:04:29Z","receivedAt":"2007-10-25T23:04:29Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 25 Oct 2007, Johannes Schindelin wrote:\n> \n> This behavior is more desirable than fetch + pull when a topic branch\n> is ready to be submitted.\n\nI'd like there to be some *big*warning* about how this destroys history \nand how you must not do this if you expose your history anywhere else.\n\nI think it's a perfectly fine history, but if you have already pushed out \nyour history somewhere else, you're now really screwed. In ways that a \n*real* merge will never screw you.\n\nSo the \"--rebase\" option really is only good for the lowest-level \ndevelopers. And that should be documented.\n\n\t\tLinus\n"},{"id":"57248","messageId":"Pine.LNX.4.64.0710260007450.4362@racer.site","threadId":"10466","inReplyTo":"alpine.LFD.0.999.0710251602160.30120@woody.linux-foundation.org","subject":"Re: [PATCH] Teach 'git pull' the '--rebase' option","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-25T23:10:08Z","receivedAt":"2007-10-25T23:10:08Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 25 Oct 2007, Linus Torvalds wrote:\n\n> On Thu, 25 Oct 2007, Johannes Schindelin wrote:\n> > \n> > This behavior is more desirable than fetch + pull when a topic branch\n> > is ready to be submitted.\n> \n> I'd like there to be some *big*warning* about how this destroys history \n> and how you must not do this if you expose your history anywhere else.\n> \n> I think it's a perfectly fine history, but if you have already pushed out \n> your history somewhere else, you're now really screwed. In ways that a \n> *real* merge will never screw you.\n> \n> So the \"--rebase\" option really is only good for the lowest-level \n> developers. And that should be documented.\n\nFair enough.\n\nHow about this in the man page:\n\n\\--rebase::\n\tInstead of a merge, perform a rebase after fetching.\n\t*NOTE:* Never do this on branches you plan to publish! This\n\tcommand will _destroy_ history, and is thus only suitable for\n\ttopic branches to be submitted to another committer.\n\nCiao,\nDscho\n"},{"id":"57249","messageId":"alpine.LFD.0.999.0710251634200.30120@woody.linux-foundation.org","threadId":"10466","inReplyTo":"Pine.LNX.4.64.0710260007450.4362@racer.site","subject":"Re: [PATCH] Teach 'git pull' the '--rebase' option","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-10-25T23:36:24Z","receivedAt":"2007-10-25T23:36:24Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 26 Oct 2007, Johannes Schindelin wrote:\n> \n> \\--rebase::\n> \tInstead of a merge, perform a rebase after fetching.\n> \t*NOTE:* Never do this on branches you plan to publish! This\n> \tcommand will _destroy_ history, and is thus only suitable for\n> \ttopic branches to be submitted to another committer.\n\nWell, it really needs explanation of what \"destroy\" means. \n\nAlso, it's not strictly even necessary to publish things for this to cause \nproblems. It's perfectly sufficient to just do development on two private \ndeveloper machines, and do things like keeping the two machines in sync by \npulling things between them manually...\n\nSo even \"normal\" developers who never publish a git tree to others may \nactually hit this issue.\n\n\t\t\tLinus\n"},{"id":"57250","messageId":"alpine.LFD.0.999.0710251647420.30120@woody.linux-foundation.org","threadId":"10466","inReplyTo":"alpine.LFD.0.999.0710251634200.30120@woody.linux-foundation.org","subject":"Re: [PATCH] Teach 'git pull' the '--rebase' option","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-10-25T23:49:21Z","receivedAt":"2007-10-25T23:49:21Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 25 Oct 2007, Linus Torvalds wrote:\n\n> Also, it's not strictly even necessary to publish things for this to cause \n> problems. It's perfectly sufficient to just do development on two private \n> developer machines, and do things like keeping the two machines in sync by \n> pulling things between them manually...\n\n.. or any branch use, for that matter.\n\nI do agree that \"git merge --rebase\" is potentially convenient, I'm just \nnot sure it's a great idea to document as such. People shouldn't do it \nunless they really *really* understand the implications, and I think the \nimplications are much easier to understand if you instead teach them \n\"fetch+rebase\", and perhaps even keep the \"merge --rebase\" option entirely \nundocumented.\n\n\t\t\t\tLinus\n"},{"id":"57251","messageId":"7v3avy21il.fsf@gitster.siamese.dyndns.org","threadId":"10466","inReplyTo":"Pine.LNX.4.64.0710260007450.4362@racer.site","subject":"Re: [PATCH] Teach 'git pull' the '--rebase' option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-10-25T23:54:58Z","receivedAt":"2007-10-25T23:54:58Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> On Thu, 25 Oct 2007, Linus Torvalds wrote:\n>\n>> On Thu, 25 Oct 2007, Johannes Schindelin wrote:\n>> > \n>> > This behavior is more desirable than fetch + pull when a topic branch\n>> > is ready to be submitted.\n>> \n>> I'd like there to be some *big*warning* about how this destroys history \n>> and how you must not do this if you expose your history anywhere else.\n>> \n>> I think it's a perfectly fine history, but if you have already pushed out \n>> your history somewhere else, you're now really screwed. In ways that a \n>> *real* merge will never screw you.\n>> \n>> So the \"--rebase\" option really is only good for the lowest-level \n>> developers. And that should be documented.\n>\n> Fair enough.\n>\n> How about this in the man page:\n>\n> \\--rebase::\n> \tInstead of a merge, perform a rebase after fetching.\n> \t*NOTE:* Never do this on branches you plan to publish! This\n> \tcommand will _destroy_ history, and is thus only suitable for\n> \ttopic branches to be submitted to another committer.\n\nNits.\n\n(1) This \"operation\" will \"rewrite\" history.\n\n You are not describing a command, but just one mode of operation\n of a command, whose other modes of operation do not share this\n history altering behaviour.\n\n The history is rewritten and made hard to work with for others\n who have previous incarnation of that history. If it happens\n that nobody shared that previously published history nobody\n needs to suffer. In that sense, there is something _usable_\n depending on who you are. Destroy feels a bit too strong a\n word.\n\n(2) This is not suitable for people who publish their trees and\n let others fetch and work off of them.\n\n Rebase is fine for e-mail submitting contributors as your\n description above suggests, but as your proposed commit log\n message said, it is also perfectly appropriate if your\n interaction with the outside world is \"fetch + rebase +\n push\". You are not limited to \"submitted to another\n committer\".\n"},{"id":"57269","messageId":"Pine.LNX.4.64.0710261047450.4362@racer.site","threadId":"10466","inReplyTo":"7v3avy21il.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Teach 'git pull' the '--rebase' option","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-26T09:52:26Z","receivedAt":"2007-10-26T09:52:26Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 25 Oct 2007, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > On Thu, 25 Oct 2007, Linus Torvalds wrote:\n> >\n> >> On Thu, 25 Oct 2007, Johannes Schindelin wrote:\n> >> > \n> >> > This behavior is more desirable than fetch + pull when a topic \n> >> > branch is ready to be submitted.\n> >> \n> >> I'd like there to be some *big*warning* about how this destroys \n> >> history and how you must not do this if you expose your history \n> >> anywhere else.\n> >> \n> >> I think it's a perfectly fine history, but if you have already pushed \n> >> out your history somewhere else, you're now really screwed. In ways \n> >> that a *real* merge will never screw you.\n> >> \n> >> So the \"--rebase\" option really is only good for the lowest-level \n> >> developers. And that should be documented.\n> >\n> > Fair enough.\n> >\n> > How about this in the man page:\n> >\n> > \\--rebase::\n> > \tInstead of a merge, perform a rebase after fetching.\n> > \t*NOTE:* Never do this on branches you plan to publish! This\n> > \tcommand will _destroy_ history, and is thus only suitable for\n> > \ttopic branches to be submitted to another committer.\n> \n> Nits.\n> \n> (1) This \"operation\" will \"rewrite\" history.\n\nOkay.\n\n> (2) This is not suitable for people who publish their trees and\n> let others fetch and work off of them.\n> \n> Rebase is fine for e-mail submitting contributors as your\n> description above suggests, but as your proposed commit log\n> message said, it is also perfectly appropriate if your\n> interaction with the outside world is \"fetch + rebase +\n> push\". You are not limited to \"submitted to another\n> committer\".\n\nWell, originally I did not want to document it at all. But I already \nheard the complaints about that in my inner ear. So I documented it, \nsparsely, in the hope that those who do not know the implications will not \ndare to use it. After Linus' complaint, I tried to make this shooing away \nmore explicit.\n\nI do not want to go into _that_ many details here, since the place to look \nfor it is git-rebase.txt. Probably I should have done that in the first \nplace.\n\nSo how about this instead:\n\n\\--rebase::\n Instead of a merge, perform a rebase after fetching.\n *NOTE:* This is a potentially _dangerous_ mode of operation. \n\tIt rewrites history, which does not bode well when you\n\tpublished that history already. Do _not_ use this option\n\tunless you have\tread gitlink:git-rebase[1] carefully.\n\nHmm?\n\nCiao,\nDscho\n"},{"id":"57273","messageId":"20071026114331.GA2693@coredump.intra.peff.net","threadId":"10466","inReplyTo":"Pine.LNX.4.64.0710260007450.4362@racer.site","subject":"Re: [PATCH] Teach 'git pull' the '--rebase' option","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-10-26T11:43:32Z","receivedAt":"2007-10-26T11:43:32Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Oct 26, 2007 at 12:10:08AM +0100, Johannes Schindelin wrote:\n\n> Fair enough.\n> \n> How about this in the man page:\n> \n> \\--rebase::\n> \tInstead of a merge, perform a rebase after fetching.\n> \t*NOTE:* Never do this on branches you plan to publish! This\n> \tcommand will _destroy_ history, and is thus only suitable for\n> \ttopic branches to be submitted to another committer.\n\nReasonable, although perhaps it should mention what I suspect might be a\ncommon workflow for this feature: CVS emulation. I.e., there is a\ncentral repo, which is the only thing considered \"published\". Developers\nmake commits in their local repo, and then rebase their changes onto the\nHEAD before pushing. The only difference from CVS is that you don't\nactually get to commit in CVS, you have to do the rebase with your\nworking tree. :)\n\nI'm imagining a \"pull.rebase = 1\" config option, and handing this out to\ndevelopers accustomed to CVS.\n\n-Peff\n"},{"id":"57274","messageId":"20071026114518.GB2693@coredump.intra.peff.net","threadId":"10466","inReplyTo":"20071026114331.GA2693@coredump.intra.peff.net","subject":"Re: [PATCH] Teach 'git pull' the '--rebase' option","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-10-26T11:45:18Z","receivedAt":"2007-10-26T11:45:18Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Oct 26, 2007 at 07:43:32AM -0400, Jeff King wrote:\n\n> Reasonable, although perhaps it should mention what I suspect might be a\n> common workflow for this feature: CVS emulation. I.e., there is a\n> central repo, which is the only thing considered \"published\". Developers\n> make commits in their local repo, and then rebase their changes onto the\n> HEAD before pushing. The only difference from CVS is that you don't\n> actually get to commit in CVS, you have to do the rebase with your\n> working tree. :)\n\nActually, I think I've just restated Junio's comment somewhat, so the\nchange you made in response to him is an improvement. Sorry for the\nnoise.\n\n-Peff\n"},{"id":"61140","messageId":"7v3aurcjpq.fsf@gitster.siamese.dyndns.org","threadId":"10466","inReplyTo":"Pine.LNX.4.64.0710261047450.4362@racer.site","subject":"Re: [PATCH] Teach 'git pull' the '--rebase' option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-28T00:11:29Z","receivedAt":"2007-11-28T00:11:29Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> ...\n> I do not want to go into _that_ many details here, since the place to look \n> for it is git-rebase.txt. Probably I should have done that in the first \n> place.\n>\n> So how about this instead:\n>\n> \\--rebase::\n> Instead of a merge, perform a rebase after fetching.\n> *NOTE:* This is a potentially _dangerous_ mode of operation. \n> \tIt rewrites history, which does not bode well when you\n> \tpublished that history already. Do _not_ use this option\n> \tunless you have\tread gitlink:git-rebase[1] carefully.\n>\n> Hmm?\n\nOkay.\n"},{"id":"61179","messageId":"Pine.LNX.4.64.0711281307420.27959@racer.site","threadId":"10466","inReplyTo":"7v3aurcjpq.fsf@gitster.siamese.dyndns.org","subject":"[PATCH v2] Teach 'git pull' about --rebase","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-28T13:11:07Z","receivedAt":"2007-11-28T13:11:07Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"\nWhen calling 'git pull' with the '--rebase' option, it performs a\nfetch + rebase instead of a fetch + pull.\n\nThis behavior is more desirable than fetch + pull when a topic branch\nis ready to be submitted and needs to be update.\n\nfetch + rebase might also be considered a better workflow with shared\nrepositories in any case, or for contributors to a centrally managed\nrepository, such as WINE's.\n\nAs a convenience, you can set the default behavior for a branch by\ndefining the config variable branch..rebase, which is\ninterpreted as a bool. This setting can be overridden on the command\nline by --rebase and --no-rebase.\n\nSigned-off-by: Johannes Schindelin \n---\n\n\tOn Tue, 27 Nov 2007, Junio C Hamano wrote:\n\n\t> Johannes Schindelin writes:\n\t> \n\t> > ...\n\t> > I do not want to go into _that_ many details here, since the \n\t> > place to look for it is git-rebase.txt. Probably I should \n\t> > have done that in the first place.\n\t> >\n\t> > So how about this instead:\n\t> >\n\t> > \\--rebase::\n\t> > \tInstead of a merge, perform a rebase after fetching.\n\t> > \t*NOTE:* This is a potentially _dangerous_ mode of operation.\n\t> > \tIt rewrites history, which does not bode well when you\n\t> > \tpublished that history already. Do _not_ use this option\n\t> > \tunless you have\tread gitlink:git-rebase[1] carefully.\n\t> >\n\t> > Hmm?\n\t> \n\t> Okay.\n\n\tI also added documentation for the branch..rebase variable.\n\n Documentation/config.txt | 7 +++++++\n Documentation/git-pull.txt | 10 ++++++++++\n git-pull.sh | 11 ++++++++++-\n t/t5520-pull.sh | 22 ++++++++++++++++++++++\n 4 files changed, 49 insertions(+), 1 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 645514d..7bebc9a 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -360,6 +360,13 @@ branch..mergeoptions::\n \toption values containing whitespace characters are currently not\n \tsupported.\n \n+branch..rebase::\n+\tWhen true, rebase the branch on top of the fetched branch,\n+\tinstead of merging the default branch from the default remote.\n+\t*NOTE*: this is a possibly dangerous operation; do *not* use\n+\tit unless you understand the implications (see gitlink:git-rebase[1]\n+\tfor details).\n+\n clean.requireForce::\n \tA boolean to make git-clean do nothing unless given -f\n \tor -n. Defaults to true.\ndiff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt\nindex e1eb2c1..d4d26af 100644\n--- a/Documentation/git-pull.txt\n+++ b/Documentation/git-pull.txt\n@@ -33,6 +33,16 @@ include::urls-remotes.txt[]\n \n include::merge-strategies.txt[]\n \n+\\--rebase::\n+\tInstead of a merge, perform a rebase after fetching.\n+\t*NOTE:* This is a potentially _dangerous_ mode of operation.\n+\tIt rewrites history, which does not bode well when you\n+\tpublished that history already. Do *not* use this option\n+\tunless you have read gitlink:git-rebase[1] carefully.\n+\n+\\--no-rebase::\n+\tOverride earlier \\--rebase.\n+\n DEFAULT BEHAVIOUR\n -----------------\n \ndiff --git a/git-pull.sh b/git-pull.sh\nindex 30fdc57..698e82b 100755\n--- a/git-pull.sh\n+++ b/git-pull.sh\n@@ -17,6 +17,9 @@ test -z \"$(git ls-files -u)\" ||\n \tdie \"You are in the middle of a conflicted merge.\"\n \n strategy_args= no_summary= no_commit= squash= no_ff=\n+curr_branch=$(git symbolic-ref -q HEAD)\n+curr_branch_short=$(echo \"$curr_branch\" | sed \"s|refs/heads/||\")\n+rebase=$(git config --bool branch.$curr_branch_short.rebase)\n while :\n do\n \tcase \"$1\" in\n@@ -52,6 +55,12 @@ do\n \t\tesac\n \t\tstrategy_args=\"${strategy_args}-s $strategy \"\n \t\t;;\n+\t-r|--r|--re|--reb|--reba|--rebas|--rebase)\n+\t\trebase=true\n+\t\t;;\n+\t--no-r|--no-re|--no-reb|--no-reba|--no-rebas|--no-rebase)\n+\t\trebase=false\n+\t\t;;\n \t-h|--h|--he|--hel|--help)\n \t\tusage\n \t\t;;\n@@ -95,7 +104,6 @@ merge_head=$(sed -e '/\tnot-for-merge\t/d' \\\n \n case \"$merge_head\" in\n '')\n-\tcurr_branch=$(git symbolic-ref -q HEAD)\n \tcase $? in\n \t 0) ;;\n \t 1) echo >&2 \"You are not currently on a branch; you must explicitly\"\n@@ -142,5 +150,6 @@ then\n fi\n \n merge_name=$(git fmt-merge-msg <\"$GIT_DIR/FETCH_HEAD\") || exit\n+test true = \"$rebase\" && exec git-rebase $merge_head\n exec git-merge $no_summary $no_commit $squash $no_ff $strategy_args \\\n \t\"$merge_name\" HEAD $merge_head\ndiff --git a/t/t5520-pull.sh b/t/t5520-pull.sh\nindex 93eaf2c..52b3a0c 100755\n--- a/t/t5520-pull.sh\n+++ b/t/t5520-pull.sh\n@@ -53,4 +53,26 @@ test_expect_success 'the default remote . should not break explicit pull' '\n \ttest `cat file` = modified\n '\n \n+test_expect_success '--rebase' '\n+\tgit branch to-rebase &&\n+\techo modified again > file &&\n+\tgit commit -m file file &&\n+\tgit checkout to-rebase &&\n+\techo new > file2 &&\n+\tgit add file2 &&\n+\tgit commit -m \"new file\" &&\n+\tgit tag before-rebase &&\n+\tgit pull --rebase . copy &&\n+\ttest $(git rev-parse HEAD^) = $(git rev-parse copy) &&\n+\ttest new = $(git show HEAD:file2)\n+'\n+\n+test_expect_success 'branch.to-rebase.rebase' '\n+\tgit reset --hard before-rebase &&\n+\tgit config branch.to-rebase.rebase 1 &&\n+\tgit pull . copy &&\n+\ttest $(git rev-parse HEAD^) = $(git rev-parse copy) &&\n+\ttest new = $(git show HEAD:file2)\n+'\n+\n test_done\n-- \n1.5.3.6.2064.g4e322\n"},{"id":"61183","messageId":"D7B369D7-B690-4F5B-852F-4EC4B03CEB45@steelskies.com","threadId":"10466","inReplyTo":"Pine.LNX.4.64.0711281307420.27959@racer.site","subject":"Re: [PATCH v2] Teach 'git pull' about --rebase","fromName":"Jonathan del Strother","fromEmail":"maillist@steelskies.com","sentAt":"2007-11-28T13:15:10Z","receivedAt":"2007-11-28T13:15:10Z","isPatch":true,"sender":{"key":"jon.delstrother@bestbefore.tv","avatar":"https://gravatar.com/avatar/754e21ab701c00e2d21fc261187254c34b2a1c0b959d9ee5be1a295990be3081?d=mp&s=160"},"body":"On 28 Nov 2007, at 13:11, Johannes Schindelin wrote:\n\n> When calling 'git pull' with the '--rebase' option, it performs a\n> fetch + rebase instead of a fetch + pull.\n>\n> This behavior is more desirable than fetch + pull when a topic branch\n> is ready to be submitted and needs to be update.\n\nDon't you mean fetch + merge ?\n"},{"id":"61188","messageId":"fijptj$a47$1@ger.gmane.org","threadId":"10466","inReplyTo":"Pine.LNX.4.64.0711281307420.27959@racer.site","subject":"Re: [PATCH v2] Teach 'git pull' about --rebase","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-11-28T13:19:48Z","receivedAt":"2007-11-28T13:19:48Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Johannes Schindelin wrote:\n\n> @@ -52,6 +55,12 @@ do\n>                 esac\n>                 strategy_args=\"${strategy_args}-s $strategy \"\n>                 ;;\n> +       -r|--r|--re|--reb|--reba|--rebas|--rebase)\n> +               rebase=true\n> +               ;;\n> +       --no-r|--no-re|--no-reb|--no-reba|--no-rebas|--no-rebase)\n> +               rebase=false\n> +               ;;\n>         -h|--h|--he|--hel|--help)\n>                 usage\n>                 ;;\n\nHmmm... rebase doesn't use git-rev-parse --parseopt?\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"61199","messageId":"Pine.LNX.4.64.0711281401530.27959@racer.site","threadId":"10466","inReplyTo":"D7B369D7-B690-4F5B-852F-4EC4B03CEB45@steelskies.com","subject":"Re: [PATCH v2] Teach 'git pull' about --rebase","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-28T14:02:07Z","receivedAt":"2007-11-28T14:02:07Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 28 Nov 2007, Jonathan del Strother wrote:\n\n> On 28 Nov 2007, at 13:11, Johannes Schindelin wrote:\n> \n> > When calling 'git pull' with the '--rebase' option, it performs a\n> > fetch + rebase instead of a fetch + pull.\n> > \n> > This behavior is more desirable than fetch + pull when a topic branch\n> > is ready to be submitted and needs to be update.\n> \n> Don't you mean fetch + merge ?\n\nObviously.\n\nThanks,\nDscho\n"},{"id":"61284","messageId":"27E5EF3C-19EF-441C-BB12-0F5B29BEAEDB@midwinter.com","threadId":"10466","inReplyTo":"Pine.LNX.4.64.0711281307420.27959@racer.site","subject":"Re: [PATCH v2] Teach 'git pull' about --rebase","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-11-28T20:35:57Z","receivedAt":"2007-11-28T20:35:57Z","isPatch":true,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"On Nov 28, 2007, at 5:11 AM, Johannes Schindelin wrote:\n> As a convenience, you can set the default behavior for a branch by\n> defining the config variable branch..rebase, which is\n> interpreted as a bool. This setting can be overridden on the command\n> line by --rebase and --no-rebase.\n\nI wonder if this shouldn't be branch..pulltype or something like \nthat, so we can represent more than just \"rebase or not.\" Values could \nbe \"rebase\", \"merge\" (the default) and maybe even \"manual\" to specify \nthat git-pull should neither merge nor rebase a particular branch even \nif it matches a wildcard refspec.\n\nNot too sure about that last suggestion but it seems like there might \nbe other settings than \"rebase\" and \"merge\" in the future even if \nthat's not one of them.\n\n-Steve\n"},{"id":"61287","messageId":"Pine.LNX.4.64.0711282039430.27959@racer.site","threadId":"10466","inReplyTo":"27E5EF3C-19EF-441C-BB12-0F5B29BEAEDB@midwinter.com","subject":"Re: [PATCH v2] Teach 'git pull' about --rebase","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-28T20:40:48Z","receivedAt":"2007-11-28T20:40:48Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 28 Nov 2007, Steven Grimm wrote:\n\n> On Nov 28, 2007, at 5:11 AM, Johannes Schindelin wrote:\n> > As a convenience, you can set the default behavior for a branch by \n> > defining the config variable branch..rebase, which is \n> > interpreted as a bool. This setting can be overridden on the command \n> > line by --rebase and --no-rebase.\n> \n> I wonder if this shouldn't be branch..pulltype or something like \n> that, so we can represent more than just \"rebase or not.\" Values could \n> be \"rebase\", \"merge\" (the default) and maybe even \"manual\" to specify \n> that git-pull should neither merge nor rebase a particular branch even \n> if it matches a wildcard refspec.\n\nI am not convinced that this is a good thing... We already have \nbranch..mergeOptions for proper merges, and I want to make clear \nthat this is about rebase, and not about merge.\n\nCiao,\nDscho\n"},{"id":"61288","messageId":"8c5c35580711281310h8764a33pba48e65010abf859@mail.gmail.com","threadId":"10466","inReplyTo":"Pine.LNX.4.64.0711282039430.27959@racer.site","subject":"Re: [PATCH v2] Teach 'git pull' about --rebase","fromName":"Lars Hjemli","fromEmail":"hjemli@gmail.com","sentAt":"2007-11-28T21:10:34Z","receivedAt":"2007-11-28T21:10:34Z","isPatch":true,"sender":{"key":"hjemli@gmail.com","avatar":null},"body":"On 11/28/07, Johannes Schindelin wrote:\n> On Wed, 28 Nov 2007, Steven Grimm wrote:\n> > I wonder if this shouldn't be branch..pulltype or something like\n> > that, so we can represent more than just \"rebase or not.\" Values could\n> > be \"rebase\", \"merge\" (the default) and maybe even \"manual\" to specify\n> > that git-pull should neither merge nor rebase a particular branch even\n> > if it matches a wildcard refspec.\n>\n> I am not convinced that this is a good thing... We already have\n> branch..mergeOptions for proper merges, and I want to make clear\n> that this is about rebase, and not about merge.\n\nMaybe branch..pullOptions ?\n\n--\nlarsh\n"},{"id":"61294","messageId":"7vhcj63uhw.fsf@gitster.siamese.dyndns.org","threadId":"10466","inReplyTo":"8c5c35580711281310h8764a33pba48e65010abf859@mail.gmail.com","subject":"Re: [PATCH v2] Teach 'git pull' about --rebase","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-28T21:55:39Z","receivedAt":"2007-11-28T21:55:39Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Lars Hjemli\" writes:\n\n> On 11/28/07, Johannes Schindelin wrote:\n>> On Wed, 28 Nov 2007, Steven Grimm wrote:\n>> > I wonder if this shouldn't be branch..pulltype or something like\n>> > that, so we can represent more than just \"rebase or not.\" Values could\n>> > be \"rebase\", \"merge\" (the default) and maybe even \"manual\" to specify\n>> > that git-pull should neither merge nor rebase a particular branch even\n>> > if it matches a wildcard refspec.\n>>\n>> I am not convinced that this is a good thing... We already have\n>> branch..mergeOptions for proper merges, and I want to make clear\n>> that this is about rebase, and not about merge.\n>\n> Maybe branch..pullOptions ?\n\nMaybe not make this part of git-pull at all? merge and rebase have\ntotally different impact on the resulting history, so perhaps a separate\ncommand that is a shorthand for \"git fetch && git rebase\" may help\nunconfuse the users.\n"},{"id":"61295","messageId":"Pine.LNX.4.64.0711282156520.27959@racer.site","threadId":"10466","inReplyTo":"7vhcj63uhw.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH v2] Teach 'git pull' about --rebase","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-28T21:58:52Z","receivedAt":"2007-11-28T21:58:52Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 28 Nov 2007, Junio C Hamano wrote:\n\n> \"Lars Hjemli\" writes:\n> \n> > On 11/28/07, Johannes Schindelin wrote:\n> >> On Wed, 28 Nov 2007, Steven Grimm wrote:\n> >> > I wonder if this shouldn't be branch..pulltype or something like\n> >> > that, so we can represent more than just \"rebase or not.\" Values could\n> >> > be \"rebase\", \"merge\" (the default) and maybe even \"manual\" to specify\n> >> > that git-pull should neither merge nor rebase a particular branch even\n> >> > if it matches a wildcard refspec.\n> >>\n> >> I am not convinced that this is a good thing... We already have\n> >> branch..mergeOptions for proper merges, and I want to make clear\n> >> that this is about rebase, and not about merge.\n> >\n> > Maybe branch..pullOptions ?\n> \n> Maybe not make this part of git-pull at all? merge and rebase have\n> totally different impact on the resulting history, so perhaps a separate\n> command that is a shorthand for \"git fetch && git rebase\" may help\n> unconfuse the users.\n\nNot so sure about that. We already have too many commands, according to \nsome outspoken people, and this would add to it.\n\nBesides, the operation \"pull\" is about getting remote changes incorporated \nin your current branch. IMHO \"pull = fetch + merge\" is only a technical \ndetail, and we should not be bound by it too much.\n\nCiao,\nDscho\n"},{"id":"61297","messageId":"474DE4D5.6020407@freescale.com","threadId":"10466","inReplyTo":"7vhcj63uhw.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH v2] Teach 'git pull' about --rebase","fromName":"Jon Loeliger","fromEmail":"jdl@freescale.com","sentAt":"2007-11-28T21:59:49Z","receivedAt":"2007-11-28T21:59:49Z","isPatch":true,"sender":{"key":"jdl@jdl.com","avatar":"https://gravatar.com/avatar/75ce9a10b151acd2c28ec4ab2136dba7b2ff1634530bd04b155981a749d08a64?d=mp&s=160"},"body":"Junio C Hamano wrote:\n\n> Maybe not make this part of git-pull at all? merge and rebase have\n> totally different impact on the resulting history, so perhaps a separate\n> command that is a shorthand for \"git fetch && git rebase\" may help\n> unconfuse the users.\n\nAt long last, we can revive \"git update\"!\n\njdl\n"},{"id":"61299","messageId":"Pine.LNX.4.64.0711282202120.27959@racer.site","threadId":"10466","inReplyTo":"474DE4D5.6020407@freescale.com","subject":"Re: [PATCH v2] Teach 'git pull' about --rebase","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-28T22:02:30Z","receivedAt":"2007-11-28T22:02:30Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 28 Nov 2007, Jon Loeliger wrote:\n\n> Junio C Hamano wrote:\n> \n> > Maybe not make this part of git-pull at all? merge and rebase have\n> > totally different impact on the resulting history, so perhaps a separate\n> > command that is a shorthand for \"git fetch && git rebase\" may help\n> > unconfuse the users.\n> \n> At long last, we can revive \"git update\"!\n\nNo, we cannot. By now, too many aliases are called \"update\".\n\nCiao,\nDscho\n"},{"id":"61300","messageId":"37EFF273-D8E1-4042-966B-743CE9D753AA@midwinter.com","threadId":"10466","inReplyTo":"Pine.LNX.4.64.0711282156520.27959@racer.site","subject":"Re: [PATCH v2] Teach 'git pull' about --rebase","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-11-28T22:06:44Z","receivedAt":"2007-11-28T22:06:44Z","isPatch":true,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"On Nov 28, 2007, at 1:58 PM, Johannes Schindelin wrote:\n> Besides, the operation \"pull\" is about getting remote changes \n> incorporated\n> in your current branch. IMHO \"pull = fetch + merge\" is only a \n> technical\n> detail, and we should not be bound by it too much.\n\nYeah, I agree. I almost never use \"pull\" as is because I almost always \nwant to rebase. That is, it's basically clutter for me as a command \nright now, and it would remain so even if a separate fetch+rebase \ncommand were added.\n\nI think this may be a difference in perspective based on how one uses \ngit. If I were an integrator I would probably use \"pull\" as is a lot \nmore because I would want the merges represented explicitly in my \nhistory. But most of the time I'm working as a leaf node in the tree \nof repositories, interacting only with a central integration repo, and \nI basically never want a give-me-the-remote-changes operation (which \nis really more of a \"sync me up with the latest changes from the rest \nof the team\" operation) to put a merge in my history.\n\nWhat's more, when I'm introducing git to new people in my environment, \nright now I tell them about fetch and rebase and pretty much have to \ntell them to avoid running \"pull\" until they're comfortable with git, \nsince I know their histories would be full of meaningless merges \notherwise. It'd be nice to have new people run one less command as \npart of their normal day-to-day work.\n\n-Steve\n"},{"id":"61305","messageId":"20071128223339.GF7376@fieldses.org","threadId":"10466","inReplyTo":"Pine.LNX.4.64.0711282156520.27959@racer.site","subject":"Re: [PATCH v2] Teach 'git pull' about --rebase","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-11-28T22:33:39Z","receivedAt":"2007-11-28T22:33:39Z","isPatch":true,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Wed, Nov 28, 2007 at 09:58:52PM +0000, Johannes Schindelin wrote:\n> Hi,\n> \n> On Wed, 28 Nov 2007, Junio C Hamano wrote:\n> \n> > \"Lars Hjemli\" writes:\n> > \n> > > On 11/28/07, Johannes Schindelin wrote:\n> > >> On Wed, 28 Nov 2007, Steven Grimm wrote:\n> > >> > I wonder if this shouldn't be branch..pulltype or something like\n> > >> > that, so we can represent more than just \"rebase or not.\" Values could\n> > >> > be \"rebase\", \"merge\" (the default) and maybe even \"manual\" to specify\n> > >> > that git-pull should neither merge nor rebase a particular branch even\n> > >> > if it matches a wildcard refspec.\n> > >>\n> > >> I am not convinced that this is a good thing... We already have\n> > >> branch..mergeOptions for proper merges, and I want to make clear\n> > >> that this is about rebase, and not about merge.\n> > >\n> > > Maybe branch..pullOptions ?\n> > \n> > Maybe not make this part of git-pull at all? merge and rebase have\n> > totally different impact on the resulting history, so perhaps a separate\n> > command that is a shorthand for \"git fetch && git rebase\" may help\n> > unconfuse the users.\n> \n> Not so sure about that. We already have too many commands, according to \n> some outspoken people, and this would add to it.\n\nWhat they're really complaining about is the size and complexity of the\ninterface, and the lack of a clearly identified subset for them to learn\nfirst.\n\nThis has so far mainly manifested itself in complaints about the number\nof commands, because that's currently where a lot of our complexity is.\nBut they *will* complain about proliferation of commandline switches and\nconfig options too. (I've heard complaints about the number of switches\nrequired on the average cvs commandline, for example.)\n\nWe're stuck expanding the interface here, whether we expand it by\nanother command or another commandline switch.\n\nSo, how do you decide whether to make it a new command or not?\n\n\t- Look at existing documentation that talks about pull: if that\n\t documentation will still apply to the new pull, that weighs\n\t for keeping it the same command. If theat documentation would\n\t apply only without having a certain config value set, then I\n\t think it's better as a separate command.\n\n\t- Will this make it more or less simple to identify the subset\n\t of the git syntax that a user will have to do a given job? If\n\t there are jobs for which someone might only ever need the new\n\t fetch+rebase, or for which they would only ever need the\n\t traditional pull, then I think it would keep the two separate,\n\t to make it easier for a learner to skip over information about\n\t the one they're not using.\n\nI've got no proposal for an alternate name. All that comes to mind is\nthe portmanteau \"freebase\", which is terrible....\n\n--b.\n"},{"id":"61310","messageId":"20071128224717.GG7376@fieldses.org","threadId":"10466","inReplyTo":"20071128223339.GF7376@fieldses.org","subject":"Re: [PATCH v2] Teach 'git pull' about --rebase","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-11-28T22:47:17Z","receivedAt":"2007-11-28T22:47:17Z","isPatch":true,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Wed, Nov 28, 2007 at 05:33:39PM -0500, J. Bruce Fields wrote:\n> What they're really complaining about is the size and complexity of the\n> interface, and the lack of a clearly identified subset for them to learn\n> first.\n> \n> This has so far mainly manifested itself in complaints about the number\n> of commands, because that's currently where a lot of our complexity is.\n> But they *will* complain about proliferation of commandline switches and\n> config options too. (I've heard complaints about the number of switches\n> required on the average cvs commandline, for example.)\n> \n> We're stuck expanding the interface here, whether we expand it by\n> another command or another commandline switch.\n> \n> So, how do you decide whether to make it a new command or not?\n> \n> \t- Look at existing documentation that talks about pull: if that\n> \t documentation will still apply to the new pull, that weighs\n> \t for keeping it the same command. If theat documentation would\n> \t apply only without having a certain config value set, then I\n> \t think it's better as a separate command.\n> \n> \t- Will this make it more or less simple to identify the subset\n> \t of the git syntax that a user will have to do a given job? If\n> \t there are jobs for which someone might only ever need the new\n> \t fetch+rebase, or for which they would only ever need the\n> \t traditional pull, then I think it would keep the two separate,\n> \t to make it easier for a learner to skip over information about\n> \t the one they're not using.\n> \n> I've got no proposal for an alternate name. All that comes to mind is\n> the portmanteau \"freebase\", which is terrible....\n\nActually, considering the second point: people that are using\nfetch+rebase don't necessarily need or (for now) want to understand pull\nat all. But they certainly *do* have to understand rebase. Would it be\npossible to add this to rebase instead of to pull?\n\n\tgit rebase --url git://x.org/x.git master\n\nwhere --url means \"interpret as a branch from the given\nremote repository.\n\nThat interacts poorly with --onto, though.\n\n--b.\n"},{"id":"61321","messageId":"Pine.LNX.4.64.0711282309030.27959@racer.site","threadId":"10466","inReplyTo":"20071128224717.GG7376@fieldses.org","subject":"Re: [PATCH v2] Teach 'git pull' about --rebase","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-28T23:12:32Z","receivedAt":"2007-11-28T23:12:32Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 28 Nov 2007, J. Bruce Fields wrote:\n\n> Would it be possible to add this to rebase instead of to pull?\n> \n> \tgit rebase --url git://x.org/x.git master\n> \n> where --url means \"interpret as a branch from the given\n> remote repository.\n\nI was briefly considering it.\n\nBut the point is this: I know exactly if I want to rebase my branch onto \nupstream, or if I want to merge it. There is not much point in mixing the \ntwo.\n\nSo my rationale was: if we already have an existing framework to integrate \nremote changes with our current branch, why not just go ahead and use it? \nThat's the reason BTW why I originally wanted a \"rebase\" merge stragegy. \nEven if it is not technically a merge.\n\nI really rather have no user-friendly support for fetch+rebase (and utter \na friendly, but loud curse everytime I made a \"git pull\" by mistake) than \nyet another command.\n\nCiao,\nDscho\n"},{"id":"61324","messageId":"7v1waa2bfi.fsf@gitster.siamese.dyndns.org","threadId":"10466","inReplyTo":"Pine.LNX.4.64.0711282309030.27959@racer.site","subject":"Re: [PATCH v2] Teach 'git pull' about --rebase","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-28T23:32:49Z","receivedAt":"2007-11-28T23:32:49Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> So my rationale was: if we already have an existing framework to integrate \n> remote changes with our current branch, why not just go ahead and use it? \n> That's the reason BTW why I originally wanted a \"rebase\" merge stragegy. \n> Even if it is not technically a merge.\n>\n> I really rather have no user-friendly support for fetch+rebase (and utter \n> a friendly, but loud curse everytime I made a \"git pull\" by mistake) than \n> yet another command.\n\nI suspect that people who do not like the two modes of checkout will\ncertainly not appreciate the overloading two behaviours to create\ndifferent kind of histories and two different ways to continue when the\nintegration do not go smoothly upon conflicts these two behaviours have.\n\nHowever, I agree very much with an earlier comment made by Daniel about\nour UI being task oriented instead of being command oriented, and I\nactually consider it a good thing. So it does not bother me too much\nthat \"git pull --rebase\" has a quite different workflow from the regular\n\"merge\" kind of pull.\n\nSo let's queue \"pull --rebase\" and see what happens.\n"},{"id":"61332","messageId":"20071128235633.GI7376@fieldses.org","threadId":"10466","inReplyTo":"7v1waa2bfi.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH v2] Teach 'git pull' about --rebase","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-11-28T23:56:33Z","receivedAt":"2007-11-28T23:56:33Z","isPatch":true,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Wed, Nov 28, 2007 at 03:32:49PM -0800, Junio C Hamano wrote:\n> Johannes Schindelin writes:\n> \n> > So my rationale was: if we already have an existing framework to integrate \n> > remote changes with our current branch, why not just go ahead and use it? \n> > That's the reason BTW why I originally wanted a \"rebase\" merge stragegy. \n> > Even if it is not technically a merge.\n> >\n> > I really rather have no user-friendly support for fetch+rebase (and utter \n> > a friendly, but loud curse everytime I made a \"git pull\" by mistake) than \n> > yet another command.\n> \n> I suspect that people who do not like the two modes of checkout will\n> certainly not appreciate the overloading two behaviours to create\n> different kind of histories and two different ways to continue when the\n> integration do not go smoothly upon conflicts these two behaviours have.\n> \n> However, I agree very much with an earlier comment made by Daniel about\n> our UI being task oriented instead of being command oriented, and I\n> actually consider it a good thing. So it does not bother me too much\n> that \"git pull --rebase\" has a quite different workflow from the regular\n> \"merge\" kind of pull.\n> \n> So let's queue \"pull --rebase\" and see what happens.\n\nWhat I'm really most worried about isn't the commandline switch but the\nconfig option--it makes the same commandlines silently behave in very\ndifferent ways.\n\nI really don't want every tutorial that mentions \"git pull\" to have to\nsay \"the following applies only if git..rebase is\nfalse\". And it'll be either that or risk having a lot of people saying\n\"I typed in exactly that commandline, but this happened....\".\n\nA default to \"false\" does at least require positive acknowledgement, but\nif this is expected to be used by newbies, they're going to be told to\nset that config before they understand the difference it makes.\n\n--b.\n"},{"id":"61337","messageId":"Pine.LNX.4.64.0711290011110.27959@racer.site","threadId":"10466","inReplyTo":"20071128235633.GI7376@fieldses.org","subject":"Re: [PATCH v2] Teach 'git pull' about --rebase","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-29T00:16:09Z","receivedAt":"2007-11-29T00:16:09Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 28 Nov 2007, J. Bruce Fields wrote:\n\n> On Wed, Nov 28, 2007 at 03:32:49PM -0800, Junio C Hamano wrote:\n> > Johannes Schindelin writes:\n> > \n> > > So my rationale was: if we already have an existing framework to integrate \n> > > remote changes with our current branch, why not just go ahead and use it? \n> > > That's the reason BTW why I originally wanted a \"rebase\" merge stragegy. \n> > > Even if it is not technically a merge.\n> > >\n> > > I really rather have no user-friendly support for fetch+rebase (and utter \n> > > a friendly, but loud curse everytime I made a \"git pull\" by mistake) than \n> > > yet another command.\n> > \n> > I suspect that people who do not like the two modes of checkout will\n> > certainly not appreciate the overloading two behaviours to create\n> > different kind of histories and two different ways to continue when the\n> > integration do not go smoothly upon conflicts these two behaviours have.\n> > \n> > However, I agree very much with an earlier comment made by Daniel about\n> > our UI being task oriented instead of being command oriented, and I\n> > actually consider it a good thing. So it does not bother me too much\n> > that \"git pull --rebase\" has a quite different workflow from the regular\n> > \"merge\" kind of pull.\n> > \n> > So let's queue \"pull --rebase\" and see what happens.\n> \n> What I'm really most worried about isn't the commandline switch but the\n> config option--it makes the same commandlines silently behave in very\n> different ways.\n> \n> I really don't want every tutorial that mentions \"git pull\" to have to\n> say \"the following applies only if git..rebase is\n> false\". And it'll be either that or risk having a lot of people saying\n> \"I typed in exactly that commandline, but this happened....\".\n> \n> A default to \"false\" does at least require positive acknowledgement, but\n> if this is expected to be used by newbies, they're going to be told to\n> set that config before they understand the difference it makes.\n\nHey, why not just special case \"mergeOptions = rebaseInstead\"?\n\nCiao,\nDscho\n"},{"id":"61359","messageId":"alpine.LFD.0.99999.0711282220300.9605@xanadu.home","threadId":"10466","inReplyTo":"20071128223339.GF7376@fieldses.org","subject":"Re: [PATCH v2] Teach 'git pull' about --rebase","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-11-29T03:23:50Z","receivedAt":"2007-11-29T03:23:50Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 28 Nov 2007, J. Bruce Fields wrote:\n\n> On Wed, Nov 28, 2007 at 09:58:52PM +0000, Johannes Schindelin wrote:\n> > Not so sure about that. We already have too many commands, according to \n> > some outspoken people, and this would add to it.\n> \n> What they're really complaining about is the size and complexity of the\n> interface, and the lack of a clearly identified subset for them to learn\n> first.\n\nWell, the idea is that once all those plumbing commands are hidden away \nin some libexec dir, that makes a _lot_ of breathing room for a few \nmore porcelain commands if needed.\n\n\nNicolas\n"},{"id":"61380","messageId":"474E79F0.4080101@op5.se","threadId":"10466","inReplyTo":"7v1waa2bfi.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH v2] Teach 'git pull' about --rebase","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-11-29T08:36:00Z","receivedAt":"2007-11-29T08:36:00Z","isPatch":true,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> Johannes Schindelin writes:\n> \n>> So my rationale was: if we already have an existing framework to integrate \n>> remote changes with our current branch, why not just go ahead and use it? \n>> That's the reason BTW why I originally wanted a \"rebase\" merge stragegy. \n>> Even if it is not technically a merge.\n>>\n>> I really rather have no user-friendly support for fetch+rebase (and utter \n>> a friendly, but loud curse everytime I made a \"git pull\" by mistake) than \n>> yet another command.\n> \n> I suspect that people who do not like the two modes of checkout will\n> certainly not appreciate the overloading two behaviours to create\n> different kind of histories and two different ways to continue when the\n> integration do not go smoothly upon conflicts these two behaviours have.\n> \n> However, I agree very much with an earlier comment made by Daniel about\n> our UI being task oriented instead of being command oriented, and I\n> actually consider it a good thing. So it does not bother me too much\n> that \"git pull --rebase\" has a quite different workflow from the regular\n> \"merge\" kind of pull.\n> \n> So let's queue \"pull --rebase\" and see what happens.\n> \n\nI've used the --rebase option to git pull, explained it to my co-workers\nand also made sure they're using a version of git that has it. So far\nthere hasn't been a single complaint about \"git pull\" being any harder\nto grok.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"61599","messageId":"20071201203759.GA11710@atjola.homenet","threadId":"10466","inReplyTo":"7vhcj63uhw.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH v2] Teach 'git pull' about --rebase","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2007-12-01T20:37:59Z","receivedAt":"2007-12-01T20:37:59Z","isPatch":true,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2007.11.28 13:55:39 -0800, Junio C Hamano wrote:\n> \"Lars Hjemli\" writes:\n> \n> > On 11/28/07, Johannes Schindelin wrote:\n> >> On Wed, 28 Nov 2007, Steven Grimm wrote:\n> >> > I wonder if this shouldn't be branch..pulltype or something like\n> >> > that, so we can represent more than just \"rebase or not.\" Values could\n> >> > be \"rebase\", \"merge\" (the default) and maybe even \"manual\" to specify\n> >> > that git-pull should neither merge nor rebase a particular branch even\n> >> > if it matches a wildcard refspec.\n> >>\n> >> I am not convinced that this is a good thing... We already have\n> >> branch..mergeOptions for proper merges, and I want to make clear\n> >> that this is about rebase, and not about merge.\n> >\n> > Maybe branch..pullOptions ?\n> \n> Maybe not make this part of git-pull at all? merge and rebase have\n> totally different impact on the resulting history, so perhaps a separate\n> command that is a shorthand for \"git fetch && git rebase\" may help\n> unconfuse the users.\n\nHm, why not tackle the whole thing the other way around? IMHO the\nprimary action is the merge/rebase, not the fetch. So choosing which\naction you want in addition to the fetch seems a bit backwards. git-svn\nalready includes a fetch from svn in its rebase operation, which is\nreally handy, because you rebase quite often with that beast.\n\nAnd it's likely that you want to merge with/rebase against the latest available\nremote commit all the time anyway and on the few(?) occassions\nwhere you have no connectivity, but already fetched some remote stuff\nwhich you want to incorporate into your local branches now, it's\nhopefully bearable to pass --no-fetch.\n\nSo how about adding --fetch/--no-fetch (maybe with a configurable\ndefault?) to git-merge/git-rebase and deprecate git-pull over time?\n\nBjörn\n"},{"id":"61780","messageId":"20071203131021.GA9674@diana.vm.bytemark.co.uk","threadId":"10466","inReplyTo":"20071201203759.GA11710@atjola.homenet","subject":"Re: [PATCH v2] Teach 'git pull' about --rebase","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-12-03T13:10:21Z","receivedAt":"2007-12-03T13:10:21Z","isPatch":true,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-12-01 21:37:59 +0100, Björn Steinbrink wrote:\n\n> So how about adding --fetch/--no-fetch (maybe with a configurable\n> default?) to git-merge/git-rebase and deprecate git-pull over time?\n\nFWIW, I like this idea. rebase/merge is the complicated part of the\noperation, so the UI should focus on that. Updating or not updating\nthe remote-tracking branch that is merged from/rebased on is a simple\nbinary choice, so a flag is perfect.\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"}]}