Any comment about upcoming Git Rev News edition 64

[chriscool]

A currently mostly empty draft is there:

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

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

Let's try to publish this edition on Wednesday June 24th 2020!

Thanks!

cc @jnareb @mjaix @sivaraam @gitster

[jnareb]

There are a lot of articles and some discussion on git mailing list about renaming / replacing the "master" branch as the default.

[chriscool]

@jnareb yeah, I've read some of that. I am not sure I could do a good job of writing a summary for all of that. It seems too much and too heated at times. I will see.

[newren]

Your article reminded me that I needed to send out a release email for filter-repo 2.27.1, which I just did. Can you link it too (https://lore.kernel.org/git/CABPp-BFo=SRkMezdD_FvM92-bgdeBzfExpjtjYiEvg0UM1rWQQ@mail.gmail.com/)?

[chriscool]

@newren added in 5a71a38

[newren]

@jnareb yeah, I've read some of that. I am not sure I could do a good job of writing a summary for all of that. It seems too much and too heated at times. I will see.

You could link or quote the Git PLC announcement you sent out instead. There might be some value in summarizing the threads, but it'd be easy to trip up and have things go sideways, while the Git PLC announcement was very well crafted.

Anyway, just an idea.

[chriscool]

@newren already done in 786eed7

[jnareb]

I have added my links in 22f8f92 and 0f5b8d9

[mjaix]

Supplied my usual tiny formatting fixes, plus one speculation regarding core.RepositoryFormatVersion in 42effee. As usual, feel free to correct / revert / whatever.

[sivaraam]

I noticed a minor thing and tweaked it in 8ed9f16
I'm a bit unsure if that's the right change, though. So, it would be nice if someone could confirm.

[chriscool]

@sivaraam I think it's indeed the right change. Thanks!

[mjaix]

IMHO the question is whether the tool "is being supported", that is under support, for a given set of languages,or if it is just "supporting" those languages, that is understanding their syntax/semantics.

On Thu, 2020-06-25 at 04:46 -0700, Christian Couder wrote: @sivaraam I think it's indeed the right change. Thanks! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

-- Dipl.-Ing. Markus Jansen Alte Vaalser Str. 40a Mob. +49 172 2742003 52074 Aachen/Aix-la-chapelle/Aken/Oche Tel. +49 241 5592439 Deutschland/Allemagne/Germany/Duitsland/Tyskland Fax +49 241 5592441 mja@jansen-preisler.de

[sivaraam]

IMHO the question is whether the tool "is being supported", that is under support, for a given set of languages,or if it is just "supporting" those languages, that is understanding their syntax/semantics.

Yeah, that does make sense. Semantics is something I would've to get better at :)

I've tried to address this in bdc5067. Let me know if that sounds better.

[chriscool]

Yeah, thanks @sivaraam!

[Cogito]

Apologies I didn't review the draft, but just saw the published rev news and had a small bit of feedback.

In this line: https://github.com/git/git.github.io/blame/master/_posts/2020-06-25-edition-64.markdown#L173

@jnareb wrote:

note that while BitKeeper used master/slave terminology for repositories, 'master' branch in Git is about being 'master copy'

I agree with the sentiment about Git, however, based on the research I've done, using master/slave terminology in BitKeeper was the exception not the rule.

That research is summarised in this post to the mailing group: https://lore.kernel.org/git/20200616190342.GC27441@legohost/T/#m9589009ba3b6663ca38c2ef19c18c933e46c253a

If BitKeeper deserves to be mentioned I would suggest something like the following instead of that line:

note that while examples exist where master/slave terminology was used to refer to repositories in BitKeeper, the 'master' branch in Git is a 'master copy'

or even something like:

note that the 'master' in the Git's default 'master branch' derives from 'master copy'

Overall this is a small thing, but I find the claim that master/slave terminology was used in BitKeeper to be unsupported by either the BitKeeper source code or by people who used it at the time (the few I've seen comment on twitter etc)

[jnareb]

@Cogito - thanks for your thoughts. You are right.

I should have checked the claims in linked article mentioned text was a comment to.

[chriscool]

@Cogito and @jnareb I also think https://twitter.com/xpasky/status/1271477451756056577 is very relevant.

[chriscool]

This edition was published and announced in:

https://lore.kernel.org/git/CAP8UFD3vfShPWQzhj28sTfXORzR-k5sJSmeenZf-G7uBMBM6=w@mail.gmail.com/

[Cogito]

@chriscool what are your thoughts on updating the published edition to reflect the above discussion?

[chriscool]

We will very likely talk about this issue in edition 65 again, so I think it would be better to write something for the new edition. You could write an article in edition 65 for example or a blog post somewhere else that we could link to in edition 65. The article or blog post can be short and maybe just link to relevant material elsewhere.

In edition 65 we should mention https://www.wired.com/story/tech-confronts-use-labels-master-slave/ as the Git PLC is mentioned. (The Git PLC was interviewed by email after the journalist contacted me.)