Tay Ray Chuan <rctay89@xxxxxxxxx> writes:
>> 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.
--
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