{{ message }}
Repository navigation
Any comment about upcoming Git Rev News edition 69 #463
Description
A currently mostly empty draft is there:
https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-69.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 November 25th 2020!
Thanks!
Activity
sivaraam commentedon Nov 11, 2020
@chriscool When do we plan to publish this edition? November 18th or November 25th? 🤔
chriscool commentedon Nov 11, 2020
@sivaraam I meant November 25th as written in https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-69.md but I had forgotten to update the comment when I copy pasted it from the previous issue. It's fixed now. Thanks!
jnareb commentedon Nov 14, 2020
I think it might be good idea to add a short note about planned deprecation and later removal of old
.git/branches/and.git/remotes/way of specifying remote repositories.See https://public-inbox.org/git/cover.1494509599.git.johannes.schindelin@gmx.de/t/#u
chriscool commentedon Nov 15, 2020
@jnareb yeah, let's do that!
PhilipOakley commentedon Nov 18, 2020
"Git is too Hard"
An interesting blog/podcast about the Git CLI, for those who work inside the terminal https://changelog.com/posts/git-is-simply-too-hard
This was in the CodeProject's daily news so may have some visibility.
chriscool commentedon Nov 18, 2020
@PhilipOakley thanks! It was also on Hacker News.
jnareb commentedon Nov 24, 2020
I have added my links in 66b6960 - it includes links to "Git is too Hard" blog/podcast mentioned by @PhilipOakley .
chriscool commentedon Nov 24, 2020
Sorry I am very late. The script to automatically get the release information from many places broke for GitLab as they changed the format of their "releases" page and it is not so easy to fix.
mjaix commentedon Nov 24, 2020
mjaix commentedon Nov 24, 2020
mjaix commentedon Nov 24, 2020
chriscool commentedon Nov 25, 2020
@mjaix yeah, I don't understand either why https://git.github.io/rev_news/2020/08/27/edition-66/ and https://git.github.io/rev_news/2020/10/30/edition-68/ have a formatting which results in a very slim left menu column while https://git.github.io/rev_news/2020/09/24/edition-67/ looks ok.
Now I hope to publish edition 69 on Friday and to send a draft today.
jnareb commentedon Nov 25, 2020
@chriscool , @mjaix : If I understand it correctly, 66 and 68 edition has a very slim left menu column because the contents column is exceedingly wide due to overly long line in the code block. The menu column starts in the same place, it is just that it has less place because content column crowds it.
I wonder if it would be possible in CSS to make the left margin slimmer instead of the menu column when contents column gets wide.
chriscool commentedon Nov 25, 2020
Draft sent: https://lore.kernel.org/git/CAP8UFD10RsOi8_gdg-ZbcrN2HHaPyia096svnjmCu_U70LU_8g@mail.gmail.com/
Publication date changed to Friday Nov 27th.
chriscool commentedon Nov 25, 2020
Thanks @sivaraam for the interview, @jnareb for the links and @mjaix for the fixes!
@jnareb thanks for finding the issue with the very slim left menu column. I think we should split overly long lines code blocks to avoid that, but I am also ok with making the left margin slimmer in CSS.
sivaraam commentedon Nov 25, 2020
That's my understanding too. I've observed this several times before and have been wanting to create an issue about this but never got around to it.
Another way to fix this would be to ensure code blocks always take up a fixed width rather than taking up as much width as it wants. I'm thinking of something similar to how code blocks in GitHub issue comments wrap withing the comment box. If that could be achieved, we wouldn't have to worry about how long the code block is.
felipec commentedon Nov 25, 2020
Shouldn't the report about git pull warning and the subsequent patch series trying to improve the situation be worthwhile to mention?
This BTW revives the old discussion, so it's interesting something that wasn't fixed in 2014 is still biting us today.
PhilipOakley commentedon Nov 25, 2020
Another thought for potential inclusions (given the
git pullcomment) could the the new and changedconfigvariables (documentation & code) that have graduated tonext/mainso that these new / changed features and defaults become known. Probably something that can be deferred to the next Git Rev Newssivaraam commentedon Nov 26, 2020
I just noticed that both the "Light reading" and "Git tools and sites" have an entry with a short paragraph that talk about
nbdev. I wonder if they're a bit redundant.Should we only mention the article in "Light reading" and talk about
nbdevin "Git tools and sites"? Or are they fine as it is? 🤔mjaix commentedon Nov 26, 2020
chriscool commentedon Nov 26, 2020
I agree that nbdev mentions should be merged in one place. @jnareb as you added the mentions, can you do that, or do you want me to do it?
chriscool commentedon Nov 26, 2020
@felipec and @PhilipOakley thanks for the suggestions! I will add them to the issue for the next edition, as it's too late to add them in this edition anyway and the discussions may not be finished. I will see what I can do next month. Feel free to start an article or a short news about them in the meantime.
chriscool commentedon Nov 27, 2020
Published and announced in https://lore.kernel.org/git/CAP8UFD0xoqVh=1BweBqNOt4_9xg4GvDd7Jf5f5_5z4H+PCVt8g@mail.gmail.com/.
felipec commentedon Dec 1, 2020
This should be closed. No?
felipec commentedon Dec 2, 2020
Yes. It is conceptually different, but I explain how in the pull request #471.
It ends up looking like this.
chriscool commentedon Dec 2, 2020
I usually wait for a few weeks before closing, as sometimes people have remarks about an edition that was just published.