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
Dear diary, on Sat, Jul 23, 2005 at 01:50:09AM CEST, I got a letter
where Linus Torvalds <[EMAIL PROTECTED]> told me that...
>
>
> On Sat, 23 Jul 2005, Petr Baudis wrote:
> >
> > Yes, but this stuff is not for personal preferences. It is for
> > project-wide preferences and policies, which can b
On Sat, 23 Jul 2005, Petr Baudis wrote:
>
> Yes, but this stuff is not for personal preferences. It is for
> project-wide preferences and policies, which can be still normally
> overridden or altered locally in each repository.
What you are describing is a nightmare.
Let's assume that a user a
Dear diary, on Sat, Jul 23, 2005 at 01:26:07AM CEST, I got a letter
where Linus Torvalds <[EMAIL PROTECTED]> told me that...
> On Fri, 22 Jul 2005, Junio C Hamano wrote:
> > Linus Torvalds <[EMAIL PROTECTED]> writes:
> >
> > > I'd _really_ prefer to not have any preferences or other metadata files
Dear diary, on Fri, Jul 22, 2005 at 11:53:41PM CEST, I got a letter
where Linus Torvalds <[EMAIL PROTECTED]> told me that...
> On Fri, 22 Jul 2005, Junio C Hamano wrote:
> >
> > And the file would obviously be per-project, so according to
> > Pasky's suggestion that would be ".gitinfo/fake_parents
On Fri, 22 Jul 2005, Junio C Hamano wrote:
> Linus Torvalds <[EMAIL PROTECTED]> 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
Linus Torvalds <[EMAIL PROTECTED]> 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
Linus Torvalds <[EMAIL PROTECTED]> writes:
> Think of something like a collection of projects, each under their own
> subdirectory. We could eventually literally make them _look_ like one big
> project, with cross-project commits grafted together, but they'd
> technically be totally independent
On Fri, 22 Jul 2005, Junio C Hamano wrote:
>
> And the file would obviously be per-project, so according to
> Pasky's suggestion that would be ".gitinfo/fake_parents" ;-).
I'd _really_ prefer to not have any preferences or other metadata files
under version control within that same project.
If
Linus Torvalds <[EMAIL PROTECTED]> writes:
> Just teach "parse_commit()" to look at a ".git/fake_parents" file, and
> insert fake extra parents for commits that way - you can graft any tree on
> top of any other tree that way, and it's probably a nice idea for testing
> things out.
Nicely put,
On Fri, 22 Jul 2005, A Large Angry SCM wrote:
>
> To do it without the history rewrite, create an alternate_history
> directory under .git with it's own objects tree. And populate that
> object tree with "alternative" content for the objects in the normal
> trees. Then teach the things the lo
Junio C Hamano wrote:
Ryan Anderson <[EMAIL PROTECTED]> writes:
On Fri, Jul 22, 2005 at 09:56:19AM -0700, Junio C Hamano wrote:
Now if we had a mechanism to graft a later history which starts
at 2.6.12-rc2 on top of this earlier history leading up to
it,... ;-)
We do - it's not even very har
On Fri, Jul 22, 2005 at 12:46:36PM -0700, Junio C Hamano wrote:
> Ryan Anderson <[EMAIL PROTECTED]> writes:
>
> > On Fri, Jul 22, 2005 at 09:56:19AM -0700, Junio C Hamano wrote:
> >> Now if we had a mechanism to graft a later history which starts
> >> at 2.6.12-rc2 on top of this earlier history l
Ryan Anderson <[EMAIL PROTECTED]> writes:
> On Fri, Jul 22, 2005 at 09:56:19AM -0700, Junio C Hamano wrote:
>> Now if we had a mechanism to graft a later history which starts
>> at 2.6.12-rc2 on top of this earlier history leading up to
>> it,... ;-)
>
> We do - it's not even very hard, we just e
On Fri, Jul 22, 2005 at 09:56:19AM -0700, Junio C Hamano wrote:
> Now if we had a mechanism to graft a later history which starts
> at 2.6.12-rc2 on top of this earlier history leading up to
> it,... ;-)
We do - it's not even very hard, we just end up with 2 commits for every
change/merge that's
In mid April, Ingo announced availability of his conversion from
CVS to a flat patchset format:
From: Ingo Molnar <[EMAIL PROTECTED]>
Subject: full kernel history, in patchset format
Message-ID: <[EMAIL PROTECTED]>
the history data starts at 2.4.0 and ends at 2.6.12-rc2. I've incl
16 matches
Mail list logo