Linus Torvalds <[EMAIL PROTECTED]> 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. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
