Conflict editing

Conflict editing

[Johannes Schindelin]

Hi,

I often end up with conflicts, and I just want to edit the conflicting 
files, one after another. To make this easier, I wrote a script (yes, no 
builtin) to start the editor with the files having conflicts.

Of course, this script is dumb and has no way to edit files whose names 
contain spaces, it will choke on conflicting symlinks and it does not 
update the index after editing the files (to avoid erroneous updating). As 
usual, it did not really receive more testing than absolutely necessary.

Ciao,
Dscho

-- snipsnap --
#!/bin/sh
#
# Copyright (c) 2006, Shawn O. Pearce
#
# Cleanup unreachable files and optimize the repository.

USAGE=''
SUBDIRECTORY_OK=Yes
. git-sh-setup
cd_to_toplevel

test -z "$(git ls-files --unmerged)" && echo "Nothing to do" && exit

git ls-files --unmerged | cut -b51- | grep ' ' >/dev/null &&
die "filenames contain spaces"

"${VISUAL:-${EDITOR:-vi}}" $(git ls-files --unmerged | cut -b51- | uniq)

Re: Conflict editing

[Johannes Schindelin]

Hi,

On Sun, 4 Mar 2007, Johannes Schindelin wrote:

> # Copyright (c) 2006, Shawn O. Pearce

As pointed out by Junio on IRC, I assigned the copyright to this small 
script to Shawn. Actually, I just forgot to edit that part after copying 
the script preamble from git-gc.sh.

Ciao,
Dscho

Re: Conflict editing

[Theodore Tso]

On Sun, Mar 04, 2007 at 01:43:59PM +0100, Johannes Schindelin wrote:
> I often end up with conflicts, and I just want to edit the conflicting 
> files, one after another. To make this easier, I wrote a script (yes, no 
> builtin) to start the editor with the files having conflicts.
> 
> Of course, this script is dumb and has no way to edit files whose names 
> contain spaces, it will choke on conflicting symlinks and it does not 
> update the index after editing the files (to avoid erroneous updating). As 
> usual, it did not really receive more testing than absolutely necessary.

As it turns out, I've been working on my own script, git-mergetool, to
deal with conflicts, and while it isn't quite ready for prime time yet
(no documentation, doesn't deal with filenames with spaces yet, etc.)
it does fire up the GUI merge tools and it does update the index
afterwards.  My intention is to polish this up and submit this into a
patch to git.  

The goal is to have similar functionality to what Bitkeeper and
Mercurial have as far as GUI merge tools are concerned.  Once I am
done polishing git-mergetool, I'll likely submit a patch to enable a
config option which will cause "git merge" to automatically fire up
"git mergetool" if there are any conflicts.

The patch doesn't current fall back to firing up an editor, but in
order to subsume Johannes' script's functionality, I will probably add
that functionality with code that looks for merge markers and which
only does the "git add" if the merge markers are completely gone.

It currently uses a hard-wired preference order for the GUI merge
tools, based on the current functionality of said merge tools, but the
plan is to add options parsing and a config option to allow a
user-specified override.

Any comments, suggestions?

						- Ted

#!/bin/sh
#
# This program resolves merge conflicts in git
#

KDIFF3="kdiff3"
TKDIFF="tkdiff"
MELD="meld"

type "$KDIFF3"    >/dev/null 2>&1 || KDIFF3=
type "$TKDIFF"    >/dev/null 2>&1 || TKDIFF=
type "$MELD"      >/dev/null 2>&1 || MELD=

if test -z "$KDIFF3" -a -z "$TKDIFF" -a -z "$MELD" ; then
	echo "No available GUI merge tools available."
	exit 1
fi

merge_file () {
	path="$1"

	if test ! -f "$path" ; then
		echo "$path: file not found"
		exit 1
	fi

	f=`git-ls-files -u "$path"`
	if test -z "$f" ; then
		echo "$path: file does not need merging"
		exit 1
	fi

	BACKUP="$path.BACKUP.$$"
	LOCAL="$path.LOCAL.$$"
	REMOTE="$path.REMOTE.$$"
	BASE="$path.BASE.$$"
	CHGTEST="$LOCAL.chg.$RAND"

	mv $path $BACKUP
	cp $BACKUP $path

	git show :1:$path > "$BASE"
	git show :2:$path > "$LOCAL"
	git show :3:$path > "$REMOTE"

	if test -n "$KDIFF3" ; then
		kdiff3 --auto "$BASE" "$LOCAL" "$REMOTE" -o "$path"
		status=$?
	elif test -n "$TKDIFF" ; then
		tkdiff "$LOCAL" "$REMOTE" -a "$BASE" -o "$path"
		status=$?
	elif test -n "$MELD" ; then
		meld "$LOCAL" "$path" "$REMOTE"
		if test "$path" -nt "$BACKUP" ; then 
			status=0;
		else
			while true; do
			        echo "$path seems unchanged."
			        echo -n "Was the merge successful? [y/n] "
			        read answer
			        case "$answer" in
			        	y*|Y*) status=0; break ;;
					n*|N*) status=1; break ;;
				esac
			done
		fi
	fi
	rm -f "$LOCAL" "$REMOTE" "$BASE"
	if test $status != 0 ; then
		echo "merge of $path failed" 1>&2
		mv "$BACKUP" $path
		exit 1
	fi
	git add $path
}

