On 12 Dec 2012, at 13:49, Pavel Sanda wrote: >> I think the idea of merging is pretty obvious ? > > If you mean "git merge" then I'm happy to tell you that some people I need to > work with even don't > know what is command line in which you can write the command or decrypt > whatever comes from git > in case of conflict :) > > One solution would be to detect merge conflicts and call our diff algorithm > for the different versions.
that is exactly what I had in mind > This would be beautiful but an order of magnitude harder to implement (surely > not me:) I don't think it is that hard. The SVN VCS support already in git offers the option to fetch remote changes and then the option to do something about conflicts if they exist (at the moment, just keep local or remote). for git this would mean 1) "pull" (presumably if the current branch is a tracking branch) 2) if the merge is successful then just reload the buffer 3) if it fails (and there are clear signals from git when this is the case) diff the local and remote documents _inside_ lyx to give some tracked changes that the user then needs to accept/reject. That really doesn't strike me as that hard to implement (iff the diff did something useful). >> 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? For us, push on commit is fine. We basically try to pull immediately before starting to make changes and push as soon as possible afterwards. This way we very rarely have trouble. However, I think some would prefer to wait to push until they had accumulated a few related changes, so it would be nicer if a design allowed this. Looking a little bit at the existing VCS class and the toolbar, I guess there isn't immediately a way to support commit without push, because svn does not have that separation. >> 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. when merging works (and this is 99% of the time for us) it is simpler. When there is conflict it is indeed much harder – and that is the problem that a functional diff in lyx could solve. > But Ok, we don't agree here, let is sleep. OK! >> what would be more important for my workflow is the ability to do merges by >> a functional diff in lyx. > > This is the key point and I recommend that you add some comment or > CC-yourself in bug #6889 > to indicate that this bug hunts more people and add it more importance... Good point. I have now done so. Nico, I guess it might be good if you did the same. Pavel has already proposed a work around that looks relatively simple to implement and ought to reduce the number of changes significantly, so there is some chance that this will get picked up and improved. Ticket is here: http://www.lyx.org/trac/ticket/6889 Best, Greg.
