Re: Dangers of working on a tracking branch

[Jeff King <peff@peff.net>]

On Thu, Feb 15, 2007 at 03:21:38PM -0600, Bill Lear wrote:

> Ok, so I break the model, what is the harm in that?  Can I no longer
> pull from or push to the remote branch?  Do I corrupt something
> locally?  Does something else break?  I'm trying to formulate an
> explanation to our users why the 1.5 way is superior and I can't just
> say "if you do that you break the model".

The commits you make will not actually go onto that tracking branch;
they will be part of a "detached HEAD" (that is, your HEAD doesn't point
to _any_ branch). Once you check out a different branch, you will
potentially lose those commits (actually, they will still be available
through your reflog, but you will have to know to look for them there).

> BTW, my ignorant assumption is that for merging to take place, git
> requires two branches, so 'git pull' will fetch into the tracking
> branch and then merge onto your ... uh ... whatever the name of the
> working version of your tracking branch is.

That's more or less correct. You don't really have to have two branches;
doing a 'git pull /path/to/repo branch' will fetch the branch into the
temporary FETCH_HEAD name, and merge from that. But yes, the way a raw
'git pull' will work is to first fetch all tracking branches into
refs/remotes/origin/*, and then merge from whichever is defined by your
config.

And they're usually called "local branches" if you differentiating them
from remote tracking branches, or just "branches" otherwise.

> BTW, again, why does git clone not have an option to just create all
> of the "working versions" (better name needed) of tracking branches?

I don't recall anybody asking for it, yet. I think the idea is that
those branches would just be clutter. If you want to work on something,
it's easy enough to just start a local version of the branch:

  git checkout -b topic origin/topic

-Peff