We talked about this at group meeting this morning. We had just been discussing a realization similar to Michael Gersten's observation about needing a "special merge" when we saw his post come in. Moments before that we had decided that we probably do want it to be a pre-fetch hook. That is... we want to avoid needing two different versions of merge (or fetch or pull). I will explain more.
I might be misunderstanding some of the 'magic' associated with fetch and merge. If one merges between branches in a single repo, would that be subject to a pre-merge hook? As MG observed, we don't want to interfere with what the devs do in their local repos. We only want to ensure that they have dumped the data before merging from external sources. So, a pre-fetch makes a little more sense unless the pre-merge hook can be set to only act on merges from external repos (or something similar). That is, with pre-fetch, you know that you are setting the hook to affect what might happen when you take data in from an external source. We definitely want to avoid having different versions of merge/fetch/pull/etc. because we don't want the devs to have to remember to do the special thing. Besides, we already have a special 'pull'. At some point soon, we will test the idea of just intercepting calls to 'git fetch' with a script that looks for a pre-fetch file in the hooks directory. If it finds one, it executes it. If not, it passes everything along to the regular fetch. We worry that we will have unintended consequences. We also worry about having to get that implemented on whatever setup any particular dev has. -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
