Re: [PATCH 3/3] builtin/checkout: DWIM with -f -b

Jeff King [off-list ref] writes:

I am not sure it is fixing a bug. There are really two possible things
to be forced during checkout:

  1. throw away local changes

  2. overwrite an existing branch

Right now, "checkout -f" means just (1). This patch makes it _also_ mean
(2). Do we want to conflate those two cases?

In some sense, it is reasonable for "-f" to mean "force anything that
might be questionable". But I wonder if it pays to be a little more
conservative given that this is a safety valve we are talking about. The
user can of course still split their compound action into:

  git branch [-f] new_branch old_branch
  git checkout [-f] new_branch

Less convenient, but there is no ambiguity.

I dunno. I don't have a strong feeling on how it should be, but I think
it is more than a simple bug fix.

Ok, fair enough.

FWIW, I often end up doing this when rebuilding 'pu' (and 'jch' that is
used internally that keeps a version of 'next' with cleaner history).

    ... a script to regenerate jch on top of master (and pu on jch)
    $ Meta/Reintegrate master..jch >Meta/redo-jch.sh
    $ Meta/Reintegrate jch..pu >Meta/redo-pu.sh

    ... rewind and rebuild jch on top of updated master
    $ git checkout -f -b jch master
    ... error ... oops
    $ git branch -f jch master
    $ git checkout jch
    $ Meta/redo-jch.sh
    $ git diff next
    ... no output---good.

    $ git checkout -f -b pu jch
    ... error ... oops
    $ git branch -f pu jch
    $ git checkout pu
    $ Meta/redo-pu.sh