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

[Jonathan Nieder <jrnieder@gmail.com>]

Hi,

Junio C Hamano wrote:

> 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.

I remember the empty blob era. :)  I don't think I ever saw something
like this patch, though, and a quick search finds that the first
iteration of the bugfix to stop commiting empty blobs was the one that
was used:

 http://thread.gmane.org/gmane.comp.version-control.git/101881/focus=101894

I suspect that at the time, introducing an intent-to-add flag (which
was always the right thing to do) provided enough momentum to avoid
any worries about smaller details like whether to error out or skip
those entries on commit, which could always be changed later (today).

> So I am not sure if this is such a good idea.

My first reaction was the same, but on reflection, I think this is a
good idea as long as the "git status" output in the editor says
something appropriate.

The response Duy mentioned[1] to a report about the unenlightening
message "error building trees" was also memorable:

> 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) thanks for stopping me, I had forgotten about that file;
  (2) I changed my mind, please leave that file out; or (3) please
  dwim and add the file ]

I think (3) was a trick --- no one that does not use the "-a" option
would want that. :)

At the time, I did not understand what (2) meant.  Now I see why ---
in interpretation (2), the user did not change her mind at all.  She
said "I will be adding this file at some point, so please keep track
of it along with the others for the sake of commands like 'git diff'
and 'git add -u', but that does not mean "I will be adding this file
at some point _before the next commit_".

So at the time I thought (1) was the only sensible behavior but kept
my mouth shut; and now I see that (1) and (2) both fit into reasonable
workflows.

However.  A person using "git diff" to review remaining changes and
"git add" to mark files once they have reached their final form would
benefit even more from a switch for "git commit" to error out if _any_
files in the worktree do not match the index.  So if we are to take
this workflow seriously, treating "git add -N" as a special case is
not helping.  What we currently provide for this workflow is a
reminder in the status area of changes that were not marked with "git
add".

I suspect no longer erroring out might feel eerie for a period for
people that were relying on "git add -N" as a reminder but that as
long as the "git status" output is sensible enough, Duy's proposed
behavior would end up seeming just as natural.

(2) makes intent-to-add entries just like any other tracked index
entry with some un-added content.  It is conceptually pleasant and
fits well in all workflows I can imagine[2].

Hope that helps, and sorry for the ramble,
Jonathan

[1] http://thread.gmane.org/gmane.comp.version-control.git/170651/focus=170658
[2] Ok, that is a small lie.  In "git stash", a commit is used to save
the state of the index, so the user would want the presence of the
intent-to-add entry to be stored somehow in the commit, and none of
(1), (2), or (3) will make her happy.  Using "git commit" this way is
not going to work when there are unmerged entries, for example,
either, so I think it is okay to ignore that problem here.