From: Jakub Narebski <jnareb@gmail.com>
Date: Tue, 02 Jan 2007 22:18:13 GMT
Subject: Re: [PATCH] Detached HEAD (experimental)
Message-ID: <enelha$n8g$3@sea.gmane.org>
In-Reply-To: <87ps9xgkjo.wl%cworth@cworth.org>

Carl Worth wrote:

> Similarly, I think this use case of "just tracking" should support
> branches disappearing from the remote repository without the user
> having to edit any config file. If there are entries that are
> automatically added by git-clone that should be removed later, that
> should happen automatically. A recent thread suggested adding an error
> message instructing the user to delete the entries. That's again
> unkind to a user who doesn't really want to learn git, but just wants
> to get at the most recent version of some code that happens to be
> available through git.
> 
> That disappearing branches cause problems requiring manual cleanup of
> configuration files is one of the reasons that we are not using any
> feature branches in the "central" cairo repository, for example, (we
> do have branches for release maintenance). I'd really like to be able
> to put some feature branches there for shared work, (rather than
> forcing that work out to separate personal repositories as we do
> know).
> 
> Maybe the configuration file entries added by git-clone need to be
> marked in some way to distinguish them from manually added entries, so
> that we would feel more comfortable automatically removing them when a
> remote branch has disappeared.

Is it still problem (the dissapearing remote branches) with the new
wildcard remote.<name>.fetch generated by new git-clone? I think it
should not complain that some branches vanished, but it would not I think
it would remove no longer needed tracking branches (local branches)
for us...

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git