Hey guys this was just meant to give you inspiration, its not a set of rules. How about use what works for you (:
Git commands I run before reading any code
411–420 of 546 posts
Re: Git commands I run before reading any code
#412Earlier quoted context omitted.
I just use Claude Code as a terminal for git these days. It writes up better commit messages than I would write anyway. No more "git commit -m fix"
That could work if Claude Code made the code changes, but if you made them and only asked Claude to commit them, how does it know "why" you made those changes? Does it have access to your bug tracking system, for example?
If Claude was used in the creation of the change, there's usually some dialogue for Claude to use.
FWIW i use Claude to help with code changes, then give the diff to Gemini to review/ create meaningful commit messages
Re: Git commands I run before reading any code
#413Thanks for this. My updated relevant portion of ~/.gitconfig:
[alias]
st = status
ci = commit
co = checkout
br = branch
df = diff
dfs = diff --stat
dfc = diff --cached
dfh = diff --histogram
dfn = diff --name-status
rs = restore
rsc = restore --staged
last = log -1 HEAD
lg = log --graph --decorate --oneline --abbrev-commit
cm = commit -m
ca = commit --amend
cane = commit --amend --no-edit
who = shortlog -sn --no-merges HEAD
dmg = log --oneline -i -E --grep='(incident|outage|downtime|rollback|revert|mitigate|mitigation|hotfix|broke|prod)' --since='1 year ago'
bugs = log --oneline -i -E --grep='(bug|bugfix|fix|fixed|fixes|defect|regression|hotfix|broke)' --since='1 year ago'
bugfiles = !git log --name-only --format='' -i -E --grep='(bug|bugfix|fix|fixed|fixes|defect|regression|hotfix|broke)' --since='1 year ago' | sort | uniq -c | sort -nr
monthly = !git log --since='1 year ago' --format='%ad' --date=format:'%Y-%m' | sort | uniq -c
churn = !git log --format='' --name-only --diff-filter=AM --since='1 year ago' | sort | uniq -c | sort -nr | head -20Re: Git commands I run before reading any code
#414[dead]
Re: Git commands I run before reading any code
#415Jujutsu equivalents, if anyone is curious: What Changes the Most jj log --no-graph -r 'ancestors(trunk()) & committer_date(after:"1 year ago")' \ -T 'self.diff().files().map(|f| f.path() ++ "\n").join("")' \ | sort | uniq -c | sort -nr | head -20 Who Built This jj log --no-graph -r 'ancestors(trunk()) & ~merges()' \ -T 'self.author().name() ++ "\n"' \ | sort | uniq -c | sort -nr Where Do Bugs Cluster jj log --no-grap…
To me, it makes jujutsu look like the Nix of VCSes. Not meaning to offend anyone: Nix is cool, but adds complexity. And as a disclaimer: I used jujutsu for a few months and went back to git. Mostly because git is wired in my fingers, and git is everywhere. Those examples of what jujutsu can do and not git sound nice, but in those few months I never remotely had a need for them, so it felt overkill for me.
I don't know about jujutsu, but I've actually found that Nix removes a lot of complexity. It's essentially just npm for tooling.
Managing a flake.nix can be a bit more complex than a package.json in practice, due to the flexibility of the format and some quirks around Nix's default caching behavior, but working with it is a breath of fresh air compared relying on globally installed tools. Having said that, you might want to check out Devbox. I haven't used it myself, but found it recently and thought it looked like a nice abstraction over raw Nix.
Re: Git commands I run before reading any code
#416[dead]
Re: Git commands I run before reading any code
#417Earlier quoted context omitted.
I don’t understand how people can remember all these custom scripting languages. I can’t even remember most git flags, I’m ecstatic when I remember how to iterate over arrays in “jq”, I can’t fathom how people remember these types of syntaxes.
I am convinced that the vast majority of professionals simply don't bother to remember and, ESPECIALLY WITH GIT, just look stuff up every single time the workflow deviates from their daily usage. At this point perhaps a million person-years have been sacrificed to the semantically incoherent shit UX of git. I have loathed git from the beginning but there's effectively no other choice. That said, the OP's commands are…
I think this is where LLMs shine. I experience the same difficulty with a lot of command line tools, .e.g find is a mystery to me after all these years. Whatever the syntax is, it just doesn't stick in my memory. Since recently I just tell the model what search I want and it gives me the command.
Re: Git commands I run before reading any code
#418Earlier quoted context omitted.
I refuse to have alises and other custom commands. Either it is useful for everyone and so I make a change to the upstream project (I have never done this), or it won't exist next time I change my system so there is no point. I do have some custom tools that I am working on that haven't been released yet, but the long term goal is either delete them or release them to more people who will use them so I know it will b…
> I refuse to have alises and other custom commands. I am the same way, and have caught much flack for it over the years. But when I sit down at a foreign system (foreign in the sense that I haven't used it before) because something is broken and my help was requested, I don't have any need to lean on aliases. I worked with someone once that had a very impressive bashrc, and it was very effective for them... on their…
You don’t need aliases when you have fzf fuzzy history search with ctrl-r
Re: Git commands I run before reading any code
#419I love how the author thinks developers write commit messages. All joking aside, it really is a chronic problem in the corporate world. Most codebases I encounter just have "changed stuff" or "hope this works now". It's a small minority of developers (myself included) who consider the git commit log to be important enough to spend time writing something meaningful. AI generated commit messages helps this a lot, if de…
This is a team lead/CTO problem. A good leader will be explicit in their expectations that developers write good commit messages. I've certainly had good leaders that expect this.
It can be even enforced using hooks/pipelines that will check that the message follow Conventional Commits as well
Re: Git commands I run before reading any code
#420Jujutsu equivalents, if anyone is curious: What Changes the Most jj log --no-graph -r 'ancestors(trunk()) & committer_date(after:"1 year ago")' \ -T 'self.diff().files().map(|f| f.path() ++ "\n").join("")' \ | sort | uniq -c | sort -nr | head -20 Who Built This jj log --no-graph -r 'ancestors(trunk()) & ~merges()' \ -T 'self.author().name() ++ "\n"' \ | sort | uniq -c | sort -nr Where Do Bugs Cluster jj log --no-grap…
To me, it makes jujutsu look like the Nix of VCSes. Not meaning to offend anyone: Nix is cool, but adds complexity. And as a disclaimer: I used jujutsu for a few months and went back to git. Mostly because git is wired in my fingers, and git is everywhere. Those examples of what jujutsu can do and not git sound nice, but in those few months I never remotely had a need for them, so it felt overkill for me.
To be completely fair to JJ: you can still use git commands and any aliases with it. I daily JJ in all of my repos but I created these aliases inside of git. That's one of the great aspects of JJ: it's fully compatible with git.