"staging area"?

[Masklinn]

On 2010-06-20, at 18:41 , Daniel Carrera wrote:

> On Sun, Jun 20, 2010 at 5:24 PM, Masklinn <masklinn at masklinn.net> wrote:
>> You want the patch subshell, which you can also access directly with git add
>> -p for an experience closer to darcs/hg record.
> 
> Ah. Thanks. I see it now. It is more complicated than darcs/hg record.
> It overlaps in functionality with hg crecord, but unlike crecord, it
> comes a the expense of simplicity.
> 
I wouldn't quite say that darcs record is simple ([ynWsfvplxdaqjk] is quite a frightening sight), likewise with crecord, but yes in general I don't find git's UI simple (or coherent, for that matter) either.

>> I'm not really sure what to make of this. git add -i/-p does show you the changes between
>> the working directory and the staging area. I can understand not liking git's two-step
>> commit process, I definitely am not fond of it myself, but I don't quite understand what
>> your second phrase means here.
> 
> Simple: It comes from now knowing how git add -p worked.
> 
> If you just do "git add" you'll get an error. You have to give it
> parameters. For example:
> 
> git add file1 file2 file3
> git add some/directory/patth/file4
> git add some/other/directory/path/file5
> 
> I was expecting "git add -p" to work the same way, but it doesn't. It
> actually shows you all the changes in the entire working directory.
> 
git add can see the whole repo though, by giving it "." as a parameter from the root of the working copy (it's recursive), -u (stages updates to the working copy, so editions or deletions, and the filespec is optional) or -A (like -u except it also stages the addition of unknown un-ignored files in the working copy).