From: Joey Hess <joey@kitenet.net>
To: git@vger.kernel.org
Subject: Re: [PATCH] add post-fetch hook
Date: Sun, 25 Dec 2011 13:54:24 -0400 [thread overview]
Message-ID: <20111225175424.GA32626@gnu.kitenet.net> (raw)
In-Reply-To: <7vsjk99exw.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 2987 bytes --]
Junio C Hamano wrote:
> So if we were to allow the hook to lie what commits were fetched and store
> something different from what we fetched in the remote tracking refs, I
> think the correct place to do so would be in store_updated_refs(),
> immediately before we call check_everything_connected().
>
> - Feed the contents of the ref_map to the hook. For each entry, the hook
> would get (at least):
> . the object name;
> . the refname at the remote;
> . the refname at the local (which could be empty when we are not
> copying it to any of our local ref); and
> . if the entry is to be used for merge.
>
> - The hook must read _everything_ from its standard input, and then
> return the
> re-written result in the same format as its input. The hook could
> . update the object name (i.e. re-point the remote tracking ref);
> . update the local refname (i.e. use different remote tracking ref);
> . change "merge" flag between true/false; and/or
> . add or remove entries
>
> - You read from the hook and replace the ref_map list that is fed to
> check_everything_connected(). This ref_map list is what is used in the
> next for() loop that calls update_local_ref() to update the remote
> tracking ref, records the entry in FETCH_HEAD, and produces the report.
>
> This way, the hook cannot screw up, as what it tells us will consistently
> be written by us to where it should go.
This is a good plan, the only problem I see with it is that
store_updated_refs is potentially called twice in a fetch, when the
automated tag following is done. I don't see that as a large problem,
perhaps it could even be optimised away.
The format of .git/FETCH_HEAD does not seem appropriate for this hook
to use (it's not documented, and it doesn't quite have all the necessary
fields, particularly missing the local refname). Instead, how about this,
for the hook's input/output format?
<sha1> SP <not-for-merge|merge> SP <remote-refname> SP <local-refname> LF
Example:
5d6dfc7cb140a6eb90138334fab2245b69bc8bc4 merge refs/heads/master refs/remotes/origin/master
f95247ea15bc62a2dab0f6ae3cd247267a0639b8 not-for-merge refs/heads/pu refs/remotes/origin/pu
2ce0edcd786b790fed580e7df56291619834d276 not-for-merge refs/tags/v1.7.8.1 refs/tags/v1.7.8.1
Allowing the hook to change the merge flag does open up some other
interesting uses of the hook. I can now think of three use cases for it:
1. Only accepting tags that meet some criteria, such as being signed
by a trusted signature.
2. Causing branches that would not normally be merged to get merged.
For example, a hook could set the merge flag on a branch when it was
pulled from a remote other than branch.master.remote. This could be useful
when using git without a single central origin and with a number of
repositories that are always wanted to be kept merged.
3. My git annex merge case.
--
see shy jo
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
next prev parent reply other threads:[~2011-12-25 17:54 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-24 23:42 [PATCH] add post-fetch hook Joey Hess
2011-12-25 3:13 ` Junio C Hamano
2011-12-25 3:50 ` Joey Hess
2011-12-25 9:30 ` Junio C Hamano
2011-12-25 16:24 ` Jakub Narebski
2011-12-25 18:06 ` Joey Hess
2011-12-26 8:09 ` Junio C Hamano
2011-12-25 17:54 ` Joey Hess [this message]
2011-12-26 2:31 ` Joey Hess
2011-12-26 7:59 ` Junio C Hamano
2011-12-26 15:51 ` Joey Hess
2011-12-27 6:37 ` Junio C Hamano
2011-12-27 15:49 ` Joey Hess
2011-12-27 23:23 ` Junio C Hamano
2011-12-27 21:27 ` Johannes Sixt
2011-12-28 19:30 ` Joey Hess
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=20111225175424.GA32626@gnu.kitenet.net \
--to=joey@kitenet.net \
--cc=git@vger.kernel.org \
/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).