Junio C Hamano <gitster@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html