Highlights from Git 2.25

https://github.blog/2020-01-13-highlights-from-git-2-25/

by guessmyname • 7 years ago

103 25 7 years ago

github.blog

richardwhiuk• 7 years ago

Sparse checkout management made easy

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

pjc50• 7 years ago

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

nerdponx3• 7 years ago

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

IshKebab2• 7 years ago

That's all of git!

yegle• 7 years ago

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.

jslabovitz• 7 years ago

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?

rjsw• 7 years ago

At a guess - new command line options are created by a GAN.

lowdose• 7 years ago

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

d33• 7 years ago

Personally I'd believe that.

Obligatory: https://git-man-page-generator.lokaltog.net/

ilikejam• 7 years ago

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

saagarjha• 7 years ago

It not uncommon to anthromorphize software.

downerending• 7 years ago

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.

dragonwriter• 7 years ago

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.

defap• 7 years ago

FWIW I see the corollary of this fairly often in commit messages, where the author "teaches" the code how to do something.

ofrzeta• 7 years ago

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/

davalapar• 7 years ago

It's starting to grow a life of its own, slowly and slowly starting to become self-aware.

adrianmsmith• 7 years ago

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

IshKebab2• 7 years ago

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.

cryptonector2• 7 years ago

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

frakturfreund• 7 years ago

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

cryptonector2• 7 years ago

Thanks.

Linus knew, damn it. He knew SHA-1 was obsolete.

wscott• 7 years ago

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.

Highlights from Git 2.25

Related Stories