What’s up with Git’s peculiar usage of ‘learned’ in their release notes? For example:

> 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?

> 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.

It not uncommon to anthromorphize software.

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

> 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.

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.

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).

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/

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/

Do you think Github patents these new fabricated options or would a good old copyright be sufficient?

Github doesn't develop Git.

> Sparse checkout management made easy

Nothing about the following paragraphs of text sounds intuitive or easy...

It looks like a bunch of low-level machinery and primitives, which can be used to build more-intuitive tools.

That's all of git!

Sort of? For example I wouldn't call "git checkout" a primitive or low level, just really bad CLI design.

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.

It's a lot of words to say "use a special checkout command then run `git sparse-checkout set A/B/C`"

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:

       -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.

You have to do more editing to resolve the conflict, but what changed is a lot more obvious.

What's the current state of Git and SHA-1?

This: https://sidewalk.crustytoothpaste.net/tech/git/2020/01/11/sh...

Thanks.

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.