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.
Jan
On Tue, Apr 23, 2013 at 12:53 PM, Jan Weitzel [off-list ref] 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")?
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
should be able to get your desired behavior by first purging all
unreachable objects. Something like "git gc --prune=now" should do the
job.
Hope this helps,
...Johan
--
Johan Herland, [off-list ref]
www.herland.net
Am Dienstag, den 23.04.2013, 13:25 +0200 schrieb Johan Herland:
On Tue, Apr 23, 2013 at 12:53 PM, Jan Weitzel [off-list ref] wrote:
quoted
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.
Hope this helps,
Thanks
Jan
...Johan
On Tue, Apr 23, 2013 at 1:45 PM, Jan Weitzel [off-list ref] wrote:
Am Dienstag, den 23.04.2013, 13:25 +0200 schrieb Johan Herland:
quoted
On Tue, Apr 23, 2013 at 12:53 PM, Jan Weitzel [off-list ref] wrote:
quoted
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.
quoted
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 ;)
quoted
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, [off-list ref]
www.herland.net