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

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

[Junio C Hamano]

In mid April, Ingo announced availability of his conversion from
CVS to a flat patchset format:

    From: Ingo Molnar <mingo@elte.hu>
    Subject: full kernel history, in patchset format
    Message-ID: <20050416131528.GB19908@elte.hu>

    the history data starts at 2.4.0 and ends at 2.6.12-rc2. I've included a 
    script that will apply all the patches in order and will create a 
    pristine 2.6.12-rc2 tree.
    ...
    note: i kept the patches the cvsps utility generated as-is, to have a 
    verifiable base to work on. There were a very small amount of deltas 
    missed (about a dozen), probably resulting from CVS related errors, 
    these are included in the diff-CVS-to-real patch. Also, the patch format 

I was futzing with the script in Ingo's tarball, which
originally used "patch".  After converting it to use
'git-apply', I had some troubles with applying patches, which
eventually led me to find out and fix a corner case bug ---
git-apply did not handle files with an incomplete line correctly
in some cases.

After I fixed that problem, the script still found some more
errors in the patchset, but after manual inspection it looked to
me that they are problems not on the patch application side, but
on the patch generation side.  I only checked 2.4.0, 2.6.9,
2.6.11 and 2.6.12-rc2, but the trees built were byte-to-byte
equivalent, except that the file executable bits, which are
preserved in the patch series.

The patch attached to this message is not for inclusion in the
git source tree.  It is the script I used for conversion.  You
will need the following patches to apply.c for it to work, which
will be sent separately:

  [PATCH 1/2] apply.c: handle incomplete lines correctly.
  [PATCH 2/2] apply.c: --exclude=fnmatch-pattern option.

I did this not because I was particularly interested in the
ancient kernel history, but because I wanted to see how well
packs perform.  Here are some numbers that may be of interest.

    26M pack-000002.pack    18M pack-015360.pack
    48M pack-001024.pack    21M pack-016384.pack
    22M pack-002048.pack    18M pack-017408.pack
    20M pack-003072.pack    19M pack-018432.pack
    21M pack-004096.pack    17M pack-019456.pack
    24M pack-005120.pack    22M pack-020480.pack
    20M pack-006144.pack    20M pack-021504.pack
    20M pack-007168.pack    17M pack-022528.pack
    24M pack-008192.pack    23M pack-023552.pack
    19M pack-009216.pack    16M pack-024576.pack
    24M pack-010240.pack    21M pack-025600.pack
    20M pack-011264.pack    19M pack-026624.pack
    23M pack-012288.pack    18M pack-027648.pack
    21M pack-013312.pack    17M pack-028237.pack
    18M pack-014336.pack

The script makes a full pack after importing 2.4.0 (which is the
patchset #2), and then makes an incremental every 1024 commits,
so the baseline pack is 26MB and the first incremental up to the
patchset #1024 is 48MB.  It averages at around 20MB per 1024
commits.  The repository with the full history, repacked into a
single pack, is 203MB (370291 objects).


------------
A script to slurp full 2.4.0->2.6.12-rc2 history.

Create an empty directory, put the "build-git-tree" script in it, 
and extract Ingo's CVSPS conversion result, available at:

  http://kernel.org/pub/linux/kernel/people/mingo/Linux-2.6-patchset/

in it.  Make sure the definition of variable PS matches the name
of the directory you extracted the tarball, and run the script.
Some hours later, you will have linux/ directory whose .git
subdirectory has a GITified full 2.4.0->2.6.12-rc2 history.

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,...  ;-)

Signed-off-by: Junio C Hamano <junkio@cox.net>
---

 build-git-tree |  177 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 177 insertions(+), 0 deletions(-)

