4 ms·

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 com

by 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!

by 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!