Re: Fast-forward able commit, otherwise fail

From: Jacob Keller <jacob.keller@gmail.com>
Date: Jul 9, 2016, 02:10 UTC
Message-ID: <CA+P7+xroUpQDX1hV=s7Qcp_yyt8A1dXuZS4+gwXgqOGy_+QC5w@mail.gmail.com>
In-Reply-To: <xmqqbn27lqm0.fsf@gitster.mtv.corp.google.com>

On Fri, Jul 8, 2016 at 3:19 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 15 quoted lines

> David Lightle <dlightle@gmail.com> writes:
>> In fact, I just noticed that GitLab has built in the functionality I'm
>> looking for even, which is what they call "Merge commit with
>> semi-linear history" but I'm asking whether direct support for this
>> approach would be reasonable.  These approaches can all produce the
>> "untested merged product", but they support the way the users want to
>> use the system as well.  I'm not saying any approach is right or wrong
>> as I'm not qualified enough to say.
>
> We, not being a for-profit entity, do not have a strong incentive to
> add features that encourages bad workflow to the users.  Of course,
> we also do not necessarily stop them if users really want to shoot
> themselves in the foot ;-), but such a change would inevitably be of
> lower priority to us.
>

I would add that after using a linear history at $dayjob a lot, i've found the biggest reasoning for a linear history is that non-linear history confuses the users. I'd rather advocate for learning how to handle the more complex history than trying to force users into quickly rebasing code which can lead to the issues Junio mentioned above.

Thanks, Jake