Re: git commit -p with file arguments

From: Jakub Narębski <jnareb@gmail.com>
Date: Sep 12, 2016, 21:14 UTC
Message-ID: <717354e1-79be-d1a2-c6bb-843d6ab99e41@gmail.com>
In-Reply-To: <xmqqa8fd6fs7.fsf@gitster.mtv.corp.google.com>

W dniu 12.09.2016 o 03:57, Junio C Hamano pisze:

Show 10 quoted lines

> Jacob Keller <jacob.keller@gmail.com> writes:
> 
>> Yes, I'm actually confused by "git commit <files>" *not* usinng what's
>> in the index already, so I think that isn't intuitive as is.
> 
> You are excused ;-)
> 
> In ancient days, "git commit <pathspec>" was to add the contents
> from working tree files that match <pathspec> to what is already in
> the index and create a commit from that state.

That is, "git commit <pathspec>" meant --include, being equivalent to "git commit --include <pathspec>".

>                                               This ran against the
> intuition of many users who knew older systems (e.g. cvs) and we had
> to migrate it to the current behaviour by breaking backward
> compatibility.

That is, "git commit <pathspec>" means --only, being equivalent to "git commit --only <pathspec>".

But it was always about working tree version of <pathspec>.

And of course older version control systems didn't have the index...

-- 
Jakub Narębski