On 1 May 2012 17:10, Nathan Gray <n8gray@xxxxxxxxxx> wrote: > On Tue, May 1, 2012 at 3:21 PM, Hilco Wijbenga <hilco.wijbenga@xxxxxxxxx> wrote: >> On 1 May 2012 14:59, PJ Weisberg <pj@xxxxxxxxxxxxxxxxxxxxxxxx> wrote: >>> On Tue, May 1, 2012 at 2:09 PM, Hilco Wijbenga <hilco.wijbenga@xxxxxxxxx> wrote: >>> >>>> On 1 May 2012 14:03, Junio C Hamano <gitster@xxxxxxxxx> wrote: >>>> >>>>> We've talked about something like that a few times in the past, but as far >>>>> as I (am concerned / remember) the conclusion has always been that is not >>>>> worth "standardizing", i.e. nothing a ./setup script in-tree or a Makefile >>>>> target cannot offer the same convenience. >>>> >>>> This would not keep things up-to-date, though, would it? It seems like >>>> yet another thing developers need to remember and do. I would prefer >>>> something more automatic. >>> >>> Once your hooks are installed, couldn't your post-checkout and >>> post-merge hooks keep all the others up to date? >> >> Excellent point. Yes, that would certainly work. > > But beware, this has the effect of making your hooks > version-dependent. Check out a different branch and you can > potentially end up with a different hook. > > IMHO things like this belong in a separate "admin" repo -- policy may > change over time, but going back to an old version of your code > shouldn't take you back to a correspondingly old version of your > policy. You have a point, of course, however, checking out an older version (that does not comply with current policy) should not break (when interacting with Git) just because of that. So I think there is at least some justification to version the policy as well. This is something we will simply have to experience to see what works best. -- 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