{"thread":{"id":"1292","subject":"[PATCH 0/2] apply.c: a fix and an enhancement","startedAt":"2005-07-22T16:56:19Z","lastAt":"2005-07-23T00:20:53Z","messageCount":16,"participants":["Junio C Hamano","Ryan Anderson","A Large Angry SCM","Linus Torvalds","Santi Béjar","Petr Baudis"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"6306","messageId":"7vzmsewzik.fsf@assigned-by-dhcp.cox.net","threadId":"1292","inReplyTo":null,"subject":"[PATCH 0/2] apply.c: a fix and an enhancement","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-22T16:56:19Z","receivedAt":"2005-07-22T16:56:19Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"In mid April, Ingo announced availability of his conversion from\nCVS to a flat patchset format:\n\n    From: Ingo Molnar <mingo@elte.hu>\n    Subject: full kernel history, in patchset format\n    Message-ID: <20050416131528.GB19908@elte.hu>\n\n    the history data starts at 2.4.0 and ends at 2.6.12-rc2. I've included a \n    script that will apply all the patches in order and will create a \n    pristine 2.6.12-rc2 tree.\n    ...\n    note: i kept the patches the cvsps utility generated as-is, to have a \n    verifiable base to work on. There were a very small amount of deltas \n    missed (about a dozen), probably resulting from CVS related errors, \n    these are included in the diff-CVS-to-real patch. Also, the patch format \n\nI was futzing with the script in Ingo's tarball, which\noriginally used \"patch\".  After converting it to use\n'git-apply', I had some troubles with applying patches, which\neventually led me to find out and fix a corner case bug ---\ngit-apply did not handle files with an incomplete line correctly\nin some cases.\n\nAfter I fixed that problem, the script still found some more\nerrors in the patchset, but after manual inspection it looked to\nme that they are problems not on the patch application side, but\non the patch generation side.  I only checked 2.4.0, 2.6.9,\n2.6.11 and 2.6.12-rc2, but the trees built were byte-to-byte\nequivalent, except that the file executable bits, which are\npreserved in the patch series.\n\nThe patch attached to this message is not for inclusion in the\ngit source tree.  It is the script I used for conversion.  You\nwill need the following patches to apply.c for it to work, which\nwill be sent separately:\n\n  [PATCH 1/2] apply.c: handle incomplete lines correctly.\n  [PATCH 2/2] apply.c: --exclude=fnmatch-pattern option.\n\nI did this not because I was particularly interested in the\nancient kernel history, but because I wanted to see how well\npacks perform.  Here are some numbers that may be of interest.\n\n    26M pack-000002.pack    18M pack-015360.pack\n    48M pack-001024.pack    21M pack-016384.pack\n    22M pack-002048.pack    18M pack-017408.pack\n    20M pack-003072.pack    19M pack-018432.pack\n    21M pack-004096.pack    17M pack-019456.pack\n    24M pack-005120.pack    22M pack-020480.pack\n    20M pack-006144.pack    20M pack-021504.pack\n    20M pack-007168.pack    17M pack-022528.pack\n    24M pack-008192.pack    23M pack-023552.pack\n    19M pack-009216.pack    16M pack-024576.pack\n    24M pack-010240.pack    21M pack-025600.pack\n    20M pack-011264.pack    19M pack-026624.pack\n    23M pack-012288.pack    18M pack-027648.pack\n    21M pack-013312.pack    17M pack-028237.pack\n    18M pack-014336.pack\n\nThe script makes a full pack after importing 2.4.0 (which is the\npatchset #2), and then makes an incremental every 1024 commits,\nso the baseline pack is 26MB and the first incremental up to the\npatchset #1024 is 48MB.  It averages at around 20MB per 1024\ncommits.  The repository with the full history, repacked into a\nsingle pack, is 203MB (370291 objects).\n\n\n------------\nA script to slurp full 2.4.0->2.6.12-rc2 history.\n\nCreate an empty directory, put the \"build-git-tree\" script in it, \nand extract Ingo's CVSPS conversion result, available at:\n\n  http://kernel.org/pub/linux/kernel/people/mingo/Linux-2.6-patchset/\n\nin it.  Make sure the definition of variable PS matches the name\nof the directory you extracted the tarball, and run the script.\nSome hours later, you will have linux/ directory whose .git\nsubdirectory has a GITified full 2.4.0->2.6.12-rc2 history.\n\nNow if we had a mechanism to graft a later history which starts\nat 2.6.12-rc2 on top of this earlier history leading up to\nit,...  ;-)\n\nSigned-off-by: Junio C Hamano <junkio@cox.net>\n---\n\n build-git-tree |  177 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++\n 1 files changed, 177 insertions(+), 0 deletions(-)\n\ndiff --git a/build-git-tree b/build-git-tree\nnew file mode 100755\n--- /dev/null\n+++ b/build-git-tree\n@@ -0,0 +1,177 @@\n+#!/bin/sh\n+\n+PS=linux-2.4.0-to-2.6.12-rc2-patchset\n+cat build-git-tree >build-git-tree-next\n+cat >sayVersion <<\\EOF\n+default:\n+\t@echo \"v$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION)\"\n+EOF\n+\n+: >duplicate-tags\n+\n+: ${END=28237}\n+: ${CPP=1024}\n+\n+sedScript='\n+    /^Date: /{\n+\ts/^Date: \\(.*\\)/\\1/\n+        s/'\\''/'\\''\\\\'\\'''\\''/g\n+\ts/^.*/DATE='\\''&'\\''/p\n+    }\n+    /^Author: /{\n+\ts/^Author: \\(.*\\)/\\1/\n+        s/'\\''/'\\''\\\\'\\'''\\''/g\n+\ts/^.*/AUTHOR='\\''&'\\''/p\n+    }\n+    /^Log:$/{\n+\tn\n+\tb LOOP\n+    }\n+    b\n+   : LOOP\n+    /^BKrev: /{\n+\tg\n+\ts/^\\n//\n+\ts/\\n$//\n+\ts/'\\''/'\\''\\\\'\\'''\\''/g\n+\ts/^.*/LOG='\\''&'\\''/p\n+\tq\n+    }\n+    H\n+    n\n+    b LOOP\n+'\n+\n+rm -fr errs linux pack && mkdir -p linux/Documentation errs pack || exit\n+cp $PS/logo.gif linux/Documentation\n+\n+cd linux\n+git-init-db\n+git-ls-files --cached -z |\n+xargs -0 -r git-update-cache --add --remove --\n+find ?* -type f -print0 | xargs -0 -r git-update-cache --add --\n+\n+N=1 P=\n+while expr $N \\<= $END >/dev/null\n+do\n+  NN=$(printf \"%06d\" $N)\n+  FILE=../$PS/patches/$N.patch\n+\n+  e=`sed -ne \"$sedScript\" $FILE` &&\n+  eval \"$e\" &&\n+\n+  GIT_AUTHOR_NAME=\"$AUTHOR\" &&\n+  GIT_AUTHOR_EMAIL=\"$AUTHOR\" &&\n+  GIT_COMMITTER_NAME=\"$AUTHOR\" &&\n+  GIT_COMMITTER_EMAIL=\"$AUTHOR\" &&\n+  GIT_AUTHOR_DATE=\"+0000 $DATE\" &&\n+  GIT_COMMITTER_DATE=\"+0000 $DATE\" &&\n+\n+  export GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_COMMITTER_NAME \\\n+         GIT_COMMITTER_EMAIL GIT_AUTHOR_DATE GIT_COMMITTER_DATE &&\n+\n+  echo \"* $NN - $AUTHOR - $DATE\" &&\n+\n+  git-apply --exclude='BitKeeper/*' --index --summary --apply \\\n+  \t<$FILE >../errs/$NN.out 2>&1 || {\n+    # Special case.\n+    patch -E -p1 <$FILE >../errs/$NN.spc 2>&1\n+    sed -ne 's|^File \\(.*\\) is not empty after patch, as expected$|\\1|p' \\\n+        <../errs/$NN.spc |\n+    while read path\n+    do\n+        echo \"* expected to be empty: $path\"\n+        ls -l \"$path\"\n+\trm -f \"$path\"\n+    done >.tmp\n+    cat .tmp >>../errs/$NN.spc\n+    rm -f .tmp\n+\n+    # Some patches (like 678) do not have Index line for everything,\n+    # so looking for Index: line is not good enough.\n+    sed -n -e 's|^--- linux/\\([^\t]*\\).*|\\1|p' \\\n+\t   -e 's|^+++ linux/\\([^\t]*\\).*|\\1|p' $FILE |\n+    sort -u |\n+    xargs -r git-update-cache --add --remove --\n+    if test -d BitKeeper\n+    then\n+      find BitKeeper -type f -print |\n+      while read path\n+      do\n+      \techo removing \"$path\"\n+      done | tee -a ../errs/$NN.spc\n+      find BitKeeper -type f -print0 |\n+      xargs -0 -r git-update-cache --force-remove --\n+      rm -fr BitKeeper\n+    fi\n+  }\n+\n+  T=`git-write-tree` &&\n+  C=$(echo \"$LOG\" | git-commit-tree $T $P) &&\n+  echo $C >.git/HEAD &&\n+\n+  P=\"-p $C\" || exit\n+\n+  # Look at the Makefile change and make a tag.\n+  git-diff-tree -p $C Makefile |\n+  sed -ne '\n+    /^[-+]VERSION =/{\n+  \tp\n+\tq\n+    }\n+    /^[-+]PATCHLEVEL =/{\n+  \tp\n+\tq\n+    }\n+    /^[-+]SUBLEVEL =/{\n+  \tp\n+\tq\n+    }\n+    /^[-+]EXTRAVERSION =/{\n+  \tp\n+\tq\n+    }\n+  ' >.tmp\n+  if test -s .tmp\n+  then\n+      v=$((sed -ne '/^VERSION/p;/^PATCHLEVEL/p;/^SUBLEVEL/p;/^EXTRAVERSION/p' \\\n+          Makefile; cat ../sayVersion) | make -f -)\n+      if test -f \".git/refs/tags/$v\"\n+      then\n+          echo \"* $v (duplicate)\"\n+\t  echo \"$C\t$v\" >>../duplicate-tags\n+      else\n+\t  echo \"$C\" >\".git/refs/tags/$v\"\n+\t  echo \"* $v\"\n+      fi\n+  fi\n+  rm -f .tmp\n+\n+  # 70a29f4bd97bbb78fac1cc7f87c13fb08d1a12cd == v2.4.0.6\n+\n+  # Pack\n+  if expr \\( $N = 2 \\) \\| \\( $N % $CPP = 0 \\) >/dev/null\n+  then\n+    {\n+\techo \"* packing\"\n+\tdu -sh .git/objects &&\n+\tcase \"$N\" in\n+\t2)\n+\t    pack=$(git-rev-list --objects $C | \\\n+\t\t   git-pack-objects ../pack/pack-$NN)\n+\t    ;;\n+\t*)\n+\t    pack=$(git-rev-list --unpacked --objects $C | \\\n+\t\t   git-pack-objects --incremental ../pack/pack-$NN)\n+\t    ;;\n+\tesac &&\n+\tln ../pack/pack-$NN-$pack.idx ../pack/pack-$NN-$pack.pack \\\n+\t\t.git/objects/pack/. &&\n+\tgit-prune-packed &&\n+\tdu -sh .git/objects\n+    } 2>&1 | tee ../errs/$NN.packlog\n+  fi\n+  test -f ../errs/$NN.spc || rm -f ../errs/$NN.out\n+\n+  N=`expr $N + 1`\n+done\n"},{"id":"6309","messageId":"20050722181800.GU20369@mythryan2.michonline.com","threadId":"1292","inReplyTo":"7vzmsewzik.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 0/2] apply.c: a fix and an enhancement","fromName":"Ryan Anderson","fromEmail":"ryan@michonline.com","sentAt":"2005-07-22T18:18:00Z","receivedAt":"2005-07-22T18:18:00Z","isPatch":true,"sender":{"key":"ryan@michonline.com","avatar":null},"body":"On Fri, Jul 22, 2005 at 09:56:19AM -0700, Junio C Hamano wrote:\n> Now if we had a mechanism to graft a later history which starts\n> at 2.6.12-rc2 on top of this earlier history leading up to\n> it,...  ;-)\n\nWe do - it's not even very hard, we just end up with 2 commits for every\nchange/merge that's unique to git, until we get to the current head:\n\nTake the last imported commit - we'll call this branch A.\nTake the 2.6.12-rc2 initial commit, we'll call this branch B.\n\nThis algorithm should stitch things together:\n\nFor each commit on branch B\n\tCopy all commit metadata (author,etc)\n\tAdd a new parent Ai.\n\tTake the trees from commit B.\n\tWrite a new commit, Ai+1\n\nWhen we get to HEAD, we replace HEAD with this last commit we have\ncreated, and we now have a nice, parallel commit tree that stitches\neverything back together.\n\nWorking from the initial import up, you'll need to work in parallel and\nhandle create some mappings of \"old commit\" to \"new commit\" to create\nall the merges with the new commit ids, but I think  this should be\npretty straightforward to do.\n\nIf this is all integrated, I'd suggest unpacking everything but the\npacks that are currently in the main tree, and repacking one very big\npack to get the maximum posible benefit from the deltas.\n\n-- \n\nRyan Anderson\n  sometimes Pug Majere\n"},{"id":"6311","messageId":"7vsly6vd2b.fsf@assigned-by-dhcp.cox.net","threadId":"1292","inReplyTo":"20050722181800.GU20369@mythryan2.michonline.com","subject":"Re: [PATCH 0/2] apply.c: a fix and an enhancement","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-22T19:46:36Z","receivedAt":"2005-07-22T19:46:36Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ryan Anderson <ryan@michonline.com> writes:\n\n> On Fri, Jul 22, 2005 at 09:56:19AM -0700, Junio C Hamano wrote:\n>> Now if we had a mechanism to graft a later history which starts\n>> at 2.6.12-rc2 on top of this earlier history leading up to\n>> it,...  ;-)\n>\n> We do - it's not even very hard, we just end up with 2 commits for every\n> change/merge that's unique to git, until we get to the current head:\n\nAren't you essentially rewriting the history after 2.6.12-rc2?.\nI suspect that would invalidate the current linux-2.6 history\npeople have been basing their work on since 2.6.12-rc2, which is\nunacceptable.  That is not what I meant by \"grafting\".\n\nWhat I meant was to give a hint to the core that says \"this\n2.6.12-rc2 commit in the current linux-2.6.git tree is recorded\nas not having a parent, but please consider it the same as this\nother 2.6.12-rc2 commit in the 2.4.0->2.6.12-rc2 history when\ntraversing the commit ancestry chain\".\n\nIf git-rev-list is taught about that, then you will see \"git\nlog\" going across 2.6.12-rc2.  If git-merge-base is taught about\nthat, it will be able to find a merge base to merge a line of\ndevelopment that is forked from say 2.6.11 to the current tip of\nlinux-2.6 tree.\n"},{"id":"6312","messageId":"20050722201606.GV20369@mythryan2.michonline.com","threadId":"1292","inReplyTo":"7vsly6vd2b.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 0/2] apply.c: a fix and an enhancement","fromName":"Ryan Anderson","fromEmail":"ryan@michonline.com","sentAt":"2005-07-22T20:16:06Z","receivedAt":"2005-07-22T20:16:06Z","isPatch":true,"sender":{"key":"ryan@michonline.com","avatar":null},"body":"On Fri, Jul 22, 2005 at 12:46:36PM -0700, Junio C Hamano wrote:\n> Ryan Anderson <ryan@michonline.com> writes:\n> \n> > On Fri, Jul 22, 2005 at 09:56:19AM -0700, Junio C Hamano wrote:\n> >> Now if we had a mechanism to graft a later history which starts\n> >> at 2.6.12-rc2 on top of this earlier history leading up to\n> >> it,...  ;-)\n> >\n> > We do - it's not even very hard, we just end up with 2 commits for every\n> > change/merge that's unique to git, until we get to the current head:\n> \n> Aren't you essentially rewriting the history after 2.6.12-rc2?.\n> I suspect that would invalidate the current linux-2.6 history\n> people have been basing their work on since 2.6.12-rc2, which is\n> unacceptable.  That is not what I meant by \"grafting\".\n\nhmm, I may have been a bit too terse.\n\nEach new commit would have at least two parents:\n\tThe commit from the current, 2.6.12-rc2 based tree.\n\tThe commits generated by this process that have, as one of their\n\tchildren, the parents of the current commit from the 2.6.12-rc2\n\tbased tree.\n\nThat will mean all the merge tools will find a common base, and, at\nworst, cycle through an extra commit that should add *no* extra issues.\n\nLet me see if I can draw a picture of 5 or 6 commit tree:\n\nToday:\n\nA0->->-A1->->-A2\n \\           /\n  \\--B1->->-/\n\n\nStiched together:\n\n  A0->->-A1->->-A2\n  |\\      |    / |\n  | \\--B1->->-/  |\n  |    |  |      |\nO-M0->->-M1->->->M2\n   \\   |        /\n    \\--N1->->->/\n\nO being the old tree we're grafting on.\n\nSo, M0 would have parents of A0 and O, and the commit metadata from A0\nN1 would have parents of M0 and B1, and the commit metadata from B1\nM1 would have parents of A1 and M0, and the commit metadata from A1\nM2 would have parents of A2, M1, and N1 and the commit metadata from A2\n\nDoes that help?\n\n-- \n\nRyan Anderson\n  sometimes Pug Majere\n"},{"id":"6313","messageId":"42E1571B.8070108@gmail.com","threadId":"1292","inReplyTo":"7vsly6vd2b.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 0/2] apply.c: a fix and an enhancement","fromName":"A Large Angry SCM","fromEmail":"gitzilla@gmail.com","sentAt":"2005-07-22T20:29:15Z","receivedAt":"2005-07-22T20:29:15Z","isPatch":true,"sender":{"key":"gitzilla@gmail.com","avatar":"https://gravatar.com/avatar/354625c442439908ff3dd99757dee330e29e9df7847472384faf7a00add247fb?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> Ryan Anderson <ryan@michonline.com> writes:\n> \n>>On Fri, Jul 22, 2005 at 09:56:19AM -0700, Junio C Hamano wrote:\n>>>Now if we had a mechanism to graft a later history which starts\n>>>at 2.6.12-rc2 on top of this earlier history leading up to\n>>>it,...  ;-)\n>>We do - it's not even very hard, we just end up with 2 commits for every\n>>change/merge that's unique to git, until we get to the current head:\n> \n> Aren't you essentially rewriting the history after 2.6.12-rc2?.\n> I suspect that would invalidate the current linux-2.6 history\n> people have been basing their work on since 2.6.12-rc2, which is\n> unacceptable.  That is not what I meant by \"grafting\".\n> \n> What I meant was to give a hint to the core that says \"this\n> 2.6.12-rc2 commit in the current linux-2.6.git tree is recorded\n> as not having a parent, but please consider it the same as this\n> other 2.6.12-rc2 commit in the 2.4.0->2.6.12-rc2 history when\n> traversing the commit ancestry chain\".\n> \n> If git-rev-list is taught about that, then you will see \"git\n> log\" going across 2.6.12-rc2.  If git-merge-base is taught about\n> that, it will be able to find a merge base to merge a line of\n> development that is forked from say 2.6.11 to the current tip of\n> linux-2.6 tree.\n\nI think that \"rewriting history\" in this case may be the better option \nin _this_ case. But only because the tools are new and the users are \nunderstanding. :-)\n\nTo do it without the history rewrite, create an alternate_history \ndirectory under .git with it's own objects tree. And populate that \nobject tree with \"alternative\" content for the objects in the normal \ntrees. Then teach the things the lookup/read objects to look there first \nand to _not_ care about invalid SHAs. Of course, if you do this, you \nwill never be able to trust your repository.\n"},{"id":"6316","messageId":"Pine.LNX.4.58.0507221340450.6074@g5.osdl.org","threadId":"1292","inReplyTo":"42E1571B.8070108@gmail.com","subject":"Re: [PATCH 0/2] apply.c: a fix and an enhancement","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-07-22T20:43:17Z","receivedAt":"2005-07-22T20:43:17Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 22 Jul 2005, A Large Angry SCM wrote:\n> \n> To do it without the history rewrite, create an alternate_history \n> directory under .git with it's own objects tree. And populate that \n> object tree with \"alternative\" content for the objects in the normal \n> trees. Then teach the things the lookup/read objects to look there first \n> and to _not_ care about invalid SHAs. Of course, if you do this, you \n> will never be able to trust your repository.\n\nYou can do it much more nicely if you want.\n\nJust teach \"parse_commit()\" to look at a \".git/fake_parents\" file, and \ninsert fake extra parents for commits that way - you can graft any tree on \ntop of any other tree that way, and it's probably a nice idea for testing \nthings out.\n\n\t\t\tLinus\n"},{"id":"6326","messageId":"7vhdempmgg.fsf@assigned-by-dhcp.cox.net","threadId":"1292","inReplyTo":"Pine.LNX.4.58.0507221340450.6074@g5.osdl.org","subject":"Re: [PATCH 0/2] apply.c: a fix and an enhancement","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-22T21:20:15Z","receivedAt":"2005-07-22T21:20:15Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds <torvalds@osdl.org> writes:\n\n> Just teach \"parse_commit()\" to look at a \".git/fake_parents\" file, and \n> insert fake extra parents for commits that way - you can graft any tree on \n> top of any other tree that way, and it's probably a nice idea for testing \n> things out.\n\nNicely put, thanks.  That was exactly what I meant by\n\"grafting\".\n\nAnd the file would obviously be per-project, so according to\nPasky's suggestion that would be \".gitinfo/fake_parents\" ;-).\n"},{"id":"6330","messageId":"Pine.LNX.4.58.0507221447420.6074@g5.osdl.org","threadId":"1292","inReplyTo":"7vhdempmgg.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 0/2] apply.c: a fix and an enhancement","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-07-22T21:53:41Z","receivedAt":"2005-07-22T21:53:41Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 22 Jul 2005, Junio C Hamano wrote:\n> \n> And the file would obviously be per-project, so according to\n> Pasky's suggestion that would be \".gitinfo/fake_parents\" ;-).\n\nI'd _really_ prefer to not have any preferences or other metadata files\nunder version control within that same project.\n\nIf you want to version control them, that's fine, but don't tie the\nversioning to the main project itself. You can have a _separate_ git\nindex, and a separate branch for the preferences and other metadata (but\nyou can, if you want to, obviously share the .git directory contents and\nmix up the objects).\n\nThe thing is, different people might want to tie in these things different\nways. For example, one thing this kind of \"grafting\" is useful for is to\nliterally graft two different projects together, even if you may actually\nwant to export them independently (ie you do _not_ want the graftign\nitself to be visible when you export it).\n\nThink of something like a collection of projects, each under their own \nsubdirectory. We could eventually literally make them _look_ like one big \nproject, with cross-project commits grafted together, but they'd \ntechnically be totally independent (think \"git\" vs \"gitk\" - rather than \nhaving a very tight merge like I did, we could have tried to make it be a \nmore virtual graft instead).\n\nAnd personal preferences are just that - personal. I do _not_ want to have \nthe kernel project history have things like \"editor preferences\" etc in \nthe revision history - you might want to revision them, but that would be \ntotally independent of the history of the project itself.\n\n\t\tLinus\n"},{"id":"6335","messageId":"87d5pa1mzq.fsf@gmail.com","threadId":"1292","inReplyTo":"Pine.LNX.4.58.0507221447420.6074@g5.osdl.org","subject":"Re: [PATCH 0/2] apply.c: a fix and an enhancement","fromName":"Santi Béjar","fromEmail":"sbejar@gmail.com","sentAt":"2005-07-22T22:42:33Z","receivedAt":"2005-07-22T22:42:33Z","isPatch":true,"sender":{"key":"santi@agolina.net","avatar":null},"body":"Linus Torvalds <torvalds@osdl.org> writes:\n\n> Think of something like a collection of projects, each under their own \n> subdirectory. We could eventually literally make them _look_ like one big \n> project, with cross-project commits grafted together, but they'd \n> technically be totally independent (think \"git\" vs \"gitk\" - rather than \n> having a very tight merge like I did, we could have tried to make it be a \n> more virtual graft instead).\n\nOne posibility for a collection of projects is to make them with a tree of\ncommits instead of a tree of trees and blobs.\n\n    Santi\n"},{"id":"6337","messageId":"7vfyu6jvrm.fsf@assigned-by-dhcp.cox.net","threadId":"1292","inReplyTo":"Pine.LNX.4.58.0507221447420.6074@g5.osdl.org","subject":"Re: [PATCH 0/2] apply.c: a fix and an enhancement","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-22T22:55:41Z","receivedAt":"2005-07-22T22:55:41Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds <torvalds@osdl.org> writes:\n\n> I'd _really_ prefer to not have any preferences or other metadata files\n> under version control within that same project.\n\nDon't you think that would be a per-project decision?  Is it\nacceptable if I make sure that .gitinfo/* is _optional_ and\nthings do not break for projects that do not use it?\n\nI hope you are not vetoing the ongoing discussion in another\nthread from including the per-project configuration.\n\nSome people want to run their project differently, and one thing\nI see often done is to have pre-commit hooks that always run\ntest suites [*1*].  I do not think it is an unreasonable thing for\nPorcelains to support, and what I am trying to get at is if two\nPorcelains decide to support it, they do it in a compatible way.\n\n> And personal preferences are just that - personal. I do _not_ want to have \n> the kernel project history have things like \"editor preferences\" etc in \n> the revision history - you might want to revision them, but that would be \n> totally independent of the history of the project itself.\n\nI agree.  The .gitinfo/fake-parents may be a good thing in that\nsense to have project-wide, and as long as the kernel person\n(that is you) do not add .gitinfo/commit-template you would be\nhappy, wouldn't you?\n\n\n[Footnote]\n\n*1* Personally sometimes I feel myself that is silly, but that\nis _other_ people's project, not my own.  I think letting them\nfollow their own workflow to slow themselves is better than\noutright forbidding it and telling them not to do it.\n"},{"id":"6345","messageId":"Pine.LNX.4.58.0507221619450.6074@g5.osdl.org","threadId":"1292","inReplyTo":"7vfyu6jvrm.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 0/2] apply.c: a fix and an enhancement","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-07-22T23:26:07Z","receivedAt":"2005-07-22T23:26:07Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 22 Jul 2005, Junio C Hamano wrote:\n> Linus Torvalds <torvalds@osdl.org> writes:\n> \n> > I'd _really_ prefer to not have any preferences or other metadata files\n> > under version control within that same project.\n> \n> Don't you think that would be a per-project decision?  Is it\n> acceptable if I make sure that .gitinfo/* is _optional_ and\n> things do not break for projects that do not use it?\n\nIt can't be a per-project decision, since the preferences are \nper-developer.\n\nIn other words, if it's per-project, then that implies that every single \ndeveloper has to agree on the same thing. Which just not possible - it \nmakes no sense.\n\nIn contrast, if you have a separate local _branch_ that maintains a\n\".gitinfo\"  totally separately (no common commits at all), then you can\nchoose to propagate/participate in that branch or not, as you wish, on a\nper-developer basis.\n\n> I agree.  The .gitinfo/fake-parents may be a good thing in that\n> sense to have project-wide,\n\nI disagree. Even something like fake-parents isn't project-wide. \n\nFor example, what if I tried to dig out even _more_ information than what \nis in the BK CVS archives? Or if I wanted to have just the 2.6.0-> \nhistory? The whole point of fake-parents is that you can do things like \nthat - you can point your history at alternative views.\n\nIf we'd make it project-global, then we might as well just rewrite the \noriginal commit entirely, and use \"git-convert-cache\" to convert the whole \narchive. At that point, fake-parents becomes pointless.\n\n>\t\t\t and as long as the kernel person\n> (that is you) do not add .gitinfo/commit-template you would be\n> happy, wouldn't you?\n\nWhat you're saying is that people can be happy if they just don't use a \nstupid decision. That's a sure sign that the decision shouldn't have been \nmade in the first place.\n\n\t\tLinus\n"},{"id":"6346","messageId":"20050722233344.GP11916@pasky.ji.cz","threadId":"1292","inReplyTo":"Pine.LNX.4.58.0507221447420.6074@g5.osdl.org","subject":"Re: [PATCH 0/2] apply.c: a fix and an enhancement","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-07-22T23:33:44Z","receivedAt":"2005-07-22T23:33:44Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Fri, Jul 22, 2005 at 11:53:41PM CEST, I got a letter\nwhere Linus Torvalds <torvalds@osdl.org> told me that...\n> On Fri, 22 Jul 2005, Junio C Hamano wrote:\n> > \n> > And the file would obviously be per-project, so according to\n> > Pasky's suggestion that would be \".gitinfo/fake_parents\" ;-).\n> \n> I'd _really_ prefer to not have any preferences or other metadata files\n> under version control within that same project.\n> \n> If you want to version control them, that's fine, but don't tie the\n> versioning to the main project itself. You can have a _separate_ git\n> index, and a separate branch for the preferences and other metadata (but\n> you can, if you want to, obviously share the .git directory contents and\n> mix up the objects).\n\nI think that is a bad idea. Suddenly, you do not have the two things in\nthe same timeline, which may be quite confusing especially in case of\nsome hooks which depend on the contents of the tree of the project\nitself, in case of commit templates and such.\n\n> And personal preferences are just that - personal. I do _not_ want to have \n> the kernel project history have things like \"editor preferences\" etc in \n> the revision history - you might want to revision them, but that would be \n> totally independent of the history of the project itself.\n\nYes, but this stuff is not for personal preferences. It is for\nproject-wide preferences and policies, which can be still normally\noverridden or altered locally in each repository.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nIf you want the holes in your knowledge showing up try teaching\nsomeone.  -- Alan Cox\n"},{"id":"6347","messageId":"20050722233903.GQ11916@pasky.ji.cz","threadId":"1292","inReplyTo":"Pine.LNX.4.58.0507221619450.6074@g5.osdl.org","subject":"Re: [PATCH 0/2] apply.c: a fix and an enhancement","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-07-22T23:39:03Z","receivedAt":"2005-07-22T23:39:03Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Sat, Jul 23, 2005 at 01:26:07AM CEST, I got a letter\nwhere Linus Torvalds <torvalds@osdl.org> told me that...\n> On Fri, 22 Jul 2005, Junio C Hamano wrote:\n> > Linus Torvalds <torvalds@osdl.org> writes:\n> > \n> > > I'd _really_ prefer to not have any preferences or other metadata files\n> > > under version control within that same project.\n> > \n> > Don't you think that would be a per-project decision?  Is it\n> > acceptable if I make sure that .gitinfo/* is _optional_ and\n> > things do not break for projects that do not use it?\n> \n> It can't be a per-project decision, since the preferences are \n> per-developer.\n> \n> In other words, if it's per-project, then that implies that every single \n> developer has to agree on the same thing. Which just not possible - it \n> makes no sense.\n\nSome example of possible per-project settings:\n\n\tpre-commit hook killing trailing whitespaces\n\tglobal per-project ignore file (*.ko or something)\n\tcommon base commit template\n\t\t(standardized form developer fills in when committing,\n\t\t some remindments in the comment section, ...)\n\nObviously, you still ought to have a way to locally override any of\nthose per-repository in your .git/conf/.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nIf you want the holes in your knowledge showing up try teaching\nsomeone.  -- Alan Cox\n"},{"id":"6348","messageId":"Pine.LNX.4.58.0507221640050.6074@g5.osdl.org","threadId":"1292","inReplyTo":"20050722233344.GP11916@pasky.ji.cz","subject":"Re: [PATCH 0/2] apply.c: a fix and an enhancement","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-07-22T23:50:09Z","receivedAt":"2005-07-22T23:50:09Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 23 Jul 2005, Petr Baudis wrote:\n> \n> Yes, but this stuff is not for personal preferences. It is for\n> project-wide preferences and policies, which can be still normally\n> overridden or altered locally in each repository.\n\nWhat you are describing is a nightmare.\n\nLet's assume that a user alters the settings locally.\n\nEVERY SINGLE TIME he does a \"cg-commit\", those local alterations would get \ncommitted, since that config file is part of the same project, and cogito \nby default commits all changes.\n\nThat's just insane. It means that in practive it's simply not reasonable \nto have your own local copies of that file. So what would you do? You'd \nadd more and more hacks to cover this up, and have a \"commit-ignore\" file \nthat ignores the .gitinfo files etc etc. UGLY. All because of a design \nmistake.\n\nIn contrast, let's say that the .gitinfo/xyzzy files were in another \nunrelated branch altogether: that means that normally those files wouldn't \neven be seen by git as being under revision control (the \"index\" file \ndoesn't mention them, nor the tree pointed to by HEAD), but you could, if \nyou wanted to, do a simple\n\n\t#\n\t# edit the control files  and check the\n\t# changes  in to the control stream\n\t#\n\tgit switch control-files\n\t.. edit .gitinfo/xyzzy\n\tgit commit --all\n\n\t#\n\t# get back to the real project\n\t#\n\tgit switch master\n\nand it just works. In the above \"git switch\" would be exactly the same as\na normal \"git checkout\", except it's told to not update the current\ndirectory contexts on switch and instead just save the index file away and\nrestore it. (In contrast, using a full \"git checkout\" would remove the\nreal project when switching to the control files, and then again remove\nthe control files when switching back to the main project).\n\n\t\tLinus\n"},{"id":"6350","messageId":"20050722235944.GS11916@pasky.ji.cz","threadId":"1292","inReplyTo":"Pine.LNX.4.58.0507221640050.6074@g5.osdl.org","subject":"Re: [PATCH 0/2] apply.c: a fix and an enhancement","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-07-22T23:59:44Z","receivedAt":"2005-07-22T23:59:44Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Sat, Jul 23, 2005 at 01:50:09AM CEST, I got a letter\nwhere Linus Torvalds <torvalds@osdl.org> told me that...\n> \n> \n> On Sat, 23 Jul 2005, Petr Baudis wrote:\n> > \n> > Yes, but this stuff is not for personal preferences. It is for\n> > project-wide preferences and policies, which can be still normally\n> > overridden or altered locally in each repository.\n> \n> What you are describing is a nightmare.\n> \n> Let's assume that a user alters the settings locally.\n> \n> EVERY SINGLE TIME he does a \"cg-commit\", those local alterations would get \n> committed, since that config file is part of the same project, and cogito \n> by default commits all changes.\n\nNo, no, no. A user does not alter the settings locally in .gitinfo/ -\n.gitinfo/ is for per-_project_ stuff, not per-user. If user wants an\noverride, he does it per-repository in his .git/conf directory, which is\nnot version-tracked (actually, core GIT does not even let me to).\n\n> That's just insane. It means that in practive it's simply not reasonable \n> to have your own local copies of that file. So what would you do? You'd \n> add more and more hacks to cover this up, and have a \"commit-ignore\" file \n> that ignores the .gitinfo files etc etc. UGLY. All because of a design \n> mistake.\n\nActually, commit-ignore might be useful in other cases, e.g. when\nsomeone (me, a thousand times in the past) needs to keep temporary hacks\nin the Makefile so that he can actually build the thing on his weird\nsystem etc. ;-)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nIf you want the holes in your knowledge showing up try teaching\nsomeone.  -- Alan Cox\n"},{"id":"6351","messageId":"7vhdeme5ju.fsf@assigned-by-dhcp.cox.net","threadId":"1292","inReplyTo":"Pine.LNX.4.58.0507221619450.6074@g5.osdl.org","subject":"Re: [PATCH 0/2] apply.c: a fix and an enhancement","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-23T00:20:53Z","receivedAt":"2005-07-23T00:20:53Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds <torvalds@osdl.org> writes:\n\n> In other words, if it's per-project, then that implies that every single \n> developer has to agree on the same thing. Which just not possible - it \n> makes no sense.\n\nI agree 75%.  See the bottom for the rest 25%.\n\n> In contrast, if you have a separate local _branch_ that maintains a\n> \".gitinfo\"  totally separately (no common commits at all), then you can\n> choose to propagate/participate in that branch or not, as you wish, on a\n> per-developer basis.\n\nAh, finally the lightbulb moment.  And I think what you outlined\nusing \"git switch\" in another message is a clean way to do it if\nsomebody wanted to.\n\n\n> For example, what if I tried to dig out even _more_ information than what \n> is in the BK CVS archives? Or if I wanted to have just the 2.6.0-> \n> history?\n\nGood examples; I stand corrected.  That is also per \"group of\npeople who share the same view\", i.e. per-developer thing that\nmay be propagated among consenting branch participants.\n\n\n> What you're saying is that people can be happy if they just\n> don't use a stupid decision. That's a sure sign that the\n> decision shouldn't have been made in the first place.\n\nI am not saying it that strongly.  Rather, people can be happy\nif they do not have to use a decision that they feel stupid.\n\nIn circles you are part of, especially in a project like the\nkernel where hundreds of people participate worldwode, I can see\nthat having project-wide preference (or policy) and maintaining\nit may not make _any_ sense.  \n\nBut on the other hand, it is my understanding that it is a\ncommon practice to enforce some centralized policy (I am\nthinking about pre-commit hooks in particular) in a corporate\nsettings, and for people wanting to have that kind of thing, it\nis not even a stupid decision.\n"}]}