git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: What's cooking in git.git (Feb 2013, #05; Tue, 12)

From
Junio C Hamano <gitster@pobox.com>
Date
Feb 14, 2013, 04:36 UTC
Message-ID
<7vtxpf341w.fsf@alter.siamese.dyndns.org>
In-Reply-To
<CAH5451kogwuzOs+BrHksDSdECbHrmW8DwTve0_kKq+-PTx+4bw@mail.gmail.com>
Andrew Ardill <andrew.ardill@gmail.com> writes:
Show 15 quoted lines
>> 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.
Previous: Andrew ArdillNext: Andrew Ardill
Message 9 of 15 in “What's cooking in git.git (Feb 2013, #05; Tue, 12)”
  1. Junio C HamanoFeb 13, 2013
  2. jn/shell-disable-interactive (Re: What's cooking in git.git (Feb 2013, #05; Tue, 12))Jonathan Nieder, Feb 13, 2013
  3. Junio C HamanoFeb 13, 2013
  4. Andrew ArdillFeb 13, 2013
  5. Junio C HamanoFeb 13, 2013
  6. Andrew ArdillFeb 13, 2013
  7. Junio C HamanoFeb 13, 2013
  8. Andrew ArdillFeb 14, 2013
  9. Junio C HamanoFeb 14, 2013
  10. Andrew ArdillFeb 14, 2013
  11. Junio C HamanoFeb 14, 2013
  12. Junio C HamanoFeb 14, 2013
  13. Miles BaderFeb 22, 2013
  14. Junio C HamanoFeb 22, 2013
  15. greened@obbligato.orgFeb 18, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.