Re: Making GIT XML aware?

From: Avery Pennarun <apenwarr@gmail.com>
Date: Sep 1, 2009, 14:06 UTC
Message-ID: <32541b130909010706s45031e64ld614802f2b57ce5e@mail.gmail.com>
In-Reply-To: <fcdc4d8bb3b1ee0b1473a48ed79e7c61.squirrel@localhost>

On Tue, Sep 1, 2009 at 1:57 PM, <david.hagood@gmail.com> wrote:

Show 9 quoted lines

> However, it seems to me that if there were some way to plug into GIT's
> merging logic, it would be possible to design an XML aware merging tool
> that might help on this (generalizing: if you could have content-aware
> merging libraries you could make all sorts of merges go more smoothly).
> For the specific case of an XML file, if you could have some way to denote
> tags and/or attributes that are "don't cares" you could address problems
> like I am having. You could also theoretically exploit a knowledge of the
> format to better identify what chunks are changes and possibly track
> motion within the files better.

You have a couple of options here, both of which you can read about in 'man gitattributes'.

If you have "don't care" attributes, that's a good sign that you shouldn't be storing them *at all*. You could use the 'filter' feature of gitattributes to remove them (or convert them to a constant) on checkin, and regenerate them on checkout.

As for merging algorithms, you can supply a custom one using the 'merge' gitattribute.

Show 5 quoted lines

> Absent that, is there a way to tell git "in case of an unresolvable merge
> conflict, don't modify the file but put the other version of the file
> somewhere (e.g. filename.other) so that I can use an external tool to
> resolve the differences"? In this case, EA doesn't know how to use the
> standard conflict tags within a file to extract deltas.

You can apparently override this with the 'merge' attribute as well.

Have fun,

Avery