Draft of Git Rev News edition 33

Draft of Git Rev News edition 33

[Christian Couder]

Hi,

A draft of a new Git Rev News edition is available here:

  https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-33.md

Everyone is welcome to contribute in any section either by editing the
above page on GitHub and sending a pull request, or by commenting on
this GitHub issue:

  https://github.com/git/git.github.io/issues/262

You can also reply to this email.

In general all kinds of contribution, for example proofreading,
suggestions for articles or links, help on the issues in GitHub, and
so on, are very much appreciated.

I tried to cc everyone who appears in this edition, but maybe I missed
some people, sorry about that.

Thomas, Jakub, Markus and myself plan to publish this edition on
Wednesday November 22nd.

Thanks,
Christian.

Re: Draft of Git Rev News edition 33

[Yubin Ruan]

2017-11-20 16:33 GMT+08:00 Christian Couder <christian.couder@gmail.com>:
> Hi,
>
> A draft of a new Git Rev News edition is available here:
>
>   https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-33.md
>
> Everyone is welcome to contribute in any section either by editing the
> above page on GitHub and sending a pull request, or by commenting on
> this GitHub issue:
>
>   https://github.com/git/git.github.io/issues/262
>
> You can also reply to this email.
>
> In general all kinds of contribution, for example proofreading,
> suggestions for articles or links, help on the issues in GitHub, and
> so on, are very much appreciated.
>
> I tried to cc everyone who appears in this edition, but maybe I missed
> some people, sorry about that.
>
> Thomas, Jakub, Markus and myself plan to publish this edition on
> Wednesday November 22nd.

Nice post.

For the CRLF issue: I am not really that concerned with this issue
because I mostly develop all my project on Linux. But can't git treat
CRLF and LF just as the same thing? That will solves the problem
gracefully.

Yubin

Re: Draft of Git Rev News edition 33

[Jonathan Nieder]

Hi,

Yubin Ruan wrote:
> 2017-11-20 16:33 GMT+08:00 Christian Couder <christian.couder@gmail.com>:

>> A draft of a new Git Rev News edition is available here:
>>
>>   https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-33.md
>>
>> Everyone is welcome to contribute in any section either by editing the
>> above page on GitHub and sending a pull request, or by commenting on
>> this GitHub issue:
>>
>>   https://github.com/git/git.github.io/issues/262
>>
>> You can also reply to this email.
[...]
> For the CRLF issue: I am not really that concerned with this issue
> because I mostly develop all my project on Linux. But can't git treat
> CRLF and LF just as the same thing? That will solves the problem
> gracefully.

Do you mean that it should ignore line ending changes?  What line
endings should a user get when they "git clone" or "git checkout"?

That said, I believe that the gitattributes(5) manpage does an okay
job of covering this and that that thread came to a clear conclusion:

  https://public-inbox.org/git/20171026203046.fu3z5ngnw7hckfrn@aiede.mtv.corp.google.com/

I commented at [1] that I found the conclusion of the rev news entry
misleading and confusing but it doesn't appear that there is anything
I can do about that.  It's disappointing because if there is something
that was not covered in that thread, then it would be good to revive
it so we can improve the program's behavior or docs, but I wasn't able
to find out what was missed.

Thanks,
Jonathan

[1] https://github.com/git/git.github.io/issues/262#issuecomment-345804038

Re: Draft of Git Rev News edition 33

[Christian Couder]

On Tue, Nov 21, 2017 at 2:10 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>
> That said, I believe that the gitattributes(5) manpage does an okay
> job of covering this and that that thread came to a clear conclusion:
>
>   https://public-inbox.org/git/20171026203046.fu3z5ngnw7hckfrn@aiede.mtv.corp.google.com/
>
> I commented at [1] that I found the conclusion of the rev news entry
> misleading and confusing but it doesn't appear that there is anything
> I can do about that.

Well, you could have provided a pull request or otherwise suggested
what you think would be a better conclusion for the article and why.

If you just say that the above email is the conclusion, when it seems
to me that another email from someone else is also a conclusion with a
quite different outcome, it does not help much come to an agreement
about what should be reported as the conclusion of the thread.

> It's disappointing because if there is something
> that was not covered in that thread, then it would be good to revive
> it so we can improve the program's behavior or docs, but I wasn't able
> to find out what was missed.

Perhaps nothing was missed, but as the issue is complex, it is just
difficult to explain and summarize it in a good way.

Re: Draft of Git Rev News edition 33

[Junio C Hamano]

Christian Couder <christian.couder@gmail.com> writes:

> On Tue, Nov 21, 2017 at 2:10 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>>
>> That said, I believe that the gitattributes(5) manpage does an okay
>> job of covering this and that that thread came to a clear conclusion:
>>
>>   https://public-inbox.org/git/20171026203046.fu3z5ngnw7hckfrn@aiede.mtv.corp.google.com/
>>
>> I commented at [1] that I found the conclusion of the rev news entry
>> misleading and confusing but it doesn't appear that there is anything
>> I can do about that.
>
> Well, you could have provided a pull request or otherwise suggested
> what you think would be a better conclusion for the article and why.

