[darcs-users] Darcs backend for Gitit

[Max Battcher]

Gwern Branwen wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> Hiya everyone. So I've been desultorily working on Darcs support in
> Gitit, and it's turned out to be a little rougher than I expected.
> Time to leech^Wask for help. Attached is what I have so far.
> 
> My questions are like this.
> - ---------------------------
> 1)
> One function Gitit uses is gitDiff:
> gitDiff :: MonadIO m
>         => String     -- ^ Filename
>         -> String     -- ^ Old version (sha1)
>         -> String     -- ^ New version (sha1)
>         -> m String  -- ^ String
> gitDiff file from to = do
>   (status, _, output)  FilePath -> FilePath -> FilePath -> m String
> gitMergeFile edited original latest = do
>   (status, err, out)  return out
>        ExitFailure n | n >= 0  -> return out  -- indicates number of
> merge conflicts
>        _                       -> error $ "git merge-file returned an
> error.\n" ++ err
> 
> I've tried to read up on Git, but I don't understand this. Is it just
> a clone of the Unix command merge, as
> http://www.kernel.org/pub/software/scm/git/docs/git-merge-file.html
> suggests? I think from its use in Gitit.hs that it is intended for use
> in 'edit conflict' situations
> (https://secure.wikimedia.org/wikipedia/en/wiki/Edit_conflict
> https://secure.wikimedia.org/wikipedia/en/wiki/Wikipedia:Edit_conflict)
> where you change a page, save, and discover someone else edited it
> already; but isn't Darcs supposed to handle such situations
> intelligently? Perhaps the right solution involves some combination of
> recording and pushing.

I agree, I think it would be much more interesting to attempt to use 
darcs' commutation for this purpose...

One possibility might be to grab the darcs changes --context at the edit 
page request and then write your own dpatch, appending that context, out 
to darcs apply...  It might be a useful here to get a verbose mode for 
darcs apply so that it will output the full conflicts to standard out 
(and/or perhaps in a simple --xml-output wrapper) rather than just the 
summary of conflicts that --dont-allow-conflicts provides...

Another strategy, since it's a Wiki that can continuously be edited, why 
not just entirely allow conflicts in the working repository for the Wiki 
and let people submit patches that conflict.  (That is, don't worry if 
the repository is always in a conflict-free state.)  Let the conflicts 
show up as errors in the Wiki output (I could see the use in a simple 
preprocessor to seek out darcs conflict markers and produce some sort of 
interesting markup) and let the next contributor (or the current 
contributor(s) if they are paying attention) fix the mess.  A heavily 
edited Wiki in such a fashion could certainly could be a brutal 
verification of darcs conflict operations and timings.  (To be honest, 
I've always thought Wikis should at least somewhat work that way 
anyway...  A wiki will show incorrect markup as ugly/an error, why are 
merge conflicts much different?)

--
--Max Battcher--
http://worldmaker.net