{"thread":{"id":"36545","subject":"What's cooking in git.git (Apr 2014, #09; Tue, 29)","startedAt":"2014-04-29T22:38:07Z","lastAt":"2014-05-09T00:58:59Z","messageCount":35,"participants":["Junio C Hamano","Felipe Contreras","John Keeping","Greg Troxel","Chris Packham","David Lang","Jonathan Nieder"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"240253","messageId":"xmqq7g67iwxc.fsf@gitster.dls.corp.google.com","threadId":"36545","inReplyTo":null,"subject":"What's cooking in git.git (Apr 2014, #09; Tue, 29)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-04-29T22:38:07Z","receivedAt":"2014-04-29T22:38:07Z","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\nThe tip of the 'master' branch has passed v2.0.0-rc1.  Last minute\nfixes to newly added code keep flowing in, which is good.  I've\npicked up some topics that will not be part of the upcoming release\nto 'pu' not to lose them, but I didn't have time to give them a deep\nreading.\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[New Topics]\n\n* cc/replace-edit (2014-04-29) 4 commits\n - replace: add --edit option\n - replace: factor object resolution out of replace_object\n - replace: use OPT_CMDMODE to handle modes\n - replace: refactor command-mode determination\n\n\n* da/imap-send-use-credential-helper (2014-04-29) 1 commit\n - imap-send: use git-credential\n\n\n* dk/blame-reorg (2014-04-28) 1 commit\n - blame: large-scale performance rewrite\n\n\n* je/pager-do-not-recurse (2014-04-28) 1 commit\n - pager: do allow spawning pager recursively\n\n\n* jk/commit-C-pick-empty (2014-04-28) 1 commit\n - commit: do not complain of empty messages from -C\n\n\n* jk/utf8-switch-between-nfd-and-nfc (2014-04-29) 1 commit\n - t3910: show failure of core.precomposeunicode with decomposed filenames\n\n\n* mt/send-email-cover-to-cc (2014-04-29) 2 commits\n - test/send-email: to-cover, cc-cover tests\n - git-send-email: two new options: to-cover, cc-cover\n\n\n* nd/split-index (2014-04-29) 33 commits\n - SQUASH???\n - t1700: new tests for split-index mode\n - t2104: make sure split index mode is off for the version test\n - read-cache: force split index mode with GIT_TEST_SPLIT_INDEX\n - read-tree: note about dropping split-index mode or index version\n - read-tree: force split-index mode off on --index-output\n - rev-parse: add --shared-index-path to get shared index path\n - update-index --split-index: do not split if $GIT_DIR is read only\n - update-index: new options to enable/disable split index mode\n - split-index: strip pathname of on-disk replaced entries\n - split-index: do not invalidate cache-tree at read time\n - split-index: the reading part\n - split-index: the writing part\n - read-cache: mark updated entries for split index\n - read-cache: save deleted entries in split index\n - read-cache: mark new entries for split index\n - read-cache: split-index mode\n - read-cache: save index SHA-1 after reading\n - entry.c: update cache_changed if refresh_cache is set in checkout_entry()\n - cache-tree: mark istate->cache_changed on prime_cache_tree()\n - cache-tree: mark istate->cache_changed on cache tree update\n - cache-tree: mark istate->cache_changed on cache tree invalidation\n - unpack-trees: be specific what part of the index has changed\n - resolve-undo: be specific what part of the index has changed\n - update-index: be specific what part of the index has changed\n - read-cache: be specific what part of the index has changed\n - read-cache: be strict about \"changed\" in remove_marked_cache_entries()\n - read-cache: store in-memory flags in the first 12 bits of ce_flags\n - read-cache: relocate and unexport commit_locked_index()\n - read-cache: new API write_locked_index instead of write_index/write_cache\n - sequencer: do not update/refresh index if the lock cannot be held\n - ewah: delete unused ewah_read_mmap_native declaration\n - ewah: fix constness of ewah_read_mmap\n\n\n* tl/relax-in-poll-emulation (2014-04-29) 1 commit\n - compat/poll: sleep 1 millisecond to avoid busy wait\n\n--------------------------------------------------\n[Stalled]\n\n* tr/merge-recursive-index-only (2014-02-05) 3 commits\n - merge-recursive: -Xindex-only to leave worktree unchanged\n - merge-recursive: internal flag to avoid touching the worktree\n - merge-recursive: remove dead conditional in update_stages()\n (this branch is used by tr/remerge-diff.)\n\n Will hold.\n\n\n* tr/remerge-diff (2014-02-26) 5 commits\n . log --remerge-diff: show what the conflict resolution changed\n . name-hash: allow dir hashing even when !ignore_case\n . merge-recursive: allow storing conflict hunks in index\n . revision: fold all merge diff variants into an enum merge_diff_mode\n . combine-diff: do not pass revs->dense_combined_merges redundantly\n (this branch uses tr/merge-recursive-index-only.)\n\n \"log -p\" output learns a new way to let users inspect a merge\n commit by showing the differences between the automerged result\n with conflicts the person who recorded the merge would have seen\n and the final conflict resolution that was recorded in the merge.\n\n Needs to be rebased, now kb/fast-hashmap topic is in.\n\n\n* jk/makefile (2014-02-05) 16 commits\n - FIXUP\n - move LESS/LV pager environment to Makefile\n - Makefile: teach scripts to include make variables\n - FIXUP\n - Makefile: auto-build C strings from make variables\n - Makefile: drop *_SQ variables\n - FIXUP\n - Makefile: add c-quote helper function\n - Makefile: introduce sq function for shell-quoting\n - Makefile: always create files via make-var\n - Makefile: store GIT-* sentinel files in MAKE/\n - Makefile: prefer printf to echo for GIT-*\n - Makefile: use tempfile/mv strategy for GIT-*\n - Makefile: introduce make-var helper function\n - Makefile: fix git-instaweb dependency on gitweb\n - Makefile: drop USE_GETTEXT_SCHEME from GIT-CFLAGS\n (this branch is used by mm/pager-less-sans-S.)\n\n Simplify the Makefile rules and macros that exist primarily for\n quoting purposes, and make it easier to robustly express the\n dependency rules.\n\n Expecting a reroll.\n\n\n* po/everyday-doc (2014-01-27) 1 commit\n - Make 'git help everyday' work\n\n This may make the said command to emit something, but the source is\n not meant to be formatted into a manual pages to begin with, and\n also its contents are a bit stale.  It may be a good first step in\n the right direction, but needs more work to at least get the\n mark-up right before public consumption.\n\n Will hold.\n\n\n* jk/branch-at-publish-rebased (2014-01-17) 5 commits\n . t1507 (rev-parse-upstream): fix typo in test title\n . implement @{publish} shorthand\n . branch_get: provide per-branch pushremote pointers\n . branch_get: return early on error\n . sha1_name: refactor upstream_mark\n\n Give an easier access to the tracking branches from \"other\" side in\n a triangular workflow by introducing B@{publish} that works in a\n similar way to how B@{upstream} does.\n\n Meant to be used as a basis for whatever Ram wants to build on.\n\n Ejected from 'pu' to make room for fc/publish-vs-upstream topic.\n\n\n* rb/merge-prepare-commit-msg-hook (2014-01-10) 4 commits\n - merge: drop unused arg from abort_commit method signature\n - merge: make prepare_to_commit responsible for write_merge_state\n - t7505: ensure cleanup after hook blocks merge\n - t7505: add missing &&\n\n Expose more merge states (e.g. $GIT_DIR/MERGE_MODE) to hooks that\n run during \"git merge\".  The log message stresses too much on one\n hook, prepare-commit-msg, but it would equally apply to other hooks\n like post-merge, I think.\n\n Waiting for a reroll.\n\n\n* jl/submodule-recursive-checkout (2013-12-26) 5 commits\n - Teach checkout to recursively checkout submodules\n - submodule: teach unpack_trees() to update submodules\n - submodule: teach unpack_trees() to repopulate submodules\n - submodule: teach unpack_trees() to remove submodule contents\n - submodule: prepare for recursive checkout of submodules\n\n An RFCv2 exists ($gmane/241455) with sizable review comments.\n Expecting a reroll.\n\n\n* jc/graph-post-root-gap (2013-12-30) 3 commits\n - WIP: document what we want at the end\n - graph: remove unused code a bit\n - graph: stuff the current commit into graph->columns[]\n\n This was primarily a RFH ($gmane/239580).\n\n\n* np/pack-v4 (2013-09-18) 90 commits\n . packv4-parse.c: add tree offset caching\n . t1050: replace one instance of show-index with verify-pack\n . index-pack, pack-objects: allow creating .idx v2 with .pack v4\n . unpack-objects: decode v4 trees\n . unpack-objects: allow to save processed bytes to a buffer\n - ...\n\n Nico and Duy advancing the eternal vaporware pack-v4.  This is here\n primarily for wider distribution of the preview edition.\n\n Needs to be rebased, now the pack-bitmap series is in.\n\n\n* tg/perf-lib-test-perf-cleanup (2013-09-19) 2 commits\n - perf-lib: add test_perf_cleanup target\n - perf-lib: split starting the test from the execution\n\n Add test_perf_cleanup shell function to the perf suite, that allows\n the script writers to define a test with a clean-up action.\n\n Will hold.\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\n* jc/show-branch (2014-03-24) 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\n Waiting for the final step to lift the hard-limit before sending it out.\n\n--------------------------------------------------\n[Cooking]\n\n* bc/blame-crlf-test (2014-04-28) 1 commit\n - blame: correctly handle files regardless of autocrlf.\n\n\n* rs/ref-transaction (2014-04-29) 27 commits\n - refs.c: make lock_ref_sha1 static\n - refs.c: make write_ref_sha1 static\n - walker.c: use ref transaction for ref updates\n - fast-import.c: use a ref transaction when dumping tags\n - receive-pack.c: use a reference transaction for updating the refs\n - fetch.c: use a single ref transaction for all ref updates\n - fetch.c: change s_update_ref to use a ref transaction\n - fetch.c: clear errno before calling functions that might set it\n - refs.c: ref_transaction_commit should not free the transaction\n - refs.c: free the transaction before returning when number of updates is 0\n - refs.c: change update_ref to use a transaction\n - branch.c: use ref transaction for all ref updates\n - fast-import.c: change update_branch to use ref transactions\n - sequencer.c: use ref transactions for all ref updates\n - commit.c: use ref transactions for updates\n - replace.c: use the ref transaction functions for updates\n - tag.c: use ref transactions when doing updates\n - refs.c: ref_transaction_delete to check for error and return status\n - refs.c: change ref_transaction_create to do error checking and return status\n - refs.c: change ref_transaction_update() to do error checking and return status\n - refs.c: remove the onerr argument to ref_transaction_commit\n - refs.c: make update_ref_write update a strbuf on failure\n - update-ref.c: log transaction error from the update_ref\n - refs.c: make ref_update_reject_duplicates take a strbuf argument for errors\n - refs.c: add a strbuf argument to ref_transaction_commit for error logging\n - refs.c: allow passing NULL to ref_transaction_free\n - refs.c: constify the sha arguments for ref_transaction_create|delete|update\n (this branch uses mh/ref-transaction.)\n\n Updates most of the callsites to write_sha1_ref(), the low-level\n mechanism to update a ref, to use the ref-transaction API.\n\n Expecting a reroll.\n\n\n* ep/shell-command-substitution (2014-04-29) 27 commits\n - t1050-large.sh: use the $( ... ) construct for command substitution\n - t1020-subdirectory.sh: use the $( ... ) construct for command substitution\n - t1004-read-tree-m-u-wf.sh: use the $( ... ) construct for command substitution\n - t1003-read-tree-prefix.sh: use the $( ... ) construct for command substitution\n - t1002-read-tree-m-u-2way.sh: use the $( ... ) construct for command substitution\n - t1001-read-tree-m-2way.sh: use the $( ... ) construct for command substitution\n - t1000-read-tree-m-3way.sh: use the $( ... ) construct for command substitution\n - t0300-credentials.sh: use the $( ... ) construct for command substitution\n - t0030-stripspace.sh: use the $( ... ) construct for command substitution\n - t0026-eol-config.sh: use the $( ... ) construct for command substitution\n - t0025-crlf-auto.sh: use the $( ... ) construct for command substitution\n - t0020-crlf.sh: use the $( ... ) construct for command substitution\n - t0010-racy-git.sh: use the $( ... ) construct for command substitution\n - t0001-init.sh: use the $( ... ) construct for command substitution\n - p5302-pack-index.sh: use the $( ... ) construct for command substitution\n - lib-gpg.sh: use the $( ... ) construct for command substitution\n - lib-cvs.sh: use the $( ... ) construct for command substitution\n - lib-credential.sh: use the $( ... ) construct for command substitution\n - git-web--browse.sh: use the $( ... ) construct for command substitution\n - git-stash.sh: use the $( ... ) construct for command substitution\n - git-rebase.sh: use the $( ... ) construct for command substitution\n - git-rebase--merge.sh: use the $( ... ) construct for command substitution\n - git-pull.sh: use the $( ... ) construct for command substitution\n - appp.sh: use the $( ... ) construct for command substitution\n - t7900-subtree.sh: use the $( ... ) construct for command substitution\n - test-gitmw-lib.sh: use the $( ... ) construct for command substitution\n - t9365-continuing-queries.sh: use the $( ... ) construct for command substitution\n\n Adjust shell scripts to use $(cmd) instead of `cmd`.\n\n Will merge to 'next' and keep it there for the remainder of the cycle.\n\n\n* ib/test-selectively-run (2014-04-23) 3 commits\n - test-lib: '--run' to run only specific tests\n - test-lib: tests skipped by GIT_SKIP_TESTS say so\n - test-lib: Document short options in t/README\n\n Allow specifying only certain individual test pieces to be run\n using a range notation (e.g. \"t1234-test.sh --run='1-4 6 8 9-'\").\n\n\n* mm/mediawiki-encoding-fix (2014-04-23) 2 commits\n - git-remote-mediawiki: fix encoding issue for UTF-8 media files\n - git-remote-mediawiki: allow stop/start-ing the test server\n\n Will merge to 'next' and keep it there for the remainder of the cycle.\n\n\n* mw/symlinks (2014-04-24) 1 commit\n  (merged to 'next' on 2014-04-25 at 20b2af6)\n + setup: fix windows path buffer over-stepping\n\n A finishing touch fix to a new change already in 'master'.\n\n Will merge to 'master' by -rc2.\n\n\n* sk/tag-contains-wo-recursion (2014-04-25) 1 commit\n  (merged to 'next' on 2014-04-25 at f320750)\n + git tag --contains: avoid stack overflow\n\n Will keep in 'next' for the remainder of the cycle.\n\n\n* fc/remote-helpers-hg-bzr-graduation (2014-04-29) 11 commits\n - remote-hg: trivial cleanups\n - remote-hg: make sure we omit multiple heads\n - git-remote-hg: use internal clone's hgrc\n - t: remote-hg: split into setup test\n - remote-hg: properly detect missing contexts\n - remote-{hg,bzr}: store marks only on success\n - remote-hg: update to 'public' phase when pushing\n - remote-hg: fix parsing of custom committer\n  (merged to 'next' on 2014-04-22 at fed170a)\n + remote-helpers: move tests out of contrib\n + remote-helpers: move out of contrib\n + remote-helpers: squelch python import exceptions\n\n Move remote-hg and remote-bzr out of contrib/.  There were some\n suggestions on the follow-up fix patches still not in 'next', which\n may result in a reroll.\n\n Will merge to 'next' and keep it there for the remainder of the\n cycle.\n\n\n* fc/remote-helper-refmap (2014-04-21) 8 commits\n  (merged to 'next' on 2014-04-22 at fb5a4c2)\n + transport-helper: remove unnecessary strbuf resets\n + transport-helper: add support to delete branches\n + fast-export: add support to delete refs\n + fast-import: add support to delete refs\n + transport-helper: add support to push symbolic refs\n + transport-helper: add support for old:new refspec\n + fast-export: add new --refspec option\n + fast-export: improve argument parsing\n\n Allow remote-helper/fast-import based transport to rename the refs\n while transferring the history.\n\n Will keep in 'next' for the remainder of the cycle.\n\n\n* jk/external-diff-use-argv-array (2014-04-21) 5 commits\n  (merged to 'next' on 2014-04-22 at e6d92d7)\n + run_external_diff: refactor cmdline setup logic\n + run_external_diff: hoist common bits out of conditional\n + run_external_diff: drop fflush(NULL)\n + run_external_diff: clean up error handling\n + run_external_diff: use an argv_array for the environment\n\n Code clean-up (and a bugfix which has been merged for 2.0).\n\n Will keep in 'next' for the remainder of the cycle.\n\n\n* jx/blame-align-relative-time (2014-04-23) 2 commits\n  (merged to 'next' on 2014-04-23 at 858df39)\n + blame: dynamic blame_date_width for different locales\n + blame: fix broken time_buf paddings in relative timestamp\n\n \"git blame\" miscounted number of columns needed to show localized\n timestamps, resulting in jaggy left-side-edge of the source code\n lines in its output.\n\n Will keep in 'next' for the remainder of the cycle.\n\n\n* fc/merge-default-to-upstream (2014-04-22) 1 commit\n  (merged to 'next' on 2014-04-22 at 4f98483)\n + merge: enable defaulttoupstream by default\n\n \"git merge\" without argument, even when there is an upstream\n defined for the current branch, refused to run until\n merge.defaultToUpstream is set to true. Flip the default of that\n configuration variable to true.\n\n Will keep in 'next' for the remainder of the cycle.\n\n\n* fc/mergetool-prompt (2014-04-24) 2 commits\n - mergetool: document the default for --[no-]prompt\n  (merged to 'next' on 2014-04-22 at dcaec94)\n + mergetool: run prompt only if guessed tool\n\n mergetool.prompt used to default to 'true', always causing a confirmation\n \"do you really want to run the tool on this path\" to be shown.\n\n Among the two purposes the prompt serves, ignore the use case to\n confirm that the user wants to view particular path with the named\n tool, and make the prompt only to confirm the choice of the tool\n made by autodetection and defaulting.  For those who configured the\n tool explicitly, the prompt shown for the latter purpose is simply\n annoying.\n\n Strictly speaking, this is a backward incompatible change and the\n users need to explicitly set the variable to 'true' if they want to\n resurrect the now-ignored use case.\n\n Will merge to 'next' and keep it there for the remainder of the cycle.\n\n\n* fc/mergetools-vimdiff3 (2014-04-22) 1 commit\n  (merged to 'next' on 2014-04-22 at d843e75)\n + mergetools: add vimdiff3 mode\n\n Will keep in 'next' for the remainder of the cycle.\n\n\n* km/git-svn-workaround-older-getopt-long (2014-04-23) 1 commit\n  (merged to 'next' on 2014-04-23 at 3f35586)\n + t9117: use --prefix \"\" instead of --prefix=\"\"\n\n Will merge to 'master' by -rc2.\n\n\n* lr/git-run-setup-gently (2014-04-22) 1 commit\n  (merged to 'next' on 2014-04-22 at 5c2523f)\n + git.c: treat RUN_SETUP_GENTLY and RUN_SETUP as mutually exclusive\n\n Will keep in 'next' for the remainder of the cycle.\n\n\n* mk/doc-git-gui-display-untracked (2014-04-21) 1 commit\n  (merged to 'next' on 2014-04-22 at 385d39a)\n + Documentation: git-gui: describe gui.displayuntracked\n\n Will merge to 'master' by -rc2.\n\n\n* rh/prompt-pcmode-avoid-eval-on-refname (2014-04-22) 1 commit\n  (merged to 'next' on 2014-04-22 at 3a1506f)\n + git-prompt.sh: don't put unsanitized branch names in $PS1\n\n Will merge to 'master' by -rc2.\n\n\n* fc/publish-vs-upstream (2014-04-21) 8 commits\n - sha1_name: add support for @{publish} marks\n - sha1_name: simplify track finding\n - sha1_name: cleanup interpret_branch_name()\n - branch: display publish branch\n - push: add --set-publish option\n - branch: add --set-publish-to option\n - Add concept of 'publish' branch\n - t5516 (fetch-push): fix test restoration\n\n Add branch@{publish}; it seems that this is somewhat different from\n Ram and Peff started working on.  There were many discussion\n messages going back and forth but it does not appear that the\n design issues have been worked out among participants yet.\n\n\n* jl/git-gui-show-added-submodule-changes (2014-04-15) 1 commit\n - git-gui: show staged submodules regardless of ignore config\n\n Tentatively queued what I expect to receive via Pat Thoyts.\n\n\n* jl/gitk-show-added-submodule-changes (2014-04-15) 3 commits\n - gitk: show staged submodules regardless of ignore config\n - gitk: Merge branch 'new' of https://github.com/vnwildman/gitk\n - l10n: Init Vietnamese translation\n\n Tentatively queued what I expect to receive via Paul Mackerras.\n\n\n* bg/rebase-off-of-previous-branch (2014-04-16) 1 commit\n - git-rebase: print name of rev when using shorthand\n\n Teach \"git rebase -\" to report the concrete name of the branch\n (i.e. the previous one).\n\n But it stops short and does not do the same for \"git rebase @{-1}\".\n Expecting a reroll.\n\n\n* ef/send-email-absolute-path-to-the-command (2014-04-23) 2 commits\n  (merged to 'next' on 2014-04-23 at a657e5e)\n + send-email: windows drive prefix (e.g. C:) appears only at the beginning\n  (merged to 'next' on 2014-04-21 at 43bebb5)\n + send-email: recognize absolute path on Windows\n\n Will keep in 'next' for the remainder of the cycle.\n\n\n* jh/submodule-tests (2014-04-17) 1 commit\n - t7410: 210 tests for various 'git submodule update' scenarios\n\n\n* rs/ref-update-check-errors-early (2014-04-17) 2 commits\n  (merged to 'next' on 2014-04-21 at acc62aa)\n + commit.c: check for lock error and return early\n + sequencer.c: check for lock failure and bail early in fast_forward_to\n\n Will keep in 'next' for the remainder of the cycle.\n\n\n* sk/svn-parse-datestamp (2014-04-17) 1 commit\n  (merged to 'next' on 2014-04-21 at 5ff519f)\n + SVN.pm::parse_svn_date: allow timestamps with a single-digit hour\n\n Will keep in 'next' for the remainder of the cycle.\n\n\n* nd/index-pack-one-fd-per-thread (2014-04-16) 1 commit\n  (merged to 'next' on 2014-04-16 at b38d5a9)\n + index-pack: work around thread-unsafe pread()\n\n Enable threaded index-pack on platforms without thread-unsafe\n pread() emulation.\n\n Will keep in 'next' for the remainder of the cycle.\n\n\n* ym/fix-opportunistic-index-update-race (2014-04-10) 2 commits\n  (merged to 'next' on 2014-04-16 at cb92f4f)\n + read-cache.c: verify index file before we opportunistically update it\n + wrapper.c: add xpread() similar to xread()\n\n Read-only operations such as \"git status\" that internally refreshes\n the index write out the refreshed index to the disk to optimize\n future accesses to the working tree, but this could race with a\n \"read-write\" operation that modify the index while it is running.\n Detect such a race and avoid overwriting the index.\n\n Duy raised a good point that we may need to do the same for the\n normal writeout codepath, not just the \"opportunistic\" update\n codepath.  While that is true, nobody sane would be running two\n simultaneous operations that are clearly write-oriented competing\n with each other against the same index file.  So in that sense that\n can be done as a less urgent follow-up for this topic.\n\n Will keep in 'next' for the remainder of the cycle.\n\n\n* jl/status-added-submodule-is-never-ignored (2014-04-07) 2 commits\n - commit -m: commit staged submodules regardless of ignore config\n - status/commit: show staged submodules regardless of ignore config\n\n There also are a few patches Ronald Weiss and Jens are working on\n polishing around this topic, and a patch from Jens each for gitk\n and git-gui.\n\n Waiting for the dust to settle until picking them up all.\n\n\n* mh/lockfile (2014-04-15) 25 commits\n - trim_last_path_elm(): replace last_path_elm()\n - resolve_symlink(): take a strbuf parameter\n - resolve_symlink(): use a strbuf for internal scratch space\n - change lock_file::filename into a strbuf\n - commit_lock_file(): use a strbuf to manage temporary space\n - try_merge_strategy(): use a statically-allocated lock_file object\n - try_merge_strategy(): remove redundant lock_file allocation\n - struct lock_file: declare some fields volatile\n - lockfile: avoid transitory invalid states\n - commit_lock_file(): die() if called for unlocked lockfile object\n - commit_lock_file(): inline temporary variable\n - remove_lock_file(): call rollback_lock_file()\n - lock_file(): exit early if lockfile cannot be opened\n - write_packed_entry_fn(): convert cb_data into a (const int *)\n - prepare_index(): declare return value to be (const char *)\n - delete_ref_loose(): don't muck around in the lock_file's filename\n - cache.h: define constants LOCK_SUFFIX and LOCK_SUFFIX_LEN\n - lockfile.c: document the various states of lock_file objects\n - lock_file(): always add lock_file object to lock_file_list\n - hold_lock_file_for_append(): release lock on errors\n - lockfile: unlock file if lockfile permissions cannot be adjusted\n - rollback_lock_file(): set fd to -1\n - rollback_lock_file(): do not clear filename redundantly\n - api-lockfile: expand the documentation\n - unable_to_lock_die(): rename function from unable_to_lock_index_die()\n\n Refactor and fix corner-case bugs in the lockfile API, all looked\n sensible.\n\n Expecting a reroll.\n\n\n* mt/patch-id-stable (2014-04-29) 5 commits\n - t4204-patch-id.sh: default is now stable\n - patch-id: change default to stable\n - patch-id-test: test stable and unstable behaviour\n - test: add test_write_lines helper\n - patch-id: make it stable against hunk reordering\n\n Introduce a new way to compute patch-id for a patch that is not\n affected by the order of the paths that appear in the input.\n\n Will merge to 'next' and keep it there for the remainder of the cycle.\n\n\n* mh/ref-transaction (2014-04-07) 27 commits\n  (merged to 'next' on 2014-04-16 at a99f84d)\n + ref_transaction_commit(): work with transaction->updates in place\n + struct ref_update: add a type field\n + struct ref_update: add a lock field\n + ref_transaction_commit(): simplify code using temporary variables\n + struct ref_update: store refname as a FLEX_ARRAY\n + struct ref_update: rename field \"ref_name\" to \"refname\"\n + refs: remove API function update_refs()\n + update-ref --stdin: reimplement using reference transactions\n + refs: add a concept of a reference transaction\n + update-ref --stdin: harmonize error messages\n + update-ref --stdin: improve the error message for unexpected EOF\n + t1400: test one mistake at a time\n + update-ref --stdin -z: deprecate interpreting the empty string as zeros\n + update-ref.c: extract a new function, parse_next_sha1()\n + t1400: test that stdin -z update treats empty <newvalue> as zeros\n + update-ref --stdin: simplify error messages for missing oldvalues\n + update-ref --stdin: make error messages more consistent\n + update-ref --stdin: improve error messages for invalid values\n + update-ref.c: extract a new function, parse_refname()\n + parse_cmd_verify(): copy old_sha1 instead of evaluating <oldvalue> twice\n + update-ref --stdin: read the whole input at once\n + update_refs(): fix constness\n + refs.h: rename the action_on_err constants\n + t1400: add some more tests involving quoted arguments\n + parse_arg(): really test that argument is properly terminated\n + t1400: provide more usual input to the command\n + t1400: fix name and expected result of one test\n (this branch is used by rs/ref-transaction.)\n\n Update \"update-ref --stdin [-z]\" and then introduce a transactional\n support for (multi-)reference updates.\n\n Will keep in 'next' for the remainder of the cycle.\n\n\n* jc/apply-ignore-whitespace (2014-03-26) 1 commit\n  (merged to 'next' on 2014-04-04 at 53779a7)\n + apply --ignore-space-change: lines with and without leading whitespaces do not match\n\n \"--ignore-space-change\" option of \"git apply\" ignored the\n spaces at the beginning of line too aggressively, which is\n inconsistent with the option of the same name \"diff\" and \"git diff\"\n have.\n\n Will keep in 'next' for the remainder of the cycle.\n\n\n* as/grep-fullname-config (2014-03-20) 1 commit\n  (merged to 'next' on 2014-03-28 at 810a076)\n + grep: add grep.fullName config variable\n\n Add a configuration variable to force --full-name to be default for\n \"git grep\".\n\n This may cause regressions on scripted users that do not expect\n this new behaviour.\n\n Will keep in 'next' for the remainder of the cycle.\n\n\n* nd/multiple-work-trees (2014-03-25) 28 commits\n - count-objects: report unused files in $GIT_DIR/repos/...\n - gc: support prune --repos\n - gc: style change -- no SP before closing bracket\n - prune: strategies for linked checkouts\n - checkout: detach if the branch is already checked out elsewhere\n - checkout: clean up half-prepared directories in --to mode\n - checkout: support checking out into a new working directory\n - use new wrapper write_file() for simple file writing\n - wrapper.c: wrapper to open a file, fprintf then close\n - setup.c: support multi-checkout repo setup\n - setup.c: detect $GIT_COMMON_DIR check_repository_format_gently()\n - setup.c: convert check_repository_format_gently to use strbuf\n - setup.c: detect $GIT_COMMON_DIR in is_git_directory()\n - setup.c: convert is_git_directory() to use strbuf\n - git-stash: avoid hardcoding $GIT_DIR/logs/....\n - *.sh: avoid hardcoding $GIT_DIR/hooks/...\n - git-sh-setup.sh: use rev-parse --git-path to get $GIT_DIR/objects\n - $GIT_COMMON_DIR: a new environment variable\n - commit: use SEQ_DIR instead of hardcoding \"sequencer\"\n - fast-import: use git_path() for accessing .git dir instead of get_git_dir()\n - reflog: avoid constructing .lock path with git_path\n - *.sh: respect $GIT_INDEX_FILE\n - git_path(): be aware of file relocation in $GIT_DIR\n - path.c: group git_path(), git_pathdup() and strbuf_git_path() together\n - path.c: rename vsnpath() to do_git_path()\n - git_snpath(): retire and replace with strbuf_git_path()\n - path.c: make get_pathname() call sites return const char *\n - path.c: make get_pathname() return strbuf instead of static buffer\n\n A replacement for contrib/workdir/git-new-workdir that does not\n rely on symbolic links and make sharing of objects and refs safer\n by making the borrowee and borrowers aware of each other.\n\n Will hold.\n\n\n* ks/tree-diff-nway (2014-04-09) 20 commits\n  (merged to 'next' on 2014-04-09 at c17228e)\n + mingw: activate alloca\n  (merged to 'next' on 2014-04-08 at 6b74773)\n + combine-diff: speed it up, by using multiparent diff tree-walker directly\n + tree-diff: rework diff_tree() to generate diffs for multiparent cases as well\n + Portable alloca for Git\n  (merged to 'next' on 2014-03-31 at 16a7bd4)\n + tree-diff: reuse base str(buf) memory on sub-tree recursion\n + tree-diff: no need to call \"full\" diff_tree_sha1 from show_path()\n + tree-diff: rework diff_tree interface to be sha1 based\n + tree-diff: diff_tree() should now be static\n + tree-diff: remove special-case diff-emitting code for empty-tree cases\n  (merged to 'next' on 2014-03-25 at cfcbdac)\n + tree-diff: simplify tree_entry_pathcmp\n + tree-diff: show_path prototype is not needed anymore\n + tree-diff: rename compare_tree_entry -> tree_entry_pathcmp\n + tree-diff: move all action-taking code out of compare_tree_entry()\n + tree-diff: don't assume compare_tree_entry() returns -1,0,1\n  (merged to 'next' on 2014-03-21 at d872679)\n + tree-diff: consolidate code for emitting diffs and recursion in one place\n + tree-diff: show_tree() is not needed\n + tree-diff: no need to pass match to skip_uninteresting()\n + tree-diff: no need to manually verify that there is no mode change for a path\n + combine-diff: move changed-paths scanning logic into its own function\n + combine-diff: move show_log_first logic/action out of paths scanning\n\n Instead of running N pair-wise diff-trees when inspecting a\n N-parent merge, find the set of paths that were touched by walking\n N+1 trees in parallel.  These set of paths can then be turned into\n N pair-wise diff-tree results to be processed through rename\n detections and such.  And N=2 case nicely degenerates to the usual\n 2-way diff-tree, which is very nice.\n\n Will keep in 'next' for the remainder of the cycle.\n\n\n* cc/interpret-trailers (2014-04-29) 11 commits\n - Documentation: add documentation for 'git interpret-trailers'\n - trailer: add tests for commands in config file\n - trailer: execute command from 'trailer.<name>.command'\n - trailer: add tests for \"git interpret-trailers\"\n - trailer: add interpret-trailers command\n - trailer: put all the processing together and print\n - trailer: parse trailers from file or stdin\n - trailer: process command line trailer arguments\n - trailer: read and process config information\n - trailer: process trailers from input message and arguments\n - trailer: add data structures and basic functions\n\n A new filter to programatically edit the tail end of the commit log\n messages.\n"},{"id":"240755","messageId":"20140505184546.GB23935@serenity.lan","threadId":"36545","inReplyTo":"xmqq7g67iwxc.fsf@gitster.dls.corp.google.com","subject":"Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2014-05-05T18:45:46Z","receivedAt":"2014-05-05T18:45:46Z","isPatch":false,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Tue, Apr 29, 2014 at 03:38:07PM -0700, Junio C Hamano wrote:\n> * fc/remote-helpers-hg-bzr-graduation (2014-04-29) 11 commits\n>  - remote-hg: trivial cleanups\n>  - remote-hg: make sure we omit multiple heads\n>  - git-remote-hg: use internal clone's hgrc\n>  - t: remote-hg: split into setup test\n>  - remote-hg: properly detect missing contexts\n>  - remote-{hg,bzr}: store marks only on success\n>  - remote-hg: update to 'public' phase when pushing\n>  - remote-hg: fix parsing of custom committer\n>   (merged to 'next' on 2014-04-22 at fed170a)\n>  + remote-helpers: move tests out of contrib\n>  + remote-helpers: move out of contrib\n>  + remote-helpers: squelch python import exceptions\n> \n>  Move remote-hg and remote-bzr out of contrib/.  There were some\n>  suggestions on the follow-up fix patches still not in 'next', which\n>  may result in a reroll.\n> \n>  Will merge to 'next' and keep it there for the remainder of the\n>  cycle.\n\nI'd like to register my opposition to moving git-remote-{bzr,hg} out of\ncontrib/.\n\nI am not convinced that tools for interoperating with other VCSs need to\nbe part of core Git; as Junio has pointed out previously, while contrib/\nwas necessary for promoting associated tools when Git was young and had\nnot established mindshare, Git is now by far the most popular DVCS and\nis rapidly catching up with centralized systems.  Associated tools can\ntherefore live on their own and do not need to be promoted as part of\nGit itself (as git-imerge is doing successfully).\n\nIn the case of git-remote-hg specifically, the remote helper has to use\nan interface that the Mercurial developers consider unstable [1]; the\nversion currently on 'pu' fails the test suite for me because I have\nMercurial 3.0:\n\n\tAttributeError: 'mqrepo' object has no attribute 'getbundle'\n\nI do not want to end up in a situation where an update to Git is blocked\nby a distribution because git-remote-hg is not updated to support newer\nversions of Mercurial sufficiently quickly; this previously happened in\nGentoo due to git-svn and meant that was stuck on 1.7.8 until 1.7.13 was\nreleased [2].\n\nSince the remote helper interface is stable and the remote helpers do\nnot use any of the Git internals, I consider the risks of including them\nin core Git to outweigh the benefits of wider distribution.  In fact,\nthe remote helpers may benefit from having their own release cadences\nso that they can respond to changes in related projects more quickly\nthan the normal Git release cycle.\n\n\n[1] http://mercurial.selenic.com/wiki/MercurialApi#Why_you_shouldn.27t_use_Mercurial.27s_internal_API\n[2] https://bugs.gentoo.org/show_bug.cgi?id=418431\n"},{"id":"240774","messageId":"5367e1ac39571_5977e7531081@nysa.notmuch","threadId":"36545","inReplyTo":"20140505184546.GB23935@serenity.lan","subject":"Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-05T19:08:28Z","receivedAt":"2014-05-05T19:08:28Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"John Keeping wrote:\n> I am not convinced that tools for interoperating with other VCSs need to\n> be part of core Git; as Junio has pointed out previously, while contrib/\n> was necessary for promoting associated tools when Git was young and had\n> not established mindshare, Git is now by far the most popular DVCS and\n> is rapidly catching up with centralized systems.  Associated tools can\n> therefore live on their own and do not need to be promoted as part of\n> Git itself (as git-imerge is doing successfully).\n\nThen let's remove git-p4.\n\n> In the case of git-remote-hg specifically, the remote helper has to use\n> an interface that the Mercurial developers consider unstable [1];\n\nThere is no other sensible way of doing them.\n\n> the version currently on 'pu' fails the test suite for me because I\n> have Mercurial 3.0:\n> \n> \tAttributeError: 'mqrepo' object has no attribute 'getbundle'\n\nAnd because this patch has not been picked up[1].\n\n> I do not want to end up in a situation where an update to Git is blocked\n> by a distribution because git-remote-hg is not updated to support newer\n> versions of Mercurial sufficiently quickly; this previously happened in\n> Gentoo due to git-svn and meant that was stuck on 1.7.8 until 1.7.13 was\n> released [2].\n\nTravis-CI ensures that won't happen[2].\n\n> Since the remote helper interface is stable and the remote helpers do\n> not use any of the Git internals, I consider the risks of including them\n> in core Git to outweigh the benefits of wider distribution.  In fact,\n> the remote helpers may benefit from having their own release cadences\n> so that they can respond to changes in related projects more quickly\n> than the normal Git release cycle.\n\nMaybe, but git-remote-hg has already benefitted a lot from the wider\nexposure of being in 'contrib/', I'm sure it would benefit even more if\nit's distributed by default.\n\nMoreover, there's a ton of subpar tools out there[3], and I believe\ngiving the burden of choosing one to the user is detrimental to the Git\nproject. If we as a project say: this is the one we recommend, and has\nthe Git stamp, that helps the users tremendously.\n\nYour point is valid though, but it's valid not just for\ngit-remote-hg/bzr.\n\nSo I think these are the two options:\n\n  1) Include git-remote-hg/bzr to the core and distribute them by\n     default (as is the current intention)\n\n  2) Remove git-remote-hg/bzr entirely from the Git tree. And do the\n     same for other tools: git-p4, git-svn, git-cvs*. Given the huge\n     amount of people using Subversion, we might want to defer that one\n     for later, but eventually do it.\n\nI'd say for v2.0 we should go for 1), and 2) should be considered for\nv3.0, perhaps.\n\n[1] http://article.gmane.org/gmane.comp.version-control.git/248065\n[2] https://travis-ci.org/felipec/git\n[3] https://github.com/felipec/git/wiki/Comparison-of-git-remote-hg-alternatives\n\n-- \nFelipe Contreras\n"},{"id":"240772","messageId":"20140505195525.GC23935@serenity.lan","threadId":"36545","inReplyTo":"5367e1ac39571_5977e7531081@nysa.notmuch","subject":"Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2014-05-05T19:55:25Z","receivedAt":"2014-05-05T19:55:25Z","isPatch":false,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Mon, May 05, 2014 at 02:08:28PM -0500, Felipe Contreras wrote:\n> John Keeping wrote:\n> > I am not convinced that tools for interoperating with other VCSs need to\n> > be part of core Git; as Junio has pointed out previously, while contrib/\n> > was necessary for promoting associated tools when Git was young and had\n> > not established mindshare, Git is now by far the most popular DVCS and\n> > is rapidly catching up with centralized systems.  Associated tools can\n> > therefore live on their own and do not need to be promoted as part of\n> > Git itself (as git-imerge is doing successfully).\n> \n> Then let's remove git-p4.\n\nIf git-p4 were not already in the core, I would be making precisely the\nsame argument regarding it (and the others you identify below).\n\n> > In the case of git-remote-hg specifically, the remote helper has to use\n> > an interface that the Mercurial developers consider unstable [1];\n> \n> There is no other sensible way of doing them.\n> \n> > the version currently on 'pu' fails the test suite for me because I\n> > have Mercurial 3.0:\n> > \n> > \tAttributeError: 'mqrepo' object has no attribute 'getbundle'\n> \n> And because this patch has not been picked up[1].\n\nAnd it is now probably too late for that to make Git 2.0, which means it\nmay be another 12 weeks before it makes it into a Git release.  Since\nthis is quite a minor change it may make it into a stable release, but\nwhat would happen if the required changes were much more involved?\n\n> > I do not want to end up in a situation where an update to Git is blocked\n> > by a distribution because git-remote-hg is not updated to support newer\n> > versions of Mercurial sufficiently quickly; this previously happened in\n> > Gentoo due to git-svn and meant that was stuck on 1.7.8 until 1.7.13 was\n> > released [2].\n> \n> Travis-CI ensures that won't happen[2].\n\nI don't see that building against Mercurial's default branch, so it will\nnot help with future releases.\n\n> > Since the remote helper interface is stable and the remote helpers do\n> > not use any of the Git internals, I consider the risks of including them\n> > in core Git to outweigh the benefits of wider distribution.  In fact,\n> > the remote helpers may benefit from having their own release cadences\n> > so that they can respond to changes in related projects more quickly\n> > than the normal Git release cycle.\n> \n> Maybe, but git-remote-hg has already benefitted a lot from the wider\n> exposure of being in 'contrib/', I'm sure it would benefit even more if\n> it's distributed by default.\n\nIs that because it was included in contrib/ or just as a result of being\npublicised on this list and elsewhere?  I don't think git-imerge is\nsuffering from being its own project and git-subtree appears to have\nreceived very little attention despite being in contrib/.\n\n> Moreover, there's a ton of subpar tools out there[3], and I believe\n> giving the burden of choosing one to the user is detrimental to the Git\n> project. If we as a project say: this is the one we recommend, and has\n> the Git stamp, that helps the users tremendously.\n\nBut by choosing one now, we are stuck promoting that one even if a\nbetter alternative comes along in the future.  We have seen that with\ngit-cvsimport and it's not dissimilar to the situation with git-pull.\n\n> Your point is valid though, but it's valid not just for\n> git-remote-hg/bzr.\n> \n> So I think these are the two options:\n> \n>   1) Include git-remote-hg/bzr to the core and distribute them by\n>      default (as is the current intention)\n> \n>   2) Remove git-remote-hg/bzr entirely from the Git tree. And do the\n>      same for other tools: git-p4, git-svn, git-cvs*. Given the huge\n>      amount of people using Subversion, we might want to defer that one\n>      for later, but eventually do it.\n\nDon't forget git-archimport...\n\nMy personal vote would be for 2), splitting the bridges to other VCSs\ninto their own repositories but there would need to be some guarantee\nthat they would continue to be maintained.  I'm not sure it needs to\nwait for a major Git release since most of the impact is on package\nmaintainers and not end users.\n\n> I'd say for v2.0 we should go for 1), and 2) should be considered for\n> v3.0, perhaps.\n\nI don't think there is any advantage to adding new tools now if we only\nintend to remove them in the future.\n\n> [1] http://article.gmane.org/gmane.comp.version-control.git/248065\n> [2] https://travis-ci.org/felipec/git\n> [3] https://github.com/felipec/git/wiki/Comparison-of-git-remote-hg-alternatives\n"},{"id":"240759","messageId":"5367f5de8e411_1193d2f30cba@nysa.notmuch","threadId":"36545","inReplyTo":"20140505195525.GC23935@serenity.lan","subject":"Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-05T20:34:38Z","receivedAt":"2014-05-05T20:34:38Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"John Keeping wrote:\n> On Mon, May 05, 2014 at 02:08:28PM -0500, Felipe Contreras wrote:\n> > John Keeping wrote:\n> > > I am not convinced that tools for interoperating with other VCSs need to\n> > > be part of core Git; as Junio has pointed out previously, while contrib/\n> > > was necessary for promoting associated tools when Git was young and had\n> > > not established mindshare, Git is now by far the most popular DVCS and\n> > > is rapidly catching up with centralized systems.  Associated tools can\n> > > therefore live on their own and do not need to be promoted as part of\n> > > Git itself (as git-imerge is doing successfully).\n> > \n> > Then let's remove git-p4.\n> \n> If git-p4 were not already in the core, I would be making precisely the\n> same argument regarding it (and the others you identify below).\n\nSo basically you are arguing against any change.\n\n> > > the version currently on 'pu' fails the test suite for me because I\n> > > have Mercurial 3.0:\n> > > \n> > > \tAttributeError: 'mqrepo' object has no attribute 'getbundle'\n> > \n> > And because this patch has not been picked up[1].\n> \n> And it is now probably too late for that to make Git 2.0,\n\nThat's not for you to decide.\n\n> which means it may be another 12 weeks before it makes it into a Git\n> release.  Since this is quite a minor change it may make it into a\n> stable release, but what would happen if the required changes were\n> much more involved?\n\nAll the Mercurial API compatibility issues I have seen are trivial.\n\n> > > I do not want to end up in a situation where an update to Git is blocked\n> > > by a distribution because git-remote-hg is not updated to support newer\n> > > versions of Mercurial sufficiently quickly; this previously happened in\n> > > Gentoo due to git-svn and meant that was stuck on 1.7.8 until 1.7.13 was\n> > > released [2].\n> > \n> > Travis-CI ensures that won't happen[2].\n> \n> I don't see that building against Mercurial's default branch, so it will\n> not help with future releases.\n\nI can easily add that.\n\n> > > Since the remote helper interface is stable and the remote helpers do\n> > > not use any of the Git internals, I consider the risks of including them\n> > > in core Git to outweigh the benefits of wider distribution.  In fact,\n> > > the remote helpers may benefit from having their own release cadences\n> > > so that they can respond to changes in related projects more quickly\n> > > than the normal Git release cycle.\n> > \n> > Maybe, but git-remote-hg has already benefitted a lot from the wider\n> > exposure of being in 'contrib/', I'm sure it would benefit even more if\n> > it's distributed by default.\n> \n> Is that because it was included in contrib/ or just as a result of being\n> publicised on this list and elsewhere?\n\nThe former I'd bet.\n\n> I don't think git-imerge is suffering from being its own project and\n> git-subtree appears to have received very little attention despite\n> being in contrib/.\n\nApples and oranges. There aren't scores of tools out there trying to do\nwhat git-subtree does.\n\n> > Moreover, there's a ton of subpar tools out there[3], and I believe\n> > giving the burden of choosing one to the user is detrimental to the Git\n> > project. If we as a project say: this is the one we recommend, and has\n> > the Git stamp, that helps the users tremendously.\n> \n> But by choosing one now, we are stuck promoting that one even if a\n> better alternative comes along in the future.\n\nAre there better alternatives coming in the future?\n\n> > Your point is valid though, but it's valid not just for\n> > git-remote-hg/bzr.\n> > \n> > So I think these are the two options:\n> > \n> >   1) Include git-remote-hg/bzr to the core and distribute them by\n> >      default (as is the current intention)\n> > \n> >   2) Remove git-remote-hg/bzr entirely from the Git tree. And do the\n> >      same for other tools: git-p4, git-svn, git-cvs*. Given the huge\n> >      amount of people using Subversion, we might want to defer that one\n> >      for later, but eventually do it.\n> \n> Don't forget git-archimport...\n> \n> My personal vote would be for 2), splitting the bridges to other VCSs\n> into their own repositories but there would need to be some guarantee\n> that they would continue to be maintained.  I'm not sure it needs to\n> wait for a major Git release since most of the impact is on package\n> maintainers and not end users.\n\nSure, we might not need to wait for v3.0, but that's not the point. The\npoint is that we should be consistent, and that means going for 1) in\nv2.0.\n\n> > I'd say for v2.0 we should go for 1), and 2) should be considered for\n> > v3.0, perhaps.\n> \n> I don't think there is any advantage to adding new tools now if we only\n> intend to remove them in the future.\n\nDo we intend to remove them in the future? That hasn't been decided.\n\n-- \nFelipe Contreras\n"},{"id":"240734","messageId":"536805e9c9f42_1a7bde73088d@nysa.notmuch","threadId":"36545","inReplyTo":"5367f5de8e411_1193d2f30cba@nysa.notmuch","subject":"Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-05T21:43:05Z","receivedAt":"2014-05-05T21:43:05Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Felipe Contreras wrote:\n> John Keeping wrote:\n> > I don't see that building against Mercurial's default branch, so it\n> > will not help with future releases.\n> \n> I can easily add that.\n\nThere:\nhttps://travis-ci.org/felipec/git\n\n-- \nFelipe Contreras\n"},{"id":"240744","messageId":"xmqqoazb944d.fsf@gitster.dls.corp.google.com","threadId":"36545","inReplyTo":"20140505184546.GB23935@serenity.lan","subject":"Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-05-05T23:50:58Z","receivedAt":"2014-05-05T23:50:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"John Keeping <john@keeping.me.uk> writes:\n\n> On Tue, Apr 29, 2014 at 03:38:07PM -0700, Junio C Hamano wrote:\n>> * fc/remote-helpers-hg-bzr-graduation (2014-04-29) 11 commits\n>>  ...\n>>  Move remote-hg and remote-bzr out of contrib/.  There were some\n>>  suggestions on the follow-up fix patches still not in 'next', which\n>>  may result in a reroll.\n>> \n>>  Will merge to 'next' and keep it there for the remainder of the\n>>  cycle.\n>\n> I'd like to register my opposition to moving git-remote-{bzr,hg} out of\n> contrib/.\n> ...\n> In the case of git-remote-hg specifically, the remote helper has to use\n> an interface that the Mercurial developers consider unstable [1];...\n> I do not want to end up in a situation where an update to Git is blocked\n> by a distribution because git-remote-hg is not updated to support newer\n> versions of Mercurial sufficiently quickly; this previously happened in\n> Gentoo due to git-svn and meant that was stuck on 1.7.8 until 1.7.13 was\n> released [2].\n\nThe same argument would apply to git-svn, git-p4, and git-cvsimport,\nI would think.\n\nAmong these, I am not sure if we can find willing maintainers who\ncan give enough love to them.  But unlike these other importers,\nremote-hg and remote-bzr do have an active maintainer (and IIRC I\nthink I heard that Hg one even has an active competitor or two?) so\nI am reasonably confident that these can live on their own merit\noutside of my tree.  In the ideal world, I would think it may be\neven beneficial to the end users of these helpers to unbundle them.\n\nYou raised a good point on the issue of external dependencies may\nimpact Git as a whole, even for those who are not interested in the\nparticular remote helpers at all.  I'll have to think about it.\n\nThe silly thing is that I totally forgot that we almost got\nourselves into a very similar situation on cvsimport when a series\nwanted to make it cvsps3-only.  It is very possible nobody would\nhave picked up the entire new release, if we merged that change.\n\nHaving said all that, there is one caveat.\n\n> Since the remote helper interface is stable and the remote helpers do\n> not use any of the Git internals, I consider the risks of including them\n> in core Git to outweigh the benefits of wider distribution.\n\nYou are correct to say that a remote helper has to talk with a\nforeign system and it would not help to dictate the update schedule\nof helpers to match the release cycle of Git itself.  At the same\ntime, however, the interface the remote helpers use to talk to Git\nhas not been as stable as you seem to think, I am afraid.  For\nexample, a recent remote-hg/bzr series needed some enhancements to\nfast-import to achieve the feature parity with native transports by\nadding a missing feature or two on the Git side.\n\nSo in reality, a helper has to talk with two sides, needs to adjust\nto changes in the both sides, and both sides are changing.\n\nUnbundling a helper from Git would place more burden on the helper's\nmaintainer, because the helper has to know enough about versions and\nfeatures of both sides (the foreign system and Git) to adjust its\nbehaviour, to stay compatible with wider versions of both foreign\nsystems and Git.  Unbundling, when done properly, may give more\nideal user experience to the end users, because such a helper would\nallow them to pick up the latest (or stay on an older but known to\nbe stable) version of the helper and expect it to work with the\nforeign system and Git they happen to have.\n\nIt however would be easier to maintain if the helper maintainer\nknows a change to Git itself will be released at the same time as\nthe new version of the helper that takes advantage of the modified\nGit.  The helper maintainer only has to worry about compatibility\nwith the foreign side if it is bundled with Git.\n\nSo it boils down to \"how much resource are there to make sure a\nhelper will stay compatible with wider versions of both sides?\" and\n\"how far backwards are helper maintainers willing to bend to support\nusers better?\".\n"},{"id":"240783","messageId":"53682ae027b7d_24f8d2930881@nysa.notmuch","threadId":"36545","inReplyTo":"xmqqoazb944d.fsf@gitster.dls.corp.google.com","subject":"Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-06T00:20:48Z","receivedAt":"2014-05-06T00:20:48Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> John Keeping <john@keeping.me.uk> writes:\n\n> > In the case of git-remote-hg specifically, the remote helper has to use\n> > an interface that the Mercurial developers consider unstable [1];...\n> > I do not want to end up in a situation where an update to Git is blocked\n> > by a distribution because git-remote-hg is not updated to support newer\n> > versions of Mercurial sufficiently quickly; this previously happened in\n> > Gentoo due to git-svn and meant that was stuck on 1.7.8 until 1.7.13 was\n> > released [2].\n> \n> The same argument would apply to git-svn, git-p4, and git-cvsimport,\n> I would think.\n> \n> Among these, I am not sure if we can find willing maintainers who\n> can give enough love to them.  But unlike these other importers,\n> remote-hg and remote-bzr do have an active maintainer (and IIRC I\n> think I heard that Hg one even has an active competitor or two?)\n\nUnfortunately there are no more real competitors to remote-hg. A far as\nI can tell msysgit has dropped their remote helper, and gitifyhg is not\nbeing actively maintatined and it's even pointing to our git-remote-hg\nas probably the best alternative to use at the moment.\n\n> so I am reasonably confident that these can live on their own merit\n> outside of my tree.  In the ideal world, I would think it may be even\n> beneficial to the end users of these helpers to unbundle them.\n\nIt might be benefitial in the future, but right now I'm willing to bet\nthere's many people that don't know git-remote-hg/bzr even exist. If Git\nv2.0 distributes them by default, and they are mentioned in the release\nnotes:\n\n * Transparent support to pull and push to and from Mercurial and Bazaar\n   repositories is now enabled by default.\n\nMany more people will know about that, and in the future when we try to\nunbundle them they can shout if for some reason it would be inconvenient\nfor them. At the moment I don't think we can say for sure.\n\nEven if people don't use these bridges, I think just mentioning that\nfeature helps the project in general.\n\n> You raised a good point on the issue of external dependencies may\n> impact Git as a whole, even for those who are not interested in the\n> particular remote helpers at all.  I'll have to think about it.\n\nYes, it's worth thinking about it because it's a real possibility.\nHowever, real possibilities are many times not likely to happen, and I\nthink this is one of those cases.\n\nAs I've said, if history is any indication these issues won't happen. As\nfar as I can remember the only issues that have happened are backwards\ncompatibility issues, not present or future. And as I said I've setup\nTravisCI builds to detect those, which is why we haven't had those\nissues since then.\n\n> So it boils down to \"how much resource are there to make sure a helper\n> will stay compatible with wider versions of both sides?\" and \"how far\n> backwards are helper maintainers willing to bend to support users\n> better?\".\n\nThis is not that big of an issue. For example, notice how the changes in\nthe transport-helper to enable say --force and --dry-run did not\nrequire to align changes in remote-hg/bzr. That's because remote-hg/bzr\nhad already the code for these features, it was just not exercised until\nthe transport-helper was modified.\n\nI think the current transport-helper infraestructure is already good\nenough to detect the features and options of the remote helpers so\nunbundling wouldn't be a major problem.\n\nHaving said that alignment issues do happen, and we have one of those in\nGit v2.0, but I don't think they are a major concern (at least for\nremote-hg/bzr).\n\n-- \nFelipe Contreras\n"},{"id":"240793","messageId":"53682f52da35b_287c15bd30cc8@nysa.notmuch","threadId":"36545","inReplyTo":"53682ae027b7d_24f8d2930881@nysa.notmuch","subject":"Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-06T00:39:46Z","receivedAt":"2014-05-06T00:39:46Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Felipe Contreras wrote:\n> Having said that alignment issues do happen, and we have one of those\n> in Git v2.0, but I don't think they are a major concern (at least for\n> remote-hg/bzr).\n\nActually I just noticed that the remote-helpers side is not in the\n\"master\" branch.\n\nI don't know what is your plan with fc/remote-helpers-hg-bzr-graduation,\nbut for v2.0 we really want the patch 'remote-{hg,bzr}: store marks only\non success'. Explaining precisely why would take a lot of effort, but\nbasically it's related to 3994e64 (transport-helper: fix sync issue on\ncrashes).\n\nIf you are worried about merging the whole branch, I could pick only the\nimportant patches and reroll.\n\n-- \nFelipe Contreras\n"},{"id":"240778","messageId":"20140506080749.GD23935@serenity.lan","threadId":"36545","inReplyTo":"xmqqoazb944d.fsf@gitster.dls.corp.google.com","subject":"Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2014-05-06T08:07:49Z","receivedAt":"2014-05-06T08:07:49Z","isPatch":false,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Mon, May 05, 2014 at 04:50:58PM -0700, Junio C Hamano wrote:\n> John Keeping <john@keeping.me.uk> writes:\n> \n> Having said all that, there is one caveat.\n> \n> > Since the remote helper interface is stable and the remote helpers do\n> > not use any of the Git internals, I consider the risks of including them\n> > in core Git to outweigh the benefits of wider distribution.\n> \n> You are correct to say that a remote helper has to talk with a\n> foreign system and it would not help to dictate the update schedule\n> of helpers to match the release cycle of Git itself.  At the same\n> time, however, the interface the remote helpers use to talk to Git\n> has not been as stable as you seem to think, I am afraid.  For\n> example, a recent remote-hg/bzr series needed some enhancements to\n> fast-import to achieve the feature parity with native transports by\n> adding a missing feature or two on the Git side.\n\nThis doesn't qualify as an unstable interface for me.  In this case, the\nremote helpers could not support a feature without Git supporting it\nfirst, which is quite natural and the remote helper can then guard that\nfeature with a capability check.  I do not think it likely that the\nremote helper interface will ever change in such a way that all remote\nhelpers must be updated, at least not without a long deprecation period.\n\nThe Mercurial API makes no such guarantee; it is considered a private\nimplementation detail and most releases seem to contain some changes\nthat require all consumers to be updated.\n\nThere is a different level of urgency between \"you cannot use this new\nfeature until you update Git\" and \"if you update Mercurial then the\nremote helper will stop working\", and that's why I think the remote\nhelpers may benefit from a separate release schedule.\n"},{"id":"240801","messageId":"53689e17e6dfb_17dfb9b31017@nysa.notmuch","threadId":"36545","inReplyTo":"20140506080749.GD23935@serenity.lan","subject":"Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-06T08:32:23Z","receivedAt":"2014-05-06T08:32:23Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"John Keeping wrote:\n> The Mercurial API makes no such guarantee; it is considered a private\n> implementation detail and most releases seem to contain some changes\n> that require all consumers to be updated.\n> \n> There is a different level of urgency between \"you cannot use this new\n> feature until you update Git\" and \"if you update Mercurial then the\n> remote helper will stop working\",\n\ns/the remote helper will stop working/certain features of the remote\nhelper *might* stop working, but we are trying hard to make sure that\ndoesn't happen/\n\n-- \nFelipe Contreras\n"},{"id":"240820","messageId":"xmqqeh06g557.fsf@gitster.dls.corp.google.com","threadId":"36545","inReplyTo":"20140505195525.GC23935@serenity.lan","subject":"Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-05-06T17:59:16Z","receivedAt":"2014-05-06T17:59:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"John Keeping <john@keeping.me.uk> writes:\n\n> And it is now probably too late for that to make Git 2.0,...\n\nAnything with end-user visible changes in the core part that is not\na fix to a regression introduced between v1.9.0..master is too late\nfor the upcoming release.  We are way past -rc1.\n\n>> So I think these are the two options:\n>> \n>>   1) Include git-remote-hg/bzr to the core and distribute them by\n>>      default (as is the current intention)\n>> \n>>   2) Remove git-remote-hg/bzr entirely from the Git tree. And do the\n>>      same for other tools: git-p4, git-svn, git-cvs*. Given the huge\n>>      amount of people using Subversion, we might want to defer that one\n>>      for later, but eventually do it.\n\nIsn't there a middle ground?  The option 1.5 may be like this:\n\n - Eject tools in contrib/ that would benefit the users better if\n   they were outside my tree.  There are a few points to consider\n   when judging \"benefit better if outside\":\n\n   * Their release cycle requirements are better met outside my tree\n     (the \"remote-hg depends not just on Git but Hg internal\" issue\n     we have discussed).\n\n   * They are actively maintained.  The overall Git maintainer would\n     merely be being a bottleneck than being a helpful editor with\n     respect to these tools if we keep them in my tree, and we\n     expect that the tool maintainer would do a much better job\n     without me.\n\n - Keep tools that are not actively maintained but still used by the\n   users widely in my tree, but when their external dependencies\n   become baggage to Git as a whole, demote them to contrib/ and\n   stop installing them by default.\n\n - I would not mind having install.contrib-frotz target in the\n   top-level Makefile for each of the remaining contrib/frotz\n   hierarchies for those users and distro packagers who know their\n   platform meets the dependency requirements.\n\n> I'm not sure it needs to\n> wait for a major Git release since most of the impact is on package\n> maintainers and not end users.\n\nRemoval of features is a big deal, I would think, though.\n"},{"id":"240823","messageId":"53692ff63ae2f_2855e9b3089e@nysa.notmuch","threadId":"36545","inReplyTo":"xmqqeh06g557.fsf@gitster.dls.corp.google.com","subject":"Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-06T18:54:46Z","receivedAt":"2014-05-06T18:54:46Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> John Keeping <john@keeping.me.uk> writes:\n> \n> > And it is now probably too late for that to make Git 2.0,...\n> \n> Anything with end-user visible changes in the core part that is not\n> a fix to a regression introduced between v1.9.0..master is too late\n> for the upcoming release.  We are way past -rc1.\n\nThe patch in question only affects users of hg v3.0 since it's\nsurrounded by a 'check_version(3, 0)'. Therefore it cannot introduce\nregressions, there's no reason not to apply it.\n\n> >> So I think these are the two options:\n> >> \n> >>   1) Include git-remote-hg/bzr to the core and distribute them by\n> >>      default (as is the current intention)\n> >> \n> >>   2) Remove git-remote-hg/bzr entirely from the Git tree. And do the\n> >>      same for other tools: git-p4, git-svn, git-cvs*. Given the huge\n> >>      amount of people using Subversion, we might want to defer that one\n> >>      for later, but eventually do it.\n> \n> Isn't there a middle ground?  The option 1.5 may be like this:\n> \n>  - Eject tools in contrib/ that would benefit the users better if\n>    they were outside my tree.  There are a few points to consider\n>    when judging \"benefit better if outside\":\n> \n>    * Their release cycle requirements are better met outside my tree\n>      (the \"remote-hg depends not just on Git but Hg internal\" issue\n>      we have discussed).\n\nShouldn't *I* be the one most qualified to know if the release cycle\nrequirements are better met outside the git.git tree?\n\n>    * They are actively maintained.  The overall Git maintainer would\n>      merely be being a bottleneck than being a helpful editor with\n>      respect to these tools if we keep them in my tree, and we\n>      expect that the tool maintainer would do a much better job\n>      without me.\n\nPerhaps. But only if the patches are reviewed throught the git mailing\nlist.\n\nAnd what about the tools that are not actively maintainted? For example\n'contrib/hg-to-git'.\n \n>  - Keep tools that are not actively maintained but still used by the\n>    users widely in my tree, but when their external dependencies\n>    become baggage to Git as a whole, demote them to contrib/ and\n>    stop installing them by default.\n\nThat implies that git-remote-hg would become a baggage to Git as a\nwhole.\n\nIf you are arguing that git-remote-hg should be distributed by default,\nand only if the dependencies become a problem, demote to 'contrib/' that\nis fine. The same for git-p4 and other tools already out of contrib.\n\n-- \nFelipe Contreras\n"},{"id":"240829","messageId":"xmqqsiomem5t.fsf@gitster.dls.corp.google.com","threadId":"36545","inReplyTo":"20140506080749.GD23935@serenity.lan","subject":"Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-05-06T19:34:38Z","receivedAt":"2014-05-06T19:34:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"John Keeping <john@keeping.me.uk> writes:\n\n> On Mon, May 05, 2014 at 04:50:58PM -0700, Junio C Hamano wrote:\n>> ...\n>> At the same\n>> time, however, the interface the remote helpers use to talk to Git\n>> has not been as stable as you seem to think, I am afraid.  For\n>> example, a recent remote-hg/bzr series needed some enhancements to\n>> fast-import to achieve the feature parity with native transports by\n>> adding a missing feature or two on the Git side.\n>\n> This doesn't qualify as an unstable interface for me.\n\nThat is true, but that does not change the equation very much, no?\nTo a remote-helper maintainer, bundled is easier to maintain than\nunbundled, because both sides are changing, and regardless of the\nnature of the change, s/he would know how the Git side looks like if\nbundled.\n\nHaving said that, I agree with the conclusion of your message:\n\n> There is a different level of urgency between \"you cannot use this new\n> feature until you update Git\" and \"if you update Mercurial then the\n> remote helper will stop working\", and that's why I think the remote\n> helpers may benefit from a separate release schedule.\n\nand I am inclined to be persuaded that the users of remote-hg/bzr\nmay better off if they are unbundled from my tree.\n"},{"id":"240822","messageId":"53693a69ed668_2c65106f2ecdb@nysa.notmuch","threadId":"36545","inReplyTo":"xmqqsiomem5t.fsf@gitster.dls.corp.google.com","subject":"Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-06T19:39:21Z","receivedAt":"2014-05-06T19:39:21Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Having said that, I agree with the conclusion of your message:\n> \n> > There is a different level of urgency between \"you cannot use this\n> > new feature until you update Git\" and \"if you update Mercurial then\n> > the remote helper will stop working\", and that's why I think the\n> > remote helpers may benefit from a separate release schedule.\n\nThe conclusion is correct, the premises are not.\n\n-- \nFelipe Contreras\n"},{"id":"240859","messageId":"xmqqd2fqcv7s.fsf@gitster.dls.corp.google.com","threadId":"36545","inReplyTo":"20140505184546.GB23935@serenity.lan","subject":"Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-05-07T00:01:59Z","receivedAt":"2014-05-07T00:01:59Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"John Keeping <john@keeping.me.uk> writes:\n\n> I'd like to register my opposition to moving git-remote-{bzr,hg} out of\n> contrib/.\n>\n> I am not convinced that tools for interoperating with other VCSs need to\n> be part of core Git; as Junio has pointed out previously, while contrib/\n> was necessary ... Associated tools can\n> therefore live on their own and do not need to be promoted as part of\n> Git itself (as git-imerge is doing successfully).\n\nAnother thing to keep in mind is that we need to ensure that we give\na good way for these third-party tools to integrate well with the\ncore Git tools to form a single toolchest for the users.  I would\nlove to be able to do\n\n    $ (cd git.git && make install)\n    $ (cd git-imerge.git && make install)\n\nand then say \"git imerge\", \"git --help imerge\", etc.  The same for\nthe remote helpers that we may be splitting out of my tree into\ntheir own stand-alone projects.\n\nI _think_ it probably is OK for git-imerge.git/Makefile to peek into\nour Makefile, e.g.\n\n    $ cd git-imerge.git\n    $ make GIT_SOURCE_DIR=../git.git install\n\nto learn where imerge should install its subcommand implementation\nand documentation.  It might even want to borrow the test framework\nby using $GIT_SOURCE_DIR/t/test-lib.sh or somesuch.  There may be\nsome changes the third-party tool authors would want to have in our\nMakefile to help them better when building their tools this way; I\ndunno.\n\nI also think that there should be a way to make it really easy to\ninstall these third-party tools to augment the installed version of\nGit without having the source tree of Git.  We have ways for them to\nask us where things are expected to be, e.g.\n\n    $ git --html-path\n    $ git --man-path\n    $ git --exec-path\n\nbut I am not sure if these are enough, or if it would help them to\nadd a bit more, then what these \"a bit more\" are.\n"},{"id":"240861","messageId":"53697b9f6b978_1b76e132f05d@nysa.notmuch","threadId":"36545","inReplyTo":"xmqqd2fqcv7s.fsf@gitster.dls.corp.google.com","subject":"Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-07T00:17:35Z","receivedAt":"2014-05-07T00:17:35Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> I _think_ it probably is OK for git-imerge.git/Makefile to peek into\n> our Makefile, e.g.\n> \n>     $ cd git-imerge.git\n>     $ make GIT_SOURCE_DIR=../git.git install\n> \n> to learn where imerge should install its subcommand implementation and\n> documentation.  It might even want to borrow the test framework by\n> using $GIT_SOURCE_DIR/t/test-lib.sh or somesuch.\n\nSince Git's test framework heavily tied to git.git, sharness[1] is the\nonly sensible option. It might not have all the latest features of Git's\ntest framework, but it's standalone.\n\n[1] https://github.com/mlafeldt/sharness\n\n-- \nFelipe Contreras\n"},{"id":"240877","messageId":"20140507080558.GH23935@serenity.lan","threadId":"36545","inReplyTo":"xmqqd2fqcv7s.fsf@gitster.dls.corp.google.com","subject":"Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2014-05-07T08:05:58Z","receivedAt":"2014-05-07T08:05:58Z","isPatch":false,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Tue, May 06, 2014 at 05:01:59PM -0700, Junio C Hamano wrote:\n> John Keeping <john@keeping.me.uk> writes:\n> \n> > I'd like to register my opposition to moving git-remote-{bzr,hg} out of\n> > contrib/.\n> >\n> > I am not convinced that tools for interoperating with other VCSs need to\n> > be part of core Git; as Junio has pointed out previously, while contrib/\n> > was necessary ... Associated tools can\n> > therefore live on their own and do not need to be promoted as part of\n> > Git itself (as git-imerge is doing successfully).\n> \n> Another thing to keep in mind is that we need to ensure that we give\n> a good way for these third-party tools to integrate well with the\n> core Git tools to form a single toolchest for the users.  I would\n> love to be able to do\n> \n>     $ (cd git.git && make install)\n>     $ (cd git-imerge.git && make install)\n> \n> and then say \"git imerge\", \"git --help imerge\", etc.  The same for\n> the remote helpers that we may be splitting out of my tree into\n> their own stand-alone projects.\n\nThis can already work given suitable installation.  With\ngit-integration[1] I can type `git help integration` and it shows me the\nman page in the same way that `git help commit` does.  When I manually\nlinked the HTML file to the right place `git help -w integration` worked\nas well.\n\n> I _think_ it probably is OK for git-imerge.git/Makefile to peek into\n> our Makefile, e.g.\n> \n>     $ cd git-imerge.git\n>     $ make GIT_SOURCE_DIR=../git.git install\n> \n> to learn where imerge should install its subcommand implementation\n> and documentation.  It might even want to borrow the test framework\n> by using $GIT_SOURCE_DIR/t/test-lib.sh or somesuch.  There may be\n> some changes the third-party tool authors would want to have in our\n> Makefile to help them better when building their tools this way; I\n> dunno.\n> \n> I also think that there should be a way to make it really easy to\n> install these third-party tools to augment the installed version of\n> Git without having the source tree of Git.  We have ways for them to\n> ask us where things are expected to be, e.g.\n> \n>     $ git --html-path\n>     $ git --man-path\n>     $ git --exec-path\n> \n> but I am not sure if these are enough, or if it would help them to\n> add a bit more, then what these \"a bit more\" are.\n\nI think this is enough - now I need to go and make git-integration's\nMakefile use them by default rather than just using the same defaults as\ngit.git.\n\nPerhaps it would be useful to have a skeleton \"external Git utility\"\nproject under contrib/ which could demonstrate best practice for\ninstalling utilties that augment Git.\n\n[1] http://johnkeeping.github.io/git-integration/\n"},{"id":"240878","messageId":"5369fc2e2df7_2d8a92330813@nysa.notmuch","threadId":"36545","inReplyTo":"20140507080558.GH23935@serenity.lan","subject":"Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-07T09:26:06Z","receivedAt":"2014-05-07T09:26:06Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"John Keeping wrote:\n> > I also think that there should be a way to make it really easy to\n> > install these third-party tools to augment the installed version of\n> > Git without having the source tree of Git.  We have ways for them to\n> > ask us where things are expected to be, e.g.\n> > \n> >     $ git --html-path\n> >     $ git --man-path\n> >     $ git --exec-path\n> > \n> > but I am not sure if these are enough, or if it would help them to\n> > add a bit more, then what these \"a bit more\" are.\n> \n> I think this is enough - now I need to go and make git-integration's\n> Makefile use them by default rather than just using the same defaults as\n> git.git.\n\nThis is wrong. Subprojects should use /usr/bin/ and /usr/share/man/ and\nnot rely on the output of `git --exec-path` and so on.\n\nFor example if the user has installed Git in his $home, when building a\npackage the package manager would use ~/libexec/git-core, which is\nwrong.\n\nMoreover, if you are cross-compiling you won't be able to run the\ntarget's `git` binary.\n\nIf anything, it should be `pkg-config --variable=exec-path git`.\n\n-- \nFelipe Contreras\n"},{"id":"240884","messageId":"rmiha51dd99.fsf@fnord.ir.bbn.com","threadId":"36545","inReplyTo":"xmqqoazb944d.fsf@gitster.dls.corp.google.com","subject":"Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)","fromName":"Greg Troxel","fromEmail":"gdt@ir.bbn.com","sentAt":"2014-05-07T11:44:34Z","receivedAt":"2014-05-07T11:44:34Z","isPatch":false,"sender":{"key":"gdt@ir.bbn.com","avatar":null},"body":"\nJunio C Hamano <gitster@pobox.com> writes:\n\n> You raised a good point on the issue of external dependencies may\n> impact Git as a whole, even for those who are not interested in the\n> particular remote helpers at all.  I'll have to think about it.\n\n(As I'm sure you know, but starting from the beginning.)  There are\nbasically two ways that a program can be built.  One is by a user on a\nparticular system.  There, checking to see if various libraries are\ninstalled and if so enabling some additional feature (that isn't that\nhard/time-consuming to build) is entirely reasonable.\n\nIn a packaging system, dependencies are much more troublesome.\nDependencies have to be declared, and the build limited to use only\nthose declared dependencies, in order to get repeatable builds and\nbinary packages that can be used on other systems.  Dependencies that\nreally are required are fine.  But optional dependencies are a problem,\nbecause e.g. one doesn't want to require the presence of qt to build\nsomething (that isn't already enormous).   So if git needs mercurial and\nsubversion installed, plus perhaps 5 other things for less popular\nremote helpers, that starts to be a real burden.\n\n(I realize some packaging systems have a style where the union of the\npossible dependencies must be present to build, and then the resulting\nbinaries are allocated to split packages.  But that's not universal, and\nit still requires large amounts of unnecessary dependencies to build a\npackage from source.)\n\nIdeally, the core of git would have a small set of dependencies, and\noptional language bindings or remote helpers could be built\nindependently (by running a different build, after git proper was built\nand installed).  It seems more likely that the property of independent\nbuilds of optional components will be preserved if the various git-foo\npieces are in seaprate trees.  But if they are in subdirs of the main\ngit tree, and build by \"./configure && make && make install\" in the\nsubdir, that's arguably equivalent.\n"},{"id":"240933","messageId":"xmqqvbtha04t.fsf@gitster.dls.corp.google.com","threadId":"36545","inReplyTo":"20140507080558.GH23935@serenity.lan","subject":"Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-05-07T18:56:18Z","receivedAt":"2014-05-07T18:56:18Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"John Keeping <john@keeping.me.uk> writes:\n\n> On Tue, May 06, 2014 at 05:01:59PM -0700, Junio C Hamano wrote:\n> ...\n>> Another thing to keep in mind is that we need to ensure that we give\n>> a good way for these third-party tools to integrate well with the\n>> core Git tools to form a single toolchest for the users.  I would\n>> love to be able to do\n>> \n>>     $ (cd git.git && make install)\n>>     $ (cd git-imerge.git && make install)\n>> \n>> and then say \"git imerge\", \"git --help imerge\", etc.  The same for\n>> the remote helpers that we may be splitting out of my tree into\n>> their own stand-alone projects.\n>\n> This can already work given suitable installation.  With\n> git-integration[1] I can type `git help integration` and it shows me the\n> man page in the same way that `git help commit` does.  When I manually\n> linked the HTML file to the right place `git help -w integration` worked\n> as well.\n\nThat \"when I manually\" part is what I meant by \"we give a good way\nfor these third-party tools\" above, and \"make it really easy to\ninstall these third-party tools\" in the remaining part of the\nmessage you are responding to.\n\n> I think this is enough...\n\nThanks.\n\nThe reason why I CC'ed Michael was primarily because I thought you\nwere not one of those third-party tools maintainers (and secondarily\nI am a fairly big fan of imerge), but it is good to hear your\nopinion as another third-party provider.  Your git-integrate might\nturn into something I could augment my workflow with with some\nadditions.  What is missing (I only read the full manual page at\nhttp://johnkeeping.github.io/git-integration/git-integration.html)\nto support my workflow seems to be:\n\n - specifying a merge strategy per branch being merged;\n - support evil merges or picking a fix-up commit;\n - leaving an empty commit only to leave comment in the history.\n\nand until that happens, I'll keep using the Reintegrate script found\nin my 'todo' branch.\n"},{"id":"240938","messageId":"20140507192805.GA9035@serenity.lan","threadId":"36545","inReplyTo":"xmqqvbtha04t.fsf@gitster.dls.corp.google.com","subject":"Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2014-05-07T19:28:05Z","receivedAt":"2014-05-07T19:28:05Z","isPatch":false,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Wed, May 07, 2014 at 11:56:18AM -0700, Junio C Hamano wrote:\n> John Keeping <john@keeping.me.uk> writes:\n> \n> > On Tue, May 06, 2014 at 05:01:59PM -0700, Junio C Hamano wrote:\n> > ...\n> >> Another thing to keep in mind is that we need to ensure that we give\n> >> a good way for these third-party tools to integrate well with the\n> >> core Git tools to form a single toolchest for the users.  I would\n> >> love to be able to do\n> >> \n> >>     $ (cd git.git && make install)\n> >>     $ (cd git-imerge.git && make install)\n> >> \n> >> and then say \"git imerge\", \"git --help imerge\", etc.  The same for\n> >> the remote helpers that we may be splitting out of my tree into\n> >> their own stand-alone projects.\n> >\n> > This can already work given suitable installation.  With\n> > git-integration[1] I can type `git help integration` and it shows me the\n> > man page in the same way that `git help commit` does.  When I manually\n> > linked the HTML file to the right place `git help -w integration` worked\n> > as well.\n> \n> That \"when I manually\" part is what I meant by \"we give a good way\n> for these third-party tools\" above, and \"make it really easy to\n> install these third-party tools\" in the remaining part of the\n> message you are responding to.\n> \n> > I think this is enough...\n\nHaving thought about it a bit more after reading Felipe's reply, it\nwould be nice if there were some way for third-party tools to install\nHTML documentation without relying on `git --html-path` but I cannot see\nan obvious way to do that as there isn't a standard $HTML_PATH to match\n$MAN_PATH and $PATH.\n\nI've never tried `git help --info` until this thread, but I think we\ncould make some trivial improvements to that in order to support .info\ndocumentation for third-party tools.\n\n> The reason why I CC'ed Michael was primarily because I thought you\n> were not one of those third-party tools maintainers (and secondarily\n> I am a fairly big fan of imerge), but it is good to hear your\n> opinion as another third-party provider.  Your git-integrate might\n> turn into something I could augment my workflow with with some\n> additions.  What is missing (I only read the full manual page at\n> http://johnkeeping.github.io/git-integration/git-integration.html)\n> to support my workflow seems to be:\n> \n>  - specifying a merge strategy per branch being merged;\n\nThis is already supported by the \"merge\" instruction:\n\n\tIf any options are given after the ref (and on the same line)\n\tthen these are passed to git merge. This may be useful for\n\tspecifying an alternative merge strategy for a branch.\n\n>  - support evil merges or picking a fix-up commit;\n\nI have an implementation of this on a branch, but have never merged it\nbecause it's not something I need to do often and it is very hard to\nsupport for git-integration's \"status\" output.\n\nOne of my primary use cases for git-integration involves pulling\ntogether branches owned by others (either in the same repository or by\nhaving fetched from their repositories); in this case it is interesting\nto see if/how a branch has changed since the last time the integration\nbranch was built.  This also handles changes to the instruction sheet\nwithout an immediate rebuild.\n\nI have not found a good way of figuring out whether a fixup commit has\nbeen applied and squashed into a merge) so I have let the branch sit\nthere awaiting a perfect solution (which I doubt exists).  It may be\nthat the status of a fixup is unimportant, so it could just be marked as\nunknown; I am mostly convinced that marking it as unknown is going to be\nbetter than an heuristic that is right most of the time.\n\n>  - leaving an empty commit only to leave comment in the history.\n\nThis would be easy to add.\n\n> and until that happens, I'll keep using the Reintegrate script found\n> in my 'todo' branch.\n\nWhen I originally wrote git-integration I purposefully did not target\nyour workflow because I (perhaps wrongly) assumed that the interaction\nbetween the different integration branches would mean that Git was\nbetter served sticking to the custom Reintegrate script.\n"},{"id":"240940","messageId":"536a8e7cc2abc_76ff7a52ec74@nysa.notmuch","threadId":"36545","inReplyTo":"20140507192805.GA9035@serenity.lan","subject":"Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-07T19:50:20Z","receivedAt":"2014-05-07T19:50:20Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"John Keeping wrote:\n> Having thought about it a bit more after reading Felipe's reply, it\n> would be nice if there were some way for third-party tools to install\n> HTML documentation without relying on `git --html-path` but I cannot\n> see an obvious way to do that as there isn't a standard $HTML_PATH to\n> match $MAN_PATH and $PATH.\n\nUsing `git --html-path` for that is wrong.\n\n-- \nFelipe Contreras\n"},{"id":"240941","messageId":"536a8f6cd81e9_76ff7a52ec60@nysa.notmuch","threadId":"36545","inReplyTo":"rmiha51dd99.fsf@fnord.ir.bbn.com","subject":"Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-07T19:54:20Z","receivedAt":"2014-05-07T19:54:20Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Greg Troxel wrote:\n> In a packaging system, dependencies are much more troublesome.\n> Dependencies have to be declared, and the build limited to use only\n> those declared dependencies, in order to get repeatable builds and\n> binary packages that can be used on other systems.  Dependencies that\n> really are required are fine.  But optional dependencies are a\n> problem, because e.g. one doesn't want to require the presence of qt\n> to build something (that isn't already enormous).   So if git needs\n> mercurial and subversion installed, plus perhaps 5 other things for\n> less popular remote helpers, that starts to be a real burden.\n\nIt doesn't *need* them to build. The Mercurial/Bazaar dependencies are\noptional, both at build-time and at run-time. Most distributions would\nwant to test the functionality they are distributing, and for testing\nthey do need these dependencies.\n\n-- \nFelipe Contreras\n"},{"id":"240949","messageId":"536a96e762dc4_76ff7a52ec44@nysa.notmuch","threadId":"36545","inReplyTo":"xmqqvbtha04t.fsf@gitster.dls.corp.google.com","subject":"Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-07T20:26:15Z","receivedAt":"2014-05-07T20:26:15Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> That \"when I manually\" part is what I meant by \"we give a good way for\n> these third-party tools\" above, and \"make it really easy to install\n> these third-party tools\" in the remaining part of the message you are\n> responding to.\n\nWe need two things:\n\n  1) Provied a pkg-config, as all sane shared components do\n  2) Split the testing framework so third-parties don't have to rely on\n     yet another third-parth (shareness)\n\n> Your git-integrate might turn into something I could augment my\n> workflow with with some additions.\n> \n>  - specifying a merge strategy per branch being merged;\n\ngit-reintegrate[1] supports this.\n\n>  - support evil merges or picking a fix-up commit;\n\ngit-reintegrate supports this.\n\n>  - leaving an empty commit only to leave comment in the history.\n\nDone[2].\n\n\n> and until that happens, I'll keep using the Reintegrate script found\n> in my 'todo' branch.\n\nMy git-reintegrate supports everything John's git-integrate and in\naddition it supports generating the commands from an existing branch,\nlike your Reintegrate. IOW; it's superior.\n\n[1] https://github.com/felipec/git-reintegrate\n[2] https://github.com/felipec/git-reintegrate/commit/332412470c6e084f10ac2f8dc11e86ab4680974a\n\n-- \nFelipe Contreras\n"},{"id":"240952","messageId":"20140507204420.GB9035@serenity.lan","threadId":"36545","inReplyTo":"536a96e762dc4_76ff7a52ec44@nysa.notmuch","subject":"Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2014-05-07T20:44:20Z","receivedAt":"2014-05-07T20:44:20Z","isPatch":false,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Wed, May 07, 2014 at 03:26:15PM -0500, Felipe Contreras wrote:\n> Junio C Hamano wrote:\n> > Your git-integrate might turn into something I could augment my\n> > workflow with with some additions.\n> > \n> >  - specifying a merge strategy per branch being merged;\n> \n> git-reintegrate[1] supports this.\n> \n> >  - support evil merges or picking a fix-up commit;\n> \n> git-reintegrate supports this.\n> \n> >  - leaving an empty commit only to leave comment in the history.\n> \n> Done[2].\n> \n> \n> > and until that happens, I'll keep using the Reintegrate script found\n> > in my 'todo' branch.\n> \n> My git-reintegrate supports everything John's git-integrate and in\n> addition it supports generating the commands from an existing branch,\n> like your Reintegrate. IOW; it's superior.\n\nAnd yet the documentation is unchanged from the version you copied in\nfrom git-integration.  Personally I would much rather use a project\nwhich takes time to document all of the features rather than relying on\nreading the code to figure out the options.\n\nMore features does not make a project superior.\n"},{"id":"240969","messageId":"536aa7e4d07c7_76ff7a52ec36@nysa.notmuch","threadId":"36545","inReplyTo":"20140507204420.GB9035@serenity.lan","subject":"Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-07T21:38:44Z","receivedAt":"2014-05-07T21:38:44Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"John Keeping wrote:\n> On Wed, May 07, 2014 at 03:26:15PM -0500, Felipe Contreras wrote:\n> > Junio C Hamano wrote:\n> > > Your git-integrate might turn into something I could augment my\n> > > workflow with with some additions.\n> > > \n> > >  - specifying a merge strategy per branch being merged;\n> > \n> > git-reintegrate[1] supports this.\n> > \n> > >  - support evil merges or picking a fix-up commit;\n> > \n> > git-reintegrate supports this.\n> > \n> > >  - leaving an empty commit only to leave comment in the history.\n> > \n> > Done[2].\n> > \n> > \n> > > and until that happens, I'll keep using the Reintegrate script found\n> > > in my 'todo' branch.\n> > \n> > My git-reintegrate supports everything John's git-integrate and in\n> > addition it supports generating the commands from an existing branch,\n> > like your Reintegrate. IOW; it's superior.\n> \n> And yet the documentation is unchanged from the version you copied in\n> from git-integration.\n\nNot much has changed since v0.1 since that version already worked\nperfectly. But I'll update it.\n\n> Personally I would much rather use a project which takes time to\n> document all of the features rather than relying on reading the code\n> to figure out the options.\n\nAnd I would rather use a project that concentrates on having the\nfeatures users need.\n\n> More features does not make a project superior.\n\nNo, better features do.\n\nEither way. Documentation updated.\n\n-- \nFelipe Contreras\n"},{"id":"240975","messageId":"rmizjit6txa.fsf@fnord.ir.bbn.com","threadId":"36545","inReplyTo":"536a8f6cd81e9_76ff7a52ec60@nysa.notmuch","subject":"Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)","fromName":"Greg Troxel","fromEmail":"gdt@ir.bbn.com","sentAt":"2014-05-07T23:38:41Z","receivedAt":"2014-05-07T23:38:41Z","isPatch":false,"sender":{"key":"gdt@ir.bbn.com","avatar":null},"body":"\nFelipe Contreras <felipe.contreras@gmail.com> writes:\n\n> Greg Troxel wrote:\n>> In a packaging system, dependencies are much more troublesome.\n>> Dependencies have to be declared, and the build limited to use only\n>> those declared dependencies, in order to get repeatable builds and\n>> binary packages that can be used on other systems.  Dependencies that\n>> really are required are fine.  But optional dependencies are a\n>> problem, because e.g. one doesn't want to require the presence of qt\n>> to build something (that isn't already enormous).   So if git needs\n>> mercurial and subversion installed, plus perhaps 5 other things for\n>> less popular remote helpers, that starts to be a real burden.\n>\n> It doesn't *need* them to build. The Mercurial/Bazaar dependencies are\n> optional, both at build-time and at run-time. Most distributions would\n> want to test the functionality they are distributing, and for testing\n> they do need these dependencies.\n\nMy point is that a packaging of git needs to either decide to forego\nthese optional parts, or to include them, in the default case.  One\nchoice means that anyone who builds the package from source has to have\nthe dependencies, and the other means that users of the built package(s)\ncan't use the features.  I realize that in Linux it's perhaps typical to\nnot worry about burdening builders because actually building is very\nrare, but that's only reasonable because of having only one OS and\nperhaps three CPUs; with dozens each, building from source becomes more\nfrequent.  So I'm merely trying to suggest that it's better to have a\ncore package with a restrained set of dependencies, and then a way to\nbuild the other things independently (perhaps assuming the core is\nbuilt/installed), each with their own dependencies.\n\nIt turns out in pkgsrc that git-svn is a meta-package (with no files)\nthat depends on git-base (no man pages, no gitk) and p5-subversion.\nhg-git appears to be a separate source distribution, depending on a\npython implementation of the git formats.  So perhaps the situation is\ncurrently ok.  I was just trying to point out the issue to avoid\nregressions in the packaging situation.\n\n\n"},{"id":"240980","messageId":"536acd4578ac_3caaa612ec76@nysa.notmuch","threadId":"36545","inReplyTo":"rmizjit6txa.fsf@fnord.ir.bbn.com","subject":"Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-08T00:18:13Z","receivedAt":"2014-05-08T00:18:13Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Greg Troxel wrote:\n> \n> Felipe Contreras <felipe.contreras@gmail.com> writes:\n> \n> > Greg Troxel wrote:\n> >> In a packaging system, dependencies are much more troublesome.\n> >> Dependencies have to be declared, and the build limited to use only\n> >> those declared dependencies, in order to get repeatable builds and\n> >> binary packages that can be used on other systems.  Dependencies that\n> >> really are required are fine.  But optional dependencies are a\n> >> problem, because e.g. one doesn't want to require the presence of qt\n> >> to build something (that isn't already enormous).   So if git needs\n> >> mercurial and subversion installed, plus perhaps 5 other things for\n> >> less popular remote helpers, that starts to be a real burden.\n> >\n> > It doesn't *need* them to build. The Mercurial/Bazaar dependencies are\n> > optional, both at build-time and at run-time. Most distributions would\n> > want to test the functionality they are distributing, and for testing\n> > they do need these dependencies.\n> \n> My point is that a packaging of git needs to either decide to forego\n> these optional parts, or to include them, in the default case.\n\nThat is currently the case. They would be included by default, but not\nusable unless the *optional* dependencies are installed.\n\n> So I'm merely trying to suggest that it's better to have a core\n> package with a restrained set of dependencies, and then a way to build\n> the other things independently (perhaps assuming the core is\n> built/installed), each with their own dependencies.\n\nI'm all in favor of 'make install' installing only the core of Git, and\ndifferent targets for all the other parts.\n\nHowever, if you take a look at any distribution's packaing of Git you\nwould see why that wouldn't be desirable (they are full of hacks and\nfixes). If the build system is eventually fixed so one package can do\n'make install', another 'make install-p4', another 'make install-hg' and\nso on, that would be great. But we are pretty far from that.\n\n-- \nFelipe Contreras\n"},{"id":"240998","messageId":"536B3259.1050602@gmail.com","threadId":"36545","inReplyTo":"xmqqoazb944d.fsf@gitster.dls.corp.google.com","subject":"Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)","fromName":"Chris Packham","fromEmail":"judge.packham@gmail.com","sentAt":"2014-05-08T07:29:29Z","receivedAt":"2014-05-08T07:29:29Z","isPatch":false,"sender":{"key":"judge.packham@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155667?v=4"},"body":"Hi,\n\nOn 06/05/14 11:50, Junio C Hamano wrote:\n> John Keeping <john@keeping.me.uk> writes:\n> \n>> On Tue, Apr 29, 2014 at 03:38:07PM -0700, Junio C Hamano wrote:\n>>> * fc/remote-helpers-hg-bzr-graduation (2014-04-29) 11 commits\n>>>  ...\n>>>  Move remote-hg and remote-bzr out of contrib/.  There were some\n>>>  suggestions on the follow-up fix patches still not in 'next', which\n>>>  may result in a reroll.\n>>>\n>>>  Will merge to 'next' and keep it there for the remainder of the\n>>>  cycle.\n>>\n>> I'd like to register my opposition to moving git-remote-{bzr,hg} out of\n>> contrib/.\n>> ...\n>> In the case of git-remote-hg specifically, the remote helper has to use\n>> an interface that the Mercurial developers consider unstable [1];...\n>> I do not want to end up in a situation where an update to Git is blocked\n>> by a distribution because git-remote-hg is not updated to support newer\n>> versions of Mercurial sufficiently quickly; this previously happened in\n>> Gentoo due to git-svn and meant that was stuck on 1.7.8 until 1.7.13 was\n>> released [2].\n> \n> The same argument would apply to git-svn, git-p4, and git-cvsimport,\n> I would think.\n\nA bit of a crazy suggestion and a little off-topic. Assuming maintainers\ncan be found what about having these foreign vcs interfaces as\nsubmodules. That way they can be in Junio's tree as well as having their\nown release cycles. The same could apply to git-gui, gitk and gitweb. It\nwould also be a chance to eat-our-own-dogfood with submodules.\n\n> Among these, I am not sure if we can find willing maintainers who\n> can give enough love to them.  But unlike these other importers,\n> remote-hg and remote-bzr do have an active maintainer (and IIRC I\n> think I heard that Hg one even has an active competitor or two?) so\n> I am reasonably confident that these can live on their own merit\n> outside of my tree.  In the ideal world, I would think it may be\n> even beneficial to the end users of these helpers to unbundle them.\n> \n> You raised a good point on the issue of external dependencies may\n> impact Git as a whole, even for those who are not interested in the\n> particular remote helpers at all.  I'll have to think about it.\n> \n> The silly thing is that I totally forgot that we almost got\n> ourselves into a very similar situation on cvsimport when a series\n> wanted to make it cvsps3-only.  It is very possible nobody would\n> have picked up the entire new release, if we merged that change.\n> \n> Having said all that, there is one caveat.\n> \n>> Since the remote helper interface is stable and the remote helpers do\n>> not use any of the Git internals, I consider the risks of including them\n>> in core Git to outweigh the benefits of wider distribution.\n> \n> You are correct to say that a remote helper has to talk with a\n> foreign system and it would not help to dictate the update schedule\n> of helpers to match the release cycle of Git itself.  At the same\n> time, however, the interface the remote helpers use to talk to Git\n> has not been as stable as you seem to think, I am afraid.  For\n> example, a recent remote-hg/bzr series needed some enhancements to\n> fast-import to achieve the feature parity with native transports by\n> adding a missing feature or two on the Git side.\n> \n> So in reality, a helper has to talk with two sides, needs to adjust\n> to changes in the both sides, and both sides are changing.\n> \n> Unbundling a helper from Git would place more burden on the helper's\n> maintainer, because the helper has to know enough about versions and\n> features of both sides (the foreign system and Git) to adjust its\n> behaviour, to stay compatible with wider versions of both foreign\n> systems and Git.  Unbundling, when done properly, may give more\n> ideal user experience to the end users, because such a helper would\n> allow them to pick up the latest (or stay on an older but known to\n> be stable) version of the helper and expect it to work with the\n> foreign system and Git they happen to have.\n> \n> It however would be easier to maintain if the helper maintainer\n> knows a change to Git itself will be released at the same time as\n> the new version of the helper that takes advantage of the modified\n> Git.  The helper maintainer only has to worry about compatibility\n> with the foreign side if it is bundled with Git.\n> \n> So it boils down to \"how much resource are there to make sure a\n> helper will stay compatible with wider versions of both sides?\" and\n> \"how far backwards are helper maintainers willing to bend to support\n> users better?\".\n> \n> \n> \n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n> \n"},{"id":"241001","messageId":"536b38b55b7fc_4fa68b32eca@nysa.notmuch","threadId":"36545","inReplyTo":"536B3259.1050602@gmail.com","subject":"Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-08T07:56:37Z","receivedAt":"2014-05-08T07:56:37Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Chris Packham wrote:\n> On 06/05/14 11:50, Junio C Hamano wrote:\n> > The same argument would apply to git-svn, git-p4, and git-cvsimport,\n> > I would think.\n> \n> A bit of a crazy suggestion and a little off-topic. Assuming maintainers\n> can be found what about having these foreign vcs interfaces as\n> submodules. That way they can be in Junio's tree as well as having their\n> own release cycles. The same could apply to git-gui, gitk and gitweb. It\n> would also be a chance to eat-our-own-dogfood with submodules.\n\nIf submodules were an integral part of Git that would be a possibility,\nbut they are more like a hack.\n\n-- \nFelipe Contreras\n"},{"id":"241016","messageId":"xmqq61lg3ywu.fsf@gitster.dls.corp.google.com","threadId":"36545","inReplyTo":"536B3259.1050602@gmail.com","subject":"Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-05-08T18:31:29Z","receivedAt":"2014-05-08T18:31:29Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Chris Packham <judge.packham@gmail.com> writes:\n\n> A bit of a crazy suggestion and a little off-topic. Assuming maintainers\n> can be found what about having these foreign vcs interfaces as\n> submodules. That way they can be in Junio's tree as well as having their\n> own release cycles. The same could apply to git-gui, gitk and gitweb. It\n> would also be a chance to eat-our-own-dogfood with submodules.\n\nWhile I agree that submodules may be useful for git-gui and gitk\n(which already have their own repository and history), I do not\nthink that affects the issue of release cycles for third-party tools,\nespecially the ones with heavier foreign system dependencies like\nvcs interfaces.\n\nThe release schedule of Git itself places a lot of stress not to\nregress anything for existing users of Git, and the gitlink that\npoints at the specific commit in a submodule will stop advancing in\nthe top-level superproject (i.e. my tree) during the feature-freeze\nperiod before releases, just like any other paths (i.e. regular file\nblobs).\n\nA third-party product maintainer may have other ideas about\nstability of their product.  They may want to issue an unproven new\nrelease to adjust to a recent update made to their external\ndependencies as soon as code is written, relying on their ability to\nissue follow-up maintenance updates on their product in quick\nsuccession.  If many of them are bundled with Git, then we would\nhave to keep following these \"oops, that was wrong\" updates from all\nof these, which would add unscalable burden to a single choking\npoint.\n\nNot bundling gives third-party tools the freedom to evolve and worry\nabout compatibility with their dependencies on their own, and allows\nthem to treat Git as just one of the dependencies at the same level\nas their other dependencies.\n"},{"id":"241053","messageId":"alpine.DEB.2.02.1405081739310.17457@nftneq.ynat.uz","threadId":"36545","inReplyTo":"536b38b55b7fc_4fa68b32eca@nysa.notmuch","subject":"Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)","fromName":"David Lang","fromEmail":"david@lang.hm","sentAt":"2014-05-09T00:40:27Z","receivedAt":"2014-05-09T00:40:27Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Thu, 8 May 2014, Felipe Contreras wrote:\n\n> Chris Packham wrote:\n>> On 06/05/14 11:50, Junio C Hamano wrote:\n>>> The same argument would apply to git-svn, git-p4, and git-cvsimport,\n>>> I would think.\n>>\n>> A bit of a crazy suggestion and a little off-topic. Assuming maintainers\n>> can be found what about having these foreign vcs interfaces as\n>> submodules. That way they can be in Junio's tree as well as having their\n>> own release cycles. The same could apply to git-gui, gitk and gitweb. It\n>> would also be a chance to eat-our-own-dogfood with submodules.\n>\n> If submodules were an integral part of Git that would be a possibility,\n> but they are more like a hack.\n\nWell, if git.git can't use them, then how can anyone else be expected to.\n\nI haven't been paying close attention for a while, what would have to be done to \nmake submodules \"an integral part of Git\"?\n\nDavid Lang\n"},{"id":"241055","messageId":"536c28297875b_741a161d3109@nysa.notmuch","threadId":"36545","inReplyTo":"alpine.DEB.2.02.1405081739310.17457@nftneq.ynat.uz","subject":"Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-09T00:58:17Z","receivedAt":"2014-05-09T00:58:17Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"David Lang wrote:\n> On Thu, 8 May 2014, Felipe Contreras wrote:\n> > If submodules were an integral part of Git that would be a possibility,\n> > but they are more like a hack.\n> \n> Well, if git.git can't use them, then how can anyone else be expected to.\n\nThat is a very good question.\n\n> I haven't been paying close attention for a while, what would have to be done to \n> make submodules \"an integral part of Git\"?\n\nThis comes to mind:\n\nhttp://article.gmane.org/gmane.comp.version-control.git/220047\n\n-- \nFelipe Contreras\n"},{"id":"241054","messageId":"20140509005859.GF9218@google.com","threadId":"36545","inReplyTo":"alpine.DEB.2.02.1405081739310.17457@nftneq.ynat.uz","subject":"Submodule improvements (Re: What's cooking in git.git (Apr 2014, #09; Tue, 29))","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2014-05-09T00:58:59Z","receivedAt":"2014-05-09T00:58:59Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nDavid Lang wrote:\n\n> I haven't been paying close attention for a while, what would have\n> to be done to make submodules \"an integral part of Git\"?\n\nThe series at\nhttp://thread.gmane.org/gmane.comp.version-control.git/241455 is a\nstart.  I'm hoping to get a reroll done soon and then I can talk about\nlater steps.\n\nhttps://github.com/jlehmann/git-submod-enhancements/wiki has a rough\nroadmap, but really there's lots of commands that could be improved to\nrecurse into submodules and not many interdependencies involved so\nanyone can bite off a chunk.\n\nThanks,\nJonathan\n"}]}