3 ms·
> Just knowing what changed often isn't enough to do proper resolution. This is why my git commit logs are sometimes: perl -p -i -e 's/FOO/BAR/g' $(find
by adekok 10y ago
> Just knowing what changed often isn't enough to do proper resolution.
This is why my git commit logs are sometimes:
perl -p -i -e 's/FOO/BAR/g' $(find src -name "*.[ch]" -print)
Having a "high level" description of what changed makes manual merges easier.
I wish git had conflict resolution like this. Treating data as an arbitrary sequence of bits is general and correct. Treating data as having a particular format can be useful, too.
- puetzk 10y agoIt does? git merge --strategy xyz means git will invoke git-merge-xyz to do the actual conflict resolution. It comes with a variety of built-in ones (see https://git-scm.com/docs/merge-strategies https://git-scm.com/docs/merge-strategies) but you can write more if you have some special-purpose approach you want to use. Git also has smudge/clean filters if you want to transform your file to a format where line-by-line textual merge is more meaningful And you can use .gitattributes to make certain extensions/folders/file/whatever default to a certain treatment. A good example is https://bitbucket.org/sippey/zippey https://bitbucket.org/sippey/zippey which unpacks zip archives (and hence file formats based on them, like .jar, .docx, etc) to allow the contents within to be tracked in the git repo better. Other custom formats could do something similar...