Re: Importing from tarballs; add, rm, update-index?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 12 Jan 2007 10:47:56 -0800, Junio C Hamano wrote:
> People new to git need to learn that the next commit is prepared
> not in the working tree but in a separate entity (staging area),

Why's that? Git really provides two separate notions here.

1. Prepare content in staging area, then commit it.

	Working with this notion, the commands a user might use are
	"git update-index", (and more recently "git add"), "git
	commit", and "git commit -a".

2. Prepare content in working tree, and commit from there

	Working with this notion, the commands a user might use are
	"git add" (to add a new file---not the new staging add),
	"git commit files...", and "git commit -a".

> "git-update-index".  I do not have anything against "git stage"
> but I simply do not see the point, other than "git update" would
> imply something entirely different to people coming from other
> SCM so we would want to avoid the word, and "git update-index"
> is too long to type every day.

Yes, those would be the only reasons for the rename. If those aren't
important then just declare "update-index" the porcelain command.

> > First, specifying extra files after 'git commit' bypasses the index.
>
> Which I happen to think is a misfeature.

But this feature _exists_ in git, and it's also _extremely_ useful.

It also just happens to provide an alternate concept by which someone
can understand "commit -a", (not that "commit -a" shows up under both
of the conceptual notions I described above).

I still don't understand how people argue so strongly against the
conceptual notion of "committing content from working tree" when git
does provide this functionality, and it also just happens to exactly
match what a lot of people want to do anyway.

The index is still there, and will still benefit the user during merge
conflicts, but there's no requirement for the user to think of the
index as a staging area to get that benefit. And there's particularly
no need for the user to be forced to conceptualize every commit as
first being staged before committed.

Where's the actual benefit to the user in only promoting the "stage
content, then commit" model?

-Carl

Attachment: pgpYuNzeTWkQG.pgp
Description: PGP signature


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]