Hi Pratyush, On Wed, 26 Aug 2020, Pratyush Yadav wrote: > On 12/08/20 03:06PM, Johannes Schindelin via GitGitGadget wrote: > > From: Johannes Schindelin <johannes.schindelin@xxxxxx> > > > > As of Git v2.28.0, the diff for files staged via `git add -N` marks them > > as new files. Git GUI was ill-prepared for that, and this patch teaches > > Git GUI about them. > > > > Please note that this will not even fix things with v2.28.0, as the > > `rp/apply-cached-with-i-t-a` patches are required on Git's side, too. > > > > This fixes https://github.com/git-for-windows/git/issues/2779 > > > > Signed-off-by: Johannes Schindelin <johannes.schindelin@xxxxxx> > > --- > > git-gui: accommodate for intent-to-add files > > > > This fixes the intent-to-add bug reported in > > https://github.com/git-for-windows/git/issues/2779: after a file was > > staged with git add -N, staging hunks/lines would fail silently. > > > > On its own, this patch is not enough, as it requires the patches > > provided in rp/apply-cached-with-i-t-a to be applied on Git's side. > > > > Please note that this patch might need a bit more help, as I do not > > really know whether showing "new file mode 100644" in the diff view is > > desirable, or whether we should somehow try to retain the > > "intent-to-add" state so that unstaging all hunks would return the file > > to "intent-to-add" state. > > I built latest Git master (e9b77c84a0) which has > `rp/apply-cached-with-i-t-a` and tested this patch. It works... for the > most part. > > I can select a line set of lines and they get staged/unstaged, which is > good. The part that is not good though is that a lot of common > operations still don't work as they should: > > - I can't click on the icon in the "Unstaged Changes" pane to stage the > whole file. Nothing happens when I do that. > > - The file that is marked as intent-to-add shows up in both the "Staged > Changes" and "Unstaged Changes" panes, with the "Staged Changes" part > being empty. Ideally it should only show up in the "Unstaged Changes" > pane. > > - Selecting the whole file and choosing "Stage Lines for Commit" works > well. But choosing "Stage Hunk for Commit" does not. While the changes > do get staged, the UI is not properly updated and the file is still > listed in the "Unstaged Changes" pane. > > I think the difference here is because for > `apply_or_revert_range_or_line`, we call `do_rescan` after it to > update the UI, but for `apply_or_revert_hunk` we update the UI > "manually" in the function after we are done applying or reverting the > changes. So the logic to update the UI needs to be updated to account > for this change. Or we can get rid of all that logic and just run a > rescan. > > And also, like you mentioned, we don't retain the i-t-a state when > unstaging. But with some quick testing, I see that Git command line > doesn't either (I tried a plain `git restore --staged`). So IMO we > should mimic what the command line UI does and not retain the i-t-a > state when unstaging. To be quite honest, I had hoped that this might be a good patch to start from... for somebody else (you?) :-) Ciao, Dscho