diff --git a/build-git-tree b/build-git-tree
new file mode 100755
--- /dev/null
+++ b/build-git-tree
@@ -0,0 +1,177 @@
+#!/bin/sh
+
+PS=linux-2.4.0-to-2.6.12-rc2-patchset
+cat build-git-tree >build-git-tree-next
+cat >sayVersion <<\EOF
+default:
+	@echo "v$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION)"
+EOF
+
+: >duplicate-tags
+
+: ${END=28237}
+: ${CPP=1024}
+
+sedScript='
+    /^Date: /{
+	s/^Date: \(.*\)/\1/
+        s/'\''/'\''\\'\'''\''/g
+	s/^.*/DATE='\''&'\''/p
+    }
+    /^Author: /{
+	s/^Author: \(.*\)/\1/
+        s/'\''/'\''\\'\'''\''/g
+	s/^.*/AUTHOR='\''&'\''/p
+    }
+    /^Log:$/{
+	n
+	b LOOP
+    }
+    b
+   : LOOP
+    /^BKrev: /{
+	g
+	s/^\n//
+	s/\n$//
+	s/'\''/'\''\\'\'''\''/g
+	s/^.*/LOG='\''&'\''/p
+	q
+    }
+    H
+    n
+    b LOOP
+'
+
+rm -fr errs linux pack && mkdir -p linux/Documentation errs pack || exit
+cp $PS/logo.gif linux/Documentation
+
+cd linux
+git-init-db
+git-ls-files --cached -z |
+xargs -0 -r git-update-cache --add --remove --
+find ?* -type f -print0 | xargs -0 -r git-update-cache --add --
+
+N=1 P=
+while expr $N \<= $END >/dev/null
+do
+  NN=$(printf "%06d" $N)
+  FILE=../$PS/patches/$N.patch
+
+  e=`sed -ne "$sedScript" $FILE` &&
+  eval "$e" &&
+
+  GIT_AUTHOR_NAME="$AUTHOR" &&
+  GIT_AUTHOR_EMAIL="$AUTHOR" &&
+  GIT_COMMITTER_NAME="$AUTHOR" &&
+  GIT_COMMITTER_EMAIL="$AUTHOR" &&
+  GIT_AUTHOR_DATE="+0000 $DATE" &&
+  GIT_COMMITTER_DATE="+0000 $DATE" &&
+
+  export GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_COMMITTER_NAME \
+         GIT_COMMITTER_EMAIL GIT_AUTHOR_DATE GIT_COMMITTER_DATE &&
+
+  echo "* $NN - $AUTHOR - $DATE" &&
+
+  git-apply --exclude='BitKeeper/*' --index --summary --apply \
+  	<$FILE >../errs/$NN.out 2>&1 || {
+    # Special case.
+    patch -E -p1 <$FILE >../errs/$NN.spc 2>&1
+    sed -ne 's|^File \(.*\) is not empty after patch, as expected$|\1|p' \
+        <../errs/$NN.spc |
+    while read path
+    do
+        echo "* expected to be empty: $path"
+        ls -l "$path"
+	rm -f "$path"
+    done >.tmp
+    cat .tmp >>../errs/$NN.spc
+    rm -f .tmp
+
+    # Some patches (like 678) do not have Index line for everything,
+    # so looking for Index: line is not good enough.
+    sed -n -e 's|^--- linux/\([^	]*\).*|\1|p' \
+	   -e 's|^+++ linux/\([^	]*\).*|\1|p' $FILE |
+    sort -u |
+    xargs -r git-update-cache --add --remove --
+    if test -d BitKeeper
+    then
+      find BitKeeper -type f -print |
+      while read path
+      do
+      	echo removing "$path"
+      done | tee -a ../errs/$NN.spc
+      find BitKeeper -type f -print0 |
+      xargs -0 -r git-update-cache --force-remove --
+      rm -fr BitKeeper
+    fi
+  }
+
+  T=`git-write-tree` &&
+  C=$(echo "$LOG" | git-commit-tree $T $P) &&
+  echo $C >.git/HEAD &&
+
+  P="-p $C" || exit
+
+  # Look at the Makefile change and make a tag.
+  git-diff-tree -p $C Makefile |
+  sed -ne '
+    /^[-+]VERSION =/{
+  	p
+	q
+    }
+    /^[-+]PATCHLEVEL =/{
+  	p
+	q
+    }
+    /^[-+]SUBLEVEL =/{
+  	p
+	q
+    }
+    /^[-+]EXTRAVERSION =/{
+  	p
+	q
+    }
+  ' >.tmp
+  if test -s .tmp
+  then
+      v=$((sed -ne '/^VERSION/p;/^PATCHLEVEL/p;/^SUBLEVEL/p;/^EXTRAVERSION/p' \
+          Makefile; cat ../sayVersion) | make -f -)
+      if test -f ".git/refs/tags/$v"
+      then
+          echo "* $v (duplicate)"
+	  echo "$C	$v" >>../duplicate-tags
+      else
+	  echo "$C" >".git/refs/tags/$v"
+	  echo "* $v"
+      fi
+  fi
+  rm -f .tmp
+
+  # 70a29f4bd97bbb78fac1cc7f87c13fb08d1a12cd == v2.4.0.6
+
+  # Pack
+  if expr \( $N = 2 \) \| \( $N % $CPP = 0 \) >/dev/null
+  then
+    {
+	echo "* packing"
+	du -sh .git/objects &&
+	case "$N" in
+	2)
+	    pack=$(git-rev-list --objects $C | \
+		   git-pack-objects ../pack/pack-$NN)
+	    ;;
+	*)
+	    pack=$(git-rev-list --unpacked --objects $C | \
+		   git-pack-objects --incremental ../pack/pack-$NN)
+	    ;;
+	esac &&
+	ln ../pack/pack-$NN-$pack.idx ../pack/pack-$NN-$pack.pack \
+		.git/objects/pack/. &&
+	git-prune-packed &&
+	du -sh .git/objects
+    } 2>&1 | tee ../errs/$NN.packlog
+  fi
+  test -f ../errs/$NN.spc || rm -f ../errs/$NN.out
+
+  N=`expr $N + 1`
+done

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

