Re: Re: Pull is Evil

From: Marc Branchaud <marcnarc@xiplink.com>
Date: May 1, 2014, 20:21 UTC
Message-ID: <5362ACD6.50505@xiplink.com>
In-Reply-To: <20140501183008.GZ6227@odin.tremily.us>

On 14-05-01 02:30 PM, W. Trevor King wrote:

Show 7 quoted lines

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

All sound practices that I think are perfectly fine.

I may be mistaken, but I think "git pull" evolved to try to address the detached-HEAD risk (at least in part). This risk was pretty real before the reflog came about (I'm under the impression -- and too lazy to check -- that "git pull" predates the reflog; please forgive me if I'm mis-perceiving the timeline).

But these days there's hardly any risk to using a detached HEAD. Plus nowadays I think it's commonly accepted that using topic branches is a git best practice. The notion of doing work on a generically-named branch like "maint" seems archaic.

So what benefit does "git pull" provide?

In your particular case, you're using "git pull" to help you track your reviews of the upstream branch. To me this seems more like you taking advantage of a "git pull" side-effect than using the command as it is intended to be used. Certainly there are other ways that git can track this for you. A simple, aliasable, "git tag -f LastReviewPoint upstream/branch" seems just as effective to me (but then, I'm not you).

M.