Jason Dagit <[email protected]> writes:
> It sounds to me like, darcs partially decouples this. It merges them
> in and keeps them separate, but it does so over top of your working
> copy. So if you have something you're working on it could get
> conflict markers over top of it.
In the past I have done
darcs pull --allow-conflicts --all --union foo bar baz
to fetch all patches from some other places into a local copy. I ignore
the working tree in that local copy (cf. --no-working-tree), and simply
use it as a cache from which to pull patches into my "real" repositories
when offline.
> In darcs, I think the best practice is to record your local changes
> first.
In general, I agree, but I would be very strongly opposed to Darcs
*enforcing* (as opposed to recommending) this workflow. "hg fetch" does
that to me, and its amazingly annoying.
> Perhaps we should consider refining darcs's UI in this case. For
> example, what if darcs could warn you when you have unrecorded changes
> locally before allowing you to pull in new changes? Here is an
> example to illustrate my point using a mocked up session:
>
> darcs pull foo
> Unrecorded local changes detected. How to proceed? [i,r,q,?]
> ?
> i: ignore the unrecorded changes and proceed with the pull.
> r: record the changes first and then proceed with the pull (Note: You
> will be able to unrecord or amend-record your changes later.)
> q: quit
> ?: help
For me, this would be disruptive and annoying. I vastly prefer to
simply have --dont-allow-conflicts in my .darcs/defaults (and it should
be the default, IMO) -- if I'm working on one part of the repo, Darcs
should not pester me if I try to pull in someone else's work on another
part of the repo -- not until they conflict, anyway.
For at least one repo (my dotfiles), I effectively NEVER have a state
where all changes to the working tree are recorded.
I would not object to a non-interactive "warning: unrecorded changes".
> With a corresponding --dont-warn-unrecorded that can be set in the
> user's defaults for scripts and people who think this feature is
> obnoxious.
Fine, except for bloating the number of options :-)
_______________________________________________
darcs-users mailing list
[email protected]
http://lists.osuosl.org/mailman/listinfo/darcs-users
