{"thread":{"id":"46492","subject":"What's cooking in git.git (Jul 2017, #09; Mon, 31)","startedAt":"2017-07-31T22:30:37Z","lastAt":"2017-08-08T18:55:28Z","messageCount":15,"participants":["Junio C Hamano","Ramsay Jones","Sahil Dua","Stefan Beller","Ævar Arnfjörð Bjarmason","Igor Djordjevic"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"325352","messageId":"xmqqfudcgryb.fsf@gitster.mtv.corp.google.com","threadId":"46492","inReplyTo":null,"subject":"What's cooking in git.git (Jul 2017, #09; Mon, 31)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-07-31T22:30:20Z","receivedAt":"2017-07-31T22:30:37Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Here are the topics that have been cooking. Commits prefixed with\n'-' are only in 'pu' (proposed updates) while commits prefixed with\n'+' are in 'next'. The ones marked with '.' do not appear in any of\nthe integration branches, but I am still holding onto them.\n\nEven though -rc2 was scheduled for today, I'll wait for a few days\nso that we can tag with updated l10n; there isn't much change since\nthe first release candidate.\n\nYou can find the changes described here in the integration branches\nof the repositories listed at\n\n http://git-blame.blogspot.com/p/git-public-repositories.html\n\n--------------------------------------------------\n[Graduated to \"master\"]\n\n* js/blame-lib (2017-07-24) 1 commit\n (merged to 'next' on 2017-07-26 at db0d081012)\n + blame: fix memory corruption scrambling revision name in error message\n\n A hotfix to a topic already in 'master'.\n\n--------------------------------------------------\n[New Topics]\n\n* as/diff-options-grammofix (2017-07-31) 1 commit\n - diff-options doc: grammar fix\n\n A grammofix.\n\n--------------------------------------------------\n[Stalled]\n\n* mg/status-in-progress-info (2017-05-10) 2 commits\n - status --short --inprogress: spell it as --in-progress\n - status: show in-progress info for short status\n\n \"git status\" learns an option to report various operations\n (e.g. \"merging\") that the user is in the middle of.\n\n cf. \n\n\n* nd/worktree-move (2017-04-20) 6 commits\n - worktree remove: new command\n - worktree move: refuse to move worktrees with submodules\n - worktree move: accept destination as directory\n - worktree move: new command\n - worktree.c: add update_worktree_location()\n - worktree.c: add validate_worktree()\n\n \"git worktree\" learned move and remove subcommands.\n\n Expecting a reroll.\n cf. <20170420101024.7593-1-pclouds@gmail.com>\n cf. <20170421145916.mknekgqzhxffu7di@sigill.intra.peff.net>\n cf. \n\n\n* sg/clone-refspec-from-command-line-config (2017-06-16) 2 commits\n - Documentation/clone: document ignored configuration variables\n - clone: respect additional configured fetch refspecs during initial fetch\n (this branch is used by sg/remote-no-string-refspecs.)\n\n \"git clone -c var=val\" is a way to set configuration variables in\n the resulting repository, but it is more useful to also make these\n variables take effect while the initial clone is happening,\n e.g. these configuration variables could be fetch refspecs.\n\n Waiting for a response.\n cf. <20170617112228.vugswym4o4owf6wj@sigill.intra.peff.net>\n cf. \n\n\n* js/rebase-i-final (2017-07-27) 10 commits\n - rebase -i: rearrange fixup/squash lines using the rebase--helper\n - t3415: test fixup with wrapped oneline\n - rebase -i: skip unnecessary picks using the rebase--helper\n - rebase -i: check for missing commits in the rebase--helper\n - t3404: relax rebase.missingCommitsCheck tests\n - rebase -i: also expand/collapse the SHA-1s via the rebase--helper\n - rebase -i: do not invent onelines when expanding/collapsing SHA-1s\n - rebase -i: remove useless indentation\n - rebase -i: generate the script via rebase--helper\n - t3415: verify that an empty instructionFormat is handled as before\n\n The final batch to \"git rebase -i\" updates to move more code from\n the shell script to C.\n\n Expecting a reroll.\n\n\n* bp/fsmonitor (2017-06-12) 6 commits\n - fsmonitor: add a sample query-fsmonitor hook script for Watchman\n - fsmonitor: add documentation for the fsmonitor extension.\n - fsmonitor: add test cases for fsmonitor extension\n - fsmonitor: teach git to optionally utilize a file system monitor to speed up detecting new or changed files.\n - dir: make lookup_untracked() available outside of dir.c\n - bswap: add 64 bit endianness helper get_be64\n\n We learned to talk to watchman to speed up \"git status\".\n\n Expecting a reroll.\n cf. \n\n--------------------------------------------------\n[Cooking]\n\n* ah/doc-wserrorhighlight (2017-07-25) 1 commit\n (merged to 'next' on 2017-07-27 at cd1bb28d95)\n + doc: add missing values \"none\" and \"default\" for diff.wsErrorHighlight\n\n Doc update.\n\n Will cook in 'next'.\n\n\n* dc/fmt-merge-msg-microcleanup (2017-07-25) 1 commit\n (merged to 'next' on 2017-07-27 at 6df06eb788)\n + fmt-merge-msg: fix coding style\n\n Code cleanup.\n\n Will cook in 'next'.\n\n\n* js/git-gui-msgfmt-on-windows (2017-07-25) 7 commits\n - Merge branch 'js/msgfmt-on-windows' of ../git-gui into js/git-gui-msgfmt-on-windows\n - git-gui (MinGW): make use of MSys2's msgfmt\n - Merge remote-tracking branch 'philoakley/dup-gui'\n - git gui: allow for a long recentrepo list\n - git gui: de-dup selected repo from recentrepo history\n - git gui: cope with duplicates in _get_recentrepo\n - git-gui: remove duplicate entries from .gitconfig's gui.recentrepo\n\n Because recent Git for Windows do come with a real msgfmt, the\n build procedure for git-gui has been updated to use it instead of a\n hand-rolled substitute.\n\n\n* jt/subprocess-handshake (2017-07-26) 3 commits\n - sub-process: refactor handshake to common function\n - Documentation: migrate sub-process docs to header\n - Merge branch 'ls/filter-process-delayed' into jt/subprocess-handshake\n (this branch uses ls/filter-process-delayed.)\n\n Code cleanup.\n\n Will merge to and cook in 'next'.\n\n\n* lg/merge-signoff (2017-07-25) 1 commit\n - merge: add a --signoff flag\n\n \"git merge\" learned a \"--signoff\" option to add the Signed-off-by:\n trailer with the committer's name.\n\n\n* pb/trailers-from-command-line (2017-07-25) 4 commits\n - SQUASH???\n - interpret-trailers: add options for actions\n - trailers: introduce struct new_trailer_item\n - trailers: export action enums and corresponding lookup functions\n\n \"git interpret-trailers\" learned to take the trailer specifications\n from the command line that overrides the configured values.\n\n Expecting a reroll for compilation fix.\n\n\n* sb/submodule-recursive-checkout-detach-head (2017-07-28) 2 commits\n - Documentation/checkout: clarify submodule HEADs to be detached\n - recursive submodules: detach HEAD from new state\n\n \"git checkout --recursive\" may overwrite and rewind the history of\n the branch that happens to be checked out in submodule\n repositories, which might not be desirable. Detach the HEAD but\n still allow the recursive checkout to succeed in such a case.\n\n Undecided.\n This needs justification in a larger picture; it is unclear why\n this is better than rejecting recursive checkout, for example.\n\n\n* ti/external-sha1dc (2017-07-25) 1 commit\n (merged to 'next' on 2017-07-27 at d1ce394fe2)\n + hash: allow building with the external sha1dc library\n\n Platforms that ship with a separate sha1 with collision detection\n library can link to it instead of using the copy we ship as part of\n our source tree.\n\n Waiting for review to conclude\n cf. \n\n\n* bw/submodule-config-cleanup (2017-07-26) 17 commits\n - submodule: remove gitmodules_config\n - unpack-trees: improve loading of .gitmodules\n - submodule-config: lazy-load a repository's .gitmodules file\n - submodule-config: move submodule-config functions to submodule-config.c\n - submodule-config: remove support for overlaying repository config\n - diff: stop allowing diff to have submodules configured in .git/config\n - submodule: remove submodule_config callback routine\n - unpack-trees: don't rely on overlayed config\n - submodule: don't rely on overlayed config when setting diffopts\n - fetch: don't overlay config with submodule-config\n - submodule--helper: don't overlay config in update-clone\n - submodule--helper: don't overlay config in remote_submodule_branch\n - add, reset: ensure submodules can be added or reset\n - submodule: don't use submodule_from_name\n - t7411: check configuration parsing errors\n - Merge branch 'bc/object-id' into bw/submodule-config-cleanup\n - Merge branch 'bw/grep-recurse-submodules' into bw/submodule-config-cleanup\n (this branch uses bc/object-id, bw/grep-recurse-submodules and sb/object-id.)\n\n Code clean-up to avoid mixing values read from the .gitmodules file\n and values read from the .git/config file.\n\n\n* jb/t8008-cleanup (2017-07-26) 1 commit\n - t8008: rely on rev-parse'd HEAD instead of sha1 value\n\n Code clean-up.\n\n Will merge to and cook in 'next'.\n\n\n* rg/rerere-train-overwrite (2017-07-26) 1 commit\n - contrib/rerere-train: optionally overwrite existing resolutions\n\n The \"rerere-train\" script (in contrib/) learned the \"--overwrite\"\n option to allow overwriting existing recorded resolutions.\n\n Will merge to and cook in 'next'.\n\n\n* dl/credential-cache-socket-in-xdg-cache (2017-07-27) 1 commit\n - credential-cache: interpret an ECONNRESET as an EOF\n\n A recently added test for the \"credential-cache\" helper revealed\n that EOF detection done around the time the connection to the cache\n daemon is torn down were flaky. This was fixed by reacting to\n ECONNRESET and behaving as if we got an EOF.\n\n Will merge to and cook in 'next'.\n\n\n* eb/contacts-reported-by (2017-07-27) 1 commit\n - git-contacts: also recognise \"Reported-by:\"\n\n \"git contacts\" (in contrib/) now lists the address on the\n \"Reported-by:\" trailer to its output, in addition to those on\n S-o-b: and other trailers, to make it easier to notify (and thank)\n the original bug reporter.\n\n Will merge to and cook in 'next'.\n\n\n* js/run-process-parallel-api-fix (2017-07-21) 1 commit\n (merged to 'next' on 2017-07-27 at 4b54b69172)\n + run_processes_parallel: change confusing task_cb convention\n\n API fix.\n\n Will cook in 'next'.\n\n\n* cc/ref-is-hidden-microcleanup (2017-07-24) 1 commit\n (merged to 'next' on 2017-07-27 at 37af544e1c)\n + refs: use skip_prefix() in ref_is_hidden()\n\n Code cleanup.\n\n Will cook in 'next'.\n\n\n* bw/push-options-recursively-to-submodules (2017-07-20) 1 commit\n (merged to 'next' on 2017-07-27 at 26b3af2544)\n + submodule--helper: teach push-check to handle HEAD\n\n \"git push --recurse-submodules $there HEAD:$target\" was not\n propagated down to the submodules, but now it is.\n\n Will cook in 'next'.\n\n\n* jc/http-sslkey-and-ssl-cert-are-paths (2017-07-20) 1 commit\n (merged to 'next' on 2017-07-20 at 5489304b99)\n + http.c: http.sslcert and http.sslkey are both pathnames\n\n The http.{sslkey,sslCert} configuration variables are to be\n interpreted as a pathname that honors \"~[username]/\" prefix, but\n weren't, which has been fixed.\n\n Will cook in 'next'.\n\n\n* jt/fsck-code-cleanup (2017-07-26) 3 commits\n (merged to 'next' on 2017-07-26 at 7a17e279da)\n + fsck: cleanup unused variable\n (merged to 'next' on 2017-07-20 at f7045a8c47)\n + object: remove \"used\" field from struct object\n + fsck: remove redundant parse_tree() invocation\n\n Code clean-up.\n\n Will cook in 'next'.\n\n\n* rs/pack-objects-pbase-cleanup (2017-07-20) 1 commit\n (merged to 'next' on 2017-07-20 at a6b618559b)\n + pack-objects: remove unnecessary NULL check\n\n Code clean-up.\n\n Will cook in 'next'.\n\n\n* st/lib-gpg-kill-stray-agent (2017-07-20) 1 commit\n (merged to 'next' on 2017-07-20 at 8ea68c483f)\n + t: lib-gpg: flush gpg agent on startup\n\n Some versions of GnuPG fails to kill gpg-agent it auto-spawned\n and such a left-over agent can interfere with a test. Work it\n around by attempting to kill one before starting a new test.\n\n Will cook in 'next'.\n\n\n* jk/c99 (2017-07-18) 2 commits\n (merged to 'next' on 2017-07-18 at 1cfc30f7c1)\n + clean.c: use designated initializer\n + strbuf: use designated initializers in STRBUF_INIT\n\n Start using selected c99 constructs in small, stable and\n essentialpart of the system to catch people who care about\n older compilers that do not grok them.\n\n Will cook in 'next'.\n\n\n* jk/check-ref-format-oor-fix (2017-07-14) 1 commit\n - check-ref-format: require a repository for --branch\n\n Objected...\n cf. <20170717172709.GL93855@aiede.mtv.corp.google.com>\n\n\n* bw/grep-recurse-submodules (2017-07-18) 10 commits\n - grep: recurse in-process using 'struct repository'\n - submodule: merge repo_read_gitmodules and gitmodules_config\n - submodule: check for unmerged .gitmodules outside of config parsing\n - submodule: check for unstaged .gitmodules outside of config parsing\n - submodule: remove fetch.recursesubmodules from submodule-config parsing\n - submodule: remove submodule.fetchjobs from submodule-config parsing\n - config: add config_from_gitmodules\n - cache.h: add GITMODULES_FILE macro\n - repository: have the_repository use the_index\n - repo_read_index: don't discard the index\n (this branch is used by bw/submodule-config-cleanup.)\n\n\n* bw/object-id (2017-07-17) 3 commits\n (merged to 'next' on 2017-07-18 at 90d27c0e7c)\n + receive-pack: don't access hash of NULL object_id pointer\n + notes: don't access hash of NULL object_id pointer\n + tree-diff: don't access hash of NULL object_id pointer\n\n Conversion from uchar[20] to struct object_id continues.\n\n Will cook in 'next'.\n\n\n* ks/commit-abort-on-empty-message-fix (2017-07-17) 1 commit\n (merged to 'next' on 2017-07-27 at e81ad4c1dc)\n + commit: check for empty message before the check for untouched template\n\n \"git commit\" when seeing an totally empty message said \"you did not\n edit the message\", which is clearly wrong. The message has been\n corrected.\n\n Will cook in 'next'.\n\n\n* rs/bswap-ubsan-fix (2017-07-17) 2 commits\n (merged to 'next' on 2017-07-20 at ce6bad07b0)\n + bswap: convert get_be16, get_be32 and put_be32 to inline functions\n + bswap: convert to unsigned before shifting in get_be32\n\n Code clean-up.\n\n Will cook in 'next'.\n\n\n* rs/move-array (2017-07-17) 4 commits\n (merged to 'next' on 2017-07-20 at f3086cd20e)\n + ls-files: don't try to prune an empty index\n + apply: use COPY_ARRAY and MOVE_ARRAY in update_image()\n + use MOVE_ARRAY\n + add MOVE_ARRAY\n\n Code clean-up.\n\n Will cook in 'next'.\n\n\n* rs/stat-data-unaligned-reads-fix (2017-07-17) 1 commit\n (merged to 'next' on 2017-07-20 at e7d3782823)\n + dir: support platforms that require aligned reads\n\n Code clean-up.\n\n Will cook in 'next'.\n\n\n* wd/rebase-conflict-guide (2017-07-17) 1 commit\n (merged to 'next' on 2017-07-20 at c78e758b23)\n + rebase: make resolve message clearer for inexperienced users\n\n The advice message given when \"git rebase\" stops for conflicting\n changes has been improved.\n\n Will cook in 'next'.\n\n\n* hb/gitweb-project-list (2017-07-18) 1 commit\n (merged to 'next' on 2017-07-27 at c25d65ca25)\n + gitweb: skip unreadable subdirectories\n\n When a directory is not readable, \"gitweb\" fails to build the\n project list. Work this around by skipping such a directory.\n\n Will cook in 'next'.\n\n It might end up hiding a problem under the rug and a better\n solution might be to loudly complain to the administrator pointing\n out the problematic directory, but this will at least make it\n \"work\".\n\n\n* jk/ref-filter-colors (2017-07-13) 15 commits\n (merged to 'next' on 2017-07-18 at 75d4eb7ecf)\n + ref-filter: consult want_color() before emitting colors\n + pretty: respect color settings for %C placeholders\n + rev-list: pass diffopt->use_colors through to pretty-print\n + for-each-ref: load config earlier\n + color: check color.ui in git_default_config()\n + ref-filter: pass ref_format struct to atom parsers\n + ref-filter: factor out the parsing of sorting atoms\n + ref-filter: make parse_ref_filter_atom a private function\n + ref-filter: provide a function for parsing sort options\n + ref-filter: move need_color_reset_at_eol into ref_format\n + ref-filter: abstract ref format into its own struct\n + ref-filter: simplify automatic color reset\n + t: use test_decode_color rather than literal ANSI codes\n + docs/for-each-ref: update pointer to color syntax\n + check return value of verify_ref_format()\n\n \"%C(color name)\" in the pretty print format always produced ANSI\n color escape codes, which was an early design mistake. They now\n honor the configuration (e.g. \"color.ui = never\") and also tty-ness\n of the output medium.\n\n Will cook in 'next'.\n\n\n* sb/object-id (2017-07-13) 2 commits\n (merged to 'next' on 2017-07-18 at e4df0ba3b1)\n + tag: convert gpg_verify_tag to use struct object_id\n + commit: convert lookup_commit_graft to struct object_id\n (this branch is used by bc/object-id and bw/submodule-config-cleanup.)\n\n Conversion from uchar[20] to struct object_id continues.\n\n Will cook in 'next'.\n\n\n* rs/sha1-file-micro-optim (2017-07-09) 2 commits\n - SQUASH???\n - sha1_file: add slash once in for_each_file_in_obj_subdir()\n\n Code cleanup.\n\n Perhaps drop.\n cf. \n\n\n* ks/prepare-commit-msg-sample (2017-07-12) 4 commits\n (merged to 'next' on 2017-07-18 at 48d9650a30)\n + hook: add a simple first example\n + hook: add sign-off using \"interpret-trailers\"\n + hook: name the positional variables\n + hook: cleanup script\n\n Remove an example that is now obsolete from a sample hook,\n and improve an old example in it that added a sign-off manually\n to use the interpret-trailers command.\n\n Will cook in 'next'.\n\n\n* jc/allow-lazy-cas (2017-07-06) 1 commit\n - push: disable lazy --force-with-lease by default\n\n Because \"git push --force-with-lease[=]\" that relies on the\n stability of remote-tracking branches is unsafe when something\n fetches into the repository behind user's back, it is now disabled\n by default. A new configuration variable can be used to enable it\n by users who know what they are doing. This would pave the way to\n possibly turn `--force` into `--force-with-lease`.\n\n Undecided.\n Independent from disabling the feature by default, this stirred up\n a discussion to replace the DWIM heuristics with a better one, which\n deserves to be its own topic.\n cf. \n\n\n* bc/object-id (2017-07-17) 12 commits\n (merged to 'next' on 2017-07-18 at fd161056e4)\n + sha1_name: convert uses of 40 to GIT_SHA1_HEXSZ\n + sha1_name: convert GET_SHA1* flags to GET_OID*\n + sha1_name: convert get_sha1* to get_oid*\n + Convert remaining callers of get_sha1 to get_oid.\n + builtin/unpack-file: convert to struct object_id\n + bisect: convert bisect_checkout to struct object_id\n + builtin/update_ref: convert to struct object_id\n + sequencer: convert to struct object_id\n + remote: convert struct push_cas to struct object_id\n + submodule: convert submodule config lookup to use object_id\n + builtin/merge-tree: convert remaining caller of get_sha1 to object_id\n + builtin/fsck: convert remaining caller of get_sha1 to object_id\n (this branch is used by bw/submodule-config-cleanup; uses sb/object-id.)\n\n Conversion from uchar[20] to struct object_id continues.\n\n Will cook in 'next'.\n\n\n* jk/reflog-walk (2017-07-09) 9 commits\n (merged to 'next' on 2017-07-09 at 7449e964c6)\n + reflog-walk: apply --since/--until to reflog dates\n + reflog-walk: stop using fake parents\n + rev-list: check reflog_info before showing usage\n + get_revision_1(): replace do-while with an early return\n + log: do not free parents when walking reflog\n + log: clarify comment about reflog cycles\n + revision: disallow reflog walking with revs->limited\n + t1414: document some reflog-walk oddities\n + Merge branch 'jk/reflog-walk-maint' into jk/reflog-walk\n\n Numerous bugs in walking of reflogs via \"log -g\" and friends have\n been fixed.\n\n Will cook in 'next'.\n\n\n* sb/hashmap-cleanup (2017-07-05) 10 commits\n (merged to 'next' on 2017-07-12 at ce31d06165)\n + t/helper/test-hashmap: use custom data instead of duplicate cmp functions\n + name-hash.c: drop hashmap_cmp_fn cast\n + submodule-config.c: drop hashmap_cmp_fn cast\n + remote.c: drop hashmap_cmp_fn cast\n + patch-ids.c: drop hashmap_cmp_fn cast\n + convert/sub-process: drop cast to hashmap_cmp_fn\n + config.c: drop hashmap_cmp_fn cast\n + builtin/describe: drop hashmap_cmp_fn cast\n + builtin/difftool.c: drop hashmap_cmp_fn cast\n + attr.c: drop hashmap_cmp_fn cast\n\n Many uses of comparision callback function the hashmap API uses\n cast the callback function type when registering it to\n hashmap_init(), which defeats the compile time type checking when\n the callback interface changes (e.g. gaining more parameters).\n The callback implementations have been updated to take \"void *\"\n pointers and cast them to the type they expect instead.\n\n Will cook in 'next'.\n\n\n* ex/deprecate-empty-pathspec-as-match-all (2017-06-23) 2 commits\n (merged to 'next' on 2017-06-26 at d026281517)\n + pathspec: die on empty strings as pathspec\n + t0027: do not use an empty string as a pathspec element\n\n The final step to make an empty string as a pathspec element\n illegal. We started this by first deprecating and warning a\n pathspec that has such an element in 2.11 (Nov 2016).\n\n Hopefully we can merge this down to the 'master' by the end of the\n year? A deprecation warning period that is about 1 year does not\n sound too bad.\n\n Will cook in 'next'.\n\n\n* mh/packed-ref-store (2017-07-27) 31 commits\n (merged to 'next' on 2017-07-27 at 857dcb8cba)\n + packed_ref_store: handle a packed-refs file that is a symlink\n (merged to 'next' on 2017-07-05 at 6c68c603cc)\n + read_packed_refs(): die if `packed-refs` contains bogus data\n + t3210: add some tests of bogus packed-refs file contents\n + repack_without_refs(): don't lock or unlock the packed refs\n + commit_packed_refs(): remove call to `packed_refs_unlock()`\n + clear_packed_ref_cache(): don't protest if the lock is held\n + packed_refs_unlock(), packed_refs_is_locked(): new functions\n + packed_refs_lock(): report errors via a `struct strbuf *err`\n + packed_refs_lock(): function renamed from lock_packed_refs()\n + commit_packed_refs(): use a staging file separate from the lockfile\n + commit_packed_refs(): report errors rather than dying\n + packed_ref_store: make class into a subclass of `ref_store`\n + packed-backend: new module for handling packed references\n + packed_read_raw_ref(): new function, replacing `resolve_packed_ref()`\n + packed_ref_store: support iteration\n + packed_peel_ref(): new function, extracted from `files_peel_ref()`\n + repack_without_refs(): take a `packed_ref_store *` parameter\n + get_packed_ref(): take a `packed_ref_store *` parameter\n + rollback_packed_refs(): take a `packed_ref_store *` parameter\n + commit_packed_refs(): take a `packed_ref_store *` parameter\n + lock_packed_refs(): take a `packed_ref_store *` parameter\n + add_packed_ref(): take a `packed_ref_store *` parameter\n + get_packed_refs(): take a `packed_ref_store *` parameter\n + get_packed_ref_cache(): take a `packed_ref_store *` parameter\n + validate_packed_ref_cache(): take a `packed_ref_store *` parameter\n + clear_packed_ref_cache(): take a `packed_ref_store *` parameter\n + packed_ref_store: move `packed_refs_lock` member here\n + packed_ref_store: move `packed_refs_path` here\n + packed_ref_store: new struct\n + add_packed_ref(): teach function to overwrite existing refs\n + t1408: add a test of stale packed refs covered by loose refs\n\n The \"ref-store\" code reorganization continues.\n\n Will cook in 'next'.\n\n\n* sd/branch-copy (2017-06-18) 3 commits\n (merged to 'next' on 2017-07-18 at 5e3b9357ea)\n + branch: add a --copy (-c) option to go with --move (-m)\n + branch: add test for -m renaming multiple config sections\n + config: create a function to format section headers\n\n \"git branch\" learned \"-c/-C\" to create and switch to a new branch\n by copying an existing one.\n\n Will cook in 'next'.\n\n I personally do not think \"branch --copy master backup\" while on\n \"master\" that switches to \"backup\" is a good UI, and I *will* say\n \"I told you so\" when users complain after we merge this down to\n 'master'.\n\n\n* ls/filter-process-delayed (2017-06-30) 7 commits\n (merged to 'next' on 2017-07-05 at a35e644082)\n + convert: add \"status=delayed\" to filter process protocol\n + convert: refactor capabilities negotiation\n + convert: move multiple file filter error handling to separate function\n + convert: put the flags field before the flag itself for consistent style\n + t0021: write \"OUT \" only on success\n + t0021: make debug log file name configurable\n + t0021: keep filter log files on comparison\n (this branch is used by jt/subprocess-handshake.)\n\n The filter-process interface learned to allow a process with long\n latency give a \"delayed\" response.\n\n Will cook in 'next'.\n\n\n* sb/diff-color-move (2017-06-30) 26 commits\n (merged to 'next' on 2017-07-06 at 758ed40e4f)\n + diff: document the new --color-moved setting\n + diff.c: add dimming to moved line detection\n + diff.c: color moved lines differently, plain mode\n + diff.c: color moved lines differently\n + diff.c: buffer all output if asked to\n + diff.c: emit_diff_symbol learns about DIFF_SYMBOL_SUMMARY\n + diff.c: emit_diff_symbol learns about DIFF_SYMBOL_STAT_SEP\n + diff.c: convert word diffing to use emit_diff_symbol\n + diff.c: convert show_stats to use emit_diff_symbol\n + diff.c: convert emit_binary_diff_body to use emit_diff_symbol\n + submodule.c: migrate diff output to use emit_diff_symbol\n + diff.c: emit_diff_symbol learns DIFF_SYMBOL_REWRITE_DIFF\n + diff.c: emit_diff_symbol learns about DIFF_SYMBOL_BINARY_FILES\n + diff.c: emit_diff_symbol learns DIFF_SYMBOL_HEADER\n + diff.c: emit_diff_symbol learns DIFF_SYMBOL_FILEPAIR_{PLUS, MINUS}\n + diff.c: emit_diff_symbol learns DIFF_SYMBOL_CONTEXT_INCOMPLETE\n + diff.c: emit_diff_symbol learns DIFF_SYMBOL_WORDS[_PORCELAIN]\n + diff.c: migrate emit_line_checked to use emit_diff_symbol\n + diff.c: emit_diff_symbol learns DIFF_SYMBOL_NO_LF_EOF\n + diff.c: emit_diff_symbol learns DIFF_SYMBOL_CONTEXT_FRAGINFO\n + diff.c: emit_diff_symbol learns DIFF_SYMBOL_CONTEXT_MARKER\n + diff.c: introduce emit_diff_symbol\n + diff.c: factor out diff_flush_patch_all_file_pairs\n + diff.c: move line ending check into emit_hunk_header\n + diff.c: readability fix\n + Merge branch 'sb/hashmap-customize-comparison' into sb/diff-color-move\n\n \"git diff\" has been taught to optionally paint new lines that are\n the same as deleted lines elsewhere differently from genuinely new\n lines.\n\n Will cook in 'next'.\n\n--------------------------------------------------\n[Discarded]\n\n* mh/packed-ref-store-prep-extra (2017-06-18) 1 commit\n . prefix_ref_iterator_advance(): relax the check of trim length\n\n Split out of mh/packed-ref-store-prep.\n\n\n* nd/prune-in-worktree (2017-04-24) 12 commits\n . rev-list: expose and document --single-worktree\n . revision.c: --reflog add HEAD reflog from all worktrees\n . files-backend: make reflog iterator go through per-worktree reflog\n . revision.c: --all adds HEAD from all worktrees\n . refs: remove dead for_each_*_submodule()\n . revision.c: use refs_for_each*() instead of for_each_*_submodule()\n . refs: add refs_head_ref()\n . refs: move submodule slash stripping code to get_submodule_ref_store\n . refs.c: refactor get_submodule_ref_store(), share common free block\n . revision.c: --indexed-objects add objects from all worktrees\n . revision.c: refactor add_index_objects_to_pending()\n . revision.h: new flag in struct rev_info wrt. worktree-related refs\n\n \"git gc\" and friends when multiple worktrees are used off of a\n single repository did not consider the index and per-worktree refs\n of other worktrees as the root for reachability traversal, making\n objects that are in use only in other worktrees to be subject to\n garbage collection.\n"},{"id":"325357","messageId":"232547ab-3b87-debc-36a4-d2285ec10a06@ramsayjones.plus.com","threadId":"46492","inReplyTo":"xmqqfudcgryb.fsf@gitster.mtv.corp.google.com","subject":"Re: What's cooking in git.git (Jul 2017, #09; Mon, 31)","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsayjones.plus.com","sentAt":"2017-07-31T23:36:33Z","receivedAt":"2017-07-31T23:36:41Z","isPatch":false,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"\n\nOn 31/07/17 23:30, Junio C Hamano wrote:\n[snip]\n> \n> * sd/branch-copy (2017-06-18) 3 commits\n> (merged to 'next' on 2017-07-18 at 5e3b9357ea)\n> + branch: add a --copy (-c) option to go with --move (-m)\n> + branch: add test for -m renaming multiple config sections\n> + config: create a function to format section headers\n> \n> \"git branch\" learned \"-c/-C\" to create and switch to a new branch\n> by copying an existing one.\n> \n> Will cook in 'next'.\n> \n> I personally do not think \"branch --copy master backup\" while on\n> \"master\" that switches to \"backup\" is a good UI, and I *will* say\n> \"I told you so\" when users complain after we merge this down to\n> 'master'.\n\nI wouldn't normally comment on an issue like this because I am\nnot very good at specifying, designing and evaluating UIs (so\nwho in their right mind would listen to me). ;-)\n\nFWIW, I suspect that I would not like using this interface either\nand would, therefore, not use it. However, I guess the worst that\nwould happen, is that it would gain another 'wort' (--option) to\nturn off the \"switches to backup\" branch. :-D\n\nI didn't want you to think that the lack of comments on this was\nbecause everybody agreed that it was a good idea.\n\nATB,\nRamsay Jones\n\n\n"},{"id":"325585","messageId":"CALiud+nKTNsr_z528Wwv3ELLk+uKoJkYa8hctg-C1dtXrbkvKg@mail.gmail.com","threadId":"46492","inReplyTo":"xmqqfudcgryb.fsf@gitster.mtv.corp.google.com","subject":"Re: What's cooking in git.git (Jul 2017, #09; Mon, 31)","fromName":"Sahil Dua","fromEmail":"sahildua2305@gmail.com","sentAt":"2017-08-03T20:17:16Z","receivedAt":"2017-08-03T20:17:42Z","isPatch":false,"sender":{"key":"sahildua2305@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5206277?v=4"},"body":">\n> * sd/branch-copy (2017-06-18) 3 commits\n> (merged to 'next' on 2017-07-18 at 5e3b9357ea)\n> + branch: add a --copy (-c) option to go with --move (-m)\n> + branch: add test for -m renaming multiple config sections\n> + config: create a function to format section headers\n>\n> \"git branch\" learned \"-c/-C\" to create and switch to a new branch\n> by copying an existing one.\n>\n> Will cook in 'next'.\n\nJunio, are we still waiting for interaction with other patches to\nsettle down or simply cooking it further for any potential\nfeedback/suggestions on this?\n\n>\n> I personally do not think \"branch --copy master backup\" while on\n> \"master\" that switches to \"backup\" is a good UI, and I *will* say\n> \"I told you so\" when users complain after we merge this down to\n> 'master'.\n>\n"},{"id":"325587","messageId":"CAGZ79kbQcWAT=MkVHK2T+n=jUGmShcnN52137TmcKjm1B4UwOQ@mail.gmail.com","threadId":"46492","inReplyTo":"CALiud+nKTNsr_z528Wwv3ELLk+uKoJkYa8hctg-C1dtXrbkvKg@mail.gmail.com","subject":"Re: What's cooking in git.git (Jul 2017, #09; Mon, 31)","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-08-03T20:23:09Z","receivedAt":"2017-08-03T20:23:17Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Thu, Aug 3, 2017 at 1:17 PM, Sahil Dua wrote:\n>>\n>> * sd/branch-copy (2017-06-18) 3 commits\n>> (merged to 'next' on 2017-07-18 at 5e3b9357ea)\n>> + branch: add a --copy (-c) option to go with --move (-m)\n>> + branch: add test for -m renaming multiple config sections\n>> + config: create a function to format section headers\n>>\n>> \"git branch\" learned \"-c/-C\" to create and switch to a new branch\n>> by copying an existing one.\n>>\n>> Will cook in 'next'.\n>\n> Junio, are we still waiting for interaction with other patches to\n> settle down or simply cooking it further for any potential\n> feedback/suggestions on this?\n\nI think anything currently cooking in next is waiting for the next\nrelease to happen, and then progress to master IIUC eventually\nunless noted otherwise.\n"},{"id":"325589","messageId":"CALiud+nm9wu4rBY6zBXmenJj_0Mn7xeU_FAvSdn4fdH+q--Jag@mail.gmail.com","threadId":"46492","inReplyTo":"232547ab-3b87-debc-36a4-d2285ec10a06@ramsayjones.plus.com","subject":"Re: What's cooking in git.git (Jul 2017, #09; Mon, 31)","fromName":"Sahil Dua","fromEmail":"sahildua2305@gmail.com","sentAt":"2017-08-03T20:26:10Z","receivedAt":"2017-08-03T20:26:35Z","isPatch":false,"sender":{"key":"sahildua2305@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5206277?v=4"},"body":"Ah! I had skipped this reply from Ramsay earlier.\n\nOn Tue, Aug 1, 2017 at 1:36 AM, Ramsay Jones\n wrote:\n>\n>\n> On 31/07/17 23:30, Junio C Hamano wrote:\n> [snip]\n>>\n>> * sd/branch-copy (2017-06-18) 3 commits\n>> (merged to 'next' on 2017-07-18 at 5e3b9357ea)\n>> + branch: add a --copy (-c) option to go with --move (-m)\n>> + branch: add test for -m renaming multiple config sections\n>> + config: create a function to format section headers\n>>\n>> \"git branch\" learned \"-c/-C\" to create and switch to a new branch\n>> by copying an existing one.\n>>\n>> Will cook in 'next'.\n>>\n>> I personally do not think \"branch --copy master backup\" while on\n>> \"master\" that switches to \"backup\" is a good UI, and I *will* say\n>> \"I told you so\" when users complain after we merge this down to\n>> 'master'.\n>\n> I wouldn't normally comment on an issue like this because I am\n> not very good at specifying, designing and evaluating UIs (so\n> who in their right mind would listen to me). ;-)\n>\n> FWIW, I suspect that I would not like using this interface either\n> and would, therefore, not use it.\n\nDoes that mean you'd use it when \"branch --copy feature-branch\nnew-feature-branch\" in the case when you would want to start working\non a new branch (to modify or experiment with your current feature\nbranch) on top of a branch keeping intact all the configuration and\nlogs?\n\nI think it's really a matter of how this feature is seen from the\nend-user point of view. If we consider example \"branch --copy master\nbackup\" - obviously, switching to backup isn't the ideal situation.\nHowever, if we consider the example above, switching makes sense. None\nof them is going to be correct in 100% cases. :)\n\n> However, I guess the worst that\n> would happen, is that it would gain another 'wort' (--option) to\n> turn off the \"switches to backup\" branch. :-D\n>\n> I didn't want you to think that the lack of comments on this was\n> because everybody agreed that it was a good idea.\n>\n> ATB,\n> Ramsay Jones\n>\n>\n"},{"id":"325594","messageId":"xmqqd18cweak.fsf@gitster.mtv.corp.google.com","threadId":"46492","inReplyTo":"CALiud+nm9wu4rBY6zBXmenJj_0Mn7xeU_FAvSdn4fdH+q--Jag@mail.gmail.com","subject":"Re: What's cooking in git.git (Jul 2017, #09; Mon, 31)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-08-03T21:07:47Z","receivedAt":"2017-08-03T21:07:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sahil Dua writes:\n\n> Ah! I had skipped this reply from Ramsay earlier.\n>\n> On Tue, Aug 1, 2017 at 1:36 AM, Ramsay Jones\n> ...\n>>> I personally do not think \"branch --copy master backup\" while on\n>>> \"master\" that switches to \"backup\" is a good UI, and I *will* say\n>>> \"I told you so\" when users complain after we merge this down to\n>>> 'master'.\n>>\n>> I wouldn't normally comment on an issue like this because I am\n>> not very good at specifying, designing and evaluating UIs (so\n>> who in their right mind would listen to me). ;-)\n>>\n>> FWIW, I suspect that I would not like using this interface either\n>> and would, therefore, not use it.\n>\n> Does that mean you'd use it when \"branch --copy feature-branch\n> new-feature-branch\" in the case when you would want to start working\n> on a new branch (to modify or experiment with your current feature\n> branch) on top of a branch keeping intact all the configuration and\n> logs?\n\nI am not Ramsay, but your choice of branch names in your question,\ni.e. \"branch --copy feature new-feature\", is what we do not agree\nwith in the first place, especially when we are *on* the \"feature\"\nbranch.\n\nWe view \"copy A B\" as a way to make a back-up of A in B. I.e. We\nwant to keep working on A, but just in case we screw up badly, make\na backup copy of A in B, so that we can recover by a \"branch --move\nB A\" later if needed. So touching B is the last thing we want to do\nafter \"copy A B\" operation---hence we do not want to switch to B.\n\nThat is not to say that you are wrong to wish to create a new\nbranch, check it out and start working on it with a single command.\nWe already have such a command all Git users are accustomed to,\nwhich is \"git checkout -b new-feature-branch feature-branch\". \n\nThat existing command does not copy things other than the commit\nobject name from \"feature-branch\", and I do not think it should by\ndefault. But I do not think it is wrong to extend it with a new\noption (think of it as \"checkout --super-b\" ;-) to copy other things\nlike branch descriptions etc.\n\nSo from that point of view, your new feature conceptually fits a lot\nbetter to \"git checkout\", and does not belong to \"git branch\". That\nis why I do not think \"git branch --copy A B\" while you are on A\nshould check out B after creating the copy.\n"},{"id":"325595","messageId":"xmqq8tj0wdtz.fsf@gitster.mtv.corp.google.com","threadId":"46492","inReplyTo":"CALiud+nKTNsr_z528Wwv3ELLk+uKoJkYa8hctg-C1dtXrbkvKg@mail.gmail.com","subject":"Re: What's cooking in git.git (Jul 2017, #09; Mon, 31)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-08-03T21:17:44Z","receivedAt":"2017-08-03T21:17:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sahil Dua writes:\n\n>>\n>> * sd/branch-copy (2017-06-18) 3 commits\n>> (merged to 'next' on 2017-07-18 at 5e3b9357ea)\n>> + branch: add a --copy (-c) option to go with --move (-m)\n>> + branch: add test for -m renaming multiple config sections\n>> + config: create a function to format section headers\n>>\n>> \"git branch\" learned \"-c/-C\" to create and switch to a new branch\n>> by copying an existing one.\n>>\n>> Will cook in 'next'.\n>\n> Junio, are we still waiting for interaction with other patches to\n> settle down or simply cooking it further for any potential\n> feedback/suggestions on this?\n\nNo, \"waiting for other topics to settle\" was a long time ago.\nDuring the pre-release feature freeze, nothing will be merged to\n'master', unless it is a trivially correct bugfix or a regression\nfix. This one is neither.\n"},{"id":"325598","messageId":"50f77fb7-551c-e84b-9fef-5ed5194dc3a4@ramsayjones.plus.com","threadId":"46492","inReplyTo":"xmqqd18cweak.fsf@gitster.mtv.corp.google.com","subject":"Re: What's cooking in git.git (Jul 2017, #09; Mon, 31)","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsayjones.plus.com","sentAt":"2017-08-03T22:20:04Z","receivedAt":"2017-08-03T22:20:12Z","isPatch":false,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"\n\nOn 03/08/17 22:07, Junio C Hamano wrote:\n> Sahil Dua writes:\n> \n>> Ah! I had skipped this reply from Ramsay earlier.\n>>\n>> On Tue, Aug 1, 2017 at 1:36 AM, Ramsay Jones\n>> ...\n>>>> I personally do not think \"branch --copy master backup\" while on\n>>>> \"master\" that switches to \"backup\" is a good UI, and I *will* say\n>>>> \"I told you so\" when users complain after we merge this down to\n>>>> 'master'.\n>>>\n>>> I wouldn't normally comment on an issue like this because I am\n>>> not very good at specifying, designing and evaluating UIs (so\n>>> who in their right mind would listen to me). ;-)\n>>>\n>>> FWIW, I suspect that I would not like using this interface either\n>>> and would, therefore, not use it.\n>>\n>> Does that mean you'd use it when \"branch --copy feature-branch\n>> new-feature-branch\" in the case when you would want to start working\n>> on a new branch (to modify or experiment with your current feature\n>> branch) on top of a branch keeping intact all the configuration and\n>> logs?\n> \n> I am not Ramsay, but your choice of branch names in your question,\n> i.e. \"branch --copy feature new-feature\", is what we do not agree\n> with in the first place, especially when we are *on* the \"feature\"\n> branch.\n> \n> We view \"copy A B\" as a way to make a back-up of A in B. I.e. We\n> want to keep working on A, but just in case we screw up badly, make\n> a backup copy of A in B, so that we can recover by a \"branch --move\n> B A\" later if needed. So touching B is the last thing we want to do\n> after \"copy A B\" operation---hence we do not want to switch to B.\n\nI couldn't have said this better. ;-)\n\n> That is not to say that you are wrong to wish to create a new\n> branch, check it out and start working on it with a single command.\n> We already have such a command all Git users are accustomed to,\n> which is \"git checkout -b new-feature-branch feature-branch\". \n\nIndeed, I wouldn't think of doing anything else. (That may be\nbecause I've been using git too long, of course).\n\n> That existing command does not copy things other than the commit\n> object name from \"feature-branch\", and I do not think it should by\n> default. But I do not think it is wrong to extend it with a new\n> option (think of it as \"checkout --super-b\" ;-) to copy other things\n> like branch descriptions etc.\n\nHmm, I've never felt the lack of copying any attributes from\nthe origin branch. So, I'm not convinced a \"--super-b\" is needed\n(but if other people feel the need, then why not).\n\n> So from that point of view, your new feature conceptually fits a lot\n> better to \"git checkout\", and does not belong to \"git branch\". That\n> is why I do not think \"git branch --copy A B\" while you are on A\n> should check out B after creating the copy.\n\nI agree (but lukewarm on the --super-b idea). :-D\n\nATB,\nRamsay Jones\n\n\n"},{"id":"325642","messageId":"87shh57nzs.fsf@gmail.com","threadId":"46492","inReplyTo":"xmqqd18cweak.fsf@gitster.mtv.corp.google.com","subject":"Re: What's cooking in git.git (Jul 2017, #09; Mon, 31)","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2017-08-05T20:34:15Z","receivedAt":"2017-08-05T20:34:25Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Thu, Aug 03 2017, Junio C. Hamano jotted:\n\n> Sahil Dua writes:\n>\n>> Ah! I had skipped this reply from Ramsay earlier.\n>>\n>> On Tue, Aug 1, 2017 at 1:36 AM, Ramsay Jones\n>> ...\n>>>> I personally do not think \"branch --copy master backup\" while on\n>>>> \"master\" that switches to \"backup\" is a good UI, and I *will* say\n>>>> \"I told you so\" when users complain after we merge this down to\n>>>> 'master'.\n>>>\n>>> I wouldn't normally comment on an issue like this because I am\n>>> not very good at specifying, designing and evaluating UIs (so\n>>> who in their right mind would listen to me). ;-)\n>>>\n>>> FWIW, I suspect that I would not like using this interface either\n>>> and would, therefore, not use it.\n>>\n>> Does that mean you'd use it when \"branch --copy feature-branch\n>> new-feature-branch\" in the case when you would want to start working\n>> on a new branch (to modify or experiment with your current feature\n>> branch) on top of a branch keeping intact all the configuration and\n>> logs?\n>\n> I am not Ramsay, but your choice of branch names in your question,\n> i.e. \"branch --copy feature new-feature\", is what we do not agree\n> with in the first place, especially when we are *on* the \"feature\"\n> branch.\n>\n> We view \"copy A B\" as a way to make a back-up of A in B. I.e. We\n> want to keep working on A, but just in case we screw up badly, make\n> a backup copy of A in B, so that we can recover by a \"branch --move\n> B A\" later if needed. So touching B is the last thing we want to do\n> after \"copy A B\" operation---hence we do not want to switch to B.\n>\n> That is not to say that you are wrong to wish to create a new\n> branch, check it out and start working on it with a single command.\n> We already have such a command all Git users are accustomed to,\n> which is \"git checkout -b new-feature-branch feature-branch\".\n>\n> That existing command does not copy things other than the commit\n> object name from \"feature-branch\", and I do not think it should by\n> default. But I do not think it is wrong to extend it with a new\n> option (think of it as \"checkout --super-b\" ;-) to copy other things\n> like branch descriptions etc.\n>\n> So from that point of view, your new feature conceptually fits a lot\n> better to \"git checkout\", and does not belong to \"git branch\". That\n> is why I do not think \"git branch --copy A B\" while you are on A\n> should check out B after creating the copy.\n\nWe've talked how this UX should look before on-list. Rather than\nre-hashing the arguments I had before I thought it was useful to present\nit as a table. Here's how the patch looks now:\n\n |----------------------------+--------------+-------+---------+-----------------+-------------|\n | cmd | creates new? | moves | copies? | ...with config? | checks out? |\n |----------------------------+--------------+-------+---------+-----------------+-------------|\n | branch | Y | N | N | N | N |\n | checkout | Y | N | N | N | Y |\n | checkout -b | Y | N | Y | N | Y |\n | branch -m | Y | Y | N | Y | Y |\n | NEW: branch -c | Y | N | Y | Y | Y |\n |----------------------------+--------------+-------+---------+-----------------+-------------|\n\nIn previous discussion my understanding was that you preferred the\nfollowing (as an ad-hoc word-diff)\n\n |----------------------------+--------------+-------+---------+-----------------+-------------|\n | cmd | creates new? | moves | copies? | ...with config? | checks out? |\n [... stuff above this point is the same ...]\n | NEW: branch -c | Y | N | Y | Y | {-Y, +N} |\n |----------------------------+--------------+-------+---------+-----------------+-------------|\n\nI.e. have \"branch -c \" but just make it not checkout the new\nthing. What you're describing above sounds to me like:\n\n |-------------------------------------------+--------------+-------+---------+-----------------+-------------|\n | cmd | creates new? | moves | copies? | ...with config? | checks out? |\n [... stuff above this point is the same ...]\n | branch -m | Y | Y | N | Y | Y |\n [... so is branch -m but included for context ...]\n | NEW: checkout --super-b -b | Y | N | Y | Y | Y |\n |-------------------------------------------+--------------+-------+---------+-----------------+-------------|\n\nAs (IIRC) noted in some earlier mail of mine: I don't disagree with what\nyou're suggesting, and this horror of a checkout/branch UX is not\nsomething anyone would have made from scratch with the benefit of\nhindsight.\n\nHowever we have 2x commands that checkout branches now and do some\ncombination of creating, moving and copying them (with & without\nconfig).\n\nI think given that we have \"branch -m \" already introducing a\n\"branch -c \" that does exactly the same thing except \"leaves old\nname behind\" was the simplest thing both in terms of explaining it to\nusers and to implement, since all the code except removing the old\nconfig section will be shared with \"branch -m\".\n\nBut having this \"checkout --super-b -b \" would make the UX\neven uglier, since now we have a command that does 99% of what \"branch\n-m \" does, but is invoked differently.\n\nI think this end state would make more sense:\n\n |----------------------------------------+--------------+-------+---------+-----------------+-------------|\n | cmd | creates new? | moves | copies? | ...with config? | checks out? |\n |----------------------------------------+--------------+-------+---------+-----------------+-------------|\n | branch | Y | N | N | N | N |\n | checkout | Y | N | N | N | Y |\n | checkout -b | Y | N | Y | N | Y |\n | DEPRECATED (WARNS): branch -m | Y | Y | N | Y | Y |\n | NEW: checkout --move -b | Y | Y | N | Y | Y |\n | NEW: checkout --copy -b | Y | N | Y | Y | Y |\n |----------------------------------------+--------------+-------+---------+-----------------+-------------|\n\nI.e. let's just move this functionality to \"git checkout\" and deprecate\n\"branch -m\" (which we could alias to begin with to checkout --move\".\n\nI think *that* would make sense, but not the half-assed solution of\nmoving a new checkout command to git-checkout while we have an analogous\ncheckout command in git-branch without being deprecated.\n"},{"id":"325645","messageId":"xmqqpoc9sksg.fsf@gitster.mtv.corp.google.com","threadId":"46492","inReplyTo":"87shh57nzs.fsf@gmail.com","subject":"Re: What's cooking in git.git (Jul 2017, #09; Mon, 31)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-08-05T22:37:51Z","receivedAt":"2017-08-05T22:38:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason writes:\n\n> We've talked how this UX should look before on-list. Rather than\n> re-hashing the arguments I had before I thought it was useful to present\n> it as a table. Here's how the patch looks now:\n>\n> |----------------------------+--------------+-------+---------+-----------------+-------------|\n> | cmd | creates new? | moves | copies? | ...with config? | checks out? |\n> |----------------------------+--------------+-------+---------+-----------------+-------------|\n> | branch | Y | N | N | N | N |\n> | checkout | Y | N | N | N | Y |\n> | checkout -b | Y | N | Y | N | Y |\n> | branch -m | Y | Y | N | Y | Y |\n> | NEW: branch -c | Y | N | Y | Y | Y |\n> |----------------------------+--------------+-------+---------+-----------------+-------------|\n\nI actually consider \"branch\" to *never* invoking a checkout. Even\nwhen \"git branch -m A B\" happens to be done when your checked out\nbranch is A and you end up being on B. That is not a \"checkout\".\n\nReally from the end-user's point of view that is not a checkout.\nThe user renamed the branch A and the same conceptual entity, which\nis a branch, is now called B. If that branch was what was checked\nout (IOW, if that branch was what would be grown by one commit if\nthe user did \"git commit\"), then now that branch's name is B. It is\nnatural if you ask \"symbolic-ref HEAD\" what branch is checked out\nafter renaming A to B (and A happened to be what was checked out),\nthe answer chould be B.\n\nIt's like the city you live in changed the name of the street your\nhouse is on. You do not call movers, you do not do anything, but\nyour address changes.\n\n> I.e. have \"branch -c \" but just make it not checkout the new\n> thing. What you're describing above sounds to me like:\n>\n> |-------------------------------------------+--------------+-------+---------+-----------------+-------------|\n> | cmd | creates new? | moves | copies? | ...with config? | checks out? |\n> [... stuff above this point is the same ...]\n> | branch -m | Y | Y | N | Y | Y |\n> [... so is branch -m but included for context ...]\n> | NEW: checkout --super-b -b | Y | N | Y | Y | Y |\n> |-------------------------------------------+--------------+-------+---------+-----------------+-------------|\n\nYou are talking backwards. I do not want \"branch -c A B\", even when\nA happens to be what is checked out, to check out branch B. You and\nSahil were who wanted to check out branch B while doing so, and I\njust tried to guess why you two wanted to have such a behaviour that\ndid not make much sense to me. And my guess was \"perhaps they want\na way to create a new branch starting from another branch, and check\nit out, and do so in a single end-user operation\". \n\nI am not particulary interested in such an operation; in my guess,\nyou two are. And the \"super-b\" thing was a suggestion to you two:\nIf you so desperately want such an operation, then don't make\n\"branch --copy A B\" that operation. Such an operation better fits\nin \"checkout\", not \"branch\".\n\nIf you are not interested in such an operation, then that is fine.\nDo not add the \"super-b\" mode to \"checkout\".\n\nBut I won't defend a \"branch --copy A B\" that checks out B when\nusers and other people like Ramsay think that such a behaviour is\nillogical, because I do think it is, too.\n\n\n"},{"id":"325659","messageId":"873794zbls.fsf@gmail.com","threadId":"46492","inReplyTo":"xmqqpoc9sksg.fsf@gitster.mtv.corp.google.com","subject":"Re: What's cooking in git.git (Jul 2017, #09; Mon, 31)","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2017-08-06T20:26:39Z","receivedAt":"2017-08-06T20:26:49Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Sat, Aug 05 2017, Junio C. Hamano jotted:\n\n> Ævar Arnfjörð Bjarmason writes:\n>\n>> We've talked how this UX should look before on-list. Rather than\n>> re-hashing the arguments I had before I thought it was useful to present\n>> it as a table. Here's how the patch looks now:\n>>\n>> |----------------------------+--------------+-------+---------+-----------------+-------------|\n>> | cmd | creates new? | moves | copies? | ...with config? | checks out? |\n>> |----------------------------+--------------+-------+---------+-----------------+-------------|\n>> | branch | Y | N | N | N | N |\n>> | checkout | Y | N | N | N | Y |\n>> | checkout -b | Y | N | Y | N | Y |\n>> | branch -m | Y | Y | N | Y | Y |\n>> | NEW: branch -c | Y | N | Y | Y | Y |\n>> |----------------------------+--------------+-------+---------+-----------------+-------------|\n>\n> I actually consider \"branch\" to *never* invoking a checkout. Even\n> when \"git branch -m A B\" happens to be done when your checked out\n> branch is A and you end up being on B. That is not a \"checkout\".\n\nI think we just have a different mental model of what \"checkout\"\nmeans. In my mind any operation that updates the HEAD to point to a new\nbranch is a checkout of that branch.\n\nIn the interest of explaining what I mean with the above and not proving\nyou wrong or whatever, consider a basic implementation of git before\npack-refs or whatever.\n\nYou could then copy a branch name like:\n\n $ cp .git/refs/heads/{master,master-copy}\n\nGet your currently checked out branch with:\n\n $ cat .git/HEAD\n ref: refs/heads/master\n\nAnd you could then implement \"git checkout\" like:\n\n $ echo \"ref: refs/heads/master-copy\" >.git/HEAD\n\nThis still works today. Now if I make a commit it goes on the\n.git/refs/heads/master-copy branch.\n\nNow let's say I wanted to rename the 'master' branch. This would rename\nit:\n\n $ mv .git/refs/heads/{master,trunk}\n\nBut it wouldn't check it out, my HEAD would still point to master:\n\n $ git log\n fatal: your current branch 'master' does not have any commits yet\n $ git log --oneline -1 trunk\n 8b18718 (trunk) moo\n\nTo check it out I need:\n\n $ echo \"ref: refs/heads/trunk\" >.git/HEAD\n\nWhich yields:\n\n $ git log --oneline -1 HEAD\n 8b18718 (HEAD -> trunk) moo\n\nThe mv sans the \"echo\" is what we'd get if we did:\n\n diff --git a/builtin/branch.c b/builtin/branch.c\n index 8a0595e115..62ed1a8e20 100644\n --- a/builtin/branch.c\n +++ b/builtin/branch.c\n @@ -493,9 +493,6 @@ static void rename_branch(const char *oldname, const char *newname, int force)\n if (recovery)\n warning(_(\"Renamed a misnamed branch '%s' away\"), oldref.buf + 11);\n\n - if (replace_each_worktree_head_symref(oldref.buf, newref.buf, logmsg.buf))\n - die(_(\"Branch renamed to %s, but HEAD is not updated!\"), newname);\n -\n strbuf_release(&logmsg);\n\n strbuf_addf(&oldsection, \"branch.%s\", oldref.buf + 11);\n\nI.e. the last step of \"git branch -m\" is checking out the branch by\nupdating the HEAD. Now let's compile git like that and rename \"master\"\nto \"trunk\":\n\n $ git symbolic-ref HEAD\n refs/heads/master\n $ ./git-branch -m trunk\n $ git symbolic-ref HEAD\n refs/heads/master\n $ git show\n fatal: your current branch 'master' does not have any commits yet\n\nNow let's do the equivalent of that removed\nreplace_each_worktree_head_symref():\n\n $ git checkout trunk\n Switched to branch 'trunk'\n\nAnd voila:\n\n $ git symbolic-ref HEAD\n refs/heads/trunk\n\nThis is why I'm saying that \"git branch -m\" involves a checkout. Because\nit is literally exactly the case that it could be replaced by a\nshellscript whose last step is a \"git checkout\" of the new branch.\n\nAnyway, none of that changes what we /should/ be doing on the fact that\n\"git branch -m\" not updating the HEAD would be rather useless. I just\nwanted to explain what I was talking about and why I was talking about\n\"checkout\" in that context.\n\n> Really from the end-user's point of view that is not a checkout.\n> The user renamed the branch A and the same conceptual entity, which\n> is a branch, is now called B. If that branch was what was checked\n> out (IOW, if that branch was what would be grown by one commit if\n> the user did \"git commit\"), then now that branch's name is B. It is\n> natural if you ask \"symbolic-ref HEAD\" what branch is checked out\n> after renaming A to B (and A happened to be what was checked out),\n> the answer chould be B.\n>\n> It's like the city you live in changed the name of the street your\n> house is on. You do not call movers, you do not do anything, but\n> your address changes.\n\nYeah I see what you mean, although this analogy rapidly breaks down when\nyou poke at it as shown above. My house (a sha1) can be on any number of\nstreets and new ones can be added/removed all the time without changing\nwhere my house is at.\n\n>> I.e. have \"branch -c \" but just make it not checkout the new\n>> thing. What you're describing above sounds to me like:\n>>\n>> |-------------------------------------------+--------------+-------+---------+-----------------+-------------|\n>> | cmd | creates new? | moves | copies? | ...with config? | checks out? |\n>> [... stuff above this point is the same ...]\n>> | branch -m | Y | Y | N | Y | Y |\n>> [... so is branch -m but included for context ...]\n>> | NEW: checkout --super-b -b | Y | N | Y | Y | Y |\n>> |-------------------------------------------+--------------+-------+---------+-----------------+-------------|\n>\n> You are talking backwards. I do not want \"branch -c A B\", even when\n> A happens to be what is checked out, to check out branch B. You and\n> Sahil were who wanted to check out branch B while doing so, and I\n> just tried to guess why you two wanted to have such a behaviour that\n> did not make much sense to me. And my guess was \"perhaps they want\n> a way to create a new branch starting from another branch, and check\n> it out, and do so in a single end-user operation\".\n\nThe use-case is the following. When I hack on e.g. git.git I'm on\n\"master\" with configured upstream info:\n\n $ git log @{u}..\n\nBecause if I don't care about 'master' another shorter way to say:\n\n $ git checkout -b topic -t origin/master\n\nIs:\n\n $ git branch -m topic\n\nThat's how I start hacking on \"topic\", now let's say I've submitted that\nand want to start on topic-2 after getting feedback:\n\n # While still on topic\n $ git branch -c topic-2\n\nSo it's just a way to get something exactly like -m except the \"move &&\ncheckout\" logic is changed to \"copy && checkout\".\n\n> I am not particulary interested in such an operation; in my guess,\n> you two are. And the \"super-b\" thing was a suggestion to you two:\n> If you so desperately want such an operation, then don't make\n> \"branch --copy A B\" that operation. Such an operation better fits\n> in \"checkout\", not \"branch\".\n\nThat's arguably another sensible way to do a /subset/ of what 'git\nbranch -c' does (or something in addition to this patch). But there's\nanother use-case it won't cover, i.e. the two-arg branch -m/-c\nmanipulating a branch that HEAD doesn't point to:\n\n $ git checkout master\n $ git branch -m topic avar/topic\n\nYou can now do that with -c to s/move/copy/, but couldn't do this with\ncheckout unless you wastefully and needlessly updated the working tree.\n\n> If you are not interested in such an operation, then that is fine.\n> Do not add the \"super-b\" mode to \"checkout\".\n\nYeah it's not something I'm interested in or have a use-case for,\nalthough I think in the same way we have -t for checkout it might be\nsensible to have e.g.:\n\n $ git checkout -b topic-2 -c topic -t origin/master\n\nWhere the new -c or --config-from would mean \"...and get the config from\n'topic'\". Such a name would probably be less confusing than\n--super-b[branch?] which to be implies some ongoing hierarchical\nrelationship.\n\n> But I won't defend a \"branch --copy A B\" that checks out B when\n> users and other people like Ramsay think that such a behaviour is\n> illogical, because I do think it is, too.\n\nI just started this from the POV of using branch -m and wanting\nsomething like that which didn't remove the old thing when it was done\nas its last step, which seemed easy to implement & explain.\n\nAs noted above I think it probably makes sense to also have something\nlike [--config-from|-c] for checkout, which would have a related but not\nexactly the same use-case.\n"},{"id":"325761","messageId":"e5564e40-702f-390b-69e2-2ed6e45610c8@gmail.com","threadId":"46492","inReplyTo":"873794zbls.fsf@gmail.com","subject":"Re: What's cooking in git.git (Jul 2017, #09; Mon, 31)","fromName":"Igor Djordjevic","fromEmail":"igor.d.djordjevic@gmail.com","sentAt":"2017-08-07T21:25:54Z","receivedAt":"2017-08-07T21:26:12Z","isPatch":false,"sender":{"key":"igor.d.djordjevic@gmail.com","avatar":null},"body":"On 06/08/2017 22:26, Ævar Arnfjörð Bjarmason wrote:\n> On Sat, Aug 05 2017, Junio C. Hamano jotted:\n>> I actually consider \"branch\" to *never* invoking a checkout. Even\n>> when \"git branch -m A B\" happens to be done when your checked out\n>> branch is A and you end up being on B. That is not a \"checkout\".\n> \n> I think we just have a different mental model of what \"checkout\"\n> means. In my mind any operation that updates the HEAD to point to a new\n> branch is a checkout of that branch.\n\nIf I may, from a side-viewer`s point of view, it seems you`re \nthinking in low-level implementation details, where what Junio \ndescribes seems more as a high-level, conceptual/end-user`s point of \nview.\n\nNeeding to update HEAD reference once we \"rename\" a branch, too, what \nyou consider a \"checkout\", seems to be required only because branch \nname _is_ the branch reference in Git, so we need to update HEAD to \npoint to a new/renamed branch reference -- but it`s still the same \nbranch, conceptually.\n\nDocumentation for \"git-checkout\" states that it is used to \"*Switch \nbranches*...[snip]\", and that is not what happens here. \nImplementation-wise it does because we can`t do it differently at the \nmoment, but in user`s eyes it`s still the same branch, so no switch \nis made as far as the user is concerned.\n\nIn a different implementation, where branches would have permanent \nreferences other than their names, no HEAD update would be needed as \nthe reference would still be the same, no matter the name change, \nmaking the `git branch -m` situation clear even from your standpoint, \nI`d say.\n\n>> Really from the end-user's point of view that is not a checkout.\n>> The user renamed the branch A and the same conceptual entity, which\n>> is a branch, is now called B. If that branch was what was checked\n>> out (IOW, if that branch was what would be grown by one commit if\n>> the user did \"git commit\"), then now that branch's name is B. It is\n>> natural if you ask \"symbolic-ref HEAD\" what branch is checked out\n>> after renaming A to B (and A happened to be what was checked out),\n>> the answer chould be B.\n>>\n>> It's like the city you live in changed the name of the street your\n>> house is on. You do not call movers, you do not do anything, but\n>> your address changes.\n> \n> Yeah I see what you mean, although this analogy rapidly breaks down when\n> you poke at it as shown above. My house (a sha1) can be on any number of\n> streets and new ones can be added/removed all the time without changing\n> where my house is at.\n\nI may be missing something, but I find the house/address analogy a \ngood one, actually, as I understood that \"house\" resembles a branch \nreference HEAD is pointing to, not a sha1.\n\nEven further, and that might be the point of confusion, \"house\" seems \nto be more like a \"permanent branch reference\" I mentioned above, \nwhere your address can change (branch being renamed), but you would \nstill be in the same house (HEAD would still point to the same \npermanent branch reference).\n\nIf you move to another house, only then would HEAD change to point to \nanother (permanent) branch reference (a different house), and that \nwould be a checkout.\n\nYes, it`s not really how it works from the inside, but I think that`s \nirrelevant for the end-user experience :)\n\n> So it's just a way to get something exactly like -m except the \"move &&\n> checkout\" logic is changed to \"copy && checkout\".\nAgain, it seems the \"checkout\" part of \"move && checkout\" you`re \ntalking about is a user-wise unnecessary implementation detail. For \nthe user, it`s just a simple \"move\", staying on the same, but renamed \nbranch, thus no branch switching occurred (no \"checkout\", as per \ndocumentation).\n\nRegards,\nBuga\n"},{"id":"325770","messageId":"db848b3e-e4cc-ddf4-9e4c-7b47b2f5d7a7@gmail.com","threadId":"46492","inReplyTo":"e5564e40-702f-390b-69e2-2ed6e45610c8@gmail.com","subject":"Re: What's cooking in git.git (Jul 2017, #09; Mon, 31)","fromName":"Igor Djordjevic","fromEmail":"igor.d.djordjevic@gmail.com","sentAt":"2017-08-07T22:20:24Z","receivedAt":"2017-08-07T22:20:41Z","isPatch":false,"sender":{"key":"igor.d.djordjevic@gmail.com","avatar":null},"body":"On 07/08/2017 23:25, Igor Djordjevic wrote:\n> On 06/08/2017 22:26, Ævar Arnfjörð Bjarmason wrote:\n>> On Sat, Aug 05 2017, Junio C. Hamano jotted:\n>>> I actually consider \"branch\" to *never* invoking a checkout. Even\n>>> when \"git branch -m A B\" happens to be done when your checked out\n>>> branch is A and you end up being on B. That is not a \"checkout\".\n>>\n>> I think we just have a different mental model of what \"checkout\"\n>> means. In my mind any operation that updates the HEAD to point to a new\n>> branch is a checkout of that branch.\n> \n> If I may, from a side-viewer`s point of view, it seems you`re \n> thinking in low-level implementation details, where what Junio \n> describes seems more as a high-level, conceptual/end-user`s point of \n> view.\n> \n> Needing to update HEAD reference once we \"rename\" a branch, too, what \n> you consider a \"checkout\", seems to be required only because branch \n> name _is_ the branch reference in Git, so we need to update HEAD to \n> point to a new/renamed branch reference -- but it`s still the same \n> branch, conceptually.\n> \n> Documentation for \"git-checkout\" states that it is used to \"*Switch \n> branches*...[snip]\", and that is not what happens here. \n> Implementation-wise it does because we can`t do it differently at the \n> moment, but in user`s eyes it`s still the same branch, so no switch \n> is made as far as the user is concerned.\n> \n> In a different implementation, where branches would have permanent \n> references other than their names, no HEAD update would be needed as \n> the reference would still be the same, no matter the name change, \n> making the `git branch -m` situation clear even from your standpoint, \n> I`d say.\n> \n>>> Really from the end-user's point of view that is not a checkout.\n>>> The user renamed the branch A and the same conceptual entity, which\n>>> is a branch, is now called B. If that branch was what was checked\n>>> out (IOW, if that branch was what would be grown by one commit if\n>>> the user did \"git commit\"), then now that branch's name is B. It is\n>>> natural if you ask \"symbolic-ref HEAD\" what branch is checked out\n>>> after renaming A to B (and A happened to be what was checked out),\n>>> the answer chould be B.\n>>>\n>>> It's like the city you live in changed the name of the street your\n>>> house is on. You do not call movers, you do not do anything, but\n>>> your address changes.\n>>\n>> Yeah I see what you mean, although this analogy rapidly breaks down when\n>> you poke at it as shown above. My house (a sha1) can be on any number of\n>> streets and new ones can be added/removed all the time without changing\n>> where my house is at.\n> \n> I may be missing something, but I find the house/address analogy a \n> good one, actually, as I understood that \"house\" resembles a branch \n> reference HEAD is pointing to, not a sha1.\n> \n> Even further, and that might be the point of confusion, \"house\" seems \n> to be more like a \"permanent branch reference\" I mentioned above, \n> where your address can change (branch being renamed), but you would \n> still be in the same house (HEAD would still point to the same \n> permanent branch reference).\n> \n> If you move to another house, only then would HEAD change to point to \n> another (permanent) branch reference (a different house), and that \n> would be a checkout.\n> \n> Yes, it`s not really how it works from the inside, but I think that`s \n> irrelevant for the end-user experience :)\n> \n>> So it's just a way to get something exactly like -m except the \"move &&\n>> checkout\" logic is changed to \"copy && checkout\".\n>\n> Again, it seems the \"checkout\" part of \"move && checkout\" you`re \n> talking about is a user-wise unnecessary implementation detail. For \n> the user, it`s just a simple \"move\", staying on the same, but renamed \n> branch, thus no branch switching occurred (no \"checkout\", as per \n> documentation).\n\nAll this said, having you mentioning the two argument version:\n\n> $ git checkout master\n> $ git branch -m topic avar/topic\n\n... exactly proves the point that \"git branch -m\" is not expected to \ninvolve a checkout, even from implementation perspective. It`s just a \nconsequence of needing to update the (now obsolete) reference HEAD \npoints to (only) when the branch we`re renaming (moving) is the one \nthat is currently checked-out.\n\n> Yeah it's not something I'm interested in or have a use-case for,\n> although I think in the same way we have -t for checkout it might be\n> sensible to have e.g.:\n> \n> $ git checkout -b topic-2 -c topic -t origin/master\n> \n> Where the new -c or --config-from would mean \"...and get the config from\n> 'topic'\". Such a name would probably be less confusing than\n> --super-b[branch?] which to be implies some ongoing hierarchical\n> relationship.\n\nThis, on the other hand, sounds sensible, staying true to the \nexisting logic. In the same manner you can do either:\n\n $ git branch topic -t origin/master\n $ git checkout topic\n\n... or shorter equivalent:\n\n $ git checkout -b topic -t origin/master\n\n..., you should be able to do:\n\n $ git branch -c topic topic-2\n $ git checkout topic-2\n\n..., or equivalent:\n\n $ git checkout -b topic-2 -c topic\n\n..., where \"-c\" would follow the same (or similar) logic as \"-t\" does \nnow, as you already pointed out :)\n\np.s. That said, is `git checkout -b topic-2 --move topic` being \nmissed now...? :P That one would/could/should actually be expected to \nmove (rename) the branch *and* check it out, no matter if HEAD \ncurrently points to it or not.\n\nRegards,\nBuga\n"},{"id":"325805","messageId":"874ltigq1x.fsf@gmail.com","threadId":"46492","inReplyTo":"db848b3e-e4cc-ddf4-9e4c-7b47b2f5d7a7@gmail.com","subject":"Re: What's cooking in git.git (Jul 2017, #09; Mon, 31)","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2017-08-08T13:14:02Z","receivedAt":"2017-08-08T13:14:16Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Mon, Aug 07 2017, Igor Djordjevic jotted:\n\n> On 07/08/2017 23:25, Igor Djordjevic wrote:\n>> On 06/08/2017 22:26, Ævar Arnfjörð Bjarmason wrote:\n>>> On Sat, Aug 05 2017, Junio C. Hamano jotted:\n>>>> I actually consider \"branch\" to *never* invoking a checkout. Even\n>>>> when \"git branch -m A B\" happens to be done when your checked out\n>>>> branch is A and you end up being on B. That is not a \"checkout\".\n>>>\n>>> I think we just have a different mental model of what \"checkout\"\n>>> means. In my mind any operation that updates the HEAD to point to a new\n>>> branch is a checkout of that branch.\n>>\n>> If I may, from a side-viewer`s point of view, it seems you`re\n>> thinking in low-level implementation details, where what Junio\n>> describes seems more as a high-level, conceptual/end-user`s point of\n>> view.\n\nYeah, I think that's a fair summary. Also I didn't mean to de-rail this\nwhole thread on what \"checkout\" really means, just explain what I meant\nwith previous comments, since there seemed to be confusion about that.\n\n>> Needing to update HEAD reference once we \"rename\" a branch, too, what\n>> you consider a \"checkout\", seems to be required only because branch\n>> name _is_ the branch reference in Git, so we need to update HEAD to\n>> point to a new/renamed branch reference -- but it`s still the same\n>> branch, conceptually.\n\nIt's not *required* we could do one of three things:\n\n 1) Do what we do now, i.e. rename the branch/reflog & check out the new\n name.\n\n 2) Rename the branch/reflog and checkout HEAD^0, i.e. say \"the branch\n is now elsewhere, but we haven't moved your commit\".\n\n 3) Just not run replace_each_worktree_head_symref() which would end up\n on a branch with no commits, i.e. an orphan branch.\n\nNow, I think 2 & 3 are pretty nonsensical and wouldn't ever propose we\nshould do that, but it's illustrative that #1 is not some required\ninevitability in terms of explaining what's happening with the new name\nbeing checked out (i.e. HEAD being updated).\n\n>> Documentation for \"git-checkout\" states that it is used to \"*Switch\n>> branches*...[snip]\", and that is not what happens here.\n\nThat's just the summary at the top but not the full story of what\ngit-checkout does. E.g. you can checkout a bare SHA1 which is not\nswitching branches, or a tag or whatever.\n\n>> Implementation-wise it does because we can`t do it differently at the\n>> moment, but in user`s eyes it`s still the same branch, so no switch\n>> is made as far as the user is concerned.\n\nKind of, it's also worthwhile to think about that in some sense no\nswitch would be performed as far as the user is concerned by taking\noption #2, i.e. we'd be in the same working tree / you could still make\ncommits.\n\nYou just couldn't make new commits on your \"master\" which is now called\n\"topic\" and get new commits on \"topic\". I think it makes sense to do\nthat, but again, it's illustrative that it's not inevitable for\ndiscussing the implementation.\n\n>> In a different implementation, where branches would have permanent\n>> references other than their names, no HEAD update would be needed as\n>> the reference would still be the same, no matter the name change,\n>> making the `git branch -m` situation clear even from your standpoint,\n>> I`d say.\n>>\n>>>> Really from the end-user's point of view that is not a checkout.\n>>>> The user renamed the branch A and the same conceptual entity, which\n>>>> is a branch, is now called B. If that branch was what was checked\n>>>> out (IOW, if that branch was what would be grown by one commit if\n>>>> the user did \"git commit\"), then now that branch's name is B. It is\n>>>> natural if you ask \"symbolic-ref HEAD\" what branch is checked out\n>>>> after renaming A to B (and A happened to be what was checked out),\n>>>> the answer chould be B.\n>>>>\n>>>> It's like the city you live in changed the name of the street your\n>>>> house is on. You do not call movers, you do not do anything, but\n>>>> your address changes.\n>>>\n>>> Yeah I see what you mean, although this analogy rapidly breaks down when\n>>> you poke at it as shown above. My house (a sha1) can be on any number of\n>>> streets and new ones can be added/removed all the time without changing\n>>> where my house is at.\n>>\n>> I may be missing something, but I find the house/address analogy a\n>> good one, actually, as I understood that \"house\" resembles a branch\n>> reference HEAD is pointing to, not a sha1.\n>>\n>> Even further, and that might be the point of confusion, \"house\" seems\n>> to be more like a \"permanent branch reference\" I mentioned above,\n>> where your address can change (branch being renamed), but you would\n>> still be in the same house (HEAD would still point to the same\n>> permanent branch reference).\n>>\n>> If you move to another house, only then would HEAD change to point to\n>> another (permanent) branch reference (a different house), and that\n>> would be a checkout.\n\nI've yet to see a good real-world analogy of \"DAG with labels\", which is\nall git really is, that doesn't break down at some point. Trees are\nprobably the best comparison, but even that breaks down in the face of\nbranch merges or even merges of entirely unrelated trees.\n\nSo it's probably pointless to discuss this tangent any further, I don't\nthink it helps with deciding what to do about this new -c construct.\n\n>> Yes, it`s not really how it works from the inside, but I think that`s\n>> irrelevant for the end-user experience :)\n>>\n>>> So it's just a way to get something exactly like -m except the \"move &&\n>>> checkout\" logic is changed to \"copy && checkout\".\n>>\n>> Again, it seems the \"checkout\" part of \"move && checkout\" you`re\n>> talking about is a user-wise unnecessary implementation detail. For\n>> the user, it`s just a simple \"move\", staying on the same, but renamed\n>> branch, thus no branch switching occurred (no \"checkout\", as per\n>> documentation).\n\nYes I agree that this has little to no impact on what's happening for\nthe user, I've merely been discussing \"checkout\" in the terms of what's\nhappening under the hood here.\n\n> All this said, having you mentioning the two argument version:\n>\n>> $ git checkout master\n>> $ git branch -m topic avar/topic\n>\n> ... exactly proves the point that \"git branch -m\" is not expected to\n> involve a checkout, even from implementation perspective. It`s just a\n> consequence of needing to update the (now obsolete) reference HEAD\n> points to (only) when the branch we`re renaming (moving) is the one\n> that is currently checked-out.\n\nHrm, I think you're confused about what this example does. For the sake\nof avoiding confusion let's stop talking about checkout and just talk\nabout updating the HEAD.\n\nThe point of that example is to show that the HEAD is only updated by\ngit branch [-m|-c] if the branch being moved/copied is the branch you're\ncurrently on.\n\nHere the user just checked out master and then moved an unrelated topic\nto avar/topic, that just manipulates the ref store & config, and won't\ntouch the HEAD.\n\nThe reason I'm mentioning that example (and talking about a \"subset\") is\nthat amending git-checkout to do some of what this new \"git-branch -c\"\noption would do would only cover a subset of what it does, since both -m\nand -c are two-mode options in the sense that some of the time they\nmanipulate the refstore and the HEAD, and some of the time only the\nrefstore.\n\n>> Yeah it's not something I'm interested in or have a use-case for,\n>> although I think in the same way we have -t for checkout it might be\n>> sensible to have e.g.:\n>>\n>> $ git checkout -b topic-2 -c topic -t origin/master\n>>\n>> Where the new -c or --config-from would mean \"...and get the config from\n>> 'topic'\". Such a name would probably be less confusing than\n>> --super-b[branch?] which to be implies some ongoing hierarchical\n>> relationship.\n>\n> This, on the other hand, sounds sensible, staying true to the\n> existing logic. In the same manner you can do either:\n\nTo continue the explanation above, yeah it's sensible, but I'm pointing\nout that it's *also* sensible, i.e. whatever mode git-checkout has for\n\"let's create a branch with the same start point & config as [some other\nbranch]\" it's always going to be complimentary but not a replacement for\ngit branch [-m|-c], since [-m|-c] has a mode for doing that without\ndoing any checkout whatsoever, just manipulating the refstore.\n\n> $ git branch topic -t origin/master\n> $ git checkout topic\n>\n> ... or shorter equivalent:\n>\n> $ git checkout -b topic -t origin/master\n>\n> ..., you should be able to do:\n>\n> $ git branch -c topic topic-2\n> $ git checkout topic-2\n>\n> ..., or equivalent:\n>\n> $ git checkout -b topic-2 -c topic\n>\n> ..., where \"-c\" would follow the same (or similar) logic as \"-t\" does\n> now, as you already pointed out :)\n>\n> p.s. That said, is `git checkout -b topic-2 --move topic` being\n> missed now...? :P That one would/could/should actually be expected to\n> move (rename) the branch *and* check it out, no matter if HEAD\n> currently points to it or not.\n>\n> Regards,\n> Buga\n"},{"id":"325828","messageId":"2cd06f54-df42-087c-6a11-678f8ce9dd0d@gmail.com","threadId":"46492","inReplyTo":"874ltigq1x.fsf@gmail.com","subject":"Re: What's cooking in git.git (Jul 2017, #09; Mon, 31)","fromName":"Igor Djordjevic","fromEmail":"igor.d.djordjevic@gmail.com","sentAt":"2017-08-08T18:55:13Z","receivedAt":"2017-08-08T18:55:28Z","isPatch":false,"sender":{"key":"igor.d.djordjevic@gmail.com","avatar":null},"body":"On 08/08/2017 15:14, Ævar Arnfjörð Bjarmason wrote:\n> On Mon, Aug 07 2017, Igor Djordjevic jotted:\n>> On 07/08/2017 23:25, Igor Djordjevic wrote:\n>>> On 06/08/2017 22:26, Ævar Arnfjörð Bjarmason wrote:\n>>>> On Sat, Aug 05 2017, Junio C. Hamano jotted:\n>>>>> I actually consider \"branch\" to *never* invoking a checkout. Even\n>>>>> when \"git branch -m A B\" happens to be done when your checked out\n>>>>> branch is A and you end up being on B. That is not a \"checkout\".\n>>>>\n>>>> I think we just have a different mental model of what \"checkout\"\n>>>> means. In my mind any operation that updates the HEAD to point to a new\n>>>> branch is a checkout of that branch.\n>>>\n>>> If I may, from a side-viewer`s point of view, it seems you`re\n>>> thinking in low-level implementation details, where what Junio\n>>> describes seems more as a high-level, conceptual/end-user`s point of\n>>> view.\n> \n> Yeah, I think that's a fair summary. Also I didn't mean to de-rail this\n> whole thread on what \"checkout\" really means, just explain what I meant\n> with previous comments, since there seemed to be confusion about that.\n> \n>>> Needing to update HEAD reference once we \"rename\" a branch, too, what\n>>> you consider a \"checkout\", seems to be required only because branch\n>>> name _is_ the branch reference in Git, so we need to update HEAD to\n>>> point to a new/renamed branch reference -- but it`s still the same\n>>> branch, conceptually.\n> \n> It's not *required* we could do one of three things:\n> \n> 1) Do what we do now, i.e. rename the branch/reflog & check out the new\n> name.\n> \n> 2) Rename the branch/reflog and checkout HEAD^0, i.e. say \"the branch\n> is now elsewhere, but we haven't moved your commit\".\n> \n> 3) Just not run replace_each_worktree_head_symref() which would end up\n> on a branch with no commits, i.e. an orphan branch.\n> \n> Now, I think 2 & 3 are pretty nonsensical and wouldn't ever propose we\n> should do that, but it's illustrative that #1 is not some required\n> inevitability in terms of explaining what's happening with the new name\n> being checked out (i.e. HEAD being updated).\n\nI think we agree, but we`re talking from different standpoints again.\n\nYou say \"it *can* be done *but* it doesn`t make sense\", where I say \n\"it *can`t* be done *because* it doesn`t make sense\".\n\nImplementation wise, of course it can be done differently, but \nconceptually it would be wrong (or confusing, at least), thus \ndifferent implementation, while theoretically possible, may not be a \nsane option, thus it`s impractical (not to say \"impossible\").\n\nBy \"required\", I really meant \"required in order to be conceptually \nsane\".\n\n>>> Documentation for \"git-checkout\" states that it is used to \"*Switch\n>>> branches*...[snip]\", and that is not what happens here.\n> \n> That's just the summary at the top but not the full story of what\n> git-checkout does. E.g. you can checkout a bare SHA1 which is not\n> switching branches, or a tag or whatever.\n\nI disagree, by checking out a bare SHA1 (or tag or whatever) I`d say \nyou *are* still switching branches - conceptually, at least.\n\nWhen you move from a named branch to (yet) unnamed one, you are \nswitching branches. Same goes for when you switch from one unnamed \nbranch to another (named or unnamed).\n\nMight be \"detached HEAD\" is not something we call an \"unnamed \nbranch\", but that`s what it practically is.\n\n>>> Implementation-wise it does because we can`t do it differently at the\n>>> moment, but in user`s eyes it`s still the same branch, so no switch\n>>> is made as far as the user is concerned.\n> \n> Kind of, it's also worthwhile to think about that in some sense no\n> switch would be performed as far as the user is concerned by taking\n> option #2, i.e. we'd be in the same working tree / you could still make\n> commits.\n> \n> You just couldn't make new commits on your \"master\" which is now called\n> \"topic\" and get new commits on \"topic\". I think it makes sense to do\n> that, but again, it's illustrative that it's not inevitable for\n> discussing the implementation.\n\nBut your second paragraph exactly explains why it`s not the same with \noption #2 (I guess you mean \"no HEAD update to point to renamed \nbranch\" here) - if user renames branch \"master\" to \"topic\", it`s \nnatural to expect that next commit is made on \"topic\" (which is now a \nnew name for \"master\", conceptually still being the same, just \nrenamed branch).\n\nEnding up in limbo, in a detached HEAD state, or even worse, still \nbeing on a branch with an old name \"master\" (which conceptually \nshouldn`t exist anymore, being known as \"topic\" now), would be \nconfusing, to say the least, and conceptually wrong, I would add.\n\n>>> In a different implementation, where branches would have permanent\n>>> references other than their names, no HEAD update would be needed as\n>>> the reference would still be the same, no matter the name change,\n>>> making the `git branch -m` situation clear even from your standpoint,\n>>> I`d say.\n>>>\n>>>>> Really from the end-user's point of view that is not a checkout.\n>>>>> The user renamed the branch A and the same conceptual entity, which\n>>>>> is a branch, is now called B. If that branch was what was checked\n>>>>> out (IOW, if that branch was what would be grown by one commit if\n>>>>> the user did \"git commit\"), then now that branch's name is B. It is\n>>>>> natural if you ask \"symbolic-ref HEAD\" what branch is checked out\n>>>>> after renaming A to B (and A happened to be what was checked out),\n>>>>> the answer chould be B.\n>>>>>\n>>>>> It's like the city you live in changed the name of the street your\n>>>>> house is on. You do not call movers, you do not do anything, but\n>>>>> your address changes.\n>>>>\n>>>> Yeah I see what you mean, although this analogy rapidly breaks down when\n>>>> you poke at it as shown above. My house (a sha1) can be on any number of\n>>>> streets and new ones can be added/removed all the time without changing\n>>>> where my house is at.\n>>>\n>>> I may be missing something, but I find the house/address analogy a\n>>> good one, actually, as I understood that \"house\" resembles a branch\n>>> reference HEAD is pointing to, not a sha1.\n>>>\n>>> Even further, and that might be the point of confusion, \"house\" seems\n>>> to be more like a \"permanent branch reference\" I mentioned above,\n>>> where your address can change (branch being renamed), but you would\n>>> still be in the same house (HEAD would still point to the same\n>>> permanent branch reference).\n>>>\n>>> If you move to another house, only then would HEAD change to point to\n>>> another (permanent) branch reference (a different house), and that\n>>> would be a checkout.\n> \n> I've yet to see a good real-world analogy of \"DAG with labels\", which is\n> all git really is, that doesn't break down at some point. Trees are\n> probably the best comparison, but even that breaks down in the face of\n> branch merges or even merges of entirely unrelated trees.\n> \n> So it's probably pointless to discuss this tangent any further, I don't\n> think it helps with deciding what to do about this new -c construct.\n> \n>>> Yes, it`s not really how it works from the inside, but I think that`s\n>>> irrelevant for the end-user experience :)\n>>>\n>>>> So it's just a way to get something exactly like -m except the \"move &&\n>>>> checkout\" logic is changed to \"copy && checkout\".\n>>>\n>>> Again, it seems the \"checkout\" part of \"move && checkout\" you`re\n>>> talking about is a user-wise unnecessary implementation detail. For\n>>> the user, it`s just a simple \"move\", staying on the same, but renamed\n>>> branch, thus no branch switching occurred (no \"checkout\", as per\n>>> documentation).\n> \n> Yes I agree that this has little to no impact on what's happening for\n> the user, I've merely been discussing \"checkout\" in the terms of what's\n> happening under the hood here.\n> \n>> All this said, having you mentioning the two argument version:\n>>\n>>> $ git checkout master\n>>> $ git branch -m topic avar/topic\n>>\n>> ... exactly proves the point that \"git branch -m\" is not expected to\n>> involve a checkout, even from implementation perspective. It`s just a\n>> consequence of needing to update the (now obsolete) reference HEAD\n>> points to (only) when the branch we`re renaming (moving) is the one\n>> that is currently checked-out.\n> \n> Hrm, I think you're confused about what this example does. For the sake\n> of avoiding confusion let's stop talking about checkout and just talk\n> about updating the HEAD.\n> \n> The point of that example is to show that the HEAD is only updated by\n> git branch [-m|-c] if the branch being moved/copied is the branch you're\n> currently on.\n> \n> Here the user just checked out master and then moved an unrelated topic\n> to avar/topic, that just manipulates the ref store & config, and won't\n> touch the HEAD.\n> \n> The reason I'm mentioning that example (and talking about a \"subset\") is\n> that amending git-checkout to do some of what this new \"git-branch -c\"\n> option would do would only cover a subset of what it does, since both -m\n> and -c are two-mode options in the sense that some of the time they\n> manipulate the refstore and the HEAD, and some of the time only the\n> refstore.\n\nI think we agree here, up to a point. I just wanted to take your \nexample in a different direction, obviously not being successful \nenough with my goal :)\n\nImplementation wise, we agree completely.\n\nConceptually, \"branch\" manipulates HEAD only to update an invalidated \nreference HEAD would otherwise still point to (being a dangling \npointer now), updating it only as much as needed to still point to \nthe same entity (branch), but having a different name now (thus a \ndifferent reference, which is implementation detail). It doesn`t do \ncheckout in terms of \"switching branches\".\n\nOn the other hand, \"checkout\" is expected to manipulate HEAD to \n\"switch branches\" (named or \"unnamed\", detached head etc., as argued \nabove).\n\n>>> Yeah it's not something I'm interested in or have a use-case for,\n>>> although I think in the same way we have -t for checkout it might be\n>>> sensible to have e.g.:\n>>>\n>>> $ git checkout -b topic-2 -c topic -t origin/master\n>>>\n>>> Where the new -c or --config-from would mean \"...and get the config from\n>>> 'topic'\". Such a name would probably be less confusing than\n>>> --super-b[branch?] which to be implies some ongoing hierarchical\n>>> relationship.\n>>\n>> This, on the other hand, sounds sensible, staying true to the\n>> existing logic. In the same manner you can do either:\n> \n> To continue the explanation above, yeah it's sensible, but I'm pointing\n> out that it's *also* sensible, i.e. whatever mode git-checkout has for\n> \"let's create a branch with the same start point & config as [some other\n> branch]\" it's always going to be complimentary but not a replacement for\n> git branch [-m|-c], since [-m|-c] has a mode for doing that without\n> doing any checkout whatsoever, just manipulating the refstore.\n\nMight be it didn`t read like that, but I actually agreed with you \nhere completely :)\n\nMy point was exactly to say that \"branch\" and \"checkout\" [-m|-c] \nshould exist one next to the other, where \"checkout\" also switches \nbranches, and \"branch\" does not...\n\n... which brings us to the very first point this whole discussion was \nstarted about, I think, whether \"branch\" should \"switch branches\" or \nnot, and it seems the conclusion would be \"no, it should not\" :)\n\nYes, \"branch\" can update HEAD in case of a renamed branch, but \nconceptually, that`s not \"branch switching\" - but if you really want \nto \"switch\" to a newly created branch right away in a single command \n(\"new branch\" not being renamed existing named or unnamed branch, but \na genuinely new entity), \"checkout\" would be the tool for the job.\n\n>> $ git branch topic -t origin/master\n>> $ git checkout topic\n>>\n>> ... or shorter equivalent:\n>>\n>> $ git checkout -b topic -t origin/master\n>>\n>> ..., you should be able to do:\n>>\n>> $ git branch -c topic topic-2\n>> $ git checkout topic-2\n>>\n>> ..., or equivalent:\n>>\n>> $ git checkout -b topic-2 -c topic\n>>\n>> ..., where \"-c\" would follow the same (or similar) logic as \"-t\" does\n>> now, as you already pointed out :)\n>>\n>> p.s. That said, is `git checkout -b topic-2 --move topic` being\n>> missed now...? :P That one would/could/should actually be expected to\n>> move (rename) the branch *and* check it out, no matter if HEAD\n>> currently points to it or not.\n>>\n>> Regards,\n>> Buga\n"}]}