What's cooking in git.git (Jul 2017, #09; Mon, 31)

What's cooking in git.git (Jul 2017, #09; Mon, 31)

[Junio C Hamano]

Here are the topics that have been cooking.  Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.  The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.

Even though -rc2 was scheduled for today, I'll wait for a few days
so that we can tag with updated l10n; there isn't much change since
the first release candidate.

You can find the changes described here in the integration branches
of the repositories listed at

    http://git-blame.blogspot.com/p/git-public-repositories.html

--------------------------------------------------
[Graduated to "master"]

* js/blame-lib (2017-07-24) 1 commit
  (merged to 'next' on 2017-07-26 at db0d081012)
 + blame: fix memory corruption scrambling revision name in error message

 A hotfix to a topic already in 'master'.

--------------------------------------------------
[New Topics]

* as/diff-options-grammofix (2017-07-31) 1 commit
 - diff-options doc: grammar fix

 A grammofix.

--------------------------------------------------
[Stalled]

* mg/status-in-progress-info (2017-05-10) 2 commits
 - status --short --inprogress: spell it as --in-progress
 - status: show in-progress info for short status

 "git status" learns an option to report various operations
 (e.g. "merging") that the user is in the middle of.

 cf. <xmqqmvakcdqw.fsf@gitster.mtv.corp.google.com>


* nd/worktree-move (2017-04-20) 6 commits
 - worktree remove: new command
 - worktree move: refuse to move worktrees with submodules
 - worktree move: accept destination as directory
 - worktree move: new command
 - worktree.c: add update_worktree_location()
 - worktree.c: add validate_worktree()

 "git worktree" learned move and remove subcommands.

 Expecting a reroll.
 cf. <20170420101024.7593-1-pclouds@gmail.com>
 cf. <20170421145916.mknekgqzhxffu7di@sigill.intra.peff.net>
 cf. <d0e81b1e-5869-299e-f462-4d43dc997bd1@ramsayjones.plus.com>


* sg/clone-refspec-from-command-line-config (2017-06-16) 2 commits
 - Documentation/clone: document ignored configuration variables
 - clone: respect additional configured fetch refspecs during initial fetch
 (this branch is used by sg/remote-no-string-refspecs.)

 "git clone -c var=val" is a way to set configuration variables in
 the resulting repository, but it is more useful to also make these
 variables take effect while the initial clone is happening,
 e.g. these configuration variables could be fetch refspecs.

 Waiting for a response.
 cf. <20170617112228.vugswym4o4owf6wj@sigill.intra.peff.net>
 cf. <xmqqmv8zhdap.fsf@gitster.mtv.corp.google.com>


* js/rebase-i-final (2017-07-27) 10 commits
 - rebase -i: rearrange fixup/squash lines using the rebase--helper
 - t3415: test fixup with wrapped oneline
 - rebase -i: skip unnecessary picks using the rebase--helper
 - rebase -i: check for missing commits in the rebase--helper
 - t3404: relax rebase.missingCommitsCheck tests
 - rebase -i: also expand/collapse the SHA-1s via the rebase--helper
 - rebase -i: do not invent onelines when expanding/collapsing SHA-1s
 - rebase -i: remove useless indentation
 - rebase -i: generate the script via rebase--helper
 - t3415: verify that an empty instructionFormat is handled as before

 The final batch to "git rebase -i" updates to move more code from
 the shell script to C.

 Expecting a reroll.


* bp/fsmonitor (2017-06-12) 6 commits
 - fsmonitor: add a sample query-fsmonitor hook script for Watchman
 - fsmonitor: add documentation for the fsmonitor extension.
 - fsmonitor: add test cases for fsmonitor extension
 - fsmonitor: teach git to optionally utilize a file system monitor to speed up detecting new or changed files.
 - dir: make lookup_untracked() available outside of dir.c
 - bswap: add 64 bit endianness helper get_be64

 We learned to talk to watchman to speed up "git status".

 Expecting a reroll.
 cf. <bade1166-e646-b05a-f65b-adb8da8ba0a7@gmail.com>

--------------------------------------------------
[Cooking]

* ah/doc-wserrorhighlight (2017-07-25) 1 commit
  (merged to 'next' on 2017-07-27 at cd1bb28d95)
 + doc: add missing values "none" and "default" for diff.wsErrorHighlight

 Doc update.

 Will cook in 'next'.


* dc/fmt-merge-msg-microcleanup (2017-07-25) 1 commit
  (merged to 'next' on 2017-07-27 at 6df06eb788)
 + fmt-merge-msg: fix coding style

 Code cleanup.

 Will cook in 'next'.


* js/git-gui-msgfmt-on-windows (2017-07-25) 7 commits
 - Merge branch 'js/msgfmt-on-windows' of ../git-gui into js/git-gui-msgfmt-on-windows
 - git-gui (MinGW): make use of MSys2's msgfmt
 - Merge remote-tracking branch 'philoakley/dup-gui'
 - git gui: allow for a long recentrepo list
 - git gui: de-dup selected repo from recentrepo history
 - git gui: cope with duplicates in _get_recentrepo
 - git-gui: remove duplicate entries from .gitconfig's gui.recentrepo

 Because recent Git for Windows do come with a real msgfmt, the
 build procedure for git-gui has been updated to use it instead of a
 hand-rolled substitute.


* jt/subprocess-handshake (2017-07-26) 3 commits
 - sub-process: refactor handshake to common function
 - Documentation: migrate sub-process docs to header
 - Merge branch 'ls/filter-process-delayed' into jt/subprocess-handshake
 (this branch uses ls/filter-process-delayed.)

 Code cleanup.

 Will merge to and cook in 'next'.


* lg/merge-signoff (2017-07-25) 1 commit
 - merge: add a --signoff flag

 "git merge" learned a "--signoff" option to add the Signed-off-by:
 trailer with the committer's name.


* pb/trailers-from-command-line (2017-07-25) 4 commits
 - SQUASH???
 - interpret-trailers: add options for actions
 - trailers: introduce struct new_trailer_item
 - trailers: export action enums and corresponding lookup functions

 "git interpret-trailers" learned to take the trailer specifications
 from the command line that overrides the configured values.

 Expecting a reroll for compilation fix.


* sb/submodule-recursive-checkout-detach-head (2017-07-28) 2 commits
 - Documentation/checkout: clarify submodule HEADs to be detached
 - recursive submodules: detach HEAD from new state

 "git checkout --recursive" may overwrite and rewind the history of
 the branch that happens to be checked out in submodule
 repositories, which might not be desirable.  Detach the HEAD but
 still allow the recursive checkout to succeed in such a case.

 Undecided.
 This needs justification in a larger picture; it is unclear why
 this is better than rejecting recursive checkout, for example.


* ti/external-sha1dc (2017-07-25) 1 commit
  (merged to 'next' on 2017-07-27 at d1ce394fe2)
 + hash: allow building with the external sha1dc library

 Platforms that ship with a separate sha1 with collision detection
 library can link to it instead of using the copy we ship as part of
 our source tree.

 Waiting for review to conclude
 cf. <CACBZZX7M=H8tNkZXpHBvv0rbY58EJk4dkoUzGKMftWoKUqF8sA@mail.gmail.com>


* bw/submodule-config-cleanup (2017-07-26) 17 commits
 - submodule: remove gitmodules_config
 - unpack-trees: improve loading of .gitmodules
 - submodule-config: lazy-load a repository's .gitmodules file
 - submodule-config: move submodule-config functions to submodule-config.c
 - submodule-config: remove support for overlaying repository config
 - diff: stop allowing diff to have submodules configured in .git/config
 - submodule: remove submodule_config callback routine
 - unpack-trees: don't rely on overlayed config
 - submodule: don't rely on overlayed config when setting diffopts
 - fetch: don't overlay config with submodule-config
 - submodule--helper: don't overlay config in update-clone
 - submodule--helper: don't overlay config in remote_submodule_branch
 - add, reset: ensure submodules can be added or reset
 - submodule: don't use submodule_from_name
 - t7411: check configuration parsing errors
 - Merge branch 'bc/object-id' into bw/submodule-config-cleanup
 - Merge branch 'bw/grep-recurse-submodules' into bw/submodule-config-cleanup
 (this branch uses bc/object-id, bw/grep-recurse-submodules and sb/object-id.)

 Code clean-up to avoid mixing values read from the .gitmodules file
 and values read from the .git/config file.


* jb/t8008-cleanup (2017-07-26) 1 commit
 - t8008: rely on rev-parse'd HEAD instead of sha1 value

 Code clean-up.

 Will merge to and cook in 'next'.


* rg/rerere-train-overwrite (2017-07-26) 1 commit
 - contrib/rerere-train: optionally overwrite existing resolutions

 The "rerere-train" script (in contrib/) learned the "--overwrite"
 option to allow overwriting existing recorded resolutions.

 Will merge to and cook in 'next'.


* dl/credential-cache-socket-in-xdg-cache (2017-07-27) 1 commit
 - credential-cache: interpret an ECONNRESET as an EOF

 A recently added test for the "credential-cache" helper revealed
 that EOF detection done around the time the connection to the cache
 daemon is torn down were flaky.  This was fixed by reacting to
 ECONNRESET and behaving as if we got an EOF.

 Will merge to and cook in 'next'.


* eb/contacts-reported-by (2017-07-27) 1 commit
 - git-contacts: also recognise "Reported-by:"

 "git contacts" (in contrib/) now lists the address on the
 "Reported-by:" trailer to its output, in addition to those on
 S-o-b: and other trailers, to make it easier to notify (and thank)
 the original bug reporter.

 Will merge to and cook in 'next'.


* js/run-process-parallel-api-fix (2017-07-21) 1 commit
  (merged to 'next' on 2017-07-27 at 4b54b69172)
 + run_processes_parallel: change confusing task_cb convention

 API fix.

 Will cook in 'next'.


* cc/ref-is-hidden-microcleanup (2017-07-24) 1 commit
  (merged to 'next' on 2017-07-27 at 37af544e1c)
 + refs: use skip_prefix() in ref_is_hidden()

 Code cleanup.

 Will cook in 'next'.


* bw/push-options-recursively-to-submodules (2017-07-20) 1 commit
  (merged to 'next' on 2017-07-27 at 26b3af2544)
 + submodule--helper: teach push-check to handle HEAD

 "git push --recurse-submodules $there HEAD:$target" was not
 propagated down to the submodules, but now it is.

 Will cook in 'next'.


