git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Another Email <yetanotheroneemail@gmail.com>
To: "Raymond E. Pasco" <ray@ameretat.dev>
Cc: git@vger.kernel.org
Subject: Re: Issue when adding new files to staged changes using interactive mode
Date: Wed, 29 Jul 2020 23:33:48 +0100	[thread overview]
Message-ID: <3B809D01-D744-436E-98A5-73B4BE6351CC@gmail.com> (raw)
In-Reply-To: <C4JFF5L90V54.1FQKYQPIC3O43@ziyou.local>

Hi Raymond,

Thanks for looking into this.

> Before I continue rooting around in the source, though, I wonder if the
> real issue here isn't the fact that add -p fails to support new files
> (requiring the intent-to-add workaround in the first place). I have
> always thought it's a confusing user experience that git add -p on a
> file that isn't yet tracked simply returns "No changes".
> 
> The underlying problem may be, and I say this without intimate knowledge
> of the subsystem, that we're now trying to force add-patch.c to do
> something it doesn't actually support, namely new files, whereas before
> it was attempting to patch what it saw as an empty file.

I cannot comment on the internals of git, but the typical use-case for using git add -p on new files would be when you add them as part of the changes that also involve existing files in the interactive mode, therefore it's helpful to have support for both compared to having to stage new files separately.

> 
> This (patch-adding new files) is real in my workflow; is there any
> reason why git add -p with an explicit argument shouldn't attempt to add
> untracked files covered by the explicit argument? (In addition to fixing
> it for intent-to-adds.)

If I get the question right, it's perfectly fine for me personally to stage a single new file via git add -p. I agree, technically, it doesn't make a lot of sense, probably rather a matter of muscle memory, when you treat new files the same way as existing ones.


  reply	other threads:[~2020-07-29 22:33 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-28 23:10 Issue when adding new files to staged changes using interactive mode Another Email
2020-07-29 18:58 ` Raymond E. Pasco
2020-07-29 21:30   ` Raymond E. Pasco
2020-07-29 22:33     ` Another Email [this message]
2020-07-31 19:51 ` Taylor Blau

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=3B809D01-D744-436E-98A5-73B4BE6351CC@gmail.com \
    --to=yetanotheroneemail@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=ray@ameretat.dev \
    /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).