From: Junio C Hamano <hidden> Date: 2016-06-15 23:08:45
Josh Triplett [off-list ref] writes:
As far as I can tell, if I run "git add -N" on a file, and then commit
without adding the file contents, it gets committed as an empty file.
Is that true? Git once worked like that in earlier days, but I
think write-tree (hence commit) would simply ignore intent-to-add
entries from its resulting tree.
Could stash save it exactly as if I'd done "git add" of an empty file at
that path and then filled in the contents without adding them?
As I said, there is no space for a tree object to say "this one
records an empty blob but it actually was an intent-to-add entry"
and "this other one records an empty blob and it indeed is an empty
blob". So "stash pop" (or "stash apply") would fundamentally be
unable to resurrect the exact state after "add -N".
quoted
"git rm --cached" the path and then running "stash save" would be a
workaround, but then you'd probably need to use "--untracked" hack
when you run "stash save" if you are stashing because you are going
to do something to the same path in the cleaned-up working tree.
Right; I do specifically want to save the working-tree files.
Then "git add" that path before "stash save" would probably be a
better workaround.
On Wed, Mar 16, 2016 at 11:51 AM, Junio C Hamano [off-list ref] wrote:
Josh Triplett [off-list ref] writes:
quoted
As far as I can tell, if I run "git add -N" on a file, and then commit
without adding the file contents, it gets committed as an empty file.
Is that true? Git once worked like that in earlier days, but I
think write-tree (hence commit) would simply ignore intent-to-add
entries from its resulting tree.
We have at least one problem, probably because of the confusion in
diff code (I haven't checked further), which may be fixed once i
re-fix d95d728 (diff-lib.c: adjust position of i-t-a entries in diff -
2015-03-16)
/tmp $ git init a
Initialized empty Git repository in /tmp/a/.git/
/tmp $ cd a
/tmp/a $ git ci --allow-empty -m 1
[master (root-commit) 4d8aed4] 1
/tmp/a $ git add -N new
fatal: pathspec 'new' did not match any files
So far so good..
/tmp/a $ touch new
/tmp/a $ git add -N new
OK let's delete "new" and trigger this problem
/tmp/a $ rm new
/tmp/a $ git ci -m NOOOO
[master ce2e4bb] NOOOO
/tmp/a $ git cat-file commit HEAD|grep ^tree
tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904
/tmp/a $ git cat-file commit HEAD^|grep ^tree
tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904
The second commit should not be created. git-commit is somehow fooled
that there's changes to commit.
--
Duy
On Tue, Mar 15, 2016 at 09:51:35PM -0700, Junio C Hamano wrote:
Josh Triplett [off-list ref] writes:
quoted
As far as I can tell, if I run "git add -N" on a file, and then commit
without adding the file contents, it gets committed as an empty file.
Is that true? Git once worked like that in earlier days, but I
think write-tree (hence commit) would simply ignore intent-to-add
entries from its resulting tree.
Git 2.7.0 does appear to commit an empty file if I commit after git add
-N.
quoted
Could stash save it exactly as if I'd done "git add" of an empty file at
that path and then filled in the contents without adding them?
As I said, there is no space for a tree object to say "this one
records an empty blob but it actually was an intent-to-add entry"
and "this other one records an empty blob and it indeed is an empty
blob". So "stash pop" (or "stash apply") would fundamentally be
unable to resurrect the exact state after "add -N".
How completely crazy would it be to use a non-standard mode bit for
that?
quoted
quoted
"git rm --cached" the path and then running "stash save" would be a
workaround, but then you'd probably need to use "--untracked" hack
when you run "stash save" if you are stashing because you are going
to do something to the same path in the cleaned-up working tree.
Right; I do specifically want to save the working-tree files.
Then "git add" that path before "stash save" would probably be a
better workaround.
I ended up using rm --cached and stash -u, which worked OK, though I
then had to manually restore the add -N state.
From: Jeff King <hidden> Date: 2016-06-15 23:08:46
On Wed, Mar 16, 2016 at 05:02:45AM -0700, Josh Triplett wrote:
On Tue, Mar 15, 2016 at 09:51:35PM -0700, Junio C Hamano wrote:
quoted
Josh Triplett [off-list ref] writes:
quoted
As far as I can tell, if I run "git add -N" on a file, and then commit
without adding the file contents, it gets committed as an empty file.
Is that true? Git once worked like that in earlier days, but I
think write-tree (hence commit) would simply ignore intent-to-add
entries from its resulting tree.
Git 2.7.0 does appear to commit an empty file if I commit after git add
-N.
I don't think this is the case:
git init
echo content >file
git add -N file
git commit -m "empty?"
git ls-tree HEAD
git status
shows that we committed an empty tree. So I see two obvious
possibilities for improvement:
1. This commit should have failed without --allow-if-empty. We need to
be more careful about intent-to-add entries when figuring out if
the commit would be empty or not
2. I'm not sure if "silently ignore intent-to-add" is the best policy.
At least a warning ("hey, what did you want to do with these
entries") seems merited, if not aborting the commit entirely. I
hesitate on the latter only because perhaps that would mess up
somebody's legitimate workflow.
-Peff
From: Junio C Hamano <hidden> Date: 2016-06-15 23:08:46
I actually think "silently ignore intent-to-add" was a mistake.
We used to error out at write-tree time, which I think is the
right behaviour--"I know I want to have this path, but I cannot
yet decide with what content" is what the user is telling us when
she says "add -N", so until that indecision is resolved, we
shouldn't write out a tree object out of the index.
On Wed, Mar 16, 2016 at 2:05 PM, Jeff King [off-list ref] wrote:
On Wed, Mar 16, 2016 at 05:02:45AM -0700, Josh Triplett wrote:
quoted
On Tue, Mar 15, 2016 at 09:51:35PM -0700, Junio C Hamano wrote:
quoted
Josh Triplett [off-list ref] writes:
quoted
As far as I can tell, if I run "git add -N" on a file, and then commit
without adding the file contents, it gets committed as an empty file.
Is that true? Git once worked like that in earlier days, but I
think write-tree (hence commit) would simply ignore intent-to-add
entries from its resulting tree.
Git 2.7.0 does appear to commit an empty file if I commit after git add
-N.
I don't think this is the case:
git init
echo content >file
git add -N file
git commit -m "empty?"
git ls-tree HEAD
git status
shows that we committed an empty tree. So I see two obvious
possibilities for improvement:
1. This commit should have failed without --allow-if-empty. We need to
be more careful about intent-to-add entries when figuring out if
the commit would be empty or not
2. I'm not sure if "silently ignore intent-to-add" is the best policy.
At least a warning ("hey, what did you want to do with these
entries") seems merited, if not aborting the commit entirely. I
hesitate on the latter only because perhaps that would mess up
somebody's legitimate workflow.
-Peff
From: Jeff King <hidden> Date: 2016-06-15 23:08:46
On Wed, Mar 16, 2016 at 02:11:19PM -0700, Junio C Hamano wrote:
I actually think "silently ignore intent-to-add" was a mistake.
We used to error out at write-tree time, which I think is the
right behaviour--"I know I want to have this path, but I cannot
yet decide with what content" is what the user is telling us when
she says "add -N", so until that indecision is resolved, we
shouldn't write out a tree object out of the index.
Yeah, I am inclined to agree, and I _thought_ we also used to error out
during write-tree, but I failed to find the spot where we switched
(thinking that it might provide some rationale).
I think I just didn't look far enough back, though. Commit 3f6d56d
(commit: ignore intent-to-add entries instead of refusing, 2012-02-07)
does not exactly have a sneaky title.
-Peff