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

From: Linus Torvalds <torvalds@osdl.org>
Date: Jul 22, 2005, 23:26 UTC
Message-ID: <Pine.LNX.4.58.0507221619450.6074@g5.osdl.org>
In-Reply-To: <7vfyu6jvrm.fsf@assigned-by-dhcp.cox.net>

On Fri, 22 Jul 2005, Junio C Hamano wrote:

Show 8 quoted lines

> Linus Torvalds <torvalds@osdl.org> writes:
> 
> > I'd _really_ prefer to not have any preferences or other metadata files
> > under version control within that same project.
> 
> Don't you think that would be a per-project decision?  Is it
> acceptable if I make sure that .gitinfo/* is _optional_ and
> things do not break for projects that do not use it?

It can't be a per-project decision, since the preferences are per-developer.

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.

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.

> I agree.  The .gitinfo/fake-parents may be a good thing in that
> sense to have project-wide,

I disagree. Even something like fake-parents isn't project-wide.

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? The whole point of fake-parents is that you can do things like that - you can point your history at alternative views.

If we'd make it project-global, then we might as well just rewrite the original commit entirely, and use "git-convert-cache" to convert the whole archive. At that point, fake-parents becomes pointless.

>			 and as long as the kernel person
> (that is you) do not add .gitinfo/commit-template you would be
> happy, wouldn't you?

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.

		Linus