5 ms·

> No commits are harmed in the operation of `git rebase`. All the commits you had in the repo before the rebase are still in the repo. The same changes are sti

by dan00 7y ago

> No commits are harmed in the operation of `git rebase`. All the commits you had in the repo before the rebase are still in the repo. The same changes are still in the repo (edit: I should have said branch here), but not the same commits, because the parents and children change and therefore the hash of the commits. It is very important to be aware that the history is changed, because the previous history can not be without issues merged with the new one, which is the main pain point and the most problems that arise from a rebase.

Sir_Cmpwn 7y ago
No, gwright is correct, and my guide fails to capture the nuance of this detail. Each commit has a link to its parent, and represents the tip of a linked list. .git/objects is a heap of all commits (and other objects), and .git/refs contains a list commit IDs that define each head (e.g. master). git rebase will often introduce new versions of a commit to the heap and update the heads to reference new histories, but the old commits stick around and can be accessed through the reflog - with their full original history intact.
- PhaseLockk 7y ago
  My understanding is that the original commits will eventually be cleaned up during garbage collection if there is nothing else pointing to them. Is that correct?
- dan00 7y ago
  It is right that the previous commits are still there in the repo, but from the point of git they are garbage now and going to be removed. The point are the commits reachable now from the branch.
  - Sir_Cmpwn 7y ago
    git-gc will save stuff in your reflogs. It works pretty hard to avoid removing objects which are referenced by anything at all.
    - dan00 7y ago
      Ah ok, the point about reflog makes sense. Thanks!
  - dahart 7y ago
    What’s the matter with reachable and unreachable commits? Commits no longer needed should be unreachable and cleaned eventually, that’s a feature. Git is fantastic about keeping the unreachable commits for long enough that should I actually need them for any reason, they’re usually there. The default is 90 days. The number of times I need to dig into the reflog for any reason is very low, and always because I made a mistake. The number of times I’ve lost a commit irrevocably because it was cleaned before I needed it is 0.
    - ZeroGravitas 7y ago
      > The number of times I need to dig into the reflog for any reason is very low, and always because I made a mistake. A good UI should allow you to recover from mistakes. Like the trashcan vs rm example everyone is using. It's good that git doesn't permanently delete stuff, it's bad that you need to be a relative expert to know that. If git branch showed rebased branches and told you they would disappear in x days then beginners might feel less fear and embrace the power of git faster.
      - dahart 7y ago
        This is a little hyperbolic though, because git does have UI above the reflog designed for catching the most common mistakes. The reflog is a powertool, it is not the default UI, and most people never need to look at the reflog. git rebase has an "abort" feature when you need to redo it. git has tag & branch & stash features if you want to save what you're doing before you rebase. The problem with keeping and showing rebased branches are that 1- you don't need them after the rebase is successful. You only need them when the rebase is going badly, and 2- you'd have a lot of unnecessary noise pile up. I often rebase multiple times before every push. I don't want to see them all, you probably don't either. That said, I fully agree that git's UI could be better and help beginners feel less fear!
- AlexTWithBeard 7y ago
  the old commits stick around They kinda are, but that's like saying that deleted files are not deleted, but stick around for a while. While technically true, for most practical purposes _rm <file>_ deletes the file. The fact that each and every "git 101" manual has to explain how to recover deleted commits, means something is wrong. It's like saying: "Here's the key, and in case it doesn't work there's a pry bar in the garage". This is usually a pretty good indicator that the lock is broken.
  - pkamb 7y ago
    Just have a backup branch at the same commit as the branch you're about to rebase. It'll keep all of the pre-rebase commits on that standard branch. No need for the reflog or "trashcan" or anything weird like that.
  - dahart 7y ago
    Comparing lost commits to rm isn’t a good analogy. Git has a very good safety net when you know how to use it. The problem is knowing how to use it, not that it’s not there. It’s a legitimate point that git’s UI sucks, that’s what’s wrong, and everyone agrees. But learn how to use the reflog and you will see the light!
    - pmiller2 7y ago
      Git has very good safety even if you don’t know how to use it, provided you commit when you want something to be saved and you don’t rm the whole repo at the first sign of trouble.
      - AlexTWithBeard 7y ago
        I think my issue is that most people should not even know how this safety net works. But every other question about git on stack exchange seems to be "how do I recover from a failed rebase".
        dahart 7y ago
