git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Andrew Ardill <andrew.ardill@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Philip Oakley <philipoakley@iee.org>,
	Chris Rorvick <chris@rorvick.com>, Git List <git@vger.kernel.org>,
	Tomas Carnecky <tomas.carnecky@gmail.com>,
	Woody Wu <narkewoody@gmail.com>
Subject: Re: [PATCH 1/2] Documentation/git-checkout.txt: clarify usage
Date: Tue, 18 Dec 2012 12:29:28 +1100	[thread overview]
Message-ID: <CAH5451kpNYqJ99Lepjyq8-KEM1D3zeao1gSx05Q7LWWdE_=8jw@mail.gmail.com> (raw)
In-Reply-To: <7vobhsjq6a.fsf@alter.siamese.dyndns.org>

On 18 December 2012 08:59, Junio C Hamano <gitster@pobox.com> wrote:
> Andrew Ardill <andrew.ardill@gmail.com> writes:
>> Even if the primary purpose of "git checkout <branch>" is to "check
>> out the branch so that further work is done on that branch", I don't
>> believe that means it has to be stated first. In fact, I would say
>> that there are enough other use cases that the language should be
>> slightly more use-case agnostic in the first situation. For example,
>> someone might switch to another branch or commit simply to see what
>> state the tree was in at that point.
>
> I've been deliberately avoiding the term "switch", actually.  I
> agree that it may be familiar to people with prior exposure to
> subversion, but that is not the primary audience of the manual.

I don't have much experience with svn, so I didn't make that
connection. Independent of svn usage, what is wrong with the term
'switch'?

I would be interested to hear how translators communicate the checkout
concept, as I assume the word checkout doesn't exist in many
languages. For me, switching between revisions is a natural way of
phrasing the action, but perhaps there is a better way of saying the
same thing?

>> Some people use checkout to
>> deploy a tag of the working tree onto a production server. The first
>> example in particular is, I think, a common enough operation that
>> restricting the opening lines of documentation to talking about
>> building further work is misleading.
>
> I agree with you that sightseeing use case where you do not intend
> to make any commit is also important.  That is exactly why I said
> "further work is done on that branch" not "to that branch" in the
> message you are responding to.

Ah ok, I didn't pick up on that nuance. Your suggestion from earlier
has, for example, "Prepare to work on building new history on
<branch>" which *is* excluding that use case. Perhaps modifying
similar lines to something like "Prepare to work with the
repository/history/something from <branch>" or maybe just "Prepare to
work with <branch>" would better encapsulate those use cases.
Following lines would expand on what it means to work with a branch or
commit, and the technical details of updates to the repositories
current state.

Regards,

Andrew Ardill

  reply	other threads:[~2012-12-18  1:35 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-17  6:45 [PATCH 0/2] Documentation: clarify usage of checkout Chris Rorvick
2012-12-17  6:45 ` [PATCH 1/2] Documentation/git-checkout.txt: clarify usage Chris Rorvick
2012-12-17  7:21   ` Junio C Hamano
2012-12-17  8:20     ` Johannes Sixt
2012-12-17  8:48       ` Junio C Hamano
2012-12-17  8:59         ` Johannes Sixt
2012-12-17 19:12           ` Junio C Hamano
2012-12-17  8:53       ` Andrew Ardill
2012-12-18  2:55       ` Chris Rorvick
2012-12-17 20:51     ` Philip Oakley
2012-12-17 21:13       ` Junio C Hamano
2012-12-17 21:50         ` Andrew Ardill
2012-12-17 21:59           ` Junio C Hamano
2012-12-18  1:29             ` Andrew Ardill [this message]
2012-12-18  1:53             ` Junio C Hamano
2012-12-18  2:12               ` Andrew Ardill
2012-12-18  3:33               ` Chris Rorvick
2012-12-18 16:43                 ` Junio C Hamano
2012-12-17 22:40         ` Philip Oakley
2012-12-17  6:45 ` [PATCH 2/2] Documentation/git-checkout.txt: document 70c9ac2 behavior Chris Rorvick
2012-12-17  7:21   ` Junio C Hamano
2012-12-17  7:23     ` Andrew Ardill
2012-12-17  7:26       ` Junio C Hamano

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to='CAH5451kpNYqJ99Lepjyq8-KEM1D3zeao1gSx05Q7LWWdE_=8jw@mail.gmail.com' \
    --to=andrew.ardill@gmail.com \
    --cc=chris@rorvick.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=narkewoody@gmail.com \
    --cc=philipoakley@iee.org \
    --cc=tomas.carnecky@gmail.com \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).