Any comment about upcoming Git Rev News edition 13

[chriscool]

A currently mostly empty draft is there:

https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-13.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 @durdn @gitster

[chriscool]

Let's try to publish this edition on Wednesday March 16.

[chriscool]

If people have ideas about some threads worth talking about, they would be very welcome!
Thinking about it, in the short news it's probably worth mentioning the GSoC and maybe also Outreachy.

[tfnico]

My links are all in now.

[gitster]

Here are some random comments:

• "well known" twice in a row felt a bit boring; perhaps turn one of them into "widely known"?
• It probably is better to tone down "important" in "important Git developers and reviewers" a bit. "active", "regular", etc. perhaps?
• It probably is worth mentioning that the "bundle" based offloading of the clone traffic is not just "often suggested", but is provided for the Linus's repository at k.org, i.e. already deployed. It also is worth mentioning that the "repo" tool that is used by AOSP uses the technique to offload the clone traffic from the core network, and it has long been the wish of "repo" folks for Git to natively support something like it.
• I do not think "And for some time this was ... Over time though Git developers realized" is an accurate depiction. It was known to be a hard problem to solve it cleanly and efficiently from the beginning, and the people who added the GSoC idea entry were simply misguided (basically, I do not want the paragraph sounding as if these misguided people are representative sample of "Git developers" who realized their mistake).
• I am not sure how detailed (in depth) and wide (in scope) you guys want to make the "resumable clone" topic, but if you were aiming for depth, one development missing in the time series is between the RFC by Shawn and an independent thread by Josh, there were a few patches around "split bundle" that advanced Shawn's RFC.
• I think "potential security issue called out" is a bit of sensationalism. A more accurate phrasing would be "X reminded that the implementation has to keep in mind that it would introduce potential security issue if Y is done carelessly".
• As this topic is in its early stage, it would be beneficial for this article to widen its scope. It is true that Shawn's RFC is the preferred "resumable CLONE", and it can easily extend to the already deployed "bundle" based priming the article alludes to in its early part (which by the way should be mentioned).
  But that does not mean Al Viro's approach mentioned in Josh's thread has been discarded (which is the impression the article gives). It will be more work, but the optimization possible via the approach is much better suited for subsequent incremental fetches, which can materialize in some future independently from resumable clone topic; it is much more suitable than Duy's PoC approach.

There were a few more interesting topics that were reviewed and discussed in the month the issue covers that may be worth mentioning.

• Duy's "more flexibility in making shallow clones" series
• Dan Aloni's "ident" series
• Stefan's "parallelism in git submodule" series
• The ".gitignore" regression before 2.7.2 and before 2.8.0-rc series.

Sorry for not being in a patch form due to lack of time.

[chriscool]

@gitster thanks for the comments and suggestions. I will see what I can do about them soon.

[chriscool]

@gitster Hopefully most of your comments related to the resumable clone article are taken into account in 6bb57ec

[chriscool]

Edition 13 has been published and its source is now available on https://github.com/git/git.github.io/blob/master/_posts/2016-03-16-edition-13.markdown.