Re: Re: Pull is Evil

From: W. Trevor King <wking@tremily.us>
Date: May 1, 2014, 18:30 UTC
Message-ID: <20140501183008.GZ6227@odin.tremily.us>
In-Reply-To: <53628CB1.8010302@xiplink.com>

On Thu, May 01, 2014 at 02:04:33PM -0400, Marc Branchaud wrote:

Show 31 quoted lines

> 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.

I find a local branch useful to mark the amount of the upstream branch that I've reviewed. The reflog helps a bit, but I may go several fetches between reviews. For newbies, I recommend avoiding detached HEADs, where possible, so they don't have to rely on the reflog if they accidentally commit and then checkout something else (ignoring Git's warning).

Cheers, Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy