Re: [PATCH v2 00/18] remote-bzr: massive changes

From: Junio C Hamano <gitster@pobox.com>
Date: May 1, 2013, 05:44 UTC
Message-ID: <7vppxb8d9k.fsf@alter.siamese.dyndns.org>
In-Reply-To: <1367370610-14250-1-git-send-email-felipe.contreras@gmail.com>

Felipe Contreras <felipe.contreras@gmail.com> writes:

Show 13 quoted lines

> After being contacted by the emacs developers and others who are stuck with
> Bazaar, which at this point seems to be utterly abandoned, I realized the
> current implementation is too crude.
> ...
> That is of course, if pushing actually worked (which in many cases doesn't).
>
> In short, our support for real-world projects suck.
>
> These patches fix all the issues I encountrered.
> ...
> Finally, after all these changes I was finally able to clone the whole emacs
> repository, all 130685 commits, and 56 branches without running out of memory
> in my modest laptop.

Yay ;-)

I assume that the trees at a handful of key points (e.g. releases) were verified to be identical with the original history and the conversion result.

Show 5 quoted lines

> Since the purpose of remote-bzr is to actually be usable for the
> poor souls stucks in DSCMs that are not git, these changes are a
> must. I propose they be merged for the next major version of git
> (v1.8.3) if no issues are found.  They changes pass all the tests,
> and work on various repositories I've tried.

Nice.

> I'll ask the emacs developers to give them a try, and let's see
> how it goes.

Yeah, that's the least we can do for both existing and future users.

Generally speaking, post -rc0 is too late for "if no issues are found", simply because no existing user has enough time to find corner case regressions in her work using the new software (I do not expect a trivial bug that can be uncovered in a few weeks of use would remain in a version that has successfully converted the Emacs history; but real world users always have different needs than what we anticipate).

I however am finding myself moderately receptive to this series. That is primarily because this series touches only two files that are totally isolated from the rest of the system. Even if they did not work at all, there is no risk for the remainder of Git. Nobody other than existing users of remote-bzr will even notice if we merged this by the final.

For existing users of remote-bzr that we shipped in 1.8.2, the story is a bit different, though. If this series makes things worse in a way your tests did not reveal, and if such a regression is not reported and/or cannot be fixed by 1.8.3 final, that will mean a real regression in the released version for them.

If that ever happens, that would be the time for us to regret the hasty decision to merge remote-bzr in 1.8.2, justifying that with a "There wasn't anything working for interoperating with bzr, and here is one to do so; anything is better than nothing", and learn from that mistake (it is not an option to say "the 1.8.2 users chose to use contrib/ material that are clearly marked as sub-par quality with their own risk". If we did not ship it in 1.8.2, they did not have to get burned with any regression and could have kept working with bzr a bit longer. "Anything" is not necessarily better than "nothing").

Hopefully, such a regression will not have to happen (for one thing, I would expect that the existing 1.8.2 remote-bzr user base would be very small). Also I somehow have a feeling that it is very unlikely to happen, especially given your report:

 (1) the series converts Emacs history without barfing; and

 (2) you have some confidence in the conversion result after
     inspecting at least a handful of key release points and trees
     and metainformation match between the original and the
     converted history.

So let's go ahead and apply these directly on top of 'master', once we hear from Emacs folks and they are happy with it. I'll queue it on 'pu' so that I do not have to go back to the list archive when it happens.

Thanks.