Re: Google Summer of Code 2009: GIT

> Hi,
>
> On Fri, 13 Mar 2009, saurabh gupta wrote:
>
>> On Fri, Mar 13, 2009 at 1:29 AM,  <david@lang.hm> wrote:
>>> On Fri, 13 Mar 2009, saurabh gupta wrote:
>>>
>>> it may be just doing an XML merge driver is a summer's worth of work,
>>> or it may be that it's not really enough and you should try to do
>>> another one or two.
>>>
>>> it also may be that there is a lot of overlap between different merge
>>> drivers, and once you have the XML driver the others become fairly
>>> trivial to do. (I'm thinking the config file examples I posted earlier
>>> in the thread)
>>
>> with the options given to the user, one can handle the config files
>> also where order doesn't matter and also the whitespaces problem can
>> also be handled in the similar way.
>
> 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.

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

> How does that sound?
>
> Ciao,
> Dscho
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>