{"thread":{"id":"20746","subject":"What's cooking in git.git (Aug 2009, #05; Wed, 26)","startedAt":"2009-08-26T23:45:14Z","lastAt":"2009-09-01T04:18:25Z","messageCount":15,"participants":["Junio C Hamano","Shawn O. Pearce","Sverre Rabbelier","Brandon Casey","Daniel Barkalow"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"121826","messageId":"7vfxbeb0mt.fsf@alter.siamese.dyndns.org","threadId":"20746","inReplyTo":null,"subject":"What's cooking in git.git (Aug 2009, #05; Wed, 26)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-08-26T23:45:14Z","receivedAt":"2009-08-26T23:45:14Z","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 integration branches, but I am\nstill holding onto them.\n\nAfter the 1.6.5 cycle, the next release will be 1.7.0, and we will push\nout the planned \"push safety\" change.  1.7.0 would be a good time to\nintroduce \"justifiable\" changes that are not strictly backward compatible.\n\nDuring 1.6.5 cycle, 'next' will hold topics meant for 1.6.5 and 1.7.0.\n\n--------------------------------------------------\n[Graduated to \"master\"]\n\n* aj/fix-read-tree-from-scratch (2009-08-17) 1 commit\n  (merged to 'next' on 2009-08-20 at 7a04133)\n + read-tree: Fix regression with creation of a new index file.\n\n* jc/maint-checkout-index-to-prefix (2009-08-16) 1 commit\n  (merged to 'next' on 2009-08-20 at 2f6aea2)\n + check_path(): allow symlinked directories to checkout-index --prefix\n\n* jl/submodule-summary-diff-files (2009-08-15) 2 commits\n  (merged to 'next' on 2009-08-15 at 165bd8e)\n + Documentaqtion/git-submodule.txt: Typofix\n  (merged to 'next' on 2009-08-14 at a702e78)\n + git submodule summary: add --files option\n\n* lh/short-decorate (2009-08-15) 1 commit\n  (merged to 'next' on 2009-08-18 at b8c1d96)\n + git-log: allow --decorate[=short|full]\n\n* oa/stash-na (2009-08-11) 1 commit\n  (merged to 'next' on 2009-08-14 at 12c2e2b)\n + git stash: Give friendlier errors when there is nothing to apply\n--------------------------------------------------\n[New Topics]\n\n* np/maint-1.6.3-deepen (2009-08-24) 1 commit.\n  (merged to 'next' on 2009-08-25 at 8e383d4)\n + fix simple deepening of a repo\n\n* jk/maint-1.6.3-checkout-unborn (2009-08-24) 1 commit.\n  (merged to 'next' on 2009-08-25 at 5f29625)\n + checkout: do not imply \"-f\" on unborn branches\n\n* mr/gitweb-snapshot (2009-08-25) 3 commits\n - gitweb: add t9501 tests for checking HTTP status codes\n - gitweb: split test suite into library and tests\n - gitweb: improve snapshot error handling\n--------------------------------------------------\n[Stalled]\n\n* js/stash-dwim (2009-07-27) 1 commit.\n  (merged to 'next' on 2009-08-16 at 67896c4)\n + Make 'git stash -k' a short form for 'git stash save --keep-index'\n (this branch is used by tr/reset-checkout-patch.)\n\n* tr/reset-checkout-patch (2009-08-18) 8 commits.\n  (merged to 'next' on 2009-08-18 at e465bb3)\n + tests: disable interactive hunk selection tests if perl is not available\n  (merged to 'next' on 2009-08-16 at 67896c4)\n + DWIM 'git stash save -p' for 'git stash -p'\n + Implement 'git stash save --patch'\n + Implement 'git checkout --patch'\n + Implement 'git reset --patch'\n + builtin-add: refactor the meat of interactive_add()\n + Add a small patch-mode testing library\n + git-apply--interactive: Refactor patch mode code\n (this branch uses js/stash-dwim.)\n\nThere was a discussion on better DWIMmery for the above two topics to (1)\nforbid \"git stash save --anything-with-dash\" and (2) redirect with any\noption \"git stash --opt\" to \"git stash save --opt\", to keep it flexible\nand safe at the same time.  I think it is a sane thing to do, but nothing\nhas happened lately.\n\n* jn/gitweb-blame (2009-08-06) 3 commits\n - gitweb: Create links leading to 'blame_incremental' using JavaScript\n - gitweb: Incremental blame (WIP)\n - gitweb: Add optional \"time to generate page\" info in footer\n\nAjax-y blame WIP\n\n* db/vcs-helper (2009-08-09) 17 commits\n - Allow helpers to request marks for fast-import\n - Allow helpers to report in \"list\" command that the ref is unchanged\n - Add support for \"import\" helper command\n - transport-helper_init(): fix a memory leak in error path\n - Add a config option for remotes to specify a foreign vcs\n - Allow programs to not depend on remotes having urls\n - Allow fetch to modify refs\n - Use a function to determine whether a remote is valid\n - Use a clearer style to issue commands to remote helpers\n  (merged to 'next' on 2009-08-07 at f3533ba)\n + Makefile: install hardlinks for git-remote-<scheme> supported by libcurl if possible\n + Makefile: do not link three copies of git-remote-* programs\n + Makefile: git-http-fetch does not need expat\n  (merged to 'next' on 2009-08-06 at 15da79d)\n + http-fetch: Fix Makefile dependancies\n + Add transport native helper executables to .gitignore\n  (merged to 'next' on 2009-08-05 at 33d491e)\n + git-http-fetch: not a builtin\n + Use an external program to implement fetching with curl\n + Add support for external programs for handling native fetches\n (this branch is used by jh/cvs-helper.)\n\nThere was a discussion that suggests that the use of colon ':' before vcs\nhelper name needs to be corrected.  Nothing happened since.\n\n* je/send-email-no-subject (2009-08-05) 1 commit\n - send-email: confirm on empty mail subjects\n\nThis seems to break t9001.  Near the tip of 'pu' I have a iffy\nworkaround.\n--------------------------------------------------\n[Cooking]\n\n* mm/reset-report (2009-08-21) 2 commits\n  (merged to 'next' on 2009-08-25 at f2a4424)\n + reset: make the reminder output consistent with \"checkout\"\n + Rename REFRESH_SAY_CHANGED to REFRESH_IN_PORCELAIN.\n\n* wl/insta-mongoose (2009-08-21) 1 commit\n  (merged to 'next' on 2009-08-25 at da1d566)\n + Add support for the Mongoose web server.\n\n* lt/approxidate (2009-08-22) 2 commits\n  (merged to 'next' on 2009-08-26 at 62853f9)\n + Further 'approxidate' improvements\n + Improve on 'approxidate'\n\nFixes a few \"reasonably formatted but thus-far misparsed\" date strings.\nAs Nico suggested, we would need a test to prevent regression to existing\nsupport for date strings that are \"reasonably formatted\".\n\n* jc/mailinfo-scissors (2009-08-25) 2 commits\n - Documentation: describe the scissors mark support of \"git am\"\n - Teach mailinfo to ignore everything before -- >8 -- mark\n\n* tf/diff-whitespace-incomplete-line (2009-08-23) 2 commits.\n  (merged to 'next' on 2009-08-26 at 4fc7784)\n + xutils: Fix xdl_recmatch() on incomplete lines\n + xutils: Fix hashing an incomplete line with whitespaces at the end\n\n* cc/sequencer-rebase-i (2009-08-21) 17 commits.\n - rebase -i: use \"git sequencer--helper --cherry-pick\"\n - sequencer: add \"--cherry-pick\" option to \"git sequencer--helper\"\n - sequencer: add \"do_commit()\" and related functions\n - pick: libify \"pick_help_msg()\"\n - revert: libify pick\n - rebase -i: use \"git sequencer--helper --fast-forward\"\n - sequencer: let \"git sequencer--helper\" callers set \"allow_dirty\"\n - sequencer: add \"--fast-forward\" option to \"git sequencer--helper\"\n - sequencer: add \"do_fast_forward()\" to perform a fast forward\n - rebase -i: use \"git sequencer--helper --reset-hard\"\n - sequencer: add \"--reset-hard\" option to \"git sequencer--helper\"\n - sequencer: add comments about reset_almost_hard()\n - sequencer: add \"reset_almost_hard()\" and related functions\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\nMigrating \"rebase -i\" bit by bit to C.  I am inclined to agree with Dscho\nthat maybe this approach forces the migration to follow the structure of\nthe shell script too much, and could force a suboptimal end result, but\nwe'll see.\n\n* as/maint-graph-interesting-fix (2009-08-21) 2 commits.\n  (merged to 'next' on 2009-08-25 at 9d5e215)\n + Add tests for rev-list --graph with options that simplify history\n + graph API: fix bug in graph_is_interesting()\n\nLooked sane.\n\n* jc/shortstatus (2009-08-15) 11 commits\n  (merged to 'next' on 2009-08-15 at 7e40766)\n + git commit --dry-run -v: show diff in color when asked\n + Documentation/git-commit.txt: describe --dry-run\n  (merged to 'next' on 2009-08-12 at 53bda17)\n + wt-status: collect untracked files in a separate \"collect\" phase\n + Make git_status_config() file scope static to builtin-commit.c\n + wt-status: move wt_status_colors[] into wt_status structure\n + wt-status: move many global settings to wt_status structure\n + commit: --dry-run\n  (merged to 'next' on 2009-08-06 at fe8cb94)\n + status: show worktree status of conflicted paths separately\n + wt-status.c: rework the way changes to the index and work tree are summarized\n + diff-index: keep the original index intact\n + diff-index: report unmerged new entries\n (this branch is used by jc/1.7.0-status.)\n\nWill cook for a bit more and then merge.\n\n* jc/maint-unpack-objects-strict (2009-08-13) 1 commit.\n  (merged to 'next' on 2009-08-23 at 38eb750)\n + Fix \"unpack-objects --strict\"\n\nWill merge.\n\n* jh/submodule-foreach (2009-08-20) 9 commits\n  (merged to 'next' on 2009-08-20 at 671bea4)\n + git clone: Add --recursive to automatically checkout (nested) submodules\n + t7407: Use 'rev-parse --short' rather than bash's substring expansion notation\n  (merged to 'next' on 2009-08-18 at f4a881d)\n + git submodule status: Add --recursive to recurse into nested submodules\n + git submodule update: Introduce --recursive to update nested submodules\n + git submodule foreach: Add --recursive to recurse into nested submodules\n + git submodule foreach: test access to submodule name as '$name'\n + Add selftest for 'git submodule foreach'\n + git submodule: Cleanup usage string and add option parsing to cmd_foreach()\n + git submodule foreach: Provide access to submodule name, as '$name'\n\nWill merge.\n\n* jh/notes (2009-07-29) 8 commits.\n - t3302-notes-index-expensive: Speed up create_repo()\n - fast-import: Add support for importing commit notes\n - First draft of notes tree parser with support for fanout subtrees\n - Teach \"-m <msg>\" and \"-F <file>\" 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\nThe cvs-helper series depends on this one.  I have a recollection\nthat some people were not happy about the fan-out of the notes tree\nlayout, but has the issue been resolved to a concensus?\n\n* ne/rev-cache (2009-08-21) 6 commits\n . support for path name caching in rev-cache\n . full integration of rev-cache into git, completed test suite\n . administrative functions for rev-cache, start of integration into git\n . support for non-commit object caching in rev-cache\n . basic revision cache system, no integration or features\n . man page and technical discussion for rev-cache\n\nUpdated but seems to break upload-pack tests when merged to 'pu'; given\nwhat this series touches, breakages in that area are expected.\nMay discard if a working reroll comes, to give it a fresh start.\n\n* jh/cvs-helper (2009-08-18) 7 commits\n - More fixes to the git-remote-cvs installation procedure\n - Fix the Makefile-generated path to the git_remote_cvs package in git-remote-cvs\n - Add simple selftests of git-remote-cvs functionality\n - git-remote-cvs: Remote helper program for CVS repositories\n - 2/2: Add Python support library for CVS remote helper\n - 1/2: Add Python support library for CVS remote helper\n - Basic build infrastructure for Python scripts\n (this branch uses db/vcs-helper.)\n\nBuilds on db/vcs-helper (which is stalled, so this cannot move).\n\nThe testing of Python part seemed to be still fragile even with the latest\nfix on one of my boches with an earlier round already installed, but I\ndidn't look very deeply before removing the older installation.\n\n* sr/gfi-options (2009-08-24) 4 commits\n - fast-import: test the new option command\n - fast-import: add option command\n - fast-import: put marks reading in it's own function\n - fast-import: put option parsing code in seperate functions\n\nWill merge to 'next' shortly.\n\n* lt/block-sha1 (2009-08-17) 4 commits\n  (merged to 'next' on 2009-08-18 at 67a1ce8)\n + remove ARM and Mozilla SHA1 implementations\n + block-sha1: guard gcc extensions with __GNUC__\n + make sure byte swapping is optimal for git\n + block-sha1: make the size member first in the context struct\n\nMay merge soon; Solaris performance patches that was discussed\nearlier can happen on 'master', as the series is usable as-is.\n\n* nd/sparse (2009-08-20) 20 commits\n - sparse checkout: inhibit empty worktree\n - Add tests for sparse checkout\n - read-tree: add --no-sparse-checkout to disable sparse checkout support\n - unpack-trees(): ignore worktree check outside checkout area\n - unpack_trees(): apply $GIT_DIR/info/sparse-checkout to the final index\n - unpack-trees(): \"enable\" sparse checkout and load $GIT_DIR/info/sparse-checkout\n - unpack-trees.c: generalize verify_* functions\n - unpack-trees(): add CE_WT_REMOVE to remove on worktree alone\n - Introduce \"sparse checkout\"\n - dir.c: export excluded_1() and add_excludes_from_file_1()\n - excluded_1(): support exclude files in index\n - unpack-trees(): carry skip-worktree bit over in merged_entry()\n - Read .gitignore from index if it is skip-worktree\n - Avoid writing to buffer in add_excludes_from_file_1()\n - Teach Git to respect skip-worktree bit (writing part)\n - Teach Git to respect skip-worktree bit (reading part)\n - Introduce \"skip-worktree\" bit in index, teach Git to get/set this bit\n - Add test-index-version\n - update-index: refactor mark_valid() in preparation for new options\n  (merged to 'next' on 2009-08-20 at ea167d7)\n + Prevent diff machinery from examining assume-unchanged entries on worktree\n\nThe first one was an independent fix; the rest has been replaced with the\n\"return of no-checkout\" series.\n--------------------------------------------------\n[For 1.7.0]\n\n* jc/1.7.0-status (2009-08-15) 3 commits\n  (merged to 'next' on 2009-08-22 at b3507bb)\n + git status: not \"commit --dry-run\" anymore\n + git stat -s: short status output\n + git stat: the beginning of \"status that is not a dry-run of commit\"\n (this branch uses jc/shortstatus.)\n\nWith this, \"git status\" is no longer \"git commit --preview\".\n\n* jc/1.7.0-send-email-no-thread-default (2009-08-22) 1 commit\n  (merged to 'next' on 2009-08-22 at 5106de8)\n + send-email: make --no-chain-reply-to the default\n\n* jc/1.7.0-diff-whitespace-only-status (2009-05-23) 2 commits.\n  (merged to 'next' on 2009-08-02 at 9c08420)\n + diff: Rename QUIET internal option to QUICK\n + diff: change semantics of \"ignore whitespace\" options\n\nThis changes exit code from \"git diff --ignore-whitespace\" and friends\nwhen there is no actual output.  It is a backward incompatible change, but\nwe could argue that it is a bugfix.\n\n* jc/1.7.0-push-safety (2009-02-09) 2 commits\n  (merged to 'next' on 2009-08-02 at 38b82fe)\n + Refuse deleting the current branch via push\n + Refuse updating the current branch in a non-bare repository via push\n--------------------------------------------------\n[I have been too busy to purge these]\n\n* jc/log-tz (2009-03-03) 1 commit.\n - Allow --date=local --date=other-format to work as expected\n\nMaybe some people care about this.  I dunno.\n\n* jc/mailinfo-remove-brackets (2009-07-15) 1 commit.\n - mailinfo: -b option keeps [bracketed] strings that is not a [PATCH] marker\n\nMaybe some people care about this.  I dunno.\n\n* ar/maint-1.6.2-merge-recursive-d-f (2009-05-11) 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\n* jc/merge-convert (2009-01-26) 1 commit.\n . git-merge-file: allow converting the results for the work tree\n\n* lt/read-directory (2009-05-15) 3 commits.\n . Add initial support for pathname conversion to UTF-8\n . read_directory(): infrastructure for pathname character set conversion\n . Add 'fill_directory()' helper function for directory traversal\n\n* ps/blame (2009-03-12) 1 commit.\n . blame.c: start libifying the blame infrastructure\n\n* pb/tracking (2009-07-16) 7 commits.\n . branch.c: if remote is not config'd for branch, don't try delete push config\n . branch, checkout: introduce autosetuppush\n . move deletion of merge configuration to branch.c\n . remote: add per-remote autosetupmerge and autosetuprebase configuration\n . introduce a struct tracking_config\n . branch: install_branch_config and struct tracking refactoring\n . config: allow false and true values for branch.autosetuprebase\n\nHas been ejected from 'pu' for some time, expecting a reroll.\n"},{"id":"121827","messageId":"20090826234903.GR1033@spearce.org","threadId":"20746","inReplyTo":"7vfxbeb0mt.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Aug 2009, #05; Wed, 26)","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2009-08-26T23:49:03Z","receivedAt":"2009-08-26T23:49:03Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano <gitster@pobox.com> wrote:\n> * sr/gfi-options (2009-08-24) 4 commits\n>  - fast-import: test the new option command\n>  - fast-import: add option command\n>  - fast-import: put marks reading in it's own function\n>  - fast-import: put option parsing code in seperate functions\n> \n> Will merge to 'next' shortly.\n\nPlease don't.\n\nThere is an off-git ML thread running between the various DVCS\ntool developers who work on the fast-import/fast-export tools for\nthe respective DVCSes.  In that thread we have decided to slightly\nchange this grammar and this series needs to be respun.\n\nIf you are itching to do something, eject it from pu and wait for\nthe respin.\n \n-- \nShawn.\n"},{"id":"121828","messageId":"fabb9a1e0908261710l2a957basff5eb5d7225ce099@mail.gmail.com","threadId":"20746","inReplyTo":"20090826234903.GR1033@spearce.org","subject":"Re: What's cooking in git.git (Aug 2009, #05; Wed, 26)","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-08-27T00:10:05Z","receivedAt":"2009-08-27T00:10:05Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Wed, Aug 26, 2009 at 16:49, Shawn O. Pearce<spearce@spearce.org> wrote:\n> In that thread we have decided to slightly\n> change this grammar and this series needs to be respun.\n\nSpeaking of which, do you want me to add the feature command to the\ngrammar and rebase this on top of that? I got the impression we were\nfar enough discussing that for at least an RPC patch?\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"121829","messageId":"20090827001207.GS1033@spearce.org","threadId":"20746","inReplyTo":"fabb9a1e0908261710l2a957basff5eb5d7225ce099@mail.gmail.com","subject":"Re: What's cooking in git.git (Aug 2009, #05; Wed, 26)","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2009-08-27T00:12:07Z","receivedAt":"2009-08-27T00:12:07Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Sverre Rabbelier <srabbelier@gmail.com> wrote:\n> On Wed, Aug 26, 2009 at 16:49, Shawn O. Pearce<spearce@spearce.org> wrote:\n> > In that thread we have decided to slightly\n> > change this grammar and this series needs to be respun.\n> \n> Speaking of which, do you want me to add the feature command to the\n> grammar and rebase this on top of that? I got the impression we were\n> far enough discussing that for at least an RPC patch?\n\nRFC patch.  And yes, because I think we already agreed in that\nthread that the date-format option is actually a feature command,\nand not an option command.  The other feature commands being kicked\naround can be held for another series.\n\n-- \nShawn.\n"},{"id":"121881","messageId":"SW-k_fUnLrE0kFNXSIYgMIc-pexuL5ykWs1ZdvHAo9_LMxe9ggJtCA@cipher.nrlssc.navy.mil","threadId":"20746","inReplyTo":"7vfxbeb0mt.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Aug 2009, #05; Wed, 26)","fromName":"Brandon Casey","fromEmail":"brandon.casey.ctr@nrlssc.navy.mil","sentAt":"2009-08-27T16:41:18Z","receivedAt":"2009-08-27T16:41:18Z","isPatch":false,"sender":{"key":"brandon.casey.ctr@nrlssc.navy.mil","avatar":null},"body":"Junio C Hamano wrote:\n\n> [Stalled]\n> \n> * je/send-email-no-subject (2009-08-05) 1 commit\n>  - send-email: confirm on empty mail subjects\n> \n> This seems to break t9001.  Near the tip of 'pu' I have a iffy\n> workaround.\n\nCan you squash this into your 'iffy' workaround to help platforms\n(Solaris 7, IRIX 6.5) without the 'yes' utility?\n\n---\n t/t9001-send-email.sh |    8 ++++++++\n 1 files changed, 8 insertions(+), 0 deletions(-)\n\ndiff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh\nindex 960d7d8..641d0c3 100755\n--- a/t/t9001-send-email.sh\n+++ b/t/t9001-send-email.sh\n@@ -505,6 +505,14 @@ test_expect_success '--suppress-cc=cc' '\n \ttest_suppression cc\n '\n \n+yes () {\n+\ttest -n \"$*\" && y=\"$*\" || y='y'\n+\twhile echo \"$y\"\n+\tdo\n+\t\t:\n+\tdone\n+}\n+\n test_confirm () {\n \tyes | \\\n \t\tGIT_SEND_EMAIL_NOTTY=1 \\\n-- \n1.6.4\n"},{"id":"121885","messageId":"7vr5uxrwld.fsf@alter.siamese.dyndns.org","threadId":"20746","inReplyTo":"SW-k_fUnLrE0kFNXSIYgMIc-pexuL5ykWs1ZdvHAo9_LMxe9ggJtCA@cipher.nrlssc.navy.mil","subject":"Re: What's cooking in git.git (Aug 2009, #05; Wed, 26)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-08-27T17:32:46Z","receivedAt":"2009-08-27T17:32:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Brandon Casey <brandon.casey.ctr@nrlssc.navy.mil> writes:\n\n>> This seems to break t9001.  Near the tip of 'pu' I have a iffy\n>> workaround.\n>\n> Can you squash this into your 'iffy' workaround to help platforms\n> (Solaris 7, IRIX 6.5) without the 'yes' utility?\n\nNot in this form, for two reasons ;-)\n\n(1) t7610-mergetool.sh,also seems to use \"yes\".  Perhaps define something\n    in test-lib.sh?\n\n(2) The implementation is iffy.\n\n> +yes () {\n> +\ttest -n \"$*\" && y=\"$*\" || y='y'\n\nShouldn't it be\n\n\tif test $# = 0\n        then\n        \ty=y\n\telse\n        \ty=\"$*\"\n\tfi\n\nso that\n\n\tyes \"\"\n\nwould give runs of empty lines?        \n"},{"id":"121887","messageId":"tK_IWVRokJuwYhAJ3h5cvYFUGHzmrYoRPbMxLQUdj2eLINK_28NnVA@cipher.nrlssc.navy.mil","threadId":"20746","inReplyTo":"7vr5uxrwld.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Aug 2009, #05; Wed, 26)","fromName":"Brandon Casey","fromEmail":"brandon.casey.ctr@nrlssc.navy.mil","sentAt":"2009-08-27T18:02:09Z","receivedAt":"2009-08-27T18:02:09Z","isPatch":false,"sender":{"key":"brandon.casey.ctr@nrlssc.navy.mil","avatar":null},"body":"Junio C Hamano wrote:\n> Brandon Casey <brandon.casey.ctr@nrlssc.navy.mil> writes:\n> \n>>> This seems to break t9001.  Near the tip of 'pu' I have a iffy\n>>> workaround.\n>> Can you squash this into your 'iffy' workaround to help platforms\n>> (Solaris 7, IRIX 6.5) without the 'yes' utility?\n> \n> Not in this form, for two reasons ;-)\n> \n> (1) t7610-mergetool.sh,also seems to use \"yes\".  Perhaps define something\n>     in test-lib.sh?\n> \n> (2) The implementation is iffy.\n\nLooks good, I'll rework it sometime if you don't beat me to it.\n\n-brandon\n\n\n\n>> +yes () {\n>> +\ttest -n \"$*\" && y=\"$*\" || y='y'\n> \n> Shouldn't it be\n> \n> \tif test $# = 0\n>         then\n>         \ty=y\n> \telse\n>         \ty=\"$*\"\n> \tfi\n> \n> so that\n> \n> \tyes \"\"\n> \n> would give runs of empty lines?        \n"},{"id":"121908","messageId":"fabb9a1e0908271248x3e2b03bblc2685530b14799a8@mail.gmail.com","threadId":"20746","inReplyTo":"20090827001207.GS1033@spearce.org","subject":"Re: What's cooking in git.git (Aug 2009, #05; Wed, 26)","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-08-27T19:48:13Z","receivedAt":"2009-08-27T19:48:13Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Wed, Aug 26, 2009 at 17:12, Shawn O. Pearce<spearce@spearce.org> wrote:\n> RFC patch.  And yes, because I think we already agreed in that\n> thread that the date-format option is actually a feature command,\n> and not an option command.  The other feature commands being kicked\n> around can be held for another series.\n\nDone, see v5a of the series (I messed up v5).\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"122064","messageId":"hFaZixUUvhrEV7wTTph3baQERVcA7g0KV0MihRGD1StE5zN58p2u1kJ9hdFMxNeyvn0_E3JvnFM@cipher.nrlssc.navy.mil","threadId":"20746","inReplyTo":"tK_IWVRokJuwYhAJ3h5cvYFUGHzmrYoRPbMxLQUdj2eLINK_28NnVA@cipher.nrlssc.navy.mil","subject":"[PATCH master] t/test-lib.sh: provide a shell implementation of the 'yes' utility","fromName":"Brandon Casey","fromEmail":"casey@nrlssc.navy.mil","sentAt":"2009-08-28T22:32:41Z","receivedAt":"2009-08-28T22:32:41Z","isPatch":true,"sender":{"key":"drafnel@gmail.com","avatar":"https://avatars.githubusercontent.com/u/921167?v=4"},"body":"From: Brandon Casey <drafnel@gmail.com>\n\nSome platforms (IRIX 6.5, Solaris 7) do not provide the 'yes' utility.\nCurrently, some tests, including t7610 and t9001, try to call this program.\nDue to the way the tests are structured, the tests still pass even though\nthis program is missing.  Rather than succeeding by chance, let's provide\nan implementation of the simple 'yes' utility in shell for all platforms to\nuse.\n\nSigned-off-by: Brandon Casey <casey@nrlssc.navy.mil>\n---\n t/test-lib.sh |   15 +++++++++++++++\n 1 files changed, 15 insertions(+), 0 deletions(-)\n\ndiff --git a/t/test-lib.sh b/t/test-lib.sh\nindex a5b8d03..f2ca536 100644\n--- a/t/test-lib.sh\n+++ b/t/test-lib.sh\n@@ -685,6 +685,21 @@ do\n \tesac\n done\n \n+# Provide an implementation of the 'yes' utility\n+yes () {\n+\tif test $# = 0\n+\tthen\n+\t\ty=y\n+\telse\n+\t\ty=\"$*\"\n+\tfi\n+\n+\twhile echo \"$y\"\n+\tdo\n+\t\t:\n+\tdone\n+}\n+\n # Fix some commands on Windows\n case $(uname -s) in\n *MINGW*)\n-- \n1.6.4\n"},{"id":"122095","messageId":"alpine.LNX.2.00.0908292116060.28290@iabervon.org","threadId":"20746","inReplyTo":"7vfxbeb0mt.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Aug 2009, #05; Wed, 26)","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2009-08-30T01:46:03Z","receivedAt":"2009-08-30T01:46:03Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 26 Aug 2009, Junio C Hamano wrote:\n\n> * db/vcs-helper (2009-08-09) 17 commits\n>  - Allow helpers to request marks for fast-import\n>  - Allow helpers to report in \"list\" command that the ref is unchanged\n>  - Add support for \"import\" helper command\n>  - transport-helper_init(): fix a memory leak in error path\n>  - Add a config option for remotes to specify a foreign vcs\n>  - Allow programs to not depend on remotes having urls\n>  - Allow fetch to modify refs\n>  - Use a function to determine whether a remote is valid\n>  - Use a clearer style to issue commands to remote helpers\n>   (merged to 'next' on 2009-08-07 at f3533ba)\n>  + Makefile: install hardlinks for git-remote-<scheme> supported by libcurl if possible\n>  + Makefile: do not link three copies of git-remote-* programs\n>  + Makefile: git-http-fetch does not need expat\n>   (merged to 'next' on 2009-08-06 at 15da79d)\n>  + http-fetch: Fix Makefile dependancies\n>  + Add transport native helper executables to .gitignore\n>   (merged to 'next' on 2009-08-05 at 33d491e)\n>  + git-http-fetch: not a builtin\n>  + Use an external program to implement fetching with curl\n>  + Add support for external programs for handling native fetches\n>  (this branch is used by jh/cvs-helper.)\n> \n> There was a discussion that suggests that the use of colon ':' before vcs\n> helper name needs to be corrected.  Nothing happened since.\n\nI believe the outcome of that discussion was:\n\n - We want to keep supporting using regular location URLs that are URLs of \n   git repositories (e.g., http://git.savannah.gnu.org/cgit/xboard.git), \n   and we probably want to do it with a helper which runs when \n   run_command() is given \"remote-<scheme>\". I think installing hardlinks \n   in EXECPATH ended up being the best implementation here. This is \n   currently a special case, because these URLs have push handled \n   internally (or, rather, with internal code calling a different external \n   program), but I think we want to make it no longer special at all, so \n   that people can install the handling for access to native repos via \n   dumb filesystem-like protocols separately. This is in next.\n\n - We want to support a separate \"vcs\" option for cases where repositories \n   in the foreign system need to be addressed through the combination of a \n   bunch of options, which will be read from the configuration by the \n   helper. The helper which gets run is \"remote-<value of vcs option>\". \n   This is in pu.\n\n - We want to support URLs of some sort leading to using helpers \n   appropriate for foreign systems that use URLs and are most conveniently \n   located this way. We didn't come to any concensus on what this should \n   do, but we also haven't had any helpers proposed yet that would use it, \n   and the series doesn't include any code that would lead to running a \n   helper other than in one of the above two cases. (jh's cvs helper \n   clearly wants \"cvsroot\" and \"cvsmodule\" options, and my p4 helper wants \n   \"port\" and \"codeline\" options; SVN is the big use cases for URLs, but \n   nobody's tackled that as a helper)\n\nSo I think this issue is squarely in \"future work\" anyway, and the current \npart of the series should be able to move forward, unless I've missed some \nother issue.\n\nOf course, there are a bunch of things that are beyond the present \ncontents of the series, but I think there's nothing wrong in the series as \nit is, and it's worthwhile without any further patches.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"122096","messageId":"7vskfat07h.fsf@alter.siamese.dyndns.org","threadId":"20746","inReplyTo":"alpine.LNX.2.00.0908292116060.28290@iabervon.org","subject":"Re: What's cooking in git.git (Aug 2009, #05; Wed, 26)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-08-30T04:06:10Z","receivedAt":"2009-08-30T04:06:10Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow <barkalow@iabervon.org> writes:\n\n>> There was a discussion that suggests that the use of colon ':' before vcs\n>> helper name needs to be corrected.  Nothing happened since.\n>\n> I believe the outcome of that discussion was:\n>\n>  - We want to keep supporting using regular location URLs that are URLs of \n>    git repositories (e.g., http://git.savannah.gnu.org/cgit/xboard.git), \n>    and we probably want to do it with a helper which runs when \n>    run_command() is given \"remote-<scheme>\". I think installing hardlinks \n>    in EXECPATH ended up being the best implementation here.\n\nThat is different from what I recall.\n\nI think you said <scheme> in the above to mean that in the general URL\nsyntax, <scheme> refers to the token before the colon, and you would be\nfeeding the rest (i.e. after the colon, and for many <scheme>'s it\ntypically begins with //) to the scheme.\n\nA flaw with this that was pointed out was that this conflicts with the\nscp-like syntax.  A remote.$name.url of foo:bar/baz could name\n$HOME/bar/baz on host foo (perhaps a nickname in .ssh/config), or the\nsource \"foo\" helper recognizes with the name bar/baz.\n\nIf I recall correctly, suggestions made later in the discussion were to\nuse either <helper>+ or <helper>:: as the prefix to avoid this issue, and\nuse it to choose remote-<helper> (and I think I probably would vote for\ndouble-colon, if only to avoid confusion with our own earlier misdesigned\nsyntax git+ssh://), so the canonical syntax would be:\n\n\t<helper>::<whatever is fed to the helper, typicall a URL>\n\nwhile we would support obvious short-hands for transports we traditionally\nsupported without explicit \"<helper>::\" prefix when we choose to eject it\nfrom \"built-in\" set of transports.\n\nE.g. http://git.savannah.gnu.org/cgit/xboard.git would be handled by curl\nbased walker, so if you spell it in the very canonical form, the url would\nbe curl::http://git.savannah.gnu.org/cgit/xboard.git, but nobody has to\nuse it.  Instead, the transport dispatcher internally recognizes http://\nand picks the curl based walker helper, which is remote-curl without any\nextra hardlinks.\n\nAnd from my point of view, this is what is blocking the series; and there\nstill is no -rc0 yet (I've been hoping to do a 1.6.5 mid September before\nI leave for Japan for about a week), because I think it is pointless to do\na new release without \"the ejection of curl from builtin\".\n\n>  - We want to support a separate \"vcs\" option for cases where repositories \n>    in the foreign system need to be addressed through the combination of a \n>    bunch of options, which will be read from the configuration by the \n>    helper. The helper which gets run is \"remote-<value of vcs option>\". \n>    This is in pu.\n\nAfter you explained this in the thread (I think for the second time), I\nsee no problem with this, except that I think to support this we should\nnotice and raise an error when we see a remote has both vcs and url,\nbecause the only reason we would want to say \"vcs\", if I recall your\nexplanation correctly, is that such a transport does not have the concept\nof URL, i.e. a well defined single string that identifies the repository.\n"},{"id":"122136","messageId":"7vzl9h9h70.fsf@alter.siamese.dyndns.org","threadId":"20746","inReplyTo":"7vskfat07h.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Aug 2009, #05; Wed, 26)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-08-30T20:31:47Z","receivedAt":"2009-08-30T20:31:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Daniel Barkalow <barkalow@iabervon.org> writes:\n>\n>>> There was a discussion that suggests that the use of colon ':' before vcs\n>>> helper name needs to be corrected.  Nothing happened since.\n>>\n>> I believe the outcome of that discussion was:\n>>\n>>  - We want to keep supporting using regular location URLs that are URLs of \n>>    git repositories (e.g., http://git.savannah.gnu.org/cgit/xboard.git), \n>>    and we probably want to do it with a helper which runs when \n>>    run_command() is given \"remote-<scheme>\". I think installing hardlinks \n>>    in EXECPATH ended up being the best implementation here.\n>\n> That is different from what I recall.\n> ...\n> And from my point of view, this is what is blocking the series...\n\nJust to make my position clear.\n\nI brought up the issue of \"should we leave it as a single colon that\nconfuses scp-like syntax and forces us to have three extra hardlinks?\" in\nthe message I am following up to, not because I firmly am on that side of\nthe argument, but because I thought your version of \"outcome\" did not\nmatch my recollection around that particular issue.  I am more or less\nneutral myself.  Avoiding the confusion seems obviously the simple and\nright thing to do, and I cannot think of obvious downsides of such a\nchange, but there probably are some downsides you have in mind, and I can\nwell imagine the issue may become \"perfect is the enemy of good\".\n\nAnd I said \"blocking the series\", not in the sense that _I_ demand to\nchange it from colon to something else, but in the sense that I recall the\nissue hasn't been settled in the discussion.\n"},{"id":"122191","messageId":"alpine.LNX.2.00.0908311130190.28290@iabervon.org","threadId":"20746","inReplyTo":"7vskfat07h.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Aug 2009, #05; Wed, 26)","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2009-08-31T17:06:24Z","receivedAt":"2009-08-31T17:06:24Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sat, 29 Aug 2009, Junio C Hamano wrote:\n\n> Daniel Barkalow <barkalow@iabervon.org> writes:\n> \n> >> There was a discussion that suggests that the use of colon ':' before vcs\n> >> helper name needs to be corrected.  Nothing happened since.\n> >\n> > I believe the outcome of that discussion was:\n> >\n> >  - We want to keep supporting using regular location URLs that are URLs of \n> >    git repositories (e.g., http://git.savannah.gnu.org/cgit/xboard.git), \n> >    and we probably want to do it with a helper which runs when \n> >    run_command() is given \"remote-<scheme>\". I think installing hardlinks \n> >    in EXECPATH ended up being the best implementation here.\n> \n> That is different from what I recall.\n> \n> I think you said <scheme> in the above to mean that in the general URL\n> syntax, <scheme> refers to the token before the colon, and you would be\n> feeding the rest (i.e. after the colon, and for many <scheme>'s it\n> typically begins with //) to the scheme.\n>\n> A flaw with this that was pointed out was that this conflicts with the\n> scp-like syntax.  A remote.$name.url of foo:bar/baz could name\n> $HOME/bar/baz on host foo (perhaps a nickname in .ssh/config), or the\n> source \"foo\" helper recognizes with the name bar/baz.\n>\n> If I recall correctly, suggestions made later in the discussion were to\n> use either <helper>+ or <helper>:: as the prefix to avoid this issue, and\n> use it to choose remote-<helper> (and I think I probably would vote for\n> double-colon, if only to avoid confusion with our own earlier misdesigned\n> syntax git+ssh://), so the canonical syntax would be:\n\n(with the syntax <helper>+, \"git+ssh://\" would specify the helper \"git\", \nwhich is as good an explicit identifier of the internal handling as any)\n\n> \n> \t<helper>::<whatever is fed to the helper, typicall a URL>\n> \n> while we would support obvious short-hands for transports we traditionally\n> supported without explicit \"<helper>::\" prefix when we choose to eject it\n> from \"built-in\" set of transports.\n>\n> E.g. http://git.savannah.gnu.org/cgit/xboard.git would be handled by curl\n> based walker, so if you spell it in the very canonical form, the url would\n> be curl::http://git.savannah.gnu.org/cgit/xboard.git, but nobody has to\n> use it.  Instead, the transport dispatcher internally recognizes http://\n> and picks the curl based walker helper, which is remote-curl without any\n> extra hardlinks.\n\nIf the policy is that we're going to have \"traditionally supported\" \nschemes, where the internal code knows what helper supports them, I can \nfix up the series so that the curl-based helper is named \"curl\", and we \ncan say that the check for \"http://\", \"ftp://\", and \"https://\" is \nrecognizing traditionally-supported schemes, and we can defer coming up \nwith what the syntax for the explicit handler selection is. (For that \nmatter, if there's a // after the colon, it's obviously not a \nhandy ssh-style location, since the second slash would do nothing)\n\nI think you're right that we decided that things we used to support \ninternally are a special case, and there's no need to try to generalize \nthem to be the general mechanism (even though I think we simultaneously \nworked out how to implement the design we were abandoning, which confused \nmy memory).\n\n> >  - We want to support a separate \"vcs\" option for cases where repositories \n> >    in the foreign system need to be addressed through the combination of a \n> >    bunch of options, which will be read from the configuration by the \n> >    helper. The helper which gets run is \"remote-<value of vcs option>\". \n> >    This is in pu.\n> \n> After you explained this in the thread (I think for the second time), I\n> see no problem with this, except that I think to support this we should\n> notice and raise an error when we see a remote has both vcs and url,\n> because the only reason we would want to say \"vcs\", if I recall your\n> explanation correctly, is that such a transport does not have the concept\n> of URL, i.e. a well defined single string that identifies the repository.\n\nA user who mostly uses Perforce as a foreign repositories but is using a \nSVN repo on occasion might want to use \"vcs\" regardless, but I agree with \nforcing the helper to use a different option for the case of a URL that \ngit isn't going to look at. That is, you ought to be able to use:\n\n[remote \"origin\"]\n\tvcs = svn\n\t(something) = http://svn.savannah.gnu.org/...\n\nBut \"(something)\" shouldn't be \"url\".\n\nSo my changes will be:\n\n - name the curl-based helper executable \"git-remote-curl\", and run it for \n   traditionally supported schemes by special-case.\n - prohibit using both \"vcs\" and \"url\" in a remote.\n\nAgreed?\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"122210","messageId":"7vhbvnzhdq.fsf@alter.siamese.dyndns.org","threadId":"20746","inReplyTo":"alpine.LNX.2.00.0908311130190.28290@iabervon.org","subject":"Re: What's cooking in git.git (Aug 2009, #05; Wed, 26)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-08-31T23:35:29Z","receivedAt":"2009-08-31T23:35:29Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow <barkalow@iabervon.org> writes:\n\n> On Sat, 29 Aug 2009, Junio C Hamano wrote:\n>\n>> ..., if only to avoid confusion with our own earlier misdesigned\n>> syntax git+ssh://), so the canonical syntax would be:\n>\n> (with the syntax <helper>+, \"git+ssh://\" would specify the helper \"git\", \n> which is as good an explicit identifier of the internal handling as any)\n\nSure but how would you explain \"ssh+git://\" then ;-)?\n\nLuckily neither is advertised in our documentation set as far as I can\ntell, so I do not think it is a huge deal between + vs ::, but as Peff\nsays in\n\n    http://thread.gmane.org/gmane.comp.version-control.git/125615\n\nI think the latter is probably less problematic.\n\nWith plus, a helper that talks with a Subversion repository whose native\nURL is http://host/path would look like svn+http://host/path, which is\nreasonable.  When talking the Subversion protocol over SSH, however, the\nnative URL for the repository would be svn+ssh://host/path, so the URL\nwith helper name on our side becomes svn+svn+ssh://host/path.  We could\nrecognize \"svn+\" part and implicitly pass the whole thing to svn helper\nupon seeing svn+ssh://host/path, but I do not think we would want to make\nthe dispatcher too familiar with what the backends do.  Using something\nother than plus sign would avoid this issue.\n\n> If the policy is that we're going to have \"traditionally supported\" \n> schemes, where the internal code knows what helper supports them, I can \n> fix up the series so that the curl-based helper is named \"curl\", and we \n> can say that the check for \"http://\", \"ftp://\", and \"https://\" is\n> recognizing traditionally-supported schemes, and we can defer coming up \n> with what the syntax for the explicit handler selection is. (For that \n> matter, if there's a // after the colon, it's obviously not a \n> handy ssh-style location, since the second slash would do nothing)\n\nThat sounds like a sane approach to first get the \"eject curl from\nbuiltin\" out the door.  We might extend the dispatcher in the future by\nchanging \"traditionally supported\" criterion to \"commonly used\",\ne.g. recognize \"svn+ssh://\" as something the svn helper would want to\nhandle, but that is a future extension we do not have to address right\nnow.\n\n>> After you explained this in the thread (I think for the second time), I\n>> see no problem with this, except that I think to support this we should\n>> notice and raise an error when we see a remote has both vcs and url,\n>> because the only reason we would want to say \"vcs\", if I recall your\n>> explanation correctly, is that such a transport does not have the concept\n>> of URL, i.e. a well defined single string that identifies the repository.\n>\n> A user who mostly uses Perforce as a foreign repositories but is using a \n> SVN repo on occasion might want to use \"vcs\" regardless, but I agree with \n> forcing the helper to use a different option for the case of a URL that \n> git isn't going to look at. That is, you ought to be able to use:\n>\n> [remote \"origin\"]\n> \tvcs = svn\n> \t(something) = http://svn.savannah.gnu.org/...\n>\n> But \"(something)\" shouldn't be \"url\".\n\nI actuallly do not have a strong opinion on this one either way.  I said\n\"I think\" when I suggested it, but it was actually without thinking too\ndeeply, hoping that you would come up with a good counter-argument.\n\nFor example, if we envision that for most of the helpers there will be one\nprimary string that identifies the repository, but the primary string\nalone is not enough for the helper without some auxiliary information, it\nwould be natural to use remote.$name.url for that primary string.  I do\nnot know if that would be the case, but I was hoping that you would have a\nbetter intuition[*1*], as you have thought this topic through a lot longer\nand deeper than I have.  So I'd rather leave the decision on that \"no\nvcs/url at the same time restriction\" up to you.  It is in general easier\nto start more strict and then loosen the restiction later, than the other\nway around, when we cannot decide, though.\n\nThanks.\n\n[Footnote]\n\n*1* What I mean by intuition is that you do not have to have the right\nanswer backed by research _now_, but have a good guess as to what the\nright answer would be.\n"},{"id":"122224","messageId":"alpine.LNX.2.00.0908312300250.28290@iabervon.org","threadId":"20746","inReplyTo":"7vhbvnzhdq.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Aug 2009, #05; Wed, 26)","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2009-09-01T04:18:25Z","receivedAt":"2009-09-01T04:18:25Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Mon, 31 Aug 2009, Junio C Hamano wrote:\n\n> Daniel Barkalow <barkalow@iabervon.org> writes:\n> \n> > On Sat, 29 Aug 2009, Junio C Hamano wrote:\n> >\n> >> ..., if only to avoid confusion with our own earlier misdesigned\n> >> syntax git+ssh://), so the canonical syntax would be:\n> >\n> > (with the syntax <helper>+, \"git+ssh://\" would specify the helper \"git\", \n> > which is as good an explicit identifier of the internal handling as any)\n> \n> Sure but how would you explain \"ssh+git://\" then ;-)?\n\nThat's just weird, and looks wrong to me, like ssh tunnelled over the git \nnative protocol. I think, if we support it, it would have to be another \nspecial case.\n\n> Luckily neither is advertised in our documentation set as far as I can\n> tell, so I do not think it is a huge deal between + vs ::, but as Peff\n> says in\n> \n>     http://thread.gmane.org/gmane.comp.version-control.git/125615\n> \n> I think the latter is probably less problematic.\n> \n> With plus, a helper that talks with a Subversion repository whose native\n> URL is http://host/path would look like svn+http://host/path, which is\n> reasonable.  When talking the Subversion protocol over SSH, however, the\n> native URL for the repository would be svn+ssh://host/path, so the URL\n> with helper name on our side becomes svn+svn+ssh://host/path.  We could\n> recognize \"svn+\" part and implicitly pass the whole thing to svn helper\n> upon seeing svn+ssh://host/path, but I do not think we would want to make\n> the dispatcher too familiar with what the backends do.  Using something\n> other than plus sign would avoid this issue.\n\nI was thinking that the dispatcher would always pass the whole thing, and \nthe svn helper would have to deal with svn+http:// and svn+svn:// as well \nas svn+ssh://. The dispatcher shouldn't be familiar with what the backends \ndo, but the backends could stand to be familiar with what might be there \njust to get to them. On the other hand, I don't have a good intuition for \nwhat makes sense to users of such systems, since I've only extensively \nused cvs, git, and perforce.\n\n> > If the policy is that we're going to have \"traditionally supported\" \n> > schemes, where the internal code knows what helper supports them, I can \n> > fix up the series so that the curl-based helper is named \"curl\", and we \n> > can say that the check for \"http://\", \"ftp://\", and \"https://\" is\n> > recognizing traditionally-supported schemes, and we can defer coming up \n> > with what the syntax for the explicit handler selection is. (For that \n> > matter, if there's a // after the colon, it's obviously not a \n> > handy ssh-style location, since the second slash would do nothing)\n> \n> That sounds like a sane approach to first get the \"eject curl from\n> builtin\" out the door.  We might extend the dispatcher in the future by\n> changing \"traditionally supported\" criterion to \"commonly used\",\n> e.g. recognize \"svn+ssh://\" as something the svn helper would want to\n> handle, but that is a future extension we do not have to address right\n> now.\n\nFair enough.\n\n> >> After you explained this in the thread (I think for the second time), I\n> >> see no problem with this, except that I think to support this we should\n> >> notice and raise an error when we see a remote has both vcs and url,\n> >> because the only reason we would want to say \"vcs\", if I recall your\n> >> explanation correctly, is that such a transport does not have the concept\n> >> of URL, i.e. a well defined single string that identifies the repository.\n> >\n> > A user who mostly uses Perforce as a foreign repositories but is using a \n> > SVN repo on occasion might want to use \"vcs\" regardless, but I agree with \n> > forcing the helper to use a different option for the case of a URL that \n> > git isn't going to look at. That is, you ought to be able to use:\n> >\n> > [remote \"origin\"]\n> > \tvcs = svn\n> > \t(something) = http://svn.savannah.gnu.org/...\n> >\n> > But \"(something)\" shouldn't be \"url\".\n> \n> I actuallly do not have a strong opinion on this one either way.  I said\n> \"I think\" when I suggested it, but it was actually without thinking too\n> deeply, hoping that you would come up with a good counter-argument.\n> \n> For example, if we envision that for most of the helpers there will be one\n> primary string that identifies the repository, but the primary string\n> alone is not enough for the helper without some auxiliary information, it\n> would be natural to use remote.$name.url for that primary string.  I do\n> not know if that would be the case, but I was hoping that you would have a\n> better intuition[*1*], as you have thought this topic through a lot longer\n> and deeper than I have.  So I'd rather leave the decision on that \"no\n> vcs/url at the same time restriction\" up to you.  It is in general easier\n> to start more strict and then loosen the restiction later, than the other\n> way around, when we cannot decide, though.\n\nAgreed.\n\n> Thanks.\n> \n> [Footnote]\n> \n> *1* What I mean by intuition is that you do not have to have the right\n> answer backed by research _now_, but have a good guess as to what the\n> right answer would be.\n\nI don't really have a particularly good guess about the case of vcs and a \nURL, because I haven't used systems that are not git and use URLs.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"}]}