On Tue, Sep 1, 2009 at 1:57 PM, <david.hagood@xxxxxxxxx> wrote: > 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. > 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 -- 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