Re: [PATCH] remote-bzr: update old organization
- From
Junio C Hamano <gitster@pobox.com>
- Date
- May 14, 2013, 22:33 UTC
- Message-ID
- <7v7gj1fayr.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <CAMP44s2L9CsLu+hr4McVzUnb7x+uipEs5nHKLg+69BicMaJjpA@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
Show 24 quoted lines
> On Tue, May 14, 2013 at 5:14 PM, Junio C Hamano <gitster@pobox.com> wrote: >> Junio C Hamano <gitster@pobox.com> writes: >> >>> Felipe Contreras <felipe.contreras@gmail.com> writes: >>> >>>> And the clone would happen either way, with or without this patch, >>>> because 'hg/origin/master' doesn't exist, the only purpose 'hg/origin' >>>> serves is to block the new feature. >>> >>> That is the answer I was trying to extract out of you (I take the hg >>> is a typo for bzr in the above, though). >> >> Just to double check, I understand that the justification for >> removal is this: >> >> If a clone exists with the old organization (v1.8.2) it will prevent the >> new shared repository organization from working, so let's remove this >> -repository, which is not used any more. >> +repository. It is not used by 1.8.3, and did not host any useful >> +information in the code in 1.8.2. > > That is not true. It did host useful information in 1.8.2, if we apply > this and the user tries to pull with remote-bzr from 1.8.2, it would > need to be cloned again.
So the answer to my original question:
So we nuke that and have them clone from scratch?
is now "Yes, unfortunately, but it happens automatically inside remote-bzr and the users won't have to do anything extra"?
That is the kind of honest description I wanted to see.