{"thread":{"id":"36776","subject":"[ANNOUNCE] Git v2.0.0","startedAt":"2014-05-28T22:31:13Z","lastAt":"2014-06-03T11:46:25Z","messageCount":15,"participants":["Junio C Hamano","Felipe Contreras","Jeff King","David Kastrup","NeilBrown","Linus Torvalds"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"242915","messageId":"xmqqr43dbkni.fsf@gitster.dls.corp.google.com","threadId":"36776","inReplyTo":null,"subject":"[ANNOUNCE] Git v2.0.0","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-05-28T22:31:13Z","receivedAt":"2014-05-28T22:31:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"The latest feature release Git v2.0.0 is now available at the\nusual places.\n\nWe had to delay the final release by a week or so because we found a\nfew problems in earlier release candidates (request-pull had a\nregression that stopped it from showing the \"tags/\" prefix in\n\"Please pull tags/frotz\" when the user asked to compose a request\nfor 'frotz' to be pulled; a code path in git-gui to support ancient\nversions of Git incorrectly triggered for Git 2.0), which we had to\nfix in an extra unplanned release candidate.\n\nHopefully the next cycle will become shorter, as topics that have\nbeen cooking on the 'next' branch had extra time to mature, so it\nall evens out in the end ;-).\n\nThe tarballs are found at:\n\n    https://www.kernel.org/pub/software/scm/git/testing/\n\nThe following public repositories all have a copy of the 'v2.0.0'\ntag and the 'master' branch that the tag points at:\n\n  url = https://kernel.googlesource.com/pub/scm/git/git\n  url = git://repo.or.cz/alt-git.git\n  url = https://code.google.com/p/git-core/\n  url = git://git.sourceforge.jp/gitroot/git-core/git.git\n  url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core\n  url = https://github.com/gitster/git\n\nGit v2.0 Release Notes\n======================\n\nBackward compatibility notes\n----------------------------\n\nWhen \"git push [$there]\" does not say what to push, we have used the\ntraditional \"matching\" semantics so far (all your branches were sent\nto the remote as long as there already are branches of the same name\nover there).  In Git 2.0, the default is now the \"simple\" semantics,\nwhich pushes:\n\n - only the current branch to the branch with the same name, and only\n   when the current branch is set to integrate with that remote\n   branch, if you are pushing to the same remote as you fetch from; or\n\n - only the current branch to the branch with the same name, if you\n   are pushing to a remote that is not where you usually fetch from.\n\nYou can use the configuration variable \"push.default\" to change\nthis.  If you are an old-timer who wants to keep using the\n\"matching\" semantics, you can set the variable to \"matching\", for\nexample.  Read the documentation for other possibilities.\n\nWhen \"git add -u\" and \"git add -A\" are run inside a subdirectory\nwithout specifying which paths to add on the command line, they\noperate on the entire tree for consistency with \"git commit -a\" and\nother commands (these commands used to operate only on the current\nsubdirectory).  Say \"git add -u .\" or \"git add -A .\" if you want to\nlimit the operation to the current directory.\n\n\"git add <path>\" is the same as \"git add -A <path>\" now, so that\n\"git add dir/\" will notice paths you removed from the directory and\nrecord the removal.  In older versions of Git, \"git add <path>\" used\nto ignore removals.  You can say \"git add --ignore-removal <path>\" to\nadd only added or modified paths in <path>, if you really want to.\n\nThe \"-q\" option to \"git diff-files\", which does *NOT* mean \"quiet\",\nhas been removed (it told Git to ignore deletion, which you can do\nwith \"git diff-files --diff-filter=d\").\n\n\"git request-pull\" lost a few \"heuristics\" that often led to mistakes.\n\nThe default prefix for \"git svn\" has changed in Git 2.0.  For a long\ntime, \"git svn\" created its remote-tracking branches directly under\nrefs/remotes, but it now places them under refs/remotes/origin/ unless\nit is told otherwise with its \"--prefix\" option.\n\n\nUpdates since v1.9 series\n-------------------------\n\nUI, Workflows & Features\n\n * The \"multi-mail\" post-receive hook (in contrib/) has been updated\n   to a more recent version from upstream.\n\n * The \"remote-hg/bzr\" remote-helper interfaces (used to be in\n   contrib/) are no more.  They are now maintained separately as\n   third-party plug-ins in their own repositories.\n\n * \"git gc --aggressive\" learned \"--depth\" option and\n   \"gc.aggressiveDepth\" configuration variable to allow use of a less\n   insane depth than the built-in default value of 250.\n\n * \"git log\" learned the \"--show-linear-break\" option to show where a\n   single strand-of-pearls is broken in its output.\n\n * The \"rev-parse --parseopt\" mechanism used by scripted Porcelains to\n   parse command-line options and to give help text learned to take\n   the argv-help (the placeholder string for an option parameter,\n   e.g. \"key-id\" in \"--gpg-sign=<key-id>\").\n\n * The pattern to find where the function begins in C/C++ used in\n   \"diff\" and \"grep -p\" has been updated to improve viewing C++\n   sources.\n\n * \"git rebase\" learned to interpret a lone \"-\" as \"@{-1}\", the\n   branch that we were previously on.\n\n * \"git commit --cleanup=<mode>\" learned a new mode, scissors.\n\n * \"git tag --list\" output can be sorted using \"version sort\" with\n   \"--sort=version:refname\".\n\n * Discard the accumulated \"heuristics\" to guess from which branch the\n   result wants to be pulled from and make sure that what the end user\n   specified is not second-guessed by \"git request-pull\", to avoid\n   mistakes.  When you pushed out your 'master' branch to your public\n   repository as 'for-linus', use the new \"master:for-linus\" syntax to\n   denote the branch to be pulled.\n\n * \"git grep\" learned to behave in a way similar to native grep when\n   \"-h\" (no header) and \"-c\" (count) options are given.\n\n * \"git push\" via transport-helper interface has been updated to\n   allow forced ref updates in a way similar to the natively\n   supported transports.\n\n * The \"simple\" mode is the default for \"git push\".\n\n * \"git add -u\" and \"git add -A\", when run without any pathspec, is a\n   tree-wide operation even when run inside a subdirectory of a\n   working tree.\n\n * \"git add <path>\" is the same as \"git add -A <path>\" now.\n\n * \"core.statinfo\" configuration variable, which is a\n   never-advertised synonym to \"core.checkstat\", has been removed.\n\n * The \"-q\" option to \"git diff-files\", which does *NOT* mean\n   \"quiet\", has been removed (it told Git to ignore deletion, which\n   you can do with \"git diff-files --diff-filter=d\").\n\n * Server operators can loosen the \"tips of refs only\" restriction for\n   the remote archive service with the uploadarchive.allowUnreachable\n   configuration option.\n\n * The progress indicators from various time-consuming commands have\n   been marked for i18n/l10n.\n\n * \"git notes -C <blob>\" diagnoses as an error an attempt to use an\n   object that is not a blob.\n\n * \"git config\" learned to read from the standard input when \"-\" is\n   given as the value to its \"--file\" parameter (attempting an\n   operation to update the configuration in the standard input is\n   rejected, of course).\n\n * Trailing whitespaces in .gitignore files, unless they are quoted\n   for fnmatch(3), e.g. \"path\\ \", are warned and ignored.  Strictly\n   speaking, this is a backward-incompatible change, but very unlikely\n   to bite any sane user and adjusting should be obvious and easy.\n\n * Many commands that create commits, e.g. \"pull\" and \"rebase\",\n   learned to take the \"--gpg-sign\" option on the command line.\n\n * \"git commit\" can be told to always GPG sign the resulting commit\n   by setting the \"commit.gpgsign\" configuration variable to \"true\"\n   (the command-line option \"--no-gpg-sign\" should override it).\n\n * \"git pull\" can be told to only accept fast-forward by setting the\n   new \"pull.ff\" configuration variable.\n\n * \"git reset\" learned the \"-N\" option, which does not reset the index\n   fully for paths the index knows about but the tree-ish the command\n   resets to does not (these paths are kept as intend-to-add entries).\n\n\nPerformance, Internal Implementation, etc.\n\n * The compilation options to port to AIX and to MSVC have been\n   updated.\n\n * We started using wildmatch() in place of fnmatch(3) a few releases\n   ago; complete the process and stop using fnmatch(3).\n\n * Uses of curl's \"multi\" interface and \"easy\" interface do not mix\n   well when we attempt to reuse outgoing connections.  Teach the RPC\n   over HTTP code, used in the smart HTTP transport, not to use the\n   \"easy\" interface.\n\n * The bitmap-index feature from JGit has been ported, which should\n   significantly improve performance when serving objects from a\n   repository that uses it.\n\n * The way \"git log --cc\" shows a combined diff against multiple\n   parents has been optimized.\n\n * The prefixcmp() and suffixcmp() functions are gone.  Use\n   starts_with() and ends_with(), and also consider if skip_prefix()\n   suits your needs better when using the former.\n\n\nAlso contains various documentation updates and code clean-ups.  Many\nof them came from flurry of activities as GSoC candidate microproject\nexercises.\n\n\nFixes since v1.9 series\n-----------------------\n\nUnless otherwise noted, all the fixes since v1.9 in the maintenance\ntrack are contained in this release (see the maintenance releases'\nnotes for details).\n\n * \"git p4\" was broken in 1.9 release to deal with changes in binary\n   files.\n   (merge 749b668 cl/p4-use-diff-tree later to maint).\n\n * The shell prompt script (in contrib/), when using the PROMPT_COMMAND\n   interface, used an unsafe construct when showing the branch name in\n   $PS1.\n   (merge 1e4119c8 rh/prompt-pcmode-avoid-eval-on-refname later to maint).\n\n * \"git rebase\" used a POSIX shell construct FreeBSD's /bin/sh does not\n   work well with.\n   (merge 8cd6596 km/avoid-non-function-return-in-rebase later to maint).\n\n * zsh prompt (in contrib/) leaked unnecessary error messages.\n\n * Bash completion (in contrib/) did not complete the refs and remotes\n   correctly given \"git pu<TAB>\" when \"pu\" is aliased to \"push\".\n\n * Some more Unicode code points, defined in Unicode 6.3 as having zero\n   width, have been taught to our display column counting logic.\n   (merge d813ab9 tb/unicode-6.3-zero-width later to maint).\n\n * Some tests used shell constructs that did not work well on FreeBSD\n   (merge ff7a1c6 km/avoid-bs-in-shell-glob later to maint).\n   (merge 00764ca km/avoid-cp-a later to maint).\n\n * \"git update-ref --stdin\" did not fail a request to create a ref\n   when the ref already existed.\n   (merge b9d56b5 mh/update-ref-batch-create-fix later to maint).\n\n * \"git diff --no-index -Mq a b\" fell into an infinite loop.\n   (merge ad1c3fb jc/fix-diff-no-index-diff-opt-parse later to maint).\n\n * \"git fetch --prune\", when the right-hand side of multiple fetch\n   refspecs overlap (e.g. storing \"refs/heads/*\" to\n   \"refs/remotes/origin/*\", while storing \"refs/frotz/*\" to\n   \"refs/remotes/origin/fr/*\"), aggressively thought that lack of\n   \"refs/heads/fr/otz\" on the origin site meant we should remove\n   \"refs/remotes/origin/fr/otz\" from us, without checking their\n   \"refs/frotz/otz\" first.\n\n   Note that such a configuration is inherently unsafe (think what\n   should happen when \"refs/heads/fr/otz\" does appear on the origin\n   site), but that is not a reason not to be extra careful.\n   (merge e6f6371 cn/fetch-prune-overlapping-destination later to maint).\n\n * \"git status --porcelain --branch\" showed its output with labels\n   \"ahead/behind/gone\" translated to the user's locale.\n   (merge 7a76c28 mm/status-porcelain-format-i18n-fix later to maint).\n\n * A stray environment variable $prefix could have leaked into and\n   affected the behaviour of the \"subtree\" script (in contrib/).\n\n * When it is not necessary to edit a commit log message (e.g. \"git\n   commit -m\" is given a message without specifying \"-e\"), we used to\n   disable the spawning of the editor by overriding GIT_EDITOR, but\n   this means all the uses of the editor, other than to edit the\n   commit log message, are also affected.\n   (merge b549be0 bp/commit-p-editor later to maint).\n\n * \"git mv\" that moves a submodule forgot to adjust the array that\n   uses to keep track of which submodules were to be moved to update\n   its configuration.\n   (merge fb8a4e8 jk/mv-submodules-fix later to maint).\n\n * Length limit for the pathname used when removing a path in a deep\n   subdirectory has been removed to avoid buffer overflows.\n   (merge 2f29e0c mh/remove-subtree-long-pathname-fix later to maint).\n\n * The test helper lib-terminal always run an actual test_expect_*\n   when included, which screwed up with the use of skil-all that may\n   have to be done later.\n   (merge 7e27173 jk/lib-terminal-lazy later to maint).\n\n * \"git index-pack\" used a wrong variable to name the keep-file in an\n   error message when the file cannot be written or closed.\n   (merge de983a0 nd/index-pack-error-message later to maint).\n\n * \"rebase -i\" produced a broken insn sheet when the title of a commit\n   happened to contain '\\n' (or ended with '\\c') due to a careless use\n   of 'echo'.\n   (merge cb1aefd us/printf-not-echo later to maint).\n\n * There were a few instances of 'git-foo' remaining in the\n   documentation that should have been spelled 'git foo'.\n   (merge 3c3e6f5 rr/doc-merge-strategies later to maint).\n\n * Serving objects from a shallow repository needs to write a\n   new file to hold the temporary shallow boundaries, but it was not\n   cleaned when we exit due to die() or a signal.\n   (merge 7839632 jk/shallow-update-fix later to maint).\n\n * When \"git stash pop\" stops after failing to apply the stash\n   (e.g. due to conflicting changes), the stash is not dropped. State\n   that explicitly in the output to let the users know.\n   (merge 2d4c993 jc/stash-pop-not-popped later to maint).\n\n * The labels in \"git status\" output that describe the nature of\n   conflicts (e.g. \"both deleted\") were limited to 20 bytes, which was\n   too short for some l10n (e.g. fr).\n   (merge c7cb333 jn/wt-status later to maint).\n\n * \"git clean -d pathspec\" did not use the given pathspec correctly\n   and ended up cleaning too much.\n   (merge 1f2e108 jk/clean-d-pathspec later to maint).\n\n * \"git difftool\" misbehaved when the repository is bound to the\n   working tree with the \".git file\" mechanism, where a textual file\n   \".git\" tells us where it is.\n   (merge fcfec8b da/difftool-git-files later to maint).\n\n * \"git push\" did not pay attention to \"branch.*.pushremote\" if it is\n   defined earlier than \"remote.pushdefault\"; the order of these two\n   variables in the configuration file should not matter, but it did\n   by mistake.\n   (merge 98b406f jk/remote-pushremote-config-reading later to maint).\n\n * Code paths that parse timestamps in commit objects have been\n   tightened.\n   (merge f80d1f9 jk/commit-dates-parsing-fix later to maint).\n\n * \"git diff --external-diff\" incorrectly fed the submodule directory\n   in the working tree to the external diff driver when it knew that it\n   is the same as one of the versions being compared.\n   (merge aba4727 tr/diff-submodule-no-reuse-worktree later to maint).\n\n * \"git reset\" needs to refresh the index when working in a working\n   tree (it can also be used to match the index to the HEAD in an\n   otherwise bare repository), but it failed to set up the working\n   tree properly, causing GIT_WORK_TREE to be ignored.\n   (merge b7756d4 nd/reset-setup-worktree later to maint).\n\n * \"git check-attr\" when working on a repository with a working tree\n   did not work well when the working tree was specified via the\n   \"--work-tree\" (and obviously with \"--git-dir\") option.\n   (merge cdbf623 jc/check-attr-honor-working-tree later to maint).\n\n * \"merge-recursive\" was broken in 1.7.7 era and stopped working in\n   an empty (temporary) working tree, when there are renames\n   involved.  This has been corrected.\n   (merge 6e2068a bk/refresh-missing-ok-in-merge-recursive later to maint.)\n\n * \"git rev-parse\" was loose in rejecting command-line arguments\n   that do not make sense, e.g. \"--default\" without the required\n   value for that option.\n   (merge a43219f ds/rev-parse-required-args later to maint.)\n\n * \"include.path\" variable (or any variable that expects a path that\n   can use ~username expansion) in the configuration file is not a\n   boolean, but the code failed to check it.\n   (merge 67beb60 jk/config-path-include-fix later to maint.)\n\n * Commands that take pathspecs on the command line misbehaved when\n   the pathspec is given as an absolute pathname (which is a\n   practice not particularly encouraged) that points at a symbolic\n   link in the working tree.\n   (merge 6127ff6 mw/symlinks later to maint.)\n\n * \"git diff --quiet -- pathspec1 pathspec2\" sometimes did not return\n   the correct status value.\n   (merge f34b205 nd/diff-quiet-stat-dirty later to maint.)\n\n * Attempting to deepen a shallow repository by fetching over smart\n   HTTP transport failed in the protocol exchange, when the no-done\n   extension was used.  The fetching side waited for the list of\n   shallow boundary commits after the sending side stopped talking to\n   it.\n   (merge 0232852 nd/http-fetch-shallow-fix later to maint.)\n\n * Allow \"git cmd path/\", when the 'path' is where a submodule is\n   bound to the top-level working tree, to match 'path', despite the\n   extra and unnecessary trailing slash (such a slash is often\n   given by command-line completion).\n   (merge 2e70c01 nd/submodule-pathspec-ending-with-slash later to maint.)\n\n * Documentation and in-code comments had many instances of mistaken\n   use of \"nor\", which have been corrected.\n   (merge 235e8d5 jl/nor-or-nand-and later to maint).\n"},{"id":"242916","messageId":"xmqqmwe1bk3f.fsf@gitster.dls.corp.google.com","threadId":"36776","inReplyTo":"xmqqr43dbkni.fsf@gitster.dls.corp.google.com","subject":"Re: [ANNOUNCE] Git v2.0.0","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-05-28T22:43:16Z","receivedAt":"2014-05-28T22:43:16Z","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> The tarballs are found at:\n>\n>     https://www.kernel.org/pub/software/scm/git/testing/\n\nHeh, I do not know how this slipped in, but the real release tarball\nis not in git/testing/ but found at:\n\n     https://www.kernel.org/pub/software/scm/git/\n"},{"id":"242918","messageId":"53866e8562b7a_12a7a052f87a@nysa.notmuch","threadId":"36776","inReplyTo":"xmqqr43dbkni.fsf@gitster.dls.corp.google.com","subject":"RE: [ANNOUNCE] Git v2.0.0","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-28T23:17:25Z","receivedAt":"2014-05-28T23:17:25Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"This is the last mail I sent to you, because you ignore them anyway, and\nremove them from the mailing list.\n\nI'm am cc'ing the git-fc mailing list so there's a public track record\nof this, so you can't claim it didn't happen.\n\nJunio C Hamano wrote:\n>  * The \"remote-hg/bzr\" remote-helper interfaces (used to be in\n>    contrib/) are no more.  They are now maintained separately as\n>    third-party plug-ins in their own repositories.\n\nThis is a lie. You are saying they don't exist any more, but they do\nexist, they \"graduated\" according to your same words.\n\nAlso, in mail [1] Jeff said:\n\n  But that being said, this is Felipe's code. While we have a legal\n  right to distribute it in v2.0, if he would really prefer it out for\n  v2.0, I would respect that.\n\nTo which you agreed, however, after you fucked up v2.0 and removed an\nimportant patch, I said I changed my wish that I didn't want to disturb\nv2.0 in mail [2], a mail you conveniently removed from the tracked\nrecord.\n\nIn mail [3] you acknowledged my wish, and you said you were going to put\nstubs for v2.0, and you didn't. You also conveniently removed this mail\nfrom the archives.\n\nYour rhetoric to make it appear as if the code is gone, your repeated\nfailures to accomplish my wish, even you said you would, and your\ndeliberate removal of the relevant discussion gives me no choice.\n\nI threat all this as deliberate acts of aggression, and I will respond\nas I said I would, and bring as much public attention to what you are\ndoing as possible.\n\n[1] 20140516084126.GB21468@sigill.intra.peff.net\n[2] 537bbd6c1daf_a6f166b308b0@nysa.notmuch\n[3] xmqqlhtwrufq.fsf@gitster.dls.corp.google.com\n\nFor reference, here's the full content of mail [2]:\n\nFrom: Felipe Contreras <felipe.contreras@gmail.com>\nSubject: Re: [PATCH] remote-helpers: point at their upstream repositories\nTo: Junio C Hamano <gitster@pobox.com>,  Felipe Contreras <felipe.contreras@gmail.com>\nCc: Jeff King <peff@peff.net>,  git@vger.kernel.org\nDate: Tue, 20 May 2014 15:39:08 -0500\n--- text/plain ---\nJunio C Hamano wrote:\n> Felipe Contreras <felipe.contreras@gmail.com> writes:\n> \n> > Junio C Hamano wrote:\n> >\n> >>   2. add warning that is given every time the scripts are run and\n> >>      give the same instruction as in README.\n> >> \n> >>   3. (optional) cripple the script to make them always fail after\n> >>      showing the same warning as above.\n> >\n> > This is what I want, and I already sent the patches for; the scripts\n> > will be stubs. At this point you would have effectively removed the\n> > code, which what I want.\n> >  \n> >>   4. Keep README and retire everything else.\n> >\n> > After you've removed the code, I don't care what you do, but I'd say you\n> > should remove the stubs after a long period of time.\n> \n> Let's try this in a different way, as I sense there is a\n> misunderstanding somewhere about your \"wish\".\n> \n> >> \"that\" does not refer to \"remove them at v2.0 (unconditional)\".  It\n> >> refers to \"If Felipe really wants for the removal for v2.0, I would\n> >> respect that\".  And I saw you said you did not want to disrupt v2.0.\n> >> \n> >> If the options I listed all meant removal at v2.0, then I would\n> >> understand your complaints, but that is not the case, so I am not\n> >> sure what to make of that.\n> >\n> > It is a weird choice of semantics then. You said you would \"respect\" my\n> > wish, but your proposals did not \"follow\" my wish.\n> \n> I understand you do not want to disrupt v2.0.  My assumption of that\n> \"not disrupting v2.0\" has been \"there still are git-remote-{hg,bzr}\n> that work just like what they had in v1.9.x, perhaps with some\n> enhancements and regressions you added in the meantime\", and I\n> understood Peff's comment \"If Felipe wants the removal\" to mean that\n> kind of \"disruption\", i.e. \"there is no git-remote-{hg,bzr} that\n> work.\", which would be either step 3 or 4.\n> \n> But your \"After you've removed the code\" comment above makes me\n> wonder that perhaps your definition of \"not disrupting\" was\n> different from ours (which is not good or bad, just different) and\n> you consider that step 3. is \"removal but not distupting v2.0\"?\n> \n> If that is what you want in v2.0, then please say so, and I already\n> said I am fine with that.\n\nNo, I already said I do not want the code removed from v2.0, that's why\nI sent patches that simply added a warning, and I specifically said\nthose were for 2.0.\n\nHowever, after seeing this commit:\n\n10e1fee (Revert \"Merge branch 'fc/transport-helper-sync-error-fix'\")\n\nWhich is:\n\n 1) Inaccurate\n 2) A lie (*you* broke 2.0, not me)\n 3) A disservice to users\n\nI therefore change my wish for you to remove all the remote helpers code\nand a replace them with stubs (the patches I originally sent for\npost-2.0).\n\nIt was a mistake from me to believe you would do the sensible thing for\n2.0.\n\nSo to make it clear, I now request that you do:\n\n 1) Remove all the code.\n\n    Since my patches were removed from the list, here's an updated patch\n    that applies on top of 'master'\n\n    https://github.com/felipec/git/commits/up/remote/remove\n\n 2) Reapply d508e4a (Merge branch 'fc/transport-helper-sync-error-fix')\n\n    Since the code in question is no longer part of v2.0, a \"possible\n    regression\" that you aren't even sure of cannot be the rationale to\n    revert this code.\n\n    Your commit 10e1fee (Revert \"Merge branch\n    'fc/transport-helper-sync-error-fix'\") actively hurts the\n    out-of-tree tools, so I'll consider a failure to re-revert a hostile\n    action.\n\n 3) Update the release notes to mention these tools have been removed\n\n  Additionally, you might want to:\n\n 4) Re-add the following release note:\n\n    * \"git push\" via transport-helper interface (e.g. remote-hg) has\n      been updated to allow forced ref updates in a way similar to the\n      natively supported transports\n\n    I don't know why you removed it in the first place. Clearly you pay\n    no attention at all to these interfaces.\n\nI expect you to do at the very least 1) and 2).\n\n-- \nFelipe Contreras\n"},{"id":"242922","messageId":"538674569a993_1a709413086@nysa.notmuch","threadId":"36776","inReplyTo":"53866e8562b7a_12a7a052f87a@nysa.notmuch","subject":"RE: [ANNOUNCE] Git v2.0.0","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-28T23:42:14Z","receivedAt":"2014-05-28T23:42:14Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Felipe Contreras wrote:\n> In mail [3] you acknowledged my wish, and you said you were going to put\n> stubs for v2.0, and you didn't. You also conveniently removed this mail\n> from the archives.\n\nMy bad. You actually did it. I missed it because the commit is named\n'Revert \"Merge branch 'jc/graduate-remote-hg-bzr' (early part)', which\nis not at all what it is doing.\n\nSo it's just the release notes that are misleading.\n\n-- \nFelipe Contreras\n"},{"id":"242971","messageId":"20140529185311.GB10865@sigill.intra.peff.net","threadId":"36776","inReplyTo":"53866e8562b7a_12a7a052f87a@nysa.notmuch","subject":"Re: [ANNOUNCE] Git v2.0.0","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-05-29T18:53:11Z","receivedAt":"2014-05-29T18:53:11Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, May 28, 2014 at 06:17:25PM -0500, Felipe Contreras wrote:\n\n> This is the last mail I sent to you, because you ignore them anyway, and\n> remove them from the mailing list.\n> [...]\n> [2], a mail you conveniently removed from the tracked record.\n> [...]\n> You also conveniently removed this mail from the archives.\n\nI see you already noticed the changes in v2.0, but I wanted to address\nthese points, because I consider silent censorship to be a serious\naccusation.\n\nI do not think Junio or anyone else has the technical ability to remove\nmessages from the archive. There is not one archive, but rather several\nthat get messages straight from vger.kernel.org and keep their own\ndatabase (e.g., gmane, marc, spinics, nabble). E.g., here is the\n\"deleted\" message on nabble:\n\n  http://git.661346.n2.nabble.com/PATCH-remote-helpers-point-at-their-upstream-repositories-td7610799i20.html#a7611324\n\nHere it is on gmane:\n\n  http://permalink.gmane.org/gmane.comp.version-control.git/249741\n\nHowever, I had to pull that link from the NNTP interface. If you look at\nthe non-threaded web interface for gmane here:\n\n  http://blog.gmane.org/gmane.comp.version-control.git/day=20140520\n\nand here:\n\n  http://blog.gmane.org/gmane.comp.version-control.git/day=20140521\n\nyou will see that there is a huge gap in the list coverage from about\nmidnight on the 20th until the 24th (but these messages are available\nvia nntp). So this seems much more like a gmane bug than anything else.\n\nI've reported the bug to gmane.discuss (no link yet, as I'm waiting for\nthe message to go through, but it is not a high traffic group, so it\nshould be easy to find the thread once it is there).\n\n-Peff\n"},{"id":"242975","messageId":"87tx88fkyt.fsf@fencepost.gnu.org","threadId":"36776","inReplyTo":"20140529185311.GB10865@sigill.intra.peff.net","subject":"Re: [ANNOUNCE] Git v2.0.0","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2014-05-29T19:23:06Z","receivedAt":"2014-05-29T19:23:06Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Wed, May 28, 2014 at 06:17:25PM -0500, Felipe Contreras wrote:\n>\n>> This is the last mail I sent to you, because you ignore them anyway, and\n>> remove them from the mailing list.\n>> [...]\n>> [2], a mail you conveniently removed from the tracked record.\n>> [...]\n>> You also conveniently removed this mail from the archives.\n>\n> I see you already noticed the changes in v2.0, but I wanted to address\n> these points, because I consider silent censorship to be a serious\n> accusation.\n>\n> I do not think Junio or anyone else has the technical ability to remove\n> messages from the archive.\n\nYou can post self-destructing messages by adding X-no-archive: yes if I\nam not mistaken.  But that only concerns stuff you post yourself.\n\n> There is not one archive, but rather several that get messages\n> straight from vger.kernel.org and keep their own database (e.g.,\n> gmane, marc, spinics, nabble).\n\nFrankly, I find it weird that vger.kernel.org does not have an archive\nof its own.  But yes, that makes it unlikely that silent censorship is\nmuch of a thing.  A list moderator may put a particular sender on silent\nmoderation, where postings will only appear once he has acknowledged\nthem.  However, that is a manual and burdensome process and requires an\nup-front decision to do so.  Once a message made it to the list, the\nvarious archives will pick it up.\n\n-- \nDavid Kastrup\n"},{"id":"242976","messageId":"20140529194517.GA16699@sigill.intra.peff.net","threadId":"36776","inReplyTo":"87tx88fkyt.fsf@fencepost.gnu.org","subject":"Re: [ANNOUNCE] Git v2.0.0","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-05-29T19:45:17Z","receivedAt":"2014-05-29T19:45:17Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, May 29, 2014 at 09:23:06PM +0200, David Kastrup wrote:\n\n> > I do not think Junio or anyone else has the technical ability to remove\n> > messages from the archive.\n> \n> You can post self-destructing messages by adding X-no-archive: yes if I\n> am not mistaken.  But that only concerns stuff you post yourself.\n\nRight, I was thinking specifically of deleting somebody else's message.\nThe other obvious choke point is to convince vger to silently drop\nmessages from somebody, but:\n\n  1. That is different than deleting already-posted messages.\n\n  2. vger is maintained by kernel.org folks, none of whom is a\n     regular on the git list. So it would involve some collusion with\n     those admins.\n\nThat is pretty clearly not what happened here (the messages did go out\nto the list).\n\n> Frankly, I find it weird that vger.kernel.org does not have an archive\n> of its own.\n\nI don't think there is much need, as gmane is pretty featureful (and if\nyou disagree, there are other competitors, or you can set up your own).\nI assume the current situation grew organically (somebody wanted an\narchive, so they set it up, and then vger saw no need to compete).\n\n-Peff\n\nPS My gmane bug report posted here:\n\n     http://article.gmane.org/gmane.discuss/16175\n"},{"id":"243060","messageId":"5388fb283edaf_bd8167d3002b@nysa.notmuch","threadId":"36776","inReplyTo":"20140529185311.GB10865@sigill.intra.peff.net","subject":"Re: [ANNOUNCE] Git v2.0.0","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-30T21:42:00Z","receivedAt":"2014-05-30T21:42:00Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Jeff King wrote:\n> On Wed, May 28, 2014 at 06:17:25PM -0500, Felipe Contreras wrote:\n> \n> > This is the last mail I sent to you, because you ignore them anyway, and\n> > remove them from the mailing list.\n> > [...]\n> > [2], a mail you conveniently removed from the tracked record.\n> > [...]\n> > You also conveniently removed this mail from the archives.\n> \n> I see you already noticed the changes in v2.0, but I wanted to address\n> these points, because I consider silent censorship to be a serious\n> accusation.\n\nYes, I also think silent censorship is a very seriours matter, and I was\nvery dissapointed that this mailing list would engage in that.\n\n> I've reported the bug to gmane.discuss (no link yet, as I'm waiting\n> for the message to go through, but it is not a high traffic group, so\n> it should be easy to find the thread once it is there).\n\nThanks. At first I thought that was the reason, but then I noticed it\nwas always my mails that seemed to get this \"bug\", so I decided it was\ntoo much of a coincidence.\n\nHopefully it's indeed a bug.\n\n-- \nFelipe Contreras\n"},{"id":"243071","messageId":"87k392e0mf.fsf@fencepost.gnu.org","threadId":"36776","inReplyTo":"5388fb283edaf_bd8167d3002b@nysa.notmuch","subject":"Re: [ANNOUNCE] Git v2.0.0","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2014-05-31T09:52:24Z","receivedAt":"2014-05-31T09:52:24Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Felipe Contreras <felipe.contreras@gmail.com> writes:\n\n> Jeff King wrote:\n>> On Wed, May 28, 2014 at 06:17:25PM -0500, Felipe Contreras wrote:\n>> \n>> > This is the last mail I sent to you, because you ignore them anyway, and\n>> > remove them from the mailing list.\n>> > [...]\n>> > [2], a mail you conveniently removed from the tracked record.\n>> > [...]\n>> > You also conveniently removed this mail from the archives.\n>> \n>> I see you already noticed the changes in v2.0, but I wanted to address\n>> these points, because I consider silent censorship to be a serious\n>> accusation.\n>\n> Yes, I also think silent censorship is a very seriours matter, and I was\n> very dissapointed that this mailing list would engage in that.\n>\n>> I've reported the bug to gmane.discuss (no link yet, as I'm waiting\n>> for the message to go through, but it is not a high traffic group, so\n>> it should be easy to find the thread once it is there).\n>\n> Thanks. At first I thought that was the reason, but then I noticed it\n> was always my mails that seemed to get this \"bug\", so I decided it was\n> too much of a coincidence.\n\nSome mailing list filters and/or spam filters flag mails with too many\nrecipients so that they need to pass through moderation first.  The\ntypical threads on this list are short and have few recipients while\nlonger threads, due to the list policy of adding every participants to\nthe Cc, will tend to have more recipients.\n\nSo there may a bias against long-running threads with multiple\nparticipants with regard to timely delivery.\n\nAnd frankly, if I were a list moderator and software asked me through\nthis sort of coincidence whether a mail should be delivered or not and a\nglance at it shows nothing but insults, wild accusations, threats and so\non for the umpteenth time, I'd consider twice clicking \"Accept\".\nWhether or not I ultimately did so, this would likely contribute to the\ndelay.\n\n-- \nDavid Kastrup\n"},{"id":"243119","messageId":"20140602063607.GA27445@sigill.intra.peff.net","threadId":"36776","inReplyTo":"87k392e0mf.fsf@fencepost.gnu.org","subject":"Re: [ANNOUNCE] Git v2.0.0","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-06-02T06:36:07Z","receivedAt":"2014-06-02T06:36:07Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, May 31, 2014 at 11:52:24AM +0200, David Kastrup wrote:\n\n> Some mailing list filters and/or spam filters flag mails with too many\n> recipients so that they need to pass through moderation first.  The\n> typical threads on this list are short and have few recipients while\n> longer threads, due to the list policy of adding every participants to\n> the Cc, will tend to have more recipients.\n\nAFAIK, vger does not do anything like this. They block HTML, messages\nlacking a message-id, messages over 100K, and certain taboo phrases:\n\n  http://vger.kernel.org/majordomo-info.html#taboo\n\nAnd anyway, I do not think vger is responsible here. The messages were\ndelivered through the list, and other archives have them. This looks\nlike a gmane problem.\n\nAccording to gmane.org, their admins will look manually at messages\nflagged as spam, but I find it unlikely that they flagged several days\nworth of git traffic (and when they do, I think they cross-post them to\na spam group in NNTP, and the messages do not seem to be marked as\nsuch). So I think this really is just a bug.\n\n> And frankly, if I were a list moderator and software asked me through\n> this sort of coincidence whether a mail should be delivered or not and a\n> glance at it shows nothing but insults, wild accusations, threats and so\n> on for the umpteenth time, I'd consider twice clicking \"Accept\".\n> Whether or not I ultimately did so, this would likely contribute to the\n> delay.\n\nI do not disagree, but please let's not rehash all of that again.\n\n-Peff\n"},{"id":"243121","messageId":"538c206ea4f86_79bdcdb2fc42@nysa.notmuch","threadId":"36776","inReplyTo":"20140602063607.GA27445@sigill.intra.peff.net","subject":"Re: [ANNOUNCE] Git v2.0.0","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-06-02T06:57:50Z","receivedAt":"2014-06-02T06:57:50Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Jeff King wrote:\n> On Sat, May 31, 2014 at 11:52:24AM +0200, David Kastrup wrote:\n\n> > And frankly, if I were a list moderator and software asked me through\n> > this sort of coincidence whether a mail should be delivered or not and a\n> > glance at it shows nothing but insults, wild accusations, threats and so\n> > on for the umpteenth time, I'd consider twice clicking \"Accept\".\n> > Whether or not I ultimately did so, this would likely contribute to the\n> > delay.\n> \n> I do not disagree, but please let's not rehash all of that again.\n\nFTR. I haven't insulted anybody, I on the other hand have been insulted\nplenty of times, included by Junio.\n\n-- \nFelipe Contreras\n"},{"id":"243124","messageId":"871tv7bwpy.fsf@fencepost.gnu.org","threadId":"36776","inReplyTo":"20140602063607.GA27445@sigill.intra.peff.net","subject":"Re: [ANNOUNCE] Git v2.0.0","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2014-06-02T07:24:09Z","receivedAt":"2014-06-02T07:24:09Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Sat, May 31, 2014 at 11:52:24AM +0200, David Kastrup wrote:\n>\n>> Some mailing list filters and/or spam filters flag mails with too many\n>> recipients so that they need to pass through moderation first.  The\n>> typical threads on this list are short and have few recipients while\n>> longer threads, due to the list policy of adding every participants to\n>> the Cc, will tend to have more recipients.\n>\n> AFAIK, vger does not do anything like this. They block HTML, messages\n> lacking a message-id, messages over 100K, and certain taboo phrases:\n>\n>   http://vger.kernel.org/majordomo-info.html#taboo\n>\n> And anyway, I do not think vger is responsible here. The messages were\n> delivered through the list, and other archives have them. This looks\n> like a gmane problem.\n\nI am reading more than one list through Gmane/nntp, and in the last\nyears it was not infrequent that delivery paused for even days and/or\nspurious old messages from the last day or even more were getting\nredelivered.\n\n> According to gmane.org, their admins will look manually at messages\n> flagged as spam, but I find it unlikely that they flagged several days\n> worth of git traffic (and when they do, I think they cross-post them\n> to a spam group in NNTP, and the messages do not seem to be marked as\n> such). So I think this really is just a bug.\n\nQuite so.  In particular when other mirrors got the messages timely.\n\n-- \nDavid Kastrup\n"},{"id":"243173","messageId":"20140603120832.7235c706@notabene.brown","threadId":"36776","inReplyTo":"xmqqr43dbkni.fsf@gitster.dls.corp.google.com","subject":"Re: [ANNOUNCE] Git v2.0.0","fromName":"NeilBrown","fromEmail":"neilb@suse.de","sentAt":"2014-06-03T02:08:32Z","receivedAt":"2014-06-03T02:08:32Z","isPatch":false,"sender":{"key":"neilb@suse.de","avatar":"https://gravatar.com/avatar/550a4445c91cb1d8120493c6079a980b8cf7d6e172ab74424a0b72a693291d19?d=mp&s=160"},"body":"On Wed, 28 May 2014 15:31:13 -0700 Junio C Hamano <gitster@pobox.com> wrote:\n\n> The latest feature release Git v2.0.0 is now available at the\n> usual places.\n\n\n> \n> \"git request-pull\" lost a few \"heuristics\" that often led to mistakes.\n> \n\nI've installed git 2.0.0 and now when I\n\n  git request-pull master git://neil.brown.name/md\n\nafter tagging the current commit as \"md/3.15-fixes\" and pushing out the tag,\nI get\n\nwarn: No match for commit 2ac295a544dcae9299cba13ce250419117ae7fd1 found at git://neil.brown.name/md\nwarn: Are you sure you pushed 'HEAD' there?\n\nYet \n   git ls-remote git://neil.brown.name/md | grep 2ac29\nshows\n\n2ac295a544dcae9299cba13ce250419117ae7fd1\trefs/tags/md/3.15-fixes^{}\n\nWhich seems clear and unambiguous.\n\nDoes this mean that the 'end' arg to 'git request-pull' is no longer optional\n(i.e. the man page is wrong), or that too many heuristics were removed?\n\n.... Looking through the change log a bit, it seems that if the 'end' arg is\nomitted, then the current 'branch' name is used and must match the same name\nat the git URL.  Could it also check the current 'tag' name?  As we are\nencouraged to used signed tags, this seems sensible.\nIn fact, I would suggest checking for a tag first, and only considering the\nbranch name if there is no tag on the current commit.\n\nThanks,\nNeilBrown\n\n"},{"id":"243174","messageId":"CA+55aFyEce-48tcguL4GvvbomivZrnOYptzOenCrGTiQxxhHTg@mail.gmail.com","threadId":"36776","inReplyTo":"20140603120832.7235c706@notabene.brown","subject":"Re: [ANNOUNCE] Git v2.0.0","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2014-06-03T02:59:53Z","receivedAt":"2014-06-03T02:59:53Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"On Mon, Jun 2, 2014 at 7:08 PM, NeilBrown <neilb@suse.de> wrote:\n>\n>   git request-pull master git://neil.brown.name/md\n>\n> after tagging the current commit as \"md/3.15-fixes\" and pushing out the tag\n\nYou should *tell* \"git request-pull\" what you're actually requesting to pull.\n\nThe old \"let's guess based on the commit at the top of your tree\" may\nhave worked for you (because you only ever had one matching thing),\nbut it did not work in general.\n\nSo the new \"git request-pull\" does not guess. If you want to request a\ntag to be pulled, you name it.  Because if you don't name it, it now\ndefaults to HEAD (like all other git log commands) rather than\nguessing. So please write it as\n\n   git request-pull master git://neil.brown.name/md md/3.15-fixes\n\nI guess the man-page should be made more explicit about this too.\n\n              Linus\n"},{"id":"243187","messageId":"20140603214625.2db24440@notabene.brown","threadId":"36776","inReplyTo":"CA+55aFyEce-48tcguL4GvvbomivZrnOYptzOenCrGTiQxxhHTg@mail.gmail.com","subject":"Re: [ANNOUNCE] Git v2.0.0","fromName":"NeilBrown","fromEmail":"neilb@suse.de","sentAt":"2014-06-03T11:46:25Z","receivedAt":"2014-06-03T11:46:25Z","isPatch":false,"sender":{"key":"neilb@suse.de","avatar":"https://gravatar.com/avatar/550a4445c91cb1d8120493c6079a980b8cf7d6e172ab74424a0b72a693291d19?d=mp&s=160"},"body":"On Mon, 2 Jun 2014 19:59:53 -0700 Linus Torvalds\n<torvalds@linux-foundation.org> wrote:\n\n> On Mon, Jun 2, 2014 at 7:08 PM, NeilBrown <neilb@suse.de> wrote:\n> >\n> >   git request-pull master git://neil.brown.name/md\n> >\n> > after tagging the current commit as \"md/3.15-fixes\" and pushing out the tag\n> \n> You should *tell* \"git request-pull\" what you're actually requesting to pull.\n> \n> The old \"let's guess based on the commit at the top of your tree\" may\n> have worked for you (because you only ever had one matching thing),\n> but it did not work in general.\n> \n> So the new \"git request-pull\" does not guess. If you want to request a\n> tag to be pulled, you name it.  Because if you don't name it, it now\n> defaults to HEAD (like all other git log commands) rather than\n> guessing. So please write it as\n> \n>    git request-pull master git://neil.brown.name/md md/3.15-fixes\n> \n> I guess the man-page should be made more explicit about this too.\n> \n>               Linus\n\nOK, thanks.   I guess I can live with being a bit more explicit.\n\nNeilBrown\n"}]}