Comment by sshine | Hacker News Reader

Comment by sshine | Hacker News Reader

Parent Full thread

> How fast I can deliver value is almost never gated by my VCS

Oh, the number of times I do

  git commit --fixup ...searches `git log` and pastes`... && \
    git rebase -i --autosquash ...that same commit^...

I waste several half minutes several times per day in periods!

Another time-consuming thing is context-switching from a feature branch with staged/unstaged changes. If you're good with worktrees, you can largely avoid this, but the way I work with worktrees, I instantiate them as subdirectories to my repo's parent, which clutters my directories unless I make space for this as I clone the repository, which I haven't got used to.

I deliberately avoid too complicated git workflow aliases because I hate being stuck without them.

I am definitely in the camp of "I'd switch to jj the moment I give myself time to try it."

In the meantime, running git commands does sometimes take more time than it needs to.

You can interactively rebase after the fact while preserving merges even. I usually work these days on stacked branches, and instead of using —-fixup I just commit with a dumb message.

    git rebase -i --rebase-merges --keep-base trunk

This lets me reorganize commits, edit commit messages, split work into new branches, etc… When I add --update-refs into the mix it lets me do what I read are the biggest workflow improvements from jj, except it’s just git.

This article from Andrew Lock on stacked branches in git was a great inspiration for me, and where I learned about --update-refs:

https://andrewlock.net/working-with-stacked-branches-in-git-...

That’s great advice, thanks for sharing --update-refs!

But I don’t see how that removes the usefulness of fixup commits, only that you can do them across stacked branches with ease.

But you’re saying I don’t need the particular hash of the parent, I can just rebase all the way back to main/trunk each time. That’s a good point!

I think I’m still saving time by fixup, it was the second hash lookup I wasn’t happy with.

I like to rebase my fixups immediately when possible so I don’t forget.

You understand it correctly: it doesn’t remove any value from fixup; instead it just means you can fixup to whatever and move the commit visually to where you want it — doesn’t have to be the main/trunk branch, and you can do it whenever is convenient.

That’s where I made the comment about not actually running fixup. Instead of claiming to fix a SHA, I leave myself a note like “fix tests” so I can move it appropriately even if I get distracted for a few days

Reply on news.ycombinator.com