On Thu, Apr 04, 2013 at 09:59:49PM -0700, Junio C Hamano wrote:
> > That means the worst case is not the accidental loss of content,
> > but rather confusion by the user when a copy of a file another
> > part of the tree is removed.
>
> A copy of a file that is on the filesystem that may not be r
Jeff King writes:
> Here's a replacement for patch 3, then. I wasn't sure if the
> editorializing in the last 2 paragraphs should go in the commit message
> or the cover letter; feel free to tweak as you see fit.
They look fine as they are.
> That means the worst case is not the accidental loss
On Thu, Apr 04, 2013 at 04:33:39PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > So let's drop patch 3. Do we want instead to have an expect_failure
> > documenting the correct behavior?
>
> I think that is very much preferred.
Here's a replacement for patch 3, then. I wasn't sure if
Jeff King writes:
> So let's drop patch 3. Do we want instead to have an expect_failure
> documenting the correct behavior?
I think that is very much preferred.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo
On Thu, Apr 04, 2013 at 04:12:01PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > Deleting across symlinks inside the repo can be brushed aside with "eh,
> > well, it is just another way to mention the same name in the
> > filesystem". But deleting anything outside of the repo seems acti
Jeff King writes:
> Deleting across symlinks inside the repo can be brushed aside with "eh,
> well, it is just another way to mention the same name in the
> filesystem". But deleting anything outside of the repo seems actively
> wrong.
Yup, you finally caught up ;-) IIRC, such an outside reposit
On Thu, Apr 04, 2013 at 01:31:43PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> >> If you do this:
> >>
> >>rm -fr d e
> >> mkdir e
> >> >e/f
> >> ln -s e d
> >> git add d/f
> >>
> >> we do complain that d/f is beyond a symlink (meaning that all you
Jeff King writes:
>> If you do this:
>>
>> rm -fr d e
>> mkdir e
>> >e/f
>> ln -s e d
>> git add d/f
>>
>> we do complain that d/f is beyond a symlink (meaning that all you
>> can add is the symlink d that may happen to point at something).
>
> Right, but th
On Thu, Apr 04, 2013 at 12:42:54PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > +test_expect_success SYMLINKS 'replace dir with symlink to dir (same
> > content)' '
> > + git reset --hard &&
> > + rm -rf d e &&
> > + mkdir e &&
> > + echo content >e/f &&
> > + ln -s e d &&
>
Jeff King writes:
> +test_expect_success SYMLINKS 'replace dir with symlink to dir (same
> content)' '
> + git reset --hard &&
> + rm -rf d e &&
> + mkdir e &&
> + echo content >e/f &&
> + ln -s e d &&
> + git rm d/f &&
> + test_must_fail git rev-parse --verify :d/f &
10 matches
Mail list logo
