git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Pratyush Yadav <me@yadavpratyush.com>
Cc: Johannes Schindelin via GitGitGadget <gitgitgadget@gmail.com>,
	git@vger.kernel.org
Subject: Re: [PATCH] git-gui: accommodate for intent-to-add files
Date: Fri, 9 Oct 2020 08:56:39 +0200 (CEST)	[thread overview]
Message-ID: <nycvar.QRO.7.76.6.2010090855260.50@tvgsbejvaqbjf.bet> (raw)
In-Reply-To: <20200826145217.gx2prxltyoyuoxo3@yadavpratyush.com>

Hi Pratyush,

On Wed, 26 Aug 2020, Pratyush Yadav wrote:

> On 26/08/20 09:36AM, Johannes Schindelin wrote:
>
> > On Wed, 26 Aug 2020, Pratyush Yadav wrote:
> >
> > > On 12/08/20 03:06PM, Johannes Schindelin via GitGitGadget wrote:
> > > > From: Johannes Schindelin <johannes.schindelin@gmx.de>
> > > >
> > > > 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@gmx.de>
> > > > ---
> > > >     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?)
>
> I'll take a stab at this during the weekend :-)

Just a gentle ping: did you get a chance to get this patch into a better
shape?

Thanks,
Dscho

  reply	other threads:[~2020-10-09  9:14 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-12 15:06 [PATCH] git-gui: accommodate for intent-to-add files Johannes Schindelin via GitGitGadget
2020-08-26 11:30 ` Pratyush Yadav
2020-08-26  7:36   ` Johannes Schindelin
2020-08-26 14:52     ` Pratyush Yadav
2020-10-09  6:56       ` Johannes Schindelin [this message]
2020-10-09  9:34         ` Pratyush Yadav
2020-10-09 13:22           ` Johannes Schindelin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=nycvar.QRO.7.76.6.2010090855260.50@tvgsbejvaqbjf.bet \
    --to=johannes.schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=me@yadavpratyush.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).