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

[Florent Becker]

Trent W. Buck wrote:

> Eric Kow <kowey at darcs.net> writes:
> 
>> It seems to share the sort of conceptual integrity that (IMHO) makes
>> Darcs so nice to use.  It does add a bit more symmetry too
>>
>>     get   / put
>>     pull  / push
>>     fetch / send
> 
> I thought apply was the "complement" of send.

As Eric said, fetch is the symmetric of send (it's the same action, but 
initiated by receiver), while apply is what the receiver does after a 
send.
> 
>> Ganesh pointed out is that we can then explain pull as being fetch +
>> apply
> 
> hg and git have this distinction, and I really hate it.  It means that
> there are, in effect, two kinds of pull operation, and when the combined
> fetch-and-apply operation fails, I don't know if I'm supposed to use the
> fetch operation and then somehow manually resolve the problem
> (conflict?), or if there's something actually wrong with the network.

This is already the case in darcs. Except that you either have to give up 
right away or, if you want to investigate whether it's network trouble, 
try to _get_ the remote repository and then do the merge manually using 
local pulls. I'm not sure making investigation of problems harder 
qualifies as a a good way to solve them. Note that contrarily to hg fetch 
(and probably git's equivalent), *darcs fetch is a no-op as far as the 
local repository is concerned*. So it can't make anything harder, only 
give you more information to work with should you want to.
> 
> I routinely throw away my hg repos and re-record the changes against a
> fresh clone, because it's too hard to work out what I'm supposed to do
> next in order to stop the fetch-and-apply operation bitching at me.
> 
In that respect, darcs fetch won't change anything.

> Maybe Darcs can do better, but I'd like to see the use case for fetch.
> 
Darcs _is doing_ better: fetch is a /pure/ operation!

My use case was "merge on the train": i have a small set of private 
patches which i want to merge by amend-recording out any conflicts 
(semantic or syntaxic). Then I want to fetch the remote repository 
straight away, and apply the bundle patch by patch on the train while 
doing the amend-record, so out of net-connectivity. Especially, if i want 
to read the patches (as we like to do when they get sent to the list), it 
is more comfortable and lightweight than doing a local pull into a fresh 
repo, then using pull between the two local repos.

The other reason is so that I can do a quick fetch of a few patches from a 
university machine to put on my usb key so that I can apply them at home 
where the machine is unreachable. This is a case where having a 

The third case is if I want to choose now what patches I want to 
ultimately apply, but I want to apply them cautiously later, then I can 
divide the mental load by first fetching then applying, without having to 
create once more a fresh local copy from which to pull.

Maybe also they can allow Eric to send patches to the list on behalf of a 
shy/missing developer who does not want to/cannot send, but only be pulled 
from. (There might be ethic problems with that one…)

Finally, maybe I want to keep some foreign repo as an archive for myself, 
but don't see any point in applying it (but there might be at some point, 
or maybe i want to keep it along with an explanation as to why it's not 
mergeable). In that case, a bundle is much more reasonnable than a full 
repo (either for mailing to myself or keeping on a usb key).

Fetch allows you to use bundles as lightweight no-working-dir 
repositories, which are very useful in some workflows. This is because it 
makes treatment of bundles symmetric with respect to local/remote ,which 
is arguably simplifying the command set. And i have much less problems 
with having stale bundles lying around rather than stale whole repos. 

> Hm, I don't suppose you could simply express it as pull --dont-apply or
> --no-working-tree, similar to push --no-working-tree (for pushing to a
> "dumb" remote host which lacks Darcs)?

It could be called pull --dont-apply -O if you really want to avoid new 
commands. But given the symmetry with send, i find it much better to have 
a new command rather than an option which changes so radically the 
behaviour of pull. I think darcs pull -O is the bad kind of options, where 
adding -O changes the post-condition of pull. Currently, only --dry-run 
(and --xml-output ?) changes the post-condition of a command, and I think 
it is something that makes darcs simple to understand and easy to use.

Florent