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: Fri, 9 Feb 2018 19:13:17 -0500	[thread overview]
Message-ID: <20180210001317.GA26856@sigill.intra.peff.net> (raw)
In-Reply-To: <87e7c3b8-3b3c-1cb0-9b11-e4bf3044e539@gaspard.io>

On Sat, Feb 10, 2018 at 12:49:31AM +0100, Leo Gaspard wrote:

> > I tend to agree with the direction of thinking you outlined: you're
> > generally better off completing the fetch to a local namespace that
> > tracks the other side completely, and then manipulating the local refs
> > as you see fit (e.g., fetching into refs/quarantine, and then migrating
> > "good" refs over to refs/remotes/origin).
> 
> Hmm... so do I understand it correctly when I say the process you're
> thinking about works like this?
>  * User installs hook for my-remote by running [something]
>  * User runs git fetch
>  * git fetch fetches remote refs/heads/* to local refs/quarantine/* (so
> I guess [something] changes the remote.my-remote.fetch refmap)
>  * When this is done `git fetch` runs a notification-only post-fetch
> hook (that would need to be added)
>  * The post-fetch hook then performs whatever it wants and updates the
> references in refs/remotes/my-remote/*

Yeah, that was roughly my thinking.

> So the changes that are required are:
>  * Adding a notification-only post-fetch hook
>  * For handling tags, there is a need to have a refmap for tags. Maybe
> adding a remote.my-remote.fetchTags refmap, that would be used when
> running with --tags, and having it default to “refs/tags/*:refs/tags/*”
> to keep the current behavior by default?

Yeah, tag-following may be a little tricky, because it usually wants to
write to refs/tags/. One workaround would be to have your config look
like this:

  [remote "origin"]
  fetch = +refs/heads/*:refs/quarantine/origin/heads/*
  fetch = +refs/tags/*:refs/quarantine/origin/tags/*
  tagOpt = --no-tags

That's not exactly the same thing, because it would fetch all tags, not
just those that point to the history on the branches. But in most
repositories and workflows the distinction doesn't matter.

(By the way, the I specifically chose the name "refs/quarantine" instead
of anything in "refs/remotes" because we'd want to make sure that the
"git checkout" DWIM behavior cannot accidentally pull from quarantine).

> The only remaining issue I can think of is: How do we avoid the issue
> of the
> trigger-only-hook-inciting-bad-behavior-by-hook-authors-who-really-want-modification
> raised in the side-thread that Junio wrote in [1]? Maybe just writing
> in the documentation that the hook should use a quarantine-like
> approach if it wants modification would be enough to not have hook
> authors try to modify the ref in the post-fetch hook?

I don't have a silver bullet there. Documenting the "right" way at least
seems like a good first step.

-Peff

  reply	other threads:[~2018-02-10  0:13 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                   ` Jeff King [this message]
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                           ` Fetch-hooks Jeff King
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=20180210001317.GA26856@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).