[freedomben]

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

I wrote a cheat sheet in my notes of common commands, until they stuck in my head and I haven't needed it now for a decade or more. I also lean heavily on aliases and "self-documenting" things in my .bashrc file. Curious how others handle it. A search every time I need to do something would be too much friction for me to stand.

[dheera]

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"

[selcuka]

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?

[dheera]

> but if you made them and only asked Claude to commit them, how does it know "why" you made those changes?

It's an LLM. It can diff and figure out why I did what I did, in most cases

> Does it have access to your bug tracking system, for example?

You can give it access and tell it to look there

[awesome_dude]

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

[yujiachen]

I just wrapped these 5 diagnostic commands into a Claude Code skill. Because the post is useful but I'm not sure I can remember these git commands all the time... https://github.com/yujiachen-y/codebase-recon-skill

[freedomben]

indeed, I held off for a while but finally caved because I got sick of seeing commits with `git commit -m .` littered in there. These are personal projects so I'm the only one dev-ing on them, but still so nice to have commit messages.

[bluGill]

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 be there next time I use a different system.

[irishcoffee]

> 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 workstation. Plop them in front of a production system, they can't even remember how to remount / rw because they've been using an alias for so long.

This is also why I learned vi, having started with emacs 30 years ago initially, as it was first taught to me. I know it'll be there, and I know how to use it.

[tcoff91]

You don’t need aliases when you have fzf fuzzy history search with ctrl-r

[freedomben]

it's a tradeoff for sure. With dig especially I can't ever remember the normal syntax because I have aliases and scripts for things. I feel the aliases are wroth it since I'm on my own machine(s) 99.5% of the time, but it does suck to be handicapped

[irishcoffee]

Absolutely, and I think aliases are great and should be used. I, personally, worked in a handful of environments that made me realize it was infeasible to lean on aliases and helper scripts. Like bluGill said, if I need it in a real way, I'll try and upstream it.

What I resent is someone telling me how to use a computer. I've got that bit mostly down at this point.