Jeff King <peff@xxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html