Question

Using Mercurial. Working in private clones, making changes, pushing to master. Etc. That’s fine.

(By the way, let me state that I am familiar with many version control systems ranging from the classics SCCS, RCS, CVS, SVN to DVCSs like BitKeeper, Git, Mercurial, passingly familiar with Monotone, Darcs, Bzr. Not so familiar with Perforce, … I just mention this for people who may be able to explain equivalents and similarities between systems.)

Unfortunately, other members of the project think that I check in too often. I use the “check in early and often” approach, sometimes checking in more often than once every half hour. They don’t want to see so many checkin messages in the log.

NOT QUESTION: Now, I have taken to the habit of making most of my changes on branches (although hg lacks retroactive branching), summarizing all of the changes when I merge my task branches back to the trunk. hg log -b default allows them to filter out my task branches, and works okay when the merge messages are meaningful. This is not my question.

NOT QUESTION: similarly, I know how to use history editing, etc., to remove my fine granularity changesets, so that the only changesets that get pushed are coarse grain. (Although, by the way, I often find the simplest thing to do is move .hg directories around.) History editing ias annoying, but I can do it.

MY QUESTION: my question is: I would like to keep track of my fine granularity changesets and log messages, even though I don’t push them to the project master repository.
Q: how do I do this?

I.e. how do I keep two repositories tracking each other, but NOT push all of my changes to the master? Preferably tag changesrts not to be pushed. (By the way, I prefer to say “tag a revision set”. Changeset sounds too much like patch.)

The way I do it now is to have
a) the project master repo
b) my personal master repo, with all of the fine grain changes
c) one or more workspaces

Where

a) clone the project master repo to get the workspace (using hg clone, yyeah, I know)

b) work in the workspace clone with fine grain checkins (I know this)

c) push from the workspace clone to my personal master

d) and, when it comes time to push to the master, edit the history, and push that.

Two troubles:

1) conflicts merging or pushing from the workspace clone to my personal master
– more precisely, conflicts when merging from the master repo with history edited to remove the fine grain checkins, to my personal master with the fine grain checkins preserved.

2) I would like to record what has been pushed to the project master in my personal master.

—

A very simple example.

A task branch, with fine grain checkins.

o  changeset:   1022:
|  branch:      default
|  parent:      1017
|  parent:      1021
|  summary:     Merged task branch onto main, default, branch, with changes to FOO and BAR
|
o    changeset:   1021
|\   branch:      task-branch
| |  parent:      1020
| |  summary:     Merged default branch to task-branch, with changes to FOO and BAR
| |
| o  changeset:   1020
| |  branch:      task-branch
| |  parent:      1018:
| |  summary:     yet another fine grain checkin on a branch changing BAR for a second time
| |
o |  changeset:   1019
| |  branch:      task-branch
| |  parent:      1018:
| |  summary:     yet another fine grain checkin on a branch changing FOO
| |
o |  changeset:   1018
| |  branch:      task-branch
| |  parent:      1017
| |  summary:     yet another fine grain checkin on a branch changing BAR a first time
| |
|/
o  changeset:   1017
|  branch:      default
|  summary:     some other changeset on the default branch, i.e. trunk
|

The edited history, that gets pushed to the project master

o  changeset:   1018: ...changed checksumm because checksum seems to include history
|  branch:      default
|  parent:      1017
|  summary:     Merged task-branch onto main, default, branch, with changes to FOO and BAR. 
|               Removed task-branch-history from what got pushed to project repo, 
|               although may still be in personal repo
|
o  changeset:   1017
|  branch:      default
|  summary:     some other changeset on the default branch, i.e. trunk
|

The problem is, when I try to merge an updated projecvt master, that may look like

o  changeset:   1019
|  branch:      default
|  parent:      1018
|  summary:     again, some other changeset on the default branch, i.e. trunk
|
o  changeset:   1018: ...changed checksumm because checksum seems to include history
|  branch:      default
|  parent:      1017
|  summary:     Merged task-branch onto main, default, branch, with changes to FOO and BAR. 
|               Removed task-branch-history from what got pushed to project repo, ]
|               although may still be in personal repo
|
o  changeset:   1017
|  branch:      default
|  summary:     some other changeset on the default branch, i.e. trunk
|

I get conflicts, even though changeset 1018 of the project master and 1022 in the personal master are exactly the same, in terms of file contents.

I’ve tried not changing the comments in the merge changesrt that gets pushed. Doesn’t help, at least not reliably.

I wonder if the full history is included in the changesets.

I also wonder if there is some merge tool that can recognize same files, even though different history and log messages.

Answer 1

In general any workflow that involves editing history is not going to work well. It’s just not the intended work mode, and no effort goes into making it work well.

Better options for you might be:

1. Versioned Mercurial Queues (hg qinit --create-repo) which lets you make multiple commits iterating on a single patch. You get the full history in your private patch repo and they only get the qfinished whole.
2. Rather than merge back your task branch and edit history, just re-apply the change as a single commit and push that. In your example it would be hg diff -r 1017 -r 1021 | hg import, which creates a new commit (1022) that is the sum of all the changes 1018::1021, inclusive. that should merge cleanly and be pushable without ever having to push any changesets on your task-branch out to them. You can even hg commit --close-branch on the task branch
3. Tell your coworkers to STFU. 😉 High changeset granularity is good practice, and they should adapt.

Also, consider using bookmarks instead of named branches for your task-branches. Similarly the new phases feature makes it possible to mark changesets in your task branches (be they bookmark-branches or old-style named-branches) as secret so they can’t be accidentally pushed.