Re: [PATCH 0/2] apply.c: a fix and an enhancement

[Junio C Hamano <junkio@cox.net>]

Linus Torvalds <torvalds@osdl.org> 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.