if test $# -eq 0 ; then
	files=`git ls-files -u --abbrev=8 | colrm 1 24 | sort -u`
	if test -z "$files" ; then
		echo "No files need merging"
		exit 0
	fi
	echo Merging the files: $files
	for i in `git ls-files -u --abbrev=8 | colrm 1 24 | sort -u`
	do
		merge_file "$i"
	done
else
	while test $# -gt 0; do
		merge_file "$1"
		shift
	done
fi
exit 0 

Re: Conflict editing

[Martin Langhoff]

On 3/5/07, Theodore Tso <tytso@mit.edu> wrote:
> It currently uses a hard-wired preference order for the GUI merge
> tools, based on the current functionality of said merge tools, but the
> plan is to add options parsing and a config option to allow a
> user-specified override.
>
> Any comments, suggestions?

I find xxdiff much better than meld, tkdiff and kdiff -- but maybe I
just don't know how to use them, or they have gotten better in the
last few months.

I had written (and posted) a git-xxdiff earlier. A (minor) concern is
that from a packaging and dependencies perspective, the packager has
to suggest *all* of them, and still a default install may not work at
all -- it might be a good idea to suggest what to install in the error
message. Or depend on all of them (yuck!).

One thing I _don't_ want as a user is to see the graphical mergers
starting by default. Most merges are trivial, and I can just edit them
in emacs or vi.

And when a merge is really hard, and calls for merge-centric tools, I
open gitk alongside to see what commits happened on each side.

cheers,


martin

Re: Conflict editing

[Theodore Tso]

On Mon, Mar 05, 2007 at 10:59:33AM +1300, Martin Langhoff wrote:
> I find xxdiff much better than meld, tkdiff and kdiff -- but maybe I
> just don't know how to use them, or they have gotten better in the
> last few months.

I wasn't familiar with xxdiff until just now, but having played with
it, kdiff3 is much easier for a beginner to use.  The toolbar makes it
a lot easier to select from one or the other, I find the keyboard
accellerators to be much more intuitive (although I suppose if you are
a vi or nethack fan the H, J, K keys will make sense to you :-).  

In addition, with xxdiff it gives the user way too many options about
whether you want to save the left, right, or center, or merged
windows.  That makes sense maybe if you are doing something completely
general, but too many options is a net negative, not a feature.  I
prefer kdiff3, where you simply hit the save icon, and it saves the
reconciled merged file to the specified output file (which the
git-mergetool specified to kdiff3 on the command-line).  So from the
workflow perspective, kdiff3 fits in much more cleanly than xxdiff.  

The one advantage xxdiff has that I can see (and maybe that's why you
like it?) is that it has the -U feature which allows it to pick apart
the merge conflict markers and so you can use it fairly easily simply
by saying "xxdiff -U hello.c".  With kdiff3 it's a lot more
complicated to invoke off the command-line, with something like:

	kdiff3 --auto hello.c.BASE hello.c.LOCAL hello.c.REMOTE -o hello.c

...but that's why you have a shell script to keep you away from such
nastyness.  All I need to do with my mergetool script is to type, "git
mergetool" to merge all unresolved merge conflicts, or "git mergetool
hello.c" if I only want to resolve conflicts in a single file.

> I had written (and posted) a git-xxdiff earlier. A (minor) concern is
> that from a packaging and dependencies perspective, the packager has
> to suggest *all* of them, and still a default install may not work at
> all -- it might be a good idea to suggest what to install in the error
> message. Or depend on all of them (yuck!).

Depending on all of them is definitely a bad idea.  Suggesting all of
them doesn't seem to be a big issue, and I don't see what's the
problem if git-mergetool can't find a graphical resolver; it can
always fall back to opening the file in an editor and asking the user
to resolve the conflict manually.

> One thing I _don't_ want as a user is to see the graphical mergers
> starting by default. Most merges are trivial, and I can just edit them
> in emacs or vi.

Well, git will handle most merges automatially for you anyway.  You
would only use git mergetool to handle the merge conflicts.

						- Ted

Re: Conflict editing

[Martin Langhoff]

On 3/5/07, Theodore Tso <tytso@mit.edu> wrote:
> On Mon, Mar 05, 2007 at 10:59:33AM +1300, Martin Langhoff wrote:
> > I find xxdiff much better than meld, tkdiff and kdiff -- but maybe I
> > just don't know how to use them, or they have gotten better in the
> > last few months.
>
> I wasn't familiar with xxdiff until just now, but having played with
> it, kdiff3 is much easier for a beginner to use.  The toolbar makes it
> a lot easier to select from one or the other, I find the keyboard
> accellerators to be much more intuitive (although I suppose if you are
> a vi or nethack fan the H, J, K keys will make sense to you :-).

