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->
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