Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
> "git branch --track" will setup config variables when branching from
> a remote branch, so that if you say "git pull" while being on that
> branch, it automatically fetches the correct remote, and merges the
> correct branch.
While I think it would have been the right thing to do if the
code did this only for a remote branch, I think there is a bug
somewhere. I just saw this:
... some random changes ...
master$ git commit -a -s -m 'Some work meant for topic.'
master$ git branch jc/new-topic
Branch jc/new-topic set up to track local branch refs/heads/master
Eh? I did not want this to get applied for my local branches.
The intention of the above command sequence was to do a branch
and then "reset --hard HEAD^" to rewind the 'master', as if I
did not commit but instead did "checkout -b jc/new-topic &&
commit && checkout master".
But "checkout -b jc/newtopic" has the same problem, as it
eventually uses the same "git-branch" that defaults to --track
even for a case where I branch off of a local branch.
I do not necessarily think the command line --track is broken.
If the user explicitly says a branch tracks a local branch, so
be it. If --track comes from autosetupmerge or built-in default
like your patch, however, I do not think it makes much sense to
pollute the config file with useless "tracking" information.
I am very tempted to revert this, but won't do so tonight, yet.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
