Re: tools for easily "uncommitting" parts of a patch I just commited?

Jacob Keller [off-list ref] writes:

I still think we're misunderstanding. I want git commit to complain
*only* under the following circumstance:

I run "git add -p" and put a partial change into the index in <file>.
There are still other parts which were not added to the index yet.
Thus, the index version of the file and the actual file differ.

Then, I (accidentally) run "git commit <file>"

I agree that this case is different.

Again, users are different, and I also often do

    $ edit file; think; decide it is a good enough first cut
    $ git add file
    $ edit file; think; decide it is getting better
    $ git add file
    $ edit file; think; decide it is now perfect
    $ git commit file

Because I do not think you can differentiate the above workflow from
the case where "git add -p" was used earlier, I think your updated
"git commit" needs to complain at this point.

I am not sure if that is OK.  I think it is less not-OK than the use
case I mentioned in my earlier message, in that this is not a case
that "please don't do it" breaks.  It however is an inconvenience
that the user has to say "git add file" before the "git commit" (or
"git commit file") to conclude the sequence.

So I dunno.

On Thu, Oct 20, 2016 at 10:39 AM, Junio C Hamano [off-list ref] wrote:

Jacob Keller [off-list ref] writes:

quoted

I still think we're misunderstanding. I want git commit to complain
*only* under the following circumstance:

I run "git add -p" and put a partial change into the index in <file>.
There are still other parts which were not added to the index yet.
Thus, the index version of the file and the actual file differ.

Then, I (accidentally) run "git commit <file>"

I agree that this case is different.

Again, users are different, and I also often do

    $ edit file; think; decide it is a good enough first cut
    $ git add file
    $ edit file; think; decide it is getting better
    $ git add file
    $ edit file; think; decide it is now perfect
    $ git commit file

Because I do not think you can differentiate the above workflow from
the case where "git add -p" was used earlier, I think your updated
"git commit" needs to complain at this point.

I am not sure if that is OK.  I think it is less not-OK than the use
case I mentioned in my earlier message, in that this is not a case
that "please don't do it" breaks.  It however is an inconvenience
that the user has to say "git add file" before the "git commit" (or
"git commit file") to conclude the sequence.

So I dunno.

Hmmm.. Ya ok I don't think we can actually distinguish between these
two work flows.

Given that I now know how to fix my mistake easily (git reset -p) I
think I will just go ahead and not bother with this as it's much less
of a pain now.

Thanks,
Jake