* jc/http-sslkey-and-ssl-cert-are-paths (2017-07-20) 1 commit
  (merged to 'next' on 2017-07-20 at 5489304b99)
 + http.c: http.sslcert and http.sslkey are both pathnames

 The http.{sslkey,sslCert} configuration variables are to be
 interpreted as a pathname that honors "~[username]/" prefix, but
 weren't, which has been fixed.

 Will cook in 'next'.


* jt/fsck-code-cleanup (2017-07-26) 3 commits
  (merged to 'next' on 2017-07-26 at 7a17e279da)
 + fsck: cleanup unused variable
  (merged to 'next' on 2017-07-20 at f7045a8c47)
 + object: remove "used" field from struct object
 + fsck: remove redundant parse_tree() invocation

 Code clean-up.

 Will cook in 'next'.


* rs/pack-objects-pbase-cleanup (2017-07-20) 1 commit
  (merged to 'next' on 2017-07-20 at a6b618559b)
 + pack-objects: remove unnecessary NULL check

 Code clean-up.

 Will cook in 'next'.


* st/lib-gpg-kill-stray-agent (2017-07-20) 1 commit
  (merged to 'next' on 2017-07-20 at 8ea68c483f)
 + t: lib-gpg: flush gpg agent on startup

 Some versions of GnuPG fails to kill gpg-agent it auto-spawned
 and such a left-over agent can interfere with a test.  Work it
 around by attempting to kill one before starting a new test.

 Will cook in 'next'.


* jk/c99 (2017-07-18) 2 commits
  (merged to 'next' on 2017-07-18 at 1cfc30f7c1)
 + clean.c: use designated initializer
 + strbuf: use designated initializers in STRBUF_INIT

 Start using selected c99 constructs in small, stable and
 essentialpart of the system to catch people who care about
 older compilers that do not grok them.

 Will cook in 'next'.


* jk/check-ref-format-oor-fix (2017-07-14) 1 commit
 - check-ref-format: require a repository for --branch

 Objected...
 cf. <20170717172709.GL93855@aiede.mtv.corp.google.com>


* bw/grep-recurse-submodules (2017-07-18) 10 commits
 - grep: recurse in-process using 'struct repository'
 - submodule: merge repo_read_gitmodules and gitmodules_config
 - submodule: check for unmerged .gitmodules outside of config parsing
 - submodule: check for unstaged .gitmodules outside of config parsing
 - submodule: remove fetch.recursesubmodules from submodule-config parsing
 - submodule: remove submodule.fetchjobs from submodule-config parsing
 - config: add config_from_gitmodules
 - cache.h: add GITMODULES_FILE macro
 - repository: have the_repository use the_index
 - repo_read_index: don't discard the index
 (this branch is used by bw/submodule-config-cleanup.)


* bw/object-id (2017-07-17) 3 commits
  (merged to 'next' on 2017-07-18 at 90d27c0e7c)
 + receive-pack: don't access hash of NULL object_id pointer
 + notes: don't access hash of NULL object_id pointer
 + tree-diff: don't access hash of NULL object_id pointer

 Conversion from uchar[20] to struct object_id continues.

 Will cook in 'next'.


* ks/commit-abort-on-empty-message-fix (2017-07-17) 1 commit
  (merged to 'next' on 2017-07-27 at e81ad4c1dc)
 + commit: check for empty message before the check for untouched template

 "git commit" when seeing an totally empty message said "you did not
 edit the message", which is clearly wrong.  The message has been
 corrected.

 Will cook in 'next'.


* rs/bswap-ubsan-fix (2017-07-17) 2 commits
  (merged to 'next' on 2017-07-20 at ce6bad07b0)
 + bswap: convert get_be16, get_be32 and put_be32 to inline functions
 + bswap: convert to unsigned before shifting in get_be32

 Code clean-up.

 Will cook in 'next'.


* rs/move-array (2017-07-17) 4 commits
  (merged to 'next' on 2017-07-20 at f3086cd20e)
 + ls-files: don't try to prune an empty index
 + apply: use COPY_ARRAY and MOVE_ARRAY in update_image()
 + use MOVE_ARRAY
 + add MOVE_ARRAY

 Code clean-up.

 Will cook in 'next'.


* rs/stat-data-unaligned-reads-fix (2017-07-17) 1 commit
  (merged to 'next' on 2017-07-20 at e7d3782823)
 + dir: support platforms that require aligned reads

 Code clean-up.

 Will cook in 'next'.


* wd/rebase-conflict-guide (2017-07-17) 1 commit
  (merged to 'next' on 2017-07-20 at c78e758b23)
 + rebase: make resolve message clearer for inexperienced users

 The advice message given when "git rebase" stops for conflicting
 changes has been improved.

 Will cook in 'next'.


* hb/gitweb-project-list (2017-07-18) 1 commit
  (merged to 'next' on 2017-07-27 at c25d65ca25)
 + gitweb: skip unreadable subdirectories

 When a directory is not readable, "gitweb" fails to build the
 project list.  Work this around by skipping such a directory.

 Will cook in 'next'.

 It might end up hiding a problem under the rug and a better
 solution might be to loudly complain to the administrator pointing
 out the problematic directory, but this will at least make it
 "work".


* jk/ref-filter-colors (2017-07-13) 15 commits
  (merged to 'next' on 2017-07-18 at 75d4eb7ecf)
 + ref-filter: consult want_color() before emitting colors
 + pretty: respect color settings for %C placeholders
 + rev-list: pass diffopt->use_colors through to pretty-print
 + for-each-ref: load config earlier
 + color: check color.ui in git_default_config()
 + ref-filter: pass ref_format struct to atom parsers
 + ref-filter: factor out the parsing of sorting atoms
 + ref-filter: make parse_ref_filter_atom a private function
 + ref-filter: provide a function for parsing sort options
 + ref-filter: move need_color_reset_at_eol into ref_format
 + ref-filter: abstract ref format into its own struct
 + ref-filter: simplify automatic color reset
 + t: use test_decode_color rather than literal ANSI codes
 + docs/for-each-ref: update pointer to color syntax
 + check return value of verify_ref_format()

 "%C(color name)" in the pretty print format always produced ANSI
 color escape codes, which was an early design mistake.  They now
 honor the configuration (e.g. "color.ui = never") and also tty-ness
 of the output medium.

 Will cook in 'next'.


* sb/object-id (2017-07-13) 2 commits
  (merged to 'next' on 2017-07-18 at e4df0ba3b1)
 + tag: convert gpg_verify_tag to use struct object_id
 + commit: convert lookup_commit_graft to struct object_id
 (this branch is used by bc/object-id and bw/submodule-config-cleanup.)

 Conversion from uchar[20] to struct object_id continues.

 Will cook in 'next'.


* rs/sha1-file-micro-optim (2017-07-09) 2 commits
 - SQUASH???
 - sha1_file: add slash once in for_each_file_in_obj_subdir()

 Code cleanup.

 Perhaps drop.
 cf. <f59c8256-716b-9305-2a4f-d4fe49f666ff@web.de>


* ks/prepare-commit-msg-sample (2017-07-12) 4 commits
  (merged to 'next' on 2017-07-18 at 48d9650a30)
 + hook: add a simple first example
 + hook: add sign-off using "interpret-trailers"
 + hook: name the positional variables
 + hook: cleanup script

 Remove an example that is now obsolete from a sample hook,
 and improve an old example in it that added a sign-off manually
 to use the interpret-trailers command.

 Will cook in 'next'.


* jc/allow-lazy-cas (2017-07-06) 1 commit
 - push: disable lazy --force-with-lease by default

 Because "git push --force-with-lease[=<ref>]" that relies on the
 stability of remote-tracking branches is unsafe when something
 fetches into the repository behind user's back, it is now disabled
 by default.  A new configuration variable can be used to enable it
 by users who know what they are doing.  This would pave the way to
 possibly turn `--force` into `--force-with-lease`.

 Undecided.
 Independent from disabling the feature by default, this stirred up
 a discussion to replace the DWIM heuristics with a better one, which
 deserves to be its own topic.
 cf. <alpine.DEB.2.21.1.1707131435220.4193@virtualbox>


* bc/object-id (2017-07-17) 12 commits
  (merged to 'next' on 2017-07-18 at fd161056e4)
 + sha1_name: convert uses of 40 to GIT_SHA1_HEXSZ
 + sha1_name: convert GET_SHA1* flags to GET_OID*
 + sha1_name: convert get_sha1* to get_oid*
 + Convert remaining callers of get_sha1 to get_oid.
 + builtin/unpack-file: convert to struct object_id
 + bisect: convert bisect_checkout to struct object_id
 + builtin/update_ref: convert to struct object_id
 + sequencer: convert to struct object_id
 + remote: convert struct push_cas to struct object_id
 + submodule: convert submodule config lookup to use object_id
 + builtin/merge-tree: convert remaining caller of get_sha1 to object_id
 + builtin/fsck: convert remaining caller of get_sha1 to object_id
 (this branch is used by bw/submodule-config-cleanup; uses sb/object-id.)

 Conversion from uchar[20] to struct object_id continues.

 Will cook in 'next'.


* jk/reflog-walk (2017-07-09) 9 commits
  (merged to 'next' on 2017-07-09 at 7449e964c6)
 + reflog-walk: apply --since/--until to reflog dates
 + reflog-walk: stop using fake parents
 + rev-list: check reflog_info before showing usage
 + get_revision_1(): replace do-while with an early return
 + log: do not free parents when walking reflog
 + log: clarify comment about reflog cycles
 + revision: disallow reflog walking with revs->limited
 + t1414: document some reflog-walk oddities
 + Merge branch 'jk/reflog-walk-maint' into jk/reflog-walk

 Numerous bugs in walking of reflogs via "log -g" and friends have
 been fixed.

 Will cook in 'next'.


* sb/hashmap-cleanup (2017-07-05) 10 commits
  (merged to 'next' on 2017-07-12 at ce31d06165)
 + t/helper/test-hashmap: use custom data instead of duplicate cmp functions
 + name-hash.c: drop hashmap_cmp_fn cast
 + submodule-config.c: drop hashmap_cmp_fn cast
 + remote.c: drop hashmap_cmp_fn cast
 + patch-ids.c: drop hashmap_cmp_fn cast
 + convert/sub-process: drop cast to hashmap_cmp_fn
 + config.c: drop hashmap_cmp_fn cast
 + builtin/describe: drop hashmap_cmp_fn cast
 + builtin/difftool.c: drop hashmap_cmp_fn cast
 + attr.c: drop hashmap_cmp_fn cast

 Many uses of comparision callback function the hashmap API uses
 cast the callback function type when registering it to
 hashmap_init(), which defeats the compile time type checking when
 the callback interface changes (e.g. gaining more parameters).
 The callback implementations have been updated to take "void *"
 pointers and cast them to the type they expect instead.

 Will cook in 'next'.


