Re: Google Summer of Code 2009: GIT

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

 



On Thu, 19 Mar 2009, Johannes Schindelin wrote:

On Thu, 19 Mar 2009, david@xxxxxxx wrote:

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.

You are misunderstanding me.

The fact that all three are XML based has nothing to do with the _real_
goal of the project.

IOW a user trying to 3-way-merge ODF files could not care less if the
underlying technical details involve having an extra merge driver for XML
files or not.

The user cares about the ease of use, about the user interface.  That is
what I want to focus on.

And if we end up with a beautiful XML merge driver at the end of the
summer that nobody uses, I will be not only a little disappointed.

So let's look at the _nature_ of the data at hand, i.e. text, marked-up
text, images (we could include UML, which is also XML-based, and where the
XML merge driver is as relevant for the user experience as for the
others), and how to make it _easy_ to resolve merge conflicts there.

but don't you want to be able to auto-merge as much as possible before you have to go to _any_ user interaction? (the best user interface is one you don't need to use)

it's only after the merge drive decides that it can't do the merge that you would have to move on to manually resolving conflicts.

when you _do_ move on to resolving conflicts, it's not a good approach to write a GUI tool to deal with each datatype (git does not need it's own ODF text document editory, spreadsheed editor, graphics editor, etc). it may end up being nessasary for some document types, but that's a last resort. it's far better if the conflict markers can be inserted in such a way that the normal tools for dealing with that file type can be used.

git doesn't provide (or mandate) what editor is used to resolve conflicts in text files today, it should not do so for other file types either (again, except as a last resort)

the only way to start from the GUI and not create a merge driver first is to either have a custom GUI that accepts files 'corrupted' with the existing conflict markers, or work on a GUI that works with both of the sources as entire files, with no conflict markers or assistance from git.

David Lang

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