From: Santi Béjar <sbejar@gmail.com>
Date: Mon, 19 Feb 2007 09:47:15 GMT
Subject: Re: [PATCH/RFC 0/3] Split fetch and merge logic
Message-ID: <8aa486160702190147ta95ed31ld0e72d214c16db4b@mail.gmail.com>
In-Reply-To: <7v4ppl4xfe.fsf@assigned-by-dhcp.cox.net>

On 2/16/07, Junio C Hamano <junkio@cox.net> wrote:
> "Santi Béjar" <sbejar@gmail.com> writes:
>
> > In the past we've had problems when we have changed the merge logic
> > (as shows 4363dfbe3). This patch makes the two process completely
> > independent, and concentrate the merge logic in one place (leaving
> > git-parse-remote.sh independent of the merge logic).
>
> But that is a solved problem, isn't it?  What else does it
> solve?  The justification for moving around the logic could be
> something like "these three patches do not do that themselves,
> but it opens a door for further work such as ...", but without
> something concrete in "..." part, your response makes the patch
> look mostly needless code churn.
>
> I was hoping to hear something like "now git-fetch has to do
> much less than before, eventual C-rewrite of the command, which
> can borrow some code already written for 'pu' branch, will
> become much easier" ;-).

On 2/16/07, Junio C Hamano <junkio@cox.net> wrote:
> "Santi Béjar" <sbejar@gmail.com> writes:
>
> > This sounds like a good justification, also :-)
>
> What I said was an example.  I do not think your code churning
> actually would make it easier.
>
>

What I said was an example of why having the two logic intermixed can
be problematic. Anyway, basically:

* It is a cleanup
* It makes the code cleaner
* It makes the code easier to maintain
* It makes the future changes easier
* It makes git-parse-remote and almost all git-fetch independent of
the merge logic
* The merge logic is in a few lines
* Do one thing and do it well

Regards,

Santi