Any comment about upcoming Git Rev News edition 33

[chriscool]

A currently mostly empty draft is there:

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

Feel free to comment in this issue, or to use the edit button (that looks like a pen) to edit and create a pull request with the changes you would like.

Thanks!

cc @tfnico @jnareb @mjaix @gitster @stefanbeller

[jreybert]

Hi, self-promotion proposition.

You talked several times about the emacs magit plugin, you may want to take a look to its little brother vim plugin vimagit.

It is not as complete as magit, it focuses for the moment to the stage/commit workflow (I intend to add checkout, stash, fixup support in the next year). And for the record, it does not aim to replace fugitive for what it does very well: Ggrep, Gblame, Gedit...

[chriscool]

@jreybert thanks for the suggestion! We will add something about vimagit in this edition.

[dscho]

@jreybert you could always open a Pull Request ;-) That's what I do when I have to self-promote some of my work... 😜

[chriscool]

Let's publish this edition on Wednesday 22nd November!

[chriscool]

@jreybert vimagit added in 4f23651

[tfnico]

My links have landed!

[jreybert]

Thanks @chriscool

[jnareb]

Do you know when Git for Windows acquired automatic checking for update? If it was in October it would be worth mentioning it in Git Rev News (and even if it was earlier, if there is some blog post about this new feature).

[jrn]

https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-33.md#support says 'A discussion then started about the merits of having an entry like "*.sh text eol=lf" in the .gitattributes for shell scripts, compared to having Git change strictly no file. It appeared that there is no clear answer about what is best', which makes it sound like the discussion didn't come to any conclusion. But https://public-inbox.org/git/f56a02d6-fbf9-188f-d19f-3d48708d9268@kdbg.org/ looks like a clear conclusion to me.

More generally, I am wondering about the audience for this summary of a support thread. The summary seems to recap each individual message --- maybe there is a way to make it more concise.

[chriscool]

@jrn I was under the impression that https://public-inbox.org/git/alpine.DEB.2.21.1.1710271716330.6482@virtualbox/ could be a different conclusion of the discussion.

My goal with these articles is not to summarize as much as possible, but to tell a story that will hopefully at once do some of the following:

• interest people,
• make them learn something about Git,
• highlight the work by reviewers, user helpers and developers.

[jrn]

@jrn I was under the impression that https://public-inbox.org/git/alpine.DEB.2.21.1.1710271716330.6482@virtualbox/ could be a different conclusion of the discussion.

Hm, care to elaborate (preferably in that thread :))?

[chriscool]

Well Dscho points to an example where setting "*.sh text eol=lf" fails to do anything useful in some cases. So I think it shows that the above settings might not be useful in some cases.

[jrn]

That sounds like a "no, you are not interested in replying there".

shrug

[chriscool]

After thinking about it perhaps the changes in #265 would be good.

And yeah, I am not interested in replying in the thread, because my current goal is not to try to make people change their opinion about what is best, but just to summarize as well as possible the conclusion of the mailing list thread in the Git Rev News article.

[jnareb]

My links have landed in 2bcdaa4

[mjaix]

Fixed some tiny typos and wordings, and hopefully improved the quoting in a better way than last time :-).

[mjaix]

BTW, just forgot one issue - I am not 100% sure what Torsten wants to express with his Gerrit statement (is the "if" misplaced?). Please check/correct.

[chriscool]

@jnareb, you should probably ask @dscho about when Git for Windows acquired automatic checking for update.

[chriscool]

Thanks @tfnico, @jnareb and @mjaix for the links and fixes.
@mjaix Torsten's Gerrit related statement looks ok to me, so I left it as is.

[dscho]

Do you know when Git for Windows acquired automatic checking for update?

Yes I do: v2.14.2 (Sep 26th, see https://github.com/git-for-windows/build-extra/blob/master/ReleaseNotes.md#changes-since-git-for-windows-v2141-august-10th-2017).

Please note that it is an opt-in feature for now, although we may soon switch it to opt-out instead. I'd like the feature to be tested a bit more, though.