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. They are still in the re

> 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. They are still in the repo, but if no treeish item (eg. a branch) points to them, then they'll eventually get garbage collected. Still, glad to see people are trying to elucidate git rebase. A small subset of its functionality is fundamental part of my workflow and I wouldn't know how I'd use Git without rebasing.

Sir_Cmpwn 7y ago
git-gc will also preserve objects which are referred to in reflogs - it doesn't just have to be tree-ish. From the man page: >git gc tries very hard not to delete objects that are referenced anywhere in your repository. In particular, it will keep not only objects referenced by your current set of branches and tags, but also objects referenced by the index, remote-tracking branches, refs saved by git filter-branch in refs/original/, or reflogs (which may reference commits in branches that were later amended or rewound). If you are expecting some objects to be deleted and they aren’t, check all of those locations and decide whether it makes sense in your case to remove those references.
- dmitryminkovsky 7y ago
  I didn’t know that! Thanks so much. I was always a bit nervous about things in my reflog being GC’d.
Dayshine 7y ago
I really don't understand why git doesn't create a tag when you rebase in case things go wrong, or more generally when doing potentially gc-able actions. Pretending the average user will know how to get things back to how they are is silly.
- mixmastamyk 7y ago
  Yep, it was designed by and for linux kernel development, that average users are using it is an accident of history.
  - irrational 7y ago
    So what are the chances that a version of Git, or something like Git, will be developed that is suitable for the average user? Someone above made a comment about how easy it is to do X in Git, and then preceded to write lines of Git commands that are as arcane as anything an alchemist could come up with. If that is easy Git, I'd hate to see what hard Git looks like.
    - mixmastamyk 7y ago
      Making it could be done, Mercurial already exists for example. Perhaps a next-gen version introduced with all the lessons learned over the last decade. Getting folks to use it would be very difficult due to network effects however.
      - muxator 7y ago
        So true. I live a mercurial life, in a git world. Thanks to hg-git, it is easy to use it and just treat the remote git repository as a black box. After having rewritten history locally (with Mercurial this is easy, powerful, safe and with a lot of tooling available) everything you need to do is doing an hg push --force. For one, hg histedit with its curses interface (default since 4.9) is sweet.
    - theoh 7y ago
      Git is really a toolkit for version control. Linus (or some other Git proponents?) distinguishes between "plumbing" and "porcelain": the infrastructure and the UI. Linus wouldn't claim to be a brilliant designer of user interfaces. It's totally conceivable that somebody could come along and develop a new way of talking about Git's functionality, implemented by a new "porcelain". Changing the vocabulary, creating a more comprehensible map of the internal logic of the thing...
      - mcguire 7y ago
        Unfortunately, none of the porcelains caught on, because all of the power users use plain git.
- jrockway 7y ago
  There is the reflog for that. https://www.atlassian.com/git/tutorials/rewriting-history/git-reflog https://www.atlassian.com/git/tutorials/rewriting-history/gi...
  - brandmeyer 7y ago
    This is technically true, and a common reposte when talking about preservation of history edits. Unfortunately, the reflog is confusing and hard to use correctly in the case of an interactive rebase with multiple steps. It is hard to figure out exactly how far back you need to go in the reflog to get to moment before the rebase started if you want to start over. It also just so happens that its when an interactive rebase goes awry that I really want to reach for the reflog to fix the damage.
    - Stratoscope 7y ago
      SmartGit does a brilliant job of integrating the reflog and stashes into the rest of Git. The history log window has a Branches panel, which is a tree view with subtrees for your local and remote branches. Below those is another subtree of any stashes you have saved, and then a Recyclable Commits checkbox. When you turn on Recyclable Commits, every commit in the reflog shows up in the history tree just like any other commit. You can see exactly where they diverge from your other branches and can work with them as you normally work with any commit. Same thing for stashes: check one and it just shows up as part of the commit tree as if it were a normal commit. I've used SmartGit for years and highly recommend it over the Git command line for the way it gives you so much more insight into the state of your repo.
    - u801e 7y ago
      > Unfortunately, the reflog is confusing and hard to use correctly in the case of an interactive rebase with multiple steps. It is hard to figure out exactly how far back you need to go in the reflog to get to moment before the rebase started if you want to start over. When you run git reflog after rebasing, you will see lines like the following: 29d82ac HEAD@{6}: rebase -i (finish): returning to refs/heads/your-branch 29d82ac HEAD@{7}: rebase -i (fixup): Commit message 2 4f8e996 HEAD@{8}: rebase -i (pick): Commit message 2 f3a954e HEAD@{9}: rebase -i (pick): Commit message 1 f74b8a5 HEAD@{10}: rebase -i (start): checkout origin/master The line listed after the one that has rebase -i (start) is the commit you were on before you started the rebase. If I screw up a rebase, then I will stash any uncommitted changes and run a git reset --hard to the commit listed below the rebase -i (start) commit I see in the reflog and start the rebase again.
- humblebee 7y ago
  feature-branch@{1} is the branch prior to the rebase. https://www.git-scm.com/docs/gitrevisions#Documentation/gitrevisions.txt-emltrefnamegtltngtemegemmaster1em https://www.git-scm.com/docs/gitrevisions#Documentation/gitr...
- mkesper 7y ago
  Create a backup branch before: git branch local/foo If you mess up too hard, check it out again.
hinkley 7y ago
> They are still in the repo, but if no treeish item (eg. a branch) points to them, then they'll eventually get garbage collected. Why else are you going to go through the trouble of rebasing master if this isn't the goal you're shooting for? I'm a big proponent of commit history hygiene but even I can't defend rebasing master except for egregious things. I think the only time I rebased master except for this was to fix a poorly executed mass file rename that broke git annotate.

