Re: git-rm isn't the inverse action of git-add

3 messages, 3 authors, 2016-06-15 · open the first message on its own page

Re: git-rm isn't the inverse action of git-add

From: Matthieu Moy <hidden>
Date: 2016-06-15 22:43:19

Johannes Schindelin [off-list ref] writes:
Hi,

On Tue, 3 Jul 2007, Matthieu Moy wrote:
quoted
Johannes Schindelin [off-list ref] writes:
quoted
What's so wrong with our man pages? You know, there have been man 
hours invested in them, and they are exclusively meant for consumption 
by people who do not know about the usage of the commands...
What's wrong is just that I shouldn't have to read a man page to avoid
data-loss.
Okay, Mr Moy.
Glad to be called by my name. Is it a tradition here, or a way to make
fun of me?
How did you learn that "rm" leads to data-loss? Because it does.
It obviously does, and I can't imagine any other behavior than
deleting the file for a command like "rm".
Hmm. How did you expect then, that git-rm does _not_ lead to data
loss? 
Because there are tons of possible behaviors for "$VCS rm", and I'd
expect it to be safe even if VCS=git, since it is with all the other
VCS I know.

What's wrong with the behavior of "hg rm"?
What's wrong with the behavior of "svn rm"?
What's wrong with the behavior of "bzr rm"?
(no, I won't do it with CVS ;-) )

None of these commands have the problem that git-rm has.

-- 
Matthieu

Re: git-rm isn't the inverse action of git-add

From: Johannes Schindelin <hidden>
Date: 2016-06-15 22:43:19

Hi,

On Tue, 3 Jul 2007, Matthieu Moy wrote:
Johannes Schindelin [off-list ref] writes:
quoted
On Tue, 3 Jul 2007, Matthieu Moy wrote:
quoted
Johannes Schindelin [off-list ref] writes:
quoted
What's so wrong with our man pages? You know, there have been man 
hours invested in them, and they are exclusively meant for 
consumption by people who do not know about the usage of the 
commands...
What's wrong is just that I shouldn't have to read a man page to 
avoid data-loss.
Okay, Mr Moy.
Glad to be called by my name. Is it a tradition here, or a way to make 
fun of me?
I tried to be funny, by introducing some diversity...
quoted
How did you learn that "rm" leads to data-loss? Because it does.
It obviously does, and I can't imagine any other behavior than deleting 
the file for a command like "rm".
quoted
Hmm. How did you expect then, that git-rm does _not_ lead to data
loss? 
Because there are tons of possible behaviors for "$VCS rm", and I'd 
expect it to be safe even if VCS=git, since it is with all the other VCS 
I know.
Which proves exactly my point. There are a ton of interpretations that 
make sense. So I would always look into the man page.
What's wrong with the behavior of "hg rm"?
What's wrong with the behavior of "svn rm"?
What's wrong with the behavior of "bzr rm"?
(no, I won't do it with CVS ;-) )

None of these commands have the problem that git-rm has.
Guess what. I do not know how they operate! I have no idea what the 
behaviour of the commands you mentioned is. So before I would answer (if 
they were not rethoric questions), I would actually really read the man 
page to know what they are supposed to do.

Ciao,
Dscho

Re: git-rm isn't the inverse action of git-add

From: Jan Hudec <hidden>
Date: 2016-06-15 22:43:19

On Tue, Jul 03, 2007 at 15:40:12 +0200, Matthieu Moy wrote:
Johannes Schindelin [off-list ref] writes:
quoted
Hmm. How did you expect then, that git-rm does _not_ lead to data
loss? 
Because there are tons of possible behaviors for "$VCS rm", and I'd
expect it to be safe even if VCS=git, since it is with all the other
VCS I know.

What's wrong with the behavior of "hg rm"?
What's wrong with the behavior of "svn rm"?
What's wrong with the behavior of "bzr rm"?
(no, I won't do it with CVS ;-) )

None of these commands have the problem that git-rm has.
Hm. They all behave roughly the same: They unversion the file and unlink it,
unless it is modified, in which case they unversion it and leave it alone.

Now git has the extra complexity that index contains also content of the
file. But the behaviour can be easily adapted like this (HEAD = version in
HEAD, index = version in index, tree = version in tree):
 - if (HEAD == index && index == version) unversion and unlink
 - else if (HEAD == index || index == version) unversion
 - else print message and do nothing

Would you consider that a sane behaviour?

-- 
						 Jan 'Bulb' Hudec [off-list ref]
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help