Paul Tan [off-list ref] 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.
On Thu, Mar 26, 2015 at 1:54 AM, Junio C Hamano [off-list ref] wrote:
Paul Tan [off-list ref] writes:
quoted
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.