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,  [off-list ref] wrote:

quoted

On Fri, 13 Mar 2009, saurabh gupta wrote:

quoted

Very well described, David. I agree with you and providing these 
merge options to the user, merge drivers can do the work and mark the 
conflicts according to the option. The work to do is to modify the 
merge driver. I think in this way, even people who have only a 
terminal can also gain from it. They can choose the apt option to see 
the conflict markers in their way. So, the aim is to make merge 
driver configurable and create the merged/conflicted file according 
to the options.

for the GSOC I suspect that the right thing to do is the define one or 
more merge drivers to create, and list what applications are going to 
be used for testing these merges.

you and the mentor can decide what is a reasonable amount of work.

I will very glad to hear about this thing from the mentor (Johannes 
Schindelin, according to wiki). I will try to plan out the things in a 
proper way to carry out this project if I get a chance to work on this 
for GSoC 2009.

Well, now that we have been accepted as an organization, we can move 
forward with this idea!

My main concern is that we define early on what should be the user 
interface, preferably with a quick sketch.

The technical details, we can hash them out later, I have no doubt that 
with the help of the complete Git community, we can overcome almost every 
problem handling XML data or some such.

quoted

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