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 _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
