Highlights from Git 2.25(github.blog)
github.blog
Highlights from Git 2.25
https://github.blog/2020-01-13-highlights-from-git-2-25/
25 comments
> I’ve never run across another piece of software that talked about itself this way.
Whoever writes the CMake changelog does this constantly.
https://cmake.org/cmake/help/v3.14/release/3.14.html#command...
I agree, it is a very awkward way of writing.
Whoever writes the CMake changelog does this constantly.
https://cmake.org/cmake/help/v3.14/release/3.14.html#command...
I agree, it is a very awkward way of writing.
I'm sure I read somewhere that Linus introduced this style of wording in a commit message. But alas I can't find the source right now (so I'm not even sure if I really did read it).
It's starting to grow a life of its own, slowly and slowly starting to become self-aware.
At a guess - new command line options are created by a GAN.
Personally I'd believe that.
Obligatory: https://git-man-page-generator.lokaltog.net/
Obligatory: https://git-man-page-generator.lokaltog.net/
It's not very common, but there's more than a few projects that use 'learned':
https://www.google.com/search?q=changelog+%22learned%22
https://www.google.com/search?q=changelog+%22learned%22
It not uncommon to anthromorphize software.
I remember several open source packages that used this idiom 15 or 20 years ago. It's probably a combination of a hat tip to the past, an inside joke, and the fact that the Git maintainer is not a native English speaker.
Smile--I think it's meant to amuse.
Smile--I think it's meant to amuse.
> I’ve never run across another piece of software that talked about itself this way.
Saying a piece of software “learned to” do something when it was programmed for a new feature is the same kind of anthropomorphism that leads one to talk about how a piece of software “talks about itself” when discussing project messaging, so it shouldn't seem that odd.
Saying a piece of software “learned to” do something when it was programmed for a new feature is the same kind of anthropomorphism that leads one to talk about how a piece of software “talks about itself” when discussing project messaging, so it shouldn't seem that odd.
FWIW I see the corollary of this fairly often in commit messages, where the author "teaches" the code how to do something.
Incidentally I just noticed that in the Git code and frankly I found it confusing until I remembered this discussion about the tool "learning" stuff.
https://patchwork.kernel.org/patch/11149363/
https://patchwork.kernel.org/patch/11149363/
The post mentions merge.conflictStyle but one thing I would like to see git steal from BitKeeper is the unified diff conflict style.
See the first example in this manpage: https://www.bitkeeper.org/man/smerge.html
But we never managed to get that used much as you can infer by this help:
See the first example in this manpage: https://www.bitkeeper.org/man/smerge.html
But we never managed to get that used much as you can infer by this help:
-g Enable 'gca' output format that shows the local and remote files
like a unified diff between the GCA and that file. This is the
recommended output format, but not the default because it con-
fuses people the first time they see it.
What's the current state of Git and SHA-1?
Thanks.
Linus knew, damn it. He knew SHA-1 was obsolete.
Linus knew, damn it. He knew SHA-1 was obsolete.
Did he? My impression was that they had SHA-1 from the start (maybe with a planned way to add another hashing) and only started to really switch gears when they got a real SHA-1 collision.
> Sparse checkout management made easy
Nothing about the following paragraphs of text sounds intuitive or easy...
Nothing about the following paragraphs of text sounds intuitive or easy...
I think this is similar to Mercurial's narrow clone: https://www.mercurial-scm.org/wiki/NarrowClonePlan
This is very useful in a mono repo.
This is very useful in a mono repo.
It's a lot of words to say "use a special checkout command then run `git sparse-checkout set A/B/C`"
> Git learned the ability to execute a “partial” clone...
> ..In Git 2.25, --format learned the verb l/L...
I’ve never run across another piece of software that talked about itself this way. I’ve tried to research it in the past, to see if it’s part of some software engineering philosophy, but have always come up short.
Anyone have any insight?