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

From: Junio C Hamano <junkio@cox.net>
Date: Jul 23, 2005, 00:20 UTC
Message-ID: <7vhdeme5ju.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.58.0507221619450.6074@g5.osdl.org>

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.