On Tue, Apr 23, 2013 at 1:45 PM, Jan Weitzel <J.Weitzel@xxxxxxxxx> wrote: > Am Dienstag, den 23.04.2013, 13:25 +0200 schrieb Johan Herland: >> On Tue, Apr 23, 2013 at 12:53 PM, Jan Weitzel <J.Weitzel@xxxxxxxxx> wrote: >> > Hello, >> > I have the following problem: I have 2 bare git repositories one has >> > several branches and tags. >> > If I try this in the second repository: >> > git fetch -f ../main.git refs/heads/master:refs/heads/master >> > I'm getting also tags from other branches, if I have an old object from >> > one of the other branches. >> > I would expect to have only tags pointing to master ref. (Although the >> > man pages points to the behaviour regarding dangling objects). Is there >> > a way to avoid this? I only find --no-tags which results in having no >> > tags at all. Or need I git purge to remove the old objects first? >> > My goal is to fetch only specific branches and the related tags. >> >> AFAIK, Git should only auto-follow tags that are reachable from the >> branches you fetch (in this case master). Are you saying that you get >> tags pointing to other history that is NOT reachable from the master >> branch? (i.e. are you getting tags for which "git merge-base $tag >> master" is not equal to "git rev-parse $tag")? >> > exactly. I reproduced it by coping a object from an other branch to the > locale repository. This results in fetching the not reachable tags. > >> Re-reading the man page, I do see the following: >> >> "if the repository has objects that are pointed by remote tags that it >> does not yet have, then fetch those missing tags. If the other end has >> tags that point at branches you are not interested in, you will not >> get them." >> >> This can be interpreted as saying that even unreachable objects in >> your local repo that are pointed to by some remote tag will cause that >> tag to be fetched, and in effect resuscitate the >> previously-unreachable object. If this is indeed how it works, I would >> be tempted to label this a bug in the auto-following behavior, as it's >> probably not what most people would expect. In that case, yes, you > > Yes my first understanding of auto-following behaviour was wrong ;) > >> should be able to get your desired behavior by first purging all >> unreachable objects. Something like "git gc --prune=now" should do the >> job. > > Because I run this by scripts is there a way without porcelain commands? > I saw even git prune is one. git prune is not sufficient, since it only removes _unpacked_ and unreachable objects. You first need to create a new pack that does not contain unreachable objects (git rebase -a -d), but before that you also need to expire reflogs (git reflog expire ...) and you should also prune packed refs (git pack-refs --prune ...). In short there are a number of commands you need to run, and in the right order and with the right options, but "git gc --prune=now" is basically just a wrapper around these that Does The Right Thing(tm). I would just use that instead. ...Johan -- Johan Herland, <johan@xxxxxxxxxxx> www.herland.net -- 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