Re: [PATCH 0/3] Reject non-ff pulls by default

From: Philip Oakley <philipoakley@iee.org>
Date: Sep 8, 2013, 10:02 UTC
Message-ID: <5E98A1684FFB4A7D93A17A609F92A1B3@PhilipOakley>
In-Reply-To: <CAMP44s1ZjtVdj1wys_7VkBrmvGAkh9cfOpZ_22aVONMH3GdcRg@mail.gmail.com>

From: "Felipe Contreras" <felipe.contreras@gmail.com>
Sent: Sunday, September 08, 2013 9:49 AM

Show 11 quoted lines

> On Sun, Sep 8, 2013 at 3:42 AM, Philip Oakley <philipoakley@iee.org> 
> wrote:
>
>> The 'problem' is (would be) that I don't yet know that I would need 
>> the
>> --onto pu until I discover (how?) that the default rebase would 
>> result in
>> conflicts.
>
> I don't see what that has to do with an invocation of 'git rebase'
> without arguments, and @{tail}.

>         There's absolutely no way Git can
> figure out for you which is the appropriate place for you to rebase
> onto.

.. which was my point. I may not have explained it that well.

Given that Git can't figure it out, we should stop trying in such cases.

>
> However, it shouldn't be too difficult to write a tool that checks
> multiple commits and tells you on top of which ones a rebase could
> work, but I don't think 'git rebase' is the right place.

That's an SOS approach (Success Oriented Script)[1] that presumes the user is already better than they are - The Kruger Dunning paper [2] offers some insight into capability misconceptions (at all levels).

-- regards

Philip -- [1] in the original it was a "Success Oriented Schedule" - one of those plans that hopeful managers put together on late running projects that amount to wishful thinking that hopefully garners them enough time to make a little progress and update their 'success stories'. [2] http://dx.doi.org/10.1111%2F1467-8721.01235 "Why People Fail to Recognize Their Own Incompetence". Though the corollaries (People fail to recognise their own skills, and hence they/we mishandle our communications) are just as (IMHO more) important.