[darcs-users] [patch39] Refactor Darcs.Commands.Pull (and 1 more)

[Eric Kow]

On Wed, Nov 04, 2009 at 23:19:30 +0000, Ian Lynagh wrote:
ian> I don't see why you need the --dont-apply. After all, you don't have to
ian> say "darcs send --dont-email -o".

This may just be another perspective shift.  If you focus on the state
of the local/remote repository as being the most important
post-condition, then being nervous about pull -o makes a certain amount
of sense.

Using that perspective, the fact that 'send' generates an email and
'send -o' should not really faze us because the most important condition
(the one I claim users would be most anxious about) remains the same
(the remote repository is untouched).

ian> I'm currently leaning towards "darcs pull -o" (in which case
ian> "darcs push -o" ought to do what "darcs send -o" currently does).
 
florent> I think darcs pull -O is the bad kind of options, where 
florent> adding -O changes the post-condition of pull.

For what it's worth, I agree with Florent on the principle that
introducing a new command (or flag) is a lesser evil than introducing
subtle complexities.  I'd rather the pull command be predictable in the
casual user's mental model than avoid a new command.  And while I'm
ping-ponging between the two views, I could be persuaded that pull -o
would introduce a worrying subtlety.

ian> "pull" and "pull -o" both put some patches into a repository. In the
ian> first case it is a "directory format" repository, and in the second case
ian> a "file format" repository.

While this may be true, it would require users to do a perspective
shift.  I suspect (without actually knowing) that most people just have
a mental model that "pull updates this repo" and "push updates that
repo"; introducing this would be effectively asking them to shift to a
new model.  Consider also that pull and push touch the working
directory.

ian> That's similar reasoning to why I think pull and apply should be merged.
ian> Both are just applying patches from a repository, just stored in
ian> different formats.

Well I believe that the reasoning on pull/apply being merged
should be separated from the reasoning about pull -o.

Put it this way: suppose bundles did not exist.  The the pull -o and the
push -o flags would really be shorthand for the hypothetical flags

 pull --to-third-repo
 push --to-third-repo

where pull takes patches from the remote repo, against the *local*
repo context and creates a new 'third' repository which consists
of the local patches plus the new remote patches.  Similarly, push
would be instantiating a third repo consisting of the remote context
plus some local patches.

Do you see what I'm getting at?  While it's easy for us as darcs hackers
to think in terms of these three repos (the context repo, the source
repo and now the third affected repo), introducing pull -o would be
asking users who are already comfortable thinking only in terms of a
source repo and a target repo (ie. context + affected), I worry that
asking people to mentally divide 'target' repo into 'context + affected'
would just make everybody's head explode.

Am I being too pessimistic here?

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.osuosl.org/pipermail/darcs-users/attachments/20091105/f5b70fd0/attachment.pgp>