Git commands I run before reading any code

This is a great list of commands to quickly understand a repository. Thank you for sharing.

I'm so used to magit, it seems kind of primitive to pipe git output around like this.

Anyway, I can glean a lot of this information in a few minutes scrolling through and filtering the log in magit, and it doesn't require memorizing a bunch of command line arguments.

thank you - these are useful

Just looking at how often a file changes without knowing how big the file is seems a bit silly. Surely it should be changes/line or something?

Step 6: grep the thread count on the squash-merge debate to determine if the team has unresolved interpersonal conflict.

blog posts are just comments that would have been torn apart if only posted on a forum, now masquerading as important universal edicts

This should be renamed to "Git commands that I run as a new hire to get metrics I'll forget on day 2".

> The 20 most-changed files in the last year. The file at the top is almost always the one people warn me about. “Oh yeah, that file. Everyone’s afraid to touch it.”

I've got my Emacs set up to display next to every file that is versioned the number of commits that file has been modified in (for the curious: using a modified all-the-icons-ivy-rich + custom elisp code + custom Bash scripts I wrote and it's trickier than it seems to do in a way that doesn't slows everything down). For example in the menu to open a file or open a recently visited file etc.: basically in every file list, in addition to its size, owner, permissions, etc. I also add the number of commits if it's a versioned file.

I like the fix/bug/broken search in TFA to see where the bugs gather.

I was curious what information I could glean from these for some popular repos. Caveat: I'm primarily an low-level embedded developer so I don't interface with large open source projects at the source level very often (other than occasionally the linux kernel). I chose some projects at random that I use.

*Mainline linux*

Most changed files: pretty much what I expected for 1 and 2... the "cutting edge" of Linux development over other OSes -- bpf and containers. The bpf verifier and AMD GPU driver might get a boost in this list due to sheer LoCs in those files (26K and 14K respectively). An intel equivalent of amdgpu_dm is #21 in the list (drivers/gpu/drm/i915/display/intel_display.c) and nvidia is nowhere to be seen (presumably due to out-of-tree modules/blobs?).

    186 kernel/bpf/verifier.c
    174 fs/namespace.c
    162 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
    161 kernel/sched/ext.c
    159 fs/f2fs/f2fs.h

    10399 Christoph Hellwig -> I only know his name because of drama last year regarding rust bindings to DMA subsystem
     8481 Mauro Carvalho Chehab -> I also know his name from the classic "Mauro, shut the fuck up!" Linus rant
     8413 Takashi Iwai -> Listed as maintainer for sound subsystem, I think he manages ALSA
     8072 Al Viro -> His name is all over bunch of filesystem code

    1477 drivers/gpu/drm/i915/intel_display.c
    1406 MAINTAINERS
    1390 sound/pci/hda/patch_realtek.c
    1102 drivers/gpu/drm/i915/i915_drv.h
     943 arch/x86/kvm/x86.c
     928 mm/page_alloc.c
     871 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
     862 drivers/gpu/drm/i915/i915_reg.h
     840 fs/btrfs/inode.c

Most changed files: IR autovectorization code, riscv heuristics tables, and C++ template handling (pt.c is "paramaterized types").

    152 gcc/tree-vect-stmts.cc
    145 gcc/config/riscv/riscv.cc
    131 gcc/tree-vect-loop.cc
    116 gcc/cp/pt.cc

   1017 gcc/dwarf2out.c
    885 gcc/config/i386/i386.c
    796 gcc/cp/cp-tree.h
    740 gcc/config/rs6000/rs6000.c
    720 gcc/cp/pt.c

This has not told me much other than where most of the functionality of this project lies.

Bus factor: Pretty huge. Not really an issue in this case due to lack of development I guess.

    3298  Olivier Fourdan
     530  Anonymous
     319  Xfce Bot
     121  Jasper Huijsmans

I think these massive open projects (excl xfwm) are generally pretty consistent code quality across the heavily trodden areas because of the amount of manpower available to refactor the pain points. I've yet to see an example of "god help you if you have to change that file" in e.g. linux, but I have of course seen that situation many times in large proprietary codebases.

More AI slop.

Wtf is happening to this website

[dead]

[dead]

[dead]

[dead]

[flagged]

git commands I run before reading any code:

git rm -rf .