git-from-the-bottom-up VS emlop

Here's a great walk through for how Git works from the bottom up: https://jwiegley.github.io/git-from-the-bottom-up/

It's short, easy to understand and you'll understand HEAD.

Very tangential:

Gerrit also stores some of its configs in a git repo. I was setting up a new instance, but couldn't get Admin permissions because the way my auth front-end didn't play well with the docker image's assumptions.

Gerrit already does a lot of its work via non-standard references. For example, you don't push to a branch, `refs/branches/foo`, you push to a separate `refs/for/foo` namespace that creates the review.

Similarly, Group config is stored in the All-Users git repo [1], but in references created after a UUID, in `refs/groups/UU/UUID`.

I ended up having a to exercise the plumbiest of plumbing commands [2] to create a new commit from scratch (from a tree, from the index, from blobs), to update the group ref to add myself to the Administrators group (this, of course, requires a local shell and permissions on the Gerrit host). It was a great way to exercise what I had learned in Git from the Bottom Up [3]

[1] https://gerrit-review.googlesource.com/Documentation/config-...

[2] https://git-scm.com/book/en/v2/Git-Internals-Git-Objects

[3] https://jwiegley.github.io/git-from-the-bottom-up/

I found Git from the Bottom Up helpful. It is very short as well. Then refer to the official book when you want more detail.

I recently came across "Git from the Bottom Up by John Wiegley" (thanks to Coding Blocks podcast), he has a chapter about rebasing: https://jwiegley.github.io/git-from-the-bottom-up/1-Repository/7-branching-and-the-power-of-rebase.html

You won't have to put your entire life on break in order to understand the fundamentals of git and why it works the way it works. Going through https://jwiegley.github.io/git-from-the-bottom-up/ and really understanding the material will take you a couple of hours at max, but will save you a lot of time in the future.

Wanting to understand things before using them is hardly elitism, not sure why you would think that.

Just like you probably don't want to fix bugs without understand the cause, it's hard to use a tool correctly unless you know how the tool works.

My oldest remaining emerge.log started in 2007. That desktop went thru some hardware upgrades, that you can spot them in the build time logs. Would love to see [emlop](https://github.com/vincentdephily/emlop) s -st -gy and emlop s -gy -e gcc from your machine.

Genlop is indeed slow, but qlop is comfortably fast, and emlop is even faster. I encourage you to check them out.

Happy to help. The size and number of packages is what's important, not whether you're installing or updating. I tend to only use emerge -j2 if I have 10 or more packages that can each build in a minute or less. You can always stop an emerge and restart it with emerge -rO -jN if you feel you made the wrong choice. You can use emlop p to get an estimate of how long the current emerge will take (current release is a bit outdated, I suggest installing from git: cargo install emlop --git https://github.com/vincentdephily/emlop).

Emlop is much faster than genlop, gives better estimates, has fewer bugs, and more features.

That's a huge variation in merge times, things are usually a bit more predictable than this. They might just get progressively slower as new package versions get bigger.

On the positive side, it inspired me to implement display of the current merge phase in emlop:

emerge -rOp|emlop p can tell you how long the currently running merge will take, if it's something you've merged on that machine before. You could also suspend your laptop instead of shutting it down.

emlop

While genlop works, I highly recommend emlop instead, as it is much faster (emerge -rOp | genlop -c is unusably slow) and featureful. The version in the GURU overlay is outdated at the moment, so either get it from the moltonel overlay or using cargo install emlop.

There are a handful of commits that take especially long, for example cc8fa62c which updates many lines of a 5Mb test file. I've observed similar issues with the vim import. It seems that large diffs slow pijul down greatly, import time is not linear to diff size.