No, I hate that navigation. But arrow keys and pageup/down work great
for me. Mouse navigation is superb too.

> In addition, with xxdiff it gives the user way too many options about
> whether you want to save the left, right, or center, or merged
> windows.

I can understand that. But it also does in-the-line diff colouring
that I haven't seen the others do. Where the lines don't match on
something small, you can see the offending characters in a slightly
different tone (I'm colourblind, so I'm unsure of the exact colour,
but it does work).

I find xxdiff to be an order of magnitude faster than meld and kdiff3.
And at least kdiff3 spews garbage about trying to start the whole of
KDE infrastructure hairball so it messes up my terminal where I had
interesting messages from the just-executed git-pull.

So at least for now xxdiff is my well-behaved, flexible and fast tool ;-)

And I can see at a glance that single quotes got replaced with double
quotes or a trailing space got added or trimmed and _that_'s why the
thing didn't merge cleanly.

> > One thing I _don't_ want as a user is to see the graphical mergers
> > starting by default. Most merges are trivial, and I can just edit them
> > in emacs or vi.
>
> Well, git will handle most merges automatially for you anyway.  You
> would only use git mergetool to handle the merge conflicts.

Sorry -- I meant to say most conflicts are trivial. Someone mentioned
auto-running gui tools on any conflict, and don't think I want that.

cheers,


martin

Re: Conflict editing

[Shawn O. Pearce]

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> I often end up with conflicts, and I just want to edit the conflicting 
> files, one after another. To make this easier, I wrote a script (yes, no 
> builtin) to start the editor with the files having conflicts.
> 
> -- snipsnap --
> #!/bin/sh
> #
> # Copyright (c) 2006, Shawn O. Pearce

Sweet!  My evil plan is working...  you do all of the work and I
get all of the credit!  Last year to boot!  ;-)


Yes, I did see the other message about how you copied the preamble
from git-gc.sh...  ;-)

-- 
Shawn.

Re: Conflict editing

[Brian Gernhardt]

On Mar 4, 2007, at 7:43 AM, Johannes Schindelin wrote:

> Of course, this script is dumb and has no way to edit files whose  
> names
> contain spaces

Wouldn't using xargs fix that?

> "${VISUAL:-${EDITOR:-vi}}" $(git ls-files --unmerged | cut -b51- |  
> uniq)

git ls-files --unmerged | cut -b51- | uniq | xargs "${VISUAL:-$ 
{EDITOR:-vi}}"

~~ Brian Gernhardt

Re: Conflict editing

[Johannes Schindelin]

Hi,

On Mon, 5 Mar 2007, Brian Gernhardt wrote:

> On Mar 4, 2007, at 7:43 AM, Johannes Schindelin wrote:
> 
> > Of course, this script is dumb and has no way to edit files whose 
> > names contain spaces
> 
> Wouldn't using xargs fix that?

I tried that first, even in the proper form to catch newlines also, with 
"-z" for ls-files and "-0" for xargs.

Alas, vi complained to me by saying "Not started from a terminal", and 
wrecking my terminal settings. For example, echo was set to off, and 
Ctrl+C no longer worked.

Since I am a nice person, I did not want you to have the same experience 
with this dumb script.

Ciao,
Dscho

Re: Conflict editing

[Uwe Kleine-König]

Hello,

Johannes Schindelin wrote:
> > > Of course, this script is dumb and has no way to edit files whose 
> > > names contain spaces
> > 
> > Wouldn't using xargs fix that?
> 
> I tried that first, even in the proper form to catch newlines also, with 
> "-z" for ls-files and "-0" for xargs.
> 
> Alas, vi complained to me by saying "Not started from a terminal", and 
> wrecking my terminal settings. For example, echo was set to off, and 
> Ctrl+C no longer worked.
Another problem is, that only GNU xargs has -0, the version on Solaris
(and probably on *BSD) doesn't know it.

Best regards
Uwe

-- 
Uwe Kleine-König

http://www.google.com/search?q=gigabyte+in+bit

Re: Conflict editing

[Brian Gernhardt]

On Mar 5, 2007, at 6:25 AM, Johannes Schindelin wrote:

> Alas, vi complained to me by saying "Not started from a terminal", and
> wrecking my terminal settings. For example, echo was set to off, and
> Ctrl+C no longer worked.

Of course.  I use "xargs vim" on a semi-regular basis and have  
forgotten that it mucks up some terms and behaves slightly oddly.   
It's just one of the little things I deal with on a regular basis and  
mostly ignore.

> Since I am a nice person, I did not want you to have the same  
> experience
> with this dumb script.

Yes, we should be nice and not screw with people's heads, even if  
mine is already pretty screwy.

~~ Brian