On Wed, Dec 12, 2012 at 7:49 AM, Pavel Sanda <[email protected]> wrote: > Gregory Jefferis wrote:
> One solution would be to detect merge conflicts and call our diff algorithm > for the different versions. > This would be beautiful but an order of magnitude harder to implement (surely > not me:) That's what I want. I think it's quite doable if we have a consistent XML representation of LyX that can be converted in both directions. That's because there are nice XML diff algorithms. LyX already supports conversions to XHTML that are reasonably faithful (more on that some other time), but there's no XML->LyX converter. I can't contribute much C++ code to LyX, but I could contribute XSLs to do XML->.lyx conversion, if you point me at documentation on how the .lyx format and the LyXHTML and XHTML export formats (specifically what conventions are used to represent LyX elements in XHTML). >> if you wanted to have bare bones support for git in lyx you would need >> * commit (saving your changes) >> * push (share your work) >> * pull (fetch changes and merge with your work) > > I know what I need, but the question was about your workflow. > In particular, does it make sense in your case to automatically push after > commit? I don't want LyX to be in the business of being a git GUI, but if it were going to be so we'd need either to always do git commit -a (ouch), or git add the files LyX knows were touched (risky) then commit those, or have a git add UI then git commit. That's either unsatisfying or a lot of work, so I'd rather LyX stay out of the git UI business. What I want is that if git (or whatever) has merged a .lyx file *with* conflicts, then LyX should be able to display those such that a user could fix them by normal editing operations in LyX. >> After testing out the existing svn implementation I think this is actually >> simpler to automatically merge with git than to lock files with svn. > > Maybe more powerful, but simpler? I have hard time to understand how > resolving merge conflicts is _simpler_ than automatical locking part of the > document you work on. > But Ok, we don't agree here, let is sleep. Locking is simpler until you realize that it causes serious problems (already discussed). I don't want to stop you from locking. I want the option to merge. Nico --
