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

2005-07-22 Thread Junio C Hamano
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

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

2005-07-22 Thread Petr Baudis
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

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

2005-07-22 Thread Linus Torvalds
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

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

2005-07-22 Thread Petr Baudis
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

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

2005-07-22 Thread Petr Baudis
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

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

2005-07-22 Thread Linus Torvalds
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

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

2005-07-22 Thread Junio C Hamano
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

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

2005-07-22 Thread Santi BĂ©jar
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

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

2005-07-22 Thread Linus Torvalds
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

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

2005-07-22 Thread Junio C Hamano
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,

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

2005-07-22 Thread Linus Torvalds
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

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

2005-07-22 Thread A Large Angry SCM
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

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

2005-07-22 Thread Ryan Anderson
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

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

2005-07-22 Thread Junio C Hamano
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

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

2005-07-22 Thread Ryan Anderson
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

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

2005-07-22 Thread Junio C Hamano
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