git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Shawn O. Pearce" <spearce@spearce.org>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 07/11] git-fetch: Limit automated tag following to only fetched objects
Date: Sun, 11 Nov 2007 00:49:51 -0500	[thread overview]
Message-ID: <20071111054951.GV14735@spearce.org> (raw)
In-Reply-To: <7v7ikrrr77.fsf@gitster.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
> 
> > We now redefine the rule to be: "tags are fetched if they refer
> > to an object that was just transferred; that is an object that is
> > new to your repository".  This rule is quite simple to understand,
> > you only get a tag if you just got the object it refers to.
> 
> In other words, if I do this:
> 
> 	git fetch git-gui master
> 
> (which should not follow any tags) when your master is a bit
> ahead of a new tag in git-gui I do not have, and then
> immediately afterwards if I do:
> 
> 	git fetch git-gui
> 
> I will not get the new tag followed?
> 
> If that is what the patch does, it feels like a regression.

Yeah, that's what it does, and everyone has stated its a regression
so its not the right change to make here.
 
> The intended behaviour was "when tag following is enabled, they
> are followed if they refer to an object that is reachable from
> your existing refs".
> 
> But this is quite expensive to compute.  If a tag points at a
> blob that is contained inside a commit that is reachable from a
> ref, we would need to grep "git rev-list --objects -all" output
> to find it out.  I do not offhand recall what the scripted
> version did, but I would not be surprised if as an approximation
> we did the auto-following by "does the pointee exist" check.

We just did `git cat-file -t`.  If it passed then we followed
the tag.  Which means we could just do a has_sha1_file() test and
call it a day.  If the object is already reachable from our current
refs we'll only download the tag; if it isn't really reachable but
is dangling in the ODB we'll download possibly a lot of objects.

I was trying to make tag auto-following only work if the tag's
target was already completely available and we'd only need to
download the tag object itself.
 
> What "random behaviour" are you trying to fix? 

Apparently I'm introducing even more random behavior.  It may have
just been a bug in the past.  Or a tag whose referred object wasn't
reachable from a ref but I thought it should have been.  Obviously
my patch series resolves neither.

-- 
Shawn.

      reply	other threads:[~2007-11-11  5:50 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-09 11:06 [PATCH 07/11] git-fetch: Limit automated tag following to only fetched objects Shawn O. Pearce
2007-11-09 11:28 ` Johannes Sixt
2007-11-09 12:12 ` CJ van den Berg
2007-11-10 14:10   ` Andreas Ericsson
2007-11-09 22:26 ` Junio C Hamano
2007-11-11  5:49   ` Shawn O. Pearce [this message]

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=20071111054951.GV14735@spearce.org \
    --to=spearce@spearce.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.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).