On Thu, Feb 5, 2009 at 4:32 PM, Ketil Malde wrote:

Peter Verswyvelen writes:

...

1) hg st

darcs cha -s

That seems to list all changes in the history. hg st lists local changes only. Can be done using darcs?

Roman Cheplyaka wrote:

* Peter Verswyvelen [2009-02-05 16:35:34+0100]

...

On Thu, Feb 5, 2009 at 4:32 PM, Ketil Malde wrote:

...

Peter Verswyvelen writes:

...

1) hg st darcs cha -s

That seems to list all changes in the history.

hg st lists local changes only. Can be done using darcs?

darcs whatsnew -s

Or `darcs w -s` if you're really adverse to spelling things out ;) The changes command gives the whole history (to varying depth, verbosity,...), whereas the whatsnew command gives what things have been altered but not recorded yet. The -s flag to whatsnew says to give a summary (names of files and count of lines changed). If you leave -s off, then you'll get textual diffs of same. -- Live well, ~wren

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. Pao

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