Hacker News Reader

Comment by zimmski | Hacker News Reader

Learning rebasing is one thing but wasting hours every week on rebasing because you are doing the same thing over and over again is another. When i do a one line fixup i just do not want to figure out the correct commit and then rebase i just want it to happen because i already know how i would rebase that: you just use git-autofixup or other similar tools discussed here to get it done.

View on HN

It's possible the other reason is trying to manipulate git history too frequently. Keep in mind this comes from a prolific git history abuser and rebaser... if hacking on a branch, a trail of messy commits is fine, it's your work in progress, it's also useful if you messed up otherwise you are forced to use reflog. Rebase when you are at the final stage of tidying things up and squashing commits down into a legible history, not on every single amendment... for this style of history rewriting rebase is perfect because you have the full power to rearrange rewrite and squash commits.

Totally agree. I guess what i am trying to say is that learning rebase is a must and powerful tool but if you are doing the same things again and again you should think about automating them and use your thinking-power and time for non-automated things.

I'd disagree. The longer the branch to rebase the larger the chance of conflicts occuring.

Rebase early and often. Always keep a close eye on upstream while you're working downstream. Otherwise you're making it harder on yourself when you do that final cleanup.

That's a fair point, if you are working against a fast moving target that forces you to rebase onto it often then you really want a short and simple history... a trail of WIPs or changes on top of changes tend blow up into a cascade of conflicts.

However in my original comment I was actually just referring to the scenario where you only want to rewrite history onto the same base, in which case I stand by my suggestion... In fact I find this can be a good strategy if your history has grown and you also need to rebase onto a new upstream - i.e first clean up your history onto the same base with a `git rebase -i current-base` and squash it all down and tidy it up, then do the `git rebase upstream` so you can do conflict resolution with more holistic commit diffs.

Practice. You'll get better and faster. I do it tens of times daily and each fixup takes ten or fifteen seconds.

Yep. I have that practice too and i thought that was good enough but with git-autofixup and my posted alias i am down to under one second. So it will save you 1-14 sesconds of your life with every fixup you do... unless it cannot be done automatically. Try it and let us know what you think :-)

Challenge accepted.

I tried git-absorb (git-autofixup is Perl? Installing things with CPAN needs sudo? Sorry... I don't have a good Perl situation and don't care to have one.) and it did not immediately work correctly. Maybe git-autofixup is better; idk. Also I misunderstood; I'm expected to `git add` before using these tools - after that, the commit/rebase only takes me a few seconds; I already knew what commit it was bound for when I staged the changes.

git-autofixup can also be installed by simply downloading the script[1], giving it execute permissions, and putting it somewhere in your PATH. It needs perl 5.8.4+, which is very old, and only depends on the standard library. Git ships with a Perl interpreter on Windows.

If there are any staged changes, git-autofixup only fixes those up and ignores any unstaged ones; otherwise it tries to autofixup all unstaged changes.

[1]: https://github.com/torbiak/git-autofixup/blob/master/git-aut...

Reply on news.ycombinator.com