{"thread":{"id":"39780","subject":"Draft of Git Rev News edition 5","startedAt":"2015-07-05T11:13:57Z","lastAt":"2015-07-08T17:36:41Z","messageCount":16,"participants":["Christian Couder","Eric Sunshine","Thomas Ferris Nicolaisen","Junio C Hamano","Michael J Gruber","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"265529","messageId":"CAP8UFD2fpRiOmgL9GW-1N9ZLAY+p-nOSH-b57vJFO4e_tELrWw@mail.gmail.com","threadId":"39780","inReplyTo":null,"subject":"Draft of Git Rev News edition 5","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2015-07-05T11:13:57Z","receivedAt":"2015-07-05T11:13:57Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Hi,\n\nA draft of Git Rev News edition 5 is available here:\n\nhttps://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-5.md\n\nEveryone is welcome to contribute in any section, like Junio and\nMatthieu already did, either by editing the\nabove page on GitHub and sending a pull request, or by commenting on\nthis GitHub issue:\n\nhttps://github.com/git/git.github.io/issues/77\n\nYou can also reply to this email.\n\nI tried to cc everyone who appears in this edition but maybe I missed\nsome people, sorry about that.\n\nThomas, Nicola and myself plan to publish this edition on Wednesday\nthe 8th of July.\n\nThanks,\nChristian.\n"},{"id":"265537","messageId":"20150705191101.GB9815@flurp.local","threadId":"39780","inReplyTo":"CAP8UFD2fpRiOmgL9GW-1N9ZLAY+p-nOSH-b57vJFO4e_tELrWw@mail.gmail.com","subject":"Re: Draft of Git Rev News edition 5","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2015-07-05T19:11:01Z","receivedAt":"2015-07-05T19:11:01Z","isPatch":false,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Sun, Jul 05, 2015 at 01:13:57PM +0200, Christian Couder wrote:\n> A draft of Git Rev News edition 5 is available here:\n> https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-5.md\n> Everyone is welcome to contribute in any section...\n\nI'm not familiar with the criteria for deciding what merits mention\nin the newsletter. Is the recent introduction of git-worktree and the\nattendant relocation of \"add\" and \"prune\" functionality worthy? If\nso, perhaps the following write-up would be suitable?\n\n---- 8< ----\nFrom: Eric Sunshine \nSubject: [PATCH] rn-5: talk about new git-worktree command\n\n---\n rev_news/drafts/edition-5.md | 60 +++++++++++++++++++++++++++++++++++++++++++-\n 1 file changed, 59 insertions(+), 1 deletion(-)\n\ndiff --git a/rev_news/drafts/edition-5.md b/rev_news/drafts/edition-5.md\nindex eb00c4a..9df4155 100644\n--- a/rev_news/drafts/edition-5.md\n+++ b/rev_news/drafts/edition-5.md\n@@ -206,6 +206,63 @@ to process the format passed in `--date=format:...`, a discussion\n about how to manage a potential strftime() failure when it is passed a\n bogus format ensued.\n \n+\n+* Linked-worktrees\n+\n+The linked-worktree facility allows multiple working directories to share a\n+single repository, with (typically) a different branch checked out in each\n+worktree. Introduced more than half a year ago to provide integrated and\n+platform-agnostic support for similar functionality long supplied by the\n+Unix-only and somewhat fragile `contrib/git-new-workdir` script,\n+linked-worktrees recently migrated to the *master* branch, but is not\n+yet part of any release.\n+\n+Creation of linked-worktrees is accomplished via `git checkout --to \n+`, and cleanup of leftover administrative files, after `` is\n+deleted, is done with `git prune --worktrees`. However, a recent unrelated\n+change to `git prune` led to a\n+[discussion](http://article.gmane.org/gmane.comp.version-control.git/272546)\n+that concluded that worktree-related maintenance functionality doesn't\n+belong in `git prune`.\n+\n+Consequently, Nguyễn Thái Ngọc Duy submitted a\n+[patch](http://thread.gmane.org/gmane.comp.version-control.git/272949)\n+which introduces a new `git worktree` command, and relocates `git prune\n+--worktrees` functionality to `git worktree prune`.\n+\n+Eric Sunshine then further fleshed out `git worktree` with a\n+[patch](http://article.gmane.org/gmane.comp.version-control.git/273032)\n+which relocates `git checkout --to` functionality to `git worktree new`.\n+A lengthy\n+[discussion](http://thread.gmane.org/gmane.comp.version-control.git/273032)\n+ensued, which eventually led to a second version, consisting of [23\n+patches](http://thread.gmane.org/gmane.comp.version-control.git/273316),\n+and which names the command `git worktree add`, rather than `git worktree\n+new`, and gives the documentation some needed attention.\n+\n+Aside from documentation updates, several other user-visible changes arrive\n+with the second version. For instance, while preparing worktree-creation\n+functionality for the move from `git checkout` to `git worktree`, Eric\n+discovered and fixed a bug where `git checkout --to HEAD~1` would\n+instead incorrectly checkout `HEAD~2` at ``.\n+\n+The second version also introduces convenience enhancements. In\n+particular, the `` in `git worktree add `, is now\n+optional. When omitted, a new branch is created automatically based upon\n+``, as if `-b $(basename )` had been provided (where `-b\n+` creates a new branch). For example, given `git worktree add\n+../hotfix`, a new branch named *hotfix* is created and checked out into new\n+worktree `../hotfix`, as if `git worktree -b hotfix ../hotfix HEAD` had\n+been specified.\n+\n+Finally, the question was\n+[raised](http://article.gmane.org/gmane.comp.version-control.git/273107)\n+whether `git checkout --ignore-other-worktrees` should be retired and `git\n+checkout --force` overloaded to subsume its duties, however, Junio was [not\n+thrilled](http://article.gmane.org/gmane.comp.version-control.git/273108)\n+by the idea.\n+\n+\n ## Releases\n \n * [git-multimail](https://github.com/git-multimail/git-multimail) [1.1.0](https://github.com/git-multimail/git-multimail/releases/tag/1.1.0) was released. git-multimail is a tool to send notification emails for pushes to a git repository. It is also available in the `contrib/hooks/multimail/` directory of Git's source tree (version 1.1.0 will be distributed with Git 2.5).\n@@ -282,5 +339,6 @@ __Git tools and sites__\n ## Credits\n \n This edition of Git Rev News was curated by Christian Couder <>,\n-Thomas Ferris Nicolaisen <> and Nicola Paolucci <>\n+Thomas Ferris Nicolaisen <> Nicola Paolucci <>,\n+and Eric Sunshine <>,\n with help from Junio C Hamano, Matthieu Moy and Johannes Schindelin.\n-- \n2.5.0.rc1.197.g417e668\n\n---- 8< ----\n"},{"id":"265538","messageId":"CAP8UFD3pD_6_SrrtCWywA8x5XY_SD3bed=QhZBBrTq0zQvqFPw@mail.gmail.com","threadId":"39780","inReplyTo":"20150705191101.GB9815@flurp.local","subject":"Re: Draft of Git Rev News edition 5","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2015-07-05T21:13:54Z","receivedAt":"2015-07-05T21:13:54Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Sun, Jul 5, 2015 at 9:11 PM, Eric Sunshine wrote:\n> On Sun, Jul 05, 2015 at 01:13:57PM +0200, Christian Couder wrote:\n>> A draft of Git Rev News edition 5 is available here:\n>> https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-5.md\n>> Everyone is welcome to contribute in any section...\n>\n> I'm not familiar with the criteria for deciding what merits mention\n> in the newsletter. Is the recent introduction of git-worktree and the\n> attendant relocation of \"add\" and \"prune\" functionality worthy?\n\nYes, I think it's really worthy, thanks a lot for contributing this\nvery interesting article!\n\n> If so, perhaps the following write-up would be suitable?\n\nYes, I changed a few things to make fit better with the rest of the\ncontent, but otherwise it looks great!\n\nI created this PR to discuss the changes I made:\n\nhttps://github.com/git/git.github.io/pull/85\n\nThomas just merged it, but we can still discuss it.\n\nThanks again,\nChristian.\n"},{"id":"265540","messageId":"CAPig+cTpy32c13Sv=m49hzqOBisZ0v07AT0X5BYNB07acrcW8w@mail.gmail.com","threadId":"39780","inReplyTo":"CAP8UFD3pD_6_SrrtCWywA8x5XY_SD3bed=QhZBBrTq0zQvqFPw@mail.gmail.com","subject":"Re: Draft of Git Rev News edition 5","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2015-07-05T22:01:09Z","receivedAt":"2015-07-05T22:01:09Z","isPatch":false,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Sun, Jul 5, 2015 at 5:13 PM, Christian Couder\n wrote:\n> On Sun, Jul 5, 2015 at 9:11 PM, Eric Sunshine wrote:\n>> On Sun, Jul 05, 2015 at 01:13:57PM +0200, Christian Couder wrote:\n>>> A draft of Git Rev News edition 5 is available here:\n>>> https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-5.md\n>>> Everyone is welcome to contribute in any section...\n>>\n>> I'm not familiar with the criteria for deciding what merits mention\n>> in the newsletter. Is the recent introduction of git-worktree and the\n>> attendant relocation of \"add\" and \"prune\" functionality worthy?\n>\n> Yes, I think it's really worthy, thanks a lot for contributing this\n> very interesting article!\n>\n>> If so, perhaps the following write-up would be suitable?\n>\n> Yes, I changed a few things to make fit better with the rest of the\n> content, but otherwise it looks great!\n>\n> I created this PR to discuss the changes I made:\n> https://github.com/git/git.github.io/pull/85\n\nThanks, for incorporating it. Unfortunately, the non-ASCII characters\nin Duy's name got corrupted, and the botch is present in the patch I\nsent. Sorry. Not sure how that happened. Can you fix it locally?\n"},{"id":"265541","messageId":"CAEcj5uXiGVvLm==s_SB7GnvBfuKi7j4yH+fgNq4JZtkvK7pZwg@mail.gmail.com","threadId":"39780","inReplyTo":"CAPig+cTpy32c13Sv=m49hzqOBisZ0v07AT0X5BYNB07acrcW8w@mail.gmail.com","subject":"Re: Draft of Git Rev News edition 5","fromName":"Thomas Ferris Nicolaisen","fromEmail":"tfnico@gmail.com","sentAt":"2015-07-05T22:35:29Z","receivedAt":"2015-07-05T22:35:29Z","isPatch":false,"sender":{"key":"tfnico@gmail.com","avatar":"https://gravatar.com/avatar/628cf28a25ca4c596c7284562100f70f0ef908bcbfadd4da1eb3d48c23658d01?d=mp&s=160"},"body":"On Mon, Jul 6, 2015 at 12:01 AM, Eric Sunshine wrote:\n> Unfortunately, the non-ASCII characters\n> in Duy's name got corrupted, and the botch is present in the patch I\n> sent. Sorry. Not sure how that happened. Can you fix it locally?\n\nFixed [1].\n\n[1] https://github.com/git/git.github.io/commit/b5f7d6523ca6a634d568fc9017135ff2a9ea6462\n"},{"id":"265542","messageId":"CAPig+cRv6g_nAEdGtrESFiE+5+OxEHwjhEPX0Q0WL+eHzkCAGA@mail.gmail.com","threadId":"39780","inReplyTo":"CAEcj5uXiGVvLm==s_SB7GnvBfuKi7j4yH+fgNq4JZtkvK7pZwg@mail.gmail.com","subject":"Re: Draft of Git Rev News edition 5","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2015-07-05T23:12:40Z","receivedAt":"2015-07-05T23:12:40Z","isPatch":false,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Sun, Jul 5, 2015 at 6:35 PM, Thomas Ferris Nicolaisen\n wrote:\n> On Mon, Jul 6, 2015 at 12:01 AM, Eric Sunshine wrote:\n>> Unfortunately, the non-ASCII characters\n>> in Duy's name got corrupted, and the botch is present in the patch I\n>> sent. Sorry. Not sure how that happened. Can you fix it locally?\n>\n> Fixed [1].\n>\n> [1] https://github.com/git/git.github.io/commit/b5f7d6523ca6a634d568fc9017135ff2a9ea6462\n\nThanks.\n"},{"id":"265569","messageId":"xmqqa8v92qdf.fsf@gitster.dls.corp.google.com","threadId":"39780","inReplyTo":"20150705191101.GB9815@flurp.local","subject":"Re: Draft of Git Rev News edition 5","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-07-06T16:38:20Z","receivedAt":"2015-07-06T16:38:20Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eric Sunshine writes:\n\n> I'm not familiar with the criteria for deciding what merits mention\n> in the newsletter. Is the recent introduction of git-worktree and the\n> attendant relocation of \"add\" and \"prune\" functionality worthy? If\n> so, perhaps the following write-up would be suitable?\n\nOne issue I had with this text was that it was not immediately clear\nwhat the end-game UI of the feature was. Is \"checkout --to\" they\nway the user is expected to trigger this? It appears in the very\nearly part of the multi-paragraph description and I suspect that the\nmajority of the users would think that way, not with \"worktree add\"\nthat appears a lot later.\n"},{"id":"265578","messageId":"CAPig+cTfkDqSDRqDjA=CNkT1c7Fo0zaLiwi2bAbCLZxPHi5=Bg@mail.gmail.com","threadId":"39780","inReplyTo":"xmqqa8v92qdf.fsf@gitster.dls.corp.google.com","subject":"Re: Draft of Git Rev News edition 5","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2015-07-06T17:24:40Z","receivedAt":"2015-07-06T17:24:40Z","isPatch":false,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Mon, Jul 6, 2015 at 12:38 PM, Junio C Hamano wrote:\n> Eric Sunshine writes:\n>> I'm not familiar with the criteria for deciding what merits mention\n>> in the newsletter. Is the recent introduction of git-worktree and the\n>> attendant relocation of \"add\" and \"prune\" functionality worthy? If\n>> so, perhaps the following write-up would be suitable?\n>\n> One issue I had with this text was that it was not immediately clear\n> what the end-game UI of the feature was. Is \"checkout --to\" they\n> way the user is expected to trigger this? It appears in the very\n> early part of the multi-paragraph description and I suspect that the\n> majority of the users would think that way, not with \"worktree add\"\n> that appears a lot later.\n\nI had the same concern when proof-reading, but wasn't sure if the\nconcern was warranted. Since you reacted to the text in the same way,\nI'd say the concern was justified.\n\nHow about this instead: prefixing with \"As originally implemented\",\nwith a couple s/is/was/ thrown in...\n\n As originally implemented, creation of linked-worktrees was\n accomplished via `git checkout --to `, and cleanup\n of leftover administrative files, after `` is deleted, was\n done with `git prune --worktrees`. However, a recent unrelated\n change to `git prune` led to a discussion that concluded that\n worktree-related maintenance functionality didn't belong in `git\n prune`.\n\nIs that sufficient to clue in the reader that \"checkout --to\" is not\nfinal form, or should we mention \"worktree add\" and \"worktree prune\"\nupfront?\n"},{"id":"265609","messageId":"xmqqfv5118a3.fsf@gitster.dls.corp.google.com","threadId":"39780","inReplyTo":"CAPig+cTfkDqSDRqDjA=CNkT1c7Fo0zaLiwi2bAbCLZxPHi5=Bg@mail.gmail.com","subject":"Re: Draft of Git Rev News edition 5","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-07-06T17:54:28Z","receivedAt":"2015-07-06T17:54:28Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eric Sunshine writes:\n\n> How about this instead: prefixing with \"As originally implemented\",\n> with a couple s/is/was/ thrown in...\n>\n> As originally implemented, creation of linked-worktrees was\n> accomplished via `git checkout --to `, and cleanup\n> of leftover administrative files, after `` is deleted, was\n> done with `git prune --worktrees`. However, a recent unrelated\n> change to `git prune` led to a discussion that concluded that\n> worktree-related maintenance functionality didn't belong in `git\n> prune`.\n>\n> Is that sufficient to clue in the reader that \"checkout --to\" is not\n> final form,...\n\nYeah, I think that is a good way to address my concern.\n\nThe current draft release notes to 2.5 mentions this feature as\nexperimental and warns that its UI is bound to change. We will\nship the upcoming release with \"checkout --to\" and the more places\nwe advise the users that this UI is not final, the better.\n"},{"id":"265619","messageId":"20150706193941.GA1730@flurp.local","threadId":"39780","inReplyTo":"xmqqfv5118a3.fsf@gitster.dls.corp.google.com","subject":"Re: Draft of Git Rev News edition 5","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2015-07-06T19:39:41Z","receivedAt":"2015-07-06T19:39:41Z","isPatch":false,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Mon, Jul 06, 2015 at 10:54:28AM -0700, Junio C Hamano wrote:\n> Eric Sunshine writes:\n> > How about this instead: prefixing with \"As originally implemented\",\n> > with a couple s/is/was/ thrown in...\n> >\n> > As originally implemented, creation of linked-worktrees was\n> > accomplished via `git checkout --to `, and cleanup\n> > of leftover administrative files, after `` is deleted, was\n> > done with `git prune --worktrees`. However, a recent unrelated\n> > change to `git prune` led to a discussion that concluded that\n> > worktree-related maintenance functionality didn't belong in `git\n> > prune`.\n> >\n> > Is that sufficient to clue in the reader that \"checkout --to\" is not\n> > final form,...\n> \n> Yeah, I think that is a good way to address my concern.\n> \n> The current draft release notes to 2.5 mentions this feature as\n> experimental and warns that its UI is bound to change. We will\n> ship the upcoming release with \"checkout --to\" and the more places\n> we advise the users that this UI is not final, the better.\n\nHere it is in patch form. (I wouldn't be surprised if the non-ASCII\ncharacters in Duy's name in the context line get botched again...)\n\n---- 8< ----\nFrom: Eric Sunshine \nSubject: [PATCH] rn-5: make it clear that \"git checkout --to\" is not final\n form\n\nWe don't want to mislead reader who is only lightly skimming the text\nor who doesn't read the entire article that \"git checkout --to\" is the\nfinal form.\n---\n rev_news/drafts/edition-5.md | 11 ++++++-----\n 1 file changed, 6 insertions(+), 5 deletions(-)\n\ndiff --git a/rev_news/drafts/edition-5.md b/rev_news/drafts/edition-5.md\nindex 241e9df..b71c99c 100644\n--- a/rev_news/drafts/edition-5.md\n+++ b/rev_news/drafts/edition-5.md\n@@ -35,12 +35,13 @@ Unix-only and somewhat fragile `contrib/git-new-workdir` script,\n linked-worktrees recently migrated to the *master* branch, but is not\n yet part of any release.\n \n-Creation of linked-worktrees is accomplished via `git checkout --to \n-`, and cleanup of leftover administrative files, after `` is\n-deleted, is done with `git prune --worktrees`. However, a recent unrelated\n-change to `git prune` led to a\n+As originally implemented, creation of linked-worktrees was accomplished\n+via `git checkout --to `, and cleanup of leftover\n+administrative files after manual deletion of `` was done with `git\n+prune --worktrees`. However, a recent unrelated change to `git prune` led\n+to a\n [discussion](http://thread.gmane.org/gmane.comp.version-control.git/272447/focus=272546)\n-that concluded that worktree-related maintenance functionality doesn't\n+that concluded that worktree-related maintenance functionality didn't\n belong in `git prune`.\n \n Consequently, Nguyễn Thái Ngọc Duy submitted a\n-- \n2.5.0.rc1.197.g417e668\n"},{"id":"265622","messageId":"CAP8UFD2JkPqkXWX0EZFcSx4Dh47Esvrnviv3+DQQgPYTC3DBHQ@mail.gmail.com","threadId":"39780","inReplyTo":"20150706193941.GA1730@flurp.local","subject":"Re: Draft of Git Rev News edition 5","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2015-07-06T19:59:43Z","receivedAt":"2015-07-06T19:59:43Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Mon, Jul 6, 2015 at 9:39 PM, Eric Sunshine wrote:\n> On Mon, Jul 06, 2015 at 10:54:28AM -0700, Junio C Hamano wrote:\n>> Eric Sunshine writes:\n>> > How about this instead: prefixing with \"As originally implemented\",\n>> > with a couple s/is/was/ thrown in...\n>> >\n>> > As originally implemented, creation of linked-worktrees was\n>> > accomplished via `git checkout --to `, and cleanup\n>> > of leftover administrative files, after `` is deleted, was\n>> > done with `git prune --worktrees`. However, a recent unrelated\n>> > change to `git prune` led to a discussion that concluded that\n>> > worktree-related maintenance functionality didn't belong in `git\n>> > prune`.\n>> >\n>> > Is that sufficient to clue in the reader that \"checkout --to\" is not\n>> > final form,...\n>>\n>> Yeah, I think that is a good way to address my concern.\n>>\n>> The current draft release notes to 2.5 mentions this feature as\n>> experimental and warns that its UI is bound to change. We will\n>> ship the upcoming release with \"checkout --to\" and the more places\n>> we advise the users that this UI is not final, the better.\n>\n> Here it is in patch form. (I wouldn't be surprised if the non-ASCII\n> characters in Duy's name in the context line get botched again...)\n\nOk, the following is merged:\n\nhttps://github.com/git/git.github.io/pull/87\n\nThanks both,\nChristian.\n"},{"id":"265809","messageId":"559CCFBE.9000702@drmicha.warpmail.net","threadId":"39780","inReplyTo":"CAPig+cRv6g_nAEdGtrESFiE+5+OxEHwjhEPX0Q0WL+eHzkCAGA@mail.gmail.com","subject":"Re: Draft of Git Rev News edition 5","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2015-07-08T07:22:38Z","receivedAt":"2015-07-08T07:22:38Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Eric Sunshine venit, vidit, dixit 06.07.2015 01:12:\n> On Sun, Jul 5, 2015 at 6:35 PM, Thomas Ferris Nicolaisen\n> wrote:\n>> On Mon, Jul 6, 2015 at 12:01 AM, Eric Sunshine wrote:\n>>> Unfortunately, the non-ASCII characters\n>>> in Duy's name got corrupted, and the botch is present in the patch I\n>>> sent. Sorry. Not sure how that happened. Can you fix it locally?\n>>\n>> Fixed [1].\n>>\n>> [1] https://github.com/git/git.github.io/commit/b5f7d6523ca6a634d568fc9017135ff2a9ea6462\n> \n> Thanks.\n> \n\nMaybe a matter of taste, but I think in general we could do with a bit\nless of \"narrating\" and more of \"summarizing\".\n\nJust as an example, in the section on \"visualizing merge diffs after the\nfact\", few people will be interested in the detail that I pointed out\nthe \"--merges\" option of rev-list to Dscho. While that recollection is\ntrue and everything on the git-ml is public, I consider \"Git Rev News\"\nto be \"more public\", targetted to a wider audience than the regulars.\nThey don't all know how much Git owes to Dscho. If things like this end\nup in the news it makes me ponder for each on-list reply whether I'd\nrather reply in private. Maybe I'm being overly sensitive (though not\naffected in this case), but I just feel there are different degrees of\n\"public\".\n\nThe pattern \"...led to a discussion [between...] that resulted in...\"\nthat we have in other places seems to be a good guideline.\n\nMichael\n"},{"id":"265815","messageId":"xmqqegkjyu0b.fsf@gitster.dls.corp.google.com","threadId":"39780","inReplyTo":"559CCFBE.9000702@drmicha.warpmail.net","subject":"Re: Draft of Git Rev News edition 5","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-07-08T07:43:16Z","receivedAt":"2015-07-08T07:43:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber writes:\n\n> Maybe a matter of taste, but I think in general we could do with a bit\n> less of \"narrating\" and more of \"summarizing\".\n\nTrue.\n\n> Just as an example, in the section on \"visualizing merge diffs after the\n> fact\", few people will be interested in the detail that I pointed out\n> the \"--merges\" option of rev-list to Dscho. While that recollection is\n> true and everything on the git-ml is public, I consider \"Git Rev News\"\n> to be \"more public\", targetted to a wider audience than the regulars.\n> They don't all know how much Git owes to Dscho. If things like this end\n> up in the news it makes me ponder for each on-list reply whether I'd\n> rather reply in private. Maybe I'm being overly sensitive (though not\n> affected in this case), but I just feel there are different degrees of\n> \"public\".\n\nI do not see \"Michael pointed out that there was a slightly better\nway to do that\" as saying anything bad about his contribution.\n\nI however do agree with you that we want to see the newsletter aim\nto summarize things better. Instead of saying \"Dscho suggested X,\nMichael then refined it to Y\", with full details of what X and Y\nlooked like, it would be more appropriate for the target audience to\nsay \"Dscho and Michael worked together to come up with a solution\nY\".\n"},{"id":"265824","messageId":"CAP8UFD1=KxcYyFfFZ++5Vty-KMv-ci8dtdo4bfX7oj_wgLOE7g@mail.gmail.com","threadId":"39780","inReplyTo":"xmqqegkjyu0b.fsf@gitster.dls.corp.google.com","subject":"Re: Draft of Git Rev News edition 5","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2015-07-08T10:29:34Z","receivedAt":"2015-07-08T10:29:34Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Wed, Jul 8, 2015 at 9:43 AM, Junio C Hamano wrote:\n> Michael J Gruber writes:\n>\n>> Maybe a matter of taste, but I think in general we could do with a bit\n>> less of \"narrating\" and more of \"summarizing\".\n>\n> True.\n\nI think sometimes the details might be interesting for different reasons.\n\n>> Just as an example, in the section on \"visualizing merge diffs after the\n>> fact\", few people will be interested in the detail that I pointed out\n>> the \"--merges\" option of rev-list to Dscho. While that recollection is\n>> true and everything on the git-ml is public, I consider \"Git Rev News\"\n>> to be \"more public\", targetted to a wider audience than the regulars.\n>> They don't all know how much Git owes to Dscho. If things like this end\n>> up in the news it makes me ponder for each on-list reply whether I'd\n>> rather reply in private. Maybe I'm being overly sensitive (though not\n>> affected in this case), but I just feel there are different degrees of\n>> \"public\".\n>\n> I do not see \"Michael pointed out that there was a slightly better\n> way to do that\" as saying anything bad about his contribution.\n\nOn the contrary I think that the way Dscho used sed shows some cli\nproficiency and might be interesting to some people.\n\n> I however do agree with you that we want to see the newsletter aim\n> to summarize things better. Instead of saying \"Dscho suggested X,\n> Michael then refined it to Y\", with full details of what X and Y\n> looked like, it would be more appropriate for the target audience to\n> say \"Dscho and Michael worked together to come up with a solution\n> Y\".\n\nWith the details, I think readers are more likely to remember the\n--merges option.\n"},{"id":"265848","messageId":"96e72d94244ef3d2b7ecdfdb83fdbafd@www.dscho.org","threadId":"39780","inReplyTo":"CAP8UFD1=KxcYyFfFZ++5Vty-KMv-ci8dtdo4bfX7oj_wgLOE7g@mail.gmail.com","subject":"Re: Draft of Git Rev News edition 5","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2015-07-08T13:02:29Z","receivedAt":"2015-07-08T13:02:29Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn 2015-07-08 12:29, Christian Couder wrote:\n> On Wed, Jul 8, 2015 at 9:43 AM, Junio C Hamano wrote:\n>> Michael J Gruber writes:\n>>\n>>> Just as an example, in the section on \"visualizing merge diffs after the\n>>> fact\", few people will be interested in the detail that I pointed out\n>>> the \"--merges\" option of rev-list to Dscho. While that recollection is\n>>> true and everything on the git-ml is public, I consider \"Git Rev News\"\n>>> to be \"more public\", targetted to a wider audience than the regulars.\n>>> They don't all know how much Git owes to Dscho. If things like this end\n>>> up in the news it makes me ponder for each on-list reply whether I'd\n>>> rather reply in private. Maybe I'm being overly sensitive (though not\n>>> affected in this case), but I just feel there are different degrees of\n>>> \"public\".\n>>\n>> I do not see \"Michael pointed out that there was a slightly better\n>> way to do that\" as saying anything bad about his contribution.\n> \n> On the contrary I think that the way Dscho used sed shows some cli\n> proficiency and might be interesting to some people.\n\nJust for the record: I was really happy to learn about the --merges option. Also: I have not the faintest problem to demonstrate lack of knowledge publicly. It was kind of flattering to hear that my contributions to Git are appreciated, though ;-)\n\n>> I however do agree with you that we want to see the newsletter aim\n>> to summarize things better. Instead of saying \"Dscho suggested X,\n>> Michael then refined it to Y\", with full details of what X and Y\n>> looked like, it would be more appropriate for the target audience to\n>> say \"Dscho and Michael worked together to come up with a solution\n>> Y\".\n> \n> With the details, I think readers are more likely to remember the\n> --merges option.\n\nYep, people remember things better when there is some story behind that they can relate to.\n\nCiao,\nDscho\n"},{"id":"265860","messageId":"xmqqio9uy2ja.fsf@gitster.dls.corp.google.com","threadId":"39780","inReplyTo":"CAP8UFD1=KxcYyFfFZ++5Vty-KMv-ci8dtdo4bfX7oj_wgLOE7g@mail.gmail.com","subject":"Re: Draft of Git Rev News edition 5","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-07-08T17:36:41Z","receivedAt":"2015-07-08T17:36:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Christian Couder writes:\n>\n> I think sometimes the details might be interesting for different reasons.\n> ...\n> With the details, I think readers are more likely to remember the\n> --merges option.\n\nThat unfortunately cuts both ways.\n\nWith too much details, the readers are more likely to skim and skip\nthe \"--merges\" buried in reams of text. Only the ones who carefully\nread from cover to cover would discover and contrast the first\niteration \"sed\" with the second iteration \"--merges\", but I'd expect\nthat they would also be the ones who carefully read the docs and\nmore likely to know about \"--merges\" without Rev News teaching them.\n\nUsed sparingly, the details do pull interested readers in. The key\nword in your message was \"sometimes\", I think.\n"}]}