[This message, (yes,another long one from me), proposes 3 changes. The

first should be uncontroversial I think, while the second and third

are clear heresy, (and the second would require some amount of

re-training or re-configuration by existing git user). Pick and choose

as you see fit. I don't think they actually depend on each other,

though I'll present them here as parts of a whole.]
Change #1: Add "git stage" command, use "--staged" instead of "--index"

=======================================================================

If we're going to start describing the index as a "staging area" let's

make the command set reflect that as well. I propose a new "git stage"

command that is intended for human use when wanting to do a staged

commit.
Then, a few other commands that currently have --index or --cached

arguments could switch to --staged as well.
With this change here is a summary of some of the primary git commands

(that are relevant to the current discussion):
add		Shove a file's contents into git's staging area
stage		Shove a file's contents into git's staging area
rm		Remove a file from git's staging area
diff		Show what's changed in working tree compared to

		staging area
diff --staged	Show what's changed in staging area compared to latest

		commit
commit		Create a new commit from the contents of the staging area
commit -a	Update the contents of all files in the staging area,

		and create a new commit from the new staging area
commit files...	Create a new commit that differs from the latest

		commit only in files... (which get new content from

		the current working tree). Staged content of other

		files (if any) will not be committed.
I hope that so far (in this email) I haven't said anything very

contentious. This is basically just a summary of the existing behavior

with things like "update-index" and "--cached" changed to "stage" and

"--staged".
The introduction of this new "stage" command would be a very minor

change. If you're not particula...
[ message continues ]

As a newbie like this entire proposal and especially the above.
Wink Saville
-

I wonder about backwards compatibility, but then another part of me says

that porcelain are probably using "git-commit-tree" anyway.
How about considering alternative words?  Like "git save" for this

higher level and more user friendly interface.
As another idea (brainstorming here), what about an "autocommit" approach?
  git rm       # removes files and asks for commit message

  git add      # ditto

  git commit   # updates and commits everything
  git stage    # starts a staged commit

  git add      # modifies staging area

  git rm       # ditto

  git stage filename # adds contents to staging area

  git commit   # saves staging area as commit
Then you could have "core.autocommit" as a repo-config option,
The "autocommit" concept may make this less of an issue.
Sam.

-

/me likes (both emails).
Q: should git-commit require either -a or --staged when there is a

staged commit?
Mark
-

By the way, back when we used to call it the "index" one of the things

that was often mentioned as a reason not to "hide the index" is that

the index ends up being so important during the process of resolving a

merge.
This is extremely true, and this is where git really starts to

shine. I've seen people get really put off by the index when they

first encounter "commit -a" or a messages instructing them to

"update-index" something. But, if people are properly presented with

what git offers for helping with conflict resolution then I think they

will fall in love with it.
But I think "hide the index" vs. "celebrate the index" frames the

debate entirely wrong. It's not a matter of "working tree" vs. "index"

being the king. The king is what the user wants to accomplish and what

does git offer to help with that.
So, for example, in the case of conflict resolution, what git offers

in an iterative process involving:
	git diff	Shows what still needs to be resolved
	git resolve	Indicate to git that conflicts are resolved in

			the specified files
(Yes, I'm assuming a future "resolve" synonym for update-index here)

And finally, "git commit" when complete. This is a fantastic sequence

since it fits what the user wants to do and helps the user do it, (and

the incremental nature of it is helpful for large conflicts).
Note that I don't think it's important whether the final "git commit"

executes a "commit -a" or a mode traditional commit-the-index. It

would be exceedingly rare for someone to want to make a partial,

staged commit during conflict resolution. So I think that special case

can be entirely ignored when considering the user-interface.
So git provides tools well suited to the job here. One thing it

doesn't do well is to advertise them to the user. It would probably be

helpful to print some small section of advice and guidance when the

conflict happens. Right now, git spews a lot of scary internal state

that definitely gives the impression of things going wrong, and

doe...
[ message continues ]