{"thread":{"id":"32896","subject":"What's cooking in git.git (Feb 2013, #05; Tue, 12)","startedAt":"2013-02-13T00:06:59Z","lastAt":"2013-02-22T16:58:53Z","messageCount":15,"participants":["Junio C Hamano","Jonathan Nieder","Andrew Ardill","greened@obbligato.org","Miles Bader"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"209442","messageId":"7v621xdql8.fsf@alter.siamese.dyndns.org","threadId":"32896","inReplyTo":null,"subject":"What's cooking in git.git (Feb 2013, #05; Tue, 12)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-02-13T00:06:59Z","receivedAt":"2013-02-13T00:06:59Z","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\nA preview of the upcoming release 1.8.2-rc0 is expected to be tagged\nlate this week.\n\nYou can find the changes described here in the integration branches of the\nrepositories listed at\n\n    http://git-blame.blogspot.com/p/git-public-repositories.html\n\n--------------------------------------------------\n[Graduated to \"master\"]\n\n* sp/smart-http-content-type-check (2013-02-06) 3 commits\n  (merged to 'next' on 2013-02-06 at 8bc6434)\n + http_request: reset \"type\" strbuf before adding\n  (merged to 'next' on 2013-02-05 at 157812c)\n + t5551: fix expected error output\n  (merged to 'next' on 2013-02-04 at d0759cb)\n + Verify Content-Type from smart HTTP servers\n\n The smart HTTP clients forgot to verify the content-type that comes\n back from the server side to make sure that the request is being\n handled properly.\n\n--------------------------------------------------\n[New Topics]\n\n* da/p4merge-mktemp-fix (2013-02-10) 1 commit\n - p4merge: fix printf usage\n\n Will merge to 'next'.\n\n\n* jn/shell-disable-interactive (2013-02-11) 2 commits\n - shell: pay attention to exit status from 'help' command\n - shell doc: emphasize purpose and security model\n\n Will merge to 'next'.\n\n\n* jk/read-commit-buffer-data-after-free (2013-02-11) 1 commit\n - log: re-encode commit messages before grepping\n\n Will merge to 'next'.\n\n\n* mk/old-expat (2013-02-11) 1 commit\n - Allow building with xmlparse.h\n\n Will merge to 'next'.\n\n\n* ef/non-ascii-parse-options-error-diag (2013-02-11) 1 commit\n - parse-options: report uncorrupted multi-byte options\n\n Will merge to 'next'.\n\n\n* jk/rebase-i-comment-char (2013-02-12) 1 commit\n - rebase -i: respect core.commentchar\n\n Will merge to 'next'.\n\n\n* mm/config-local-completion (2013-02-12) 1 commit\n - completion: support 'git config --local'\n\n Will merge to 'next'.\n\n--------------------------------------------------\n[Stalled]\n\n* mp/diff-algo-config (2013-01-16) 3 commits\n - diff: Introduce --diff-algorithm command line option\n - config: Introduce diff.algorithm variable\n - git-completion.bash: Autocomplete --minimal and --histogram for git-diff\n\n Add diff.algorithm configuration so that the user does not type\n \"diff --histogram\".\n\n Looking better; may want tests to protect it from future breakages,\n but otherwise it looks ready for 'next'.\n\n Expecting a follow-up to add tests.\n\n\n* mb/gitweb-highlight-link-target (2012-12-20) 1 commit\n - Highlight the link target line in Gitweb using CSS\n\n Expecting a reroll.\n $gmane/211935\n\n\n* jk/lua-hackery (2012-10-07) 6 commits\n - pretty: fix up one-off format_commit_message calls\n - Minimum compilation fixup\n - Makefile: make \"lua\" a bit more configurable\n - add a \"lua\" pretty format\n - add basic lua infrastructure\n - pretty: make some commit-parsing helpers more public\n\n Interesting exercise. When we do this for real, we probably would want\n to wrap a commit to make it more like an \"object\" with methods like\n \"parents\", etc.\n\n\n* rc/maint-complete-git-p4 (2012-09-24) 1 commit\n - Teach git-completion about git p4\n\n Comment from Pete will need to be addressed ($gmane/206172).\n\n\n* jc/maint-name-rev (2012-09-17) 7 commits\n - describe --contains: use \"name-rev --algorithm=weight\"\n - name-rev --algorithm=weight: tests and documentation\n - name-rev --algorithm=weight: cache the computed weight in notes\n - name-rev --algorithm=weight: trivial optimization\n - name-rev: --algorithm option\n - name_rev: clarify the logic to assign a new tip-name to a commit\n - name-rev: lose unnecessary typedef\n\n \"git name-rev\" names the given revision based on a ref that can be\n reached in the smallest number of steps from the rev, but that is\n not useful when the caller wants to know which tag is the oldest one\n that contains the rev.  This teaches a new mode to the command that\n uses the oldest ref among those which contain the rev.\n\n I am not sure if this is worth it; for one thing, even with the help\n from notes-cache, it seems to make the \"describe --contains\" even\n slower. Also the command will be unusably slow for a user who does\n not have a write access (hence unable to create or update the\n notes-cache).\n\n Stalled mostly due to lack of responses.\n\n\n* jc/xprm-generation (2012-09-14) 1 commit\n - test-generation: compute generation numbers and clock skews\n\n A toy to analyze how bad the clock skews are in histories of real\n world projects.\n\n Stalled mostly due to lack of responses.\n\n\n* jc/add-delete-default (2012-08-13) 1 commit\n - git add: notice removal of tracked paths by default\n\n \"git add dir/\" updated modified files and added new files, but does\n not notice removed files, which may be \"Huh?\" to some users.  They\n can of course use \"git add -A dir/\", but why should they?\n\n Resurrected from graveyard, as I thought it was a worthwhile thing\n to do in the longer term.\n\n Stalled mostly due to lack of responses.\n\n\n* mb/remote-default-nn-origin (2012-07-11) 6 commits\n - Teach get_default_remote to respect remote.default.\n - Test that plain \"git fetch\" uses remote.default when on a detached HEAD.\n - Teach clone to set remote.default.\n - Teach \"git remote\" about remote.default.\n - Teach remote.c about the remote.default configuration setting.\n - Rename remote.c's default_remote_name static variables.\n\n When the user does not specify what remote to interact with, we\n often attempt to use 'origin'.  This can now be customized via a\n configuration variable.\n\n Expecting a reroll.\n $gmane/210151\n\n \"The first remote becomes the default\" bit is better done as a\n separate step.\n\n--------------------------------------------------\n[Cooking]\n\n* jc/fetch-raw-sha1 (2013-02-07) 4 commits\n - fetch: fetch objects by their exact SHA-1 object names\n - upload-pack: optionally allow fetching from the tips of hidden refs\n - fetch: use struct ref to represent refs to be fetched\n - parse_fetch_refspec(): clarify the codeflow a bit\n (this branch uses jc/hidden-refs.)\n\n Allows requests to fetch objects at any tip of refs (including\n hidden ones).  It seems that there may be use cases even outside\n Gerrit (e.g. $gmane/215701).\n\n\n* jk/diff-graph-cleanup (2013-02-12) 6 commits\n  (merged to 'next' on 2013-02-12 at 6e764c1)\n + combine-diff.c: teach combined diffs about line prefix\n + diff.c: use diff_line_prefix() where applicable\n + diff: add diff_line_prefix function\n + diff.c: make constant string arguments const\n + diff: write prefix to the correct file\n + graph: output padding for merge subsequent parents\n\n Refactors a lot of repetitive code sequence from the graph drawing\n code and adds it to the combined diff output.\n\n Will merge to 'master'.\n\n\n* mn/send-email-works-with-credential (2013-02-12) 6 commits\n - git-send-email: use git credential to obtain password\n - Git.pm: add interface for git credential command\n - Git.pm: allow pipes to be closed prior to calling command_close_bidi_pipe\n - Git.pm: refactor command_close_bidi_pipe to use _cmd_close\n - Git.pm: fix example in command_close_bidi_pipe documentation\n - Git.pm: allow command_close_bidi_pipe to be called as method\n\n Hooks the credential system to send-email.\n Rerolled.\n Waiting for a review.\n\n\n* tz/perl-styles (2013-02-06) 1 commit\n  (merged to 'next' on 2013-02-09 at c8cff17)\n + Update CodingGuidelines for Perl\n\n Add coding guidelines for writing Perl scripts for Git.\n\n Will merge to 'master'.\n\n\n* al/mergetool-printf-fix (2013-02-10) 2 commits\n  (merged to 'next' on 2013-02-11 at 5f9bc4e)\n + difftool--helper: fix printf usage\n + git-mergetool: print filename when it contains %\n\n Will merge to 'master'.\n\n\n* jk/error-const-return (2013-02-08) 1 commit\n  (merged to 'next' on 2013-02-11 at ba8dba3)\n + Use __VA_ARGS__ for all of error's arguments\n\n Will merge to 'master'.\n\n\n* mm/remote-mediawiki-build (2013-02-08) 2 commits\n  (merged to 'next' on 2013-02-11 at 4ebb902)\n + git-remote-mediawiki: use toplevel's Makefile\n + Makefile: make script-related rules usable from subdirectories\n\n Will merge to 'master'.\n\n\n* nd/branch-show-rebase-bisect-state (2013-02-08) 1 commit\n - branch: show rebase/bisect info when possible instead of \"(no branch)\"\n\n Expecting a reroll.\n $gmane/215771\n\n\n* nd/count-garbage (2013-02-08) 3 commits\n - count-objects: report how much disk space taken by garbage files\n - count-objects: report garbage files in pack directory too\n - git-count-objects.txt: describe each line in -v output\n\n Expecting a reroll.\n $gmane/216127\n\n\n* wk/man-deny-current-branch-is-default-these-days (2013-02-08) 1 commit\n - user-manual: Update for receive.denyCurrentBranch=refuse\n\n Will merge to 'next'.\n\n\n* bw/get-tz-offset-perl (2013-02-09) 3 commits\n  (merged to 'next' on 2013-02-11 at b9c8893)\n + cvsimport: format commit timestamp ourselves without using strftime\n + perl/Git.pm: fix get_tz_offset to properly handle DST boundary cases\n + Move Git::SVN::get_tz to Git::get_tz_offset\n\n Will merge to 'master'.\n\n\n* mg/bisect-doc (2013-02-11) 1 commit\n  (merged to 'next' on 2013-02-11 at 6125304)\n + git-bisect.txt: clarify that reset quits bisect\n\n Will merge to 'master'.\n\n\n* jc/extended-fake-ancestor-for-gitlink (2013-02-05) 1 commit\n  (merged to 'next' on 2013-02-09 at 2d3547b)\n + apply: verify submodule commit object name better\n\n Instead of requiring the full 40-hex object names on the index\n line, we can read submodule commit object names from the textual\n diff when synthesizing a fake ancestore tree for \"git am -3\".\n\n Will merge to 'master'.\n\n\n* tz/credential-authinfo (2013-02-05) 1 commit\n - Add contrib/credentials/netrc with GPG support\n\n A new read-only credential helper (in contrib/) to interact with\n the .netrc/.authinfo files.  Hopefully mn/send-email-authinfo topic\n can rebuild on top of something like this.\n\n Expecting a reroll.\n $gmane/215556\n\n\n* jx/utf8-printf-width (2013-02-11) 1 commit\n  (merged to 'next' on 2013-02-11 at 968b4e2)\n + Add utf8_fprintf helper that returns correct number of columns\n\n Use a new helper that prints a message and counts its display width\n to align the help messages parse-options produces.\n\n Will merge to 'master'.\n\n\n* dg/subtree-fixes (2013-02-05) 6 commits\n  (merged to 'next' on 2013-02-09 at 8f19ebe)\n + contrib/subtree: make the manual directory if needed\n + contrib/subtree: honor DESTDIR\n + contrib/subtree: fix synopsis\n + contrib/subtree: better error handling for 'subtree add'\n + contrib/subtree: use %B for split subject/body\n + contrib/subtree: remove test number comments\n\n contrib/subtree updates, but here are only the ones that looked\n ready to be merged to 'next'.  For the remainder, they will have\n another day.\n\n Will merge to 'master'.\n\n\n* jl/submodule-deinit (2013-02-06) 1 commit\n - submodule: add 'deinit' command\n\n There was no Porcelain way to say \"I no longer am interested in\n this submodule\", once you express your interest in a submodule with\n \"submodule init\".  \"submodule deinit\" is the way to do so.\n\n Will merge to 'next'.\n\n\n* jc/remove-export-from-config-mak-in (2013-02-12) 2 commits\n  (merged to 'next' on 2013-02-12 at eb8af04)\n + Makefile: do not export mandir/htmldir/infodir\n  (merged to 'next' on 2013-02-07 at 33f7d4f)\n + config.mak.in: remove unused definitions\n\n config.mak.in template had an \"export\" line to cause a few\n common makefile variables to be exported; if they need to be\n expoted for autoconf/configure users, they should also be exported\n for people who write config.mak the same way.  Move the \"export\" to\n the main Makefile.  Also, stop exporting mandir that used to be\n exported (only) when config.mak.autogen was used.  It would have\n broken installation of manpages (but not other documentation\n formats).\n\n\n* nd/status-show-in-progress (2013-02-05) 1 commit\n  (merged to 'next' on 2013-02-11 at 5ffcbc2)\n + status: show the branch name if possible in in-progress info\n\n Will merge to 'master'.\n\n\n* jc/mention-tracking-for-pull-default (2013-01-31) 1 commit\n - doc: mention tracking for pull.default\n\n We stopped mentioning `tracking` is a deprecated but supported\n synonym for `upstream` in pull.default even though we have no\n intention of removing the support for it.\n\n This is my \"don't list it to catch readers' eyes, but make sure it\n can be found if the reader looks for it\" version; I'm not married\n to the layout and will be happy to take a replacement patch.\n\n Will merge to 'next', unless a replacement materializes soonish.\n\n\n* jc/hidden-refs (2013-02-07) 3 commits\n - upload/receive-pack: allow hiding ref hierarchies\n - upload-pack: simplify request validation\n - upload-pack: share more code\n (this branch is used by jc/fetch-raw-sha1.)\n\n Allow the server side to redact the refs/ namespace it shows to the\n client.\n\n Will merge to 'next'.\n\n\n* jc/remove-treesame-parent-in-simplify-merges (2013-01-17) 1 commit\n  (merged to 'next' on 2013-01-30 at b639b47)\n + simplify-merges: drop merge from irrelevant side branch\n\n The --simplify-merges logic did not cull irrelevant parents from a\n merge that is otherwise not interesting with respect to the paths\n we are following.\n\n This touches a fairly core part of the revision traversal\n infrastructure; even though I think this change is correct, please\n report immediately if you find any unintended side effect.\n\n Will cook in 'next'.\n\n\n* jc/push-2.0-default-to-simple (2013-01-16) 14 commits\n  (merged to 'next' on 2013-01-16 at 23f5df2)\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  (merged to 'next' on 2013-01-09 at 74c3498)\n + doc: push.default is no longer \"matching\"\n + push: switch default from \"matching\" to \"simple\"\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 Will cook in 'next' until Git 2.0 ;-).\n\n\n* bc/append-signed-off-by (2013-02-12) 12 commits\n - Unify appending signoff in format-patch, commit and sequencer\n - format-patch: update append_signoff prototype\n - t4014: more tests about appending s-o-b lines\n - sequencer.c: teach append_signoff to avoid adding a duplicate newline\n - sequencer.c: teach append_signoff how to detect duplicate s-o-b\n - sequencer.c: always separate \"(cherry picked from\" from commit body\n - sequencer.c: require a conforming footer to be preceded by a blank line\n - sequencer.c: recognize \"(cherry picked from ...\" as part of s-o-b footer\n - t/t3511: add some tests of 'cherry-pick -s' functionality\n - t/test-lib-functions.sh: allow to specify the tag name to test_commit\n - commit, cherry-pick -s: remove broken support for multiline rfc2822 fields\n - sequencer.c: rework search for start of footer to improve clarity\n\n Will merge to 'next'.\n\n--------------------------------------------------\n[Discarded]\n\n* mn/send-email-authinfo (2013-01-29) 1 commit\n . git-send-email: add ~/.authinfo parsing\n\n Instead of making send-email directly read from .netrc/.authinfo,\n mn/send-email-works-with-credential topic hooks the program to our\n credential framework, and tz/credential-authinfo topic gives access\n to these file formats to credential consumers.\n\n\n* mm/allow-contrib-build (2013-02-07) 2 commits\n . perl.mak: introduce $(GIT_ROOT_DIR) to allow inclusion from other directories\n . Makefile: extract perl-related rules to make them available from other dirs\n\n Superseded by mm/remote-mediawiki-build.\n"},{"id":"209443","messageId":"20130213001213.GA15246@google.com","threadId":"32896","inReplyTo":"7v621xdql8.fsf@alter.siamese.dyndns.org","subject":"jn/shell-disable-interactive (Re: What's cooking in git.git (Feb 2013, #05; Tue, 12))","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-02-13T00:12:13Z","receivedAt":"2013-02-13T00:12:13Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Junio C Hamano wrote:\n\n> * jn/shell-disable-interactive (2013-02-11) 2 commits\n>  - shell: pay attention to exit status from 'help' command\n>  - shell doc: emphasize purpose and security model\n>\n>  Will merge to 'next'.\n\nPlease hold off on merging the second patch.  I'd like to reroll\nrenaming the command to 'no-interactive-login' or some such, which\nwould be less disruptive to existing setups and should be easier to\nexplain.\n\nThanks,\nJonathan\n"},{"id":"209444","messageId":"7v1ucldq6y.fsf@alter.siamese.dyndns.org","threadId":"32896","inReplyTo":"20130213001213.GA15246@google.com","subject":"Re: jn/shell-disable-interactive (Re: What's cooking in git.git (Feb 2013, #05; Tue, 12))","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-02-13T00:15:33Z","receivedAt":"2013-02-13T00:15:33Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder <jrnieder@gmail.com> writes:\n\n> Junio C Hamano wrote:\n>\n>> * jn/shell-disable-interactive (2013-02-11) 2 commits\n>>  - shell: pay attention to exit status from 'help' command\n>>  - shell doc: emphasize purpose and security model\n>>\n>>  Will merge to 'next'.\n>\n> Please hold off on merging the second patch.  I'd like to reroll\n> renaming the command to 'no-interactive-login' or some such, which\n> would be less disruptive to existing setups and should be easier to\n> explain.\n\nThanks; that sounds like a sensible and safer change.\n"},{"id":"209445","messageId":"CAH5451nPKq8DKwo+Bkxh08N-wqrYCY4BihbvaE14z5iGVA1iZw@mail.gmail.com","threadId":"32896","inReplyTo":"7v621xdql8.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Feb 2013, #05; Tue, 12)","fromName":"Andrew Ardill","fromEmail":"andrew.ardill@gmail.com","sentAt":"2013-02-13T00:21:03Z","receivedAt":"2013-02-13T00:21:03Z","isPatch":false,"sender":{"key":"andrew.ardill@gmail.com","avatar":"https://gravatar.com/avatar/da14cb7c091dd44dc6c63a4d3361b149acaf25226dc78eb4131a17b93d9b0993?d=mp&s=160"},"body":"On 13 February 2013 11:06, Junio C Hamano <gitster@pobox.com> wrote:\n> * jc/add-delete-default (2012-08-13) 1 commit\n>  - git add: notice removal of tracked paths by default\n>\n>  \"git add dir/\" updated modified files and added new files, but does\n>  not notice removed files, which may be \"Huh?\" to some users.  They\n>  can of course use \"git add -A dir/\", but why should they?\n>\n>  Resurrected from graveyard, as I thought it was a worthwhile thing\n>  to do in the longer term.\n>\n>  Stalled mostly due to lack of responses.\n\nWhat do you need to progress this?\n\nI have been bitten by this before (the 'huh?' reaction) and think the\nprevious discussions and patch look reasonable. Does it need testing?\nFurther input??\n\nRegards,\n\nAndrew Ardill\n"},{"id":"209446","messageId":"7vsj51caqb.fsf@alter.siamese.dyndns.org","threadId":"32896","inReplyTo":"CAH5451nPKq8DKwo+Bkxh08N-wqrYCY4BihbvaE14z5iGVA1iZw@mail.gmail.com","subject":"Re: What's cooking in git.git (Feb 2013, #05; Tue, 12)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-02-13T00:34:52Z","receivedAt":"2013-02-13T00:34:52Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andrew Ardill <andrew.ardill@gmail.com> writes:\n\n> On 13 February 2013 11:06, Junio C Hamano <gitster@pobox.com> wrote:\n>> * jc/add-delete-default (2012-08-13) 1 commit\n>>  - git add: notice removal of tracked paths by default\n>>\n>>  \"git add dir/\" updated modified files and added new files, but does\n>>  not notice removed files, which may be \"Huh?\" to some users.  They\n>>  can of course use \"git add -A dir/\", but why should they?\n>>\n>>  Resurrected from graveyard, as I thought it was a worthwhile thing\n>>  to do in the longer term.\n>>\n>>  Stalled mostly due to lack of responses.\n>\n> What do you need to progress this?\n>\n> I have been bitten by this before (the 'huh?' reaction) and think the\n> previous discussions and patch look reasonable. Does it need testing?\n\nI _think_ the code does what it claims it does; I do not think that\nis what is lacking (more testing would not _hurt_, of course).\n\n> Further input??\n\nThe updated behaviour is a departure from the traditional norm, and\nit would surprise people who do not expect \"git add .\" to update the\nindex for removed paths.  For many of them, it may be a pleasant\nsurprise, but \"many\" is not \"all\".\n\nThe change could negatively affect people who expect that removing\nfiles that are not used for their purpose (e.g. a large file that is\nunnecessary for their build) will _not_ affect what they get from\n\"git add .\"; obviously they must have trained themselves not to do\n\"git add -u\" or \"git commit -a\".\n"},{"id":"209447","messageId":"CAH5451mmXg=xvb-gW0qNvp7f8M5Jk5_ZS+UHAzMaGhJ677zWmw@mail.gmail.com","threadId":"32896","inReplyTo":"7vsj51caqb.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Feb 2013, #05; Tue, 12)","fromName":"Andrew Ardill","fromEmail":"andrew.ardill@gmail.com","sentAt":"2013-02-13T00:42:06Z","receivedAt":"2013-02-13T00:42:06Z","isPatch":false,"sender":{"key":"andrew.ardill@gmail.com","avatar":"https://gravatar.com/avatar/da14cb7c091dd44dc6c63a4d3361b149acaf25226dc78eb4131a17b93d9b0993?d=mp&s=160"},"body":"On 13 February 2013 11:34, Junio C Hamano <gitster@pobox.com> wrote:\n> The change could negatively affect people who expect that removing\n> files that are not used for their purpose (e.g. a large file that is\n> unnecessary for their build) will _not_ affect what they get from\n> \"git add .\";\n\nHow big a problem is this?\n\nIf we need to support this behaviour than I would suppose a config\noption is required. A default config transition path similar to git\npush defaults would probably work well, in the case where breaking\nthese expectations is unacceptable.\n\n> obviously they must have trained themselves not to do\n> \"git add -u\" or \"git commit -a\".\n\nMany people use git add -p by default, so I would not be surprised\nabout people not using -u or -a.\n\nRegards,\n\nAndrew Ardill\n"},{"id":"209472","messageId":"7vpq04b5e2.fsf@alter.siamese.dyndns.org","threadId":"32896","inReplyTo":"CAH5451mmXg=xvb-gW0qNvp7f8M5Jk5_ZS+UHAzMaGhJ677zWmw@mail.gmail.com","subject":"Re: What's cooking in git.git (Feb 2013, #05; Tue, 12)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-02-13T15:27:49Z","receivedAt":"2013-02-13T15:27:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andrew Ardill <andrew.ardill@gmail.com> writes:\n\n> On 13 February 2013 11:34, Junio C Hamano <gitster@pobox.com> wrote:\n>> The change could negatively affect people who expect that removing\n>> files that are not used for their purpose (e.g. a large file that is\n>> unnecessary for their build) will _not_ affect what they get from\n>> \"git add .\";\n>\n> How big a problem is this?\n\nAs you said below, it could be fairly big, if you expect a lot of\npeople do not use \"git add -u\".\n\n> If we need to support this behaviour than I would suppose a config\n> option is required. A default config transition path similar to git\n> push defaults would probably work well, in the case where breaking\n> these expectations is unacceptable.\n\nWe've discussed that before.\n\nhttp://thread.gmane.org/gmane.comp.version-control.git/171811/focus=171818\n\n>> obviously they must have trained themselves not to do\n>> \"git add -u\" or \"git commit -a\".\n>\n> Many people use git add -p by default, so I would not be surprised\n> about people not using -u or -a.\n"},{"id":"209505","messageId":"CAH5451kogwuzOs+BrHksDSdECbHrmW8DwTve0_kKq+-PTx+4bw@mail.gmail.com","threadId":"32896","inReplyTo":"7vpq04b5e2.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Feb 2013, #05; Tue, 12)","fromName":"Andrew Ardill","fromEmail":"andrew.ardill@gmail.com","sentAt":"2013-02-14T02:43:55Z","receivedAt":"2013-02-14T02:43:55Z","isPatch":false,"sender":{"key":"andrew.ardill@gmail.com","avatar":"https://gravatar.com/avatar/da14cb7c091dd44dc6c63a4d3361b149acaf25226dc78eb4131a17b93d9b0993?d=mp&s=160"},"body":"On 14 February 2013 02:27, Junio C Hamano <gitster@pobox.com> wrote:\n>> If we need to support this behaviour than I would suppose a config\n>> option is required. A default config transition path similar to git\n>> push defaults would probably work well, in the case where breaking\n>> these expectations is unacceptable.\n>\n> We've discussed that before.\n>\n> http://thread.gmane.org/gmane.comp.version-control.git/171811/focus=171818\n\nSomething that I couldn't find discussed was the option of, rather\nthan providing a config to 'turn it off', inverting the current\ndefault/flags combo.\n\nThat is, currently git add defaults to not staging file deletions, and\nwe provide command line flags to include them. The consensus in the\nthread is that it is better to stage them by default; it seems\nreasonable to me that if we stage deletions by default we should\nprovide flags to _not_ stage them. If that was the entirety of the\nchange, would your position from that thread, \"if we need this\noptional, then it is not worth doing this\", still hold?\n\nSome people would be adversely affected by this change, but any\nobjections I can come up with are not game stoppers.\n- It is possible newcomers might stumble at deleted files being staged\nfor commit by a command called 'add', but if they can already grok the\nconcept of staging then including deletions in that is trivial. If\nthey don't understand staging then we have a different issue.\n- For people who rely heavily on file deletions remaining out of the\nindex, providing a flag allows them to keep their workflow. No data\nwould be lost, and most accidents would be easily recoverable.\n- For scripts that rely on this behaviour, a flag allows it to be\nupdated, though it may break in the meantime. (I would presume that\nnot many of these scripts exist in the first place, but I don't really\nknow)\n\nFinally, making this change makes sense from a consistency point of\nview. For example, we don't track file renames because (and I\nparaphrase) we can work that out from the content that is moved.\nHowever if I rename a file and then 'git add .' I see that a new file\nis added, not that it has been renamed! Manually adding the deletion\nto the index causes git to correctly detect the rename, however this\nis unintuitive and not consistent with how git works and is\ncommunicated in general.\n\nGit add is also inconsistent with git add -p (although that might be\ndue to unclear documentation for -p). When in patch mode, git add will\npropose deletions get added to the index as well, not just additions\nand modifications.\n\nRegards,\n\nAndrew Ardill\n"},{"id":"209506","messageId":"7vtxpf341w.fsf@alter.siamese.dyndns.org","threadId":"32896","inReplyTo":"CAH5451kogwuzOs+BrHksDSdECbHrmW8DwTve0_kKq+-PTx+4bw@mail.gmail.com","subject":"Re: What's cooking in git.git (Feb 2013, #05; Tue, 12)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-02-14T04:36:11Z","receivedAt":"2013-02-14T04:36:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andrew Ardill <andrew.ardill@gmail.com> writes:\n\n>> We've discussed that before.\n>>\n>> http://thread.gmane.org/gmane.comp.version-control.git/171811/focus=171818\n>\n> Something that I couldn't find discussed was the option of, rather\n> than providing a config to 'turn it off', inverting the current\n> default/flags combo.\n>\n> That is, currently git add defaults to not staging file deletions, and\n> we provide command line flags to include them. The consensus in the\n> thread is that it is better to stage them by default; it seems\n> reasonable to me that if we stage deletions by default we should\n> provide flags to _not_ stage them. If that was the entirety of the\n> change, would your position from that thread, \"if we need this\n> optional, then it is not worth doing this\", still hold?\n\nIf that is the change we are going to make, and if you can guarantee\nthat nobody who is used to the historical behaviour will complain,\nthen I am fine with it, but I think the latter part of the condition\nwill not hold.\n\n> Some people would be adversely affected by this change, but any\n> objections I can come up with are not game stoppers.\n> - It is possible newcomers might stumble at deleted files being staged\n> for commit by a command called 'add',...\n\nNew people are fair game; we haven't trained them with the\n\"inconsistent\" behaviour, and the default being different from\nhistorical behaviour will not affect them adversely.\n\n> - For people who rely heavily on file deletions remaining out of the\n> index, providing a flag allows them to keep their workflow.\n\nAllowing to do the things they used to be able to do is a bare\nminimum.  You are still forcing them to do things differently.\n\n> - For scripts that rely on this behaviour, a flag allows it to be\n> updated, though it may break in the meantime.\n\nLikewise.\n\n> Finally, making this change makes sense from a consistency point of\n> view.\n\nThat is a given. Otherwise we wouldn't be even discussing this.\n"},{"id":"209507","messageId":"CAH5451mMG-U8qETAy_6pRJLbtOjtAPhbapVA9RLbrrS2yy7rCw@mail.gmail.com","threadId":"32896","inReplyTo":"7vtxpf341w.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Feb 2013, #05; Tue, 12)","fromName":"Andrew Ardill","fromEmail":"andrew.ardill@gmail.com","sentAt":"2013-02-14T04:54:51Z","receivedAt":"2013-02-14T04:54:51Z","isPatch":false,"sender":{"key":"andrew.ardill@gmail.com","avatar":"https://gravatar.com/avatar/da14cb7c091dd44dc6c63a4d3361b149acaf25226dc78eb4131a17b93d9b0993?d=mp&s=160"},"body":"On 14 February 2013 15:36, Junio C Hamano <gitster@pobox.com> wrote:\n>> That is, currently git add defaults to not staging file deletions, and\n>> we provide command line flags to include them. The consensus in the\n>> thread is that it is better to stage them by default; it seems\n>> reasonable to me that if we stage deletions by default we should\n>> provide flags to _not_ stage them. If that was the entirety of the\n>> change, would your position from that thread, \"if we need this\n>> optional, then it is not worth doing this\", still hold?\n>\n> If that is the change we are going to make, and if you can guarantee\n> that nobody who is used to the historical behaviour will complain,\n> then I am fine with it, but I think the latter part of the condition\n> will not hold.\n\nDoes the impossibility of asserting that no-one will complain put this\nin the 'too hard' bucket?\n\n>> Some people would be adversely affected by this change, but any\n>> objections I can come up with are not game stoppers.\n>> - It is possible newcomers might stumble at deleted files being staged\n>> for commit by a command called 'add',...\n>\n> New people are fair game; we haven't trained them with the\n> \"inconsistent\" behaviour, and the default being different from\n> historical behaviour will not affect them adversely.\n>\n>> - For people who rely heavily on file deletions remaining out of the\n>> index, providing a flag allows them to keep their workflow.\n>\n> Allowing to do the things they used to be able to do is a bare\n> minimum.  You are still forcing them to do things differently.\n\nThe implication here is that a relatively small number of people will\nbe inconvenienced by needing to specify extra flags/set up an alias.\nCompare this to the many for whom the expected behaviour is now\ndefault, and we have a net win.\n\n>> Finally, making this change makes sense from a consistency point of\n>> view.\n>\n> That is a given. Otherwise we wouldn't be even discussing this.\n\nObviously I agree. I was actually bringing up a point about patch mode\nand it got incorporated into the bigger picture; patch mode includes\ndeletions by default and I don't even know if you can turn that\nbehaviour off. So, when we talk about git add -u and git add -A, we\nshould also mention git add -p.\n\nRegards,\n\nAndrew Ardill\n"},{"id":"209530","messageId":"7vd2w23k7k.fsf@alter.siamese.dyndns.org","threadId":"32896","inReplyTo":"CAH5451mMG-U8qETAy_6pRJLbtOjtAPhbapVA9RLbrrS2yy7rCw@mail.gmail.com","subject":"Re: What's cooking in git.git (Feb 2013, #05; Tue, 12)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-02-14T16:59:27Z","receivedAt":"2013-02-14T16:59:27Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andrew Ardill <andrew.ardill@gmail.com> writes:\n\n>> If that is the change we are going to make, and if you can guarantee\n>> that nobody who is used to the historical behaviour will complain,\n>> then I am fine with it, but I think the latter part of the condition\n>> will not hold.\n>\n> Does the impossibility of asserting that no-one will complain put this\n> in the 'too hard' bucket?\n\nBasically, yes.  \"Cannot be done without UI regression.\"\n\nIt could be a Git 2.0 item, if you plan the transition right, though.\n\n> The implication here is that a relatively small number of people will\n> be inconvenienced by needing to specify extra flags/set up an alias.\n> Compare this to the many for whom the expected behaviour is now\n> default, and we have a net win.\n\nWe take backward compatibility a lot more seriously; it is not even\na democracy.\n\n\"Net win\" does not mean an iota.  Even if \"small number\" is 47 and\nlarge majority is 4 million, it does not change the fact that you\nare breaking things these 47 people have depended on working in an\nexpected (the \"expected\" does not have to be \"intuitive\" in this\nsentence; what counts more is that it is the way they are accustomed\nto) way and introducing a UI regression.\n"},{"id":"209544","messageId":"7vvc9uwkmm.fsf@alter.siamese.dyndns.org","threadId":"32896","inReplyTo":"7vd2w23k7k.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Feb 2013, #05; Tue, 12)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-02-14T23:17:37Z","receivedAt":"2013-02-14T23:17:37Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Andrew Ardill <andrew.ardill@gmail.com> writes:\n>\n>>> If that is the change we are going to make, and if you can guarantee\n>>> that nobody who is used to the historical behaviour will complain,\n>>> then I am fine with it, but I think the latter part of the condition\n>>> will not hold.\n>>\n>> Does the impossibility of asserting that no-one will complain put this\n>> in the 'too hard' bucket?\n>\n> Basically, yes.  \"Cannot be done without UI regression.\"\n>\n> It could be a Git 2.0 item, if you plan the transition right, though.\n\nI have been staring at the patch again, but I do not think of an\neasy way out without retraining the old timers to introduce this \"if\nwe knew better, we would have done so from day one and the world\nwould have been a much better place\" change.  If we were to have\nthis in the longer term, we would need a proper transition plan,\nsimilar to the one we devised to change the default used for a lazy\n\"git push\" (and \"git push $there\") from the traditional \"matching\"\nto \"simple\" at Git 2.0 boundary.\n\nThe transition would go like this:\n\n * Introduce \"git add --ignore-removal\" option in the release after\n   the current cycle (a new feature is too late for this cycle):\n\n   - when \"git add <pathspec>\" is given without \"--ignore-removal\",\n     give a warning about upcoming default change, and advise people\n     to use either \"--ignore-removal\" or \"--all\" option, but behave\n     as if \"--ignore-removal\" were given.\n\n   - when \"git add --ignore-removal <pathspec>\" is given, only add\n     additions and modifications, just like the current behaviour.\n\n   - obviously, \"-u\", \"-A\", and \"--ignore-removal\" are mutually\n     exclusive.\n\n * Run with the above for a few releases.\n\n * Change the behaviour of \"git add <pathspec>\" without \"-u\", \"-A\"\n   nor \"--ignore-removal\" to error out with the same warning and\n   advise.\n\n * Run with the above for a few releases.\n\n * At Git 2.0, change \"git add <pathspec>\" without \"-u\", \"-A\" nor\n   \"--ignore-removal\" to behave as if \"git add -A <pathspec>\" were\n   given.\n\nAt any point during the above transtion, \"git add\" without any\npathspec will not change its meaning; it will stay a no-op.\n"},{"id":"209719","messageId":"877gm54bl1.fsf@waller.obbligato.org","threadId":"32896","inReplyTo":"7v621xdql8.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Feb 2013, #05; Tue, 12)","fromName":"","fromEmail":"greened@obbligato.org","sentAt":"2013-02-18T20:21:46Z","receivedAt":"2013-02-18T20:21:46Z","isPatch":false,"sender":{"key":"greened@obbligato.org","avatar":"https://avatars.githubusercontent.com/u/5291869?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> * dg/subtree-fixes (2013-02-05) 6 commits\n>   (merged to 'next' on 2013-02-09 at 8f19ebe)\n>  + contrib/subtree: make the manual directory if needed\n>  + contrib/subtree: honor DESTDIR\n>  + contrib/subtree: fix synopsis\n>  + contrib/subtree: better error handling for 'subtree add'\n>  + contrib/subtree: use %B for split subject/body\n>  + contrib/subtree: remove test number comments\n>\n>  contrib/subtree updates, but here are only the ones that looked\n>  ready to be merged to 'next'.  For the remainder, they will have\n>  another day.\n\nGreat, I've got updates for the rest.\n\n                       -David\n"},{"id":"210019","messageId":"87hal4n3z1.fsf@catnip.gol.com","threadId":"32896","inReplyTo":"7vvc9uwkmm.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Feb 2013, #05; Tue, 12)","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2013-02-22T08:32:34Z","receivedAt":"2013-02-22T08:32:34Z","isPatch":false,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n>  * Introduce \"git add --ignore-removal\" option in the release after\n>    the current cycle (a new feature is too late for this cycle):\n\nToo late in the cycle even if the option is simply ignored ... ?\n\n[To extend the range of git versions where it's not an error]\n\n-miles\n\n-- \nKilt, n. A costume sometimes worn by Scotchmen [sic] in America and Americans\nin Scotland.\n"},{"id":"210033","messageId":"7vip5ks2sy.fsf@alter.siamese.dyndns.org","threadId":"32896","inReplyTo":"87hal4n3z1.fsf@catnip.gol.com","subject":"Re: What's cooking in git.git (Feb 2013, #05; Tue, 12)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-02-22T16:58:53Z","receivedAt":"2013-02-22T16:58:53Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Miles Bader <miles@gnu.org> writes:\n\n> Junio C Hamano <gitster@pobox.com> writes:\n>>  * Introduce \"git add --ignore-removal\" option in the release after\n>>    the current cycle (a new feature is too late for this cycle):\n>\n> Too late in the cycle even if the option is simply ignored ... ?\n>\n> [To extend the range of git versions where it's not an error]\n\nI'd feel safer to have enough time to cook the \"alleged no-op\"\nbefore merging it to 'master' and include it in a release.\n\nPossible implementation mistakes aside, \"--ignore-removal\" is\nprobably too long to type, we haven't even discussed if it deserves\na short-and-sweet single letter option, the obvious \"-i\" is not\navailable, etc. etc.  I do not think we have a concensus that the\ntransition plan outlined is a good way to go in the first place.\n\nSo, I do think it is a bit too late for this cycle, especially when\nwe still have doubts about the design. Actually it is *I* who have\ndoubts; I do not even know if other people share the doubts or they\nsupport the direction wholeheartedly.\n"}]}