From: Junio C Hamano Date: Sat, 23 Jul 2005 00:20:53 GMT Subject: Re: [PATCH 0/2] apply.c: a fix and an enhancement Message-ID: <7vhdeme5ju.fsf@assigned-by-dhcp.cox.net> In-Reply-To: Linus Torvalds writes: > In other words, if it's per-project, then that implies that every single > developer has to agree on the same thing. Which just not possible - it > makes no sense. I agree 75%. See the bottom for the rest 25%. > In contrast, if you have a separate local _branch_ that maintains a > ".gitinfo" totally separately (no common commits at all), then you can > choose to propagate/participate in that branch or not, as you wish, on a > per-developer basis. Ah, finally the lightbulb moment. And I think what you outlined using "git switch" in another message is a clean way to do it if somebody wanted to. > For example, what if I tried to dig out even _more_ information than what > is in the BK CVS archives? Or if I wanted to have just the 2.6.0-> > history? Good examples; I stand corrected. That is also per "group of people who share the same view", i.e. per-developer thing that may be propagated among consenting branch participants. > What you're saying is that people can be happy if they just > don't use a stupid decision. That's a sure sign that the > decision shouldn't have been made in the first place. I am not saying it that strongly. Rather, people can be happy if they do not have to use a decision that they feel stupid. In circles you are part of, especially in a project like the kernel where hundreds of people participate worldwode, I can see that having project-wide preference (or policy) and maintaining it may not make _any_ sense. But on the other hand, it is my understanding that it is a common practice to enforce some centralized policy (I am thinking about pre-commit hooks in particular) in a corporate settings, and for people wanting to have that kind of thing, it is not even a stupid decision.