Sir_Cmpwn 7y ago

git-gc will also preserve objects which are referred to in reflogs - it doesn't just have to be tree-ish. From the man page: >git gc tries very hard not to delete objects that are referenced anywhere in your repository. In particular, it will keep not only objects referenced by your current set of branches and tags, but also objects referenced by the index, remote-tracking branches, refs saved by git filter-branch in refs/original/, or reflogs (which may reference commits in branches that were later amended or rewound). If you are expecting some objects to be deleted and they aren’t, check all of those locations and decide whether it makes sense in your case to remove those references.

dmitryminkovsky 7y ago
I didn’t know that! Thanks so much. I was always a bit nervous about things in my reflog being GC’d.

Dayshine 7y ago

I really don't understand why git doesn't create a tag when you rebase in case things go wrong, or more generally when doing potentially gc-able actions. Pretending the average user will know how to get things back to how they are is silly.

mixmastamyk 7y ago
Yep, it was designed by and for linux kernel development, that average users are using it is an accident of history.
- irrational 7y ago
  So what are the chances that a version of Git, or something like Git, will be developed that is suitable for the average user? Someone above made a comment about how easy it is to do X in Git, and then preceded to write lines of Git commands that are as arcane as anything an alchemist could come up with. If that is easy Git, I'd hate to see what hard Git looks like.
  - mixmastamyk 7y ago
    Making it could be done, Mercurial already exists for example. Perhaps a next-gen version introduced with all the lessons learned over the last decade. Getting folks to use it would be very difficult due to network effects however.
    - muxator 7y ago
      So true. I live a mercurial life, in a git world. Thanks to hg-git, it is easy to use it and just treat the remote git repository as a black box. After having rewritten history locally (with Mercurial this is easy, powerful, safe and with a lot of tooling available) everything you need to do is doing an hg push --force. For one, hg histedit with its curses interface (default since 4.9) is sweet.
  - theoh 7y ago
    Git is really a toolkit for version control. Linus (or some other Git proponents?) distinguishes between "plumbing" and "porcelain": the infrastructure and the UI. Linus wouldn't claim to be a brilliant designer of user interfaces. It's totally conceivable that somebody could come along and develop a new way of talking about Git's functionality, implemented by a new "porcelain". Changing the vocabulary, creating a more comprehensible map of the internal logic of the thing...
    - mcguire 7y ago
      Unfortunately, none of the porcelains caught on, because all of the power users use plain git.
jrockway 7y ago
There is the reflog for that. https://www.atlassian.com/git/tutorials/rewriting-history/git-reflog https://www.atlassian.com/git/tutorials/rewriting-history/gi...
- brandmeyer 7y ago
  This is technically true, and a common reposte when talking about preservation of history edits. Unfortunately, the reflog is confusing and hard to use correctly in the case of an interactive rebase with multiple steps. It is hard to figure out exactly how far back you need to go in the reflog to get to moment before the rebase started if you want to start over. It also just so happens that its when an interactive rebase goes awry that I really want to reach for the reflog to fix the damage.
  - Stratoscope 7y ago
    SmartGit does a brilliant job of integrating the reflog and stashes into the rest of Git. The history log window has a Branches panel, which is a tree view with subtrees for your local and remote branches. Below those is another subtree of any stashes you have saved, and then a Recyclable Commits checkbox. When you turn on Recyclable Commits, every commit in the reflog shows up in the history tree just like any other commit. You can see exactly where they diverge from your other branches and can work with them as you normally work with any commit. Same thing for stashes: check one and it just shows up as part of the commit tree as if it were a normal commit. I've used SmartGit for years and highly recommend it over the Git command line for the way it gives you so much more insight into the state of your repo.
  - u801e 7y ago
    > Unfortunately, the reflog is confusing and hard to use correctly in the case of an interactive rebase with multiple steps. It is hard to figure out exactly how far back you need to go in the reflog to get to moment before the rebase started if you want to start over. When you run git reflog after rebasing, you will see lines like the following: 29d82ac HEAD@{6}: rebase -i (finish): returning to refs/heads/your-branch 29d82ac HEAD@{7}: rebase -i (fixup): Commit message 2 4f8e996 HEAD@{8}: rebase -i (pick): Commit message 2 f3a954e HEAD@{9}: rebase -i (pick): Commit message 1 f74b8a5 HEAD@{10}: rebase -i (start): checkout origin/master The line listed after the one that has rebase -i (start) is the commit you were on before you started the rebase. If I screw up a rebase, then I will stash any uncommitted changes and run a git reset --hard to the commit listed below the rebase -i (start) commit I see in the reflog and start the rebase again.
humblebee 7y ago
feature-branch@{1} is the branch prior to the rebase. https://www.git-scm.com/docs/gitrevisions#Documentation/gitrevisions.txt-emltrefnamegtltngtemegemmaster1em https://www.git-scm.com/docs/gitrevisions#Documentation/gitr...
mkesper 7y ago
Create a backup branch before: git branch local/foo If you mess up too hard, check it out again.

hinkley 7y ago

> They are still in the repo, but if no treeish item (eg. a branch) points to them, then they'll eventually get garbage collected. Why else are you going to go through the trouble of rebasing master if this isn't the goal you're shooting for? I'm a big proponent of commit history hygiene but even I can't defend rebasing master except for egregious things. I think the only time I rebased master except for this was to fix a poorly executed mass file rename that broke git annotate.