Hello everyone,
On Sat, Aug 20, 2011 at 6:04 PM, Nick Dokos <nicholas.do...@hp.com> wrote:
> And emacs has the emerge tool already built in. In fact, Chacon
> mentions emerge as one of the presets in git, so it may be even
> simpler than what he describes.
When there is a conflict, this should work:
$ git mergetool --tool=emerge
This pops out an emacs window for every conflicting file. But I believe
it is possible to specify a custom mergetool rather easily using `emacs
-nw` or `emacsclient -t`.
Excerpt from `man git-config`:
merge.tool
Controls which merge resolution program is used by
git-mergetool(1). Valid built-in values are: "kdiff3", "tkdiff",
"meld", "xxdiff", "emerge", "vimdiff", "gvimdiff", "diffuse",
"ecmerge", "tortoisemerge", "p4merge", "araxis" and "opendiff".
Any other value is treated is custom merge tool and there must be
a corresponding mergetool.<tool>.cmd option.
However what I have found is it is rather difficult to merge blocks of
text reasonably trivially. Often diff (or git diff) is thrown off when:
1. There is a TODO/tag change very close to some other change in text
2. A headline is promoted or demoted without any change in the content
3. There is minor change in a body of text but line wrapping makes the
diff very difficult to follow as it lists many more changes.
I think the problem is all tools like patch/diff are made for source
code. So they understand source code structures like code blocks {..} in
most languages or methods/functions like someFunc() {..} in C/C++ or
(defun somefn () ...) in lisp. Where as plain text / Org text is
structured more as paragraphs and trees, line wrapping is usually
inconsequential. So a dedicated git driver to merge org files might be
worth it. It could automatically take care of differences solely due to
wrapping and other formatting changes like promoting or demoting a tree,
whereas only present to the users areas where text content has been
changed (a driver that understands the extra word is what I care about
and not the apparent 5 line change because of the wrapping).
Maybe the way to do this would be to first simplify the text into a form
where formatting is irrelevant. The driver could then take the
formatting merge related decisions and present the content merging
decisions to the user. Of course this is all talk and probably a *big*
project in itself. :-p
Hopefully I was able to express myself clearly.
--
Suvayu
Open source is the future. It sets us free.