[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 unique to git, until we get to the current head:

Take the last imported commit - we'll call this branch A.
Take the 2.6.12-rc2 initial commit, we'll call this branch B.

This algorithm should stitch things together:

For each commit on branch B
	Copy all commit metadata (author,etc)
	Add a new parent Ai.
	Take the trees from commit B.
	Write a new commit, Ai+1

When we get to HEAD, we replace HEAD with this last commit we have
created, and we now have a nice, parallel commit tree that stitches
everything back together.

Working from the initial import up, you'll need to work in parallel and
handle create some mappings of "old commit" to "new commit" to create
all the merges with the new commit ids, but I think  this should be
pretty straightforward to do.

If this is all integrated, I'd suggest unpacking everything but the
packs that are currently in the main tree, and repacking one very big
pack to get the maximum posible benefit from the deltas.

-- 

Ryan Anderson
  sometimes Pug Majere

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

[Junio C Hamano]

Ryan Anderson <ryan@michonline.com> 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 end up with 2 commits for every
> change/merge that's unique to git, until we get to the current head:

Aren't you essentially rewriting the history after 2.6.12-rc2?.
I suspect that would invalidate the current linux-2.6 history
people have been basing their work on since 2.6.12-rc2, which is
unacceptable.  That is not what I meant by "grafting".

What I meant was to give a hint to the core that says "this
2.6.12-rc2 commit in the current linux-2.6.git tree is recorded
as not having a parent, but please consider it the same as this
other 2.6.12-rc2 commit in the 2.4.0->2.6.12-rc2 history when
traversing the commit ancestry chain".

If git-rev-list is taught about that, then you will see "git
log" going across 2.6.12-rc2.  If git-merge-base is taught about
that, it will be able to find a merge base to merge a line of
development that is forked from say 2.6.11 to the current tip of
linux-2.6 tree.

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

[Ryan Anderson]

On Fri, Jul 22, 2005 at 12:46:36PM -0700, Junio C Hamano wrote:
> Ryan Anderson <ryan@michonline.com> 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 end up with 2 commits for every
> > change/merge that's unique to git, until we get to the current head:
> 
> Aren't you essentially rewriting the history after 2.6.12-rc2?.
> I suspect that would invalidate the current linux-2.6 history
> people have been basing their work on since 2.6.12-rc2, which is
> unacceptable.  That is not what I meant by "grafting".

hmm, I may have been a bit too terse.

Each new commit would have at least two parents:
	The commit from the current, 2.6.12-rc2 based tree.
	The commits generated by this process that have, as one of their
	children, the parents of the current commit from the 2.6.12-rc2
	based tree.

That will mean all the merge tools will find a common base, and, at
worst, cycle through an extra commit that should add *no* extra issues.

Let me see if I can draw a picture of 5 or 6 commit tree:

Today:

A0->->-A1->->-A2
 \           /
  \--B1->->-/


Stiched together:

  A0->->-A1->->-A2
  |\      |    / |
  | \--B1->->-/  |
  |    |  |      |
O-M0->->-M1->->->M2
   \   |        /
    \--N1->->->/

O being the old tree we're grafting on.

So, M0 would have parents of A0 and O, and the commit metadata from A0
N1 would have parents of M0 and B1, and the commit metadata from B1
M1 would have parents of A1 and M0, and the commit metadata from A1
M2 would have parents of A2, M1, and N1 and the commit metadata from A2

Does that help?

-- 

Ryan Anderson
  sometimes Pug Majere

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

[A Large Angry SCM]

Junio C Hamano wrote:
> Ryan Anderson <ryan@michonline.com> 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 end up with 2 commits for every
>>change/merge that's unique to git, until we get to the current head:
> 
> Aren't you essentially rewriting the history after 2.6.12-rc2?.
> I suspect that would invalidate the current linux-2.6 history
> people have been basing their work on since 2.6.12-rc2, which is
> unacceptable.  That is not what I meant by "grafting".
> 
> What I meant was to give a hint to the core that says "this
> 2.6.12-rc2 commit in the current linux-2.6.git tree is recorded
> as not having a parent, but please consider it the same as this
> other 2.6.12-rc2 commit in the 2.4.0->2.6.12-rc2 history when
> traversing the commit ancestry chain".
> 
> If git-rev-list is taught about that, then you will see "git
> log" going across 2.6.12-rc2.  If git-merge-base is taught about
> that, it will be able to find a merge base to merge a line of
> development that is forked from say 2.6.11 to the current tip of
> linux-2.6 tree.

I think that "rewriting history" in this case may be the better option 
in _this_ case. But only because the tools are new and the users are 
understanding. :-)

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 lookup/read objects to look there first 
and to _not_ care about invalid SHAs. Of course, if you do this, you 
will never be able to trust your repository.

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

