rebase: confusing behaviour since --fork-point

Hi all,

This will be a bit long, sorry in advance.

I've hit a problem with how rebase works since the introduction of the --fork-point option. I initially thought it was a bug until the kind folks over at git-for-windows patiently told me otherwise.

Consider the following:

-------8<------- # On branch master which is at origin/master # hack hack hack

git commit -am'First topic commit' # optionally followed by more commits

# realize I want all this on a different branch instead # (maybe I just forgot to create one; would be typical)

git checkout -b topic --track git branch -f master origin/master

# optionally add more commits to 'topic' and/or update 'master' # with changes to 'origin/master', then finally:

git rebase # or git pull --rebase ------->8-------

What happens is that 'First topic commit' is discarded because rebase, with this syntax, defaults to --fork-point, which then works out from master's reflog that the commit in question was previously part of the upstream branch. The rebase is then carried out under the assumption that, even though that specific commit is no longer in master, something equivalent to it or superseding it is, or else it is meant to be dropped - which would likely be the case if a complicated history rewrite happened, but is not the case here.

There are two reasons why I think this is confusing and should be changed:

(1) My mental model of git after some 5 years of using it is such that
    I view the reflog as auxiliary information for purposes of mining
    history or recovering from mistakes, and I rely only on the
    contents and parent-child relationships of commits to work out what
    a command I'm about to run will do. I would expect the vast
    majority of users to have a similar mental model, in which case the
    fact that the same commits can be rebased differently depending on
    the data in the reflog will be equally confusing to those users.

(2) Most people don't like to rebase too often, consequently the time
    elapsed from a user creating the topic branch and resetting its
    upstream until actually rebasing it can be days or weeks, by the
    end of which they are unlikely to remember the circumstances of
    creating the branch. Even more alarmingly, they may have committed
    dozens of further changes, and therefore may not even notice that
    the first few of those silently disappeared. (I'm not making this
    up: see discussion links below in PS.)

I believe the correct design would be to always make --no-fork-point
the default for rebase, and only use --fork-point when explicitly
specified. This would potentially be inconvenient for those who rebase
on top of complicated history rewrites, but said inconvenience would be
mitigated by several factors:
- Anyone doing rebases like that will already know that they can go
  wrong in a million ways.
- Perhaps more crucially, they will have a way of noticing if it went
  wrong, with all relevant information in short-term memory, so would
  recover easily.
- If the rebase turns out to be really complex, they are likely to
  resort to rebase -i, which shows full details of what is about to
  happen, moreover it seems relatively simple to enhance the contents
  of the rebase-todo file so that full information about the merge-base
  and fork-point is readily available.

If changing the default is not an option, e.g. because of backwards compatibility concerns, then some configurability could still be helpful, e.g. rebase.useForkPoint = never / auto / always (default auto, to keep the current behaviour). Although I suspect this would just lead to everyone suggesting setting this to 'never'. In any case this would provide a way to ensure that any git newbies in my organization don't spend days trying to figure this out like I've just done.

Assuming there is agreement to do one of the above (I don't even know whose agreement is required), what's the process for getting it implemented? Sorry, that probably counts as a dumb question, but I've never been around open-source projects much & need someone to show me the ropes.

Many thanks Laszlo

PS. Further reading about the same topic if anyone is interested:
- http://marc.info/?l=git&m=140991293402880&w=2 (from this same mailing
  list 2+ years ago, but I can see no clear conclusion)
- https://github.com/git-for-windows/git/issues/1076 (my bug report
  where contacting this list was suggested)
- http://stackoverflow.com/questions/22790765 and
  http://stackoverflow.com/questions/35320740 (various SO users being
  confused and asking about / discussing the same thing)