hg equivalent of git push -f?

[Arne Babenhauserheide]

Jeremy . writes:

> How do regular hg users handle such a workflow? I presume not with a hook, although that would solve my problem as I described it.

I normally do not worry about cluttering history: If I think the test
should run, the code belongs into the history. Since Mercurial preserves
the branch information, that is much more manageable than in Git (you
can always query for the diff of any past feature - but also for all
steps leading to it).

If I had to do heavy history rewriting (as you describe it), I’d use
mutable (convenient, safe, collaborative) or mercurial queues (explicit
patch development). You can share a patch queue and have that tested.

For small scale history rewriting (submitting a patch), I sometimes
simply use hg diff -r $OLD -r $NEW > change.diff

For interfacing with a subversion repository (via hgsubversion) I
created a dedicated "feature_refactored" branch in which I reworked the
history. That was after successful testing, however, splitting off code
review and testing from upstreaming.

> The requirements are:
>
> 1) Programmers commit their work to feature branches.
>
> 2) These feature branches are regularly pushed to a central server for CI or so that others can view the code.
>
> 3) As this code is work in progress they regularly use git commit --amend && git push -f to update the server copy without cluttering history.

With this method, other people cannot easily improve the code without
getting into conflicts / having to rebase repeatedly.

"I improved something" isn’t easily possible, though you can drop a hint
via another channel showing how an improvement could be made.

That’s why I’d ever use mutable (which solves that problem) or prefer
cluttering history and adding an explicit patch-creation step if it is
needed.

Best wishes,
Arne