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:
signature.asc
Description: Digital signature