{"thread":{"id":"33517","subject":"What's cooking in git.git (Apr 2013, #05; Mon, 15)","startedAt":"2013-04-15T20:28:53Z","lastAt":"2013-04-26T21:30:43Z","messageCount":85,"participants":["Junio C Hamano","Felipe Contreras","Jeff King","Øyvind A. Holm","Eric Sunshine","Drew Northup","Thomas Rast","Phil Hord","John Keeping","Lukas Fleischer","Jens Lehmann","Matthieu Moy","Ramkumar Ramachandra","Jonathan Nieder"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"214383","messageId":"7vhaj7r116.fsf@alter.siamese.dyndns.org","threadId":"33517","inReplyTo":null,"subject":"What's cooking in git.git (Apr 2013, #05; Mon, 15)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-15T20:28:53Z","receivedAt":"2013-04-15T20:28:53Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Here are the topics that have been cooking. Commits prefixed with\n'-' are only in 'pu' (proposed updates) while commits prefixed with\n'+' are in 'next'.\n\nYou can find the changes described here in the integration branches\nof the repositories listed at\n\n http://git-blame.blogspot.com/p/git-public-repositories.html\n\n--------------------------------------------------\n[Graduated to \"master\"]\n\n* jk/diff-algo-finishing-touches (2013-04-05) 2 commits\n (merged to 'next' on 2013-04-11 at af83b2b)\n + diff: allow unstuck arguments with --diff-algorithm\n + git-merge(1): document diff-algorithm option to merge-recursive\n\n \"git diff --diff-algorithm algo\" is also understood as \"git diff\n --diff-algorithm=algo\".\n\n\n* jk/diff-graph-submodule-summary (2013-04-05) 1 commit\n (merged to 'next' on 2013-04-11 at 70dfa8d)\n + submodule: print graph output next to submodule log\n\n Make \"git diff --graph\" work better with submodule log output.\n\n\n* jk/http-error-messages (2013-04-06) 9 commits\n (merged to 'next' on 2013-04-11 at 7a03981)\n + http: drop http_error function\n + remote-curl: die directly with http error messages\n + http: re-word http error message\n + http: simplify http_error helper function\n + remote-curl: consistently report repo url for http errors\n + remote-curl: always show friendlier 404 message\n + remote-curl: let servers override http 404 advice\n + remote-curl: show server content on http errors\n + http: add HTTP_KEEP_ERROR option\n\n Improve error reporting from the http transfer clients.\n\n\n* jk/show-branch-strbuf (2013-04-06) 1 commit\n (merged to 'next' on 2013-04-11 at 7a20aa5)\n + show-branch: use strbuf instead of static buffer\n\n \"git show-branch\" was not prepared to show a very long run of\n ancestor operators e.g. foobar^2~2^2^2^2...^2~4 correctly.\n\n\n* lf/bundle-with-tip-wo-message (2013-04-07) 1 commit\n (merged to 'next' on 2013-04-11 at bb9f869)\n + bundle: Accept prerequisites without commit messages\n\n \"git bundle\" did not like a bundle created using a commit without\n any message as its one of the prerequistes.\n\n\n* po/help-guides (2013-04-03) 5 commits\n (merged to 'next' on 2013-04-04 at 3d99b28)\n + doc: include --guide option description for \"git help\"\n + help: mention -a and -g option, and 'git help ' usage.\n + builtin/help.c: add list_common_guides_help() function\n + builtin/help.c: add --guide option\n + builtin/help.c: split \"-a\" processing into two\n\n \"git help\" learned \"-g\" option to show the list of guides just like\n list of commands are given with \"-a\".\n * po/help-guides (2013-04-12) 1 commit\n - help: mark common_guides[] as translatable\n\n Finishing touches.\n\n\n* rt/commentchar-fmt-merge-msg (2013-04-07) 2 commits\n (merged to 'next' on 2013-04-11 at 6af638b)\n + fmt-merge-msg: use core.commentchar in tag signatures completely\n + fmt-merge-msg: respect core.commentchar in people credits\n\n The new core.commentchar configuration was not applied to a few\n places.\n\n\n* tr/perl-keep-stderr-open (2013-04-04) 2 commits\n (merged to 'next' on 2013-04-07 at 04f737a)\n + t9700: do not close STDERR\n + perl: redirect stderr to /dev/null instead of closing\n\n Closing (not redirecting to /dev/null) the standard error stream is\n not a very smart thing to do. Later open may return file\n descriptor #2 for unrelated purpose, and error reporting code may\n write into them.\n\n--------------------------------------------------\n[New Topics]\n\n* kb/status-ignored-optim-2 (2013-04-15) 14 commits\n . dir.c: git-status --ignored: don't scan the work tree twice\n . dir.c: git-status --ignored: don't scan the work tree three times\n . dir.c: git-status: avoid is_excluded checks for tracked files\n . dir.c: replace is_path_excluded with now equivalent is_excluded API\n . dir.c: unify is_excluded and is_path_excluded APIs\n . dir.c: move prep_exclude\n . dir.c: factor out parts of last_exclude_matching for later reuse\n . dir.c: git-clean -d -X: don't delete tracked directories\n . dir.c: make 'git-status --ignored' work within leading directories\n . dir.c: git-status --ignored: don't list empty directories as ignored\n . dir.c: git-ls-files --directories: don't hide empty directories\n . dir.c: git-status --ignored: don't list empty ignored directories\n . dir.c: git-status --ignored: don't list files in ignored directories\n . dir.c: git-status --ignored: don't drop ignored directories\n\n Rerolls kb/status-ignored-optim topic (reverted from 'next'). Not\n merged to 'pu' as it heavily interferes with as/check-ignore topic.\n\n\n* fc/branch-upstream-color (2013-04-15) 1 commit\n (merged to 'next' on 2013-04-15 at 2fc50fd)\n + branch: colour upstream branches\n\n Add more colors to \"git branch -vv\" output.\n\n Will merge to 'master'.\n\n\n* jk/commit-info-slab (2013-04-13) 3 commits\n - commit-slab: introduce a macro to define a slab for new type\n - commit-slab: avoid large realloc\n - commit: allow associating auxiliary info on-demand\n\n Technology demonstration to show a way we could use unbound number\n of flag bits on commit objects.\n\n\n* jk/test-trash (2013-04-14) 2 commits\n (merged to 'next' on 2013-04-15 at 15a6624)\n + t/test-lib.sh: drop \"$test\" variable\n + t/test-lib.sh: fix TRASH_DIRECTORY handling\n\n Fix longstanding issues with the test harness when used with --root=\n option.\n\n\n* lf/read-blob-data-from-index (2013-04-15) 3 commits\n (merged to 'next' on 2013-04-15 at 09f92c6)\n + convert.c: Remove duplicate code\n + Add size parameter to read_blob_data_from_index_path()\n + Add public function read_blob_data_from_index_path()\n\n Reduce duplicated code between convert.c and attr.c.\n\n Will merge to 'master'.\n\n\n* mv/ssl-ftp-curl (2013-04-12) 1 commit\n (merged to 'next' on 2013-04-15 at 7fdada6)\n + Support FTP-over-SSL/TLS for regular FTP\n\n Does anybody really use commit walkers over ftp???\n\n Will merge to 'master'.\n\n\n* as/check-ignore (2013-04-11) 5 commits\n - Documentation: add caveats about I/O buffering for check-{attr,ignore}\n - check-ignore: allow incremental streaming of queries via --stdin\n - check-ignore: move setup into cmd_check_ignore()\n - check-ignore: add -n / --non-matching option\n - t0008: remove duplicated test fixture data\n\n Enhance \"check-ignore\" (1.8.2 update) to work more like \"check-attr\"\n over bidi-pipes.\n\n\n* mh/packed-refs-various (2013-04-15) 33 commits\n - refs: handle the main ref_cache specially\n - refs: change do_for_each_*() functions to take ref_cache arguments\n - pack_one_ref(): do some cheap tests before a more expensive one\n - pack_one_ref(): use write_packed_entry() to do the writing\n - pack_one_ref(): use function peel_entry()\n - refs: inline function do_not_prune()\n - pack_refs(): change to use do_for_each_entry()\n - refs: use same lock_file object for both ref-packing functions\n - pack_one_ref(): rename \"path\" parameter to \"refname\"\n - pack-refs: merge code from pack-refs.{c,h} into refs.{c,h}\n - pack-refs: rename handle_one_ref() to pack_one_ref()\n - refs: extract a function write_packed_entry()\n - repack_without_ref(): write peeled refs in the rewritten file\n - t3211: demonstrate loss of peeled refs if a packed ref is deleted\n - refs: change how packed refs are deleted\n - search_ref_dir(): return an index rather than a pointer\n - repack_without_ref(): silence errors for dangling packed refs\n - t3210: test for spurious error messages for dangling packed refs\n - refs: change the internal reference-iteration API\n - refs: extract a function peel_entry()\n - peel_ref(): fix return value for non-peelable, not-current reference\n - peel_object(): give more specific information in return value\n - refs: extract function peel_object()\n - refs: extract a function ref_resolves_to_object()\n - repack_without_ref(): use function get_packed_ref()\n - peel_ref(): use function get_packed_ref()\n - get_packed_ref(): return a ref_entry\n - do_for_each_ref_in_dirs(): remove dead code\n - refs: define constant PEELED_LINE_LENGTH\n - refs: document how current_ref is used\n - refs: document do_for_each_ref() and do_one_ref()\n - refs: document the fields of struct ref_value\n - refs: document flags constants REF_*\n\n Updates reading and updating packed-refs file, correcting corner\n case bugs.\n\n\n* jk/remote-helper-with-signed-tags (2013-04-15) 3 commits\n - transport-helper: add 'signed-tags' capability\n - transport-helper: pass --signed-tags=warn-strip to fast-export\n - fast-export: add --signed-tags=warn-strip mode\n\n Allows remote-helpers to declare they can handle signed tags, and\n issue a warning when using those that don't.\n\n Comments?\n\n\n* jn/config-ignore-inaccessible (2013-04-15) 1 commit\n - config: allow inaccessible configuration under $HOME\n\n When $HOME is misconfigured to point at an unreadable directory, we\n used to complain and die. This loosens the check.\n\n I do not think we agreed that this is a good idea, though.\n\n\n* jn/gitweb-install-doc (2013-04-15) 1 commit\n - gitweb/INSTALL: Simplify description of GITWEB_CONFIG_SYSTEM\n\n Reword gitweb configuration instrutions.\n\n Will merge to 'next'.\n\n\n* jx/i18n-branch-error-messages (2013-04-15) 1 commit\n - i18n: branch: mark strings for translation\n\n Will merge to 'master'.\n\n\n* nd/checkout-keep-sparse (2013-04-15) 1 commit\n - checkout: add --ignore-skip-worktree-bits in sparse checkout mode\n\n Make the initial \"sparse\" selection of the paths more sticky across\n \"git checkout\".\n\n Will merge to 'next'.\n\n\n* ta/glossary (2013-04-15) 4 commits\n - glossary: improve definitions of refspec and pathspec\n - The name of the hash function is \"SHA-1\", not \"SHA1\"\n - glossary: improve description of SHA-1 related topics\n - glossary: remove outdated/misleading/irrelevant entries\n\n Will merge to 'next'.\n\n\n* th/bisect-final-log (2013-04-15) 1 commit\n - bisect: Store first bad commit as comment in log file\n\n Will merge to 'next'.\n\n--------------------------------------------------\n[Stalled]\n\n* nd/pretty-formats (2013-04-01) 12 commits\n - pretty: support %>> that steal trailing spaces\n - pretty: support truncating in %>, %< and %><\n - pretty: support padding placeholders, %< %> and %><\n - pretty: add %C(auto) for auto-coloring on the next placeholder\n - pretty: two phase conversion for non utf-8 commits\n - utf8: keep NULs in reencode_string()\n - pretty: get the correct encoding for --pretty:format=%e\n - pretty: save commit encoding from logmsg_reencode if the caller needs it\n - utf8.c: add utf8_strnwidth() with the ability to skip ansi sequences\n - utf8.c: move display_mode_esc_sequence_len() for use by other functions\n - pretty: share code between format_decoration and show_decorations\n - pretty-formats.txt: wrap long lines\n\n A mixed bag of a bugfix and two fun enhancements on pretty formats\n placeholder.\n\n Expecting a reroll.\n\n\n* jc/format-patch (2013-02-21) 2 commits\n - format-patch: --inline-single\n - format-patch: rename \"no_inline\" field\n\n A new option to send a single patch to the standard output to be\n appended at the bottom of a message. I personally have no need for\n this, but it was easy enough to cobble together. Tests, docs and\n stripping out more MIMEy stuff are left as exercises to interested\n parties.\n\n Not ready for inclusion.\n\n--------------------------------------------------\n[Cooking]\n\n* ap/strbuf-humanize (2013-04-10) 2 commits\n (merged to 'next' on 2013-04-14 at 66d7af5)\n + count-objects: add -H option to humanize sizes\n + strbuf: create strbuf_humanise_bytes() to show byte sizes\n\n Teach \"--human-readable\" aka \"-H\" option to \"git count-objects\" to\n show various large numbers in Ki/Mi/GiB scaled as necessary.\n\n I've decided to let this topic supersede mc/count-objects-kibibytes.\n Human users will get an even easier output with \"-H\" and by not\n changing the output without an explicit option we do not have to\n break third-party tools that may have been reading from the output\n of this command.\n\n\n* as/clone-reference-with-gitfile (2013-04-09) 2 commits\n (merged to 'next' on 2013-04-15 at ab0d128)\n + clone: Allow repo using gitfile as a reference\n + clone: Fix error message for reference repository\n\n \"git clone\" did not work if a repository pointed at by the\n \"--reference\" option is a gitfile that points at another place.\n\n Waiting for comments.\n\n\n* fc/transport-helper-error-reporting (2013-04-11) 3 commits\n - transport-helper: improve push messages\n - transport-helper: mention helper name when it dies\n - transport-helper: report errors properly\n\n Rerolled enough times. In-code comments may want to be further\n extended to explain tricky parts, but seems to be ready otherwise.\n\n Will merge to 'next'.\n\n\n* jk/doc-http-backend (2013-04-13) 3 commits\n - doc/http-backend: match query-string in apache half-auth example\n - doc/http-backend: give some lighttpd config examples\n - doc/http-backend: clarify \"half-auth\" repo configuration\n\n Improve documentation to illustrate \"push authenticated, fetch\n anonymous\" configuration for smart HTTP servers.\n\n Will merge to 'next'.\n\n\n* jk/gitweb-utf8 (2013-04-08) 4 commits\n - gitweb: Fix broken blob action parameters on blob/commitdiff pages\n - gitweb: Don't append ';js=(0|1)' to external links\n - gitweb: Make feed title valid utf8\n - gitweb: Fix utf8 encoding for blob_plain, blobdiff_plain, commitdiff_plain, and patch\n\n Various fixes to gitweb.\n\n Waiting for a reroll after a review.\n\n\n* jk/submodule-subdirectory-ok (2013-04-10) 2 commits\n - submodule: drop the top-level requirement\n - rev-parse: add --prefix option\n\n Allow various subcommands of \"git submodule\" to be run not from the\n top of the working tree of the superproject.\n\n Waiting for comments.\n\n\n* kb/co-orphan-suggestion-short-sha1 (2013-04-08) 1 commit\n (merged to 'next' on 2013-04-14 at 8caf7fd)\n + checkout: abbreviate hash in suggest_reattach\n\n Update the informational message when \"git checkout\" leaves the\n detached head state.\n\n Will merge to 'master'.\n\n\n* mv/sequencer-pick-error-diag (2013-04-11) 1 commit\n - cherry-pick: make sure all input objects are commits\n\n \"git cherry-pick $blob $tree\" is diagnosed as a nonsense.\n\n Will merge to 'next'.\n\n\n* rs/empty-archive (2013-04-10) 1 commit\n (merged to 'next' on 2013-04-15 at eab39bc)\n + t5004: fix issue with empty archive test and bsdtar\n\n Implementations of \"tar\" of BSD descend have found to have trouble\n with reading an otherwise empty tar archive with pax headers and\n causes an unnecessary test failure.\n\n Will merge to 'master'.\n\n\n* th/t9903-symlinked-workdir (2013-04-11) 1 commit\n (merged to 'next' on 2013-04-15 at f062dc6)\n + t9903: Don't fail when run from path accessed through symlink\n\n Will merge to 'master'.\n\n\n* fc/completion (2013-04-14) 8 commits\n (merged to 'next' on 2013-04-14 at a509746)\n + completion: small optimization\n + completion: inline __gitcomp_1 to its sole callsite\n + completion: get rid of compgen\n + completion: add __gitcomp_nl tests\n + completion: add new __gitcompadd helper\n + completion: get rid of empty COMPREPLY assignments\n + completion: trivial test improvement\n + completion: add more cherry-pick options\n\n Will merge to 'master'.\n\n\n* jk/daemon-user-doc (2013-04-12) 1 commit\n (merged to 'next' on 2013-04-14 at 56c08ff)\n + doc: clarify that \"git daemon --user=\" option does not export HOME=~user\n\n Will merge to 'master'.\n\n\n* fc/send-email-annotate (2013-04-14) 7 commits\n (merged to 'next' on 2013-04-14 at 4af1076)\n + rebase-am: explicitly disable cover-letter\n + format-patch: trivial cleanups\n + format-patch: add format.coverLetter configuration variable\n + log: update to OPT_BOOL\n + format-patch: refactor branch name calculation\n + format-patch: improve head calculation for cover-letter\n + send-email: make annotate configurable\n\n Allows format-patch --cover-letter to be configurable; the most\n notable is the \"auto\" mode to create cover-letter only for multi\n patch series.\n\n Will merge to 'master'.\n\n\n* fc/remote-hg (2013-04-11) 21 commits\n - remote-hg: activate graphlog extension for hg_log()\n - remote-hg: fix bad file paths\n - remote-hg: document location of stored hg repository\n - remote-hg: fix bad state issue\n - remote-hg: add 'insecure' option\n - remote-hg: add simple mail test\n - remote-hg: add basic author tests\n - remote-hg: show more proper errors\n - remote-hg: force remote push\n - remote-hg: push to the appropriate branch\n - remote-hg: update tags globally\n - remote-hg: update remote bookmarks\n - remote-hg: refactor export\n - remote-hg: split bookmark handling\n - remote-hg: redirect buggy mercurial output\n - remote-hg: trivial test cleanups\n - remote-hg: make sure fake bookmarks are updated\n - remote-hg: fix for files with spaces\n - remote-hg: properly report errors on bookmark pushes\n - remote-hg: add missing config variable in doc\n - remote-hg: trivial cleanups\n\n Rerolled.\n\n Waiting for comments.\n\n\n* jk/http-dumb-namespaces (2013-04-09) 1 commit\n (merged to 'next' on 2013-04-15 at 4bfa834)\n + http-backend: respect GIT_NAMESPACE with dumb clients\n\n Allow smart-capable HTTP servers to be restricted via the\n GIT_NAMESPACE mechanism when talking with commit-walker clients\n (they already do so when talking with smart HTTP clients).\n\n Will merge to 'master'.\n\n\n* jl/submodule-mv (2013-04-11) 4 commits\n - rm: delete .gitmodules entry of submodules removed from the work tree\n - Teach mv to update the path entry in .gitmodules for moved submodules\n - Teach mv to move submodules using a gitfile\n - Teach mv to move submodules together with their work trees\n\n \"git mv A B\" when moving a submodule A does \"the right thing\",\n inclusing relocating its working tree and adjusting the paths in\n the .gitmodules file.\n\n Will merge to 'next'.\n\n\n* jc/detached-head-doc (2013-04-05) 1 commit\n (merged to 'next' on 2013-04-14 at 24b9271)\n + glossary: extend \"detached HEAD\" description\n\n Will merge to 'master'.\n\n\n* jk/merge-tree-added-identically (2013-04-08) 1 commit\n (merged to 'next' on 2013-04-15 at 35fd4b9)\n + merge-tree: don't print entries that match \"local\"\n\n The resolution of some corner cases by \"git merge-tree\" were\n inconsistent between top-of-the-tree and in a subdirectory.\n\n Will merge to 'master'.\n\n\n* jn/add-2.0-u-A-sans-pathspec (2013-04-03) 6 commits\n - git add: -u/-A now affects the entire working tree\n (merged to 'next' on 2013-04-05 at eae93ef)\n + add -A: only show pathless 'add -A' warning when changes exist outside cwd\n + add -u: only show pathless 'add -u' warning when changes exist outside cwd\n + add: make warn_pathless_add() a no-op after first call\n + add: add a blank line at the end of pathless 'add [-u|-A]' warning\n + add: make pathless 'add [-u|-A]' warning a file-global function\n\n \"git add -u/-A\" without any pathspec traditionally limited its\n operation to the current directory when run from a subdirectory,\n but in Git 2.0, they will affect the entire working tree. Start\n training users to explicitly say \".\" or \":/\" to smooth out the\n transition hump with the earlier parts of this series, and flip the\n default as the final step.\n\n Will merge to 'master' the early bits and cook the rest in 'next' until Git 2.0.\n\n\n* tr/packed-object-info-wo-recursion (2013-03-27) 3 commits\n (merged to 'next' on 2013-03-29 at b1c3858)\n + sha1_file: remove recursion in unpack_entry\n + Refactor parts of in_delta_base_cache/cache_or_unpack_entry\n + sha1_file: remove recursion in packed_object_info\n\n Attempts to reduce the stack footprint of sha1_object_info()\n and unpack_entry() codepaths.\n\n Will merge to 'master'.\n\n\n* nd/magic-pathspecs (2013-03-31) 45 commits\n . Rename field \"raw\" to \"_raw\" in struct pathspec\n . pathspec: support :(glob) syntax\n . pathspec: make --literal-pathspecs disable pathspec magic\n . pathspec: support :(literal) syntax for noglob pathspec\n . Kill limit_pathspec_to_literal() as it's only used by parse_pathspec()\n . parse_pathspec: preserve prefix length via PATHSPEC_PREFIX_ORIGIN\n . parse_pathspec: make sure the prefix part is wildcard-free\n . tree-diff: remove the use of pathspec's raw[] in follow-rename codepath\n . Remove match_pathspec() in favor of match_pathspec_depth()\n . Remove init_pathspec() in favor of parse_pathspec()\n . Remove diff_tree_{setup,release}_paths\n . Convert common_prefix() to use struct pathspec\n . Convert add_files_to_cache to take struct pathspec\n . Convert {read,fill}_directory to take struct pathspec\n . Convert refresh_index to take struct pathspec\n . Convert report_path_error to take struct pathspec\n . checkout: convert read_tree_some to take struct pathspec\n . Convert unmerge_cache to take struct pathspec\n . Convert run_add_interactive to use struct pathspec\n . Convert read_cache_preload() to take struct pathspec\n . reset: convert to use parse_pathspec\n . add: convert to use parse_pathspec\n . check-ignore: convert to use parse_pathspec\n . archive: convert to use parse_pathspec\n . ls-files: convert to use parse_pathspec\n . rm: convert to use parse_pathspec\n . checkout: convert to use parse_pathspec\n . rerere: convert to use parse_pathspec\n . status: convert to use parse_pathspec\n . commit: convert to use parse_pathspec\n . clean: convert to use parse_pathspec\n . Guard against new pathspec magic in pathspec matching code\n . parse_pathspec: support prefixing original patterns\n . parse_pathspec: support stripping/checking submodule paths\n . parse_pathspec: support stripping submodule trailing slashes\n . parse_pathspec: a special flag for max_depth feature\n . Convert some get_pathspec() calls to parse_pathspec()\n . parse_pathspec: add PATHSPEC_PREFER_{CWD,FULL}\n . parse_pathspec: save original pathspec for reporting\n . Add parse_pathspec() that converts cmdline args to struct pathspec\n . pathspec: add copy_pathspec\n . pathspec: i18n-ize error strings in pathspec parsing code\n . Move struct pathspec and related functions to pathspec.[ch]\n . clean: remove unused variable \"seen\"\n . setup.c: check that the pathspec magic ends with \")\"\n\n Migrate the rest of codebase to use \"struct pathspec\" more.\n\n\n* jc/add-2.0-delete-default (2013-03-08) 3 commits\n - git add ... defaults to \"-A\"\n (merged to 'next' on 2013-04-05 at 199442e)\n + git add: start preparing for \"git add ...\" to default to \"-A\"\n + builtin/add.c: simplify boolean variables\n\n In Git 2.0, \"git add pathspec\" will mean \"git add -A pathspec\". If\n you did this in a working tree that tracks dir/lost and dir/another:\n\n $ rm dir/lost\n $ edit dir/another\n $ git add dir\n\n The last step will not only notices and records updated\n dir/another, but also notices and records the removal of dir/lost\n in the index.\n\n Start training the users for this change to say --no-all when they\n want to ignore the removal to smooth the transition hump.\n\n Will merge to 'master' the early bits and cook the rest in 'next' until Git 2.0.\n\n\n* tr/line-log (2013-04-12) 11 commits\n (merged to 'next' on 2013-04-15 at 504559e)\n + log -L: improve comments in process_all_files()\n + log -L: store the path instead of a diff_filespec\n + log -L: test merge of parallel modify/rename\n + t4211: pass -M to 'git log -M -L...' test\n (merged to 'next' on 2013-04-05 at 5afb00c)\n + log -L: fix overlapping input ranges\n + log -L: check range set invariants when we look it up\n (merged to 'next' on 2013-04-01 at 5be920c)\n + Speed up log -L... -M\n + log -L: :pattern:file syntax to find by funcname\n + Implement line-history search (git log -L)\n + Export rewrite_parents() for 'log -L'\n + Refactor parse_loc\n\n\n* jc/push-2.0-default-to-simple (2013-04-03) 13 commits\n - push: switch default from \"matching\" to \"simple\"\n (merged to 'next' on 2013-04-05 at 1b42c19)\n + t5570: do not assume the \"matching\" push is the default\n + t5551: do not assume the \"matching\" push is the default\n + t5550: do not assume the \"matching\" push is the default\n + t9401: do not assume the \"matching\" push is the default\n + t9400: do not assume the \"matching\" push is the default\n + t7406: do not assume the \"matching\" push is the default\n + t5531: do not assume the \"matching\" push is the default\n + t5519: do not assume the \"matching\" push is the default\n + t5517: do not assume the \"matching\" push is the default\n + t5516: do not assume the \"matching\" push is the default\n + t5505: do not assume the \"matching\" push is the default\n + t5404: do not assume the \"matching\" push is the default\n\n Update the test suite that still assumed the push.default will\n forever be 'matching'. In Git 2.0, that will no longer be the\n case.\n\n Will merge to 'master' the early bits and cook the rest in 'next' until Git 2.0.\n\n--------------------------------------------------\n[Discarded]\n\n* fc/transport-helper-waitpid (2013-04-07) 3 commits\n . SQUASH???\n . transport-helper: check if remote helper is alive\n . [EXPLAIN BETTER] run-command: add new check_command helper\n\n fc/transport-helper-error-reporting supersedes this topic.\n\n\n* jc/gg (2013-04-08) 3 commits\n . commit: add get_commit_encoding()\n . commit: rename parse_commit_date()\n . commit: shrink \"indegree\" field\n (this branch uses jc/decorate.)\n\n\n* mc/count-objects-kibibytes (2013-04-14) 2 commits\n (merged to 'next' on 2013-04-14 at ff03f2b)\n + Revert \"count-objects: output \"KiB\" instead of \"kilobytes\"\"\n (merged to 'next' on 2013-04-05 at f4e50e8)\n + count-objects: output \"KiB\" instead of \"kilobytes\"\n\n The command reports the total diskspace used to store loose objects\n in kibibytes, but it was labelled as \"kilobytes\". The number now\n is shown with \"KiB\", e.g. \"6750 objects, 50928 KiB\".\n\n If you have scripts that decide when to run \"git repack\" by parsing\n the output from \"git count-objects\", this release may break them.\n Sorry about that. One of the scripts shipped by git-core itself\n also had to be adjusted. You may want to consider updating such\n scripts to always call \"git gc --auto\" to let it decide when to\n repack for you.\n\n Discarded.\n\n\n* jc/decorate (2013-04-07) 2 commits\n - decorate: add \"clear_decoration()\"\n - decorate: document API\n (this branch is used by jc/gg.)\n\n Discarded.\n\n\n* kb/status-ignored-optim (2013-03-19) 8 commits\n (merged to 'next' on 2013-04-01 at 0c12ed9)\n + dir.c: git-status: avoid is_excluded checks for tracked files\n + dir.c: replace is_path_excluded with now equivalent is_excluded API\n + dir.c: unify is_excluded and is_path_excluded APIs\n + dir.c: move prep_exclude and factor out parts of last_exclude_matching\n + dir.c: git-status --ignored: don't list empty directories as ignored\n + dir.c: git-status --ignored: don't list empty ignored directories\n + dir.c: git-status --ignored: don't list files in ignored directories\n + dir.c: git-status --ignored: don't drop ignored directories\n\n \"git status --ignored\" had many corner case bugs. Also the command\n has been optimized by taking advantage of the fact that paths that\n are already known to the index do not have to be checked against\n the .gitignore mechanism most of the time.\n\n Discarded.\n"},{"id":"214395","messageId":"CAMP44s2_wiNr4RaBOEnKnZzT4CF0qKK+bp+Lyi=Nfx3Q9ggqOQ@mail.gmail.com","threadId":"33517","inReplyTo":"7vhaj7r116.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-15T22:24:47Z","receivedAt":"2013-04-15T22:24:47Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Mon, Apr 15, 2013 at 3:28 PM, Junio C Hamano wrote:\n\n> * fc/remote-hg (2013-04-11) 21 commits\n> - remote-hg: activate graphlog extension for hg_log()\n> - remote-hg: fix bad file paths\n> - remote-hg: document location of stored hg repository\n> - remote-hg: fix bad state issue\n> - remote-hg: add 'insecure' option\n> - remote-hg: add simple mail test\n> - remote-hg: add basic author tests\n> - remote-hg: show more proper errors\n> - remote-hg: force remote push\n> - remote-hg: push to the appropriate branch\n> - remote-hg: update tags globally\n> - remote-hg: update remote bookmarks\n> - remote-hg: refactor export\n> - remote-hg: split bookmark handling\n> - remote-hg: redirect buggy mercurial output\n> - remote-hg: trivial test cleanups\n> - remote-hg: make sure fake bookmarks are updated\n> - remote-hg: fix for files with spaces\n> - remote-hg: properly report errors on bookmark pushes\n> - remote-hg: add missing config variable in doc\n> - remote-hg: trivial cleanups\n>\n> Rerolled.\n>\n> Waiting for comments.\n\n>From whom?\n\n\nAnd about this:\nhttp://mid.gmane.org/1365638832-9000-3-git-send-email-felipe.contreras@gmail.com\n\nI think it's a disservice to git users to not consider this a \"cooking\npatch\", specially since it's only the commit message somebody was\nworried about. But whatever, don't.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"214400","messageId":"7vip3npet0.fsf@alter.siamese.dyndns.org","threadId":"33517","inReplyTo":"CAMP44s2_wiNr4RaBOEnKnZzT4CF0qKK+bp+Lyi=Nfx3Q9ggqOQ@mail.gmail.com","subject":"Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-15T23:14:19Z","receivedAt":"2013-04-15T23:14:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> And about this:\n> http://mid.gmane.org/1365638832-9000-3-git-send-email-felipe.contreras@gmail.com\n\nWhat about it? Is that the one you said you are going to reroll?\n\nI do not recall the details of Peff's complaints, but re-reading the\nlog message of the patch itself, seeing \"correctly\" twice is not\nsatisfactory. As you very well know, a bug description that says\n\"This does not correctly work!\" and stops there is not as useful as\na description that defines what \"correct\" behaviour is expected.\n\nIf one of them said \"update correctly to record what was pushed\" or\nsomething like that, that should be sufficient.\n"},{"id":"214401","messageId":"20130415232532.GA7134@sigill.intra.peff.net","threadId":"33517","inReplyTo":"7vhaj7r116.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-04-15T23:25:32Z","receivedAt":"2013-04-15T23:25:32Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Apr 15, 2013 at 01:28:53PM -0700, Junio C Hamano wrote:\n\n> [Graduated to \"master\"]\n> [...]\n> * jk/http-error-messages (2013-04-06) 9 commits\n> (merged to 'next' on 2013-04-11 at 7a03981)\n> + http: drop http_error function\n> + remote-curl: die directly with http error messages\n> + http: re-word http error message\n> + http: simplify http_error helper function\n> + remote-curl: consistently report repo url for http errors\n> + remote-curl: always show friendlier 404 message\n> + remote-curl: let servers override http 404 advice\n> + remote-curl: show server content on http errors\n> + http: add HTTP_KEEP_ERROR option\n> \n> Improve error reporting from the http transfer clients.\n\nI had not been keeping tabs on the progress of this topic, and was\nsurprised to see it in master already. It hadn't gotten any comments, so\nI sort of assumed I would need to re-post to get interest. I don't mind,\nbut...\n\n...the tip of your current master does not currently pass the test\nsuite[1]. I bisected the problem to \"show server content on http\nerrors\" from the above topic, but haven't figure it out past that. I\ntypically run \"make test\" before submitting, so I'm guessing it is an\ninteraction with another topic that graduated around the same time\n(though it's also possible that I just failed to test after the last\nrebase).\n\nI'll investigate further, but it may be a few hours.\n\n-Peff\n\n[1] I know you always test master before pushing it out, but I suspect\n you do not run the GIT_TEST_HTTPD tests. The failures are in t5541\n and t5551.\n"},{"id":"214402","messageId":"CAMP44s3NE3yrQoa1nZXAgy3KFXGF56Ki8icJ2z2TDigzax0nWg@mail.gmail.com","threadId":"33517","inReplyTo":"7vip3npet0.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-15T23:30:45Z","receivedAt":"2013-04-15T23:30:45Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Mon, Apr 15, 2013 at 6:14 PM, Junio C Hamano wrote:\n> Felipe Contreras writes:\n>\n>> And about this:\n>> http://mid.gmane.org/1365638832-9000-3-git-send-email-felipe.contreras@gmail.com\n>\n> What about it? Is that the one you said you are going to reroll?\n\nAt first, but then I changed my mind.\n\n> I do not recall the details of Peff's complaints, but re-reading the\n> log message of the patch itself, seeing \"correctly\" twice is not\n> satisfactory. As you very well know, a bug description that says\n> \"This does not correctly work!\" and stops there is not as useful as\n> a description that defines what \"correct\" behaviour is expected.\n\n The subject is: transport-helper: update remote helper namespace\n\nClearly, that's the correct behavior. Why would anybody send a change\nthat does something other than the correct behavior?\n\n---\nWhen pushing, the remote namespace is updated correctly\n(e.g. refs/origin/master), but not the remote helper's\n(e.g. refs/testgit/origin/master).\n---\n\nSo it should be clear now: the remote namespace refs/origin/master is\nupdated, but not the remote helper's namespace\nrefs/testgit/origin/master, which is what I already said. I don't know\nwhat more do you expect. When you push 'refs/heads/master' to origin,\nyou expect 'refs/remotes/origin/master' to point to the same commit,\nsame with 'refs/testgit/origin/master', why would you expect to point\nsomewhere else?\n\n> If one of them said \"update correctly to record what was pushed\" or\n> something like that, that should be sufficient.\n\nSure, it's still under the definition of \"cooking\" in my mind. Anyway,\nI'm not feeling a great urge to resubmit this patch just because of\nthe commit message, which I think it's perfectly fine. There's more\ninteresting things work on.\n\nPersonally I feel it's preferable to fix the actual issue that is\nalready present rather than hold it because the commit message might\nor might not be enough for hypothetical point in the future.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"214405","messageId":"CAA787rmJKNGF_4koHJpdzbAVjvLB-sWxT__secVRDBi1ieBYnQ@mail.gmail.com","threadId":"33517","inReplyTo":"20130415232532.GA7134@sigill.intra.peff.net","subject":"Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)","fromName":"Øyvind A. Holm","fromEmail":"sunny@sunbase.org","sentAt":"2013-04-15T23:49:13Z","receivedAt":"2013-04-15T23:49:13Z","isPatch":false,"sender":{"key":"sunny@sunbase.org","avatar":"https://avatars.githubusercontent.com/u/113445?v=4"},"body":"On 16 April 2013 01:25, Jeff King wrote:\n> On Mon, Apr 15, 2013 at 01:28:53PM -0700, Junio C Hamano wrote:\n> > [Graduated to \"master\"]\n> > [...]\n> > * jk/http-error-messages (2013-04-06) 9 commits\n> > (merged to 'next' on 2013-04-11 at 7a03981)\n> > [...]\n>\n> ...the tip of your current master does not currently pass the test\n> suite[1].\n> [...]\n>\n> [1] I know you always test master before pushing it out, but I suspect\n> you do not run the GIT_TEST_HTTPD tests. The failures are in t5541\n> and t5551.\n\nAh, that explains why the test suite passed here, I built a new\nversion an hour ago from current master (v1.8.2.1-418-gaec3f77,\n2013-04-15 12:45:15 -0700), and no errors were found. I build new gits\nalmost every day for testing purposes (master, and next and maint very\noften) on several machines with different setups, and of course also\nto have the newest version. I'd like to run as many tests as possible.\nIs there any list of environment variables or make directives\navailable to enable most of them?\n\nRegards,\nØyvind\n"},{"id":"214407","messageId":"20130416003038.GA5336@sigill.intra.peff.net","threadId":"33517","inReplyTo":"20130415232532.GA7134@sigill.intra.peff.net","subject":"Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-04-16T00:30:38Z","receivedAt":"2013-04-16T00:30:38Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Apr 15, 2013 at 07:25:32PM -0400, Jeff King wrote:\n\n> On Mon, Apr 15, 2013 at 01:28:53PM -0700, Junio C Hamano wrote:\n> \n> > * jk/http-error-messages (2013-04-06) 9 commits\n> [...]\n> ...the tip of your current master does not currently pass the test\n> suite[1]. I bisected the problem to \"show server content on http\n> errors\" from the above topic, but haven't figure it out past that. I\n> typically run \"make test\" before submitting, so I'm guessing it is an\n> interaction with another topic that graduated around the same time\n> (though it's also possible that I just failed to test after the last\n> rebase).\n\nThis patch on top of jk/http-error-messages fixes it.\n\n-- >8 --\nSubject: [PATCH] http: set curl FAILONERROR each time we select a handle\n\nBecause we reuse curl handles for multiple requests, the\nsetup of a handle happens in two stages: stable, global\nsetup and per-request setup. The lifecycle of a handle is\nsomething like:\n\n 1. get_curl_handle; do basic global setup that will last\n through the whole program (e.g., setting the user\n agent, ssl options, etc)\n\n 2. get_active_slot; set up a per-request baseline (e.g.,\n clearing the read/write functions, making it a GET\n request, etc)\n\n 3. perform the request with curl_*_perform functions\n\n 4. goto step 2 to perform another request\n\nBreaking it down this way means we can avoid doing global\nsetup from step (1) repeatedly, but we still finish step (2)\nwith a predictable baseline setup that callers can rely on.\n\nUntil commit 6d052d7 (http: add HTTP_KEEP_ERROR option,\n2013-04-05), setting curl's FAILONERROR option was a global\nsetup; we never changed it. However, 6d052d7 introduced in\noption where some requests might turn off FAILONERROR. Later\nrequests using the same handle would have the option\nunexpectedly turned off, which meant they would not notice\nhttp failures at all.\n\nThis could easily be seen in the test-suite for the\n\"half-auth\" cases of t5541 and t5551. The initial requests\nturned off FAILONERROR, which meant it was erroneously off\nfor the rpc POST. That worked fine for a successful request,\nbut meant that we failed to react properly to the HTTP 401\n(instead, we treated whatever the server handed us as a\nsuccessful message body).\n\nThe solution is simple: now that FAILONERROR is a\nper-request setting, we move it to get_active_slot to make\nsure it is reset for each request.\n\nSigned-off-by: Jeff King \n---\nHmph. I have no idea how this ever passed the tests, so I can only\nassume that I screwed up in running them. I even recall considering this\nissue while writing the patches, but I mixed up which of get_curl_handle\nand get_active_slot it needed to be in when I did so.\n\n http.c | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/http.c b/http.c\nindex 58c063c..48d4ff6 100644\n--- a/http.c\n+++ b/http.c\n@@ -282,7 +282,6 @@ static CURL *get_curl_handle(void)\n #endif\n \tif (ssl_cainfo != NULL)\n \t\tcurl_easy_setopt(result, CURLOPT_CAINFO, ssl_cainfo);\n-\tcurl_easy_setopt(result, CURLOPT_FAILONERROR, 1);\n \n \tif (curl_low_speed_limit > 0 && curl_low_speed_time > 0) {\n \t\tcurl_easy_setopt(result, CURLOPT_LOW_SPEED_LIMIT,\n@@ -506,6 +505,7 @@ struct active_request_slot *get_active_slot(void)\n \tcurl_easy_setopt(slot->curl, CURLOPT_POSTFIELDS, NULL);\n \tcurl_easy_setopt(slot->curl, CURLOPT_UPLOAD, 0);\n \tcurl_easy_setopt(slot->curl, CURLOPT_HTTPGET, 1);\n+\tcurl_easy_setopt(slot->curl, CURLOPT_FAILONERROR, 1);\n \tif (http_auth.password)\n \t\tinit_curl_http_auth(slot->curl);\n \n-- \n1.8.2.8.g44e4c28\n"},{"id":"214409","messageId":"20130416005322.GB14995@sigill.intra.peff.net","threadId":"33517","inReplyTo":"CAA787rmJKNGF_4koHJpdzbAVjvLB-sWxT__secVRDBi1ieBYnQ@mail.gmail.com","subject":"Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-04-16T00:53:22Z","receivedAt":"2013-04-16T00:53:22Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Apr 16, 2013 at 01:49:13AM +0200, Øyvind A. Holm wrote:\n\n> > [1] I know you always test master before pushing it out, but I suspect\n> > you do not run the GIT_TEST_HTTPD tests. The failures are in t5541\n> > and t5551.\n> \n> Ah, that explains why the test suite passed here, I built a new\n> version an hour ago from current master (v1.8.2.1-418-gaec3f77,\n> 2013-04-15 12:45:15 -0700), and no errors were found. I build new gits\n> almost every day for testing purposes (master, and next and maint very\n> often) on several machines with different setups, and of course also\n> to have the newest version. I'd like to run as many tests as possible.\n> Is there any list of environment variables or make directives\n> available to enable most of them?\n\nI don't think there's a master list anywhere. The simplest thing is\nprobably to run the whole suite and grep for skipped tests, each of\nwhich should usually explain their reasoning for the skip. Like:\n\n make test | grep '# skip'\n\nNote that this will turn up more than just environment variables to set.\nIt will also turn up missing programs you might need to install to run\nthe tests (e.g., we do not do subversion tests if svn is not installed).\nWhich is a good thing if you are trying for complete test coverage. But\nit will also turn up useless things that are just fundamental to your\nplatform (e.g., you cannot do both the case-sensitive and the\ncase-insensitive filesystem tests).\n\nMost of the tests are on by default, unless necessary programs are\nmissing or you explicitly disable them. GIT_TEST_HTTPD and\nGIT_TEST_GIT_DAEMON seem to be the exceptions.\n\n-Peff\n"},{"id":"214412","messageId":"CAPig+cTemYT1qTNpYFF2gvZhu=O=NwQu5GzAisgnMCjfZYFCkA@mail.gmail.com","threadId":"33517","inReplyTo":"20130416003038.GA5336@sigill.intra.peff.net","subject":"Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2013-04-16T01:08:23Z","receivedAt":"2013-04-16T01:08:23Z","isPatch":false,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Mon, Apr 15, 2013 at 8:30 PM, Jeff King wrote:\n> Subject: [PATCH] http: set curl FAILONERROR each time we select a handle\n>\n> Until commit 6d052d7 (http: add HTTP_KEEP_ERROR option,\n> 2013-04-05), setting curl's FAILONERROR option was a global\n> setup; we never changed it. However, 6d052d7 introduced in\n\ns/in/an/\n\n> option where some requests might turn off FAILONERROR. Later\n> requests using the same handle would have the option\n> unexpectedly turned off, which meant they would not notice\n> http failures at all.\n"},{"id":"214425","messageId":"CAM9Z-nns0AYDne8Jp98_LUupLZLv+CvXU7JTzrO32MqyGnqWJA@mail.gmail.com","threadId":"33517","inReplyTo":"7vhaj7r116.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)","fromName":"Drew Northup","fromEmail":"n1xim.email@gmail.com","sentAt":"2013-04-16T03:21:35Z","receivedAt":"2013-04-16T03:21:35Z","isPatch":false,"sender":{"key":"n1xim.email@gmail.com","avatar":null},"body":"n Mon, Apr 15, 2013 at 4:28 PM, Junio C Hamano wrote:\n\n> * jn/gitweb-install-doc (2013-04-15) 1 commit\n> - gitweb/INSTALL: Simplify description of GITWEB_CONFIG_SYSTEM\n>\n> Reword gitweb configuration instrutions.\n>\n> Will merge to 'next'.\n\nWhile the re-worded text is easier on the eyes it fails to note why we\ndon't just dump our idiosyncratic way of doing things and just make\nthe system-wide defaults act individually. This information is useful\nto system administrators, as it explains what is actually going on.\n\n--\n-Drew Northup\n--------------------------------------------------------------\n\"As opposed to vegetable or mineral error?\"\n-John Pescatore, SANS NewsBites Vol. 12 Num. 59\n"},{"id":"214429","messageId":"7v1uabp109.fsf@alter.siamese.dyndns.org","threadId":"33517","inReplyTo":"CAMP44s3NE3yrQoa1nZXAgy3KFXGF56Ki8icJ2z2TDigzax0nWg@mail.gmail.com","subject":"Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-16T04:12:22Z","receivedAt":"2013-04-16T04:12:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> So it should be clear now: the remote namespace refs/origin/master is\n> updated, but not the remote helper's namespace\n> refs/testgit/origin/master, which is what I already said. I don't know\n> what more do you expect. When you push 'refs/heads/master' to origin,\n> you expect 'refs/remotes/origin/master' to point to the same commit,\n> same with 'refs/testgit/origin/master', why would you expect to point\n> somewhere else?\n\nLet me play somebody who comes later and wonders about this exchange\nthree months down the road...\n\nYou mention three refs/ here. Do they live in the same repository?\nAny Git person is expected to know refs/heads/master, which is \"my\nlocal branch I have worked on and I am pushing\". It also is easy to\nguess what \"refs/remotes/origin/master\" is, even though we are not\ntalking about a usual Git remote. It is to keep track of the remote\nbehind the helper we are pushing into, and is updated to pretend as\nif we fetched immediately from the place we just pushed. The latter\nbeing in sync with what we pushed is something that can naturally be\nexpected.\n\nNow, what is this third \"refs/testgit/origin/master\" thing? Is it\nexpected to always be the same as \"refs/remotes/origin/master\"? If\nthat is the case, why do we even need such a redundant information\nin the first place?\n"},{"id":"214438","messageId":"CAMP44s3shDEx9dfWw_jNu0zQrReabgAMW-mti86wyoxhk+N2Ow@mail.gmail.com","threadId":"33517","inReplyTo":"7v1uabp109.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-16T05:32:14Z","receivedAt":"2013-04-16T05:32:14Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Mon, Apr 15, 2013 at 11:12 PM, Junio C Hamano wrote:\n> Felipe Contreras writes:\n>\n>> So it should be clear now: the remote namespace refs/origin/master is\n>> updated, but not the remote helper's namespace\n>> refs/testgit/origin/master, which is what I already said. I don't know\n>> what more do you expect. When you push 'refs/heads/master' to origin,\n>> you expect 'refs/remotes/origin/master' to point to the same commit,\n>> same with 'refs/testgit/origin/master', why would you expect to point\n>> somewhere else?\n>\n> Let me play somebody who comes later and wonders about this exchange\n> three months down the road...\n>\n> You mention three refs/ here. Do they live in the same repository?\n> Any Git person is expected to know refs/heads/master, which is \"my\n> local branch I have worked on and I am pushing\". It also is easy to\n> guess what \"refs/remotes/origin/master\" is, even though we are not\n> talking about a usual Git remote. It is to keep track of the remote\n> behind the helper we are pushing into, and is updated to pretend as\n> if we fetched immediately from the place we just pushed. The latter\n> being in sync with what we pushed is something that can naturally be\n> expected.\n>\n> Now, what is this third \"refs/testgit/origin/master\" thing? Is it\n> expected to always be the same as \"refs/remotes/origin/master\"? If\n> that is the case, why do we even need such a redundant information\n> in the first place?\n\nAnswering that question is beyond the scope of the commit message. The\npurpose of the commit message is not to educate people about the\ncurrent design of transport-helpers, we have\nDocumentation/gitremote-helpers.txt for that. We also have discussions\nin the mailing list.\n\nThe untold answer is 'if you have to ask, you don't understand this\ncode', but if you must, the short answer is: because it doesn't work\notherwise.\n\nYes, in theory not using a remote helper ref namespace should work,\nbut it doesn't, and I sent patches to try to fix this behavior, but\nthose, along with this particular patch, where ignored. So I gave up\non those patches that tried to fix the behavior for more corner cases\nand tried to push the simplest one I could find, still finding\ntrouble. I tried to document that in t/t5801-remote-helpers.sh,\nalthough to be honest, the tests that pass can be hardly be considered\nproper behavior. This is of course, for import/export, which are the\nonly operations I'm familiar with (maybe the namespace makes sense for\npush/fetch operations.\n\nSo basically I'm just tired of explaining the same things over and\nover again, and if you try to explain every single detail, I think any\nreasonable person would reach the conclusion that the design doesn't\nreally make sense. But the only person that seems to be trying to\nexplain it and improve it seems to be me.\n\nThe commit message is no place to explain all these subtleties, it\nwould be huge and would need to refer to plenty of mails in the\nmailing list.\n\nI could send the whole patch series I have, and then it might become\nclearer why not having the refspec doesn't work, but then ,the chances\nof this patch not getting through would be higher, as the last time I\nsent such series, it didn't go through.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"214474","messageId":"8761zm4wzg.fsf@linux-k42r.v.cablecom.net","threadId":"33517","inReplyTo":"CAMP44s3NE3yrQoa1nZXAgy3KFXGF56Ki8icJ2z2TDigzax0nWg@mail.gmail.com","subject":"Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)","fromName":"Thomas Rast","fromEmail":"trast@inf.ethz.ch","sentAt":"2013-04-16T09:59:31Z","receivedAt":"2013-04-16T09:59:31Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Felipe Contreras writes:\n\n> Clearly, that's the correct behavior. Why would anybody send a change\n> that does something other than the correct behavior?\n\nAlong the same lines, why would anyone write broken code? Nobody does,\nright?\n\nIf anyone reads that commit message in more than a few weeks, then it's\nbecause some of the code is *broken*. So the reader is investigating a\nsituation where there must be a flaw somewhere, and trying to pin down\nthe source. Having access to the thinking behind each commit means s/he\ncan more easily verify whether that thinking was correct and still\napplies.\n\nAnd your commit messages do nothing towards that end.\n\n\nA cursory look^W^Wreview of the messages in fc/remote-hg:\n\n remote-hg: fix bad file paths\n \n Mercurial allows absolute file paths, and Git doesn't like that.\n\nOnly describes the problem; no reasoning as to what the chosen solution\nis or why it is correct. (I can at least infer the former from the\ncode, but not the latter.)\n\n remote-hg: show more proper errors\n \n When cloning or pushing fails, we don't want to show a stack-trace.\n\nSo what do we show?\n\nIt also seems that you do not actually use the import you add, or do\nyou?\n\n remote-hg: force remote push\n \n Ideally we shouldn't do this, as it's not recommended in mercurial\n documentation, but there's no other way to push multiple bookmarks (on\n the same branch), which would be the behavior most similar to git.\n \n At the same time, add a configuration option for the people that don't\n want to risk creating new remote heads.\n\nThis one, for a change, says what it does but doesn't say what problem\nit fixes.\n\nI'll refrain from commenting on all the one-line messages, and just\npoint at this one:\n\n remote-hg: trivial test cleanups\n\nIn $DAYJOB the advice is to avoid \"trivial\" (and similarly \"obvious\"):\neither it *is* trivial, in which case you don't need to point that out,\nor you're just trying to handwave over the fact that it's not. Like\nthis:\n\n git_clone () {\n- hg -R $1 bookmark -f -r tip master &&\n git clone -q \"hg::$PWD/$1\" $2\n }\n\nNot knowing the code I can only conjecture, but surely there was a\nreason that the hg call lived in a function called git_clone? And\nsurely there must be a good reason why it is no longer needed?\n\n\nMy personal favorite however is this one:\n\n remote-bzr: improve tag handling\n \n revision_history() is deprecated and doesn't do what we want (revno\n instead of dotted_revno?).\n\nI don't even know how to parse that question mark. Does it actually ask\na question? Does it mean to imply, by the intonation suggested by a\nquestion mark, \"how could anyone ever have been so silly as to use a\nrevno instead of a dotted_revno\"?\n\n\nBy the way, it's easy to find similarly helpful messages in git.git in\nthe old days. One that I remember stumbling across was:\n\n Add the --color-words option to the diff options family\n \n With this option, the changed words are shown inline. For example,\n if a file containing \"This is foo\" is changed to \"This is bar\", the diff\n will now show \"This is \" in plain text, \"foo\" in red, and \"bar\" in green.\n\nHow could it not be obvious how it achieves this to anyone who has read\nthe ~170 lines of code it adds?\n\nLuckily *that* code was correct and feature-complete right from the\nstart, so nobody ever had to actually read it to figure out what's going\non.\n\nBut that was back in 2006. I should think that git.git has improved\nsince; when I wrote my first patches in 2008, I was impressed with the\nreadable history and extensive reviews.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"214498","messageId":"7va9oyo0mf.fsf@alter.siamese.dyndns.org","threadId":"33517","inReplyTo":"20130416003038.GA5336@sigill.intra.peff.net","subject":"Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-16T17:18:16Z","receivedAt":"2013-04-16T17:18:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> The solution is simple: now that FAILONERROR is a\n> per-request setting, we move it to get_active_slot to make\n> sure it is reset for each request.\n>\n> Signed-off-by: Jeff King \n> ---\n> Hmph. I have no idea how this ever passed the tests, so I can only\n> assume that I screwed up in running them. I even recall considering this\n> issue while writing the patches, but I mixed up which of get_curl_handle\n> and get_active_slot it needed to be in when I did so.\n\nThanks.\n\n> http.c | 2 +-\n> 1 file changed, 1 insertion(+), 1 deletion(-)\n>\n> diff --git a/http.c b/http.c\n> index 58c063c..48d4ff6 100644\n> --- a/http.c\n> +++ b/http.c\n> @@ -282,7 +282,6 @@ static CURL *get_curl_handle(void)\n> #endif\n> \tif (ssl_cainfo != NULL)\n> \t\tcurl_easy_setopt(result, CURLOPT_CAINFO, ssl_cainfo);\n> -\tcurl_easy_setopt(result, CURLOPT_FAILONERROR, 1);\n> \n> \tif (curl_low_speed_limit > 0 && curl_low_speed_time > 0) {\n> \t\tcurl_easy_setopt(result, CURLOPT_LOW_SPEED_LIMIT,\n> @@ -506,6 +505,7 @@ struct active_request_slot *get_active_slot(void)\n> \tcurl_easy_setopt(slot->curl, CURLOPT_POSTFIELDS, NULL);\n> \tcurl_easy_setopt(slot->curl, CURLOPT_UPLOAD, 0);\n> \tcurl_easy_setopt(slot->curl, CURLOPT_HTTPGET, 1);\n> +\tcurl_easy_setopt(slot->curl, CURLOPT_FAILONERROR, 1);\n> \tif (http_auth.password)\n> \t\tinit_curl_http_auth(slot->curl);\nThanks\n"},{"id":"214520","messageId":"CAMP44s0a2VsPBMd9Vrrhwdw=SPp2HrvDdXZ9Dmzhr9A6T+Sz7w@mail.gmail.com","threadId":"33517","inReplyTo":"8761zm4wzg.fsf@linux-k42r.v.cablecom.net","subject":"Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-16T19:04:13Z","receivedAt":"2013-04-16T19:04:13Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, Apr 16, 2013 at 4:59 AM, Thomas Rast wrote:\n> Felipe Contreras writes:\n>\n>> Clearly, that's the correct behavior. Why would anybody send a change\n>> that does something other than the correct behavior?\n>\n> Along the same lines, why would anyone write broken code? Nobody does,\n> right?\n\nYes, I should change the subject to:\n\n transport-helper: update remote helper namespace, because that's\nexactly the thing we DON'T want to do, the purpose of this patch is to\nmess up everything\n\nSuree. I'm willing and knowingly introducing a change that goes\ndiametrically opposite to what we want.\n\n> If anyone reads that commit message in more than a few weeks, then it's\n> because some of the code is *broken*.\n\nThat is irrelevant. Junio said the correct behavior was not described,\nwhen if fact it clearly is. Whether or not the patch has a bug in it\nis irrelevant to the fact that the correct behavior is described or\nnot.\n\n> So the reader is investigating a\n> situation where there must be a flaw somewhere, and trying to pin down\n> the source. Having access to the thinking behind each commit means s/he\n> can more easily verify whether that thinking was correct and still\n> applies.\n\nSure, and where is the thinking not clear? The remote helper ref is\nnot updated, so we do update it. How is that not clear?\n\n> And your commit messages do nothing towards that end.\n\nOh, it does. You just don't understand how remote-helper works.\n\n> A cursory look^W^Wreview of the messages in fc/remote-hg:\n\n[skipping irrelevant comments]\n\nI'm sorry, did you actually hit an issue that required to look at the\ncommit message to understand where the issue came from? No? Then I\nwon't bother with hypotheticals.\n\nIf you want to waste your time, by all means, rewrite all my commit\nmessages with essays that nobody will ever read. I'm not going to do\nthat for some hypothetical case that will never happen. I'm not going\nto waste my time.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"214523","messageId":"7va9oyl1wb.fsf@alter.siamese.dyndns.org","threadId":"33517","inReplyTo":"CAMP44s0a2VsPBMd9Vrrhwdw=SPp2HrvDdXZ9Dmzhr9A6T+Sz7w@mail.gmail.com","subject":"Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-16T19:19:00Z","receivedAt":"2013-04-16T19:19:00Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> Sure, and where is the thinking not clear? The remote helper ref is\n> not updated, so we do update it. How is that not clear?\n\nSure, between \"leaving it untouched, keeping the stale value\" and\n\"updating it to match what was pushed\", everybody would know you\nmean the latter when you say \"correctly update\". There is no third\noption \"updating it to match a random commit that is related to but\nis not exactly the same as what was pushed\" to be correct.\n\nWhat I felt unclear was _why_ both of these two (remote and testgit)\nhave to get updated. In other words, \"correctly update it\" because\n\"without doing so, these bad things X, Y and Z will happen\".\n"},{"id":"214527","messageId":"CAMP44s38M7P0T1Wjhfv=XryoUevuxGwrik4pXwfkUfdpPNrXTQ@mail.gmail.com","threadId":"33517","inReplyTo":"7va9oyl1wb.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-16T19:48:46Z","receivedAt":"2013-04-16T19:48:46Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, Apr 16, 2013 at 2:19 PM, Junio C Hamano wrote:\n> Felipe Contreras writes:\n>\n>> Sure, and where is the thinking not clear? The remote helper ref is\n>> not updated, so we do update it. How is that not clear?\n>\n> Sure, between \"leaving it untouched, keeping the stale value\" and\n> \"updating it to match what was pushed\", everybody would know you\n> mean the latter when you say \"correctly update\". There is no third\n> option \"updating it to match a random commit that is related to but\n> is not exactly the same as what was pushed\" to be correct.\n>\n> What I felt unclear was _why_ both of these two (remote and testgit)\n> have to get updated. In other words, \"correctly update it\" because\n> \"without doing so, these bad things X, Y and Z will happen\".\n\nThe bad thing that would happen is that it won't be up-to-date.\n\nIf you don't know what an outdated ref causes, then you don't know\nwhat transport-helper does with it, and if you don't know that, why\nare you bothering trying to review this patch? Is the purpose of a\npatch to educate people?\n\nHere it goes. The remote helper ref is going to be used to tell\nfast-export which refs to negate (e.g. ^refs/testgit/origin/master),\nso that extra commits are not generated, which the remote helper\nshould ignore anyway, because it should already have marks for those.\nSo doing two consecutive pushes, would push the commits twice.\n\nIt's worth noting this is the first time anybody asks what is the\nnegative effect of this not getting fixed.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"214554","messageId":"CABURp0q29QkUadbXXa7pQLnTAArRbKh0Y5tdN8stQ7s2BjNAYw@mail.gmail.com","threadId":"33517","inReplyTo":"CAMP44s38M7P0T1Wjhfv=XryoUevuxGwrik4pXwfkUfdpPNrXTQ@mail.gmail.com","subject":"Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)","fromName":"Phil Hord","fromEmail":"phil.hord@gmail.com","sentAt":"2013-04-16T22:34:59Z","receivedAt":"2013-04-16T22:34:59Z","isPatch":false,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"On Tue, Apr 16, 2013 at 3:48 PM, Felipe Contreras\n wrote:\n> Here it goes. The remote helper ref is going to be used to tell\n> fast-export which refs to negate (e.g. ^refs/testgit/origin/master),\n> so that extra commits are not generated, which the remote helper\n> should ignore anyway, because it should already have marks for those.\n> So doing two consecutive pushes, would push the commits twice.\n>\n> It's worth noting this is the first time anybody asks what is the\n> negative effect of this not getting fixed.\n\nYes, but what is noteworthy about it is that you did not include that\nin your commit message to begin with. This is the commit message\nrequest from Documentation/SubmittingPatches:\n\n The body should provide a meaningful commit message, which:\n\n . explains the problem the change tries to solve, iow, what is wrong\n with the current code without the change.\n\n . justifies the way the change solves the problem, iow, why the\n result with the change is better.\n\n . alternate solutions considered but discarded, if any.\n"},{"id":"214555","messageId":"CABURp0qGYG4T+t36=Us328YdLzy9KjBOWot2gSOk=FgCRUCLnQ@mail.gmail.com","threadId":"33517","inReplyTo":"CAMP44s0a2VsPBMd9Vrrhwdw=SPp2HrvDdXZ9Dmzhr9A6T+Sz7w@mail.gmail.com","subject":"Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)","fromName":"Phil Hord","fromEmail":"phil.hord@gmail.com","sentAt":"2013-04-16T22:45:46Z","receivedAt":"2013-04-16T22:45:46Z","isPatch":false,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"On Tue, Apr 16, 2013 at 3:04 PM, Felipe Contreras\n wrote:\n> On Tue, Apr 16, 2013 at 4:59 AM, Thomas Rast wrote:\n>> A cursory look^W^Wreview of the messages in fc/remote-hg:\n>\n> [skipping irrelevant comments]\n>\n> I'm sorry, did you actually hit an issue that required to look at the\n> commit message to understand where the issue came from? No? Then I\n> won't bother with hypotheticals.\n>\n> If you want to waste your time, by all means, rewrite all my commit\n> messages with essays that nobody will ever read. I'm not going to do\n> that for some hypothetical case that will never happen. I'm not going\n> to waste my time.\n\nThis is not a hypothetical. Almost every time I bisect a regression\nin git.git, I find the commit message tells me exactly why the commit\ndid what it did and what the expected result was. I find this to be\namazingly useful. Do I need to show you real instances of that\nhappening? No. I promise it did, though.\n\nOf course, 99% of the commit messages may never be useful to me or\nanyone else. But we do not eschew them altogether. The 1% I have to\nrely on are nearly always helpful and clear, and that is the part I\ncare about.\n\nIf you will not waste your time to write a decent commit message, why\ndo you waste our time asking us to review and accept ill-defined\npatches? Here, of course, I use the royal \"us\" as I do not review\nyour patches. I do not know why that is; I suppose you patch things\noutside of my interests, but it may also be that your patches are\nsimply incomprehensible by design.\n\nPhil\n"},{"id":"214557","messageId":"CAMP44s0q23j-7amBSuT0SL2-SkTmpyonmJx0y5VuAbk38Jo9KQ@mail.gmail.com","threadId":"33517","inReplyTo":"CABURp0q29QkUadbXXa7pQLnTAArRbKh0Y5tdN8stQ7s2BjNAYw@mail.gmail.com","subject":"Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-16T23:50:05Z","receivedAt":"2013-04-16T23:50:05Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, Apr 16, 2013 at 5:34 PM, Phil Hord wrote:\n> On Tue, Apr 16, 2013 at 3:48 PM, Felipe Contreras\n> wrote:\n>> Here it goes. The remote helper ref is going to be used to tell\n>> fast-export which refs to negate (e.g. ^refs/testgit/origin/master),\n>> so that extra commits are not generated, which the remote helper\n>> should ignore anyway, because it should already have marks for those.\n>> So doing two consecutive pushes, would push the commits twice.\n>>\n>> It's worth noting this is the first time anybody asks what is the\n>> negative effect of this not getting fixed.\n>\n> Yes, but what is noteworthy about it is that you did not include that\n> in your commit message to begin with. This is the commit message\n> request from Documentation/SubmittingPatches:\n\nAnd yet, nobody asked for that.\n\nAnyway, drop the patch then.\n\n-- \nFelipe Contreras\n"},{"id":"214558","messageId":"7v8v4ihw41.fsf@alter.siamese.dyndns.org","threadId":"33517","inReplyTo":"7vhaj7r116.fsf@alter.siamese.dyndns.org","subject":"\"What's cooking\" between #05 and #06","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-16T23:52:14Z","receivedAt":"2013-04-16T23:52:14Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Quick incremental report on tonight's integration status.\n\n> * jk/http-error-messages (2013-04-06) 9 commits\n> (merged to 'next' on 2013-04-11 at 7a03981)\n> ...\n> + http: add HTTP_KEEP_ERROR option\n>\n> Improve error reporting from the http transfer clients.\n\nPeff posted an update to this to fix a regression, which is parked\non 'next' for tonight.\n\n> * kb/status-ignored-optim-2 (2013-04-15) 14 commits\n> ...\n>\n> Rerolls kb/status-ignored-optim topic (reverted from 'next'). Not\n> merged to 'pu' as it heavily interferes with as/check-ignore topic.\n\nThis still has not been merged to 'pu' for the same reason.\n\n> * jk/remote-helper-with-signed-tags (2013-04-15) 3 commits\n> - transport-helper: add 'signed-tags' capability\n> - transport-helper: pass --signed-tags=warn-strip to fast-export\n> - fast-export: add --signed-tags=warn-strip mode\n\nThere were some comments on the noisiness of the warning output, but\nit appears that everybody involved in the area is basically happy\nwith the direction this series goes in, so I'll expect a reroll and\nthen merge it to 'next'.\n\n> * jn/gitweb-install-doc (2013-04-15) 1 commit\n> - gitweb/INSTALL: Simplify description of GITWEB_CONFIG_SYSTEM\n>\n> Reword gitweb configuration instrutions.\n\nThis hasn't been merged to 'next'.\n\nThere are a few competing proposals to further update it. I am\ninclined to take Jonathan's version.\n\n> * nd/pretty-formats (2013-04-01) 12 commits\n> ...\n\nUpdated the one in 'pu' with the reroll.\n\n> * fc/transport-helper-error-reporting (2013-04-11) 3 commits\n> - transport-helper: improve push messages\n> - transport-helper: mention helper name when it dies\n> - transport-helper: report errors properly\n>\n> Rerolled enough times. In-code comments may want to be further\n> extended to explain tricky parts, but seems to be ready otherwise.\n>\n> Will merge to 'next'.\n\nThis is in 'next' with the last one (missing from the above list)\nwith slightly tweaked commit log message.\n\n> * jk/submodule-subdirectory-ok (2013-04-10) 2 commits\n> - submodule: drop the top-level requirement\n> - rev-parse: add --prefix option\n>\n> Allow various subcommands of \"git submodule\" to be run not from the\n> top of the working tree of the superproject.\n>\n> Waiting for comments.\n\nAny submodule users wants to weigh in? The code looked fine, but I\ndo not heavily use it (and the repository with a submodule I have, I\ndo not have a \"subdirectory\" ;-, so I am a bad guinea pig).\n\n\n> * mv/sequencer-pick-error-diag (2013-04-11) 1 commit\n> - cherry-pick: make sure all input objects are commits\n>\n> \"git cherry-pick $blob $tree\" is diagnosed as a nonsense.\n>\n> Will merge to 'next'.\n\nThis, with the help with a fix to a long-standing issue in the\ncommand line parser for revisions from Thomas, is now in 'next'.\n\n> * fc/remote-hg (2013-04-11) 21 commits\n> ...\n> Rerolled.\n>\n> Waiting for comments.\n\nI think this has gone as far as it can go with the people who are\ninterested in reviewing this series on the list. It is in 'next'\nnow.\n\n> * nd/magic-pathspecs (2013-03-31) 45 commits\n> ...\n>\n> Migrate the rest of codebase to use \"struct pathspec\" more.\n\nStill out of 'pu' for the same reason as yesterday (and as\nkb/status-ignored-optim topic).\n"},{"id":"214571","messageId":"7vy5chhik6.fsf@alter.siamese.dyndns.org","threadId":"33517","inReplyTo":"CABURp0qGYG4T+t36=Us328YdLzy9KjBOWot2gSOk=FgCRUCLnQ@mail.gmail.com","subject":"Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-17T04:44:57Z","receivedAt":"2013-04-17T04:44:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Phil Hord writes:\n\n> ... Almost every time I bisect a regression\n> in git.git, I find the commit message tells me exactly why the commit\n> did what it did and what the expected result was. I find this to be\n> amazingly useful.\n> ...\n> Of course, 99% of the commit messages may never be useful to me or\n> anyone else. But we do not eschew them altogether. The 1% I have to\n> rely on are nearly always helpful and clear, and that is the part I\n> care about.\n\nIt is nice to be appreciated for our efforts by somebody every once\nin a while ;-)\n\nThanks.\n"},{"id":"214589","messageId":"20130417084037.GQ2278@serenity.lan","threadId":"33517","inReplyTo":"7v8v4ihw41.fsf@alter.siamese.dyndns.org","subject":"Re: \"What's cooking\" between #05 and #06","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-04-17T08:40:37Z","receivedAt":"2013-04-17T08:40:37Z","isPatch":false,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Tue, Apr 16, 2013 at 04:52:14PM -0700, Junio C Hamano wrote:\n> > * jk/remote-helper-with-signed-tags (2013-04-15) 3 commits\n> > - transport-helper: add 'signed-tags' capability\n> > - transport-helper: pass --signed-tags=warn-strip to fast-export\n> > - fast-export: add --signed-tags=warn-strip mode\n> \n> There were some comments on the noisiness of the warning output, but\n> it appears that everybody involved in the area is basically happy\n> with the direction this series goes in, so I'll expect a reroll and\n> then merge it to 'next'.\n\nWhat do you expect to change in the reroll? The only comments I've seen\nhave been about the warning output it seems to me that we've agreed to\nleave that as it is. Have I missed something?\n"},{"id":"214591","messageId":"20130417084901.GA7632@blizzard","threadId":"33517","inReplyTo":"7vhaj7r116.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)","fromName":"Lukas Fleischer","fromEmail":"git@cryptocrack.de","sentAt":"2013-04-17T08:49:01Z","receivedAt":"2013-04-17T08:49:01Z","isPatch":false,"sender":{"key":"git@cryptocrack.de","avatar":null},"body":"On Mon, Apr 15, 2013 at 01:28:53PM -0700, Junio C Hamano wrote:\n> Here are the topics that have been cooking. Commits prefixed with\n> '-' are only in 'pu' (proposed updates) while commits prefixed with\n> '+' are in 'next'.\n> [...]\n> --------------------------------------------------\n> [New Topics]\n> [...]\n> * lf/read-blob-data-from-index (2013-04-15) 3 commits\n> (merged to 'next' on 2013-04-15 at 09f92c6)\n> + convert.c: Remove duplicate code\n> + Add size parameter to read_blob_data_from_index_path()\n> + Add public function read_blob_data_from_index_path()\n> \n> Reduce duplicated code between convert.c and attr.c.\n> \n> Will merge to 'master'.\n\nNot sure if you care but the commit messages of these are all wrong now\nthat you squashed your API fix into the first commit. They all refer to\nread_blob_data_from_index_path() instead of read_blob_data_from_index()\nand most of the details mentioned in the first commit of this series no\nlonger apply...\n\nJust saying :)\n"},{"id":"214595","messageId":"87txn5xzdn.fsf@linux-k42r.v.cablecom.net","threadId":"33517","inReplyTo":"7vhaj7r116.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)","fromName":"Thomas Rast","fromEmail":"trast@inf.ethz.ch","sentAt":"2013-04-17T09:47:16Z","receivedAt":"2013-04-17T09:47:16Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Junio C Hamano writes:\n\n> * jc/add-2.0-delete-default (2013-03-08) 3 commits\n> - git add ... defaults to \"-A\"\n> (merged to 'next' on 2013-04-05 at 199442e)\n> + git add: start preparing for \"git add ...\" to default to \"-A\"\n> + builtin/add.c: simplify boolean variables\n>\n> In Git 2.0, \"git add pathspec\" will mean \"git add -A pathspec\". If\n> you did this in a working tree that tracks dir/lost and dir/another:\n>\n> $ rm dir/lost\n> $ edit dir/another\n> $ git add dir\n>\n> The last step will not only notices and records updated\n> dir/another, but also notices and records the removal of dir/lost\n> in the index.\n>\n> Start training the users for this change to say --no-all when they\n> want to ignore the removal to smooth the transition hump.\n>\n> Will merge to 'master' the early bits and cook the rest in 'next' until Git 2.0.\n\nThe warning triggers in some cases where it shouldn't, relating to\nsubmodules:\n\n $ git submodule add gitosis@git.csa.inf.ethz.ch:domjudge.git domjudge\n Adding existing repo at 'domjudge' to the index \n warning: In Git 2.0, 'git add ...' will also update the \n index for paths removed from the working tree that match \n the given pathspec. If you want to 'add' only changed \n or newly created paths, say 'git add --no-all ...' instead.\n\nIt also seems to hint that the problem is with giving a 'pathspec', but\nin fact in the case of a \"proper\" pathspec (that isn't an existing path)\nit does *not* trigger, even though it probably should:\n\n $ git ls-files\n foo\n $ rm foo\n $ git add 'f*'\n $ git status\n # On branch master\n # Changes not staged for commit:\n # (use \"git add/rm ...\" to update what will be committed)\n # (use \"git checkout -- ...\" to discard changes in working directory)\n #\n # deleted: foo\n #\n no changes added to commit (use \"git add\" and/or \"git commit -a\")\n $ git add -A 'f*'\n $ git status\n # On branch master\n # Changes to be committed:\n # (use \"git reset HEAD ...\" to unstage)\n #\n # deleted: foo\n #\n # Untracked files not listed (use -u option to show untracked files)\n\nThat's of course assuming that you want to unconditionally make -A the\ndefault.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"214611","messageId":"7vhaj5gpk6.fsf@alter.siamese.dyndns.org","threadId":"33517","inReplyTo":"20130417084901.GA7632@blizzard","subject":"Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-17T15:11:21Z","receivedAt":"2013-04-17T15:11:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Lukas Fleischer writes:\n\n> Not sure if you care but the commit messages of these are all wrong now\n> that you squashed your API fix into the first commit. They all refer to\n> read_blob_data_from_index_path()...\n\nOuch; thanks for noticing.\n"},{"id":"214612","messageId":"7vd2ttgoyr.fsf@alter.siamese.dyndns.org","threadId":"33517","inReplyTo":"87txn5xzdn.fsf@linux-k42r.v.cablecom.net","subject":"Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-17T15:24:12Z","receivedAt":"2013-04-17T15:24:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thomas Rast writes:\n\n> The warning triggers in some cases where it shouldn't, relating to\n> submodules:\n>\n> $ git submodule add gitosis@git.csa.inf.ethz.ch:domjudge.git domjudge\n> Adding existing repo at 'domjudge' to the index\n> warning: In Git 2.0, 'git add ...' will also update\n> the index for paths removed from the working tree that match\n> the given pathspec. If you want to 'add' only changed\n> or newly created paths, say 'git add --no-all ...' instead.\n\nGood one. So \"add\" used internally there needs to say --no-add?\n\n> It also seems to hint that the problem is with giving a 'pathspec', but\n> in fact in the case of a \"proper\" pathspec (that isn't an existing path)\n> it does *not* trigger, even though it probably should:\n\nWe have seen users who explicitly say:\n\n\tgit add dir\n\nafter removing dir/del and adding dir/ins got surprised that we do\nnot notice removal of dir/del without \"add -A\". And it is fairly\nstraight-forward to check and warn for such a case.\n\n> That's of course assuming that you want to unconditionally make -A the\n> default.\n\nI thought what the warning text says is what we decided to do\neventually. Not \"unconditionally\", but \"with \", but not\n\"only with pathspec that exactly matches an existing path\". It\nappears that we would better discuss and decide such details\nfurther, so let's revert the \"warn early\" bits from master and kick\nthe topic back.\n"},{"id":"214614","messageId":"7vzjwxfa4m.fsf@alter.siamese.dyndns.org","threadId":"33517","inReplyTo":"20130417084037.GQ2278@serenity.lan","subject":"Re: \"What's cooking\" between #05 and #06","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-17T15:30:01Z","receivedAt":"2013-04-17T15:30:01Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"John Keeping writes:\n\n> On Tue, Apr 16, 2013 at 04:52:14PM -0700, Junio C Hamano wrote:\n>> > * jk/remote-helper-with-signed-tags (2013-04-15) 3 commits\n>> > - transport-helper: add 'signed-tags' capability\n>> > - transport-helper: pass --signed-tags=warn-strip to fast-export\n>> > - fast-export: add --signed-tags=warn-strip mode\n>> \n>> There were some comments on the noisiness of the warning output, but\n>> it appears that everybody involved in the area is basically happy\n>> with the direction this series goes in, so I'll expect a reroll and\n>> then merge it to 'next'.\n>\n> What do you expect to change in the reroll? The only comments I've seen\n> have been about the warning output it seems to me that we've agreed to\n> leave that as it is. Have I missed something?\n\nYou missed the sender timestamp of the message you are responding\nto, and that of the discussion we later agreed there is nothing to\nchange ;-)\n"},{"id":"214618","messageId":"87wqs1xi9h.fsf@hexa.v.cablecom.net","threadId":"33517","inReplyTo":"7vd2ttgoyr.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)","fromName":"Thomas Rast","fromEmail":"trast@inf.ethz.ch","sentAt":"2013-04-17T15:56:58Z","receivedAt":"2013-04-17T15:56:58Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Junio C Hamano writes:\n\n> Thomas Rast writes:\n>\n>> The warning triggers in some cases where it shouldn't, relating to\n>> submodules:\n>>\n>> $ git submodule add gitosis@git.csa.inf.ethz.ch:domjudge.git domjudge\n>> Adding existing repo at 'domjudge' to the index\n>> warning: In Git 2.0, 'git add ...' will also update\n>> the index for paths removed from the working tree that match\n>> the given pathspec. If you want to 'add' only changed\n>> or newly created paths, say 'git add --no-all ...' instead.\n>\n> Good one. So \"add\" used internally there needs to say --no-add?\n\nI think the logic in git-add needs to learn about submodules. The same\nwarning later trigger when you later say 'git add submoduledir', even\nthough that obviously doesn't walk inside the submodule.\n\n>> It also seems to hint that the problem is with giving a 'pathspec', but\n>> in fact in the case of a \"proper\" pathspec (that isn't an existing path)\n>> it does *not* trigger, even though it probably should:\n>\n> We have seen users who explicitly say:\n>\n> \tgit add dir\n>\n> after removing dir/del and adding dir/ins got surprised that we do\n> not notice removal of dir/del without \"add -A\". And it is fairly\n> straight-forward to check and warn for such a case.\n\nI can see that problem, but along the same lines, why shouldn't I have\nan expectation that when I say 'git add \"*.py\"' it removes stuff that I\nhave removed? That's what I tried to show with the f?o example.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"214621","messageId":"7vk3o1f5kb.fsf@alter.siamese.dyndns.org","threadId":"33517","inReplyTo":"87wqs1xi9h.fsf@hexa.v.cablecom.net","subject":"Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-17T17:08:36Z","receivedAt":"2013-04-17T17:08:36Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thomas Rast writes:\n\n> I can see that problem, but along the same lines, why shouldn't I have\n> an expectation that when I say 'git add \"*.py\"' it removes stuff that I\n> have removed?\n\nYou _should_ have that expectation.\n\nIf it does not remove with the code that has been prepared for 2.0\n(that is a bit beyond 'next'), then it is a big problem, but I think\nit does remove the removed python source without \"-A\", as long as\nyou give a pathspec \"*.py\" (with quotes around it) that match it.\n\nI think it is just the warning code avoiding extra complexity and\noverhead, if you are talking about not getting warning in the\npre-2.0 step that is in 'next'. Patches are very much welcomed,\nespecially the ones that come before I get around to it ;-)\n"},{"id":"214627","messageId":"7vwqs1dnxp.fsf@alter.siamese.dyndns.org","threadId":"33517","inReplyTo":"7vk3o1f5kb.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-17T18:14:42Z","receivedAt":"2013-04-17T18:14:42Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Thomas Rast writes:\n>\n>> I can see that problem, but along the same lines, why shouldn't I have\n>> an expectation that when I say 'git add \"*.py\"' it removes stuff that I\n>> have removed?\n>\n> You _should_ have that expectation.\n>\n> If it does not remove with the code that has been prepared for 2.0\n> (that is a bit beyond 'next'), then it is a big problem, but I think\n> it does remove the removed python source without \"-A\", as long as\n> you give a pathspec \"*.py\" (with quotes around it) that match it.\n>\n> I think it is just the warning code avoiding extra complexity and\n> overhead, if you are talking about not getting warning in the\n> pre-2.0 step that is in 'next'. Patches are very much welcomed,\n> especially the ones that come before I get around to it ;-)\n\nI took a brief look at the code, and as you said \"add\" needs to know\nabout submodules, and the best fix looks to me to take the same\napproach Jonathan came up with to de-noise the \"add -u/-A\" topic.\n\nThat is, to scan the working tree to actually see if we would record\nremovals to the index in 2.0, but not remove them in this current\nversion, and give the warning when the differences in the behaviours\nmatter.\n"},{"id":"214631","messageId":"CAMP44s3pZt3QVjS7GbXqjMS4ti3p=Vs2DmFXQjsMM3rs9qURmw@mail.gmail.com","threadId":"33517","inReplyTo":"CABURp0qGYG4T+t36=Us328YdLzy9KjBOWot2gSOk=FgCRUCLnQ@mail.gmail.com","subject":"Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-17T18:50:50Z","receivedAt":"2013-04-17T18:50:50Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, Apr 16, 2013 at 5:45 PM, Phil Hord wrote:\n> On Tue, Apr 16, 2013 at 3:04 PM, Felipe Contreras\n> wrote:\n>> On Tue, Apr 16, 2013 at 4:59 AM, Thomas Rast wrote:\n>>> A cursory look^W^Wreview of the messages in fc/remote-hg:\n>>\n>> [skipping irrelevant comments]\n>>\n>> I'm sorry, did you actually hit an issue that required to look at the\n>> commit message to understand where the issue came from? No? Then I\n>> won't bother with hypotheticals.\n>>\n>> If you want to waste your time, by all means, rewrite all my commit\n>> messages with essays that nobody will ever read. I'm not going to do\n>> that for some hypothetical case that will never happen. I'm not going\n>> to waste my time.\n>\n> This is not a hypothetical. Almost every time I bisect a regression\n> in git.git, I find the commit message tells me exactly why the commit\n> did what it did and what the expected result was. I find this to be\n> amazingly useful. Do I need to show you real instances of that\n> happening? No. I promise it did, though.\n\nYes please. Show me one of the instances where you hit a bisect with\nany of the remote-hg commits mentioned above by Thomas Rast.\n\n> Of course, 99% of the commit messages may never be useful to me or\n> anyone else. But we do not eschew them altogether. The 1% I have to\n> rely on are nearly always helpful and clear, and that is the part I\n> care about.\n\nAnd how do you know this will be part of the 1%? You don't. How many\ntimes have you tracked regressions in transport helper's import/export\nfunctionality? How many times in remote-hg? How many times has\n*anybody* done so?\n\n> If you will not waste your time to write a decent commit message, why\n> do you waste our time asking us to review and accept ill-defined\n> patches?\n\nBecause it *fixes a problem*. And a commit essay doesn't fix any,\nbecause nobody will ever go back in history and wonder, hey, what is\nup with this commit. If somebody does, then I will accept that commit\nessays are always a must. But it won't happen.\n\n> Here, of course, I use the royal \"us\" as I do not review\n> your patches. I do not know why that is; I suppose you patch things\n> outside of my interests, but it may also be that your patches are\n> simply incomprehensible by design.\n\nYeah, but that's the thing, if you don't understand the code the\npatches are changing, then how can you know the commit message is\nsufficient to figure things out when a regression is found? You don't.\nYou can't.\n\nLet's face the truth, you are advocating for stopping progress on the\nname that something might happen sometime in the feature, although\nmost likely won't. When in reality, it just won't.\n\nAnd you are not saying \"it would be nice to have full commit essay\",\nyou are saying: \"without a commit essay this patch should NOT be\nmerged\", even more \"without a commit essay this patch should NOT be\nconsidered a cooking patch\".\n\nI think the commit message is fine, you don't. So YOU go ahead and\nwrite the proper one. If you don't, all you are doing is being an\nimpediment to progress.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"214637","messageId":"20130417201056.GA2914@sigill.intra.peff.net","threadId":"33517","inReplyTo":"7vwqs1dnxp.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-04-17T20:10:56Z","receivedAt":"2013-04-17T20:10:56Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Apr 17, 2013 at 11:14:42AM -0700, Junio C Hamano wrote:\n\n> > I think it is just the warning code avoiding extra complexity and\n> > overhead, if you are talking about not getting warning in the\n> > pre-2.0 step that is in 'next'. Patches are very much welcomed,\n> > especially the ones that come before I get around to it ;-)\n> \n> I took a brief look at the code, and as you said \"add\" needs to know\n> about submodules, and the best fix looks to me to take the same\n> approach Jonathan came up with to de-noise the \"add -u/-A\" topic.\n> \n> That is, to scan the working tree to actually see if we would record\n> removals to the index in 2.0, but not remove them in this current\n> version, and give the warning when the differences in the behaviours\n> matter.\n\nYeah, I had the same thought, as this warning has been bugging me for\nthe last day or two. The worst part about it is that I finally trained\nmyself to type \"git add .\" to silence the _other_ warning, and now it\ntriggers this one. :)\n\n-Peff\n"},{"id":"214643","messageId":"516F1333.5070804@web.de","threadId":"33517","inReplyTo":"7v8v4ihw41.fsf@alter.siamese.dyndns.org","subject":"Re: \"What's cooking\" between #05 and #06","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2013-04-17T21:25:07Z","receivedAt":"2013-04-17T21:25:07Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 17.04.2013 01:52, schrieb Junio C Hamano:\n>> * jk/submodule-subdirectory-ok (2013-04-10) 2 commits\n>> - submodule: drop the top-level requirement\n>> - rev-parse: add --prefix option\n>>\n>> Allow various subcommands of \"git submodule\" to be run not from the\n>> top of the working tree of the superproject.\n>>\n>> Waiting for comments.\n> \n> Any submodule users wants to weigh in? The code looked fine, but I\n> do not heavily use it (and the repository with a submodule I have, I\n> do not have a \"subdirectory\" ;-, so I am a bad guinea pig).\n\nI like it, as it gets rid of the top-level requirement. But from\nmy testing it looks like we're not quite there yet.\n\n'summary' and 'status' behave as if they were run in the toplevel\ndirectory, while a \"git status\" shows all filenames relative to the\ncurrent directory. Me thinks 'summary' and 'status' (and all other\nsubmodule commands) should behave like status and print relative\npaths too. I'm not really sure yet how $sm_path should behave for\n'foreach', but I suspect having it relative to the current\ndirectory would be the way to go (which it currently isn't).\n\nWhen \"submodule add\" is run with a relative path it is relative to\nthe top-level directory, which I find confusing (and won't play\nwell with shell completion).\n\n'deinit .' doesn't deinit submodules above the current directory\n(but prints the path relative to top-level) while 'init' will\ninitialize all submodules known to the superproject.\n\nSo this is a good start, but it looks like there is some work left\nto do before this can hit master.\n"},{"id":"214654","messageId":"7vsj2od841.fsf@alter.siamese.dyndns.org","threadId":"33517","inReplyTo":"CAMP44s3pZt3QVjS7GbXqjMS4ti3p=Vs2DmFXQjsMM3rs9qURmw@mail.gmail.com","subject":"Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-17T23:56:30Z","receivedAt":"2013-04-17T23:56:30Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> And how do you know this will be part of the 1%? You don't. How many\n> times have you tracked regressions in transport helper's import/export\n> functionality? How many times in remote-hg? How many times has\n> *anybody* done so?\n\nThe last point makes it all the more important to have a good\nhistory [*1*]. An area that no developer rarely touches with a little\nuser base can stay dormant for a long time, and when people do need\nto hunt for an ancient bug or to enhance the existing feature to\nsupport a new use case without breaking the old use case, the\noriginal author may not be around, lost interest, or no longer uses\nhis own creation.\n\nThe code left behind tells us what the author thought was the best\nway to solve his problem, but it does not clearly define what the\nproblem he tried to solve was, within what constraint he had to find\na solution for it, and why he thought that the solution was the best\n(or sometimes \"only\") one. Log and in-code comments are to explain\nsuch things that are beyond how the code works and what it does.\n\n\n[Footnote]\n\n*1* In this message, I am not judging if the depth of your writing\n for the particular change is deep enough. It depends on how well\n the reader knows the area, and there is no single right answer\n to that question.\n \n Incidentally that is why we tend to err on the more descriptive\n side. The next person your commit will help may not know the\n area as well as you do and has to figure things out on his\n own. You are helping him by being descriptive.\n"},{"id":"214665","messageId":"7va9owd3d1.fsf@alter.siamese.dyndns.org","threadId":"33517","inReplyTo":"20130417201056.GA2914@sigill.intra.peff.net","subject":"Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-18T01:39:06Z","receivedAt":"2013-04-18T01:39:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> Yeah, I had the same thought, as this warning has been bugging me for\n> the last day or two. The worst part about it is that I finally trained\n> myself to type \"git add .\" to silence the _other_ warning, and now it\n> triggers this one. :)\n\nSo here is the \"reworked\" one on top of what is in 'next'.\n\nIt introduces a bit of conflict with the \"add -u/-A\" topic, so I am\nnot ready to push out the integration result yet.\n\n-- >8 --\nSubject: [PATCH] git add: rework the logic to warn \"git add ...\" default change\n\nThe earlier logic to warn against \"git add subdir\" that is run\nwithout \"-A\" or \"--no-all\" was only to check any given\nexactly spells a directory name that (still) exists on the\nfilesystem. This had number of problems:\n\n * \"git add '*dir'\" (note that the wildcard is hidden from the\n shell) would not trigger the warning.\n\n * \"git add '*.py'\" would behave differently between the current\n version of Git and Git 2.0 for the same reason as \"subdir\", but\n would not trigger the warning.\n\n * \"git add dir\" for a submodule \"dir\" would just update the index\n entry for the submodule \"dir\" without ever recursing into it, and\n use of \"-A\" or \"--no-all\" would matter. But the logic only\n checks the directory-ness of \"dir\" and gives an unnecessary\n warning.\n\nRework the logic to detect the case where the behaviour will be\ndifferent in Git 2.0, and issue a warning only when it matters.\nEven with the code before this warning, \"git add subdir\" will have\nto traverse the directory in order to find _new_ files the index\ndoes not know about _anyway_, so we can do this check without adding\nan extra pass to find if matches any removed file.\n\nThis essentially updates the \"add_files_to_cache()\" public API to\n\"update_files_in_cache()\" API that is internal to \"git add\", because\nwith the \"--all\" option, the function is no longer about \"adding\"\npaths to the cache, but is also used to remove them.\n\nThere are other callers of the former from \"checkout\" (used when\n\"checkout -m\" prepares the temporary tree that represents the local\nmodifications to be merged) and \"commit\" (\"commit --include\" that\npicks up local changes in addition to what is in the index). Since\nADD_CACHE_IGNORE_ERRORS (aka \"--no-all\") is not used by either of\nthem, once dust settles after Git 2.0 and the warning becomes\nunnecessary, we may want to unify these two functions again.\n\nSigned-off-by: Junio C Hamano \n---\n builtin/add.c | 64 +++++++++++++++++++++++++++++++++++------------------------\n 1 file changed, 38 insertions(+), 26 deletions(-)\n\ndiff --git a/builtin/add.c b/builtin/add.c\nindex f8f6c9e..4242bce 100644\n--- a/builtin/add.c\n+++ b/builtin/add.c\n@@ -26,6 +26,9 @@ static int take_worktree_changes;\n struct update_callback_data {\n \tint flags;\n \tint add_errors;\n+\n+\t/* only needed for 2.0 transition preparation */\n+\tint warn_add_would_remove;\n };\n \n static int fix_unmerged_status(struct diff_filepair *p,\n@@ -49,6 +52,17 @@ static int fix_unmerged_status(struct diff_filepair *p,\n \t\treturn DIFF_STATUS_MODIFIED;\n }\n \n+static void warn_add_would_remove(const char *path)\n+{\n+\twarning(_(\"In Git 2.0, 'git add ...' will also update the\\n\"\n+\t\t \"index for paths removed from the working tree that match\\n\"\n+\t\t \"the given pathspec. If you want to 'add' only changed\\n\"\n+\t\t \"or newly created paths, say 'git add --no-all ...'\"\n+\t\t \" instead.\\n\\n\"\n+\t\t \"'%s' would be removed from the index without --no-all.\"),\n+\t\tpath);\n+}\n+\n static void update_callback(struct diff_queue_struct *q,\n \t\t\t struct diff_options *opt, void *cbdata)\n {\n@@ -70,6 +84,10 @@ static void update_callback(struct diff_queue_struct *q,\n \t\t\t}\n \t\t\tbreak;\n \t\tcase DIFF_STATUS_DELETED:\n+\t\t\tif (data->warn_add_would_remove) {\n+\t\t\t\twarn_add_would_remove(path);\n+\t\t\t\tdata->warn_add_would_remove = 0;\n+\t\t\t}\n \t\t\tif (data->flags & ADD_CACHE_IGNORE_REMOVAL)\n \t\t\t\tbreak;\n \t\t\tif (!(data->flags & ADD_CACHE_PRETEND))\n@@ -81,20 +99,27 @@ static void update_callback(struct diff_queue_struct *q,\n \t}\n }\n \n-int add_files_to_cache(const char *prefix, const char **pathspec, int flags)\n+static void update_files_in_cache(const char *prefix, const char **pathspec,\n+\t\t\t\t struct update_callback_data *data)\n {\n-\tstruct update_callback_data data;\n \tstruct rev_info rev;\n \tinit_revisions(&rev, prefix);\n \tsetup_revisions(0, NULL, &rev, NULL);\n \tinit_pathspec(&rev.prune_data, pathspec);\n \trev.diffopt.output_format = DIFF_FORMAT_CALLBACK;\n \trev.diffopt.format_callback = update_callback;\n-\tdata.flags = flags;\n-\tdata.add_errors = 0;\n-\trev.diffopt.format_callback_data = &data;\n+\trev.diffopt.format_callback_data = data;\n \trev.max_count = 0; /* do not compare unmerged paths with stage #2 */\n \trun_diff_files(&rev, DIFF_RACY_IS_MODIFIED);\n+}\n+\n+int add_files_to_cache(const char *prefix, const char **pathspec, int flags)\n+{\n+\tstruct update_callback_data data;\n+\n+\tmemset(&data, 0, sizeof(data));\n+\tdata.flags = flags;\n+\tupdate_files_in_cache(prefix, pathspec, &data);\n \treturn !!data.add_errors;\n }\n \n@@ -354,18 +379,6 @@ static void warn_pathless_add(const char *option_name, const char *short_name) {\n \t\toption_name, short_name);\n }\n \n-static int directory_given(int argc, const char **argv)\n-{\n-\tstruct stat st;\n-\n-\twhile (argc--) {\n-\t\tif (!lstat(*argv, &st) && S_ISDIR(st.st_mode))\n-\t\t\treturn 1;\n-\t\targv++;\n-\t}\n-\treturn 0;\n-}\n-\n int cmd_add(int argc, const char **argv, const char *prefix)\n {\n \tint exit_status = 0;\n@@ -378,6 +391,7 @@ int cmd_add(int argc, const char **argv, const char *prefix)\n \tchar *seen = NULL;\n \tconst char *option_with_implicit_dot = NULL;\n \tconst char *short_option_with_implicit_dot = NULL;\n+\tstruct update_callback_data update_data;\n \n \tgit_config(add_config, NULL);\n \n@@ -403,15 +417,11 @@ int cmd_add(int argc, const char **argv, const char *prefix)\n \n \t/*\n \t * Warn when \"git add pathspec...\" was given without \"-u\" or \"-A\"\n-\t * and pathspec... contains a directory name.\n+\t * and pathspec... covers a removed path.\n \t */\n-\tif (!take_worktree_changes && addremove_explicit < 0 &&\n-\t directory_given(argc, argv))\n-\t\twarning(_(\"In Git 2.0, 'git add ...' will also update the\\n\"\n-\t\t\t \"index for paths removed from the working tree that match\\n\"\n-\t\t\t \"the given pathspec. If you want to 'add' only changed\\n\"\n-\t\t\t \"or newly created paths, say 'git add --no-all ...'\"\n-\t\t\t \" instead.\"));\n+\tmemset(&update_data, 0, sizeof(update_data));\n+\tif (!take_worktree_changes && addremove_explicit < 0)\n+\t\tupdate_data.warn_add_would_remove = 1;\n \n \tif (!take_worktree_changes && addremove_explicit < 0 && argc)\n \t\t/*\n@@ -508,8 +518,10 @@ int cmd_add(int argc, const char **argv, const char *prefix)\n \n \tplug_bulk_checkin();\n \n-\texit_status |= add_files_to_cache(prefix, pathspec, flags);\n+\tupdate_data.flags = flags;\n+\tupdate_files_in_cache(prefix, pathspec, &update_data);\n \n+\texit_status |= !!update_data.add_errors;\n \tif (add_new_files)\n \t\texit_status |= add_files(&dir, flags);\n \n-- \n1.8.2.1-552-g964983e\n"},{"id":"214667","messageId":"7v1ua8d2zn.fsf_-_@alter.siamese.dyndns.org","threadId":"33517","inReplyTo":"7va9owd3d1.fsf@alter.siamese.dyndns.org","subject":"[PATCH] git add ... defaults to \"-A\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-18T01:47:08Z","receivedAt":"2013-04-18T01:47:08Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Make \"git add ...\" notice paths that have been removed\nfrom the working tree, i.e. a synonym to \"git add -A ...\".\n\nGiven that \"git add \" is to update the index with the\nstate of the named part of the working tree as a whole, it makes it\nmore intuitive, and also makes it possible to simplify the advice we\ngive while marking the paths the user finished resolving conflicts\nwith. We used to say \"to record removal as a resolution, remove the\npath from the working tree and say 'git rm'; for all other cases,\nedit the path in the working tree and say 'git add'\", but we can now\nsay \"update the path in the working tree and say 'git add'\" instead.\n\nAs promised, this merges the temporary update_files_in_cache() helper\nfunction back to add_files_to_cache() function.\n\nSigned-off-by: Junio C Hamano \n---\n\n * So this comes on top of the previous update that will sit at\n jc/add-2.0-delete-default~1 and replaces the one previouly at its\n tip.\n\n Documentation/git-add.txt | 18 +++++++++------\n builtin/add.c | 57 ++++++++---------------------------------------\n 2 files changed, 20 insertions(+), 55 deletions(-)\n\ndiff --git a/Documentation/git-add.txt b/Documentation/git-add.txt\nindex 5c501a2..5bd0791 100644\n--- a/Documentation/git-add.txt\n+++ b/Documentation/git-add.txt\n@@ -53,8 +53,14 @@ OPTIONS\n \tFiles to add content from. Fileglobs (e.g. `*.c`) can\n \tbe given to add all matching files. Also a\n \tleading directory name (e.g. `dir` to add `dir/file1`\n-\tand `dir/file2`) can be given to add all files in the\n-\tdirectory, recursively.\n+\tand `dir/file2`) can be given to update the index to\n+\tmatch the current state of the directory as a whole (e.g.\n+\tspecifying `dir` will record not just a file `dir/file1`\n+\tmodified in the working tree, a file `dir/file2` added to\n+\tthe working tree, but also a file `dir/file3` removed from\n+\tthe working tree. Note that older versions of \tGit used\n+\tto ignore removed files; use `--no-all` option if you want\n+\tto add modified or new files but ignore removed\tones.\n \n -n::\n --dry-run::\n@@ -127,11 +133,9 @@ of Git, hence the form without should not be used.\n \tfiles that have been removed from the working tree. This\n \toption is a no-op when no is used.\n +\n-This option is primarily to help the current users of Git, whose\n-\"git add ...\" ignores removed files. In future versions\n-of Git, \"git add ...\" will be a synonym to \"git add -A\n-...\" and \"git add --no-all ...\" will behave like\n-today's \"git add ...\", ignoring removed files.\n+This option is primarily to help users who are used to older\n+versions of Git, whose \"git add ...\" was a synonym\n+to \"git add --no-all ...\", i.e. ignored removed files.\n \n -N::\n --intent-to-add::\ndiff --git a/builtin/add.c b/builtin/add.c\nindex 4242bce..21c685f 100644\n--- a/builtin/add.c\n+++ b/builtin/add.c\n@@ -26,9 +26,6 @@ static int take_worktree_changes;\n struct update_callback_data {\n \tint flags;\n \tint add_errors;\n-\n-\t/* only needed for 2.0 transition preparation */\n-\tint warn_add_would_remove;\n };\n \n static int fix_unmerged_status(struct diff_filepair *p,\n@@ -52,17 +49,6 @@ static int fix_unmerged_status(struct diff_filepair *p,\n \t\treturn DIFF_STATUS_MODIFIED;\n }\n \n-static void warn_add_would_remove(const char *path)\n-{\n-\twarning(_(\"In Git 2.0, 'git add ...' will also update the\\n\"\n-\t\t \"index for paths removed from the working tree that match\\n\"\n-\t\t \"the given pathspec. If you want to 'add' only changed\\n\"\n-\t\t \"or newly created paths, say 'git add --no-all ...'\"\n-\t\t \" instead.\\n\\n\"\n-\t\t \"'%s' would be removed from the index without --no-all.\"),\n-\t\tpath);\n-}\n-\n static void update_callback(struct diff_queue_struct *q,\n \t\t\t struct diff_options *opt, void *cbdata)\n {\n@@ -84,10 +70,6 @@ static void update_callback(struct diff_queue_struct *q,\n \t\t\t}\n \t\t\tbreak;\n \t\tcase DIFF_STATUS_DELETED:\n-\t\t\tif (data->warn_add_would_remove) {\n-\t\t\t\twarn_add_would_remove(path);\n-\t\t\t\tdata->warn_add_would_remove = 0;\n-\t\t\t}\n \t\t\tif (data->flags & ADD_CACHE_IGNORE_REMOVAL)\n \t\t\t\tbreak;\n \t\t\tif (!(data->flags & ADD_CACHE_PRETEND))\n@@ -99,27 +81,20 @@ static void update_callback(struct diff_queue_struct *q,\n \t}\n }\n \n-static void update_files_in_cache(const char *prefix, const char **pathspec,\n-\t\t\t\t struct update_callback_data *data)\n+int add_files_to_cache(const char *prefix, const char **pathspec, int flags)\n {\n+\tstruct update_callback_data data;\n \tstruct rev_info rev;\n \tinit_revisions(&rev, prefix);\n \tsetup_revisions(0, NULL, &rev, NULL);\n \tinit_pathspec(&rev.prune_data, pathspec);\n \trev.diffopt.output_format = DIFF_FORMAT_CALLBACK;\n \trev.diffopt.format_callback = update_callback;\n-\trev.diffopt.format_callback_data = data;\n+\tdata.flags = flags;\n+\tdata.add_errors = 0;\n+\trev.diffopt.format_callback_data = &data;\n \trev.max_count = 0; /* do not compare unmerged paths with stage #2 */\n \trun_diff_files(&rev, DIFF_RACY_IS_MODIFIED);\n-}\n-\n-int add_files_to_cache(const char *prefix, const char **pathspec, int flags)\n-{\n-\tstruct update_callback_data data;\n-\n-\tmemset(&data, 0, sizeof(data));\n-\tdata.flags = flags;\n-\tupdate_files_in_cache(prefix, pathspec, &data);\n \treturn !!data.add_errors;\n }\n \n@@ -298,7 +273,7 @@ N_(\"The following paths are ignored by one of your .gitignore files:\\n\");\n static int verbose, show_only, ignored_too, refresh_only;\n static int ignore_add_errors, intent_to_add, ignore_missing;\n \n-#define ADDREMOVE_DEFAULT 0 /* Change to 1 in Git 2.0 */\n+#define ADDREMOVE_DEFAULT 1\n static int addremove = ADDREMOVE_DEFAULT;\n static int addremove_explicit = -1; /* unspecified */\n \n@@ -391,7 +366,6 @@ int cmd_add(int argc, const char **argv, const char *prefix)\n \tchar *seen = NULL;\n \tconst char *option_with_implicit_dot = NULL;\n \tconst char *short_option_with_implicit_dot = NULL;\n-\tstruct update_callback_data update_data;\n \n \tgit_config(add_config, NULL);\n \n@@ -415,20 +389,9 @@ int cmd_add(int argc, const char **argv, const char *prefix)\n \tif (addremove && take_worktree_changes)\n \t\tdie(_(\"-A and -u are mutually incompatible\"));\n \n-\t/*\n-\t * Warn when \"git add pathspec...\" was given without \"-u\" or \"-A\"\n-\t * and pathspec... covers a removed path.\n-\t */\n-\tmemset(&update_data, 0, sizeof(update_data));\n-\tif (!take_worktree_changes && addremove_explicit < 0)\n-\t\tupdate_data.warn_add_would_remove = 1;\n-\n \tif (!take_worktree_changes && addremove_explicit < 0 && argc)\n-\t\t/*\n-\t\t * Turn \"git add pathspec...\" to \"git add -A pathspec...\"\n-\t\t * in Git 2.0 but not yet\n-\t\t */\n-\t\t; /* addremove = 1; */\n+\t\t/* Turn \"git add pathspec...\" to \"git add -A pathspec...\" */\n+\t\taddremove = 1;\n \n \tif (!show_only && ignore_missing)\n \t\tdie(_(\"Option --ignore-missing can only be used together with --dry-run\"));\n@@ -518,10 +481,8 @@ int cmd_add(int argc, const char **argv, const char *prefix)\n \n \tplug_bulk_checkin();\n \n-\tupdate_data.flags = flags;\n-\tupdate_files_in_cache(prefix, pathspec, &update_data);\n+\texit_status |= add_files_to_cache(prefix, pathspec, flags);\n \n-\texit_status |= !!update_data.add_errors;\n \tif (add_new_files)\n \t\texit_status |= add_files(&dir, flags);\n \n-- \n1.8.2.1-552-g964983e\n"},{"id":"214668","messageId":"CAMP44s0q4k+bjQDhWAiYoj2P+7PJqFRs9s0arhy+F7YDO50dZg@mail.gmail.com","threadId":"33517","inReplyTo":"7vsj2od841.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-18T03:59:58Z","receivedAt":"2013-04-18T03:59:58Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Wed, Apr 17, 2013 at 6:56 PM, Junio C Hamano wrote:\n> Felipe Contreras writes:\n>\n>> And how do you know this will be part of the 1%? You don't. How many\n>> times have you tracked regressions in transport helper's import/export\n>> functionality? How many times in remote-hg? How many times has\n>> *anybody* done so?\n>\n> The last point makes it all the more important to have a good\n> history [*1*]. An area that no developer rarely touches with a little\n> user base can stay dormant for a long time, and when people do need\n> to hunt for an ancient bug or to enhance the existing feature to\n> support a new use case without breaking the old use case, the\n> original author may not be around, lost interest, or no longer uses\n> his own creation.\n\nYou are going in circles, I said such situation was *HYPOTHETICAL*,\nPhil Hord said it wasn't, and now you are bringing back more\nhypothetical examples, which I would gladly address, as soon as you\naccept they are HYPOTHETICAL.\n\nNow, how about you answer the questions about the *REAL* situations\nPhil Hord mentioned?\n\n* How many times have you tracked regressions in transport helper's\nimport/export functionality?\n\nHint: zero.\n\n* How many times in remote-hg?\n\nHint: zero.\n\n* How many times has *anybody* done so?\n\nHint: other than me, quite possibly zero.\n\nAnd then, before we consider this *hypothetical* situation, it might\nbe worth noticing what commit this hypothetical person would hit if\nyou do *not* apply this patch, and what the commit message says:\n\n---\nremote-helpers: add support for an export command\n\nSigned-off-by: Junio C Hamano \n---\n\nYeah, well, glad you didn't apply my patch, wouldn't want to mess up\nthe code that was clearly explained by that commit message.\n\nAnd before you rationalize the above commit, because maybe the\nfunctionality was described in the documentation, it wasn't:\n\n transport-helper.c | 132\n++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-----------\n 1 file changed, 120 insertions(+), 12 deletions(-)\n\nIf you do apply my patch, it turns out even the shortest version of my\ncommit message already gives more information to this *hypothetical*\ndeveloper person.\n\n> [Footnote]\n>\n> *1* In this message, I am not judging if the depth of your writing\n> for the particular change is deep enough. It depends on how well\n> the reader knows the area, and there is no single right answer\n> to that question.\n>\n> Incidentally that is why we tend to err on the more descriptive\n> side. The next person your commit will help may not know the\n> area as well as you do and has to figure things out on his\n> own. You are helping him by being descriptive.\n\nI partially agree with this, but I think documenting the nuts and\nbolts of transport-helper would be better in done in code,\ndocumentation, tests, and mailing list analysis. And in all those\nrespects, I believe I've done a more than adequate job.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"214687","messageId":"vpq61zk8er7.fsf@grenoble-inp.fr","threadId":"33517","inReplyTo":"CAMP44s0q4k+bjQDhWAiYoj2P+7PJqFRs9s0arhy+F7YDO50dZg@mail.gmail.com","subject":"Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-04-18T07:44:12Z","receivedAt":"2013-04-18T07:44:12Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Felipe Contreras writes:\n\n> * How many times have you tracked regressions in transport helper's\n> import/export functionality?\n>\n> Hint: zero.\n\nThe real question to make the situation non-hypothetical would actually\nbe \"how many times did you track a regression that bisected down to\n*this particular commit*\". Any regression that ends up on another commit\nis irrelevant.\n\nI guess you realize how stupid my argument is. But how is yours\ndifferent? You do realize that your claim that nobody is ever going to\nbisect down to your commit is as hypothetical as other people's claim\n(if you think it is not, then try to point us a proof that nobody is\never going to need a good message in the future to understand what I\nmean).\n\nWe're trying to make all the code and all the commits clean. It seems to\nbe a consensus here that review is good. I see no reason to purposely\nmake some commits less good than others based on the fact that they may\nnot be used in the future.\n\nSearch your favorite search engine for \"broken window principle\" to get\nmore arguments in this direction.\n\n> * How many times has *anybody* done so?\n>\n> Hint: other than me, quite possibly zero.\n\nIf you want to be the only developer, and avoid being disturbed by\nothers, then why are you pushing your changes to git.git? Why are you\neven discussing on this list?\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"214695","messageId":"20130418084923.GT2278@serenity.lan","threadId":"33517","inReplyTo":"516F1333.5070804@web.de","subject":"Re: \"What's cooking\" between #05 and #06","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-04-18T08:49:23Z","receivedAt":"2013-04-18T08:49:23Z","isPatch":false,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Wed, Apr 17, 2013 at 11:25:07PM +0200, Jens Lehmann wrote:\n> I like it, as it gets rid of the top-level requirement. But from\n> my testing it looks like we're not quite there yet.\n> \n> 'summary' and 'status' behave as if they were run in the toplevel\n> directory, while a \"git status\" shows all filenames relative to the\n> current directory. Me thinks 'summary' and 'status' (and all other\n> submodule commands) should behave like status and print relative\n> paths too. I'm not really sure yet how $sm_path should behave for\n> 'foreach', but I suspect having it relative to the current\n> directory would be the way to go (which it currently isn't).\n>\n> When \"submodule add\" is run with a relative path it is relative to\n> the top-level directory, which I find confusing (and won't play\n> well with shell completion).\n\nThis confused me for a bit because I was sure I handled this, but I see\nI missed relative submodules URLs. So the path at which to put the\nsubmodule is correct, but the path from which to clone is not.\n\n> 'deinit .' doesn't deinit submodules above the current directory\n> (but prints the path relative to top-level) while 'init' will\n> initialize all submodules known to the superproject.\n\nI can't see how this happens. 'init' uses module_list which has been\nupdated to handle relative paths. So I expect 'git submodule init .' to\nwork correctly here. I would expect either of them to act on all\nsubmodules when given no extra arguments.\n\n> So this is a good start, but it looks like there is some work left\n> to do before this can hit master.\n\nThanks for the feedback.\n"},{"id":"214697","messageId":"CAMP44s2xH9yi+EvsVnV6JW0gPPistBbvg8Jj_62hXmZAAvC1cw@mail.gmail.com","threadId":"33517","inReplyTo":"vpq61zk8er7.fsf@grenoble-inp.fr","subject":"Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-18T09:15:21Z","receivedAt":"2013-04-18T09:15:21Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Apr 18, 2013 at 2:44 AM, Matthieu Moy\n wrote:\n> Felipe Contreras writes:\n>\n>> * How many times have you tracked regressions in transport helper's\n>> import/export functionality?\n>>\n>> Hint: zero.\n>\n> The real question to make the situation non-hypothetical would actually\n> be \"how many times did you track a regression that bisected down to\n> *this particular commit*\". Any regression that ends up on another commit\n> is irrelevant.\n>\n> I guess you realize how stupid my argument is. But how is yours\n> different?\n\nI did not make any argument (stupid or otherwise), I made I claim; I\nwon't waste my time with hypotheticals.\n\n> You do realize that your claim that nobody is ever going to\n> bisect down to your commit is as hypothetical as other people's claim\n> (if you think it is not, then try to point us a proof that nobody is\n> ever going to need a good message in the future to understand what I\n> mean).\n\nYeah, they are both hypotheticals, the only difference is that your\nclaim is very easy to prove; all you need is *ONE* example.\n\nBut I'm very happy to withdraw my claim, as long as you withdraw your\nclaim as well, and we go back to the default position: we don't know\nif anybody will every look at these commit messages again.\n\n> We're trying to make all the code and all the commits clean. It seems to\n> be a consensus here that review is good. I see no reason to purposely\n> make some commits less good than others based on the fact that they may\n> not be used in the future.\n\nYou have to prove first that they are \"less good\", and the best way to\ndo that is provide commit messages of your own, if you do that, they\ncan be used instead, but if you don't, what do you propose to do? Drop\nthe patches?\n\n> Search your favorite search engine for \"broken window principle\" to get\n> more arguments in this direction.\n\nMore like broken windows hypothesis, which is not without its critics.\n\n>> * How many times has *anybody* done so?\n>>\n>> Hint: other than me, quite possibly zero.\n>\n> If you want to be the only developer, and avoid being disturbed by\n> others, then why are you pushing your changes to git.git? Why are you\n> even discussing on this list?\n\nDoesn't matter, it's still *HYPOTHETICAL* that anybody will every hit\nthis in a bisect.\n\nNow, if you agree it's all hypothetical, the next rational thing to do\nis risk analysis: how likely is it to happen, and what would be the\nimpact if it does? The answer to both questions is: close to *ZERO*.\nSo, considering the nature of these patches (a remote-helper in the\ncontrib area that is relatively new), and the active developers (me),\nI'd say it's much more important to get the fixes in, than to document\nevery little quirk, detail and reasoning behind them. It's the balance\nI think it's best at this point, and it is my time, and it is my\ndecision what I do with it.\n\nIt might also help to compare oranges with oranges, and with regards\nto remote-hg transport helpers, I do believe the one in\ncontrib/remote-helpers has the best commit messages:\n\nmsysgit's remote-hg:\n---\ncommit 6bbd5365988d63780acc2ab407878eef8c19b47c\nAuthor: Sverre Rabbelier \nDate: Sun Aug 22 01:22:14 2010 -0500\n\n git_remote_helpers: add fastimport library\n\n git_remote_helpers/fastimport/__init__.py | 0\n git_remote_helpers/fastimport/commands.py | 469\n+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++\n git_remote_helpers/fastimport/dates.py | 79 +++++++++++\n git_remote_helpers/fastimport/errors.py | 182 +++++++++++++++++++++++++\n git_remote_helpers/fastimport/head_tracker.py | 47 +++++++\n git_remote_helpers/fastimport/helpers.py | 88 +++++++++++++\n git_remote_helpers/fastimport/idmapfile.py | 65 +++++++++\n git_remote_helpers/fastimport/parser.py | 621\n++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++\n git_remote_helpers/fastimport/processor.py | 222\n+++++++++++++++++++++++++++++++\n git_remote_helpers/setup.py | 3 +-\n 10 files changed, 1775 insertions(+), 1 deletion(-)\n---\n\ngitifyhg:\n--\ncommit 4b364563cd705dc5e69082e6b80d304fe50b9c9c\nAuthor: Alex Sydell \nDate: Sat Mar 23 23:46:33 2013 -0700\n\n Report correct (instead of unknown) hashes when importing refs into git\n\n gitifyhg/gitifyhg.py | 27 +++++++++++++++++++++------\n gitifyhg/hgimporter.py | 20 ++------------------\n gitifyhg/util.py | 44 ++++++++++++++++++++++++++++++++++++++++++++\n test/test_push.py | 31 +++++++++++++++++++++++++++----\n 4 files changed, 94 insertions(+), 28 deletions(-)\n---\n\nAnd of course, the best place to discuss the lack of good commit\nmessages, is in the patches themselves, which are after all, sent to\nthe mailing list for everyone to review.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"214698","messageId":"CALkWK0nji4m0zJPf_s0G5jfWaAN_RTGFZ6dSxfahq2OcRsu5xQ@mail.gmail.com","threadId":"33517","inReplyTo":"CAMP44s3pZt3QVjS7GbXqjMS4ti3p=Vs2DmFXQjsMM3rs9qURmw@mail.gmail.com","subject":"Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-18T09:19:42Z","receivedAt":"2013-04-18T09:19:42Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Felipe Contreras wrote:\n> I think the commit message is fine, you don't. So YOU go ahead and\n> write the proper one. If you don't, all you are doing is being an\n> impediment to progress.\n\nHey Felipe. Let's get a few things straightened out first:\n\n- We all act in our selfish interests, and write code to scratch our\npersonal itches. I don't write code or commit messages for anyone\nelse, and neither should you.\n\n- However, we're not working in isolation. We have this giant mailing\nlist where we all post our patches. It's like a bazaar where we\ncompete against other patches for developer attention and potential\nreviewers. In other words, it's a free market, and we're selling our\nproduct: if it fails to sell, will you blame the market or your\nproduct? I write clear code and beautiful commit messages exactly for\nthis reason: I'm fighting for attention!\n\n- We have to learn to interoperate with others' code and conventions,\nif we want to be part of the community. That doesn't mean that we\ndrown out our individuality, but it means that a our patch series has\nto conform to some minimal, loose, and evolving standard. Now, you\ncan argue that many of the existing conventions are outdated (I do it\nall the time), but it cannot change overnight. Your influence on the\ncommunity will show up over an extended period of time.\n\n- We are not an old enterprise who blame breakages on a few\nindividuals, and fire them. We're a community where all of us are\nequally responsible for all parts of the code. I am as responsible\nfor the remote-hg code in master as you are, as I had every\nopportunity to review it when the patch series came up on the list. I\nmight have chosen not to, but that doesn't relieve me of\nresponsibility.\n\n- We don't practice division of labour. There are no managers,\n\"testing people\", \"documentation people\", \"code-writing people\",\n\"commit-message writing people\" etc. Everyone has to do some portion\nof all these tasks, although we try to keep the boring work/ technical\ndebt to a minimum. Don't ask other people to write commit messages\nfor your code.\n"},{"id":"214703","messageId":"CAMP44s1RpgM5U0ySsof_sgEHNS1p-seQ=ciVCth9gOJMG0cpHw@mail.gmail.com","threadId":"33517","inReplyTo":"CALkWK0nji4m0zJPf_s0G5jfWaAN_RTGFZ6dSxfahq2OcRsu5xQ@mail.gmail.com","subject":"Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-18T09:53:58Z","receivedAt":"2013-04-18T09:53:58Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Apr 18, 2013 at 4:19 AM, Ramkumar Ramachandra\n wrote:\n> Felipe Contreras wrote:\n>> I think the commit message is fine, you don't. So YOU go ahead and\n>> write the proper one. If you don't, all you are doing is being an\n>> impediment to progress.\n>\n> Hey Felipe. Let's get a few things straightened out first:\n>\n> - We all act in our selfish interests, and write code to scratch our\n> personal itches. I don't write code or commit messages for anyone\n> else, and neither should you.\n>\n> - However, we're not working in isolation. We have this giant mailing\n> list where we all post our patches. It's like a bazaar where we\n> compete against other patches for developer attention and potential\n> reviewers. In other words, it's a free market, and we're selling our\n> product: if it fails to sell, will you blame the market or your\n> product? I write clear code and beautiful commit messages exactly for\n> this reason: I'm fighting for attention!\n\nExcept the customers are not git developers, it's git users. Git\ndevelopers rejecting patches because of the commit message is akin to\ndistributors rejecting products because they don't like the\ntransportation packages; they are only hurting themselves, by hurting\ntheir customers.\n\n> - We have to learn to interoperate with others' code and conventions,\n> if we want to be part of the community. That doesn't mean that we\n> drown out our individuality, but it means that a our patch series has\n> to conform to some minimal, loose, and evolving standard. Now, you\n> can argue that many of the existing conventions are outdated (I do it\n> all the time), but it cannot change overnight. Your influence on the\n> community will show up over an extended period of time.\n\nAnd the only way it can change is by discussing.\n\nThe only one that gets bitten by fixes not getting merged are git\nusers, not me. So if a discussion of a commit message impedes the\nmerging of the commit, I don't get affected, but when we have agreed\nto disagree on what constitutes a good message, and the patch is still\non hold, then there's a problem.\n\n> - We are not an old enterprise who blame breakages on a few\n> individuals, and fire them. We're a community where all of us are\n> equally responsible for all parts of the code. I am as responsible\n> for the remote-hg code in master as you are, as I had every\n> opportunity to review it when the patch series came up on the list. I\n> might have chosen not to, but that doesn't relieve me of\n> responsibility.\n\nI don't think so. Unless you added your Signed-off-by, you are not.\n\n> - We don't practice division of labour. There are no managers,\n> \"testing people\", \"documentation people\", \"code-writing people\",\n> \"commit-message writing people\" etc. Everyone has to do some portion\n> of all these tasks, although we try to keep the boring work/ technical\n> debt to a minimum. Don't ask other people to write commit messages\n> for your code.\n\nI am not. Neither should they ask me to write the commit messages they\nwant. They can make *suggestions*, and I can reject them.\n\nWhen two persons have different ideas, often times both are wrong, and\nthe middle-ground is best, but sometimes a person reaches the\nmiddle-ground, and sometimes one person was right from the start.\n\nBut when everyone shares the *assumption* that there is never a commit\nmessage that is too long, you know the wrestling mat of ideas is\nrigged. I wonder if I should write a commit message as long as a book\nchapter for a one-liner, only to prove a point, but I'm honestly\nafraid that it would be committed as is.\n\nAnd remember what started the conversation; do you think a patch with\na possibly incomplete commit message should not be merged to pu\n(proposed updates), shouldn't even be mentioned in the \"what's\ncooking\" mail, and thus shouldn't even be considered \"cooking\"?\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"214713","messageId":"CALkWK0krWM4kJ5GTnQ2SL7HoNfNMNA0-xdRVbeatAFpyKW_RtA@mail.gmail.com","threadId":"33517","inReplyTo":"CAMP44s1RpgM5U0ySsof_sgEHNS1p-seQ=ciVCth9gOJMG0cpHw@mail.gmail.com","subject":"Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-18T10:27:34Z","receivedAt":"2013-04-18T10:27:34Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Felipe Contreras wrote:\n> Except the customers are not git developers, it's git users. Git\n> developers rejecting patches because of the commit message is akin to\n> distributors rejecting products because they don't like the\n> transportation packages; they are only hurting themselves, by hurting\n> their customers.\n\nHuh? I certainly don't develop for some \"git users\" I don't even know\nor care about. In this order of precedence, my customers are:\n\n1. Me.\n2. People who develop git.git, whom I have to cooperate with.\n3. People who exercise git heavily like the linux.git community, as\nopposed to some little projects that operate using pull requests on\nGitHub.\n...\n137. People who incidentally choose to use git.\n138. People who incidentally choose to use git, but aren't on Linux.\n\nI don't know if Junio or the others share this view, but this is how I\npersonally operate and I'm very happy.\n\nAnd nobody is hurting anyone else. Someone wrote some code, and\nfailed to sell it to the community. That's all happened.\n\n> The only one that gets bitten by fixes not getting merged are git\n> users, not me. So if a discussion of a commit message impedes the\n> merging of the commit, I don't get affected, but when we have agreed\n> to disagree on what constitutes a good message, and the patch is still\n> on hold, then there's a problem.\n\nI think the whole issue of whether your commit message conforms to\nsome transcendental standard is orthogonal to the issue. Is your\npatch getting attention? Has it attracted reviewers, and turned up on\nthe latest \"What's cooking\"?\n\n> I don't think so. Unless you added your Signed-off-by, you are not.\n\nOkay, so your view differs.\n\n> I am not. Neither should they ask me to write the commit messages they\n> want. They can make *suggestions*, and I can reject them.\n\nOfcourse you have a right to reject suggestions. The question at the\nend of the day doesn't change: did you manage to get people to read\nyour patch?\n\n> When two persons have different ideas, often times both are wrong, and\n> the middle-ground is best, but sometimes a person reaches the\n> middle-ground, and sometimes one person was right from the start.\n\nhttps://yourlogicalfallacyis.com/middle-ground :)\n\n> But when everyone shares the *assumption* that there is never a commit\n> message that is too long, you know the wrestling mat of ideas is\n> rigged. I wonder if I should write a commit message as long as a book\n> chapter for a one-liner, only to prove a point, but I'm honestly\n> afraid that it would be committed as is.\n\nI'm with you, and don't share that assumption. I'm not accusing you\nof writing commit messages that don't conform to some \"transcendental\nstandard\" either: I didn't look at your patches in the first place,\nbecause the simple Signed-off-by: one-liner in the body didn't really\nmake me want to read it.\n\n> And remember what started the conversation; do you think a patch with\n> a possibly incomplete commit message should not be merged to pu\n> (proposed updates), shouldn't even be mentioned in the \"what's\n> cooking\" mail, and thus shouldn't even be considered \"cooking\"?\n\nIt's irrelevant what I think or others think. The point is that it\nwasn't mentioned. Now, why wasn't it mentioned? Is it because Junio\nand the community hate you, and are conspiring against getting your\ncode merged? Or is it because it didn't catch anyone's eye, and Junio\nwas waiting for it to happen (as always)?\n\nTL;DR version: Your goal in submitting a patch is to sell it to other\npeople in the community. If enough people like your patch, it gets\nmerged (but that is only the second step). Your goal is not to fix\nproblems for some unknown \"users\", or argue about some \"transcendental\nstandard\". Ofcourse the community shares some view about what a patch\nshould look like, but you can mould those expectations gradually.\n"},{"id":"214714","messageId":"CAMP44s0KW4_Q6-d-3=M7GzWmHwy4H--FcemK4UF5FS0t3wnOgg@mail.gmail.com","threadId":"33517","inReplyTo":"CALkWK0krWM4kJ5GTnQ2SL7HoNfNMNA0-xdRVbeatAFpyKW_RtA@mail.gmail.com","subject":"Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-18T10:55:27Z","receivedAt":"2013-04-18T10:55:27Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Apr 18, 2013 at 5:27 AM, Ramkumar Ramachandra\n wrote:\n> Felipe Contreras wrote:\n>> Except the customers are not git developers, it's git users. Git\n>> developers rejecting patches because of the commit message is akin to\n>> distributors rejecting products because they don't like the\n>> transportation packages; they are only hurting themselves, by hurting\n>> their customers.\n>\n> Huh? I certainly don't develop for some \"git users\" I don't even know\n> or care about. In this order of precedence, my customers are:\n>\n> 1. Me.\n> 2. People who develop git.git, whom I have to cooperate with.\n> 3. People who exercise git heavily like the linux.git community, as\n> opposed to some little projects that operate using pull requests on\n> GitHub.\n> ...\n> 137. People who incidentally choose to use git.\n> 138. People who incidentally choose to use git, but aren't on Linux.\n\nAs they are for most open source developers on the planet, not me. I\nbelieve a project is nothing without its users.\n\n> And nobody is hurting anyone else. Someone wrote some code, and\n> failed to sell it to the community. That's all happened.\n\nIf remote-hg wasn't available for users, they would be hurt; if stash\nwasn't available, if rebase --interactive didn't exist, if there was\nno msysgit, if it wasn't so fast, if the object model wasn't so simple\nand extensible; users would be hurt. And if users didn't have all\nthese, there would be less users, and if there were less users, there\nwould be less developers, and mercurial might have been more popular,\nand most repositories you have to work on would be in mercurial, and\nyou might be developing mercurial right now.\n\nBut I won't bother trying to convince you that no project is more\nimportant than its users (in the words of Linus Torvalds), because\nmost people don't see the big picture.\n\n>> I don't think so. Unless you added your Signed-off-by, you are not.\n>\n> Okay, so your view differs.\n>\n>> I am not. Neither should they ask me to write the commit messages they\n>> want. They can make *suggestions*, and I can reject them.\n>\n> Ofcourse you have a right to reject suggestions. The question at the\n> end of the day doesn't change: did you manage to get people to read\n> your patch?\n\nNo, at the end of the day what matters is: did the users benefit from this?\n\nThe answer for this particular patch is no, and it's not my fault.\n\n>> When two persons have different ideas, often times both are wrong, and\n>> the middle-ground is best, but sometimes a person reaches the\n>> middle-ground, and sometimes one person was right from the start.\n>\n> https://yourlogicalfallacyis.com/middle-ground :)\n\nYeah, but I didn't claim that, I said sometimes one person was right\nfrom the start, no middle-ground.\n\n>> But when everyone shares the *assumption* that there is never a commit\n>> message that is too long, you know the wrestling mat of ideas is\n>> rigged. I wonder if I should write a commit message as long as a book\n>> chapter for a one-liner, only to prove a point, but I'm honestly\n>> afraid that it would be committed as is.\n>\n> I'm with you, and don't share that assumption.\n\ns/everyone/almost everyone/\n\n> I'm not accusing you\n> of writing commit messages that don't conform to some \"transcendental\n> standard\" either: I didn't look at your patches in the first place,\n> because the simple Signed-off-by: one-liner in the body didn't really\n> make me want to read it.\n>\n>> And remember what started the conversation; do you think a patch with\n>> a possibly incomplete commit message should not be merged to pu\n>> (proposed updates), shouldn't even be mentioned in the \"what's\n>> cooking\" mail, and thus shouldn't even be considered \"cooking\"?\n>\n> It's irrelevant what I think or others think. The point is that it\n> wasn't mentioned. Now, why wasn't it mentioned? Is it because Junio\n> and the community hate you, and are conspiring against getting your\n> code merged? Or is it because it didn't catch anyone's eye, and Junio\n> was waiting for it to happen (as always)?\n\nMy abridged version of the story is: because Jeff King pointed to an\narea of improvement he wasn't even strongly attached to, I agreed to\nresubmit, Junio saw that, then I changed my mind, Junio probably\ndidn't see that, and then he forgot about it.\n\nThen, since it's taboo to suggest that a concise commit message is\nfine, a discussion sprung.\n\n> TL;DR version: Your goal in submitting a patch is to sell it to other\n> people in the community.\n\nI disagree.\n\n> If enough people like your patch, it gets\n> merged (but that is only the second step). Your goal is not to fix\n> problems for some unknown \"users\", or argue about some \"transcendental\n> standard\".\n\nI disagree.\n\n> Ofcourse the community shares some view about what a patch\n> should look like, but you can mould those expectations gradually.\n\nIf experience is any guide, doesn't look like that. But I've noticed\nthat after many months that a patch has been sent people realize that\nit's more important to get the damn issue fixed than to have a hugely\nverbose commit message...\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"214719","messageId":"CALkWK0nOp_w1LXnN9SoAS9zvhwb5W37csx42KKau5aYCqdwTkQ@mail.gmail.com","threadId":"33517","inReplyTo":"CAMP44s0KW4_Q6-d-3=M7GzWmHwy4H--FcemK4UF5FS0t3wnOgg@mail.gmail.com","subject":"Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-18T11:31:51Z","receivedAt":"2013-04-18T11:31:51Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Since you disagreed with the rest, I'll only respond to this part:\n\nFelipe Contreras wrote:\n> But I won't bother trying to convince you that no project is more\n> important than its users (in the words of Linus Torvalds), because\n> most people don't see the big picture.\n\nI didn't say otherwise. What I'm saying is: my personal incentive to\nwrite code does not prioritize the supposed benefit of some unknown\n\"user\" somewhere on the planet above everything else. My personal\nincentive prioritizes me, and my immediate circle (ie. the git\ncommunity). The benefit propagates outwards to extended circles until\nit reaches the people I care least about: incidental end-users.\nThat's how people are connected: how can I care about distant unknown\npeople I'm not connected to? The people in the outermost circles\nbenefit the least, because they didn't get a say in the development.\nAll they can do is write a rant about it on their blog, and hope that\nit gets fixed someday.\n\nYou just ditched us, the inner circle of people who care about your\nwork the most, and are instead trying to convince us that we're\nhurting some unknown hypothetical \"users\" by not merging your code\nimmediately.\n\nIf you think these users are more important to you than we are, then\nwhy are you posting your code on this mailing list? Start your own\nproject that's focused on satisfying these users. It doesn't even\nneed to be open source or have a community of reviewers, because all\nyou care about are users.\n"},{"id":"214721","messageId":"CALkWK0ncfuzuYSKjkT2uQy4dGR=TSnHoJNdhU9ownDUytysL6w@mail.gmail.com","threadId":"33517","inReplyTo":"CAMP44s0KW4_Q6-d-3=M7GzWmHwy4H--FcemK4UF5FS0t3wnOgg@mail.gmail.com","subject":"Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-18T11:46:28Z","receivedAt":"2013-04-18T11:46:28Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Okay, one more segment needs to be responded to.\n\nFelipe Contreras wrote:\n> If remote-hg wasn't available for users, they would be hurt; if stash\n> wasn't available, if rebase --interactive didn't exist, if there was\n> no msysgit, if it wasn't so fast, if the object model wasn't so simple\n> and extensible; users would be hurt. And if users didn't have all\n> these, there would be less users, and if there were less users, there\n> would be less developers, and mercurial might have been more popular,\n> and most repositories you have to work on would be in mercurial, and\n> you might be developing mercurial right now.\n\nFlawed logic.\n\nA large number of users doesn't automatically imply good software with\nlots of features, or even a great development community. A great\ndevelopment community leads to great software. And great software\nleads to lots of users. Sure, there's a feedback loop pushing users\nto become developers; but it doesn't start with users of vaporware,\nleading to more developers joining the effort to turn that vaporware\ninto a great product.\n\nLife doesn't begin with users.\n"},{"id":"214722","messageId":"CAMP44s2Vc0b-DBnExFCwfZX2a5om5z_NasBFZNTRfuPte75hXg@mail.gmail.com","threadId":"33517","inReplyTo":"CALkWK0nOp_w1LXnN9SoAS9zvhwb5W37csx42KKau5aYCqdwTkQ@mail.gmail.com","subject":"Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-18T12:05:58Z","receivedAt":"2013-04-18T12:05:58Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Apr 18, 2013 at 6:31 AM, Ramkumar Ramachandra\n wrote:\n> Since you disagreed with the rest, I'll only respond to this part:\n>\n> Felipe Contreras wrote:\n>> But I won't bother trying to convince you that no project is more\n>> important than its users (in the words of Linus Torvalds), because\n>> most people don't see the big picture.\n>\n> I didn't say otherwise. What I'm saying is: my personal incentive to\n> write code does not prioritize the supposed benefit of some unknown\n> \"user\" somewhere on the planet above everything else. My personal\n> incentive prioritizes me, and my immediate circle (ie. the git\n> community). The benefit propagates outwards to extended circles until\n> it reaches the people I care least about: incidental end-users.\n\nIf the people that matter most are given the worst prioritization, it\nmeans the prioritization is wrong.\n\n> That's how people are connected: how can I care about distant unknown\n> people I'm not connected to?\n\nIt's called empathy.\n\n> The people in the outermost circles\n> benefit the least, because they didn't get a say in the development.\n> All they can do is write a rant about it on their blog, and hope that\n> it gets fixed someday.\n\nTo the detriment of the project.\n\n> You just ditched us, the inner circle of people who care about your\n> work the most, and are instead trying to convince us that we're\n> hurting some unknown hypothetical \"users\" by not merging your code\n> immediately.\n\nThe users are real, the developers that will look retroatcively to the\ncommit message of this patch are not.\n\n> If you think these users are more important to you than we are, then\n> why are you posting your code on this mailing list?\n\nWhat other way is there for this code to reach the users?\n\n> Start your own\n> project that's focused on satisfying these users.\n\nStart a new project so I can include a patch that hasn't made it yet\ninto the \"what's cooking\" in one week? That's ridiculous.\n\n> It doesn't even\n> need to be open source or have a community of reviewers, because all\n> you care about are users.\n\nWho said *all* that matters are the users? And even if somebody did,\nultimately a closed source proprietary software doesn't benefit the\nusers, so either way it has to be open and active to benefit the\nusers.\n\n-- \nFelipe Contreras\n"},{"id":"214723","messageId":"CAMP44s162msct=W0eV93LX15Bho=DA1baLZcgFCouSRH=z0mDQ@mail.gmail.com","threadId":"33517","inReplyTo":"CALkWK0ncfuzuYSKjkT2uQy4dGR=TSnHoJNdhU9ownDUytysL6w@mail.gmail.com","subject":"Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-18T12:16:30Z","receivedAt":"2013-04-18T12:16:30Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Apr 18, 2013 at 6:46 AM, Ramkumar Ramachandra\n wrote:\n> Okay, one more segment needs to be responded to.\n>\n> Felipe Contreras wrote:\n>> If remote-hg wasn't available for users, they would be hurt; if stash\n>> wasn't available, if rebase --interactive didn't exist, if there was\n>> no msysgit, if it wasn't so fast, if the object model wasn't so simple\n>> and extensible; users would be hurt. And if users didn't have all\n>> these, there would be less users, and if there were less users, there\n>> would be less developers, and mercurial might have been more popular,\n>> and most repositories you have to work on would be in mercurial, and\n>> you might be developing mercurial right now.\n>\n> Flawed logic.\n>\n> A large number of users doesn't automatically imply good software with\n> lots of features, or even a great development community. A great\n> development community leads to great software. And great software\n> leads to lots of users. Sure, there's a feedback loop pushing users\n> to become developers; but it doesn't start with users of vaporware,\n> leading to more developers joining the effort to turn that vaporware\n> into a great product.\n>\n> Life doesn't begin with users.\n\nNobody knows how life began, and it doesn't matter now, what matters\nis how life evolves. It doesn't matter if the chicken was first, or\nthe egg, what matters is that if all the chickens and eggs are gone,\nthere won't be more.\n\nPlenty of projects have died because they stopped caring about their\nusers, and without users there's no new developers, and the old\ndevelopers eventually move on, and all the literary quality of commit\nmessages have no eyes to see it.\n\nI repeat: no project is more important than its users.\n\n-- \nFelipe Contreras\n"},{"id":"214739","messageId":"20130418172714.GA24690@sigill.intra.peff.net","threadId":"33517","inReplyTo":"7va9owd3d1.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-04-18T17:27:14Z","receivedAt":"2013-04-18T17:27:14Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Apr 17, 2013 at 06:39:06PM -0700, Junio C Hamano wrote:\n\n> Subject: [PATCH] git add: rework the logic to warn \"git add ...\" default change\n>\n> [...]\n>\n> Rework the logic to detect the case where the behaviour will be\n> different in Git 2.0, and issue a warning only when it matters.\n> Even with the code before this warning, \"git add subdir\" will have\n> to traverse the directory in order to find _new_ files the index\n> does not know about _anyway_, so we can do this check without adding\n> an extra pass to find if matches any removed file.\n\nThanks, I think this is looking much better.\n\nA few minor nits on the message itself:\n\n> +static void warn_add_would_remove(const char *path)\n> +{\n> +\twarning(_(\"In Git 2.0, 'git add ...' will also update the\\n\"\n> +\t\t \"index for paths removed from the working tree that match\\n\"\n> +\t\t \"the given pathspec. If you want to 'add' only changed\\n\"\n> +\t\t \"or newly created paths, say 'git add --no-all ...'\"\n> +\t\t \" instead.\\n\\n\"\n\nThis wrapping looks funny in the actual output, due to the extra\n\"warning:\" and the lack of newline before \"instead\":\n\n warning: In Git 2.0, 'git add ...' will also update the\n index for paths removed from the working tree that match\n the given pathspec. If you want to 'add' only changed\n or newly created paths, say 'git add --no-all ...' instead.\n\nWrapping it like this ends up with a much more natural-looking\nparagraph:\n\n warning: In Git 2.0, 'git add ...' will also update the\n index for paths removed from the working tree that match the given\n pathspec. If you want to 'add' only changed or newly created paths,\n say 'git add --no-all ...' instead.\n\n> +\t\t \"'%s' would be removed from the index without --no-all.\"),\n> +\t\tpath);\n\nI think mentioning the filename is a good thing; the original message\nleft me scratching my head and wondering \"so, did you add it or not?\".\nI still think your \"would be\" is unnecessarily confusing, though. It is\n\"would be in Git 2.0 without --no-all, but we did not now\". Which makes\nsense when you think about it, but it took me a moment to parse.\n\nPerhaps we can be more direct with something like:\n\n warning: did not stage removal of 'foo'\n\nor perhaps the present tense \"not staging removal of...\" would be\nbetter.\n\nI also think it makes sense to show every path that is affected, not\njust the first one, to be clear about what was done (and what _would_\nhave been done in Git 2.0).\n\nA patch with all of the suggestions together is below. I still think the\nmulti-line warning block looks ugly. I kind of like the way advise()\nputs \"hint:\" on each line. I wonder if we should do the same here.\n\ndiff --git a/builtin/add.c b/builtin/add.c\nindex 4242bce..aae550a 100644\n--- a/builtin/add.c\n+++ b/builtin/add.c\n@@ -52,15 +52,19 @@ static void warn_add_would_remove(const char *path)\n \t\treturn DIFF_STATUS_MODIFIED;\n }\n \n+static const char *add_would_remove_warning = N_(\n+/* indent for \"warning: \" */\n+ \"In Git 2.0, 'git add ...' will also update the\\n\"\n+\"index for paths removed from the working tree that match the given\\n\"\n+\"pathspec. If you want to 'add' only changed or newly created paths,\\n\"\n+\"say 'git add --no-all ...' instead.\\n\");\n+\n static void warn_add_would_remove(const char *path)\n {\n-\twarning(_(\"In Git 2.0, 'git add ...' will also update the\\n\"\n-\t\t \"index for paths removed from the working tree that match\\n\"\n-\t\t \"the given pathspec. If you want to 'add' only changed\\n\"\n-\t\t \"or newly created paths, say 'git add --no-all ...'\"\n-\t\t \" instead.\\n\\n\"\n-\t\t \"'%s' would be removed from the index without --no-all.\"),\n-\t\tpath);\n+\tstatic int warned_once;\n+\tif (!warned_once++)\n+\t\twarning(_(add_would_remove_warning));\n+\twarning(\"did not stage removal of '%s'\", path);\n }\n \n static void update_callback(struct diff_queue_struct *q,\n@@ -84,10 +88,8 @@ static void update_callback(struct diff_queue_struct *q,\n \t\t\t}\n \t\t\tbreak;\n \t\tcase DIFF_STATUS_DELETED:\n-\t\t\tif (data->warn_add_would_remove) {\n+\t\t\tif (data->warn_add_would_remove)\n \t\t\t\twarn_add_would_remove(path);\n-\t\t\t\tdata->warn_add_would_remove = 0;\n-\t\t\t}\n \t\t\tif (data->flags & ADD_CACHE_IGNORE_REMOVAL)\n \t\t\t\tbreak;\n \t\t\tif (!(data->flags & ADD_CACHE_PRETEND))\n"},{"id":"214746","messageId":"7vd2tr6833.fsf@alter.siamese.dyndns.org","threadId":"33517","inReplyTo":"20130418172714.GA24690@sigill.intra.peff.net","subject":"Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-18T17:51:12Z","receivedAt":"2013-04-18T17:51:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> +static const char *add_would_remove_warning = N_(\n> +/* indent for \"warning: \" */\n> + \"In Git 2.0, 'git add ...' will also update the\\n\"\n> +\"index for paths removed from the working tree that match the given\\n\"\n> +\"pathspec. If you want to 'add' only changed or newly created paths,\\n\"\n> +\"say 'git add --no-all ...' instead.\\n\");\n> +\n> static void warn_add_would_remove(const char *path)\n> {\n> -\twarning(_(\"In Git 2.0, 'git add ...' will also update the\\n\"\n> -\t\t \"index for paths removed from the working tree that match\\n\"\n> -\t\t \"the given pathspec. If you want to 'add' only changed\\n\"\n> -\t\t \"or newly created paths, say 'git add --no-all ...'\"\n> -\t\t \" instead.\\n\\n\"\n> -\t\t \"'%s' would be removed from the index without --no-all.\"),\n> -\t\tpath);\n> +\tstatic int warned_once;\n> +\tif (!warned_once++)\n> +\t\twarning(_(add_would_remove_warning));\n> +\twarning(\"did not stage removal of '%s'\", path);\n> }\n\nWould \"add --dry-run\" say this, too?\n\n> static void update_callback(struct diff_queue_struct *q,\n> @@ -84,10 +88,8 @@ static void update_callback(struct diff_queue_struct *q,\n> \t\t\t}\n> \t\t\tbreak;\n> \t\tcase DIFF_STATUS_DELETED:\n> -\t\t\tif (data->warn_add_would_remove) {\n> +\t\t\tif (data->warn_add_would_remove)\n> \t\t\t\twarn_add_would_remove(path);\n> -\t\t\t\tdata->warn_add_would_remove = 0;\n> -\t\t\t}\n> \t\t\tif (data->flags & ADD_CACHE_IGNORE_REMOVAL)\n> \t\t\t\tbreak;\n> \t\t\tif (!(data->flags & ADD_CACHE_PRETEND))\n"},{"id":"214747","messageId":"20130418180017.GA5714@sigill.intra.peff.net","threadId":"33517","inReplyTo":"7vd2tr6833.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-04-18T18:00:18Z","receivedAt":"2013-04-18T18:00:18Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Apr 18, 2013 at 10:51:12AM -0700, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > +static const char *add_would_remove_warning = N_(\n> > +/* indent for \"warning: \" */\n> > + \"In Git 2.0, 'git add ...' will also update the\\n\"\n> > +\"index for paths removed from the working tree that match the given\\n\"\n> > +\"pathspec. If you want to 'add' only changed or newly created paths,\\n\"\n> > +\"say 'git add --no-all ...' instead.\\n\");\n> > +\n> > static void warn_add_would_remove(const char *path)\n> > {\n> > -\twarning(_(\"In Git 2.0, 'git add ...' will also update the\\n\"\n> > -\t\t \"index for paths removed from the working tree that match\\n\"\n> > -\t\t \"the given pathspec. If you want to 'add' only changed\\n\"\n> > -\t\t \"or newly created paths, say 'git add --no-all ...'\"\n> > -\t\t \" instead.\\n\\n\"\n> > -\t\t \"'%s' would be removed from the index without --no-all.\"),\n> > -\t\tpath);\n> > +\tstatic int warned_once;\n> > +\tif (!warned_once++)\n> > +\t\twarning(_(add_would_remove_warning));\n> > +\twarning(\"did not stage removal of '%s'\", path);\n> > }\n> \n> Would \"add --dry-run\" say this, too?\n\nIt probably makes sense to continue to have the warning in the dry-run\ncase, but it may make sense to tweak it grammatically when we are in\ndry-run mode. Saying \"would stage removal\" is technically correct, but I\nthink it is somewhat ambiguous: would git do it if we were not in a\n--dry-run, or would git do it if it were Git 2.0?\n\nDoing it as:\n\n warning: not staging removal of '%s'\n\ncould work for both cases. Something like \"not considering\" (or another\nsynonym for \"considering\") might be even more accurate. It is not just\nthat we did not stage it; it is what we did not even consider it an item\nfor staging under the current rules.\n\nNote that the \"not staging\" warnings may potentially be interspersed\nwith the normal dry-run output. I think that's OK. But another\nalternative would be to collect the paths and then print:\n\n warning: In Git 2.0, ...\n\n The following deleted paths were not considered under the current\n rule. Use \"git add -A\" to stage their removal now.\n\n foo\n bar\n\n-Peff\n"},{"id":"214748","messageId":"7v61zj66wu.fsf@alter.siamese.dyndns.org","threadId":"33517","inReplyTo":"20130418180017.GA5714@sigill.intra.peff.net","subject":"Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-18T18:16:33Z","receivedAt":"2013-04-18T18:16:33Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> could work for both cases. Something like \"not considering\" (or another\n> synonym for \"considering\") might be even more accurate. It is not just\n> that we did not stage it; it is what we did not even consider it an item\n> for staging under the current rules.\n\nYes, \"not considering\" is much more sensible, while side-stepping\nthe dryrun issue. Or\n\n warning(\"ignoring removal of '%s'\")\n\n> Note that the \"not staging\" warnings may potentially be interspersed\n> with the normal dry-run output. I think that's OK.\n\nAs long as the top-text makes it clear what \"not considering\" (or\n\"ignoring\") in the following text means, I think it is fine.\n\nBut I think we are doing users a disservice by listing tons of\npaths. Where the difference of versions matters _most_ is when the\nuser has tons of removed paths in the working tree. Either with one\nwarning per path, or a block of collected paths at the end, we are\nscrolling the more important part of the message up.\n\nThat was why I originally showed one path as an example and stopped\nthere. Perhaps it is a better solution to keep that behaviour and\nrephrase the message to say that we ignored removal of paths like\nthis one '%s' you lost from the working tree but it will change in\nGit 2.0 and you will better learn to use the --no-all option now.\n\nThe inter-topic conflicts between stages of three \"add in Git 2.0\"\ntopics is getting cumbersome even with the help from rerere, so I'd\nlike to merge their preparatory steps as I have them now to 'next'\nand merge them down to 'master' first, and start applying tweaks\nfrom there, or something.\n"},{"id":"214758","messageId":"CABURp0riKhJ1p+06aKMCnBiupg3LyVCky5XRcPNLyaJDTkip9Q@mail.gmail.com","threadId":"33517","inReplyTo":"CAMP44s3pZt3QVjS7GbXqjMS4ti3p=Vs2DmFXQjsMM3rs9qURmw@mail.gmail.com","subject":"Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)","fromName":"Phil Hord","fromEmail":"phil.hord@gmail.com","sentAt":"2013-04-18T20:06:32Z","receivedAt":"2013-04-18T20:06:32Z","isPatch":false,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"On Wed, Apr 17, 2013 at 2:50 PM, Felipe Contreras\n wrote:\n> On Tue, Apr 16, 2013 at 5:45 PM, Phil Hord wrote:\n>> On Tue, Apr 16, 2013 at 3:04 PM, Felipe Contreras\n\n>>> If you want to waste your time, by all means, rewrite all my commit\n>>> messages with essays that nobody will ever read. I'm not going to do\n>>> that for some hypothetical case that will never happen. I'm not going\n>>> to waste my time.\n>>\n>> This is not a hypothetical. Almost every time I bisect a regression\n>> in git.git, I find the commit message tells me exactly why the commit\n>> did what it did and what the expected result was. I find this to be\n>> amazingly useful. Do I need to show you real instances of that\n>> happening? No. I promise it did, though.\n>\n> Yes please. Show me one of the instances where you hit a bisect with\n> any of the remote-hg commits mentioned above by Thomas Rast.\n\nI made no such claim. In fact, I have never bisected to any\nremote-hg-related commit. I fail to see the relevance of this\nqualifier, though.\n\nP\n"},{"id":"214760","messageId":"20130418203035.GB24690@sigill.intra.peff.net","threadId":"33517","inReplyTo":"7v61zj66wu.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-04-18T20:30:35Z","receivedAt":"2013-04-18T20:30:35Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Apr 18, 2013 at 11:16:33AM -0700, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > could work for both cases. Something like \"not considering\" (or another\n> > synonym for \"considering\") might be even more accurate. It is not just\n> > that we did not stage it; it is what we did not even consider it an item\n> > for staging under the current rules.\n> \n> Yes, \"not considering\" is much more sensible, while side-stepping\n> the dryrun issue. Or\n> \n> warning(\"ignoring removal of '%s'\")\n\nI like that much better than either of my suggestions.\n\n> > Note that the \"not staging\" warnings may potentially be interspersed\n> > with the normal dry-run output. I think that's OK.\n> \n> As long as the top-text makes it clear what \"not considering\" (or\n> \"ignoring\") in the following text means, I think it is fine.\n\nAgreed, and I think the current text is fine for that (though neither of\nus is the best judge at this point of how a less familiar user would\ninterpret it).\n\n> But I think we are doing users a disservice by listing tons of\n> paths. Where the difference of versions matters _most_ is when the\n> user has tons of removed paths in the working tree. Either with one\n> warning per path, or a block of collected paths at the end, we are\n> scrolling the more important part of the message up.\n\nI'm not sure I agree. Even with a handful, it made me wonder why one was\nmentioned and not others. That _could_ be cleared up by rewording (i.e.,\nmaking it clear that this is an example, and there may be more). But\nsomehow listing them is what I would expect. Perhaps because it gives\nthe user a clue about what to do next; they ask themselves \"did I want\nthose updated or not?\".\n\nIn the orphaned-commit message when leaving a detached HEAD, we collect\nthe answer, say \"you are leaving N commits\", and show the first 5 five\nof them, with an ellipsis at the end if we didn't show them all. Would\nit makes sense to do that here?\n\nYet another alternative would be to print a warning for each path, but\nhold the main warning for the end, so that it is the first thing the\nuser sees. That has the added bonus that regular \"--dry-run\" output\nwill not scroll it away, either.\n\n-Peff\n"},{"id":"214763","messageId":"7vvc7j4j0u.fsf@alter.siamese.dyndns.org","threadId":"33517","inReplyTo":"20130418203035.GB24690@sigill.intra.peff.net","subject":"Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-18T21:37:53Z","receivedAt":"2013-04-18T21:37:53Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n>> But I think we are doing users a disservice by listing tons of\n>> paths. Where the difference of versions matters _most_ is when the\n>> user has tons of removed paths in the working tree. Either with one\n>> warning per path, or a block of collected paths at the end, we are\n>> scrolling the more important part of the message up.\n>\n> I'm not sure I agree. Even with a handful, it made me wonder why one was\n> mentioned and not others. That _could_ be cleared up by rewording (i.e.,\n> making it clear that this is an example, and there may be more). But\n> somehow listing them is what I would expect. Perhaps because it gives\n> the user a clue about what to do next; they ask themselves \"did I want\n> those updated or not?\".\n>\n> In the orphaned-commit message when leaving a detached HEAD, we collect\n> the answer, say \"you are leaving N commits\", and show the first 5 five\n> of them, with an ellipsis at the end if we didn't show them all. Would\n> it makes sense to do that here?\n\nBecause this is to help people who are _used_ to seeing \"git add\"\nnot take the removals into account, I doubt that \"Did I want those\nupdated or not? Let me see the details of them.\" will be the\nquestion they will be asking [*1*].\n\nI dunno.\n\n\n[Footnote]\n\n*1* \"I know I didn't want to include these removals to the index,\nbut I learned today that in later Git I should make myself more\nclear if I want to keep doing so; thanks for letting me know.\", or\n\"I've long been assuming that I have to say 'git add' and 'git rm'\nseparately, but I learned today that I can say 'add --all', and in\nlater Git I do not even have to; thanks for letting me know.\" are\nthe two reactions I expected.\n"},{"id":"214764","messageId":"20130418214427.GA10119@sigill.intra.peff.net","threadId":"33517","inReplyTo":"7vvc7j4j0u.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-04-18T21:44:27Z","receivedAt":"2013-04-18T21:44:27Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Apr 18, 2013 at 02:37:53PM -0700, Junio C Hamano wrote:\n\n> Because this is to help people who are _used_ to seeing \"git add\"\n> not take the removals into account, I doubt that \"Did I want those\n> updated or not? Let me see the details of them.\" will be the\n> question they will be asking [*1*].\n> \n> I dunno.\n> \n> \n> [Footnote]\n> \n> *1* \"I know I didn't want to include these removals to the index,\n> but I learned today that in later Git I should make myself more\n> clear if I want to keep doing so; thanks for letting me know.\", or\n> \"I've long been assuming that I have to say 'git add' and 'git rm'\n> separately, but I learned today that I can say 'add --all', and in\n> later Git I do not even have to; thanks for letting me know.\" are\n> the two reactions I expected.\n\nI am expecting a reaction more like \"Hmm, I never thought about it\nbefore. Does that make sense to me or not? Let me think about which\npaths it pertains to and decide\".\n\nWhich I admit is no more likely than the scenarios you outlined, but it\nis close to what I thought the first time I saw the warning.\n\n-Peff\n"},{"id":"214765","messageId":"7vobdb4hii.fsf@alter.siamese.dyndns.org","threadId":"33517","inReplyTo":"20130418214427.GA10119@sigill.intra.peff.net","subject":"Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-18T22:10:29Z","receivedAt":"2013-04-18T22:10:29Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> I am expecting a reaction more like \"Hmm, I never thought about it\n> before. Does that make sense to me or not? Let me think about which\n> paths it pertains to and decide\".\n\nLet's step back and re-review the main text.\n\nIt currently says:\n\n In Git 2.0, 'git add ...' will also update the\n index for paths removed from the working tree that match\n the given pathspec. If you want to 'add' only changed\n or newly created paths, say 'git add --no-all ...'\n instead.\n\nThis was written for the old \"we may want to warn\" logic that did\nnot even check if we would be omitting a removal. The new logic\nwill show the text _only_ when the difference matters, we have an\nopportunity to tighten it a lot, for example:\n\n You ran 'git add' with neither '-A (--all)' or '--no-all', whose\n behaviour will change in Git 2.0 with respect to paths you\n removed from your working tree.\n\n * 'git add --no-all ', which is the current default,\n ignores paths you removed from your working tree.\n\n * 'git add --all ' will let you also record the\n removals.\n\n The removed paths (e.g. '%s') are ignored with this version of Git.\n Run 'git status' to remind yourself what paths you have removed\n from your working tree.\n\nor something?\n"},{"id":"214785","messageId":"CAMP44s2Yb+fSWYw0S7WuS-MEjKaSsnvndFw4ryZ8_Og6ioFcTQ@mail.gmail.com","threadId":"33517","inReplyTo":"CABURp0riKhJ1p+06aKMCnBiupg3LyVCky5XRcPNLyaJDTkip9Q@mail.gmail.com","subject":"Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-18T23:48:35Z","receivedAt":"2013-04-18T23:48:35Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Apr 18, 2013 at 3:06 PM, Phil Hord wrote:\n> On Wed, Apr 17, 2013 at 2:50 PM, Felipe Contreras\n\n>> Yes please. Show me one of the instances where you hit a bisect with\n>> any of the remote-hg commits mentioned above by Thomas Rast.\n>\n> I made no such claim. In fact, I have never bisected to any\n> remote-hg-related commit. I fail to see the relevance of this\n> qualifier, though.\n\nHere, this is what you said:\n\nYou:\n> Me:\n>> [skipping irrelevant comments]\n>>\n>> I'm sorry, did you actually hit an issue that required to look at the\n>> commit message to understand where the issue came from? No? Then I\n>> won't bother with hypotheticals.\n>>\n>> If you want to waste your time, by all means, rewrite all my commit\n>> messages with essays that nobody will ever read. I'm not going to do\n>> that for some hypothetical case that will never happen. I'm not going\n>> to waste my time.\n>\n> This is not a hypothetical.\n\nIf something is not hypothetical, it's real, which means it actually\nhappened, but then you said you never made the claim that it did. So\nwhat is it? Either it did happen, or it didn't; you cannot have your\ncake and eat it.\n\nIf you are going to change your claims on the fly, and deny you ever\nmade them, I don't see much point in discussing with you.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"214794","messageId":"20130419041424.GA377@sigill.intra.peff.net","threadId":"33517","inReplyTo":"7vobdb4hii.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-04-19T04:14:24Z","receivedAt":"2013-04-19T04:14:24Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Apr 18, 2013 at 03:10:29PM -0700, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > I am expecting a reaction more like \"Hmm, I never thought about it\n> > before. Does that make sense to me or not? Let me think about which\n> > paths it pertains to and decide\".\n> \n> Let's step back and re-review the main text.\n\nGood idea. I was very caught up in the existing message and what it made\nme expect, and not in what we are trying to accomplish overall.\n\n> It currently says:\n> \n> In Git 2.0, 'git add ...' will also update the\n> index for paths removed from the working tree that match\n> the given pathspec. If you want to 'add' only changed\n> or newly created paths, say 'git add --no-all ...'\n> instead.\n> \n> This was written for the old \"we may want to warn\" logic that did\n> not even check if we would be omitting a removal. The new logic\n> will show the text _only_ when the difference matters, we have an\n> opportunity to tighten it a lot, for example:\n> \n> You ran 'git add' with neither '-A (--all)' or '--no-all', whose\n> behaviour will change in Git 2.0 with respect to paths you\n> removed from your working tree.\n> \n> * 'git add --no-all ', which is the current default,\n> ignores paths you removed from your working tree.\n> \n> * 'git add --all ' will let you also record the\n> removals.\n> \n> The removed paths (e.g. '%s') are ignored with this version of Git.\n> Run 'git status' to remind yourself what paths you have removed\n> from your working tree.\n> \n> or something?\n\nYes, I like that much better. It reads more clearly than the original,\nand it is more obvious why we are mentioning the path at all.\n\nAnd I think the hint of \"git status\" is good. I had considered before\nthat the user would simply run \"git status\" after the message to get\nmore data, but I didn't want to rely on them knowing to do that.\nActually mentioning it is a good solution. :)\n\nThanks for pointing us in the right direction.\n\n-Peff\n"},{"id":"214795","messageId":"20130419043142.GA5055@elie.Belkin","threadId":"33517","inReplyTo":"7vobdb4hii.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-04-19T04:31:42Z","receivedAt":"2013-04-19T04:31:42Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Junio C Hamano wrote:\n\n> You ran 'git add' with neither '-A (--all)' or '--no-all', whose\n> behaviour will change in Git 2.0 with respect to paths you\n> removed from your working tree.\n>\n> * 'git add --no-all ', which is the current default,\n> ignores paths you removed from your working tree.\n>\n> * 'git add --all ' will let you also record the\n> removals.\n>\n> The removed paths (e.g. '%s') are ignored with this version of Git.\n> Run 'git status' to remind yourself what paths you have removed\n> from your working tree.\n>\n> or something?\n\nThat looks good. :)\n"},{"id":"214849","messageId":"7vbo9a3011.fsf@alter.siamese.dyndns.org","threadId":"33517","inReplyTo":"20130419043142.GA5055@elie.Belkin","subject":"Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-19T17:25:46Z","receivedAt":"2013-04-19T17:25:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n> Junio C Hamano wrote:\n>\n>> You ran 'git add' with neither '-A (--all)' or '--no-all', whose\n>> behaviour will change in Git 2.0 with respect to paths you\n>> removed from your working tree.\n>>\n>> * 'git add --no-all ', which is the current default,\n>> ignores paths you removed from your working tree.\n>>\n>> * 'git add --all ' will let you also record the\n>> removals.\n>>\n>> The removed paths (e.g. '%s') are ignored with this version of Git.\n>> Run 'git status' to remind yourself what paths you have removed\n>> from your working tree.\n>>\n>> or something?\n>\n> That looks good. :)\n\nI think the direction may be good but the above is too tall to be\nthe final version. of the message. Somebody good at phrasing needs\nto trim it down without losing the essense.\n"},{"id":"214888","messageId":"CABURp0pyAEppU7JL350vKtFQu_qBJ6YbzXTud+L7eEoPByGvYA@mail.gmail.com","threadId":"33517","inReplyTo":"CAMP44s2Yb+fSWYw0S7WuS-MEjKaSsnvndFw4ryZ8_Og6ioFcTQ@mail.gmail.com","subject":"Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)","fromName":"Phil Hord","fromEmail":"phil.hord@gmail.com","sentAt":"2013-04-19T21:07:47Z","receivedAt":"2013-04-19T21:07:47Z","isPatch":false,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"On Thu, Apr 18, 2013 at 7:48 PM, Felipe Contreras\n wrote:\n> On Thu, Apr 18, 2013 at 3:06 PM, Phil Hord wrote:\n>> On Wed, Apr 17, 2013 at 2:50 PM, Felipe Contreras\n>\n>>> Yes please. Show me one of the instances where you hit a bisect with\n>>> any of the remote-hg commits mentioned above by Thomas Rast.\n>>\n>> I made no such claim. In fact, I have never bisected to any\n>> remote-hg-related commit. I fail to see the relevance of this\n>> qualifier, though.\n>\n> Here, this is what you said:\n>\n> You:\n>> Me:\n>>> [skipping irrelevant comments]\n>>>\n>>> I'm sorry, did you actually hit an issue that required to look at the\n>>> commit message to understand where the issue came from? No? Then I\n>>> won't bother with hypotheticals.\n>>>\n>>> If you want to waste your time, by all means, rewrite all my commit\n>>> messages with essays that nobody will ever read. I'm not going to do\n>>> that for some hypothetical case that will never happen. I'm not going\n>>> to waste my time.\n>>\n>> This is not a hypothetical.\n>\n> If something is not hypothetical, it's real, which means it actually\n> happened, but then you said you never made the claim that it did. So\n> what is it?\n\nMy claim:\n\n I bisected to a commit whose commit message helped me deduce its entirety.\n\n\nYour fanciful interpretation, which I denied:\n\n \"Show me one of the instances where you hit a bisect with\n any of the remote-hg commits mentioned above by Thomas Rast.\"\n\n\nI have never bisected to any commit related to remote-hg, and neither\ndid I ever claim to. I do not know where you got such a ridiculous\nqualifier as this to append to my statement.\n\n\n> Either it did happen, or it didn't;\n\nIt did. Where \"it\" is my actual claim, that I bisected to a commit\nwhose commit message helped me deduce its entirety.\n\nBut also, it didn't, where \"it\" is your preposterous interpretation of\nmy interest and/or experiences with remote-hg commits.\n\nYou seem only to want to argue, Felipe. I have neither time nor\ninterest in pig-wrestling, myself.\n\nPhil\n"},{"id":"214891","messageId":"20130419213455.GB20873@sigill.intra.peff.net","threadId":"33517","inReplyTo":"7vbo9a3011.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-04-19T21:34:55Z","receivedAt":"2013-04-19T21:34:55Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Apr 19, 2013 at 10:25:46AM -0700, Junio C Hamano wrote:\n\n> Jonathan Nieder writes:\n> \n> > Junio C Hamano wrote:\n> >\n> >> You ran 'git add' with neither '-A (--all)' or '--no-all', whose\n> >> behaviour will change in Git 2.0 with respect to paths you\n> >> removed from your working tree.\n> >>\n> >> * 'git add --no-all ', which is the current default,\n> >> ignores paths you removed from your working tree.\n> >>\n> >> * 'git add --all ' will let you also record the\n> >> removals.\n> >>\n> >> The removed paths (e.g. '%s') are ignored with this version of Git.\n> >> Run 'git status' to remind yourself what paths you have removed\n> >> from your working tree.\n> >>\n> >> or something?\n> >\n> > That looks good. :)\n> \n> I think the direction may be good but the above is too tall to be\n> the final version. of the message. Somebody good at phrasing needs\n> to trim it down without losing the essense.\n\nHmph. I actually like it as it is. It says:\n\n 1. Here's what triggered this warning (removed paths without -A).\n\n 2. Here is how you tell git what you want to do (--all/--no-all)\n\n 3. Here is how you get more information about what you wanted to do\n (mention one such path, point to \"git status\").\n\nI would not want to cut out any of those three. You could perhaps cut\nout the bullet points in the middle, which reduces (2), but the user may\nbe able to figure it out from the first sentence. However, I like the\nexplicitness of those bullet points (and I prefer them to a wall of text\nwhich is more daunting to read).\n\n-Peff\n"},{"id":"214892","messageId":"7v61ziyykv.fsf@alter.siamese.dyndns.org","threadId":"33517","inReplyTo":"20130419213455.GB20873@sigill.intra.peff.net","subject":"Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-19T21:56:00Z","receivedAt":"2013-04-19T21:56:00Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Fri, Apr 19, 2013 at 10:25:46AM -0700, Junio C Hamano wrote:\n>\n>> Jonathan Nieder writes:\n>> \n>> > Junio C Hamano wrote:\n>> >\n>> >> You ran 'git add' with neither '-A (--all)' or '--no-all', whose\n>> >> behaviour will change in Git 2.0 with respect to paths you\n>> >> removed from your working tree.\n>> >>\n>> >> * 'git add --no-all ', which is the current default,\n>> >> ignores paths you removed from your working tree.\n>> >>\n>> >> * 'git add --all ' will let you also record the\n>> >> removals.\n>> >>\n>> >> The removed paths (e.g. '%s') are ignored with this version of Git.\n>> >> Run 'git status' to remind yourself what paths you have removed\n>> >> from your working tree.\n>> >>\n>> >> or something?\n>> >\n>> > That looks good. :)\n>> \n>> I think the direction may be good but the above is too tall to be\n>> the final version. of the message. Somebody good at phrasing needs\n>> to trim it down without losing the essense.\n>\n> Hmph. I actually like it as it is. It says:\n>\n> 1. Here's what triggered this warning (removed paths without -A).\n>\n> 2. Here is how you tell git what you want to do (--all/--no-all)\n>\n> 3. Here is how you get more information about what you wanted to do\n> (mention one such path, point to \"git status\").\n>\n> I would not want to cut out any of those three. You could perhaps cut\n> out the bullet points in the middle, which reduces (2), but the user may\n> be able to figure it out from the first sentence. However, I like the\n> explicitness of those bullet points (and I prefer them to a wall of text\n> which is more daunting to read).\n\nI think we are saying the same thing. I do agree with you that\nthese three points are \"the essense\" we do not want to lose.\n\nShrinking the first paragraph and the last paragraph to less than\nthree lines and each bullet point a single liner each was the kind\nof change I had in mind.\n"},{"id":"214896","messageId":"CAMP44s2dWNO2bcwzW=t5QEgQBNTEpBguwVUdkoFb6puhKV_3Yw@mail.gmail.com","threadId":"33517","inReplyTo":"CABURp0pyAEppU7JL350vKtFQu_qBJ6YbzXTud+L7eEoPByGvYA@mail.gmail.com","subject":"Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-20T01:29:12Z","receivedAt":"2013-04-20T01:29:12Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Fri, Apr 19, 2013 at 4:07 PM, Phil Hord wrote:\n> On Thu, Apr 18, 2013 at 7:48 PM, Felipe Contreras\n> wrote:\n\n>> If something is not hypothetical, it's real, which means it actually\n>> happened, but then you said you never made the claim that it did. So\n>> what is it?\n>\n> My claim:\n>\n> I bisected to a commit whose commit message helped me deduce its entirety.\n\nWhat a bold claim! That changes everything! Without your valuable\ninput this discussion would have gone nowhere!\n\nThis claim is absolutely worthless, nobody denies that somebody at\nsome point in time did bisect a commit and a read it's commit message,\nand claiming what nobody denies makes as much sense as fighting the\nwind.\n\nThanks for wasting all of our times.\n\n> Your fanciful interpretation, which I denied:\n>\n> \"Show me one of the instances where you hit a bisect with\n> any of the remote-hg commits mentioned above by Thomas Rast.\"\n>\n>\n> I have never bisected to any commit related to remote-hg, and neither\n> did I ever claim to. I do not know where you got such a ridiculous\n> qualifier as this to append to my statement.\n\nThat's *EXACTLY* the topic you replied to. Thomas Rast pointed to\nremote-hg commits, I asked if he hit an actual issue that required to\nlook at the commit message, or such issue was hypothetical.\n\nThen you come along and say it isn't, Well, what isn't? If it's not\nthe *EXACT* topic we were talking about.\n\n>> Either it did happen, or it didn't;\n>\n> It did. Where \"it\" is my actual claim, that I bisected to a commit\n> whose commit message helped me deduce its entirety.\n\nSo \"it\" is absolutely unrelated to what we were talking about, and\n\"it\" was something nobody cared about, nor did help one iota to move\nthe conversation forward.\n\nThanks, thanks a lot.\n\n> But also, it didn't, where \"it\" is your preposterous interpretation of\n> my interest and/or experiences with remote-hg commits.\n>\n> You seem only to want to argue, Felipe. I have neither time nor\n> interest in pig-wrestling, myself.\n\nNo, I don't want to argue, specially with people that either a) deny\nthat they argued what they argued, or b) argue with pointless obvious\nclaims about something that is not being discussed. Whether it's\nintellectual dishonesty, or plain madness, I'm not interested.\n\nHitting an issue that required anybody to look at the commit messages\nof the commits that Thomas Rast mentioned, is a hypothetical\nsituation. *Period*.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"214974","messageId":"20130421073918.GD10429@elie.Belkin","threadId":"33517","inReplyTo":"20130419213455.GB20873@sigill.intra.peff.net","subject":"jc/add-2.0-delete-default (Re: What's cooking in git.git (Apr 2013, #05; Mon, 15))","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-04-21T07:39:18Z","receivedAt":"2013-04-21T07:39:18Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"> On Fri, Apr 19, 2013 at 10:25:46AM -0700, Junio C Hamano wrote:\n>>> Junio C Hamano wrote:\n\n>>>> You ran 'git add' with neither '-A (--all)' or '--no-all', whose\n>>>> behaviour will change in Git 2.0 with respect to paths you\n>>>> removed from your working tree.\n>>>>\n>>>> * 'git add --no-all ', which is the current default,\n>>>> ignores paths you removed from your working tree.\n>>>>\n>>>> * 'git add --all ' will let you also record the\n>>>> removals.\n>>>>\n>>>> The removed paths (e.g. '%s') are ignored with this version of Git.\n>>>> Run 'git status' to remind yourself what paths you have removed\n>>>> from your working tree.\n>>>>\n>>>> or something?\n[...]\n>> Somebody good at phrasing needs\n>> to trim it down without losing the essense.\n\nBy the way, it was mentioned on IRC that the above is a bit odd for\na different reason: the option --no-all that maintains the old behavior\nis not intuitively named.\n\nHow about something like this?\n\n\twarning: \"git add\" run on path with files removed (e.g., '%s')\n\thint: use \"git add --ignore-removals \" to ignore removals\n\thint: or \"git add --no-ignore-removals \" to notice them\n\thint: --ignore-removals is the default but this will change soon\n\thint: see git-add(1) for details\n\nThen the --ignore-removals option could be added using a patch like\nthe following.\n\nSigned-off-by: Jonathan Nieder \n---\n Documentation/git-add.txt | 24 +++++++++++++++---------\n builtin/add.c | 28 +++++++++++++++++++++++++---\n 2 files changed, 40 insertions(+), 12 deletions(-)\n\ndiff --git a/Documentation/git-add.txt b/Documentation/git-add.txt\nindex b0944e57..8607cf37 100644\n--- a/Documentation/git-add.txt\n+++ b/Documentation/git-add.txt\n@@ -9,7 +9,8 @@ SYNOPSIS\n --------\n [verse]\n 'git add' [-n] [-v] [--force | -f] [--interactive | -i] [--patch | -p]\n-\t [--edit | -e] [--all | [--update | -u]] [--intent-to-add | -N]\n+\t [--edit | -e] [--update | -u] [--no-ignore-removals | -A]\n+\t [--intent-to-add | -N]\n \t [--refresh] [--ignore-errors] [--ignore-missing] [--]\n \t [...]\n \n@@ -109,17 +110,22 @@ If no is given, the current version of Git defaults to\n and its subdirectories. This default will change in a future version\n of Git, hence the form without should not be used.\n \n+--ignore-removals::\n+--no-ignore-removals::\n -A::\n --all::\n-\tUpdate the index not only where the working tree has a file\n-\tmatching but also where the index already has an\n-\tentry.\tThis adds, modifies, and removes index entries to\n-\tmatch the working tree.\n+\tUpdate the index only where the working tree has a file\n+\tmatching . This adds and modifies index entries\n+\tto match the working tree but ignores removed files.\n +\n-If no is given, the current version of Git defaults to\n-\".\"; in other words, update all files in the current directory\n-and its subdirectories. This default will change in a future version\n-of Git, hence the form without should not be used.\n+This is currently the default. Git 2.0 will change the default\n+to --no-ignore-removals.\n++\n+With --no-ignore-removals (and its historical synonyms `-A` and\n+`--all`), if no is given, the current version of Git\n+defaults to \".\"; in other words, update all files in the current\n+directory and its subdirectories. This default will change in a future\n+version of Git, hence the form without should not be used.\n \n -N::\n --intent-to-add::\ndiff --git a/builtin/add.c b/builtin/add.c\nindex ab1c9e8f..4a4e71ad 100644\n--- a/builtin/add.c\n+++ b/builtin/add.c\n@@ -28,6 +28,14 @@ struct update_callback_data {\n \tint add_errors;\n };\n \n+static int parse_opt_neg_tertiary(const struct option *opt, const char *arg,\n+\t\t\t\t int unset)\n+{\n+\tint *target = opt->value;\n+\t*target = unset ? 1 : 2;\n+\treturn 0;\n+}\n+\n static int fix_unmerged_status(struct diff_filepair *p,\n \t\t\t struct update_callback_data *data)\n {\n@@ -271,7 +279,8 @@ static const char ignore_error[] =\n N_(\"The following paths are ignored by one of your .gitignore files:\\n\");\n \n static int verbose = 0, show_only = 0, ignored_too = 0, refresh_only = 0;\n-static int ignore_add_errors, addremove, intent_to_add, ignore_missing = 0;\n+static int ignore_add_errors, intent_to_add, ignore_missing = 0;\n+static int ignore_removals, addremove;\n \n static struct option builtin_add_options[] = {\n \tOPT__DRY_RUN(&show_only, N_(\"dry run\")),\n@@ -283,10 +292,12 @@ static struct option builtin_add_options[] = {\n \tOPT__FORCE(&ignored_too, N_(\"allow adding otherwise ignored files\")),\n \tOPT_BOOLEAN('u', \"update\", &take_worktree_changes, N_(\"update tracked files\")),\n \tOPT_BOOLEAN('N', \"intent-to-add\", &intent_to_add, N_(\"record only the fact that the path will be added later\")),\n-\tOPT_BOOLEAN('A', \"all\", &addremove, N_(\"add changes from all tracked and untracked files\")),\n+\tOPT_UYN( 0 , \"ignore-removals\", &ignore_removals, N_(\"do not record removal of tracked files\")),\n \tOPT_BOOLEAN( 0 , \"refresh\", &refresh_only, N_(\"don't add, only refresh the index\")),\n \tOPT_BOOLEAN( 0 , \"ignore-errors\", &ignore_add_errors, N_(\"just skip files which cannot be added because of errors\")),\n \tOPT_BOOLEAN( 0 , \"ignore-missing\", &ignore_missing, N_(\"check if - even missing - files are ignored in dry run\")),\n+\t{ OPTION_CALLBACK, 'A', \"all\", &ignore_removals, NULL, N_(\"synonym for --no-ignore-removals\"),\n+\t PARSE_OPT_HIDDEN | PARSE_OPT_NOARG, &parse_opt_neg_tertiary },\n \tOPT_END(),\n };\n \n@@ -377,8 +388,19 @@ int cmd_add(int argc, const char **argv, const char *prefix)\n \targc--;\n \targv++;\n \n+\tif (ignore_removals == 2) {\t/* --no-ignore-removals, or -A */\n+\t\taddremove = 1;\n+\t\tignore_removals = 0;\n+\t}\n+\tif (ignore_removals && take_worktree_changes)\n+\t\t/*\n+\t\t * NEEDSWORK: \"git add -u --ignore-removals\" should mean\n+\t\t * \"git diff --diff-filter=M | git apply --cached\"\n+\t\t */\n+\t\tdie(_(\"--ignore-removals cannot be used with --update\"));\n \tif (addremove && take_worktree_changes)\n-\t\tdie(_(\"-A and -u are mutually incompatible\"));\n+\t\t/* -u --no-ignore-removals is the same as -u */\n+\t\taddremove = 0;\n \tif (!show_only && ignore_missing)\n \t\tdie(_(\"Option --ignore-missing can only be used together with --dry-run\"));\n \tif (addremove) {\n-- \n1.8.2.1\n"},{"id":"215049","messageId":"7vsj2jqqmu.fsf@alter.siamese.dyndns.org","threadId":"33517","inReplyTo":"20130421073918.GD10429@elie.Belkin","subject":"Re: jc/add-2.0-delete-default (Re: What's cooking in git.git (Apr 2013, #05; Mon, 15))","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-22T01:51:37Z","receivedAt":"2013-04-22T01:51:37Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n> How about something like this?\n>\n> \twarning: \"git add\" run on path with files removed (e.g., '%s')\n> \thint: use \"git add --ignore-removals \" to ignore removals\n> \thint: or \"git add --no-ignore-removals \" to notice them\n> \thint: --ignore-removals is the default but this will change soon\n> \thint: see git-add(1) for details\n>\n> Then the --ignore-removals option could be added using a patch like\n> the following.\n\nadding ignore-removals as a synonym (and keeping it) would be a good\nidea.\n\nWe would still need to carry --all and --no-all that have been with\nus ever since we added \"-A\" option, though.\n"},{"id":"215051","messageId":"7vehe3qi5m.fsf@alter.siamese.dyndns.org","threadId":"33517","inReplyTo":"7vsj2jqqmu.fsf@alter.siamese.dyndns.org","subject":"Re: jc/add-2.0-delete-default (Re: What's cooking in git.git (Apr 2013, #05; Mon, 15))","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-22T04:54:45Z","receivedAt":"2013-04-22T04:54:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n>> Then the --ignore-removals option could be added using a patch like\n>> the following.\n>\n> adding ignore-removals as a synonym (and keeping it) would be a good\n> idea.\n>\n> We would still need to carry --all and --no-all that have been with\n> us ever since we added \"-A\" option, though.\n\nThe final step to turn \"-A\" the default will be held back until Git 2.0 release,\nbut I've inserted the following patch before that step.\n\nI am thinking that it would be a good idea to merge up to this step\nto 'master' tomorrow, and have you guys tweak it further on 'master'\nwith a patch like the one I am responding to, before the 1.8.3\nfinal. We will have to tweak the 2.0 endgame version as we go but\nthat is outside 'next' for now, so it should be manageable.\n\n-- >8 --\nSubject: [PATCH] git add: rephrase the \"removal will cease to be ignored\" warning\n\nNow the logic to decide when to warn has been tightened, we know the\nuser is in a situation where the current and future behaviours will\nbe different. Spell out what happens with these two versions and\nhow to explicitly ask for the behaviour, and suggest \"git status\" as\na way to inspect the current status.\n\nSigned-off-by: Junio C Hamano \n---\n builtin/add.c | 21 ++++++++++++++-------\n 1 file changed, 14 insertions(+), 7 deletions(-)\n\ndiff --git a/builtin/add.c b/builtin/add.c\nindex 4242bce..20f459a 100644\n--- a/builtin/add.c\n+++ b/builtin/add.c\n@@ -52,15 +52,22 @@ static int fix_unmerged_status(struct diff_filepair *p,\n \t\treturn DIFF_STATUS_MODIFIED;\n }\n \n+static const char *add_would_remove_warning = N_(\n+\t\"You ran 'git add' with neither '-A (--all)' or '--no-all', whose\\n\"\n+\"behaviour will change in Git 2.0 with respect to paths you removed from\\n\"\n+\"your working tree. Paths like '%s' that are\\n\"\n+\"removed are ignored with this version of Git.\\n\"\n+\"\\n\"\n+\"* 'git add --no-all ', which is the current default, ignores\\n\"\n+\" paths you removed from your working tree.\\n\"\n+\"\\n\"\n+\"* 'git add --all ' will let you also record the removals.\\n\"\n+\"\\n\"\n+\"Run 'git status' to check the paths you removed from your working tree.\\n\");\n+\n static void warn_add_would_remove(const char *path)\n {\n-\twarning(_(\"In Git 2.0, 'git add ...' will also update the\\n\"\n-\t\t \"index for paths removed from the working tree that match\\n\"\n-\t\t \"the given pathspec. If you want to 'add' only changed\\n\"\n-\t\t \"or newly created paths, say 'git add --no-all ...'\"\n-\t\t \" instead.\\n\\n\"\n-\t\t \"'%s' would be removed from the index without --no-all.\"),\n-\t\tpath);\n+\twarning(_(add_would_remove_warning), path);\n }\n \n static void update_callback(struct diff_queue_struct *q,\n-- \n1.8.2.1-650-g3c8b519\n"},{"id":"215150","messageId":"1366663435-13598-1-git-send-email-gitster@pobox.com","threadId":"33517","inReplyTo":"7vehe3qi5m.fsf@alter.siamese.dyndns.org","subject":"[PATCH 0/2] \"git add -A/--no-all\" finishing touches","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-22T20:43:53Z","receivedAt":"2013-04-22T20:43:53Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Applying Jonathan's idea on top of the early part that has graduated\nto 'master', here is to add \"--ignore-removal\" (which is a more\nnatural way to say \"--no-all\") and use it in the warning message.\n\nJunio C Hamano (2):\n git add: --ignore-removal is a better named --no-all\n git add: rephrase -A/--no-all warning\n\n Documentation/git-add.txt | 10 ++++++----\n builtin/add.c | 23 +++++++++++++++++------\n 2 files changed, 23 insertions(+), 10 deletions(-)\n\n-- \n1.8.2.1-683-g39c426e\n"},{"id":"215151","messageId":"1366663435-13598-2-git-send-email-gitster@pobox.com","threadId":"33517","inReplyTo":"1366663435-13598-1-git-send-email-gitster@pobox.com","subject":"[PATCH 1/2] git add: --ignore-removal is a better named --no-all","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-22T20:43:54Z","receivedAt":"2013-04-22T20:43:54Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"In the historical context of \"git add --all .\" that tells the\ncommand to pay attention to \"all kinds of changes\" (implying\n\"without ignoring removals\"), the option \"--no-all\" to countermand\nit may have made some sense, but because we will be making \"--all\"\nthe default when a pathspec is given, it makes more sense to rename\nthe option to a more explicit \"--ignore-removal\". The \"-all\" option\nnaturally becomes its negation: \"--no-ignore-removal\".\n\nSigned-off-by: Junio C Hamano \n---\n Documentation/git-add.txt | 10 ++++++----\n builtin/add.c | 11 +++++++++++\n 2 files changed, 17 insertions(+), 4 deletions(-)\n\ndiff --git a/Documentation/git-add.txt b/Documentation/git-add.txt\nindex 5c501a2..48754cb 100644\n--- a/Documentation/git-add.txt\n+++ b/Documentation/git-add.txt\n@@ -9,9 +9,9 @@ SYNOPSIS\n --------\n [verse]\n 'git add' [-n] [-v] [--force | -f] [--interactive | -i] [--patch | -p]\n-\t [--edit | -e] [--[no-]all | [--update | -u]] [--intent-to-add | -N]\n-\t [--refresh] [--ignore-errors] [--ignore-missing] [--]\n-\t [...]\n+\t [--edit | -e] [--[no-]all | --[no-]ignore-removal | [--update | -u]]\n+\t [--intent-to-add | -N] [--refresh] [--ignore-errors] [--ignore-missing]\n+\t [--] [...]\n \n DESCRIPTION\n -----------\n@@ -111,6 +111,7 @@ of Git, hence the form without should not be used.\n \n -A::\n --all::\n+--no-ignore-removal::\n \tUpdate the index not only where the working tree has a file\n \tmatching but also where the index already has an\n \tentry.\tThis adds, modifies, and removes index entries to\n@@ -122,6 +123,7 @@ and its subdirectories. This default will change in a future version\n of Git, hence the form without should not be used.\n \n --no-all::\n+--ignore-removal::\n \tUpdate the index by adding new files that are unknown to the\n \tindex and files modified in the working tree, but ignore\n \tfiles that have been removed from the working tree. This\n@@ -130,7 +132,7 @@ of Git, hence the form without should not be used.\n This option is primarily to help the current users of Git, whose\n \"git add ...\" ignores removed files. In future versions\n of Git, \"git add ...\" will be a synonym to \"git add -A\n-...\" and \"git add --no-all ...\" will behave like\n+...\" and \"git add --ignore-removal ...\" will behave like\n today's \"git add ...\", ignoring removed files.\n \n -N::\ndiff --git a/builtin/add.c b/builtin/add.c\nindex 54cd2d4..aefbc45 100644\n--- a/builtin/add.c\n+++ b/builtin/add.c\n@@ -382,6 +382,13 @@ static int ignore_add_errors, intent_to_add, ignore_missing;\n static int addremove = ADDREMOVE_DEFAULT;\n static int addremove_explicit = -1; /* unspecified */\n \n+static int ignore_removal_cb(const struct option *opt, const char *arg, int unset)\n+{\n+\t/* if we are told to ignore, we are not adding removals */\n+\t*(int *)opt->value = !unset ? 0 : 1;\n+\treturn 0;\n+}\n+\n static struct option builtin_add_options[] = {\n \tOPT__DRY_RUN(&show_only, N_(\"dry run\")),\n \tOPT__VERBOSE(&verbose, N_(\"be verbose\")),\n@@ -393,6 +400,10 @@ static struct option builtin_add_options[] = {\n \tOPT_BOOL('u', \"update\", &take_worktree_changes, N_(\"update tracked files\")),\n \tOPT_BOOL('N', \"intent-to-add\", &intent_to_add, N_(\"record only the fact that the path will be added later\")),\n \tOPT_BOOL('A', \"all\", &addremove_explicit, N_(\"add changes from all tracked and untracked files\")),\n+\t{ OPTION_CALLBACK, 0, \"ignore-removal\", &addremove_explicit,\n+\t NULL /* takes no arguments */,\n+\t N_(\"ignore paths removed in the working tree (same as --no-all)\"),\n+\t PARSE_OPT_NOARG, ignore_removal_cb },\n \tOPT_BOOL( 0 , \"refresh\", &refresh_only, N_(\"don't add, only refresh the index\")),\n \tOPT_BOOL( 0 , \"ignore-errors\", &ignore_add_errors, N_(\"just skip files which cannot be added because of errors\")),\n \tOPT_BOOL( 0 , \"ignore-missing\", &ignore_missing, N_(\"check if - even missing - files are ignored in dry run\")),\n-- \n1.8.2.1-683-g39c426e\n"},{"id":"215152","messageId":"1366663435-13598-3-git-send-email-gitster@pobox.com","threadId":"33517","inReplyTo":"1366663435-13598-1-git-send-email-gitster@pobox.com","subject":"[PATCH 2/2] git add: rephrase -A/--no-all warning","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-22T20:43:55Z","receivedAt":"2013-04-22T20:43:55Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"With the synonym \"--ignore-removal\" for \"--no-all\", we can rephrase\nthe Git 2.0 transition warning message in a more natural way.\n\nSigned-off-by: Junio C Hamano \n---\n builtin/add.c | 12 ++++++------\n 1 file changed, 6 insertions(+), 6 deletions(-)\n\ndiff --git a/builtin/add.c b/builtin/add.c\nindex aefbc45..c55615b 100644\n--- a/builtin/add.c\n+++ b/builtin/add.c\n@@ -97,13 +97,13 @@ static int fix_unmerged_status(struct diff_filepair *p,\n }\n \n static const char *add_would_remove_warning = N_(\n-\t\"You ran 'git add' with neither '-A (--all)' or '--no-all', whose\\n\"\n-\"behaviour will change in Git 2.0 with respect to paths you removed from\\n\"\n-\"your working tree. Paths like '%s' that are\\n\"\n-\"removed are ignored with this version of Git.\\n\"\n+\t\"You ran 'git add' with neither '-A (--all)' or '--ignore-removal',\\n\"\n+\"whose behaviour will change in Git 2.0 with respect to paths you removed.\\n\"\n+\"Paths like '%s' that are\\n\"\n+\"removed from your working tree are ignored with this version of Git.\\n\"\n \"\\n\"\n-\"* 'git add --no-all ', which is the current default, ignores\\n\"\n-\" paths you removed from your working tree.\\n\"\n+\"* 'git add --ignore-removal ', which is the current default,\\n\"\n+\" ignores paths you removed from your working tree.\\n\"\n \"\\n\"\n \"* 'git add --all ' will let you also record the removals.\\n\"\n \"\\n\"\n-- \n1.8.2.1-683-g39c426e\n"},{"id":"215188","messageId":"7vr4i2mbmb.fsf_-_@alter.siamese.dyndns.org","threadId":"33517","inReplyTo":"1366663435-13598-1-git-send-email-gitster@pobox.com","subject":"[PATCH 3/2] git add ... defaults to \"-A\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-22T22:41:48Z","receivedAt":"2013-04-22T22:41:48Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Make \"git add ...\" notice paths that have been removed\nfrom the working tree, i.e. a synonym to \"git add -A ...\".\n\nGiven that \"git add \" is to update the index with the\nstate of the named part of the working tree as a whole, it makes it\nmore intuitive, and also makes it possible to simplify the advice we\ngive while marking the paths the user finished resolving conflicts\nwith. We used to say \"to record removal as a resolution, remove the\npath from the working tree and say 'git rm'; for all other cases,\nedit the path in the working tree and say 'git add'\", but we can now\nsay \"update the path in the working tree and say 'git add'\" instead.\n\nAs promised, this merges the temporary update_files_in_cache() helper\nfunction back to add_files_to_cache() function.\n\nSigned-off-by: Junio C Hamano \n---\n\n * This comes on top of the previous two meant for 1.8.3, but should\n wait until Git 2.0. You can see that it still has conflicts with\n Jonathan's jn/add-2.0-u-A-sans-pathspec topic, but there is a\n resolution already prepared on 'pu'.\n\n Documentation/git-add.txt | 18 +++++++++++-------\n builtin/add.c | 43 ++++---------------------------------------\n 2 files changed, 15 insertions(+), 46 deletions(-)\n\ndiff --git a/Documentation/git-add.txt b/Documentation/git-add.txt\nindex 48754cb..77ad391 100644\n--- a/Documentation/git-add.txt\n+++ b/Documentation/git-add.txt\n@@ -53,8 +53,14 @@ OPTIONS\n \tFiles to add content from. Fileglobs (e.g. `*.c`) can\n \tbe given to add all matching files. Also a\n \tleading directory name (e.g. `dir` to add `dir/file1`\n-\tand `dir/file2`) can be given to add all files in the\n-\tdirectory, recursively.\n+\tand `dir/file2`) can be given to update the index to\n+\tmatch the current state of the directory as a whole (e.g.\n+\tspecifying `dir` will record not just a file `dir/file1`\n+\tmodified in the working tree, a file `dir/file2` added to\n+\tthe working tree, but also a file `dir/file3` removed from\n+\tthe working tree. Note that older versions of \tGit used\n+\tto ignore removed files; use `--no-all` option if you want\n+\tto add modified or new files but ignore removed\tones.\n \n -n::\n --dry-run::\n@@ -129,11 +135,9 @@ of Git, hence the form without should not be used.\n \tfiles that have been removed from the working tree. This\n \toption is a no-op when no is used.\n +\n-This option is primarily to help the current users of Git, whose\n-\"git add ...\" ignores removed files. In future versions\n-of Git, \"git add ...\" will be a synonym to \"git add -A\n-...\" and \"git add --ignore-removal ...\" will behave like\n-today's \"git add ...\", ignoring removed files.\n+This option is primarily to help users who are used to older\n+versions of Git, whose \"git add ...\" was a synonym\n+to \"git add --no-all ...\", i.e. ignored removed files.\n \n -N::\n --intent-to-add::\ndiff --git a/builtin/add.c b/builtin/add.c\nindex c55615b..22c5ff5 100644\n--- a/builtin/add.c\n+++ b/builtin/add.c\n@@ -28,9 +28,6 @@ struct update_callback_data {\n \tint add_errors;\n \tconst char *implicit_dot;\n \tsize_t implicit_dot_len;\n-\n-\t/* only needed for 2.0 transition preparation */\n-\tint warn_add_would_remove;\n };\n \n static const char *option_with_implicit_dot;\n@@ -96,24 +93,6 @@ static int fix_unmerged_status(struct diff_filepair *p,\n \t\treturn DIFF_STATUS_MODIFIED;\n }\n \n-static const char *add_would_remove_warning = N_(\n-\t\"You ran 'git add' with neither '-A (--all)' or '--ignore-removal',\\n\"\n-\"whose behaviour will change in Git 2.0 with respect to paths you removed.\\n\"\n-\"Paths like '%s' that are\\n\"\n-\"removed from your working tree are ignored with this version of Git.\\n\"\n-\"\\n\"\n-\"* 'git add --ignore-removal ', which is the current default,\\n\"\n-\" ignores paths you removed from your working tree.\\n\"\n-\"\\n\"\n-\"* 'git add --all ' will let you also record the removals.\\n\"\n-\"\\n\"\n-\"Run 'git status' to check the paths you removed from your working tree.\\n\");\n-\n-static void warn_add_would_remove(const char *path)\n-{\n-\twarning(_(add_would_remove_warning), path);\n-}\n-\n static void update_callback(struct diff_queue_struct *q,\n \t\t\t struct diff_options *opt, void *cbdata)\n {\n@@ -151,10 +130,6 @@ static void update_callback(struct diff_queue_struct *q,\n \t\t\t}\n \t\t\tbreak;\n \t\tcase DIFF_STATUS_DELETED:\n-\t\t\tif (data->warn_add_would_remove) {\n-\t\t\t\twarn_add_would_remove(path);\n-\t\t\t\tdata->warn_add_would_remove = 0;\n-\t\t\t}\n \t\t\tif (data->flags & ADD_CACHE_IGNORE_REMOVAL)\n \t\t\t\tbreak;\n \t\t\tif (!(data->flags & ADD_CACHE_PRETEND))\n@@ -378,7 +353,7 @@ N_(\"The following paths are ignored by one of your .gitignore files:\\n\");\n static int verbose, show_only, ignored_too, refresh_only;\n static int ignore_add_errors, intent_to_add, ignore_missing;\n \n-#define ADDREMOVE_DEFAULT 0 /* Change to 1 in Git 2.0 */\n+#define ADDREMOVE_DEFAULT 1\n static int addremove = ADDREMOVE_DEFAULT;\n static int addremove_explicit = -1; /* unspecified */\n \n@@ -476,20 +451,9 @@ int cmd_add(int argc, const char **argv, const char *prefix)\n \tif (addremove && take_worktree_changes)\n \t\tdie(_(\"-A and -u are mutually incompatible\"));\n \n-\t/*\n-\t * Warn when \"git add pathspec...\" was given without \"-u\" or \"-A\"\n-\t * and pathspec... covers a removed path.\n-\t */\n-\tmemset(&update_data, 0, sizeof(update_data));\n-\tif (!take_worktree_changes && addremove_explicit < 0)\n-\t\tupdate_data.warn_add_would_remove = 1;\n-\n \tif (!take_worktree_changes && addremove_explicit < 0 && argc)\n-\t\t/*\n-\t\t * Turn \"git add pathspec...\" to \"git add -A pathspec...\"\n-\t\t * in Git 2.0 but not yet\n-\t\t */\n-\t\t; /* addremove = 1; */\n+\t\t/* Turn \"git add pathspec...\" to \"git add -A pathspec...\" */\n+\t\taddremove = 1;\n \n \tif (!show_only && ignore_missing)\n \t\tdie(_(\"Option --ignore-missing can only be used together with --dry-run\"));\n@@ -579,6 +543,7 @@ int cmd_add(int argc, const char **argv, const char *prefix)\n \n \tplug_bulk_checkin();\n \n+\tmemset(&update_data, 0, sizeof(update_data));\n \tif ((flags & ADD_CACHE_IMPLICIT_DOT) && prefix) {\n \t\t/*\n \t\t * Check for modified files throughout the worktree so\n-- \n1.8.2.1-740-ga5571a3\n"},{"id":"215196","messageId":"CAPig+cTQyxacsCpUs+bSotusOb16kXwGgmxssongr237i=89iA@mail.gmail.com","threadId":"33517","inReplyTo":"7vr4i2mbmb.fsf_-_@alter.siamese.dyndns.org","subject":"Re: [PATCH 3/2] git add ... defaults to \"-A\"","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2013-04-23T00:42:13Z","receivedAt":"2013-04-23T00:42:13Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Mon, Apr 22, 2013 at 6:41 PM, Junio C Hamano wrote:\n> diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt\n> index 48754cb..77ad391 100644\n> --- a/Documentation/git-add.txt\n> +++ b/Documentation/git-add.txt\n> @@ -53,8 +53,14 @@ OPTIONS\n> Files to add content from. Fileglobs (e.g. `*.c`) can\n> be given to add all matching files. Also a\n> leading directory name (e.g. `dir` to add `dir/file1`\n> - and `dir/file2`) can be given to add all files in the\n> - directory, recursively.\n> + and `dir/file2`) can be given to update the index to\n> + match the current state of the directory as a whole (e.g.\n> + specifying `dir` will record not just a file `dir/file1`\n> + modified in the working tree, a file `dir/file2` added to\n> + the working tree, but also a file `dir/file3` removed from\n> + the working tree. Note that older versions of Git used\n\ns/of\\s+Git/of Git/\n\n> + to ignore removed files; use `--no-all` option if you want\n> + to add modified or new files but ignore removed ones.\n>\n> -n::\n> --dry-run::\n> @@ -129,11 +135,9 @@ of Git, hence the form without should not be used.\n> files that have been removed from the working tree. This\n> option is a no-op when no is used.\n> +\n> -This option is primarily to help the current users of Git, whose\n> -\"git add ...\" ignores removed files. In future versions\n> -of Git, \"git add ...\" will be a synonym to \"git add -A\n> -...\" and \"git add --ignore-removal ...\" will behave like\n> -today's \"git add ...\", ignoring removed files.\n> +This option is primarily to help users who are used to older\n> +versions of Git, whose \"git add ...\" was a synonym\n> +to \"git add --no-all ...\", i.e. ignored removed files.\n\ns/to/for/ [or] s/to/of/\n\n>\n> -N::\n> --intent-to-add::\n"},{"id":"215267","messageId":"CALkWK0m05nWS=fQVCkFhNx7BT6_7qHN8W2WVW=6mGFeKKfN1Mw@mail.gmail.com","threadId":"33517","inReplyTo":"CAMP44s162msct=W0eV93LX15Bho=DA1baLZcgFCouSRH=z0mDQ@mail.gmail.com","subject":"Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-23T18:49:26Z","receivedAt":"2013-04-23T18:49:26Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"[off-topic; what happened/happens to your series is entirely unrelated\nto the issue]\n\nFelipe Contreras wrote:\n> Nobody knows how life began, and it doesn't matter now, what matters\n> is how life evolves. It doesn't matter if the chicken was first, or\n> the egg, what matters is that if all the chickens and eggs are gone,\n> there won't be more.\n>\n> Plenty of projects have died because they stopped caring about their\n> users, and without users there's no new developers, and the old\n> developers eventually move on, and all the literary quality of commit\n> messages have no eyes to see it.\n\nI was a pure end-user of git until about Jan 2010. I was initially\nimpressed with git because it behaved in a beautiful consistent\nmanner. Then I dug in and found out that it had a beautiful codebase,\nexcellent mailing list (content and conventions), and large\ndevelopment community. I could literally read through the commit\nmessages and code with ease. I do bounce between a few projects, but\nalways come back to git because nothing else fits the criterion. What\nI do not consider (as much as the other things) is the\nnumber-of-end-users.\n\nThen again, you would argue that I came across git only because of a\nlarge enough user-base. I agree with that, but you're practically\nidolizing user-base as the most important thing.\n\nMy point is simple: yes, it's nice to have a big user base. We\nalready do. Now, what's the point of pitching to end-users who only\nuse the most basic functionality? Their inputs are likely to be\nuseless (arising from misunderstandings) anyway. They're not going to\nbe the next developers. And they're not going to help create what our\nnext developer is looking for in us either (i.e. codebase, community).\n\nOur primary customers are each other, because that's how we get a\ntight community and great codebase. And because the next potential\ndeveloper looks like one of us.\n\nThat does _not_ mean: live only within the community. Everyone should\nhave a healthy interaction with the outside world, otherwise they risk\nturning into researchers and suffering engineering myopia. And\nofcourse not attract a large userbase.\n"},{"id":"215268","messageId":"CAMP44s2QVOSgT+GdZ9BhahGXmtJXO4Fv_WmPSkmEzjsdbe0hDw@mail.gmail.com","threadId":"33517","inReplyTo":"CALkWK0m05nWS=fQVCkFhNx7BT6_7qHN8W2WVW=6mGFeKKfN1Mw@mail.gmail.com","subject":"Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-04-23T19:11:01Z","receivedAt":"2013-04-23T19:11:01Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, Apr 23, 2013 at 1:49 PM, Ramkumar Ramachandra\n wrote:\n\n> My point is simple: yes, it's nice to have a big user base. We\n> already do. Now, what's the point of pitching to end-users who only\n> use the most basic functionality? Their inputs are likely to be\n> useless (arising from misunderstandings) anyway. They're not going to\n> be the next developers. And they're not going to help create what our\n> next developer is looking for in us either (i.e. codebase, community).\n\nThat is your mistake right there. They *are* the next developers, you\nyourself came from there. We all did.\n\nIn fact, this notion that there's a divide between users and\ndevelopers is a myth; it's a continuum that follows the Pareto\ndistribution. It happens in every healthy open source project.\n\nAnd this is not an assumption, I've measured it:\n\nhttp://felipec.wordpress.com/2011/11/21/no-project-is-more-important-than-its-users/\n\n70% of the commits in git.git come from people that have provided less\nthan 6 patches. That 70% (maybe 80%, maybe 90%) would have never\nhappened, if git didn't have a large enough user-base. I'm not\nidolizing the user-base, this project *is* the user-base, developers\nare users, and without users there's no project.\n\nAgain, in the words of Linus: no project is more important than it's users.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"215520","messageId":"7vhaiu1a89.fsf@alter.siamese.dyndns.org","threadId":"33517","inReplyTo":"1366663435-13598-1-git-send-email-gitster@pobox.com","subject":"Re: [PATCH 0/2] \"git add -A/--no-all\" finishing touches","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-25T23:06:30Z","receivedAt":"2013-04-25T23:06:30Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Applying Jonathan's idea on top of the early part that has graduated\n> to 'master', here is to add \"--ignore-removal\" (which is a more\n> natural way to say \"--no-all\") and use it in the warning message.\n>\n> Junio C Hamano (2):\n> git add: --ignore-removal is a better named --no-all\n> git add: rephrase -A/--no-all warning\n>\n> Documentation/git-add.txt | 10 ++++++----\n> builtin/add.c | 23 +++++++++++++++++------\n> 2 files changed, 23 insertions(+), 10 deletions(-)\n\nI am planning to fast-track this to 'master' for 1.8.3, to\ncomplement Jonathan's \"add -u/-A without pathspec\" warning.\n\nIt would be nice if people can eyeball the behaviour of tonight's\n'next', find glitches (if any) and help polishing it before the\nfeature freeze.\n\nOne thing I noticed about Jonathan's warn_pathless_add() thing is\nthat even though it knows for which path we would behave differently\nbetween the current version and Git 2.0, the warning message does\nnot say which path outside the current directory would be added if\nnot restricted with an explicit \".\", and leaves the reader in\nsuspense.\n\nWe may want to fix it by tweaking the end of the message, perhaps?\n\n builtin/add.c | 14 +++++++++-----\n 1 file changed, 9 insertions(+), 5 deletions(-)\n\ndiff --git a/builtin/add.c b/builtin/add.c\nindex d4b40f2..24a2d6f 100644\n--- a/builtin/add.c\n+++ b/builtin/add.c\n@@ -36,7 +36,7 @@ struct update_callback_data {\n static const char *option_with_implicit_dot;\n static const char *short_option_with_implicit_dot;\n \n-static void warn_pathless_add(void)\n+static void warn_pathless_add(const char *path)\n {\n \tstatic int shown;\n \tassert(option_with_implicit_dot && short_option_with_implicit_dot);\n@@ -67,12 +67,16 @@ static void warn_pathless_add(void)\n \t\t \" git add %s .\\n\"\n \t\t \" (or git add %s .)\\n\"\n \t\t \"\\n\"\n-\t\t \"With the current Git version, the command is restricted to \"\n-\t\t \"the current directory.\\n\"\n+\t\t \"With the current Git version, the command is limited to the current\"\n+\t\t \"directory, and paths like '%s'\\n\"\n+\t\t \"that %s are not added.\\n\"\n \t\t \"\"),\n \t\toption_with_implicit_dot, short_option_with_implicit_dot,\n \t\toption_with_implicit_dot, short_option_with_implicit_dot,\n-\t\toption_with_implicit_dot, short_option_with_implicit_dot);\n+\t\toption_with_implicit_dot, short_option_with_implicit_dot,\n+\t\tpath,\n+\t\t(!strcmp(short_option_with_implicit_dot, \"-u\")\n+\t\t ? _(\"are modified\") : _(\"are new\")));\n }\n \n static int fix_unmerged_status(struct diff_filepair *p,\n@@ -136,7 +140,7 @@ static void update_callback(struct diff_queue_struct *q,\n \t\t */\n \t\tif (implicit_dot &&\n \t\t strncmp_icase(path, implicit_dot, implicit_dot_len)) {\n-\t\t\twarn_pathless_add();\n+\t\t\twarn_pathless_add(path);\n \t\t\tcontinue;\n \t\t}\n \t\tswitch (fix_unmerged_status(p, data)) {\n"},{"id":"215522","messageId":"7v4neu19mj.fsf@alter.siamese.dyndns.org","threadId":"33517","inReplyTo":"7vhaiu1a89.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 0/2] \"git add -A/--no-all\" finishing touches","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-25T23:19:32Z","receivedAt":"2013-04-25T23:19:32Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> One thing I noticed about Jonathan's warn_pathless_add() thing is\n> that even though it knows for which path we would behave differently\n> between the current version and Git 2.0, the warning message does\n> not say which path outside the current directory would be added if\n> not restricted with an explicit \".\", and leaves the reader in\n> suspense.\n>\n> We may want to fix it by tweaking the end of the message, perhaps?\n\nHmph, bad idea.\n\nAt the point of calling warn_pathless_add(), it seems that we are\ntriggering this for paths that are not necessarily modified when run\nwith \"add -n -u\".\n"},{"id":"215524","messageId":"20130425232410.GN29963@google.com","threadId":"33517","inReplyTo":"7v4neu19mj.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 0/2] \"git add -A/--no-all\" finishing touches","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-04-25T23:24:10Z","receivedAt":"2013-04-25T23:24:10Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Junio C Hamano wrote:\n\n> At the point of calling warn_pathless_add(), it seems that we are\n> triggering this for paths that are not necessarily modified when run\n> with \"add -n -u\".\n\nDo you mean files that were touched but have no content change, or\nsomething more subtle?\n"},{"id":"215526","messageId":"7vvc7ayy84.fsf@alter.siamese.dyndns.org","threadId":"33517","inReplyTo":"20130425232410.GN29963@google.com","subject":"Re: [PATCH 0/2] \"git add -A/--no-all\" finishing touches","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-25T23:41:47Z","receivedAt":"2013-04-25T23:41:47Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n> Junio C Hamano wrote:\n>\n>> At the point of calling warn_pathless_add(), it seems that we are\n>> triggering this for paths that are not necessarily modified when run\n>> with \"add -n -u\".\n>\n> Do you mean files that were touched but have no content change, or\n> something more subtle?\n\nI had the change (which by the way needs a fix for the \"found a\ndirectory\" codepath) on top of master, uncommitted, and no other\nchange (I also have some cruft that is not ignored).\n\n cd Documentation && ../git add -n -u\n\nreported GIT-VERSION-GEN which was not touched. It does not\nreproduce, though...\n"},{"id":"215527","messageId":"7vobd2yy3c.fsf@alter.siamese.dyndns.org","threadId":"33517","inReplyTo":"7vvc7ayy84.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 0/2] \"git add -A/--no-all\" finishing touches","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-25T23:44:39Z","receivedAt":"2013-04-25T23:44:39Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Jonathan Nieder writes:\n>\n>> Junio C Hamano wrote:\n>>\n>>> At the point of calling warn_pathless_add(), it seems that we are\n>>> triggering this for paths that are not necessarily modified when run\n>>> with \"add -n -u\".\n>>\n>> Do you mean files that were touched but have no content change, or\n>> something more subtle?\n>\n> I had the change (which by the way needs a fix for the \"found a\n> directory\" codepath) on top of master, uncommitted, and no other\n> change (I also have some cruft that is not ignored).\n>\n> cd Documentation && ../git add -n -u\n>\n> reported GIT-VERSION-GEN which was not touched. It does not\n> reproduce, though...\n\nAhh, I haven't run anything under the debugger yet, but I think I\nknow what is going on.\n\nDon't we limit our \"update-index --refresh\" equivalent to the\noriginal pathspec, even though your \"-u/-A sans pathspec\" warning\ndetection relies on grabbing the changes from the entire tree?\n"},{"id":"215528","messageId":"20130425235624.GO29963@google.com","threadId":"33517","inReplyTo":"7vobd2yy3c.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 0/2] \"git add -A/--no-all\" finishing touches","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-04-25T23:56:24Z","receivedAt":"2013-04-25T23:56:24Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Junio C Hamano wrote:\n>> Jonathan Nieder writes:\n\n>>> Do you mean files that were touched but have no content change, or\n>>> something more subtle?\n[...]\n> Ahh, I haven't run anything under the debugger yet, but I think I\n> know what is going on.\n>\n> Don't we limit our \"update-index --refresh\" equivalent to the\n> original pathspec, even though your \"-u/-A sans pathspec\" warning\n> detection relies on grabbing the changes from the entire tree?\n\nI think it's more basic than that. \"git add\" doesn't bother to\nrun an \"update-index --refresh\" equivalent before its main loop\nunless you pass --refresh to it, since reading files to compare\nthem to the index would be duplicated work. The files hit in\nupdate_callback() are only potentially modified.\n\nMaybe the warning should happen after add_file_to_index() has run,\nletting git compare the old and new index entries for that path?\n\nJonathan\n"},{"id":"215539","messageId":"7vhaiuywps.fsf@alter.siamese.dyndns.org","threadId":"33517","inReplyTo":"20130425235624.GO29963@google.com","subject":"Re: [PATCH 0/2] \"git add -A/--no-all\" finishing touches","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-26T00:14:23Z","receivedAt":"2013-04-26T00:14:23Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n> Maybe the warning should happen after add_file_to_index() has run,\n> letting git compare the old and new index entries for that path?\n\nYeah, new and deleted cases we do not have to worry about, so a\nno-op add_file_to_index() is the only case we have to be careful.\nThere is a \"if verbose, say 'add %s'\" logic in the funciton, so it\nshould be possible to enhance the API without affecting existing\ncallers to extract that necessary information out of it.\n"},{"id":"215636","messageId":"7vd2thvx7l.fsf@alter.siamese.dyndns.org","threadId":"33517","inReplyTo":"7vhaiuywps.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 0/2] \"git add -A/--no-all\" finishing touches","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-26T20:44:14Z","receivedAt":"2013-04-26T20:44:14Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Jonathan Nieder writes:\n>\n>> Maybe the warning should happen after add_file_to_index() has run,\n>> letting git compare the old and new index entries for that path?\n>\n> Yeah, new and deleted cases we do not have to worry about, so a\n> no-op add_file_to_index() is the only case we have to be careful.\n> There is a \"if verbose, say 'add %s'\" logic in the funciton, so it\n> should be possible to enhance the API without affecting existing\n> callers to extract that necessary information out of it.\n\nI've thought about this a bit more.\n\nOne possible solution would go like this:\n\n - Extend add_file_to_index() (the logic is add_to_index() in\n read-cache.c) so that it can return an extra boolean \"I would add\n it, but that would be a no-op---the index already has that\n object\" to the caller.\n\n - In update_callback(), when we are comparing _all_ paths due to\n \"implicit-dot\" logic, check if the path is outside the current\n directory, instead of unconditionally calling warn_pathless_add():\n\n * If fix_unmerged_status() tells us that we would go to the\n remove_file_from_index() codepath, instead of calling it, call\n warn_pathless_add() instead.\n\n * If we are going to call add_file_to_index(), call it with\n ADD_CACHE_PRETEND on using the extended interface to see if it\n is adding already up-to-date contents. If not, call\n warn_pathless_add().\n\nBut I think it is a much better solution to just refresh the index\nlike the attached patch when implicit_dot is active and we are not\nat the top level directory. The paths that are stat-dirty but have\nthe up-to-date contents need to be hashed at least once _anyway_ to\nsee if the current contents match with what is in the index. If we\nuse the approach outlined above, the rehashing will be done in the\nextended add_file_to_index(). If we simply refresh the entire cache,\nthe same check will be done there. The only performance penalty\nwould be that we may end up running lstat() twice.\n\nIncidentally, I noticed that we set implicit_dot=1 even when we are\nalready at the top-level directory. I suspect the code may become\nsomewhat simpler if we set it only when (prefix != NULL), but it\nprobably would not matter.\n\n\n builtin/add.c | 2 ++\n 1 file changed, 2 insertions(+)\n\ndiff --git a/builtin/add.c b/builtin/add.c\nindex daf02c6..ec2359c 100644\n--- a/builtin/add.c\n+++ b/builtin/add.c\n@@ -495,6 +495,8 @@ int cmd_add(int argc, const char **argv, const char *prefix)\n \t\trefresh(verbose, pathspec);\n \t\tgoto finish;\n \t}\n+\tif (implicit_dot && !prefix)\n+\t\trefresh_cache(REFRESH_QUIET);\n \n \tif (pathspec) {\n \t\tint i;\n"},{"id":"215651","messageId":"20130426213043.GP29963@google.com","threadId":"33517","inReplyTo":"7vd2thvx7l.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 0/2] \"git add -A/--no-all\" finishing touches","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-04-26T21:30:43Z","receivedAt":"2013-04-26T21:30:43Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Junio C Hamano wrote:\n\n> --- a/builtin/add.c\n> +++ b/builtin/add.c\n> @@ -495,6 +495,8 @@ int cmd_add(int argc, const char **argv, const char *prefix)\n> \t\trefresh(verbose, pathspec);\n> \t\tgoto finish;\n> \t}\n> +\tif (implicit_dot && !prefix)\n> +\t\trefresh_cache(REFRESH_QUIET);\n\nI think you mean \"if (implicit_dot && prefix)\". :)\n\nThis strategy is much less invasive than the alternatives discussed,\nso for what it's worth, with that correction,\n\nAcked-by: Jonathan Nieder \n\nI'll try to get time to work on those promised tests this weekend.\n"}]}