git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Filipp Bakanov <filipp@bakanov.su>
Cc: git@vger.kernel.org
Subject: Re: Proposal: "unadd" command / alias.
Date: Wed, 28 Oct 2020 16:44:08 -0700	[thread overview]
Message-ID: <xmqqmu059arb.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: <CAAdniQ5pRHKUU77XVmZkZ_gUgfYYFpo9=Xt2T6EgzJ3hoT0YMg@mail.gmail.com> (Filipp Bakanov's message of "Tue, 27 Oct 2020 23:10:00 +0300")

Filipp Bakanov <filipp@bakanov.su> writes:

> Hi! I suggest to add "unadd" command, that will undo a git add command.
>
> git unadd path/to/file
>
> It will be an alias to:
>
> git reset HEAD -- path/to/file
>
> The motivation is that I always forget syntax and have to google each
> time I want to undo accidentally added files. Unadd is just much
> easier to remember and quite obvious.

I am not sure if the behaviour of the "git reset HEAD -- path" is
what people would imagine what "unadd" would do, actually.  For
example, with this sequence:

    $ edit file
    $ git add file
    $ edit file
    $ git add file
    $ git unadd file

what would be the natural expectation of users after the last
"unadd" step?  Should it have the result of the first 'add'?  Should
another "git unadd file" bring the index back to the state before
the first 'add' was run?

There is no such ambiguity to "reset HEAD -- path".  It tells
exactly what contents you want to have in the index for the path
(i.e. the same as what is in HEAD).  There is no "go back to the
state before the last add", and there is no false hint that such a
thing might exist.

So, I do not think it is a good idea to even call it "unadd", let
alone adding an alias that is used outside your immediate circle
where you can explain what it exactly means to "unadd" by your
definition.

      parent reply	other threads:[~2020-10-28 23:44 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-27 20:10 Proposal: "unadd" command / alias Filipp Bakanov
2020-10-27 20:32 ` Junio C Hamano
2020-10-27 21:56   ` Theodore Y. Ts'o
2020-10-27 22:02     ` Filipp Bakanov
2020-10-27 22:54       ` Theodore Y. Ts'o
2020-10-27 23:14         ` Filipp Bakanov
2020-10-28 11:00           ` Philip Oakley
2020-10-28 12:13 ` Konstantin Tokarev
2020-10-28 12:21   ` Filipp Bakanov
2020-10-28 13:07 ` Pratyush Yadav
2020-10-28 13:56   ` Filipp Bakanov
2020-10-28 23:44 ` Junio C Hamano [this message]

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqmu059arb.fsf@gitster.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=filipp@bakanov.su \
    --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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).