Wayne Davison <wayne@xxxxxxxxxxxxx> writes:
> ... Is there
> a problem with local branches being supported when explicitly
> requested?
Maybe this one?
commit 6f084a56fcb3543d88d252bb49c1d2bbf2bd0cf3
Author: Johannes Schindelin <Johannes.Schindelin@xxxxxx>
Date: Tue Jul 10 18:50:44 2007 +0100
branch --track: code cleanup and saner handling of local branches
This patch cleans up some complicated code, and replaces it with a
cleaner version, using code from remote.[ch], which got extended a
little in the process. This also enables us to fix two cases:
The earlier "fix" to setup tracking only when the original ref started
with "refs/remotes" is wrong. You are absolutely allowed to use a
separate layout for your tracking branches. The correct fix, of course,
is to set up tracking information only when there is a matching
remote.<nick>.fetch line containing a colon.
Another corner case was not handled properly. If two remotes write to
the original ref, just warn the user and do not set up tracking.
Signed-off-by: Johannes Schindelin <johannes.schindelin@xxxxxx>
Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx>
As a local branch does not have to be "fetched", the restriction
on "remote.<nick>.fetch" is sort of pointless.
Also why remote.<nick>.fetch needs a colon, I begin to wonder.
You can be keep fetching and merging from the same branch of the
same remote without keeping a remote tracking branch for that,
but the above "correct fix" forbids that.
Dscho, what were we smoking when we made this change?
-
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
