6 ms·

git is really simple it only has like 6 atomic operations. thats what makes it so beautiful. a git rebase to reorder the commits and drop the uninteresting ones

by jatone 6y ago

git is really simple it only has like 6 atomic operations. thats what makes it so beautiful. a git rebase to reorder the commits and drop the uninteresting ones would produce the result wanted here. along with a few other approaches.

Pxtl 6y ago
I'm aware of the interactive rebase and the simple rebase, but the amount of stuff we throw at students and juniors, asking them to clean their history in such a hoary old ui seems like a lot to ask. Plus, I've become painfully aware of what happens when you encourage squashing and rebasing but developers don't carefully delete the source branches. The housekeeping of old branches is nightmarish since they're all ahead of the target, because rebasing means the commits aren't the commits. And it means allowing force-push on our git server.
- TheCraiggers 6y ago
  git rebase is akin to being a wizard but forbidden to use magic. I know it's there. I know it could solve a ton of my problems. But I can't use it because it would break everything from the feature-branch promotion model to my teammate's repos. It's basically useless to me, despite all the power it grants me.
  - adrianN 6y ago
    The trick is rebasing your stuff before you push it anywhere.
  - dharmab 6y ago
    We use rebase heavily and it makes our lives so much easier. The main rule is that we never rebase anything in the main repository- only in our forks. And everyone accepts that the forks are unstable.
    - lmm 6y ago
      What do you actually get out of it though? Everyone talks about "clean history" but how much do you actually use that history? (except to bisect - and bisect works better without rebasing, IME) You're definitely missing out on being able to pull each other's branches - that's a huge help for avoiding conflicts ahead of time (if you know your colleague is halfway through a change in a given code area, start from their branch rather than master) or for unblocking development while a quickfix is making its way to master. I could believe that tradeoff could be worthwhile, but I've never found that rebasing offers any real advantages in practice.
      - deleted 6y ago
        [deleted]
      - phyzome 6y ago
        I use it all the time! I do really messy stuff locally, and then I rebase to organize it into commits that tell a story, which makes it easier for reviewers (and archaeologists, such as me in 5 months) to understand. Most common pattern: Commit 1 does a preliminary refactoring, commit 2 does the actual feature change. If you squash them together, the changes are harder to understand. But in the editing process, I often end up doing additional refactoring before I'm done with the feature work, so I use rebase -i to reorder and squash the changes appropriately. (I also run tests at both commits to make sure that my story is true, heh.) (This way, you can even do things like later revert the feature change without undoing the refactoring work.)
        lmm 6y ago
        > I do really messy stuff locally, and then I rebase to organize it into commits that tell a story, which makes it easier for reviewers (and archaeologists, such as me in 5 months) to understand. So people review commit-by-commit? What review tool are you using for that? Github and Bitbucket very much nudge you towards reviewing the PR's diff as a whole, IME. And do you find that you actually look at the history in 5 months' time? People worry about this a lot but I find it's pretty rare to actually need more history than what's in the diffs. > But in the editing process, I often end up doing additional refactoring before I'm done with the feature work, so I use rebase -i to reorder and squash the changes appropriately. (I also run tests at both commits to make sure that my story is true, heh.) I do that but without the reordering - it just seems like a lot of overhead (and lots of potential for conflicts since the refactoring will almost necessarily be in the same code area as the feature work) plus running the build/tests again etc. > (This way, you can even do things like later revert the feature change without undoing the refactoring work.) You can do that either way, though I guess if all the refactoring commits were before the feature commits then that means fewer conflicts (though you still have to worry about subsequent refactorings in the same area). Is that something that happens often?
  - cryptonector 6y ago
    Ay, no. You can't rewrite history in upstream branches, no (well...[0]), but you _can_ (and should) do it locally. There's this terrible misunderstanding that "git rebase means rewriting history, which is bad" when in fact rewriting history locally (before you push upstream) is fine and quite desirable. [0] In fact you can rewrite history upstream if you really must, but then you have to securely communicate to downstream users how to recover by telling them the previous HEAD commit and the new one so they can use git rebase --onto. If you really wanted to, you could make a habit out of this and make it work just fine. Most projects just aren't set up for this.
  - fourthark 6y ago
    Rebasing a PR is also good - the branch has been pushed but everyone knows it’s unstable.
