Looking forward to Git 2.56 - and 3.0

70 points by dimonomid 16 hours ago on lobsters | 9 comments

jbauer | 14 hours ago

There is some solid snark in this article 😄

Unfortunately, it still refuses to work if the history contains merge commits, making it unusable for many (or most) repositories.

It still, though, will say that a branch is "up to date" even if it lags behind an (unfetched) remote tracking branch.

Those commands, create, delete, update, and rename, perhaps surprisingly for Git, do exactly what their names suggest they would.

BenjaminRi | 10 hours ago

If you've been a long-time LWN reader, you get to know Jonathan Corbet's style. I really love his dry humor which is often expressed by simply stating plain facts in a certain arrangement. He is an excellent writer and the main reason why I support LWN.

intelfx | 56 minutes ago

And the deadpan puns. So many puns. Never change, Jon.

It still, though, will say that a branch is "up to date" even if it lags behind an (unfetched) remote tracking branch.

I was just talking to some folks at the Git conference about this issue this week. I've been doing a bunch of work on Git's documentation and I've learned a lot about how contributing to Git works. If you're a C programmer who would be interested in working on this (or on other issues related to improving Git's usability!), I'd be happy to talk (via email) about my experiences working with the Git community. I've found the official Git discord (linked at https://git-scm.com/community#discord) to be a pretty friendly place where the existing Git contributors are very wiling to help new contributors.

I don't think that this particular issue would be trivial to fix but it might be possible and I think it could help a lot of people.

hugoarnal | 15 hours ago

There are a number of minor usability tweaks. The new --delete-merged option to git branch will remove local branches that have been merged into their remote tracking branches.

Ooh! Maybe this can finally replace the prune-branches "hack"

Halkcyon | 9 hours ago

Unfortunately, it still refuses to work if the history contains merge commits, making it unusable for many (or most) repositories.

Ugh. The bane of all projects. That one guy who won't learn how rebase works

recursive | 6 hours ago

I learned it, but I just prefer merge.

cadey | 8 hours ago

I have just had rebase->merge ripped away from me at work because if you do that to a claudebot/explicitly vibeslopped PR it won't autodeploy with ${MEME_PLATFORM}.

Is this (the SHA change) going to be the new Python 2 vs. 3 saga?