* ex/deprecate-empty-pathspec-as-match-all (2017-06-23) 2 commits
  (merged to 'next' on 2017-06-26 at d026281517)
 + pathspec: die on empty strings as pathspec
 + t0027: do not use an empty string as a pathspec element

 The final step to make an empty string as a pathspec element
 illegal.  We started this by first deprecating and warning a
 pathspec that has such an element in 2.11 (Nov 2016).

 Hopefully we can merge this down to the 'master' by the end of the
 year?  A deprecation warning period that is about 1 year does not
 sound too bad.

 Will cook in 'next'.


* mh/packed-ref-store (2017-07-27) 31 commits
  (merged to 'next' on 2017-07-27 at 857dcb8cba)
 + packed_ref_store: handle a packed-refs file that is a symlink
  (merged to 'next' on 2017-07-05 at 6c68c603cc)
 + read_packed_refs(): die if `packed-refs` contains bogus data
 + t3210: add some tests of bogus packed-refs file contents
 + repack_without_refs(): don't lock or unlock the packed refs
 + commit_packed_refs(): remove call to `packed_refs_unlock()`
 + clear_packed_ref_cache(): don't protest if the lock is held
 + packed_refs_unlock(), packed_refs_is_locked(): new functions
 + packed_refs_lock(): report errors via a `struct strbuf *err`
 + packed_refs_lock(): function renamed from lock_packed_refs()
 + commit_packed_refs(): use a staging file separate from the lockfile
 + commit_packed_refs(): report errors rather than dying
 + packed_ref_store: make class into a subclass of `ref_store`
 + packed-backend: new module for handling packed references
 + packed_read_raw_ref(): new function, replacing `resolve_packed_ref()`
 + packed_ref_store: support iteration
 + packed_peel_ref(): new function, extracted from `files_peel_ref()`
 + repack_without_refs(): take a `packed_ref_store *` parameter
 + get_packed_ref(): take a `packed_ref_store *` parameter
 + rollback_packed_refs(): take a `packed_ref_store *` parameter
 + commit_packed_refs(): take a `packed_ref_store *` parameter
 + lock_packed_refs(): take a `packed_ref_store *` parameter
 + add_packed_ref(): take a `packed_ref_store *` parameter
 + get_packed_refs(): take a `packed_ref_store *` parameter
 + get_packed_ref_cache(): take a `packed_ref_store *` parameter
 + validate_packed_ref_cache(): take a `packed_ref_store *` parameter
 + clear_packed_ref_cache(): take a `packed_ref_store *` parameter
 + packed_ref_store: move `packed_refs_lock` member here
 + packed_ref_store: move `packed_refs_path` here
 + packed_ref_store: new struct
 + add_packed_ref(): teach function to overwrite existing refs
 + t1408: add a test of stale packed refs covered by loose refs

 The "ref-store" code reorganization continues.

 Will cook in 'next'.


* sd/branch-copy (2017-06-18) 3 commits
  (merged to 'next' on 2017-07-18 at 5e3b9357ea)
 + branch: add a --copy (-c) option to go with --move (-m)
 + branch: add test for -m renaming multiple config sections
 + config: create a function to format section headers

 "git branch" learned "-c/-C" to create and switch to a new branch
 by copying an existing one.

 Will cook in 'next'.

 I personally do not think "branch --copy master backup" while on
 "master" that switches to "backup" is a good UI, and I *will* say
 "I told you so" when users complain after we merge this down to
 'master'.


* ls/filter-process-delayed (2017-06-30) 7 commits
  (merged to 'next' on 2017-07-05 at a35e644082)
 + convert: add "status=delayed" to filter process protocol
 + convert: refactor capabilities negotiation
 + convert: move multiple file filter error handling to separate function
 + convert: put the flags field before the flag itself for consistent style
 + t0021: write "OUT <size>" only on success
 + t0021: make debug log file name configurable
 + t0021: keep filter log files on comparison
 (this branch is used by jt/subprocess-handshake.)

 The filter-process interface learned to allow a process with long
 latency give a "delayed" response.

 Will cook in 'next'.


* sb/diff-color-move (2017-06-30) 26 commits
  (merged to 'next' on 2017-07-06 at 758ed40e4f)
 + diff: document the new --color-moved setting
 + diff.c: add dimming to moved line detection
 + diff.c: color moved lines differently, plain mode
 + diff.c: color moved lines differently
 + diff.c: buffer all output if asked to
 + diff.c: emit_diff_symbol learns about DIFF_SYMBOL_SUMMARY
 + diff.c: emit_diff_symbol learns about DIFF_SYMBOL_STAT_SEP
 + diff.c: convert word diffing to use emit_diff_symbol
 + diff.c: convert show_stats to use emit_diff_symbol
 + diff.c: convert emit_binary_diff_body to use emit_diff_symbol
 + submodule.c: migrate diff output to use emit_diff_symbol
 + diff.c: emit_diff_symbol learns DIFF_SYMBOL_REWRITE_DIFF
 + diff.c: emit_diff_symbol learns about DIFF_SYMBOL_BINARY_FILES
 + diff.c: emit_diff_symbol learns DIFF_SYMBOL_HEADER
 + diff.c: emit_diff_symbol learns DIFF_SYMBOL_FILEPAIR_{PLUS, MINUS}
 + diff.c: emit_diff_symbol learns DIFF_SYMBOL_CONTEXT_INCOMPLETE
 + diff.c: emit_diff_symbol learns DIFF_SYMBOL_WORDS[_PORCELAIN]
 + diff.c: migrate emit_line_checked to use emit_diff_symbol
 + diff.c: emit_diff_symbol learns DIFF_SYMBOL_NO_LF_EOF
 + diff.c: emit_diff_symbol learns DIFF_SYMBOL_CONTEXT_FRAGINFO
 + diff.c: emit_diff_symbol learns DIFF_SYMBOL_CONTEXT_MARKER
 + diff.c: introduce emit_diff_symbol
 + diff.c: factor out diff_flush_patch_all_file_pairs
 + diff.c: move line ending check into emit_hunk_header
 + diff.c: readability fix
 + Merge branch 'sb/hashmap-customize-comparison' into sb/diff-color-move

 "git diff" has been taught to optionally paint new lines that are
 the same as deleted lines elsewhere differently from genuinely new
 lines.

 Will cook in 'next'.

--------------------------------------------------
[Discarded]

* mh/packed-ref-store-prep-extra (2017-06-18) 1 commit
 . prefix_ref_iterator_advance(): relax the check of trim length

 Split out of mh/packed-ref-store-prep.


* nd/prune-in-worktree (2017-04-24) 12 commits
 . rev-list: expose and document --single-worktree
 . revision.c: --reflog add HEAD reflog from all worktrees
 . files-backend: make reflog iterator go through per-worktree reflog
 . revision.c: --all adds HEAD from all worktrees
 . refs: remove dead for_each_*_submodule()
 . revision.c: use refs_for_each*() instead of for_each_*_submodule()
 . refs: add refs_head_ref()
 . refs: move submodule slash stripping code to get_submodule_ref_store
 . refs.c: refactor get_submodule_ref_store(), share common free block
 . revision.c: --indexed-objects add objects from all worktrees
 . revision.c: refactor add_index_objects_to_pending()
 . revision.h: new flag in struct rev_info wrt. worktree-related refs

 "git gc" and friends when multiple worktrees are used off of a
 single repository did not consider the index and per-worktree refs
 of other worktrees as the root for reachability traversal, making
 objects that are in use only in other worktrees to be subject to
 garbage collection.

Re: What's cooking in git.git (Jul 2017, #09; Mon, 31)

[Ramsay Jones]

On 31/07/17 23:30, Junio C Hamano wrote:
[snip]
> 
> * sd/branch-copy (2017-06-18) 3 commits
>   (merged to 'next' on 2017-07-18 at 5e3b9357ea)
>  + branch: add a --copy (-c) option to go with --move (-m)
>  + branch: add test for -m renaming multiple config sections
>  + config: create a function to format section headers
> 
>  "git branch" learned "-c/-C" to create and switch to a new branch
>  by copying an existing one.
> 
>  Will cook in 'next'.
> 
>  I personally do not think "branch --copy master backup" while on
>  "master" that switches to "backup" is a good UI, and I *will* say
>  "I told you so" when users complain after we merge this down to
>  'master'.

I wouldn't normally comment on an issue like this because I am
not very good at specifying, designing and evaluating UIs (so
who in their right mind would listen to me). ;-)

FWIW, I suspect that I would not like using this interface either
and would, therefore, not use it. However, I guess the worst that
would happen, is that it would gain another 'wort' (--option) to
turn off the "switches to backup" branch. :-D

I didn't want you to think that the lack of comments on this was
because everybody agreed that it was a good idea.

ATB,
Ramsay Jones

Re: What's cooking in git.git (Jul 2017, #09; Mon, 31)

[Sahil Dua]

>
> * sd/branch-copy (2017-06-18) 3 commits
>   (merged to 'next' on 2017-07-18 at 5e3b9357ea)
>  + branch: add a --copy (-c) option to go with --move (-m)
>  + branch: add test for -m renaming multiple config sections
>  + config: create a function to format section headers
>
>  "git branch" learned "-c/-C" to create and switch to a new branch
>  by copying an existing one.
>
>  Will cook in 'next'.

Junio, are we still waiting for interaction with other patches to
settle down or simply cooking it further for any potential
feedback/suggestions on this?

>
>  I personally do not think "branch --copy master backup" while on
>  "master" that switches to "backup" is a good UI, and I *will* say
>  "I told you so" when users complain after we merge this down to
>  'master'.
>

Re: What's cooking in git.git (Jul 2017, #09; Mon, 31)

[Stefan Beller]

On Thu, Aug 3, 2017 at 1:17 PM, Sahil Dua <sahildua2305@gmail.com> wrote:
>>
>> * sd/branch-copy (2017-06-18) 3 commits
>>   (merged to 'next' on 2017-07-18 at 5e3b9357ea)
>>  + branch: add a --copy (-c) option to go with --move (-m)
>>  + branch: add test for -m renaming multiple config sections
>>  + config: create a function to format section headers
>>
>>  "git branch" learned "-c/-C" to create and switch to a new branch
>>  by copying an existing one.
>>
>>  Will cook in 'next'.
>
> Junio, are we still waiting for interaction with other patches to
> settle down or simply cooking it further for any potential
> feedback/suggestions on this?

