{"thread":{"id":"54027","subject":"[PATCH] git-gui: accommodate for intent-to-add files","startedAt":"2020-08-12T15:06:23Z","lastAt":"2020-10-09T15:40:23Z","messageCount":7,"participants":["Johannes Schindelin via GitGitGadget","Pratyush Yadav","Johannes Schindelin"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"403460","messageId":"pull.699.git.1597244777943.gitgitgadget@gmail.com","threadId":"54027","inReplyTo":null,"subject":"[PATCH] git-gui: accommodate for intent-to-add files","fromName":"Johannes Schindelin via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2020-08-12T15:06:17Z","receivedAt":"2020-08-12T15:06:23Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"From: Johannes Schindelin <johannes.schindelin@gmx.de>\n\nAs of Git v2.28.0, the diff for files staged via `git add -N` marks them\nas new files. Git GUI was ill-prepared for that, and this patch teaches\nGit GUI about them.\n\nPlease note that this will not even fix things with v2.28.0, as the\n`rp/apply-cached-with-i-t-a` patches are required on Git's side, too.\n\nThis fixes https://github.com/git-for-windows/git/issues/2779\n\nSigned-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n---\n    git-gui: accommodate for intent-to-add files\n    \n    This fixes the intent-to-add bug reported in \n    https://github.com/git-for-windows/git/issues/2779: after a file was\n    staged with git add -N, staging hunks/lines would fail silently.\n    \n    On its own, this patch is not enough, as it requires the patches\n    provided in rp/apply-cached-with-i-t-a to be applied on Git's side.\n    \n    Please note that this patch might need a bit more help, as I do not\n    really know whether showing \"new file mode 100644\" in the diff view is\n    desirable, or whether we should somehow try to retain the\n    \"intent-to-add\" state so that unstaging all hunks would return the file\n    to \"intent-to-add\" state.\n    \n    Thoughts?\n\nPublished-As: https://github.com/gitgitgadget/git/releases/tag/pr-699%2Fdscho%2Fgit-gui-stage-ita-hunks-and-lines-v1\nFetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-699/dscho/git-gui-stage-ita-hunks-and-lines-v1\nPull-Request: https://github.com/gitgitgadget/git/pull/699\n\n git-gui.sh   |  2 ++\n lib/diff.tcl | 12 ++++++++----\n 2 files changed, 10 insertions(+), 4 deletions(-)\n\ndiff --git a/git-gui.sh b/git-gui.sh\nindex 49bd86e635..e08cb17395 100755\n--- a/git-gui.sh\n+++ b/git-gui.sh\n@@ -2080,6 +2080,7 @@ set all_icons(U$ui_index)   file_merge\n set all_icons(T$ui_index)   file_statechange\n \n set all_icons(_$ui_workdir) file_plain\n+set all_icons(A$ui_workdir) file_plain\n set all_icons(M$ui_workdir) file_mod\n set all_icons(D$ui_workdir) file_question\n set all_icons(U$ui_workdir) file_merge\n@@ -2106,6 +2107,7 @@ foreach i {\n \t\t{A_ {mc \"Staged for commit\"}}\n \t\t{AM {mc \"Portions staged for commit\"}}\n \t\t{AD {mc \"Staged for commit, missing\"}}\n+\t\t{AA {mc \"Intended to be added\"}}\n \n \t\t{_D {mc \"Missing\"}}\n \t\t{D_ {mc \"Staged for removal\"}}\ndiff --git a/lib/diff.tcl b/lib/diff.tcl\nindex 871ad488c2..36d3715f7b 100644\n--- a/lib/diff.tcl\n+++ b/lib/diff.tcl\n@@ -582,7 +582,8 @@ proc apply_or_revert_hunk {x y revert} {\n \tif {$current_diff_side eq $ui_index} {\n \t\tset failed_msg [mc \"Failed to unstage selected hunk.\"]\n \t\tlappend apply_cmd --reverse --cached\n-\t\tif {[string index $mi 0] ne {M}} {\n+\t\tset file_state [string index $mi 0]\n+\t\tif {$file_state ne {M} && $file_state ne {A}} {\n \t\t\tunlock_index\n \t\t\treturn\n \t\t}\n@@ -595,7 +596,8 @@ proc apply_or_revert_hunk {x y revert} {\n \t\t\tlappend apply_cmd --cached\n \t\t}\n \n-\t\tif {[string index $mi 1] ne {M}} {\n+\t\tset file_state [string index $mi 1]\n+\t\tif {$file_state ne {M} && $file_state ne {A}} {\n \t\t\tunlock_index\n \t\t\treturn\n \t\t}\n@@ -687,7 +689,8 @@ proc apply_or_revert_range_or_line {x y revert} {\n \t\tset failed_msg [mc \"Failed to unstage selected line.\"]\n \t\tset to_context {+}\n \t\tlappend apply_cmd --reverse --cached\n-\t\tif {[string index $mi 0] ne {M}} {\n+\t\tset file_state [string index $mi 0]\n+\t\tif {$file_state ne {M} && $file_state ne {A}} {\n \t\t\tunlock_index\n \t\t\treturn\n \t\t}\n@@ -702,7 +705,8 @@ proc apply_or_revert_range_or_line {x y revert} {\n \t\t\tlappend apply_cmd --cached\n \t\t}\n \n-\t\tif {[string index $mi 1] ne {M}} {\n+\t\tset file_state [string index $mi 1]\n+\t\tif {$file_state ne {M} && $file_state ne {A}} {\n \t\t\tunlock_index\n \t\t\treturn\n \t\t}\n\nbase-commit: 469725c1a3d44f7e1475f1d37cd13e0824d4ea41\n-- \ngitgitgadget\n"},{"id":"404509","messageId":"20200826113030.xnutfxxfmdhgoq5o@yadavpratyush.com","threadId":"54027","inReplyTo":"pull.699.git.1597244777943.gitgitgadget@gmail.com","subject":"Re: [PATCH] git-gui: accommodate for intent-to-add files","fromName":"Pratyush Yadav","fromEmail":"me@yadavpratyush.com","sentAt":"2020-08-26T11:30:30Z","receivedAt":"2020-08-26T11:30:48Z","isPatch":true,"sender":{"key":"me@yadavpratyush.com","avatar":"https://avatars.githubusercontent.com/u/8817931?v=4"},"body":"Hi Johannes,\n\nThanks for the patch.\n\nOn 12/08/20 03:06PM, Johannes Schindelin via GitGitGadget wrote:\n> From: Johannes Schindelin <johannes.schindelin@gmx.de>\n> \n> As of Git v2.28.0, the diff for files staged via `git add -N` marks them\n> as new files. Git GUI was ill-prepared for that, and this patch teaches\n> Git GUI about them.\n> \n> Please note that this will not even fix things with v2.28.0, as the\n> `rp/apply-cached-with-i-t-a` patches are required on Git's side, too.\n> \n> This fixes https://github.com/git-for-windows/git/issues/2779\n> \n> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n> ---\n>     git-gui: accommodate for intent-to-add files\n>     \n>     This fixes the intent-to-add bug reported in \n>     https://github.com/git-for-windows/git/issues/2779: after a file was\n>     staged with git add -N, staging hunks/lines would fail silently.\n>     \n>     On its own, this patch is not enough, as it requires the patches\n>     provided in rp/apply-cached-with-i-t-a to be applied on Git's side.\n>     \n>     Please note that this patch might need a bit more help, as I do not\n>     really know whether showing \"new file mode 100644\" in the diff view is\n>     desirable, or whether we should somehow try to retain the\n>     \"intent-to-add\" state so that unstaging all hunks would return the file\n>     to \"intent-to-add\" state.\n\nI built latest Git master (e9b77c84a0) which has \n`rp/apply-cached-with-i-t-a` and tested this patch. It works... for the \nmost part.\n\nI can select a line set of lines and they get staged/unstaged, which is \ngood. The part that is not good though is that a lot of common \noperations still don't work as they should:\n\n- I can't click on the icon in the \"Unstaged Changes\" pane to stage the \n  whole file. Nothing happens when I do that.\n\n- The file that is marked as intent-to-add shows up in both the \"Staged \n  Changes\" and \"Unstaged Changes\" panes, with the \"Staged Changes\" part \n  being empty. Ideally it should only show up in the \"Unstaged Changes\" \n  pane.\n\n- Selecting the whole file and choosing \"Stage Lines for Commit\" works \n  well. But choosing \"Stage Hunk for Commit\" does not. While the changes \n  do get staged, the UI is not properly updated and the file is still \n  listed in the \"Unstaged Changes\" pane.\n\n  I think the difference here is because for \n  `apply_or_revert_range_or_line`, we call `do_rescan` after it to \n  update the UI, but for `apply_or_revert_hunk` we update the UI \n  \"manually\" in the function after we are done applying or reverting the \n  changes. So the logic to update the UI needs to be updated to account \n  for this change. Or we can get rid of all that logic and just run a \n  rescan.\n\nAnd also, like you mentioned, we don't retain the i-t-a state when \nunstaging. But with some quick testing, I see that Git command line \ndoesn't either (I tried a plain `git restore --staged`). So IMO we \nshould mimic what the command line UI does and not retain the i-t-a \nstate when unstaging.\n\n>     \n>     Thoughts?\n\nIMO this is a good start but more work needs to be done before we can \ncall this feature finished.\n \n> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-699%2Fdscho%2Fgit-gui-stage-ita-hunks-and-lines-v1\n> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-699/dscho/git-gui-stage-ita-hunks-and-lines-v1\n> Pull-Request: https://github.com/gitgitgadget/git/pull/699\n> \n>  git-gui.sh   |  2 ++\n>  lib/diff.tcl | 12 ++++++++----\n>  2 files changed, 10 insertions(+), 4 deletions(-)\n> \n> diff --git a/git-gui.sh b/git-gui.sh\n> index 49bd86e635..e08cb17395 100755\n> --- a/git-gui.sh\n> +++ b/git-gui.sh\n> @@ -2080,6 +2080,7 @@ set all_icons(U$ui_index)   file_merge\n>  set all_icons(T$ui_index)   file_statechange\n>  \n>  set all_icons(_$ui_workdir) file_plain\n> +set all_icons(A$ui_workdir) file_plain\n>  set all_icons(M$ui_workdir) file_mod\n>  set all_icons(D$ui_workdir) file_question\n>  set all_icons(U$ui_workdir) file_merge\n> @@ -2106,6 +2107,7 @@ foreach i {\n>  \t\t{A_ {mc \"Staged for commit\"}}\n>  \t\t{AM {mc \"Portions staged for commit\"}}\n>  \t\t{AD {mc \"Staged for commit, missing\"}}\n> +\t\t{AA {mc \"Intended to be added\"}}\n>  \n>  \t\t{_D {mc \"Missing\"}}\n>  \t\t{D_ {mc \"Staged for removal\"}}\n> diff --git a/lib/diff.tcl b/lib/diff.tcl\n> index 871ad488c2..36d3715f7b 100644\n> --- a/lib/diff.tcl\n> +++ b/lib/diff.tcl\n> @@ -582,7 +582,8 @@ proc apply_or_revert_hunk {x y revert} {\n>  \tif {$current_diff_side eq $ui_index} {\n>  \t\tset failed_msg [mc \"Failed to unstage selected hunk.\"]\n>  \t\tlappend apply_cmd --reverse --cached\n> -\t\tif {[string index $mi 0] ne {M}} {\n> +\t\tset file_state [string index $mi 0]\n> +\t\tif {$file_state ne {M} && $file_state ne {A}} {\n>  \t\t\tunlock_index\n>  \t\t\treturn\n>  \t\t}\n> @@ -595,7 +596,8 @@ proc apply_or_revert_hunk {x y revert} {\n>  \t\t\tlappend apply_cmd --cached\n>  \t\t}\n>  \n> -\t\tif {[string index $mi 1] ne {M}} {\n> +\t\tset file_state [string index $mi 1]\n> +\t\tif {$file_state ne {M} && $file_state ne {A}} {\n>  \t\t\tunlock_index\n>  \t\t\treturn\n>  \t\t}\n> @@ -687,7 +689,8 @@ proc apply_or_revert_range_or_line {x y revert} {\n>  \t\tset failed_msg [mc \"Failed to unstage selected line.\"]\n>  \t\tset to_context {+}\n>  \t\tlappend apply_cmd --reverse --cached\n> -\t\tif {[string index $mi 0] ne {M}} {\n> +\t\tset file_state [string index $mi 0]\n> +\t\tif {$file_state ne {M} && $file_state ne {A}} {\n>  \t\t\tunlock_index\n>  \t\t\treturn\n>  \t\t}\n> @@ -702,7 +705,8 @@ proc apply_or_revert_range_or_line {x y revert} {\n>  \t\t\tlappend apply_cmd --cached\n>  \t\t}\n>  \n> -\t\tif {[string index $mi 1] ne {M}} {\n> +\t\tset file_state [string index $mi 1]\n> +\t\tif {$file_state ne {M} && $file_state ne {A}} {\n>  \t\t\tunlock_index\n>  \t\t\treturn\n>  \t\t}\n> \n\nThese changes look good to me to set up basic functionality. We just \nneed to iron out the rough edges.\n\n> base-commit: 469725c1a3d44f7e1475f1d37cd13e0824d4ea41\n> -- \n> gitgitgadget\n\n-- \nRegards,\nPratyush Yadav\n"},{"id":"404518","messageId":"nycvar.QRO.7.76.6.2008260936010.56@tvgsbejvaqbjf.bet","threadId":"54027","inReplyTo":"20200826113030.xnutfxxfmdhgoq5o@yadavpratyush.com","subject":"Re: [PATCH] git-gui: accommodate for intent-to-add files","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2020-08-26T07:36:55Z","receivedAt":"2020-08-26T14:36:53Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Pratyush,\n\nOn Wed, 26 Aug 2020, Pratyush Yadav wrote:\n\n> On 12/08/20 03:06PM, Johannes Schindelin via GitGitGadget wrote:\n> > From: Johannes Schindelin <johannes.schindelin@gmx.de>\n> >\n> > As of Git v2.28.0, the diff for files staged via `git add -N` marks them\n> > as new files. Git GUI was ill-prepared for that, and this patch teaches\n> > Git GUI about them.\n> >\n> > Please note that this will not even fix things with v2.28.0, as the\n> > `rp/apply-cached-with-i-t-a` patches are required on Git's side, too.\n> >\n> > This fixes https://github.com/git-for-windows/git/issues/2779\n> >\n> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n> > ---\n> >     git-gui: accommodate for intent-to-add files\n> >\n> >     This fixes the intent-to-add bug reported in\n> >     https://github.com/git-for-windows/git/issues/2779: after a file was\n> >     staged with git add -N, staging hunks/lines would fail silently.\n> >\n> >     On its own, this patch is not enough, as it requires the patches\n> >     provided in rp/apply-cached-with-i-t-a to be applied on Git's side.\n> >\n> >     Please note that this patch might need a bit more help, as I do not\n> >     really know whether showing \"new file mode 100644\" in the diff view is\n> >     desirable, or whether we should somehow try to retain the\n> >     \"intent-to-add\" state so that unstaging all hunks would return the file\n> >     to \"intent-to-add\" state.\n>\n> I built latest Git master (e9b77c84a0) which has\n> `rp/apply-cached-with-i-t-a` and tested this patch. It works... for the\n> most part.\n>\n> I can select a line set of lines and they get staged/unstaged, which is\n> good. The part that is not good though is that a lot of common\n> operations still don't work as they should:\n>\n> - I can't click on the icon in the \"Unstaged Changes\" pane to stage the\n>   whole file. Nothing happens when I do that.\n>\n> - The file that is marked as intent-to-add shows up in both the \"Staged\n>   Changes\" and \"Unstaged Changes\" panes, with the \"Staged Changes\" part\n>   being empty. Ideally it should only show up in the \"Unstaged Changes\"\n>   pane.\n>\n> - Selecting the whole file and choosing \"Stage Lines for Commit\" works\n>   well. But choosing \"Stage Hunk for Commit\" does not. While the changes\n>   do get staged, the UI is not properly updated and the file is still\n>   listed in the \"Unstaged Changes\" pane.\n>\n>   I think the difference here is because for\n>   `apply_or_revert_range_or_line`, we call `do_rescan` after it to\n>   update the UI, but for `apply_or_revert_hunk` we update the UI\n>   \"manually\" in the function after we are done applying or reverting the\n>   changes. So the logic to update the UI needs to be updated to account\n>   for this change. Or we can get rid of all that logic and just run a\n>   rescan.\n>\n> And also, like you mentioned, we don't retain the i-t-a state when\n> unstaging. But with some quick testing, I see that Git command line\n> doesn't either (I tried a plain `git restore --staged`). So IMO we\n> should mimic what the command line UI does and not retain the i-t-a\n> state when unstaging.\n\nTo be quite honest, I had hoped that this might be a good patch to start\nfrom... for somebody else (you?)\n\n:-)\n\nCiao,\nDscho\n"},{"id":"404521","messageId":"20200826145217.gx2prxltyoyuoxo3@yadavpratyush.com","threadId":"54027","inReplyTo":"nycvar.QRO.7.76.6.2008260936010.56@tvgsbejvaqbjf.bet","subject":"Re: [PATCH] git-gui: accommodate for intent-to-add files","fromName":"Pratyush Yadav","fromEmail":"me@yadavpratyush.com","sentAt":"2020-08-26T14:52:17Z","receivedAt":"2020-08-26T14:58:06Z","isPatch":true,"sender":{"key":"me@yadavpratyush.com","avatar":"https://avatars.githubusercontent.com/u/8817931?v=4"},"body":"On 26/08/20 09:36AM, Johannes Schindelin wrote:\n> Hi Pratyush,\n> \n> On Wed, 26 Aug 2020, Pratyush Yadav wrote:\n> \n> > On 12/08/20 03:06PM, Johannes Schindelin via GitGitGadget wrote:\n> > > From: Johannes Schindelin <johannes.schindelin@gmx.de>\n> > >\n> > > As of Git v2.28.0, the diff for files staged via `git add -N` marks them\n> > > as new files. Git GUI was ill-prepared for that, and this patch teaches\n> > > Git GUI about them.\n> > >\n> > > Please note that this will not even fix things with v2.28.0, as the\n> > > `rp/apply-cached-with-i-t-a` patches are required on Git's side, too.\n> > >\n> > > This fixes https://github.com/git-for-windows/git/issues/2779\n> > >\n> > > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n> > > ---\n> > >     git-gui: accommodate for intent-to-add files\n> > >\n> > >     This fixes the intent-to-add bug reported in\n> > >     https://github.com/git-for-windows/git/issues/2779: after a file was\n> > >     staged with git add -N, staging hunks/lines would fail silently.\n> > >\n> > >     On its own, this patch is not enough, as it requires the patches\n> > >     provided in rp/apply-cached-with-i-t-a to be applied on Git's side.\n> > >\n> > >     Please note that this patch might need a bit more help, as I do not\n> > >     really know whether showing \"new file mode 100644\" in the diff view is\n> > >     desirable, or whether we should somehow try to retain the\n> > >     \"intent-to-add\" state so that unstaging all hunks would return the file\n> > >     to \"intent-to-add\" state.\n> >\n> > I built latest Git master (e9b77c84a0) which has\n> > `rp/apply-cached-with-i-t-a` and tested this patch. It works... for the\n> > most part.\n> >\n> > I can select a line set of lines and they get staged/unstaged, which is\n> > good. The part that is not good though is that a lot of common\n> > operations still don't work as they should:\n> >\n> > - I can't click on the icon in the \"Unstaged Changes\" pane to stage the\n> >   whole file. Nothing happens when I do that.\n> >\n> > - The file that is marked as intent-to-add shows up in both the \"Staged\n> >   Changes\" and \"Unstaged Changes\" panes, with the \"Staged Changes\" part\n> >   being empty. Ideally it should only show up in the \"Unstaged Changes\"\n> >   pane.\n> >\n> > - Selecting the whole file and choosing \"Stage Lines for Commit\" works\n> >   well. But choosing \"Stage Hunk for Commit\" does not. While the changes\n> >   do get staged, the UI is not properly updated and the file is still\n> >   listed in the \"Unstaged Changes\" pane.\n> >\n> >   I think the difference here is because for\n> >   `apply_or_revert_range_or_line`, we call `do_rescan` after it to\n> >   update the UI, but for `apply_or_revert_hunk` we update the UI\n> >   \"manually\" in the function after we are done applying or reverting the\n> >   changes. So the logic to update the UI needs to be updated to account\n> >   for this change. Or we can get rid of all that logic and just run a\n> >   rescan.\n> >\n> > And also, like you mentioned, we don't retain the i-t-a state when\n> > unstaging. But with some quick testing, I see that Git command line\n> > doesn't either (I tried a plain `git restore --staged`). So IMO we\n> > should mimic what the command line UI does and not retain the i-t-a\n> > state when unstaging.\n> \n> To be quite honest, I had hoped that this might be a good patch to start\n> from... for somebody else (you?)\n\nI'll take a stab at this during the weekend :-)\n\n-- \nRegards,\nPratyush Yadav\n"},{"id":"407202","messageId":"nycvar.QRO.7.76.6.2010090855260.50@tvgsbejvaqbjf.bet","threadId":"54027","inReplyTo":"20200826145217.gx2prxltyoyuoxo3@yadavpratyush.com","subject":"Re: [PATCH] git-gui: accommodate for intent-to-add files","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2020-10-09T06:56:39Z","receivedAt":"2020-10-09T09:14:27Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Pratyush,\n\nOn Wed, 26 Aug 2020, Pratyush Yadav wrote:\n\n> On 26/08/20 09:36AM, Johannes Schindelin wrote:\n>\n> > On Wed, 26 Aug 2020, Pratyush Yadav wrote:\n> >\n> > > On 12/08/20 03:06PM, Johannes Schindelin via GitGitGadget wrote:\n> > > > From: Johannes Schindelin <johannes.schindelin@gmx.de>\n> > > >\n> > > > As of Git v2.28.0, the diff for files staged via `git add -N` marks them\n> > > > as new files. Git GUI was ill-prepared for that, and this patch teaches\n> > > > Git GUI about them.\n> > > >\n> > > > Please note that this will not even fix things with v2.28.0, as the\n> > > > `rp/apply-cached-with-i-t-a` patches are required on Git's side, too.\n> > > >\n> > > > This fixes https://github.com/git-for-windows/git/issues/2779\n> > > >\n> > > > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n> > > > ---\n> > > >     git-gui: accommodate for intent-to-add files\n> > > >\n> > > >     This fixes the intent-to-add bug reported in\n> > > >     https://github.com/git-for-windows/git/issues/2779: after a file was\n> > > >     staged with git add -N, staging hunks/lines would fail silently.\n> > > >\n> > > >     On its own, this patch is not enough, as it requires the patches\n> > > >     provided in rp/apply-cached-with-i-t-a to be applied on Git's side.\n> > > >\n> > > >     Please note that this patch might need a bit more help, as I do not\n> > > >     really know whether showing \"new file mode 100644\" in the diff view is\n> > > >     desirable, or whether we should somehow try to retain the\n> > > >     \"intent-to-add\" state so that unstaging all hunks would return the file\n> > > >     to \"intent-to-add\" state.\n> > >\n> > > I built latest Git master (e9b77c84a0) which has\n> > > `rp/apply-cached-with-i-t-a` and tested this patch. It works... for the\n> > > most part.\n> > >\n> > > I can select a line set of lines and they get staged/unstaged, which is\n> > > good. The part that is not good though is that a lot of common\n> > > operations still don't work as they should:\n> > >\n> > > - I can't click on the icon in the \"Unstaged Changes\" pane to stage the\n> > >   whole file. Nothing happens when I do that.\n> > >\n> > > - The file that is marked as intent-to-add shows up in both the \"Staged\n> > >   Changes\" and \"Unstaged Changes\" panes, with the \"Staged Changes\" part\n> > >   being empty. Ideally it should only show up in the \"Unstaged Changes\"\n> > >   pane.\n> > >\n> > > - Selecting the whole file and choosing \"Stage Lines for Commit\" works\n> > >   well. But choosing \"Stage Hunk for Commit\" does not. While the changes\n> > >   do get staged, the UI is not properly updated and the file is still\n> > >   listed in the \"Unstaged Changes\" pane.\n> > >\n> > >   I think the difference here is because for\n> > >   `apply_or_revert_range_or_line`, we call `do_rescan` after it to\n> > >   update the UI, but for `apply_or_revert_hunk` we update the UI\n> > >   \"manually\" in the function after we are done applying or reverting the\n> > >   changes. So the logic to update the UI needs to be updated to account\n> > >   for this change. Or we can get rid of all that logic and just run a\n> > >   rescan.\n> > >\n> > > And also, like you mentioned, we don't retain the i-t-a state when\n> > > unstaging. But with some quick testing, I see that Git command line\n> > > doesn't either (I tried a plain `git restore --staged`). So IMO we\n> > > should mimic what the command line UI does and not retain the i-t-a\n> > > state when unstaging.\n> >\n> > To be quite honest, I had hoped that this might be a good patch to start\n> > from... for somebody else (you?)\n>\n> I'll take a stab at this during the weekend :-)\n\nJust a gentle ping: did you get a chance to get this patch into a better\nshape?\n\nThanks,\nDscho\n"},{"id":"407203","messageId":"20201009093455.yxh5xnyvcjqvn54a@yadavpratyush.com","threadId":"54027","inReplyTo":"nycvar.QRO.7.76.6.2010090855260.50@tvgsbejvaqbjf.bet","subject":"Re: [PATCH] git-gui: accommodate for intent-to-add files","fromName":"Pratyush Yadav","fromEmail":"me@yadavpratyush.com","sentAt":"2020-10-09T09:34:55Z","receivedAt":"2020-10-09T09:35:03Z","isPatch":true,"sender":{"key":"me@yadavpratyush.com","avatar":"https://avatars.githubusercontent.com/u/8817931?v=4"},"body":"On 09/10/20 08:56AM, Johannes Schindelin wrote:\n> Hi Pratyush,\n> \n> On Wed, 26 Aug 2020, Pratyush Yadav wrote:\n> \n> > On 26/08/20 09:36AM, Johannes Schindelin wrote:\n> >\n> > > On Wed, 26 Aug 2020, Pratyush Yadav wrote:\n> > >\n> > > > On 12/08/20 03:06PM, Johannes Schindelin via GitGitGadget wrote:\n> > > > > From: Johannes Schindelin <johannes.schindelin@gmx.de>\n> > > > >\n> > > > > As of Git v2.28.0, the diff for files staged via `git add -N` marks them\n> > > > > as new files. Git GUI was ill-prepared for that, and this patch teaches\n> > > > > Git GUI about them.\n> > > > >\n> > > > > Please note that this will not even fix things with v2.28.0, as the\n> > > > > `rp/apply-cached-with-i-t-a` patches are required on Git's side, too.\n> > > > >\n> > > > > This fixes https://github.com/git-for-windows/git/issues/2779\n> > > > >\n> > > > > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n> > > > > ---\n> > > > >     git-gui: accommodate for intent-to-add files\n> > > > >\n> > > > >     This fixes the intent-to-add bug reported in\n> > > > >     https://github.com/git-for-windows/git/issues/2779: after a file was\n> > > > >     staged with git add -N, staging hunks/lines would fail silently.\n> > > > >\n> > > > >     On its own, this patch is not enough, as it requires the patches\n> > > > >     provided in rp/apply-cached-with-i-t-a to be applied on Git's side.\n> > > > >\n> > > > >     Please note that this patch might need a bit more help, as I do not\n> > > > >     really know whether showing \"new file mode 100644\" in the diff view is\n> > > > >     desirable, or whether we should somehow try to retain the\n> > > > >     \"intent-to-add\" state so that unstaging all hunks would return the file\n> > > > >     to \"intent-to-add\" state.\n> > > >\n> > > > I built latest Git master (e9b77c84a0) which has\n> > > > `rp/apply-cached-with-i-t-a` and tested this patch. It works... for the\n> > > > most part.\n> > > >\n> > > > I can select a line set of lines and they get staged/unstaged, which is\n> > > > good. The part that is not good though is that a lot of common\n> > > > operations still don't work as they should:\n> > > >\n> > > > - I can't click on the icon in the \"Unstaged Changes\" pane to stage the\n> > > >   whole file. Nothing happens when I do that.\n> > > >\n> > > > - The file that is marked as intent-to-add shows up in both the \"Staged\n> > > >   Changes\" and \"Unstaged Changes\" panes, with the \"Staged Changes\" part\n> > > >   being empty. Ideally it should only show up in the \"Unstaged Changes\"\n> > > >   pane.\n> > > >\n> > > > - Selecting the whole file and choosing \"Stage Lines for Commit\" works\n> > > >   well. But choosing \"Stage Hunk for Commit\" does not. While the changes\n> > > >   do get staged, the UI is not properly updated and the file is still\n> > > >   listed in the \"Unstaged Changes\" pane.\n> > > >\n> > > >   I think the difference here is because for\n> > > >   `apply_or_revert_range_or_line`, we call `do_rescan` after it to\n> > > >   update the UI, but for `apply_or_revert_hunk` we update the UI\n> > > >   \"manually\" in the function after we are done applying or reverting the\n> > > >   changes. So the logic to update the UI needs to be updated to account\n> > > >   for this change. Or we can get rid of all that logic and just run a\n> > > >   rescan.\n> > > >\n> > > > And also, like you mentioned, we don't retain the i-t-a state when\n> > > > unstaging. But with some quick testing, I see that Git command line\n> > > > doesn't either (I tried a plain `git restore --staged`). So IMO we\n> > > > should mimic what the command line UI does and not retain the i-t-a\n> > > > state when unstaging.\n> > >\n> > > To be quite honest, I had hoped that this might be a good patch to start\n> > > from... for somebody else (you?)\n> >\n> > I'll take a stab at this during the weekend :-)\n> \n> Just a gentle ping: did you get a chance to get this patch into a better\n> shape?\n\nNo, I have not. I'll try my hand on it tomorrow and try to get it done \nin time for 2.29.\n\n-- \nRegards,\nPratyush Yadav\n"},{"id":"407213","messageId":"nycvar.QRO.7.76.6.2010091522150.50@tvgsbejvaqbjf.bet","threadId":"54027","inReplyTo":"20201009093455.yxh5xnyvcjqvn54a@yadavpratyush.com","subject":"Re: [PATCH] git-gui: accommodate for intent-to-add files","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2020-10-09T13:22:34Z","receivedAt":"2020-10-09T15:40:23Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Pratyush,\n\nOn Fri, 9 Oct 2020, Pratyush Yadav wrote:\n\n> On 09/10/20 08:56AM, Johannes Schindelin wrote:\n> >\n> > On Wed, 26 Aug 2020, Pratyush Yadav wrote:\n> >\n> > > On 26/08/20 09:36AM, Johannes Schindelin wrote:\n> > >\n> > > > On Wed, 26 Aug 2020, Pratyush Yadav wrote:\n> > > >\n> > > > > On 12/08/20 03:06PM, Johannes Schindelin via GitGitGadget wrote:\n> > > > > > From: Johannes Schindelin <johannes.schindelin@gmx.de>\n> > > > > >\n> > > > > > As of Git v2.28.0, the diff for files staged via `git add -N` marks them\n> > > > > > as new files. Git GUI was ill-prepared for that, and this patch teaches\n> > > > > > Git GUI about them.\n> > > > > >\n> > > > > > Please note that this will not even fix things with v2.28.0, as the\n> > > > > > `rp/apply-cached-with-i-t-a` patches are required on Git's side, too.\n> > > > > >\n> > > > > > This fixes https://github.com/git-for-windows/git/issues/2779\n> > > > > >\n> > > > > > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>\n> > > > > > ---\n> > > > > >     git-gui: accommodate for intent-to-add files\n> > > > > >\n> > > > > >     This fixes the intent-to-add bug reported in\n> > > > > >     https://github.com/git-for-windows/git/issues/2779: after a file was\n> > > > > >     staged with git add -N, staging hunks/lines would fail silently.\n> > > > > >\n> > > > > >     On its own, this patch is not enough, as it requires the patches\n> > > > > >     provided in rp/apply-cached-with-i-t-a to be applied on Git's side.\n> > > > > >\n> > > > > >     Please note that this patch might need a bit more help, as I do not\n> > > > > >     really know whether showing \"new file mode 100644\" in the diff view is\n> > > > > >     desirable, or whether we should somehow try to retain the\n> > > > > >     \"intent-to-add\" state so that unstaging all hunks would return the file\n> > > > > >     to \"intent-to-add\" state.\n> > > > >\n> > > > > I built latest Git master (e9b77c84a0) which has\n> > > > > `rp/apply-cached-with-i-t-a` and tested this patch. It works... for the\n> > > > > most part.\n> > > > >\n> > > > > I can select a line set of lines and they get staged/unstaged, which is\n> > > > > good. The part that is not good though is that a lot of common\n> > > > > operations still don't work as they should:\n> > > > >\n> > > > > - I can't click on the icon in the \"Unstaged Changes\" pane to stage the\n> > > > >   whole file. Nothing happens when I do that.\n> > > > >\n> > > > > - The file that is marked as intent-to-add shows up in both the \"Staged\n> > > > >   Changes\" and \"Unstaged Changes\" panes, with the \"Staged Changes\" part\n> > > > >   being empty. Ideally it should only show up in the \"Unstaged Changes\"\n> > > > >   pane.\n> > > > >\n> > > > > - Selecting the whole file and choosing \"Stage Lines for Commit\" works\n> > > > >   well. But choosing \"Stage Hunk for Commit\" does not. While the changes\n> > > > >   do get staged, the UI is not properly updated and the file is still\n> > > > >   listed in the \"Unstaged Changes\" pane.\n> > > > >\n> > > > >   I think the difference here is because for\n> > > > >   `apply_or_revert_range_or_line`, we call `do_rescan` after it to\n> > > > >   update the UI, but for `apply_or_revert_hunk` we update the UI\n> > > > >   \"manually\" in the function after we are done applying or reverting the\n> > > > >   changes. So the logic to update the UI needs to be updated to account\n> > > > >   for this change. Or we can get rid of all that logic and just run a\n> > > > >   rescan.\n> > > > >\n> > > > > And also, like you mentioned, we don't retain the i-t-a state when\n> > > > > unstaging. But with some quick testing, I see that Git command line\n> > > > > doesn't either (I tried a plain `git restore --staged`). So IMO we\n> > > > > should mimic what the command line UI does and not retain the i-t-a\n> > > > > state when unstaging.\n> > > >\n> > > > To be quite honest, I had hoped that this might be a good patch to start\n> > > > from... for somebody else (you?)\n> > >\n> > > I'll take a stab at this during the weekend :-)\n> >\n> > Just a gentle ping: did you get a chance to get this patch into a better\n> > shape?\n>\n> No, I have not. I'll try my hand on it tomorrow and try to get it done\n> in time for 2.29.\n\nThank you so much!\n\nCiao,\nDscho\n"}]}