Do most people feel tracking branches useful?

Hi,

I often feel tracking branches are useless to me, because there are remote branches and I work on my private branch in most time.

repos

     |
     |-- my               (private branch, do my dirty work)
     |-- master           (tracking branch)
     |-- origin/master    (remote branch)

To avoid conflict when execute git pull and make the history linear, I work on branch "my" instead of "master". Here is my work flow:

1) use git fetch or git remote update to synchronize branch "origin/master" with branch "master" in remote repository;
2) create a new private branch to polish my commits and rebase it against "origin/master";
3) at last push this new branch to the remote repository or ask the upstream developer to fetch it(no git pull because we want history as linear as possible).

I don't want to bother with the tracking branch "master", it's identical with "origin/master". Because git checkout -b xxx <remote_branch> will create a tracking branch "xxx" by default, so my question is:
do most people feel tracking branches useful?

BTW: I feel the terminalogy "remote branch" is confused, because I must synchronize it with git fetch. I feel it's better to call it "tracking branch" // seems will lead to bigger confusion to experienced git users:-(

Actually, origin/master is the "[remote] tracking branch". master is just a branch that has config settings for "git pull" defaults. ;-)

"Remote branches" are the actual branches on a remote repository.

git pull --rebase

Tracking branches (origin/* etc.) are very useful :-) And branches that have "git pull" defaults (what you called "tracking branch") are also useful.

In your case, you probably want:
git checkout -b my-stuff origin/master
git config branch.my-stuff.rebase true

and then you can do:
git pull

Instead of:
git fetch origin
git rebase origin/master

You can also setup branch.autosetuprebase, to automatically get the rebase setup, so you can skip the call to "git config" above.

And you can just delete the "master" branch if you don't use it. There's nothing that forces you to keep any branches around that you don't use. But that doesn't affect the usefulness of tracking branches or branches that have "git pull" defaults :-)

See above, that's already the case ;-)

Björn

Oh, I'm misguided by the --track option, thank you for clarifying it!

A new config setting, git amazes me again @_@

It's great, thanks!

Got it, --rebase and config.<branch>.rebase and config.autosetuprebase, thank you again:-)

Use "git fetch" instead of "git pull" and you won't need the 'my' branch. If you use "git pull --rebase" you won't need to bother at all.

Not unless you "git pull" when there's only fast-forward changes.

I use them all the time. They're immensely useful to me.

I can't understand why you're working so hard for a linear history, but perhaps that's just an effect of only having leaf developers. I also can't understand why you'd want to sync with upstream at all if you're just working on a single feature/bugfix at the time, since you'd probably be better off by just completing that single feature in your own time and doing "git pull --rebase && git push" when you're done.

Andreas Ericsson                   [email protected]
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Thank you very much, I didn't know the "--rebase" option, now I learn the 'branch.<name>.rebase' configuration too by "git help pull".

[...snip...]

You got it exactly, we are leaf developers and make enhancement mostly, we don't want the upstream branch full of merging commit for many not so major changes. I remember keeping linear history is recommended in git's documentation.

I only sync when I have finished my enhancement, I don't like merging when pull.

Yes, I'd better use "git pull --rebase", "pull" is a wonderful command:
pull = fetch + merge, pull --rebase = fetch + rebase, wow!

That should probably be rephrased to "Think before you merge" or something like that. Keeping history linear provides very little value in itself, but mindlessly criss-cross-merging makes history difficul to review for no good reason. Any perceived value of mindless merging is quickly nullified once one starts looking at "git rerere".

The only time you'll run into problems with non-linear history is when you're bisecting, and bisection ends up at a merge-commit where all the merged branhces tips' pre-merge work flawlessly, but the merge-commit itself introduces breakage by erroneously resolving a conflict, or by introducing changes of its own (git commit --amend, fe).

Andreas Ericsson                   [email protected]
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Extremely useful. I usually keep local branches closely synchronized with a remote "central" version, and tracking branches make the frequent push/pull much more convenient.

I often delete the default local "master" branch though, and have only one local branch per working directory (and like you, use origin/... for much interbranch synchronization, e.g. rebasing).

-Miles

"Whatever you do will be insignificant, but it is very important that
 you do it."  Mahatma Gandhi

In my work flow, I don't keep changes in local branch for long time, I rebase it regularly and push them to central branch or discard them if the upstream rejects.

You are right, I realize tracking branches is useful for people who keeps local changes for long time and track the upstream branch at the same time.

But I guess an auto-rebasing policy is more sensible than auto-merging policy because I won't get many useless "Merge branch 'xxx' of ..." messages in the history.

Another problem about tracking branch is git pull won't merge tracking branch with remote branch when the current branch isn't tracking branch, it warns me "You asked me to pull without telling me which branch you ....". It's not convenient to checkout tracking branch and execute git pull then switch back to my working branch.

I don't keep local changes for a long time, I push daily. The local tracking branch and the corresponding remote branch are basically copies of each other, in different locations. I also do regularly rebasing, but against a _different_ remote branch.

There are never merge commits, because all merges done by pull are fast-forwards. If I were to push changes from multiple working directories to the central location, I'd have to be more careful about the pull-merging -- a rebase-on-pull as you suggest would be useful -- but I generally don't.

-Miles

Do not taunt Happy Fun Ball.