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 - 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