Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
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 Go to next message
David M. Karr is currently offline David M. KarrFriend
Messages: 575
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 Go to previous messageGo to next message
Thomas Wolf is currently offline Thomas WolfFriend
Messages: 79
Registered: August 2016
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 Go to previous messageGo to next message
David M. Karr is currently offline David M. KarrFriend
Messages: 575
Registered: July 2009
Senior Member
Thomas Wolf wrote on Wed, 07 June 2017 03:32
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.


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 Go to previous messageGo to next message
Thomas Wolf is currently offline Thomas WolfFriend
Messages: 79
Registered: August 2016
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>".
Re: Exploring merging master to pull request branch [message #1765362 is a reply to message #1765270] Thu, 08 June 2017 18:52 Go to previous message
Matthias Sohn is currently offline Matthias SohnFriend
Messages: 1032
Registered: July 2009
Senior Member
in git there are two fundamentally different types of branches:

local branches:
- they are used in your local repository to create new commits and keep track of your local development work
- they move when you create a new commit, reset, merge, rebase, revert
- their full name is
refs/heads/<hierarchical branch name>
e.g.
refs/heads/my/favorite/local/branch

remote tracking branches:
- they are used in your local repository to keep track of branches living in remote repositories, most often residing on another host
- they cache locally where the respective branch was in the upstream remote repository when you last ran a fetch command,
this enables you to compare your local work done on local branches against the work pushed to the remote repository by your colleagues
without constantly having to communicate with the remote repository
- they only move when you download commits from the corresponding remote repository by running a git fetch
- git fetch will never update your local branches but only the remote tracking branches
- their full name is
refs/remotes/<remote name>/<hierarchical branch name>
e.g.
refs/remotes/origin/master
Previous Topic:Newb question: can JGIT support manual password entering
Next Topic:Strategies for repairing a branch after a misguided rebase
Goto Forum:
  


Current Time: Thu Sep 20 03:22:44 GMT 2018

Powered by FUDForum. Page generated in 0.02103 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top