On Wed, Apr 03, 2013 at 10:35:52AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > Of the two situations, I think the first one is less likely to be
> > destructive (noticing that a file is already gone via ENOTDIR), as we
> > are only proceeding with the index deletion, and we end up not
On Wed, Apr 03, 2013 at 10:35:52AM -0700, Junio C Hamano wrote:
> > diff --git a/builtin/rm.c b/builtin/rm.c
> > index dabfcf6..7b91d52 100644
> > --- a/builtin/rm.c
> > +++ b/builtin/rm.c
> > @@ -110,7 +110,7 @@ static int check_local_mod(unsigned char *head, int
> > index_only)
> >
Jeff King writes:
> Of the two situations, I think the first one is less likely to be
> destructive (noticing that a file is already gone via ENOTDIR), as we
> are only proceeding with the index deletion, and we end up not touching
> the filesystem at all.
Nice to see sound reasoning.
>
> diff
On Wed, Apr 03, 2013 at 07:50:24AM -0700, jpinheiro wrote:
> While experimenting with git we found an unexpected behavior with git rm.
> Here is a trace of the unexpected behavior:
>
> $ git init
> $ mkdir D
> $ echo "Hi" > D/F
> $ git add D/F
> $ rm -r D
> $ echo "Hey" > D
> $ git rm D/F
> warni
init
$ mkdir D
$ echo "Hi" > D/F
$ git add D/F
$ rm -r D
$ echo "Hey" > F
$ git rm D/F
This works as expected, and the only difference is the name of the file of
the last echo.
Is this the expected behavior of git rm?
--
View this message in context:
http://git.661
5 matches
Mail list logo