Home » Eclipse Projects » EGit / JGit » Exploring merging master to pull request branch
| Exploring merging master to pull request branch [message #1765138] |
Tue, 06 June 2017 22:29  |
 David M. Karr
Messages: 801
Registered: July 2009 |
Senior Member |
|
|
So I've determined that my pull request branch has conflicts with master, so I want to use egit to resolve this. We use BitBucket server, which will have similarities to github.
I have several questions about this process that will be interspersed here, and I'd appreciate any comments about what I'm seeing here.
I imagine I would start at https://wiki.eclipse.org/EGit/User_Guide#Merging for a guide.
The first thing I wonder is why doesn't this guide present somewhat of a "goal-oriented" view? For instance, if BitBucket says "This pull request can't be merged." and that I have to resolve conflicts, it would be nice if this guide makes it clear that the task you have to approach is "merging master into my pull request branch". Actually, I believe that's what I have to do, but I'm not 100% certain. I have a feeling a lot of people have the same issue. They need to solve a particular problem, and it isn't completely clear from this guide how to bridge from the problem to the solutions described in this guide.
Next, the first choice of three presented in this section refers to "the History View". The History View? What exactly is that? There is a view in Eclipse called "History", but it really has nothing to do with this. What is this "History View" that this page is referring to?
For me, it probably makes more sense to start from "the Git Repositories View", so I'll proceed with that.
I'm currently on my pull request branch. As the "Merge..." dialog says "Select a branch or tag to merge into the '<pullrequest>' branch", I imagine I would select "master" at this point.
One question I have at this point, if I'm merging master to my pull request branch, do I need to do a "pull" on master first to ensure it's up to date? I've been working on my pull request branch for a while, and I haven't updated master in that period. Is this something this guide should be recommending? It will be slightly annoying if I have to switch to master, pull it, wait for it to build everything (our repo is larger than it should be), then switch back to the pull request branch.
Concerning the "merge options" and "fast forward options", I guess I won't change them from their defaults, but I wish this guide would give some info about those choices.
The messy part ahead is actually resolving conflicts, but I want to make sure my first steps are ok first.
|
|
|
| Re: Exploring merging master to pull request branch [message #1765184 is a reply to message #1765138] |
Wed, 07 June 2017 10:32  |
Thomas Wolf
Messages: 576
Registered: August 2016 |
Senior Member |
|
|
The history view is the view named "History", typically in the view stack bottom right in your Eclipse.
In the Git repositories view on a repository, choose Context Menu->Show In->History, and it'll show you the git history of that repository. That history view also has a button "Link with selection" (two yellow straight arrows, one pointing left, the other pointing right). Then that view will display the history of whatever is currently selected elsewhere in Eclipse.
Yes, you should first make sure your local git clone is up to date. Either switch to your master branch and do a pull, or alternatively you can do a "Fetch from upstream" and then you merge "origin/master" into your <pullrequest> branch.
Whether you want to merge or maybe instead rebase your <pullrequest> branch on origin/master is another question. I can't give you the answer, it'll depend on circumstances such as how many conflicting commits you have on your <pullrequest> branch, or how your shop works with git at all.
As for the EGit user's guide: while it certainly could be improved, it is not intended as a basic tutorial on how to work with git. There are several good tutorials out there; for instance http://www.vogella.com/tutorials/Git/article.html and http://www.vogella.com/tutorials/EclipseGit/article.html . The Git book at https://git-scm.com/book/en/v2 is also pretty good.
Caveat: I don't have personally much experience with Bitbucket/GitHub-style pull requests. We use Gerrit in our shop, which has a different model.
|
|
|
| Re: Exploring merging master to pull request branch [message #1765235 is a reply to message #1765184] |
Wed, 07 June 2017 17:44 |
David M. Karr
Messages: 801
Registered: July 2009 |
Senior Member |
|
|
Thomas Wolf wrote on Wed, 07 June 2017 03:32The history view is the view named "History", typically in the view stack bottom right in your Eclipse.
In the Git repositories view on a repository, choose Context Menu->Show In->History, and it'll show you the git history of that repository. That history view also has a button "Link with selection" (two yellow straight arrows, one pointing left, the other pointing right). Then that view will display the history of whatever is currently selected elsewhere in Eclipse.
Ok, this helps. By default, my history view is blank. It wasn't obvious that I had to do some configuration to get it to show anything useful.
Thomas Wolf wrote on Wed, 07 June 2017 03:32
Yes, you should first make sure your local git clone is up to date. Either switch to your master branch and do a pull, or alternatively you can do a "Fetch from upstream" and then you merge "origin/master" into your <pullrequest> branch.
I think what you're saying here is that doing "fetch from upstream" might be more efficient, but I could use a confirmation of this. If I'm currently on my pull request branch, doing the fetch would update my local copy of the master branch, without switching to the master branch. In addition, pulling on master would then cause all the impacted projects to be recompiled. It seems to me that doing the fetch would also avoid that extra step.
I believe that your statement about "then you merge ..." is not specific to the "alternatively" step, but something that would be done after either alternative (switch to master, pull, switch to pr branch or just fetching from upstream). Is that correct?
Thomas Wolf wrote on Wed, 07 June 2017 03:32
Whether you want to merge or maybe instead rebase your <pullrequest> branch on origin/master is another question. I can't give you the answer, it'll depend on circumstances such as how many conflicting commits you have on your <pullrequest> branch, or how your shop works with git at all.
Yeah, that's something that is a little mysterious to me. I understand the basic idea and difference between rebase and merge, but I've found the results from rebase to be confusing. I tried doing a rebase for this task originally, but I found that after the rebase, many of the files that were new to my pull request branch disappeared. Fortunately, I knew that I could checkout my last commit in detached mode to get access to those files again.
Thomas Wolf wrote on Wed, 07 June 2017 03:32
As for the EGit user's guide: while it certainly could be improved, it is not intended as a basic tutorial on how to work with git. There are several good tutorials out there; for instance http://www.vogella.com/tutorials/Git/article.html and http://www.vogella.com/tutorials/EclipseGit/article.html . The Git book at https://git-scm.com/book/en/v2 is also pretty good.
I've read that git book, and I agree that it's very helpful, but the problem is, most developers are not going to read that, and try to rely entirely on Eclipse resources. In addition, I think it can sometimes be non-obvious how to translate pure git concepts into egit operations.
Thomas Wolf wrote on Wed, 07 June 2017 03:32
Caveat: I don't have personally much experience with Bitbucket/GitHub-style pull requests. We use Gerrit in our shop, which has a different model.
Understood. I've worked with both, and I think for the scope of this particular set of problems, the models are equivalent in terms of the problems that developers have in getting past these issues.
|
|
|
| Re: Exploring merging master to pull request branch [message #1765270 is a reply to message #1765235] |
Wed, 07 June 2017 22:17 |
Thomas Wolf
Messages: 576
Registered: August 2016 |
Senior Member |
|
|
David M. Karr wrote on Wed, 07 June 2017 17:44
Thomas Wolf wrote on Wed, 07 June 2017 03:32
Yes, you should first make sure your local git clone is up to date. Either switch to your master branch and do a pull, or alternatively you can do a "Fetch from upstream" and then you merge "origin/master" into your <pullrequest> branch.
I think what you're saying here is that doing "fetch from upstream" might be more efficient, but I could use a confirmation of this. If I'm currently on my pull request branch, doing the fetch would update my local copy of the master branch, without switching to the master branch. In addition, pulling on master would then cause all the impacted projects to be recompiled. It seems to me that doing the fetch would also avoid that extra step.
I believe that your statement about "then you merge ..." is not specific to the "alternatively" step, but something that would be done after either alternative (switch to master, pull, switch to pr branch or just fetching from upstream). Is that correct?
"master" and "origin/master" are two different branches. Just do the fetch! Then look in the history view what commits "master" and "origin/master" point to! Fetching will not update your local branch "master".
So if you are on <pullrequest> and do a fetch, you then must merge "origin/master". If you merge "master" (a local branch), you won't get the desired result.
The other way is, as you have recognized, more complicated: checkout your local branch "master", pull, wait for the build to finish, checkout "<pullrequest>",wait for the buildto finish, merge "master" (or "origin/master",since they will point to the same commit after the pull) into "<pullrequest>".
|
|
| |
Goto Forum:
Current Time: Fri Apr 19 11:24:40 GMT 2024
Powered by FUDForum. Page generated in 0.01683 seconds |
] 
Search
Help
Register
Login
Home
