threads / patch / 1292

patch, 2 partsapply.c: a fix and an enhancement

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

## tl;dr

16 messages between Jul 22, 2005 and Jul 23, 2005. Diffs are folded; open one to read it.

replies: 15people: 6as markdown or json

Junio C Hamano· Jul 22, 2005, 16:56 UTC · lore

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(-)
Show changes to build-git-tree +177 −0
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
Ryan Anderson· Jul 22, 2005, 18:18 UTC · re: Junio C Hamano · lore

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

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
Junio C Hamano· Jul 22, 2005, 19:46 UTC · re: Ryan Anderson · lore

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

Ryan Anderson <ryan@michonline.com> writes:
Show 7 quoted lines
> 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.

Ryan Anderson· Jul 22, 2005, 20:16 UTC · re: Junio C Hamano · lore

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

On Fri, Jul 22, 2005 at 12:46:36PM -0700, Junio C Hamano wrote:
Show 14 quoted lines
> 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
A Large Angry SCM· Jul 22, 2005, 20:29 UTC · re: Junio C Hamano · lore

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

Junio C Hamano wrote:
Show 25 quoted lines
> 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.

Linus Torvalds· Jul 22, 2005, 20:43 UTC · re: A Large Angry SCM · lore

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

On Fri, 22 Jul 2005, A Large Angry SCM wrote:
Show 7 quoted lines
> 
> 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
Junio C Hamano· Jul 22, 2005, 21:20 UTC · re: Linus Torvalds · lore

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

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

Linus Torvalds· Jul 22, 2005, 21:53 UTC · re: Junio C Hamano · lore

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

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
Santi Béjar· Jul 22, 2005, 22:42 UTC · re: Linus Torvalds · lore

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

Linus Torvalds <torvalds@osdl.org> writes:
Show 6 quoted lines
> 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
Junio C Hamano· Jul 22, 2005, 22:55 UTC · re: Linus Torvalds · lore

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

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.

Linus Torvalds· Jul 22, 2005, 23:26 UTC · re: Junio C Hamano · lore

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

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
Petr Baudis· Jul 22, 2005, 23:39 UTC · re: Linus Torvalds · lore

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

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...

Show 16 quoted lines
> 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
Junio C Hamano· Jul 23, 2005, 00:20 UTC · re: Linus Torvalds · lore

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

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.

Petr Baudis· Jul 22, 2005, 23:33 UTC · re: Linus Torvalds · lore

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

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...

Show 13 quoted lines
> 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
Linus Torvalds· Jul 22, 2005, 23:50 UTC · re: Petr Baudis · lore

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

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
Petr Baudis· Jul 22, 2005, 23:59 UTC · re: Linus Torvalds · lore

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

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...

Show 15 quoted lines
> 
> 
> 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).

Show 5 quoted lines
> 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

← back to recent threads