Re: Google Summer of Code 2009: GIT

[saurabh gupta <saurabhgupta1403@gmail.com>]

On Wed, Mar 11, 2009 at 9:59 PM, Daniel Barkalow <barkalow@iabervon.org> wrote:
> On Wed, 11 Mar 2009, saurabh gupta wrote:
>
>> On Wed, Mar 11, 2009 at 7:32 PM, Johannes Schindelin
>> <Johannes.Schindelin@gmx.de> wrote:
>> > Hi,
>> >
>> > On Wed, 11 Mar 2009, saurabh gupta wrote:
>> >
>> >> What I think is to implement file formats other than text like that
>> >> written on wiki i.e. latex, xml, or even any database file (db file).
>> >> Another idea (although it can be weired also) is to implement the new
>> >> file formats in the plug-in formats. For example, to incorporate the
>> >> merger engine for a new file format, a plug-in is created and can be
>> >> integrated with the present merger in the git. However, I am not sure
>> >> how much valid is this idea to make the present merger in git to be
>> >> compatible with the plug-ins for enabling newer file formats.
>> >
>> > I am not sure that a plugin structure is needed.  Take, for example, three
>> > different .xml based formats: OpenOffice documents, .svg files and Ant
>> > build.xml files.  They need very different user interfaces.
>>
>> okay. In that case, if they have  a different user interfaces then
>> separate plug-in would be needed for each of these. May be this will
>> get more messy.
>
> One thing that I think would be good whenever possible is to have the
> merge program generate a file in the same format which is easily
> recognizable as having conflict markers. For example, I think it should be
> possible to show conflicts in the text of office documents by having
> styles for each side of the merge, and show each side's content in the
> appropriate style. Then the user opens the document with their choice of
> office software, finds the things in the conflict styles, and decides what
> the result should be.

Well, I think this is what which is done in case of normal text files
also. The conflicts put the markers in the file to indicate the
changes and the modification part. However, in the case of OO
documents, we have to change the content for the xml file and when it
is opened in the office software, the user will get the modified
contents.


> Of course, if the two sides conflict over something that isn't text, it
> gets harder.
>
> Also remember that, for a merge, there are two important cases: (1) the
> two sides changed things that aren't related at all; (2) the two sides
> changed things that might affect each other. In case (1), the tool should
> take care of everything automatically and report that it took care of it;
> in case (2), it should reliably determine that user assistance is
> required.
>
>        -Daniel
> *This .sig left intentionally blank*
>



-- 
Saurabh Gupta
Senior,
Electronics and Communication Engg.
NSIT,New Delhi, India