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

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 20, 2010, 21:10 UTC
Message-ID: <7vpqzltnp3.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20100620201137.GA8502@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 22 quoted lines

> 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