Repository navigation
Any comment about upcoming Git Rev News edition 69 #463
Description
Activity
@chriscool When do we plan to publish this edition? November 18th or November 25th? 🤔
@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!
Reacted by Kaartic SivaraamI 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
"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.
@PhilipOakley thanks! It was also on Hacker News.
I have added my links in 66b6960 - it includes links to "Git is too Hard" blog/podcast mentioned by @PhilipOakley .
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.
- Hi, I tried to understand why https://git.github.io/rev_news/2020/08/27/edition-66/, https://git.github.io/rev_news/2020/10/30/edition-68/, and the actual Rev News have a formatting which results in a very slim left menu colomn. Failed :-( ... hints are appreciated. @chriscool: do you still plan to publish edition 69 tomorrow? cc @jnareb @sivaraam
- I had similar experiences when trying to enrich/augment IBM web pages with Ericsson/IBM internal information some years ago for an intranet page ... after having had a look at the present GitLab release page, I got some idea of your trouble. Did you succeed in the end?
- Supplied some tiny fixes in 33601bf.
@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.
@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.
Draft sent: https://lore.kernel.org/git/CAP8UFD10RsOi8_gdg-ZbcrN2HHaPyia096svnjmCu_U70LU_8g@mail.gmail.com/
Publication date changed to Friday Nov 27th.
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.
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.
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.
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.
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.
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 NewsI 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? 🤔- Added some more tiny fixes in f210744, whithout changing the contents. Also stumbled across the double nbrev mention - maybe that info should be merged in one of the places.
@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.
Published and announced in https://lore.kernel.org/git/CAP8UFD0xoqVh=1BweBqNOt4_9xg4GvDd7Jf5f5_5z4H+PCVt8g@mail.gmail.com/.
This should be closed. No?
This should be closed. No?
I usually wait for a few weeks before closing, as sometimes people have remarks about an edition that was just published.
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!
cc @jnareb @mjaix @sivaraam @gitster