CODEWITHSUNDEEP
mercurialrepositoryrevision-history
user462982
user462982

Reputation: 1645

Mercurial: Multiple commit histories

We collaborate with a third party (contractor) using our "master" mercurial repo on a project for a client. It appears we get a very cluttered commit history (including trail and errors). We'd like to hide these details from the client (i.e. not reveal the whole commit history). However, at the same time, we would like to use the repo to deliver our results to the client (in a orderly and more "condensed" form). Is there a recommend work flow (and tooling/hg commands) that suit this purpose?

Upvotes: 0

Views: 57

Answers (2)

Lazy Badger
Lazy Badger

Reputation: 97280

Using MQ is good way, using MQ with TortoiseHG is also easy way to rewriting history.

In your case you can create, have and maintain two related repository: "Dirty" and "Clean"

  • Clean can be created as clone of used in work Dirty (and doesn't cloned after it to developers)
  • In Clean you'll enable MQ extension and rewrite history in Mercurial's CLI (or with TortoiseHG)

Upvotes: 1

Ry4an Brase
Ry4an Brase

Reputation: 78330

There's no good/easy way to do this, but there are plenty of bad/hard ways to do it. Here are a few:

  1. Internally do all your work in Mecurial Queues and then qfinish the changesets only when done / perfect. Give them access to the repo but not the mq repo (they're optionally, separately versioned)

  2. Use things that rewrite history like commit --ammend or histedit's collapse command to alter the repo after you like it (drawback, everyone on your team has to delete and reclone)

  3. create a totally separate repo for them and when you're ready to give them a drop copy in a hg archive from your repo and commit

I don't think any of those are worth the hassle of hiding normal software development work, but there you go.

Upvotes: 2

Related Questions