[darcs-users] Resolving conflicts in a push only repo

[Jamie Webb]

On Mon, Nov 07, 2005 at 11:31:57AM -0600, Richard A. Smith wrote:
> Darcs by default won't allow a push to cause a conflict.  Thats why I 
> went to the master and did a pull from my local.  So if I do a record 
> I'm going to introduce a local modification into the master repo.  And 
> I'm looking for advice on if thats bad or not.

It's not the end of the world. Nothing bad is likely to happen. It's
just not the recommended workflow. Don't do it again :-). Reason
being that by permitting a conflict on the master in the first place,
you have the potential to infuriate your collaborators by propagating
conflicts to their repos.

It's that conflict on the master which is the problem, not the fact
that you are recording a patch on the master. Rule of thumb: if you
have to manually SSH to the master for /any reason, including
pulls/, you are probably doing something bad.

I remember getting into horrible situations before Darcs started
preventing conflicting pushes, where several developers would get the
conflict, resolve it, and then we'd have to resolve a bunch of
conflicting conflict resolutions. It's a feature. Don't try to work
around it.

The preferred route is to do exactly what the CVS/SVN people do: pull
the conflict into your local repo, resolve it there, and then push the
resolution up to the master along with your original patch. That way
no-one else ever sees the conflict.

In general, if you're working with a centralised repo, it's helpful to
always pull before you push (but /after/ you record, so that it's easy
to reverse the pull if you decide you didn't want that patch after
all) just as with CVS/SVN one tends to update before committing.

If the pull flags up conflicts, you then have the choice of creating a
new patch to remedy them, or amend-recording your existing patch
(/only/ since you haven't yet pushed it anywhere).

-- Jamie Webb