Recently I switched to Mercurial
from Subversion
and was excited to learn about local commits
.
However I had a different workflow in mind than how it currently works.
I perform very frequent commits, ie. my one single push
to a central repository involves 5-6 local commit changesets
each with their commit log
. However I wouldn't care to see/revert to these individual commits
later in th开发者_开发百科e future but to my single push
. I was hoping to see this push
operation as an abstraction for my multiple local commits
with a single push log
and all changesets merged into one changeset
.
All commits are the same, there is no distinction between "local" or "remote" commits instead of the computer where they are stored.
Also large commits (what you want to do) are usually a bad idea and make the changes harder to understand. Therefore it is better to commit early and commit often, also push to other developers (pushing does not mean merging!), so that they may use your code and merge when things things need to be combined. If you are developing a larger functionality then you may also create branches and when they are finished merge them.
It highly depends on what you want to achieve, but you can use the MQ extension to modify the local commits (which MQ convert into patches) you do in the first place.
You can fold two patches into one, or refresh an existing patch, adding more changes.
There are two philosophies about what history is ideal:
- commits should be left as they were made, intact, or
- history should contain commits as if they were made in an ideal world, by omniscient developers.
MQ works best if you like the latter approach.
精彩评论