{"thread":{"id":"51197","subject":"Request: git add --interactive: split hunk: When can't split further, split on empty lines","startedAt":"2019-05-30T00:19:59Z","lastAt":"2019-05-30T20:31:17Z","messageCount":5,"participants":["James Harvey","Johannes Schindelin","Philip Oakley"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"376432","messageId":"CA+X5Wn5bt-3zHUqtRDWtc0A82SFmWPuQ0+RvRLaAV6Vn24nf4g@mail.gmail.com","threadId":"51197","inReplyTo":null,"subject":"Request: git add --interactive: split hunk: When can't split further, split on empty lines","fromName":"James Harvey","fromEmail":"jamespharvey20@gmail.com","sentAt":"2019-05-30T00:19:45Z","receivedAt":"2019-05-30T00:19:59Z","isPatch":false,"sender":{"key":"jamespharvey20@gmail.com","avatar":null},"body":"When adding interactively, 's' can be used to split the current hunk.\nOnce it gets down to where 's' reports \"Sorry, cannot split this\nhunk\", it could be useful if it would then start splitting based on\nempty lines, probably leaving empty lines at the top of the split\nhunks.  It certainly wouldn't be perfect, and might create many hunks,\nbut it would be a nice alternative to manually editing the hunk.\nCertainly someone could still manually edit the hunk if they didn't\nwant to use it in a particular situation.\n\nExample:\n\n----------\nint a() {\n}\n\nint b() {\n}\n----------\n\nbecomes\n\n---------\nint a() {\n}\n---------\n\nint b() {\n}\n---------\n"},{"id":"376441","messageId":"nycvar.QRO.7.76.6.1905301644020.44@tvgsbejvaqbjf.bet","threadId":"51197","inReplyTo":"CA+X5Wn5bt-3zHUqtRDWtc0A82SFmWPuQ0+RvRLaAV6Vn24nf4g@mail.gmail.com","subject":"Re: Request: git add --interactive: split hunk: When can't split further, split on empty lines","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2019-05-30T14:53:02Z","receivedAt":"2019-05-30T14:53:32Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi James,\n\nOn Wed, 29 May 2019, James Harvey wrote:\n\n> When adding interactively, 's' can be used to split the current hunk.\n> Once it gets down to where 's' reports \"Sorry, cannot split this\n> hunk\", it could be useful if it would then start splitting based on\n> empty lines, probably leaving empty lines at the top of the split\n> hunks.  It certainly wouldn't be perfect, and might create many hunks,\n> but it would be a nice alternative to manually editing the hunk.\n> Certainly someone could still manually edit the hunk if they didn't\n> want to use it in a particular situation.\n\nWhile a neat idea from the users' perspective, I think that it is\ntechnically a bit challenging, as you then have a problem to coalesce the\npatches appropriately.\n\nThe thing with the splitting at context lines is that you have a much\neasier time to merge individual split-hunks into a \"coalesced\" hunk\nbecause the context lines stay context lines.\n\nHaving said that, there was a patch series recently to add the ability to\nstage individual lines, and I think that your feature request could be\nimplemented on top of that.\n\nIn the meantime, an Outreachy intern and I worked on turning `git add -i`\ninto a built-in (it was written in Perl, and the built-in is written in\nportable C instead), and I *think* that the plan with the patch series to\nstage individual lines was to re-implement it on top of the built-in patch\nseries.\n\nWould you be interested in participating in that project?\n\nCiao,\nJohannes\n"},{"id":"376454","messageId":"aad93135-6280-ac6a-c72a-8a325fbbaf67@iee.org","threadId":"51197","inReplyTo":"nycvar.QRO.7.76.6.1905301644020.44@tvgsbejvaqbjf.bet","subject":"Re: Request: git add --interactive: split hunk: When can't split further, split on empty lines","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2019-05-30T19:26:29Z","receivedAt":"2019-05-30T19:26:34Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"Hi,  some minor comments.\nOn 30/05/2019 15:53, Johannes Schindelin wrote:\n> Hi James,\n>\n> On Wed, 29 May 2019, James Harvey wrote:\n>\n>> When adding interactively, 's' can be used to split the current hunk.\n>> Once it gets down to where 's' reports \"Sorry, cannot split this\n>> hunk\", it could be useful if it would then start splitting based on\n>> empty lines, probably leaving empty lines at the top of the split\n>> hunks.  It certainly wouldn't be perfect, and might create many hunks,\nA binary search style split may be an option to avoid the 'many hunks' \nissue.\n>> but it would be a nice alternative to manually editing the hunk.\n>> Certainly someone could still manually edit the hunk if they didn't\n>> want to use it in a particular situation.\n> While a neat idea from the users' perspective, I think that it is\n> technically a bit challenging, as you then have a problem to coalesce the\n> patches appropriately.\n>\n> The thing with the splitting at context lines is that you have a much\n> easier time to merge individual split-hunks into a \"coalesced\" hunk\n> because the context lines stay context lines.\n>\n> Having said that, there was a patch series recently to add the ability to\n> stage individual lines,\nI believe that the git-gui (in tk/tcl, but using git commands) was \nalready able to stage individual/selected lines, so there may be some \nideas from there.\n\n> and I think that your feature request could be\n> implemented on top of that.\n>\n> In the meantime, an Outreachy intern and I worked on turning `git add -i`\n> into a built-in (it was written in Perl, and the built-in is written in\n> portable C instead), and I *think* that the plan with the patch series to\n> stage individual lines was to re-implement it on top of the built-in patch\n> series.\n>\n> Would you be interested in participating in that project?\n>\n> Ciao,\n> Johannes\n--\nPhilip\n"},{"id":"376456","messageId":"nycvar.QRO.7.76.6.1905302136400.44@tvgsbejvaqbjf.bet","threadId":"51197","inReplyTo":"aad93135-6280-ac6a-c72a-8a325fbbaf67@iee.org","subject":"Re: Request: git add --interactive: split hunk: When can't split further, split on empty lines","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2019-05-30T19:43:08Z","receivedAt":"2019-05-30T19:43:33Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Philip,\n\nOn Thu, 30 May 2019, Philip Oakley wrote:\n\n> On 30/05/2019 15:53, Johannes Schindelin wrote:\n> >\n> > Having said that, there was a patch series recently to add the ability to\n> > stage individual lines,\n>\n> I believe that the git-gui (in tk/tcl, but using git commands) was\n> already able to stage individual/selected lines, so there may be some\n> ideas from there.\n\nSadly, no.\n\nThere is one very big difference between Git GUI and `git add -p`: when\nyou stage a line in Git GUI, it is staged *immediately*.\n\nWhen you stage a single line in the Git GUI, the diff you see in the\nwindow is reloaded. That is quite slow in the long run, and no fun.\n\nIn contrast, `git add -p` does not stage *anything* until you're done\nselecting what you want to stage.\n\nTherefore, `git add -p` does have to do things quite a bit differently, as\nit will have to eventually build a single diff that is applied in one fell\nswoop, no matter how many lines you select individually.\n\nAnd naturally, there is also the difference between the user interfaces:\nwhile you can ask the user to select (part of) the line to stage in Git\nGUI via the mouse, that is not at all an option in `git add -p`.\n\nLikewise, the very convenient option to navigate via regular expressions\nin `git add -p` is not available in Git GUI at all.\n\nIn short: I think that it makes more sense to come up with a design\nspecific to `git add -p` and not get distracted by Tcl code that works\nquite differently.\n\nCiao,\nDscho\n"},{"id":"376457","messageId":"fb5fd48d-c5fe-57dc-c307-c959ad132da6@iee.org","threadId":"51197","inReplyTo":"nycvar.QRO.7.76.6.1905302136400.44@tvgsbejvaqbjf.bet","subject":"Re: Request: git add --interactive: split hunk: When can't split further, split on empty lines","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2019-05-30T20:30:51Z","receivedAt":"2019-05-30T20:31:17Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"Thanks for the clarification. Funny that we are \"staging\" the patch \npreparation to avoid real staging;-)\n\nOn 30/05/2019 20:43, Johannes Schindelin wrote:\n> Hi Philip,\n>\n> On Thu, 30 May 2019, Philip Oakley wrote:\n>\n>> On 30/05/2019 15:53, Johannes Schindelin wrote:\n>>> Having said that, there was a patch series recently to add the ability to\n>>> stage individual lines,\n>> I believe that the git-gui (in tk/tcl, but using git commands) was\n>> already able to stage individual/selected lines, so there may be some\n>> ideas from there.\n> Sadly, no.\n>\n> There is one very big difference between Git GUI and `git add -p`: when\n> you stage a line in Git GUI, it is staged *immediately*.\n>\n> When you stage a single line in the Git GUI, the diff you see in the\n> window is reloaded. That is quite slow in the long run, and no fun.\n>\n> In contrast, `git add -p` does not stage *anything* until you're done\n> selecting what you want to stage.\n>\n> Therefore, `git add -p` does have to do things quite a bit differently, as\n> it will have to eventually build a single diff that is applied in one fell\n> swoop, no matter how many lines you select individually.\n>\n> And naturally, there is also the difference between the user interfaces:\n> while you can ask the user to select (part of) the line to stage in Git\n> GUI via the mouse, that is not at all an option in `git add -p`.\n>\n> Likewise, the very convenient option to navigate via regular expressions\n> in `git add -p` is not available in Git GUI at all.\n>\n> In short: I think that it makes more sense to come up with a design\n> specific to `git add -p` and not get distracted by Tcl code that works\n> quite differently.\n>\n> Ciao,\n> Dscho\n\n"}]}