Re: [RFC/GSoC] Proposal: Make git-pull and git-am builtins

From: Paul Tan <pyokagan@gmail.com>
Date: Mar 26, 2015, 05:02 UTC
Message-ID: <CACRoPnQusL85-ZOoM3Mg579eyvcL=BOgzz6KsnnNC5hRY9uAFw@mail.gmail.com>
In-Reply-To: <xmqq4mp92c9h.fsf@gitster.dls.corp.google.com>

On Thu, Mar 26, 2015 at 1:54 AM, Junio C Hamano <gitster@pobox.com> wrote:

Show 13 quoted lines

> Paul Tan <pyokagan@gmail.com> writes:
>
>> I think it's still good to have the ideal in mind though (and whoops I
>> forgot to put in the word "ideal" in the text).
>
> Using or not using fork is merely one of the trade-offs we can make.
>
> "If all other things are equal, no fork is better than a fork" is a
> meaningless statement, as all other things are never equal in real
> life---doing things internally will have a cost of having to clean
> up and a risk to get that part wrong, for example.  Engineering is a
> fine balancing act and setting an absolute goal is not a healthy
> attitude.

No, I do not mean "all other things are equal", I meant "all other things are ideal", meaning that human factors are not involved.

I thought we were in agreement that calling functions in the internal API is technically superior to forking, assuming that there are no bugs or errors. Isn't this one of the reasons why libgit2 exists? If for whatever reason spawning an external git process is chosen, it would be because rewriting all the code paths without committing any errors would take too much effort.

I will switch the word "requirements" to the word "guidelines" to make it sound less strict. However my above point still stands.