I think anything currently cooking in next is waiting for the next
release to happen, and then progress to master IIUC eventually
unless noted otherwise.

Re: What's cooking in git.git (Jul 2017, #09; Mon, 31)

[Sahil Dua]

Ah! I had skipped this reply from Ramsay earlier.

On Tue, Aug 1, 2017 at 1:36 AM, Ramsay Jones
<ramsay@ramsayjones.plus.com> wrote:
>
>
> On 31/07/17 23:30, Junio C Hamano wrote:
> [snip]
>>
>> * sd/branch-copy (2017-06-18) 3 commits
>>   (merged to 'next' on 2017-07-18 at 5e3b9357ea)
>>  + branch: add a --copy (-c) option to go with --move (-m)
>>  + branch: add test for -m renaming multiple config sections
>>  + config: create a function to format section headers
>>
>>  "git branch" learned "-c/-C" to create and switch to a new branch
>>  by copying an existing one.
>>
>>  Will cook in 'next'.
>>
>>  I personally do not think "branch --copy master backup" while on
>>  "master" that switches to "backup" is a good UI, and I *will* say
>>  "I told you so" when users complain after we merge this down to
>>  'master'.
>
> I wouldn't normally comment on an issue like this because I am
> not very good at specifying, designing and evaluating UIs (so
> who in their right mind would listen to me). ;-)
>
> FWIW, I suspect that I would not like using this interface either
> and would, therefore, not use it.

Does that mean you'd use it when "branch --copy feature-branch
new-feature-branch" in the case when you would want to start working
on a new branch (to modify or experiment with your current feature
branch) on top of a branch keeping intact all the configuration and
logs?

I think it's really a matter of how this feature is seen from the
end-user point of view. If we consider example "branch --copy master
backup" - obviously, switching to backup isn't the ideal situation.
However, if we consider the example above, switching makes sense. None
of them is going to be correct in 100% cases. :)

> However, I guess the worst that
> would happen, is that it would gain another 'wort' (--option) to
> turn off the "switches to backup" branch. :-D
>
> I didn't want you to think that the lack of comments on this was
> because everybody agreed that it was a good idea.
>
> ATB,
> Ramsay Jones
>
>

Re: What's cooking in git.git (Jul 2017, #09; Mon, 31)

[Junio C Hamano]

Sahil Dua <sahildua2305@gmail.com> writes:

> Ah! I had skipped this reply from Ramsay earlier.
>
> On Tue, Aug 1, 2017 at 1:36 AM, Ramsay Jones
> ...
>>>  I personally do not think "branch --copy master backup" while on
>>>  "master" that switches to "backup" is a good UI, and I *will* say
>>>  "I told you so" when users complain after we merge this down to
>>>  'master'.
>>
>> I wouldn't normally comment on an issue like this because I am
>> not very good at specifying, designing and evaluating UIs (so
>> who in their right mind would listen to me). ;-)
>>
>> FWIW, I suspect that I would not like using this interface either
>> and would, therefore, not use it.
>
> Does that mean you'd use it when "branch --copy feature-branch
> new-feature-branch" in the case when you would want to start working
> on a new branch (to modify or experiment with your current feature
> branch) on top of a branch keeping intact all the configuration and
> logs?

I am not Ramsay, but your choice of branch names in your question,
i.e. "branch --copy feature new-feature", is what we do not agree
with in the first place, especially when we are *on* the "feature"
branch.

We view "copy A B" as a way to make a back-up of A in B.  I.e. We
want to keep working on A, but just in case we screw up badly, make
a backup copy of A in B, so that we can recover by a "branch --move
B A" later if needed.  So touching B is the last thing we want to do
after "copy A B" operation---hence we do not want to switch to B.

That is not to say that you are wrong to wish to create a new
branch, check it out and start working on it with a single command.
We already have such a command all Git users are accustomed to,
which is "git checkout -b new-feature-branch feature-branch".  

That existing command does not copy things other than the commit
object name from "feature-branch", and I do not think it should by
default.  But I do not think it is wrong to extend it with a new
option (think of it as "checkout --super-b" ;-) to copy other things
like branch descriptions etc.

So from that point of view, your new feature conceptually fits a lot
better to "git checkout", and does not belong to "git branch".  That
is why I do not think "git branch --copy A B" while you are on A
should check out B after creating the copy.

Re: What's cooking in git.git (Jul 2017, #09; Mon, 31)

[Junio C Hamano]

Sahil Dua <sahildua2305@gmail.com> writes:

>>
>> * sd/branch-copy (2017-06-18) 3 commits
>>   (merged to 'next' on 2017-07-18 at 5e3b9357ea)
>>  + branch: add a --copy (-c) option to go with --move (-m)
>>  + branch: add test for -m renaming multiple config sections
>>  + config: create a function to format section headers
>>
>>  "git branch" learned "-c/-C" to create and switch to a new branch
>>  by copying an existing one.
>>
>>  Will cook in 'next'.
>
> Junio, are we still waiting for interaction with other patches to
> settle down or simply cooking it further for any potential
> feedback/suggestions on this?

No, "waiting for other topics to settle" was a long time ago.
During the pre-release feature freeze, nothing will be merged to
'master', unless it is a trivially correct bugfix or a regression
fix.  This one is neither.

Re: What's cooking in git.git (Jul 2017, #09; Mon, 31)

[Ramsay Jones]

On 03/08/17 22:07, Junio C Hamano wrote:
> Sahil Dua <sahildua2305@gmail.com> writes:
> 
>> Ah! I had skipped this reply from Ramsay earlier.
>>
>> On Tue, Aug 1, 2017 at 1:36 AM, Ramsay Jones
>> ...
>>>>  I personally do not think "branch --copy master backup" while on
>>>>  "master" that switches to "backup" is a good UI, and I *will* say
>>>>  "I told you so" when users complain after we merge this down to
>>>>  'master'.
>>>
>>> I wouldn't normally comment on an issue like this because I am
>>> not very good at specifying, designing and evaluating UIs (so
>>> who in their right mind would listen to me). ;-)
>>>
>>> FWIW, I suspect that I would not like using this interface either
>>> and would, therefore, not use it.
>>
>> Does that mean you'd use it when "branch --copy feature-branch
>> new-feature-branch" in the case when you would want to start working
>> on a new branch (to modify or experiment with your current feature
>> branch) on top of a branch keeping intact all the configuration and
>> logs?
> 
> I am not Ramsay, but your choice of branch names in your question,
> i.e. "branch --copy feature new-feature", is what we do not agree
> with in the first place, especially when we are *on* the "feature"
> branch.
> 
> We view "copy A B" as a way to make a back-up of A in B.  I.e. We
> want to keep working on A, but just in case we screw up badly, make
> a backup copy of A in B, so that we can recover by a "branch --move
> B A" later if needed.  So touching B is the last thing we want to do
> after "copy A B" operation---hence we do not want to switch to B.

I couldn't have said this better. ;-)

> That is not to say that you are wrong to wish to create a new
> branch, check it out and start working on it with a single command.
> We already have such a command all Git users are accustomed to,
> which is "git checkout -b new-feature-branch feature-branch".  

Indeed, I wouldn't think of doing anything else. (That may be
because I've been using git too long, of course).

> That existing command does not copy things other than the commit
> object name from "feature-branch", and I do not think it should by
> default.  But I do not think it is wrong to extend it with a new
> option (think of it as "checkout --super-b" ;-) to copy other things
> like branch descriptions etc.

Hmm, I've never felt the lack of copying any attributes from
the origin branch. So, I'm not convinced a "--super-b" is needed
(but if other people feel the need, then why not).

> So from that point of view, your new feature conceptually fits a lot
> better to "git checkout", and does not belong to "git branch".  That
> is why I do not think "git branch --copy A B" while you are on A
> should check out B after creating the copy.

I agree (but lukewarm on the --super-b idea). :-D

ATB,
Ramsay Jones

Re: What's cooking in git.git (Jul 2017, #09; Mon, 31)

[Ævar Arnfjörð Bjarmason]

On Thu, Aug 03 2017, Junio C. Hamano jotted:

> Sahil Dua <sahildua2305@gmail.com> writes:
>
>> Ah! I had skipped this reply from Ramsay earlier.
>>
>> On Tue, Aug 1, 2017 at 1:36 AM, Ramsay Jones
>> ...
>>>>  I personally do not think "branch --copy master backup" while on
>>>>  "master" that switches to "backup" is a good UI, and I *will* say
>>>>  "I told you so" when users complain after we merge this down to
>>>>  'master'.
>>>
>>> I wouldn't normally comment on an issue like this because I am
>>> not very good at specifying, designing and evaluating UIs (so
>>> who in their right mind would listen to me). ;-)
>>>
>>> FWIW, I suspect that I would not like using this interface either
>>> and would, therefore, not use it.
>>
>> Does that mean you'd use it when "branch --copy feature-branch
>> new-feature-branch" in the case when you would want to start working
>> on a new branch (to modify or experiment with your current feature
>> branch) on top of a branch keeping intact all the configuration and
>> logs?
>
> I am not Ramsay, but your choice of branch names in your question,
> i.e. "branch --copy feature new-feature", is what we do not agree
> with in the first place, especially when we are *on* the "feature"
> branch.
>
> We view "copy A B" as a way to make a back-up of A in B.  I.e. We
> want to keep working on A, but just in case we screw up badly, make
> a backup copy of A in B, so that we can recover by a "branch --move
> B A" later if needed.  So touching B is the last thing we want to do
> after "copy A B" operation---hence we do not want to switch to B.
>
> That is not to say that you are wrong to wish to create a new
> branch, check it out and start working on it with a single command.
> We already have such a command all Git users are accustomed to,
> which is "git checkout -b new-feature-branch feature-branch".
>
> That existing command does not copy things other than the commit
> object name from "feature-branch", and I do not think it should by
> default.  But I do not think it is wrong to extend it with a new
> option (think of it as "checkout --super-b" ;-) to copy other things
> like branch descriptions etc.
>
> So from that point of view, your new feature conceptually fits a lot
> better to "git checkout", and does not belong to "git branch".  That
> is why I do not think "git branch --copy A B" while you are on A
> should check out B after creating the copy.

