Re: Separating "add path to index" from "update content in index"

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

 



At Thu, 21 Dec 2006 21:10:51 -0800, Junio C Hamano wrote:
> I guess my responding to whatever you said was wasted effort,
> and if you do not like "git add" this time, I should not be
> surprised.  That's kind of sad ;-).

I hope I'm not coming across as always just complaining. I do think
the new "git add" thing is an improvement. So if nothing else changes,
I still think git's better than it was before this recent round of
improvements.

> I do not remember who advocated for making "git status" the
> preview of "git commit" to happen.  Was that also you?  I wonder
> how many people use this form:
>
> 	git status -v path1 path2...

I was involved in the discussions that led to "status -v", yes. As a
new user I was surprised that "git diff" didn't give a commit preview
and you replied with the "status -v" idea. As things have turned out,
I've never used "status -v".

> Sure, what you want is "git add --no-add newfile", and I can
> understand that mode of operation if you are always going to
> commit with "git commit -a".  Maybe we can have a config
> variable that makes "commit -a" and "add --no-add" the default
> for these two commands, and we do not have to change anything
> else.

Yes, you could add the "don't update content" as an option to git-add,
and then all that would be left would be a discussion about which
modes get the default and which require configuration options, (and
those discussions generally don't go anywhere).

But don't you see how odd the command "git add --no-add" looks? What
does it mean to add something without adding it? This is just
reinforcing my position that using "add" to mean "update content"
rather muddles things.

> One minor detail I wonder about is what mode bits would you give
> to that placeholder entry.

You could certainly grab them from the named file if it exists. If the
user is going to "commit -a" it won't matter much, right?

> > I think the best would be:
> >
> > 	git update-index --all
> >
> > which would still allow room for:
> >
> > 	git add --all
>
> Wasn't it you who said "all" is ambiguous (all known to git vs
> all in this directory)?

Yes. Having "--all" is ambiguous while "git add" is used for both
adding new paths to the index _and_ updating index content. But if
"git add" were restricted to just adding paths to the index as I am
suggesting, then there's no ambiguity at all.

-Carl

Attachment: pgpxpcbWDiwqo.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]