Subject: Re: [PATCH] Attempt to make git-checkout man page a bit more clear.

From: Junio C Hamano <[email-masked]>
Date: Wed, 20 Dec 2006 23:47:42 -0800

Sean <[email-masked]> 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_.