We've talked how this UX should look before on-list. Rather than
re-hashing the arguments I had before I thought it was useful to present
it as a table. Here's how the patch looks now:

    |----------------------------+--------------+-------+---------+-----------------+-------------|
    | cmd                        | creates new? | moves | copies? | ...with config? | checks out? |
    |----------------------------+--------------+-------+---------+-----------------+-------------|
    | branch <name>              | Y            | N     | N       | N               | N           |
    | checkout <name>            | Y            | N     | N       | N               | Y           |
    | checkout -b <name> <start> | Y            | N     | Y       | N               | Y           |
    | branch -m <name>           | Y            | Y     | N       | Y               | Y           |
    | NEW: branch -c <name>      | Y            | N     | Y       | Y               | Y           |
    |----------------------------+--------------+-------+---------+-----------------+-------------|

In previous discussion my understanding was that you preferred the
following (as an ad-hoc word-diff)

    |----------------------------+--------------+-------+---------+-----------------+-------------|
    | cmd                        | creates new? | moves | copies? | ...with config? | checks out? |
    [... stuff above this point is the same ...]
    | NEW: branch -c <name>      | Y            | N     | Y       | Y               | {-Y, +N}    |
    |----------------------------+--------------+-------+---------+-----------------+-------------|

I.e. have "branch -c <name>" but just make it not checkout the new
thing. What you're describing above sounds to me like:

    |-------------------------------------------+--------------+-------+---------+-----------------+-------------|
    | cmd                                       | creates new? | moves | copies? | ...with config? | checks out? |
    [... stuff above this point is the same ...]
    | branch -m <name>                          | Y            | Y     | N       | Y               | Y           |
    [... so is branch -m but included for context ...]
    | NEW: checkout --super-b -b <name> <start> | Y            | N     | Y       | Y               | Y           |
    |-------------------------------------------+--------------+-------+---------+-----------------+-------------|

As (IIRC) noted in some earlier mail of mine: I don't disagree with what
you're suggesting, and this horror of a checkout/branch UX is not
something anyone would have made from scratch with the benefit of
hindsight.

However we have 2x commands that checkout branches now and do some
combination of creating, moving and copying them (with & without
config).

I think given that we have "branch -m <name>" already introducing a
"branch -c <name>" that does exactly the same thing except "leaves old
name behind" was the simplest thing both in terms of explaining it to
users and to implement, since all the code except removing the old
config section will be shared with "branch -m".

But having this "checkout --super-b -b <name> <start>" would make the UX
even uglier, since now we have a command that does 99% of what "branch
-m <name>" does, but is invoked differently.

I think this end state would make more sense:

    |----------------------------------------+--------------+-------+---------+-----------------+-------------|
    | cmd                                    | creates new? | moves | copies? | ...with config? | checks out? |
    |----------------------------------------+--------------+-------+---------+-----------------+-------------|
    | branch <name>                          | Y            | N     | N       | N               | N           |
    | checkout <name>                        | Y            | N     | N       | N               | Y           |
    | checkout -b <name> <start>             | Y            | N     | Y       | N               | Y           |
    | DEPRECATED (WARNS): branch -m <name>   | Y            | Y     | N       | Y               | Y           |
    | NEW: checkout --move -b <name> <start> | Y            | Y     | N       | Y               | Y           |
    | NEW: checkout --copy -b <name> <start> | Y            | N     | Y       | Y               | Y           |
    |----------------------------------------+--------------+-------+---------+-----------------+-------------|

I.e. let's just move this functionality to "git checkout" and deprecate
"branch -m" (which we could alias to begin with to checkout --move".

I think *that* would make sense, but not the half-assed solution of
moving a new checkout command to git-checkout while we have an analogous
checkout command in git-branch without being deprecated.

Re: What's cooking in git.git (Jul 2017, #09; Mon, 31)

[Junio C Hamano]

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

> We've talked how this UX should look before on-list. Rather than
> re-hashing the arguments I had before I thought it was useful to present
> it as a table. Here's how the patch looks now:
>
>     |----------------------------+--------------+-------+---------+-----------------+-------------|
>     | cmd                        | creates new? | moves | copies? | ...with config? | checks out? |
>     |----------------------------+--------------+-------+---------+-----------------+-------------|
>     | branch <name>              | Y            | N     | N       | N               | N           |
>     | checkout <name>            | Y            | N     | N       | N               | Y           |
>     | checkout -b <name> <start> | Y            | N     | Y       | N               | Y           |
>     | branch -m <name>           | Y            | Y     | N       | Y               | Y           |
>     | NEW: branch -c <name>      | Y            | N     | Y       | Y               | Y           |
>     |----------------------------+--------------+-------+---------+-----------------+-------------|

I actually consider "branch" to *never* invoking a checkout.  Even
when "git branch -m A B" happens to be done when your checked out
branch is A and you end up being on B.  That is not a "checkout".

Really from the end-user's point of view that is not a checkout.
The user renamed the branch A and the same conceptual entity, which
is a branch, is now called B.  If that branch was what was checked
out (IOW, if that branch was what would be grown by one commit if
the user did "git commit"), then now that branch's name is B.  It is
natural if you ask "symbolic-ref HEAD" what branch is checked out
after renaming A to B (and A happened to be what was checked out),
the answer chould be B.

It's like the city you live in changed the name of the street your
house is on.  You do not call movers, you do not do anything, but
your address changes.

> I.e. have "branch -c <name>" but just make it not checkout the new
> thing. What you're describing above sounds to me like:
>
>     |-------------------------------------------+--------------+-------+---------+-----------------+-------------|
>     | cmd                                       | creates new? | moves | copies? | ...with config? | checks out? |
>     [... stuff above this point is the same ...]
>     | branch -m <name>                          | Y            | Y     | N       | Y               | Y           |
>     [... so is branch -m but included for context ...]
>     | NEW: checkout --super-b -b <name> <start> | Y            | N     | Y       | Y               | Y           |
>     |-------------------------------------------+--------------+-------+---------+-----------------+-------------|

You are talking backwards.  I do not want "branch -c A B", even when
A happens to be what is checked out, to check out branch B.  You and
Sahil were who wanted to check out branch B while doing so, and I
just tried to guess why you two wanted to have such a behaviour that
did not make much sense to me.  And my guess was "perhaps they want
a way to create a new branch starting from another branch, and check
it out, and do so in a single end-user operation".  

I am not particulary interested in such an operation; in my guess,
you two are.  And the "super-b" thing was a suggestion to you two:
If you so desperately want such an operation, then don't make
"branch --copy A B" that operation.  Such an operation better fits
in "checkout", not "branch".

If you are not interested in such an operation, then that is fine.
Do not add the "super-b" mode to "checkout".

But I won't defend a "branch --copy A B" that checks out B when
users and other people like Ramsay think that such a behaviour is
illogical, because I do think it is, too.

Re: What's cooking in git.git (Jul 2017, #09; Mon, 31)

[Ævar Arnfjörð Bjarmason]

On Sat, Aug 05 2017, Junio C. Hamano jotted:

> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
>> We've talked how this UX should look before on-list. Rather than
>> re-hashing the arguments I had before I thought it was useful to present
>> it as a table. Here's how the patch looks now:
>>
>>     |----------------------------+--------------+-------+---------+-----------------+-------------|
>>     | cmd                        | creates new? | moves | copies? | ...with config? | checks out? |
>>     |----------------------------+--------------+-------+---------+-----------------+-------------|
>>     | branch <name>              | Y            | N     | N       | N               | N           |
>>     | checkout <name>            | Y            | N     | N       | N               | Y           |
>>     | checkout -b <name> <start> | Y            | N     | Y       | N               | Y           |
>>     | branch -m <name>           | Y            | Y     | N       | Y               | Y           |
>>     | NEW: branch -c <name>      | Y            | N     | Y       | Y               | Y           |
>>     |----------------------------+--------------+-------+---------+-----------------+-------------|
>
> I actually consider "branch" to *never* invoking a checkout.  Even
> when "git branch -m A B" happens to be done when your checked out
> branch is A and you end up being on B.  That is not a "checkout".

I think we just have a different mental model of what "checkout"
means. In my mind any operation that updates the HEAD to point to a new
branch is a checkout of that branch.

In the interest of explaining what I mean with the above and not proving
you wrong or whatever, consider a basic implementation of git before
pack-refs or whatever.

You could then copy a branch name like:

    $ cp .git/refs/heads/{master,master-copy}

Get your currently checked out branch with:

    $ cat .git/HEAD
    ref: refs/heads/master

And you could then implement "git checkout" like:

    $ echo "ref: refs/heads/master-copy" >.git/HEAD

This still works today. Now if I make a commit it goes on the
.git/refs/heads/master-copy branch.

Now let's say I wanted to rename the 'master' branch. This would rename
it:

    $ mv .git/refs/heads/{master,trunk}

But it wouldn't check it out, my HEAD would still point to master:

    $ git log
    fatal: your current branch 'master' does not have any commits yet
    $ git log --oneline -1 trunk
    8b18718 (trunk) moo

To check it out I need:

    $ echo "ref: refs/heads/trunk" >.git/HEAD

Which yields:

    $ git log --oneline -1 HEAD
    8b18718 (HEAD -> trunk) moo

The mv sans the "echo" is what we'd get if we did:

    diff --git a/builtin/branch.c b/builtin/branch.c
    index 8a0595e115..62ed1a8e20 100644
    --- a/builtin/branch.c
    +++ b/builtin/branch.c
    @@ -493,9 +493,6 @@ static void rename_branch(const char *oldname, const char *newname, int force)
            if (recovery)
                    warning(_("Renamed a misnamed branch '%s' away"), oldref.buf + 11);

    -       if (replace_each_worktree_head_symref(oldref.buf, newref.buf, logmsg.buf))
    -               die(_("Branch renamed to %s, but HEAD is not updated!"), newname);
    -
            strbuf_release(&logmsg);

            strbuf_addf(&oldsection, "branch.%s", oldref.buf + 11);

I.e. the last step of "git branch -m" is checking out the branch by
updating the HEAD. Now let's compile git like that and rename "master"
to "trunk":

    $ git symbolic-ref HEAD
    refs/heads/master
    $ ./git-branch -m trunk
    $ git symbolic-ref HEAD
    refs/heads/master
    $ git show
    fatal: your current branch 'master' does not have any commits yet

Now let's do the equivalent of that removed
replace_each_worktree_head_symref():

    $ git checkout trunk
    Switched to branch 'trunk'

And voila:

    $ git symbolic-ref HEAD
    refs/heads/trunk

This is why I'm saying that "git branch -m" involves a checkout. Because
it is literally exactly the case that it could be replaced by a
shellscript whose last step is a "git checkout" of the new branch.

Anyway, none of that changes what we /should/ be doing on the fact that
"git branch -m" not updating the HEAD would be rather useless. I just
wanted to explain what I was talking about and why I was talking about
"checkout" in that context.

> Really from the end-user's point of view that is not a checkout.
> The user renamed the branch A and the same conceptual entity, which
> is a branch, is now called B.  If that branch was what was checked
> out (IOW, if that branch was what would be grown by one commit if
> the user did "git commit"), then now that branch's name is B.  It is
> natural if you ask "symbolic-ref HEAD" what branch is checked out
> after renaming A to B (and A happened to be what was checked out),
> the answer chould be B.
>
> It's like the city you live in changed the name of the street your
> house is on.  You do not call movers, you do not do anything, but
> your address changes.

Yeah I see what you mean, although this analogy rapidly breaks down when
you poke at it as shown above. My house (a sha1) can be on any number of
streets and new ones can be added/removed all the time without changing
where my house is at.

>> I.e. have "branch -c <name>" but just make it not checkout the new
>> thing. What you're describing above sounds to me like:
>>
>>     |-------------------------------------------+--------------+-------+---------+-----------------+-------------|
>>     | cmd                                       | creates new? | moves | copies? | ...with config? | checks out? |
>>     [... stuff above this point is the same ...]
>>     | branch -m <name>                          | Y            | Y     | N       | Y               | Y           |
>>     [... so is branch -m but included for context ...]
>>     | NEW: checkout --super-b -b <name> <start> | Y            | N     | Y       | Y               | Y           |
>>     |-------------------------------------------+--------------+-------+---------+-----------------+-------------|
>
> You are talking backwards.  I do not want "branch -c A B", even when
> A happens to be what is checked out, to check out branch B.  You and
> Sahil were who wanted to check out branch B while doing so, and I
> just tried to guess why you two wanted to have such a behaviour that
> did not make much sense to me.  And my guess was "perhaps they want
> a way to create a new branch starting from another branch, and check
> it out, and do so in a single end-user operation".

The use-case is the following. When I hack on e.g. git.git I'm on
"master" with configured upstream info:

    $ git log @{u}..

Because if I don't care about 'master' another shorter way to say:

    $ git checkout -b topic -t origin/master

Is:

    $ git branch -m topic

That's how I start hacking on "topic", now let's say I've submitted that
and want to start on topic-2 after getting feedback:

    # While still on topic
    $ git branch -c topic-2

So it's just a way to get something exactly like -m except the "move &&
checkout" logic is changed to "copy && checkout".

> I am not particulary interested in such an operation; in my guess,
> you two are.  And the "super-b" thing was a suggestion to you two:
> If you so desperately want such an operation, then don't make
> "branch --copy A B" that operation.  Such an operation better fits
> in "checkout", not "branch".

That's arguably another sensible way to do a /subset/ of what 'git
branch -c' does (or something in addition to this patch). But there's
another use-case it won't cover, i.e. the two-arg branch -m/-c
manipulating a branch that HEAD doesn't point to:

    $ git checkout master
    $ git branch -m topic avar/topic

You can now do that with -c to s/move/copy/, but couldn't do this with
checkout unless you wastefully and needlessly updated the working tree.

> If you are not interested in such an operation, then that is fine.
> Do not add the "super-b" mode to "checkout".

Yeah it's not something I'm interested in or have a use-case for,
although I think in the same way we have -t for checkout it might be
sensible to have e.g.:

    $ git checkout -b topic-2 -c topic -t origin/master

Where the new -c or --config-from would mean "...and get the config from
'topic'". Such a name would probably be less confusing than
--super-b[branch?] which to be implies some ongoing hierarchical
relationship.

> But I won't defend a "branch --copy A B" that checks out B when
> users and other people like Ramsay think that such a behaviour is
> illogical, because I do think it is, too.

I just started this from the POV of using branch -m and wanting
something like that which didn't remove the old thing when it was done
as its last step, which seemed easy to implement & explain.

As noted above I think it probably makes sense to also have something
like [--config-from|-c] for checkout, which would have a related but not
exactly the same use-case.

Re: What's cooking in git.git (Jul 2017, #09; Mon, 31)

[Igor Djordjevic]

On 06/08/2017 22:26, Ævar Arnfjörð Bjarmason wrote:
> On Sat, Aug 05 2017, Junio C. Hamano jotted:
>> I actually consider "branch" to *never* invoking a checkout.  Even
>> when "git branch -m A B" happens to be done when your checked out
>> branch is A and you end up being on B.  That is not a "checkout".
> 
> I think we just have a different mental model of what "checkout"
> means. In my mind any operation that updates the HEAD to point to a new
> branch is a checkout of that branch.

If I may, from a side-viewer`s point of view, it seems you`re 
thinking in low-level implementation details, where what Junio 
describes seems more as a high-level, conceptual/end-user`s point of 
view.

Needing to update HEAD reference once we "rename" a branch, too, what 
you consider a "checkout", seems to be required only because branch 
name _is_ the branch reference in Git, so we need to update HEAD to 
point to a new/renamed branch reference -- but it`s still the same 
branch, conceptually.

Documentation for "git-checkout" states that it is used to "*Switch 
branches*...[snip]", and that is not what happens here. 
Implementation-wise it does because we can`t do it differently at the 
moment, but in user`s eyes it`s still the same branch, so no switch 
is made as far as the user is concerned.

In a different implementation, where branches would have permanent 
references other than their names, no HEAD update would be needed as 
the reference would still be the same, no matter the name change, 
making the `git branch -m` situation clear even from your standpoint, 
I`d say.

>> Really from the end-user's point of view that is not a checkout.
>> The user renamed the branch A and the same conceptual entity, which
>> is a branch, is now called B.  If that branch was what was checked
>> out (IOW, if that branch was what would be grown by one commit if
>> the user did "git commit"), then now that branch's name is B.  It is
>> natural if you ask "symbolic-ref HEAD" what branch is checked out
>> after renaming A to B (and A happened to be what was checked out),
>> the answer chould be B.
>>
>> It's like the city you live in changed the name of the street your
>> house is on.  You do not call movers, you do not do anything, but
>> your address changes.
> 
> Yeah I see what you mean, although this analogy rapidly breaks down when
> you poke at it as shown above. My house (a sha1) can be on any number of
> streets and new ones can be added/removed all the time without changing
> where my house is at.

I may be missing something, but I find the house/address analogy a 
good one, actually, as I understood that "house" resembles a branch 
reference HEAD is pointing to, not a sha1.

Even further, and that might be the point of confusion, "house" seems 
to be more like a "permanent branch reference" I mentioned above, 
where your address can change (branch being renamed), but you would 
still be in the same house (HEAD would still point to the same 
permanent branch reference).

If you move to another house, only then would HEAD change to point to 
another (permanent) branch reference (a different house), and that 
would be a checkout.

Yes, it`s not really how it works from the inside, but I think that`s 
irrelevant for the end-user experience :)

