# git-branch silently ignores --track on local branches 3 messages from 2007-11-10 to 2007-11-11. Participants: Wayne Davison, Junio C Hamano, Johannes Schindelin. Thread: https://gitlist.dev/t/10786 ## Wayne Davison, 2007-11-10 17:45 Subject: git-branch silently ignores --track on local branches Message-ID: <20071110174557.GC1036@blorf.net> URL: https://gitlist.dev/e/20071110174557.GC1036%40blorf.net ``` I used to be able to create a branch that tracked master (or another local branch) by using "git branch --track new-branch" from that checked-out branch. However, this functionality was apparently removed and now the --track option is silently ignored for local branches. I'd love to have this functionality restored. Is there a problem with local branches being supported when explicitly requested? ..wayne.. ``` ## Junio C Hamano, 2007-11-10 18:43 Subject: Re: git-branch silently ignores --track on local branches Message-ID: <7vfxzelz5b.fsf@gitster.siamese.dyndns.org> URL: https://gitlist.dev/e/7vfxzelz5b.fsf%40gitster.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? ``` ## Johannes Schindelin, 2007-11-11 19:23 Subject: Re: git-branch silently ignores --track on local branches Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0711111919170.4362%40racer.site In-Reply-To: <7vfxzelz5b.fsf@gitster.siamese.dyndns.org> ``` Hi, On Sat, 10 Nov 2007, Junio C Hamano wrote: > 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. IIRC it was you, Junio, who complained first that the local branches have tracking set up. > 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. The point here was to find out what to track when we do a "git branch --track ". So we definitely only want to find those remotes that fetch to a certain tracking branch. Sure, you can set up branch..merge to a branch that is not tracked. But git cannot find out which one it is in the command "branch". > Dscho, what were we smoking when we made this change? Dude, I, uh, I think I, uh, don't remember. Peace. Ciao, Dscho ```