Re: Google Summer of Code 2009: GIT

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Mar 11, 2009 at 6:28 PM, Johannes Schindelin
<Johannes.Schindelin@xxxxxx> wrote:
> Hi,
>
> On Wed, 11 Mar 2009, saurabh gupta wrote:
>
>> On Wed, Mar 11, 2009 at 5:28 PM, Johannes Schindelin
>> <Johannes.Schindelin@xxxxxx> wrote:
>>
>> > On Wed, 11 Mar 2009, Saurabh Gupta wrote:
>> >
>> > > /*About GSoC GIT ideas; */Here are the ideas which I found to be
>> > > interested in. Although, I would like to discuss any other idea than
>> > > these in GIT organization.
>> > >
>> > > *1) Domain specific merge helpers* Intelligence in the merger can be
>> > > put which modifies the source file according the format. Different
>> > > file formats can be put in the merger to support.
>> >
>> > You said that you are interested in this project, but from your mails
>> > I do not see what are the specific reasons why.
>>
>> All right. May be I lacked in my mail to specify the reason for my
>> interest.
>
> Oh, sorry, I did not mean to imply any offense...

No, I didn;t mean that either too :-D

>
>> The reason is that from my past experience, I got the notion that this
>> project is according to my interest and is doable in the three months
>> time period.
>>
>> Another reason is that I have been using the versioning tools like svn
>> and now perforce for a long time and this added up to my interest.
>
> Sounds good!
>
>> > IMHO this project can only fly if you have a specific file format that
>> > you absolutely want to be able to merge; otherwise, it will be an
>> > uphill fight.
>>
>> Well, as suggested on the wiki, I would like to work on the xml file
>> formats as I have quite experience of working with xml files and parsing
>> them using msxml and nsxml libraries and some of personal wrappers.
>
> As I am known to not exactly like Microsoft's products, if you wanted to
> have me as a mentor, you'd need to use Open Source libraries to do the
> parsing.

Yeah, of course. I mentioned msxml and nsxml just to indicate that I
am comfortable with the xml parsing. I will, no doubt, go for open
source libraries to parse xml and write or reuse some of my own
wrappers to parse xml.



>> How about my idea of making the support of new file formats in the
>> plug-ins (suggested in my last post).
>
> Sorry, I missed that idea.  Could you describe it again?
>

All right. This is the quote which I said in my last posts.

=>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.


>> > Personally, I would _love_ to see a good graphical tool (maybe written
>> > in Tcl/Tk) to help merging conflicts in LaTeX files, but I just do not
>> > have the time...
>>
>> Ok. What I am thinking is to implement something  like that of
>> graphical *diff* command output but in these special file formats, it
>> ought to have intelligence to bring out the difference of two files
>> (like latex or xml) in a readable manner. For example, in case of xml
>> files, if one file contains an inner tag block , then merger GUI
>> should notify the user in a readable manner about this added tag
>> rather than only the difference in lines.
>
> A diff would be a first step, but the real issue are the merge helpers.
> And they need first and foremost a thought-through user interface design.
> The technical issues are all solveable, I am sure.

I got your point. I am thinking of using gtk+ libraries to implement
the GUI part (I am quite comfortable with gtk+). However, I think in
merging and notifying about the conflicts in the xml files, other
things can also be put forward. Like the GUI will show the number of
tags differing and what are the new tags added and even if any tag is
renamed with the content unchanged. If possible, how about showing a
tree like structure (just like DOM model) to compare (or diff) the two
xml files.


> Ciao,
> Dscho
>
>



-- 
Saurabh Gupta
Senior,
NSIT,New Delhi, India
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux