git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: git fetch refs and tags

From
JWJan Weitzel <j.weitzel@phytec.de>
Date
Apr 23, 2013, 11:45 UTC
Message-ID
<1366717552.2899.17.camel@lws-weitzel>
In-Reply-To
<CALKQrge2vHqA1HitpdJKYQu0KY5+XkFdrN_Gg254gW_ih57o=Q@mail.gmail.com>
Am Dienstag, den 23.04.2013, 13:25 +0200 schrieb Johan Herland:
Show 20 quoted lines
> 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.

Show 13 quoted lines
> 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
> 
Previous: Johan HerlandNext: Johan Herland
Message 3 of 7 in “git fetch refs and tags”
  1. Jan WeitzelApr 23, 2013
  2. Johan HerlandApr 23, 2013
  3. Jan WeitzelApr 23, 2013
  4. Johan HerlandApr 23, 2013
  5. Junio C HamanoApr 23, 2013
  6. Johan HerlandApr 23, 2013
  7. Jan WeitzelApr 24, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.