Re: [PATCHv2 3/3] git-add: rename -u to -a

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

 



Matthieu Moy venit, vidit, dixit 28.02.2011 11:05:
> Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> writes:
> 
>> Matthieu Moy venit, vidit, dixit 28.02.2011 10:40:
>> 
>>> # let's see what happens ... $ git add $ # ok, nothing happened
>>> ... # continue hacking without noticing that a bunch of files
>>> have been added.
>> 
>> No no, I said "add" would default to what "-u" does now (see
>> below).
> 
> Right, that less disturbing than I wrote (but still potentially 
> disturbing)
> 
>>> Mercurial has taken the other way, making "hg add" add everything
>>> by default, and some users do complain:
>>> 
>>> http://osdir.com/ml/version-control.mercurial.general/2007-08/msg00316.html
>>
>>
>>> Since when do we care about them (as in "hg", not in "users", mind
>> you...).
> 
> If you don't care about experiences of others, I can do nothing for
> you. I don't have a crystal ball, so I can't say what Git users will
> say about a given feature, but I can look around me (I'm sure you can
> too) and see how it went for other people.
> 

Between hg and git, add and commit are very different. Haven't we all
seen these super smart comparisons saying

hg add is much faster than git add, but git commit is much faster than
hg commit?

They do completely different things. When used after each other, they do
"A+B+C", but "hg add" does "A", "hg commit" "B+C", whereas "git add"
does "A+B", "git commit" does "C" (with pathspecs for add, no options).

Because of that, and also because I haven't thought
about/suggested/proposed what "hg add" seems to do by default now, I
dismiss that experience as unrelated. "hg add" is partially related to
"git add" only, and their default is completely different from what I've
mentioned.

(I think you know hg and git well enough to know this difference, and
also know from the list that I do care [even in your quote], or I would
have explained that in the first place).

>>> If you change this for Git, you'll have people complaining about 
>>> backward compatibility plus people complaining about least
>>> surprise :-(
>>> 
>>>> - "add" should be about tracked paths by default (default
>>>> pathspec "."),
>> 
>> See, here!
>> 
>>>> 
>>>> - "commit -a,--add <addopts>" be "add <addopts> && commit",
>>>> and
>>>> 
>>>> - "-A,--all pathspec" (default pathspec ".") be about tracked
>>>> and untracked paths (whether add or commit).
>>> 
>>> Today, "git add ." adds new content in tracked files, and new
>>> files, but doesn't notice files deletions. Did I miss something,
>>> or is there no way to do that with your proposal?
>> 
>> What in
>> 
>>> That would need a proper migration plan etc., and some thinking
>>> about -i/-o. Just brain-storming.
>> 
>> reads "proposal" to you?
> 
> What's wrong with you today? Miles asks a honnest question and gets
> a dissertation about the netiquette,

A question answered in the post he replied to (but failed to quote).
Given my previous encounters the other day, an explanation of our
netiquette seemed in order (other lists trim much more then we do), and
non the less I did so politely, and I even appreciated his leaving cc in
place (which other lists do differently, and proves his openness to adapt).

> I ask another question, mention
> the experience of other people and get this.

Jeff, then Junio and I have been discussing ways forward to improve the
user experience with respect to related options of "add" and "commit"
(which are similar and named differently, or dissimilar and named the
same), and everyone is welcome to join (of course; just to be clear),
there is no consensus yet. Every voice counts.

> I did read "brainstorming" in your email, tried to brainstorm with
> you, but you're not making it easy to us. I'm stopping here, sorry
> for disturbing.

What is not OK is trimming down my posts to the amount that they make no
sense any more, or a completely different sense, and then commenting on
that skewed quote, forcing me to reexplain what I had explained already.
This makes us go in circles, rather than forward. It's a waste of resources.

You may have been unlucky in being number "n+1" to do so to me on-list
today, and maybe in "proposal" being more formal in English than in
French, alleviated by the fact that you cut out my sentence

"I know I'm getting a bit radical here, but the more I think about it, I
feel that"

introducing the list of items which you did quote (no to mention the
whole reasoning building up to that). So, not just poor luck, you see;)

Writing that long post (with a large unradical part, and a short radical
brain-storming) I was afraid already it would make people read partially
only. I hope we'll turn that into a more constructive direction again.

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[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]