Here is an example of why I may want to do a merge at lower granularity:
- I am working on a branch B
- I do a pull from the parent, hg pull
- I merge from the parent on to my branch B, because I am not yet ready to merge back onto the trunk (aka default branch)
- I run my tests
Now I notice that the .hgignore that I got from the parent is missing a file. I fix it in my repository, to shut it up.
Then I realize that I should push such a generic change back to the trunk asap.
What I want to do is something like"
hg clone work-repo quick-fix cd quick-fix hg update -r default hg merge -r B .hgignore # to merge just the change to .hgignore into the trunk make clean;hg purge make test hg ci ... hg pushI.e. I want to merge JUST the change to .hgignore, using "hg merge -r B .hgignore". Instead I do
hg clone work-repo quick-fix cd quick-fix hg update -r default cp ../work-repo/.hgignore . make clean;hg purge make test hg ci ... hg pushI.e. "cp ../work-repo/.hgignore ." is used instead of "hg merge -r B .hgignore". Although this works, it makes me unhappy. E.g. I may blithely have overwritten other changes, e.g. if I cloned from the master rather than the work-repo. Not to mention the fact that the "hg push" abnove would push my branch. And my teammates do not want my branch to be pushed, because it has too many fine grain checkins - they want just a single checkin message. But that's another story.
Post a Comment