Avatar

Jakub Narębski

jnareb@programming.dev
Joined
0 posts • 14 comments

one of editors of Git Rev News: https://git.github.io/rev_news/

Direct message

I think the biggest issue is dealing with very large code bases, like the code for a mid-large size company. You either go with a monorepo and deal with slowness, Windows-only optimizations and bare minimum partial checkout support.

Or you go with submodules and then you have even bigger problems. Honestly I’m not sure there’s really an answer for this with Git currently.

The partial checkout support in Git is getting improved. Take a look, maybe it now solves your problems.

Support for large repositories via scalar works also for Linux (though not everything is ported; as main body of work on supporting large repositories was created to deal with the size of MS Windows repository, it started with Windows-only support / optimization first).

There are alternatives to submodules, like https://github.com/chronoxor/gil

permalink
report
parent
reply

I think it refers to two things: the title of the book about how Linus create Linux “Just for Fun. The Story of an Accidental Revolutionary”, and the fact that Git had to be created to continue effective work on Linux kernel (after BitKeeper fiasco).

From the start of the article:

Linus Torvalds once wrote in a book that he created Linux just for fun, but it ended up sparking a revolution. Git, his second major creation, also an accidental revolution.

permalink
report
parent
reply

undefined symbol: curl_global_sslset, version CURL_GNUTLS_3

This function was added in libcurl 7.56.0.

Maybe your curl is too old?

permalink
report
reply

Note that you can examine branch reflog to find where branch was forked from (1st image), or tell Git to examine it for you with git rebase --fork-point

permalink
report
reply

One thing that is not made clear in the article, is that there is a separate reflog for HEAD, and separate reflogs for individual branches.

HEAD reflog logs changes such as “checkout: moving from next to main”. Branch reflog logs changes such as “branch: Created from HEAD” (first entry in branch reflog). Most are common to both (i.e. git logs both to HEAD reflog and the reflog of currently checked out branch).

permalink
report
reply

Because ultimately you look at the diff of changes, which significantly limits the amount of code you need to examine to find the bug (or at least something that uncovered the bug).

permalink
report
parent
reply

Not much new here (I think I saw nearly the same description of Git history a short while ago), and there are a few factual errors in there - or at least parts that are not clear.

  1. The “tree” objects have nothing to do with the tree command, and nothing to do with how repo objects are stored on the filesystem. You can display tree objects with “git cat-file -p” (just like any type of objects), but also with “git ls-tree” command.

  2. The “commit” objects also store the reference to previous version (previous commit) in the history, which is very important. It enables Git to perform merges fast and well.

  3. A bit pedantic, but “tag” objects can point to any type of object, though tags pointing to commits are most common.

permalink
report
reply

There was a proposal to add universal signing to Git in 2021, but I think it went nowhere for various reasons (like breaking SHA-1 <-> SHA-256 signing interoperability, if I understand the discussion correctly).

permalink
report
reply

As an in-depth alternative, I recommend “Patterns for Managing Source Code Branches” by Martin Fowler: https://martinfowler.com/articles/branching-patterns.html

permalink
report
reply

The README of this project needs to describe what this project actually do. It would also be nice to have an example of how it can be used, and how long it takes in the case described in an example.

Note that this idea (forcing SHA-1 id to have some specific format) is not something new:

permalink
report
reply