I just re-read the sub-thread Jonathan pointed at, and to me it does
look like the original request was adequately addressed and talk has
concluded at around that article.

I somehow was hoping that Jonathan's citing the above URL is a
suggestion enough for the editors, especially given that the
announcement for the draft invites a reply to this thread.

> Perhaps nothing was missed, but as the issue is complex, it is just
> difficult to explain and summarize it in a good way.

Perhaps you want to take a bit more time between a draft to the
final publication?  I've often wondered if the time between a draft
announcement and the release is too short for those who understand
the discussions on the list well enough to give useful input to help
editors regurgitate the issues to arrive at a clear summary article.

Re: Draft of Git Rev News edition 33

[Christian Couder]

On Tue, Nov 21, 2017 at 2:12 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Christian Couder <christian.couder@gmail.com> writes:
>
>> On Tue, Nov 21, 2017 at 2:10 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>>>
>>> That said, I believe that the gitattributes(5) manpage does an okay
>>> job of covering this and that that thread came to a clear conclusion:
>>>
>>>   https://public-inbox.org/git/20171026203046.fu3z5ngnw7hckfrn@aiede.mtv.corp.google.com/
>>>
>>> I commented at [1] that I found the conclusion of the rev news entry
>>> misleading and confusing but it doesn't appear that there is anything
>>> I can do about that.
>>
>> Well, you could have provided a pull request or otherwise suggested
>> what you think would be a better conclusion for the article and why.
>
> I just re-read the sub-thread Jonathan pointed at, and to me it does
> look like the original request was adequately addressed and talk has
> concluded at around that article.
>
> I somehow was hoping that Jonathan's citing the above URL is a
> suggestion enough for the editors, especially given that the
> announcement for the draft invites a reply to this thread.

DId you also read https://github.com/git/git.github.io/issues/262?

I think I have tried to properly answer Jonathan's feedback there too.
Especially I wrote a pull request with a different conclusion
(https://github.com/git/git.github.io/pull/265) and asked Jonathan if
that was better, but so far got no answer.

>> Perhaps nothing was missed, but as the issue is complex, it is just
>> difficult to explain and summarize it in a good way.
>
> Perhaps you want to take a bit more time between a draft to the
> final publication?  I've often wondered if the time between a draft
> announcement and the release is too short for those who understand
> the discussions on the list well enough to give useful input to help
> editors regurgitate the issues to arrive at a clear summary article.

If it would take a really long time for "those who understand the
discussions on the list well enough to give useful input", can you
imagine how long it would take to write articles in the first place?

I try to write the articles in less than 2 days, so I think 2 days
should also be enough for people to provide useful input on the
articles.
Also I have tried at times to give one more day for people to provide
feedback (or more content) following you suggestion. But when I did
that, I have seen no change in the amount of feedback (or content)
provided.

Re: Draft of Git Rev News edition 33

[Junio C Hamano]

Christian Couder <christian.couder@gmail.com> writes:

> On Tue, Nov 21, 2017 at 2:12 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> I just re-read the sub-thread Jonathan pointed at, and to me it does
>> look like the original request was adequately addressed and talk has
>> concluded at around that article.
>>
>> I somehow was hoping that Jonathan's citing the above URL is a
>> suggestion enough for the editors, especially given that the
>> announcement for the draft invites a reply to this thread.
>
> DId you also read https://github.com/git/git.github.io/issues/262?

No, but I just did.  I didn't know the purpose of the Rev News
changed over time from helping those who do not have time to follow
the list by highlighting useful discussions and giving them concise
summary to just quoting pieces from messages in interesting
discussions and have the readers draw their own conclusions (or lack
thereof).

Re: Draft of Git Rev News edition 33

[Jonathan Nieder]

Hi,

Christian Couder wrote:
> On Tue, Nov 21, 2017 at 2:10 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:

>> That said, I believe that the gitattributes(5) manpage does an okay
>> job of covering this and that that thread came to a clear conclusion:
>>
>>   https://public-inbox.org/git/20171026203046.fu3z5ngnw7hckfrn@aiede.mtv.corp.google.com/
>>
>> I commented at [1] that I found the conclusion of the rev news entry
>> misleading and confusing but it doesn't appear that there is anything
>> I can do about that.
>
> Well, you could have provided a pull request or otherwise suggested
> what you think would be a better conclusion for the article and why.
>
> If you just say that the above email is the conclusion, when it seems
> to me that another email from someone else is also a conclusion with a
> quite different outcome, it does not help much come to an agreement
> about what should be reported as the conclusion of the thread.

This is something I suspect journalists have to deal with all the
time: when one of the subjects of an article feels misrepresented
(which happens inevitably when writing to a deadline), that comes with
a feeling of powerlessness that can lead to grumpiness and harsh
words.

In the end you ended up improving the text enough that I don't mind
any more.  Sorry for the bumpy road along the way.

Thanks,
Jonathan