Thomas Davie wrote:
On 6 Feb 2009, at 10:12, Paolo Losi wrote:
Henning Thielemann wrote:
4) hg commit -m "message"
this commits my changes locally. I always do this before pulling since
then I'm sure my changes are saved in the case a merge goes wrong.
In old darcs its precisely the other way round. Since it is so slow on
merging ready patches, you better merge uncrecorded changes.
IMO pulling & merging before commit is a good practise also for hg:
it avoids a (very often useless) merge commit in the history.
I don't understand this view. Isn't the point of a commit that you flag
working points. In each branch, before you merge (hopefully) you have a
working repository, so flag it as such, and commit. When you merge, you
may or may not have a working repository, fix it until it is, and merge.
I would never do a merge without the two branches I was merging having a
commit just before the merge.
Bob
I think you're right. but:
- if you synch with the central repo at every commit you usually have
a sort of out of band protocol with your peers for avoiding conflicts
and in case of conflicts the manual merge is easy (if you occasionally
merge unrelated branches that is obviously a different story)
- the problem with mercurial is that it doesn't allow to amend history
(you cannot afford to "merge" the first commit with the
"merge" commit) and the commit history becomes cluttered.
That's the reason why I prefer (in the case
of commit/sync/commit/sync... scenario) pulling and updating
before committing.
AFAIK darcs and git doesn't have this problem, so the
approach your suggesting should be the best in any case.
I'm an "old" user of mercurial but I'm starting seeing some
shortcomings with respect to git (and probably darcs).
I really hope there will be some sort of convergence on a de facto
DVCS soon in the opensource community :-)
Paolo
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