dahart 7y ago
> previous history can not be without issues merged with the new one I don’t understand what you mean. Why would you rebase a branch and then merge the rebased version with the old version of that branch? I don’t think that’s a common workflow, that is a specific case you should avoid. Typical use of rebase to clean up the unpushed portion of a personal repo before pushing doesn’t normally cause any problems. The main thing that pops up for me is trying to re-order my own dependent commits when I forget that one commit touched the same code as another. Squashing them during the rebase is the easy fix.

by dan00 7y ago

Sir_Cmpwn 7y ago

No, gwright is correct, and my guide fails to capture the nuance of this detail. Each commit has a link to its parent, and represents the tip of a linked list. .git/objects is a heap of all commits (and other objects), and .git/refs contains a list commit IDs that define each head (e.g. master). git rebase will often introduce new versions of a commit to the heap and update the heads to reference new histories, but the old commits stick around and can be accessed through the reflog - with their full original history intact.

PhaseLockk 7y ago
My understanding is that the original commits will eventually be cleaned up during garbage collection if there is nothing else pointing to them. Is that correct?
dan00 7y ago
It is right that the previous commits are still there in the repo, but from the point of git they are garbage now and going to be removed. The point are the commits reachable now from the branch.
- Sir_Cmpwn 7y ago
  git-gc will save stuff in your reflogs. It works pretty hard to avoid removing objects which are referenced by anything at all.
  - dan00 7y ago
    Ah ok, the point about reflog makes sense. Thanks!
- dahart 7y ago
  What’s the matter with reachable and unreachable commits? Commits no longer needed should be unreachable and cleaned eventually, that’s a feature. Git is fantastic about keeping the unreachable commits for long enough that should I actually need them for any reason, they’re usually there. The default is 90 days. The number of times I need to dig into the reflog for any reason is very low, and always because I made a mistake. The number of times I’ve lost a commit irrevocably because it was cleaned before I needed it is 0.
  - ZeroGravitas 7y ago
    > The number of times I need to dig into the reflog for any reason is very low, and always because I made a mistake. A good UI should allow you to recover from mistakes. Like the trashcan vs rm example everyone is using. It's good that git doesn't permanently delete stuff, it's bad that you need to be a relative expert to know that. If git branch showed rebased branches and told you they would disappear in x days then beginners might feel less fear and embrace the power of git faster.
    - dahart 7y ago
      This is a little hyperbolic though, because git does have UI above the reflog designed for catching the most common mistakes. The reflog is a powertool, it is not the default UI, and most people never need to look at the reflog. git rebase has an "abort" feature when you need to redo it. git has tag & branch & stash features if you want to save what you're doing before you rebase. The problem with keeping and showing rebased branches are that 1- you don't need them after the rebase is successful. You only need them when the rebase is going badly, and 2- you'd have a lot of unnecessary noise pile up. I often rebase multiple times before every push. I don't want to see them all, you probably don't either. That said, I fully agree that git's UI could be better and help beginners feel less fear!
AlexTWithBeard 7y ago
the old commits stick around They kinda are, but that's like saying that deleted files are not deleted, but stick around for a while. While technically true, for most practical purposes _rm <file>_ deletes the file. The fact that each and every "git 101" manual has to explain how to recover deleted commits, means something is wrong. It's like saying: "Here's the key, and in case it doesn't work there's a pry bar in the garage". This is usually a pretty good indicator that the lock is broken.
- pkamb 7y ago
  Just have a backup branch at the same commit as the branch you're about to rebase. It'll keep all of the pre-rebase commits on that standard branch. No need for the reflog or "trashcan" or anything weird like that.
- dahart 7y ago
  Comparing lost commits to rm isn’t a good analogy. Git has a very good safety net when you know how to use it. The problem is knowing how to use it, not that it’s not there. It’s a legitimate point that git’s UI sucks, that’s what’s wrong, and everyone agrees. But learn how to use the reflog and you will see the light!
  - pmiller2 7y ago
    Git has very good safety even if you don’t know how to use it, provided you commit when you want something to be saved and you don’t rm the whole repo at the first sign of trouble.
    - AlexTWithBeard 7y ago
      I think my issue is that most people should not even know how this safety net works. But every other question about git on stack exchange seems to be "how do I recover from a failed rebase".
      - dahart 7y ago

dahart 7y ago

> previous history can not be without issues merged with the new one I don’t understand what you mean. Why would you rebase a branch and then merge the rebased version with the old version of that branch? I don’t think that’s a common workflow, that is a specific case you should avoid. Typical use of rebase to clean up the unpushed portion of a personal repo before pushing doesn’t normally cause any problems. The main thing that pops up for me is trying to re-order my own dependent commits when I forget that one commit touched the same code as another. Squashing them during the rebase is the easy fix.