[darcs-devel] darcs-git merge

[Juliusz Chroboczek]

>> > Most notably, I'd like to make GitSlurpy be a
>> > {Writeable,Readable}Directory,

>> Could you explain that?

> data SlurpMonad a = SM ((Either String Slurpy)
>                         -> Either String (Slurpy, a))

Aha.

> apply_to_slurpy :: Patch -> Slurpy -> Maybe Slurpy
> apply_to_slurpy p s = case withSlurpy s (apply p) of
>                       Left _ -> Nothing
>                       Right (s', ()) -> Just s'

(Enlightening took a good few minutes.)

There's one trivial change that I'd like to make to slurpies which
might conflict with your work; so I guess I'd rather outline it now.
We've already discussed it earlier, but I've changed the design
slightly.  The plan is

  data SlurpyHash = NoHash | GitHash !String

  slurpyHashMatch :: SlurpyHash -> SlurpyHash -> Bool
  slurpyHashMatch (GitHash h1) (GitHash h2) = h1 == h2
  slurpyHashMatch _ _ = False

and add a hash field to both kinds of nodes in a slurpy.

> I think this relates to the question of how you want to handle pending and
> darcs add.

> On one extreme, we could have both a pristine cache and a pending
> file in darcs-enabled git repositories.

> On the other extreme (which I think is what you're
> imagining/implementing), we could have neither, and rely on the
> normal git cache to store both the "pristine state" and the "pending
> change" (meaning whatever information we need to get the needed
> functionality).

The pristine cache and the pending patch are distinct issues.  I'll
treat both.

Git allows you to quickly slurp an arbitrary tree.  What Darcs-git
does, is that slurp_recorded slurps the head tree.  Additionally,
there's some magic to get the stat data from the Git cache, but it's
not specific to the head revision; whenever you slurp a Git file, you
get the mtime from the Git cache if it's there (that's done in
gitSlurpyToSlurpy).

In other words, the Git cache is treated just like a cache; if you run
with no Git cache, everything will still work, you'll just end up
doing a lot of whole-file comparisons.

> I think we ought to always support a pending.  

You are right, as usual.  I did initially try to get away without one,
but it turned out there's too much impedance.)  So I'm just writing a
file ``.git/darcs_pending'' that uses the native Darcs format.  The
only problem with that is that if you do ``darcs move'' or ``darcs
replace'', you'll end up getting an error only when you record, not at
the time of the move.

> Having support for pending (provided we abstract it a bit) would
> mean that replace/add/remove/mv could all be implemented in a
> repository-format-agnostic manner.

Your wish has been granted on 26 April 2005.  Grep for ``pendingName''.

> Okay, this makes sense.  I guess maybe a comment somewhere in there
> explaining this would be nice, to avoid scaring people like me?

Yes, will do.

> I'm still thinking that moving some of the unsafePerformIOs to different
> locations might be a good idea.

Go for it, by all means.  I've never claimed I understand lazy
evaluation.

(And go ahead, remove all the unsafePerformIOs that you think are
useless.  I just put them in at all places I could think of where I
knew they are safe, without thinking whether they are useful.)

> In particular, if GitRepo.read_repo is pased a relative path to a
> repository, there will be potential bugs if we ever change
> directories, which is very scary.

Aye.  Should we canonicalise the path instead?

                                        Juliusz