[git-users] Question: git merge origin/master
Hi all. This is just a simple question. Most of the discussions of merge from master to my branch I've seen recommend this: git checkout master git pull git checkout mybranch git merge master I did things this way at first, but as I understood git more it seemed to me that far simpler, and completely equivalent (with the exception that the master branch is not updated, which is fine) would be: git fetch git merge origin/master Is there some downside to this alternative that I'm not seeing, or other consideration (philosophical or otherwise) that should be taken? Cheers! -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] Question: git merge origin/master
On Thu, 13 Jun 2013 11:00:42 -0400 Paul Smith p...@mad-scientist.net wrote: Hi all. This is just a simple question. Most of the discussions of merge from master to my branch I've seen recommend this: git checkout master git pull git checkout mybranch git merge master I did things this way at first, but as I understood git more it seemed to me that far simpler, and completely equivalent (with the exception that the master branch is not updated, which is fine) would be: git fetch git merge origin/master Is there some downside to this alternative that I'm not seeing, or other consideration (philosophical or otherwise) that should be taken? If you have a local branch named master which is set to track origin/master, the second sequence won't update it because `git pull` in the first sequence does fetching *and* then merging of what was fetched into the currently checked out branch -- master. Note that you might as well be *not* interesting in having such a local master branch at all! For instance, if you intend to contribute to someone else's project, and forked a local branch my-feature off that repo's master branch, you might freely go on with the approach you asked about -- that is, fetch from the remote periodically and then -- at key times -- integrate the updated remote's master branch into your local branch. But note that in this particular case you might be interested in periodical rebasing your local branch instead. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] Question: git merge origin/master
On Thu, 2013-06-13 at 19:30 +0400, Konstantin Khomoutov wrote: On Thu, 13 Jun 2013 11:00:42 -0400 Paul Smith p...@mad-scientist.net wrote: Hi all. This is just a simple question. Most of the discussions of merge from master to my branch I've seen recommend this: git checkout master git pull git checkout mybranch git merge master I did things this way at first, but as I understood git more it seemed to me that far simpler, and completely equivalent (with the exception that the master branch is not updated, which is fine) would be: git fetch git merge origin/master Is there some downside to this alternative that I'm not seeing, or other consideration (philosophical or otherwise) that should be taken? If you have a local branch named master which is set to track origin/master, the second sequence won't update it because `git pull` in the first sequence does fetching *and* then merging of what was fetched into the currently checked out branch -- master. Yes, sure, that's why I said above with the exception that the master branch is not updated. That doesn't matter to me at this point because I just want my branch updated. Later on, when I want to merge my branch back to master, of course I would update master first then merge from my branch, then finally push to origin. Remember I'm trying to reproduce the result in the first sequence above, the goal of which is to merge from the upstream master branch into my work branch. Note that you might as well be *not* interesting in having such a local master branch at all! Possibly but that's not the question above. In our environment we are required to merge our own branches to master in our own repo, then push the result to the upstream git server. So I do need a local master branch which tracks origin/master. The question above is talking only about intermediate merge steps, where I want to bring in other peoples' changes into my work branch before I merge back to master. I'm just wondering if there's some issue with merging directly from origin/master, rather than first updating my local master and merging from that. I can't see one. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] Question: git merge origin/master
On Thu, 13 Jun 2013 11:37:42 -0400 Paul Smith p...@mad-scientist.net wrote: [...] The question above is talking only about intermediate merge steps, where I want to bring in other peoples' changes into my work branch before I merge back to master. I'm just wondering if there's some issue with merging directly from origin/master, rather than first updating my local master and merging from that. I can't see one. I can see one: commit ordering in case of your local master having unpushed commits at the time of doing `git pull` so that the resulting merge is a true merge, not a fast-forward. Otherwise there shouldn't be any differences. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