[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 lookup/read objects to look there first 
> and to _not_ care about invalid SHAs. Of course, if you do this, you 
> will never be able to trust your repository.

You can do it much more nicely if you want.

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.

			Linus

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

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> 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, thanks.  That was exactly what I meant by
"grafting".

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

[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 you want to version control them, that's fine, but don't tie the
versioning to the main project itself. You can have a _separate_ git
index, and a separate branch for the preferences and other metadata (but
you can, if you want to, obviously share the .git directory contents and
mix up the objects).

The thing is, different people might want to tie in these things different
ways. For example, one thing this kind of "grafting" is useful for is to
literally graft two different projects together, even if you may actually
want to export them independently (ie you do _not_ want the graftign
itself to be visible when you export it).

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 (think "git" vs "gitk" - rather than 
having a very tight merge like I did, we could have tried to make it be a 
more virtual graft instead).

And personal preferences are just that - personal. I do _not_ want to have 
the kernel project history have things like "editor preferences" etc in 
the revision history - you might want to revision them, but that would be 
totally independent of the history of the project itself.

		Linus

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

[Santi Béjar]

Linus Torvalds <torvalds@osdl.org> 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 (think "git" vs "gitk" - rather than 
> having a very tight merge like I did, we could have tried to make it be a 
> more virtual graft instead).

One posibility for a collection of projects is to make them with a tree of
commits instead of a tree of trees and blobs.

    Santi

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

[Junio C Hamano]

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?

I hope you are not vetoing the ongoing discussion in another
thread from including the per-project configuration.

Some people want to run their project differently, and one thing
I see often done is to have pre-commit hooks that always run
test suites [*1*].  I do not think it is an unreasonable thing for
Porcelains to support, and what I am trying to get at is if two
Porcelains decide to support it, they do it in a compatible way.

> And personal preferences are just that - personal. I do _not_ want to have 
> the kernel project history have things like "editor preferences" etc in 
> the revision history - you might want to revision them, but that would be 
> totally independent of the history of the project itself.

I agree.  The .gitinfo/fake-parents may be a good thing in that
sense to have project-wide, and as long as the kernel person
(that is you) do not add .gitinfo/commit-template you would be
happy, wouldn't you?


[Footnote]

*1* Personally sometimes I feel myself that is silly, but that
is _other_ people's project, not my own.  I think letting them
follow their own workflow to slow themselves is better than
outright forbidding it and telling them not to do it.

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

[Linus Torvalds]

On Fri, 22 Jul 2005, Junio C Hamano wrote:
> 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

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

[Petr Baudis]

Dear diary, on Fri, Jul 22, 2005 at 11:53:41PM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> 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" ;-).
> 
> I'd _really_ prefer to not have any preferences or other metadata files
> under version control within that same project.
> 
> If you want to version control them, that's fine, but don't tie the
> versioning to the main project itself. You can have a _separate_ git
> index, and a separate branch for the preferences and other metadata (but
> you can, if you want to, obviously share the .git directory contents and
> mix up the objects).

I think that is a bad idea. Suddenly, you do not have the two things in
the same timeline, which may be quite confusing especially in case of
some hooks which depend on the contents of the tree of the project
itself, in case of commit templates and such.

> And personal preferences are just that - personal. I do _not_ want to have 
> the kernel project history have things like "editor preferences" etc in 
> the revision history - you might want to revision them, but that would be 
> totally independent of the history of the project itself.

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.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone.  -- Alan Cox

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

[Petr Baudis]

Dear diary, on Sat, Jul 23, 2005 at 01:26:07AM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> told me that...
> On Fri, 22 Jul 2005, Junio C Hamano wrote:
> > 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.

Some example of possible per-project settings:

	pre-commit hook killing trailing whitespaces
	global per-project ignore file (*.ko or something)
	common base commit template
		(standardized form developer fills in when committing,
		 some remindments in the comment section, ...)

Obviously, you still ought to have a way to locally override any of
those per-repository in your .git/conf/.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone.  -- Alan Cox

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

[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 alters the settings locally.

EVERY SINGLE TIME he does a "cg-commit", those local alterations would get 
committed, since that config file is part of the same project, and cogito 
by default commits all changes.

That's just insane. It means that in practive it's simply not reasonable 
to have your own local copies of that file. So what would you do? You'd 
add more and more hacks to cover this up, and have a "commit-ignore" file 
that ignores the .gitinfo files etc etc. UGLY. All because of a design 
mistake.

In contrast, let's say that the .gitinfo/xyzzy files were in another 
unrelated branch altogether: that means that normally those files wouldn't 
even be seen by git as being under revision control (the "index" file 
doesn't mention them, nor the tree pointed to by HEAD), but you could, if 
you wanted to, do a simple

	#
	# edit the control files  and check the
	# changes  in to the control stream
	#
	git switch control-files
	.. edit .gitinfo/xyzzy
	git commit --all

	#
	# get back to the real project
	#
	git switch master

and it just works. In the above "git switch" would be exactly the same as
a normal "git checkout", except it's told to not update the current
directory contexts on switch and instead just save the index file away and
restore it. (In contrast, using a full "git checkout" would remove the
real project when switching to the control files, and then again remove
the control files when switching back to the main project).

		Linus

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

[Petr Baudis]

Dear diary, on Sat, Jul 23, 2005 at 01:50:09AM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> 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 be still normally
> > overridden or altered locally in each repository.
> 
> What you are describing is a nightmare.
> 
> Let's assume that a user alters the settings locally.
> 
> EVERY SINGLE TIME he does a "cg-commit", those local alterations would get 
> committed, since that config file is part of the same project, and cogito 
> by default commits all changes.

No, no, no. A user does not alter the settings locally in .gitinfo/ -
.gitinfo/ is for per-_project_ stuff, not per-user. If user wants an
override, he does it per-repository in his .git/conf directory, which is
not version-tracked (actually, core GIT does not even let me to).

> That's just insane. It means that in practive it's simply not reasonable 
> to have your own local copies of that file. So what would you do? You'd 
> add more and more hacks to cover this up, and have a "commit-ignore" file 
> that ignores the .gitinfo files etc etc. UGLY. All because of a design 
> mistake.

Actually, commit-ignore might be useful in other cases, e.g. when
someone (me, a thousand times in the past) needs to keep temporary hacks
in the Makefile so that he can actually build the thing on his weird
system etc. ;-)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone.  -- Alan Cox

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

[Junio C Hamano]

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.