git and branches (was: [PATCH] [cygwin|mingw]: Add cross-compile support to cwrapper (take 6))

[Ralf Wildenhues]

Maybe a bit more explanation:

* Ralf Wildenhues wrote on Sat, Aug 28, 2010 at 07:22:42AM CEST:
> * Charles Wilson wrote on Sat, Aug 28, 2010 at 07:10:25AM CEST:
> > On 8/27/2010 3:47 PM, Ralf Wildenhues wrote:
> > > * Charles Wilson wrote on Fri, Aug 27, 2010 at 08:49:24PM CEST:
> > >> However, once I have finished the requested changes above and the
> > >> rebasing (plus whatever comes of the four open ***QQQ***uestions), I
> > >> might ask for a 12 hour halt on updates to master so I can run those
> > >> tests, if that's ok?
> > > 
> > > Why should you need the halt?  If there are new pushs in the meantime,
> > > you just merge origin/master into your master, and push. 
> > 
> > Doesn't that mess up the "linear" history of commits in the upstream
> > master?
> 
> Well, yes, if you want to call it "messing up", that is.  From git's
> perspective, origin/master and master are not the same branch in your
> repository.  Just that most of the time, you use fast-forward or rebase
> when getting the changes from the former into the latter.

With git, branch names are not permanent.  branches are merely movable
named pointers into some DAG, and when you delete a branch, all you
delete is the named pointer.  The only bit where branch names become
permanent is in the text of the (automatically generated) log entries
for merge commits.  And these are just for humans to read and digest,
so you could even change them after a merge (with commit --amend) if
you haven't made that merge public.

In that way, whether your master tracks origin/master is only relevant
for 'git pull' (namely, which remote branch to merge or rebase against)
and 'git status' messages.  In the case above, you would of course do
fetch and then merge rather than fetch and then rebase (not sure if your
pull is configured to rebase rather than merge).  FWIW, I've come to
never use pull, simply because it confuses me having to think about
which way was configured as default (merging or rebasing).

The branch concept is in contrast to some other dVCS where branch names
somehow permanently describe (possibly overlapping) subgraphs of the
full history graph.

Cheers,
Ralf