Re: [PATCH 2/2] gittutorial: wrap literal examples in backticks

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Martin Ågren <martin.agren@xxxxxxxxx> writes:

> Our coding guidelines prefer literal examples to be wrapped in
> `backticks` to typeset them in monospace.

True.

Everything I saw in this patch looked reasonable.  Except for one
minor thing that I found a bit iffy.

>  ------------------------------------------------
>  alice$ cd /home/alice/project
>  alice$ git pull /home/bob/myrepo master
>  ------------------------------------------------
>  
> -This merges the changes from Bob's "master" branch into Alice's
> +This merges the changes from Bob's `master` branch into Alice's
>  current branch.  If Alice has made her own changes in the meantime,
>  then she may need to manually fix any conflicts.
>  
> -The "pull" command thus performs two operations: it fetches changes
> +The `pull` command thus performs two operations: it fetches changes
>  from a remote branch, then merges them into the current branch.

We use the name of an operation (e.g. "pull", "fetch", ...)  to
refer to a specific command name and also as a general concept.  The
former should be in `pair of backticks`, but not the latter.
Unfortunately, there is no bright line between the two.

It is OK to say that this "pull" refers to the command line we see
above, i.e. "git pull", but ...

>  Note that in general, Alice would want her local changes committed before
> -initiating this "pull".  If Bob's work conflicts with what Alice did since
> +initiating this `pull`.  If Bob's work conflicts with what Alice did since

... it is unclear if this one should be taken as a "literal
example".  It may flow more naturally if we take it as the name of
general concept of one operation, as ...

>  their histories forked, Alice will use her working tree and the index to
>  resolve conflicts, and existing local changes will interfere with the
>  conflict resolution process (Git will still perform the fetch but will
>  refuse to merge -- Alice will have to get rid of her local changes in

... it contrasts with the "fetch" operation and the "merge"
operation referred to here a bit better, it seems.  The same for the
reference of `fetch` in the next paragraph.

>  some way and pull again when this happens).
>  
> -Alice can peek at what Bob did without merging first, using the "fetch"
> +Alice can peek at what Bob did without merging first, using the `fetch`
>  command; this allows Alice to inspect what Bob did, using a special
> -symbol "FETCH_HEAD", in order to determine if he has anything worth
> +symbol `FETCH_HEAD`, in order to determine if he has anything worth
>  pulling, like this:

But as I said, it is quite minor and I am not even convinced it is
wrong, so let's take the whole thing as is and merge it down.

Thanks.



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux