* What's cooking in git.git (Jul 2017, #09; Mon, 31) @ 2017-07-31 22:30 Junio C Hamano 2017-07-31 23:36 ` Ramsay Jones 2017-08-03 20:17 ` Sahil Dua 0 siblings, 2 replies; 15+ messages in thread From: Junio C Hamano @ 2017-07-31 22:30 UTC (permalink / raw) To: git 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: What's cooking in git.git (Jul 2017, #09; Mon, 31) 2017-07-31 22:30 What's cooking in git.git (Jul 2017, #09; Mon, 31) Junio C Hamano @ 2017-07-31 23:36 ` Ramsay Jones 2017-08-03 20:26 ` Sahil Dua 2017-08-03 20:17 ` Sahil Dua 1 sibling, 1 reply; 15+ messages in thread From: Ramsay Jones @ 2017-07-31 23:36 UTC (permalink / raw) To: Junio C Hamano, git 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: What's cooking in git.git (Jul 2017, #09; Mon, 31) 2017-07-31 23:36 ` Ramsay Jones @ 2017-08-03 20:26 ` Sahil Dua 2017-08-03 21:07 ` Junio C Hamano 0 siblings, 1 reply; 15+ messages in thread From: Sahil Dua @ 2017-08-03 20:26 UTC (permalink / raw) To: Ramsay Jones; +Cc: Junio C Hamano, Git Mailing List 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 > > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: What's cooking in git.git (Jul 2017, #09; Mon, 31) 2017-08-03 20:26 ` Sahil Dua @ 2017-08-03 21:07 ` Junio C Hamano 2017-08-03 22:20 ` Ramsay Jones 2017-08-05 20:34 ` Ævar Arnfjörð Bjarmason 0 siblings, 2 replies; 15+ messages in thread From: Junio C Hamano @ 2017-08-03 21:07 UTC (permalink / raw) To: Sahil Dua; +Cc: Ramsay Jones, Git Mailing List 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: What's cooking in git.git (Jul 2017, #09; Mon, 31) 2017-08-03 21:07 ` Junio C Hamano @ 2017-08-03 22:20 ` Ramsay Jones 2017-08-05 20:34 ` Ævar Arnfjörð Bjarmason 1 sibling, 0 replies; 15+ messages in thread From: Ramsay Jones @ 2017-08-03 22:20 UTC (permalink / raw) To: Junio C Hamano, Sahil Dua; +Cc: Git Mailing List 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: What's cooking in git.git (Jul 2017, #09; Mon, 31) 2017-08-03 21:07 ` Junio C Hamano 2017-08-03 22:20 ` Ramsay Jones @ 2017-08-05 20:34 ` Ævar Arnfjörð Bjarmason 2017-08-05 22:37 ` Junio C Hamano 1 sibling, 1 reply; 15+ messages in thread From: Ævar Arnfjörð Bjarmason @ 2017-08-05 20:34 UTC (permalink / raw) To: Junio C Hamano; +Cc: Sahil Dua, Ramsay Jones, Git Mailing List 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: What's cooking in git.git (Jul 2017, #09; Mon, 31) 2017-08-05 20:34 ` Ævar Arnfjörð Bjarmason @ 2017-08-05 22:37 ` Junio C Hamano 2017-08-06 20:26 ` Ævar Arnfjörð Bjarmason 0 siblings, 1 reply; 15+ messages in thread From: Junio C Hamano @ 2017-08-05 22:37 UTC (permalink / raw) To: Ævar Arnfjörð Bjarmason Cc: Sahil Dua, Ramsay Jones, Git Mailing List Æ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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: What's cooking in git.git (Jul 2017, #09; Mon, 31) 2017-08-05 22:37 ` Junio C Hamano @ 2017-08-06 20:26 ` Ævar Arnfjörð Bjarmason 2017-08-07 21:25 ` Igor Djordjevic 0 siblings, 1 reply; 15+ messages in thread From: Ævar Arnfjörð Bjarmason @ 2017-08-06 20:26 UTC (permalink / raw) To: Junio C Hamano; +Cc: Sahil Dua, Ramsay Jones, Git Mailing List 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: What's cooking in git.git (Jul 2017, #09; Mon, 31) 2017-08-06 20:26 ` Ævar Arnfjörð Bjarmason @ 2017-08-07 21:25 ` Igor Djordjevic 2017-08-07 22:20 ` Igor Djordjevic 0 siblings, 1 reply; 15+ messages in thread From: Igor Djordjevic @ 2017-08-07 21:25 UTC (permalink / raw) To: Ævar Arnfjörð Bjarmason, Junio C Hamano Cc: Sahil Dua, Ramsay Jones, Git Mailing List 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: What's cooking in git.git (Jul 2017, #09; Mon, 31) 2017-08-07 21:25 ` Igor Djordjevic @ 2017-08-07 22:20 ` Igor Djordjevic 2017-08-08 13:14 ` Ævar Arnfjörð Bjarmason 0 siblings, 1 reply; 15+ messages in thread From: Igor Djordjevic @ 2017-08-07 22:20 UTC (permalink / raw) To: Ævar Arnfjörð Bjarmason, Junio C Hamano Cc: Sahil Dua, Ramsay Jones, Git Mailing List 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: What's cooking in git.git (Jul 2017, #09; Mon, 31) 2017-08-07 22:20 ` Igor Djordjevic @ 2017-08-08 13:14 ` Ævar Arnfjörð Bjarmason 2017-08-08 18:55 ` Igor Djordjevic 0 siblings, 1 reply; 15+ messages in thread From: Ævar Arnfjörð Bjarmason @ 2017-08-08 13:14 UTC (permalink / raw) To: Igor Djordjevic; +Cc: Junio C Hamano, Sahil Dua, Ramsay Jones, Git Mailing List 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: What's cooking in git.git (Jul 2017, #09; Mon, 31) 2017-08-08 13:14 ` Ævar Arnfjörð Bjarmason @ 2017-08-08 18:55 ` Igor Djordjevic 0 siblings, 0 replies; 15+ messages in thread From: Igor Djordjevic @ 2017-08-08 18:55 UTC (permalink / raw) To: Ævar Arnfjörð Bjarmason Cc: Junio C Hamano, Sahil Dua, Ramsay Jones, Git Mailing List 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: What's cooking in git.git (Jul 2017, #09; Mon, 31) 2017-07-31 22:30 What's cooking in git.git (Jul 2017, #09; Mon, 31) Junio C Hamano 2017-07-31 23:36 ` Ramsay Jones @ 2017-08-03 20:17 ` Sahil Dua 2017-08-03 20:23 ` Stefan Beller 2017-08-03 21:17 ` Junio C Hamano 1 sibling, 2 replies; 15+ messages in thread From: Sahil Dua @ 2017-08-03 20:17 UTC (permalink / raw) To: Junio C Hamano; +Cc: Git Mailing List > > * 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'. > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: What's cooking in git.git (Jul 2017, #09; Mon, 31) 2017-08-03 20:17 ` Sahil Dua @ 2017-08-03 20:23 ` Stefan Beller 2017-08-03 21:17 ` Junio C Hamano 1 sibling, 0 replies; 15+ messages in thread From: Stefan Beller @ 2017-08-03 20:23 UTC (permalink / raw) To: Sahil Dua; +Cc: Junio C Hamano, Git Mailing List 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: What's cooking in git.git (Jul 2017, #09; Mon, 31) 2017-08-03 20:17 ` Sahil Dua 2017-08-03 20:23 ` Stefan Beller @ 2017-08-03 21:17 ` Junio C Hamano 1 sibling, 0 replies; 15+ messages in thread From: Junio C Hamano @ 2017-08-03 21:17 UTC (permalink / raw) To: Sahil Dua; +Cc: Git Mailing List 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2017-08-08 18:55 UTC | newest] Thread overview: 15+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-07-31 22:30 What's cooking in git.git (Jul 2017, #09; Mon, 31) Junio C Hamano 2017-07-31 23:36 ` Ramsay Jones 2017-08-03 20:26 ` Sahil Dua 2017-08-03 21:07 ` Junio C Hamano 2017-08-03 22:20 ` Ramsay Jones 2017-08-05 20:34 ` Ævar Arnfjörð Bjarmason 2017-08-05 22:37 ` Junio C Hamano 2017-08-06 20:26 ` Ævar Arnfjörð Bjarmason 2017-08-07 21:25 ` Igor Djordjevic 2017-08-07 22:20 ` Igor Djordjevic 2017-08-08 13:14 ` Ævar Arnfjörð Bjarmason 2017-08-08 18:55 ` Igor Djordjevic 2017-08-03 20:17 ` Sahil Dua 2017-08-03 20:23 ` Stefan Beller 2017-08-03 21:17 ` Junio C Hamano
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).