This is to resolve conflicts early in preparation for possible
inclusion of "reflog on detached HEAD" series by Nico, as having
it in 1.5.0 would really help us remove confusion between
detached and attached states.
Signed-off-by: Junio C Hamano <junkio@cox.net>
@ -39,7 +39,7 @@ in the section header, like in example below:
@@ -39,7 +39,7 @@ in the section header, like in example below:
Subsection names can contain any characters except newline (doublequote
'`"`' and backslash have to be escaped as '`\"`' and '`\\`',
respecitvely) and are case sensitive. Section header cannot span multiple
respectively) and are case sensitive. Section header cannot span multiple
lines. Variables may belong directly to a section or to a given subsection.
You can have `[section]` if you have `[section "subsection"]`, but you
don't need to.
@ -62,7 +62,7 @@ The values following the equals sign in variable assign are all either
@@ -62,7 +62,7 @@ The values following the equals sign in variable assign are all either
a string, an integer, or a boolean. Boolean values may be given as yes/no,
0/1 or true/false. Case is not significant in boolean values, when
converting value to the canonical form using '--bool' type specifier;
`git-repo-config` will ensure that the output is "true" or "false".
`git-config` will ensure that the output is "true" or "false".
String values may be entirely or partially enclosed in double quotes.
You need to enclose variable value in double quotes if you want to
@ -624,7 +624,7 @@ name for the state at that point.
@@ -624,7 +624,7 @@ name for the state at that point.
Copying repositories
--------------------
git repositories are normally totally self-sufficient and relocatable
git repositories are normally totally self-sufficient and relocatable.
Unlike CVS, for example, there is no separate notion of
"repository" and "working tree". A git repository normally *is* the
working tree, with the local git information hidden in the `.git`
@ -1118,7 +1118,7 @@ You could do without using any branches at all, by
@@ -1118,7 +1118,7 @@ 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
you merge between branches. The advantage of this approach is
that it lets you keep set of files for each `branch` checked
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
juggle multiple lines of development simultaneously. Of
course, you will pay the price of more disk usage to hold
@ -1130,7 +1130,7 @@ the remote repository URL in the local repository's config file
@@ -1130,7 +1130,7 @@ the remote repository URL in the local repository's config file
@ -8,7 +8,7 @@ git-blame - Show what revision and author last modified each line of a file
@@ -8,7 +8,7 @@ git-blame - Show what revision and author last modified each line of a file
@ -8,132 +8,10 @@ git-fsck-objects - Verifies the connectivity and validity of the objects in the
@@ -8,132 +8,10 @@ git-fsck-objects - Verifies the connectivity and validity of the objects in the
@ -21,7 +21,7 @@ given will be ignored when checking which packs are required. This makes the
@@ -21,7 +21,7 @@ given will be ignored when checking which packs are required. This makes the
following command useful when wanting to remove packs which contain unreachable
@ -8,220 +8,11 @@ git-repo-config - Get and set repository or global options
@@ -8,220 +8,11 @@ git-repo-config - Get and set repository or global options
SYNOPSIS
--------
[verse]
'git-repo-config' [--global] [type] name [value [value_regex]]
'git-repo-config' [--global] [type] --add name value
'git-repo-config' [--global] [type] --replace-all name [value [value_regex]]
'git-repo-config' [--global] [type] --get name [value_regex]
'git-repo-config' [--global] [type] --get-all name [value_regex]
'git-repo-config' [--global] [type] --unset name [value_regex]
'git-repo-config' [--global] [type] --unset-all name [value_regex]
'git-repo-config' [--global] -l | --list
'git-repo-config' ...
DESCRIPTION
-----------
You can query/set/replace/unset options with this command. The name is
actually the section and the key separated by a dot, and the value will be
escaped.
Multiple lines can be added to an option by using the '--add' option.
If you want to update or unset an option which can occur on multiple
lines, a POSIX regexp `value_regex` needs to be given. Only the
existing values that match the regexp are updated or unset. If
you want to handle the lines that do *not* match the regex, just
prepend a single exclamation mark in front (see EXAMPLES).
The type specifier can be either '--int' or '--bool', which will make
'git-repo-config' ensure that the variable(s) are of the given type and
convert the value to the canonical form (simple decimal number for int,
a "true" or "false" string for bool). If no type specifier is passed,
no checks or transformations are performed on the value.
This command will fail if:
. The .git/config file is invalid,
. Can not write to .git/config,
. no section was provided,
. the section or key is invalid,
. you try to unset an option which does not exist,
. you try to unset/set an option for which multiple lines match, or
. you use --global option without $HOME being properly set.
OPTIONS
-------
--replace-all::
Default behavior is to replace at most one line. This replaces
all lines matching the key (and optionally the value_regex).
--add::
Adds a new line to the option without altering any existing
values. This is the same as providing '^$' as the value_regex.
--get::
Get the value for a given key (optionally filtered by a regex
matching the value). Returns error code 1 if the key was not
found and error code 2 if multiple key values were found.
--get-all::
Like get, but does not fail if the number of values for the key
is not exactly one.
--get-regexp::
Like --get-all, but interprets the name as a regular expression.
--global::
Use global ~/.gitconfig file rather than the repository .git/config.
--unset::
Remove the line matching the key from config file.
--unset-all::
Remove all matching lines from config file.
-l, --list::
List all variables set in config file.
--bool::
git-repo-config will ensure that the output is "true" or "false"
--int::
git-repo-config will ensure that the output is a simple
decimal number. An optional value suffix of 'k', 'm', or 'g'
in the config file will cause the value to be multiplied
by 1024, 1048576, or 1073741824 prior to output.
ENVIRONMENT
DESCRIPTION
-----------
GIT_CONFIG::
Take the configuration from the given file instead of .git/config.
Using the "--global" option forces this to ~/.gitconfig.
GIT_CONFIG_LOCAL::
Currently the same as $GIT_CONFIG; when Git will support global
configuration files, this will cause it to take the configuration
from the global configuration file in addition to the given file.
EXAMPLE
-------
Given a .git/config like this:
#
# This is the config file, and
# a '#' or ';' character indicates
# a comment
#
; core variables
[core]
; Don't trust file modes
filemode = false
; Our diff algorithm
[diff]
external = "/usr/local/bin/gnu-diff -u"
renames = true
; Proxy settings
[core]
gitproxy="ssh" for "ssh://kernel.org/"
gitproxy="proxy-command" for kernel.org
gitproxy="myprotocol-command" for "my://"
gitproxy=default-proxy ; for all the rest
you can set the filemode to true with
------------
% git repo-config core.filemode true
------------
The hypothetical proxy command entries actually have a postfix to discern
what URL they apply to. Here is how to change the entry for kernel.org
to "ssh".
------------
% git repo-config core.gitproxy '"ssh" for kernel.org' 'for kernel.org$'
------------
This makes sure that only the key/value pair for kernel.org is replaced.
To delete the entry for renames, do
------------
% git repo-config --unset diff.renames
------------
If you want to delete an entry for a multivar (like core.gitproxy above),
you have to provide a regex matching the value of exactly one line.
@ -133,7 +133,7 @@ manually joining branches on commit.
@@ -133,7 +133,7 @@ manually joining branches on commit.
'multi-init'::
This command supports git-svnimport-like command-line syntax for
importing repositories that are layed out as recommended by the
importing repositories that are laid out as recommended by the
SVN folks. This is a bit more tolerant than the git-svnimport
command-line syntax and doesn't require the user to figure out
where the repository URL ends and where the repository path
@ -204,7 +204,7 @@ removed by default if there are no files left in them. git
@@ -204,7 +204,7 @@ removed by default if there are no files left in them. git
cannot version empty directories. Enabling this flag will make
the commit to SVN act like git.
repo-config key: svn.rmdir
config key: svn.rmdir
-e::
--edit::
@ -215,7 +215,7 @@ Edit the commit message before committing to SVN. This is off by
@@ -215,7 +215,7 @@ Edit the commit message before committing to SVN. This is off by
default for objects that are commits, and forced on when committing
tree objects.
repo-config key: svn.edit
config key: svn.edit
-l<num>::
--find-copies-harder::
@ -226,8 +226,8 @@ They are both passed directly to git-diff-tree see
@@ -226,8 +226,8 @@ They are both passed directly to git-diff-tree see
gitlink:git-diff-tree[1] for more information.
[verse]
repo-config key: svn.l
repo-config key: svn.findcopiesharder
config key: svn.l
config key: svn.findcopiesharder
-A<filename>::
--authors-file=<filename>::
@ -245,7 +245,7 @@ will abort operation. The user will then have to add the
@@ -245,7 +245,7 @@ will abort operation. The user will then have to add the
appropriate entry. Re-running the previous git-svn command
after the authors-file is modified should continue operation.
--repack-flags are passed directly to gitlink:git-repack[1].
repo-config key: svn.repack
repo-config key: svn.repackflags
config key: svn.repack
config key: svn.repackflags
-m::
--merge::
@ -304,7 +304,7 @@ used to track branches across multiple SVN _repositories_.
@@ -304,7 +304,7 @@ used to track branches across multiple SVN _repositories_.
This option may be specified multiple times, once for each
branch.
repo-config key: svn.branch
config key: svn.branch
-i<GIT_SVN_ID>::
--id <GIT_SVN_ID>::
@ -320,7 +320,7 @@ for more information on using GIT_SVN_ID.
@@ -320,7 +320,7 @@ for more information on using GIT_SVN_ID.
started tracking a branch and never tracked the trunk it was
descended from.
repo-config key: svn.followparent
config key: svn.followparent
--no-metadata::
This gets rid of the git-svn-id: lines at the end of every commit.
The command honors `core.filemode` configuration variable. If
your repository is on an filesystem whose executable bits are
unreliable, this should be set to 'false' (see gitlink:git-repo-config[1]).
unreliable, this should be set to 'false' (see gitlink:git-config[1]).
This causes the command to ignore differences in file modes recorded
in the index and the file mode on the filesystem if they differ only on
executable bit. On such an unfortunate filesystem, you may
@ -301,7 +301,7 @@ The command looks at `core.ignorestat` configuration variable. See
@@ -301,7 +301,7 @@ The command looks at `core.ignorestat` configuration variable. See
@ -22,9 +22,12 @@ See this link:tutorial.html[tutorial] to get started, then see
@@ -22,9 +22,12 @@ See this link:tutorial.html[tutorial] to get started, then see
link:everyday.html[Everyday Git] for a useful minimum set of commands, and
"man git-commandname" for documentation of each command. CVS users may
also want to read link:cvs-migration.html[CVS migration].
link:user-manual.html[Git User's Manual] is still work in
progress, but when finished hopefully it will guide a new user
in a coherent way to git enlightenment ;-).
The COMMAND is either a name of a Git command (see below) or an alias
as defined in the configuration file (see gitlink:git-repo-config[1]).
as defined in the configuration file (see gitlink:git-config[1]).
@ -90,9 +90,6 @@ parameter, and is invoked after a commit is made.
@@ -90,9 +90,6 @@ parameter, and is invoked after a commit is made.
This hook is meant primarily for notification, and cannot affect
the outcome of `git-commit`.
The default 'post-commit' hook, when enabled, demonstrates how to
send out a commit notification e-mail.
update
------
@ -130,6 +127,8 @@ The standard output of this hook is sent to `stderr`, so if you
@@ -130,6 +127,8 @@ The standard output of this hook is sent to `stderr`, so if you
want to report something to the `git-send-pack` on the other end,
you can simply `echo` your messages.
The default 'update' hook, when enabled, demonstrates how to
@ -16,8 +16,8 @@ public email address before doing any operation. The easiest
@@ -16,8 +16,8 @@ public email address before doing any operation. The easiest
way to do so is:
------------------------------------------------
$ git repo-config --global user.name "Your Name Comes Here"
@ -101,27 +101,27 @@ want to commit together. This can be done in a few different ways:
@@ -101,27 +101,27 @@ want to commit together. This can be done in a few different ways:
1) By using 'git add <file_spec>...'
This can be performed multiple times before a commit. Note that this
is not only for adding new files. Even modified files must be
added to the set of changes about to be committed. The "git status"
command gives you a summary of what is included so far for the
next commit. When done you should use the 'git commit' command to
make it real.
This can be performed multiple times before a commit. Note that this
is not only for adding new files. Even modified files must be
added to the set of changes about to be committed. The "git status"
command gives you a summary of what is included so far for the
next commit. When done you should use the 'git commit' command to
make it real.
Note: don't forget to 'add' a file again if you modified it after the
first 'add' and before 'commit'. Otherwise only the previous added
state of that file will be committed. This is because git tracks
content, so what you're really 'add'ing to the commit is the *content*
of the file in the state it is in when you 'add' it.
Note: don't forget to 'add' a file again if you modified it after the
first 'add' and before 'commit'. Otherwise only the previous added
state of that file will be committed. This is because git tracks
content, so what you're really 'add'ing to the commit is the *content*
of the file in the state it is in when you 'add' it.
2) By using 'git commit -a' directly
This is a quick way to automatically 'add' the content from all files
that were modified since the previous commit, and perform the actual
commit without having to separately 'add' them beforehand. This will
not add content from new files i.e. files that were never added before.
Those files still have to be added explicitly before performing a
commit.
This is a quick way to automatically 'add' the content from all files
that were modified since the previous commit, and perform the actual
commit without having to separately 'add' them beforehand. This will
not add content from new files i.e. files that were never added before.
Those files still have to be added explicitly before performing a
commit.
But here's a twist. If you do 'git commit <file1> <file2> ...' then only
the changes belonging to those explicitly specified files will be
@ -353,12 +353,12 @@ repository in the repository configuration, and that location is
@@ -353,12 +353,12 @@ repository in the repository configuration, and that location is
used for pulls:
-------------------------------------
$ git repo-config --get remote.origin.url
$ git config --get remote.origin.url
/home/bob/myrepo
-------------------------------------
(The complete configuration created by git-clone is visible using
"git repo-config -l", and the gitlink:git-repo-config[1] man page
"git config -l", and the gitlink:git-config[1] man page
explains the meaning of each option.)
Git also keeps a pristine copy of Alice's master branch under the
@ -458,9 +458,9 @@ $ git reset --hard HEAD^ # reset your current branch and working
@@ -458,9 +458,9 @@ $ git reset --hard HEAD^ # reset your current branch and working
Be careful with that last command: in addition to losing any changes
in the working directory, it will also remove all later commits from
this branch. If this branch is the only branch containing those
commits, they will be lost. (Also, don't use "git reset" on a
publicly-visible branch that other developers pull from, as git will
be confused by history that disappears in this way.)
commits, they will be lost. Also, don't use "git reset" on a
publicly-visible branch that other developers pull from, as it will
force needless merges on other developers to clean up the history.
The git grep command can search for strings in any version of your
@ -781,7 +781,7 @@ that is a plain string. (Unless C<$Error::ObjectifyCallback> is modified)
@@ -781,7 +781,7 @@ that is a plain string. (Unless C<$Error::ObjectifyCallback> is modified)
This variable holds a reference to a subroutine that converts errors that
are plain strings to objects. It is used by Error.pm to convert textual
errors to objects, and can be overrided by the user.
errors to objects, and can be overridden by the user.
It accepts a single argument which is a hash reference to named parameters.
Currently the only named parameter passed is C<'text'> which is the text
@ -87,7 +87,7 @@ test_expect_success 'three-way not complaining on an untracked path in both' '
@@ -87,7 +87,7 @@ test_expect_success 'three-way not complaining on an untracked path in both' '
git-read-tree -m -u branch-point master side
'
test_expect_success 'three-way not cloberring a working tree file' '
test_expect_success 'three-way not clobbering a working tree file' '