> So it's just a way to get something exactly like -m except the "move &&
> checkout" logic is changed to "copy && checkout".
Again, it seems the "checkout" part of "move && checkout" you`re 
talking about is a user-wise unnecessary implementation detail. For 
the user, it`s just a simple "move", staying on the same, but renamed 
branch, thus no branch switching occurred (no "checkout", as per 
documentation).

Regards,
Buga

Re: What's cooking in git.git (Jul 2017, #09; Mon, 31)

[Igor Djordjevic]

On 07/08/2017 23:25, Igor Djordjevic wrote:
> On 06/08/2017 22:26, Ævar Arnfjörð Bjarmason wrote:
>> On Sat, Aug 05 2017, Junio C. Hamano jotted:
>>> I actually consider "branch" to *never* invoking a checkout.  Even
>>> when "git branch -m A B" happens to be done when your checked out
>>> branch is A and you end up being on B.  That is not a "checkout".
>>
>> I think we just have a different mental model of what "checkout"
>> means. In my mind any operation that updates the HEAD to point to a new
>> branch is a checkout of that branch.
> 
> If I may, from a side-viewer`s point of view, it seems you`re 
> thinking in low-level implementation details, where what Junio 
> describes seems more as a high-level, conceptual/end-user`s point of 
> view.
> 
> Needing to update HEAD reference once we "rename" a branch, too, what 
> you consider a "checkout", seems to be required only because branch 
> name _is_ the branch reference in Git, so we need to update HEAD to 
> point to a new/renamed branch reference -- but it`s still the same 
> branch, conceptually.
> 
> Documentation for "git-checkout" states that it is used to "*Switch 
> branches*...[snip]", and that is not what happens here. 
> Implementation-wise it does because we can`t do it differently at the 
> moment, but in user`s eyes it`s still the same branch, so no switch 
> is made as far as the user is concerned.
> 
> In a different implementation, where branches would have permanent 
> references other than their names, no HEAD update would be needed as 
> the reference would still be the same, no matter the name change, 
> making the `git branch -m` situation clear even from your standpoint, 
> I`d say.
> 
>>> Really from the end-user's point of view that is not a checkout.
>>> The user renamed the branch A and the same conceptual entity, which
>>> is a branch, is now called B.  If that branch was what was checked
>>> out (IOW, if that branch was what would be grown by one commit if
>>> the user did "git commit"), then now that branch's name is B.  It is
>>> natural if you ask "symbolic-ref HEAD" what branch is checked out
>>> after renaming A to B (and A happened to be what was checked out),
>>> the answer chould be B.
>>>
>>> It's like the city you live in changed the name of the street your
>>> house is on.  You do not call movers, you do not do anything, but
>>> your address changes.
>>
>> Yeah I see what you mean, although this analogy rapidly breaks down when
>> you poke at it as shown above. My house (a sha1) can be on any number of
>> streets and new ones can be added/removed all the time without changing
>> where my house is at.
> 
> I may be missing something, but I find the house/address analogy a 
> good one, actually, as I understood that "house" resembles a branch 
> reference HEAD is pointing to, not a sha1.
> 
> Even further, and that might be the point of confusion, "house" seems 
> to be more like a "permanent branch reference" I mentioned above, 
> where your address can change (branch being renamed), but you would 
> still be in the same house (HEAD would still point to the same 
> permanent branch reference).
> 
> If you move to another house, only then would HEAD change to point to 
> another (permanent) branch reference (a different house), and that 
> would be a checkout.
> 
> Yes, it`s not really how it works from the inside, but I think that`s 
> irrelevant for the end-user experience :)
> 
>> So it's just a way to get something exactly like -m except the "move &&
>> checkout" logic is changed to "copy && checkout".
>
> Again, it seems the "checkout" part of "move && checkout" you`re 
> talking about is a user-wise unnecessary implementation detail. For 
> the user, it`s just a simple "move", staying on the same, but renamed 
> branch, thus no branch switching occurred (no "checkout", as per 
> documentation).

