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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
