{"thread":{"id":"7077","subject":"Conflict editing","startedAt":"2007-03-04T12:43:59Z","lastAt":"2007-03-05T19:27:48Z","messageCount":11,"participants":["Johannes Schindelin","Theodore Tso","Martin Langhoff","Shawn O. Pearce","Brian Gernhardt","Uwe Kleine-König"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"36237","messageId":"Pine.LNX.4.63.0703041339350.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"7077","inReplyTo":null,"subject":"Conflict editing","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-03-04T12:43:59Z","receivedAt":"2007-03-04T12:43:59Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nI often end up with conflicts, and I just want to edit the conflicting \nfiles, one after another. To make this easier, I wrote a script (yes, no \nbuiltin) to start the editor with the files having conflicts.\n\nOf course, this script is dumb and has no way to edit files whose names \ncontain spaces, it will choke on conflicting symlinks and it does not \nupdate the index after editing the files (to avoid erroneous updating). As \nusual, it did not really receive more testing than absolutely necessary.\n\nCiao,\nDscho\n\n-- snipsnap --\n#!/bin/sh\n#\n# Copyright (c) 2006, Shawn O. Pearce\n#\n# Cleanup unreachable files and optimize the repository.\n\nUSAGE=''\nSUBDIRECTORY_OK=Yes\n. git-sh-setup\ncd_to_toplevel\n\ntest -z \"$(git ls-files --unmerged)\" && echo \"Nothing to do\" && exit\n\ngit ls-files --unmerged | cut -b51- | grep ' ' >/dev/null &&\ndie \"filenames contain spaces\"\n\n\"${VISUAL:-${EDITOR:-vi}}\" $(git ls-files --unmerged | cut -b51- | uniq)\n"},{"id":"36239","messageId":"Pine.LNX.4.63.0703041427110.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"7077","inReplyTo":"Pine.LNX.4.63.0703041339350.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Conflict editing","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-03-04T13:29:08Z","receivedAt":"2007-03-04T13:29:08Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 4 Mar 2007, Johannes Schindelin wrote:\n\n> # Copyright (c) 2006, Shawn O. Pearce\n\nAs pointed out by Junio on IRC, I assigned the copyright to this small \nscript to Shawn. Actually, I just forgot to edit that part after copying \nthe script preamble from git-gc.sh.\n\nCiao,\nDscho\n"},{"id":"36242","messageId":"20070304181044.GC8560@thunk.org","threadId":"7077","inReplyTo":"Pine.LNX.4.63.0703041339350.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Conflict editing","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-03-04T18:10:44Z","receivedAt":"2007-03-04T18:10:44Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Sun, Mar 04, 2007 at 01:43:59PM +0100, Johannes Schindelin wrote:\n> I often end up with conflicts, and I just want to edit the conflicting \n> files, one after another. To make this easier, I wrote a script (yes, no \n> builtin) to start the editor with the files having conflicts.\n> \n> Of course, this script is dumb and has no way to edit files whose names \n> contain spaces, it will choke on conflicting symlinks and it does not \n> update the index after editing the files (to avoid erroneous updating). As \n> usual, it did not really receive more testing than absolutely necessary.\n\nAs it turns out, I've been working on my own script, git-mergetool, to\ndeal with conflicts, and while it isn't quite ready for prime time yet\n(no documentation, doesn't deal with filenames with spaces yet, etc.)\nit does fire up the GUI merge tools and it does update the index\nafterwards.  My intention is to polish this up and submit this into a\npatch to git.  \n\nThe goal is to have similar functionality to what Bitkeeper and\nMercurial have as far as GUI merge tools are concerned.  Once I am\ndone polishing git-mergetool, I'll likely submit a patch to enable a\nconfig option which will cause \"git merge\" to automatically fire up\n\"git mergetool\" if there are any conflicts.\n\nThe patch doesn't current fall back to firing up an editor, but in\norder to subsume Johannes' script's functionality, I will probably add\nthat functionality with code that looks for merge markers and which\nonly does the \"git add\" if the merge markers are completely gone.\n\nIt currently uses a hard-wired preference order for the GUI merge\ntools, based on the current functionality of said merge tools, but the\nplan is to add options parsing and a config option to allow a\nuser-specified override.\n\nAny comments, suggestions?\n\n\t\t\t\t\t\t- Ted\n\n#!/bin/sh\n#\n# This program resolves merge conflicts in git\n#\n\nKDIFF3=\"kdiff3\"\nTKDIFF=\"tkdiff\"\nMELD=\"meld\"\n\ntype \"$KDIFF3\"    >/dev/null 2>&1 || KDIFF3=\ntype \"$TKDIFF\"    >/dev/null 2>&1 || TKDIFF=\ntype \"$MELD\"      >/dev/null 2>&1 || MELD=\n\nif test -z \"$KDIFF3\" -a -z \"$TKDIFF\" -a -z \"$MELD\" ; then\n\techo \"No available GUI merge tools available.\"\n\texit 1\nfi\n\nmerge_file () {\n\tpath=\"$1\"\n\n\tif test ! -f \"$path\" ; then\n\t\techo \"$path: file not found\"\n\t\texit 1\n\tfi\n\n\tf=`git-ls-files -u \"$path\"`\n\tif test -z \"$f\" ; then\n\t\techo \"$path: file does not need merging\"\n\t\texit 1\n\tfi\n\n\tBACKUP=\"$path.BACKUP.$$\"\n\tLOCAL=\"$path.LOCAL.$$\"\n\tREMOTE=\"$path.REMOTE.$$\"\n\tBASE=\"$path.BASE.$$\"\n\tCHGTEST=\"$LOCAL.chg.$RAND\"\n\n\tmv $path $BACKUP\n\tcp $BACKUP $path\n\n\tgit show :1:$path > \"$BASE\"\n\tgit show :2:$path > \"$LOCAL\"\n\tgit show :3:$path > \"$REMOTE\"\n\n\tif test -n \"$KDIFF3\" ; then\n\t\tkdiff3 --auto \"$BASE\" \"$LOCAL\" \"$REMOTE\" -o \"$path\"\n\t\tstatus=$?\n\telif test -n \"$TKDIFF\" ; then\n\t\ttkdiff \"$LOCAL\" \"$REMOTE\" -a \"$BASE\" -o \"$path\"\n\t\tstatus=$?\n\telif test -n \"$MELD\" ; then\n\t\tmeld \"$LOCAL\" \"$path\" \"$REMOTE\"\n\t\tif test \"$path\" -nt \"$BACKUP\" ; then \n\t\t\tstatus=0;\n\t\telse\n\t\t\twhile true; do\n\t\t\t        echo \"$path seems unchanged.\"\n\t\t\t        echo -n \"Was the merge successful? [y/n] \"\n\t\t\t        read answer\n\t\t\t        case \"$answer\" in\n\t\t\t        \ty*|Y*) status=0; break ;;\n\t\t\t\t\tn*|N*) status=1; break ;;\n\t\t\t\tesac\n\t\t\tdone\n\t\tfi\n\tfi\n\trm -f \"$LOCAL\" \"$REMOTE\" \"$BASE\"\n\tif test $status != 0 ; then\n\t\techo \"merge of $path failed\" 1>&2\n\t\tmv \"$BACKUP\" $path\n\t\texit 1\n\tfi\n\tgit add $path\n}\n\nif test $# -eq 0 ; then\n\tfiles=`git ls-files -u --abbrev=8 | colrm 1 24 | sort -u`\n\tif test -z \"$files\" ; then\n\t\techo \"No files need merging\"\n\t\texit 0\n\tfi\n\techo Merging the files: $files\n\tfor i in `git ls-files -u --abbrev=8 | colrm 1 24 | sort -u`\n\tdo\n\t\tmerge_file \"$i\"\n\tdone\nelse\n\twhile test $# -gt 0; do\n\t\tmerge_file \"$1\"\n\t\tshift\n\tdone\nfi\nexit 0 \n"},{"id":"36252","messageId":"46a038f90703041359w3cf5ff14n85445396c0ffc422@mail.gmail.com","threadId":"7077","inReplyTo":"20070304181044.GC8560@thunk.org","subject":"Re: Conflict editing","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2007-03-04T21:59:33Z","receivedAt":"2007-03-04T21:59:33Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 3/5/07, Theodore Tso <tytso@mit.edu> wrote:\n> It currently uses a hard-wired preference order for the GUI merge\n> tools, based on the current functionality of said merge tools, but the\n> plan is to add options parsing and a config option to allow a\n> user-specified override.\n>\n> Any comments, suggestions?\n\nI find xxdiff much better than meld, tkdiff and kdiff -- but maybe I\njust don't know how to use them, or they have gotten better in the\nlast few months.\n\nI had written (and posted) a git-xxdiff earlier. A (minor) concern is\nthat from a packaging and dependencies perspective, the packager has\nto suggest *all* of them, and still a default install may not work at\nall -- it might be a good idea to suggest what to install in the error\nmessage. Or depend on all of them (yuck!).\n\nOne thing I _don't_ want as a user is to see the graphical mergers\nstarting by default. Most merges are trivial, and I can just edit them\nin emacs or vi.\n\nAnd when a merge is really hard, and calls for merge-centric tools, I\nopen gitk alongside to see what commits happened on each side.\n\ncheers,\n\n\nmartin\n"},{"id":"36268","messageId":"20070304234030.GA20116@spearce.org","threadId":"7077","inReplyTo":"Pine.LNX.4.63.0703041339350.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Conflict editing","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-03-04T23:40:30Z","receivedAt":"2007-03-04T23:40:30Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n> I often end up with conflicts, and I just want to edit the conflicting \n> files, one after another. To make this easier, I wrote a script (yes, no \n> builtin) to start the editor with the files having conflicts.\n> \n> -- snipsnap --\n> #!/bin/sh\n> #\n> # Copyright (c) 2006, Shawn O. Pearce\n\nSweet!  My evil plan is working...  you do all of the work and I\nget all of the credit!  Last year to boot!  ;-)\n\n\nYes, I did see the other message about how you copied the preamble\nfrom git-gc.sh...  ;-)\n\n-- \nShawn.\n"},{"id":"36278","messageId":"20070305040406.GB26781@thunk.org","threadId":"7077","inReplyTo":"46a038f90703041359w3cf5ff14n85445396c0ffc422@mail.gmail.com","subject":"Re: Conflict editing","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-03-05T04:04:06Z","receivedAt":"2007-03-05T04:04:06Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Mon, Mar 05, 2007 at 10:59:33AM +1300, Martin Langhoff wrote:\n> I find xxdiff much better than meld, tkdiff and kdiff -- but maybe I\n> just don't know how to use them, or they have gotten better in the\n> last few months.\n\nI wasn't familiar with xxdiff until just now, but having played with\nit, kdiff3 is much easier for a beginner to use.  The toolbar makes it\na lot easier to select from one or the other, I find the keyboard\naccellerators to be much more intuitive (although I suppose if you are\na vi or nethack fan the H, J, K keys will make sense to you :-).  \n\nIn addition, with xxdiff it gives the user way too many options about\nwhether you want to save the left, right, or center, or merged\nwindows.  That makes sense maybe if you are doing something completely\ngeneral, but too many options is a net negative, not a feature.  I\nprefer kdiff3, where you simply hit the save icon, and it saves the\nreconciled merged file to the specified output file (which the\ngit-mergetool specified to kdiff3 on the command-line).  So from the\nworkflow perspective, kdiff3 fits in much more cleanly than xxdiff.  \n\nThe one advantage xxdiff has that I can see (and maybe that's why you\nlike it?) is that it has the -U feature which allows it to pick apart\nthe merge conflict markers and so you can use it fairly easily simply\nby saying \"xxdiff -U hello.c\".  With kdiff3 it's a lot more\ncomplicated to invoke off the command-line, with something like:\n\n\tkdiff3 --auto hello.c.BASE hello.c.LOCAL hello.c.REMOTE -o hello.c\n\n...but that's why you have a shell script to keep you away from such\nnastyness.  All I need to do with my mergetool script is to type, \"git\nmergetool\" to merge all unresolved merge conflicts, or \"git mergetool\nhello.c\" if I only want to resolve conflicts in a single file.\n\n> I had written (and posted) a git-xxdiff earlier. A (minor) concern is\n> that from a packaging and dependencies perspective, the packager has\n> to suggest *all* of them, and still a default install may not work at\n> all -- it might be a good idea to suggest what to install in the error\n> message. Or depend on all of them (yuck!).\n\nDepending on all of them is definitely a bad idea.  Suggesting all of\nthem doesn't seem to be a big issue, and I don't see what's the\nproblem if git-mergetool can't find a graphical resolver; it can\nalways fall back to opening the file in an editor and asking the user\nto resolve the conflict manually.\n\n> One thing I _don't_ want as a user is to see the graphical mergers\n> starting by default. Most merges are trivial, and I can just edit them\n> in emacs or vi.\n\nWell, git will handle most merges automatially for you anyway.  You\nwould only use git mergetool to handle the merge conflicts.\n\n\t\t\t\t\t\t- Ted\n"},{"id":"36279","messageId":"46a038f90703042048m42ec07f6yab41c2a2de410ac9@mail.gmail.com","threadId":"7077","inReplyTo":"20070305040406.GB26781@thunk.org","subject":"Re: Conflict editing","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2007-03-05T04:48:32Z","receivedAt":"2007-03-05T04:48:32Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 3/5/07, Theodore Tso <tytso@mit.edu> wrote:\n> On Mon, Mar 05, 2007 at 10:59:33AM +1300, Martin Langhoff wrote:\n> > I find xxdiff much better than meld, tkdiff and kdiff -- but maybe I\n> > just don't know how to use them, or they have gotten better in the\n> > last few months.\n>\n> I wasn't familiar with xxdiff until just now, but having played with\n> it, kdiff3 is much easier for a beginner to use.  The toolbar makes it\n> a lot easier to select from one or the other, I find the keyboard\n> accellerators to be much more intuitive (although I suppose if you are\n> a vi or nethack fan the H, J, K keys will make sense to you :-).\n\nNo, I hate that navigation. But arrow keys and pageup/down work great\nfor me. Mouse navigation is superb too.\n\n> In addition, with xxdiff it gives the user way too many options about\n> whether you want to save the left, right, or center, or merged\n> windows.\n\nI can understand that. But it also does in-the-line diff colouring\nthat I haven't seen the others do. Where the lines don't match on\nsomething small, you can see the offending characters in a slightly\ndifferent tone (I'm colourblind, so I'm unsure of the exact colour,\nbut it does work).\n\nI find xxdiff to be an order of magnitude faster than meld and kdiff3.\nAnd at least kdiff3 spews garbage about trying to start the whole of\nKDE infrastructure hairball so it messes up my terminal where I had\ninteresting messages from the just-executed git-pull.\n\nSo at least for now xxdiff is my well-behaved, flexible and fast tool ;-)\n\nAnd I can see at a glance that single quotes got replaced with double\nquotes or a trailing space got added or trimmed and _that_'s why the\nthing didn't merge cleanly.\n\n> > One thing I _don't_ want as a user is to see the graphical mergers\n> > starting by default. Most merges are trivial, and I can just edit them\n> > in emacs or vi.\n>\n> Well, git will handle most merges automatially for you anyway.  You\n> would only use git mergetool to handle the merge conflicts.\n\nSorry -- I meant to say most conflicts are trivial. Someone mentioned\nauto-running gui tools on any conflict, and don't think I want that.\n\ncheers,\n\n\nmartin\n"},{"id":"36281","messageId":"190CCFDA-7BCC-4CC9-81D5-F38B14D8D54D@silverinsanity.com","threadId":"7077","inReplyTo":"Pine.LNX.4.63.0703041339350.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Conflict editing","fromName":"Brian Gernhardt","fromEmail":"benji@silverinsanity.com","sentAt":"2007-03-05T06:25:09Z","receivedAt":"2007-03-05T06:25:09Z","isPatch":false,"sender":{"key":"benji@silverinsanity.com","avatar":"https://gravatar.com/avatar/e06c101dbc25c68114d859b4a9ec7cf8a2c52fd2b0270ef0eac0e2e63ff22311?d=mp&s=160"},"body":"\nOn Mar 4, 2007, at 7:43 AM, Johannes Schindelin wrote:\n\n> Of course, this script is dumb and has no way to edit files whose  \n> names\n> contain spaces\n\nWouldn't using xargs fix that?\n\n> \"${VISUAL:-${EDITOR:-vi}}\" $(git ls-files --unmerged | cut -b51- |  \n> uniq)\n\ngit ls-files --unmerged | cut -b51- | uniq | xargs \"${VISUAL:-$ \n{EDITOR:-vi}}\"\n\n~~ Brian Gernhardt\n"},{"id":"36315","messageId":"Pine.LNX.4.63.0703051223420.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"7077","inReplyTo":"190CCFDA-7BCC-4CC9-81D5-F38B14D8D54D@silverinsanity.com","subject":"Re: Conflict editing","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-03-05T11:25:29Z","receivedAt":"2007-03-05T11:25:29Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 5 Mar 2007, Brian Gernhardt wrote:\n\n> On Mar 4, 2007, at 7:43 AM, Johannes Schindelin wrote:\n> \n> > Of course, this script is dumb and has no way to edit files whose \n> > names contain spaces\n> \n> Wouldn't using xargs fix that?\n\nI tried that first, even in the proper form to catch newlines also, with \n\"-z\" for ls-files and \"-0\" for xargs.\n\nAlas, vi complained to me by saying \"Not started from a terminal\", and \nwrecking my terminal settings. For example, echo was set to off, and \nCtrl+C no longer worked.\n\nSince I am a nice person, I did not want you to have the same experience \nwith this dumb script.\n\nCiao,\nDscho\n"},{"id":"36328","messageId":"20070305150728.GB17844@informatik.uni-freiburg.de","threadId":"7077","inReplyTo":"Pine.LNX.4.63.0703051223420.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Conflict editing","fromName":"Uwe Kleine-König","fromEmail":"ukleinek@informatik.uni-freiburg.de","sentAt":"2007-03-05T15:07:28Z","receivedAt":"2007-03-05T15:07:28Z","isPatch":false,"sender":{"key":"u.kleine-koenig@pengutronix.de","avatar":"https://gravatar.com/avatar/354b5e3ceb2806a2f1e1e382ac29ddbdad18288654da62b61eb13583a857eee7?d=mp&s=160"},"body":"Hello,\n\nJohannes Schindelin wrote:\n> > > Of course, this script is dumb and has no way to edit files whose \n> > > names contain spaces\n> > \n> > Wouldn't using xargs fix that?\n> \n> I tried that first, even in the proper form to catch newlines also, with \n> \"-z\" for ls-files and \"-0\" for xargs.\n> \n> Alas, vi complained to me by saying \"Not started from a terminal\", and \n> wrecking my terminal settings. For example, echo was set to off, and \n> Ctrl+C no longer worked.\nAnother problem is, that only GNU xargs has -0, the version on Solaris\n(and probably on *BSD) doesn't know it.\n\nBest regards\nUwe\n\n-- \nUwe Kleine-König\n\nhttp://www.google.com/search?q=gigabyte+in+bit\n"},{"id":"36355","messageId":"CFF9D792-A563-408A-8E28-1F045B0952F8@silverinsanity.com","threadId":"7077","inReplyTo":"Pine.LNX.4.63.0703051223420.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Conflict editing","fromName":"Brian Gernhardt","fromEmail":"benji@silverinsanity.com","sentAt":"2007-03-05T19:27:48Z","receivedAt":"2007-03-05T19:27:48Z","isPatch":false,"sender":{"key":"benji@silverinsanity.com","avatar":"https://gravatar.com/avatar/e06c101dbc25c68114d859b4a9ec7cf8a2c52fd2b0270ef0eac0e2e63ff22311?d=mp&s=160"},"body":"\nOn Mar 5, 2007, at 6:25 AM, Johannes Schindelin wrote:\n\n> Alas, vi complained to me by saying \"Not started from a terminal\", and\n> wrecking my terminal settings. For example, echo was set to off, and\n> Ctrl+C no longer worked.\n\nOf course.  I use \"xargs vim\" on a semi-regular basis and have  \nforgotten that it mucks up some terms and behaves slightly oddly.   \nIt's just one of the little things I deal with on a regular basis and  \nmostly ignore.\n\n> Since I am a nice person, I did not want you to have the same  \n> experience\n> with this dumb script.\n\nYes, we should be nice and not screw with people's heads, even if  \nmine is already pretty screwy.\n\n~~ Brian\n"}]}