Documentation: more "git-" versus "git " changes
With git-commands moving out of $(bindir), it is useful to make a clearer distinction between the git subcommand 'git-whatever' and the command you type, `git whatever <options>`. So we use a dash after "git" when referring to the former and not the latter. I already sent a patch doing this same thing, but I missed some spots. Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
This commit is contained in:
Jonathan Nieder
Junio C Hamano
parent
7a7d4ef69c
commit
467c0197fd
@ -356,8 +356,8 @@ core.pager::
|
||||
|
||||
core.whitespace::
|
||||
A comma separated list of common whitespace problems to
|
||||
notice. `git diff` will use `color.diff.whitespace` to
|
||||
highlight them, and `git apply --whitespace=error` will
|
||||
notice. `git-diff` will use `color.diff.whitespace` to
|
||||
highlight them, and `git-apply --whitespace=error` will
|
||||
consider them as errors:
|
||||
+
|
||||
* `trailing-space` treats trailing whitespaces at the end of the line
|
||||
@ -426,20 +426,20 @@ branch.autosetuprebase::
|
||||
This option defaults to never.
|
||||
|
||||
branch.<name>.remote::
|
||||
When in branch <name>, it tells `git fetch` which remote to fetch.
|
||||
If this option is not given, `git fetch` defaults to remote "origin".
|
||||
When in branch <name>, it tells `git-fetch` which remote to fetch.
|
||||
If this option is not given, `git-fetch` defaults to remote "origin".
|
||||
|
||||
branch.<name>.merge::
|
||||
When in branch <name>, it tells `git fetch` the default
|
||||
When in branch <name>, it tells `git-fetch` the default
|
||||
refspec to be marked for merging in FETCH_HEAD. The value is
|
||||
handled like the remote part of a refspec, and must match a
|
||||
ref which is fetched from the remote given by
|
||||
"branch.<name>.remote".
|
||||
The merge information is used by `git pull` (which at first calls
|
||||
`git fetch`) to lookup the default branch for merging. Without
|
||||
this option, `git pull` defaults to merge the first refspec fetched.
|
||||
The merge information is used by `git-pull` (which at first calls
|
||||
`git-fetch`) to lookup the default branch for merging. Without
|
||||
this option, `git-pull` defaults to merge the first refspec fetched.
|
||||
Specify multiple values to get an octopus merge.
|
||||
If you wish to setup `git pull` so that it merges into <name> from
|
||||
If you wish to setup `git-pull` so that it merges into <name> from
|
||||
another branch in the local repository, you can point
|
||||
branch.<name>.merge to the desired branch, and use the special setting
|
||||
`.` (a period) for branch.<name>.remote.
|
||||
@ -508,12 +508,12 @@ color.diff.<slot>::
|
||||
|
||||
color.interactive::
|
||||
When set to `always`, always use colors for interactive prompts
|
||||
and displays (such as those used by "git add --interactive").
|
||||
and displays (such as those used by "git-add --interactive").
|
||||
When false (or `never`), never. When set to `true` or `auto`, use
|
||||
colors only when the output is to the terminal. Defaults to false.
|
||||
|
||||
color.interactive.<slot>::
|
||||
Use customized color for `git add --interactive`
|
||||
Use customized color for `git-add --interactive`
|
||||
output. `<slot>` may be `prompt`, `header`, or `help`, for
|
||||
three distinct types of normal output from interactive
|
||||
programs. The values of these variables may be specified as
|
||||
@ -550,14 +550,14 @@ color.ui::
|
||||
take precedence over this setting. Defaults to false.
|
||||
|
||||
diff.autorefreshindex::
|
||||
When using `git diff` to compare with work tree
|
||||
When using `git-diff` to compare with work tree
|
||||
files, do not consider stat-only change as changed.
|
||||
Instead, silently run `git update-index --refresh` to
|
||||
update the cached stat information for paths whose
|
||||
contents in the work tree match the contents in the
|
||||
index. This option defaults to true. Note that this
|
||||
affects only `git diff` Porcelain, and not lower level
|
||||
`diff` commands, such as `git diff-files`.
|
||||
affects only `git-diff` Porcelain, and not lower level
|
||||
`diff` commands, such as `git-diff-files`.
|
||||
|
||||
diff.external::
|
||||
If this config variable is set, diff generation is not
|
||||
@ -568,7 +568,7 @@ diff.external::
|
||||
|
||||
diff.renameLimit::
|
||||
The number of files to consider when performing the copy/rename
|
||||
detection; equivalent to the git diff option '-l'.
|
||||
detection; equivalent to the git-diff option '-l'.
|
||||
|
||||
diff.renames::
|
||||
Tells git to detect renames. If set to any boolean value, it
|
||||
@ -608,7 +608,7 @@ format.pretty::
|
||||
|
||||
gc.aggressiveWindow::
|
||||
The window size parameter used in the delta compression
|
||||
algorithm used by 'git gc --aggressive'. This defaults
|
||||
algorithm used by 'git-gc --aggressive'. This defaults
|
||||
to 10.
|
||||
|
||||
gc.auto::
|
||||
@ -625,37 +625,37 @@ gc.autopacklimit::
|
||||
default value is 50. Setting this to 0 disables it.
|
||||
|
||||
gc.packrefs::
|
||||
`git gc` does not run `git pack-refs` in a bare repository by
|
||||
`git-gc` does not run `git pack-refs` in a bare repository by
|
||||
default so that older dumb-transport clients can still fetch
|
||||
from the repository. Setting this to `true` lets `git gc`
|
||||
from the repository. Setting this to `true` lets `git-gc`
|
||||
to run `git pack-refs`. Setting this to `false` tells
|
||||
`git gc` never to run `git pack-refs`. The default setting is
|
||||
`git-gc` never to run `git pack-refs`. The default setting is
|
||||
`notbare`. Enable it only when you know you do not have to
|
||||
support such clients. The default setting will change to `true`
|
||||
at some stage, and setting this to `false` will continue to
|
||||
prevent `git pack-refs` from being run from `git gc`.
|
||||
prevent `git pack-refs` from being run from `git-gc`.
|
||||
|
||||
gc.pruneexpire::
|
||||
When `git gc` is run, it will call `prune --expire 2.weeks.ago`.
|
||||
When `git-gc` is run, it will call `prune --expire 2.weeks.ago`.
|
||||
Override the grace period with this config variable.
|
||||
|
||||
gc.reflogexpire::
|
||||
`git reflog expire` removes reflog entries older than
|
||||
`git-reflog expire` removes reflog entries older than
|
||||
this time; defaults to 90 days.
|
||||
|
||||
gc.reflogexpireunreachable::
|
||||
`git reflog expire` removes reflog entries older than
|
||||
`git-reflog expire` removes reflog entries older than
|
||||
this time and are not reachable from the current tip;
|
||||
defaults to 30 days.
|
||||
|
||||
gc.rerereresolved::
|
||||
Records of conflicted merge you resolved earlier are
|
||||
kept for this many days when `git rerere gc` is run.
|
||||
kept for this many days when `git-rerere gc` is run.
|
||||
The default is 60 days. See linkgit:git-rerere[1].
|
||||
|
||||
gc.rerereunresolved::
|
||||
Records of conflicted merge you have not resolved are
|
||||
kept for this many days when `git rerere gc` is run.
|
||||
kept for this many days when `git-rerere gc` is run.
|
||||
The default is 15 days. See linkgit:git-rerere[1].
|
||||
|
||||
rerere.enabled::
|
||||
@ -844,7 +844,7 @@ instaweb.port::
|
||||
|
||||
log.date::
|
||||
Set default date-time mode for the log command. Setting log.date
|
||||
value is similar to using git log's --date option. The value is one of
|
||||
value is similar to using git-log's --date option. The value is one of the
|
||||
following alternatives: {relative,local,default,iso,rfc,short}.
|
||||
See linkgit:git-log[1].
|
||||
|
||||
|
||||
@ -26,7 +26,7 @@ on the subcommand:
|
||||
git bisect log
|
||||
git bisect run <cmd>...
|
||||
|
||||
This command uses `git rev-list --bisect` to help drive the
|
||||
This command uses `git-rev-list --bisect` to help drive the
|
||||
binary search process to find which change introduced a bug, given an
|
||||
old "good" commit object name and a later "bad" commit object name.
|
||||
|
||||
@ -101,7 +101,7 @@ $ git bisect visualize
|
||||
to see the currently remaining suspects in `gitk`. `visualize` is a bit
|
||||
too long to type and `view` is provided as a synonym.
|
||||
|
||||
If `DISPLAY` environment variable is not set, `git log` is used
|
||||
If 'DISPLAY' environment variable is not set, `git-log` is used
|
||||
instead. You can even give command line options such as `-p` and
|
||||
`--stat`.
|
||||
|
||||
|
||||
@ -155,7 +155,7 @@ but can be used to amend a merge commit.
|
||||
Make a commit only from the paths specified on the
|
||||
command line, disregarding any contents that have been
|
||||
staged so far. This is the default mode of operation of
|
||||
'git commit' if any paths are given on the command line,
|
||||
'git-commit' if any paths are given on the command line,
|
||||
in which case this option can be omitted.
|
||||
If this option is specified together with '--amend', then
|
||||
no paths need be specified, which can be used to amend
|
||||
|
||||
@ -163,7 +163,7 @@ to other tags will be rewritten to point to the underlying commit.
|
||||
|
||||
-f::
|
||||
--force::
|
||||
`git filter-branch` refuses to start with an existing temporary
|
||||
`git-filter-branch` refuses to start with an existing temporary
|
||||
directory or when there are already refs starting with
|
||||
'refs/original/', unless forced.
|
||||
|
||||
|
||||
@ -190,7 +190,7 @@ EXAMPLES
|
||||
the current branch using `git-am` to cherry-pick them:
|
||||
+
|
||||
------------
|
||||
$ git format-patch -k --stdout R1..R2 | git-am -3 -k
|
||||
$ git format-patch -k --stdout R1..R2 | git am -3 -k
|
||||
------------
|
||||
|
||||
* Extract all commits which are in the current branch but not in the
|
||||
|
||||
@ -120,7 +120,7 @@ man.<tool>.path
|
||||
You can explicitly provide a full path to your preferred man viewer by
|
||||
setting the configuration variable 'man.<tool>.path'. For example, you
|
||||
can configure the absolute path to konqueror by setting
|
||||
'man.konqueror.path'. Otherwise, 'git help' assumes the tool is
|
||||
'man.konqueror.path'. Otherwise, 'git-help' assumes the tool is
|
||||
available in PATH.
|
||||
|
||||
man.<tool>.cmd
|
||||
|
||||
@ -259,10 +259,10 @@ NOTES
|
||||
When you rebase a branch, you are changing its history in a way that
|
||||
will cause problems for anyone who already has a copy of the branch
|
||||
in their repository and tries to pull updates from you. You should
|
||||
understand the implications of using 'git rebase' on a repository that
|
||||
understand the implications of using 'git-rebase' on a repository that
|
||||
you share.
|
||||
|
||||
When the git rebase command is run, it will first execute a "pre-rebase"
|
||||
When the git-rebase command is run, it will first execute a "pre-rebase"
|
||||
hook if one exists. You can use this hook to do sanity checks and
|
||||
reject the rebase if it isn't appropriate. Please see the template
|
||||
pre-rebase hook script for an example.
|
||||
|
||||
@ -60,7 +60,7 @@ OPTIONS
|
||||
refs.
|
||||
+
|
||||
This computation involves traversing all the reachable objects, i.e. it
|
||||
has the same cost as 'git prune'. Fortunately, once this is run, we
|
||||
has the same cost as 'git-prune'. Fortunately, once this is run, we
|
||||
should not have to ever worry about missing objects, because the current
|
||||
prune and pack-objects know about reflogs and protect objects referred by
|
||||
them.
|
||||
|
||||
@ -124,7 +124,7 @@ $ git checkout -b nfs linux-nfs/master
|
||||
...
|
||||
------------
|
||||
|
||||
* Imitate 'git clone' but track only selected branches
|
||||
* Imitate 'git-clone' but track only selected branches
|
||||
+
|
||||
------------
|
||||
$ mkdir project.git
|
||||
|
||||
@ -163,7 +163,7 @@ If this three-way merge resolves cleanly, the result is written
|
||||
out to your working tree file, so you would not have to manually
|
||||
resolve it. Note that `git-rerere` leaves the index file alone,
|
||||
so you still need to do the final sanity checks with `git diff`
|
||||
(or `git diff -c`) and `git add` when you are satisfied.
|
||||
(or `git diff -c`) and `git-add` when you are satisfied.
|
||||
|
||||
As a convenience measure, `git-merge` automatically invokes
|
||||
`git-rerere` when it exits with a failed automerge, which
|
||||
|
||||
@ -3,7 +3,7 @@ git-shortlog(1)
|
||||
|
||||
NAME
|
||||
----
|
||||
git-shortlog - Summarize 'git log' output
|
||||
git-shortlog - Summarize 'git-log' output
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
|
||||
@ -595,7 +595,7 @@ pointer to the state you want to tag, but also a small tag name and
|
||||
message, along with optionally a PGP signature that says that yes,
|
||||
you really did
|
||||
that tag. You create these annotated tags with either the `-a` or
|
||||
`-s` flag to `git tag`:
|
||||
`-s` flag to `git-tag`:
|
||||
|
||||
----------------
|
||||
$ git tag -s <tagname>
|
||||
@ -642,7 +642,7 @@ and it will be gone. There's no external repository, and there's no
|
||||
history outside the project you created.
|
||||
|
||||
- if you want to move or duplicate a git repository, you can do so. There
|
||||
is `git clone` command, but if all you want to do is just to
|
||||
is `git-clone` command, but if all you want to do is just to
|
||||
create a copy of your repository (with all the full history that
|
||||
went along with it), you can do so with a regular
|
||||
`cp -a git-tutorial new-git-tutorial`.
|
||||
@ -776,7 +776,7 @@ to it.
|
||||
================================================
|
||||
If you make the decision to start your new branch at some
|
||||
other point in the history than the current `HEAD`, you can do so by
|
||||
just telling `git checkout` what the base of the checkout would be.
|
||||
just telling `git-checkout` what the base of the checkout would be.
|
||||
In other words, if you have an earlier tag or branch, you'd just do
|
||||
|
||||
------------
|
||||
@ -819,7 +819,7 @@ $ git branch <branchname> [startingpoint]
|
||||
|
||||
which will simply _create_ the branch, but will not do anything further.
|
||||
You can then later -- once you decide that you want to actually develop
|
||||
on that branch -- switch to that branch with a regular `git checkout`
|
||||
on that branch -- switch to that branch with a regular `git-checkout`
|
||||
with the branchname as the argument.
|
||||
|
||||
|
||||
@ -881,7 +881,7 @@ source.
|
||||
Anyway, let's exit `gitk` (`^Q` or the File menu), and decide that we want
|
||||
to merge the work we did on the `mybranch` branch into the `master`
|
||||
branch (which is currently our `HEAD` too). To do that, there's a nice
|
||||
script called `git merge`, which wants to know which branches you want
|
||||
script called `git-merge`, which wants to know which branches you want
|
||||
to resolve and what the merge is all about:
|
||||
|
||||
------------
|
||||
@ -1023,12 +1023,12 @@ Merging external work
|
||||
It's usually much more common that you merge with somebody else than
|
||||
merging with your own branches, so it's worth pointing out that git
|
||||
makes that very easy too, and in fact, it's not that different from
|
||||
doing a `git merge`. In fact, a remote merge ends up being nothing
|
||||
doing a `git-merge`. In fact, a remote merge ends up being nothing
|
||||
more than "fetch the work from a remote repository into a temporary tag"
|
||||
followed by a `git merge`.
|
||||
followed by a `git-merge`.
|
||||
|
||||
Fetching from a remote repository is done by, unsurprisingly,
|
||||
`git fetch`:
|
||||
`git-fetch`:
|
||||
|
||||
----------------
|
||||
$ git fetch <remote-repository>
|
||||
@ -1115,7 +1115,7 @@ argument.
|
||||
[NOTE]
|
||||
You could do without using any branches at all, by
|
||||
keeping as many local repositories as you would like to have
|
||||
branches, and merging between them with `git pull`, just like
|
||||
branches, and merging between them with `git-pull`, just like
|
||||
you merge between branches. The advantage of this approach is
|
||||
that it lets you keep a set of files for each `branch` checked
|
||||
out and you may find it easier to switch back and forth if you
|
||||
@ -1132,7 +1132,7 @@ like this:
|
||||
$ git config remote.linus.url http://www.kernel.org/pub/scm/git/git.git/
|
||||
------------------------------------------------
|
||||
|
||||
and use the "linus" keyword with `git pull` instead of the full URL.
|
||||
and use the "linus" keyword with `git-pull` instead of the full URL.
|
||||
|
||||
Examples.
|
||||
|
||||
@ -1168,7 +1168,7 @@ $ git show-branch --more=2 master mybranch
|
||||
+* [master^] Some fun.
|
||||
------------
|
||||
|
||||
Remember, before running `git merge`, our `master` head was at
|
||||
Remember, before running `git-merge`, our `master` head was at
|
||||
"Some fun." commit, while our `mybranch` head was at "Some
|
||||
work." commit.
|
||||
|
||||
@ -1345,7 +1345,7 @@ $ mkdir my-git.git
|
||||
------------
|
||||
|
||||
Then, make that directory into a git repository by running
|
||||
`git init`, but this time, since its name is not the usual
|
||||
`git-init`, but this time, since its name is not the usual
|
||||
`.git`, we do things slightly differently:
|
||||
|
||||
------------
|
||||
@ -1407,7 +1407,7 @@ $ git repack
|
||||
|
||||
will do it for you. If you followed the tutorial examples, you
|
||||
would have accumulated about 17 objects in `.git/objects/??/`
|
||||
directories by now. `git repack` tells you how many objects it
|
||||
directories by now. `git-repack` tells you how many objects it
|
||||
packed, and stores the packed file in `.git/objects/pack`
|
||||
directory.
|
||||
|
||||
@ -1656,8 +1656,8 @@ $ git reset --hard master~2
|
||||
------------
|
||||
|
||||
You can make sure 'git show-branch' matches the state before
|
||||
those two 'git merge' you just did. Then, instead of running
|
||||
two 'git merge' commands in a row, you would merge these two
|
||||
those two 'git-merge' you just did. Then, instead of running
|
||||
two 'git-merge' commands in a row, you would merge these two
|
||||
branch heads (this is known as 'making an Octopus'):
|
||||
|
||||
------------
|
||||
|
||||
@ -1963,10 +1963,10 @@ error: failed to push to 'ssh://yourserver.com/~you/proj.git'
|
||||
|
||||
This can happen, for example, if you:
|
||||
|
||||
- use `git reset --hard` to remove already-published commits, or
|
||||
- use `git commit --amend` to replace already-published commits
|
||||
- use `git-reset --hard` to remove already-published commits, or
|
||||
- use `git-commit --amend` to replace already-published commits
|
||||
(as in <<fixing-a-mistake-by-rewriting-history>>), or
|
||||
- use `git rebase` to rebase any already-published commits (as
|
||||
- use `git-rebase` to rebase any already-published commits (as
|
||||
in <<using-git-rebase>>).
|
||||
|
||||
You may force git-push to perform the update anyway by preceding the
|
||||
@ -2170,7 +2170,7 @@ they are for, or what status they are in. To get a reminder of what
|
||||
changes are in a specific branch, use:
|
||||
|
||||
-------------------------------------------------
|
||||
$ git log linux..branchname | git-shortlog
|
||||
$ git log linux..branchname | git shortlog
|
||||
-------------------------------------------------
|
||||
|
||||
To see whether it has already been merged into the test or release branches,
|
||||
@ -2443,7 +2443,7 @@ patches to the new mywork. The result will look like:
|
||||
................................................
|
||||
|
||||
In the process, it may discover conflicts. In that case it will stop
|
||||
and allow you to fix the conflicts; after fixing conflicts, use "git add"
|
||||
and allow you to fix the conflicts; after fixing conflicts, use "git-add"
|
||||
to update the index with those contents, and then, instead of
|
||||
running git-commit, just run
|
||||
|
||||
@ -2700,7 +2700,7 @@ master branch. In more detail:
|
||||
git fetch and fast-forwards
|
||||
---------------------------
|
||||
|
||||
In the previous example, when updating an existing branch, "git fetch"
|
||||
In the previous example, when updating an existing branch, "git-fetch"
|
||||
checks to make sure that the most recent commit on the remote
|
||||
branch is a descendant of the most recent commit on your copy of the
|
||||
branch before updating your copy of the branch to point at the new
|
||||
@ -2726,7 +2726,7 @@ resulting in a situation like:
|
||||
o--o--o <-- new head of the branch
|
||||
................................................
|
||||
|
||||
In this case, "git fetch" will fail, and print out a warning.
|
||||
In this case, "git-fetch" will fail, and print out a warning.
|
||||
|
||||
In that case, you can still force git to update to the new head, as
|
||||
described in the following section. However, note that in the
|
||||
@ -3106,7 +3106,7 @@ $ git prune
|
||||
|
||||
to remove any of the "loose" objects that are now contained in the
|
||||
pack. This will also remove any unreferenced objects (which may be
|
||||
created when, for example, you use "git reset" to remove a commit).
|
||||
created when, for example, you use "git-reset" to remove a commit).
|
||||
You can verify that the loose objects are gone by looking at the
|
||||
.git/objects directory or by running
|
||||
|
||||
@ -3135,7 +3135,7 @@ branch still exists, as does everything it pointed to. The branch
|
||||
pointer itself just doesn't, since you replaced it with another one.
|
||||
|
||||
There are also other situations that cause dangling objects. For
|
||||
example, a "dangling blob" may arise because you did a "git add" of a
|
||||
example, a "dangling blob" may arise because you did a "git-add" of a
|
||||
file, but then, before you actually committed it and made it part of the
|
||||
bigger picture, you changed something else in that file and committed
|
||||
that *updated* thing--the old state that you added originally ends up
|
||||
@ -3185,7 +3185,7 @@ Usually, dangling blobs and trees aren't very interesting. They're
|
||||
almost always the result of either being a half-way mergebase (the blob
|
||||
will often even have the conflict markers from a merge in it, if you
|
||||
have had conflicting merges that you fixed up by hand), or simply
|
||||
because you interrupted a "git fetch" with ^C or something like that,
|
||||
because you interrupted a "git-fetch" with ^C or something like that,
|
||||
leaving _some_ of the new objects in the object database, but just
|
||||
dangling and useless.
|
||||
|
||||
@ -3694,7 +3694,7 @@ removed. The only thing `--remove` means is that update-index will be
|
||||
considering a removed file to be a valid thing, and if the file really
|
||||
does not exist any more, it will update the index accordingly.
|
||||
|
||||
As a special case, you can also do `git-update-index --refresh`, which
|
||||
As a special case, you can also do `git update-index --refresh`, which
|
||||
will refresh the "stat" information of each index to match the current
|
||||
stat information. It will 'not' update the object status itself, and
|
||||
it will only update the fields that are used to quickly test whether
|
||||
@ -3770,7 +3770,7 @@ from one representation to the other:
|
||||
Tying it all together
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
To commit a tree you have instantiated with "git-write-tree", you'd
|
||||
To commit a tree you have instantiated with "git write-tree", you'd
|
||||
create a "commit" object that refers to that tree and the history
|
||||
behind it--most notably the "parent" commits that preceded it in
|
||||
history.
|
||||
@ -3927,7 +3927,7 @@ $ git read-tree -m -u <origtree> <yourtree> <targettree>
|
||||
|
||||
which will do all trivial merge operations for you directly in the
|
||||
index file, and you can just write the result out with
|
||||
`git-write-tree`.
|
||||
`git write-tree`.
|
||||
|
||||
|
||||
[[merging-multiple-trees-2]]
|
||||
@ -4095,7 +4095,7 @@ functions like `get_sha1_basic()` or the likes.
|
||||
This is just to get you into the groove for the most libified part of Git:
|
||||
the revision walker.
|
||||
|
||||
Basically, the initial version of `git log` was a shell script:
|
||||
Basically, the initial version of `git-log` was a shell script:
|
||||
|
||||
----------------------------------------------------------------
|
||||
$ git-rev-list --pretty $(git-rev-parse --default HEAD "$@") | \
|
||||
@ -4130,7 +4130,7 @@ just have a look at the first implementation of `cmd_log()`; call
|
||||
`git show v1.3.0{tilde}155^2{tilde}4` and scroll down to that function (note that you
|
||||
no longer need to call `setup_pager()` directly).
|
||||
|
||||
Nowadays, `git log` is a builtin, which means that it is _contained_ in the
|
||||
Nowadays, `git-log` is a builtin, which means that it is _contained_ in the
|
||||
command `git`. The source side of a builtin is
|
||||
|
||||
- a function called `cmd_<bla>`, typically defined in `builtin-<bla>.c`,
|
||||
@ -4146,7 +4146,7 @@ since they share quite a bit of code. In that case, the commands which are
|
||||
_not_ named like the `.c` file in which they live have to be listed in
|
||||
`BUILT_INS` in the `Makefile`.
|
||||
|
||||
`git log` looks more complicated in C than it does in the original script,
|
||||
`git-log` looks more complicated in C than it does in the original script,
|
||||
but that allows for a much greater flexibility and performance.
|
||||
|
||||
Here again it is a good point to take a pause.
|
||||
@ -4157,9 +4157,9 @@ the organization of Git (after you know the basic concepts).
|
||||
So, think about something which you are interested in, say, "how can I
|
||||
access a blob just knowing the object name of it?". The first step is to
|
||||
find a Git command with which you can do it. In this example, it is either
|
||||
`git show` or `git cat-file`.
|
||||
`git-show` or `git-cat-file`.
|
||||
|
||||
For the sake of clarity, let's stay with `git cat-file`, because it
|
||||
For the sake of clarity, let's stay with `git-cat-file`, because it
|
||||
|
||||
- is plumbing, and
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user