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:-(

Liu Yubao wrote:

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:

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.

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".

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

 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?

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                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

On 2008.10.29 16:55:48 +0800, Liu Yubao wrote:

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)

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.

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).

git pull --rebase

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?

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 :-)

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:-(

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

Björn

Andreas Ericsson wrote:

Liu Yubao wrote:

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.

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...]

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

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.

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.

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!

Björn Steinbrink wrote:

On 2008.10.29 16:55:48 +0800, Liu Yubao wrote:

quoted

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)

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.

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

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.

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

It's great, thanks!

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 :-)

quoted

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:-(

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

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

Björn

Liu Yubao wrote:

Andreas Ericsson wrote:

quoted

Liu Yubao wrote:

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.

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...]

quoted

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

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.

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                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231