From: "Felipe Contreras" <felipe.contre...@gmail.com>
Sent: Sunday, September 08, 2013 9:49 AM
On Sun, Sep 8, 2013 at 3:42 AM, Philip Oakley <philipoak...@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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
