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:
> > Josh Triplett <[email protected]> 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.
>
> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
