[gcp]

Mercurial Queues are different from git branches, not just "worse".

Mercurial Queues are bolted onto Mercurial and you can often see the cracks. Merging is my pet peeve which I've already mentioned. I think it's not controversial to say that it's a pain? I think that, in true Mercurial tradition, there's an extension in development for it now...

So why do we need to deal with this bolt-on and the resulting pain? Because Mercurial branches aren't good enough, or at least can't adequately support the workflow people need. Compare the amount of Mercurial users using mq to the amount of git users using quilt or equivalents.

I don't disagree with the abstract principle of operation of Mercurial Queues. I disagree with Mercurial as it is.

However, if you use git to rewrite the history of your branch as part of your development process, AFAIK there is no way to go back in time and instantly see what your branch looked like at time K in the past, because history has been rewritten.

1) It may be possible to do this with reflog. I don't know for sure because I haven't needed to do this yet. (I think the main problem is that by default reflog purges old history at some point)

2) You can simply create more branches as you go. i.e. replace qcommit by git checkout -b etc. Then push the final ones.

[__david__]

> 1) It may be possible to do this with reflog. I don't know for sure because I haven't needed to do this yet. (I think the main problem is that by default reflog purges old history at some point)

I've done this when I was submitting patches to a large git based project (perl5). The trick is to to the rebase and then re-tag your old branch. That way the old work is there if you need to reference it. Since it has a real live tag, it will not get garbage collected.

[azakai]

I agree that MQ has some pain points. Merging, as you say.

But git branches also have pain points. The only way to save history from before you rewrite history is to save branches, as you mentioned - but doing that manually every time you rewrite history is a pain.

[sofal]

Actually the history is kept by reflog for 90 days by default I believe (and you can change this). This covers the large majority of cases where you have completely screwed up your history rewriting and need to go back to a state you remembered you were in.

[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.

[alwillis]

Learn how to use rebase to merge your MQ patches with changes from someone else: http://www.screenr.com/1Hx