{"thread":{"id":"11239","subject":"[ANNOUNCE] ugit: a pyqt-based git gui // was: Re: If you would write git from scratch now, what would you change?","startedAt":"2007-12-11T13:48:32Z","lastAt":"2007-12-14T06:32:17Z","messageCount":31,"participants":["David","Marco Costalba","Jason Sewall","Alex Riesen","Steffen Prohaska","Jakub Narebski","Shawn O. Pearce","Johannes Schindelin","Junio C Hamano","Jean-François Veillette","Wincent Colaiuta","Johannes Sixt"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"62715","messageId":"402731c90712110548k67f28b64w5afa93ee908ce73b@mail.gmail.com","threadId":"11239","inReplyTo":null,"subject":"[ANNOUNCE] ugit: a pyqt-based git gui // was: Re: If you would write git from scratch now, what would you change?","fromName":"David","fromEmail":"davvid@gmail.com","sentAt":"2007-12-11T13:48:32Z","receivedAt":"2007-12-11T13:48:32Z","isPatch":false,"sender":{"key":"davvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13196?v=4"},"body":"On Dec 4, 2007 3:00 AM, Andy Parkins wrote:\n>\n> Qt puts a common face on threading, process control, networking, file\n> systems, internationalisation, rendering, openGL, and of course the GUI\n> itself. Tcl/Tk (to take the most wicked example) gives you applications\n> that are much harder to make run on Windows than on UNIX.\n>\n> Anyway, I don't want to sound like a strange Qt fan boy; the above is simply\n> my justification for putting \"git-gui in Qt\" on my wish list.\n>\n> Andy\n> --\n> Dr Andy Parkins, M Eng (hons), MIET\n> andyparkins@gmail.com\n\nFor whatever it's worth, I've written a PyQt4-based git gui. For lack\nof a better name I call it ugit, as in \"I git, you git, we all git\nwith ugit\" (or something silly like that).\n\nThough there's still a few things remaining to be implemented, the\nbulk of the initial groundwork is already done. All you need to\nbuild/run it is python and pyqt4 (pyuic4). I've deliberately tried to\nkeep the interface similar to git-gui for now since it is obviously\nbased on it, but that's not a requirement.\n\nOf course there are some notable things missing (such as proper i18n),\nbut it's not too bad for a first draft.\n\nFor more details (and the code) see:\nhttp://repo.or.cz/w/ugit.git\n\nEnjoy,\n-- David A.\n"},{"id":"62759","messageId":"e5bfff550712111020k51829c03n5d64a94ce7c7ac2a@mail.gmail.com","threadId":"11239","inReplyTo":"402731c90712110548k67f28b64w5afa93ee908ce73b@mail.gmail.com","subject":"Re: [ANNOUNCE] ugit: a pyqt-based git gui // was: Re: If you would write git from scratch now, what would you change?","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-12-11T18:20:00Z","receivedAt":"2007-12-11T18:20:00Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On Dec 11, 2007 2:48 PM, David wrote:\n>\n> Of course there are some notable things missing (such as proper i18n),\n> but it's not too bad for a first draft.\n>\n\nCannot start the thing...\n\n$ python bin/ugit.py\nTraceback (most recent call last):\n File \"bin/ugit.py\", line 6, in \n from ugitlibs.models import GitModel\nImportError: No module named ugitlibs.models\n$\n\nSome hints?\n\nThanks\nMarco\n"},{"id":"62771","messageId":"31e9dd080712111114t2bbdba60m18b7d6210f3f9174@mail.gmail.com","threadId":"11239","inReplyTo":"e5bfff550712111020k51829c03n5d64a94ce7c7ac2a@mail.gmail.com","subject":"Re: [ANNOUNCE] ugit: a pyqt-based git gui // was: Re: If you would write git from scratch now, what would you change?","fromName":"Jason Sewall","fromEmail":"jasonsewall@gmail.com","sentAt":"2007-12-11T19:14:42Z","receivedAt":"2007-12-11T19:14:42Z","isPatch":false,"sender":{"key":"jasonsewall@gmail.com","avatar":null},"body":"On Dec 11, 2007 1:20 PM, Marco Costalba wrote:\n> Cannot start the thing...\n>\n> $ python bin/ugit.py\n> Traceback (most recent call last):\n> File \"bin/ugit.py\", line 6, in \n> from ugitlibs.models import GitModel\n> ImportError: No module named ugitlibs.models\n> $\n>\n> Some hints?\n\nWhere did you install it?\n\nBecause I had the same problem when I did\n./configure\nbecause it puts the python stuff in\n/usr/local/python2.5/site-packages/... and python doesn't look there\nby default.\n./configure --prefix=/usr fixed that for me (and I'm sure there's a\nway to tell python to look in /usr/local... too, but I can't be\nbothered with that.\n\nI re-installed without the prefix and that error disappeared, but now I get\nTraceback (most recent call last):\n File \"/usr/local/bin/ugit\", line 12, in \n view = GitView (app.activeWindow())\n File \"../py/views.py\", line 15, in __init__\n File \"default/ui/Window.py\", line 43, in setupUi\nAttributeError: setLeftMargin\n\nI'm too busy to poke around and see why that's happening, but\nhopefully someone can.\n\nThis with Python 2.5.1 and PyQt4 4.2-8 (from an up-to-date Fedora 8 install)\n\nJason\n"},{"id":"62779","messageId":"e5bfff550712111133j66c4b9adx9f57661cc720aa41@mail.gmail.com","threadId":"11239","inReplyTo":"31e9dd080712111114t2bbdba60m18b7d6210f3f9174@mail.gmail.com","subject":"Re: [ANNOUNCE] ugit: a pyqt-based git gui // was: Re: If you would write git from scratch now, what would you change?","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-12-11T19:33:45Z","receivedAt":"2007-12-11T19:33:45Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On Dec 11, 2007 8:14 PM, Jason Sewall wrote:\n> On Dec 11, 2007 1:20 PM, Marco Costalba wrote:\n\n> ./configure --prefix=/usr fixed that for me (and I'm sure there's a\n> way to tell python to look in /usr/local... too, but I can't be\n> bothered with that.\n>\n\n./configure --prefix=$HOME/bin\n\n(half) worked thanks.\n\n\n\n> I re-installed without the prefix and that error disappeared, but now I get\n> Traceback (most recent call last):\n> File \"/usr/local/bin/ugit\", line 12, in \n> view = GitView (app.activeWindow())\n> File \"../py/views.py\", line 15, in __init__\n> File \"default/ui/Window.py\", line 43, in setupUi\n> AttributeError: setLeftMargin\n>\n> I'm too busy to poke around and see why that's happening, but\n> hopefully someone can.\n>\n\nI have only $HOME/bin in path so I manually moved main 4 files and\ndirectory ugitlibs under bin/\n\n$HOME/bin -> ugit ugit.py uit.pyc ugit.pyo\n -> ugitlibs/ -> with remaining files\n\n\nAnd it worked.\n\nMarco\n"},{"id":"62798","messageId":"402731c90712111254q1cb99c6al47538971d93b4592@mail.gmail.com","threadId":"11239","inReplyTo":"e5bfff550712111133j66c4b9adx9f57661cc720aa41@mail.gmail.com","subject":"Re: [ANNOUNCE] ugit: a pyqt-based git gui // was: Re: If you would write git from scratch now, what would you change?","fromName":"David","fromEmail":"davvid@gmail.com","sentAt":"2007-12-11T20:54:46Z","receivedAt":"2007-12-11T20:54:46Z","isPatch":false,"sender":{"key":"davvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13196?v=4"},"body":"On Dec 11, 2007 11:33 AM, Marco Costalba wrote:\n> On Dec 11, 2007 8:14 PM, Jason Sewall wrote:\n> > On Dec 11, 2007 1:20 PM, Marco Costalba wrote:\n>\n> > ./configure --prefix=/usr fixed that for me (and I'm sure there's a\n> > way to tell python to look in /usr/local... too, but I can't be\n> > bothered with that.\n> >\n>\n> ./configure --prefix=$HOME/bin\n>\n> (half) worked thanks.\n>\n\nHello\n\nTo allow python to find the libs you just have to set $PYTHONPATH to\ninclude $PREFIX/lib/python2.4/site-packages (change that 2.4 to 2.5\nif you're on python2.5). Of course in a packaged form that wouldn't\nbe an issue since $PREFIX=/usr, but for test-driving it you'd probably\nneed to set PYTHONPATH. Are there any distros that don't use\n$PREFIX/lib/python2.x/site-packages? If not, it wouldn't hurt to add\nan assumption about the installation layout into the main script.\n\n\n> > I re-installed without the prefix and that error disappeared, but now I get\n> > Traceback (most recent call last):\n> > File \"/usr/local/bin/ugit\", line 12, in \n> > view = GitView (app.activeWindow())\n> > File \"../py/views.py\", line 15, in __init__\n> > File \"default/ui/Window.py\", line 43, in setupUi\n> > AttributeError: setLeftMargin\n\nAs for the setLeftMarginError -- That could be because you have py/qt\n4.2. The ui files were generated with designer-qt4 (4.3.x) so you\nmight need a more recent pyqt4. I'll see if I can grab an older\nversion of pyqt and use it for all of the ui designs (.ui files are\nprobably forward but not backwards compatible).\n"},{"id":"62811","messageId":"31e9dd080712111329j2c8b22ebs38ab727a5fbe85fb@mail.gmail.com","threadId":"11239","inReplyTo":"402731c90712111254q1cb99c6al47538971d93b4592@mail.gmail.com","subject":"Re: [ANNOUNCE] ugit: a pyqt-based git gui // was: Re: If you would write git from scratch now, what would you change?","fromName":"Jason Sewall","fromEmail":"jasonsewall@gmail.com","sentAt":"2007-12-11T21:29:52Z","receivedAt":"2007-12-11T21:29:52Z","isPatch":false,"sender":{"key":"jasonsewall@gmail.com","avatar":null},"body":"On Dec 11, 2007 3:54 PM, David wrote:\n> > On Dec 11, 2007 8:14 PM, Jason Sewall wrote:\n> >\n> > I re-installed without the prefix and that error disappeared, but now I get\n> > Traceback (most recent call last):\n> > File \"/usr/local/bin/ugit\", line 12, in \n> > view = GitView (app.activeWindow())\n> > File \"../py/views.py\", line 15, in __init__\n> > File \"default/ui/Window.py\", line 43, in setupUi\n> > AttributeError: setLeftMargin\n>\n> As for the setLeftMarginError -- That could be because you have py/qt\n> 4.2. The ui files were generated with designer-qt4 (4.3.x) so you\n> might need a more recent pyqt4. I'll see if I can grab an older\n> version of pyqt and use it for all of the ui designs (.ui files are\n> probably forward but not backwards compatible).\n\nThat was it - as a matter of fact, the package updater for my distro\nwas asking me to upgrade.\n\nWell done, though I don't think I'm going to abandon git-gui quite yet.\n\nThe most valuable thing git-gui does, IMHO, is give you fine control\nover what you stage in a commit. The two-paned view of staged and\nunstaged changes with the view of the actual changes makes it really\neasy to see exactly what you are committing. And the graphical\n\"{Un}stage hunk for commit\" business, which ugit seems to lack so far,\nis really excellent - it's much easier to use than git add -i for\npartial adds.\n\nI would like to see git add -i's hunk-splitting functionality in a\ngraphical tool for that matter.\n\nAnyway, ugit is very good for a first draft; its text display beats\nwhats in git-gui in a big way (and I would *hope* qt4 would beat\nTcl/Tk at that at least).\n\nOne suggestion:\nFor Westerners like me, having \"staged\" on the left and \"unstaged\" on\nthe right seems a little unnatural; I'd be curious to hear others'\nopinions on that.\n\nJason\n"},{"id":"62823","messageId":"20071211223742.GB19857@steel.home","threadId":"11239","inReplyTo":"402731c90712110548k67f28b64w5afa93ee908ce73b@mail.gmail.com","subject":"Re: [ANNOUNCE] ugit: a pyqt-based git gui // was: Re: If you would write git from scratch now, what would you change?","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-12-11T22:37:42Z","receivedAt":"2007-12-11T22:37:42Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"David, Tue, Dec 11, 2007 14:48:32 +0100:\n> Though there's still a few things remaining to be implemented, the\n> bulk of the initial groundwork is already done. All you need to\n> build/run it is python and pyqt4 (pyuic4). I've deliberately tried to\n> keep the interface similar to git-gui for now since it is obviously\n> based on it, but that's not a requirement.\n\nInteresting. I had to start it like this:\n\n\t$ export PYTHONPATH=$(pwd)/build/default:$(pwd)/build/default/ui\n\t$ python ./build/default/bin/ugit.pyc\n\nIt has some problem with merges in \"Git Commit Browser\": takes a lot\nof CPU and very slowly generates a very big diff.\n\nThe diff view is very ... dark. Out of place, when the rest of the\ninterface corresponds to system theme (mine is rather light).\n"},{"id":"62825","messageId":"F7561A3C-06F1-413B-96E2-F9707C193FB2@zib.de","threadId":"11239","inReplyTo":"20071211223742.GB19857@steel.home","subject":"Re: [ANNOUNCE] ugit: a pyqt-based git gui // was: Re: If you would write git from scratch now, what would you change?","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-12-11T23:08:57Z","receivedAt":"2007-12-11T23:08:57Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Dec 11, 2007, at 11:37 PM, Alex Riesen wrote:\n\n> David, Tue, Dec 11, 2007 14:48:32 +0100:\n>> Though there's still a few things remaining to be implemented, the\n>> bulk of the initial groundwork is already done. All you need to\n>> build/run it is python and pyqt4 (pyuic4). I've deliberately \n>> tried to\n>> keep the interface similar to git-gui for now since it is obviously\n>> based on it, but that's not a requirement.\n>\n> Interesting. I had to start it like this:\n>\n> \t$ export PYTHONPATH=$(pwd)/build/default:$(pwd)/build/default/ui\n> \t$ python ./build/default/bin/ugit.pyc\n>\n> It has some problem with merges in \"Git Commit Browser\": takes a lot\n> of CPU and very slowly generates a very big diff.\n>\n> The diff view is very ... dark. Out of place, when the rest of the\n> interface corresponds to system theme (mine is rather light).\n\n\nYeah, it's dark here (Mac OS X), too -- doesn't look very\nfriendly.\n\nIt took me some time to get the full Qt, SIP, PyQT toolchain\nrunning ... below's my first (tiny) fix that makes\n\"Branch > Create ...\" work if you don't select track.\n\n\tSteffen\n\ndiff --git a/py/cmds.py b/py/cmds.py\nindex 5abf930..4a35ead 100644\n--- a/py/cmds.py\n+++ b/py/cmds.py\n@@ -119,8 +119,8 @@ def git_create_branch (name, base, track=False):\n '''Creates a branch starting from base. Pass track=True\n to create a remote tracking branch.'''\n cmd = 'git branch'\n- if track: cmd += ' --track '\n- cmd += '%s %s' % ( utils.shell_quote (name),\n+ if track: cmd += ' --track'\n+ cmd += ' %s %s' % ( utils.shell_quote (name),\n utils.shell_quote (base))\n return commands.getoutput (cmd)\n"},{"id":"62834","messageId":"m363z4srf3.fsf@roke.D-201","threadId":"11239","inReplyTo":"402731c90712110548k67f28b64w5afa93ee908ce73b@mail.gmail.com","subject":"Re: [ANNOUNCE] ugit: a pyqt-based git gui // was: Re: If you would write git from scratch now, what would you change?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-12-12T00:11:30Z","receivedAt":"2007-12-12T00:11:30Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"David writes:\n\n> For whatever it's worth, I've written a PyQt4-based git gui. For lack\n> of a better name I call it ugit, as in \"I git, you git, we all git\n> with ugit\" (or something silly like that).\n\nI have added it to http://git.or.cz/gitwiki/InterfacesFrontendsAndTools\n\nFunny that both (h)gct and Qct, which are commit tools too (although\nmulti-SCM) are also written in PyQt...\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"62851","messageId":"20071212041002.GN14735@spearce.org","threadId":"11239","inReplyTo":"31e9dd080712111329j2c8b22ebs38ab727a5fbe85fb@mail.gmail.com","subject":"Re: [ANNOUNCE] ugit: a pyqt-based git gui // was: Re: If you would write git from scratch now, what would you change?","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-12-12T04:10:02Z","receivedAt":"2007-12-12T04:10:02Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Jason Sewall wrote:\n> Anyway, ugit is very good for a first draft; its text display beats\n> whats in git-gui in a big way (and I would *hope* qt4 would beat\n> Tcl/Tk at that at least).\n\nAre you just using the wrong fonts under git-gui? I mean both\nTk and qt4 are drawing text through your windowing system, from\nthe same pool of font files... if qt4 can draw nice text then\nso can Tk, right?\n\n-- \nShawn.\n"},{"id":"62854","messageId":"31e9dd080712112113u44b30c62ja012951fba958c5d@mail.gmail.com","threadId":"11239","inReplyTo":"20071212041002.GN14735@spearce.org","subject":"Re: [ANNOUNCE] ugit: a pyqt-based git gui // was: Re: If you would write git from scratch now, what would you change?","fromName":"Jason Sewall","fromEmail":"jasonsewall@gmail.com","sentAt":"2007-12-12T05:13:03Z","receivedAt":"2007-12-12T05:13:03Z","isPatch":false,"sender":{"key":"jasonsewall@gmail.com","avatar":null},"body":"On Dec 11, 2007 11:10 PM, Shawn O. Pearce wrote:\n> Jason Sewall wrote:\n> > Anyway, ugit is very good for a first draft; its text display beats\n> > whats in git-gui in a big way (and I would *hope* qt4 would beat\n> > Tcl/Tk at that at least).\n>\n> Are you just using the wrong fonts under git-gui? I mean both\n> Tk and qt4 are drawing text through your windowing system, from\n> the same pool of font files... if qt4 can draw nice text then\n> so can Tk, right?\n\nI don't know much about graphical toolkits and the like, but I think\nthat the more modern ones have fancy features like antialiasing and\nsubpixel rendering, which makes a big difference when you're working\non a laptop with a tiny screen.\n\nTake a look for yourself:\nhttp://img441.imageshack.us/img441/492/comparejd6.png\n\nThey are obviously using different fonts there (because I can't figure\nout what font ugit is using) but there is a difference in rendering\nquality to be sure.\n\nThe qt stuff fits better with the rest of my system better too (even\nthough I'm using gnome) - it's entirely the result of Tk being\nlightweight and a million years old, when UI conventions were\ndifferent (like every menu being detachable, and antique scrollbars).\nI'm not here to start a toolkit flame war (we had a toolkit dogpile on\nthe list last week, I think) I'm just pointing out that Tk is from a\ndifferent era.\n\nI use git-gui and gitk for my git graphical needs because they rock\nand at the end of the day, the fonts and antialiasing aren't that big\nof a deal, especially since I'm usually doing quick scans and searches\nover the information those tools display, not reading novels in them.\n\nJason\n"},{"id":"62855","messageId":"20071212052329.GR14735@spearce.org","threadId":"11239","inReplyTo":"31e9dd080712112113u44b30c62ja012951fba958c5d@mail.gmail.com","subject":"Re: [ANNOUNCE] ugit: a pyqt-based git gui // was: Re: If you would write git from scratch now, what would you change?","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-12-12T05:23:29Z","receivedAt":"2007-12-12T05:23:29Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Jason Sewall wrote:\n> I don't know much about graphical toolkits and the like, but I think\n> that the more modern ones have fancy features like antialiasing and\n> subpixel rendering, which makes a big difference when you're working\n> on a laptop with a tiny screen.\n\nOh, that's a good point. On my Mac OS X system with the aqua port\nof Tk the fonts render just as good as anything else on this box.\nI guess the Aqua port of Tk is just better than the X11 port of\nTk is. :)\n \n> Take a look for yourself:\n> http://img441.imageshack.us/img441/492/comparejd6.png\n> \n> They are obviously using different fonts there (because I can't figure\n> out what font ugit is using) but there is a difference in rendering\n> quality to be sure.\n\nBe nice to know what ugit is using, or really how its guessing the\ndefault font. I wonder what font you are using with your git-gui.\nThe default Tk picks on X11 is basically crap, but git-gui goes\nwith your system default as its own default.\n \n> The qt stuff fits better with the rest of my system better too (even\n> though I'm using gnome) - it's entirely the result of Tk being\n> lightweight and a million years old, when UI conventions were\n> different (like every menu being detachable, and antique scrollbars).\n> I'm not here to start a toolkit flame war (we had a toolkit dogpile on\n> the list last week, I think) I'm just pointing out that Tk is from a\n> different era.\n\nYes. The tile extension in 8.5 should actually improve this quite\na bit; as I understand it there is a GTK backend for Tk with that\nset of extensions, making the UI look more modern on X11, assuming\nGTK was available when Tk was compiled, etc...\n\nI have yet to make git-gui use the tile extension. Its however\nplanned to happen in the near-ish future.\n \n> I use git-gui and gitk for my git graphical needs because they rock\n> and at the end of the day, the fonts and antialiasing aren't that big\n> of a deal, especially since I'm usually doing quick scans and searches\n> over the information those tools display, not reading novels in them.\n\nGood points. Features win over pretty most of the time. But at\nsome point pretty is important; especially to new user adoption.\nPlus if you are looking at it all day long it shouldn't be jarring\nto the eyes. But git-gui still isn't even where I want it ot\nbe feature-wise. E.g. I'd *love* to teach it inotify support,\nso you don't even need to have that Rescan button.\n\n-- \nShawn.\n"},{"id":"62905","messageId":"31e9dd080712120702k36a959cfh3e2a5c5fb076d922@mail.gmail.com","threadId":"11239","inReplyTo":"20071212052329.GR14735@spearce.org","subject":"Re: [ANNOUNCE] ugit: a pyqt-based git gui // was: Re: If you would write git from scratch now, what would you change?","fromName":"Jason Sewall","fromEmail":"jasonsewall@gmail.com","sentAt":"2007-12-12T15:02:44Z","receivedAt":"2007-12-12T15:02:44Z","isPatch":false,"sender":{"key":"jasonsewall@gmail.com","avatar":null},"body":"On Dec 12, 2007 12:23 AM, Shawn O. Pearce wrote:\n> > I use git-gui and gitk for my git graphical needs because they rock\n> > and at the end of the day, the fonts and antialiasing aren't that big\n> > of a deal, especially since I'm usually doing quick scans and searches\n> > over the information those tools display, not reading novels in them.\n>\n> Good points. Features win over pretty most of the time. But at\n> some point pretty is important; especially to new user adoption.\n> Plus if you are looking at it all day long it shouldn't be jarring\n> to the eyes. But git-gui still isn't even where I want it ot\n> be feature-wise. E.g. I'd *love* to teach it inotify support,\n> so you don't even need to have that Rescan button.\n\nOn that note, did you see what I wrote above, about having \"split\nhunk\" functionality? That would be killer. I know, I know, I should\nwrite a patch... well, I've got a paper deadline coming up, and the\ntime it takes me to run git add -i over some clicks in git-gui plus\nthe time to figure out how to add that feature doesn't balance...\n\nJason\n"},{"id":"62940","messageId":"Pine.LNX.4.64.0712121814260.27959@racer.site","threadId":"11239","inReplyTo":"31e9dd080712120702k36a959cfh3e2a5c5fb076d922@mail.gmail.com","subject":"Re: [ANNOUNCE] ugit: a pyqt-based git gui // was: Re: If you would write git from scratch now, what would you change?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-12-12T18:15:30Z","receivedAt":"2007-12-12T18:15:30Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 12 Dec 2007, Jason Sewall wrote:\n\n> On Dec 12, 2007 12:23 AM, Shawn O. Pearce wrote:\n> > > I use git-gui and gitk for my git graphical needs because they rock \n> > > and at the end of the day, the fonts and antialiasing aren't that \n> > > big of a deal, especially since I'm usually doing quick scans and \n> > > searches over the information those tools display, not reading \n> > > novels in them.\n> >\n> > Good points. Features win over pretty most of the time. But at some \n> > point pretty is important; especially to new user adoption. Plus if \n> > you are looking at it all day long it shouldn't be jarring to the \n> > eyes. But git-gui still isn't even where I want it ot be \n> > feature-wise. E.g. I'd *love* to teach it inotify support, so you \n> > don't even need to have that Rescan button.\n> \n> On that note, did you see what I wrote above, about having \"split hunk\" \n> functionality?\n\nI had a patch for splitting hunks in git-gui in August, but there were \nsome issues that I did not yet resolve. If you want to work on it, I'll \ngladly share that patch with you.\n\nCiao,\nDscho\n"},{"id":"62948","messageId":"31e9dd080712121050i45981ed5u845b71f0e73aa8e2@mail.gmail.com","threadId":"11239","inReplyTo":"Pine.LNX.4.64.0712121814260.27959@racer.site","subject":"Re: [ANNOUNCE] ugit: a pyqt-based git gui // was: Re: If you would write git from scratch now, what would you change?","fromName":"Jason Sewall","fromEmail":"jasonsewall@gmail.com","sentAt":"2007-12-12T18:50:55Z","receivedAt":"2007-12-12T18:50:55Z","isPatch":false,"sender":{"key":"jasonsewall@gmail.com","avatar":null},"body":"On Dec 12, 2007 1:15 PM, Johannes Schindelin wrote:\n> On Wed, 12 Dec 2007, Jason Sewall wrote:\n> > On that note, did you see what I wrote above, about having \"split hunk\"\n> > functionality?\n>\n> I had a patch for splitting hunks in git-gui in August, but there were\n> some issues that I did not yet resolve. If you want to work on it, I'll\n> gladly share that patch with you.\n\nSure, send it along. I'm not going to make any promises, but I could\nprobably find time poke around in there.\n\nJason\n"},{"id":"62952","messageId":"Pine.LNX.4.64.0712121931050.27959@racer.site","threadId":"11239","inReplyTo":"31e9dd080712121050i45981ed5u845b71f0e73aa8e2@mail.gmail.com","subject":"[PATCH] Teach git-gui to split hunks","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-12-12T19:37:45Z","receivedAt":"2007-12-12T19:37:45Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"\nWhen you select the context menu item \"Split Hunk\" in the diff area,\ngit-gui will now split the current hunk so that a new hunk starts at\nthe current position.\n\nFor this to work, apply has to be called with --unidiff-zero, since\nthe new hunks can start or stop with a \"-\" or \"+\" line.\n\nSigned-off-by: Johannes Schindelin \n---\n\n\tOn Wed, 12 Dec 2007, Jason Sewall wrote:\n\n\t> On Dec 12, 2007 1:15 PM, Johannes Schindelin wrote:\n\t> >\n\t> > I had a patch for splitting hunks in git-gui in August, but \n\t> > there were some issues that I did not yet resolve. If you \n\t> > want to work on it, I'll gladly share that patch with you.\n\t> \n\t> Sure, send it along. I'm not going to make any promises, but I \n\t> could probably find time poke around in there.\n\n\tThis was the next step that I did not yet quite complete:\n\n+proc get_context_lines {line_number context_count direction variable} {\n+ global ui_diff\n+ upvar result $variable\n+\n+ set count 0\n+ set result \"\"\n+ for {set i $line_number} {$count < $context_count} {incr i $direction} {\n+ switch -exact -- [$ui_diff get $i.0] {\n+ \" \" {\n+ append result [$ui_diff get $i.0 \"$i.lineend\"]\n+ incr count\n+ }\n+ \"-\" {\n+ append result [$ui_diff get $i.0 \"$i.lineend\"]\n+ incr count\n+ }\n+ \"@\" {\n+ return $count\n+ }\n+ \"\" {\n+ return $count\n+ }\n+ }\n+ }\n+}\n\n\tOf course, this function would be used to add some context \n\tto the new hunk boundaries (if needed), and to adjust the contexts\n\tof the remaining hunks whenever some hunk was applied.\n\n\t... and then get rid of that ugly unidiff-zero option.\n\n git-gui.sh | 4 +++\n lib/diff.tcl | 75 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++-\n 2 files changed, 78 insertions(+), 1 deletions(-)\n\ndiff --git a/git-gui.sh b/git-gui.sh\nindex 1fca11f..0798d41 100755\n--- a/git-gui.sh\n+++ b/git-gui.sh\n@@ -2567,6 +2567,10 @@ $ctxm add command \\\n \t-command {apply_hunk $cursorX $cursorY}\n set ui_diff_applyhunk [$ctxm index last]\n lappend diff_actions [list $ctxm entryconf $ui_diff_applyhunk -state]\n+$ctxm add command \\\n+\t-label [mc \"Split Hunk\"] \\\n+\t-command {split_hunk $cursorX $cursorY}\n+lappend diff_actions [list $ctxm entryconf [$ctxm index last] -state]\n $ctxm add separator\n $ctxm add command \\\n \t-label [mc \"Decrease Font Size\"] \\\ndiff --git a/lib/diff.tcl b/lib/diff.tcl\nindex 43565e4..0c3f790 100644\n--- a/lib/diff.tcl\n+++ b/lib/diff.tcl\n@@ -289,6 +289,79 @@ proc read_diff {fd} {\n \t}\n }\n \n+proc split_hunk {x y} {\n+\tglobal current_diff_path current_diff_header current_diff_side\n+\tglobal ui_diff ui_index file_states\n+\n+\tif {$current_diff_path eq {} || $current_diff_header eq {}} return\n+\tif {![lock_index apply_hunk]} return\n+\n+\tset c_lno [lindex [split [$ui_diff index @$x,$y] .] 0]\n+\tset s_idx [$ui_diff search -backwards -regexp ^@@ $c_lno.0 0.0]\n+\tif {$s_idx eq {} || $s_idx >= [expr $c_lno - 1]} {\n+\t\tunlock_index\n+\t\treturn\n+\t}\n+\tset s_lno [lindex [split $s_idx .] 0]\n+\n+\t# the first hunk will look like this: @@ -$m1,$m2 +$p1,$p2 @@\n+\t# the second hunk will look like this: @@ -$m3,$m4 +$p3,$p4 @@\n+\n+\t# get original hunk numbers\n+\tset hunk_line [$ui_diff get $s_idx \"$s_idx lineend\"]\n+\tset re \"@@ +-(\\[0-9\\]+)(,(\\[0-9\\]+))? +\\\\+(\\[0-9\\]+)(,(\\[0-9\\]+))? *@@\"\n+\tif {![regexp $re $hunk_line dummy m1 dummy m4 p1 dummy p4] ||\n+\t\t\t$m1 == 0 || $p1 == 0} { # create/delete file\n+\t\tunlock_index\n+\t\treturn\n+\t}\n+\tif {$m4 == \"\"} {\n+\t\tset m4 1\n+\t}\n+\tif {$p4 == \"\"} {\n+\t\tset p4 1\n+\t}\n+\n+\t# count changes\n+\tset m2 0\n+\tset p2 0\n+\tfor {set l [expr $s_lno + 1]} {$l < $c_lno} {incr l} {\n+\t\tswitch -exact -- [$ui_diff get $l.0] {\n+\t\t\t\" \" {\n+\t\t\t\tincr m2\n+\t\t\t\tincr p2\n+\t\t\t}\n+\t\t\t\"+\" {\n+\t\t\t\tincr p2\n+\t\t\t}\n+\t\t\t\"-\" {\n+\t\t\t\tincr m2\n+\t\t\t}\n+\t\t}\n+\t}\n+\n+\t# We could check if {$m2 == $p2 && $m2 == [expr $c_lno - $s_lno]}\n+\t# and just remove the hunk. But let's not be too clever here.\n+\n+\tset m3 [expr $m1 + $m2]\n+\tset m4 [expr $m4 - $m2]\n+\tset p3 [expr $p1 + $p2]\n+\tset p4 [expr $p4 - $p2]\n+\n+\tif {$m4 == 0 && $p4 == 0} {\n+\t\tindex_unlock\n+\t\treturn\n+\t}\n+\n+\t$ui_diff configure -state normal\n+\t$ui_diff delete $s_idx \"$s_idx lineend\"\n+\t$ui_diff insert $s_idx \"@@ -$m1,$m2 +$p1,$p2 @@\" d_@\n+\t$ui_diff insert $c_lno.0 \"@@ -$m3,$m4 +$p3,$p4 @@\\n\" d_@\n+\t$ui_diff configure -state disabled\n+\n+\tunlock_index\n+}\n+\n proc apply_hunk {x y} {\n \tglobal current_diff_path current_diff_header current_diff_side\n \tglobal ui_diff ui_index file_states\n@@ -296,7 +369,7 @@ proc apply_hunk {x y} {\n \tif {$current_diff_path eq {} || $current_diff_header eq {}} return\n \tif {![lock_index apply_hunk]} return\n \n-\tset apply_cmd {apply --cached --whitespace=nowarn}\n+\tset apply_cmd {apply --cached --whitespace=nowarn --unidiff-zero}\n \tset mi [lindex $file_states($current_diff_path) 0]\n \tif {$current_diff_side eq $ui_index} {\n \t\tset failed_msg [mc \"Failed to unstage selected hunk.\"]\n-- \n1.5.3.7.2250.g3893\n"},{"id":"62959","messageId":"7vk5nj7jkp.fsf@gitster.siamese.dyndns.org","threadId":"11239","inReplyTo":"Pine.LNX.4.64.0712121931050.27959@racer.site","subject":"Re: [PATCH] Teach git-gui to split hunks","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-12-12T20:18:46Z","receivedAt":"2007-12-12T20:18:46Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> When you select the context menu item \"Split Hunk\" in the diff area,\n> git-gui will now split the current hunk so that a new hunk starts at\n> the current position.\n>\n> For this to work, apply has to be called with --unidiff-zero, since\n> the new hunks can start or stop with a \"-\" or \"+\" line.\n> ...\n\nI still have conceptual problem with this whole thing. For example,\nwhat does that MEAN to split this hunk from your patch...\n\n> @@ -296,7 +369,7 @@ proc apply_hunk {x y} {\n> \tif {$current_diff_path eq {} || $current_diff_header eq {}} return\n> \tif {![lock_index apply_hunk]} return\n> \n> -\tset apply_cmd {apply --cached --whitespace=nowarn}\n> +\tset apply_cmd {apply --cached --whitespace=nowarn --unidiff-zero}\n> \tset mi [lindex $file_states($current_diff_path) 0]\n> \tif {$current_diff_side eq $ui_index} {\n> \t\tset failed_msg [mc \"Failed to unstage selected hunk.\"]\n\n... by clicking between the '-' and '+' lines, and apply only one half?\n\nWell, the question was not very well stated. I know what it means --\nremove that old line, without replacing with the corrected/updated one.\nThe real question is how would that be useful?\n"},{"id":"62961","messageId":"Pine.LNX.4.64.0712122037180.27959@racer.site","threadId":"11239","inReplyTo":"7vk5nj7jkp.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Teach git-gui to split hunks","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-12-12T20:39:14Z","receivedAt":"2007-12-12T20:39:14Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 12 Dec 2007, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > When you select the context menu item \"Split Hunk\" in the diff area, \n> > git-gui will now split the current hunk so that a new hunk starts at \n> > the current position.\n> >\n> > For this to work, apply has to be called with --unidiff-zero, since \n> > the new hunks can start or stop with a \"-\" or \"+\" line. ...\n> \n> I still have conceptual problem with this whole thing. For example, \n> what does that MEAN to split this hunk from your patch...\n> \n> > @@ -296,7 +369,7 @@ proc apply_hunk {x y} {\n> > \tif {$current_diff_path eq {} || $current_diff_header eq {}} return\n> > \tif {![lock_index apply_hunk]} return\n> > \n> > -\tset apply_cmd {apply --cached --whitespace=nowarn}\n> > +\tset apply_cmd {apply --cached --whitespace=nowarn --unidiff-zero}\n> > \tset mi [lindex $file_states($current_diff_path) 0]\n> > \tif {$current_diff_side eq $ui_index} {\n> > \t\tset failed_msg [mc \"Failed to unstage selected hunk.\"]\n> \n> ... by clicking between the '-' and '+' lines, and apply only one half?\n> \n> Well, the question was not very well stated. I know what it means -- \n> remove that old line, without replacing with the corrected/updated one. \n> The real question is how would that be useful?\n\nThe thing is: sometimes there is a patch which contains just one garbage \nline. (I am talking about my current working tree, so you are not allowed \nto be offended by my language in this case.)\n\nThe thing I would like to do is right click on that line, start a new \nhunk, then right click on the next line to start yet another hunk, and \napply this and the first hunk.\n\nIt is a lazy way to edit a patch.\n\nCiao,\nDscho\n"},{"id":"62963","messageId":"7A812021-DCEC-49D4-895B-2DCBEFA7CA2E@yahoo.ca","threadId":"11239","inReplyTo":"7vk5nj7jkp.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Teach git-gui to split hunks","fromName":"Jean-François Veillette","fromEmail":"jean_francois_veillette@yahoo.ca","sentAt":"2007-12-12T20:50:47Z","receivedAt":"2007-12-12T20:50:47Z","isPatch":true,"sender":{"key":"jean_francois_veillette@yahoo.ca","avatar":null},"body":"> Well, the question was not very well stated. I know what it means --\n> remove that old line, without replacing with the corrected/updated \n> one.\n> The real question is how would that be useful?\n\nI often get big hunk just because I modified whitespaces around \nrelevent pieces of code, the ability to segment the changes and only \npick isolated and specific lines for a commit (not commiting \nwhitespaces surrounding real code changes) would be very welcome.\nMaybe I should know better, but the actual hunk selection in git gui \nis quite good already, but the ability to be more precise on how a \nhunk is defined is a welcome change.\n\n- jfv\n"},{"id":"62968","messageId":"7vbq8v7cdx.fsf@gitster.siamese.dyndns.org","threadId":"11239","inReplyTo":"7A812021-DCEC-49D4-895B-2DCBEFA7CA2E@yahoo.ca","subject":"Re: [PATCH] Teach git-gui to split hunks","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-12-12T22:54:02Z","receivedAt":"2007-12-12T22:54:02Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jean-François Veillette writes:\n\n>> Well, the question was not very well stated. I know what it means --\n>> remove that old line, without replacing with the corrected/updated\n>> one.\n>> The real question is how would that be useful?\n>\n> I often get big hunk just because I modified whitespaces around\n> relevent pieces of code, the ability to segment the changes and only\n> pick isolated and specific lines for a commit (not commiting\n> whitespaces surrounding real code changes) would be very welcome.\n> Maybe I should know better, but the actual hunk selection in git gui\n> is quite good already, but the ability to be more precise on how a\n> hunk is defined is a welcome change.\n\nOh, I wasn't questioning the usefulness of hunk splitting in general.\nIt is sometimes useful and that is why we have \"add -i\".\n\nIf you have something like this:\n\n @@ -j,k +l,m @@\n common 1\n common 2\n -preimage\n +postimage\n common 3\n -deleted\n common 4\n common 5\n\nI think it makes sense to split it into two logical (overlapping) hunks:\n\n @@ -j,(k-3) +l,(m-2) @@\n common 1\n common 2\n -preimage\n +postimage\n common 3\n\nand\n\n @@ -j,(k-3) +l,(m-3) @@\n common 3\n -deleted\n common 4\n common 5\n\nand being able to apply one of them independent from the other, or\nre-combine them back into one hunk.\n\nI was just questioning if it makes sense to split a hunk like this in\nthe middle of -/+ lines:\n\n\t@@ -j,k +l,m @@\n\t common\n\t common\n\t-pre 1\n\t-pre 2\n -pre 3\n +post 1\n\t+post 2\n\t common\n\nYou could split between \"-pre 2\" and \"-pre 3\", but I do not think that\nwould be so useful. It is a different story if you allowed the above to\nfirst be transformed into this way (assuming that \"pre 1\" and \"pre 2\"\ncorresponds to \"post 1\"):\n\n\t@@ -j,k +l,m @@\n\t common\n\t common\n\t-pre 1\n\t-pre 2\n +post 1\n -pre 3\n\t+post 2\n\t common\n\nand then be split between \"+post 1\" and \"-pre 3\". That may make sense\nin some context.\n"},{"id":"62969","messageId":"0B657FBB-A1D9-4C86-BC80-C33F92D7AF77@wincent.com","threadId":"11239","inReplyTo":"7vk5nj7jkp.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Teach git-gui to split hunks","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2007-12-12T23:02:20Z","receivedAt":"2007-12-12T23:02:20Z","isPatch":true,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 12/12/2007, a las 21:18, Junio C Hamano escribió:\n\n> Johannes Schindelin writes:\n>\n>> When you select the context menu item \"Split Hunk\" in the diff area,\n>> git-gui will now split the current hunk so that a new hunk starts at\n>> the current position.\n>>\n>> For this to work, apply has to be called with --unidiff-zero, since\n>> the new hunks can start or stop with a \"-\" or \"+\" line.\n>> ...\n>\n> I still have conceptual problem with this whole thing. For example,\n> what does that MEAN to split this hunk from your patch...\n>\n>> @@ -296,7 +369,7 @@ proc apply_hunk {x y} {\n>> \tif {$current_diff_path eq {} || $current_diff_header eq {}} return\n>> \tif {![lock_index apply_hunk]} return\n>>\n>> -\tset apply_cmd {apply --cached --whitespace=nowarn}\n>> +\tset apply_cmd {apply --cached --whitespace=nowarn --unidiff-zero}\n>> \tset mi [lindex $file_states($current_diff_path) 0]\n>> \tif {$current_diff_side eq $ui_index} {\n>> \t\tset failed_msg [mc \"Failed to unstage selected hunk.\"]\n>\n> ... by clicking between the '-' and '+' lines, and apply only one \n> half?\n>\n> Well, the question was not very well stated. I know what it means --\n> remove that old line, without replacing with the corrected/updated \n> one.\n> The real question is how would that be useful?\n\nI don't know if it would be useful, but I think the more important \nconcern here is consistency. ie. it should split hunks the same way \n\"git add -i\" does. Both \"git gui\" and \"git add -i\" are official parts \nof Git, so in the interests of coherency they should share the same \nconcept of \"what it means to split a hunk\".\n\n\"git add -i\" considers any hunk where a there are multiple groups of \ndeletions and/or insertions separated by context lines to be \n\"splittable\" (on the boundaries defined by those intervening context \nline), and all others to be unsplittable. I think this is a fairly \nintuitive way to conceptualize splitting, so if it comes down to \nmaking \"git gui\" split like \"git add -i\", or making \"git add -i\" split \nlike this patch proposes that \"git gui\" should do it, then I'd vote \nfor the former.\n\nCheers,\nWincent\n"},{"id":"62988","messageId":"4760E0CF.1030805@viscovery.net","threadId":"11239","inReplyTo":"Pine.LNX.4.64.0712121931050.27959@racer.site","subject":"Re: [PATCH] Teach git-gui to split hunks","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2007-12-13T07:35:43Z","receivedAt":"2007-12-13T07:35:43Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Johannes Schindelin schrieb:\n> When you select the context menu item \"Split Hunk\" in the diff area,\n> git-gui will now split the current hunk so that a new hunk starts at\n> the current position.\n> \n> For this to work, apply has to be called with --unidiff-zero, since\n> the new hunks can start or stop with a \"-\" or \"+\" line.\n\nNACK! --unidiff-zero eats your data.\n\n1. Prepare a modification that adds 2 lines that are *not* adjacent, like this:\n\n\t@@ -6,6 +6,8 @@ git-checkout [options] [] [...]\n\t --\n\t b= create a new branch started at \n\t+first\n\t l create the new branch's reflog\n\t track arrange that the new branch tracks the remote branch\n\t+after track\n\t f proceed even if the index or working tree is not HEAD\n\t m merge local modifications into the new branch\n\n2. Reduce context to zero.\n3. Stage *second* hunk.\n\nResult: It is staged at the wrong place:\n\n\t@@ -9,4 +9,5 @@ l create the new branch's reflog\n\t track arrange that the new branch tracks the remote branch\n\t f proceed even if the index or working tree is not HEAD\n\t+after track\n\t m merge local modifications into the new branch\n\t q,quiet be quiet\n\n\nReason: --unidiff-zero can only look at the line numbers. And those are\nwrong because it doesn't account for the shift in line numbers caused by the\nfirst hunk.\n\n-- Hannes\n"},{"id":"62990","messageId":"20071213074825.GX14735@spearce.org","threadId":"11239","inReplyTo":"4760E0CF.1030805@viscovery.net","subject":"Re: [PATCH] Teach git-gui to split hunks","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-12-13T07:48:25Z","receivedAt":"2007-12-13T07:48:25Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Johannes Sixt wrote:\n> Johannes Schindelin schrieb:\n> > When you select the context menu item \"Split Hunk\" in the diff area,\n> > git-gui will now split the current hunk so that a new hunk starts at\n> > the current position.\n> > \n> > For this to work, apply has to be called with --unidiff-zero, since\n> > the new hunks can start or stop with a \"-\" or \"+\" line.\n> \n> NACK! --unidiff-zero eats your data.\n\nYea, don't worry about that, I won't be applying any patch to git-gui\nthat feeds data to git-apply with --undiff-zero. Not unless its\ncompletely bullet-proof that the hunk headers will *never* be wrong.\n\nI'd rather always apply with context and let git-apply do its thing\nto validate the hunks. If you can get the hunk headers computed\nright you can also get the context computed right, which means\ngit-apply can actually verify the patch can be applied, thus double\nchecking the splitter.\n \n> Reason: --unidiff-zero can only look at the line numbers. And those are\n> wrong because it doesn't account for the shift in line numbers caused by the\n> first hunk.\n\n-- \nShawn.\n"},{"id":"62992","messageId":"7vhcin3rv4.fsf@gitster.siamese.dyndns.org","threadId":"11239","inReplyTo":"Pine.LNX.4.64.0712121931050.27959@racer.site","subject":"Re: [PATCH] Teach git-gui to split hunks","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-12-13T08:45:35Z","receivedAt":"2007-12-13T08:45:35Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> For this to work, apply has to be called with --unidiff-zero, since\n> the new hunks can start or stop with a \"-\" or \"+\" line.\n\nYou do not have to do \"unidiff zero\". Suppose you have this hunk you\nneed to split.\n\ndiff --git a/read-cache.c b/read-cache.c\nindex 7db5588..4d12073 100644\n--- a/read-cache.c\n+++ b/read-cache.c\n@@ -12,8 +12,8 @@\n /* Index extensions.\n *\n * The first letter should be 'A'..'Z' for extensions that are not\n- * necessary for a correct operation (i.e. optimization data).\n- * When new extensions are added that _needs_ to be understood in\n+ * necessary for a correct operation (that is, optimization data).\n+ * When new extensions are added that needs to be understood in\n * order to correctly interpret the index file, pick character that\n * is outside the range, to cause the reader to abort.\n */\n\nThink about taking the s/i.e./that is,/ substitution without taking the\nother s/_needs_/needs/ substitution. You do not split the hunk between\ntwo '-' lines, but effectively make it into this hunk instead:\n\ndiff --git a/read-cache.c b/read-cache.c\nindex 7db5588..4d12073 100644\n--- a/read-cache.c\n+++ b/read-cache.c\n@@ -12,8 +12,8 @@\n /* Index extensions.\n *\n * The first letter should be 'A'..'Z' for extensions that are not\n- * necessary for a correct operation (i.e. optimization data).\n+ * necessary for a correct operation (that is, optimization data).\n * When new extensions are added that _needs_ to be understood in\n * order to correctly interpret the index file, pick character that\n * is outside the range, to cause the reader to abort.\n */\n\nThat is, , if you want to do finer grained hunk splitting than what \"git\nadd -p\" lets you do, you do _not_ let user specify \"I want to split the\nhunk into two, before this point and after this point\". Instead, let\nthe user pick zero or more '-' line and zero or more '+' line, and\nadjust the context around it. An unpicked '-' line becomes the common\ncontext, and an unpicked '+' line disappears. After that, you recount\nthe diff. That way, you do not have to do any \"unidiff zero\" cop-out.\n\nAt the same time, you can stash away what was _not_ picked, creating two\nvariants to be applied on top of the result of applying (or not\napplying) the picked patch, if you want to allow \"undo\".\n\n(variant one: applies after the above is applied)\n@@ -12,8 +12,8 @@\n /* Index extensions.\n *\n * The first letter should be 'A'..'Z' for extensions that are not\n * necessary for a correct operation (that is, optimization data).\n- * When new extensions are added that _needs_ to be understood in\n+ * When new extensions are added that needs to be understood in\n * order to correctly interpret the index file, pick character that\n * is outside the range, to cause the reader to abort.\n */\n\n(variant two: applies if the above is not applied)\n@@ -12,8 +12,8 @@\n /* Index extensions.\n *\n * The first letter should be 'A'..'Z' for extensions that are not\n * necessary for a correct operation (i.e. optimization data).\n- * When new extensions are added that _needs_ to be understood in\n+ * When new extensions are added that needs to be understood in\n * order to correctly interpret the index file, pick character that\n * is outside the range, to cause the reader to abort.\n */\n"},{"id":"62999","messageId":"4760FE4C.9010806@viscovery.net","threadId":"11239","inReplyTo":"7vhcin3rv4.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Teach git-gui to split hunks","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2007-12-13T09:41:32Z","receivedAt":"2007-12-13T09:41:32Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Junio C Hamano schrieb:\n> Johannes Schindelin writes:\n> \n>> For this to work, apply has to be called with --unidiff-zero, since\n>> the new hunks can start or stop with a \"-\" or \"+\" line.\n> \n> You do not have to do \"unidiff zero\". Suppose you have this hunk you\n> need to split.\n> \n> diff --git a/read-cache.c b/read-cache.c\n> index 7db5588..4d12073 100644\n> --- a/read-cache.c\n> +++ b/read-cache.c\n> @@ -12,8 +12,8 @@\n> /* Index extensions.\n> *\n> * The first letter should be 'A'..'Z' for extensions that are not\n> - * necessary for a correct operation (i.e. optimization data).\n> - * When new extensions are added that _needs_ to be understood in\n> + * necessary for a correct operation (that is, optimization data).\n> + * When new extensions are added that needs to be understood in\n> * order to correctly interpret the index file, pick character that\n> * is outside the range, to cause the reader to abort.\n> */\n...\n> That is, , if you want to do finer grained hunk splitting than what \"git\n> add -p\" lets you do, you do _not_ let user specify \"I want to split the\n> hunk into two, before this point and after this point\". Instead, let\n> the user pick zero or more '-' line and zero or more '+' line, and\n> adjust the context around it. An unpicked '-' line becomes the common\n> context, and an unpicked '+' line disappears. After that, you recount\n> the diff. That way, you do not have to do any \"unidiff zero\" cop-out.\n\nIn this case I would expect two adjacent hunks: one that covers the selected\nchanges, another one with the remaining changes, but each against the original:\n\n@@ -12,7 +12,7 @@\n /* Index extensions.\n *\n * The first letter should be 'A'..'Z' for extensions that are not\n- * necessary for a correct operation (i.e. optimization data).\n+ * necessary for a correct operation (that is, optimization data).\n * When new extensions are added that _needs_ to be understood in\n * order to correctly interpret the index file, pick character that\n * is outside the range, to cause the reader to abort.\n@@ -13,7 +13,7 @@\n *\n * The first letter should be 'A'..'Z' for extensions that are not\n * necessary for a correct operation (i.e. optimization data).\n- * When new extensions are added that _needs_ to be understood in\n+ * When new extensions are added that needs to be understood in\n * order to correctly interpret the index file, pick character that\n * is outside the range, to cause the reader to abort.\n */\n\nThen I can stage either one. After that operation, git-gui refreshes the\npatch display. This is now the time where the hunk that was not staged\nshould be updated to reflect the correct diff against the staged hunk.\n\n-- Hannes\n"},{"id":"63003","messageId":"Pine.LNX.4.64.0712131224340.27959@racer.site","threadId":"11239","inReplyTo":"4760E0CF.1030805@viscovery.net","subject":"Re: [PATCH] Teach git-gui to split hunks","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-12-13T12:25:34Z","receivedAt":"2007-12-13T12:25:34Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 13 Dec 2007, Johannes Sixt wrote:\n\n> Johannes Schindelin schrieb:\n> > When you select the context menu item \"Split Hunk\" in the diff area,\n> > git-gui will now split the current hunk so that a new hunk starts at\n> > the current position.\n> > \n> > For this to work, apply has to be called with --unidiff-zero, since\n> > the new hunks can start or stop with a \"-\" or \"+\" line.\n> \n> NACK! --unidiff-zero eats your data.\n\nDid I not make crystal clear that I intended this patch to be cleaned up \nfirst, to not need unidiff-zero?\n\nIf so, my sincerest apologies.\n\nTHIS PATCH IS NOT MEANT FOR APPLICATION, BUT FOR JASON TO PLAY WITH.\n\nCiao,\nDscho\n"},{"id":"63004","messageId":"Pine.LNX.4.64.0712131248500.27959@racer.site","threadId":"11239","inReplyTo":"7vhcin3rv4.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Teach git-gui to split hunks","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-12-13T12:49:45Z","receivedAt":"2007-12-13T12:49:45Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 13 Dec 2007, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > For this to work, apply has to be called with --unidiff-zero, since\n> > the new hunks can start or stop with a \"-\" or \"+\" line.\n> \n> You do not have to do \"unidiff zero\". Suppose you have this hunk you\n> need to split.\n>\n> [describes to pick zero or more '-' lines and zero or more '+' lines]\n\nI thought about that, but the UI is not trivial. The UI for my solution \nis.\n\nCiao,\nDscho\n"},{"id":"63017","messageId":"47613BA6.1060705@viscovery.net","threadId":"11239","inReplyTo":"Pine.LNX.4.64.0712131248500.27959@racer.site","subject":"Re: [PATCH] Teach git-gui to split hunks","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2007-12-13T14:03:18Z","receivedAt":"2007-12-13T14:03:18Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Johannes Schindelin schrieb:\n> On Thu, 13 Dec 2007, Junio C Hamano wrote:\n> \n>> Johannes Schindelin writes:\n>>\n>>> For this to work, apply has to be called with --unidiff-zero, since\n>>> the new hunks can start or stop with a \"-\" or \"+\" line.\n>> You do not have to do \"unidiff zero\". Suppose you have this hunk you\n>> need to split.\n>>\n>> [describes to pick zero or more '-' lines and zero or more '+' lines]\n> \n> I thought about that, but the UI is not trivial. The UI for my solution \n> is.\n\nIt's probably sufficient to have an option \"Stage this Line\": Once you have\nstaged enough lines, the hunk will be split automatically by the current\nnumber-of-context-lines setting.\n\n-- Hannes\n"},{"id":"63020","messageId":"Pine.LNX.4.64.0712131417110.27959@racer.site","threadId":"11239","inReplyTo":"47613BA6.1060705@viscovery.net","subject":"Re: [PATCH] Teach git-gui to split hunks","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-12-13T14:18:43Z","receivedAt":"2007-12-13T14:18:43Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 13 Dec 2007, Johannes Sixt wrote:\n\n> Johannes Schindelin schrieb:\n> > On Thu, 13 Dec 2007, Junio C Hamano wrote:\n> > \n> >> Johannes Schindelin writes:\n> >>\n> >>> For this to work, apply has to be called with --unidiff-zero, since \n> >>> the new hunks can start or stop with a \"-\" or \"+\" line.\n> >> You do not have to do \"unidiff zero\". Suppose you have this hunk you \n> >> need to split.\n> >>\n> >> [describes to pick zero or more '-' lines and zero or more '+' lines]\n> > \n> > I thought about that, but the UI is not trivial. The UI for my \n> > solution is.\n> \n> It's probably sufficient to have an option \"Stage this Line\": Once you \n> have staged enough lines, the hunk will be split automatically by the \n> current number-of-context-lines setting.\n\nAnd your hand falls off... ;-)\n\nSeriously, I often have a big chunk of changes, for example with \nan indentation change, where I want to stage everything _but_ one line in \nthe middle. Just staging that, \"git checkout \" and fixing the \nindentation of that single line speeds up my procedure vastly.\n\nCiao,\nDscho\n"},{"id":"63022","messageId":"47614419.3050604@viscovery.net","threadId":"11239","inReplyTo":"Pine.LNX.4.64.0712131417110.27959@racer.site","subject":"[PATCH] git-gui: Move frequently used commands to the top of the context menu.","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2007-12-13T14:39:21Z","receivedAt":"2007-12-13T14:39:21Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"From: Johannes Sixt \n\n\"Stage/Unstage Hunk\" is probably the most frequently used command of the\npatch context menu *and* it is not available in some other form than\nthe context menu. Therefore, it should go to the top. \"Less Context\" and\n\"More Context\" entries are also not easily available otherwise, and are\ntherefore, moved second. The other entries are available via key strokes\n(Copy, Paste, Refresh) or rarly used (Font Size, Options) and can go last.\n\nSigned-off-by: Johannes Sixt \n---\n Johannes Schindelin schrieb:\n > On Thu, 13 Dec 2007, Johannes Sixt wrote:\n >> It's probably sufficient to have an option \"Stage this Line\": Once you\n >> have staged enough lines, the hunk will be split automatically by the\n >> current number-of-context-lines setting.\n >\n > And your hand falls off... ;-)\n\n Not with this patch.\n\n And, obviously, \"Stage this Line\" is accompanied by \"Unstage this Line\".\n So when you want to stage a lot *except* one line, then you better\n stage the lot, then *unstage* one line.\n\n -- Hannes\n\n PS: Warning, Shawn: [ab]/git-gui.sh below is forged; you won't have\n blob 95b9537.\n\n git-gui.sh | 42 +++++++++++++++++++++---------------------\n 1 files changed, 21 insertions(+), 21 deletions(-)\n\ndiff --git a/git-gui.sh b/git-gui.sh\nindex 95b9537..8e3751f 100755\n--- a/git-gui.sh\n+++ b/git-gui.sh\n@@ -2542,6 +2542,27 @@ $ui_diff tag raise sel\n set ctxm .vpane.lower.diff.body.ctxm\n menu $ctxm -tearoff 0\n $ctxm add command \\\n+\t-label [mc \"Apply/Reverse Hunk\"] \\\n+\t-command {apply_hunk $cursorX $cursorY}\n+set ui_diff_applyhunk [$ctxm index last]\n+lappend diff_actions [list $ctxm entryconf $ui_diff_applyhunk -state]\n+$ctxm add separator\n+$ctxm add command \\\n+\t-label [mc \"Show Less Context\"] \\\n+\t-command {if {$repo_config(gui.diffcontext) >= 1} {\n+\t\tincr repo_config(gui.diffcontext) -1\n+\t\treshow_diff\n+\t}}\n+lappend diff_actions [list $ctxm entryconf [$ctxm index last] -state]\n+$ctxm add command \\\n+\t-label [mc \"Show More Context\"] \\\n+\t-command {if {$repo_config(gui.diffcontext) < 99} {\n+\t\tincr repo_config(gui.diffcontext)\n+\t\treshow_diff\n+\t}}\n+lappend diff_actions [list $ctxm entryconf [$ctxm index last] -state]\n+$ctxm add separator\n+$ctxm add command \\\n \t-label [mc Refresh] \\\n \t-command reshow_diff\n lappend diff_actions [list $ctxm entryconf [$ctxm index last] -state]\n@@ -2563,12 +2584,6 @@ $ctxm add command \\\n lappend diff_actions [list $ctxm entryconf [$ctxm index last] -state]\n $ctxm add separator\n $ctxm add command \\\n-\t-label [mc \"Apply/Reverse Hunk\"] \\\n-\t-command {apply_hunk $cursorX $cursorY}\n-set ui_diff_applyhunk [$ctxm index last]\n-lappend diff_actions [list $ctxm entryconf $ui_diff_applyhunk -state]\n-$ctxm add separator\n-$ctxm add command \\\n \t-label [mc \"Decrease Font Size\"] \\\n \t-command {incr_font_size font_diff -1}\n lappend diff_actions [list $ctxm entryconf [$ctxm index last] -state]\n@@ -2577,21 +2592,6 @@ $ctxm add command \\\n \t-command {incr_font_size font_diff 1}\n lappend diff_actions [list $ctxm entryconf [$ctxm index last] -state]\n $ctxm add separator\n-$ctxm add command \\\n-\t-label [mc \"Show Less Context\"] \\\n-\t-command {if {$repo_config(gui.diffcontext) >= 1} {\n-\t\tincr repo_config(gui.diffcontext) -1\n-\t\treshow_diff\n-\t}}\n-lappend diff_actions [list $ctxm entryconf [$ctxm index last] -state]\n-$ctxm add command \\\n-\t-label [mc \"Show More Context\"] \\\n-\t-command {if {$repo_config(gui.diffcontext) < 99} {\n-\t\tincr repo_config(gui.diffcontext)\n-\t\treshow_diff\n-\t}}\n-lappend diff_actions [list $ctxm entryconf [$ctxm index last] -state]\n-$ctxm add separator\n $ctxm add command -label [mc \"Options...\"] \\\n \t-command do_options\n proc popup_diff_menu {ctxm x y X Y} {\n-- \n1.5.3.7.1929.gf9f0a\n"},{"id":"63106","messageId":"20071214063217.GG14735@spearce.org","threadId":"11239","inReplyTo":"47614419.3050604@viscovery.net","subject":"Re: [PATCH] git-gui: Move frequently used commands to the top of the context menu.","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-12-14T06:32:17Z","receivedAt":"2007-12-14T06:32:17Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Johannes Sixt wrote:\n> \"Stage/Unstage Hunk\" is probably the most frequently used command of the\n> patch context menu *and* it is not available in some other form than\n> the context menu. Therefore, it should go to the top. \"Less Context\" and\n> \"More Context\" entries are also not easily available otherwise, and are\n> therefore, moved second. The other entries are available via key strokes\n> (Copy, Paste, Refresh) or rarly used (Font Size, Options) and can go last.\n\nThanks. This will be in my repo.or.cz tree shortly.\n\n-- \nShawn.\n"}]}