Re: [PATCH RFC] commit: allow to commit even if there are intent-to-add entries

["Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>]

2012/1/11 Junio C Hamano <gitster@pobox.com>:
> I have a mild suspicion that in earlier incarnation of the patch we used
> to let empty blobs committed, and then we used to instead not commit
> anything at all for such a path, and the real users were bitten by either
> of these approaches, forgetting to add the contents to the final commit.
>
> So I am not sure if this is such a good idea.

I found your elaborate writing [1] about it. These are the
interpretations listed in that post:

-- 8< --
When running "commit" and "status" with files marked with "intent to add",
I think there are three possible interpretations of what the user wants to
do.

 (1) I earlier said "I'll decide the exact contents to be committed for
     these paths and tell you by running 'git add' later." when I said
     'git add -N'.  But I forgot to do so before running "git commit".
     Thanks for catching this mistake and erroring out.

 (2) I said "I'll decide the exact content to be committed ... later."
     when I said 'git add -N'. I am running "git commit" now, but I still
     don't know what the final contents for this path should be.  I
     changed my mind, and I do not want to include the addition of these
     paths in the commit I am making.  Please do not error out, but just
     ignore the earlier 'add -N' for now.

 (3) I said "I'll decide the exact content to be committed ... later."
     when I said 'git add -N'. I am running "git commit" now, without
     explicitly telling you with 'git add' about the final contents for
     these paths.  Please take it as an implicit hint that I am happy with
     the contents in the working tree and commit them as if I said 'git
     add' on these paths, but do leave modifications to already tracked
     paths that I haven't added with 'git add'.
-- 8< --

So (1) may be the safe and sane interpretation and should be the
default. But perhaps we should allow (2) also, for example with
--skip-intent-to-add option? It's really frustrating to remove all
i-t-a, commit (I don't do "commit <path>"), then add them back.

[1] http://article.gmane.org/gmane.comp.version-control.git/170658

Nguyễn Thái Ngọc Duy (2):
  cache-tree: update API to take abitrary flags
  commit: add --skip-intent-to-add to allow commit with i-t-a entries
    in index

 builtin/commit.c       |   10 +++++++---
 cache-tree.c           |   35 +++++++++++++++++------------------
 cache-tree.h           |    5 ++++-
 merge-recursive.c      |    2 +-
 t/t2203-add-intent.sh  |   17 +++++++++++++++++
 test-dump-cache-tree.c |    2 +-
 6 files changed, 47 insertions(+), 24 deletions(-)

-- 
1.7.3.1.256.g2539c.dirty