_ZeD_ 6y ago
"git" and "beautiful" should not be in the same sentence.

by jatone 6y ago

Pxtl 6y ago

I'm aware of the interactive rebase and the simple rebase, but the amount of stuff we throw at students and juniors, asking them to clean their history in such a hoary old ui seems like a lot to ask. Plus, I've become painfully aware of what happens when you encourage squashing and rebasing but developers don't carefully delete the source branches. The housekeeping of old branches is nightmarish since they're all ahead of the target, because rebasing means the commits aren't the commits. And it means allowing force-push on our git server.

TheCraiggers 6y ago
git rebase is akin to being a wizard but forbidden to use magic. I know it's there. I know it could solve a ton of my problems. But I can't use it because it would break everything from the feature-branch promotion model to my teammate's repos. It's basically useless to me, despite all the power it grants me.
- adrianN 6y ago
  The trick is rebasing your stuff before you push it anywhere.
- dharmab 6y ago
  We use rebase heavily and it makes our lives so much easier. The main rule is that we never rebase anything in the main repository- only in our forks. And everyone accepts that the forks are unstable.
  - lmm 6y ago
    What do you actually get out of it though? Everyone talks about "clean history" but how much do you actually use that history? (except to bisect - and bisect works better without rebasing, IME) You're definitely missing out on being able to pull each other's branches - that's a huge help for avoiding conflicts ahead of time (if you know your colleague is halfway through a change in a given code area, start from their branch rather than master) or for unblocking development while a quickfix is making its way to master. I could believe that tradeoff could be worthwhile, but I've never found that rebasing offers any real advantages in practice.
    - deleted 6y ago
      [deleted]
    - phyzome 6y ago
      I use it all the time! I do really messy stuff locally, and then I rebase to organize it into commits that tell a story, which makes it easier for reviewers (and archaeologists, such as me in 5 months) to understand. Most common pattern: Commit 1 does a preliminary refactoring, commit 2 does the actual feature change. If you squash them together, the changes are harder to understand. But in the editing process, I often end up doing additional refactoring before I'm done with the feature work, so I use rebase -i to reorder and squash the changes appropriately. (I also run tests at both commits to make sure that my story is true, heh.) (This way, you can even do things like later revert the feature change without undoing the refactoring work.)
      - lmm 6y ago
        > I do really messy stuff locally, and then I rebase to organize it into commits that tell a story, which makes it easier for reviewers (and archaeologists, such as me in 5 months) to understand. So people review commit-by-commit? What review tool are you using for that? Github and Bitbucket very much nudge you towards reviewing the PR's diff as a whole, IME. And do you find that you actually look at the history in 5 months' time? People worry about this a lot but I find it's pretty rare to actually need more history than what's in the diffs. > But in the editing process, I often end up doing additional refactoring before I'm done with the feature work, so I use rebase -i to reorder and squash the changes appropriately. (I also run tests at both commits to make sure that my story is true, heh.) I do that but without the reordering - it just seems like a lot of overhead (and lots of potential for conflicts since the refactoring will almost necessarily be in the same code area as the feature work) plus running the build/tests again etc. > (This way, you can even do things like later revert the feature change without undoing the refactoring work.) You can do that either way, though I guess if all the refactoring commits were before the feature commits then that means fewer conflicts (though you still have to worry about subsequent refactorings in the same area). Is that something that happens often?
- cryptonector 6y ago
  Ay, no. You can't rewrite history in upstream branches, no (well...[0]), but you _can_ (and should) do it locally. There's this terrible misunderstanding that "git rebase means rewriting history, which is bad" when in fact rewriting history locally (before you push upstream) is fine and quite desirable. [0] In fact you can rewrite history upstream if you really must, but then you have to securely communicate to downstream users how to recover by telling them the previous HEAD commit and the new one so they can use git rebase --onto. If you really wanted to, you could make a habit out of this and make it work just fine. Most projects just aren't set up for this.
- fourthark 6y ago
  Rebasing a PR is also good - the branch has been pushed but everyone knows it’s unstable.

_ZeD_ 6y ago

"git" and "beautiful" should not be in the same sentence.