3 ms·

Genuine Curiosity: How else can you destroy/rewrite history in git besides a force push and gc?

Someone 13y ago
I have almost no experience with git, but http://git-scm.com/book/ch6-4.html http://git-scm.com/book/ch6-4.html mentions several (and doesn't mention force push) Also, you don't need to do the gc; git will run it automatically for you, eventually.
csense 13y ago
The one I use most often: git commit --amend will add any currently staged changes to your last commit, and allow you to change the commit message. In the words of the manpage, git rebase origin/master will "forward-port local commits to the updated upstream head." In other words, if you have local commits, it throws them away and replaces them with different commits. This allows you to avoid making merge commits. Interactive mode rebase, for example: git rebase -i HEAD~4 will let you rewrite the last commits. You can use it for lots of things like: changing commit messages, changing commit contents, add new commits in the middle of a sequence, squash multiple commits into one. git filter-branch can be used to apply a script to all the commits in a branch. Situations where it's useful: "I don't like the username/email I was using, it didn't matter when it was just a local repo for me only, but when I publish it I want to change it", or "Oh crap for 2 years we've had files in our repo we don't own the copyright for, we need to get it out of our history before somebody sues us!" FYI, when people talk about "destroying/rewriting history," they're usually referring to the above commands that take a bunch of commits and replace them with different commits. I wouldn't call push --force, reset --hard and gc commands that destroy history; instead I think of them as commands that help you work with different views of history. E.g. doing git rebase -i followed by git push -f, the rebase is what actually rewrites history while the git push -f merely propogates the rewritten history to a remote repo.
- skyebook 13y ago
  Ah sure, amending commits doesn't work once you've pushed it to a remote branch though (IIRC). Though this distinction is one of the things brought up in that email, that hg treats it all as one history. That is kind of nice.

I have almost no experience with git, but http://git-scm.com/book/ch6-4.html http://git-scm.com/book/ch6-4.html mentions several (and doesn't mention force push) Also, you don't need to do the gc; git will run it automatically for you, eventually.

csense 13y ago

The one I use most often: git commit --amend will add any currently staged changes to your last commit, and allow you to change the commit message. In the words of the manpage, git rebase origin/master will "forward-port local commits to the updated upstream head." In other words, if you have local commits, it throws them away and replaces them with different commits. This allows you to avoid making merge commits. Interactive mode rebase, for example: git rebase -i HEAD~4 will let you rewrite the last commits. You can use it for lots of things like: changing commit messages, changing commit contents, add new commits in the middle of a sequence, squash multiple commits into one. git filter-branch can be used to apply a script to all the commits in a branch. Situations where it's useful: "I don't like the username/email I was using, it didn't matter when it was just a local repo for me only, but when I publish it I want to change it", or "Oh crap for 2 years we've had files in our repo we don't own the copyright for, we need to get it out of our history before somebody sues us!" FYI, when people talk about "destroying/rewriting history," they're usually referring to the above commands that take a bunch of commits and replace them with different commits. I wouldn't call push --force, reset --hard and gc commands that destroy history; instead I think of them as commands that help you work with different views of history. E.g. doing git rebase -i followed by git push -f, the rebase is what actually rewrites history while the git push -f merely propogates the rewritten history to a remote repo.

skyebook 13y ago
Ah sure, amending commits doesn't work once you've pushed it to a remote branch though (IIRC). Though this distinction is one of the things brought up in that email, that hg treats it all as one history. That is kind of nice.