{"thread":{"id":"34030","subject":"What's cooking in git.git (Jun 2013, #02; Tue, 4)","startedAt":"2013-06-04T23:45:37Z","lastAt":"2013-06-10T20:50:31Z","messageCount":104,"participants":["Junio C Hamano","David Lang","Michael Haggerty","Johannes Sixt","Jeff King","Felipe Contreras","demerphq","Barry Fishman","Matthieu Moy","Greg Troxel","Johannes Schindelin","Thomas Ferris Nicolaisen","Ramkumar Ramachandra","Charles McGarvey","Jonathan Nieder","Erik Faye-Lund","Matthew Ruffalo","Duy Nguyen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"219427","messageId":"7vtxld30f2.fsf@alter.siamese.dyndns.org","threadId":"34030","inReplyTo":null,"subject":"What's cooking in git.git (Jun 2013, #02; Tue, 4)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-06-04T23:45:37Z","receivedAt":"2013-06-04T23:45:37Z","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\n'-' are only in 'pu' (proposed updates) while commits prefixed with\n'+' are in 'next'.\n\nWe are in the post-1.8.3 cycle. As promised, 'next' has been\nrewound. A few stalled topics have been ejected and bunch of new\ntopics that have been cooking are now in it. I expect these on\n'next' to graduate to 'master' soonish, as I picked relatively easy\nones in this round.\n\nYou can find the changes described here in the integration branches\nof the repositories listed at\n\n http://git-blame.blogspot.com/p/git-public-repositories.html\n\n--------------------------------------------------\n[Graduated to \"master\"]\n\n* kb/status-ignored-optim-2 (2013-06-02) 1 commit\n (merged to 'next' on 2013-06-02 at 88ee588)\n + dir.c: fix ignore processing within not-ignored directories\n\n Fix 1.8.3 regressions in the .gitignore path exclusion logic.\n\n--------------------------------------------------\n[New Topics]\n\n* ar/wildmatch-foldcase (2013-06-02) 1 commit\n (merged to 'next' on 2013-06-04 at 3180bcc)\n + wildmatch: properly fold case everywhere\n\n The wildmatch engine did not honor WM_CASEFOLD option correctly.\n\n Will merge to 'master'.\n\n* cr/git-work-tree-sans-git-dir (2013-06-03) 1 commit\n (merged to 'next' on 2013-06-04 at bebedca)\n + git.txt: remove stale comment regarding GIT_WORK_TREE\n\n These days, \"git --work-tree=there cmd\" without specifying an\n explicit --git-dir=here will do the usual discovery, but we had a\n description of older behaviour in the documentation.\n\n Will merge to 'master'.\n\n\n* fc/do-not-use-the-index-in-add-to-index (2013-06-03) 2 commits\n (merged to 'next' on 2013-06-04 at 94e7b60)\n + read-cache: trivial style cleanups\n + read-cache: fix wrong 'the_index' usage\n\n Will merge to 'master'.\n\n\n* fc/sequencer-skip-quiet (2013-06-03) 8 commits\n - revert/cherry-pick: add --skip option\n - revert/cherry-pick: add --quiet option\n - sequencer: run post-rewrite hook\n - cherry-pick: store rewritten commits\n - SQUASH???\n - cherry-pick: add --skip-empty option\n - sequencer: trivial fix\n - sequencer: remove useless indentation\n\n I think the post-rewrite hook should not apply to revert, and\n revert should be taught about --skip-empty. The \"copy-notes\"\n change was nak'ed, and I agree with Thomas that the external\n interface to the mechanism should be aligned with existing\n notes.rewrite..\n\n Waiting for a reroll.\n\n $gmane/225676, $gmane/226263, $gmane/226271\n\n\n* js/test-ln-s-add (2013-06-02) 11 commits\n - t6035: use test_ln_s_add to remove SYMLINKS prerequisite\n - t3509, t4023, t4114: use test_ln_s_add to remove SYMLINKS prerequisite\n - t3100: use test_ln_s_add to remove SYMLINKS prerequisite\n - t3030: use test_ln_s_add to remove SYMLINKS prerequisite\n - t2100: use test_ln_s_add to remove SYMLINKS prerequisite\n - t0000: use test_ln_s_add to remove SYMLINKS prerequisite\n - tests: use test_ln_s_add to remove SYMLINKS prerequisite (trivial cases)\n - tests: introduce test_ln_s and test_ln_s_add\n - t3010: modernize style\n - t2100: modernize style and unroll a loop of test cases\n - test-chmtime: Fix exit code on Windows\n\n Many tests that check the behaviour of symbolic links stored in the\n index or the tree objects do not have to be skipped on a filesystem\n that lack symbolic link support.\n\n There seem to be some misconversion, mostly around the use of the\n new test_ln_s helper.\n\n Waiting for responses to reviews.\n $gmane/226417 and others.\n\n\n* mt/send-email-cc-match-fix (2013-06-03) 6 commits\n - t/send-email: test suppress-cc=self with non-ascii\n - t/send-email: add test with quoted sender\n - send-email: make --suppress-cc=self sanitize input\n - t/send-email: test suppress-cc=self on cccmd\n - send-email: fix suppress-cc=self on cccmd\n - t/send-email.sh: add test for suppress-cc=self\n\n It may want to have an additional test case for --from='\"A U. Thor\"\n ' to make sure we do not doubly escape what is\n already escaped.\n\n Some changes in patch 2/6 and a later patch may need to be flipped\n around.\n\n\n* rr/complete-difftool (2013-06-03) 2 commits\n (merged to 'next' on 2013-06-04 at 01c7611)\n + completion: clarify ls-tree, archive, show completion\n + completion: difftool takes both revs and files\n\n Update command line completion (in contrib/) to use a better named\n completion helper function for commands that take revisions and\n paths.\n\n Will merge to 'master'.\n\n\n* rr/diffcore-pickaxe-doc (2013-06-03) 2 commits\n (merged to 'next' on 2013-06-04 at 67d1fc7)\n + diffcore-pickaxe doc: document -S and -G properly\n + diffcore-pickaxe: make error messages more consistent\n\n Update the low-level diffcore documentation on -S/-G and --pickaxe-all.\n\n Will merge to 'master'.\n\n\n* tr/sha1-file-silence-loose-object-info-under-prune-race (2013-06-03) 1 commit\n (merged to 'next' on 2013-06-04 at e891bb8)\n + sha1_file: silence sha1_loose_object_info\n\n Will merge to 'master'.\n\n\n* bp/mediawiki-credential (2013-06-04) 1 commit\n - git-remote-mediawiki: use git.pm functions for credentials\n\n The bridge to MediaWiki has been updated to use the credential\n helper interface in Git.pm, losing its own and the original\n implementation the former was based on.\n\n Minor review comments sent.\n\n\n* mz/rebase-tests (2013-06-03) 7 commits\n - tests: move test for rebase messages from t3400 to t3406\n - t3406: modernize style\n - add tests for rebasing merged history\n - add tests for rebasing root\n - add tests for rebasing of empty commits\n - add tests for rebasing with patch-equivalence present\n - add simple tests of consistency across rebase types\n\n--------------------------------------------------\n[Stalled]\n\n* mg/more-textconv (2013-05-10) 7 commits\n - grep: honor --textconv for the case rev:path\n - grep: allow to use textconv filters\n - t7008: demonstrate behavior of grep with textconv\n - cat-file: do not die on --textconv without textconv filters\n - show: honor --textconv for blobs\n - diff_opt: track whether flags have been set explicitly\n - t4030: demonstrate behavior of show with textconv\n\n Make \"git grep\" and \"git show\" pay attention to --textconv when\n dealing with blob objects.\n\n I thought this was pretty well designed and executed, but it seems\n there are some doubts on the list; kicking back to 'pu'.\n\n\n* mh/multimail (2013-04-21) 1 commit\n - git-multimail: a replacement for post-receive-email\n\n Waiting for the initial history to pull from.\n $gmane/223564\n\n\n* jc/format-patch (2013-04-22) 2 commits\n - format-patch: --inline-single\n - format-patch: rename \"no_inline\" field\n\n A new option to send a single patch to the standard output to be\n appended at the bottom of a message. I personally have no need for\n this, but it was easy enough to cobble together. Tests, docs and\n stripping out more MIMEy stuff are left as exercises to interested\n parties.\n\n Not ready for inclusion.\n\n Will discard unless we hear from anybody who is interested in\n tying its loose ends.\n\n\n* jk/gitweb-utf8 (2013-04-08) 4 commits\n - gitweb: Fix broken blob action parameters on blob/commitdiff pages\n - gitweb: Don't append ';js=(0|1)' to external links\n - gitweb: Make feed title valid utf8\n - gitweb: Fix utf8 encoding for blob_plain, blobdiff_plain, commitdiff_plain, and patch\n\n Various fixes to gitweb.\n\n Drew Northup volunteered to take a look into this.\n $gmane/226216\n\n\n* jk/commit-info-slab (2013-04-19) 3 commits\n - commit-slab: introduce a macro to define a slab for new type\n - commit-slab: avoid large realloc\n - commit: allow associating auxiliary info on-demand\n (this branch is used by jc/show-branch.)\n\n Technology demonstration to show a way we could use unbound number\n of flag bits on commit objects.\n\n\n* jc/show-branch (2013-05-21) 5 commits\n - show-branch: use commit slab to represent bitflags of arbitrary width\n - show-branch.c: remove \"all_mask\"\n - show-branch.c: abstract out \"flags\" operation\n - show-branch.c: lift all_mask/all_revs to a global static\n - show-branch.c: update comment style\n (this branch uses jk/commit-info-slab.)\n\n Waiting for the final step to lift the hard-limit before sending it out.\n\n--------------------------------------------------\n[Cooking]\n\n* fc/completion-less-ls-remote (2013-06-02) 1 commit\n (merged to 'next' on 2013-06-03 at 6624f0b)\n + completion: avoid ls-remote in certain scenarios\n\n Will merge to 'master'.\n\n\n* jk/test-exit-code-by-signal (2013-06-02) 1 commit\n (merged to 'next' on 2013-06-03 at 25af892)\n + t0005: test git exit code from signal death\n\n Will merge to 'master'.\n\n\n* nd/make-wildmatch-default (2013-06-02) 1 commit\n - Makefile: promote wildmatch to be the default fnmatch implementation\n\n Will merge to 'next'.\n\n\n* rr/remove-contrib-some (2013-06-02) 1 commit\n - contrib: remove continuous/ and patches/\n\n Will merge to 'next'.\n\n\n* rs/unpack-trees-plug-leak (2013-06-02) 7 commits\n (merged to 'next' on 2013-06-03 at 97e7b6d)\n + unpack-trees: free cache_entry array members for merges\n + diff-lib, read-tree, unpack-trees: mark cache_entry array paramters const\n + diff-lib, read-tree, unpack-trees: mark cache_entry pointers const\n + unpack-trees: create working copy of merge entry in merged_entry\n + unpack-trees: factor out dup_entry\n + read-cache: mark cache_entry pointers const\n + cache: mark cache_entry pointers const\n\n Will merge to 'master'.\n\n\n* tr/test-commit-only-on-orphan (2013-06-02) 1 commit\n (merged to 'next' on 2013-06-03 at b1864fd)\n + Test 'commit --only' after 'checkout --orphan'\n\n Will merge to 'master'.\n\n\n* ap/diff-ignore-blank-lines (2013-05-29) 1 commit\n - diff: add --ignore-blank-lines option\n\n \"git diff\" learned a mode that ignores hunks whose change consists\n only of additions and removals of blank lines, which is the same as\n \"diff -B\" (ignore blank lines) of GNU diff.\n\n Will be rerolled.\n $gmane/226394\n\n\n* fc/show-branch-in-rebase-am (2013-05-29) 1 commit\n (merged to 'next' on 2013-06-03 at 176f6b7)\n + prompt: fix for simple rebase\n\n The bash prompt code (in contrib/) displayed the name of the branch\n being rebased when \"rebase -i/-m/-p\" modes are in use, but not the\n plain vanilla \"rebase\".\n\n Will merge to 'master'.\n\n\n* ks/difftool-dir-diff-copy-fix (2013-05-29) 1 commit\n (merged to 'next' on 2013-06-03 at ca0cae0)\n + difftool --dir-diff: allow changing any clean working tree file\n\n \"difftool --dir-diff\" did not copy back changes made by the\n end-user in the diff tool backend to the working tree in some\n cases.\n\n Will merge to 'master'.\n\n\n* rr/push-head (2013-05-29) 3 commits\n (merged to 'next' on 2013-06-03 at ecd5be7)\n + push: make push.default = current use resolved HEAD\n + push: fail early with detached HEAD and current\n + push: factor out the detached HEAD error message\n\n \"git push $there HEAD:branch\" did not resolve HEAD early enough, so\n it was easy to flip it around while push is still going on and push\n out a branch that the user did not originally intended when the\n command was started.\n\n Will merge to 'master'.\n\n\n* sb/archive-zip-double-assignment-fix (2013-05-29) 1 commit\n (merged to 'next' on 2013-06-03 at c316eec)\n + archive-zip:write_zip_entry: Remove second reset of size variable to zero.\n\n Will merge to 'master'.\n\n\n* rj/mingw-cygwin (2013-05-08) 2 commits\n (merged to 'next' on 2013-06-04 at 308fdb4)\n + cygwin: Remove the CYGWIN_V15_WIN32API build variable\n + mingw: rename WIN32 cpp macro to GIT_WINDOWS_NATIVE\n\n Update build for Cygwin 1.[57]. Torsten Bögershausen reports that\n this is fine with Cygwin 1.7 ($gmane/225824) so let's try moving it\n ahead.\n\n Will merge to 'master'.\n\n\n* rr/rebase-autostash (2013-05-29) 7 commits\n (merged to 'next' on 2013-06-04 at 16f7c54)\n + rebase: implement --[no-]autostash and rebase.autostash\n + rebase --merge: return control to caller, for housekeeping\n + rebase -i: return control to caller, for housekeeping\n + am: return control to caller, for housekeeping\n + rebase: prepare to do generic housekeeping\n + rebase -i: don't error out if $state_dir already exists\n + am: tighten a conditional that checks for $dotest\n\n Will merge to 'master'.\n\n\n* nd/urls-doc-no-file-hyperlink-fix (2013-05-24) 1 commit\n (merged to 'next' on 2013-06-03 at 54903b2)\n + urls.txt: avoid auto converting to hyperlink\n\n Will merge to 'master'.\n\n\n* cb/log-follow-with-combined (2013-05-28) 1 commit\n (merged to 'next' on 2013-06-04 at d5bf4f3)\n + fix segfault with git log -c --follow\n\n Will merge to 'master'.\n\n\n* fc/cleanups (2013-05-28) 3 commits\n (merged to 'next' on 2013-06-03 at 527cf93)\n + test: rebase: fix --interactive test\n + test: trivial cleanups\n + remote: trivial style cleanup\n\n Will merge to 'master'.\n\n\n* fc/makefile (2013-05-26) 5 commits\n (merged to 'next' on 2013-06-03 at d1074e4)\n + build: do not install git-remote-testpy\n + build: add NO_INSTALL variable\n + build: cleanup using $<\n + build: cleanup using $^\n + build: trivial simplification\n (this branch is used by fc/remote-helpers-use-specified-python.)\n\n Will merge to 'master'.\n\n\n* fc/remote-helpers-use-specified-python (2013-05-28) 4 commits\n - remote-helpers: add exec-path links\n - remote-helpers: allow direct test execution\n - remote-helpers: rename tests\n - remote-helpers: generate scripts\n (this branch uses fc/makefile.)\n\n I do not particularly think the second from the bottom is a good\n change, but it takes the remainder of the series hostage.\n\n Waiting for a reroll.\n\n\n* fc/send-email-chainreplyto-warning (2013-05-28) 1 commit\n (merged to 'next' on 2013-06-03 at e04764f)\n + send-email: remove warning about unset chainreplyto\n\n An overdue removal od \"behaviour changed at 1.7.0; if you were\n living in a cave, here is what you can adjust to it\" message.\n\n Will merge to 'master'.\n\n\n* nd/prune-packed-dryrun-verbose (2013-05-28) 1 commit\n (merged to 'next' on 2013-06-03 at 3445b27)\n + prune-packed: avoid implying \"1\" is DRY_RUN in prune_packed_objects()\n\n Will merge to 'master'.\n\n\n* rj/mingw-compat-st-mode-bits (2013-05-29) 1 commit\n (merged to 'next' on 2013-06-03 at 2efe84c)\n + path: Fix a sparse warning\n\n Will merge to 'master'.\n\n\n* rs/commit-m-no-edit (2013-05-28) 1 commit\n (merged to 'next' on 2013-06-03 at 14329fa)\n + commit: don't start editor if empty message is given with -m\n\n \"git commit --allow-empty-message -m ''\" should not start an\n editor.\n\n Will merge to 'master'.\n\n\n* xq/credential-osxkeychain (2013-05-28) 1 commit\n (merged to 'next' on 2013-06-04 at a4ee0e0)\n + credential-osxkeychain: support more protocols\n\n Will merge to 'master'.\n\n\n* jc/core-checkstat (2013-05-06) 1 commit\n (merged to 'next' on 2013-06-03 at 2166cb3)\n + deprecate core.statinfo at Git 2.0 boundary\n (this branch is used by jc/core-checkstat-2.0.)\n\n Will merge to 'master'.\n\n\n* mh/reflife (2013-06-02) 25 commits\n - refs: document the lifetime of the args passed to each_ref_fn\n - register_ref(): make a copy of the bad reference SHA-1\n - exclude_existing(): set existing_refs.strdup_strings\n - string_list_add_refs_by_glob(): add a comment about memory management\n - string_list_add_one_ref(): rename first parameter to \"refname\"\n - show_head_ref(): rename first parameter to \"refname\"\n - show_head_ref(): do not shadow name of argument\n - add_existing(): do not retain a reference to sha1\n - do_fetch(): clean up existing_refs before exiting\n - do_fetch(): reduce scope of peer_item\n - object_array_entry: fix memory handling of the name field\n - find_first_merges(): remove unnecessary code\n - find_first_merges(): initialize merges variable using initializer\n - fsck: don't put a void*-shaped peg in a char*-shaped hole\n - object_array_remove_duplicates(): rewrite to reduce copying\n - revision: use object_array_filter() in implementation of gc_boundary()\n - object_array: add function object_array_filter()\n - revision: split some overly-long lines\n - cmd_diff(): make it obvious which cases are exclusive of each other\n - cmd_diff(): rename local variable \"list\" -> \"entry\"\n - cmd_diff(): use an object_array for holding trees\n - builtin_diff_tree(): make it obvious that function wants two entries\n - add_rev_cmdline(): make a copy of the name argument\n - fetch: make own copies of refnames\n - describe: make own copy of refname\n\n Define memory ownership and lifetime rules for what for-each-ref\n feeds to its callbacks (in short, \"you do not own it, so make a\n copy if you want to keep it\").\n\n Will merge to 'next'.\n\n\n* th/bisect-skip-report-range-fix (2013-05-22) 1 commit\n (merged to 'next' on 2013-06-03 at 7bd4656)\n + bisect: Fix log output for multi-parent skip ranges\n\n Fix for an additional bisect log comments.\n\n Will merge to 'master'.\n\n\n* mm/mediawiki-https-fail-message (2013-05-29) 1 commit\n (merged to 'next' on 2013-06-04 at fb2671c)\n + git-remote-mediawiki: better error message when HTTP(S) access fails\n\n Hint users when https:// connection failed to check the\n certificate; it is a good hint if we assumie that it is common\n error for the end users to make.\n\n Will merge to 'master'.\n\n\n* tg/maint-zsh-svn-remote-prompt (2013-05-22) 1 commit\n (merged to 'next' on 2013-06-03 at 32a45c0)\n + prompt: fix show upstream with svn and zsh\n\n zsh prompt script that borrowed from bash prompt script did not\n work due to slight differences in array variable notation between\n these two shells.\n\n Will merge to 'master'.\n\n\n* tr/push-no-verify-doc (2013-05-23) 1 commit\n (merged to 'next' on 2013-06-03 at 01737d6)\n + Document push --no-verify\n\n \"git push --[no-]verify\" was not documented.\n\n Will merge to 'master'.\n\n\n* dm/unbash-subtree (2013-05-21) 1 commit\n (merged to 'next' on 2013-06-03 at 2c9d2fb)\n + contrib/git-subtree: Use /bin/sh interpreter instead of /bin/bash\n\n It turns out that git-subtree script does not have to be run with\n bash.\n\n Will merge to 'master'.\n\n\n* fc/transport-helper-no-refspec (2013-05-21) 2 commits\n (merged to 'next' on 2013-06-03 at 8763bda)\n + transport-helper: check if the dry-run is supported\n + transport-helper: barf when user tries old:new\n\n With \"export\" remote-helper protocol, (1) a push that tries to\n update a remote ref whose name is different from the pushing side\n does not work yet, and (2) the helper may not know how to do\n --dry-run, so detect such problematic cases and disable them for\n now.\n\n Will merge to 'master'.\n\n\n* rr/die-on-missing-upstream (2013-06-02) 2 commits\n (merged to 'next' on 2013-06-03 at 00847ea)\n + sha1_name: fix error message for @{}, @{}\n + sha1_name: fix error message for @{u}\n\n When a reflog notation is used for implicit \"current branch\", we\n did not say which branch and worse said \"branch ''\".\n\n Will merge to 'master'.\n\n\n* fc/remote-bzr (2013-05-28) 8 commits\n (merged to 'next' on 2013-06-04 at a603082)\n + remote-bzr: add fallback check for a partial clone\n + remote-bzr: reorganize the way 'wanted' works\n + remote-bzr: trivial cleanups\n + remote-bzr: change global repo\n + remote-bzr: delay cloning/pulling\n + remote-bzr: simplify get_remote_branch()\n + remote-bzr: fix for files with spaces\n + remote-bzr: recover from failed clones\n\n Will merge to 'master'.\n\n\n* jx/clean-interactive (2013-06-03) 15 commits\n - test: add t7301 for git-clean--interactive\n - git-clean: add documentation for interactive git-clean\n - git-clean: add ask each interactive action\n - git-clean: add select by numbers interactive action\n - git-clean: add filter by pattern interactive action\n - git-clean: use a git-add-interactive compatible UI\n - git-clean: add colors to interactive git-clean\n - git-clean: show items of del_list in columns\n - git-clean: add support for -i/--interactive\n - git-clean: refactor git-clean into two phases\n - Refactor write_name_quoted_relative, remove unused params\n - Refactor quote_path_relative, remove unused params\n - quote.c: remove path_relative, use relative_path instead\n - path.c: refactor relative_path(), not only strip prefix\n - test: add test cases for relative_path\n\n\n* tr/test-v-and-v-subtest-only (2013-05-16) 6 commits\n - test-lib: support running tests under valgrind in parallel\n - test-lib: allow prefixing a custom string before \"ok N\" etc.\n - test-lib: valgrind for only tests matching a pattern\n - test-lib: verbose mode for only tests matching a pattern\n - test-lib: refactor $GIT_SKIP_TESTS matching\n - test-lib: enable MALLOC_* for the actual tests\n\n Allows N instances of tests run in parallel, each running 1/N parts\n of the test suite under Valgrind, to speed things up.\n\n The tip one may be useful in practice but is a tad ugly ;-)\n\n There seem to be some miscounting by toggling the verbose/valgrind\n mode at wrong places? Cf. $gmane/225735\n\n Waiting for a reroll.\n\n\n* rr/zsh-color-prompt (2013-05-17) 3 commits\n (merged to 'next' on 2013-06-03 at d011a76)\n + prompt: colorize ZSH prompt\n + prompt: factor out gitstring coloring logic\n + prompt: introduce GIT_PS1_STATESEPARATOR\n\n Will merge to 'master'.\n\n\n* fc/contrib-related (2013-06-03) 4 commits\n - contrib: related: parse committish like format-patch\n - contrib: related: add option to parse from committish\n - contrib: related: add support for multiple patches\n - Add new git-related helper to contrib\n\n Waiting for the design review to settle.\n\n\n* fc/remote-hg (2013-05-28) 50 commits\n (merged to 'next' on 2013-06-04 at 9ee7dab)\n + remote-hg: add support for --force\n + remote-hg: add support for --dry-run\n + remote-hg: check if a fetch is needed\n + remote-hg: trivial cleanup\n + remote-helpers: improve marks usage\n + remote-hg: add check_push() helper\n + remote-hg: add setup_big_push() helper\n + remote-hg: remove files before modifications\n + remote-hg: improve lightweight tag author\n + remote-hg: use remote 'default' not local one\n + remote-hg: improve branch listing\n + remote-hg: simplify branch_tip()\n + remote-hg: check diverged bookmarks\n + remote-hg: pass around revision refs\n + remote-hg: implement custom checkheads()\n + remote-hg: implement custom push()\n + remote-hg: only update necessary revisions\n + remote-hg: force remote bookmark push selectively\n + remote-hg: reorganize bookmark handling\n + remote-hg: add test for failed double push\n + remote-hg: add test for big push\n + remote-hg: add test for new bookmark special\n + remote-hg: add test for bookmark diverge\n + remote-hg: add test for diverged push\n + remote-hg: add test to push new bookmark\n + remote-hg: add remote tests\n + remote-hg: update bookmarks when using a remote\n + remote-hg: add check_bookmark() test helper\n + remote-bzr: simplify test checks\n + remote-hg: add tests for 'master' bookmark\n + remote-hg: always point HEAD to master\n + remote-hg: improve progress calculation\n + remote-hg: trivial cleanups\n + remote-hg: ensure remote rebasing works\n + remote-hg: upgrade version 1 marks\n + remote-hg: switch from revisions to SHA-1 noteids\n + remote-hg: add version checks to the marks\n + remote-hg: improve node traversing\n + remote-hg: shuffle some code\n + remote-hg: use a shared repository store\n + remote-hg: load all extensions\n + remote-hg: test: simplify previous branch checkout\n + remote-helpers: test: simplify remote URLs\n + remote-helpers: tests: general improvements\n + remote-helpers: test: cleanup style\n + remote-helpers: test: cleanup white-spaces\n + remote-hg: trivial reorganization\n + remote-hg: test: be a little more quiet\n + remote-hg: tests: fix hg merge\n + remote-helpers: tests: use python directly\n\n Will merge to 'master'.\n\n\n* hv/config-from-blob (2013-05-12) 5 commits\n - do not die when error in config parsing of buf occurs\n - teach config --blob option to parse config from database\n - config: make parsing stack struct independent from actual data source\n - config: drop cf validity check in get_next_char()\n - config: factor out config file stack management\n\n Waiting for a reroll.\n $gmane/223964\n\n\n* nd/clone-connectivity-shortcut (2013-05-28) 4 commits\n (merged to 'next' on 2013-06-03 at 812bd80)\n + clone: open a shortcut for connectivity check\n + index-pack: remove dead code (it should never happen)\n + fetch-pack: prepare updated shallow file before fetching the pack\n + clone: let the user know when check_everything_connected is run\n\n Will merge to 'master'.\n\n\n* kb/full-history-compute-treesame-carefully-2 (2013-05-16) 15 commits\n - revision.c: make default history consider bottom commits\n - revision.c: don't show all merges for --parents\n - revision.c: discount side branches when computing TREESAME\n - revision.c: add BOTTOM flag for commits\n - simplify-merges: drop merge from irrelevant side branch\n - simplify-merges: never remove all TREESAME parents\n - t6012: update test for tweaked full-history traversal\n - revision.c: Make --full-history consider more merges\n - Documentation: avoid \"uninteresting\"\n - rev-list-options.txt: correct TREESAME for P\n - t6111: add parents to tests\n - t6111: allow checking the parents as well\n - t6111: new TREESAME test set\n - t6019: test file dropped in -s ours merge\n - decorate.c: compact table when growing\n\n Major update to a very core part of the system to improve culling\n of irrelevant parents while traversing a mergy history.\n\n Will not be a 1.8.3 material, but is an important topic.\n\n Will merge to 'next'.\n\n\n* mm/color-auto-default (2013-05-15) 2 commits\n - make color.ui default to 'auto'\n - config: refactor management of color.ui's default value\n\n Flip the default for color.ui to 'auto', which is what many\n tutorials recommend new users to do. The updated code claims the\n switch happened at Git 2.0 in the past tense, but we might want to\n expedite it, as this change is not all that important to deserve a\n major version bump.\n\n I'd vote for merging this without waiting for 2.0. Comments?\n\n Waiting for a reroll.\n\n\n* jh/shorten-refname (2013-05-07) 4 commits\n - t1514: refname shortening is done after dereferencing symbolic refs\n - shorten_unambiguous_ref(): Fix shortening refs/remotes/origin/HEAD to origin\n - t1514: Demonstrate failure to correctly shorten \"refs/remotes/origin/HEAD\"\n - t1514: Add tests of shortening refnames in strict/loose mode\n\n When remotes/origin/HEAD is not a symbolic ref, \"rev-parse\n --abbrev-ref remotes/origin/HEAD\" ought to show \"origin\", not\n \"origin/HEAD\", which is fixed with this series (if it is a symbolic\n ref that points at remotes/origin/something, then it should show\n \"origin/something\" and it already does).\n\n Expecting a reroll, as an early part of a larger series.\n\n\n* nd/warn-ambiguous-object-name (2013-05-29) 1 commit\n (merged to 'next' on 2013-06-04 at e87c9d1)\n + get_sha1: warn about full or short object names that look like refs\n\n \"git cmd \", when happens to be a 40-hex string,\n directly uses the 40-hex string as an object name, even if a ref\n \"refs//\" exists. This disambiguation order\n is unlikely to change, but we should warn about the ambiguity just\n like we warn when more than one refs/ hierachies share the same\n name.\n\n Will merge to 'master'.\n\n\n* jk/packed-refs-race (2013-05-06) 4 commits\n - for_each_ref: load all loose refs before packed refs\n - get_packed_refs: reload packed-refs file when it changes\n - add a stat_validity struct\n - resolve_ref: close race condition for packed refs\n\n What is the status of this thing?\n\n\n* fc/at-head (2013-05-08) 13 commits\n (merged to 'next' on 2013-06-04 at f334a2a)\n + sha1_name: compare variable with constant, not constant with variable\n + Add new @ shortcut for HEAD\n + sha1_name: refactor reinterpret()\n + sha1_name: check @{-N} errors sooner\n + sha1_name: reorganize get_sha1_basic()\n + sha1_name: don't waste cycles in the @-parsing loop\n + sha1_name: remove unnecessary braces\n + sha1_name: remove no-op\n + tests: at-combinations: @{N} versus HEAD@{N}\n + tests: at-combinations: increase coverage\n + tests: at-combinations: improve nonsense()\n + tests: at-combinations: check ref names directly\n + tests: at-combinations: simplify setup\n\n Instead of typing four capital letters \"HEAD\", you can say \"@\"\n instead.\n\n Will merge to 'master'.\n\n\n* jk/submodule-subdirectory-ok (2013-04-24) 3 commits\n - submodule: fix quoting in relative_path()\n - submodule: drop the top-level requirement\n - rev-parse: add --prefix option\n\n Allow various subcommands of \"git submodule\" to be run not from the\n top of the working tree of the superproject.\n\n Waiting for a reroll.\n\n\n* jl/submodule-mv (2013-04-23) 5 commits\n - submodule.c: duplicate real_path's return value\n - rm: delete .gitmodules entry of submodules removed from the work tree\n - Teach mv to update the path entry in .gitmodules for moved submodules\n - Teach mv to move submodules using a gitfile\n - Teach mv to move submodules together with their work trees\n\n \"git mv A B\" when moving a submodule A does \"the right thing\",\n inclusing relocating its working tree and adjusting the paths in\n the .gitmodules file.\n\n Waiting for a reroll.\n\n\n* jn/add-2.0-u-A-sans-pathspec (2013-04-26) 1 commit\n - git add: -u/-A now affects the entire working tree\n\n Will cook in 'next' until Git 2.0.\n\n\n* jc/core-checkstat-2.0 (2013-05-06) 1 commit\n - core.statinfo: remove as promised in Git 2.0\n (this branch uses jc/core-checkstat.)\n\n Will cook in 'next' until Git 2.0.\n\n\n* jc/push-2.0-default-to-simple (2013-04-03) 1 commit\n - push: switch default from \"matching\" to \"simple\"\n\n Will cook in 'next' until Git 2.0.\n\n\n* jc/add-2.0-ignore-removal (2013-04-22) 1 commit\n - git add ... defaults to \"-A\"\n\n Updated endgame for \"git add \" that defaults to \"--all\"\n aka \"--no-ignore-removal\".\n\n Will cook in 'next' until Git 2.0.\n"},{"id":"219428","messageId":"7va9n52zjc.fsf@alter.siamese.dyndns.org","threadId":"34030","inReplyTo":"7vtxld30f2.fsf@alter.siamese.dyndns.org","subject":"[Administrivia] On ruby and contrib/","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-06-05T00:04:39Z","receivedAt":"2013-06-05T00:04:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> * fc/contrib-related (2013-06-03) 4 commits\n> - contrib: related: parse committish like format-patch\n> - contrib: related: add option to parse from committish\n> - contrib: related: add support for multiple patches\n> - Add new git-related helper to contrib\n>\n> Waiting for the design review to settle.\n\nAs people may have seen in the discussion on the earlier iteration,\nsomething like this (there may be a room for bikeshedding the name,\nthough) that takes either a range of changes or set of patches and\nfinds people who may be able to review them may be a good addition\nto our official toolchest.\n\n http://thread.gmane.org/gmane.comp.version-control.git/221728/focus=221796\n\nRight now, \"related\" is in contrib/ primarily because its design\nreview phase is not yet finished and because it is in Ruby, which\nthe rest of the system does not depend on.\n\nI have some administrative comments on two issues as the maintainer.\n\n * Do we want to add Ruby dependency?\n * Do we want to keep expanding contrib/?\n\nThese have been triggered by \"related\", but the comments in this\nmessage are not limited to the specific topic (e.g. you can read it\nwith s/Ruby//).\n\n\nOn Ruby:\n\nAssuming \"related\" is a good idea, to make it as the proper part of\nthe system out of contrib/ when its design review phase is finished,\none of these things has to happen:\n\n 1. Find a volunteer to rewrite it in one of the languages that we\n know the platforms our current users use already support, which\n means either C (not a good match), POSIX shell (not the best\n match), or Perl.\n\n 2. Promote Ruby to the first-class citizen status, which involves\n making sure people on platforms that matter do not have problem\n adding dependency on it (I am primarily worried about MinGW\n folks), and also making sure core developers do not mind\n reviewing code written in it.\n\nAs long as we can get as high quality reviews on changes written in\nRuby as we do for the current codebase, it is OK to go route #2, and\nthat may hopefully happen in the longer term as and there will be\nsome people, among competent Ruby programmers, who have understood\nhow the pieces of entire Git are designed to fit together by the\ntime it happens.\n\nI however do not know how much extra burden it would place to add\ndependencies to platform folks, so obviously the safer approach is 1\nat least in the immediate future. My understanding is that msysgit\nfolks are already having trouble with Python, and we do not want to\ngo route #2 at least for now. Having to ship a variant of Git with\nNO_PYTHON is already bad enough. And that is why the option 1 above\ndoes not list Python as a possible candidate.\n\n\nOn contrib/:\n\nBack when Git was very young, it made sense to bundle third-party\ntools in our tree's \"contrib/\" section to give them visibility and\nusers convenience. Now Git ecosystem has grown to have many users\nwho know Git and who do not necessarily come to this list, and with\neasy-to-use hosting sites where anybody can publish their ware and\ncollaborate with their contributors, \"giving more visibility\" angle\nof contrib/ has outlived its usefulness. When there are multiple\nthird-party tools that address similar needs, there is not much\npoint picking one at random and ship it over others, and shipping\nall of them is simply crazy. In an ecosystem with flourishing\nthird-party add-ons, their products should and will stand on their\nown.\n\nAs the maintainer, I've been thinking about closing contrib/ area\nfor new stuff, and shrinking existing ones, either by moving stuff\nthat are only useful within the context of Git to main part of the\ntree (e.g. \"contrib/workdir\" may move to a new directory \"addons/\",\nsome of remote-helpers in contrib/ may move to \"remote-helpers/\",\netc.), and removing others from contrib/, for this reason. Of\ncourse, interested folks can take the last version of the removed\nones and continue improving them as standalone projects.\n\nAnd that is why the list of possible actions in the previous part\ndoes not have \"3. Keep it in contrib/ forever\" as an option.\n\nThat is all for the \"administrative comments\" as the maintainer.\n\n\nThe rest is just a personal opinion.\n\nIf we were looking at a compelling and sizeable web application that\ndepends on Rails, it is very likely that it would not make much\nsense to rewrite it in other languages only to avoid a new language\ndependency on Ruby.\n\nBut \"related\" is \"read and extract some info out of text files,\nspawn a 'blame' (or two) based on that info, read to collect further\ninfo and summarize\", for which Ruby does not especially shine\ncompared to Perl, which is the language we already depend on.\nBecause of this, I am moderately reluctant to add Ruby dependency\nonly for this script. Unless I know people who regularly give us\nhigh quality reviews, and those who support various platforms, are\nfine with it, that is.\n\nIn the shorter term (read: up to 2.0), I am inclined to vote that we\nshould go route #1 (i.e. rewrite in Perl once the design settles).\n\nMy \"personal opinion\" above of course assumes that everybody agrees\nthat \"related\" is a good addition. If not, there is \"3. not add it\nto contrib/ and leave it as an out-of-tree third-party project\"\noption.\n"},{"id":"219430","messageId":"alpine.DEB.2.02.1306041954360.2900@nftneq.ynat.uz","threadId":"34030","inReplyTo":"7va9n52zjc.fsf@alter.siamese.dyndns.org","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"David Lang","fromEmail":"david@lang.hm","sentAt":"2013-06-05T03:02:15Z","receivedAt":"2013-06-05T03:02:15Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Tue, 4 Jun 2013, Junio C Hamano wrote:\n\n> Junio C Hamano writes:\n>\n>\n> On Ruby:\n>\n> Assuming \"related\" is a good idea, to make it as the proper part of\n> the system out of contrib/ when its design review phase is finished,\n> one of these things has to happen:\n>\n> 1. Find a volunteer to rewrite it in one of the languages that we\n> know the platforms our current users use already support, which\n> means either C (not a good match), POSIX shell (not the best\n> match), or Perl.\n>\n> 2. Promote Ruby to the first-class citizen status, which involves\n> making sure people on platforms that matter do not have problem\n> adding dependency on it (I am primarily worried about MinGW\n> folks), and also making sure core developers do not mind\n> reviewing code written in it.\n>\n> As long as we can get as high quality reviews on changes written in\n> Ruby as we do for the current codebase, it is OK to go route #2, and\n> that may hopefully happen in the longer term as and there will be\n> some people, among competent Ruby programmers, who have understood\n> how the pieces of entire Git are designed to fit together by the\n> time it happens.\n>\n> I however do not know how much extra burden it would place to add\n> dependencies to platform folks, so obviously the safer approach is 1\n> at least in the immediate future. My understanding is that msysgit\n> folks are already having trouble with Python, and we do not want to\n> go route #2 at least for now. Having to ship a variant of Git with\n> NO_PYTHON is already bad enough. And that is why the option 1 above\n> does not list Python as a possible candidate.\n\nAs someone who builds minimalist builds (firewalls, openwrt, raspberry pi, etc), \nhaving to pull in a full ruby install to get git installed would not be \nsomething I'd like to see.\n\nYes, openwrt (and I) can build our own version, but that's a pain. I tend to \nbuild my tight systems from Debian and it's nice to be able to use stock \npackages.\n\nI tend to use git for sysadmin type functions as much as for development, so \nit's very useful even on such small and slow platforms.\n\n> On contrib/:\n>\n> Back when Git was very young, it made sense to bundle third-party\n> tools in our tree's \"contrib/\" section to give them visibility and\n> users convenience. Now Git ecosystem has grown to have many users\n> who know Git and who do not necessarily come to this list, and with\n> easy-to-use hosting sites where anybody can publish their ware and\n> collaborate with their contributors, \"giving more visibility\" angle\n> of contrib/ has outlived its usefulness. When there are multiple\n> third-party tools that address similar needs, there is not much\n> point picking one at random and ship it over others, and shipping\n> all of them is simply crazy. In an ecosystem with flourishing\n> third-party add-ons, their products should and will stand on their\n> own.\n>\n> As the maintainer, I've been thinking about closing contrib/ area\n> for new stuff, and shrinking existing ones, either by moving stuff\n> that are only useful within the context of Git to main part of the\n> tree (e.g. \"contrib/workdir\" may move to a new directory \"addons/\",\n> some of remote-helpers in contrib/ may move to \"remote-helpers/\",\n> etc.), and removing others from contrib/, for this reason. Of\n> course, interested folks can take the last version of the removed\n> ones and continue improving them as standalone projects.\n\nIf you can, you should leave just enough of a stub in place so that people who \ndon't know about the change and try to run the stuff that used to be in contrib/ \nget a message pointing them to the new home.\n\nDavid Lang\n"},{"id":"219431","messageId":"51AEBAEF.6090402@alum.mit.edu","threadId":"34030","inReplyTo":"7va9n52zjc.fsf@alter.siamese.dyndns.org","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2013-06-05T04:13:35Z","receivedAt":"2013-06-05T04:13:35Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 06/05/2013 02:04 AM, Junio C Hamano wrote:\n> Junio C Hamano writes:\n> \n>> * fc/contrib-related (2013-06-03) 4 commits\n>> - contrib: related: parse committish like format-patch\n>> - contrib: related: add option to parse from committish\n>> - contrib: related: add support for multiple patches\n>> - Add new git-related helper to contrib\n>>\n>> Waiting for the design review to settle.\n> \n> As people may have seen in the discussion on the earlier iteration,\n> something like this (there may be a room for bikeshedding the name,\n> though) that takes either a range of changes or set of patches and\n> finds people who may be able to review them may be a good addition\n> to our official toolchest.\n> \n> http://thread.gmane.org/gmane.comp.version-control.git/221728/focus=221796\n> \n> Right now, \"related\" is in contrib/ primarily because its design\n> review phase is not yet finished and because it is in Ruby, which\n> the rest of the system does not depend on.\n> \n> I have some administrative comments on two issues as the maintainer.\n> \n> * Do we want to add Ruby dependency?\n> * Do we want to keep expanding contrib/?\n> \n> These have been triggered by \"related\", but the comments in this\n> message are not limited to the specific topic (e.g. you can read it\n> with s/Ruby//).\n> \n> \n> On Ruby:\n> [...]\n\nI don't have an opinion on allowing Ruby into the core, except to say\nthat I would personally prefer *some* alternative that is more capable\nthan shell and more modern and self-consistent than Perl. Python, Ruby,\nand Lua would seem to be the obvious candidates, with the latter being\neasiest for packagers.\n\n> On contrib/:\n> \n> Back when Git was very young, it made sense to bundle third-party\n> tools in our tree's \"contrib/\" section to give them visibility and\n> users convenience. Now Git ecosystem has grown to have many users\n> who know Git and who do not necessarily come to this list, and with\n> easy-to-use hosting sites where anybody can publish their ware and\n> collaborate with their contributors, \"giving more visibility\" angle\n> of contrib/ has outlived its usefulness. When there are multiple\n> third-party tools that address similar needs, there is not much\n> point picking one at random and ship it over others, and shipping\n> all of them is simply crazy. In an ecosystem with flourishing\n> third-party add-ons, their products should and will stand on their\n> own.\n\nFor completeness, let me point out two other small advantages of contrib:\n\n* a tool in contrib can assume that it is being bundled with the\ncorresponding version of Git, and therefore doesn't necessarily have to\ngo to the effort of supporting older versions of Git.\n\n* at the source-code level, a tool in contrib can take advantage of some\nof the Git build/test infrastructure, though I don't know whether they\ncurrently do.\n\n\nBut my main point is that I think it would be easier to phase out\ncontrib/ if there were a good alternate way of providing visibility to\n\"satellite\" projects. The relevant Git wiki page [1] is the most likely\ncandidate, but it is a bit overwhelming due to its size, it has fallen\ninto disuse because it was broken for such a long time, and it is not\nprominently linked to from git-scm.com. If it were curated a bit, it\nwould help users find the best ancillary tools quickly. Perhaps ranking\nthe tools based on the results of the Git user surveys would help bring\nthe most popular to the top of each category.\n\nMichael\n\n[1] https://git.wiki.kernel.org/index.php/Interfaces,_frontends,_and_tools\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"219438","messageId":"51AEE1C3.9020507@viscovery.net","threadId":"34030","inReplyTo":"7vtxld30f2.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Jun 2013, #02; Tue, 4)","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2013-06-05T06:59:15Z","receivedAt":"2013-06-05T06:59:15Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 6/5/2013 1:45, schrieb Junio C Hamano:\n> * jk/test-exit-code-by-signal (2013-06-02) 1 commit\n> (merged to 'next' on 2013-06-03 at 25af892)\n> + t0005: test git exit code from signal death\n> \n> Will merge to 'master'.\n\nI haven't gotten around to run this new test on Windows. I've reason to\nbelieve that it won't pass as is. Please don't let it graduate, yet.\n\n-- Hannes\n"},{"id":"219440","messageId":"20130605071206.GC14427@sigill.intra.peff.net","threadId":"34030","inReplyTo":"51AEE1C3.9020507@viscovery.net","subject":"Re: What's cooking in git.git (Jun 2013, #02; Tue, 4)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-06-05T07:12:06Z","receivedAt":"2013-06-05T07:12:06Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Jun 05, 2013 at 08:59:15AM +0200, Johannes Sixt wrote:\n\n> Am 6/5/2013 1:45, schrieb Junio C Hamano:\n> > * jk/test-exit-code-by-signal (2013-06-02) 1 commit\n> > (merged to 'next' on 2013-06-03 at 25af892)\n> > + t0005: test git exit code from signal death\n> > \n> > Will merge to 'master'.\n> \n> I haven't gotten around to run this new test on Windows. I've reason to\n> believe that it won't pass as is. Please don't let it graduate, yet.\n\nYeah, I sort of assumed that we would need to check for either \"3\" or\n\"131\" on Windows, but I wasn't sure which. I don't think there is any\nrush on it.\n\n-Peff\n"},{"id":"219452","messageId":"CAMP44s2VToROGXTz57GgT1sLuZDRhx3wpQMwQDTi-c7migTgrA@mail.gmail.com","threadId":"34030","inReplyTo":"alpine.DEB.2.02.1306041954360.2900@nftneq.ynat.uz","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-05T14:30:55Z","receivedAt":"2013-06-05T14:30:55Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, Jun 4, 2013 at 10:02 PM, David Lang wrote:\n> On Tue, 4 Jun 2013, Junio C Hamano wrote:\n>\n>> Junio C Hamano writes:\n>>\n>>\n>> On Ruby:\n>>\n>> Assuming \"related\" is a good idea, to make it as the proper part of\n>> the system out of contrib/ when its design review phase is finished,\n>> one of these things has to happen:\n>>\n>> 1. Find a volunteer to rewrite it in one of the languages that we\n>> know the platforms our current users use already support, which\n>> means either C (not a good match), POSIX shell (not the best\n>> match), or Perl.\n>>\n>> 2. Promote Ruby to the first-class citizen status, which involves\n>> making sure people on platforms that matter do not have problem\n>> adding dependency on it (I am primarily worried about MinGW\n>> folks), and also making sure core developers do not mind\n>> reviewing code written in it.\n>>\n>> As long as we can get as high quality reviews on changes written in\n>> Ruby as we do for the current codebase, it is OK to go route #2, and\n>> that may hopefully happen in the longer term as and there will be\n>> some people, among competent Ruby programmers, who have understood\n>> how the pieces of entire Git are designed to fit together by the\n>> time it happens.\n>>\n>> I however do not know how much extra burden it would place to add\n>> dependencies to platform folks, so obviously the safer approach is 1\n>> at least in the immediate future. My understanding is that msysgit\n>> folks are already having trouble with Python, and we do not want to\n>> go route #2 at least for now. Having to ship a variant of Git with\n>> NO_PYTHON is already bad enough. And that is why the option 1 above\n>> does not list Python as a possible candidate.\n>\n>\n> As someone who builds minimalist builds (firewalls, openwrt, raspberry pi,\n> etc), having to pull in a full ruby install to get git installed would not\n> be something I'd like to see.\n\nYou wouldn't _have_ to, just like you don't _have_ to install Python right now.\n\n-- \nFelipe Contreras\n"},{"id":"219453","messageId":"CAMP44s012ccmaArrTbfy_xNrqbnOjVGTnY+po9cE8JGh_U72Gg@mail.gmail.com","threadId":"34030","inReplyTo":"7va9n52zjc.fsf@alter.siamese.dyndns.org","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-05T14:45:52Z","receivedAt":"2013-06-05T14:45:52Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, Jun 4, 2013 at 7:04 PM, Junio C Hamano wrote:\n> Junio C Hamano writes:\n\n> I however do not know how much extra burden it would place to add\n> dependencies to platform folks, so obviously the safer approach is 1\n> at least in the immediate future. My understanding is that msysgit\n> folks are already having trouble with Python, and we do not want to\n> go route #2 at least for now. Having to ship a variant of Git with\n> NO_PYTHON is already bad enough. And that is why the option 1 above\n> does not list Python as a possible candidate.\n\nThis rests on the assumption that Ruby would be as difficult to\ndistribute as Python, which might not be the case.\n\n> As the maintainer, I've been thinking about closing contrib/ area\n> for new stuff, and shrinking existing ones, either by moving stuff\n> that are only useful within the context of Git to main part of the\n> tree (e.g. \"contrib/workdir\" may move to a new directory \"addons/\",\n> some of remote-helpers in contrib/ may move to \"remote-helpers/\",\n> etc.), and removing others from contrib/, for this reason. Of\n> course, interested folks can take the last version of the removed\n> ones and continue improving them as standalone projects.\n\nThis does make sense, however, I do think some parts of Git might be\nmore maintainable if they have their own Makefile (e.g. bash\ncompletion), where it's clear where they should be installed by\ndefault.\n\nEither way, the user might want to do 'install-all' or\n'install-addons', to install all these things, and I think a good rule\nof thumb is that if we don't want 'install-all' to install certain\nscript (eventually), then that script probably doesn't belong in\n'contrib' (or anywhere in Git).\n\n> The rest is just a personal opinion.\n>\n> If we were looking at a compelling and sizeable web application that\n> depends on Rails, it is very likely that it would not make much\n> sense to rewrite it in other languages only to avoid a new language\n> dependency on Ruby.\n>\n> But \"related\" is \"read and extract some info out of text files,\n> spawn a 'blame' (or two) based on that info, read to collect further\n> info and summarize\", for which Ruby does not especially shine\n> compared to Perl, which is the language we already depend on.\n> Because of this, I am moderately reluctant to add Ruby dependency\n> only for this script. Unless I know people who regularly give us\n> high quality reviews, and those who support various platforms, are\n> fine with it, that is.\n>\n> In the shorter term (read: up to 2.0), I am inclined to vote that we\n> should go route #1 (i.e. rewrite in Perl once the design settles).\n\nThat might make sense for the shorter term, but in longer term I see\nPerl as declining in favor of other languages. It's only a matter of\ntime before Ruby surpasses Perl in popularity, and soon enough new\ncontributors to the Git project will have problems trying to improve\nGit because parts of it are written in a language they are not\nfamiliar with, and have trouble learning (isn't that already\nhappening?).\n\nThe Ruby vs. Python is another question altogether, I could go into\ndetail about why I think Ruby is a better choice, but my point right\nnow is that Perl is not a good choice for the future.\n\n-- \nFelipe Contreras\n"},{"id":"219464","messageId":"7v1u8g3160.fsf@alter.siamese.dyndns.org","threadId":"34030","inReplyTo":"51AEBAEF.6090402@alum.mit.edu","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-06-05T17:41:43Z","receivedAt":"2013-06-05T17:41:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael Haggerty writes:\n\n> For completeness, let me point out two other small advantages of contrib:\n>\n> * a tool in contrib can assume that it is being bundled with the\n> corresponding version of Git, and therefore doesn't necessarily have to\n> go to the effort of supporting older versions of Git.\n\nIt is true that in-tree stuff can go in-sync with the rest, but I\nthink that is irrelevant, as we are discussing a tool in contrib/;\nif it is part of the core, it deserves that benefit over tools\ndeveloped out-of-tree (that need to worry about utilizing new\nfeatures after a version check). After moving tools that we want to\nkeep as a part of core out of contrib/, they will still be in-sync.\n\nFor those that alternative third-party designs and implementations\nfor solving the non-core problems they try to solve (e.g. ciabot,\ncontinuous, blameview) can exist, it would be better for the\necosystem of they compete with their alternatives on the same\nground.\n\n> But my main point is that I think it would be easier to phase out\n> contrib/ if there were a good alternate way of providing visibility to\n> \"satellite\" projects. The relevant Git wiki page [1] is the most likely\n> candidate, but it is a bit overwhelming due to its size, it has fallen\n> into disuse because it was broken for such a long time, and it is not\n> prominently linked to from git-scm.com. If it were curated a bit, it\n> would help users find the best ancillary tools quickly. Perhaps ranking\n> the tools based on the results of the Git user surveys would help bring\n> the most popular to the top of each category.\n\nThat is a very good point.\n\n>\n> Michael\n>\n> [1] https://git.wiki.kernel.org/index.php/Interfaces,_frontends,_and_tools\n"},{"id":"219481","messageId":"51B02D81.3000700@viscovery.net","threadId":"34030","inReplyTo":"20130605071206.GC14427@sigill.intra.peff.net","subject":"[PATCH] t0005: skip signal death exit code test on Windows","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2013-06-06T06:34:41Z","receivedAt":"2013-06-06T06:34:41Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"From: Johannes Sixt \n\nThe test case depends on that test-sigchain can commit suicide by a call\nto raise(SIGTERM) in a way that run-command.c::wait_or_whine() can detect\nas death through a signal. There are no POSIX signals on Windows, and a\nsufficiently close emulation is not available in the Microsoft C runtime\n(and probably not even possible).\n\nThe particular deficiency is that when a signal is raise()d whose SIG_DFL\naction will cause process death (SIGTERM in this case), the\nimplementation of raise() just calls exit(3).\n\nWe could check for exit code 3 in addition to 143, but that would miss\nthe point of the test entirely. Hence, just skip it on Windows.\n\nSigned-off-by: Johannes Sixt \n---\n t/t0005-signals.sh | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/t/t0005-signals.sh b/t/t0005-signals.sh\nindex ad9e604..981437b 100755\n--- a/t/t0005-signals.sh\n+++ b/t/t0005-signals.sh\n@@ -20,7 +20,7 @@ test_expect_success 'sigchain works' '\n \ttest_cmp expect actual\n '\n \n-test_expect_success 'signals are propagated using shell convention' '\n+test_expect_success !MINGW 'signals are propagated using shell convention' '\n \t# we use exec here to avoid any sub-shell interpretation\n \t# of the exit code\n \tgit config alias.sigterm \"!exec test-sigchain\" &&\n-- \n1.8.3.1489.g15123b5\n"},{"id":"219482","messageId":"20130606063754.GA20050@sigill.intra.peff.net","threadId":"34030","inReplyTo":"51B02D81.3000700@viscovery.net","subject":"Re: [PATCH] t0005: skip signal death exit code test on Windows","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-06-06T06:37:54Z","receivedAt":"2013-06-06T06:37:54Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Jun 06, 2013 at 08:34:41AM +0200, Johannes Sixt wrote:\n\n> From: Johannes Sixt \n> \n> The test case depends on that test-sigchain can commit suicide by a call\n> to raise(SIGTERM) in a way that run-command.c::wait_or_whine() can detect\n> as death through a signal. There are no POSIX signals on Windows, and a\n> sufficiently close emulation is not available in the Microsoft C runtime\n> (and probably not even possible).\n> \n> The particular deficiency is that when a signal is raise()d whose SIG_DFL\n> action will cause process death (SIGTERM in this case), the\n> implementation of raise() just calls exit(3).\n> \n> We could check for exit code 3 in addition to 143, but that would miss\n> the point of the test entirely. Hence, just skip it on Windows.\n\nThanks. I wasn't quite clear on how the signal handling worked on\nWindows, but from your description, I agree there is not any point in\nrunning the test at all.\n\nAcked-by: Jeff King \n\n-Peff\n"},{"id":"219483","messageId":"CAMP44s2L4EOG7aEOR8gqXeaHm7SeuPg=GQAWX3PByKKbtTHnwQ@mail.gmail.com","threadId":"34030","inReplyTo":"20130606063754.GA20050@sigill.intra.peff.net","subject":"Re: [PATCH] t0005: skip signal death exit code test on Windows","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-06T06:41:05Z","receivedAt":"2013-06-06T06:41:05Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Jun 6, 2013 at 1:37 AM, Jeff King wrote:\n> On Thu, Jun 06, 2013 at 08:34:41AM +0200, Johannes Sixt wrote:\n>\n>> From: Johannes Sixt \n>>\n>> The test case depends on that test-sigchain can commit suicide by a call\n>> to raise(SIGTERM) in a way that run-command.c::wait_or_whine() can detect\n>> as death through a signal. There are no POSIX signals on Windows, and a\n>> sufficiently close emulation is not available in the Microsoft C runtime\n>> (and probably not even possible).\n>>\n>> The particular deficiency is that when a signal is raise()d whose SIG_DFL\n>> action will cause process death (SIGTERM in this case), the\n>> implementation of raise() just calls exit(3).\n>>\n>> We could check for exit code 3 in addition to 143, but that would miss\n>> the point of the test entirely. Hence, just skip it on Windows.\n>\n> Thanks. I wasn't quite clear on how the signal handling worked on\n> Windows, but from your description, I agree there is not any point in\n> running the test at all.\n\nShouldn't we clarify that Git exit codes only work on UNIX-like\noperating systems?\n\n-- \nFelipe Contreras\n"},{"id":"219484","messageId":"20130606064409.GA20334@sigill.intra.peff.net","threadId":"34030","inReplyTo":"CAMP44s2L4EOG7aEOR8gqXeaHm7SeuPg=GQAWX3PByKKbtTHnwQ@mail.gmail.com","subject":"Re: [PATCH] t0005: skip signal death exit code test on Windows","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-06-06T06:44:09Z","receivedAt":"2013-06-06T06:44:09Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Jun 06, 2013 at 01:41:05AM -0500, Felipe Contreras wrote:\n\n> > Thanks. I wasn't quite clear on how the signal handling worked on\n> > Windows, but from your description, I agree there is not any point in\n> > running the test at all.\n> \n> Shouldn't we clarify that Git exit codes only work on UNIX-like\n> operating systems?\n\nClarify where? My impression is that this issue is well-known in the\nmsys world, and it is a platform issue, not a git issue. If somebody\nwants to write a note somewhere in the git documentation, that's fine\nwith me, but I'm not clear on exactly what it would even say.\n\n-Peff\n"},{"id":"219485","messageId":"CAMP44s0jNoP2bSkkwaxufKVkyG=obHXZwcJPc1CiU4wy9yTjPA@mail.gmail.com","threadId":"34030","inReplyTo":"20130606064409.GA20334@sigill.intra.peff.net","subject":"Re: [PATCH] t0005: skip signal death exit code test on Windows","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-06T06:48:03Z","receivedAt":"2013-06-06T06:48:03Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Jun 6, 2013 at 1:44 AM, Jeff King wrote:\n> On Thu, Jun 06, 2013 at 01:41:05AM -0500, Felipe Contreras wrote:\n>\n>> > Thanks. I wasn't quite clear on how the signal handling worked on\n>> > Windows, but from your description, I agree there is not any point in\n>> > running the test at all.\n>>\n>> Shouldn't we clarify that Git exit codes only work on UNIX-like\n>> operating systems?\n>\n> Clarify where?\n\nDocumentation/technical/api-run-command.txt\n\n> My impression is that this issue is well-known in the\n> msys world, and it is a platform issue, not a git issue. If somebody\n> wants to write a note somewhere in the git documentation, that's fine\n> with me, but I'm not clear on exactly what it would even say.\n\nThat the exit code is not the same in Windows (not msys).\n\n-- \nFelipe Contreras\n"},{"id":"219486","messageId":"CANgJU+W1BLOB_TuMa_zRHtCW-8Ge8nu_kK=5qu2xDY=Km_kk4A@mail.gmail.com","threadId":"34030","inReplyTo":"CAMP44s012ccmaArrTbfy_xNrqbnOjVGTnY+po9cE8JGh_U72Gg@mail.gmail.com","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"demerphq","fromEmail":"demerphq@gmail.com","sentAt":"2013-06-06T07:26:02Z","receivedAt":"2013-06-06T07:26:02Z","isPatch":false,"sender":{"key":"demerphq@gmail.com","avatar":null},"body":"On 5 June 2013 16:45, Felipe Contreras wrote:\n> On Tue, Jun 4, 2013 at 7:04 PM, Junio C Hamano wrote:\n> That might make sense for the shorter term, but in longer term I see\n> Perl as declining in favor of other languages. It's only a matter of\n> time before Ruby surpasses Perl in popularity, and soon enough new\n> contributors to the Git project will have problems trying to improve\n> Git because parts of it are written in a language they are not\n> familiar with, and have trouble learning (isn't that already\n> happening?).\n>\n> The Ruby vs. Python is another question altogether, I could go into\n> detail about why I think Ruby is a better choice, but my point right\n> now is that Perl is not a good choice for the future.\n\nGood thing you are being objective and leaving out the Python 3.0\nmess, the long legacy of backwards compatibility in the Perl\ncommunity, the active community behind it, its extensive portability\nsupport, and fail to mention the lack of an equivalent to CPAN. We\nwouldn't want facts to get in the way of a personal bias would we?\n\nJust thought I'd push back on the FUD. People have been saying Perl is\ngoing away for decades...\n\nYves\n"},{"id":"219487","messageId":"CAMP44s3zuDPTApPvnaC0bzqmAUkRRwePZDRL4syB=tM3d6eiBA@mail.gmail.com","threadId":"34030","inReplyTo":"CANgJU+W1BLOB_TuMa_zRHtCW-8Ge8nu_kK=5qu2xDY=Km_kk4A@mail.gmail.com","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-06T07:46:59Z","receivedAt":"2013-06-06T07:46:59Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Jun 6, 2013 at 2:26 AM, demerphq wrote:\n> On 5 June 2013 16:45, Felipe Contreras wrote:\n>> On Tue, Jun 4, 2013 at 7:04 PM, Junio C Hamano wrote:\n>> That might make sense for the shorter term, but in longer term I see\n>> Perl as declining in favor of other languages. It's only a matter of\n>> time before Ruby surpasses Perl in popularity, and soon enough new\n>> contributors to the Git project will have problems trying to improve\n>> Git because parts of it are written in a language they are not\n>> familiar with, and have trouble learning (isn't that already\n>> happening?).\n>>\n>> The Ruby vs. Python is another question altogether, I could go into\n>> detail about why I think Ruby is a better choice, but my point right\n>> now is that Perl is not a good choice for the future.\n>\n> Good thing you are being objective and leaving out the Python 3.0\n> mess, the long legacy of backwards compatibility in the Perl\n> community, the active community behind it, its extensive portability\n> support, and fail to mention the lack of an equivalent to CPAN. We\n> wouldn't want facts to get in the way of a personal bias would we?\n\nNone of that has anything to do with Perl's popularity.\n\n> Just thought I'd push back on the FUD. People have been saying Perl is\n> going away for decades...\n\nPerl has been going away for the last decade [1], and will continue to\ngo away. Perl is going away, and that an undeniable fact, and if you\nare not interested in discussing on the basis of reality, I'm not\ninterested in discussing with you.\n\n[1] http://www.tiobe.com/content/paperinfo/tpci/images/tpci_trends.png\n\n-- \nFelipe Contreras\n"},{"id":"219503","messageId":"m3d2rz5svw.fsf@barry_fishman.acm.org","threadId":"34030","inReplyTo":"CAMP44s3zuDPTApPvnaC0bzqmAUkRRwePZDRL4syB=tM3d6eiBA@mail.gmail.com","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Barry Fishman","fromEmail":"barry_fishman@acm.org","sentAt":"2013-06-06T12:24:35Z","receivedAt":"2013-06-06T12:24:35Z","isPatch":false,"sender":{"key":"barry_fishman@acm.org","avatar":"https://gravatar.com/avatar/4844db8f23c87ef393afd071604bce66ae3f30c5ddd3e9002eced18b7884fa46?d=mp&s=160"},"body":"\nOn 2013-06-06 03:46:59 EDT, Felipe Contreras wrote:\n> On Thu, Jun 6, 2013 at 2:26 AM, demerphq wrote:\n>> Good thing you are being objective and leaving out the Python 3.0\n>> mess, the long legacy of backwards compatibility in the Perl\n>> community, the active community behind it, its extensive portability\n>> support, and fail to mention the lack of an equivalent to CPAN. We\n>> wouldn't want facts to get in the way of a personal bias would we?\n>\n> None of that has anything to do with Perl's popularity.\n>\n>> Just thought I'd push back on the FUD. People have been saying Perl is\n>> going away for decades...\n>\n> Perl has been going away for the last decade [1], and will continue to\n> go away. Perl is going away, and that an undeniable fact, and if you\n> are not interested in discussing on the basis of reality, I'm not\n> interested in discussing with you.\n>\n> [1] http://www.tiobe.com/content/paperinfo/tpci/images/tpci_trends.png\n\nI don't think the usefulness of a language should be judged by hits on a\nweb site.\n\nPersonally I would like the Git client to be packaged with as few\ndependencies as possible. Right now that seems to require Shell, Sed,\nAwk and Perl. The documentation has other requirements, but a prebuild\ntar file is available.\n\nI would have the rest of the distribution be bundled as something\nlike \"git-utils\" which could have a subdirectory for each support\nlanguage. Then one could even make available alternative\nimplementations of higher level utilities and people could decide if\nsupport of a specific language was useful to them.\n\nMost such extension code is simple, although more complex than suitable\nfor just Shell/Sed/Awk. People in each language community could provide\ncode which meets the needs of their community, and the Git project\nitself would not need to make (Solomon like) decisions about what\nextension languages to support.\n\n--\nBarry Fishman\n"},{"id":"219504","messageId":"vpq61xr8kpl.fsf@anie.imag.fr","threadId":"34030","inReplyTo":"51AEBAEF.6090402@alum.mit.edu","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-06-06T12:52:54Z","receivedAt":"2013-06-06T12:52:54Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Michael Haggerty writes:\n\n> * at the source-code level, a tool in contrib can take advantage of some\n> of the Git build/test infrastructure, though I don't know whether they\n> currently do.\n\nThey do not do much AFAICT. For example, contrib/subtree/t/Makefile is\nessentially copy-pasted from Git's equivalent.\n\nBut they can do to some extend, for example \"make install\" in\ncontrib/mw-to-git/ re-uses Git's Makefile to hardcode the PERL_PATH in\nthe file, find Git's exec-path & so. I'd love to be able to use\nDocumentation/Makefile and t/Makefile too for external programs meant to\nbe used as a Git command.\n\nThat does not strictly imply that these commands be maintained within\ngit.git, as we could imagine:\n\n* Ask the user to build external programs with\n\n make GIT_ROOT=where/git/lives/\n\n* or, ask users to checkout the external program as a subdirectory of\n git.git to build it (for example, clang's build installation ask you\n to put clang as a subdirectory of LLVM's tree).\n\n> But my main point is that I think it would be easier to phase out\n> contrib/ if there were a good alternate way of providing visibility to\n> \"satellite\" projects. [...] Perhaps ranking\n> the tools based on the results of the Git user surveys would help bring\n> the most popular to the top of each category.\n\nI think this is the most important point. A good example would be\ngit-multimail: for now, the shell version in contrib/ is somehow\nconsidered as the official hook to send emails, just because it is in\ncontrib, while git-multimail is clearly superior (unless you don't have\na python interpreter on your server).\n\n\nI also see contrib/ as a \"safe\" place to live, in that the likeliness\nfor the project to be abandonned is rather small. Especially for small\npieces of code, it's easy to create a repo and throw the code somewhere\non GitHub, but maintaining it is harder. Take again the example of\npost-receive-email, the code was originally written by Andy Parkins, but\nthe community took over it (Andy's last commit on the script was in\n2008). I'm not sure this would have been so easy with a script hosted on\nan arbitrary repo.\n\n\nI'm not opposed to Junio's proposal to restrict contrib/ (although a bit\nreluctant), but I think this should be done with care, at least to give\npotential users a way to chose which tool to use (really, nobody want to\ngo use https://git.wiki.kernel.org/index.php/InterfacesFrontendsAndTools\nto pick the right tool. It's a great list, but not a guide).\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"219505","messageId":"CAMP44s0M5tsN+zYoa_HC+8SLqyvDUBi_wuiOGyQWo0XWbWXC-A@mail.gmail.com","threadId":"34030","inReplyTo":"m3d2rz5svw.fsf@barry_fishman.acm.org","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-06T13:01:48Z","receivedAt":"2013-06-06T13:01:48Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Jun 6, 2013 at 7:24 AM, Barry Fishman wrote:\n>\n> On 2013-06-06 03:46:59 EDT, Felipe Contreras wrote:\n>> On Thu, Jun 6, 2013 at 2:26 AM, demerphq wrote:\n>>> Good thing you are being objective and leaving out the Python 3.0\n>>> mess, the long legacy of backwards compatibility in the Perl\n>>> community, the active community behind it, its extensive portability\n>>> support, and fail to mention the lack of an equivalent to CPAN. We\n>>> wouldn't want facts to get in the way of a personal bias would we?\n>>\n>> None of that has anything to do with Perl's popularity.\n>>\n>>> Just thought I'd push back on the FUD. People have been saying Perl is\n>>> going away for decades...\n>>\n>> Perl has been going away for the last decade [1], and will continue to\n>> go away. Perl is going away, and that an undeniable fact, and if you\n>> are not interested in discussing on the basis of reality, I'm not\n>> interested in discussing with you.\n>>\n>> [1] http://www.tiobe.com/content/paperinfo/tpci/images/tpci_trends.png\n>\n> I don't think the usefulness of a language should be judged by hits on a\n> web site.\n\nNobody is judging the usefulness of a language, I have plenty of\narguments for that, but this is about popularity.\n\n> Personally I would like the Git client to be packaged with as few\n> dependencies as possible. Right now that seems to require Shell, Sed,\n> Awk and Perl. The documentation has other requirements, but a prebuild\n> tar file is available.\n\nI would be perfectly fine with replacing shell, sed, awk and perl with\nruby. But that's not what you are arguing, is it?\n\n-- \nFelipe Contreras\n"},{"id":"219506","messageId":"m3ip1rnygk.fsf@barry_fishman.acm.org","threadId":"34030","inReplyTo":"CAMP44s0M5tsN+zYoa_HC+8SLqyvDUBi_wuiOGyQWo0XWbWXC-A@mail.gmail.com","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Barry Fishman","fromEmail":"barry_fishman@acm.org","sentAt":"2013-06-06T13:46:51Z","receivedAt":"2013-06-06T13:46:51Z","isPatch":false,"sender":{"key":"barry_fishman@acm.org","avatar":"https://gravatar.com/avatar/4844db8f23c87ef393afd071604bce66ae3f30c5ddd3e9002eced18b7884fa46?d=mp&s=160"},"body":"\nOn 2013-06-06 09:01:48 EDT, Felipe Contreras wrote:\n> On Thu, Jun 6, 2013 at 7:24 AM, Barry Fishman wrote:\n>>\n>> On 2013-06-06 03:46:59 EDT, Felipe Contreras wrote:\n>>> On Thu, Jun 6, 2013 at 2:26 AM, demerphq wrote:\n>>>> Good thing you are being objective and leaving out the Python 3.0\n>>>> mess, the long legacy of backwards compatibility in the Perl\n>>>> community, the active community behind it, its extensive portability\n>>>> support, and fail to mention the lack of an equivalent to CPAN. We\n>>>> wouldn't want facts to get in the way of a personal bias would we?\n>>>\n>>> None of that has anything to do with Perl's popularity.\n>>>\n>>>> Just thought I'd push back on the FUD. People have been saying Perl is\n>>>> going away for decades...\n>>>\n>>> Perl has been going away for the last decade [1], and will continue to\n>>> go away. Perl is going away, and that an undeniable fact, and if you\n>>> are not interested in discussing on the basis of reality, I'm not\n>>> interested in discussing with you.\n>>>\n>>> [1] http://www.tiobe.com/content/paperinfo/tpci/images/tpci_trends.png\n>>\n>> I don't think the usefulness of a language should be judged by hits on a\n>> web site.\n>\n> Nobody is judging the usefulness of a language, I have plenty of\n> arguments for that, but this is about popularity.\n\nI used \"usefulness\" in its general vague sense. It is useful to be popular,\nI don't make choices solely on that or I would be writing everything in\nJava.\n\n>> Personally I would like the Git client to be packaged with as few\n>> dependencies as possible. Right now that seems to require Shell, Sed,\n>> Awk and Perl. The documentation has other requirements, but a prebuild\n>> tar file is available.\n>\n> I would be perfectly fine with replacing shell, sed, awk and perl with\n> ruby. But that's not what you are arguing, is it?\n\nI'm talking about porcelain code and not core functionality which should\nbe left in C. I'm saying that you should be free to provide Ruby\nimplementations of all such superstructure. And the same can be done by\n(but not required by) the Perl, Python, Tcl and even C, Haskel, Guile\nand whatever communities. Most such higher level code is fairly\ntrivial, and if the file names are kept the same, the same test\nprocedures could be run.\n\nI don't think the cost of duplication of code functionality is that\nsignificant, since it would bring new people to the project. After all\nthis is a free project and not a commerical venture. It certainly helps\nporting to new platforms. Separate language communities would be\nmaintaining their own contributions, with their own experimental\ndirectories.\n\nTranslating the same functionality to multiple languages requires\ncareful reading which can help identify some hidden bugs.\n\n-- \nBarry Fishman\n"},{"id":"219507","messageId":"CAMP44s0baW0muNzZb1yjDXiS=y3_R5LhzWcqEsPzNZizETwACQ@mail.gmail.com","threadId":"34030","inReplyTo":"m3ip1rnygk.fsf@barry_fishman.acm.org","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-06T14:09:21Z","receivedAt":"2013-06-06T14:09:21Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Jun 6, 2013 at 8:46 AM, Barry Fishman wrote:\n>\n> On 2013-06-06 09:01:48 EDT, Felipe Contreras wrote:\n\n>> Nobody is judging the usefulness of a language, I have plenty of\n>> arguments for that, but this is about popularity.\n>\n> I used \"usefulness\" in its general vague sense. It is useful to be popular,\n> I don't make choices solely on that or I would be writing everything in\n> Java.\n\nStraw man.\n\n>>> Personally I would like the Git client to be packaged with as few\n>>> dependencies as possible. Right now that seems to require Shell, Sed,\n>>> Awk and Perl. The documentation has other requirements, but a prebuild\n>>> tar file is available.\n>>\n>> I would be perfectly fine with replacing shell, sed, awk and perl with\n>> ruby. But that's not what you are arguing, is it?\n\nI don't know what you are saying, but it clearly has nothing to do\nwith the point.\n\nPerl is declining, and it would be wise to use another language instead of it.\n\n-- \nFelipe Contreras\n"},{"id":"219509","messageId":"m3txlbe1ym.fsf@barry_fishman.acm.org","threadId":"34030","inReplyTo":"CAMP44s0baW0muNzZb1yjDXiS=y3_R5LhzWcqEsPzNZizETwACQ@mail.gmail.com","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Barry Fishman","fromEmail":"barry_fishman@acm.org","sentAt":"2013-06-06T14:41:21Z","receivedAt":"2013-06-06T14:41:21Z","isPatch":false,"sender":{"key":"barry_fishman@acm.org","avatar":"https://gravatar.com/avatar/4844db8f23c87ef393afd071604bce66ae3f30c5ddd3e9002eced18b7884fa46?d=mp&s=160"},"body":"On 2013-06-06 10:09:21 EDT, Felipe Contreras wrote:\n> I don't know what you are saying, but it clearly has nothing to do\n> with the point.\n>\n> Perl is declining, and it would be wise to use another language\n> instead of it.\n\nYou want a simple statement. I don't particulary like Perl, but it has\nworked well for the project.\n\nIf you have a better solution, then write all the code to replace it,\nand demonstrate with a significant number of active users that your\nsolution works out better in practice.\n\nWasn't that how Git started?\n\n-- \nBarry Fishman\n"},{"id":"219511","messageId":"rmivc5rp9w2.fsf@fnord.ir.bbn.com","threadId":"34030","inReplyTo":"7va9n52zjc.fsf@alter.siamese.dyndns.org","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Greg Troxel","fromEmail":"gdt@ir.bbn.com","sentAt":"2013-06-06T14:54:37Z","receivedAt":"2013-06-06T14:54:37Z","isPatch":false,"sender":{"key":"gdt@ir.bbn.com","avatar":null},"body":"\nAs one of the people who helps maintain git packages in pkgsrc, my\ninitial reaction is negative to adding a ruby dependency. There are\nseveral not-entirely-related reasons:\n\ngit is a core tool that people use on almost the smallest of boxes,\nperhaps even replacing rcs for managing local config files. On such\nmachines, even perl may be large, but a second scripting language seems\nexcessive. On a NetBSD 6 i386 system, the size of the ruby193-base\nbinary package (as installed) is 25 MB (vs 15 MB for the git base\npackage, which lacks gitk and docs). (Presently, the git base package\ndefaults to requiring python and installing the git_remote_helpers, but\nI think that's a bug.) perl is 54 MB.\n\nI am unclear on how mature/stable ruby is. perl has a good track record\nover the last many years. In particular, no one in pkgsrc has felt the\nneed to support multiple concurrent versions of perl. But there\npresently exists both 1.8 and 1.9 in pkgsrc (and there are multiple\npython verions). So given how critical git is on many systems, I'd ask\nif the ruby requirement is for a stable vs old vs bleeding-edge version,\nand how that is expected to function over the next 5 years. (With perl,\nthe answer seems to be \"any half-way modern version of 5.x is fine, from\nunreasonably old to the latest release\".) By stable, I don't mean that\na particular ruby release works well. I mean the experience of having\ncode that depends on ruby over many years, and whether one can just use\nwhatever ruby happens to be there, or whether it's effort to manage\nhaving an acceptable version.\n\nFrom a packaging viewpoint, dependencies are costly, because they force\nbuild and installation of them before the package can be built. In a\nsource-centric packaging environment (where it's normal to build, rather\nthan only having pre-built packages), the question is if the git package\nneeds ruby, which is a different question than whether something in git\nwhich may be optional needs ruby. So if ruby, or something else, is\nneeded for optional components, it would be really nice if the build\nsystem were such that it was simple (via arguments to configure,\nselecting subdirs, or something functionally similar) to build the main\npart, and then the ruby part as a separate build. Then, it would be\npretty easy to have git-ruby package that has the ruby parts. But if\nthe ruby part isn't considered optional, that won't work. (Note that\nthe usual GNU/Linux approach of split binary packages doesn't really\naddress this, because as I understand it you need the union of the\ndependencies installed to build once, and then tar up the resulting bits\nseparately. So that fixes the problem for people that install binaries,\nbut doesn't help building from source.)\n\ntcl/tk is another dependency, but it seems limited to gitk. pkgsrc has\na separate scmgit-gitk package, which is relatively easy to maintain\nbecause it just involves selecting subdirs to build. So that's an\nexample of a good way to do it, from the source-based packaging\nviewpoint.\n\nFinally, I realize that most people on this list will build git directly\nFrom sources. While that of course has to be smooth, I think great\nweight should be given to how packaging systems use releases and how\nthat impacts packaging effort and the eventual user experience. I would\nguess that over 99% of git users are running binaries built from a\npackaging system.\n\n"},{"id":"219510","messageId":"CAMP44s3RPSo5Uw2yLfGPmepbgFePD3bmj6wh7aQDuKdQL-eLuQ@mail.gmail.com","threadId":"34030","inReplyTo":"m3txlbe1ym.fsf@barry_fishman.acm.org","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-06T15:04:20Z","receivedAt":"2013-06-06T15:04:20Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Jun 6, 2013 at 9:41 AM, Barry Fishman wrote:\n> On 2013-06-06 10:09:21 EDT, Felipe Contreras wrote:\n>> I don't know what you are saying, but it clearly has nothing to do\n>> with the point.\n>>\n>> Perl is declining, and it would be wise to use another language\n>> instead of it.\n>\n> You want a simple statement. I don't particulary like Perl, but it has\n> worked well for the project.\n\nIt would serve it less and less as the years go by.\n\n> If you have a better solution, then write all the code to replace it,\n\nFalse dichotomy fallacy. I don't need to do that.\n\n-- \nFelipe Contreras\n"},{"id":"219512","messageId":"CAMP44s07p0vpS_2cjAjB=QWoZjjPSuAm09xwk4BjAAD+hsJrSw@mail.gmail.com","threadId":"34030","inReplyTo":"rmivc5rp9w2.fsf@fnord.ir.bbn.com","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-06T15:17:25Z","receivedAt":"2013-06-06T15:17:25Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Jun 6, 2013 at 9:54 AM, Greg Troxel wrote:\n>\n> As one of the people who helps maintain git packages in pkgsrc, my\n> initial reaction is negative to adding a ruby dependency. There are\n> several not-entirely-related reasons:\n>\n> git is a core tool that people use on almost the smallest of boxes,\n> perhaps even replacing rcs for managing local config files. On such\n> machines, even perl may be large, but a second scripting language seems\n> excessive.\n\nYou can compile Git without any of them.\n\n> On a NetBSD 6 i386 system, the size of the ruby193-base\n> binary package (as installed) is 25 MB (vs 15 MB for the git base\n> package, which lacks gitk and docs). (Presently, the git base package\n> defaults to requiring python and installing the git_remote_helpers, but\n> I think that's a bug.) perl is 54 MB.\n\nThat's only the default, if the default doesn't suit you, don't use the default.\n\nBesides, that doesn't carry any weight if Perl code is replaced with\nRuby code, or Python.\n\nIt is quite possible to slowly rewrite the Perl scripts, preferably\nmove as much code as possible to C, but the rest to shell, or Ruby.\nFor Ruby, we could maintain both versions at the same time until the\nnew versions are ready, and then the Perl dependency gets deprecated.\nIn this interim time, people that don't want Ruby could use the Perl\nversions. But I think this is overkill. Yes, ideally we wouldn't want\nto depend on both Ruby and Perl, but I think it's OK to do that for a\nwhile, until the Perl scripts are rewritten.\n\nIn the end my point remains unchanged; Perl is declining, so it would\nbe wise for the future to use another scripting language instead.\n\n-- \nFelipe Contreras\n"},{"id":"219515","messageId":"alpine.DEB.2.02.1306060904100.13204@nftneq.ynat.uz","threadId":"34030","inReplyTo":"CAMP44s07p0vpS_2cjAjB=QWoZjjPSuAm09xwk4BjAAD+hsJrSw@mail.gmail.com","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"David Lang","fromEmail":"david@lang.hm","sentAt":"2013-06-06T16:09:20Z","receivedAt":"2013-06-06T16:09:20Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Thu, 6 Jun 2013, Felipe Contreras wrote:\n\n> In the end my point remains unchanged; Perl is declining, so it would\n> be wise for the future to use another scripting language instead.\n\nPerl use may or may not be declining (depending on how you measure it), but are \nyou really willing to take on the task of re-writing everything that's in Perl \ninto another language and force all developers of scripts to learn that other \nlanguage? what's the ROI of this?\n\nPerl isn't going to disappear any time soon. What makes you think that whatever \nlanguage you pick to replace Perl is going to be more stable than Perl is?\n\nand, like the parent poster, by 'stable' I mean from the compatibility point of \nview.\n\nWhat are the odds that the 'newer' language that you pick is going to pull a \n\"python 3\" on you?\n\nThere have been a very large number of scripting languages show up, make a lot \nof press, and then fade in favor of other languages while Perl has continued. \nIt's not the sexy languange nowdays, but it's there, reliable, and used so \nheavily that there's really no chance of it dissapearing in the forseable \nfuture.\n\nDavid Lang\n"},{"id":"219513","messageId":"alpine.DEB.1.00.1306061818191.28957@s15462909.onlinehome-server.info","threadId":"34030","inReplyTo":"rmivc5rp9w2.fsf@fnord.ir.bbn.com","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2013-06-06T16:22:48Z","receivedAt":"2013-06-06T16:22:48Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Greg,\n\nOn Thu, 6 Jun 2013, Greg Troxel wrote:\n\n> As one of the people who helps maintain git packages in pkgsrc, my\n> initial reaction is negative to adding a ruby dependency.\n\nMy initial reaction, too. It was hard enough to get Perl included with Git\nfor Windows (because of that pesky Subversion dependency).\n\nAs you can see from the commit history, I was the primary force behind\ntrying to get everything \"core\" in Git away from requiring scripting\nlanguages (I think it is an awesome thing to provide APIs for as many\nlanguages as possible, but a not-so-cool thing to use more than one\nlanguage in the core code). It does not seem that anybody picked up that\ntask when I left, though.\n\nCiao,\nJohannes\n"},{"id":"219516","messageId":"rmisj0vnorm.fsf@fnord.ir.bbn.com","threadId":"34030","inReplyTo":"CAMP44s07p0vpS_2cjAjB=QWoZjjPSuAm09xwk4BjAAD+hsJrSw@mail.gmail.com","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Greg Troxel","fromEmail":"gdt@ir.bbn.com","sentAt":"2013-06-06T17:16:13Z","receivedAt":"2013-06-06T17:16:13Z","isPatch":false,"sender":{"key":"gdt@ir.bbn.com","avatar":null},"body":"\nFelipe Contreras writes:\n\n> On Thu, Jun 6, 2013 at 9:54 AM, Greg Troxel wrote:\n>>\n>> git is a core tool that people use on almost the smallest of boxes,\n>> perhaps even replacing rcs for managing local config files. On such\n>> machines, even perl may be large, but a second scripting language seems\n>> excessive.\n>\n> You can compile Git without any of them.\n\nThat ignores the 99% of people who use packaged versions. The question\nis really \"Should the standared approach for building be to use or not\nuse dependency X?\". Really this should be expressed in the README, and\nit creates expectations for someone who just installs the git package in\nterms of whether pieces of functionality are there. Packagers generally\nshould be reading the README and including required/recommended\ndependencies and not including optional dependencies (in the main\npackage). The information in INSTALL is pretty reasonable, but it\ndoesn't really clearly say \"if you hand someone git built without perl,\nit is { perfectly ok but missing a fringe optional feature | deficient\nbecause \"git add -p\" won't work }. I'm leaning towards the \"deficient\"\ncamp.\n\nSo \"you can compile git without X\" should really translate into \"when\none runs the default build following the instructions, and does not take\naffirmative steps to use X, X should not be used or depended on\". If it\ndoesn't mean that, it doesn't help the packaging/expectations discussion.\n\nIt's of course fine that one can hand-compile a smaller than standard\nbut still useful subset. But that's entirely different from the\ndefinition of normal.\n\n>> On a NetBSD 6 i386 system, the size of the ruby193-base\n>> binary package (as installed) is 25 MB (vs 15 MB for the git base\n>> package, which lacks gitk and docs). (Presently, the git base package\n>> defaults to requiring python and installing the git_remote_helpers, but\n>> I think that's a bug.) perl is 54 MB.\n>\n> That's only the default, if the default doesn't suit you, don't use\n> the default.\n\nIt's not about what I want. It's about making choices that affect other\npeople, and trying to find a plan that will be overall reasonable;\nthat's the essence of stewardship in packaging. Compiling for just\nmyself is far easier.\n\n\n"},{"id":"219517","messageId":"7vy5anyx1w.fsf@alter.siamese.dyndns.org","threadId":"34030","inReplyTo":"20130606064409.GA20334@sigill.intra.peff.net","subject":"Re: [PATCH] t0005: skip signal death exit code test on Windows","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-06-06T17:21:47Z","receivedAt":"2013-06-06T17:21:47Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Thu, Jun 06, 2013 at 01:41:05AM -0500, Felipe Contreras wrote:\n>\n>> > Thanks. I wasn't quite clear on how the signal handling worked on\n>> > Windows, but from your description, I agree there is not any point in\n>> > running the test at all.\n>> \n>> Shouldn't we clarify that Git exit codes only work on UNIX-like\n>> operating systems?\n>\n> Clarify where? My impression is that this issue is well-known in the\n> msys world, and it is a platform issue, not a git issue.\n\nI actually was scratching my head while reading \"the implementation\nof raise() just calls exit(3).\" part, in this:\n\n> The particular deficiency is that when a signal is raise()d whose SIG_DFL\n> action will cause process death (SIGTERM in this case), the\n> implementation of raise() just calls exit(3).\n\nAfter a bit of web searching, it seems to me that this behaviour of\nraise() is in msvcrt, and compat/mingw.c::mingw_raise() just calls\nthat. In other words, \"the implementation of raise()\" is at an even\nlower level than mingw/msys, and I would agree that it is a platform\nissue.\n\n> If somebody wants to write a note somewhere in the git\n> documentation, that's fine with me, but I'm not clear on exactly\n> what it would even say.\n\nI agree with both points. I can suggest to clarify the log message\na bit with \"the implementation of raise() in msvcrt (Microsoft C\nRuntime library) just calls exit(3)\", but that does not address the\nend-user documentation issue.\n\nI tried to summarize the issue for end-user documentation and came\nup with this:\n\n The Git implementation on MinGW exits with status code 3 upon\n receiving an uncaught process-terminating signal, just like any\n program that link with msvcrt (Microsoft C Runtime library)\n whose raise() implementation just calls exit(3). This is\n different from Git on POSIX, which reports a death by receiving\n a signal with the exit status code (128 + signal number).\n\nBut when stated this way, it feels that it belongs to Msysgit\ndocumentation, not ours, at least to me.\n"},{"id":"219519","messageId":"20130606174032.GB32174@sigill.intra.peff.net","threadId":"34030","inReplyTo":"7vy5anyx1w.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] t0005: skip signal death exit code test on Windows","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-06-06T17:40:32Z","receivedAt":"2013-06-06T17:40:32Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Jun 06, 2013 at 10:21:47AM -0700, Junio C Hamano wrote:\n\n> > The particular deficiency is that when a signal is raise()d whose SIG_DFL\n> > action will cause process death (SIGTERM in this case), the\n> > implementation of raise() just calls exit(3).\n> \n> After a bit of web searching, it seems to me that this behaviour of\n> raise() is in msvcrt, and compat/mingw.c::mingw_raise() just calls\n> that. In other words, \"the implementation of raise()\" is at an even\n> lower level than mingw/msys, and I would agree that it is a platform\n> issue.\n\nYeah, if it were mingw_raise responsible for this, I would suggest using\nthe POSIX shell \"128+sig\" instead. We could potentially check for\nSIG_DFL[1] mingw_raise and intercept and exit there. I don't know if\nthat would create headaches or confusion for other msys programs,\nthough. I'd leave that up to the msysgit people to decide whether it is\nworth the trouble.\n\n[1] I'd use sigaction to do that on POSIX, but I would not be surprised\n to find that there is no support for it in msys. :)\n\n> I tried to summarize the issue for end-user documentation and came\n> up with this:\n> \n> The Git implementation on MinGW exits with status code 3 upon\n> receiving an uncaught process-terminating signal, just like any\n> program that link with msvcrt (Microsoft C Runtime library)\n> whose raise() implementation just calls exit(3). This is\n> different from Git on POSIX, which reports a death by receiving\n> a signal with the exit status code (128 + signal number).\n> \n> But when stated this way, it feels that it belongs to Msysgit\n> documentation, not ours, at least to me.\n\nYeah, I think I agree.\n\n-Peff\n"},{"id":"219523","messageId":"CAMP44s3JZh6sn77Tz9gaRZe2or-pbrCrHUhbxQysA1gQY0AzUw@mail.gmail.com","threadId":"34030","inReplyTo":"alpine.DEB.2.02.1306060904100.13204@nftneq.ynat.uz","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-06T18:16:48Z","receivedAt":"2013-06-06T18:16:48Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Jun 6, 2013 at 11:09 AM, David Lang wrote:\n> On Thu, 6 Jun 2013, Felipe Contreras wrote:\n>\n>> In the end my point remains unchanged; Perl is declining, so it would\n>> be wise for the future to use another scripting language instead.\n>\n>\n> Perl use may or may not be declining (depending on how you measure it), but\n> are you really willing to take on the task of re-writing everything that's\n> in Perl into another language and force all developers of scripts to learn\n> that other language?\n\nBut that's exactly what we are asking the newer generations of\ndevelopers; to learn another language. Fewer and fewer new\ncontributors will come with knowledge of Perl.\n\n> What are the odds that the 'newer' language that you pick is going to pull a\n> \"python 3\" on you?\n\nRuby 2 speaks volumes on that front.\n\n> There have been a very large number of scripting languages show up, make a\n> lot of press, and then fade in favor of other languages while Perl has\n> continued. It's not the sexy languange nowdays, but it's there, reliable,\n> and used so heavily that there's really no chance of it dissapearing in the\n> forseable future.\n\nYet it's declining, more and more every year. And the more the time\ngoes by, the more we hurt ourselves.\n\n-- \nFelipe Contreras\n"},{"id":"219525","messageId":"CAMP44s1QotO7yx7reiLdxd61VoZNOTUTWja7ed1G7E9mEJEdrA@mail.gmail.com","threadId":"34030","inReplyTo":"rmisj0vnorm.fsf@fnord.ir.bbn.com","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-06T18:24:43Z","receivedAt":"2013-06-06T18:24:43Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Jun 6, 2013 at 12:16 PM, Greg Troxel wrote:\n>\n> Felipe Contreras writes:\n>\n>> On Thu, Jun 6, 2013 at 9:54 AM, Greg Troxel wrote:\n>>>\n>>> git is a core tool that people use on almost the smallest of boxes,\n>>> perhaps even replacing rcs for managing local config files. On such\n>>> machines, even perl may be large, but a second scripting language seems\n>>> excessive.\n>>\n>> You can compile Git without any of them.\n>\n> That ignores the 99% of people who use packaged versions.\n\nThe 99% of people who use packaged versions wouldn't care about the\nadditional dependency.\n\n>>> On a NetBSD 6 i386 system, the size of the ruby193-base\n>>> binary package (as installed) is 25 MB (vs 15 MB for the git base\n>>> package, which lacks gitk and docs). (Presently, the git base package\n>>> defaults to requiring python and installing the git_remote_helpers, but\n>>> I think that's a bug.) perl is 54 MB.\n>>\n>> That's only the default, if the default doesn't suit you, don't use\n>> the default.\n>\n> It's not about what I want.\n\nIt is exactly about what you want.\n\nYou use the argument that 99% of the people use packaged versions, yet\nyou ignore the fact that 99% of the people don't care about a single\nextra dependency (specially one that would be transitory). It is all\nabout 1% of the users, in fact, not even that, because of this 1% of\nusers who dread extra dependencies, most of them would be happy that\nit's only temporary, and eventually a heavier dependency would be\nreplaced with a lighter one. It is for all intents and purposes only\nyou, the person you are speaking on behalf of.\n\nIf the Git project considers a new dependency that would be needed in\naddition to Perl for a finite period of time, your argument does\nabsolutely nothing to block this route.\n\n-- \nFelipe Contreras\n"},{"id":"219527","messageId":"CAMP44s0Qq2n5cJa9buaLgNDTp61cxA1G+XutTZasphkGmyguHg@mail.gmail.com","threadId":"34030","inReplyTo":"7vy5anyx1w.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] t0005: skip signal death exit code test on Windows","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-06T18:32:08Z","receivedAt":"2013-06-06T18:32:08Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Jun 6, 2013 at 12:21 PM, Junio C Hamano wrote:\n> Jeff King writes:\n\n>> If somebody wants to write a note somewhere in the git\n>> documentation, that's fine with me, but I'm not clear on exactly\n>> what it would even say.\n>\n> I agree with both points. I can suggest to clarify the log message\n> a bit with \"the implementation of raise() in msvcrt (Microsoft C\n> Runtime library) just calls exit(3)\", but that does not address the\n> end-user documentation issue.\n>\n> I tried to summarize the issue for end-user documentation and came\n> up with this:\n>\n> The Git implementation on MinGW\n\nThat's not accurate at all. MinGW is essentially a compiler for\nWindows. It doesn't matter if you use MinGW, Visual C++, or any other\ncompiler for Windows, the result would be the same.\n\n> But when stated this way, it feels that it belongs to Msysgit\n> documentation, not ours, at least to me.\n\nAre we saying then that Git doesn't support Windows? That wouldn't be\nwise considering it's one of the most widely used reasons to argue\nthat Git is not a good choice of a SCM; lack of Windows support.\n\nThe truth of the matter is that exit codes are platform-dependent. Period.\n\n-- \nFelipe Contreras\n"},{"id":"219555","messageId":"CAEcj5uXHxvo90bP8GC5hDLBz4HZhg1JV4jHUSWnbSNhnjtCH=g@mail.gmail.com","threadId":"34030","inReplyTo":"51AEBAEF.6090402@alum.mit.edu","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Thomas Ferris Nicolaisen","fromEmail":"tfnico@gmail.com","sentAt":"2013-06-06T19:48:39Z","receivedAt":"2013-06-06T19:48:39Z","isPatch":false,"sender":{"key":"tfnico@gmail.com","avatar":"https://gravatar.com/avatar/628cf28a25ca4c596c7284562100f70f0ef908bcbfadd4da1eb3d48c23658d01?d=mp&s=160"},"body":"On Wed, Jun 5, 2013 at 6:13 AM, Michael Haggerty wrote:\n>\n> But my main point is that I think it would be easier to phase out\n> contrib/ if there were a good alternate way of providing visibility to\n> \"satellite\" projects. The relevant Git wiki page [1] is the most likely\n> candidate, but it is a bit overwhelming due to its size, it has fallen\n> into disuse because it was broken for such a long time, and it is not\n> prominently linked to from git-scm.com. If it were curated a bit, it\n> would help users find the best ancillary tools quickly. Perhaps ranking\n> the tools based on the results of the Git user surveys would help bring\n> the most popular to the top of each category.\n>\n\nOne idea here could be to mirror what the libgit2 project [1] (and many\nothers) are doing on GitHub. Use the organization unit [2] as an umbrella\nfor the contrib projects. If necessary, put a pretty web-page on top [3].\n\nOf course you don't have to tie it to GitHub, but they do have some nice\nmechanisms for showing off popularity (stars and forks).\n\nI heard that clojure/contrib [4] went through a big clean-up recently,\nalthough I'm not sure if there was an equivalent reasoning behind it. But\ntheir guide-lines on what should go into contrib may have some good\nideas [5].\n\n[1] https://github.com/libgit2\n[2] https://github.com/git\n[3] http://libgit2.github.com/\n[4] http://dev.clojure.org/display/design/Where+Did+Clojure.Contrib+Go\n[5] http://dev.clojure.org/pages/viewpage.action?pageId=5767464\n"},{"id":"219562","messageId":"alpine.DEB.2.02.1306061308100.29361@nftneq.ynat.uz","threadId":"34030","inReplyTo":"CALkWK0mwxfGJdZi6kSaAPr66o550RiT_p8_r_4mDvcd_VAFYQw@mail.gmail.com","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"David Lang","fromEmail":"david@lang.hm","sentAt":"2013-06-06T20:19:49Z","receivedAt":"2013-06-06T20:19:49Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Fri, 7 Jun 2013, Ramkumar Ramachandra wrote:\n\n> David Lang wrote:\n>> Perl use may or may not be declining (depending on how you measure it), but\n>> are you really willing to take on the task of re-writing everything that's\n>> in Perl into another language and force all developers of scripts to learn\n>> that other language? what's the ROI of this?\n>\n> Let's not talk hypotheticals. git-svn.perl (+ perl/SVN/*.pl) is\n> absolutely massive. It's an incredibly useful tool in that it\n> actually works, and that there is nothing replacing it in the\n> foreseeable future. This monster was written almost entirely by one\n> brilliant person, and nobody is going to rewrite it. We don't start a\n> huge discussion about what languages are \"approved\" before accepting\n> such a contribution: if the contributor wants to write something in a\n> dominant language (Perl in this case), and it's going to be useful, we\n> merge it. End of story.\n\nWell, Felipe is saying that Perl is dieing and we should re-write everything \nthat exists in Perl to Ruby.\n\nPart of the reason for the discussion now is because not having similar \ndiscussions in the past have caused problems.\n\n> All this planning is a colossal waste of time, in my opinion.\n>\n>> Perl isn't going to disappear any time soon. What makes you think that\n>> whatever language you pick to replace Perl is going to be more stable than\n>> Perl is?\n>\n> Why are we discussing something that is indeterminate? It is\n> impossible to foresee the future, but that is no reason to freeze\n> _present_ development.\n\nand it's not a reason to throw away existing stuff based on the argument that \nPerl is dieing\n\n>> There have been a very large number of scripting languages show up, make a\n>> lot of press, and then fade in favor of other languages while Perl has\n>> continued. It's not the sexy languange nowdays, but it's there, reliable,\n>> and used so heavily that there's really no chance of it dissapearing in the\n>> forseable future.\n>\n> Nobody claimed that \"press coverage\" is a good metric. We can only\n> talk about facts, and Felipe already showed you a TIOBE index graph.\n> If you have overwhelming _evidence_ that Ruby is a weak language that\n> will die soon, share it: otherwise, I see no value in this discussion.\n\nTIOBE index graph is \"press coverage\" as far as I'm concerned.\n\nI'm not saying that Ruby in particular has a fatal flaw, I'm just questioning \nthe \"Perl is dead, re-write everything in Ruby\" mantra.\n\nThe language that you choose to use when writing a new application is related to \nthings related to that type of application.\n\nRuby is not an extremely common language for sysadmins to use.\n\nPerl remains a common language for these sorts of tasks, even if it's not used \nfor user visible applications.\n\nArguing that Perl is dieing, we need to abandon it is just wrong.\n\nDavid Lang\n"},{"id":"219556","messageId":"CALkWK0mwxfGJdZi6kSaAPr66o550RiT_p8_r_4mDvcd_VAFYQw@mail.gmail.com","threadId":"34030","inReplyTo":"alpine.DEB.2.02.1306060904100.13204@nftneq.ynat.uz","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-06T20:29:48Z","receivedAt":"2013-06-06T20:29:48Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"David Lang wrote:\n> Perl use may or may not be declining (depending on how you measure it), but\n> are you really willing to take on the task of re-writing everything that's\n> in Perl into another language and force all developers of scripts to learn\n> that other language? what's the ROI of this?\n\nLet's not talk hypotheticals. git-svn.perl (+ perl/SVN/*.pl) is\nabsolutely massive. It's an incredibly useful tool in that it\nactually works, and that there is nothing replacing it in the\nforeseeable future. This monster was written almost entirely by one\nbrilliant person, and nobody is going to rewrite it. We don't start a\nhuge discussion about what languages are \"approved\" before accepting\nsuch a contribution: if the contributor wants to write something in a\ndominant language (Perl in this case), and it's going to be useful, we\nmerge it. End of story.\n\nAll this planning is a colossal waste of time, in my opinion.\n\n> Perl isn't going to disappear any time soon. What makes you think that\n> whatever language you pick to replace Perl is going to be more stable than\n> Perl is?\n\nWhy are we discussing something that is indeterminate? It is\nimpossible to foresee the future, but that is no reason to freeze\n_present_ development.\n\n> and, like the parent poster, by 'stable' I mean from the compatibility point\n> of view.\n\nVarious programming languages have different philosophies, and have\ngrown in different ways. What matters is that some of them have a\nlarge number of users, and we're talking about one such example.\n\n> What are the odds that the 'newer' language that you pick is going to pull a\n> \"python 3\" on you?\n\nThis has to be a rhetorical, because I don't imagine you expect anyone\nto predict the future. As Felipe already pointed out Ruby 2.0 is a\ngood sign.\n\n> There have been a very large number of scripting languages show up, make a\n> lot of press, and then fade in favor of other languages while Perl has\n> continued. It's not the sexy languange nowdays, but it's there, reliable,\n> and used so heavily that there's really no chance of it dissapearing in the\n> forseable future.\n\nNobody claimed that \"press coverage\" is a good metric. We can only\ntalk about facts, and Felipe already showed you a TIOBE index graph.\nIf you have overwhelming _evidence_ that Ruby is a weak language that\nwill die soon, share it: otherwise, I see no value in this discussion.\n"},{"id":"219558","messageId":"CALkWK0n2VsEP31jMB2kZ4x=wa90o8QPkR=ZWETfm=H5RC1kKcg@mail.gmail.com","threadId":"34030","inReplyTo":"alpine.DEB.1.00.1306061818191.28957@s15462909.onlinehome-server.info","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-06T20:40:58Z","receivedAt":"2013-06-06T20:40:58Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Johannes Schindelin wrote:\n> My initial reaction, too. It was hard enough to get Perl included with Git\n> for Windows (because of that pesky Subversion dependency).\n\nNevertheless, we had to do it, and we did it. We will do it again, if\nwe get enough important code written in Ruby.\n\n> As you can see from the commit history, I was the primary force behind\n> trying to get everything \"core\" in Git away from requiring scripting\n> languages (I think it is an awesome thing to provide APIs for as many\n> languages as possible, but a not-so-cool thing to use more than one\n> language in the core code). It does not seem that anybody picked up that\n> task when I left, though.\n\nRewriting everything in C? Is anyone bored enough to pick up this\ntask? Bourne shell is a great language for prototyping; git-rebase.sh\n(and friends), git-stash.sh, git-pull.sh are doing just fine. Sure,\nit makes sense to do heavy-lifting in C, and this is happening as it\nhas always been happening (remember git-commit.sh?). If you followed\nthe list emails, you'd know that Felipe is looking into delegating\nlarge portions of the work done by git-rebase.sh to sequencer.c.\n\nAnyway, all this talk about some hypothetical ideas just bores me.\nWhat matters is what is currently happening. And nobody is actively\nrewriting the \"core in Git\" in C, so I don't see the point of\ndiscussing anything but patches.\n"},{"id":"219557","messageId":"51B0F3F6.5040507@brokenzipper.com","threadId":"34030","inReplyTo":"CAMP44s3zuDPTApPvnaC0bzqmAUkRRwePZDRL4syB=tM3d6eiBA@mail.gmail.com","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Charles McGarvey","fromEmail":"chazmcgarvey@brokenzipper.com","sentAt":"2013-06-06T20:41:26Z","receivedAt":"2013-06-06T20:41:26Z","isPatch":false,"sender":{"key":"chazmcgarvey@brokenzipper.com","avatar":"https://avatars.githubusercontent.com/u/108998?v=4"},"body":"On 06/06/2013 01:46 AM, Felipe Contreras wrote:\n> On Thu, Jun 6, 2013 at 2:26 AM, demerphq wrote:\n>>\n>> Good thing you are being objective and leaving out the Python 3.0\n>> mess, the long legacy of backwards compatibility in the Perl\n>> community, the active community behind it, its extensive portability\n>> support, and fail to mention the lack of an equivalent to CPAN. We\n>> wouldn't want facts to get in the way of a personal bias would we?\n> \n> None of that has anything to do with Perl's popularity.\n> \n>> Just thought I'd push back on the FUD. People have been saying Perl is\n>> going away for decades...\n> \n> Perl has been going away for the last decade [1], and will continue to\n> go away. Perl is going away, and that an undeniable fact, and if you\n> are not interested in discussing on the basis of reality, I'm not\n> interested in discussing with you.\n> \n> [1] http://www.tiobe.com/content/paperinfo/tpci/images/tpci_trends.png\n\nThe linchpin of your argument is that Perl is dying. Let's assume that the\nTIOBE index is a reliable basis for making business decisions--it's not, but\nlet's pretend--the graph you linked to doesn't even seem to support your\nconclusion (or am I missing something?). It looks like Perl's popularity has\npretty much been constant for at least two years. It's apparently not\nincreasing in popularity, but this isn't an electrocardiogram (i.e.\nflat-lining is not dead or even dying). The same graph shows that Ruby's\npopularity also hasn't changed very much since 2007 after its initial surge.\n\nNow, it's probably too off-topic to pick apart TIOBE's methodology here, but\nsuffice it to say that, like any trend indicator, it's only as useful as your\nknowledge of its limitations, and this has been discussed enough elsewhere.\n\nIt's true that Perl isn't soon going to win any trendiness awards, but the\nsame reasons that made Perl a good choice for git so many years ago are still\nthere and then some. You would probably also be surprised at the number of\nnew kids learning Perl.\n\nI guess I just denied the \"undeniable fact\" that Perl is going away, so maybe\nI'm one of those with whom you do not want to discuss this, but, for my part,\nI am willing to consider other evidence for the claim. As I pointed out, the\nevidence shown so far (one reference to the TIOBE index) isn't nearly enough\nto settle the matter. I also apologize for dragging this out if this thread\nis judged to not be worth a whole lot.\n\n-- \nCharles McGarvey\n\n"},{"id":"219559","messageId":"CALkWK0kQSuvv9owUYxatKTKW+GEpR0kL6XsyrOJD66yfodycUQ@mail.gmail.com","threadId":"34030","inReplyTo":"rmisj0vnorm.fsf@fnord.ir.bbn.com","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-06T21:05:30Z","receivedAt":"2013-06-06T21:05:30Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Greg Troxel wrote:\n> It's not about what I want. It's about making choices that affect other\n> people, and trying to find a plan that will be overall reasonable;\n> that's the essence of stewardship in packaging. Compiling for just\n> myself is far easier.\n\nHave you asked the SBCL or Google-Chrome package maintainers what they\nhave to deal with? I believe they're packaging nightmares. GHC/\nHaskell projects aren't far behind. Git is probably the _last_ thing\nto be complaining about when it comes to packaging.\n\nSure, people want to run Git on embedded devices like Rpi. The core\nis already in C and Bourne Shell, and I don't see anyone rewriting\nthat in Ruby. No cause for concern.\n\n> That ignores the 99% of people who use packaged versions. The question\n> is really \"Should the standared approach for building be to use or not\n> use dependency X?\". Really this should be expressed in the README, and\n> it creates expectations for someone who just installs the git package in\n> terms of whether pieces of functionality are there. Packagers generally\n> should be reading the README and including required/recommended\n> dependencies and not including optional dependencies (in the main\n> package). The information in INSTALL is pretty reasonable, but it\n> doesn't really clearly say \"if you hand someone git built without perl,\n> it is { perfectly ok but missing a fringe optional feature | deficient\n> because \"git add -p\" won't work }. I'm leaning towards the \"deficient\"\n> camp.\n\nSo whom is this extra dependency affecting, if 99% of users are using\npackaged versions? So, it's just extra burden for the package\nmaintainers (and users on source-based distributions)? git-svn and\ngit-send-email are already separate packages on Ubuntu/Debian because\nthey depend on lots of CPAN packages that can be non-trivial to\ninstall for new users. If we do get one important Ruby script, ship\nit as a separate package: done?\n\nAt the moment, there's just contrib/git-related that depends on ruby.\nCan we just stop planning centuries in advance, and tackle the problem\nwhen it arises? It remains to be determined whether or not git.git\nwill grow a healthy ruby sub-ecosystem. If it does, package\nmaintainers will be inconvenienced slightly. Otherwise, we'll just\nthrow out the ruby code that's rotting in our tree, and get on with\nour lives.\n\nThe direction of the project is not decided on the basis of some vague\nfuture packaging expectations. It's decided on the basis of what\npatches come in from contributors, and everything else is secondary.\nIf people want to write ruby, they will write ruby. Whether or not\nthe git project welcomes their contributions.\n"},{"id":"219565","messageId":"20130606213124.GB12924@google.com","threadId":"34030","inReplyTo":"CALkWK0kQSuvv9owUYxatKTKW+GEpR0kL6XsyrOJD66yfodycUQ@mail.gmail.com","subject":"Dependencies and packaging (Re: [Administrivia] On ruby and contrib/)","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-06-06T21:31:24Z","receivedAt":"2013-06-06T21:31:24Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Ramkumar Ramachandra wrote:\n\n> Git is probably the _last_ thing\n> to be complaining about when it comes to packaging.\n\nIt would be nice if contrib/ files supported the usual \"make; make\ninstall; make clean\" targets. That's missing functionality that does\nmatter to at least one packager.\n\nIt would be nice if the dependencies associated to each piece of\nfunctionality or makefile flag were documented more clearly.\nCurrently when e.g. features of gitweb gain dependencies I don't\nnotice until the testsuite fails.\n\nJonathan\n"},{"id":"219583","messageId":"alpine.DEB.1.00.1306070518510.28957@s15462909.onlinehome-server.info","threadId":"34030","inReplyTo":"CALkWK0n2VsEP31jMB2kZ4x=wa90o8QPkR=ZWETfm=H5RC1kKcg@mail.gmail.com","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2013-06-07T03:25:36Z","receivedAt":"2013-06-07T03:25:36Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Ram,\n\nOn Fri, 7 Jun 2013, Ramkumar Ramachandra wrote:\n\n> Johannes Schindelin wrote:\n> > My initial reaction, too. It was hard enough to get Perl included with Git\n> > for Windows (because of that pesky Subversion dependency).\n> \n> Nevertheless, we had to do it, and we did it.\n\nThat is not quite correct. *I* did it. Not *we*. And I will not do it\nagain.\n\n> We will do it again, if we get enough important code written in Ruby.\n\nI am a bit bored by this hypothetical talk. This hypothetical \"we will do\nit again\", to be precise. Given my experience, it would be very painful if\n\"enough important code\" was written in Ruby. Nobody would help me \"do it\nagain\". Just like nobody helps right now to upgrade to a newer Perl. Feel\nfree to prove me wrong. Until that time, I will firmly believe that there\nis no \"we will do it again\".\n\nSo here is a chance to prevent that: not repeat the mistake, and stay away\nfrom language hell by avoiding to require yet another language.\n\n> > As you can see from the commit history, I was the primary force behind\n> > trying to get everything \"core\" in Git away from requiring scripting\n> > languages (I think it is an awesome thing to provide APIs for as many\n> > languages as possible, but a not-so-cool thing to use more than one\n> > language in the core code). It does not seem that anybody picked up\n> > that task when I left, though.\n> \n> Rewriting everything in C? Is anyone bored enough to pick up this task?\n> Bourne shell is a great language for prototyping; git-rebase.sh (and\n> friends), git-stash.sh, git-pull.sh are doing just fine. Sure, it makes\n> sense to do heavy-lifting in C, and this is happening as it has always\n> been happening (remember git-commit.sh?). If you followed the list\n> emails, you'd know that Felipe is looking into delegating large portions\n> of the work done by git-rebase.sh to sequencer.c.\n\nAs you know, there are very good reasons why I do not follow those mails.\n\n> Anyway, all this talk about some hypothetical ideas just bores me.\n> What matters is what is currently happening. And nobody is actively\n> rewriting the \"core in Git\" in C, so I don't see the point of\n> discussing anything but patches.\n\nExactly. Nobody really cares about keeping Git portable enough. Hence my\nimpression that this idea to start requiring yet another language for core\nparts of Git is a bit misguided, and only logical from the point of view:\n\"If you don't like it, why don't you install Linux?\" (which, just in case\nyou wondered, is a pretty naive way of looking at the real world).\n\nCiao,\nJohannes\n"},{"id":"219608","messageId":"51B17C3D.6000703@viscovery.net","threadId":"34030","inReplyTo":"20130606174032.GB32174@sigill.intra.peff.net","subject":"Re: [PATCH] t0005: skip signal death exit code test on Windows","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2013-06-07T06:22:53Z","receivedAt":"2013-06-07T06:22:53Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 6/6/2013 19:40, schrieb Jeff King:\n> On Thu, Jun 06, 2013 at 10:21:47AM -0700, Junio C Hamano wrote:\n> \n>>> The particular deficiency is that when a signal is raise()d whose SIG_DFL\n>>> action will cause process death (SIGTERM in this case), the\n>>> implementation of raise() just calls exit(3).\n>>\n>> After a bit of web searching, it seems to me that this behaviour of\n>> raise() is in msvcrt, and compat/mingw.c::mingw_raise() just calls\n>> that. In other words, \"the implementation of raise()\" is at an even\n>> lower level than mingw/msys, and I would agree that it is a platform\n>> issue.\n> \n> Yeah, if it were mingw_raise responsible for this, I would suggest using\n> the POSIX shell \"128+sig\" instead. We could potentially check for\n> SIG_DFL[1] mingw_raise and intercept and exit there. I don't know if\n> that would create headaches or confusion for other msys programs,\n> though. I'd leave that up to the msysgit people to decide whether it is\n> worth the trouble.\n\nEven if we move the signal emulation closer to POSIX in the way that you\nsuggested (if that were possible, I haven't checked), the emulation is\nstill not complete, because we would have addressed only raise().\nTherefore, personally I would like to delay the issue until there is a\nuser (script) that depends on POSIXly exit codes.\n\nAs far as t0005.2 is concerned, its the best to just concede that Windows\ndoes not have POSIX-like behavior as far as signals are concerned, and\nskip the test.\n\nWe could also sweep the issue under the rug with the patch below, which\nworks because SIGALRM does not exist in MSVCRT and is handled entirely by\ncompat/mingw.c. But it goes into the wrong direction, IMO.\n\ndiff --git a/t/t0005-signals.sh b/t/t0005-signals.sh\nindex ad9e604..68b6c3b 100755\n--- a/t/t0005-signals.sh\n+++ b/t/t0005-signals.sh\n@@ -12,9 +12,8 @@ EOF\n test_expect_success 'sigchain works' '\n \ttest-sigchain >actual\n \tcase \"$?\" in\n-\t143) true ;; # POSIX w/ SIGTERM=15\n-\t271) true ;; # ksh w/ SIGTERM=15\n-\t 3) true ;; # Windows\n+\t142) true ;; # POSIX w/ SIGALRM=14\n+\t270) true ;; # ksh w/ SIGTERM=14\n \t *) false ;;\n \tesac &&\n \ttest_cmp expect actual\n@@ -23,8 +22,8 @@ test_expect_success 'sigchain works' '\n test_expect_success 'signals are propagated using shell convention' '\n \t# we use exec here to avoid any sub-shell interpretation\n \t# of the exit code\n-\tgit config alias.sigterm \"!exec test-sigchain\" &&\n-\ttest_expect_code 143 git sigterm\n+\tgit config alias.sigalrm \"!exec test-sigchain\" &&\n+\ttest_expect_code 142 git sigalrm\n '\n\n test_done\ndiff --git a/test-sigchain.c b/test-sigchain.c\nindex 42db234..0233a39 100644\n--- a/test-sigchain.c\n+++ b/test-sigchain.c\n@@ -14,9 +14,9 @@ X(three)\n #undef X\n\n int main(int argc, char **argv) {\n-\tsigchain_push(SIGTERM, one);\n-\tsigchain_push(SIGTERM, two);\n-\tsigchain_push(SIGTERM, three);\n-\traise(SIGTERM);\n+\tsigchain_push(SIGALRM, one);\n+\tsigchain_push(SIGALRM, two);\n+\tsigchain_push(SIGALRM, three);\n+\traise(SIGALRM);\n \treturn 0;\n }\n"},{"id":"219616","messageId":"CABPQNSa+nZY2V44B-L47aqwt=4eKr96jtadgKHhS__29tTvsdg@mail.gmail.com","threadId":"34030","inReplyTo":"51B02D81.3000700@viscovery.net","subject":"Re: [PATCH] t0005: skip signal death exit code test on Windows","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@gmail.com","sentAt":"2013-06-07T10:01:15Z","receivedAt":"2013-06-07T10:01:15Z","isPatch":true,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Thu, Jun 6, 2013 at 8:34 AM, Johannes Sixt wrote:\n> From: Johannes Sixt \n>\n> The test case depends on that test-sigchain can commit suicide by a call\n> to raise(SIGTERM) in a way that run-command.c::wait_or_whine() can detect\n> as death through a signal. There are no POSIX signals on Windows, and a\n> sufficiently close emulation is not available in the Microsoft C runtime\n> (and probably not even possible).\n>\n> The particular deficiency is that when a signal is raise()d whose SIG_DFL\n> action will cause process death (SIGTERM in this case), the\n> implementation of raise() just calls exit(3).\n>\n> We could check for exit code 3 in addition to 143, but that would miss\n> the point of the test entirely. Hence, just skip it on Windows.\n>\n\nHuh? We do \"exit(128 + sigint);\" in mingw_raise these days, no?\n\nOr is the signal triggered from a non-git process?\n"},{"id":"219617","messageId":"CABPQNSZMae0F3PDDp+h6zy7fC1jfAzSDbO--i1aSk2HTjVkSiw@mail.gmail.com","threadId":"34030","inReplyTo":"CABPQNSa+nZY2V44B-L47aqwt=4eKr96jtadgKHhS__29tTvsdg@mail.gmail.com","subject":"Re: [PATCH] t0005: skip signal death exit code test on Windows","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@gmail.com","sentAt":"2013-06-07T10:03:49Z","receivedAt":"2013-06-07T10:03:49Z","isPatch":true,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Fri, Jun 7, 2013 at 12:01 PM, Erik Faye-Lund wrote:\n> On Thu, Jun 6, 2013 at 8:34 AM, Johannes Sixt wrote:\n>> From: Johannes Sixt \n>>\n>> The test case depends on that test-sigchain can commit suicide by a call\n>> to raise(SIGTERM) in a way that run-command.c::wait_or_whine() can detect\n>> as death through a signal. There are no POSIX signals on Windows, and a\n>> sufficiently close emulation is not available in the Microsoft C runtime\n>> (and probably not even possible).\n>>\n>> The particular deficiency is that when a signal is raise()d whose SIG_DFL\n>> action will cause process death (SIGTERM in this case), the\n>> implementation of raise() just calls exit(3).\n>>\n>> We could check for exit code 3 in addition to 143, but that would miss\n>> the point of the test entirely. Hence, just skip it on Windows.\n>>\n>\n> Huh? We do \"exit(128 + sigint);\" in mingw_raise these days, no?\n>\n> Or is the signal triggered from a non-git process?\n\nArgh, I'm blind. Yeah, SIGTERM, not SIGINT...\n"},{"id":"219618","messageId":"CABPQNSYLmFWkdgph6W7MwaSTe+zrU0AaJpj_v9z=cmvWu64HNA@mail.gmail.com","threadId":"34030","inReplyTo":"20130606174032.GB32174@sigill.intra.peff.net","subject":"Re: [PATCH] t0005: skip signal death exit code test on Windows","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@gmail.com","sentAt":"2013-06-07T10:12:52Z","receivedAt":"2013-06-07T10:12:52Z","isPatch":true,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Thu, Jun 6, 2013 at 7:40 PM, Jeff King wrote:\n> On Thu, Jun 06, 2013 at 10:21:47AM -0700, Junio C Hamano wrote:\n>\n>> > The particular deficiency is that when a signal is raise()d whose SIG_DFL\n>> > action will cause process death (SIGTERM in this case), the\n>> > implementation of raise() just calls exit(3).\n>>\n>> After a bit of web searching, it seems to me that this behaviour of\n>> raise() is in msvcrt, and compat/mingw.c::mingw_raise() just calls\n>> that. In other words, \"the implementation of raise()\" is at an even\n>> lower level than mingw/msys, and I would agree that it is a platform\n>> issue.\n>\n> Yeah, if it were mingw_raise responsible for this, I would suggest using\n> the POSIX shell \"128+sig\" instead. We could potentially check for\n> SIG_DFL[1] mingw_raise and intercept and exit there. I don't know if\n> that would create headaches or confusion for other msys programs,\n> though. I'd leave that up to the msysgit people to decide whether it is\n> worth the trouble.\n>\n\n...and here's the code to do just that:\n\ndiff --git a/compat/mingw.c b/compat/mingw.c\nindex b295e2f..8b3c1b4 100644\n--- a/compat/mingw.c\n+++ b/compat/mingw.c\n@@ -1573,7 +1573,8 @@ static HANDLE timer_event;\n static HANDLE timer_thread;\n static int timer_interval;\n static int one_shot;\n-static sig_handler_t timer_fn = SIG_DFL, sigint_fn = SIG_DFL;\n+static sig_handler_t timer_fn = SIG_DFL, sigint_fn = SIG_DFL,\n+ sigterm_fn = SIG_DFL;\n\n /* The timer works like this:\n * The thread, ticktack(), is a trivial routine that most of the time\n@@ -1688,6 +1689,10 @@ sig_handler_t mingw_signal(int sig,\nsig_handler_t handler)\n \t\tsigint_fn = handler;\n \t\tbreak;\n\n+\tcase SIGTERM:\n+\t\tsigterm_fn = handler;\n+\t\tbreak;\n+\n \tdefault:\n \t\treturn signal(sig, handler);\n \t}\n@@ -1715,6 +1720,13 @@ int mingw_raise(int sig)\n \t\t\tsigint_fn(SIGINT);\n \t\treturn 0;\n\n+\tcase SIGTERM:\n+\t\tif (sigterm_fn == SIG_DFL)\n+\t\t\texit(128 + SIGTERM);\n+\t\telse if (sigterm_fn != SIG_IGN)\n+\t\t\tsigterm_fn(SIGTERM);\n+\t\treturn 0;\n+\n \tdefault:\n \t\treturn raise(sig);\n \t}\n"},{"id":"219619","messageId":"51B1B4DF.90705@viscovery.net","threadId":"34030","inReplyTo":"CABPQNSYLmFWkdgph6W7MwaSTe+zrU0AaJpj_v9z=cmvWu64HNA@mail.gmail.com","subject":"Re: [PATCH] t0005: skip signal death exit code test on Windows","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2013-06-07T10:24:31Z","receivedAt":"2013-06-07T10:24:31Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 6/7/2013 12:12, schrieb Erik Faye-Lund:\n> On Thu, Jun 6, 2013 at 7:40 PM, Jeff King wrote:\n>> On Thu, Jun 06, 2013 at 10:21:47AM -0700, Junio C Hamano wrote:\n>>\n>>>> The particular deficiency is that when a signal is raise()d whose SIG_DFL\n>>>> action will cause process death (SIGTERM in this case), the\n>>>> implementation of raise() just calls exit(3).\n>>>\n>>> After a bit of web searching, it seems to me that this behaviour of\n>>> raise() is in msvcrt, and compat/mingw.c::mingw_raise() just calls\n>>> that. In other words, \"the implementation of raise()\" is at an even\n>>> lower level than mingw/msys, and I would agree that it is a platform\n>>> issue.\n>>\n>> Yeah, if it were mingw_raise responsible for this, I would suggest using\n>> the POSIX shell \"128+sig\" instead. We could potentially check for\n>> SIG_DFL[1] mingw_raise and intercept and exit there. I don't know if\n>> that would create headaches or confusion for other msys programs,\n>> though. I'd leave that up to the msysgit people to decide whether it is\n>> worth the trouble.\n>>\n> \n> ...and here's the code to do just that:\n> \n> diff --git a/compat/mingw.c b/compat/mingw.c\n> index b295e2f..8b3c1b4 100644\n> --- a/compat/mingw.c\n> +++ b/compat/mingw.c\n> @@ -1573,7 +1573,8 @@ static HANDLE timer_event;\n> static HANDLE timer_thread;\n> static int timer_interval;\n> static int one_shot;\n> -static sig_handler_t timer_fn = SIG_DFL, sigint_fn = SIG_DFL;\n> +static sig_handler_t timer_fn = SIG_DFL, sigint_fn = SIG_DFL,\n> + sigterm_fn = SIG_DFL;\n> \n> /* The timer works like this:\n> * The thread, ticktack(), is a trivial routine that most of the time\n> @@ -1688,6 +1689,10 @@ sig_handler_t mingw_signal(int sig,\n> sig_handler_t handler)\n> \t\tsigint_fn = handler;\n> \t\tbreak;\n> \n> +\tcase SIGTERM:\n> +\t\tsigterm_fn = handler;\n> +\t\tbreak;\n> +\n> \tdefault:\n> \t\treturn signal(sig, handler);\n> \t}\n> @@ -1715,6 +1720,13 @@ int mingw_raise(int sig)\n> \t\t\tsigint_fn(SIGINT);\n> \t\treturn 0;\n> \n> +\tcase SIGTERM:\n> +\t\tif (sigterm_fn == SIG_DFL)\n> +\t\t\texit(128 + SIGTERM);\n> +\t\telse if (sigterm_fn != SIG_IGN)\n> +\t\t\tsigterm_fn(SIGTERM);\n> +\t\treturn 0;\n> +\n> \tdefault:\n> \t\treturn raise(sig);\n> \t}\n\nThat's pointless and does not work. The handler would only be called when\nraise() is called, but not when a SIGTERM is received, e.g., via Ctrl-C\nfrom the command line, because that route ends up in MSVCRT, which does\nnot know about this handler.\n\nIf you want to follow this route, you must emulate everything that MSVCRT\nalready does for us, and that's quite a lot, in particular, when some form\nof thread safety is required.\n\n-- Hannes\n"},{"id":"219622","messageId":"CABPQNSYE=Mvrmc44dZmKnB14KLh4A=HxWo2-xgnJRyj1Q+BJLg@mail.gmail.com","threadId":"34030","inReplyTo":"51B1B4DF.90705@viscovery.net","subject":"Re: [PATCH] t0005: skip signal death exit code test on Windows","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@gmail.com","sentAt":"2013-06-07T12:00:41Z","receivedAt":"2013-06-07T12:00:41Z","isPatch":true,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Fri, Jun 7, 2013 at 12:24 PM, Johannes Sixt wrote:\n> Am 6/7/2013 12:12, schrieb Erik Faye-Lund:\n>> On Thu, Jun 6, 2013 at 7:40 PM, Jeff King wrote:\n>>> On Thu, Jun 06, 2013 at 10:21:47AM -0700, Junio C Hamano wrote:\n>>>\n>>>>> The particular deficiency is that when a signal is raise()d whose SIG_DFL\n>>>>> action will cause process death (SIGTERM in this case), the\n>>>>> implementation of raise() just calls exit(3).\n>>>>\n>>>> After a bit of web searching, it seems to me that this behaviour of\n>>>> raise() is in msvcrt, and compat/mingw.c::mingw_raise() just calls\n>>>> that. In other words, \"the implementation of raise()\" is at an even\n>>>> lower level than mingw/msys, and I would agree that it is a platform\n>>>> issue.\n>>>\n>>> Yeah, if it were mingw_raise responsible for this, I would suggest using\n>>> the POSIX shell \"128+sig\" instead. We could potentially check for\n>>> SIG_DFL[1] mingw_raise and intercept and exit there. I don't know if\n>>> that would create headaches or confusion for other msys programs,\n>>> though. I'd leave that up to the msysgit people to decide whether it is\n>>> worth the trouble.\n>>>\n>>\n>> ...and here's the code to do just that:\n>>\n>> diff --git a/compat/mingw.c b/compat/mingw.c\n>> index b295e2f..8b3c1b4 100644\n>> --- a/compat/mingw.c\n>> +++ b/compat/mingw.c\n>> @@ -1573,7 +1573,8 @@ static HANDLE timer_event;\n>> static HANDLE timer_thread;\n>> static int timer_interval;\n>> static int one_shot;\n>> -static sig_handler_t timer_fn = SIG_DFL, sigint_fn = SIG_DFL;\n>> +static sig_handler_t timer_fn = SIG_DFL, sigint_fn = SIG_DFL,\n>> + sigterm_fn = SIG_DFL;\n>>\n>> /* The timer works like this:\n>> * The thread, ticktack(), is a trivial routine that most of the time\n>> @@ -1688,6 +1689,10 @@ sig_handler_t mingw_signal(int sig,\n>> sig_handler_t handler)\n>> sigint_fn = handler;\n>> break;\n>>\n>> + case SIGTERM:\n>> + sigterm_fn = handler;\n>> + break;\n>> +\n>> default:\n>> return signal(sig, handler);\n>> }\n>> @@ -1715,6 +1720,13 @@ int mingw_raise(int sig)\n>> sigint_fn(SIGINT);\n>> return 0;\n>>\n>> + case SIGTERM:\n>> + if (sigterm_fn == SIG_DFL)\n>> + exit(128 + SIGTERM);\n>> + else if (sigterm_fn != SIG_IGN)\n>> + sigterm_fn(SIGTERM);\n>> + return 0;\n>> +\n>> default:\n>> return raise(sig);\n>> }\n>\n> That's pointless and does not work. The handler would only be called when\n> raise() is called, but not when a SIGTERM is received, e.g., via Ctrl-C\n> from the command line, because that route ends up in MSVCRT, which does\n> not know about this handler.\n\nThat's not entirely true. On Windows, there's only *one* way to\ngenerate SIGTERM; \"signal(SIGTERM)\". Ctrl+C does not generate SIGTERM.\nWe generate SIGINT on Ctrl+C in mingw_fgetc, but the default Control+C\nhandler routine calls ExitProcess():\nhttp://msdn.microsoft.com/en-us/library/windows/desktop/ms683242(v=vs.85).aspx\n\nSo I believe this *does* entirely fix SIGTERM (as we currently know\nit) on Windows. SIGINT is still not entirely clean, but we can fix\nthat on a case-by-case basis.\n"},{"id":"219624","messageId":"51B1CFD4.3030908@viscovery.net","threadId":"34030","inReplyTo":"CABPQNSYE=Mvrmc44dZmKnB14KLh4A=HxWo2-xgnJRyj1Q+BJLg@mail.gmail.com","subject":"Re: [PATCH] t0005: skip signal death exit code test on Windows","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2013-06-07T12:19:32Z","receivedAt":"2013-06-07T12:19:32Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 6/7/2013 14:00, schrieb Erik Faye-Lund:\n> On Fri, Jun 7, 2013 at 12:24 PM, Johannes Sixt wrote:\n>> Am 6/7/2013 12:12, schrieb Erik Faye-Lund:\n>>> On Thu, Jun 6, 2013 at 7:40 PM, Jeff King wrote:\n>>>> On Thu, Jun 06, 2013 at 10:21:47AM -0700, Junio C Hamano wrote:\n>>>>\n>>>>>> The particular deficiency is that when a signal is raise()d whose SIG_DFL\n>>>>>> action will cause process death (SIGTERM in this case), the\n>>>>>> implementation of raise() just calls exit(3).\n>>>>>\n>>>>> After a bit of web searching, it seems to me that this behaviour of\n>>>>> raise() is in msvcrt, and compat/mingw.c::mingw_raise() just calls\n>>>>> that. In other words, \"the implementation of raise()\" is at an even\n>>>>> lower level than mingw/msys, and I would agree that it is a platform\n>>>>> issue.\n>>>>\n>>>> Yeah, if it were mingw_raise responsible for this, I would suggest using\n>>>> the POSIX shell \"128+sig\" instead. We could potentially check for\n>>>> SIG_DFL[1] mingw_raise and intercept and exit there. I don't know if\n>>>> that would create headaches or confusion for other msys programs,\n>>>> though. I'd leave that up to the msysgit people to decide whether it is\n>>>> worth the trouble.\n>>>>\n>>>\n>>> ...and here's the code to do just that:\n>>>\n>>> diff --git a/compat/mingw.c b/compat/mingw.c\n>>> index b295e2f..8b3c1b4 100644\n>>> --- a/compat/mingw.c\n>>> +++ b/compat/mingw.c\n>>> @@ -1573,7 +1573,8 @@ static HANDLE timer_event;\n>>> static HANDLE timer_thread;\n>>> static int timer_interval;\n>>> static int one_shot;\n>>> -static sig_handler_t timer_fn = SIG_DFL, sigint_fn = SIG_DFL;\n>>> +static sig_handler_t timer_fn = SIG_DFL, sigint_fn = SIG_DFL,\n>>> + sigterm_fn = SIG_DFL;\n>>>\n>>> /* The timer works like this:\n>>> * The thread, ticktack(), is a trivial routine that most of the time\n>>> @@ -1688,6 +1689,10 @@ sig_handler_t mingw_signal(int sig,\n>>> sig_handler_t handler)\n>>> sigint_fn = handler;\n>>> break;\n>>>\n>>> + case SIGTERM:\n>>> + sigterm_fn = handler;\n>>> + break;\n>>> +\n>>> default:\n>>> return signal(sig, handler);\n>>> }\n>>> @@ -1715,6 +1720,13 @@ int mingw_raise(int sig)\n>>> sigint_fn(SIGINT);\n>>> return 0;\n>>>\n>>> + case SIGTERM:\n>>> + if (sigterm_fn == SIG_DFL)\n>>> + exit(128 + SIGTERM);\n>>> + else if (sigterm_fn != SIG_IGN)\n>>> + sigterm_fn(SIGTERM);\n>>> + return 0;\n>>> +\n>>> default:\n>>> return raise(sig);\n>>> }\n>>\n>> That's pointless and does not work. The handler would only be called when\n>> raise() is called, but not when a SIGTERM is received, e.g., via Ctrl-C\n>> from the command line, because that route ends up in MSVCRT, which does\n>> not know about this handler.\n> \n> That's not entirely true. On Windows, there's only *one* way to\n> generate SIGTERM; \"signal(SIGTERM)\". Ctrl+C does not generate SIGTERM.\n> We generate SIGINT on Ctrl+C in mingw_fgetc, but the default Control+C\n> handler routine calls ExitProcess():\n> http://msdn.microsoft.com/en-us/library/windows/desktop/ms683242(v=vs.85).aspx\n\nBut a call to signal(SIGTERM, my_handler) should divert Ctrl+C to\nmy_handler. The unpatched version does, because MSVCRT now knows about\nmy_handler and sets things up so that the event handler calls my_handler.\nBut your patched version bypasses MSVCRT, and the default (whatever MSVCRT\nhas set up) happens, and my_handler is not called.\n\n-- Hannes\n"},{"id":"219626","messageId":"CABPQNSasTdkmpeGWb7_wZK2cQhiOyF7bX5ObcBg5kHm0KBGS5w@mail.gmail.com","threadId":"34030","inReplyTo":"51B1CFD4.3030908@viscovery.net","subject":"Re: [PATCH] t0005: skip signal death exit code test on Windows","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@gmail.com","sentAt":"2013-06-07T12:46:01Z","receivedAt":"2013-06-07T12:46:01Z","isPatch":true,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Fri, Jun 7, 2013 at 2:19 PM, Johannes Sixt wrote:\n> Am 6/7/2013 14:00, schrieb Erik Faye-Lund:\n>> On Fri, Jun 7, 2013 at 12:24 PM, Johannes Sixt wrote:\n>>> Am 6/7/2013 12:12, schrieb Erik Faye-Lund:\n>>>> On Thu, Jun 6, 2013 at 7:40 PM, Jeff King wrote:\n>>>>> On Thu, Jun 06, 2013 at 10:21:47AM -0700, Junio C Hamano wrote:\n>>>>>\n>>>>>>> The particular deficiency is that when a signal is raise()d whose SIG_DFL\n>>>>>>> action will cause process death (SIGTERM in this case), the\n>>>>>>> implementation of raise() just calls exit(3).\n>>>>>>\n>>>>>> After a bit of web searching, it seems to me that this behaviour of\n>>>>>> raise() is in msvcrt, and compat/mingw.c::mingw_raise() just calls\n>>>>>> that. In other words, \"the implementation of raise()\" is at an even\n>>>>>> lower level than mingw/msys, and I would agree that it is a platform\n>>>>>> issue.\n>>>>>\n>>>>> Yeah, if it were mingw_raise responsible for this, I would suggest using\n>>>>> the POSIX shell \"128+sig\" instead. We could potentially check for\n>>>>> SIG_DFL[1] mingw_raise and intercept and exit there. I don't know if\n>>>>> that would create headaches or confusion for other msys programs,\n>>>>> though. I'd leave that up to the msysgit people to decide whether it is\n>>>>> worth the trouble.\n>>>>>\n>>>>\n>>>> ...and here's the code to do just that:\n>>>>\n>>>> diff --git a/compat/mingw.c b/compat/mingw.c\n>>>> index b295e2f..8b3c1b4 100644\n>>>> --- a/compat/mingw.c\n>>>> +++ b/compat/mingw.c\n>>>> @@ -1573,7 +1573,8 @@ static HANDLE timer_event;\n>>>> static HANDLE timer_thread;\n>>>> static int timer_interval;\n>>>> static int one_shot;\n>>>> -static sig_handler_t timer_fn = SIG_DFL, sigint_fn = SIG_DFL;\n>>>> +static sig_handler_t timer_fn = SIG_DFL, sigint_fn = SIG_DFL,\n>>>> + sigterm_fn = SIG_DFL;\n>>>>\n>>>> /* The timer works like this:\n>>>> * The thread, ticktack(), is a trivial routine that most of the time\n>>>> @@ -1688,6 +1689,10 @@ sig_handler_t mingw_signal(int sig,\n>>>> sig_handler_t handler)\n>>>> sigint_fn = handler;\n>>>> break;\n>>>>\n>>>> + case SIGTERM:\n>>>> + sigterm_fn = handler;\n>>>> + break;\n>>>> +\n>>>> default:\n>>>> return signal(sig, handler);\n>>>> }\n>>>> @@ -1715,6 +1720,13 @@ int mingw_raise(int sig)\n>>>> sigint_fn(SIGINT);\n>>>> return 0;\n>>>>\n>>>> + case SIGTERM:\n>>>> + if (sigterm_fn == SIG_DFL)\n>>>> + exit(128 + SIGTERM);\n>>>> + else if (sigterm_fn != SIG_IGN)\n>>>> + sigterm_fn(SIGTERM);\n>>>> + return 0;\n>>>> +\n>>>> default:\n>>>> return raise(sig);\n>>>> }\n>>>\n>>> That's pointless and does not work. The handler would only be called when\n>>> raise() is called, but not when a SIGTERM is received, e.g., via Ctrl-C\n>>> from the command line, because that route ends up in MSVCRT, which does\n>>> not know about this handler.\n>>\n>> That's not entirely true. On Windows, there's only *one* way to\n>> generate SIGTERM; \"signal(SIGTERM)\". Ctrl+C does not generate SIGTERM.\n>> We generate SIGINT on Ctrl+C in mingw_fgetc, but the default Control+C\n>> handler routine calls ExitProcess():\n>> http://msdn.microsoft.com/en-us/library/windows/desktop/ms683242(v=vs.85).aspx\n>\n> But a call to signal(SIGTERM, my_handler) should divert Ctrl+C to\n> my_handler. The unpatched version does, because MSVCRT now knows about\n> my_handler and sets things up so that the event handler calls my_handler.\n\nNo, it does not:\n--->8---\n#include \n#include \n#include \n\nvoid my_handler(int signum)\n{\n printf(\"signal: %d\\n\", signum);\n exit(1);\n}\n\nint main()\n{\n signal(SIGTERM, my_handler);\n while (1);\n return 0;\n}\n--->8---\n\nThis quietly kills the process on Windows with MSVCRT's\nsignal-implementation. In fact SIGTERM isn't raised on Linux either.\nCtrl+C raises SIGINT, not SIGTERM.\n"},{"id":"219628","messageId":"51B1DB2A.2060306@viscovery.net","threadId":"34030","inReplyTo":"CABPQNSasTdkmpeGWb7_wZK2cQhiOyF7bX5ObcBg5kHm0KBGS5w@mail.gmail.com","subject":"Re: [PATCH] t0005: skip signal death exit code test on Windows","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2013-06-07T13:07:54Z","receivedAt":"2013-06-07T13:07:54Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 6/7/2013 14:46, schrieb Erik Faye-Lund:\n> On Fri, Jun 7, 2013 at 2:19 PM, Johannes Sixt wrote:\n>> Am 6/7/2013 14:00, schrieb Erik Faye-Lund:\n>>> On Fri, Jun 7, 2013 at 12:24 PM, Johannes Sixt wrote:\n>>>> Am 6/7/2013 12:12, schrieb Erik Faye-Lund:\n>>>>> diff --git a/compat/mingw.c b/compat/mingw.c\n>>>>> index b295e2f..8b3c1b4 100644\n>>>>> --- a/compat/mingw.c\n>>>>> +++ b/compat/mingw.c\n>>>>> @@ -1573,7 +1573,8 @@ static HANDLE timer_event;\n>>>>> static HANDLE timer_thread;\n>>>>> static int timer_interval;\n>>>>> static int one_shot;\n>>>>> -static sig_handler_t timer_fn = SIG_DFL, sigint_fn = SIG_DFL;\n>>>>> +static sig_handler_t timer_fn = SIG_DFL, sigint_fn = SIG_DFL,\n>>>>> + sigterm_fn = SIG_DFL;\n>>>>>\n>>>>> /* The timer works like this:\n>>>>> * The thread, ticktack(), is a trivial routine that most of the time\n>>>>> @@ -1688,6 +1689,10 @@ sig_handler_t mingw_signal(int sig,\n>>>>> sig_handler_t handler)\n>>>>> sigint_fn = handler;\n>>>>> break;\n>>>>>\n>>>>> + case SIGTERM:\n>>>>> + sigterm_fn = handler;\n>>>>> + break;\n>>>>> +\n>>>>> default:\n>>>>> return signal(sig, handler);\n>>>>> }\n>>>>> @@ -1715,6 +1720,13 @@ int mingw_raise(int sig)\n>>>>> sigint_fn(SIGINT);\n>>>>> return 0;\n>>>>>\n>>>>> + case SIGTERM:\n>>>>> + if (sigterm_fn == SIG_DFL)\n>>>>> + exit(128 + SIGTERM);\n>>>>> + else if (sigterm_fn != SIG_IGN)\n>>>>> + sigterm_fn(SIGTERM);\n>>>>> + return 0;\n>>>>> +\n>>>>> default:\n>>>>> return raise(sig);\n>>>>> }\n>>>>\n>>>> That's pointless and does not work. The handler would only be called when\n>>>> raise() is called, but not when a SIGTERM is received, e.g., via Ctrl-C\n>>>> from the command line, because that route ends up in MSVCRT, which does\n>>>> not know about this handler.\n>>>\n>>> That's not entirely true. On Windows, there's only *one* way to\n>>> generate SIGTERM; \"signal(SIGTERM)\". Ctrl+C does not generate SIGTERM.\n>>> We generate SIGINT on Ctrl+C in mingw_fgetc, but the default Control+C\n>>> handler routine calls ExitProcess():\n>>> http://msdn.microsoft.com/en-us/library/windows/desktop/ms683242(v=vs.85).aspx\n>>\n>> But a call to signal(SIGTERM, my_handler) should divert Ctrl+C to\n>> my_handler. The unpatched version does, because MSVCRT now knows about\n>> my_handler and sets things up so that the event handler calls my_handler.\n> \n> No, it does not:\n> Ctrl+C raises SIGINT, not SIGTERM.\n\n\n\nYou are right. Your change would \"fix\" SIGTERM as it can be raised only\nvia raise() on Windows nor can it be caught when a process is killed via\nmingw_kill(...,SIGTERM) by another process.\n\nBut then the current handling of SIGINT in compat/mingw.c is broken. The\nhandler is not propagated to MSVCRT, and after a SIGINT handler is\ninstalled, Ctrl+C still terminates the process. No?\n\nBTW, isn't mingw_signal() bogus in that it returns the SIGALRM handler\neven if a SIGINT handler is installed?\n\n-- Hannes\n"},{"id":"219631","messageId":"CABPQNSa1-dna_b+q-U6jgYy7p6zeiT7dAwu1Mw47QAezSNYKqA@mail.gmail.com","threadId":"34030","inReplyTo":"51B1DB2A.2060306@viscovery.net","subject":"Re: [PATCH] t0005: skip signal death exit code test on Windows","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@gmail.com","sentAt":"2013-06-07T14:20:31Z","receivedAt":"2013-06-07T14:20:31Z","isPatch":true,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Fri, Jun 7, 2013 at 3:07 PM, Johannes Sixt wrote:\n> Am 6/7/2013 14:46, schrieb Erik Faye-Lund:\n>> On Fri, Jun 7, 2013 at 2:19 PM, Johannes Sixt wrote:\n>>> Am 6/7/2013 14:00, schrieb Erik Faye-Lund:\n>>>> On Fri, Jun 7, 2013 at 12:24 PM, Johannes Sixt wrote:\n>>>>> Am 6/7/2013 12:12, schrieb Erik Faye-Lund:\n>>>>>> diff --git a/compat/mingw.c b/compat/mingw.c\n>>>>>> index b295e2f..8b3c1b4 100644\n>>>>>> --- a/compat/mingw.c\n>>>>>> +++ b/compat/mingw.c\n>>>>>> @@ -1573,7 +1573,8 @@ static HANDLE timer_event;\n>>>>>> static HANDLE timer_thread;\n>>>>>> static int timer_interval;\n>>>>>> static int one_shot;\n>>>>>> -static sig_handler_t timer_fn = SIG_DFL, sigint_fn = SIG_DFL;\n>>>>>> +static sig_handler_t timer_fn = SIG_DFL, sigint_fn = SIG_DFL,\n>>>>>> + sigterm_fn = SIG_DFL;\n>>>>>>\n>>>>>> /* The timer works like this:\n>>>>>> * The thread, ticktack(), is a trivial routine that most of the time\n>>>>>> @@ -1688,6 +1689,10 @@ sig_handler_t mingw_signal(int sig,\n>>>>>> sig_handler_t handler)\n>>>>>> sigint_fn = handler;\n>>>>>> break;\n>>>>>>\n>>>>>> + case SIGTERM:\n>>>>>> + sigterm_fn = handler;\n>>>>>> + break;\n>>>>>> +\n>>>>>> default:\n>>>>>> return signal(sig, handler);\n>>>>>> }\n>>>>>> @@ -1715,6 +1720,13 @@ int mingw_raise(int sig)\n>>>>>> sigint_fn(SIGINT);\n>>>>>> return 0;\n>>>>>>\n>>>>>> + case SIGTERM:\n>>>>>> + if (sigterm_fn == SIG_DFL)\n>>>>>> + exit(128 + SIGTERM);\n>>>>>> + else if (sigterm_fn != SIG_IGN)\n>>>>>> + sigterm_fn(SIGTERM);\n>>>>>> + return 0;\n>>>>>> +\n>>>>>> default:\n>>>>>> return raise(sig);\n>>>>>> }\n>>>>>\n>>>>> That's pointless and does not work. The handler would only be called when\n>>>>> raise() is called, but not when a SIGTERM is received, e.g., via Ctrl-C\n>>>>> from the command line, because that route ends up in MSVCRT, which does\n>>>>> not know about this handler.\n>>>>\n>>>> That's not entirely true. On Windows, there's only *one* way to\n>>>> generate SIGTERM; \"signal(SIGTERM)\". Ctrl+C does not generate SIGTERM.\n>>>> We generate SIGINT on Ctrl+C in mingw_fgetc, but the default Control+C\n>>>> handler routine calls ExitProcess():\n>>>> http://msdn.microsoft.com/en-us/library/windows/desktop/ms683242(v=vs.85).aspx\n>>>\n>>> But a call to signal(SIGTERM, my_handler) should divert Ctrl+C to\n>>> my_handler. The unpatched version does, because MSVCRT now knows about\n>>> my_handler and sets things up so that the event handler calls my_handler.\n>>\n>> No, it does not:\n>> Ctrl+C raises SIGINT, not SIGTERM.\n>\n> \n>\n> You are right. Your change would \"fix\" SIGTERM as it can be raised only\n> via raise() on Windows nor can it be caught when a process is killed via\n> mingw_kill(...,SIGTERM) by another process.\n>\n> But then the current handling of SIGINT in compat/mingw.c is broken. The\n> handler is not propagated to MSVCRT, and after a SIGINT handler is\n> installed, Ctrl+C still terminates the process. No?\n\nYeah, probably. I wasn't aware that it handled SIGINT, but yeah it\ndoes. So this was indeed a regression.\n\n> BTW, isn't mingw_signal() bogus in that it returns the SIGALRM handler\n> even if a SIGINT handler is installed?\n\nYep, that's a bug. Thanks for noticing.\n\nI've pushed out a branch here that tries to address these issues, but\nI haven't had time to test them. I'll post the series when I have. In\nthe mean time:\n\nhttps://github.com/kusma/git/tree/win32-signal-raise\n"},{"id":"219632","messageId":"CALkWK0k8m16oy7u+a8bHK93pRxfomOZDne3k0voVHLGULO+uiw@mail.gmail.com","threadId":"34030","inReplyTo":"alpine.DEB.2.02.1306061308100.29361@nftneq.ynat.uz","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-07T14:24:28Z","receivedAt":"2013-06-07T14:24:28Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"David Lang wrote:\n> Well, Felipe is saying that Perl is dieing and we should re-write everything\n> that exists in Perl to Ruby.\n\nI don't agree with that opinion. More generally, I think the entire\ndiscussion on what _should_ or _should not_ be done is rubbish. What\n_will_ and _will not_ happen depends on the patches contributors send.\n If a contributor sends a patch rewriting git-svn in ruby, then we\nhave a discussion: is anyone bored enough to pick up the task in the\nfirst place?\n\n> TIOBE index graph is \"press coverage\" as far as I'm concerned.\n\nWell, that's your definition of \"press coverage\" then. TIOBE index is\ngenerated from scraping the web to figure out which languages are\n\"living\", based on discussions between programmers (and yes, \"press\"\narticles). I do not have conclusive or \"undeniable\" proof that perl\nis dying, but the trends are indicative of a decline.\n\nI think Felipe is using the argument that perl is declining to answer\nthe question \"why didn't you write git-related in perl instead?\";\nthat's it.\n"},{"id":"219638","messageId":"CALkWK0nUoF2VX6Ns09vQHYo11520_4r9ikYmkZW108aQm1RpoQ@mail.gmail.com","threadId":"34030","inReplyTo":"alpine.DEB.1.00.1306070518510.28957@s15462909.onlinehome-server.info","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-07T15:20:36Z","receivedAt":"2013-06-07T15:20:36Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Johannes Schindelin wrote:\n> On Fri, 7 Jun 2013, Ramkumar Ramachandra wrote:\n>> Johannes Schindelin wrote:\n>> > My initial reaction, too. It was hard enough to get Perl included with Git\n>> > for Windows (because of that pesky Subversion dependency).\n>>\n>> Nevertheless, we had to do it, and we did it.\n>\n> That is not quite correct. *I* did it. Not *we*. And I will not do it\n> again.\n\nWhen I say \"we\", I mean the git community. You were incidentally part\nof the git community when we got perl included in git-for-windows.\nDon't make laughable assumptions about your indispensability: the\ncommunity will run fine without you (as it will run fine without me,\nfc, or even jc). There are enough and more smart diverse people to\nreplace the inactive people.\n\n>> We will do it again, if we get enough important code written in Ruby.\n>\n> I am a bit bored by this hypothetical talk. This hypothetical \"we will do\n> it again\", to be precise. Given my experience, it would be very painful if\n> \"enough important code\" was written in Ruby. Nobody would help me \"do it\n> again\". Just like nobody helps right now to upgrade to a newer Perl. Feel\n> free to prove me wrong. Until that time, I will firmly believe that there\n> is no \"we will do it again\".\n>\n> So here is a chance to prevent that: not repeat the mistake, and stay away\n> from language hell by avoiding to require yet another language.\n\nWhat is this \"mistake\" that you're talking about? We never should\nhave merged git-svn.perl in our tree, and lost out on an incredibly\nuseful piece of software?\n\nLet me make one thing clear: contributors are priority #1, and\neverything else is secondary. git.git is the sum of contributor\nwishes, and we exist to keep contributors productive. Yes, we have to\nforce some boring work onto contributors: nobody likes to write\ndocumentation, and we have guidelines to make sure that it gets done,\nfor instance.\n\nIf enough people are interested in porting git-related to Windows,\nthey will figure out how to ship ruby with git-for-windows. It is not\nrocket science.\n\n> As you know, there are very good reasons why I do not follow those mails.\n\nNo, I don't know the reason. I would guess that you are disinterested.\n\n> Exactly. Nobody really cares about keeping Git portable enough. Hence my\n> impression that this idea to start requiring yet another language for core\n> parts of Git is a bit misguided, and only logical from the point of view:\n> \"If you don't like it, why don't you install Linux?\" (which, just in case\n> you wondered, is a pretty naive way of looking at the real world).\n\nI am personally disinterested in git-for-windows, but I wouldn't make\nsuch a sweeping statement: there are some people interested in\ngit-for-windows.\n"},{"id":"219637","messageId":"7vd2ryueuu.fsf@alter.siamese.dyndns.org","threadId":"34030","inReplyTo":"CALkWK0k8m16oy7u+a8bHK93pRxfomOZDne3k0voVHLGULO+uiw@mail.gmail.com","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-06-07T15:20:41Z","receivedAt":"2013-06-07T15:20:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra writes:\n\n> I think Felipe is using the argument that perl is declining to answer\n> the question \"why didn't you write git-related in perl instead?\";\n> that's it.\n\nA question which nobody asked, I presume?\n\nI think we heard enough from packaging folks that a new dependency\nis unwelcome. Also we heard from no regular/high-value reviewers\nthat they feel comfortable reviewing additions in Ruby.\n\nSo at least for now, the conclusion is to take approach #1, i.e.\nsomebody who finds \"related\" a good addition rewrites it in Perl to\npromote it out of contrib/ once the design issues settle (of course\nit is still a possibility that no such volunteer appears).\n"},{"id":"219639","messageId":"CALkWK0=rZoCuw+_ovTu7iC49fDkyXCT9To=W8vTTkd4=+O+w_g@mail.gmail.com","threadId":"34030","inReplyTo":"7vd2ryueuu.fsf@alter.siamese.dyndns.org","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-07T15:28:01Z","receivedAt":"2013-06-07T15:28:01Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n> So at least for now, the conclusion is to take approach #1, i.e.\n> somebody who finds \"related\" a good addition rewrites it in Perl to\n> promote it out of contrib/ once the design issues settle (of course\n> it is still a possibility that no such volunteer appears).\n\nWe'll think about it if and when we get major ruby patches, and see\nperl patches declining. One git-related.rb doesn't say anything.\n"},{"id":"219644","messageId":"7vvc5puchl.fsf@alter.siamese.dyndns.org","threadId":"34030","inReplyTo":"vpq61xr8kpl.fsf@anie.imag.fr","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-06-07T16:11:50Z","receivedAt":"2013-06-07T16:11:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> * Ask the user to build external programs with\n>\n> make GIT_ROOT=where/git/lives/\n>\n> * or, ask users to checkout the external program as a subdirectory of\n> git.git to build it (for example, clang's build installation ask you\n> to put clang as a subdirectory of LLVM's tree).\n>\n>> But my main point is that I think it would be easier to phase out\n>> contrib/ if there were a good alternate way of providing visibility to\n>> \"satellite\" projects. [...] Perhaps ranking\n>> the tools based on the results of the Git user surveys would help bring\n>> the most popular to the top of each category.\n>\n> I think this is the most important point. A good example would be\n> git-multimail: for now, the shell version in contrib/ is somehow\n> considered as the official hook to send emails, just because it is in\n> contrib, while git-multimail is clearly superior (unless you don't have\n> a python interpreter on your server).\n\nI was envisioning to sift what are in contrib/ into these four\ncategories:\n\n (1) Ones that deserve to be Git subcommands;\n\n (2) Ones that are useful only in the context of using Git\n (e.g. hooks, completion scripts, credential and remote helpers);\n\n (3) Ones that are no longer useful;\n\n (4) Ones that primarily _use_ Git, not the other way around\n (i.e. opposite of category (2) which help use of Git).\n\nThe first category will live next to git-am.sh (i.e. in the longer\nterm when we restructure the source tree into src/, lib/, etc.,\ncandidates for new scripted subcommands move with the scripted\nPorcelains).\n\nThe second category will be in a separate hierarchy (perhaps\naddons/, hooks/, ..., but I am fine if we decide to keep them in\ncontrib/addons, contrib/hooks, etc.).\n\nThe last two categories will be removed; people are welcome to\ndecide which category between (3) and (4) each piece belongs to, and\npick up to start a standalone third-party project.\n\nThe multimail tool can be in the second category. It helps use of\nGit more than it is helped by using Git.\n\n> I'm not opposed to Junio's proposal to restrict contrib/ (although a bit\n> reluctant), but I think this should be done with care, at least to give\n> potential users a way to chose which tool to use (really, nobody want to\n> go use https://git.wiki.kernel.org/index.php/InterfacesFrontendsAndTools\n> to pick the right tool. It's a great list, but not a guide).\n"},{"id":"219657","messageId":"vpqhah9248u.fsf@anie.imag.fr","threadId":"34030","inReplyTo":"CALkWK0nUoF2VX6Ns09vQHYo11520_4r9ikYmkZW108aQm1RpoQ@mail.gmail.com","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-06-07T17:57:21Z","receivedAt":"2013-06-07T17:57:21Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Ramkumar Ramachandra writes:\n\n> Johannes Schindelin wrote:\n>> On Fri, 7 Jun 2013, Ramkumar Ramachandra wrote:\n>>> Johannes Schindelin wrote:\n>>> > My initial reaction, too. It was hard enough to get Perl included with Git\n>>> > for Windows (because of that pesky Subversion dependency).\n>>>\n>>> Nevertheless, we had to do it, and we did it.\n>>\n>> That is not quite correct. *I* did it. Not *we*. And I will not do it\n>> again.\n>\n> When I say \"we\", I mean the git community.\n\nI think it should be \"the Git for Windows community\", and my feeling is\nthat the community developing Git for POSIX systems is far more active\nthan the one making it work for Windows (although we may now have more\nwindows users than unix users).\n\nReading Git for Windows's FAQ\n( https://github.com/msysgit/msysgit/wiki/Frequently-Asked-Questions ),\nit seems rather clear that the TODO-list is already long to have a\ncorrect Perl support (I'm quite admirative of the work done already).\nThe POSIX guys shouldn't move faster than the Windows guys can follow.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"219658","messageId":"CALkWK0=RU1Sv9X6oyYYSSGfhEHYT6nbrr8gACN4XX-+=DTG54Q@mail.gmail.com","threadId":"34030","inReplyTo":"vpqhah9248u.fsf@anie.imag.fr","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-07T18:14:43Z","receivedAt":"2013-06-07T18:14:43Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Matthieu Moy wrote:\n> Reading Git for Windows's FAQ\n> ( https://github.com/msysgit/msysgit/wiki/Frequently-Asked-Questions ),\n> it seems rather clear that the TODO-list is already long to have a\n> correct Perl support (I'm quite admirative of the work done already).\n> The POSIX guys shouldn't move faster than the Windows guys can follow.\n\nHa! So, it's subversion and perlxs. I was wondering what was so\nnon-trivial about shipping a perl interpreter with Windows when dscho\nmentioned it.\n\nHopefully, I've done a little bit to improve the situation by pushing\nsvnrdump into core (I don't know if it has any users). On the git\nside, git-remote-testsvn is still a toy (which is a product of many\nmonths of work by db + 2x SoCs) compared to git-svn.perl. Yeah,\nsupporting subversion is extraordinarily painful.\n"},{"id":"219659","messageId":"CALkWK0mLVxKGvvYmREFyEkp6CgWuOEmML5V4ajF8R0SK62D4Gg@mail.gmail.com","threadId":"34030","inReplyTo":"vpqhah9248u.fsf@anie.imag.fr","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-07T18:24:03Z","receivedAt":"2013-06-07T18:24:03Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Matthieu Moy wrote:\n> I think it should be \"the Git for Windows community\", and my feeling is\n> that the community developing Git for POSIX systems is far more active\n> than the one making it work for Windows (although we may now have more\n> windows users than unix users).\n\nIf I can be excused for being frank, and saying something potentially\nblasphemous:\n\nI think he way forward on Windows is an implementation like libgit2 or\ngit# with some sort of gui/ide integration. I never understood why\nusers on Windows want to use something as POSIX'y as git.git.\nWouldn't they prefer some visual-studio integration thing? *scratches\nhead*\n"},{"id":"219660","messageId":"7vli6lu65v.fsf@alter.siamese.dyndns.org","threadId":"34030","inReplyTo":"vpqhah9248u.fsf@anie.imag.fr","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-06-07T18:28:28Z","receivedAt":"2013-06-07T18:28:28Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> The POSIX guys shouldn't move faster than the Windows guys can follow.\n\nThat is a very good summary.\n\nIt does not mean everybody must always crawl at the same pace as the\nslowest people. But it is one of the important things we should\nconsider, when we have choices to make (e.g. \"do we write this in\nPython\", \"do we write it using this Perl module we haven't depended\non\", etc.), to pick the one that does not make others work harder\nthan necessary---it affects the trade-offs.\n"},{"id":"219661","messageId":"vpqip1pzs9d.fsf@anie.imag.fr","threadId":"34030","inReplyTo":"CALkWK0mLVxKGvvYmREFyEkp6CgWuOEmML5V4ajF8R0SK62D4Gg@mail.gmail.com","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-06-07T18:32:14Z","receivedAt":"2013-06-07T18:32:14Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Ramkumar Ramachandra writes:\n\n> I think he way forward on Windows is an implementation like libgit2 or\n> git# with some sort of gui/ide integration. I never understood why\n> users on Windows want to use something as POSIX'y as git.git.\n\nWhether it's based on POSIX is an implementation detail for the user.\nThe real question is more command-line Vs GUI than POSIX/Win32. Some\nLinux users like GUI, some windows users use command-line. I tried IDE\nintegration with EGIT, and quite frankly I ended-up doing all the Git\nstuff in a terminal next to Eclipse.\n\n> Wouldn't they prefer some visual-studio integration thing? *scratches\n> head*\n\nVisual Studio now has official Git support from MS (based on libgit2 if\nI understood correctly). That's cool, but not a reason to kill msysgit\nIMHO ;-).\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"219662","messageId":"20130607183325.GC12924@google.com","threadId":"34030","inReplyTo":"CALkWK0mLVxKGvvYmREFyEkp6CgWuOEmML5V4ajF8R0SK62D4Gg@mail.gmail.com","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-06-07T18:33:25Z","receivedAt":"2013-06-07T18:33:25Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Ramkumar Ramachandra wrote:\n\n> I think he way forward on Windows is\n\nWhy is there only one way forward? Why do you get to pick it, given\nthat you've said you're not interested in working on it?\n\n[...]\n> I never understood why\n> users on Windows want to use something as POSIX'y as git.git.\n\nPlenty of users on Windows use a command line. I have even been such\na user from time to time. I'm quite grateful for Dscho et al's work\non making that less painful.\n\nJonathan\n"},{"id":"219669","messageId":"51B22A59.20607@case.edu","threadId":"34030","inReplyTo":"20130607183325.GC12924@google.com","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Matthew Ruffalo","fromEmail":"mmr15@case.edu","sentAt":"2013-06-07T18:45:45Z","receivedAt":"2013-06-07T18:45:45Z","isPatch":false,"sender":{"key":"mmr15@case.edu","avatar":null},"body":"Jonathan Nieder wrote:\n> Ramkumar Ramachandra wrote:\n>\n>> I think he way forward on Windows is\n> Why is there only one way forward? Why do you get to pick it, given\n> that you've said you're not interested in working on it?\n>\n> [...]\n>> I never understood why\n>> users on Windows want to use something as POSIX'y as git.git.\n> Plenty of users on Windows use a command line. I have even been such\n> a user from time to time. I'm quite grateful for Dscho et al's work\n> on making that less painful.\n>\n> Jonathan\nI agree completely. It's rare that I use Windows now, but a few years \nago I installed Cygwin on any machine that I would use in any serious \ncapacity. I haven't needed to do this since I started to use Git; the \nWindows installer ships all of the POSIX utilities that I need (with the \npossible exception of 'tree', and the caveat that scp can't handle files \n >= 2GB).\n\nI'm very appreciative of the work that's gone in to Git for Windows, and \nfrom my perspective it's a pleasant coincidence that it includes a POSIX \nshell and associated tools.\n\nMMR...\n"},{"id":"219668","messageId":"CALkWK0=mthyNQz9o6vG0b_yEMVL3GsB-dppNt6xgWTdUQQ5Zqw@mail.gmail.com","threadId":"34030","inReplyTo":"vpqip1pzs9d.fsf@anie.imag.fr","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-07T18:48:18Z","receivedAt":"2013-06-07T18:48:18Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Matthieu Moy wrote:\n> Visual Studio now has official Git support from MS (based on libgit2 if\n> I understood correctly). That's cool, but not a reason to kill msysgit\n> IMHO ;-).\n\nOh, I'm not interested in killing anything. If people want msysgit,\nthey will work on it: I'm nobody to say otherwise. I was just curious\nto know why msysgit is suffering from a lack of attention: fewer\nusers?\n\n> Whether it's based on POSIX is an implementation detail for the user.\n> The real question is more command-line Vs GUI than POSIX/Win32. Some\n> Linux users like GUI, some windows users use command-line. I tried IDE\n> integration with EGIT, and quite frankly I ended-up doing all the Git\n> stuff in a terminal next to Eclipse.\n\nI see. But isn't it possible to implement a CLI in libgit2 too, no?\n"},{"id":"219671","messageId":"vpq8v2lycd1.fsf@anie.imag.fr","threadId":"34030","inReplyTo":"CALkWK0=mthyNQz9o6vG0b_yEMVL3GsB-dppNt6xgWTdUQQ5Zqw@mail.gmail.com","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-06-07T19:00:58Z","receivedAt":"2013-06-07T19:00:58Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Ramkumar Ramachandra writes:\n\n>> Whether it's based on POSIX is an implementation detail for the user.\n>> The real question is more command-line Vs GUI than POSIX/Win32. Some\n>> Linux users like GUI, some windows users use command-line. I tried IDE\n>> integration with EGIT, and quite frankly I ended-up doing all the Git\n>> stuff in a terminal next to Eclipse.\n>\n> I see. But isn't it possible to implement a CLI in libgit2 too, no?\n\nYes (there have actually been several attempts at this like\nhttps://github.com/Romain-Geissler/git2 and\nhttps://github.com/vfr-nl/git2/), but there are a *lot* of stuff that\nare in git.git and not in libgit2.\n\nI'd love to see Git re-implemented on top of libgit2, but that's not\ngoing to happen tomorrow :-\\.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"219674","messageId":"CAMP44s2f2RBGd0VwJaSB1FkHBXRGhrTs_sA80kcinmpzJX8UDg@mail.gmail.com","threadId":"34030","inReplyTo":"7vd2ryueuu.fsf@alter.siamese.dyndns.org","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-07T19:04:11Z","receivedAt":"2013-06-07T19:04:11Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Fri, Jun 7, 2013 at 10:20 AM, Junio C Hamano wrote:\n> Ramkumar Ramachandra writes:\n>\n>> I think Felipe is using the argument that perl is declining to answer\n>> the question \"why didn't you write git-related in perl instead?\";\n>> that's it.\n>\n> A question which nobody asked, I presume?\n>\n> I think we heard enough from packaging folks that a new dependency\n> is unwelcome.\n\nWhat are you talking about? Which are these \"packaging folks\" we heard from?\n\n> Also we heard from no regular/high-value reviewers\n> that they feel comfortable reviewing additions in Ruby.\n\nCorrection; *current* regular/high-value reviewers.\n\n> So at least for now, the conclusion is to take approach #1, i.e.\n> somebody who finds \"related\" a good addition rewrites it in Perl to\n> promote it out of contrib/ once the design issues settle (of course\n> it is still a possibility that no such volunteer appears).\n\nRegardless of what you conclude, Perl still continues to die, and by\nclinging to a dying language, all we do is hurt the project.\n\nThere's tons of people that are familiar with Git and Ruby, but these\npeople are not in this mailing list because there's nothing for them\nto discuss, because Git doesn't use Ruby. By making conclusions based\non the comments from people who do follow the mailing list\n*currently*, you are being biased towards the status quo.\n\nIt's no surprise that you decided to keep the status quo.\n\nWe could change, and we would probably receive a big influx of fresh\ncontributors happy that they can contribute in their favorite\nlanguage. But we won't do that, why? Because you already decided\nthat's not going to happen, because you are making the false\nassumption that things in the future can only be like things have been\nin the past.\n\n-- \nFelipe Contreras\n"},{"id":"219675","messageId":"CAMP44s0UkmVc7kLo6vD2=Cn-SN+mFrGO_udJcbhC-h=0yx_pqQ@mail.gmail.com","threadId":"34030","inReplyTo":"vpq8v2lycd1.fsf@anie.imag.fr","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-07T19:10:12Z","receivedAt":"2013-06-07T19:10:12Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Fri, Jun 7, 2013 at 2:00 PM, Matthieu Moy\n wrote:\n> Ramkumar Ramachandra writes:\n>\n>>> Whether it's based on POSIX is an implementation detail for the user.\n>>> The real question is more command-line Vs GUI than POSIX/Win32. Some\n>>> Linux users like GUI, some windows users use command-line. I tried IDE\n>>> integration with EGIT, and quite frankly I ended-up doing all the Git\n>>> stuff in a terminal next to Eclipse.\n>>\n>> I see. But isn't it possible to implement a CLI in libgit2 too, no?\n>\n> Yes (there have actually been several attempts at this like\n> https://github.com/Romain-Geissler/git2 and\n> https://github.com/vfr-nl/git2/), but there are a *lot* of stuff that\n> are in git.git and not in libgit2.\n>\n> I'd love to see Git re-implemented on top of libgit2, but that's not\n> going to happen tomorrow :-\\.\n\nSpecially not if we *always* keep the status quo, and don't make\nbetter use of C and scripting languages. One of the advantages of Ruby\nis that it can be very easily extended from C. I have never seen an\neasier way to write bindings than in Ruby. If we allowed Ruby to be in\nthe core, it would make sense to create official Ruby bindings, and\nthat would create an enormous motivation for libigit/libgit2 to be\ncomplete.\n\nBut if we always keep the status quo, there will never be that much\nmotivation for such an effort.\n\n-- \nFelipe Contreras\n"},{"id":"219677","messageId":"CAMP44s3xbvaftqbWA97S=OEFguCbRdA45ryEXECnL7yDf+L0Uw@mail.gmail.com","threadId":"34030","inReplyTo":"alpine.DEB.1.00.1306070518510.28957@s15462909.onlinehome-server.info","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-07T19:14:13Z","receivedAt":"2013-06-07T19:14:13Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Jun 6, 2013 at 10:25 PM, Johannes Schindelin\n wrote:\n> On Fri, 7 Jun 2013, Ramkumar Ramachandra wrote:\n>\n>> Johannes Schindelin wrote:\n>> > My initial reaction, too. It was hard enough to get Perl included with Git\n>> > for Windows (because of that pesky Subversion dependency).\n>>\n>> Nevertheless, we had to do it, and we did it.\n>\n> That is not quite correct. *I* did it. Not *we*. And I will not do it\n> again.\n\nThat's fine, I can do it. I bet it will be easy.\n\nWhile at it, why not re-evaluate the whole msysgit approach? I bet we\ndon't need a whole separate project just to create a Windows\ninstaller. I've written Windows installers before, it's very easy to\ndo from Linux.\n\n>> Rewriting everything in C? Is anyone bored enough to pick up this task?\n>> Bourne shell is a great language for prototyping; git-rebase.sh (and\n>> friends), git-stash.sh, git-pull.sh are doing just fine. Sure, it makes\n>> sense to do heavy-lifting in C, and this is happening as it has always\n>> been happening (remember git-commit.sh?). If you followed the list\n>> emails, you'd know that Felipe is looking into delegating large portions\n>> of the work done by git-rebase.sh to sequencer.c.\n>\n> As you know, there are very good reasons why I do not follow those mails.\n\nTo the detriment on the project.\n\n-- \nFelipe Contreras\n"},{"id":"219679","messageId":"CAMP44s1+ax-Z=CRsSFEZHYKrBA1voQFv1=Vso9RkWDwEqhZR-A@mail.gmail.com","threadId":"34030","inReplyTo":"alpine.DEB.2.02.1306061308100.29361@nftneq.ynat.uz","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-07T19:21:24Z","receivedAt":"2013-06-07T19:21:24Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Jun 6, 2013 at 3:19 PM, David Lang wrote:\n> On Fri, 7 Jun 2013, Ramkumar Ramachandra wrote:\n>\n>> David Lang wrote:\n>>>\n>>> Perl use may or may not be declining (depending on how you measure it),\n>>> but\n>>> are you really willing to take on the task of re-writing everything\n>>> that's\n>>> in Perl into another language and force all developers of scripts to\n>>> learn\n>>> that other language? what's the ROI of this?\n>>\n>>\n>> Let's not talk hypotheticals. git-svn.perl (+ perl/SVN/*.pl) is\n>> absolutely massive. It's an incredibly useful tool in that it\n>> actually works, and that there is nothing replacing it in the\n>> foreseeable future. This monster was written almost entirely by one\n>> brilliant person, and nobody is going to rewrite it. We don't start a\n>> huge discussion about what languages are \"approved\" before accepting\n>> such a contribution: if the contributor wants to write something in a\n>> dominant language (Perl in this case), and it's going to be useful, we\n>> merge it. End of story.\n>\n>\n> Well, Felipe is saying that Perl is dieing and we should re-write everything\n> that exists in Perl to Ruby.\n\nNo, I said we should try to move away from Perl. Move stuff to C,\nshell scripts, and yeah, Ruby.\n\n>> Why are we discussing something that is indeterminate? It is\n>> impossible to foresee the future, but that is no reason to freeze\n>> _present_ development.\n>\n> and it's not a reason to throw away existing stuff based on the argument\n> that Perl is dieing\n\nWho said anything about throwing away code?\n\n>> Nobody claimed that \"press coverage\" is a good metric. We can only\n>> talk about facts, and Felipe already showed you a TIOBE index graph.\n>> If you have overwhelming _evidence_ that Ruby is a weak language that\n>> will die soon, share it: otherwise, I see no value in this discussion.\n>\n>\n> TIOBE index graph is \"press coverage\" as far as I'm concerned.\n>\n> I'm not saying that Ruby in particular has a fatal flaw, I'm just\n> questioning the \"Perl is dead, re-write everything in Ruby\" mantra.\n>\n> The language that you choose to use when writing a new application is\n> related to things related to that type of application.\n>\n> Ruby is not an extremely common language for sysadmins to use.\n\nWho said we need a language commonly used by sysadmins for our Git core?\n\n> Perl remains a common language for these sorts of tasks, even if it's not\n> used for user visible applications.\n\nRuby is pretty much a replacement for Perl. For every task Perl is\ngood, Ruby also is. Ruby's syntax even borrows from Perl.\n\nThe difference is; Ruby is better for many more tasks that suck in Perl.\n\n> Arguing that Perl is dieing, we need to abandon it is just wrong.\n\nStraw man. Nobody is arguing that.\n\nI said we should try to avoid it, not abandon it immediately.\n\n-- \nFelipe Contreras\n"},{"id":"219681","messageId":"CALkWK0m4V4KYyKW8KJMRsCgOxqcLi0XDYZvS4w++6BKVVvioyw@mail.gmail.com","threadId":"34030","inReplyTo":"CAMP44s2f2RBGd0VwJaSB1FkHBXRGhrTs_sA80kcinmpzJX8UDg@mail.gmail.com","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-07T19:27:33Z","receivedAt":"2013-06-07T19:27:33Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Felipe Contreras wrote:\n>> Also we heard from no regular/high-value reviewers\n>> that they feel comfortable reviewing additions in Ruby.\n>\n> Correction; *current* regular/high-value reviewers.\n\nCorrect. The opinions of inactive community members and\nnon-contributors are less useful.\n\n> We could change, and we would probably receive a big influx of fresh\n> contributors happy that they can contribute in their favorite\n> language. But we won't do that, why? Because you already decided\n> that's not going to happen, because you are making the false\n> assumption that things in the future can only be like things have been\n> in the past.\n\nOkay, so here's the deal: commit a lot of good ruby code to contrib*,\nand attract users/ contributors. Eventually, if you're right about\ngit.git growing a healthy ruby ecosystem, we'll get ruby in core. As\nI've said multiple times, this agenda-based approach just sucks,\nbecause we can't predict the future.\n\n* I'll help out in whatever little way I can\n"},{"id":"219682","messageId":"CAMP44s0ko1T96J7u3xdrZgxnvG_JwizLyWqFuginujggDCQD_w@mail.gmail.com","threadId":"34030","inReplyTo":"20130606213124.GB12924@google.com","subject":"Re: Dependencies and packaging (Re: [Administrivia] On ruby and contrib/)","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-07T19:29:37Z","receivedAt":"2013-06-07T19:29:37Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Jun 6, 2013 at 4:31 PM, Jonathan Nieder wrote:\n> Ramkumar Ramachandra wrote:\n>\n>> Git is probably the _last_ thing\n>> to be complaining about when it comes to packaging.\n>\n> It would be nice if contrib/ files supported the usual \"make; make\n> install; make clean\" targets. That's missing functionality that does\n> matter to at least one packager.\n>\n> It would be nice if the dependencies associated to each piece of\n> functionality or makefile flag were documented more clearly.\n> Currently when e.g. features of gitweb gain dependencies I don't\n> notice until the testsuite fails.\n\nHere's a good example how to do that:\nhttps://github.com/felipec/git/blob/fc/master/contrib/remote-helpers/Makefile\n\n-- \nFelipe Contreras\n"},{"id":"219687","messageId":"CALkWK0nfOSC8Q9WiU3SG437=7aQrD5nMhCGxung_OenUxiCDAg@mail.gmail.com","threadId":"34030","inReplyTo":"CALkWK0m4V4KYyKW8KJMRsCgOxqcLi0XDYZvS4w++6BKVVvioyw@mail.gmail.com","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-07T19:38:53Z","receivedAt":"2013-06-07T19:38:53Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Ramkumar Ramachandra wrote:\n> commit a lot of good ruby code to contrib*\n\nOh, by the way: I have a project idea. There's this really popular\nproject called hub[1] that has an implementation of the GitHub API in\nruby. Unfortunately, it's a terrible piece of software because it\ncreates an extra layer of indirection by putting a ruby wrapper on top\nof git, and this slows git down: I cannot tolerate even a microsecond\nof delay in git. Maybe it's worth ripping out the GitHub API\nimplementation and writing some useful subcommands?\n\n[1]: https://github.com/defunkt/hub\n"},{"id":"219688","messageId":"CALkWK0ntWzJj1AkDzv9VvS+7e3B17HFkZLQhAu-7pQv6M7=dkw@mail.gmail.com","threadId":"34030","inReplyTo":"CAMP44s3xbvaftqbWA97S=OEFguCbRdA45ryEXECnL7yDf+L0Uw@mail.gmail.com","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-07T19:41:37Z","receivedAt":"2013-06-07T19:41:37Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Felipe Contreras wrote:\n> While at it, why not re-evaluate the whole msysgit approach? I bet we\n> don't need a whole separate project just to create a Windows\n> installer. I've written Windows installers before, it's very easy to\n> do from Linux.\n\nYeah, taking the pain out of msysgit packaging would be a great way to\ncounter this new-dependency-fud. The main problem, as mm pointed out\nis subversion + perlxs [1]. Any idea how to tackle that?\n\n[1]: https://github.com/msysgit/msysgit/wiki/Frequently-Asked-Questions\n"},{"id":"219691","messageId":"7vsj0tsnjw.fsf@alter.siamese.dyndns.org","threadId":"34030","inReplyTo":"CAMP44s2f2RBGd0VwJaSB1FkHBXRGhrTs_sA80kcinmpzJX8UDg@mail.gmail.com","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-06-07T19:55:47Z","receivedAt":"2013-06-07T19:55:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n>> I think we heard enough from packaging folks that a new dependency\n>> is unwelcome.\n>\n> What are you talking about? Which are these \"packaging folks\" we heard from?\n\nDscho is one of the primary people behind msysgit effort, and I\nconsulted with others from the circle with an draft before I sent\nthe message to the list for sanity checking (fearing that I may be\nworrying about adding new dependencies needlessly). Jonathan\npackages git for Debian and he is negative on adding new dependency\nneedlessly. It was unexpected that we hear from a pkgsrc person but\nthe response was also negative.\n\n>> Also we heard from no regular/high-value reviewers\n>> that they feel comfortable reviewing additions in Ruby.\n>\n> Correction; *current* regular/high-value reviewers.\n\nThat is exactly what I meant.\n\nThe code review is not only about following best practices in the\nimplementation language. If somebody who is an expert in a language\nwe do not currently depend on, but who does not know how the parts\nof Git are supposed to fit together enough to judge the soundness of\nthe design of new code written in that new language, or does not\nknow how the tests, documentation and log messages are supposed to\nwritten around here, that person cannot be the only reviewer for\nchanges written in that language to ensure quality standard.\n\nThe reviewer pool for code written in a new language _must_ be\nseeded by some from the current set of reviewers whose judgement\nI/we can trust.\n"},{"id":"219695","messageId":"CAMP44s2FaoL5T+eG9mKua1U5PN9SURtXOE_YE8WO8cUusf=mBw@mail.gmail.com","threadId":"34030","inReplyTo":"7vsj0tsnjw.fsf@alter.siamese.dyndns.org","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-07T20:24:44Z","receivedAt":"2013-06-07T20:24:44Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Fri, Jun 7, 2013 at 2:55 PM, Junio C Hamano wrote:\n> Felipe Contreras writes:\n>\n>>> I think we heard enough from packaging folks that a new dependency\n>>> is unwelcome.\n>>\n>> What are you talking about? Which are these \"packaging folks\" we heard from?\n>\n> Dscho is one of the primary people behind msysgit effort, and I\n> consulted with others from the circle with an draft before I sent\n> the message to the list for sanity checking (fearing that I may be\n> worrying about adding new dependencies needlessly).\n\nHe said he won't do it, but I said I would. Doesn't that solve the problem?\n\n> Jonathan\n> packages git for Debian and he is negative on adding new dependency\n> needlessly.\n\nI don't see any comment from Jonathan.\n\n> It was unexpected that we hear from a pkgsrc person but\n> the response was also negative.\n\nYou mean Greg Troxel? He is only one of the persons that help, and I\ndid shut down his argument, didn't I?\n\n>>> Also we heard from no regular/high-value reviewers\n>>> that they feel comfortable reviewing additions in Ruby.\n>>\n>> Correction; *current* regular/high-value reviewers.\n>\n> That is exactly what I meant.\n>\n> The code review is not only about following best practices in the\n> implementation language. If somebody who is an expert in a language\n> we do not currently depend on, but who does not know how the parts\n> of Git are supposed to fit together enough to judge the soundness of\n> the design of new code written in that new language, or does not\n> know how the tests, documentation and log messages are supposed to\n> written around here, that person cannot be the only reviewer for\n> changes written in that language to ensure quality standard.\n>\n> The reviewer pool for code written in a new language _must_ be\n> seeded by some from the current set of reviewers whose judgement\n> I/we can trust.\n\nBy that standard nothing will ever change. Ever.\n\nEven twenty years from now, you will still only trust people that are\nfamiliar with shell, Perl, and C. Because the only way to gain your\ntrust, is by being proficient in shell, Perl, and C.\n\n-- \nFelipe Contreras\n"},{"id":"219777","messageId":"CACsJy8BMrxLZFGQfUN1YCG+qkAj-91aYkc54R5O4iqgXUNeQOw@mail.gmail.com","threadId":"34030","inReplyTo":"alpine.DEB.1.00.1306061818191.28957@s15462909.onlinehome-server.info","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2013-06-08T02:17:40Z","receivedAt":"2013-06-08T02:17:40Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Thu, Jun 6, 2013 at 11:22 PM, Johannes Schindelin\n wrote:\n> Hi Greg,\n>\n> On Thu, 6 Jun 2013, Greg Troxel wrote:\n>\n>> As one of the people who helps maintain git packages in pkgsrc, my\n>> initial reaction is negative to adding a ruby dependency.\n>\n> My initial reaction, too. It was hard enough to get Perl included with Git\n> for Windows (because of that pesky Subversion dependency).\n>\n> As you can see from the commit history, I was the primary force behind\n> trying to get everything \"core\" in Git away from requiring scripting\n> languages (I think it is an awesome thing to provide APIs for as many\n> languages as possible, but a not-so-cool thing to use more than one\n> language in the core code). It does not seem that anybody picked up that\n> task when I left, though.\n\nNobody seems to mention it yet. There's another reason behind the C\nrewrite effort: fork is costly on Windows. The C rewrite allows us to\nrun with one process (most of the time). This applies for shell, perl\nand even ruby scripts because libgit.a is never meant to be used\noutside git.c context (unlike libgit2). In this regard, ruby is just\nas bad as currently supported non-C languages.\n--\nDuy\n"},{"id":"219778","messageId":"CACsJy8BngfgTfXDXvzjmu0t__86LAivP+_VhGUSXmG5hTnM9SA@mail.gmail.com","threadId":"34030","inReplyTo":"CAMP44s2FaoL5T+eG9mKua1U5PN9SURtXOE_YE8WO8cUusf=mBw@mail.gmail.com","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2013-06-08T02:23:01Z","receivedAt":"2013-06-08T02:23:01Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Sat, Jun 8, 2013 at 3:24 AM, Felipe Contreras\n wrote:\n>> The reviewer pool for code written in a new language _must_ be\n>> seeded by some from the current set of reviewers whose judgement\n>> I/we can trust.\n>\n> By that standard nothing will ever change. Ever.\n>\n> Even twenty years from now, you will still only trust people that are\n> familiar with shell, Perl, and C. Because the only way to gain your\n> trust, is by being proficient in shell, Perl, and C.\n\nI don't see why a trusted person cannot learn a new language and\nconvince the community to give it a try (well given that enough\nreviewers support the new language, which was Junio's point).\n--\nDuy\n"},{"id":"219793","messageId":"CAMP44s08V1=nVbeo6r8UVT3Fd0=iSpRohinqf77Tmu4=xpDHeg@mail.gmail.com","threadId":"34030","inReplyTo":"CACsJy8BMrxLZFGQfUN1YCG+qkAj-91aYkc54R5O4iqgXUNeQOw@mail.gmail.com","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-08T10:02:44Z","receivedAt":"2013-06-08T10:02:44Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Fri, Jun 7, 2013 at 9:17 PM, Duy Nguyen wrote:\n> On Thu, Jun 6, 2013 at 11:22 PM, Johannes Schindelin\n> wrote:\n>> Hi Greg,\n>>\n>> On Thu, 6 Jun 2013, Greg Troxel wrote:\n>>\n>>> As one of the people who helps maintain git packages in pkgsrc, my\n>>> initial reaction is negative to adding a ruby dependency.\n>>\n>> My initial reaction, too. It was hard enough to get Perl included with Git\n>> for Windows (because of that pesky Subversion dependency).\n>>\n>> As you can see from the commit history, I was the primary force behind\n>> trying to get everything \"core\" in Git away from requiring scripting\n>> languages (I think it is an awesome thing to provide APIs for as many\n>> languages as possible, but a not-so-cool thing to use more than one\n>> language in the core code). It does not seem that anybody picked up that\n>> task when I left, though.\n>\n> Nobody seems to mention it yet. There's another reason behind the C\n> rewrite effort: fork is costly on Windows. The C rewrite allows us to\n> run with one process (most of the time). This applies for shell, perl\n> and even ruby scripts because libgit.a is never meant to be used\n> outside git.c context (unlike libgit2). In this regard, ruby is just\n> as bad as currently supported non-C languages.\n\nAre you sure?\n\n---\n#!/bin/sh\n\ncat > /tmp/test <\n#include \n#include \n\n#undef NORETURN\n#undef PATH_SEP\n\n#include \n\nstatic VALUE shellwords;\n\nstruct cmd_struct {\n\tconst char *cmd;\n\tint (*fn)(int, const char **, const char *);\n\tint option;\n};\n\n#define RUN_SETUP (1 << 0)\n#define RUN_SETUP_GENTLY (1 << 1)\n#define USE_PAGER (1 << 2)\n#define NEED_WORK_TREE (1 << 3)\n\nstatic struct cmd_struct commands[] = {\n\t{ \"rev-parse\", cmd_rev_parse },\n\t{ \"show\", cmd_show, RUN_SETUP },\n};\n\nstatic VALUE git_rb_backticks(int o_argc, VALUE *o_argv, VALUE ctx)\n{\n\tint argc, i, old;\n\tint pipefd[2];\n\tconst char **argv;\n\tchar buf[0x1000];\n\tVALUE command;\n\tint do_read;\n\tstruct cmd_struct *cmd = NULL;\n\tconst char *prefix = NULL;\n\n\tif (strncmp(RSTRING_PTR(o_argv[0]), \"git \", 4)) {\n\t\tVALUE port, result;\n\t\tport = rb_funcall(rb_cIO, rb_intern(\"popen\"), 1, o_argv[0]);\n\t\tresult = rb_funcall(port, rb_intern(\"read\"), 0);\n\t\trb_funcall(result, rb_intern(\"chomp!\"), 0);\n\t\trb_io_close(port);\n\t\treturn result;\n\t}\n\n\tcommand = rb_funcall(shellwords, rb_intern(\"shellsplit\"), 1, o_argv[0]);\n\trb_ary_shift(command);\n\n\targc = RARRAY_LEN(command);\n\targv = xcalloc(sizeof(*argv), argc);\n\n\tVALUE *rarray = RARRAY_PTR(command);\n\tfor (i = 0; i < argc; i++)\n\t\targv[i] = RSTRING_PTR(rarray[i]);\n\n\told = dup(1);\n\ti = pipe(pipefd);\n\tdup2(pipefd[1], 1);\n\tclose(pipefd[1]);\n\n\tfor (i = 0; i < ARRAY_SIZE(commands); i++) {\n\t\tstruct cmd_struct *p = &commands[i];\n\t\tif (strcmp(p->cmd, argv[0]))\n\t\t\tcontinue;\n\t\tcmd = p;\n\t}\n\n\tif (!cmd)\n\t\trb_raise(rb_eArgError, \"unknown command: %s\", argv[0]);\n\n\tif (cmd->option & RUN_SETUP)\n\t\tprefix = setup_git_directory();\n\n\ti = cmd->fn(argc, argv, prefix);\n\trb_last_status_set(i, getpid());\n\n\tfflush(stdout);\n\tdup2(old, 1);\n\n\ti = read(pipefd[0], buf, sizeof(buf));\n\tif (buf[i - 1] == '\\n')\n\t\ti -= 1;\n\tbuf[i] = '\\0';\n\n\treturn rb_str_new(buf, i);\n}\n\nvoid Init_git(void)\n{\n\trb_require(\"shellwords\");\n\tshellwords = rb_define_module(\"Shellwords\");\n\trb_define_global_function(\"`\", git_rb_backticks, -1);\n}\n"},{"id":"219794","messageId":"CAMP44s1JdakrtcaXbO0rxob7+NPCo-Bp4uGO6-6-o3ACriOwhg@mail.gmail.com","threadId":"34030","inReplyTo":"CACsJy8BngfgTfXDXvzjmu0t__86LAivP+_VhGUSXmG5hTnM9SA@mail.gmail.com","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-08T10:08:28Z","receivedAt":"2013-06-08T10:08:28Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Fri, Jun 7, 2013 at 9:23 PM, Duy Nguyen wrote:\n> On Sat, Jun 8, 2013 at 3:24 AM, Felipe Contreras\n> wrote:\n>>> The reviewer pool for code written in a new language _must_ be\n>>> seeded by some from the current set of reviewers whose judgement\n>>> I/we can trust.\n>>\n>> By that standard nothing will ever change. Ever.\n>>\n>> Even twenty years from now, you will still only trust people that are\n>> familiar with shell, Perl, and C. Because the only way to gain your\n>> trust, is by being proficient in shell, Perl, and C.\n>\n> I don't see why a trusted person cannot learn a new language and\n> convince the community to give it a try (well given that enough\n> reviewers support the new language, which was Junio's point).\n\nI do. Raise your hand if you are interested in giving a try to Ruby\nfor Git's core given that somebody gives convincing reasons?\n\nHow many hands do you expect?\n\n-- \nFelipe Contreras\n"},{"id":"219799","messageId":"CACsJy8A7pP=Hj2=-6iCqK9qXrC0pe2-A-YE4qoSRxhTX7=OvWQ@mail.gmail.com","threadId":"34030","inReplyTo":"CAMP44s1JdakrtcaXbO0rxob7+NPCo-Bp4uGO6-6-o3ACriOwhg@mail.gmail.com","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2013-06-08T11:20:54Z","receivedAt":"2013-06-08T11:20:54Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Sat, Jun 8, 2013 at 5:08 PM, Felipe Contreras\n wrote:\n> On Fri, Jun 7, 2013 at 9:23 PM, Duy Nguyen wrote:\n>> On Sat, Jun 8, 2013 at 3:24 AM, Felipe Contreras\n>> wrote:\n>>>> The reviewer pool for code written in a new language _must_ be\n>>>> seeded by some from the current set of reviewers whose judgement\n>>>> I/we can trust.\n>>>\n>>> By that standard nothing will ever change. Ever.\n>>>\n>>> Even twenty years from now, you will still only trust people that are\n>>> familiar with shell, Perl, and C. Because the only way to gain your\n>>> trust, is by being proficient in shell, Perl, and C.\n>>\n>> I don't see why a trusted person cannot learn a new language and\n>> convince the community to give it a try (well given that enough\n>> reviewers support the new language, which was Junio's point).\n>\n> I do. Raise your hand if you are interested in giving a try to Ruby\n> for Git's core given that somebody gives convincing reasons?\n\nPersonally, no additional runtime dependency > Ruby > Python. I don't\nthink Ruby is available on SunOS and I prefer not to build and install\nPython nor Ruby myself to be able to use Git. So no hands from me.\n\n> How many hands do you expect?\n\nIf not many hands show up, the Git community clearly is not ready to\nadopt Ruby. Maybe ask again next year when Ruby is getting more\npopular?\n--\nDuy\n"},{"id":"219800","messageId":"CACsJy8DTKr5Fy3-+8ShUrWQrKC2_7EmLHwyVgQ9Aq5JDOFBAqA@mail.gmail.com","threadId":"34030","inReplyTo":"CAMP44s08V1=nVbeo6r8UVT3Fd0=iSpRohinqf77Tmu4=xpDHeg@mail.gmail.com","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2013-06-08T11:28:56Z","receivedAt":"2013-06-08T11:28:56Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Sat, Jun 8, 2013 at 5:02 PM, Felipe Contreras\n wrote:\n> On Fri, Jun 7, 2013 at 9:17 PM, Duy Nguyen wrote:\n>> On Thu, Jun 6, 2013 at 11:22 PM, Johannes Schindelin\n>> wrote:\n>>> Hi Greg,\n>>>\n>>> On Thu, 6 Jun 2013, Greg Troxel wrote:\n>>>\n>>>> As one of the people who helps maintain git packages in pkgsrc, my\n>>>> initial reaction is negative to adding a ruby dependency.\n>>>\n>>> My initial reaction, too. It was hard enough to get Perl included with Git\n>>> for Windows (because of that pesky Subversion dependency).\n>>>\n>>> As you can see from the commit history, I was the primary force behind\n>>> trying to get everything \"core\" in Git away from requiring scripting\n>>> languages (I think it is an awesome thing to provide APIs for as many\n>>> languages as possible, but a not-so-cool thing to use more than one\n>>> language in the core code). It does not seem that anybody picked up that\n>>> task when I left, though.\n>>\n>> Nobody seems to mention it yet. There's another reason behind the C\n>> rewrite effort: fork is costly on Windows. The C rewrite allows us to\n>> run with one process (most of the time). This applies for shell, perl\n>> and even ruby scripts because libgit.a is never meant to be used\n>> outside git.c context (unlike libgit2). In this regard, ruby is just\n>> as bad as currently supported non-C languages.\n>\n> Are you sure?\n\nI'm not saying you can't. I'm saying it's not meant to be used that\nway. Which means there may be problems lurking around. You can write a\nruby extension to access libgit.a, sure, but how many people on this\nlist understand git design and limits _and_ ruby's good enough to spot\nthe bugs? If a bug is found and requires major restructuring in\nlibgit.a, how are you sure it's worth the effort and does not\ndestablize the rest of git? A better way to do it is linking against\nlibgit2.\n\n>\n> ---\n> #!/bin/sh\n>\n> cat > /tmp/test < require './git'\n>\n> (1..100).each do |e|\n> puts \\`git rev-parse HEAD~#{e}\\`\n> end\n> EOF\n>\n> strace -o /tmp/log -e fork,clone ruby /tmp/test\n> cat /tmp/log\n> ---\n>\n> ---\n> clone(child_stack=0x7f84131dbff0,\n> flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,\n> parent_tidptr=0x7f84131dc9d0, tls=0x7f84131dc700,\n> child_tidptr=0x7f84131dc9d0) = 17455\n> +++ exited with 0 +++\n> ---\n>\n> I wrote a simple Ruby extension to access Git builtins so `git\n> rev-parse` actually calls cmd_rev_parse directly. I don't know of any\n> other language that supports so much extensibility. Of course, as soon\n> as one command does exit(), the script ends too. It could be useful to\n> do experiments though.\n--\nDuy\n"},{"id":"219803","messageId":"CAMP44s0GUrQqXCj97Ay+0CsA1z=96BPYfyADbTaHH7fc7HL0sQ@mail.gmail.com","threadId":"34030","inReplyTo":"CACsJy8DTKr5Fy3-+8ShUrWQrKC2_7EmLHwyVgQ9Aq5JDOFBAqA@mail.gmail.com","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-08T11:56:12Z","receivedAt":"2013-06-08T11:56:12Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sat, Jun 8, 2013 at 6:28 AM, Duy Nguyen wrote:\n> On Sat, Jun 8, 2013 at 5:02 PM, Felipe Contreras\n> wrote:\n>> On Fri, Jun 7, 2013 at 9:17 PM, Duy Nguyen wrote:\n>>> On Thu, Jun 6, 2013 at 11:22 PM, Johannes Schindelin\n>>> wrote:\n>>>> Hi Greg,\n>>>>\n>>>> On Thu, 6 Jun 2013, Greg Troxel wrote:\n>>>>\n>>>>> As one of the people who helps maintain git packages in pkgsrc, my\n>>>>> initial reaction is negative to adding a ruby dependency.\n>>>>\n>>>> My initial reaction, too. It was hard enough to get Perl included with Git\n>>>> for Windows (because of that pesky Subversion dependency).\n>>>>\n>>>> As you can see from the commit history, I was the primary force behind\n>>>> trying to get everything \"core\" in Git away from requiring scripting\n>>>> languages (I think it is an awesome thing to provide APIs for as many\n>>>> languages as possible, but a not-so-cool thing to use more than one\n>>>> language in the core code). It does not seem that anybody picked up that\n>>>> task when I left, though.\n>>>\n>>> Nobody seems to mention it yet. There's another reason behind the C\n>>> rewrite effort: fork is costly on Windows. The C rewrite allows us to\n>>> run with one process (most of the time). This applies for shell, perl\n>>> and even ruby scripts because libgit.a is never meant to be used\n>>> outside git.c context (unlike libgit2). In this regard, ruby is just\n>>> as bad as currently supported non-C languages.\n>>\n>> Are you sure?\n>\n> I'm not saying you can't. I'm saying it's not meant to be used that\n> way. Which means there may be problems lurking around.\n\nCode is code. If something is not meant to be used in certain way, you fix it.\n\n> You can write a ruby extension to access libgit.a, sure,\n\nI'm not using libgit.a, I'm using the builtin commands. This is\nexactly the same code you run when you type 'git foo'.\n\n> but how many people on this\n> list understand git design and limits _and_ ruby's good enough to spot\n> the bugs?\n\nNow you are changing the subject. Does that mean that you accept that\n'fork' wouldn't be a problem when writing Ruby scripts?\n\nAs for the people that know Git and Ruby; they can learn. Didn't you\njust said that you didn't see any problem with the community learning\na new language?\n\n> If a bug is found and requires major restructuring in\n> libgit.a, how are you sure it's worth the effort and does not\n> destablize the rest of git?\n\nThere is no need to destabilize anything. I just showed you 100 lines\nof code that are able to run git commands without forks, and without\nchanging anything in libgit.a.\n\n> A better way to do it is linking against libgit2.\n\nI would rather use what the rest of Git uses. It doesn't make any\nsense fragment even more the code, and make Ruby scripts 2nd class\ncitizens along the way. Plus, any script that tries to use libgit2,\nwould certainly need more than 100 lines.\n\n-- \nFelipe Contreras\n"},{"id":"219805","messageId":"CAMP44s2u_0xPFHJG7UUwAhAuJR7TCtRDcOMg-Hn00xo4CiAZ8w@mail.gmail.com","threadId":"34030","inReplyTo":"CACsJy8A7pP=Hj2=-6iCqK9qXrC0pe2-A-YE4qoSRxhTX7=OvWQ@mail.gmail.com","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-08T12:06:52Z","receivedAt":"2013-06-08T12:06:52Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sat, Jun 8, 2013 at 6:20 AM, Duy Nguyen wrote:\n> On Sat, Jun 8, 2013 at 5:08 PM, Felipe Contreras\n> wrote:\n>> On Fri, Jun 7, 2013 at 9:23 PM, Duy Nguyen wrote:\n>>> On Sat, Jun 8, 2013 at 3:24 AM, Felipe Contreras\n>>> wrote:\n>>>>> The reviewer pool for code written in a new language _must_ be\n>>>>> seeded by some from the current set of reviewers whose judgement\n>>>>> I/we can trust.\n>>>>\n>>>> By that standard nothing will ever change. Ever.\n>>>>\n>>>> Even twenty years from now, you will still only trust people that are\n>>>> familiar with shell, Perl, and C. Because the only way to gain your\n>>>> trust, is by being proficient in shell, Perl, and C.\n>>>\n>>> I don't see why a trusted person cannot learn a new language and\n>>> convince the community to give it a try (well given that enough\n>>> reviewers support the new language, which was Junio's point).\n>>\n>> I do. Raise your hand if you are interested in giving a try to Ruby\n>> for Git's core given that somebody gives convincing reasons?\n>\n> Personally, no additional runtime dependency > Ruby > Python.\n\nYou forgot to list the current ones; shell, perl, python.\n\n> I don't\n> think Ruby is available on SunOS and I prefer not to build and install\n> Python nor Ruby myself to be able to use Git. So no hands from me.\n\nIt doesn't surprise me that you stopped at an assumption, instead of\nmaking sure.\n\n>> How many hands do you expect?\n>\n> If not many hands show up, the Git community clearly is not ready to\n> adopt Ruby.\n\nAnd they will never be. Nor Ruby nor anything else, which was\nprecisely my point.\n\n> Maybe ask again next year when Ruby is getting more popular?\n\nYou will stop again with another assumption, without ever giving it a chance.\n\n-- \nFelipe Contreras\n"},{"id":"219806","messageId":"CACsJy8D8xD3mdC2gsBpU74Faa+CUfEWEgh5fhwPoRjz46-hjcw@mail.gmail.com","threadId":"34030","inReplyTo":"CAMP44s0GUrQqXCj97Ay+0CsA1z=96BPYfyADbTaHH7fc7HL0sQ@mail.gmail.com","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2013-06-08T12:07:54Z","receivedAt":"2013-06-08T12:07:54Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Sat, Jun 8, 2013 at 6:56 PM, Felipe Contreras\n wrote:\n> On Sat, Jun 8, 2013 at 6:28 AM, Duy Nguyen wrote:\n>> On Sat, Jun 8, 2013 at 5:02 PM, Felipe Contreras\n>> wrote:\n>>> On Fri, Jun 7, 2013 at 9:17 PM, Duy Nguyen wrote:\n>>>> On Thu, Jun 6, 2013 at 11:22 PM, Johannes Schindelin\n>>>> wrote:\n>>>>> Hi Greg,\n>>>>>\n>>>>> On Thu, 6 Jun 2013, Greg Troxel wrote:\n>>>>>\n>>>>>> As one of the people who helps maintain git packages in pkgsrc, my\n>>>>>> initial reaction is negative to adding a ruby dependency.\n>>>>>\n>>>>> My initial reaction, too. It was hard enough to get Perl included with Git\n>>>>> for Windows (because of that pesky Subversion dependency).\n>>>>>\n>>>>> As you can see from the commit history, I was the primary force behind\n>>>>> trying to get everything \"core\" in Git away from requiring scripting\n>>>>> languages (I think it is an awesome thing to provide APIs for as many\n>>>>> languages as possible, but a not-so-cool thing to use more than one\n>>>>> language in the core code). It does not seem that anybody picked up that\n>>>>> task when I left, though.\n>>>>\n>>>> Nobody seems to mention it yet. There's another reason behind the C\n>>>> rewrite effort: fork is costly on Windows. The C rewrite allows us to\n>>>> run with one process (most of the time). This applies for shell, perl\n>>>> and even ruby scripts because libgit.a is never meant to be used\n>>>> outside git.c context (unlike libgit2). In this regard, ruby is just\n>>>> as bad as currently supported non-C languages.\n>>>\n>>> Are you sure?\n>>\n>> I'm not saying you can't. I'm saying it's not meant to be used that\n>> way. Which means there may be problems lurking around.\n>\n> Code is code. If something is not meant to be used in certain way, you fix it.\n\nCode is code. Bugs can be hard and easy. Hard bugs take a lot of time\nand may not be worth it after all.\n\n>> You can write a ruby extension to access libgit.a, sure,\n>\n> I'm not using libgit.a, I'm using the builtin commands. This is\n> exactly the same code you run when you type 'git foo'.\n>\n>> but how many people on this\n>> list understand git design and limits _and_ ruby's good enough to spot\n>> the bugs?\n>\n> Now you are changing the subject. Does that mean that you accept that\n> 'fork' wouldn't be a problem when writing Ruby scripts?\n\nThere are a lot of static variables in builtin/ (and outside too),\nwhich make it non-entrant, or at least not safe. fork provides a\nprocess space isolation, some depend on that. And there are die()\neverywhere. Good luck controlling them.\n\n> As for the people that know Git and Ruby; they can learn. Didn't you\n> just said that you didn't see any problem with the community learning\n> a new language?\n\nI said nothing about the community being ready _now_, did I? When you\nhave the support for Ruby in Git, sure go ahead.\n\n>> If a bug is found and requires major restructuring in\n>> libgit.a, how are you sure it's worth the effort and does not\n>> destablize the rest of git?\n>\n> There is no need to destabilize anything. I just showed you 100 lines\n> of code that are able to run git commands without forks, and without\n> changing anything in libgit.a.\n\nAnd how do you deal with, for example die(), or thread safety?\n-- \nDuy\n"},{"id":"219816","messageId":"CAMP44s192hzh8AWU-Eg1VVVXjZ9qyNqHw99X6y48MXJn3DHw+Q@mail.gmail.com","threadId":"34030","inReplyTo":"CACsJy8D8xD3mdC2gsBpU74Faa+CUfEWEgh5fhwPoRjz46-hjcw@mail.gmail.com","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-08T13:20:28Z","receivedAt":"2013-06-08T13:20:28Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sat, Jun 8, 2013 at 7:07 AM, Duy Nguyen wrote:\n> On Sat, Jun 8, 2013 at 6:56 PM, Felipe Contreras\n> wrote:\n>> On Sat, Jun 8, 2013 at 6:28 AM, Duy Nguyen wrote:\n\n>>> but how many people on this\n>>> list understand git design and limits _and_ ruby's good enough to spot\n>>> the bugs?\n>>\n>> Now you are changing the subject. Does that mean that you accept that\n>> 'fork' wouldn't be a problem when writing Ruby scripts?\n>\n> There are a lot of static variables in builtin/ (and outside too),\n> which make it non-entrant, or at least not safe.\n\nSo?\n\n> fork provides a process space isolation, some depend on that.\n\nProcess space isolation from what?\n\n> And there are die() everywhere. Good luck controlling them.\n\nDone.\n\n--- a/ruby/git.c\n+++ b/ruby/git.c\n@@ -1,6 +1,7 @@\n #include \n #include \n #include \n+#include \n\n #undef NORETURN\n #undef PATH_SEP\n@@ -8,6 +9,8 @@\n #include \n\n static VALUE shellwords;\n+static ucontext_t main_context;\n+static int status;\n\n struct cmd_struct {\n \tconst char *cmd;\n@@ -73,7 +76,14 @@ static VALUE git_rb_backticks(int o_argc, VALUE\n*o_argv, VALUE ctx)\n \tif (cmd->option & RUN_SETUP)\n \t\tprefix = setup_git_directory();\n\n-\ti = cmd->fn(argc, argv, prefix);\n+\tgetcontext(&main_context);\n+\tif (status == 0) {\n+\t\tstatus += 1;\n+\t\ti = cmd->fn(argc, argv, prefix);\n+\t} else {\n+\t\ti = 1;\n+\t}\n+\tstatus = 0;\n \trb_last_status_set(i, getpid());\n\n \tfflush(stdout);\n@@ -87,9 +97,19 @@ static VALUE git_rb_backticks(int o_argc, VALUE\n*o_argv, VALUE ctx)\n \treturn rb_str_new(buf, i);\n }\n\n+static void bye(void)\n+{\n+\tif (status != 1)\n+\t\treturn;\n+\tstatus += 1;\n+\tsetcontext(&main_context);\n+}\n+\n void Init_git(void)\n {\n \trb_require(\"shellwords\");\n \tshellwords = rb_define_module(\"Shellwords\");\n \trb_define_global_function(\"`\", git_rb_backticks, -1);\n+\n+\tatexit(bye);\n }\n\n>> As for the people that know Git and Ruby; they can learn. Didn't you\n>> just said that you didn't see any problem with the community learning\n>> a new language?\n>\n> I said nothing about the community being ready _now_, did I?\n\nIf they can learn Ruby five years from now, then can learn it now.\n\n> When you have the support for Ruby in Git, sure go ahead.\n\nYou are going in circles.\n\n>>> If a bug is found and requires major restructuring in\n>>> libgit.a, how are you sure it's worth the effort and does not\n>>> destablize the rest of git?\n>>\n>> There is no need to destabilize anything. I just showed you 100 lines\n>> of code that are able to run git commands without forks, and without\n>> changing anything in libgit.a.\n>\n> And how do you deal with, for example die(), or thread safety?\n\nSee above for die(), and I don't see many perl or shell scripts with\nmultiple threads, why should the Ruby scripts have more than one\nthread?\n\n-- \nFelipe Contreras\n"},{"id":"219841","messageId":"20130608171513.GA28029@sigill.intra.peff.net","threadId":"34030","inReplyTo":"CAMP44s192hzh8AWU-Eg1VVVXjZ9qyNqHw99X6y48MXJn3DHw+Q@mail.gmail.com","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-06-08T17:15:13Z","receivedAt":"2013-06-08T17:15:13Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Jun 08, 2013 at 08:20:28AM -0500, Felipe Contreras wrote:\n\n> > There are a lot of static variables in builtin/ (and outside too),\n> > which make it non-entrant, or at least not safe.\n> \n> So?\n> \n> > fork provides a process space isolation, some depend on that.\n> \n> Process space isolation from what?\n\nManipulation of global variables. Here are a few examples off the top of\nmy head:\n\nTry running \"git diff\" from your Ruby hook, then try running \"git\ndiff-files\" within the same process. I believe the latter will start\nrespecting porcelain diff config like diff.mnemonicprefix. To clear\nstate you need to reset a list of global variables back to their initial\nstates (some of which are the BSS-default zero, but some of which are\nnot).\n\nTry running \"git log\" followed by another \"git log\". The log family of\ncommands does not clear its marks from the commit objects, since it\nexpects to exit after the traversal. The second log will sometimes give\nwrong answers if its traversal overlaps with the first (e.g., commits\nmarked SEEN or UNINTERESTING that should not be). You can add a call to\nclear them at the end of the process, but that does not cover any cases\nwhere we die().\n\nThese are problems that can be solved. But there is a lot of work\ninvolved in finding these subtle bugs and coming up with fixes. I think\nyou would be better off working on an implementation of git that was\ndesigned from scratch to work in-process, like libgit2. And it even has\nan actively developed and maintained Ruby binding[1].\n\nlibgit2 doesn't have feature parity with regular git yet, but there are\nmany clients based around it that use the library internally for speed,\nand then exec regular git to fill in the gaps.\n\n-Peff\n\n[1] https://github.com/libgit2/rugged\n"},{"id":"219847","messageId":"CAMP44s1pkNd1NBM_q8Hb71jDOMXrX7_szQvNudGafYYQpdBt0Q@mail.gmail.com","threadId":"34030","inReplyTo":"20130608171513.GA28029@sigill.intra.peff.net","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-08T17:40:19Z","receivedAt":"2013-06-08T17:40:19Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sat, Jun 8, 2013 at 12:15 PM, Jeff King wrote:\n> On Sat, Jun 08, 2013 at 08:20:28AM -0500, Felipe Contreras wrote:\n>\n>> > There are a lot of static variables in builtin/ (and outside too),\n>> > which make it non-entrant, or at least not safe.\n>>\n>> So?\n>>\n>> > fork provides a process space isolation, some depend on that.\n>>\n>> Process space isolation from what?\n>\n> Manipulation of global variables. Here are a few examples off the top of\n> my head:\n>\n> Try running \"git diff\" from your Ruby hook, then try running \"git\n> diff-files\" within the same process. I believe the latter will start\n> respecting porcelain diff config like diff.mnemonicprefix. To clear\n> state you need to reset a list of global variables back to their initial\n> states (some of which are the BSS-default zero, but some of which are\n> not).\n>\n> Try running \"git log\" followed by another \"git log\". The log family of\n> commands does not clear its marks from the commit objects, since it\n> expects to exit after the traversal. The second log will sometimes give\n> wrong answers if its traversal overlaps with the first (e.g., commits\n> marked SEEN or UNINTERESTING that should not be). You can add a call to\n> clear them at the end of the process, but that does not cover any cases\n> where we die().\n>\n> These are problems that can be solved. But there is a lot of work\n> involved in finding these subtle bugs and coming up with fixes. I think\n> you would be better off working on an implementation of git that was\n> designed from scratch to work in-process, like libgit2.\n\nSo you are in favor of never ever having an official Git library. Got it.\n\n> libgit2 doesn't have feature parity with regular git yet, but there are\n> many clients based around it that use the library internally for speed,\n> and then exec regular git to fill in the gaps.\n\nThere's a reason why the Git project doesn't use libgit2, and for the\nsame reason the official Ruby scripts should not use it.\n\nAs history indicates, the Git project will never have any pressure to\nfix it's re-entrancy and re-run issues, so these issues will remain\nthere forever.\n\nOnly if you allow code that exposes those issues will there ever be\nany pressure to fix them.\n\n-- \nFelipe Contreras\n"},{"id":"219863","messageId":"20130609001025.GB29964@sigill.intra.peff.net","threadId":"34030","inReplyTo":"CAMP44s1pkNd1NBM_q8Hb71jDOMXrX7_szQvNudGafYYQpdBt0Q@mail.gmail.com","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-06-09T00:10:25Z","receivedAt":"2013-06-09T00:10:25Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Jun 08, 2013 at 12:40:19PM -0500, Felipe Contreras wrote:\n\n> > These are problems that can be solved. But there is a lot of work\n> > involved in finding these subtle bugs and coming up with fixes. I think\n> > you would be better off working on an implementation of git that was\n> > designed from scratch to work in-process, like libgit2.\n> \n> So you are in favor of never ever having an official Git library. Got it.\n\nNo, I didn't say that at all.\n\nI do think that it would be more work to try to slowly massage the git\ncode into a library-ready form than it would be to simply start with\nmore library-friendly code and pull in bits of git.git as appropriate.\n\nThat is what the libgit2 project is doing. Perhaps one day that project\nwill reach a point where we start building git.git commands off of it or\nsometihng like it (for that matter, there is no reason you could not\nbuild external commands off of libgit2 right now). Would it be the\n\"official\" Git library then? I don't know. It is not clear to me what\nthat even means.\n\nIn the meantime, I think it cannot be a bad thing for libgit2 to proceed\nalong its path, and I don't see a good reason for people not to use it.\n\nBut hey, you don't need to listen to me. If you think it would be easier\nto make the git.git code into a library, go ahead and work on it. But I\nthink you will find that there are a large number of hard-to-find bugs\ncaused by implicit assumptions about global state, how file descriptors\nare used, and so forth.\n\n> There's a reason why the Git project doesn't use libgit2, and for the\n> same reason the official Ruby scripts should not use it.\n\nWhat reason is that?\n\n> As history indicates, the Git project will never have any pressure to\n> fix it's re-entrancy and re-run issues, so these issues will remain\n> there forever.\n> \n> Only if you allow code that exposes those issues will there ever be\n> any pressure to fix them.\n\nI think it is a matter of critical mass. If you were to start linking\nagainst libgit.a and 90% of it worked, you might have a reason to fix\nthe other 10%. But I suspect it is more the other way around.\n\n-Peff\n"},{"id":"219864","messageId":"20130609001845.GC29964@sigill.intra.peff.net","threadId":"34030","inReplyTo":"CABPQNSYLmFWkdgph6W7MwaSTe+zrU0AaJpj_v9z=cmvWu64HNA@mail.gmail.com","subject":"Re: [PATCH] t0005: skip signal death exit code test on Windows","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-06-09T00:18:45Z","receivedAt":"2013-06-09T00:18:45Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jun 07, 2013 at 12:12:52PM +0200, Erik Faye-Lund wrote:\n\n> > Yeah, if it were mingw_raise responsible for this, I would suggest using\n> > the POSIX shell \"128+sig\" instead. We could potentially check for\n> > SIG_DFL[1] mingw_raise and intercept and exit there. I don't know if\n> > that would create headaches or confusion for other msys programs,\n> > though. I'd leave that up to the msysgit people to decide whether it is\n> > worth the trouble.\n> >\n> \n> ...and here's the code to do just that:\n> [...]\n> @@ -1715,6 +1720,13 @@ int mingw_raise(int sig)\n> \t\t\tsigint_fn(SIGINT);\n> \t\treturn 0;\n> \n> +\tcase SIGTERM:\n> +\t\tif (sigterm_fn == SIG_DFL)\n> +\t\t\texit(128 + SIGTERM);\n> +\t\telse if (sigterm_fn != SIG_IGN)\n> +\t\t\tsigterm_fn(SIGTERM);\n> +\t\treturn 0;\n\nI'm a little negative on handling just SIGTERM. That would make the test\npass, but does it really address the overall issue? To me, the\nusefulness is having exit values with consistent meanings. Imagine I run\na very large git hosting site, and I want to log exceptional conditions\n(e.g., a git sub-process crashes). What exit code do I get from a\nSIGSEGV or SIGBUS (or GPF, or whatever Windows calls these)?\n\nOn Unix systems, this is pretty easy. To be honest, I do not care that\nmuch about Windows systems because I would not host a large site on it.\n:) But IMHO, the point of such a scheme is to be consistent across all\nsignals.\n\n-Peff\n"},{"id":"219865","messageId":"CAMP44s21hyKLw0=hwOzuNzSuQx4qeca2VLnz9Reh5rD7j4oSrw@mail.gmail.com","threadId":"34030","inReplyTo":"20130609001025.GB29964@sigill.intra.peff.net","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-09T01:17:08Z","receivedAt":"2013-06-09T01:17:08Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sat, Jun 8, 2013 at 7:10 PM, Jeff King wrote:\n> On Sat, Jun 08, 2013 at 12:40:19PM -0500, Felipe Contreras wrote:\n>\n>> > These are problems that can be solved. But there is a lot of work\n>> > involved in finding these subtle bugs and coming up with fixes. I think\n>> > you would be better off working on an implementation of git that was\n>> > designed from scratch to work in-process, like libgit2.\n>>\n>> So you are in favor of never ever having an official Git library. Got it.\n>\n> No, I didn't say that at all.\n\nThen you truly think libgit2 will ever reach the point where it can\nreplace libgit.a?\n\nIt won't. But decreeing that both projects should remain isolated, and\nthat libgit.a should never be a library, you are effectively\ncondemning the effort to fail, knowingly or not.\n\nHow many years has libgit2 been brewing? Do you think it's closer for\nmerging so it can be used by Git's core? No, it doesn't, and it will\nnot in the future, because it was never meant for that.\n\n> I do think that it would be more work to try to slowly massage the git\n> code into a library-ready form than it would be to simply start with\n> more library-friendly code and pull in bits of git.git as appropriate.\n\nIt might be more effort, but the results are guaranteed by our\nextensive testing infrastructure and huge user-base. Slowly but\nsteadily we'll get there.\n\nWaiting for libgit2 to switch directions and reach some hypothetical\npoint is waiting for hell to freeze.\n\nIt won't happen. There's no incentive nor reason for it to happen.\n\n> That is what the libgit2 project is doing. Perhaps one day that project\n> will reach a point where we start building git.git commands off of it or\n> sometihng like it (for that matter, there is no reason you could not\n> build external commands off of libgit2 right now). Would it be the\n> \"official\" Git library then? I don't know. It is not clear to me what\n> that even means.\n\nIt means 'make install' installs a shared library with a clearly\ndefined and stable API that other projects can depend on, and it can\nbe used for all sort of purposes, including the git binary, and it's\nbuiltins.\n\n> In the meantime, I think it cannot be a bad thing for libgit2 to proceed\n> along its path, and I don't see a good reason for people not to use it.\n\nIts path will never end as an official Git library, not unless we do something.\n\n> But hey, you don't need to listen to me. If you think it would be easier\n> to make the git.git code into a library, go ahead and work on it. But I\n> think you will find that there are a large number of hard-to-find bugs\n> caused by implicit assumptions about global state, how file descriptors\n> are used, and so forth.\n\nThat's impossible. Specially since moving irrelevant code out of\nlibgit.a is not permitted.\n\n>> There's a reason why the Git project doesn't use libgit2, and for the\n>> same reason the official Ruby scripts should not use it.\n>\n> What reason is that?\n\nYou tell me. Why isn't Git using libgit2?\n\n>> As history indicates, the Git project will never have any pressure to\n>> fix it's re-entrancy and re-run issues, so these issues will remain\n>> there forever.\n>>\n>> Only if you allow code that exposes those issues will there ever be\n>> any pressure to fix them.\n>\n> I think it is a matter of critical mass. If you were to start linking\n> against libgit.a and 90% of it worked, you might have a reason to fix\n> the other 10%. But I suspect it is more the other way around.\n\nIt doesn't matter if it's 90% or 10%, it's the only thing we have.\n\nUnless you are in favor of including libgit2 and start using it for\nGit's core *right now*, the only way forward is to improve libgit.a.\n\n-- \nFelipe Contreras\n"},{"id":"219869","messageId":"20130609022351.GA30393@sigill.intra.peff.net","threadId":"34030","inReplyTo":"CAMP44s21hyKLw0=hwOzuNzSuQx4qeca2VLnz9Reh5rD7j4oSrw@mail.gmail.com","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-06-09T02:23:51Z","receivedAt":"2013-06-09T02:23:51Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Jun 08, 2013 at 08:17:08PM -0500, Felipe Contreras wrote:\n\n> > No, I didn't say that at all.\n> \n> Then you truly think libgit2 will ever reach the point where it can\n> replace libgit.a?\n\nI don't know. It may. Or something like it may. It is certainly not\nready to do so yet, but perhaps one day it will be.\n\n> It won't.\n\nOh, I see, you were not actually interested in my answer and were just\nbeing rhetorical.\n\n> But decreeing that both projects should remain isolated, and\n> that libgit.a should never be a library, you are effectively\n> condemning the effort to fail, knowingly or not.\n\nHuh? When did I decree anything? You asked Duy what kinds of problems\nyou would run into with running multiple git commands in the same\nprocess space. I answered with concrete examples, and gave my opinions\non what the path of least work would be to reach a re-entrant library.\nYou don't have to agree (didn't I even say \"you don't have to listen to\nme\" in the last email?).\n\n> How many years has libgit2 been brewing? Do you think it's closer for\n> merging so it can be used by Git's core? No, it doesn't, and it will\n> not in the future, because it was never meant for that.\n\nThere has been about 2 years of active development, and there's been\nquite a lot of improvement in that time. Closer than what? Than it was 2\nyears ago? Yes, I think it is. But it still has a ways to go.\n\nI do not think there will be a flag day where we throw away git.git's\ncode and start using libgit2. But we could slowly start replacing\nunderlying bits with libgit2 bits, if that implementation proves to be\nrobust and clean enough to do so.\n\n> > But hey, you don't need to listen to me. If you think it would be easier\n> > to make the git.git code into a library, go ahead and work on it. But I\n> > think you will find that there are a large number of hard-to-find bugs\n> > caused by implicit assumptions about global state, how file descriptors\n> > are used, and so forth.\n> \n> That's impossible. Specially since moving irrelevant code out of\n> libgit.a is not permitted.\n\nI'm not even sure what your second sentence means.\n\nBut it seems to me that the first step would be cleaning up the internal\ncode so that it is more friendly to library callers (both in interface\nand in being re-entrant), with those first sets of callers being the\nexisting code in git.git. Such cleanups would be a good thing for the\nmodularity of the code, even without an intended library step.\n\nAnd then you can start to pull out individual interfaces that are known\nto be safe for library use, and think about making a coherent library\nout of them.\n\nAnd please don't tell me about \"not permitted\". You are free to fork and\nwork on this. But do not expect people who have already said \"that does\nnot seem like a fruitful path to me\" to jump into it with you. If you\nthink it is worth doing and that you can come up with initial results to\nconvince others, go for it.\n\n> >> There's a reason why the Git project doesn't use libgit2, and for the\n> >> same reason the official Ruby scripts should not use it.\n> >\n> > What reason is that?\n> \n> You tell me. Why isn't Git using libgit2?\n\nWait, you indicated you had such a reason in mind, but now you won't\ntell me? Is it a secret?\n\n> > I think it is a matter of critical mass. If you were to start linking\n> > against libgit.a and 90% of it worked, you might have a reason to fix\n> > the other 10%. But I suspect it is more the other way around.\n> \n> It doesn't matter if it's 90% or 10%, it's the only thing we have.\n> \n> Unless you are in favor of including libgit2 and start using it for\n> Git's core *right now*, the only way forward is to improve libgit.a.\n\nThat seems like a false choice to me. You obviously feel that libgit2 is\nsome kind of dead end. I don't agree. Whatever.\n\nI have very little interest in discussing this further with you, as it\nis not leading in a productive direction. In my opinion, the productive\nthings to do would be one (or both) of:\n\n 1. Work on libgit2.\n\n 2. Clean up non-reentrant bits of git.git, hopefully making the code\n more readable and more modular (and taking care not to make it\n worse in other ways, like maintainability or performance).\n\n-Peff\n"},{"id":"219871","messageId":"CAMP44s2bNQ2GCXGcZBQBcTa3BPXCt6vTUsG36b_4L1WzfN=aEQ@mail.gmail.com","threadId":"34030","inReplyTo":"20130609022351.GA30393@sigill.intra.peff.net","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-09T02:41:46Z","receivedAt":"2013-06-09T02:41:46Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sat, Jun 8, 2013 at 9:23 PM, Jeff King wrote:\n> On Sat, Jun 08, 2013 at 08:17:08PM -0500, Felipe Contreras wrote:\n>\n>> > No, I didn't say that at all.\n>>\n>> Then you truly think libgit2 will ever reach the point where it can\n>> replace libgit.a?\n>\n> I don't know. It may. Or something like it may. It is certainly not\n> ready to do so yet, but perhaps one day it will be.\n\nPerhaps one day we would end poverty and hunger, and perhaps one day\nwe will live in peace, but I wouldn't hold on my breath. I fact, I'll\ndo the opposite, I bet it won't happen anytime soon.\n\n>> It won't.\n>\n> Oh, I see, you were not actually interested in my answer and were just\n> being rhetorical.\n>\n>> But decreeing that both projects should remain isolated, and\n>> that libgit.a should never be a library, you are effectively\n>> condemning the effort to fail, knowingly or not.\n>\n> Huh? When did I decree anything?\n\nWhen you said in your opinion we should wait until libgit2 is ready,\nand not improve libgit.a.\n\n>> How many years has libgit2 been brewing? Do you think it's closer for\n>> merging so it can be used by Git's core? No, it doesn't, and it will\n>> not in the future, because it was never meant for that.\n>\n> There has been about 2 years of active development, and there's been\n> quite a lot of improvement in that time. Closer than what? Than it was 2\n> years ago? Yes, I think it is. But it still has a ways to go.\n\nWhy is it closer? In what ways is it a better fit now than 2 years\nago? What is missing before merging to be used in Git's core?\n\n> I do not think there will be a flag day where we throw away git.git's\n> code and start using libgit2. But we could slowly start replacing\n> underlying bits with libgit2 bits, if that implementation proves to be\n> robust and clean enough to do so.\n\nAnd what are we waiting for then? Shouldn't we copy the whole libgit2\ncode and start migrating?\n\n>> > But hey, you don't need to listen to me. If you think it would be easier\n>> > to make the git.git code into a library, go ahead and work on it. But I\n>> > think you will find that there are a large number of hard-to-find bugs\n>> > caused by implicit assumptions about global state, how file descriptors\n>> > are used, and so forth.\n>>\n>> That's impossible. Specially since moving irrelevant code out of\n>> libgit.a is not permitted.\n>\n> I'm not even sure what your second sentence means.\n\nIt means this:\nhttp://article.gmane.org/gmane.comp.version-control.git/226752\n\nI move code that doesn't belong in a libgit library out of libgit.a,\nand the change gets rejected.\n\n> But it seems to me that the first step would be cleaning up the internal\n> code so that it is more friendly to library callers (both in interface\n> and in being re-entrant),\n\nThat is the second step. It doesn't make sense to make code\nre-entrant, if that code will only be used by builtin commands. First\nstep is to move irrelevant code out of libgit.a.\n\n>> >> There's a reason why the Git project doesn't use libgit2, and for the\n>> >> same reason the official Ruby scripts should not use it.\n>> >\n>> > What reason is that?\n>>\n>> You tell me. Why isn't Git using libgit2?\n>\n> Wait, you indicated you had such a reason in mind, but now you won't\n> tell me? Is it a secret?\n\nI did not. I made the assumption that there was a reason, if there's\nno reason to stay clear of libgit2, then let's merge it already.\n\n>> > I think it is a matter of critical mass. If you were to start linking\n>> > against libgit.a and 90% of it worked, you might have a reason to fix\n>> > the other 10%. But I suspect it is more the other way around.\n>>\n>> It doesn't matter if it's 90% or 10%, it's the only thing we have.\n>>\n>> Unless you are in favor of including libgit2 and start using it for\n>> Git's core *right now*, the only way forward is to improve libgit.a.\n>\n> That seems like a false choice to me. You obviously feel that libgit2 is\n> some kind of dead end. I don't agree. Whatever.\n\nI never said so. It is a dead end *if* we don't do an effort to have a\nproper libgit library, which is the path we are taking.\n\n> I have very little interest in discussing this further with you, as it\n> is not leading in a productive direction. In my opinion, the productive\n> things to do would be one (or both) of:\n>\n> 1. Work on libgit2.\n>\n> 2. Clean up non-reentrant bits of git.git, hopefully making the code\n> more readable and more modular (and taking care not to make it\n> worse in other ways, like maintainability or performance).\n\nYou forgot the first step of 2.: move irrelevant code out of libgit.a.\n\n-- \nFelipe Contreras\n"},{"id":"219873","messageId":"alpine.DEB.1.00.1306090456160.28957@s15462909.onlinehome-server.info","threadId":"34030","inReplyTo":"CALkWK0m4V4KYyKW8KJMRsCgOxqcLi0XDYZvS4w++6BKVVvioyw@mail.gmail.com","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2013-06-09T02:57:18Z","receivedAt":"2013-06-09T02:57:18Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Ram,\n\nOn Sat, 8 Jun 2013, Ramkumar Ramachandra wrote:\n\n> Felipe Contreras wrote:\n> >> Also we heard from no regular/high-value reviewers that they feel\n> >> comfortable reviewing additions in Ruby.\n> >\n> > Correction; *current* regular/high-value reviewers.\n> \n> Correct. The opinions of inactive community members and\n> non-contributors are less useful.\n\nI humbly suggest to treat other people's contribution with the same\nrespect you want yours' to be treated.\n\nJust a suggestion,\nJ\n"},{"id":"219874","messageId":"alpine.DEB.1.00.1306090457340.28957@s15462909.onlinehome-server.info","threadId":"34030","inReplyTo":"CALkWK0ntWzJj1AkDzv9VvS+7e3B17HFkZLQhAu-7pQv6M7=dkw@mail.gmail.com","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2013-06-09T02:59:41Z","receivedAt":"2013-06-09T02:59:41Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Ram,\n\nOn Sat, 8 Jun 2013, Ramkumar Ramachandra wrote:\n\n> Felipe Contreras wrote:\n> > While at it, why not re-evaluate the whole msysgit approach? I bet we\n> > don't need a whole separate project just to create a Windows\n> > installer. I've written Windows installers before, it's very easy to\n> > do from Linux.\n> \n> Yeah, taking the pain out of msysgit packaging would be a great way to\n> counter this new-dependency-fud. The main problem, as mm pointed out\n> is subversion + perlxs.\n\nYeah, this is the main problem, and you probably will end up with a much\nbetter (Linux-based) solution than the people who contributed to the Git\nfor Windows project in all those years since August 2007.\n\nSurprise me, with code,\nJ\n"},{"id":"219875","messageId":"alpine.DEB.1.00.1306090502470.28957@s15462909.onlinehome-server.info","threadId":"34030","inReplyTo":"CACsJy8BMrxLZFGQfUN1YCG+qkAj-91aYkc54R5O4iqgXUNeQOw@mail.gmail.com","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2013-06-09T03:07:33Z","receivedAt":"2013-06-09T03:07:33Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Duy,\n\nOn Sat, 8 Jun 2013, Duy Nguyen wrote:\n\n> On Thu, Jun 6, 2013 at 11:22 PM, Johannes Schindelin\n> wrote:\n> > Hi Greg,\n> >\n> > On Thu, 6 Jun 2013, Greg Troxel wrote:\n> >\n> >> As one of the people who helps maintain git packages in pkgsrc, my\n> >> initial reaction is negative to adding a ruby dependency.\n> >\n> > My initial reaction, too. It was hard enough to get Perl included with Git\n> > for Windows (because of that pesky Subversion dependency).\n> >\n> > As you can see from the commit history, I was the primary force behind\n> > trying to get everything \"core\" in Git away from requiring scripting\n> > languages (I think it is an awesome thing to provide APIs for as many\n> > languages as possible, but a not-so-cool thing to use more than one\n> > language in the core code). It does not seem that anybody picked up that\n> > task when I left, though.\n> \n> Nobody seems to mention it yet. There's another reason behind the C\n> rewrite effort: fork is costly on Windows. The C rewrite allows us to\n> run with one process (most of the time). This applies for shell, perl\n> and even ruby scripts because libgit.a is never meant to be used\n> outside git.c context (unlike libgit2). In this regard, ruby is just\n> as bad as currently supported non-C languages.\n\nI think you should have said \"on Windows\" when you said \"fork is costly\".\nOh wait, you did.\n\nIt seems that at least some people participating in this discussion are\nnot overly keen on supporting the platform that -- according to\nstatistics, i.e. facts -- is the most prevalent.\n\nI am glad that Junio still seems to be interested in giving us poor folks\ntrying to make the Git experience on Windows a less sucky one enough\ncredit, even if we only got a little over 900 commits into git.git. But\nthat does not count because the commits are older than one year. That\nmakes them useless to some people, apparently.\n\nHopefully Junio will have more mercy on us poor Windows folks than others\nwould,\nDscho\n"},{"id":"219947","messageId":"CALkWK0nCe-fDVdYjD=0XrW-MXBrP1aMrcwdmxfZ_bnM+_esuhQ@mail.gmail.com","threadId":"34030","inReplyTo":"alpine.DEB.1.00.1306090456160.28957@s15462909.onlinehome-server.info","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-09T09:16:16Z","receivedAt":"2013-06-09T09:16:16Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Johannes Schindelin wrote:\n>> Correct. The opinions of inactive community members and\n>> non-contributors are less useful.\n>\n> I humbly suggest to treat other people's contribution with the same\n> respect you want yours' to be treated.\n\nWhat?! When did I disrespect other people's contributions? git.git\nis what it is today because of everyone's contributions: if I\ndisrespected them, why would I work on improving git?\n\nMy opinion has nothing to do with me, or my contributions. I have\nalready stated multiple times on the list that I take no pride in my\ncontributions whatsoever*: I have no ego to speak of. I said \"the\nopinions of inactive community members and non-contributors are less\nuseful [than those of active contributors]\", and I'm still scratching\nmy head over what you inferred. Do you think that the opinions of\ninactive community members and non-contributors are _more_ valuable\nthan those of active contributors, or am I missing something?\n\n* You'd know that if you read emails on the list. But you don't, for\nsome mysterious unstated reason.\n"},{"id":"220161","messageId":"7vk3m3owk2.fsf@alter.siamese.dyndns.org","threadId":"34030","inReplyTo":"20130609001845.GC29964@sigill.intra.peff.net","subject":"Re: [PATCH] t0005: skip signal death exit code test on Windows","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-06-09T20:31:41Z","receivedAt":"2013-06-09T20:31:41Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> I'm a little negative on handling just SIGTERM. That would make the test\n> pass, but does it really address the overall issue? To me, the\n> usefulness is having exit values with consistent meanings.\n\nYes. Unless the goal is to give Windows port pratically the same\nsignal semantics as ports on other platforms, I do not think special\ncasing SIGTERM (unless it is a very common signal on Windows and\nothers are unlikely to be useful) buys us much.\n"},{"id":"220213","messageId":"7vli6in9ru.fsf@alter.siamese.dyndns.org","threadId":"34030","inReplyTo":"CALkWK0nCe-fDVdYjD=0XrW-MXBrP1aMrcwdmxfZ_bnM+_esuhQ@mail.gmail.com","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-06-09T23:29:09Z","receivedAt":"2013-06-09T23:29:09Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra writes:\n\n> Do you think that the opinions of\n> inactive community members and non-contributors are _more_ valuable\n> than those of active contributors, or am I missing something?\n\nI am not Dscho, but it probably is worth saying this anyway.\n\n6d297f81373e (Status update on merge-recursive in C, 2006-07-08)\nstole merge-recursive.c from git-merge-recursive.py with an explicit\npurpose of making sure that those without a working Python can\nperform such a core operation like \"merge\" with Git without extra\nforking.\n\nThe person who worked on it, as long as he knows that the project\nnot just accepted the patch and kept using the code but also that\nthe project understood the rationale behind that change, does not\nnecessarily have a reason to appear every week to interject comments\nin discussions on any part of the system, even to proposed changes\nto merge-recursive.c, as long as the original thing the change meant\nto address is not broken (e.g. removing merge-recursive.c and add it\nas a merge strategy written in Python or Ruby might trigger \"huh\",\nbut ditching merge-recursive.c and replacing it with merge-replay.c\nas long as it works would be a \"meh\" for him).\n\nWhen otherwise silent old-timers feel a need to come during a\ndiscussion that might affect the course of the project in a major\nway, we should pay more attention, not less, to what they say (I am\nnot saying \"we should blindly follow\"). They can explain why some\nthings are as they are, why some changes that may look like a good\nidea did not work out and how they failed, etc.\n\nCertainly the opinions from them are no less valuable.\n"},{"id":"220231","messageId":"CAMP44s04L3NB0_D4Mn9uK_SVhv38AN-bN4XMhz7zDw4LEZjbYQ@mail.gmail.com","threadId":"34030","inReplyTo":"7vli6in9ru.fsf@alter.siamese.dyndns.org","subject":"Re: [Administrivia] On ruby and contrib/","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-06-10T04:56:44Z","receivedAt":"2013-06-10T04:56:44Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sun, Jun 9, 2013 at 6:29 PM, Junio C Hamano wrote:\n\n> When otherwise silent old-timers feel a need to come during a\n> discussion that might affect the course of the project in a major\n> way, we should pay more attention, not less, to what they say (I am\n> not saying \"we should blindly follow\").\n\nI say we should pay attention to the arguments, not the people, that's\nad hominem.\n\n-- \nFelipe Contreras\n"},{"id":"220239","messageId":"51B5648B.7020703@viscovery.net","threadId":"34030","inReplyTo":"7vk3m3owk2.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] t0005: skip signal death exit code test on Windows","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2013-06-10T05:30:51Z","receivedAt":"2013-06-10T05:30:51Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 6/9/2013 22:31, schrieb Junio C Hamano:\n> Jeff King writes:\n> \n>> I'm a little negative on handling just SIGTERM. That would make the test\n>> pass, but does it really address the overall issue? To me, the\n>> usefulness is having exit values with consistent meanings.\n> \n> Yes. Unless the goal is to give Windows port pratically the same\n> signal semantics as ports on other platforms, I do not think special\n> casing SIGTERM (unless it is a very common signal on Windows and\n> others are unlikely to be useful) buys us much.\n\nI'm thinking the same. And, no, SIGTERM is not very common on Windows.\n\n-- Hannes\n"},{"id":"220240","messageId":"51B568A1.9090409@viscovery.net","threadId":"34030","inReplyTo":"CABPQNSa1-dna_b+q-U6jgYy7p6zeiT7dAwu1Mw47QAezSNYKqA@mail.gmail.com","subject":"[PATCH] mingw: make mingw_signal return the correct handler","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2013-06-10T05:48:17Z","receivedAt":"2013-06-10T05:48:17Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"From: Erik Faye-Lund \n\nReturning the SIGALRM handler for SIGINT is not very useful.\n\nSigned-off-by: Erik Faye-Lund \nSigned-off-by: Johannes Sixt \n---\nAm 6/7/2013 16:20, schrieb Erik Faye-Lund:\n> On Fri, Jun 7, 2013 at 3:07 PM, Johannes Sixt wrote:\n>> BTW, isn't mingw_signal() bogus in that it returns the SIGALRM handler\n>> even if a SIGINT handler is installed?\n> \n> Yep, that's a bug. Thanks for noticing.\n\nThis is your patch to address it.\n\n> I've pushed out a branch here that tries to address these issues, but\n> I haven't had time to test them. I'll post the series when I have. In\n> the mean time:\n> \n> https://github.com/kusma/git/tree/win32-signal-raise\n\nConcerning the other two patches:\n\n* SIGINT: perhaps handle only the SIG_DFL case (for the exit code) and\nforward all other cases to MSVCRT?\n\n* SIGTERM: it papers only over a general issue and should be dropped.\n\nIMO.\n\n-- Hannes\n\n compat/mingw.c | 4 +++-\n 1 file changed, 3 insertions(+), 1 deletion(-)\n\ndiff --git a/compat/mingw.c b/compat/mingw.c\nindex b295e2f..bb92c43 100644\n--- a/compat/mingw.c\n+++ b/compat/mingw.c\n@@ -1677,14 +1677,16 @@ int sigaction(int sig, struct sigaction *in,\nstruct sigaction *out)\n #undef signal\n sig_handler_t mingw_signal(int sig, sig_handler_t handler)\n {\n-\tsig_handler_t old = timer_fn;\n+\tsig_handler_t old;\n\n \tswitch (sig) {\n \tcase SIGALRM:\n+\t\told = timer_fn;\n \t\ttimer_fn = handler;\n \t\tbreak;\n\n \tcase SIGINT:\n+\t\told = sigint_fn;\n \t\tsigint_fn = handler;\n \t\tbreak;\n\n-- \n1.8.3.1504.g78dbf7a\n"},{"id":"220272","messageId":"CABPQNSZYuXWCOXYD=v_0axsj95bPQdVznUcC9usnT=FU2-j6tQ@mail.gmail.com","threadId":"34030","inReplyTo":"51B568A1.9090409@viscovery.net","subject":"Re: [PATCH] mingw: make mingw_signal return the correct handler","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@gmail.com","sentAt":"2013-06-10T11:37:21Z","receivedAt":"2013-06-10T11:37:21Z","isPatch":true,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Mon, Jun 10, 2013 at 7:48 AM, Johannes Sixt wrote:\n> From: Erik Faye-Lund \n>\n> Returning the SIGALRM handler for SIGINT is not very useful.\n>\n> Signed-off-by: Erik Faye-Lund \n> Signed-off-by: Johannes Sixt \n> ---\n> Am 6/7/2013 16:20, schrieb Erik Faye-Lund:\n>> On Fri, Jun 7, 2013 at 3:07 PM, Johannes Sixt wrote:\n>>> BTW, isn't mingw_signal() bogus in that it returns the SIGALRM handler\n>>> even if a SIGINT handler is installed?\n>>\n>> Yep, that's a bug. Thanks for noticing.\n>\n> This is your patch to address it.\n>\n>> I've pushed out a branch here that tries to address these issues, but\n>> I haven't had time to test them. I'll post the series when I have. In\n>> the mean time:\n>>\n>> https://github.com/kusma/git/tree/win32-signal-raise\n>\n> Concerning the other two patches:\n>\n> * SIGINT: perhaps handle only the SIG_DFL case (for the exit code) and\n> forward all other cases to MSVCRT?\n\nPerhaps. I'll have to think a bit about it, but it might very well be\nthe sanest approach, as long as it doesn't break git_terminal_prompt\n(which was the reason for the change in the first place). I can't of\nthe top of my head understand why it should, though.\n\n> * SIGTERM: it papers only over a general issue and should be dropped.\n\nFair enough.\n"},{"id":"220273","messageId":"CABPQNSbcAZZ_s7ow4HJ5HenSGSrHLUojqVygokgkQOgjLeDQEQ@mail.gmail.com","threadId":"34030","inReplyTo":"51B5648B.7020703@viscovery.net","subject":"Re: [PATCH] t0005: skip signal death exit code test on Windows","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@gmail.com","sentAt":"2013-06-10T11:38:16Z","receivedAt":"2013-06-10T11:38:16Z","isPatch":true,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Mon, Jun 10, 2013 at 7:30 AM, Johannes Sixt wrote:\n> Am 6/9/2013 22:31, schrieb Junio C Hamano:\n>> Jeff King writes:\n>>\n>>> I'm a little negative on handling just SIGTERM. That would make the test\n>>> pass, but does it really address the overall issue? To me, the\n>>> usefulness is having exit values with consistent meanings.\n>>\n>> Yes. Unless the goal is to give Windows port pratically the same\n>> signal semantics as ports on other platforms, I do not think special\n>> casing SIGTERM (unless it is a very common signal on Windows and\n>> others are unlikely to be useful) buys us much.\n>\n> I'm thinking the same. And, no, SIGTERM is not very common on Windows.\n>\n\nI have no strong feelings on SIGTERM, but my knee-jerk reaction is the\nsame. AFAIK, the only issue we've seen with it has been this one,\nwhich is synthetic.\n"},{"id":"220376","messageId":"7v8v2hg06g.fsf@alter.siamese.dyndns.org","threadId":"34030","inReplyTo":"51B568A1.9090409@viscovery.net","subject":"Re: [PATCH] mingw: make mingw_signal return the correct handler","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-06-10T20:50:31Z","receivedAt":"2013-06-10T20:50:31Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thanks.\n"}]}