git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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
> 

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