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