From: Sverre Hvammen Johansen <hvammen@gmail.com>
Date: Mon, 04 Feb 2008 08:06:09 GMT
Subject: Re: [RFC/PATCH] Fast forward strategies only, common, fork and path
Message-ID: <402c10cd0802040006yb654688l8dfc7140c507bc26@mail.gmail.com>
In-Reply-To: <7vwsplkwuq.fsf@gitster.siamese.dyndns.org>

On Feb 3, 2008 11:24 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Please make the next round an in-line patch.  Attachments cannot
> be commented on, and an RFC patch is all about getting comments,
> not about being included.  Whitespace breakages do not matter as
> much as the final submissions; readability and commentability
> matters more.

I will post an update in a few days, with a few bug-fixes.

> Instead of adding many new sub-strategies at once, I think it
> would make it easier to review to split the patch into (1) code
> movement without adding any functionality changes to make your
> further changes easier, if such a change is needed in your work
> (I did not really look at the attachment carefully), (2) add
> logic to find out the set of independent parents to remove
> redundant parents (perhaps using show-branch --independent? I
> dunno) and conditionally use it, (3) add infrastructure to allow
> adding different --ff=<what-to-do>, and then finally (4) a
> separate patch for each of <what-to-do>.

The patch is not easy to read for git-merge.sh.  You really need to
apply the patch and then review the code.  If I follow your suggestion
above it might be easier to read the patches.  I will do if tthere is
a demand for a split.  However, it might take some time.  What is the
time-frame for inclusion in 1.5.5?

> I suspect (2) is controversial if made unconditional.  Some
> people do not even like the fast-forward "merges" we have
> traditionally done.

--ff=never will turn this off together with fast forward.  Maybe we
should have --ff=traditional that is the old behavior.

-- 
Sverre Hvammen Johansen