3 ms·

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

by tomxor 6y ago

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.

zimmski 6y ago
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.
urxvtcd 6y ago
I'd disagree. The longer the branch to rebase the larger the chance of conflicts occuring.
hashkb 6y ago
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.
- tomxor 6y ago
  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.

by tomxor 6y ago

zimmski 6y ago

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.

urxvtcd 6y ago

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

hashkb 6y ago

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.

tomxor 6y ago
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.