Folding for editing files with merge-conflicts?

3 views
Skip to first unread message

Steve

unread,
Dec 18, 2008, 8:50:43 AM12/18/08
to vim_use
Hi Guys,

has anyone implemented a folding/side-by-side plugin for editing files
containing merge conflicts?
I'm thinking of something like :diffsplit mode.

For example, many configuration management systems mark conflicts in
merged files something like this:

<<<<<<< file-from-left-branch
left side of conflict
------------- file-from-right-branch
right side of conflict
>>>>>>>

Would it even be possible for vim to display the same file in two
buffers, one showing the left side of the conflicts and the other
showing the right side? Of course have the two buffers correctly bound
to each other so that the conflicting code is displayed next to each
other, and everything else folded.
Editing of course effects both buffers, and once the conflict markers
have been removed, the text could be folded up and you would move on
to the next conflict, until the file is just one fold-summary :-)

There are several plugins for integrating SCM systems with vim, ie:
cvs, svn, git, mecurial, etc. but they all seem to concentrate on
displaying changes against the repository, adding and committing files
and so on.

Any other macros or tips for working with conflicts would also be
greatly appreciated!

Cheers and thanks in advance,

Steve

Christian Ebert

unread,
Dec 18, 2008, 9:57:19 AM12/18/08
to vim...@googlegroups.com
* Steve on Thursday, December 18, 2008 at 05:50:43 -0800

> has anyone implemented a folding/side-by-side plugin for editing files
> containing merge conflicts?
> I'm thinking of something like :diffsplit mode.
>
> For example, many configuration management systems mark conflicts in
> merged files something like this:
>
> <<<<<<< file-from-left-branch
> left side of conflict
> ------------- file-from-right-branch
> right side of conflict
>>>>>>>>
>
> Would it even be possible for vim to display the same file in two
> buffers, one showing the left side of the conflicts and the other
> showing the right side? Of course have the two buffers correctly bound
> to each other so that the conflicting code is displayed next to each
> other, and everything else folded.
> Editing of course effects both buffers, and once the conflict markers
> have been removed, the text could be folded up and you would move on
> to the next conflict, until the file is just one fold-summary :-)

Try out Conflict2Diff:

http://www.vim.org/scripts/script.php?script_id=621

However, I ended up writing my own 3-way diff for Mercurial.
Unfortunately I don't have the time to polish it for publication.

c
--
\black\trash movie _C O W B O Y_ _C A N O E_ _C O M A_
Ein deutscher Western/A German Western
-->> http://www.blacktrash.org/underdogma/ccc.html
-->> http://www.blacktrash.org/underdogma/ccc-en.html

Charles Campbell

unread,
Dec 18, 2008, 10:44:53 AM12/18/08
to vim...@googlegroups.com
Steve wrote:
> Hi Guys,
>
> has anyone implemented a folding/side-by-side plugin for editing files
> containing merge conflicts?
> I'm thinking of something like :diffsplit mode.
>
> For example, many configuration management systems mark conflicts in
> merged files something like this:
>
> <<<<<<< file-from-left-branch
> left side of conflict
> ------------- file-from-right-branch
> right side of conflict
>

CVSconflict sets up two buffers with the left side being the
"local+merge" file and the right side being the "repository+merge" file,
and applies vimdiff to them.

http://vim.sourceforge.net/scripts/script.php?script_id=1370

Regards,
Chip Campbell

Steve

unread,
Dec 18, 2008, 6:23:18 PM12/18/08
to vim_use
> > has anyone implemented a folding/side-by-side plugin for editing files
> > containing merge conflicts?

> CVSconflict sets up two buffers with the left side being the
> "local+merge" file and the right side being the "repository+merge" file,
> and applies vimdiff to them.
>
> http://vim.sourceforge.net/scripts/script.php?script_id=1370

Thanks Chip & Christian,

I've gone for Christian's tip (Conflict2Diff) because the three buffer
approach works much nicer.
But thanks to both of you for your input!

Cheers,

Steve
Reply all
Reply to author
Forward
0 new messages