From: Emily Shaffer <emilyshaffer@google.com>
To: git@vger.kernel.org
Subject: Change behavior of git add --patch on newly added file?
Date: Fri, 8 Nov 2019 14:50:35 -0800 [thread overview]
Message-ID: <20191108225035.GA60198@google.com> (raw)
Should 'git add -p <newly-added-file>' do the same thing as 'git add -N
<newly-added-file && git add -p <newly-added-file>'?
To demonstrate:
git init .
printf "%s\n" {1..10} >newfile
git add -p newfile
This outputs "No changes." 'git status' shows that 'newfile' is
untracked.
However, since I want each of my commits to be atomic, I want only lines
1-5 in my first commit. (Or more realistically, maybe I only want
function stubs.)
I *can* do:
git add -N newfile
git add -p newfile
But, why doesn't 'git add -p' just do that on its own? At the very
least, "No changes" is a pretty cryptic output - there ARE changes,
right here in my workspace! (I think it means "there isn't a 'newfile' in
the index, so we can't say whether there is a difference between
'newfile' in the index and 'newfile' in your working tree".)
And if I reason to myself, "I can only add --patch a file which is
tracked, so I need to track this file first" and go skimming through the
documentation for "git add", -N doesn't jump out very much:
-N, --intent-to-add record only the fact that the path will be added later
or,
-N, --intent-to-add
Record only the fact that the path will be added later. An entry for the path is placed in
the index with no content. This is useful for, among other things, showing the unstaged
content of such files with git diff and committing them with git commit -a.
Considering that other parts of the add documentation talk about
tracked or untracked files, I personally miss the upshot that we are
tracking a file which was previously untracked with '-N'. (My gut
guess is that while many Git users are familiar with "tracked" or
"untracked" but less Git users are familiar with what it means to "place
in the index".)
Interestingly, in the whole-file deletion case, I *do* get interactive
support....kind of.
rm trackedfile
git add -p trackedfile
diff --git a/trackedfile b/trackedfile
index f00c965..0000000
--- a/trackedfile
+++ /dev/null
deleted file mode 100644
@@ -1,10 +0,0 @@
-1
-2
-3
-4
-5
-6
-7
-8
-9
-10
(1/1) Stage deletion [y,n,q,a,d,?]? e
Sorry, cannot edit this hunk
Is there a reason that git add -p can't do whole-file support this way?
While I'm less sure about what I'd like to see for copied files, I do
feel like there's a strong argument for patch adding new or deleted
files.
- Emily
next reply other threads:[~2019-11-08 22:50 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-08 22:50 Emily Shaffer [this message]
2019-11-09 4:27 ` Change behavior of git add --patch on newly added file? Junio C Hamano
2019-11-09 7:14 ` Junio C Hamano
2019-11-12 18:47 ` Emily Shaffer
2019-11-12 20:16 ` Johannes Schindelin
2019-11-13 1:47 ` Junio C Hamano
2019-11-11 3:41 ` Jeff King
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191108225035.GA60198@google.com \
--to=emilyshaffer@google.com \
--cc=git@vger.kernel.org \
/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.
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 NNTP newsgroup(s).