Hacker News Reader

Comment by adql | Hacker News Reader

> git reflog (git usage or git cmdlog)

It kinda needs separate command that shows you both reflog entries and commands that lead to it. Maybe merged with undo command so you could look at the history of operations, go back to that point, and get alert if you skip something already pushed upstream.

git rebase -i is essentially "undo" of sort but, uh, not a tool for faint hearts.

> git blame (git author)

I doubt people are confused by that

> I'd love a command pallet where you could search for basic behavior in plain text like "reset my branch to GitHub's copy" or "only rebase two commits" and have it find the magic incantation.

"git do" that just asks ChatGPT and pastes solution lmao.

View on HN

I've been using git for years and do `rebase -i` daily, bisect many spooky commands. However, I still don't know how I can update a branch and switch to it in one motion:

- not just update `origin/branch` - not checkout `branch` and sync it with `origin/brach`

and it drives me crazy.

Not aware of a built in way, but if you use bash or similar as your shell you can do an alias like

  git config --global alias.chpull '!f() { git checkout "$1" && git pull; }; f'

Didn't think about alias for this even though I have alias for many other things, that should prevent `direnv` from triggering between checkout and pull. Thanks.

Why is rebase such a reviled git command? It's so useful. Interactive rebase is essentially a centralized place for editing history: reordering, squashing, amending, rewording, dropping, merging, splitting. Pretty much anything anyone could ever want to do can be done with interactive rebase. Enable autostashing and explicit dropping of commits and there's basically no way to screw things up. In the event that does happen somehow, reflog shows previous heads and even notes the point where the rebase began, making it easy to hard reset.

It's just so good. I don't know what I'd do without it.

It's so easy to end up in rebase hell where you're constantly fixing the same diffs. If you know what you're doing and can get the rebased commits to be pretty small it's okay. Although I've recently started using merge commits again and just squashing my branch when I merge into main.

Rebase (with or without -i) is one of my most used git commands. The one thing I still get confused with is whether I have to commit to continue or not.

Reply on news.ycombinator.com