Re: [RFC/PATCH] Fast forward strategies only, common, fork and path

From: Sverre Hvammen Johansen <hvammen@gmail.com>
Date: Feb 4, 2008, 08:06 UTC
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:

Show 5 quoted lines

> 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.

Show 10 quoted lines

> 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