Re: Google Summer of Code 2009: GIT

[david@lang.hm]

On Thu, 12 Mar 2009, saurabh gupta wrote:

> hello,
>
> On Thu, Mar 12, 2009 at 1:51 AM,  <david@lang.hm> wrote:
>>
>>> Yes, but the thing is that the underlying codes and method will be
>>> different for GUI part and terminal part to make it readable and
>>> understandable. Like for OO Documents, if we aim to show the *diff*
>>> output in the Office tool, then we have to change the xml file
>>> accordingly. But the same xml file when used with terminal only, the
>>> *diff* output is not clear.
>>>
>>> As Johannes said in above post that for OO documents, while showing
>>> the *diff* result, no xml data should be shown.
>>
>> in part we are talking about different aspects of things, and we were all
>> wrong.
>>
>> see the e-mail a little bit ago by Junio
>>
>> there are two types of helpers that can be written
>>
>> 1. a low-level part that does the simple merges automaticaly and leaves
>> behind appropriate conflict markers when it can't
>>
>> there is no GUI involved with this.
>>
>> what 'appropriate conflict markers' are can vary from XML file to XML file
>>
>>
>> 2. after a conflict has taken place, a helper to work with the user to
>> resolve the conflict
>>
>> this can have a GUI and/or a text UI and is tied to the 'appropriate
>> conflict markers' as defined in #1, and can be _very_ tightly coupled to the
>> specific use of the XML file.
>>
>> I think it's very important to have a text UI tool that can be used for the
>> conflict resolution step as well as supporting GUI tools.
>
> All right. What I can understand from the current situation is that
> for merging and marking conflicts in xml (for example) files has
> following things to do.
>
> One, if the markers are put in the xml files like that of a text file,
> one can see the difference using a text editor or a terminal. But if
> the same xml file is to be opened in another editor which expects a
> valid xml (as clearly mentioned on the wiki ideas for GIT), then a
> merge helper is needed.
>
> But if the conflict markers are put in a way to make the xml file
> still valid which can be then opened in the appropriate editor, then
> the marking will be different. The merge driver has to produce the
> conflicted merged file in a manner which is still a valid xml file and
> user has the choice to open it in his own editor to resolve the
> conflicts.

exactly. and how you mark the conflict to have it be valid XML is going to 
depend on details of the type of file. there are probably a few basic 
methods that will work the vast majority of the time, but with some 
details needing to be configurable.

for example, if the XML document is a ODF document, it may be possible to 
add 'revision' tags around the conflict that are already understood by the 
editor.

David Lang