From: saurabh gupta <saurabhgupta1403@gmail.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: git@vger.kernel.org
Subject: Re: Google Summer of Code 2009: GIT
Date: Wed, 11 Mar 2009 19:25:54 +0530 [thread overview]
Message-ID: <ab9fa62a0903110655y4a47ccfkde0984ecb46b3307@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.1.00.0903111353340.10498@intel-tinevez-2-302>
On Wed, Mar 11, 2009 at 6:28 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Wed, 11 Mar 2009, saurabh gupta wrote:
>
>> On Wed, Mar 11, 2009 at 5:28 PM, Johannes Schindelin
>> <Johannes.Schindelin@gmx.de> 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
next prev parent reply other threads:[~2009-03-11 13:57 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-11 4:52 Google Summer of Code 2009: GIT Saurabh Gupta
2009-03-11 5:56 ` Daniel Barkalow
[not found] ` <ab9fa62a0903102317l3a7322f7w5e4d9ba0e02af37b@mail.gmail.com>
2009-03-11 9:04 ` saurabh gupta
2009-03-11 8:59 ` David Symonds
2009-03-11 9:02 ` saurabh gupta
2009-03-11 11:55 ` Johannes Schindelin
2009-03-11 11:55 ` David Symonds
2009-03-11 12:52 ` Johannes Schindelin
2009-03-11 11:58 ` Johannes Schindelin
2009-03-11 12:11 ` saurabh gupta
2009-03-11 12:58 ` Johannes Schindelin
2009-03-11 13:55 ` saurabh gupta [this message]
2009-03-11 14:02 ` Johannes Schindelin
2009-03-11 14:13 ` saurabh gupta
2009-03-11 15:27 ` Rogan Dawes
2009-03-11 16:21 ` saurabh gupta
2009-03-11 15:38 ` Johannes Schindelin
2009-03-11 16:29 ` saurabh gupta
2009-03-11 16:29 ` Daniel Barkalow
2009-03-11 16:44 ` Johannes Schindelin
2009-03-12 12:56 ` Michael J Gruber
2009-03-12 13:07 ` Johannes Schindelin
2009-03-12 13:15 ` Michael J Gruber
2009-03-12 18:25 ` david
2009-03-11 16:58 ` saurabh gupta
2009-03-12 12:47 ` Michael J Gruber
2009-03-11 16:32 ` david
2009-03-11 17:01 ` Johannes Schindelin
2009-03-11 19:30 ` david
2009-03-11 19:55 ` Johannes Schindelin
2009-03-11 17:07 ` saurabh gupta
2009-03-11 19:29 ` david
2009-03-11 20:02 ` saurabh gupta
2009-03-11 20:21 ` david
2009-03-11 20:37 ` Johannes Schindelin
2009-03-11 21:05 ` david
2009-03-11 21:47 ` Junio C Hamano
2009-03-12 1:57 ` thestar
2009-03-12 7:40 ` Junio C Hamano
2009-03-12 12:45 ` saurabh gupta
2009-03-12 18:00 ` david
2009-03-12 18:43 ` Junio C Hamano
[not found] ` <ab9fa62a0903121119j6c2a1d43kd9cda99db47b5e7c@mail.gmail.com>
2009-03-12 18:53 ` david
2009-03-12 19:00 ` saurabh gupta
2009-03-12 19:29 ` david
2009-03-12 19:45 ` saurabh gupta
2009-03-12 19:59 ` david
2009-03-12 20:03 ` saurabh gupta
2009-03-12 20:45 ` david
2009-03-13 3:15 ` saurabh gupta
2009-03-18 23:16 ` Johannes Schindelin
2009-03-18 23:55 ` david
2009-03-19 0:43 ` Johannes Schindelin
2009-03-19 8:37 ` david
2009-03-19 10:24 ` Johannes Schindelin
2009-03-19 19:12 ` david
2009-03-19 19:23 ` saurabh gupta
2009-03-19 6:30 ` Caleb Cushing
2009-03-19 10:19 ` Johannes Schindelin
2009-03-21 23:53 ` Caleb Cushing
2009-03-19 19:17 ` saurabh gupta
2009-03-19 23:42 ` Johannes Schindelin
2009-03-20 0:07 ` david
2009-03-20 0:30 ` Johannes Schindelin
2009-03-20 3:09 ` david
2009-03-20 9:35 ` Johannes Schindelin
2009-03-20 20:50 ` david
2009-03-21 17:38 ` saurabh gupta
[not found] ` <ab9fa62a0903211031l78c7afadg9409a544f2bda7db@mail.gmail.com>
2009-03-21 17:36 ` saurabh gupta
2009-03-12 20:18 ` Junio C Hamano
2009-03-12 12:42 ` saurabh gupta
2009-03-12 18:03 ` david
2009-03-12 18:23 ` saurabh gupta
2009-03-13 9:41 ` Rogan Dawes
2009-03-13 20:18 ` saurabh gupta
2009-03-11 19:36 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ab9fa62a0903110655y4a47ccfkde0984ecb46b3307@mail.gmail.com \
--to=saurabhgupta1403@gmail.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).