From: Jakub Narebski <jnareb@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Joey Hess <joey@kitenet.net>, git@vger.kernel.org
Subject: Re: [PATCH] add post-fetch hook
Date: Sun, 25 Dec 2011 08:24:52 -0800 (PST) [thread overview]
Message-ID: <m3liq0fwkz.fsf@localhost.localdomain> (raw)
In-Reply-To: <7vsjk99exw.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> [...] 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
This is a very nice idea, IMHO, both because it makes it simple to
implement no-op (example) hook by just using "cat", and beause it
makes possible to stack such hooks (e.g. one from git-annex with the
one from pristine-tar etc.).
One thing that needs to be specified is what should happen if the hook
changes "the refname at the remote" part...
> - 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.
--
Jakub Narebski
next prev parent reply other threads:[~2011-12-25 16:25 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 [this message]
2011-12-25 18:06 ` Joey Hess
2011-12-26 8:09 ` Junio C Hamano
2011-12-25 17:54 ` Joey Hess
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=m3liq0fwkz.fsf@localhost.localdomain \
--to=jnareb@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=joey@kitenet.net \
/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).