6 ms·

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 wh

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
seba_dos1 4y ago
> It's like using an aircraft cockpit to control the television! It's not a television though. It's a set of tools used to manipulate a tree-like data structure that you're using to store your versions and reconcile changes across multiple trees. Once you approach it with that in mind and can imagine the high level data structure in your head, using it becomes almost as natural as using a hammer for a nail. Rebasing is nothing more than changing the location a pointer ("branch") points at and then moving some nodes from one tree branch to another (in exactly the same way cherry picking works). It's really simple to visualize, you just need to have that tree in your mind already.

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

seba_dos1 4y ago

> It's like using an aircraft cockpit to control the television! It's not a television though. It's a set of tools used to manipulate a tree-like data structure that you're using to store your versions and reconcile changes across multiple trees. Once you approach it with that in mind and can imagine the high level data structure in your head, using it becomes almost as natural as using a hammer for a nail. Rebasing is nothing more than changing the location a pointer ("branch") points at and then moving some nodes from one tree branch to another (in exactly the same way cherry picking works). It's really simple to visualize, you just need to have that tree in your mind already.