git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Andres G. Aragoneses" <knocte@gmail.com>
To: git@vger.kernel.org
Subject: Re: [PATCH v2] git-checkout.txt: Document "git checkout <pathspec>" better
Date: Wed, 17 Jun 2015 19:53:06 +0200	[thread overview]
Message-ID: <mlsc62$8u5$1@ger.gmane.org> (raw)
In-Reply-To: <vpqh9q6gsdt.fsf@anie.imag.fr>

On 17/06/15 19:24, Matthieu Moy wrote:
> Torsten Bögershausen <tboegi@web.de> writes:
>
>> My v3 will probably use the original line:
>> git-checkout - Checkout a branch or paths to the working tree
>
> I think mentionning "Switch branch" was a real improvement. For someone
> not familiar with the version control vocabulary, "checkout" does not
> mean much (just looked in a dictionary, it talks about payment and
> leaving a room in a hotel ...). And someone not understanding what
> "checkout" means in this context won't be helped much reading the
> description and getting "checkout" there.
>
> (Ironically, Junio did almost the same remark when I proposed to
> document "git describe" as "Describe ...", but the word "describe" does
> not have the ambiguity problem that "checkout" has)
>
>> 'git checkout <commit> -- <path>'
>> will "copy" the version from another commit into the workspace.
>
> If <commit> exists, it means that the state of this path existed
> somewhere in <path> in the past (well, modulo "git add -p" and other
> ways to cheat with history).
>
> So, to me, "restore a previous version" does apply in this case. Perhaps
> "restore a recorded state into the worktree" (my favorite up to now I
> think).
>
> But as you say, it copies into the workspace, so "copy a previous
> version into the workspace" sounds good to me.
>
> Basically, I'm fine with anything starting with "Switch branches or",
> but please do change the headline ;-).
>

Having read all this thread, I think it's really confusing that:
1) We have this command named "checkout", as Matthieu points out.
2) This command allows different distinct operations (one for when it 
receives a path, other for when it receives a branch, other for when it 
receives a commit...).

So what I would propose is fix the root of the problem: split these 
command in several ones, and mark the "checkout" command as deprecated 
(it would still allow the same functions as before, but it would not be 
documented, and would be announced as deprecated when used).

So then we could have a "git switch <branchname>" for switching to a 
different branch.

Also a "git discard <path>" to discard local changes.

Etcetera.

Comments?

  reply	other threads:[~2015-06-17 17:53 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-17  7:54 [PATCH v2] git-checkout.txt: Document "git checkout <pathspec>" better Torsten Bögershausen
2015-06-17  9:58 ` Duy Nguyen
2015-06-17 10:54   ` Matthieu Moy
2015-06-17 11:47     ` Andres G. Aragoneses
2015-06-17 11:54       ` Matthieu Moy
2015-06-17 11:56         ` Andres G. Aragoneses
2015-06-17 12:17           ` Matthieu Moy
2015-06-17 15:29             ` Junio C Hamano
2015-06-17 16:12               ` Torsten Bögershausen
2015-06-17 16:19               ` Junio C Hamano
2015-06-17 16:43                 ` Torsten Bögershausen
2015-06-17 17:24                   ` Matthieu Moy
2015-06-17 17:53                     ` Andres G. Aragoneses [this message]
2015-06-17 19:24                       ` Junio C Hamano
2015-06-17 19:23                     ` Junio C Hamano
2015-06-17 19:29                       ` Torsten Bögershausen
2015-06-17 19:58                         ` Junio C Hamano
2015-06-18  0:37                           ` Duy Nguyen
2015-06-18  1:07                             ` Junio C Hamano
2015-06-18  7:00                       ` Matthieu Moy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='mlsc62$8u5$1@ger.gmane.org' \
    --to=knocte@gmail.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).