5 ms·

Why would you rewrite history? Don't be ashamed.

by Fenume 11y ago

allersj 11y ago
For me, I tend to commit frequently, sort of like my obsession with constantly hitting CTRL-S while working in an IDE. Before I push my changes I like to squash the commits into more cohesive commits. If anything, I think it makes it easier on my colleagues for code review.
- jordigh 11y ago
  I do the same in hg. I do `hg amend` all the time to keep adding changes to my commit. At the end I may selectively undo some changes with `hg uncommit --interactive` or `hg uncommit --all` and redo the whole thing piecemeal with `hg commit --interactive` in order to slowly split up my work into several commits. Evolve makes it really easy to keep (and ignore!) a meta-history of all of my editions, with a clear lineage of which new commit replaced which prior commit. I may also rebase my work onto the latest head at the end (not to be confused with git HEAD). And all of this with a very nice interface. It's always --interactive, not sometimes --patch and sometimes --interactive.
  - allersj 11y ago
    Thanks, that is useful to know. Mercurial was my first DCVS and I loved using it, but I only touched on the basic features. I stopped using it when I switched jobs and to become proficient with git. I'll have to give it another try with one of my side projects.
- limeyx 11y ago
  Thats not the same kind of rewriting history because its local to you and hasn't yet been pushed out to others. Git allows you to push commits to other people and then rewrite history, which is different
  - allersj 11y ago
    Ah, gotcha. Thanks for the clarification. I knew that pushing a rewritten history was possible, but I can't think of any situation where I would ever want to do that.
mpdehaan2 11y ago
Rebase is awesome. Here's an example. http://michaeldehaan.net/post/116465000577/understanding-when-to-use-git-rebase http://michaeldehaan.net/post/116465000577/understanding-whe...
- leni536 11y ago
  No it's not, it rewrites and destroys history. The problem it solves is "keeping the history clean", when actually it's not what you want. You don't see your history, you see logs and diffs. So you want to keep your logs and diffs clean. There should be an other solution to this other than simply removing/merging commits and eventually removing information with it.
  - brusch64 11y ago
    We had the same discussion in my office. If I am developing a feature (in a separate branch) - why shouldn't I rebase to make a single commit out of this feature ? Is this really interesting for you that it took me 10 commits to do sO ? Even if one of the commits was just a "I have to switch an fix a bug and want to commit before switching to another branch" - commit ? I think there is nothing wrong with rebasing and to merge commits before pusing them.
    - leni536 11y ago
      I don't think it's wrong when using git. However I think it shouldn't be designed like this though. Git rebase should add metadata not remove them. Essentially you rebase because you want to hide certain details because they are not important. Rebase could do one or more actual merges instead and mark certain commits not important so they wouldn't show up in logs by default. AFAIK rebase is the only operation that happily destroys your history without any --force or --hard option. It always disturbed me. There is a legitimate usage of rebase though: you really want something removed from history. Like you accidentally committed a secret, inappropriate message or you just want to fix a typo in the last commit.
      - 11y ago

Why would you rewrite history? Don't be ashamed.

by Fenume 11y ago

Why would you rewrite history? Don't be ashamed.

For me, I tend to commit frequently, sort of like my obsession with constantly hitting CTRL-S while working in an IDE. Before I push my changes I like to squash the commits into more cohesive commits. If anything, I think it makes it easier on my colleagues for code review.

jordigh 11y ago
I do the same in hg. I do `hg amend` all the time to keep adding changes to my commit. At the end I may selectively undo some changes with `hg uncommit --interactive` or `hg uncommit --all` and redo the whole thing piecemeal with `hg commit --interactive` in order to slowly split up my work into several commits. Evolve makes it really easy to keep (and ignore!) a meta-history of all of my editions, with a clear lineage of which new commit replaced which prior commit. I may also rebase my work onto the latest head at the end (not to be confused with git HEAD). And all of this with a very nice interface. It's always --interactive, not sometimes --patch and sometimes --interactive.
- allersj 11y ago
  Thanks, that is useful to know. Mercurial was my first DCVS and I loved using it, but I only touched on the basic features. I stopped using it when I switched jobs and to become proficient with git. I'll have to give it another try with one of my side projects.
limeyx 11y ago
Thats not the same kind of rewriting history because its local to you and hasn't yet been pushed out to others. Git allows you to push commits to other people and then rewrite history, which is different
- allersj 11y ago
  Ah, gotcha. Thanks for the clarification. I knew that pushing a rewritten history was possible, but I can't think of any situation where I would ever want to do that.

mpdehaan2 11y ago

Rebase is awesome. Here's an example. http://michaeldehaan.net/post/116465000577/understanding-when-to-use-git-rebase http://michaeldehaan.net/post/116465000577/understanding-whe...

leni536 11y ago
No it's not, it rewrites and destroys history. The problem it solves is "keeping the history clean", when actually it's not what you want. You don't see your history, you see logs and diffs. So you want to keep your logs and diffs clean. There should be an other solution to this other than simply removing/merging commits and eventually removing information with it.
- brusch64 11y ago
  We had the same discussion in my office. If I am developing a feature (in a separate branch) - why shouldn't I rebase to make a single commit out of this feature ? Is this really interesting for you that it took me 10 commits to do sO ? Even if one of the commits was just a "I have to switch an fix a bug and want to commit before switching to another branch" - commit ? I think there is nothing wrong with rebasing and to merge commits before pusing them.
  - leni536 11y ago
    I don't think it's wrong when using git. However I think it shouldn't be designed like this though. Git rebase should add metadata not remove them. Essentially you rebase because you want to hide certain details because they are not important. Rebase could do one or more actual merges instead and mark certain commits not important so they wouldn't show up in logs by default. AFAIK rebase is the only operation that happily destroys your history without any --force or --hard option. It always disturbed me. There is a legitimate usage of rebase though: you really want something removed from history. Like you accidentally committed a secret, inappropriate message or you just want to fix a typo in the last commit.
    - 11y ago