{"thread":{"id":"33827","subject":"[RFC] New kind of upstream branch: base branch","startedAt":"2013-05-15T20:34:49Z","lastAt":"2013-05-19T08:12:32Z","messageCount":14,"participants":["Felipe Contreras","Philip Oakley","Kevin Bracey","Junio C Hamano","Ramkumar Ramachandra"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"217477","messageId":"CAMP44s3LQ0GN4rrXdpb8Fe0iLeAEm2VjkH6BHK64pmX-xpc7+Q@mail.gmail.com","threadId":"33827","inReplyTo":null,"subject":"[RFC] New kind of upstream branch: base branch","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-15T20:34:49Z","receivedAt":"2013-05-15T20:34:49Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Hi,\n\nI've been using Git from the start, but only lately have I forced\nmyself to configure upstream branches for all my branches, and I've\nfound a few things more convenient, but others completely contrary to\nwhat I expected.\n\nInconvenient:\n\nBefore, I used to do 'git fetch' to simply fetch from 'origin', but\nnow, it depends on where 'upstream' is set to.\n\nConvinient:\n\nNow, I can just do 'git rebase --interactive' and I don't have to\nspecify the starting point, which is particularily useful when there's\na lot of branches one depending on another.\n\nI think I'm using 'upstream' for something it was not intended to, and\nI think the current 'upstream' behavior should be split into\n'upstream' and 'base'.\n\n== base ==\n\nThe 'base' branch will be set each time you create a branch from another;\n'git checkout -b foobar master' sets 'master' as the 'base' of 'foobar'.\n\nThen you can do 'git rebase foobar@{base}' or simply 'git rebase', and\nGit will pick the right branch to rebase unto, even if you have no\n'upstream'\nconfigured.\n\nThis way 'git fetch' will keep picking 'origin', and other commands\nthat make use of 'upstream' would be undisturbed.\n\nIf both 'base' and 'upstream' are defined, I think 'git rebase' should\nuse 'base', but since that would break old behavior, perhaps there\nshould be a configuration variable to enable a different behavior.\n\nI already started writting the patches, and although tedious, I think\nthey they'll be rather straightforward, but I thought it would be best\nto hear some opinions first.\n\nWhat do you think?\n\n-- \nFelipe Contreras\n"},{"id":"217479","messageId":"AE3E8FA3205F42C5B11F3617987BEA05@PhilipOakley","threadId":"33827","inReplyTo":"CAMP44s3LQ0GN4rrXdpb8Fe0iLeAEm2VjkH6BHK64pmX-xpc7+Q@mail.gmail.com","subject":"Re: [RFC] New kind of upstream branch: base branch","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-05-15T22:22:55Z","receivedAt":"2013-05-15T22:22:55Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Felipe Contreras\" \nSent: Wednesday, May 15, 2013 9:34 PM\n> Hi,\n>\n> I've been using Git from the start, but only lately have I forced\n> myself to configure upstream branches for all my branches, and I've\n> found a few things more convenient, but others completely contrary to\n> what I expected.\n>\n> Inconvenient:\n>\n> Before, I used to do 'git fetch' to simply fetch from 'origin', but\n> now, it depends on where 'upstream' is set to.\n>\n> Convinient:\n>\n> Now, I can just do 'git rebase --interactive' and I don't have to\n> specify the starting point, which is particularily useful when there's\n> a lot of branches one depending on another.\n>\n> I think I'm using 'upstream' for something it was not intended to, and\n> I think the current 'upstream' behavior should be split into\n> 'upstream' and 'base'.\n>\n> == base ==\n>\n> The 'base' branch will be set each time you create a branch from \n> another;\n> 'git checkout -b foobar master' sets 'master' as the 'base' of \n> 'foobar'.\n>\n> Then you can do 'git rebase foobar@{base}' or simply 'git rebase', and\n> Git will pick the right branch to rebase unto, even if you have no\n> 'upstream'\n> configured.\n>\n> This way 'git fetch' will keep picking 'origin', and other commands\n> that make use of 'upstream' would be undisturbed.\n>\n> If both 'base' and 'upstream' are defined, I think 'git rebase' should\n> use 'base', but since that would break old behavior, perhaps there\n> should be a configuration variable to enable a different behavior.\n>\n> I already started writting the patches, and although tedious, I think\n> they they'll be rather straightforward, but I thought it would be best\n> to hear some opinions first.\n>\n> What do you think?\n>\n> -- \n> Felipe Contreras\n---\nSound a reasonable idea. On some patches I was working on I had to \n[chose to] add a tag for the base which made it easier to rebase later.\n\nThe other point is that I had already noted that the glossary doesn't \ninclude the many \"base\" terms in use that aren't always well understood.\n\nPhilip Oakley \n"},{"id":"217503","messageId":"CAMP44s13Q6DMX+QNteqO8D-J7bDcNyp7OkRVqj6B1Qhp0OSB+Q@mail.gmail.com","threadId":"33827","inReplyTo":"AE3E8FA3205F42C5B11F3617987BEA05@PhilipOakley","subject":"Re: [RFC] New kind of upstream branch: base branch","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-16T03:46:58Z","receivedAt":"2013-05-16T03:46:58Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Wed, May 15, 2013 at 5:22 PM, Philip Oakley wrote:\n\n> Sound a reasonable idea. On some patches I was working on I had to [chose\n> to] add a tag for the base which made it easier to rebase later.\n\nAnd was the 'upstream' branch somehow not appropriate for some reason?\n\n-- \nFelipe Contreras\n"},{"id":"217639","messageId":"D6098E29305740EE916958521A797AB9@PhilipOakley","threadId":"33827","inReplyTo":"CAMP44s13Q6DMX+QNteqO8D-J7bDcNyp7OkRVqj6B1Qhp0OSB+Q@mail.gmail.com","subject":"Re: [RFC] New kind of upstream branch: base branch","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-05-16T19:35:26Z","receivedAt":"2013-05-16T19:35:26Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Felipe Contreras\" \nSent: Thursday, May 16, 2013 4:46 AM\n> On Wed, May 15, 2013 at 5:22 PM, Philip Oakley \n> wrote:\n>\n>> Sound a reasonable idea. On some patches I was working on I had to \n>> [chose\n>> to] add a tag for the base which made it easier to rebase later.\n>\n> And was the 'upstream' branch somehow not appropriate for some reason?\n\nIf I remember correctly, I had a short branch based on 'pu', which was \nrewound, so I wanted to rebase that short branch onto the new 'pu'. This \ncreates a confusion between old-pu and new-pu. Having a marker for the \n'base' at the branch point allowed an easy specification of the branch\n\nI think I misunderstood your proposal. I thought that it would \neffectively save a marker (e.g. the sha1) for the base point of the \nbranch, it may have been something similar to a [lightweight] tag, it \ncould have been just local or could have been transferable, I hadn't \nthought it further.\n\nPhilip \n"},{"id":"217669","messageId":"CAMP44s3UjDUWb_ng5NhLB2tMV0gqsRx_Ob=vj3P5RVfigD1r7Q@mail.gmail.com","threadId":"33827","inReplyTo":"D6098E29305740EE916958521A797AB9@PhilipOakley","subject":"Re: [RFC] New kind of upstream branch: base branch","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-17T00:07:26Z","receivedAt":"2013-05-17T00:07:26Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, May 16, 2013 at 2:35 PM, Philip Oakley wrote:\n> From: \"Felipe Contreras\" \n> Sent: Thursday, May 16, 2013 4:46 AM\n>\n>> On Wed, May 15, 2013 at 5:22 PM, Philip Oakley \n>> wrote:\n>>\n>>> Sound a reasonable idea. On some patches I was working on I had to [chose\n>>> to] add a tag for the base which made it easier to rebase later.\n>>\n>>\n>> And was the 'upstream' branch somehow not appropriate for some reason?\n>\n>\n> If I remember correctly, I had a short branch based on 'pu', which was\n> rewound, so I wanted to rebase that short branch onto the new 'pu'. This\n> creates a confusion between old-pu and new-pu. Having a marker for the\n> 'base' at the branch point allowed an easy specification of the branch\n\nSo you were not doing 'git rebase @{base}', you were doing 'git rebase\n--onto X @{base}'?\n\n> I think I misunderstood your proposal. I thought that it would effectively\n> save a marker (e.g. the sha1) for the base point of the branch, it may have\n> been something similar to a [lightweight] tag, it could have been just local\n> or could have been transferable, I hadn't thought it further.\n\nYeah, I thought about that, and I think it might make sense, but\nthat's another topic.\n\n-- \nFelipe Contreras\n"},{"id":"217755","messageId":"51968311.1020107@bracey.fi","threadId":"33827","inReplyTo":"CAMP44s3LQ0GN4rrXdpb8Fe0iLeAEm2VjkH6BHK64pmX-xpc7+Q@mail.gmail.com","subject":"Re: [RFC] New kind of upstream branch: base branch","fromName":"Kevin Bracey","fromEmail":"kevin@bracey.fi","sentAt":"2013-05-17T19:20:49Z","receivedAt":"2013-05-17T19:20:49Z","isPatch":false,"sender":{"key":"kevin@bracey.fi","avatar":"https://avatars.githubusercontent.com/u/96079793?v=4"},"body":"On 15/05/2013 23:34, Felipe Contreras wrote:\n> \n> I think I'm using 'upstream' for something it was not intended to, and\n> I think the current 'upstream' behavior should be split into\n> 'upstream' and 'base'.\n>\nI found myself thinking the same thing. It's really convenient being \nable to set your topic branch's upstream to another local branch, so git \nrebase works without parameters. But then I can't use upstream to point \nto a remote version of that topic branch. I want my topic branch to know \nboth that it's based on master (or origin/master), and that it's \nupstream is origin/topic.\n\nSo, yes, here's a vote in favour of the general concept.\n\nKevin\n"},{"id":"217756","messageId":"7va9ntxu3w.fsf@alter.siamese.dyndns.org","threadId":"33827","inReplyTo":"51968311.1020107@bracey.fi","subject":"Re: [RFC] New kind of upstream branch: base branch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-05-17T19:51:47Z","receivedAt":"2013-05-17T19:51:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Kevin Bracey writes:\n\n> On 15/05/2013 23:34, Felipe Contreras wrote:\n>> I think I'm using 'upstream' for something it was not intended to,\n>> and\n>> I think the current 'upstream' behavior should be split into\n>> 'upstream' and 'base'.\n>>\n> I found myself thinking the same thing. It's really convenient being\n> able to set your topic branch's upstream to another local branch, so\n\nWhat is that \"another local branch\"?\n\nIs the use case \"master forks from origin/master and has its own\nchanges on top, and then topic builds on my master but the range of\ncommits origin/master..topic includes both changes, that is\ninconvenient to when rebuilding topic on top of my master\"?\n\nI'd assume that it is the case, and the answer to the previous\nquestion is 'master' in the example.\n\n> git rebase works without parameters. But then I can't use upstream to\n> point to a remote version of that topic branch. I want my topic branch\n> to know both that it's based on master (or origin/master), and that\n> it's upstream is origin/topic.\n\nIf we do s/and that it's upstream is/and that it is pushed to/, then\nI think I am in general agreement (I wrote about it earlier in a\nseparate message).\n\n> So, yes, here's a vote in favour of the general concept.\n\nYes, you should be able to treat what you build on top (upstream)\nand where you publish the result (we are still looking for a better\nname in the other thread) as two distinct things in a triangular\nworkflow. I agree that it is an issue we need to address.\n\nWe have solved a half (\"push goes to a different repository\") but\nnot the other half (\"updates a branch whose name is different from\nthe upstream\") in the upcoming 1.8.3 release.\n\nThe latest round of design from Felipe calls it branch.$name.push,\nif I am not mistaken.\n\nI think it is somewhat an overkill, though.\n\nIt is normal for upstream's name not to match the topic's name\n(i.e. your 'topic' may branch off of a generic 'master', but would\nbe named after a more specific purpose of the branch and is unlikely\nto be named 'master'. In other words, branch.$name.merge that\npoints at an upstream that has a name that is totally different from\n$name is not an exception. So branch.$name.merge that you have to\nset for each branch is a necessity.\n\nHowever, if you were to push out 'topic' directly (as opposed to\npushing out a result of integrating it and other topic branches to\nyour 'master') to your own publishing point, it is likely you would\npush it out to the same name (i.e. 'topic' will be pushed out as\n'topic', not as 'master'). And if that is your workflow, setting\npush.default to \"current\" (and setting remote.pushdefault to your\npublishing repository) should be a sufficient interim solution, and\nyou do not need to set branch.$name.push to each and every branch\nyou intend to push out, I think.\n"},{"id":"217757","messageId":"CAMP44s1N4XpR4W-DgGgZrBPp-xe+14JpRTAXs=C0CdAb149nfQ@mail.gmail.com","threadId":"33827","inReplyTo":"51968311.1020107@bracey.fi","subject":"Re: [RFC] New kind of upstream branch: base branch","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-17T20:01:57Z","receivedAt":"2013-05-17T20:01:57Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Fri, May 17, 2013 at 2:20 PM, Kevin Bracey wrote:\n> On 15/05/2013 23:34, Felipe Contreras wrote:\n>>\n>> I think I'm using 'upstream' for something it was not intended to, and\n>> I think the current 'upstream' behavior should be split into\n>> 'upstream' and 'base'.\n>>\n> I found myself thinking the same thing. It's really convenient being able to\n> set your topic branch's upstream to another local branch, so git rebase\n> works without parameters. But then I can't use upstream to point to a remote\n> version of that topic branch. I want my topic branch to know both that it's\n> based on master (or origin/master), and that it's upstream is origin/topic.\n\nIf you are in your topic branch, what do you expect 'git pull' to do?\nAnd what do you expect 'git push' to do?\n\n-- \nFelipe Contreras\n"},{"id":"217758","messageId":"CAMP44s14CtWS=cGsF=ZqYPrCmSPjjc-8XQFZ7gD==Dg8sESRfQ@mail.gmail.com","threadId":"33827","inReplyTo":"7va9ntxu3w.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC] New kind of upstream branch: base branch","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-17T20:15:02Z","receivedAt":"2013-05-17T20:15:02Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Fri, May 17, 2013 at 2:51 PM, Junio C Hamano wrote:\n> Kevin Bracey writes:\n>\n>> On 15/05/2013 23:34, Felipe Contreras wrote:\n>>> I think I'm using 'upstream' for something it was not intended to,\n>>> and\n>>> I think the current 'upstream' behavior should be split into\n>>> 'upstream' and 'base'.\n>>>\n>> I found myself thinking the same thing. It's really convenient being\n>> able to set your topic branch's upstream to another local branch, so\n>\n> What is that \"another local branch\"?\n\nrefs/heads/*\n\n> Is the use case \"master forks from origin/master and has its own\n> changes on top, and then topic builds on my master but the range of\n> commits origin/master..topic includes both changes, that is\n> inconvenient to when rebuilding topic on top of my master\"?\n\nNo it's not. You just 'git rebase -i' and everything works.\n\n> I'd assume that it is the case, and the answer to the previous\n> question is 'master' in the example.\n>\n>> git rebase works without parameters. But then I can't use upstream to\n>> point to a remote version of that topic branch. I want my topic branch\n>> to know both that it's based on master (or origin/master), and that\n>> it's upstream is origin/topic.\n>\n> If we do s/and that it's upstream is/and that it is pushed to/, then\n> I think I am in general agreement (I wrote about it earlier in a\n> separate message).\n>\n>> So, yes, here's a vote in favour of the general concept.\n>\n> Yes, you should be able to treat what you build on top (upstream)\n> and where you publish the result (we are still looking for a better\n> name in the other thread) as two distinct things in a triangular\n> workflow. I agree that it is an issue we need to address.\n>\n> We have solved a half (\"push goes to a different repository\") but\n> not the other half (\"updates a branch whose name is different from\n> the upstream\") in the upcoming 1.8.3 release.\n>\n> The latest round of design from Felipe calls it branch.$name.push,\n> if I am not mistaken.\n>\n> I think it is somewhat an overkill, though.\n\nIt is needed.\n\n> It is normal for upstream's name not to match the topic's name\n> (i.e. your 'topic' may branch off of a generic 'master', but would\n> be named after a more specific purpose of the branch and is unlikely\n> to be named 'master'. In other words, branch.$name.merge that\n> points at an upstream that has a name that is totally different from\n> $name is not an exception. So branch.$name.merge that you have to\n> set for each branch is a necessity.\n>\n> However, if you were to push out 'topic' directly (as opposed to\n> pushing out a result of integrating it and other topic branches to\n> your 'master') to your own publishing point, it is likely you would\n> push it out to the same name (i.e. 'topic' will be pushed out as\n> 'topic', not as 'master').\n\nLikely, but not certain.\n\n> And if that is your workflow, setting\n> push.default to \"current\" (and setting remote.pushdefault to your\n> publishing repository) should be a sufficient interim solution, and\n> you do not need to set branch.$name.push to each and every branch\n> you intend to push out, I think.\n\nIf git needs configurations to behave sanely, git is broken.\n\nIf we set:\nbranch.autosetupmerge = always\npush.default = simple\n\nBy default in v2.0, and there's a UI to set remote.pushdefault, then I\nmight be inclined to agree that branch.$name.push is overkill.\n\nBut I don't see that happening; the user still needs a sane way to\nmake trivial workflows work without hacking the configuration.\n\n-- \nFelipe Contreras\n"},{"id":"217817","messageId":"51979065.4060609@bracey.fi","threadId":"33827","inReplyTo":"7va9ntxu3w.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC] New kind of upstream branch: base branch","fromName":"Kevin Bracey","fromEmail":"kevin@bracey.fi","sentAt":"2013-05-18T14:29:57Z","receivedAt":"2013-05-18T14:29:57Z","isPatch":false,"sender":{"key":"kevin@bracey.fi","avatar":"https://avatars.githubusercontent.com/u/96079793?v=4"},"body":"On 17/05/2013 22:51, Junio C Hamano wrote:\n> Kevin Bracey writes:\n>\n>> On 15/05/2013 23:34, Felipe Contreras wrote:\n>>> I think I'm using 'upstream' for something it was not intended to,\n>>> and\n>>> I think the current 'upstream' behavior should be split into\n>>> 'upstream' and 'base'.\n>>>\n>> I found myself thinking the same thing. It's really convenient being\n>> able to set your topic branch's upstream to another local branch, so\n> What is that \"another local branch\"? ... And if that is your workflow, setting\n> push.default to \"current\" (and setting remote.pushdefault to your\n> publishing repository) should be a sufficient interim solution, and\n> you do not need to set branch.$name.push to each and every branch\n> you intend to push out, I think.\n\nI agree that using \"push.default current\" covers some cases - I hadn't \nreally considered it - tended to just stick with \"upstream\". \"current\" \nnearly does the job, but I will sometimes be wanting different names.\n\nWhat I'll often be doing is creating a topic branch based on master or \norigin/master. (I would hardly ever be updating master or pushing to \norigin/master myself, so I probably should be just doing origin/master, \nbut I tend to create a local master just to save typing on all those \n\"git rebase origin/master\").\n\nDuring work, to give others visibility, and the possibility to tinker \nwith the topic branch during development (as we don't have full \ninter-site sharing of work areas), I would push the topic branch up to \nthe central \"origin\" server, often with a \"kbracey/\" prefix, partially \nfor namespacing, and partially to indicate it's currently \"private\" work \nand subject to rebasing. I guess I could create the topic branch as \n\"kbracey/topic\" locally, but I'd rather not have to.\n\nSo I'd like \"git rebase (-i)\" to move my topic branch up \n(origin/)master. And I'd like \"git push (-f)\" to send it to \n\"origin/kbracey/topic\". And by extension, I suppose \"git pull --rebase\" \nto update origin/master and rebase. (Although I'm not much of a puller - \nI tend to fetch then rebase manually).\n\nThe final releasing procedure for the topic branch would be to hand that \nbranch over to an integrator, who would then merge/rebase it into master.\n\nAnd it would be ideal if the initial base and push tracking information \ncould be set up automatically on the first \"git checkout -b\"/\"git \nbranch\" and \"git push\". (For one, I've always found it odd that there's \nan asymmetry - if you check out a topic branch from the server to work \non or use it, you get a local copy with upstream set by default. But if \nyou create a topic branch yourself then push it, the upstream isn't set \nby default - you need the -u flag. This seems odd to me, and I've seen \nothers confused by this).\n\nKevin\n"},{"id":"217821","messageId":"CALkWK0nQVkmq+OdhWhM2EnZKmHxzLQonhd2tUeUvqJNf27GCXA@mail.gmail.com","threadId":"33827","inReplyTo":"51979065.4060609@bracey.fi","subject":"Re: [RFC] New kind of upstream branch: base branch","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-05-18T18:14:31Z","receivedAt":"2013-05-18T18:14:31Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Kevin Bracey wrote:\n> What I'll often be doing is creating a topic branch based on master or\n> origin/master. (I would hardly ever be updating master or pushing to\n> origin/master myself, so I probably should be just doing origin/master, but\n> I tend to create a local master just to save typing on all those \"git rebase\n> origin/master\").\n\nbranch..merge was designed primarily for pull and merge. I use\noperations like git diff origin.., git log origin.., git rebase [-i]\norigin. Ofcourse, rebase is a bit of a special case because it\ndefaults to operating on branch..merge by default: this is\nuseful to me when I want to rebase against what I just fetched\n(central workflows: we're slowly getting triangular workflows).\nAbusing branch..merge because you want a different default for\nrebase means we're doing something wrong. Perhaps we should get a\nrebase.defaultUpstream = @{u}|origin|... -- @{u} being the current\ndefault. In my opinion, branch..base is a huge overkill.\n\n> During work, to give others visibility, and the possibility to tinker with\n> the topic branch during development (as we don't have full inter-site\n> sharing of work areas), I would push the topic branch up to the central\n> \"origin\" server, often with a \"kbracey/\" prefix, partially for namespacing,\n> and partially to indicate it's currently \"private\" work and subject to\n> rebasing. I guess I could create the topic branch as \"kbracey/topic\"\n> locally, but I'd rather not have to.\n\nAll we have to do for this is to allow the user to set a custom\nrefspec using remote..push. The refspecs you get now are\nlimited to the ones set by the different modes of push.default (see\nbuiltin/push.c to see what refspec each of them set). We discussed\nbranch..push too on another thread, but I'm not convinced that\nwe need it.\n\n> (Although I'm not much of a puller - I tend to fetch then rebase manually).\n\npull needs to be fixed. I've partially fixed the rebasing pull thing\nwith rebase.autostash (still in pu), but there's a lot of work to be\ndone there.\n\n> And it would be ideal if the initial base and push tracking information\n> could be set up automatically on the first \"git checkout -b\"/\"git branch\"\n> and \"git push\". (For one, I've always found it odd that there's an asymmetry\n> - if you check out a topic branch from the server to work on or use it, you\n> get a local copy with upstream set by default. But if you create a topic\n> branch yourself then push it, the upstream isn't set by default - you need\n> the -u flag. This seems odd to me, and I've seen others confused by this).\n\nIt happens because @{u} doesn't exist before the first push. We\nshould definitely fix git checkout -b to inherit branch..remote\nand infer branch..merge.\n\nTo sum it up, lots of work to be done.\n"},{"id":"217836","messageId":"CAMP44s2dZkRUOQmKwmP_ruXfZemjTjEapTvdt276_d+NRZ8vhA@mail.gmail.com","threadId":"33827","inReplyTo":"51979065.4060609@bracey.fi","subject":"Re: [RFC] New kind of upstream branch: base branch","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-18T22:42:22Z","receivedAt":"2013-05-18T22:42:22Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sat, May 18, 2013 at 9:29 AM, Kevin Bracey wrote:\n> On 17/05/2013 22:51, Junio C Hamano wrote:\n>>\n>> Kevin Bracey writes:\n>>\n>>> On 15/05/2013 23:34, Felipe Contreras wrote:\n>>>>\n>>>> I think I'm using 'upstream' for something it was not intended to,\n>>>> and\n>>>> I think the current 'upstream' behavior should be split into\n>>>> 'upstream' and 'base'.\n>>>>\n>>> I found myself thinking the same thing. It's really convenient being\n>>> able to set your topic branch's upstream to another local branch, so\n>>\n>> What is that \"another local branch\"? ... And if that is your workflow,\n>> setting\n>>\n>> push.default to \"current\" (and setting remote.pushdefault to your\n>> publishing repository) should be a sufficient interim solution, and\n>> you do not need to set branch.$name.push to each and every branch\n>> you intend to push out, I think.\n>\n>\n> I agree that using \"push.default current\" covers some cases - I hadn't\n> really considered it - tended to just stick with \"upstream\". \"current\"\n> nearly does the job, but I will sometimes be wanting different names.\n>\n> What I'll often be doing is creating a topic branch based on master or\n> origin/master. (I would hardly ever be updating master or pushing to\n> origin/master myself, so I probably should be just doing origin/master, but\n> I tend to create a local master just to save typing on all those \"git rebase\n> origin/master\").\n>\n> During work, to give others visibility, and the possibility to tinker with\n> the topic branch during development (as we don't have full inter-site\n> sharing of work areas), I would push the topic branch up to the central\n> \"origin\" server, often with a \"kbracey/\" prefix, partially for namespacing,\n> and partially to indicate it's currently \"private\" work and subject to\n> rebasing. I guess I could create the topic branch as \"kbracey/topic\"\n> locally, but I'd rather not have to.\n>\n> So I'd like \"git rebase (-i)\" to move my topic branch up (origin/)master.\n> And I'd like \"git push (-f)\" to send it to \"origin/kbracey/topic\". And by\n> extension, I suppose \"git pull --rebase\" to update origin/master and rebase.\n> (Although I'm not much of a puller - I tend to fetch then rebase manually).\n>\n> The final releasing procedure for the topic branch would be to hand that\n> branch over to an integrator, who would then merge/rebase it into master.\n>\n> And it would be ideal if the initial base and push tracking information\n> could be set up automatically on the first \"git checkout -b\"/\"git branch\"\n> and \"git push\". (For one, I've always found it odd that there's an asymmetry\n> - if you check out a topic branch from the server to work on or use it, you\n> get a local copy with upstream set by default. But if you create a topic\n> branch yourself then push it, the upstream isn't set by default - you need\n> the -u flag. This seems odd to me, and I've seen others confused by this).\n\nIndeed, and I agree.\n\nI've started to set branch.autosetupmerge=always, so I always get an\nupstream no matter what. The only problem is that 'git fetch' now is\nuseless without any argument, but that can be fixed with another\nconfiguration 'fetch.default=simple', so that it always fetches from\norigin, no matter what. Then, everything is consistent, it doesn't\nmatter what 'branch.autosetupmerge' you have configured, and in which\nbranch you are sitting at, 'git fetch' will always do something\nuseful.\n\nThe missing problem is that you have to manually do 'git push origin\nkbracey/topic', and that can be solved with the concept of a\ndownstream (branch.x.remotepush+branch.x.push).\n\nIf we have these two changes, everything would work perfectly, wouldn't it?\n\n-- \nFelipe Contreras\n"},{"id":"217842","messageId":"7vbo871obk.fsf@alter.siamese.dyndns.org","threadId":"33827","inReplyTo":"51979065.4060609@bracey.fi","subject":"Re: [RFC] New kind of upstream branch: base branch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-05-19T06:22:23Z","receivedAt":"2013-05-19T06:22:23Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Kevin Bracey writes:\n\n>>> I found myself thinking the same thing. It's really convenient being\n>>> able to set your topic branch's upstream to another local branch, so\n>\n>> What is that \"another local branch\"? ... And if that is your workflow, setting\n>> push.default to \"current\" (and setting remote.pushdefault to your\n>> publishing repository) should be a sufficient interim solution, and\n>> you do not need to set branch.$name.push to each and every branch\n>> you intend to push out, I think.\n>\n> I agree that using \"push.default current\" covers some cases - I hadn't\n> really considered it - tended to just stick with \"upstream\". \"current\"\n> nearly does the job, but I will sometimes be wanting different names.\n\n\n> What I'll often be doing is creating a topic branch based on master or\n> origin/master. (I would hardly ever be updating master or pushing to\n> origin/master myself, so I probably should be just doing\n> origin/master, but I tend to create a local master just to save typing\n> on all those \"git rebase origin/master\").\n\nDo you mean, by \"save typing\", \"instead of origin/master, I can type\nmaster\"?\n\nIf you are using the \"checkout -t -b topic origin/master\", \"git rebase\"\nwithout any other argument should know that you meant to rebase\nagainst 'origin/master', so you do not even have to type 'master'.\n> During work, to give others visibility, and the possibility to tinker\n> with the topic branch during development (as we don't have full\n> inter-site sharing of work areas), I would push the topic branch up to\n> the central \"origin\" server, often with a \"kbracey/\" prefix, partially\n> for namespacing, and partially to indicate it's currently \"private\"\n> work and subject to rebasing. I guess I could create the topic branch\n> as \"kbracey/topic\" locally, but I'd rather not have to.\n\nYup, that is sensible, and I think with Felipe's proposed change,\nyou can spell it like this:\n\n [branch \"topic\"]\n\tremote = origin\n\tmerge = refs/heads/master\n push = refs/heads/kbracey/topic\n\nNote that the above assumes you did \"checkout -t -b topic origin/master\"\nas a typesaver for \"git rebase\".\n\n> So I'd like \"git rebase (-i)\" to move my topic branch up\n> (origin/)master. And I'd like \"git push (-f)\" to send it to\n> \"origin/kbracey/topic\". \n\nUnderstood. And I think the [branch \"topic\"] configuration above\nwould cover that use case.\n\n> And by extension, I suppose \"git pull --rebase\" to update origin/master\n> and rebase. (Although I'm not much of a puller - I tend to fetch\n> then rebase manually).\n\n\"git pull --rebase\" would be \"git fetch\" followed by \"git rebase\",\nand again the [branch \"topic\"] configuration above would cover that\nuse case, I think.\n\n> And it would be ideal if the initial base and push tracking\n> information could be set up automatically on the first \"git checkout\n> -b\"/\"git branch\" and \"git push\".\n\nI think checkout and branch is already covered with -t. There may\neven be a configuration option to implicitly add -t to them (I\ndidn't check).\n\n> (For one, I've always found it odd\n> that there's an asymmetry - if you check out a topic branch from the\n> server to work on or use it, you get a local copy with upstream set by\n> default. But if you create a topic branch yourself then push it, the\n> upstream isn't set by default - you need the -u flag. This seems odd\n> to me, and I've seen others confused by this).\n\nYeah, I would imagine that it would be trivial to add an option to\ncause \"git push\" to do that, and it would be useful if you push to\nand pull from the same place (I haven't thought about ramifications\nsuch an option would have on the triangular workflows, though).\n\nThanks.\n"},{"id":"217852","messageId":"5198897048728_76e0f31e20807dc@nysa.mail","threadId":"33827","inReplyTo":"7vbo871obk.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC] New kind of upstream branch: base branch","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-19T08:12:32Z","receivedAt":"2013-05-19T08:12:32Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Kevin Bracey writes:\n\n> > And it would be ideal if the initial base and push tracking\n> > information could be set up automatically on the first \"git checkout\n> > -b\"/\"git branch\" and \"git push\".\n> \n> I think checkout and branch is already covered with -t. There may\n> even be a configuration option to implicitly add -t to them (I\n> didn't check).\n\nbranch.autosetupmerge=always\n\n> > (For one, I've always found it odd\n> > that there's an asymmetry - if you check out a topic branch from the\n> > server to work on or use it, you get a local copy with upstream set by\n> > default. But if you create a topic branch yourself then push it, the\n> > upstream isn't set by default - you need the -u flag. This seems odd\n> > to me, and I've seen others confused by this).\n> \n> Yeah, I would imagine that it would be trivial to add an option to\n> cause \"git push\" to do that, and it would be useful if you push to\n> and pull from the same place (I haven't thought about ramifications\n> such an option would have on the triangular workflows, though).\n\nIt would work wonderfully. Now:\n\n== remote ==\n\n% git checkout -b master origin/master\n# work\n% git push\n\n== local ==\n\n% git checkout -b topic master\n# work\n% git push # ERR\n% git push -u origin/master\n# work\n% git push # ERR\n\nThat doesn't work. We could set branch.autosetupmerge=always as the default,\nbut it still wouldn't work, because push.default=simple (or at least it will\nbe), and the names don't match.\n\nBut with my patches, and branch.autosetupmerge=always (hopefully for 2.0):\n\n== local ==\n\n% git checkout -b topic master\n# work\n% git push # ERR\n% git push --set-downstream origin/master\n# work\n% git push\n\nCheers.\n\n-- \nFelipe Contreras\n"}]}