Sean <seanlkml@xxxxxxxxxxxx> writes:
> diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
> index fbdbadc..97c3afe 100644
> --- a/Documentation/git-checkout.txt
> +++ b/Documentation/git-checkout.txt
> @@ -8,23 +8,29 @@ git-checkout - Checkout and switch to a branch
> SYNOPSIS
> --------
> [verse]
> +'git-checkout' [-f] [-m] <branch>
> +'git-checkout' [-f] [-b <new_branch> [-l]] [-m] [<commit-ish>]
> 'git-checkout' [-m] [<branch>] <paths>...
>
> DESCRIPTION
> -----------
> ...
> +With the third form, this command does *not* switch branches.
> +Instead, it replaces the contents of the named paths in your
> +working tree from the index. Here, the <branch> argument can be
> used to specify a specific tree-ish to update the index for the
> given paths before updating the working tree.
The 'restore from arbitrary tree-ish' form does not take -m as
far as I know.
Although it might be interesting to do a single-file three-way
merge, I do not think the command is _checkout_ anymore once it
starts doing that.
That is:
$ git checkout -f master
$ edit file.c
$ git that-funny-command next file.c
would steal the version of file.c from 'next', and merge the
change your locally did on top of 'master', and put it in your
working tree and in the index. Technically I can explain how
that work (and how it could be implemented -- which is trivial),
but I cannot explain what that operation _means_.
-
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