Community
Participate
Working Groups
I've been working in a topic branch for a few days. Now I want to rebase it on the latest master and then push. It seems really awkward. First try: Go to repo page and choose "Rebase" on the master branch. The tooltip looks promising ("starting the active branch based on the latest state in "master"...) but I'm doubtful since I haven't fetched master in awhile. Sure enough, it says I'm up to date. Next: I open up git log on the remote and fetch. But I don't want to merge into my active branch. I want to update the local tracking branch so that I can rebase on it. Do I really have to do this? 1) make master the active branch, 2) then fetch/merge the remote 3) then make the topic branch active again 4) then choose master and "rebase" If you have to make the rebase reference branch active in order to get it up to date, perhaps the rebase command should work the opposite way. I could go to the topic branch and choose rebase, and rebase would work by removing all commits on the selected (topic) branch and rebasing off the active (instead of vice versa as it is now). OR...we need a workflow for the reference branch to truly be brought up to date before the rebase.
What would a command line user do? Sequence of steps or is there a single command for this?
The simplest command line I can think of is (assuming topic branch is already checked out): git pull git rebase master If I only wanted to update master without touching others, I think I would have to checkout master: git checkout master git pull origin master git rebase master topic I think both of these have fairly direct mappings to Orion UI. I would do it like this: - Open the repositories page on my repo - Click "pull" at the top (fetch/merge all branches) - Click "rebase" next to the master branch I'm not saying we can't improve this, but I think our current UI maps pretty closely to what you get on the command line
(In reply to comment #2) > I think both of these have fairly direct mappings to Orion UI. I would do it > like this: > > - Open the repositories page on my repo > - Click "pull" at the top (fetch/merge all branches) > - Click "rebase" next to the master branch Are you sure step 2 works? If I'm in a new topic branch, using pull will fetch/merge my master without me having to go there? This is the step I was missing, I thought I had to switch branches simply to fetch/merge, then switch back in order to rebase.
(In reply to comment #3) > > Are you sure step 2 works? If I'm in a new topic branch, using pull will > fetch/merge my master without me having to go there? This is the step I was > missing, I thought I had to switch branches simply to fetch/merge, then switch > back in order to rebase. It won't quite work, as you can only merge into your checked out branch. For short-lived topic branches, the CLI steps to rebase on master: $ git fetch $ git rebase origin/master That'll rebase your topic branch on master without having to update your local master branch. You just have to remember to update it when you switch back to master. PW
(In reply to comment #4) > (In reply to comment #3) > > > > Are you sure step 2 works? If I'm in a new topic branch, using pull will > > fetch/merge my master without me having to go there? This is the step I was > > missing, I thought I had to switch branches simply to fetch/merge, then switch > > back in order to rebase. > > It won't quite work, as you can only merge into your checked out branch. This is exactly my complaint. The current workflow requires two checkouts (to master and back) in order for it to work. Does no one else find this annoying?
I guess I find the command overall nonintuitive. I've mentioned this before. It makes sense to me that if you pick "rebase" on a branch, you are rebasing THAT BRANCH. But the way it's implemented, you are rebasing the active branch onto the target. At a minimum we could rename it "rebase from" but I think it should really work the opposite way.
(In reply to comment #4) > It won't quite work, as you can only merge into your checked out branch. > > For short-lived topic branches, the CLI steps to rebase on master: > > $ git fetch > $ git rebase origin/master > > That'll rebase your topic branch on master without having to update your local > master branch. You just have to remember to update it when you switch back to > master. I can't believe this isn't bothering anyone else. Maybe it's the speed of the UI/changing branches that makes this feel so cumbersome. What I really want is a way to accomplish the command line version without having to change branches and back. Something like: - when you create a topic branch, you can establish what branch you want to keep up with (default to master). - Do work. - Occasionally choose a command like "rebase from master" which will fetch master and rebase the topic branch on it, without me having to switch to master, pull, switch back to topic branch, rebase. Basically, turn 4 steps into 1.
(In reply to comment #7) > > - when you create a topic branch, you can establish what branch you want to > keep up with (default to master). You have 2 choices. If you are working from one box and you never expect to push the topic branch up and then pull it down from another box, you can just create your topic branch to track and rebase off of origin/master (just like any other tracked branch). > - Do work. > - Occasionally choose a command like "rebase from master" which will fetch > master and rebase the topic branch on it, without me having to switch to > master, pull, switch back to topic branch, rebase. If you want to have a tracked topic branch that you occasionally rebase off of master, you don't have to do any switching. When you want to re-sync off of master, you just pick origin/master when you rebase (don't bother with master). Is it that your UI doesn't let you specify origin/master for the rebase directly? PW
(In reply to comment #8) > Is it that your UI doesn't let you specify origin/master for the rebase > directly? I believe it does.. Susan try this: - In Repositories page, click "View All" in the Branches section - Click Fetch Remote next to origin/master. - Click Rebase next to origin/master
(In reply to comment #9) > (In reply to comment #8) > > Is it that your UI doesn't let you specify origin/master for the rebase > > directly? Yes, it's that I have to think about how the page wants me to work, and it takes several steps to get to the point where I can do something. > > I believe it does.. Susan try this: > > - In Repositories page, click "View All" in the Branches section > - Click Fetch Remote next to origin/master. > - Click Rebase next to origin/master That's better than I thought it was. I didn't think to "view all" and go to the remote branch, but I think that's part of the issue. Maybe it's as simple as making sure that remote tracking branches are visible initially in the branches list so that I don't have to wait that 3-5 seconds to "view all".
Retitling bug. My initial question was: > Do I really have to do this? > 1) make master the active branch, > 2) then fetch/merge the remote > 3) then make the topic branch active again > 4) then choose master and "rebase" It seems like the answer is no. The current workflow is: > > - In Repositories page, click "View All" in the Branches section > > - Click Fetch Remote next to origin/master. > > - Click Rebase next to origin/master My problem with this is: - you have to already know that "view all" will give you the remote branch list and that you can perform the operation from there - you have a full page reload and a fetch of all branches, which takes some time So I think that if we include any tracking branches in the initial branch list, then the workflow becomes: - click fetch remote - click rebase No page reload, no changing branches, etc. etc. Szymon, is this something you could look at for 0.5? Since we are mentioning the tracking branches in the branch list we must know them and could put them in the list?
*** Bug 369297 has been marked as a duplicate of this bug. ***
I think this would be solved by the main repository UI changes I've proposed in bug 369604, comment 5.
Invalid.
