4 ms·

Stash -> pull -> unstash is just manual rebase, though. You're already doing the thing you're claiming not to do, you're just doing it the hard way. Which is f

by blep_ 4y ago

Stash -> pull -> unstash is just manual rebase, though. You're already doing the thing you're claiming not to do, you're just doing it the hard way. Which is fine, if that works for you! Just know that you're using different terms for the same thing (do some work on top of A, then move it to be on top of B instead).

chociej 4y ago
Soft reset is a rebase too
MetaWhirledPeas 4y ago
Now you've piqued my interest.
- OkayPhysicist 4y ago
  Not the person you replied to, but what a rebase is is taking a series of commits you made to one place, and replaying them on top of another commit. So you make your PR, then branch off of that commit, and continue doing the normal edit-commit workflow on that new branch. Then, when you the PR gets merged, you git rebase -i (master/main/whatever branch your PR was being pulled into). You'll be presented with all your commits, you can choose to exclude some from the rebase (useful if you had to update something specifically because it gets updated between every PR/build), then commit to the rebase. It will then proceed to replay each commit you made, just like a repeated version of your stash/unstash process, on top of the new top of the master branch. Your working branch is now contains all the changes you made, but instead of working off your PR commit, it's like you were working off of the finished PR commit. If you want to make sure that your git history maintains the old branch for sentimental reasons (or you want to try out removing some commits and desire an easy way to rollback if you get lost), just make a branch off of your working branch before the rebase. That branch will be identical to the branch you were working on, before the rebase. A---B---C topic / PR Branch P---R---S \ O---L---D---E master (where commit D and E are produced as part of the PR, say, the merge commit and a version number crank or something) (checked out topic) git rebase master PR Branch P---R---S A---B---C topic \ / O---L---D---E master magic
  - MetaWhirledPeas 4y ago
    This is an excellent explanation, thank you. Still, I have questions. When I have topic checked out then run "git rebase -i main" does it first do fetch (or whatever) to make sure main's latest commit history is represented? Or is it up to me to do that first? The rebase concept is sound, but the semantics are a bit daunting. git rebase -i main This sounds like an operation is being performed on main. Terrifying! And "rebase" is a scary word choice regardless. Perhaps you remember when you were new to Git and can relate. I may give rebase a try at some point, to see if perhaps it might speed me up. The vast library of Git commands is a bit much for me though. It's like using an aircraft cockpit to control the television!
    - qu4z-2 4y ago
      I definitely sympathise with the confusing and scary command names! "reset" is the worst in my opinion. Rebase is kind of the natural choice once you understand the data model, but it doesn't necessarily make it more approachable. `git rebase main` will modify your currently checked out branch to make the commits on that branch now branch off of the current value of main. It won't update main or modify it in any other way, only your current branch. You can equally `git rebase 347ae9` to have them come off a specific commit. If you know what a tree is (in the general computer science sense, not the git term of art) it's well worth taking a little time to learn the underlying data model in my opinion.
      - MetaWhirledPeas 4y ago
        Thanks, that's useful information!
    - blep_ 4y ago
      There's also `git pull --rebase`, which is just "pull like normal, then rebase onto the thing I just pulled". Remember that it's okay to screw around and break stuff! Sometimes that's the best way to learn. Git's whole thing is tracking history, even the history of the history itself[0]. It is hard to accidentally lose something if you've committed it at least once. If you're nervous, push your branch somewhere before starting (it's not strictly necessary, but it's the easiest way to get peace of mind). Nothing you do locally will be pushed back to the remote unless you explicitly do `git push`. If you manage to screw up your branches so badly you don't know how to recover, you can just delete the local branch you broke and re-pull the remote one like it's a new branch, even if it's main/master. [0] https://ohshitgit.com/ https://ohshitgit.com/, especially the first thing there

by blep_ 4y ago

chociej 4y ago

Soft reset is a rebase too

MetaWhirledPeas 4y ago

Now you've piqued my interest.

OkayPhysicist 4y ago
Not the person you replied to, but what a rebase is is taking a series of commits you made to one place, and replaying them on top of another commit. So you make your PR, then branch off of that commit, and continue doing the normal edit-commit workflow on that new branch. Then, when you the PR gets merged, you git rebase -i (master/main/whatever branch your PR was being pulled into). You'll be presented with all your commits, you can choose to exclude some from the rebase (useful if you had to update something specifically because it gets updated between every PR/build), then commit to the rebase. It will then proceed to replay each commit you made, just like a repeated version of your stash/unstash process, on top of the new top of the master branch. Your working branch is now contains all the changes you made, but instead of working off your PR commit, it's like you were working off of the finished PR commit. If you want to make sure that your git history maintains the old branch for sentimental reasons (or you want to try out removing some commits and desire an easy way to rollback if you get lost), just make a branch off of your working branch before the rebase. That branch will be identical to the branch you were working on, before the rebase. A---B---C topic / PR Branch P---R---S \ O---L---D---E master (where commit D and E are produced as part of the PR, say, the merge commit and a version number crank or something) (checked out topic) git rebase master PR Branch P---R---S A---B---C topic \ / O---L---D---E master magic
- MetaWhirledPeas 4y ago
  This is an excellent explanation, thank you. Still, I have questions. When I have topic checked out then run "git rebase -i main" does it first do fetch (or whatever) to make sure main's latest commit history is represented? Or is it up to me to do that first? The rebase concept is sound, but the semantics are a bit daunting. git rebase -i main This sounds like an operation is being performed on main. Terrifying! And "rebase" is a scary word choice regardless. Perhaps you remember when you were new to Git and can relate. I may give rebase a try at some point, to see if perhaps it might speed me up. The vast library of Git commands is a bit much for me though. It's like using an aircraft cockpit to control the television!
  - qu4z-2 4y ago
    I definitely sympathise with the confusing and scary command names! "reset" is the worst in my opinion. Rebase is kind of the natural choice once you understand the data model, but it doesn't necessarily make it more approachable. `git rebase main` will modify your currently checked out branch to make the commits on that branch now branch off of the current value of main. It won't update main or modify it in any other way, only your current branch. You can equally `git rebase 347ae9` to have them come off a specific commit. If you know what a tree is (in the general computer science sense, not the git term of art) it's well worth taking a little time to learn the underlying data model in my opinion.
    - MetaWhirledPeas 4y ago
      Thanks, that's useful information!
  - blep_ 4y ago
    There's also `git pull --rebase`, which is just "pull like normal, then rebase onto the thing I just pulled". Remember that it's okay to screw around and break stuff! Sometimes that's the best way to learn. Git's whole thing is tracking history, even the history of the history itself[0]. It is hard to accidentally lose something if you've committed it at least once. If you're nervous, push your branch somewhere before starting (it's not strictly necessary, but it's the easiest way to get peace of mind). Nothing you do locally will be pushed back to the remote unless you explicitly do `git push`. If you manage to screw up your branches so badly you don't know how to recover, you can just delete the local branch you broke and re-pull the remote one like it's a new branch, even if it's main/master. [0] https://ohshitgit.com/ https://ohshitgit.com/, especially the first thing there