Re: Re: Pull is Evil

[Marc Branchaud <marcnarc@xiplink.com>]

On 14-05-01 02:30 PM, W. Trevor King wrote:
> 
> 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.