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

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 21, 2010, 05:15 UTC
Message-ID: <7vpqzlrmo4.fsf@alter.siamese.dyndns.org>
In-Reply-To: <AANLkTik3QZBpOjwZHGwIXphXnaHLaBV4pUSb1OVAau9V@mail.gmail.com>

Tay Ray Chuan <rctay89@gmail.com> writes:

Show 11 quoted lines

>> Yes; I thought the implication of "-f" to be destructive would be a
>> justification enough, but I agree with you that conflating the two may be
>> a bad idea.  When a user says "git checkout -f -b jch" after seeing the
>> command without "-f" fail due to existing "jch", it is quite clear that
>> the user wants to clobber the history of existing "jch" branch (why else
>> would he giving "-f"), but it is not a justification to clobber local
>> changes he has in the index and the work tree.
>
> How about doing
>
>   git checkout -f -f -b <branch>

That is not the problem I want you to solve. What your patch does solves only half of my issue as Peff pointed out (it lets me reuse the name of the existing branch for an unrelated history, but it loses the local changes I may have in my working tree). IOW, I want to start <branch> from scratch, based on an half-done work I started from my current branch in my work tree.

That is what "git checkout -b <branch>" usually gives us, if the name <branch> is not in use.

I think you were suggesting not to nuke local change with a single -f only when -b is also in use, but I think that makes things even more confusing to the users. Sometimes a single -f discards local changes, but some other times you would need double -f. That will lead to insanity.

Perhaps we would want another option that is similar to -b but lets us discard the named branch if it exists. Let's call it tentatively -B.

 * git checkout -b <branch> [<start-point>]

   - starts a new branch <branch> at <start-point> commit;

   - attempts three-way merge to keep the local change forward while doing
     so, but aborts if it needs a real file-level merge;

   - complains and aborts if <branch> already exists.

   When -f is used, instead of attempting three-way merge to keep the local
   changes, it discards them.

   When -m is used, instead of failing when it needs a real file-level merge,
   it will attempt CVS/SVN "update" style merge (and can cause conflicts).

   When -B is used instead of -b, it does the three-way merge and the usual
   rejection upon a file-level merge unless -m is given.  If it can go ahead,
   but <branch> already exists, then the existing <branch> is discarded and
   replaced with the <start-point> commit.

Something like that would reduce the confusion factor and would help the "recreate an existing branch from scratch" (or "reuse the name of an existing branch") workflow a bit.