From: Michael J Gruber <git@drmicha.warpmail.net>
To: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Cc: Junio C Hamano <gitster@pobox.com>,
Nguyen Thai Ngoc Duy <pclouds@gmail.com>,
git@vger.kernel.org, Jeff King <peff@peff.net>
Subject: Re: [PATCHv2 3/3] git-add: rename -u to -a
Date: Mon, 28 Feb 2011 11:53:05 +0100 [thread overview]
Message-ID: <4D6B7E91.4050308@drmicha.warpmail.net> (raw)
In-Reply-To: <vpqr5aslbje.fsf@bauges.imag.fr>
Matthieu Moy venit, vidit, dixit 28.02.2011 11:05:
> Michael J Gruber <git@drmicha.warpmail.net> 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
next prev parent reply other threads:[~2011-02-28 10:56 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-25 14:45 [PATCH/RFC 0/3] add/commit -u/-a/-A Michael J Gruber
2011-02-25 14:45 ` [PATCH/RFC 1/3] git-add: make -A description clearer vs. -u Michael J Gruber
2011-02-25 19:04 ` Junio C Hamano
2011-02-25 14:45 ` [PATCH/RFC 2/3] git-commit: rename --all to --track Michael J Gruber
2011-02-25 19:08 ` Junio C Hamano
2011-02-25 14:45 ` [PATCH/RFC 3/3] git-add: rename -u to -a Michael J Gruber
2011-02-25 19:40 ` Junio C Hamano
[not found] ` <7vr5aw9b7m.fsf@alter.siamese.dyndns.org>
2011-02-26 10:30 ` [PATCH/RFC 0/3] add/commit -u/-a/-A Michael J Gruber
2011-02-27 15:50 ` [PATCHv2 " Michael J Gruber
2011-02-27 15:50 ` [PATCHv2 1/3] git-add: make -A description clearer vs. -u Michael J Gruber
2011-02-27 23:35 ` Junio C Hamano
2011-02-27 15:50 ` [PATCHv2 2/3] git-commit: rename --all to --all-tracked Michael J Gruber
2011-02-27 15:50 ` [PATCHv2 3/3] git-add: rename -u to -a Michael J Gruber
2011-02-27 16:38 ` Nguyen Thai Ngoc Duy
2011-02-28 6:40 ` Junio C Hamano
2011-02-28 8:30 ` Michael J Gruber
2011-02-28 8:42 ` Miles Bader
2011-02-28 8:46 ` Michael J Gruber
2011-02-28 8:53 ` Miles Bader
2011-02-28 9:05 ` Snipping on this list (Was: Re: [PATCHv2 3/3] git-add: rename -u to -a) Michael J Gruber
2011-02-28 18:18 ` Snipping on this list Junio C Hamano
2011-02-28 9:03 ` [PATCHv2 3/3] git-add: rename -u to -a Miles Bader
2011-02-28 9:08 ` Michael J Gruber
2011-02-28 9:40 ` Matthieu Moy
2011-02-28 9:49 ` Michael J Gruber
2011-02-28 10:01 ` Tor Arntsen
2011-02-28 10:03 ` Michael J Gruber
2011-02-28 10:05 ` Matthieu Moy
2011-02-28 10:53 ` Michael J Gruber [this message]
2011-02-28 18:21 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D6B7E91.4050308@drmicha.warpmail.net \
--to=git@drmicha.warpmail.net \
--cc=Matthieu.Moy@grenoble-inp.fr \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=pclouds@gmail.com \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).