On 14-05-01 01:56 PM, W. Trevor King wrote: > On Thu, May 01, 2014 at 11:20:44AM -0400, Marc Branchaud wrote: >> On 14-05-01 05:46 AM, brian m. carlson wrote: >>> git checkout maintenance-branch >>> # Update our maintenance branch to the latest from the main repo. >>> git pull --ff-only >>> git pull --no-ff developer-remote topic-branch >>> git push main-repo HEAD >> >> … >> What's more, it seems to me that the only real advantage "git pull" provides >> here is a less typing compared to the non-pull equivalent: >> >> git fetch main-repo >> git checkout main-repo/maintenance-branch >> git fetch developer-remote >> git merge --no-ff developer-remote/topic-branch >> git push main-repo HEAD > > You're missing Brian's fast-forward merge here. It should be: > > git checkout maintenance-branch > git fetch main-repo > git merge --ff-only main-repo/maintenance-branch > git fetch developer-remote > … I think you're mistaken -- I checked out "main-repo/maintenance-branch" directly, so there's no need to fast-forward a local branch. >> Sure, the non-pull approach makes use of Scary Branch Stuff (remotes >> and namespaces and detached HEADs -- oh my!). > > No need for detached heads with Brian's local maintenance-branch. Yes. OTOH, no need to bother keeping a local maintenance-branch up to date if you use a detached HEAD. > If > you're teaching and just need folks merging the remote's HEAD, you > can avoid namespaces and remotes entirely: > > git fetch git://example.net/main-repo.git > git merge --ff-only FETCH_HEAD > > although I doubt “the remote's HEAD” will be easier to explain than > the namespaced, remote-tracking branches it replaces. It's certainly > not worth the hassle of un-training FETCH_HEAD-merges later on ;). Agreed. I wouldn't advocate teaching people about FETCH_HEAD as if it were something they should use regularly. M. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html