All this said, having you mentioning the two argument version:

>     $ git checkout master
>     $ git branch -m topic avar/topic

... exactly proves the point that "git branch -m" is not expected to 
involve a checkout, even from implementation perspective. It`s just a 
consequence of needing to update the (now obsolete) reference HEAD 
points to (only) when the branch we`re renaming (moving) is the one 
that is currently checked-out.

> Yeah it's not something I'm interested in or have a use-case for,
> although I think in the same way we have -t for checkout it might be
> sensible to have e.g.:
> 
>     $ git checkout -b topic-2 -c topic -t origin/master
> 
> Where the new -c or --config-from would mean "...and get the config from
> 'topic'". Such a name would probably be less confusing than
> --super-b[branch?] which to be implies some ongoing hierarchical
> relationship.

This, on the other hand, sounds sensible, staying true to the 
existing logic. In the same manner you can do either:

    $ git branch topic -t origin/master
    $ git checkout topic

... or shorter equivalent:

    $ git checkout -b topic -t origin/master

..., you should be able to do:

    $ git branch -c topic topic-2
    $ git checkout topic-2

..., or equivalent:

    $ git checkout -b topic-2 -c topic

..., where "-c" would follow the same (or similar) logic as "-t" does 
now, as you already pointed out :)

p.s. That said, is `git checkout -b topic-2 --move topic` being 
missed now...? :P That one would/could/should actually be expected to 
move (rename) the branch *and* check it out, no matter if HEAD 
currently points to it or not.

Regards,
Buga

Re: What's cooking in git.git (Jul 2017, #09; Mon, 31)

[Ævar Arnfjörð Bjarmason]

On Mon, Aug 07 2017, Igor Djordjevic jotted:

> On 07/08/2017 23:25, Igor Djordjevic wrote:
>> On 06/08/2017 22:26, Ævar Arnfjörð Bjarmason wrote:
>>> On Sat, Aug 05 2017, Junio C. Hamano jotted:
>>>> I actually consider "branch" to *never* invoking a checkout.  Even
>>>> when "git branch -m A B" happens to be done when your checked out
>>>> branch is A and you end up being on B.  That is not a "checkout".
>>>
>>> I think we just have a different mental model of what "checkout"
>>> means. In my mind any operation that updates the HEAD to point to a new
>>> branch is a checkout of that branch.
>>
>> If I may, from a side-viewer`s point of view, it seems you`re
>> thinking in low-level implementation details, where what Junio
>> describes seems more as a high-level, conceptual/end-user`s point of
>> view.

Yeah, I think that's a fair summary. Also I didn't mean to de-rail this
whole thread on what "checkout" really means, just explain what I meant
with previous comments, since there seemed to be confusion about that.

>> Needing to update HEAD reference once we "rename" a branch, too, what
>> you consider a "checkout", seems to be required only because branch
>> name _is_ the branch reference in Git, so we need to update HEAD to
>> point to a new/renamed branch reference -- but it`s still the same
>> branch, conceptually.

It's not *required* we could do one of three things:

 1) Do what we do now, i.e. rename the branch/reflog & check out the new
    name.

 2) Rename the branch/reflog and checkout HEAD^0, i.e. say "the branch
    is now elsewhere, but we haven't moved your commit".

 3) Just not run replace_each_worktree_head_symref() which would end up
 on a branch with no commits, i.e. an orphan branch.

Now, I think 2 & 3 are pretty nonsensical and wouldn't ever propose we
should do that, but it's illustrative that #1 is not some required
inevitability in terms of explaining what's happening with the new name
being checked out (i.e. HEAD being updated).

>> Documentation for "git-checkout" states that it is used to "*Switch
>> branches*...[snip]", and that is not what happens here.

That's just the summary at the top but not the full story of what
git-checkout does. E.g. you can checkout a bare SHA1 which is not
switching branches, or a tag or whatever.

>> Implementation-wise it does because we can`t do it differently at the
>> moment, but in user`s eyes it`s still the same branch, so no switch
>> is made as far as the user is concerned.

Kind of, it's also worthwhile to think about that in some sense no
switch would be performed as far as the user is concerned by taking
option #2, i.e. we'd be in the same working tree / you could still make
commits.

You just couldn't make new commits on your "master" which is now called
"topic" and get new commits on "topic". I think it makes sense to do
that, but again, it's illustrative that it's not inevitable for
discussing the implementation.

>> In a different implementation, where branches would have permanent
>> references other than their names, no HEAD update would be needed as
>> the reference would still be the same, no matter the name change,
>> making the `git branch -m` situation clear even from your standpoint,
>> I`d say.
>>
>>>> Really from the end-user's point of view that is not a checkout.
>>>> The user renamed the branch A and the same conceptual entity, which
>>>> is a branch, is now called B.  If that branch was what was checked
>>>> out (IOW, if that branch was what would be grown by one commit if
>>>> the user did "git commit"), then now that branch's name is B.  It is
>>>> natural if you ask "symbolic-ref HEAD" what branch is checked out
>>>> after renaming A to B (and A happened to be what was checked out),
>>>> the answer chould be B.
>>>>
>>>> It's like the city you live in changed the name of the street your
>>>> house is on.  You do not call movers, you do not do anything, but
>>>> your address changes.
>>>
>>> Yeah I see what you mean, although this analogy rapidly breaks down when
>>> you poke at it as shown above. My house (a sha1) can be on any number of
>>> streets and new ones can be added/removed all the time without changing
>>> where my house is at.
>>
>> I may be missing something, but I find the house/address analogy a
>> good one, actually, as I understood that "house" resembles a branch
>> reference HEAD is pointing to, not a sha1.
>>
>> Even further, and that might be the point of confusion, "house" seems
>> to be more like a "permanent branch reference" I mentioned above,
>> where your address can change (branch being renamed), but you would
>> still be in the same house (HEAD would still point to the same
>> permanent branch reference).
>>
>> If you move to another house, only then would HEAD change to point to
>> another (permanent) branch reference (a different house), and that
>> would be a checkout.

I've yet to see a good real-world analogy of "DAG with labels", which is
all git really is, that doesn't break down at some point. Trees are
probably the best comparison, but even that breaks down in the face of
branch merges or even merges of entirely unrelated trees.

So it's probably pointless to discuss this tangent any further, I don't
think it helps with deciding what to do about this new -c construct.

>> Yes, it`s not really how it works from the inside, but I think that`s
>> irrelevant for the end-user experience :)
>>
>>> So it's just a way to get something exactly like -m except the "move &&
>>> checkout" logic is changed to "copy && checkout".
>>
>> Again, it seems the "checkout" part of "move && checkout" you`re
>> talking about is a user-wise unnecessary implementation detail. For
>> the user, it`s just a simple "move", staying on the same, but renamed
>> branch, thus no branch switching occurred (no "checkout", as per
>> documentation).

Yes I agree that this has little to no impact on what's happening for
the user, I've merely been discussing "checkout" in the terms of what's
happening under the hood here.

> All this said, having you mentioning the two argument version:
>
>>     $ git checkout master
>>     $ git branch -m topic avar/topic
>
> ... exactly proves the point that "git branch -m" is not expected to
> involve a checkout, even from implementation perspective. It`s just a
> consequence of needing to update the (now obsolete) reference HEAD
> points to (only) when the branch we`re renaming (moving) is the one
> that is currently checked-out.

Hrm, I think you're confused about what this example does. For the sake
of avoiding confusion let's stop talking about checkout and just talk
about updating the HEAD.

The point of that example is to show that the HEAD is only updated by
git branch [-m|-c] if the branch being moved/copied is the branch you're
currently on.

Here the user just checked out master and then moved an unrelated topic
to avar/topic, that just manipulates the ref store & config, and won't
touch the HEAD.

The reason I'm mentioning that example (and talking about a "subset") is
that amending git-checkout to do some of what this new "git-branch -c"
option would do would only cover a subset of what it does, since both -m
and -c are two-mode options in the sense that some of the time they
manipulate the refstore and the HEAD, and some of the time only the
refstore.

>> Yeah it's not something I'm interested in or have a use-case for,
>> although I think in the same way we have -t for checkout it might be
>> sensible to have e.g.:
>>
>>     $ git checkout -b topic-2 -c topic -t origin/master
>>
>> Where the new -c or --config-from would mean "...and get the config from
>> 'topic'". Such a name would probably be less confusing than
>> --super-b[branch?] which to be implies some ongoing hierarchical
>> relationship.
>
> This, on the other hand, sounds sensible, staying true to the
> existing logic. In the same manner you can do either:

To continue the explanation above, yeah it's sensible, but I'm pointing
out that it's *also* sensible, i.e. whatever mode git-checkout has for
"let's create a branch with the same start point & config as [some other
branch]" it's always going to be complimentary but not a replacement for
git branch [-m|-c], since [-m|-c] has a mode for doing that without
doing any checkout whatsoever, just manipulating the refstore.

>     $ git branch topic -t origin/master
>     $ git checkout topic
>
> ... or shorter equivalent:
>
>     $ git checkout -b topic -t origin/master
>
> ..., you should be able to do:
>
>     $ git branch -c topic topic-2
>     $ git checkout topic-2
>
> ..., or equivalent:
>
>     $ git checkout -b topic-2 -c topic
>
> ..., where "-c" would follow the same (or similar) logic as "-t" does
> now, as you already pointed out :)
>
> p.s. That said, is `git checkout -b topic-2 --move topic` being
> missed now...? :P That one would/could/should actually be expected to
> move (rename) the branch *and* check it out, no matter if HEAD
> currently points to it or not.
>
> Regards,
> Buga

Re: What's cooking in git.git (Jul 2017, #09; Mon, 31)

[Igor Djordjevic]

