{"thread":{"id":"4115","subject":"What's in git.git","startedAt":"2006-05-10T03:11:31Z","lastAt":"2006-05-10T16:48:55Z","messageCount":14,"participants":["Junio C Hamano","Linus Torvalds","Randal L. Schwartz","Martin Langhoff","Jakub Narebski","Nicolas Pitre","Alex Riesen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"19814","messageId":"7viroezi8s.fsf@assigned-by-dhcp.cox.net","threadId":"4115","inReplyTo":null,"subject":"What's in git.git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-05-10T03:11:31Z","receivedAt":"2006-05-10T03:11:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"This week's \"What's in\" is a day early, since I do not expect to\nbe able to do much gitting for the rest of the week.\n\n* The 'maint' branch has these fixes since the last announcement.\n\nDmitry V. Levin:\n      Separate object name errors from usage errors\n\nEric Wong:\n      apply: fix infinite loop with multiple patches with --index\n\nJohannes Schindelin:\n      repo-config: trim white-space before comment\n\nJunio C Hamano:\n      core.prefersymlinkrefs: use symlinks for .git/HEAD\n      repo-config: document what value_regexp does a bit more clearly.\n      Fix repo-config set-multivar error return path.\n      Documentation: {caret} fixes (git-rev-list.txt)\n\nLinus Torvalds:\n      Fix \"git diff --stat\" with long filenames\n      revert/cherry-pick: use aggressive merge.\n\nMartin Waitz:\n      clone: keep --reference even with -l -s\n      repack: honor -d even when no new pack was created\n\nMatthias Lederhofer:\n      core-tutorial.txt: escape asterisk\n\nPavel Roskin:\n      Release config lock if the regex is invalid\n\nSean Estabrooks:\n      Fix for config file section parsing.\n\nYakov Lerner:\n      read-cache.c: use xcalloc() not calloc()\n\n\n* The 'master' branch has these since the last announcement, in\n  addition to the above.  I've flushed topics that have been\n  cooked in \"next\" long enough and hadn't given me problems.\n\nEric Wong:\n      git-svn: documentation updates\n      git-svn 1.0.0\n\nJohannes Schindelin:\n      builtin-push: --all and --tags _are_ explicit refspecs\n      Fix users of prefix_path() to free() only when necessary\n      Fix users of prefix_path() to free() only when necessary\n\nJunio C Hamano:\n      get_sha1(): :path and :[0-3]:path to extract from index.\n      Makefile: do not link rev-list any specially.\n      delta: stricter constness\n      pack-object: squelch eye-candy on non-tty\n      binary patch.\n      binary diff: further updates.\n      update-index --unresolve: work from a subdirectory.\n      checkout-index: plug memory leak from prefix_path()\n      update-index: plug memory leak from prefix_path()\n      update-index --again\n      update-index --again: take optional pathspecs\n      binary diff and apply: testsuite.\n      repo-config: document what value_regexp does a bit more clearly.\n      get_sha1() - fix infinite loop on nonexistent stage.\n      Teach git-clean optional <paths>... parameters.\n      checkout: use --aggressive when running a 3-way merge (-m).\n\nMartin Waitz:\n      Transitively read alternatives\n      test case for transitive info/alternates\n      clone: don't clone the info/alternates file\n\nNicolas Pitre:\n      split the diff-delta interface\n      use delta index data when finding best delta matches\n      replace adler32 with Rabin's polynomial in diff-delta\n      tiny optimization to diff-delta\n      improve diff-delta with sparse and/or repetitive data\n      improve base85 generated assembly code\n\nPeter Hagervall:\n      Sparse fix for builtin-diff\n\nSean Estabrooks:\n      Several trivial documentation touch ups.\n      Fix up docs where \"--\" isn't displayed correctly.\n      Update git-unpack-objects documentation.\n      Clarify git-cherry documentation.\n      Another config file parsing fix.\n      t1300-repo-config: two new config parsing tests.\n\n\n* The 'next' branch, in addition, has these.\n\n  - cvsserver and cvsexportcommit updates (Martin Langhoff and Martyn Smith)\n\n    This is a new merge but not very new code.  Martin may want\n    to comment on how ready they are.\n\n  - built-in fmt-patch (Johannes Schindelin)\n\n    I think this is ready, even though it does not have some\n    things we have in format-patch (i.e. --attach, --signoff,\n    --check).  If anybody deeply cares please stop me soon or\n    better yet enhance with your patches; otherwise I would like\n    to push this out to \"master\" sometime next week to supersede\n    the git-format-patch script.\n\n  - built-in grep (me)\n\n    I think this is also ready, even though it robs users from\n    having funky \"grep\" on their $PATH and invoke it.  Compared\n    to GNU grep, it lacks -P (pcre), -Z (NUL-terminated output),\n    -q (totally quiet), -z (NUL-terminated input), but all the\n    commonly used ones including -f (from file), -F (fixed), -w\n    (word regexp), -l/-L (files with/without match) and -n (line\n    number) are implemented.  The same \"stop me or else\" comment\n    applies.\n\n  - use config \"remote.$name.url\" and friends for fetch/pull\n    (Johannes Schindelin)\n\n    I think this itself is ready; the only reason I do not plan\n    to do so this week is to wait until the new config format\n    discussion settles, at which time we would need to adjust\n    this to the new format.\n\n  - cache-tree (me)\n\n    This has been stalled; I would want to redo it without using\n    out-of-index data structure, but that would need the\n    following steps, and lately I have too many distractions to\n    concentrate on them.\n\n    - review existing index/working-tree/tree walkers.\n\n    - prepare a merge-tree style path walker that walks index,\n      working tree, and zero or more trees in parallel.  This\n      would probably have an interator interface to return list\n      of either tree or blob <mode,sha1> to the caller.  Because\n      index does not currently have tree entries, a \"not\n      up-to-date\" tree entry would be returned from the index\n      part of the walker if I base this change on \"master\".  I\n      might base this on \"next\" and use information from\n      cache-tree. \n\n    - using the parallel path walker, revamp diff-cache (both\n      cached and non cached) to work out kinks to the walker API\n      and see how well it performs.  If I base the work on\n      \"next\", the code should be able to skip unchanged\n      subtrees.\n\n    - revamp diff-files (walks index and working tree), although\n      this will not get any benefit from having tree entries in\n      the index.\n\n    - revamp read-tree (all forms).\n\n    - if I based the work on \"next\", rip out the cache-tree\n      dependency and make the walker return \"not up-to-date\"\n      tree entries for index.\n\n    - revamp update-index, apply, and write-tree to have tree\n      entries in the index.  This probably involves revamping\n      read-cache interface to update the index file contents.\n\n    - review read-tree to make sure it correctly maintains the\n      tree entries in the cache.\n\n* The 'pu' branch, in addition, has the proposed configuration\n  file syntax updates from Linus with a patch from Sean.  I\n  haven't had time to really look at it, and it seems to fail a\n  test right now, but I left it as is.  This is merged from a\n  throw-away topic branch for now, but when I resume to gitting\n  sometime next week I am hoping we have something ready to be\n  tested (iow, \"next\" material) based on the list concensus.  At\n  that time we might probably do backport to cope with the\n  syntax updates for 1.3.X release and perhaps 1.2.X series just\n  for fun.\n"},{"id":"19815","messageId":"Pine.LNX.4.64.0605092043270.3718@g5.osdl.org","threadId":"4115","inReplyTo":"7viroezi8s.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-05-10T03:48:27Z","receivedAt":"2006-05-10T03:48:27Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 9 May 2006, Junio C Hamano wrote:\n> \n> * The 'pu' branch, in addition, has the proposed configuration\n>   file syntax updates from Linus with a patch from Sean.  I\n>   haven't had time to really look at it, and it seems to fail a\n>   test right now, but I left it as is.\n\nThe reason for the failure is the new syntax for multi-section variables.\n\nThis patch makes the test succed, by changing\n\n\t[1.2.3]\n\ninto\n\n\t[1 \"2.3\"]\n\nwhich is how subsections now end up being shown (you can still _parse_ \nthem the old way, but they get created the new way, which is why the test \nfails)\n\nThat's a very strange test-case, and on the face of it the new syntax \nlooks \"worse\", but if you were to be realistic about this kind of section \nname, it would more likely explain _what_ that number sequence means, so \nyou would more realistically name your sections something like\n\n\t[version \"1.2.3\"]\n\nwhich I think everybody agrees looks nicer than\n\n\t[version.1.2.3]\n\nor similar.\n\nOf course, I don't think we currently actually have any _users_ of any \nmulti-level section names at all, so this is all entirely theoretical \nuntil we start actually using them.\n\n\t\tLinus\n---\ndiff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh\nindex 7090ea9..54b3394 100755\n--- a/t/t1300-repo-config.sh\n+++ b/t/t1300-repo-config.sh\n@@ -241,7 +241,7 @@ # empty line\n \tNoNewLine = wow2 for me\n [123456]\n \ta123 = 987\n-[1.2.3]\n+[1 \"2.3\"]\n \talpha = beta\n EOF\n \n"},{"id":"19816","messageId":"Pine.LNX.4.64.0605092117240.3718@g5.osdl.org","threadId":"4115","inReplyTo":"7viroezi8s.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-05-10T04:21:07Z","receivedAt":"2006-05-10T04:21:07Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 9 May 2006, Junio C Hamano wrote:\n> \n> Junio C Hamano:\n>       binary patch.\n>       binary diff: further updates.\n\nBtw, am I just smoking stuff, or is this going to be fundamentally \nproblematic for \"git-apply -R\" if we ever want to support that?\n\nI think the new binary diff is non-reversible. That's ok right now, since \nwe don't actually support patching in reverse (if you want to get the \nreverse patch, you need to _diff_ it in reverse and then patch it that \nway).\n\nBut at least in theory we might well want to do \"-R\" eventually.\n\nHmm? Or did I just mis-understand the format?\n\n\t\tLinus\n"},{"id":"19817","messageId":"Pine.LNX.4.64.0605092123520.3718@g5.osdl.org","threadId":"4115","inReplyTo":"Pine.LNX.4.64.0605092117240.3718@g5.osdl.org","subject":"Re: What's in git.git","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-05-10T04:26:24Z","receivedAt":"2006-05-10T04:26:24Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 9 May 2006, Linus Torvalds wrote:\n> \n> I think the new binary diff is non-reversible. That's ok right now, since \n> we don't actually support patching in reverse (if you want to get the \n> reverse patch, you need to _diff_ it in reverse and then patch it that \n> way).\n\nBtw, I don't actually know why we don't support \"-R\". The way git-apply is \nwritten, it should be totally trivial (just switch old/new around for data \nand line numbers - since it doesn't actually apply the patch directly line \nby line or anything like that) for a normal patch.\n\nSo if I read the binary patch right, the lack of \"-R\" went from \"silly \noversight\" to \"uhhuh, I don't think the patch format supports it\".\n\nMaybe it's not a big deal.\n\n\t\t\tLinus\n"},{"id":"19818","messageId":"864pzyh4x0.fsf@blue.stonehenge.com","threadId":"4115","inReplyTo":"7viroezi8s.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2006-05-10T04:36:43Z","receivedAt":"2006-05-10T04:36:43Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Junio\" == Junio C Hamano <junkio@cox.net> writes:\n\nJunio> This week's \"What's in\" is a day early, since I do not expect to\nJunio> be able to do much gitting for the rest of the week.\n\nI just got this with the latest, on the git archive, using git-repack -a:\n\nGenerating pack...\nDone counting 19151 objects.\nDeltifying 19151 objects.\nSegmentation fault (core dumped)\n\nThis is on OpenBSD.  Is there a secret sabotage afoot?  This is repeatable.\nIs there anything I can try differently?\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>\nPerl/Unix/security consulting, Technical writing, Comedy, etc. etc.\nSee PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!\n"},{"id":"19819","messageId":"7vd5emze3h.fsf@assigned-by-dhcp.cox.net","threadId":"4115","inReplyTo":"Pine.LNX.4.64.0605092117240.3718@g5.osdl.org","subject":"Re: What's in git.git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-05-10T04:41:06Z","receivedAt":"2006-05-10T04:41:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds <torvalds@osdl.org> writes:\n\n> On Tue, 9 May 2006, Junio C Hamano wrote:\n>> \n>> Junio C Hamano:\n>>       binary patch.\n>>       binary diff: further updates.\n>\n> Btw, am I just smoking stuff, or is this going to be fundamentally \n> problematic for \"git-apply -R\" if we ever want to support that?\n\nIt is problematic but not more than the current index + \"Binary\nfiles differ\" output.  If you have both pre and postimage then\nyou do not need the binary data.\n\nThe forward application is done assuming you have the preimage\n(but not necessarily postimage), and when you do not have\npostimage the binary data is used.  When going reverse we should\nassume you have the postimage (but not necessarily preimage),\nbut the pack-object format xdelta is not reversible so if you do\nnot have preimage that matches the index, with the current\noutput format you lose.\n\nIf we care enough, we could add a reverse delta from postimage\nto preimage to the output, but I am not sure if it is worth it.\n\n> But at least in theory we might well want to do \"-R\" eventually.\n\nYes, but even without binary, -R has a funny implication when\ncopy-edit patch is involved.  What if a patch copy-edits to\ncreate a new file B based on old A, and also modifies A\nin-place, and somehow the postimages of A and B you already have\nare not consistent with what that patch does?  Application with\n-R would produce two versions of A and you would get a conflict.\nI guess showing a combined diff would be a helpful way to\nresolve that ;-).\n"},{"id":"19820","messageId":"Pine.LNX.4.64.0605092142050.3718@g5.osdl.org","threadId":"4115","inReplyTo":"864pzyh4x0.fsf@blue.stonehenge.com","subject":"Re: What's in git.git","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-05-10T04:45:23Z","receivedAt":"2006-05-10T04:45:23Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 9 May 2006, Randal L. Schwartz wrote:\n\n> >>>>> \"Junio\" == Junio C Hamano <junkio@cox.net> writes:\n> \n> Junio> This week's \"What's in\" is a day early, since I do not expect to\n> Junio> be able to do much gitting for the rest of the week.\n> \n> I just got this with the latest, on the git archive, using git-repack -a:\n> \n> Generating pack...\n> Done counting 19151 objects.\n> Deltifying 19151 objects.\n> Segmentation fault (core dumped)\n> \n> This is on OpenBSD.  Is there a secret sabotage afoot?  This is repeatable.\n> Is there anything I can try differently?\n\nCan you see what the traceback is with gdb?\n\nI'd suspect the deltifier changes, the rabin hash in particular. The core \nfile traceback would probably point right at the culprit if so.\n\nI don't see the problem myself, but if it's an access just past the end of \nan array or something, it would depend on exactly what the delta pattern \nis (which, without the \"-f\" flag, in turn depends on what your previous \npacks looked like) and also on the allocation strategy (which migth \nexplain why it shows on OpenBSD but Linux people hadn't seen it).\n\n\t\t\tLinus\n"},{"id":"19821","messageId":"Pine.LNX.4.64.0605092150460.3718@g5.osdl.org","threadId":"4115","inReplyTo":"7vd5emze3h.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-05-10T04:51:44Z","receivedAt":"2006-05-10T04:51:44Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 9 May 2006, Junio C Hamano wrote:\n> \n> It is problematic but not more than the current index + \"Binary\n> files differ\" output.  If you have both pre and postimage then\n> you do not need the binary data.\n\nFair enough.\n\n> > But at least in theory we might well want to do \"-R\" eventually.\n> \n> Yes, but even without binary, -R has a funny implication when\n> copy-edit patch is involved.  What if a patch copy-edits to\n> create a new file B based on old A, and also modifies A\n> in-place, and somehow the postimages of A and B you already have\n> are not consistent with what that patch does?\n\nYeah, that could get exciting ;)\n\n\t\tLinus\n"},{"id":"19823","messageId":"7v64kezczd.fsf@assigned-by-dhcp.cox.net","threadId":"4115","inReplyTo":"864pzyh4x0.fsf@blue.stonehenge.com","subject":"Re: What's in git.git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-05-10T05:05:10Z","receivedAt":"2006-05-10T05:05:10Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"merlyn@stonehenge.com (Randal L. Schwartz) writes:\n\n>>>>>> \"Junio\" == Junio C Hamano <junkio@cox.net> writes:\n>\n> Junio> This week's \"What's in\" is a day early, since I do not expect to\n> Junio> be able to do much gitting for the rest of the week.\n>\n> I just got this with the latest, on the git archive, using git-repack -a:\n>\n> Generating pack...\n> Done counting 19151 objects.\n> Deltifying 19151 objects.\n> Segmentation fault (core dumped)\n>\n> This is on OpenBSD.  Is there a secret sabotage afoot?  This is repeatable.\n> Is there anything I can try differently?\n\nTonight's latest (f7a3276) merged Nico's delta patches that was\nin \"next\" branch for some time, so that is what I would suspect\nfirst.\n\n    commit 06a9f9203570d21f9ef5fe219cdde527dcdf0990\n    Author: Nicolas Pitre <nico@cam.org>\n\n        improve diff-delta with sparse and/or repetitive data\n\n    commit 2d08e5dd730680f7f8645a6326ec653435e032df\n    Author: Nicolas Pitre <nico@cam.org>\n\n        tiny optimization to diff-delta\n\n    commit 3dc5a9e4cdcc7124c665a050547d1285d86a421f\n    Author: Nicolas Pitre <nico@cam.org>\n\n        replace adler32 with Rabin's polynomial in diff-delta\n\n    commit f6c7081aa97aa67baa06390a1ef36088c33bf010\n    Author: Nicolas Pitre <nico@cam.org>\n\n        use delta index data when finding best delta matches\n\n    commit 08abe669c05521499149dbf84fedefb04a8fa34d\n    Author: Nicolas Pitre <nico@cam.org>\n\n        split the diff-delta interface\n\nCould you revert them (i.e. run \"git revert 06a9f9\", \"git revert\n2d08e5\", ...) to see where it starts behaving again?\n\nAlternatively, you could bisect between 2fc240a (before merging\nnp/delta branch) and master (f7a3276).\n\n(1) Reverting recipe.\n\n\t$ git checkout -b testfix master\n        $ make\n        $ GIT_EXEC_PATH=. PATH=.:$PATH \\\n          ./git-repack -a ;# you already know this fails.\n        $ EDITOR=: git revert 06a9f92\n        $ make\n        $ GIT_EXEC_PATH=. PATH=.:$PATH ./git-repack -a ;# does it?\n        $ EDITOR=: git revert 2d08e5d\n        $ make\n        $ GIT_EXEC_PATH=. PATH=.:$PATH ./git-repack -a ;# does it?\n        $ EDITOR=: git revert 3dc5a9e\n        $ make\n        $ GIT_EXEC_PATH=. PATH=.:$PATH ./git-repack -a ;# does it?\n        ...\n\n(2) Bisecting recipe.\n\n\t$ git checkout -b testfix master\n\t$ make\n        $ GIT_EXEC_PATH=. PATH=.:$PATH \\\n          ./git-repack -a ;# you already know this fails.\n        $ git reset --hard 2fc240a\n\t$ make\n        $ GIT_EXEC_PATH=. PATH=.:$PATH \\\n          ./git-repack -a ;# before merging np/delta,\n                           # should hopefully work\n        $ git bisect start\n        $ git bisect good 2fc240a\n        $ git bisect bad master\n        Bisecting: 10 revisions left to test after this\n        [143f4d94c6e2188a6bedfdfa268e66b579e3fbf9] Merge branch 'jc/again'\n\t$ make\n        $ GIT_EXEC_PATH=. PATH=.:$PATH ./git-repack -a ;# does this work?\n\n        $ git bisect good ;# if it works, or\n        $ git bisect bad  ;# otherwise\n\tBisecting: 7 revisions left to test after this\n\t...\n\n\t\n"},{"id":"19824","messageId":"46a038f90605092234u14d4cd2en73c9cbe698eea8b9@mail.gmail.com","threadId":"4115","inReplyTo":"7viroezi8s.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-05-10T05:34:28Z","receivedAt":"2006-05-10T05:34:28Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 5/10/06, Junio C Hamano <junkio@cox.net> wrote:\n> * The 'next' branch, in addition, has these.\n>\n>   - cvsserver and cvsexportcommit updates (Martin Langhoff and Martyn Smith)\n>\n>     This is a new merge but not very new code.  Martin may want\n>     to comment on how ready they are.\n\nThey have seen some limited use in-house -- we don't use Eclipse\nin-house that much, but that has been the test target. I am currently\nlooking for a machine with good bandwidth to a backbone and cycles to\nspare where we can run anon cvs access to Linus's kernel.git repo.\n\ncheers,\n\n\nmartin\n"},{"id":"19825","messageId":"e3s2b0$i1m$1@sea.gmane.org","threadId":"4115","inReplyTo":"7viroezi8s.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-05-10T06:48:08Z","receivedAt":"2006-05-10T06:48:08Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n>   - built-in grep (me)\n> \n>     I think this is also ready, even though it robs users from\n>     having funky \"grep\" on their $PATH and invoke it.  Compared\n>     to GNU grep, it lacks -P (pcre), -Z (NUL-terminated output),\n>     -q (totally quiet), -z (NUL-terminated input), but all the\n>     commonly used ones including -f (from file), -F (fixed), -w\n>     (word regexp), -l/-L (files with/without match) and -n (line\n>     number) are implemented.  The same \"stop me or else\" comment\n>     applies.\n\nIf there would be possible to use external grep (like one can use external\ndiff), then lack of some options wouldn't matter.\n\n-- \nJakub Narebski\nWarsaw, Poland\n"},{"id":"19829","messageId":"Pine.LNX.4.64.0605101012250.24505@localhost.localdomain","threadId":"4115","inReplyTo":"Pine.LNX.4.64.0605092142050.3718@g5.osdl.org","subject":"Re: What's in git.git","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-05-10T14:15:17Z","receivedAt":"2006-05-10T14:15:17Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 9 May 2006, Linus Torvalds wrote:\n\n> \n> \n> On Tue, 9 May 2006, Randal L. Schwartz wrote:\n> \n> > >>>>> \"Junio\" == Junio C Hamano <junkio@cox.net> writes:\n> > \n> > Junio> This week's \"What's in\" is a day early, since I do not expect to\n> > Junio> be able to do much gitting for the rest of the week.\n> > \n> > I just got this with the latest, on the git archive, using git-repack -a:\n> > \n> > Generating pack...\n> > Done counting 19151 objects.\n> > Deltifying 19151 objects.\n> > Segmentation fault (core dumped)\n> > \n> > This is on OpenBSD.  Is there a secret sabotage afoot?  This is repeatable.\n> > Is there anything I can try differently?\n> \n> Can you see what the traceback is with gdb?\n> \n> I'd suspect the deltifier changes, the rabin hash in particular. The core \n> file traceback would probably point right at the culprit if so.\n> \n> I don't see the problem myself, but if it's an access just past the end of \n> an array or something, it would depend on exactly what the delta pattern \n> is (which, without the \"-f\" flag, in turn depends on what your previous \n> packs looked like) and also on the allocation strategy (which migth \n> explain why it shows on OpenBSD but Linux people hadn't seen it).\n\nWhen linking with Electric Fence I can reproduce the segfault on Linux \nas well.\n\nLooking into it now.\n\n\nNicolas\n"},{"id":"19830","messageId":"81b0412b0605100800p48fa6b46nb91c103aeee4aa94@mail.gmail.com","threadId":"4115","inReplyTo":"Pine.LNX.4.64.0605101012250.24505@localhost.localdomain","subject":"Re: What's in git.git","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2006-05-10T15:00:42Z","receivedAt":"2006-05-10T15:00:42Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 5/10/06, Nicolas Pitre <nico@cam.org> wrote:\n> > >\n> > > Junio> This week's \"What's in\" is a day early, since I do not expect to\n> > > Junio> be able to do much gitting for the rest of the week.\n> > >\n> > > I just got this with the latest, on the git archive, using git-repack -a:\n> > >\n> > > Generating pack...\n> > > Done counting 19151 objects.\n> > > Deltifying 19151 objects.\n> > > Segmentation fault (core dumped)\n> > >\n\nProbably unrelated but I get something similar in cygwin:\n$ git pull //pc1/share/dir +ref1:ref2\nGenerating pack...\nDone counting 93 objects.\nResult has 62 objects.\nDeltifying 62 objects.\ngit-unpack-objects: fatal: early EOF\ngit-fetch-pack: fatal: git-unpack-objects died with error code 128\n\n(The program names come from a patch attached to the message)\n\nAfter I remerged (from git's master) everything but np/delta\n(I saw that report about crash on openbsd) it worked again.\nThis time I cannot make the repository public but will try to\nhelp with testing.\n"},{"id":"19834","messageId":"Pine.LNX.4.64.0605100919250.3718@g5.osdl.org","threadId":"4115","inReplyTo":"Pine.LNX.4.64.0605101012250.24505@localhost.localdomain","subject":"Re: What's in git.git","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-05-10T16:48:55Z","receivedAt":"2006-05-10T16:48:55Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 10 May 2006, Nicolas Pitre wrote:\n> \n> When linking with Electric Fence I can reproduce the segfault on Linux \n> as well.\n> \n> Looking into it now.\n\nYeah, I get \n\n\t#0  0x1000bfe4 in create_delta (index=0xf7d758a0, trg_buf=0xf7d72eb8, trg_size=327, delta_size=0xffb422b4, \n\t    max_size=143) at diff-delta.c:308\n\t#1  0x10005734 in try_delta (trg=0xf7fdbfa0, src=0xf7fdbf94, src_index=0xf7d758a0, max_depth=10)\n\t    at pack-objects.c:1049\n\t#2  0x10005b04 in find_deltas (list=0xf7e32f54, window=11, depth=10) at pack-objects.c:1128\n\t#3  0x10005ca0 in prepare_pack (window=10, depth=10) at pack-objects.c:1161\n\t#4  0x1000677c in main (argc=3, argv=0xffb436e4) at pack-objects.c:1359\n\nie the \"entry\" chain seems to be corrupt in create_delta.\n\nActually, it's not even the chain: it's the very first entry:\n\n\t(gdb) p index->hash[i]\n\t$2 = (struct index_entry *) 0xf7d7385c\n\t(gdb) p entry\n\t$3 = (struct index_entry *) 0xf7d7385c\n\nand it's not a random value - it looks perfectly valid. As do all the \nother index hash entries. It's just that the index hash entries seem to \nall have been freed, so accessing them causes a SIGSEV!\n\n\t\t\tLinus\n"}]}