# [RFC] New kind of upstream branch: base branch 14 messages from 2013-05-15 to 2013-05-19. Participants: Felipe Contreras, Philip Oakley, Kevin Bracey, Junio C Hamano, Ramkumar Ramachandra. Thread: https://gitlist.dev/t/33827 ## Felipe Contreras, 2013-05-15 20:34 Subject: [RFC] New kind of upstream branch: base branch Message-ID: URL: https://gitlist.dev/e/CAMP44s3LQ0GN4rrXdpb8Fe0iLeAEm2VjkH6BHK64pmX-xpc7%2BQ%40mail.gmail.com ``` Hi, I've been using Git from the start, but only lately have I forced myself to configure upstream branches for all my branches, and I've found a few things more convenient, but others completely contrary to what I expected. Inconvenient: Before, I used to do 'git fetch' to simply fetch from 'origin', but now, it depends on where 'upstream' is set to. Convinient: Now, I can just do 'git rebase --interactive' and I don't have to specify the starting point, which is particularily useful when there's a lot of branches one depending on another. I think I'm using 'upstream' for something it was not intended to, and I think the current 'upstream' behavior should be split into 'upstream' and 'base'. == base == The 'base' branch will be set each time you create a branch from another; 'git checkout -b foobar master' sets 'master' as the 'base' of 'foobar'. Then you can do 'git rebase foobar@{base}' or simply 'git rebase', and Git will pick the right branch to rebase unto, even if you have no 'upstream' configured. This way 'git fetch' will keep picking 'origin', and other commands that make use of 'upstream' would be undisturbed. If both 'base' and 'upstream' are defined, I think 'git rebase' should use 'base', but since that would break old behavior, perhaps there should be a configuration variable to enable a different behavior. I already started writting the patches, and although tedious, I think they they'll be rather straightforward, but I thought it would be best to hear some opinions first. What do you think? -- Felipe Contreras ``` ## Philip Oakley, 2013-05-15 22:22 Subject: Re: [RFC] New kind of upstream branch: base branch Message-ID: URL: https://gitlist.dev/e/AE3E8FA3205F42C5B11F3617987BEA05%40PhilipOakley In-Reply-To: ``` From: "Felipe Contreras" Sent: Wednesday, May 15, 2013 9:34 PM > Hi, > > I've been using Git from the start, but only lately have I forced > myself to configure upstream branches for all my branches, and I've > found a few things more convenient, but others completely contrary to > what I expected. > > Inconvenient: > > Before, I used to do 'git fetch' to simply fetch from 'origin', but > now, it depends on where 'upstream' is set to. > > Convinient: > > Now, I can just do 'git rebase --interactive' and I don't have to > specify the starting point, which is particularily useful when there's > a lot of branches one depending on another. > > I think I'm using 'upstream' for something it was not intended to, and > I think the current 'upstream' behavior should be split into > 'upstream' and 'base'. > > == base == > > The 'base' branch will be set each time you create a branch from > another; > 'git checkout -b foobar master' sets 'master' as the 'base' of > 'foobar'. > > Then you can do 'git rebase foobar@{base}' or simply 'git rebase', and > Git will pick the right branch to rebase unto, even if you have no > 'upstream' > configured. > > This way 'git fetch' will keep picking 'origin', and other commands > that make use of 'upstream' would be undisturbed. > > If both 'base' and 'upstream' are defined, I think 'git rebase' should > use 'base', but since that would break old behavior, perhaps there > should be a configuration variable to enable a different behavior. > > I already started writting the patches, and although tedious, I think > they they'll be rather straightforward, but I thought it would be best > to hear some opinions first. > > What do you think? > > -- > Felipe Contreras --- Sound a reasonable idea. On some patches I was working on I had to [chose to] add a tag for the base which made it easier to rebase later. The other point is that I had already noted that the glossary doesn't include the many "base" terms in use that aren't always well understood. Philip Oakley ``` ## Felipe Contreras, 2013-05-16 03:46 Subject: Re: [RFC] New kind of upstream branch: base branch Message-ID: URL: https://gitlist.dev/e/CAMP44s13Q6DMX%2BQNteqO8D-J7bDcNyp7OkRVqj6B1Qhp0OSB%2BQ%40mail.gmail.com In-Reply-To: ``` On Wed, May 15, 2013 at 5:22 PM, Philip Oakley wrote: > Sound a reasonable idea. On some patches I was working on I had to [chose > to] add a tag for the base which made it easier to rebase later. And was the 'upstream' branch somehow not appropriate for some reason? -- Felipe Contreras ``` ## Philip Oakley, 2013-05-16 19:35 Subject: Re: [RFC] New kind of upstream branch: base branch Message-ID: URL: https://gitlist.dev/e/D6098E29305740EE916958521A797AB9%40PhilipOakley In-Reply-To: ``` From: "Felipe Contreras" Sent: Thursday, May 16, 2013 4:46 AM > On Wed, May 15, 2013 at 5:22 PM, Philip Oakley > wrote: > >> Sound a reasonable idea. On some patches I was working on I had to >> [chose >> to] add a tag for the base which made it easier to rebase later. > > And was the 'upstream' branch somehow not appropriate for some reason? If I remember correctly, I had a short branch based on 'pu', which was rewound, so I wanted to rebase that short branch onto the new 'pu'. This creates a confusion between old-pu and new-pu. Having a marker for the 'base' at the branch point allowed an easy specification of the branch I think I misunderstood your proposal. I thought that it would effectively save a marker (e.g. the sha1) for the base point of the branch, it may have been something similar to a [lightweight] tag, it could have been just local or could have been transferable, I hadn't thought it further. Philip ``` ## Felipe Contreras, 2013-05-17 00:07 Subject: Re: [RFC] New kind of upstream branch: base branch Message-ID: URL: https://gitlist.dev/e/CAMP44s3UjDUWb_ng5NhLB2tMV0gqsRx_Ob%3Dvj3P5RVfigD1r7Q%40mail.gmail.com In-Reply-To: ``` On Thu, May 16, 2013 at 2:35 PM, Philip Oakley wrote: > From: "Felipe Contreras" > Sent: Thursday, May 16, 2013 4:46 AM > >> On Wed, May 15, 2013 at 5:22 PM, Philip Oakley >> wrote: >> >>> Sound a reasonable idea. On some patches I was working on I had to [chose >>> to] add a tag for the base which made it easier to rebase later. >> >> >> And was the 'upstream' branch somehow not appropriate for some reason? > > > If I remember correctly, I had a short branch based on 'pu', which was > rewound, so I wanted to rebase that short branch onto the new 'pu'. This > creates a confusion between old-pu and new-pu. Having a marker for the > 'base' at the branch point allowed an easy specification of the branch So you were not doing 'git rebase @{base}', you were doing 'git rebase --onto X @{base}'? > I think I misunderstood your proposal. I thought that it would effectively > save a marker (e.g. the sha1) for the base point of the branch, it may have > been something similar to a [lightweight] tag, it could have been just local > or could have been transferable, I hadn't thought it further. Yeah, I thought about that, and I think it might make sense, but that's another topic. -- Felipe Contreras ``` ## Kevin Bracey, 2013-05-17 19:20 Subject: Re: [RFC] New kind of upstream branch: base branch Message-ID: <51968311.1020107@bracey.fi> URL: https://gitlist.dev/e/51968311.1020107%40bracey.fi In-Reply-To: ``` On 15/05/2013 23:34, Felipe Contreras wrote: > > I think I'm using 'upstream' for something it was not intended to, and > I think the current 'upstream' behavior should be split into > 'upstream' and 'base'. > I found myself thinking the same thing. It's really convenient being able to set your topic branch's upstream to another local branch, so git rebase works without parameters. But then I can't use upstream to point to a remote version of that topic branch. I want my topic branch to know both that it's based on master (or origin/master), and that it's upstream is origin/topic. So, yes, here's a vote in favour of the general concept. Kevin ``` ## Junio C Hamano, 2013-05-17 19:51 Subject: Re: [RFC] New kind of upstream branch: base branch Message-ID: <7va9ntxu3w.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7va9ntxu3w.fsf%40alter.siamese.dyndns.org In-Reply-To: <51968311.1020107@bracey.fi> ``` Kevin Bracey writes: > On 15/05/2013 23:34, Felipe Contreras wrote: >> I think I'm using 'upstream' for something it was not intended to, >> and >> I think the current 'upstream' behavior should be split into >> 'upstream' and 'base'. >> > I found myself thinking the same thing. It's really convenient being > able to set your topic branch's upstream to another local branch, so What is that "another local branch"? Is the use case "master forks from origin/master and has its own changes on top, and then topic builds on my master but the range of commits origin/master..topic includes both changes, that is inconvenient to when rebuilding topic on top of my master"? I'd assume that it is the case, and the answer to the previous question is 'master' in the example. > git rebase works without parameters. But then I can't use upstream to > point to a remote version of that topic branch. I want my topic branch > to know both that it's based on master (or origin/master), and that > it's upstream is origin/topic. If we do s/and that it's upstream is/and that it is pushed to/, then I think I am in general agreement (I wrote about it earlier in a separate message). > So, yes, here's a vote in favour of the general concept. Yes, you should be able to treat what you build on top (upstream) and where you publish the result (we are still looking for a better name in the other thread) as two distinct things in a triangular workflow. I agree that it is an issue we need to address. We have solved a half ("push goes to a different repository") but not the other half ("updates a branch whose name is different from the upstream") in the upcoming 1.8.3 release. The latest round of design from Felipe calls it branch.$name.push, if I am not mistaken. I think it is somewhat an overkill, though. It is normal for upstream's name not to match the topic's name (i.e. your 'topic' may branch off of a generic 'master', but would be named after a more specific purpose of the branch and is unlikely to be named 'master'. In other words, branch.$name.merge that points at an upstream that has a name that is totally different from $name is not an exception. So branch.$name.merge that you have to set for each branch is a necessity. However, if you were to push out 'topic' directly (as opposed to pushing out a result of integrating it and other topic branches to your 'master') to your own publishing point, it is likely you would push it out to the same name (i.e. 'topic' will be pushed out as 'topic', not as 'master'). And if that is your workflow, setting push.default to "current" (and setting remote.pushdefault to your publishing repository) should be a sufficient interim solution, and you do not need to set branch.$name.push to each and every branch you intend to push out, I think. ``` ## Felipe Contreras, 2013-05-17 20:01 Subject: Re: [RFC] New kind of upstream branch: base branch Message-ID: URL: https://gitlist.dev/e/CAMP44s1N4XpR4W-DgGgZrBPp-xe%2B14JpRTAXs%3DC0CdAb149nfQ%40mail.gmail.com In-Reply-To: <51968311.1020107@bracey.fi> ``` On Fri, May 17, 2013 at 2:20 PM, Kevin Bracey wrote: > On 15/05/2013 23:34, Felipe Contreras wrote: >> >> I think I'm using 'upstream' for something it was not intended to, and >> I think the current 'upstream' behavior should be split into >> 'upstream' and 'base'. >> > I found myself thinking the same thing. It's really convenient being able to > set your topic branch's upstream to another local branch, so git rebase > works without parameters. But then I can't use upstream to point to a remote > version of that topic branch. I want my topic branch to know both that it's > based on master (or origin/master), and that it's upstream is origin/topic. If you are in your topic branch, what do you expect 'git pull' to do? And what do you expect 'git push' to do? -- Felipe Contreras ``` ## Felipe Contreras, 2013-05-17 20:15 Subject: Re: [RFC] New kind of upstream branch: base branch Message-ID: URL: https://gitlist.dev/e/CAMP44s14CtWS%3DcGsF%3DZqYPrCmSPjjc-8XQFZ7gD%3D%3DDg8sESRfQ%40mail.gmail.com In-Reply-To: <7va9ntxu3w.fsf@alter.siamese.dyndns.org> ``` On Fri, May 17, 2013 at 2:51 PM, Junio C Hamano wrote: > Kevin Bracey writes: > >> On 15/05/2013 23:34, Felipe Contreras wrote: >>> I think I'm using 'upstream' for something it was not intended to, >>> and >>> I think the current 'upstream' behavior should be split into >>> 'upstream' and 'base'. >>> >> I found myself thinking the same thing. It's really convenient being >> able to set your topic branch's upstream to another local branch, so > > What is that "another local branch"? refs/heads/* > Is the use case "master forks from origin/master and has its own > changes on top, and then topic builds on my master but the range of > commits origin/master..topic includes both changes, that is > inconvenient to when rebuilding topic on top of my master"? No it's not. You just 'git rebase -i' and everything works. > I'd assume that it is the case, and the answer to the previous > question is 'master' in the example. > >> git rebase works without parameters. But then I can't use upstream to >> point to a remote version of that topic branch. I want my topic branch >> to know both that it's based on master (or origin/master), and that >> it's upstream is origin/topic. > > If we do s/and that it's upstream is/and that it is pushed to/, then > I think I am in general agreement (I wrote about it earlier in a > separate message). > >> So, yes, here's a vote in favour of the general concept. > > Yes, you should be able to treat what you build on top (upstream) > and where you publish the result (we are still looking for a better > name in the other thread) as two distinct things in a triangular > workflow. I agree that it is an issue we need to address. > > We have solved a half ("push goes to a different repository") but > not the other half ("updates a branch whose name is different from > the upstream") in the upcoming 1.8.3 release. > > The latest round of design from Felipe calls it branch.$name.push, > if I am not mistaken. > > I think it is somewhat an overkill, though. It is needed. > It is normal for upstream's name not to match the topic's name > (i.e. your 'topic' may branch off of a generic 'master', but would > be named after a more specific purpose of the branch and is unlikely > to be named 'master'. In other words, branch.$name.merge that > points at an upstream that has a name that is totally different from > $name is not an exception. So branch.$name.merge that you have to > set for each branch is a necessity. > > However, if you were to push out 'topic' directly (as opposed to > pushing out a result of integrating it and other topic branches to > your 'master') to your own publishing point, it is likely you would > push it out to the same name (i.e. 'topic' will be pushed out as > 'topic', not as 'master'). Likely, but not certain. > And if that is your workflow, setting > push.default to "current" (and setting remote.pushdefault to your > publishing repository) should be a sufficient interim solution, and > you do not need to set branch.$name.push to each and every branch > you intend to push out, I think. If git needs configurations to behave sanely, git is broken. If we set: branch.autosetupmerge = always push.default = simple By default in v2.0, and there's a UI to set remote.pushdefault, then I might be inclined to agree that branch.$name.push is overkill. But I don't see that happening; the user still needs a sane way to make trivial workflows work without hacking the configuration. -- Felipe Contreras ``` ## Kevin Bracey, 2013-05-18 14:29 Subject: Re: [RFC] New kind of upstream branch: base branch Message-ID: <51979065.4060609@bracey.fi> URL: https://gitlist.dev/e/51979065.4060609%40bracey.fi In-Reply-To: <7va9ntxu3w.fsf@alter.siamese.dyndns.org> ``` On 17/05/2013 22:51, Junio C Hamano wrote: > Kevin Bracey writes: > >> On 15/05/2013 23:34, Felipe Contreras wrote: >>> I think I'm using 'upstream' for something it was not intended to, >>> and >>> I think the current 'upstream' behavior should be split into >>> 'upstream' and 'base'. >>> >> I found myself thinking the same thing. It's really convenient being >> able to set your topic branch's upstream to another local branch, so > What is that "another local branch"? ... And if that is your workflow, setting > push.default to "current" (and setting remote.pushdefault to your > publishing repository) should be a sufficient interim solution, and > you do not need to set branch.$name.push to each and every branch > you intend to push out, I think. I agree that using "push.default current" covers some cases - I hadn't really considered it - tended to just stick with "upstream". "current" nearly does the job, but I will sometimes be wanting different names. What I'll often be doing is creating a topic branch based on master or origin/master. (I would hardly ever be updating master or pushing to origin/master myself, so I probably should be just doing origin/master, but I tend to create a local master just to save typing on all those "git rebase origin/master"). During work, to give others visibility, and the possibility to tinker with the topic branch during development (as we don't have full inter-site sharing of work areas), I would push the topic branch up to the central "origin" server, often with a "kbracey/" prefix, partially for namespacing, and partially to indicate it's currently "private" work and subject to rebasing. I guess I could create the topic branch as "kbracey/topic" locally, but I'd rather not have to. So I'd like "git rebase (-i)" to move my topic branch up (origin/)master. And I'd like "git push (-f)" to send it to "origin/kbracey/topic". And by extension, I suppose "git pull --rebase" to update origin/master and rebase. (Although I'm not much of a puller - I tend to fetch then rebase manually). The final releasing procedure for the topic branch would be to hand that branch over to an integrator, who would then merge/rebase it into master. And it would be ideal if the initial base and push tracking information could be set up automatically on the first "git checkout -b"/"git branch" and "git push". (For one, I've always found it odd that there's an asymmetry - if you check out a topic branch from the server to work on or use it, you get a local copy with upstream set by default. But if you create a topic branch yourself then push it, the upstream isn't set by default - you need the -u flag. This seems odd to me, and I've seen others confused by this). Kevin ``` ## Ramkumar Ramachandra, 2013-05-18 18:14 Subject: Re: [RFC] New kind of upstream branch: base branch Message-ID: URL: https://gitlist.dev/e/CALkWK0nQVkmq%2BOdhWhM2EnZKmHxzLQonhd2tUeUvqJNf27GCXA%40mail.gmail.com In-Reply-To: <51979065.4060609@bracey.fi> ``` Kevin Bracey wrote: > What I'll often be doing is creating a topic branch based on master or > origin/master. (I would hardly ever be updating master or pushing to > origin/master myself, so I probably should be just doing origin/master, but > I tend to create a local master just to save typing on all those "git rebase > origin/master"). branch..merge was designed primarily for pull and merge. I use operations like git diff origin.., git log origin.., git rebase [-i] origin. Ofcourse, rebase is a bit of a special case because it defaults to operating on branch..merge by default: this is useful to me when I want to rebase against what I just fetched (central workflows: we're slowly getting triangular workflows). Abusing branch..merge because you want a different default for rebase means we're doing something wrong. Perhaps we should get a rebase.defaultUpstream = @{u}|origin|... -- @{u} being the current default. In my opinion, branch..base is a huge overkill. > During work, to give others visibility, and the possibility to tinker with > the topic branch during development (as we don't have full inter-site > sharing of work areas), I would push the topic branch up to the central > "origin" server, often with a "kbracey/" prefix, partially for namespacing, > and partially to indicate it's currently "private" work and subject to > rebasing. I guess I could create the topic branch as "kbracey/topic" > locally, but I'd rather not have to. All we have to do for this is to allow the user to set a custom refspec using remote..push. The refspecs you get now are limited to the ones set by the different modes of push.default (see builtin/push.c to see what refspec each of them set). We discussed branch..push too on another thread, but I'm not convinced that we need it. > (Although I'm not much of a puller - I tend to fetch then rebase manually). pull needs to be fixed. I've partially fixed the rebasing pull thing with rebase.autostash (still in pu), but there's a lot of work to be done there. > And it would be ideal if the initial base and push tracking information > could be set up automatically on the first "git checkout -b"/"git branch" > and "git push". (For one, I've always found it odd that there's an asymmetry > - if you check out a topic branch from the server to work on or use it, you > get a local copy with upstream set by default. But if you create a topic > branch yourself then push it, the upstream isn't set by default - you need > the -u flag. This seems odd to me, and I've seen others confused by this). It happens because @{u} doesn't exist before the first push. We should definitely fix git checkout -b to inherit branch..remote and infer branch..merge. To sum it up, lots of work to be done. ``` ## Felipe Contreras, 2013-05-18 22:42 Subject: Re: [RFC] New kind of upstream branch: base branch Message-ID: URL: https://gitlist.dev/e/CAMP44s2dZkRUOQmKwmP_ruXfZemjTjEapTvdt276_d%2BNRZ8vhA%40mail.gmail.com In-Reply-To: <51979065.4060609@bracey.fi> ``` On Sat, May 18, 2013 at 9:29 AM, Kevin Bracey wrote: > On 17/05/2013 22:51, Junio C Hamano wrote: >> >> Kevin Bracey writes: >> >>> On 15/05/2013 23:34, Felipe Contreras wrote: >>>> >>>> I think I'm using 'upstream' for something it was not intended to, >>>> and >>>> I think the current 'upstream' behavior should be split into >>>> 'upstream' and 'base'. >>>> >>> I found myself thinking the same thing. It's really convenient being >>> able to set your topic branch's upstream to another local branch, so >> >> What is that "another local branch"? ... And if that is your workflow, >> setting >> >> push.default to "current" (and setting remote.pushdefault to your >> publishing repository) should be a sufficient interim solution, and >> you do not need to set branch.$name.push to each and every branch >> you intend to push out, I think. > > > I agree that using "push.default current" covers some cases - I hadn't > really considered it - tended to just stick with "upstream". "current" > nearly does the job, but I will sometimes be wanting different names. > > What I'll often be doing is creating a topic branch based on master or > origin/master. (I would hardly ever be updating master or pushing to > origin/master myself, so I probably should be just doing origin/master, but > I tend to create a local master just to save typing on all those "git rebase > origin/master"). > > During work, to give others visibility, and the possibility to tinker with > the topic branch during development (as we don't have full inter-site > sharing of work areas), I would push the topic branch up to the central > "origin" server, often with a "kbracey/" prefix, partially for namespacing, > and partially to indicate it's currently "private" work and subject to > rebasing. I guess I could create the topic branch as "kbracey/topic" > locally, but I'd rather not have to. > > So I'd like "git rebase (-i)" to move my topic branch up (origin/)master. > And I'd like "git push (-f)" to send it to "origin/kbracey/topic". And by > extension, I suppose "git pull --rebase" to update origin/master and rebase. > (Although I'm not much of a puller - I tend to fetch then rebase manually). > > The final releasing procedure for the topic branch would be to hand that > branch over to an integrator, who would then merge/rebase it into master. > > And it would be ideal if the initial base and push tracking information > could be set up automatically on the first "git checkout -b"/"git branch" > and "git push". (For one, I've always found it odd that there's an asymmetry > - if you check out a topic branch from the server to work on or use it, you > get a local copy with upstream set by default. But if you create a topic > branch yourself then push it, the upstream isn't set by default - you need > the -u flag. This seems odd to me, and I've seen others confused by this). Indeed, and I agree. I've started to set branch.autosetupmerge=always, so I always get an upstream no matter what. The only problem is that 'git fetch' now is useless without any argument, but that can be fixed with another configuration 'fetch.default=simple', so that it always fetches from origin, no matter what. Then, everything is consistent, it doesn't matter what 'branch.autosetupmerge' you have configured, and in which branch you are sitting at, 'git fetch' will always do something useful. The missing problem is that you have to manually do 'git push origin kbracey/topic', and that can be solved with the concept of a downstream (branch.x.remotepush+branch.x.push). If we have these two changes, everything would work perfectly, wouldn't it? -- Felipe Contreras ``` ## Junio C Hamano, 2013-05-19 06:22 Subject: Re: [RFC] New kind of upstream branch: base branch Message-ID: <7vbo871obk.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7vbo871obk.fsf%40alter.siamese.dyndns.org In-Reply-To: <51979065.4060609@bracey.fi> ``` Kevin Bracey writes: >>> I found myself thinking the same thing. It's really convenient being >>> able to set your topic branch's upstream to another local branch, so > >> What is that "another local branch"? ... And if that is your workflow, setting >> push.default to "current" (and setting remote.pushdefault to your >> publishing repository) should be a sufficient interim solution, and >> you do not need to set branch.$name.push to each and every branch >> you intend to push out, I think. > > I agree that using "push.default current" covers some cases - I hadn't > really considered it - tended to just stick with "upstream". "current" > nearly does the job, but I will sometimes be wanting different names. > What I'll often be doing is creating a topic branch based on master or > origin/master. (I would hardly ever be updating master or pushing to > origin/master myself, so I probably should be just doing > origin/master, but I tend to create a local master just to save typing > on all those "git rebase origin/master"). Do you mean, by "save typing", "instead of origin/master, I can type master"? If you are using the "checkout -t -b topic origin/master", "git rebase" without any other argument should know that you meant to rebase against 'origin/master', so you do not even have to type 'master'. > During work, to give others visibility, and the possibility to tinker > with the topic branch during development (as we don't have full > inter-site sharing of work areas), I would push the topic branch up to > the central "origin" server, often with a "kbracey/" prefix, partially > for namespacing, and partially to indicate it's currently "private" > work and subject to rebasing. I guess I could create the topic branch > as "kbracey/topic" locally, but I'd rather not have to. Yup, that is sensible, and I think with Felipe's proposed change, you can spell it like this: [branch "topic"] remote = origin merge = refs/heads/master push = refs/heads/kbracey/topic Note that the above assumes you did "checkout -t -b topic origin/master" as a typesaver for "git rebase". > So I'd like "git rebase (-i)" to move my topic branch up > (origin/)master. And I'd like "git push (-f)" to send it to > "origin/kbracey/topic". Understood. And I think the [branch "topic"] configuration above would cover that use case. > And by extension, I suppose "git pull --rebase" to update origin/master > and rebase. (Although I'm not much of a puller - I tend to fetch > then rebase manually). "git pull --rebase" would be "git fetch" followed by "git rebase", and again the [branch "topic"] configuration above would cover that use case, I think. > And it would be ideal if the initial base and push tracking > information could be set up automatically on the first "git checkout > -b"/"git branch" and "git push". I think checkout and branch is already covered with -t. There may even be a configuration option to implicitly add -t to them (I didn't check). > (For one, I've always found it odd > that there's an asymmetry - if you check out a topic branch from the > server to work on or use it, you get a local copy with upstream set by > default. But if you create a topic branch yourself then push it, the > upstream isn't set by default - you need the -u flag. This seems odd > to me, and I've seen others confused by this). Yeah, I would imagine that it would be trivial to add an option to cause "git push" to do that, and it would be useful if you push to and pull from the same place (I haven't thought about ramifications such an option would have on the triangular workflows, though). Thanks. ``` ## Felipe Contreras, 2013-05-19 08:12 Subject: Re: [RFC] New kind of upstream branch: base branch Message-ID: <5198897048728_76e0f31e20807dc@nysa.mail> URL: https://gitlist.dev/e/5198897048728_76e0f31e20807dc%40nysa.mail In-Reply-To: <7vbo871obk.fsf@alter.siamese.dyndns.org> ``` Junio C Hamano wrote: > Kevin Bracey writes: > > And it would be ideal if the initial base and push tracking > > information could be set up automatically on the first "git checkout > > -b"/"git branch" and "git push". > > I think checkout and branch is already covered with -t. There may > even be a configuration option to implicitly add -t to them (I > didn't check). branch.autosetupmerge=always > > (For one, I've always found it odd > > that there's an asymmetry - if you check out a topic branch from the > > server to work on or use it, you get a local copy with upstream set by > > default. But if you create a topic branch yourself then push it, the > > upstream isn't set by default - you need the -u flag. This seems odd > > to me, and I've seen others confused by this). > > Yeah, I would imagine that it would be trivial to add an option to > cause "git push" to do that, and it would be useful if you push to > and pull from the same place (I haven't thought about ramifications > such an option would have on the triangular workflows, though). It would work wonderfully. Now: == remote == % git checkout -b master origin/master # work % git push == local == % git checkout -b topic master # work % git push # ERR % git push -u origin/master # work % git push # ERR That doesn't work. We could set branch.autosetupmerge=always as the default, but it still wouldn't work, because push.default=simple (or at least it will be), and the names don't match. But with my patches, and branch.autosetupmerge=always (hopefully for 2.0): == local == % git checkout -b topic master # work % git push # ERR % git push --set-downstream origin/master # work % git push Cheers. -- Felipe Contreras ```