git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Leo Gaspard <leo@gaspard.io>
Cc: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	"Joey Hess" <id@joeyh.name>,
	git@vger.kernel.org, "Brandon Williams" <bmwill@google.com>,
	"Junio C Hamano" <gitster@pobox.com>
Subject: Re: Fetch-hooks
Date: Tue, 13 Feb 2018 20:35:20 -0500	[thread overview]
Message-ID: <20180214013520.GA25188@sigill.intra.peff.net> (raw)
In-Reply-To: <5abf8565-1aa1-c101-83a7-90781682bc7a@gaspard.io>

On Sat, Feb 10, 2018 at 07:36:47PM +0100, Leo Gaspard wrote:

> Hmm... would this also drown the remote.<name>.fetch map? Also, I think
> this behavior could be emulated with fetch and fetchTagsTo, and it would
> look like:
> [remote "my-remote"]
>     fetch = +refs/heads/*:refs/remotes/my-remote/heads/*
>     fetchTagsTo = refs/remotes/my-remote/tags/*
> The remaining issue being to teach the lookup side to look for tags in
> all the remote-tag namespaces (and the fact it's a breaking change).

Right, I think fetching into the right spots is the easy part. Designing
the new lookup rules is the tricky part.

If you're really interested in the gory details, here's a very old
discussion on it:

  https://public-inbox.org/git/AANLkTi=yFwOAQMHhvLsB1_xmYOE9HHP2YB4H4TQzwwc8@mail.gmail.com/

I think there may have been some more concrete proposals after that, but
that's what I was able to dig up quickly.

> That said, actually I just noticed an issue in the “add a
> remote.<name>.fetch option to fetch to refs/quarantine then have the
> post-fetch hook do the work”: it means if I run `git pull`, then:
>  1. The remote references will be pulled to refs/quarantine/...
>  2. The post-fetch hook will copy the accepted ones to refs/remotes/...
>  3. The `git merge FETCH_HEAD` called by pull will merge FETCH_HEAD into
> local branches... and so merge from refs/quarantine.

Good point. You can't munge FETCH_HEAD by playing with refspecs.

I am starting to come around to the idea that "pre-fetch" might be the
best way to do what you want. Not to rewrite refs, but perhaps to simply
reject them. In the same way that we allow pre-receive to reject pushed
refs (both are, after all, the final check on admitting new history into
the repository, just in opposite directions).

> So, when thinking about it, I'm back to thinking the proper hook
> interface should be the one of the tweak-fetch hook, but its
> implementation should make it not go crazy on remote servers. And so
> that the implementation should do all this refs/quarantine wizardry
> inside git itself.

So does anybody actually want to be able to adjust the refs as they pass
through? It really sounds like you just want to be able to reject or not
reject the fetch. And that rejecting would be the uncommon case, so it's
OK to just abort the whole operation and expect the user to figure it
out.

-Peff

  parent reply	other threads:[~2018-02-14  1:35 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-07 21:56 Fetch-hooks Leo Gaspard
2018-02-07 22:51 ` Fetch-hooks Ævar Arnfjörð Bjarmason
2018-02-08  0:06   ` Fetch-hooks Leo Gaspard
2018-02-08 15:30     ` Fetch-hooks Joey Hess
2018-02-08 17:02       ` Fetch-hooks Leo Gaspard
2018-02-08 21:06         ` Fetch-hooks Ævar Arnfjörð Bjarmason
2018-02-08 22:18           ` Fetch-hooks Leo Gaspard
2018-02-09 22:04             ` Fetch-hooks Ævar Arnfjörð Bjarmason
2018-02-09 22:24               ` Fetch-hooks Leo Gaspard
2018-02-09 22:56                 ` Fetch-hooks Ævar Arnfjörð Bjarmason
2018-02-09 22:30               ` Fetch-hooks Jeff King
2018-02-09 22:45                 ` Fetch-hooks Junio C Hamano
2018-02-09 23:49                 ` Fetch-hooks Leo Gaspard
2018-02-10  0:13                   ` Fetch-hooks Jeff King
2018-02-10  0:37                     ` Fetch-hooks Leo Gaspard
2018-02-10  1:08                       ` Fetch-hooks Junio C Hamano
2018-02-10  1:33                         ` Fetch-hooks Leo Gaspard
2018-02-10 18:03                           ` Fetch-hooks Leo Gaspard
2018-02-10 12:21                       ` Fetch-hooks Jeff King
2018-02-10 18:36                         ` Fetch-hooks Leo Gaspard
2018-02-12 19:23                           ` Fetch-hooks Brandon Williams
2018-02-13 15:44                             ` Fetch-hooks Leo Gaspard
2018-02-14  1:38                             ` Fetch-hooks Jeff King
2018-02-14  1:35                           ` Jeff King [this message]
2018-02-14  2:02                             ` Fetch-hooks Leo Gaspard
2018-02-19 21:23                               ` Fetch-hooks Jeff King
2018-02-19 22:50                                 ` Fetch-hooks Leo Gaspard
2018-02-20  6:10                                   ` Fetch-hooks Jacob Keller
2018-02-20  7:42                                   ` Fetch-hooks Jeff King
2018-02-20 21:19                                     ` Fetch-hooks Leo Gaspard
2018-02-14  1:46                         ` Fetch-hooks Jacob Keller
2018-02-09 19:12         ` Fetch-hooks Leo Gaspard
2018-02-09 20:20           ` Fetch-hooks Joey Hess
2018-02-09 21:28             ` [PATCH 0/2] fetch: add tweak-fetch hook Leo Gaspard
2018-02-09 21:44               ` [PATCH 1/2] fetch: preparations for " Leo Gaspard
2018-02-09 21:44                 ` [PATCH 2/2] fetch: add " Leo Gaspard
2018-02-09 22:40                   ` Junio C Hamano
2018-02-09 22:34                 ` [PATCH 1/2] fetch: preparations for " Junio C Hamano

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=20180214013520.GA25188@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=avarab@gmail.com \
    --cc=bmwill@google.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=id@joeyh.name \
    --cc=leo@gaspard.io \
    /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).