All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Andrew Ardill <andrew.ardill@gmail.com>
Cc: "git\@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: What's cooking in git.git (Feb 2013, #05; Tue, 12)
Date: Wed, 13 Feb 2013 20:36:11 -0800	[thread overview]
Message-ID: <7vtxpf341w.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <CAH5451kogwuzOs+BrHksDSdECbHrmW8DwTve0_kKq+-PTx+4bw@mail.gmail.com> (Andrew Ardill's message of "Thu, 14 Feb 2013 13:43:55 +1100")

Andrew Ardill <andrew.ardill@gmail.com> writes:

>> We've discussed that before.
>>
>> http://thread.gmane.org/gmane.comp.version-control.git/171811/focus=171818
>
> Something that I couldn't find discussed was the option of, rather
> than providing a config to 'turn it off', inverting the current
> default/flags combo.
>
> That is, currently git add defaults to not staging file deletions, and
> we provide command line flags to include them. The consensus in the
> thread is that it is better to stage them by default; it seems
> reasonable to me that if we stage deletions by default we should
> provide flags to _not_ stage them. If that was the entirety of the
> change, would your position from that thread, "if we need this
> optional, then it is not worth doing this", still hold?

If that is the change we are going to make, and if you can guarantee
that nobody who is used to the historical behaviour will complain,
then I am fine with it, but I think the latter part of the condition
will not hold.

> Some people would be adversely affected by this change, but any
> objections I can come up with are not game stoppers.
> - It is possible newcomers might stumble at deleted files being staged
> for commit by a command called 'add',...

New people are fair game; we haven't trained them with the
"inconsistent" behaviour, and the default being different from
historical behaviour will not affect them adversely.

> - For people who rely heavily on file deletions remaining out of the
> index, providing a flag allows them to keep their workflow.

Allowing to do the things they used to be able to do is a bare
minimum.  You are still forcing them to do things differently.

> - For scripts that rely on this behaviour, a flag allows it to be
> updated, though it may break in the meantime.

Likewise.

> Finally, making this change makes sense from a consistency point of
> view.

That is a given. Otherwise we wouldn't be even discussing this.

  reply	other threads:[~2013-02-14  4:36 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-13  0:06 What's cooking in git.git (Feb 2013, #05; Tue, 12) Junio C Hamano
2013-02-13  0:12 ` jn/shell-disable-interactive (Re: What's cooking in git.git (Feb 2013, #05; Tue, 12)) Jonathan Nieder
2013-02-13  0:15   ` Junio C Hamano
2013-02-13  0:21 ` What's cooking in git.git (Feb 2013, #05; Tue, 12) Andrew Ardill
2013-02-13  0:34   ` Junio C Hamano
2013-02-13  0:42     ` Andrew Ardill
2013-02-13 15:27       ` Junio C Hamano
2013-02-14  2:43         ` Andrew Ardill
2013-02-14  4:36           ` Junio C Hamano [this message]
2013-02-14  4:54             ` Andrew Ardill
2013-02-14 16:59               ` Junio C Hamano
2013-02-14 23:17                 ` Junio C Hamano
2013-02-22  8:32                   ` Miles Bader
2013-02-22 16:58                     ` Junio C Hamano
2013-02-18 20:21 ` greened

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=7vtxpf341w.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=andrew.ardill@gmail.com \
    --cc=git@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.