On 08/08/2017 15:14, Ævar Arnfjörð Bjarmason wrote:
> On Mon, Aug 07 2017, Igor Djordjevic jotted:
>> On 07/08/2017 23:25, Igor Djordjevic wrote:
>>> On 06/08/2017 22:26, Ævar Arnfjörð Bjarmason wrote:
>>>> On Sat, Aug 05 2017, Junio C. Hamano jotted:
>>>>> I actually consider "branch" to *never* invoking a checkout.  Even
>>>>> when "git branch -m A B" happens to be done when your checked out
>>>>> branch is A and you end up being on B.  That is not a "checkout".
>>>>
>>>> I think we just have a different mental model of what "checkout"
>>>> means. In my mind any operation that updates the HEAD to point to a new
>>>> branch is a checkout of that branch.
>>>
>>> If I may, from a side-viewer`s point of view, it seems you`re
>>> thinking in low-level implementation details, where what Junio
>>> describes seems more as a high-level, conceptual/end-user`s point of
>>> view.
> 
> Yeah, I think that's a fair summary. Also I didn't mean to de-rail this
> whole thread on what "checkout" really means, just explain what I meant
> with previous comments, since there seemed to be confusion about that.
> 
>>> Needing to update HEAD reference once we "rename" a branch, too, what
>>> you consider a "checkout", seems to be required only because branch
>>> name _is_ the branch reference in Git, so we need to update HEAD to
>>> point to a new/renamed branch reference -- but it`s still the same
>>> branch, conceptually.
> 
> It's not *required* we could do one of three things:
> 
>  1) Do what we do now, i.e. rename the branch/reflog & check out the new
>     name.
> 
>  2) Rename the branch/reflog and checkout HEAD^0, i.e. say "the branch
>     is now elsewhere, but we haven't moved your commit".
> 
>  3) Just not run replace_each_worktree_head_symref() which would end up
>  on a branch with no commits, i.e. an orphan branch.
> 
> Now, I think 2 & 3 are pretty nonsensical and wouldn't ever propose we
> should do that, but it's illustrative that #1 is not some required
> inevitability in terms of explaining what's happening with the new name
> being checked out (i.e. HEAD being updated).

I think we agree, but we`re talking from different standpoints again.

You say "it *can* be done *but* it doesn`t make sense", where I say 
"it *can`t* be done *because* it doesn`t make sense".

Implementation wise, of course it can be done differently, but 
conceptually it would be wrong (or confusing, at least), thus 
different implementation, while theoretically possible, may not be a 
sane option, thus it`s impractical (not to say "impossible").

By "required", I really meant "required in order to be conceptually 
sane".

>>> Documentation for "git-checkout" states that it is used to "*Switch
>>> branches*...[snip]", and that is not what happens here.
> 
> That's just the summary at the top but not the full story of what
> git-checkout does. E.g. you can checkout a bare SHA1 which is not
> switching branches, or a tag or whatever.

I disagree, by checking out a bare SHA1 (or tag or whatever) I`d say 
you *are* still switching branches - conceptually, at least.

When you move from a named branch to (yet) unnamed one, you are 
switching branches. Same goes for when you switch from one unnamed 
branch to another (named or unnamed).

Might be "detached HEAD" is not something we call an "unnamed 
branch", but that`s what it practically is.

>>> Implementation-wise it does because we can`t do it differently at the
>>> moment, but in user`s eyes it`s still the same branch, so no switch
>>> is made as far as the user is concerned.
> 
> Kind of, it's also worthwhile to think about that in some sense no
> switch would be performed as far as the user is concerned by taking
> option #2, i.e. we'd be in the same working tree / you could still make
> commits.
> 
> You just couldn't make new commits on your "master" which is now called
> "topic" and get new commits on "topic". I think it makes sense to do
> that, but again, it's illustrative that it's not inevitable for
> discussing the implementation.

But your second paragraph exactly explains why it`s not the same with 
option #2 (I guess you mean "no HEAD update to point to renamed 
branch" here) - if user renames branch "master" to "topic", it`s 
natural to expect that next commit is made on "topic" (which is now a 
new name for "master", conceptually still being the same, just 
renamed branch).

Ending up in limbo, in a detached HEAD state, or even worse, still 
being on a branch with an old name "master" (which conceptually 
shouldn`t exist anymore, being known as "topic" now), would be 
confusing, to say the least, and conceptually wrong, I would add.

>>> In a different implementation, where branches would have permanent
>>> references other than their names, no HEAD update would be needed as
>>> the reference would still be the same, no matter the name change,
>>> making the `git branch -m` situation clear even from your standpoint,
>>> I`d say.
>>>
>>>>> Really from the end-user's point of view that is not a checkout.
>>>>> The user renamed the branch A and the same conceptual entity, which
>>>>> is a branch, is now called B.  If that branch was what was checked
>>>>> out (IOW, if that branch was what would be grown by one commit if
>>>>> the user did "git commit"), then now that branch's name is B.  It is
>>>>> natural if you ask "symbolic-ref HEAD" what branch is checked out
>>>>> after renaming A to B (and A happened to be what was checked out),
>>>>> the answer chould be B.
>>>>>
>>>>> It's like the city you live in changed the name of the street your
>>>>> house is on.  You do not call movers, you do not do anything, but
>>>>> your address changes.
>>>>
>>>> Yeah I see what you mean, although this analogy rapidly breaks down when
>>>> you poke at it as shown above. My house (a sha1) can be on any number of
>>>> streets and new ones can be added/removed all the time without changing
>>>> where my house is at.
>>>
>>> I may be missing something, but I find the house/address analogy a
>>> good one, actually, as I understood that "house" resembles a branch
>>> reference HEAD is pointing to, not a sha1.
>>>
>>> Even further, and that might be the point of confusion, "house" seems
>>> to be more like a "permanent branch reference" I mentioned above,
>>> where your address can change (branch being renamed), but you would
>>> still be in the same house (HEAD would still point to the same
>>> permanent branch reference).
>>>
>>> If you move to another house, only then would HEAD change to point to
>>> another (permanent) branch reference (a different house), and that
>>> would be a checkout.
> 
> I've yet to see a good real-world analogy of "DAG with labels", which is
> all git really is, that doesn't break down at some point. Trees are
> probably the best comparison, but even that breaks down in the face of
> branch merges or even merges of entirely unrelated trees.
> 
> So it's probably pointless to discuss this tangent any further, I don't
> think it helps with deciding what to do about this new -c construct.
> 
>>> Yes, it`s not really how it works from the inside, but I think that`s
>>> irrelevant for the end-user experience :)
>>>
>>>> So it's just a way to get something exactly like -m except the "move &&
>>>> checkout" logic is changed to "copy && checkout".
>>>
>>> Again, it seems the "checkout" part of "move && checkout" you`re
>>> talking about is a user-wise unnecessary implementation detail. For
>>> the user, it`s just a simple "move", staying on the same, but renamed
>>> branch, thus no branch switching occurred (no "checkout", as per
>>> documentation).
> 
> Yes I agree that this has little to no impact on what's happening for
> the user, I've merely been discussing "checkout" in the terms of what's
> happening under the hood here.
> 
>> All this said, having you mentioning the two argument version:
>>
>>>     $ git checkout master
>>>     $ git branch -m topic avar/topic
>>
>> ... exactly proves the point that "git branch -m" is not expected to
>> involve a checkout, even from implementation perspective. It`s just a
>> consequence of needing to update the (now obsolete) reference HEAD
>> points to (only) when the branch we`re renaming (moving) is the one
>> that is currently checked-out.
> 
> Hrm, I think you're confused about what this example does. For the sake
> of avoiding confusion let's stop talking about checkout and just talk
> about updating the HEAD.
> 
> The point of that example is to show that the HEAD is only updated by
> git branch [-m|-c] if the branch being moved/copied is the branch you're
> currently on.
> 
> Here the user just checked out master and then moved an unrelated topic
> to avar/topic, that just manipulates the ref store & config, and won't
> touch the HEAD.
> 
> The reason I'm mentioning that example (and talking about a "subset") is
> that amending git-checkout to do some of what this new "git-branch -c"
> option would do would only cover a subset of what it does, since both -m
> and -c are two-mode options in the sense that some of the time they
> manipulate the refstore and the HEAD, and some of the time only the
> refstore.

I think we agree here, up to a point. I just wanted to take your 
example in a different direction, obviously not being successful 
enough with my goal :)

Implementation wise, we agree completely.

Conceptually, "branch" manipulates HEAD only to update an invalidated 
reference HEAD would otherwise still point to (being a dangling 
pointer now), updating it only as much as needed to still point to 
the same entity (branch), but having a different name now (thus a 
different reference, which is implementation detail). It doesn`t do 
checkout in terms of "switching branches".

On the other hand, "checkout" is expected to manipulate HEAD to 
"switch branches" (named or "unnamed", detached head etc., as argued 
above).

>>> Yeah it's not something I'm interested in or have a use-case for,
>>> although I think in the same way we have -t for checkout it might be
>>> sensible to have e.g.:
>>>
>>>     $ git checkout -b topic-2 -c topic -t origin/master
>>>
>>> Where the new -c or --config-from would mean "...and get the config from
>>> 'topic'". Such a name would probably be less confusing than
>>> --super-b[branch?] which to be implies some ongoing hierarchical
>>> relationship.
>>
>> This, on the other hand, sounds sensible, staying true to the
>> existing logic. In the same manner you can do either:
> 
> To continue the explanation above, yeah it's sensible, but I'm pointing
> out that it's *also* sensible, i.e. whatever mode git-checkout has for
> "let's create a branch with the same start point & config as [some other
> branch]" it's always going to be complimentary but not a replacement for
> git branch [-m|-c], since [-m|-c] has a mode for doing that without
> doing any checkout whatsoever, just manipulating the refstore.

Might be it didn`t read like that, but I actually agreed with you 
here completely :)

My point was exactly to say that "branch" and "checkout" [-m|-c] 
should exist one next to the other, where "checkout" also switches 
branches, and "branch" does not...

... which brings us to the very first point this whole discussion was 
started about, I think, whether "branch" should "switch branches" or 
not, and it seems the conclusion would be "no, it should not" :)

Yes, "branch" can update HEAD in case of a renamed branch, but 
conceptually, that`s not "branch switching" - but if you really want 
to "switch" to a newly created branch right away in a single command 
("new branch" not being renamed existing named or unnamed branch, but 
a genuinely new entity), "checkout" would be the tool for the job.

>>     $ git branch topic -t origin/master
>>     $ git checkout topic
>>
>> ... or shorter equivalent:
>>
>>     $ git checkout -b topic -t origin/master
>>
>> ..., you should be able to do:
>>
>>     $ git branch -c topic topic-2
>>     $ git checkout topic-2
>>
>> ..., or equivalent:
>>
>>     $ git checkout -b topic-2 -c topic
>>
>> ..., where "-c" would follow the same (or similar) logic as "-t" does
>> now, as you already pointed out :)
>>
>> p.s. That said, is `git checkout -b topic-2 --move topic` being
>> missed now...? :P That one would/could/should actually be expected to
>> move (rename) the branch *and* check it out, no matter if HEAD
>> currently points to it or not.
>>
>> Regards,
>> Buga