From: david@lang.hm
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: saurabh gupta <saurabhgupta1403@gmail.com>,
Junio C Hamano <gitster@pobox.com>,
git@vger.kernel.org
Subject: Re: Google Summer of Code 2009: GIT
Date: Thu, 19 Mar 2009 01:37:15 -0700 (PDT) [thread overview]
Message-ID: <alpine.DEB.1.10.0903190129110.4560@asgard.lang.hm> (raw)
In-Reply-To: <alpine.DEB.1.00.0903190141300.10279@pacific.mpi-cbg.de>
On Thu, 19 Mar 2009, Johannes Schindelin wrote:
> On Wed, 18 Mar 2009, david@lang.hm wrote:
>
>> On Thu, 19 Mar 2009, Johannes Schindelin wrote:
>>
>>>
>>> In my humble opinion, we should focus on the data types we want to be
>>> able to support at the end of the summer first.
>>>
>>> For example, if we decide that OOXML is a must (as it is a proper
>>> standard, and many people will benefit from it), we will most likely
>>> end up in having to write a merge _driver_ (to handle those .zip
>>> files), _and_ a merge _helper_, although we can avoid writing our own
>>> GUI, as we can create an OOXML that has its own version of conflict
>>> markers.
>>
>> do you mean OOXML (the microsoft format) or ODF (the open office
>> format)?
>
> Oops.
>
> EOVERLOAD
it happens.
>>> If we decide that SVG is something we want to support by the end of
>>> the summer, then we can probably avoid writing a merge _driver_, as
>>> plain text is handled reasonably well in Git. OTOH it could turn out
>>> that there are _real_ conflicts in overlapping tag ids, and it would
>>> still be easier to write a merge driver, too.
>>>
>>> IOW the details are not as important as
>>>
>>> - knowing what data types we want to support _at the least_, and what
>>> data types we keep for the free skate,
>>>
>>> - a clear picture of the user interface we want to be able to provide,
>>>
>>> - a timeline (weekly milestones should be fine, I guess) what should
>>> be achieved when, and
>>>
>>> - being flexible in how to support that (IOW if a merge driver appears
>>> unnecessary first, but necessary later, we should be able to fit
>>> that into both the design and the timeline).
>>
>> it's up to the student, but I suspect that the best approach would be to
>> start with defining a merge driver to handle XML (with a minimum set of
>> capabilities, and additional optional ones), and go from there.
>
> Well, the thing is: if the student decides to have a go at an XML driver
> first and foremost, then I'll just flatly refuse to mentor that. Because
> I sincerely believe that this project is best designed from top to bottom,
> not the other way round.
>
> After all, the project is based on a user's request, not just a
> playthingie for an XML enthusiast (if such a thing exists).
all three formats mentioned here (OOXML, ODF, SVG) are XML-based formats
and a single flexible XML merge driver could potentially handle all three
(as well as other formats). for that matter, the ODF specs cover multiple
types of data, and I suspect that appropriate conflict markers for text
could well end up being different than the ones for spreadsheets.
that's not a 'plaything for an XML entusiast', it's making the tool
slightly more general than it would need to be for any one of these
formats to let it handle all of them.
but I'm not a mentor or a student, just an interested user.
David Lang
next prev parent reply other threads:[~2009-03-19 8:39 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
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 [this message]
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=alpine.DEB.1.10.0903190129110.4560@asgard.lang.hm \
--to=david@lang.hm \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=saurabhgupta1403@gmail.com \
/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).