On 14-05-01 05:46 AM, brian m. carlson wrote:
> On Wed, Apr 30, 2014 at 05:25:59PM -0500, Felipe Contreras wrote:
>> Marc Branchaud wrote:
>>> On 14-04-30 04:14 PM, Felipe Contreras wrote:
>>>> What is wrong when `git pull` merges a fast-forward?
>>> Nothing. Everything. It depends.
>> It depends on what? I don't see how a fast-forward `git pull` could
>> possibly have any trouble.
>>>> The problems with `git pull` come when you can't do a fast-forward merge,
>>> Some of them, maybe most of them.
>> Name one problem with a fast-forward merge.
> At work, we have a workflow where we merge topic branches as
> non-fast-forward, so that we have a record of the history (including who
> reviewed the code), but when we want to just update our local branches,
> we always want fast-forward:
> 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
Thanks for the nice example.
To me this looks like an advanced use of "git pull". A new user could be
taught to work like this, but I don't think a new user would come up with it
on their own (until they became an experienced user).
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
I suggest that this approach is superior for new users (despite the increased
risk of finger cramps), because if main-repo's maintenance-branch is updated
in the interim and the push fails, the user can use the exact same commands
to resolve the situation.
Sure, the non-pull approach makes use of Scary Branch Stuff (remotes and
namespaces and detached HEADs -- oh my!). But trying to avoid that stuff is
precisely the slippery slope that led to pull's misguided gymnastics. We've
gone down that slope, slipped and fallen over, and now we're wallowing in the
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html