From: Junio C Hamano Date: Sat, 10 Nov 2007 18:43:28 GMT Subject: Re: git-branch silently ignores --track on local branches Message-ID: <7vfxzelz5b.fsf@gitster.siamese.dyndns.org> In-Reply-To: <20071110174557.GC1036@blorf.net> Wayne Davison writes: > ... Is there > a problem with local branches being supported when explicitly > requested? Maybe this one? commit 6f084a56fcb3543d88d252bb49c1d2bbf2bd0cf3 Author: Johannes Schindelin 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..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 Signed-off-by: Junio C Hamano As a local branch does not have to be "fetched", the restriction on "remote..fetch" is sort of pointless. Also why remote..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?