From: Christian Jaeger <christian@jaeger.mine.nu>
To: Yann Dirson <ydirson@altern.org>
Cc: git@vger.kernel.org
Subject: Re: git-rm isn't the inverse action of git-add
Date: Mon, 02 Jul 2007 22:23:00 +0200 [thread overview]
Message-ID: <46895EA4.5040803@jaeger.mine.nu> (raw)
In-Reply-To: <20070702194237.GN7730@nan92-1-81-57-214-146.fbx.proxad.net>
Yann Dirson wrote:
> On Mon, Jul 02, 2007 at 08:09:37PM +0200, Christian Jaeger wrote:
>
>> Why so complicated? Why not just make git-rm without options behave like
>> cg-rm? (Or at the very least, I'd change the hint to say "try -f --cached".)
>>
>
> It is probably a matter of taste. Personally, I am really upset by
> this behaviour that cvs, cogito, stgit and others share, which forces
> me to issue 2 commands to really delete a file from version control
> and from the filesystem.
>
It doesn't force you to issue 2 commands: the -f option to cg-rm unlinks
the file for you. So you only have to type an additional "-f".
Yes it's probably (partly) a matter of taste: in my bash startup files I
have mv aliased to mv -i and rm to rm -i, so that it asks me whether I'm
sure to delete or overwrite a file. If I know in advance that I'm sure,
I just type "rm -f $file", which then expands to "rm -i -f $file" where
the -f overrides the -i. cg-rm -f just fits very well into this scheme
(the only difference being that "cg-rm $file" doesn't explicitely ask me
whether I also want the file to be unlinked). (BTW note that usually for
removing a file I use a "trash" (or shorter alias "tra") command, which
moves it to a trash can instead of deleting; so I use "tra $file" by
default, and only for big files or when I'm sure I immediately want to
delete them, I use rm, and then if the paths are clear I add the -f
flag, if not (like globbing involved), I don't add the -f and thus am
asked for confirmation.)
If I could alias the git-rm command so that the default action is the
reverse of git-add and adding an -f flag removes it from disk, that
would be fine for me.
> Do you really need to undo an add more often than you need to remove a
> file from version-control ? It may be worth, however, to make things
> easier. Maybe "git add --undo foo" would be a solution ?
This doesn't sound very intuitive to me (and I couldn't fix it with an
alias).
I don't per se require undo actions. I just don't understand why git-rm
refuses to remove the file from the index, even if I didn't commit it.
The index is just an intermediate record of the changes in my
understandings, and the rm action would also be intermediate until it's
being committed. And a non-committed action being deleted shouldn't need
a special confirmation from me, especially not one which is consisting
of a combination of two flags (of which one is a destructive one).
Christian.
next prev parent reply other threads:[~2007-07-02 20:23 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-02 18:09 git-rm isn't the inverse action of git-add Christian Jaeger
2007-07-02 19:42 ` Yann Dirson
2007-07-02 20:23 ` Christian Jaeger [this message]
2007-07-02 20:40 ` Yann Dirson
2007-07-02 20:54 ` Matthieu Moy
2007-07-02 21:05 ` Johannes Schindelin
2007-07-03 10:37 ` Matthieu Moy
2007-07-03 12:09 ` Johannes Schindelin
2007-07-03 13:40 ` Matthieu Moy
2007-07-03 14:21 ` Johannes Schindelin
2007-07-04 20:08 ` Jan Hudec
2007-07-05 13:44 ` Matthieu Moy
2007-07-05 14:00 ` David Kastrup
2007-07-08 17:36 ` [RFC][PATCH] " Matthieu Moy
2007-07-08 18:10 ` Johannes Schindelin
2007-07-08 20:34 ` Matthieu Moy
2007-07-08 21:49 ` Johannes Schindelin
2007-07-09 9:45 ` Matthieu Moy
2007-07-13 17:36 ` Matthieu Moy
2007-07-13 17:41 ` [PATCH] More permissive "git-rm --cached" behavior without -f Matthieu Moy
2007-07-13 17:57 ` Jeff King
2007-07-13 18:53 ` Matthieu Moy
2007-07-14 3:42 ` Jeff King
2007-07-14 0:44 ` Jakub Narebski
2007-07-14 6:52 ` Junio C Hamano
2007-07-14 7:16 ` Junio C Hamano
2007-07-14 10:14 ` Matthieu Moy
2007-07-02 21:20 ` git-rm isn't the inverse action of git-add Christian Jaeger
2007-07-03 4:12 ` Jeff King
2007-07-03 4:47 ` Junio C Hamano
2007-07-03 4:59 ` Jeff King
2007-07-03 5:09 ` Junio C Hamano
2007-07-03 5:12 ` Jeff King
2007-07-03 6:26 ` Junio C Hamano
2007-07-11 12:20 ` Jakub Narebski
2007-07-11 18:56 ` Jan Hudec
2007-07-11 21:26 ` 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=46895EA4.5040803@jaeger.mine.nu \
--to=christian@jaeger.mine.nu \
--cc=git@vger.kernel.org \
--cc=ydirson@altern.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.