Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued

From: Andreas Ericsson <ae@op5.se>
Date: Oct 25, 2007, 08:07 UTC
Message-ID: <47204ECA.7040309@op5.se>
In-Reply-To: <Pine.LNX.4.64.0710242315310.25221@racer.site>

Johannes Schindelin wrote:

Show 14 quoted lines

> Hi,
> 
> On Wed, 24 Oct 2007, Andreas Ericsson wrote:
> 
>> Conceptually, I don't think it'll be any problem what so ever telling 
>> anyone that the branches that aren't currently checked out get merged 
>> automatically only if they result in a fast-forward.
> 
> It would be a matter of seconds until someone asks "why only 
> fast-forwards?  Would it not be _much_ better to merge _always_?  Stupid 
> git."
> 
> And all because the concept of "local" vs "remote" was blurred.
>

It's already blurred, since we have git-pull instead of just git-fetch. pull is the dwim version of fetch for anyone who isn't frequently pulling from multiple repos that aren't configured as remotes (99% of git's users). It really is. You configure it to merge this and that branch to those and these branches. Sometimes it does and sometimes it doesn't, and the decision is based on what branch you're currently on.

Only git-fetch has the clear local vs remote distinction, because it *never* merges anything.

On a side-note, I'm starting to see why hg has gotten such a user-base. Their docs focus on one repo per branch, which doesn't have this problem at all.

So in short, letting "git-pull" fast-forward (or rebase; I like that idea)
the local copies of the remote tracking branches onto those remote tracking
branches will make life easier for:
* People who collaborate with others in a shared environment, where branch
  heads frequently change in the mothership repo but all development is
  supposed to be done at the tip of those mothership branches anyway.
  Nearly all corporate users fall into this category.
* People who just want to track and test the latest and greatest version of
  software X. Sometimes trying latest stable, and sometimes going with the
  freshest beta. They won't want to do "git merge beta origin/beta" after
  having done "git checkout beta", but they sure as hell don't want to run
  anything but the latest either. They may contribute once in a while, but
  generally just want to make sure they've got the bleeding edge.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231