From: Jan Weitzel <J.Weitzel@phytec.de>
To: Johan Herland <johan@herland.net>
Cc: git@vger.kernel.org, sitaramc@gmail.com
Subject: Re: git fetch refs and tags
Date: Tue, 23 Apr 2013 13:45:52 +0200 [thread overview]
Message-ID: <1366717552.2899.17.camel@lws-weitzel> (raw)
In-Reply-To: <CALKQrge2vHqA1HitpdJKYQu0KY5+XkFdrN_Gg254gW_ih57o=Q@mail.gmail.com>
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@phytec.de> 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.
>
> Hope this helps,
Thanks
Jan
>
> ...Johan
>
next prev parent reply other threads:[~2013-04-23 11:45 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-23 10:53 git fetch refs and tags Jan Weitzel
2013-04-23 11:25 ` Johan Herland
2013-04-23 11:45 ` Jan Weitzel [this message]
2013-04-23 12:16 ` Johan Herland
2013-04-23 14:59 ` Junio C Hamano
2013-04-23 20:50 ` Johan Herland
2013-04-24 7:45 ` Jan Weitzel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1366717552.2899.17.camel@lws-weitzel \
--to=j.weitzel@phytec.de \
--cc=git@vger.kernel.org \
--cc=johan@herland.net \
--cc=sitaramc@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).