[azakai]

90 days, or any other finite amount, isn't a solution for what I want. I don't need a quick undo if I erred, I want to see the development process that went into creating some code that later was committed into trunk (and perhaps much much later turned out to have a bug).

[pyre]

I always see this argument about "I want to see everything that a developer did during the development process."

In reality, 'rewriting history' comes down to things like:

* Creating a commit, then amending the commit message.

* Rebasing all of your current changes on top of a new version of master (basically re-applying all of your commits/patches on top of master).

* Fixing a typo creating a commit, and then squashing that into the original commit.

(Note: That these operations all happen on topic branches prior to being merged into master. Once you merge into master, or just publish for public consumption, then you should not be rewriting history at all.)

From my perspective, the view that git is useless because the ability to rewrite history means that valuable information is being lost is an extreme overreaction by people without much (or any) git experience.

If you want to hold this view, you should have rational examples of workflows where people will lose valuable information just as a matter of course.

[sofal]

This probably comes down to discipline, meaning that when you rewrite history in git you may want to take care that you're keeping the useful bits of it and not just squashing everything down to get fat feature-rich commits. Do you think that the history-rewriting tools in git are too often abused by the average git user such that the use of git in general has the problems you've described?

[azakai]

Not sure if I agree as to what is normal and what is abuse here. If you write some feature in a branch, and have various commits for bugfixes as you go, you might want to merge those little commits away for review as well as for bisection purposes. This seems both normal and desirable to me - no one wants to review a set of 100 patches for a feature if they contain a lot of redundancy. It's useful to do small commits as you work to get a feature stable, but it isn't useful to ask someone to review all those commits, especially if they fix a previous bug introduced by another such small commit.

However, that history can still be very useful: You might hit a variation on those bugs later, and seeing the original unrewritten history can help a lot in refreshing your memory on what you did there (and it can be even more helpful for someone else getting up to speed on the code trying to fix that bug). Losing the history after history rewriting isn't a good thing.

[sofal]

In my experience what is being reviewed by your peers are the feature diffs, not the individual commit diffs. What the actual history looks like is entirely up to you as the coder.

[gcp]

I want to see the development process that went into creating some code that later was committed into trunk (and perhaps much much later turned out to have a bug).

With your MQ workflow, you can only ever do this for your own patches.