{"thread":{"id":"20037","subject":"What's cooking in git.git (Jul 2009, #01; Mon, 06)","startedAt":"2009-07-06T18:32:47Z","lastAt":"2009-07-10T05:05:16Z","messageCount":20,"participants":["Junio C Hamano","Marcus Camen","Jakub Narebski","Mark Lodato","Johannes Sixt","Linus Torvalds","Alex Riesen","Johannes Schindelin","Shawn O. Pearce","Jeff King","Stephen Boyd","Christian Couder"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"117510","messageId":"7vk52l4q7k.fsf@alter.siamese.dyndns.org","threadId":"20037","inReplyTo":null,"subject":"What's cooking in git.git (Jul 2009, #01; Mon, 06)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-07-06T18:32:47Z","receivedAt":"2009-07-06T18:32:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Here are the topics that have been cooking. Commits prefixed with '-' are\nonly in 'pu' while commits prefixed with '+' are in 'next'. The ones\nmarked with '.' do not appear in any of the branches, but I am still\nholding onto them.\n\nThe topics list the commits in reverse chronological order. The topics\nmeant to be merged to the maintenance series have \"maint-\" in their names.\n\nIt has been relatively quiet for the past few weeks. The 'next' branch is\ngetting quite thin, and it would be a good time to declare -rc0. I'll do\nso by my Wednesday.\n\n----------------------------------------------------------------\n[New Topics]\n\n* ld/push-porcelain-output-format (Mon Jun 22 21:10:01 2009 -0400) 1 commit\n + add --porcelain option to git-push\n\n* js/run-command-updates (Sat Jul 4 21:26:43 2009 +0200) 7 commits\n - receive-pack: remove unnecessary run_status report\n - run_command: report failure to execute the program, but optionally\n don't\n - run_command: encode deadly signal number in the return value\n - run_command: report system call errors instead of returning error\n codes\n - run_command: return exit code as positive value\n - MinGW: simplify waitpid() emulation macros\n - MinGW: truncate exit()'s argument to lowest 8 bits\n\nA few replacement/squash updates came in before it hit 'pu'; this should\nbe the latest version.\n\n* cc/sequencer-rebase-i (Fri Jun 26 23:08:46 2009 +0200) 4 commits\n - rebase -i: use \"git sequencer--helper --make-patch\"\n - sequencer: free memory used in \"make_patch\" function\n - sequencer: add \"make_patch\" function to save a patch\n - sequencer: add \"builtin-sequencer--helper.c\"\n\n* ae/maint-mailinfo-rm-only-one-patch-marker (Mon Jun 29 11:55:51 2009 +0200) 1 commit\n - mailinfo: Remove only one set of square brackets\n\nThe change needed to the test vector shows the extent of the damage this\nchange may cause in the real world. A handcrafted \"Subject: [area] [PATCH] title\"\nwill be turned into \"[PATCH] title\".\n\n* rs/grep-p (Thu Jul 2 00:06:34 2009 +0200) 7 commits\n + grep: simplify -p output\n + grep -p: support user defined regular expressions\n + grep: add option -p/--show-function\n + grep: handle pre context lines on demand\n + grep: print context hunk marks between files\n + grep: move context hunk mark handling into show_line()\n + userdiff: add xdiff_clear_find_func()\n\n----------------------------------------------------------------\n[Graduated to \"master\"]\n\n* cf/maint-remote-uploadpack-useconfig-fix (Thu Jun 25 17:21:35 2009 -0400) 1 commit\n + git-remote: fix missing .uploadpack usage for show command\n\n* sb/show-ref-parse-options (Sat Jun 20 21:40:46 2009 -0700) 1 commit\n + show-ref: migrate to parse-options\n\n* ne/maint-1.6.0-diff-tree-t-r-show-directory (Sat Jun 13 17:06:09 2009 -0700) 1 commit\n + diff-tree -r -t: include added/removed directories in the output\n\nThis changes the output from \"diff-tree -r -t\"; it brings more consistency\nto it, but it is a change and could break scripts.\n\n* uk/rev-parse-parse-opt (Sun Jun 14 01:58:43 2009 +0200) 2 commits\n + parse-opt: make PARSE_OPT_STOP_AT_NON_OPTION available to git rev-\n parse\n + more tests for git rev-parse --parse-opt\n\n* js/daemon-log (Sun Jun 21 23:16:09 2009 +0200) 3 commits\n + receive-pack: do not send error details to the client\n + upload-pack: squelch progress indicator if client cannot see it\n + daemon: send stderr of service programs to the syslog\n\n* sb/quiet-porcelains (Wed Jun 17 18:07:37 2009 -0700) 6 commits\n + stash: teach quiet option\n + am, rebase: teach quiet option\n + submodule, repack: migrate to git-sh-setup's say()\n + git-sh-setup: introduce say() for quiet options\n + am: suppress apply errors when using 3-way\n + t4150: test applying with a newline in subject\n\n* jk/use-our-regexp (Fri Jun 19 10:10:39 2009 -0500) 3 commits\n + Makefile: Solaris needs HAVE_ALLOCA_H for alloca()\n + Makefile: use compat regex on Solaris\n + Makefile: refactor regex compat support\n\n* cb/maint-fetch-refspec-wo-dst (Wed Jun 17 15:38:36 2009 +0200) 1 commit\n - fetch: do not create ref from empty name\n\n* cc/bisect (Sat Jun 13 13:11:02 2009 +0200) 2 commits\n + Documentation: remove warning saying that \"git bisect skip\" may\n slow bisection\n + bisect: use a PRNG with a bias when skipping away from untestable\n commits\n\n* tr/die_errno (Sat Jun 27 17:58:47 2009 +0200) 4 commits\n - Use die_errno() instead of die() when checking syscalls\n - Convert existing die(..., strerror(errno)) to die_errno()\n - die_errno(): double % in strerror() output just in case\n - Introduce die_errno() that appends strerror(errno) to die()\n\nI didn't check the individual conversion from die() to die_errno()\nin this latest round; comments?\n\n* gb/am-foreign (Wed May 27 11:25:19 2009 +0200) 4 commits\n - git-am: refactor 'cleaning up and aborting'\n - git-am foreign patch support: StGIT support\n - git-am foreign patch support: autodetect some patch formats\n - git-am foreign patch support: introduce patch_format\n\nWill be in 'next' shortly.\n\n----------------------------------------------------------------\n[Stalled and may need help and prodding to go forward]\n\n* ml/http (Wed May 27 23:16:03 2009 -0400) 2 commits\n - http.c: add http.sslCertPasswordProtected option\n - http.c: prompt for SSL client certificate password\n\nI've rewritten these two to (1) move the #ifdef out of the main codepath,\nand (2) use configuration/environment to make the misfeature of always\nasking for a passphrase even a key/cert is unencrypted optional. I tried\nto be careful but extra sets of eyeballs would be nice to check the result.\n\nNobody seems to be jumping up-and-down asking for this or helping to push\nthis forward. Perhaps it's time to drop it?\n\n* jh/notes (Sat May 16 13:44:17 2009 +0200) 5 commits\n - Teach \"-m \" and \"-F \" to \"git notes edit\"\n - Add an expensive test for git-notes\n - Speed up git notes lookup\n - Add a script to edit/inspect notes\n - Introduce commit notes\n\nDscho asked about the performance implications of this; I do not think I\nsaw any progress on that yet...\n\n* lt/read-directory (Fri May 15 12:01:29 2009 -0700) 3 commits\n - Add initial support for pathname conversion to UTF-8\n - read_directory(): infrastructure for pathname character set\n conversion\n - Add 'fill_directory()' helper function for directory traversal\n\nBefore adding the real \"conversion\", this needs a few real fixups, I\nthink. For example there is one hardcoded array that is used without\nbounds check.\n\n* ar/maint-1.6.2-merge-recursive-d-f (Mon May 11 21:25:36 2009 +0200) 2 commits\n - Fix for a merge where a branch has an F->D transition\n - Add a reminder test case for a merge with F/D transition\n\nAlthough the reported breakage is covered with the patch, Alex feels the\nsolution unsatisfactory. Cleaning up D/F conflict handling in merge-recursive\nmay be long overdue but seems to be a hard problem.\n\n* ps/blame (Thu Mar 12 21:30:03 2009 +1100) 1 commit\n - blame.c: start libifying the blame infrastructure\n\nA few minor point remains in this initial one.\n\n* jc/log-tz (Tue Mar 3 00:45:37 2009 -0800) 1 commit\n - Allow --date=local --date=other-format to work as expected\n\nThe one I posted had a few corner-case bugs that was caught with the test\nsuite; this one has them fixed. People did not like the UI so it is kept\nout of 'next'\n\n* jc/merge-convert (Mon Jan 26 16:45:01 2009 -0800) 1 commit\n - git-merge-file: allow converting the results for the work tree\n\nThis is a feature waiting for a user.\n\nWe did not give scripted Porcelains a way to say \"this temporary file I am\nusing for merging is for this path, so use the core.autocrlf and attributes\nrules for that final path\". Instead, merge-file simply wrote out the\ndata in the canonical repository representation.\n\nrerere has the same issue, but it is a lot worse. It reads the three\nfiles (preimage, postimage and thisimage) from the work tree in the work\ntree representation, merges them without converting them to the canonical\nrepresentation first but inserts the conflict markers with the canonical\nrepresentation and writes the resulting mess out. It needs to be fixed to\nread with convert_to_git(), merge them while they are still in the\ncanonical representation and possibly add conflict markers, and then write\nthe results out after convert_to_working_tree(). It also needs to write\nin binary mode as well.\n\n* db/foreign-scm (Tue Mar 24 23:04:12 2009 -0400) 3 commits\n - Add option for using a foreign VCS\n - Document details of transport function APIs\n - Allow late reporting of fetched hashes\n\n* hv/cvsps-tests (Sun Apr 5 01:40:50 2009 -0700) 8 commits\n - t/t9600: remove exit after test_done\n - cvsimport: extend testcase about patchset order to contain\n branches\n - cvsimport: add test illustrating a bug in cvsps\n - Add a test of \"git cvsimport\"'s handling of tags and branches\n - Add some tests of git-cvsimport's handling of vendor branches\n - Test contents of entire cvsimported \"master\" tree contents\n - Use CVS's -f option if available (ignore user's ~/.cvsrc file)\n - Start a library for cvsimport-related tests\n\n----------------------------------------------------------------\n[Actively cooking]\n\n* gb/gitweb-avatar (Tue Jun 30 00:00:54 2009 +0200) 7 commits\n - gitweb: add empty alt text to avatar img\n - gitweb: picon avatar provider\n - gitweb: gravatar url cache\n - gitweb: (gr)avatar support\n - gitweb: use git_print_authorship_rows in 'tag' view too\n - gitweb: uniform author info for commit and commitdiff\n - gitweb: refactor author name insertion\n\nThis should be the latest one posted to the list, and I think it is\nreasonable, and Jakub seemed to concur. Will be in 'next'\n\n* en/fast-export (Thu Jun 25 22:48:33 2009 -0600) 7 commits\n - fast-export: Document the fact that git-rev-list arguments are\n accepted\n - Add new fast-export testcases\n - fast-export: Add a --tag-of-filtered-object option for newly\n dangling tags\n - fast-export: Do parent rewriting to avoid dropping relevant\n commits\n - fast-export: Make sure we show actual ref names instead of\n \"(null)\"\n - fast-export: Omit tags that tag trees\n - fast-export: Set revs.topo_order before calling setup_revisions\n\nShawn? Dscho?\n\n* jc/diff-whitespace-only-status (Sat May 23 01:15:35 2009 -0700) 2 commits\n - diff: Rename QUIET internal option to QUICK\n - diff: change semantics of \"ignore whitespace\" options\n\nI am not sure if it should wait for a major version bump but this is a\ngood semantics change. Perhaps merge to 'next' soonish, but I am\nundecided. Comments?\n\nFor the following three series, I have not managed to convince myself if\nthese changes have real-world needs.\n\n* sb/read-tree (Thu Jun 25 22:14:10 2009 -0700) 2 commits\n - read-tree: migrate to parse-options\n - read-tree: convert unhelpful usage()'s to helpful die()'s\n\n* ne/futz-upload-pack (Wed Jun 10 01:50:18 2009 +0200) 1 commit\n - Shift object enumeration out of upload-pack\n\n* cc/replace (Wed May 27 07:14:09 2009 +0200) 14 commits\n - t6050: check pushing something based on a replaced commit\n - Documentation: add documentation for \"git replace\"\n - Add git-replace to .gitignore\n - builtin-replace: use \"usage_msg_opt\" to give better error messages\n - parse-options: add new function \"usage_msg_opt\"\n - builtin-replace: teach \"git replace\" to actually replace\n - Add new \"git replace\" command\n - environment: add global variable to disable replacement\n - mktag: call \"check_sha1_signature\" with the replacement sha1\n - replace_object: add a test case\n - object: call \"check_sha1_signature\" with the replacement sha1\n - sha1_file: add a \"read_sha1_file_repl\" function\n - replace_object: add mechanism to replace objects found in\n \"refs/replace/\"\n - refs: add a \"for_each_replace_ref\" function\n\n----------------------------------------------------------------\n[On Hold]\n\n* jc/deny-delete-current-1.7.0 (Mon Feb 9 00:19:46 2009 -0800) 1 commit\n - receive-pack: default receive.denyDeleteCurrent to refuse\n\n* jc/refuse-push-to-current-1.7.0 (Wed Feb 11 02:28:03 2009 -0800) 1 commit\n - Refuse updating the current branch in a non-bare repository via\n push\n\nThese are for 1.7.0, but the messages when they trigger together may need\nto be rethought.\n"},{"id":"117511","messageId":"200907062229.11763.mcamen@mcamen.de","threadId":"20037","inReplyTo":"7vk52l4q7k.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Jul 2009, #01; Mon, 06)","fromName":"Marcus Camen","fromEmail":"mcamen@mcamen.de","sentAt":"2009-07-06T20:29:11Z","receivedAt":"2009-07-06T20:29:11Z","isPatch":false,"sender":{"key":"mcamen@mcamen.de","avatar":null},"body":"On Montag 06 Juli 2009, Junio C Hamano wrote:\n> * ml/http (Wed May 27 23:16:03 2009 -0400) 2 commits\n> - http.c: add http.sslCertPasswordProtected option\n> - http.c: prompt for SSL client certificate password\n>\n> I've rewritten these two to (1) move the #ifdef out of the main\n> codepath, and (2) use configuration/environment to make the misfeature\n> of always asking for a passphrase even a key/cert is unencrypted\n> optional. I tried to be careful but extra sets of eyeballs would be\n> nice to check the result.\n>\n> Nobody seems to be jumping up-and-down asking for this or helping to\n> push this forward. Perhaps it's time to drop it?\n\n/me jumping up-and-down\n\nThis fix is crucial for corporate environments where HTTPS is the only way \nto access GIT repositories outside the firewall.\n\nI verified the patch and everything works as expected.\n\n\n--\nMarcus\n"},{"id":"117515","messageId":"7vk52l1oht.fsf@alter.siamese.dyndns.org","threadId":"20037","inReplyTo":"200907062229.11763.mcamen@mcamen.de","subject":"Re: What's cooking in git.git (Jul 2009, #01; Mon, 06)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-07-06T21:38:06Z","receivedAt":"2009-07-06T21:38:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Marcus Camen writes:\n\n> On Montag 06 Juli 2009, Junio C Hamano wrote:\n>> * ml/http (Wed May 27 23:16:03 2009 -0400) 2 commits\n>> - http.c: add http.sslCertPasswordProtected option\n>> - http.c: prompt for SSL client certificate password\n>>\n>> I've rewritten these two to (1) move the #ifdef out of the main\n>> codepath, and (2) use configuration/environment to make the misfeature\n>> of always asking for a passphrase even a key/cert is unencrypted\n>> optional. I tried to be careful but extra sets of eyeballs would be\n>> nice to check the result.\n>>\n>> Nobody seems to be jumping up-and-down asking for this or helping to\n>> push this forward. Perhaps it's time to drop it?\n>\n> /me jumping up-and-down\n>\n> This fix is crucial for corporate environments where HTTPS is the only way \n> to access GIT repositories outside the firewall.\n>\n> I verified the patch and everything works as expected.\n\nThanks.\n\nWhat did you exactly mean by \"everything\"?\n\n - On a protected key/cert, with configuration, it asks the question once.\n\n - On an unprotected key/cert, without configuration, it never asks the\n question.\n\n - On an unprotected key/cert, with configuration, it asks an useless\n question but it does so only once.\n\nYou tested all of the above? I am not demanding you to test all of these,\nbut we need to make sure at least somebody did. Especially because it\nwould be a regression if the second one does not.\n"},{"id":"117520","messageId":"200907070003.25788.mcamen@mcamen.de","threadId":"20037","inReplyTo":"7vk52l1oht.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Jul 2009, #01; Mon, 06)","fromName":"Marcus Camen","fromEmail":"mcamen@mcamen.de","sentAt":"2009-07-06T22:03:25Z","receivedAt":"2009-07-06T22:03:25Z","isPatch":false,"sender":{"key":"mcamen@mcamen.de","avatar":null},"body":"> - On a protected key/cert, with configuration, it asks the question\n> once.\n> - On an unprotected key/cert, without configuration, it never asks the\n> question.\n> - On an unprotected key/cert, with configuration, it asks an useless\n> question but it does so only once.\n>\n> You tested all of the above?\n\nYes, all three tests run exactly as you described.\n\nIn addition\n - On a protected key/cert, without configuration\nGIT shows the same behaviour as without the patch.\n\nI checked using http.sslCertPasswordProtected and also \nGIT_SSL_CERT_PASSWORD_PROTECTED. curl is 7.19.5\n\n\nJust let me know if you need more checks.\n\n\nMarcus\n"},{"id":"117524","messageId":"7vd48djvae.fsf@alter.siamese.dyndns.org","threadId":"20037","inReplyTo":"200907070003.25788.mcamen@mcamen.de","subject":"Re: What's cooking in git.git (Jul 2009, #01; Mon, 06)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-07-06T22:34:01Z","receivedAt":"2009-07-06T22:34:01Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Marcus Camen writes:\n\n>> - On a protected key/cert, with configuration, it asks the question\n>> once.\n>> - On an unprotected key/cert, without configuration, it never asks the\n>> question.\n>> - On an unprotected key/cert, with configuration, it asks an useless\n>> question but it does so only once.\n>>\n>> You tested all of the above?\n>\n> Yes, all three tests run exactly as you described.\n\nWonderful; thanks.\n"},{"id":"117529","messageId":"m3r5wtv0nr.fsf@localhost.localdomain","threadId":"20037","inReplyTo":"7vk52l4q7k.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Jul 2009, #01; Mon, 06)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-07-06T23:42:34Z","receivedAt":"2009-07-06T23:42:34Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano writes:\n\n> [Actively cooking]\n> \n> * gb/gitweb-avatar (Tue Jun 30 00:00:54 2009 +0200) 7 commits\n> - gitweb: add empty alt text to avatar img\n> - gitweb: picon avatar provider\n> - gitweb: gravatar url cache\n> - gitweb: (gr)avatar support\n> - gitweb: use git_print_authorship_rows in 'tag' view too\n> - gitweb: uniform author info for commit and commitdiff\n> - gitweb: refactor author name insertion\n> \n> This should be the latest one posted to the list, and I think it is\n> reasonable, and Jakub seemed to concur. Will be in 'next'\n\nI concur.\n\nIt is now, after many iterations, well written and nicely crafted\nseries, IMVHO.\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"117532","messageId":"ca433830907061918s6c674bf6w2f8d166f645d4e33@mail.gmail.com","threadId":"20037","inReplyTo":"7vk52l4q7k.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Jul 2009, #01; Mon, 06)","fromName":"Mark Lodato","fromEmail":"lodatom@gmail.com","sentAt":"2009-07-07T02:18:03Z","receivedAt":"2009-07-07T02:18:03Z","isPatch":false,"sender":{"key":"lodatom@gmail.com","avatar":"https://avatars.githubusercontent.com/u/58860?v=4"},"body":"On Mon, Jul 6, 2009 at 2:32 PM, Junio C Hamano wrote:\n> [Stalled and may need help and prodding to go forward]\n>\n> * ml/http (Wed May 27 23:16:03 2009 -0400) 2 commits\n>  - http.c: add http.sslCertPasswordProtected option\n>  - http.c: prompt for SSL client certificate password\n>\n> I've rewritten these two to (1) move the #ifdef out of the main codepath,\n> and (2) use configuration/environment to make the misfeature of always\n> asking for a passphrase even a key/cert is unencrypted optional.  I tried\n> to be careful but extra sets of eyeballs would be nice to check the result.\n>\n> Nobody seems to be jumping up-and-down asking for this or helping to push\n> this forward.  Perhaps it's time to drop it?\n\nSorry for the lack of updates. After hearing feedback, the consensus\nseemed to be that detection of the certificate's encryption (above)\nand file type (other patch, not in git.git) should be done\nautomatically, that is, without user configuration. I agree, but\nneither can be done without great difficulty outside of libcurl.\nTherefore, I have started implement the autodetection of both, as well\nas the password caching, directly in libcurl. If my work, once\ncompleted, is accepted by the libcurl folks, then there would be no\nneed for the above, and we should recommend upgrading libcurl for\nthose who want to use client-side certificates.\n\nHowever, in the interim, and for users with earlier libcurl versions\n(and especially if my libcurl patch is never accepted), it might be\nnice to still have the above commits. They are unobtrusive - the\npatches are small, and they do not affect users who do not enable the\noption - yet they drastically improve the experience for those using\npassword-protected client-side certificates.\n\nAnyway, I am still very interested in getting proper client-side\ncertificate support in git, and I am glad to see Marcus is as well.\nUltimately, I think the libcurl solution is the proper way to go, but\nthis patch series might still be good to include in git. The downside\nis that it adds extra crap to the git-config man page and it does\nincrease the code size a little.\n\n--\nMark\n"},{"id":"117538","messageId":"4A52EB8F.1010806@viscovery.net","threadId":"20037","inReplyTo":"7vk52l4q7k.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Jul 2009, #01; Mon, 06)","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2009-07-07T06:30:39Z","receivedAt":"2009-07-07T06:30:39Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Junio C Hamano schrieb:\n> * ne/futz-upload-pack (Wed Jun 10 01:50:18 2009 +0200) 1 commit\n> - Shift object enumeration out of upload-pack\n\nI'm interested in this one because it is a step towards improved behavior\nof upload-pack on Windows if the repository is corrupted[*]. This patch\ncovers the common case where shallow clones are out of the game, but it is\nnot ready for prime time until its implementation is complete. IIUC, this\nshould be a fall-out of a GSoC project. Until then I include it in my git.\n\n[*] One test case in t5530 still fails on Windows, because for some reason\nerrors are not reported correctly. It has to do with the rev-list being\nrun in a thread and that thread die()s.\n\n-- Hannes\n"},{"id":"117576","messageId":"alpine.LFD.2.01.0907071142330.3210@localhost.localdomain","threadId":"20037","inReplyTo":"7vk52l4q7k.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Jul 2009, #01; Mon, 06)","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2009-07-07T19:17:46Z","receivedAt":"2009-07-07T19:17:46Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 6 Jul 2009, Junio C Hamano wrote:\n> \n> * lt/read-directory (Fri May 15 12:01:29 2009 -0700) 3 commits\n> - Add initial support for pathname conversion to UTF-8\n> - read_directory(): infrastructure for pathname character set\n> conversion\n> - Add 'fill_directory()' helper function for directory traversal\n> \n> Before adding the real \"conversion\", this needs a few real fixups, I\n> think. For example there is one hardcoded array that is used without\n> bounds check.\n\nHmm. I'm not sure what array you're talking about (the newpath/newbase \nones? We do protect against PATH_MAX, it's just that we protect against it \nin the \"previous iteration\").\n\nThe bigger issue, though, is that I spent half a day looking more at this \nseries last Thursday, and I've got some improvements, but getting \"all the \nway\" turns out to be really quite painful.\n\nWhy?\n\nWe have a _lot_ of code that does \"lstat()\" on pathnames, and it all \nbasically uses the internal git representation of the pathname. In \nparticular, we do this a lot for index lookups, but it's true in other \ncases too (example: things like tree merging, where we check whether a \nfile exists in the working tree).\n\nTo test this all out, I actually fleshed out the patches to the point \nwhere I could do\n\n\t[core]\n\t\tPathEncoding = Latin1\n\nand actually have the working tree use Latin1 encoding, and convert \ninternally in git to UTF-8, and have a working \"git add .\"\n\nHowever, \"git add .\" was just about the only thing that I made do the \nright thing. Even doing a simple \"git diff\" afterwards would then show the \nfile as deleted, because the UTF-8 version of the file (that the index \ncontained) didn't exist in the filesystem. I fixed that with a hack, but \nit basically turns out to be pretty damn ugly, and there's a _lot_ of \nthose places.\n\nSo, the question is, \"What now?\"\n\nThere's a few alternatives:\n\n(a) don't do any of this crap at all. What git does right now works fairly\n well for most people. Instead, perhaps worry about just the crazy \n case-insensitive filesystems, which are a totally separate issue.\n\n End result: git will always have problems with the crazy NFD format\n that OS X uses. Mixing git archives across OS X and other saner\n operating systems (and in this context, Windows really does count as\n \"saner\" - it really is OS X that is braindamaged!) will be painful if\n you have odd characters in your working tree.\n\n This is the simplest approach, of course. The case-insensitivity is \n still not trivial, but we could work on it, and it really is a \n different problem (and has none of the \"if you look the file up with a \n converted name, you cannot see it\" issues that the Latin1<->UTF8 \n example had).\n\n(b) Forget about the general case (like Latin1) that needs two-way \n conversion. Just worry about OS X being crazy, and do the NFD->NFC \n translation, which only needs to be done one way (because OS X will\n still accept and recognize NFC characters, so the \"converted\" path is \n still seen as valid by 'lstat()' and friends).\n\n This is very much just a special case of handling filesystems that are \n UTF-8, but are confused about what \"equivalent\" and \"identical\" means, \n and where the filesystem designer was a moron on some seriously crazy \n drugs, and thought that equivalence means identity, and thought that \n NFD is a sane form to expose.\n\n This is a much simpler case than the general approach. I don't have OS \n X to test with, though, and so far it hasn't appeared that any OS X \n people really care about to actually implement it. So I can fix up my \n series to a certain point, but will never be able to really do the \n final testing and tuning. At least with the full \"treat filesystem as \n Latin1 encoding\", I could _test_ it.\n\n(c) Try to bite the bullet. I can do this, but it really is going to be a \n _very_ invasive patch-series, and it will probably involve some nasty \n changes to the index format (for performance, we'll likely have to \n change the index to have _both_ the \"git filename\", and the \n \"filesystem filename\" in it).\n\n This was what I wanted to do, and it's what you'd need to do if you do \n things like Latin1 filesystem trees or ones where pathnames are done \n with shift-JIS encoding or if we want to actually use the (crazy) \n native Windows UCS filesystem accessors or whatever.\n\n But I have to admit that after looking at the pain, I'm not at all \n convinced it's worth it. Do we ever want to say \"git supports \n filesystems with shift-JIS encoding\"? Do people really care deeply \n enough about non-utf filesystems that they'd be willing to live with a \n _lot_ of pretty nasty complexity, and some real performance overhead?\n\nI have to say, even with plain UTF-8, git isn't really a pleasure to use. \nWhile I did my Latin1 test, I used filenames like \"åäö\" (the three extra \nFinnish/Swedish characters), and if you do this\n\n\tmkdir test-repo\n\tcd test-repo\n\tgit init\n\techo testfile > åäö\n\tgit add .\n\tgit ls-files\n\nthe end result is not actually really usable. We quote it to a binary \nmess, rather than showing \"åäö\". Our pathname quoting is trying to be \nsafe, which is good, but it does mean that right now, odd characters \naren't very friendly even _if_ you are using a sane filesystem, and all \nplain NFC utf-8.\n\nSo right now, my personal opinion is:\n\n - let's just face the fact that the only sane filename representation is \n NFC UTF-8. Show filenames as UTF-8 when possible, rather than quoting \n them.\n\n - Do case (b) above: add support for converting NFD -> NFC at readdir() \n time, so that OS X people can use UTF-8 sanely. \n\n - add a \"binary encoding\" mode to filesystems that actually use Latin1, \n just so that if people use Latin1 or Shift-JIS filesystem encodings, we \n promise that we'll never munge those kinds of names. \n\n - Maybe we'd make the \"binary encoding\" (which is effectively existing \n git behavior) be the default on non-OSX platforms.\n\nbut that's just my gut feel from trying to weigh the costs of trying to do \nsomething more involved against the costs of OS X support and just letting \ncrazy encodings exist in their own little worlds. So a development group \nthat uses Shift-JIS (or Latin1) would be able to work internally with git \nthat way, but would not be able to sanely work with the world at large \nthat uses UTF-8.\n\n\t\tLinus\n"},{"id":"117580","messageId":"81b0412b0907071257q14bb544dp99846f2a35fbada2@mail.gmail.com","threadId":"20037","inReplyTo":"alpine.LFD.2.01.0907071142330.3210@localhost.localdomain","subject":"Re: What's cooking in git.git (Jul 2009, #01; Mon, 06)","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2009-07-07T19:57:14Z","receivedAt":"2009-07-07T19:57:14Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On Tue, Jul 7, 2009 at 21:17, Linus\nTorvalds wrote:\n> So right now, my personal opinion is:\n>\n>  - let's just face the fact that the only sane filename representation is\n>   NFC UTF-8. Show filenames as UTF-8 when possible, rather than quoting\n>   them.\n>\n>  - Do case (b) above: add support for converting NFD -> NFC at readdir()\n>   time, so that OS X people can use UTF-8 sanely.\n>\n>  - add a \"binary encoding\" mode to filesystems that actually use Latin1,\n>   just so that if people use Latin1 or Shift-JIS filesystem encodings, we\n>   promise that we'll never munge those kinds of names.\n>\n>  - Maybe we'd make the \"binary encoding\" (which is effectively existing\n>   git behavior) be the default on non-OSX platforms.\n>\n> but that's just my gut feel from trying to weigh the costs of trying to do\n> something more involved against the costs of OS X support and just letting\n> crazy encodings exist in their own little worlds. So a development group\n> that uses Shift-JIS (or Latin1) would be able to work internally with git\n> that way, but would not be able to sanely work with the world at large\n> that uses UTF-8.\n\nMaybe we could at least let the user save the encoding of file names\nin the tree objects somehow?\n"},{"id":"117582","messageId":"alpine.DEB.1.00.0907072206170.3155@pacific.mpi-cbg.de","threadId":"20037","inReplyTo":"7vk52l4q7k.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Jul 2009, #01; Mon, 06)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-07-07T20:08:12Z","receivedAt":"2009-07-07T20:08:12Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 6 Jul 2009, Junio C Hamano wrote:\n\n> * jh/notes (Sat May 16 13:44:17 2009 +0200) 5 commits\n> - Teach \"-m \" and \"-F \" to \"git notes edit\"\n> - Add an expensive test for git-notes\n> - Speed up git notes lookup\n> - Add a script to edit/inspect notes\n> - Introduce commit notes\n> \n> Dscho asked about the performance implications of this; I do not think I \n> saw any progress on that yet...\n\nNeither did I.\n\n> * en/fast-export (Thu Jun 25 22:48:33 2009 -0600) 7 commits\n> - fast-export: Document the fact that git-rev-list arguments are\n> accepted\n> - Add new fast-export testcases\n> - fast-export: Add a --tag-of-filtered-object option for newly\n> dangling tags\n> - fast-export: Do parent rewriting to avoid dropping relevant\n> commits\n> - fast-export: Make sure we show actual ref names instead of\n> \"(null)\"\n> - fast-export: Omit tags that tag trees\n> - fast-export: Set revs.topo_order before calling setup_revisions\n> \n> Shawn? Dscho?\n\nSorry, today I was still jet-lagged, and I do not trust myself in such \nconditions at all. Will take another look tomorrow (what I saw looked \nokay to me, but I did not have time to look closely).\n\nCiao,\nDscho\n"},{"id":"117583","messageId":"20090707201326.GB11191@spearce.org","threadId":"20037","inReplyTo":"alpine.DEB.1.00.0907072206170.3155@pacific.mpi-cbg.de","subject":"Re: What's cooking in git.git (Jul 2009, #01; Mon, 06)","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2009-07-07T20:13:26Z","receivedAt":"2009-07-07T20:13:26Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Johannes Schindelin wrote:\n> On Mon, 6 Jul 2009, Junio C Hamano wrote:\n> \n> > * jh/notes (Sat May 16 13:44:17 2009 +0200) 5 commits\n> > - Teach \"-m \" and \"-F \" to \"git notes edit\"\n> > - Add an expensive test for git-notes\n> > - Speed up git notes lookup\n> > - Add a script to edit/inspect notes\n> > - Introduce commit notes\n> > \n> > Dscho asked about the performance implications of this; I do not think I \n> > saw any progress on that yet...\n> \n> Neither did I.\n\nI was thinking about this the other day. We could use a hash of\nthe commit timestamp as the top level directory. E.g. if we take\nthe commit time of the commit and convert it to a date string,\nwe could make the note path e.g.:\n\n YYYY/MM/COMMITSHA1\n\nThe advantage is we only need to scan and hash the subtrees for\nthe range of commits we are currently producing output for. As we\ngo further back in time, we can evict entries for newer dates and\nhash the older dates.\n\n-- \nShawn.\n"},{"id":"117593","messageId":"20090707211109.GA1922@coredump.intra.peff.net","threadId":"20037","inReplyTo":"ca433830907061918s6c674bf6w2f8d166f645d4e33@mail.gmail.com","subject":"Re: What's cooking in git.git (Jul 2009, #01; Mon, 06)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-07-07T21:11:09Z","receivedAt":"2009-07-07T21:11:09Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jul 06, 2009 at 10:18:03PM -0400, Mark Lodato wrote:\n\n> > * ml/http (Wed May 27 23:16:03 2009 -0400) 2 commits\n> >  - http.c: add http.sslCertPasswordProtected option\n> >  - http.c: prompt for SSL client certificate password\n> [...]\n> \n> Sorry for the lack of updates. After hearing feedback, the consensus\n> seemed to be that detection of the certificate's encryption (above)\n> and file type (other patch, not in git.git) should be done\n> automatically, that is, without user configuration. I agree, but\n> neither can be done without great difficulty outside of libcurl.\n> Therefore, I have started implement the autodetection of both, as well\n> as the password caching, directly in libcurl. If my work, once\n> completed, is accepted by the libcurl folks, then there would be no\n> need for the above, and we should recommend upgrading libcurl for\n> those who want to use client-side certificates.\n> \n> However, in the interim, and for users with earlier libcurl versions\n> (and especially if my libcurl patch is never accepted), it might be\n> nice to still have the above commits. They are unobtrusive - the\n> patches are small, and they do not affect users who do not enable the\n> option - yet they drastically improve the experience for those using\n> password-protected client-side certificates.\n\nYes, even if you get patches into libcurl, we will be supporting libcurl\nwithout this feature for some time. So I think the right upgrade path\nis:\n\n 1. add sslCertPasswordProtected as a bool config option now, defaulting\n to false (i.e., your patches)\n\n 2. libcurl grows new auto-detect feature\n\n 3. When the new feature is available at build-time, turn\n sslCertPasswordProtected into a tri-state yes/no/auto, defaulting to\n \"auto\". For older libcurl, setting it to \"auto\" should probably\n generate an error (or perhaps simply default to \"no\").\n\nIOW, whether the libcurl auto-detection feature happens or not, your\npatches are the right first step (and if \"not\", then they are the final\nstep :) ).\n\n-Peff\n"},{"id":"117595","messageId":"alpine.LFD.2.01.0907071504540.3210@localhost.localdomain","threadId":"20037","inReplyTo":"81b0412b0907071257q14bb544dp99846f2a35fbada2@mail.gmail.com","subject":"Re: What's cooking in git.git (Jul 2009, #01; Mon, 06)","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2009-07-07T22:13:39Z","receivedAt":"2009-07-07T22:13:39Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 7 Jul 2009, Alex Riesen wrote:\n> \n> Maybe we could at least let the user save the encoding of file names\n> in the tree objects somehow?\n\nThere's no place to really sanely save it in a tree, nor is there really \neven any way to figure the right encoding out. In fact, one of the \nproblems with non-utf encodings is that in theory people could literally \nbe mixing different encodings in one tree (imagine test-suites etc). \n\nThere's a reason why the only _sane_ model is to use an encoding that is \nuniversal. \n\nSo we could in theory save an encoding in the commit, but quite frankly, \nit's unlikely that we could use it sanely. Nobody is ever going to write a \nsane merge that will merge across different encodings. So realistically, \nyou're going to have a single encoding not per tree, or per commit, but \nfor the whole project.\n\nAnd then when you get fed up with Latin1 or Shift-JIS or whatever crazy \nsh*t people are still using, you use fast-export + script + fast-import, \nand change the encoding for the whole repository that way. Exactly because \ndoing it at a smaller granularity is a total pain in the *ss.\n\n\t\t\tLinus\n"},{"id":"117596","messageId":"7vk52k9lvw.fsf@alter.siamese.dyndns.org","threadId":"20037","inReplyTo":"20090707201326.GB11191@spearce.org","subject":"Re: What's cooking in git.git (Jul 2009, #01; Mon, 06)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-07-07T22:19:31Z","receivedAt":"2009-07-07T22:19:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Shawn O. Pearce\" writes:\n\n> Johannes Schindelin wrote:\n>> On Mon, 6 Jul 2009, Junio C Hamano wrote:\n>> \n>> > * jh/notes (Sat May 16 13:44:17 2009 +0200) 5 commits\n>> > - Teach \"-m \" and \"-F \" to \"git notes edit\"\n>> > - Add an expensive test for git-notes\n>> > - Speed up git notes lookup\n>> > - Add a script to edit/inspect notes\n>> > - Introduce commit notes\n>> > \n>> > Dscho asked about the performance implications of this; I do not think I \n>> > saw any progress on that yet...\n>> \n>> Neither did I.\n>\n> I was thinking about this the other day. We could use a hash of\n> the commit timestamp as the top level directory. E.g. if we take\n> the commit time of the commit and convert it to a date string,\n> we could make the note path e.g.:\n>\n> YYYY/MM/COMMITSHA1\n>\n> The advantage is we only need to scan and hash the subtrees for\n> the range of commits we are currently producing output for. As we\n> go further back in time, we can evict entries for newer dates and\n> hash the older dates.\n\nIs the idea to make the tree object we need to scan for that particular\nSHA-1 hash smaller?\n\nIf so, I am not sure how it would help over another approach of say taking\nthe first four hexdigits from the SHA-1 to use as the initial fan-out\nYYYY, then two hexdigits for the secondary fan-out MM.\n\nBut probably I am missing something.\n\nBesides, trees and blobs cannot be annotated with that approach.\n"},{"id":"117598","messageId":"20090707222820.GC11191@spearce.org","threadId":"20037","inReplyTo":"7vk52k9lvw.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Jul 2009, #01; Mon, 06)","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2009-07-07T22:28:20Z","receivedAt":"2009-07-07T22:28:20Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> \"Shawn O. Pearce\" writes:\n> >> \n> >> > * jh/notes (Sat May 16 13:44:17 2009 +0200) 5 commits\n> >\n> > I was thinking about this the other day. We could use a hash of\n> > the commit timestamp as the top level directory. E.g. if we take\n> > the commit time of the commit and convert it to a date string,\n> > we could make the note path e.g.:\n> >\n> > YYYY/MM/COMMITSHA1\n> \n> Is the idea to make the tree object we need to scan for that particular\n> SHA-1 hash smaller?\n\nNo, the idea was to avoid needing to create a massive hash of all\ncommit notes just to answer `git log -10` on the current branch.\nI remember that was a concern last time we were talking about this.\nBy putting the notes under a timestamped path we can scan only a\nsmall percentage of the notes before we have sufficient data to\noutput the first few commits.\n\n> If so, I am not sure how it would help over another approach of say taking\n> the first four hexdigits from the SHA-1 to use as the initial fan-out\n> YYYY, then two hexdigits for the secondary fan-out MM.\n\nSee above, the idea is to avoid scanning all notes at once on\nstartup. SHA-1 is bad at this as a fanout because it is too good\nat uniform distribution of the names.\n \n> But probably I am missing something.\n> \n> Besides, trees and blobs cannot be annotated with that approach.\n\nTrue. But I didn't realize that was a goal. :-|\n\n-- \nShawn.\n"},{"id":"117607","messageId":"4A543116.8050507@gmail.com","threadId":"20037","inReplyTo":"7vk52l4q7k.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Jul 2009, #01; Mon, 06)","fromName":"Stephen Boyd","fromEmail":"bebarino@gmail.com","sentAt":"2009-07-08T05:39:34Z","receivedAt":"2009-07-08T05:39:34Z","isPatch":false,"sender":{"key":"bebarino@gmail.com","avatar":"https://avatars.githubusercontent.com/u/38832?v=4"},"body":"Junio C Hamano wrote:\n> For the following three series, I have not managed to convince myself if\n> these changes have real-world needs.\n>\n> * sb/read-tree (Thu Jun 25 22:14:10 2009 -0700) 2 commits\n> - read-tree: migrate to parse-options\n> - read-tree: convert unhelpful usage()'s to helpful die()'s\n\nI think the first patch is good. I am still thinking about the second\none though. Obviously rc is coming so it's not too pressing.\n\nI've done a quick survey of parse-optification of builtins and I see\nthat send-pack, rev-list, and fetch-pack all set bitfields when parsing\noptions. Migrating these will have the same problems. I don't know if\nthere's really any simple answer to it though, because you can't take\nthe address of a bitfield. And I think it's stupid to make the bitfields\ninto full ints just to support parse-options.\n\nMaybe some builtins are just never meant to be migrated. Like\nupdate-index and its --cacheinfo option.\n"},{"id":"117609","messageId":"4A543EDF.5090302@viscovery.net","threadId":"20037","inReplyTo":"7vk52l4q7k.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Jul 2009, #01; Mon, 06)","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2009-07-08T06:38:23Z","receivedAt":"2009-07-08T06:38:23Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Junio C Hamano schrieb:\n> It has been relatively quiet for the past few weeks. The 'next' branch is\n> getting quite thin, and it would be a good time to declare -rc0. I'll do\n> so by my Wednesday.\n...\n> * js/run-command-updates (Sat Jul 4 21:26:43 2009 +0200) 7 commits\n> - receive-pack: remove unnecessary run_status report\n> - run_command: report failure to execute the program, but optionally\n> don't\n> - run_command: encode deadly signal number in the return value\n> - run_command: report system call errors instead of returning error\n> codes\n> - run_command: return exit code as positive value\n> - MinGW: simplify waitpid() emulation macros\n> - MinGW: truncate exit()'s argument to lowest 8 bits\n\nPlease include the first one of this series (truncate exit code) in -rc0;\nit fixes a bug in git-bisect on Windows.\n\nThanks,\n-- Hannes\n"},{"id":"117614","messageId":"alpine.DEB.1.00.0907081519210.4302@intel-tinevez-2-302","threadId":"20037","inReplyTo":"20090707222820.GC11191@spearce.org","subject":"notes, was Re: What's cooking in git.git (Jul 2009, #01; Mon, 06)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-07-08T13:42:11Z","receivedAt":"2009-07-08T13:42:11Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 7 Jul 2009, Shawn O. Pearce wrote:\n\n> Junio C Hamano wrote:\n> > \"Shawn O. Pearce\" writes:\n> > >> \n> > >> > * jh/notes (Sat May 16 13:44:17 2009 +0200) 5 commits\n> > >\n> > > I was thinking about this the other day. We could use a hash of the \n> > > commit timestamp as the top level directory. E.g. if we take the \n> > > commit time of the commit and convert it to a date string, we could \n> > > make the note path e.g.:\n> > >\n> > > YYYY/MM/COMMITSHA1\n> > \n> > Is the idea to make the tree object we need to scan for that \n> > particular SHA-1 hash smaller?\n> \n> No, the idea was to avoid needing to create a massive hash of all\n> commit notes just to answer `git log -10` on the current branch.\n> I remember that was a concern last time we were talking about this.\n> By putting the notes under a timestamped path we can scan only a\n> small percentage of the notes before we have sufficient data to\n> output the first few commits.\n\nThe problem is that you end up with possibly _very_ large root trees in \nthe notes, and the whole idea was to reduce the root tree, and load the \nsubtrees only on demand. That way, outputting a couple of commits (or a \nsingle one) is still cheap.\n\nTo recapitulate mugwump's idea: allow not only blobs in the root tree of \nthe notes, but also tree objects. That allows for fan-out -- if you want \nit.\n\nExample:\n\nCommit 0123456789abcdef0123456789abcdef01234567 can be in \nrefs/notes:0123456789abcdef0123456789abcdef01234567 or in\nrefs/notes:01/23456789abcdef0123456789abcdef01234567 or in\nrefs/notes:01/23/456789abcdef0123456789abcdef01234567 or in\n\nMy idea was to let shorter paths (in terms of characters used) precedence \n(and longer prefixes). There was also the idea to always show all of \nthem, but that would not appeal to me from a performance angle.\n\n> > If so, I am not sure how it would help over another approach of say \n> > taking the first four hexdigits from the SHA-1 to use as the initial \n> > fan-out YYYY, then two hexdigits for the secondary fan-out MM.\n> \n> See above, the idea is to avoid scanning all notes at once on startup. \n> SHA-1 is bad at this as a fanout because it is too good at uniform \n> distribution of the names.\n\nThe problem is the unpacking of the tree object.\n\n> > Besides, trees and blobs cannot be annotated with that approach.\n> \n> True. But I didn't realize that was a goal. :-|\n\nIt would be a nice-to-have, I guess.\n\nCiao,\nDscho\n"},{"id":"117751","messageId":"200907100705.16590.chriscool@tuxfamily.org","threadId":"20037","inReplyTo":"7vk52l4q7k.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Jul 2009, #01; Mon, 06)","fromName":"Christian Couder","fromEmail":"chriscool@tuxfamily.org","sentAt":"2009-07-10T05:05:16Z","receivedAt":"2009-07-10T05:05:16Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Monday 06 July 2009, Junio C Hamano wrote:\n> For the following three series, I have not managed to convince myself if\n> these changes have real-world needs.\n\n[...]\n\n> * cc/replace (Wed May 27 07:14:09 2009 +0200) 14 commits\n> - t6050: check pushing something based on a replaced commit\n> - Documentation: add documentation for \"git replace\"\n> - Add git-replace to .gitignore\n> - builtin-replace: use \"usage_msg_opt\" to give better error messages\n> - parse-options: add new function \"usage_msg_opt\"\n> - builtin-replace: teach \"git replace\" to actually replace\n> - Add new \"git replace\" command\n> - environment: add global variable to disable replacement\n> - mktag: call \"check_sha1_signature\" with the replacement sha1\n> - replace_object: add a test case\n> - object: call \"check_sha1_signature\" with the replacement sha1\n> - sha1_file: add a \"read_sha1_file_repl\" function\n> - replace_object: add mechanism to replace objects found in\n> \"refs/replace/\"\n> - refs: add a \"for_each_replace_ref\" function\n\nDidn't you say before that it would be an improvement over grafts?\n\nBy the way, may be it would be an improvement to use one bit in \"struct \nobject\" to mark replaced objects. It could make it easier to spot them \nwhere they could make the code behave strangely.\n\nAnyway I will have a 2 week long vacation starting today, so I won't be able \nto do much soon.\n\nBest regards,\nChristian.\n"}]}