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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.