CONFIGURATION FILE
------------------
- The git configuration file contains a number of variables that affect
- the git command's behavior. The `.git/config` file in each repository
+ The Git configuration file contains a number of variables that affect
+ the Git commands' behavior. The `.git/config` file in each repository
is used to store the configuration for that repository, and
`$HOME/.gitconfig` is used to store a per-user configuration as
fallback values for the `.git/config` file. The file `/etc/gitconfig`
can be used to store a system-wide default configuration.
- The configuration variables are used by both the git plumbing
+ The configuration variables are used by both the Git plumbing
and the porcelains. The variables are divided into sections, wherein
the fully qualified variable name of the variable itself is the last
dot-separated segment and the section name is everything before the last
pushUpdateRejected::
Set this variable to 'false' if you want to disable
'pushNonFFCurrent', 'pushNonFFDefault',
- 'pushNonFFMatching', and 'pushAlreadyExists'
+ 'pushNonFFMatching', 'pushAlreadyExists',
+ 'pushFetchFirst', and 'pushNeedsForce'
simultaneously.
pushNonFFCurrent::
Advice shown when linkgit:git-push[1] fails due to a
pushAlreadyExists::
Shown when linkgit:git-push[1] rejects an update that
does not qualify for fast-forwarding (e.g., a tag.)
+ pushFetchFirst::
+ Shown when linkgit:git-push[1] rejects an update that
+ tries to overwrite a remote ref that points at an
+ object we do not have.
+ pushNeedsForce::
+ Shown when linkgit:git-push[1] rejects an update that
+ tries to overwrite a remote ref that points at an
+ object that is not a committish, or make the remote
+ ref point at an object that is not a committish.
statusHints::
Show directions on how to proceed from the current
state in the output of linkgit:git-status[1], in
core.ignorecase::
If true, this option enables various workarounds to enable
- git to work better on filesystems that are not case sensitive,
+ Git to work better on filesystems that are not case sensitive,
like FAT. For example, if a directory listing finds
- "makefile" when git expects "Makefile", git will assume
+ "makefile" when Git expects "Makefile", Git will assume
it is really the same file, and continue to remember it as
"Makefile".
+
is created.
core.precomposeunicode::
- This option is only used by Mac OS implementation of git.
- When core.precomposeunicode=true, git reverts the unicode decomposition
+ This option is only used by Mac OS implementation of Git.
+ When core.precomposeunicode=true, Git reverts the unicode decomposition
of filenames done by Mac OS. This is useful when sharing a repository
between Mac OS and Linux or Windows.
- (Git for Windows 1.7.10 or higher is needed, or git under cygwin 1.7).
- When false, file names are handled fully transparent by git,
- which is backward compatible with older versions of git.
+ (Git for Windows 1.7.10 or higher is needed, or Git under cygwin 1.7).
+ When false, file names are handled fully transparent by Git,
+ which is backward compatible with older versions of Git.
core.trustctime::
If false, the ctime differences between the index and the
crawlers and some backup systems).
See linkgit:git-update-index[1]. True by default.
+core.checkstat::
+ Determines which stat fields to match between the index
+ and work tree. The user can set this to 'default' or
+ 'minimal'. Default (or explicitly 'default'), is to check
+ all fields, including the sub-second part of mtime and ctime.
+
core.quotepath::
The commands that output paths (e.g. 'ls-files',
'diff'), when not given the `-z` option, will quote
conversion.
core.safecrlf::
- If true, makes git check if converting `CRLF` is reversible when
+ If true, makes Git check if converting `CRLF` is reversible when
end-of-line conversion is active. Git will verify if a command
modifies a file in the work tree either directly or indirectly.
For example, committing a file followed by checking out the
same file should yield the original file in the work tree. If
this is not the case for the current setting of
- `core.autocrlf`, git will reject the file. The variable can
- be set to "warn", in which case git will only warn about an
+ `core.autocrlf`, Git will reject the file. The variable can
+ be set to "warn", in which case Git will only warn about an
irreversible conversion but continue the operation.
+
CRLF conversion bears a slight chance of corrupting data.
- When it is enabled, git will convert CRLF to LF during commit and LF to
+ When it is enabled, Git will convert CRLF to LF during commit and LF to
CRLF during checkout. A file that contains a mixture of LF and
- CRLF before the commit cannot be recreated by git. For text
+ CRLF before the commit cannot be recreated by Git. For text
files this is the right thing to do: it corrects line endings
such that we have only LF line endings in the repository.
But for binary files that are accidentally classified as text the
setting the conversion type explicitly in .gitattributes. Right
after committing you still have the original file in your work
tree and this file is not yet corrupted. You can explicitly tell
- git that this file is binary and git will handle the file
+ Git that this file is binary and Git will handle the file
appropriately.
+
Unfortunately, the desired effect of cleaning up text files with
core.gitProxy::
A "proxy command" to execute (as 'command host port') instead
of establishing direct connection to the remote server when
- using the git protocol for fetching. If the variable value is
+ using the Git protocol for fetching. If the variable value is
in the "COMMAND for DOMAIN" format, the command is applied only
on hostnames ending with the specified domain string. This variable
may be set multiple times and is matched in the given order;
file in a ".git" subdirectory of a directory and its value differs
from the latter directory (e.g. "/path/to/.git/config" has
core.worktree set to "/different/path"), which is most likely a
- misconfiguration. Running git commands in the "/path/to" directory will
+ misconfiguration. Running Git commands in the "/path/to" directory will
still use "/different/path" as the root of the work tree and can cause
confusion unless you know what you are doing (e.g. you are creating a
read-only snapshot of the same index to a location different from the
several users in a group (making sure all the files and objects are
group-writable). When 'all' (or 'world' or 'everybody'), the
repository will be readable by all users, additionally to being
- group-shareable. When 'umask' (or 'false'), git will use permissions
+ group-shareable. When 'umask' (or 'false'), Git will use permissions
reported by umask(2). When '0xxx', where '0xxx' is an octal number,
files in the repository will have this mode value. '0xxx' will override
user's umask value (whereas the other options will only override
See linkgit:git-init[1]. False by default.
core.warnAmbiguousRefs::
- If true, git will warn you if the ref name you passed it is ambiguous
+ If true, Git will warn you if the ref name you passed it is ambiguous
and might match multiple refs in the .git/refs/ tree. True by default.
core.compression::
core.excludesfile::
In addition to '.gitignore' (per-directory) and
- '.git/info/exclude', git looks into this file for patterns
+ '.git/info/exclude', Git looks into this file for patterns
of files which are not meant to be tracked. "`~/`" is expanded
to the value of `$HOME` and "`~user/`" to the specified user's
home directory. Its default value is $XDG_CONFIG_HOME/git/ignore.
core.attributesfile::
In addition to '.gitattributes' (per-directory) and
- '.git/info/attributes', git looks into this file for attributes
+ '.git/info/attributes', Git looks into this file for attributes
(see linkgit:gitattributes[5]). Path expansions are made the same
way as for `core.excludesfile`. Its default value is
$XDG_CONFIG_HOME/git/attributes. If $XDG_CONFIG_HOME is either not
variable when it is set, and the environment variable
`GIT_EDITOR` is not set. See linkgit:git-var[1].
+core.commentchar::
+ Commands such as `commit` and `tag` that lets you edit
+ messages consider a line that begins with this character
+ commented, and removes them after the editor returns
+ (default '#').
+
sequence.editor::
Text editor used by `git rebase -i` for editing the rebase insn file.
The value is meant to be interpreted by the shell when it is used.
When not configured the default commit message editor is used instead.
core.pager::
- The command that git will use to paginate output. Can
+ The command that Git will use to paginate output. Can
be overridden with the `GIT_PAGER` environment
- variable. Note that git sets the `LESS` environment
+ variable. Note that Git sets the `LESS` environment
variable to `FRSX` if it is unset when it runs the
pager. One can change these settings by setting the
`LESS` variable to some other value. Alternately,
global basis by setting the `core.pager` option.
Setting `core.pager` has no effect on the `LESS`
environment variable behaviour above, so if you want
- to override git's default settings this way, you need
+ to override Git's default settings this way, you need
to be explicit. For example, to disable the S option
in a backward compatible manner, set `core.pager`
to `less -+S`. This will be passed to the shell by
- git, which will translate the final command to
+ Git, which will translate the final command to
`LESS=FRSX less -+S`.
core.whitespace::
does not trigger if the character before such a carriage-return
is not a whitespace (not enabled by default).
* `tabwidth=<n>` tells how many character positions a tab occupies; this
- is relevant for `indent-with-non-tab` and when git fixes `tab-in-indent`
+ is relevant for `indent-with-non-tab` and when Git fixes `tab-in-indent`
errors. The default tab width is 8. Allowed values are 1 to 63.
core.fsyncobjectfiles::
+
This can speed up operations like 'git diff' and 'git status' especially
on filesystems like NFS that have weak caching semantics and thus
- relatively high IO latencies. With this set to 'true', git will do the
+ relatively high IO latencies. With this set to 'true', Git will do the
index comparison to the filesystem data in parallel, allowing
overlapping IO's.
add.ignoreErrors::
Tells 'git add' to continue adding files when some files cannot be
added due to indexing errors. Equivalent to the '--ignore-errors'
- option of linkgit:git-add[1]. Older versions of git accept only
+ option of linkgit:git-add[1]. Older versions of Git accept only
`add.ignore-errors`, which does not follow the usual naming
- convention for configuration variables. Newer versions of git
+ convention for configuration variables. Newer versions of Git
honor `add.ignoreErrors` as well.
alias.*::
after defining "alias.last = cat-file commit HEAD", the invocation
"git last" is equivalent to "git cat-file commit HEAD". To avoid
confusion and troubles with script usage, aliases that
- hide existing git commands are ignored. Arguments are split by
+ hide existing Git commands are ignored. Arguments are split by
spaces, the usual shell quoting and escaping is supported.
quote pair and a backslash can be used to quote them.
+
branch.autosetuprebase::
When a new branch is created with 'git branch' or 'git checkout'
- that tracks another branch, this variable tells git to set
+ that tracks another branch, this variable tells Git to set
up pull to rebase instead of merge (see "branch.<name>.rebase").
When `never`, rebase is never automatically set to true.
When `local`, rebase is set to true for tracked branches of
one of `header` (the header text of the status message),
`added` or `updated` (files which are added but not committed),
`changed` (files which are changed but not added in the index),
- `untracked` (files which are not tracked by git),
+ `untracked` (files which are not tracked by Git),
`branch` (the current branch), or
`nobranch` (the color the 'no branch' warning is shown in, defaulting
to red). The values of these variables may be specified as in
to `always` if you want all output not intended for machine
consumption to use color, to `true` or `auto` if you want such
output to use color when written to the terminal, or to `false` or
- `never` if you prefer git commands not to use color unless enabled
+ `never` if you prefer Git commands not to use color unless enabled
explicitly with some other configuration or the `--color` option.
column.ui::
is used instead.
fetch.unpackLimit::
- If the number of objects fetched over the git native
+ If the number of objects fetched over the Git native
transfer is below this
limit, then the objects will be unpacked into loose object
files. However if the number of received objects equals or
format.signature::
The default for format-patch is to output a signature containing
- the git version number. Use this variable to change that default.
+ the Git version number. Use this variable to change that default.
Set this variable to the empty string ("") to suppress
signature generation.
gitcvs.usecrlfattr::
If true, the server will look up the end-of-line conversion
attributes for files to determine the '-k' modes to use. If
- the attributes force git to treat a file as text,
+ the attributes force Git to treat a file as text,
the '-k' mode will be left blank so CVS clients will
treat it as text. If they suppress text conversion, the file
will be set with '-kb' mode, which suppresses any newline munging
gitcvs.dbname::
Database used by git-cvsserver to cache revision information
- derived from the git repository. The exact meaning depends on the
+ derived from the Git repository. The exact meaning depends on the
used database driver, for SQLite (which is the default driver) this
is a filename. Supports variable substitution (see
linkgit:git-cvsserver[1] for details). May not contain semicolons (`;`).
http.cookiefile::
File containing previously stored cookie lines which should be used
- in the git http session, if they match the server. The file format
+ in the Git http session, if they match the server. The file format
of the file to read cookies from should be plain HTTP headers or
the Netscape/Mozilla cookie file format (see linkgit:curl[1]).
NOTE that the file specified with http.cookiefile is only used as
variable.
http.sslCertPasswordProtected::
- Enable git's password prompt for the SSL certificate. Otherwise
+ Enable Git's password prompt for the SSL certificate. Otherwise
OpenSSL will prompt the user, possibly many times, if the
certificate or private key is encrypted. Can be overridden by the
'GIT_SSL_CERT_PASSWORD_PROTECTED' environment variable.
http.useragent::
The HTTP USER_AGENT string presented to an HTTP server. The default
- value represents the version of the client git such as git/1.7.1.
+ value represents the version of the client Git such as git/1.7.1.
This option allows you to override this value to a more common value
such as Mozilla/4.0. This may be necessary, for instance, if
connecting through a firewall that restricts HTTP connections to a set
Can be overridden by the 'GIT_HTTP_USER_AGENT' environment variable.
i18n.commitEncoding::
- Character encoding the commit messages are stored in; git itself
+ Character encoding the commit messages are stored in; Git itself
does not care per se, but this information is necessary e.g. when
importing commits from emails or in the gitk graphical history
browser (and possibly at other places in the future or in other
`true` (i.e. keep the backup files).
mergetool.keepTemporaries::
- When invoking a custom merge tool, git uses a set of temporary
+ When invoking a custom merge tool, Git uses a set of temporary
files to pass to the tool. If the tool returns an error and this
variable is set to `true`, then these temporary files will be
preserved, otherwise they will be removed after the tool has
notes.rewrite.<command>::
When rewriting commits with <command> (currently `amend` or
- `rebase`) and this variable is set to `true`, git
+ `rebase`) and this variable is set to `true`, Git
automatically copies your notes from the original to the
rewritten commit. Defaults to `true`, but see
"notes.rewriteRef" below.
warning. This is meant to reduce packing time on multiprocessor
machines. The required amount of memory for the delta search window
is however multiplied by the number of threads.
- Specifying 0 will cause git to auto-detect the number of CPU's
+ Specifying 0 will cause Git to auto-detect the number of CPU's
and set the number of threads accordingly.
pack.indexVersion::
and this config option ignored whenever the corresponding pack is
larger than 2 GB.
+
- If you have an old git that does not understand the version 2 `*.idx` file,
+ If you have an old Git that does not understand the version 2 `*.idx` file,
cloning or fetching over a non native protocol (e.g. "http" and "rsync")
that will copy both `*.pack` file and corresponding `*.idx` file from the
other side may give you a repository that cannot be accessed with your
- older version of git. If the `*.pack` file is smaller than 2 GB, however,
+ older version of Git. If the `*.pack` file is smaller than 2 GB, however,
you can use linkgit:git-index-pack[1] on the *.pack file to regenerate
the `*.idx` file.
pager.<cmd>::
If the value is boolean, turns on or off pagination of the
- output of a particular git subcommand when writing to a tty.
+ output of a particular Git subcommand when writing to a tty.
Otherwise, turns on pagination for the subcommand using the
pager specified by the value of `pager.<cmd>`. If `--paginate`
or `--no-pager` is specified on the command line, it takes
The default merge strategy to use when pulling a single branch.
push.default::
- Defines the action git push should take if no refspec is given
+ Defines the action `git push` should take if no refspec is given
on the command line, no refspec is configured in the remote, and
no refspec is implied by any of the options given on the command
line. Possible values are:
linkgit:git-fetch[1].
remote.<name>.vcs::
- Setting this to a value <vcs> will cause git to interact with
+ Setting this to a value <vcs> will cause Git to interact with
the remote with the git-remote-<vcs> helper.
remotes.<group>::
repack.usedeltabaseoffset::
By default, linkgit:git-repack[1] creates packs that use
delta-base offset. If you need to share your repository with
- git older than version 1.4.4, either directly or via a dumb
+ Git older than version 1.4.4, either directly or via a dumb
protocol such as http, then you need to set this option to
- "false" and repack. Access from old git versions over the
+ "false" and repack. Access from old Git versions over the
native protocol are unaffected by this option.
rerere.autoupdate::
status.relativePaths::
By default, linkgit:git-status[1] shows paths relative to the
current directory. Setting this variable to `false` shows paths
- relative to the repository root (this was the default for git
+ relative to the repository root (this was the default for Git
prior to v1.5.4).
status.showUntrackedFiles::
large number of repositories, and serves them with multiple
access methods, and some users need to use different access
methods, this feature allows people to specify any of the
- equivalent URLs and have git automatically rewrite the URL to
+ equivalent URLs and have Git automatically rewrite the URL to
the best alternative for the particular user, even for a
never-before-seen repository on the site. When more than one
insteadOf strings match a given URL, the longest match is used.
resulting URL will be pushed to. In cases where some site serves
a large number of repositories, and serves them with multiple
access methods, some of which do not allow push, this feature
- allows people to specify a pull-only URL and have git
+ allows people to specify a pull-only URL and have Git
automatically use an appropriate URL to push, even for a
never-before-seen repository on the site. When more than one
pushInsteadOf strings match a given URL, the longest match is
- used. If a remote has an explicit pushurl, git will ignore this
+ used. If a remote has an explicit pushurl, Git will ignore this
setting for that remote.
user.email::
DESCRIPTION
-----------
- Imports a CVS repository into git. It will either create a new
+*WARNING:* `git cvsimport` uses cvsps version 2, which is considered
+deprecated; it does not work with cvsps version 3 and later. If you are
+performing a one-shot import of a CVS repository consider using
+link:http://cvs2svn.tigris.org/cvs2git.html[cvs2git] or
+link:https://github.com/BartMassey/parsecvs[parsecvs].
+
+ Imports a CVS repository into Git. It will either create a new
repository, or incrementally import into an existing one.
Splitting the CVS log into patch sets is done by 'cvsps'.
`CVS/Repository`.
-C <target-dir>::
- The git repository to import to. If the directory doesn't
+ The Git repository to import to. If the directory doesn't
exist, it will be created. Default is the current directory.
-r <remote>::
- The git remote to import this CVS repository into.
+ The Git remote to import this CVS repository into.
Moves all CVS branches into remotes/<remote>/<branch>
akin to the way 'git clone' uses 'origin' by default.
-o <branch-for-HEAD>::
When no remote is specified (via -r) the 'HEAD' branch
- from CVS is imported to the 'origin' branch within the git
- repository, as 'HEAD' already has a special meaning for git.
+ from CVS is imported to the 'origin' branch within the Git
+ repository, as 'HEAD' already has a special meaning for Git.
When a remote is specified the 'HEAD' branch is named
remotes/<remote>/master mirroring 'git clone' behaviour.
Use this option if you want to import into a different
NAME
----
- git-cvsserver - A CVS server emulator for git
+ git-cvsserver - A CVS server emulator for Git
SYNOPSIS
--------
DESCRIPTION
-----------
- This application is a CVS emulation layer for git.
+ This application is a CVS emulation layer for Git.
It is highly functional. However, not all methods are implemented,
and for those methods that are implemented,
LIMITATIONS
-----------
- CVS clients cannot tag, branch or perform GIT merges.
+ CVS clients cannot tag, branch or perform Git merges.
- 'git-cvsserver' maps GIT branches to CVS modules. This is very different
+ 'git-cvsserver' maps Git branches to CVS modules. This is very different
from what most CVS users would expect since in CVS modules usually represent
one or more directories.
------
cvs -d:pserver:someuser:somepassword <at> server/path/repo.git co <HEAD_name>
------
- No special setup is needed for SSH access, other than having GIT tools
+ No special setup is needed for SSH access, other than having Git tools
in the PATH. If you have clients that do not accept the CVS_SERVER
environment variable, you can rename 'git-cvsserver' to `cvs`.
Note: you need to ensure each user that is going to invoke 'git-cvsserver' has
write access to the log file and to the database (see
<<dbbackend,Database Backend>>. If you want to offer write access over
- SSH, the users of course also need write access to the git repository itself.
+ SSH, the users of course also need write access to the Git repository itself.
- You also need to ensure that each repository is "bare" (without a git index
+ You also need to ensure that each repository is "bare" (without a Git index
file) for `cvs commit` to work. See linkgit:gitcvs-migration[7].
[[configaccessmethod]]
3. If you didn't specify the CVSROOT/CVS_SERVER directly in the checkout command,
automatically saving it in your 'CVS/Root' files, then you need to set them
explicitly in your environment. CVSROOT should be set as per normal, but the
- directory should point at the appropriate git repo. As above, for SSH clients
+ directory should point at the appropriate Git repo. As above, for SSH clients
_not_ restricted to 'git-shell', CVS_SERVER should be set to 'git-cvsserver'.
+
--
shell is bash, .bashrc may be a reasonable alternative.
5. Clients should now be able to check out the project. Use the CVS 'module'
- name to indicate what GIT 'head' you want to check out. This also sets the
+ name to indicate what Git 'head' you want to check out. This also sets the
name of your newly checked-out directory, unless you tell it otherwise with
`-d <dir_name>`. For example, this checks out 'master' branch to the
`project-master` directory:
Database Backend
----------------
- 'git-cvsserver' uses one database per git head (i.e. CVS module) to
+ 'git-cvsserver' uses one database per Git head (i.e. CVS module) to
store information about the repository to maintain consistent
CVS revision numbers. The database needs to be
updated (i.e. written to) after every commit.
the database to work reliably (otherwise you need to make sure
that the database is up-to-date any time 'git-cvsserver' is executed).
- By default it uses SQLite databases in the git directory, named
+ By default it uses SQLite databases in the Git directory, named
`gitcvs.<module_name>.sqlite`. Note that the SQLite backend creates
temporary files in the same directory as the database file on
write so it might not be enough to grant the users using
In `dbdriver` and `dbuser` you can use the following variables:
%G::
- git directory name
+ Git directory name
%g::
- git directory name, where all characters except for
+ Git directory name, where all characters except for
alpha-numeric ones, `.`, and `-` are replaced with
`_` (this should make it easier to use the directory
name in a filename if wanted)
%m::
- CVS module/git head name
+ CVS module/Git head name
%a::
access method (one of "ext" or "pserver")
%u::
All the operations required for normal use are supported, including
checkout, diff, status, update, log, add, remove, commit.
+
+Most CVS command arguments that read CVS tags or revision numbers
+(typically -r) work, and also support any git refspec
+(tag, branch, commit ID, etc).
+However, CVS revision numbers for non-default branches are not well
+emulated, and cvs log does not show tags or branches at
+all. (Non-main-branch CVS revision numbers superficially resemble CVS
+revision numbers, but they actually encode a git commit ID directly,
+rather than represent the number of revisions since the branch point.)
+
+Note that there are two ways to checkout a particular branch.
+As described elsewhere on this page, the "module" parameter
+of cvs checkout is interpreted as a branch name, and it becomes
+the main branch. It remains the main branch for a given sandbox
+even if you temporarily make another branch sticky with
+cvs update -r. Alternatively, the -r argument can indicate
+some other branch to actually checkout, even though the module
+is still the "main" branch. Tradeoffs (as currently
+implemented): Each new "module" creates a new database on disk with
+a history for the given module, and after the database is created,
+operations against that main branch are fast. Or alternatively,
+-r doesn't take any extra disk space, but may be significantly slower for
+many operations, like cvs update.
+
+If you want to refer to a git refspec that has characters that are
+not allowed by CVS, you have two options. First, it may just work
+to supply the git refspec directly to the appropriate CVS -r argument;
+some CVS clients don't seem to do much sanity checking of the argument.
+Second, if that fails, you can use a special character escape mechanism
+that only uses characters that are valid in CVS tags. A sequence
+of 4 or 5 characters of the form (underscore (`"_"`), dash (`"-"`),
+one or two characters, and dash (`"-"`)) can encode various characters based
+on the one or two letters: `"s"` for slash (`"/"`), `"p"` for
+period (`"."`), `"u"` for underscore (`"_"`), or two hexadecimal digits
+for any byte value at all (typically an ASCII number, or perhaps a part
+of a UTF-8 encoded character).
+
Legacy monitoring operations are not supported (edit, watch and related).
Exports and tagging (tags and branches) are not supported at this stage.
DESCRIPTION
-----------
This command provides a way to interact with p4 repositories
- using git.
+ using Git.
- Create a new git repository from an existing p4 repository using
+ Create a new Git repository from an existing p4 repository using
'git p4 clone', giving it one or more p4 depot paths. Incorporate
new commits from p4 changes with 'git p4 sync'. The 'sync' command
is also used to include new branches from other p4 depot paths.
- Submit git changes back to p4 using 'git p4 submit'. The command
+ Submit Git changes back to p4 using 'git p4 submit'. The command
'git p4 rebase' does a sync plus rebases the current branch onto
the updated p4 remote branch.
$ git p4 clone //depot/path/project
------------
- * Do some work in the newly created git repository:
+ * Do some work in the newly created Git repository:
+
------------
$ cd project
$ git commit -a -m "edited foo.h"
------------
- * Update the git repository with recent changes from p4, rebasing your
+ * Update the Git repository with recent changes from p4, rebasing your
work on top:
+
------------
Clone
~~~~~
- Generally, 'git p4 clone' is used to create a new git directory
+ Generally, 'git p4 clone' is used to create a new Git directory
from an existing p4 repository:
------------
$ git p4 clone //depot/path/project
------------
This:
- 1. Creates an empty git repository in a subdirectory called 'project'.
+ 1. Creates an empty Git repository in a subdirectory called 'project'.
+
2. Imports the full contents of the head revision from the given p4
- depot path into a single commit in the git branch 'refs/remotes/p4/master'.
+ depot path into a single commit in the Git branch 'refs/remotes/p4/master'.
+
3. Creates a local branch, 'master' from this remote and checks it out.
- To reproduce the entire p4 history in git, use the '@all' modifier on
+ To reproduce the entire p4 history in Git, use the '@all' modifier on
the depot path:
------------
$ git p4 clone //depot/path/project@all
Sync
~~~~
As development continues in the p4 repository, those changes can
- be included in the git repository using:
+ be included in the Git repository using:
------------
$ git p4 sync
------------
- This command finds new changes in p4 and imports them as git commits.
+ This command finds new changes in p4 and imports them as Git commits.
- P4 repositories can be added to an existing git repository using
+ P4 repositories can be added to an existing Git repository using
'git p4 sync' too:
------------
$ mkdir repo-git
$ git p4 sync //path/in/your/perforce/depot
------------
This imports the specified depot into
- 'refs/remotes/p4/master' in an existing git repository. The
+ 'refs/remotes/p4/master' in an existing Git repository. The
'--branch' option can be used to specify a different branch to
be used for the p4 content.
- If a git repository includes branches 'refs/remotes/origin/p4', these
+ If a Git repository includes branches 'refs/remotes/origin/p4', these
will be fetched and consulted first during a 'git p4 sync'. Since
importing directly from p4 is considerably slower than pulling changes
- from a git remote, this can be useful in a multi-developer environment.
+ from a Git remote, this can be useful in a multi-developer environment.
+If there are multiple branches, doing 'git p4 sync' will automatically
+use the "BRANCH DETECTION" algorithm to try to partition new changes
+into the right branch. This can be overridden with the '--branch'
+option to specify just a single branch to update.
+
Rebase
~~~~~~
Submit
~~~~~~
- Submitting changes from a git repository back to the p4 repository
+ Submitting changes from a Git repository back to the p4 repository
requires a separate p4 client workspace. This should be specified
- using the 'P4CLIENT' environment variable or the git configuration
+ using the 'P4CLIENT' environment variable or the Git configuration
variable 'git-p4.client'. The p4 client must exist, but the client root
will be created and populated if it does not already exist.
- To submit all changes that are in the current git branch but not in
+ To submit all changes that are in the current Git branch but not in
the 'p4/master' branch, use:
------------
$ git p4 submit
The p4 changes will be created as the user invoking 'git p4 submit'. The
'--preserve-user' option will cause ownership to be modified
- according to the author of the git commit. This option requires admin
+ according to the author of the Git commit. This option requires admin
privileges in p4, which can be granted using 'p4 protect'.
--branch <branch>::
Import changes into given branch. If the branch starts with
- 'refs/', it will be used as is, otherwise the path 'refs/heads/'
- will be prepended. The default branch is 'master'. If used
- with an initial clone, no HEAD will be checked out.
+ 'refs/', it will be used as is. Otherwise if it does not start
+ with 'p4/', that prefix is added. The branch is assumed to
+ name a remote tracking, but this can be modified using
+ '--import-local', or by giving a full ref name. The default
+ branch is 'master'.
+
This example imports a new remote "p4/proj2" into an existing
- git repository:
+ Git repository:
+
----
$ git init
--detect-labels::
Query p4 for labels associated with the depot paths, and add
- them as tags in git. Limited usefulness as only imports labels
+ them as tags in Git. Limited usefulness as only imports labels
associated with new changelists. Deprecated.
--import-labels::
- Import labels from p4 into git.
+ Import labels from p4 into Git.
--import-local::
By default, p4 branches are stored in 'refs/remotes/p4/',
specifier.
--keep-path::
- The mapping of file names from the p4 depot path to git, by
+ The mapping of file names from the p4 depot path to Git, by
default, involves removing the entire depot path. With this
- option, the full p4 depot path is retained in git. For example,
+ option, the full p4 depot path is retained in Git. For example,
path '//depot/main/foo/bar.c', when imported from
'//depot/main/', becomes 'foo/bar.c'. With '--keep-path', the
- git path is instead 'depot/main/foo/bar.c'.
+ Git path is instead 'depot/main/foo/bar.c'.
--use-client-spec::
Use a client spec to find the list of interesting files in p4.
options described above.
--destination <directory>::
- Where to create the git repository. If not provided, the last
+ Where to create the Git repository. If not provided, the last
component in the p4 depot path is used to create a new
directory.
requires p4 admin privileges.
--export-labels::
- Export tags from git as p4 labels. Tags found in git are applied
+ Export tags from Git as p4 labels. Tags found in Git are applied
to the perforce working directory.
--dry-run, -n::
Show just what commits would be submitted to p4; do not change
- state in git or p4.
+ state in Git or p4.
--prepare-p4-only::
Apply a commit to the p4 workspace, opening, adding and deleting
to bypass the prompt, causing conflicting commits to be automatically
skipped, or to quit trying to apply commits, without prompting.
+--branch <branch>::
+ After submitting, sync this named branch instead of the default
+ p4/master. See the "Sync options" section above for more
+ information.
+
Rebase options
~~~~~~~~~~~~~~
These options can be used to modify 'git p4 rebase' behavior.
"//depot/proj1@all //depot/proj2@all"::
Import all changes from both named depot paths into a single
repository. Only files below these directories are included.
- There is not a subdirectory in git for each "proj1" and "proj2".
+ There is not a subdirectory in Git for each "proj1" and "proj2".
You must use the '--destination' option when specifying more
than one depot path. The revision specifier must be specified
identically on each depot path. If there are files in the
depot paths with the same name, the path with the most recently
- updated version of the file is the one that appears in git.
+ updated version of the file is the one that appears in Git.
See 'p4 help revisions' for the full syntax of p4 revision specifiers.
work properly; the submit command looks only at the variable and does
not have a command-line option.
- The full syntax for a p4 view is documented in 'p4 help views'. 'Git p4'
+ The full syntax for a p4 view is documented in 'p4 help views'. 'git p4'
knows only a subset of the view syntax. It understands multi-line
mappings, overlays with '+', exclusions with '-' and double-quotes
around whitespace. Of the possible wildcards, 'git p4' only handles
- '...', and only when it is at the end of the path. 'Git p4' will complain
+ '...', and only when it is at the end of the path. 'git p4' will complain
if it encounters an unhandled wildcard.
Bugs in the implementation of overlap mappings exist. If multiple depot
BRANCH DETECTION
----------------
- P4 does not have the same concept of a branch as git. Instead,
+ P4 does not have the same concept of a branch as Git. Instead,
p4 organizes its content as a directory tree, where by convention
different logical branches are in different locations in the tree.
The 'p4 branch' command is used to maintain mappings between
If you have a repository where all the branches of interest exist as
subdirectories of a single depot path, you can use '--detect-branches'
when cloning or syncing to have 'git p4' automatically find
- subdirectories in p4, and to generate these as branches in git.
+ subdirectories in p4, and to generate these as branches in Git.
For example, if the P4 repository structure is:
----
However, it is not necessary to create branches in p4 to be able to use
them like branches. Because it is difficult to infer branch
- relationships automatically, a git configuration setting
+ relationships automatically, a Git configuration setting
'git-p4.branchList' can be used to explicitly identify branch
relationships. It is a list of "source:destination" pairs, like a
simple p4 branch specification, where the "source" and "destination" are
presence of the p4 branch. Without p4 branches, the same result will
occur with:
----
+git init depot
+cd depot
git config git-p4.branchList main:branch1
-git p4 clone --detect-branches //depot@all
+git p4 clone --detect-branches //depot@all .
----
PERFORMANCE
-----------
The fast-import mechanism used by 'git p4' creates one pack file for
- each invocation of 'git p4 sync'. Normally, git garbage compression
+ each invocation of 'git p4 sync'. Normally, Git garbage compression
(linkgit:git-gc[1]) automatically compresses these to fewer pack files,
but explicit invocation of 'git repack -adf' may improve performance.
Clone and sync variables
~~~~~~~~~~~~~~~~~~~~~~~~
git-p4.syncFromOrigin::
- Because importing commits from other git repositories is much faster
+ Because importing commits from other Git repositories is much faster
than importing them from p4, a mechanism exists to find p4 changes
- first in git remotes. If branches exist under 'refs/remote/origin/p4',
+ first in Git remotes. If branches exist under 'refs/remote/origin/p4',
those will be fetched and used when syncing from p4. This
variable can be set to 'false' to disable this behavior.
Detect copies harder. See linkgit:git-diff[1]. A boolean.
git-p4.preserveUser::
- On submit, re-author changes to reflect the git author,
+ On submit, re-author changes to reflect the Git author,
regardless of who invokes 'git p4 submit'.
git-p4.allowMissingP4Users::
present.
git-p4.exportLabels::
- Export git tags to p4 labels, as per --export-labels.
+ Export Git tags to p4 labels, as per --export-labels.
git-p4.labelExportRegexp::
Only p4 labels matching this regular expression will be exported. The
IMPLEMENTATION DETAILS
----------------------
- * Changesets from p4 are imported using git fast-import.
+ * Changesets from p4 are imported using Git fast-import.
* Cloning or syncing does not require a p4 client; file contents are
collected using 'p4 print'.
* Submitting requires a p4 client, which is not in the same location
- as the git repository. Patches are applied, one at a time, to
+ as the Git repository. Patches are applied, one at a time, to
this p4 client and submitted from there.
* Each commit imported by 'git p4' has a line at the end of the log
message indicating the p4 depot location and change number. This
DESCRIPTION
-----------
- Clean the input in the manner used by 'git' for text such as commit
+ Clean the input in the manner used by Git for text such as commit
messages, notes, tags and branch descriptions.
With no arguments, this will:
-------
-s::
--strip-comments::
- Skip and remove all lines starting with '#'.
+ Skip and remove all lines starting with comment character (default '#').
+
+-c::
+--comment-lines::
+ Prepend comment character and blank to each line. Lines will automatically
+ be terminated with a newline. On empty lines, only the comment character
+ will be prepended.
EXAMPLES
--------
NAME
----
- githooks - Hooks used by git
+ githooks - Hooks used by Git
SYNOPSIS
--------
means a failure of the hook and aborts the commit. It should not
be used as replacement for pre-commit hook.
- The sample `prepare-commit-msg` hook that comes with git comments
+ The sample `prepare-commit-msg` hook that comes with Git comments
out the `Conflicts:` part of a merge's commit message.
commit-msg
(eg: permissions/ownership, ACLS, etc). See contrib/hooks/setgitperms.perl
for an example of how to do this.
+pre-push
+~~~~~~~~
+
+This hook is called by 'git push' and can be used to prevent a push from taking
+place. The hook is called with two parameters which provide the name and
+location of the destination remote, if a named remote is not being used both
+values will be the same.
+
+Information about what is to be pushed is provided on the hook's standard
+input with lines of the form:
+
+ <local ref> SP <local sha1> SP <remote ref> SP <remote sha1> LF
+
+For instance, if the command +git push origin master:foreign+ were run the
+hook would receive a line like the following:
+
+ refs/heads/master 67890 refs/heads/foreign 12345
+
+although the full, 40-character SHA1s would be supplied. If the foreign ref
+does not yet exist the `<remote SHA1>` will be 40 `0`. If a ref is to be
+deleted, the `<local ref>` will be supplied as `(delete)` and the `<local
+SHA1>` will be 40 `0`. If the local commit was specified by something other
+than a name which could be expanded (such as `HEAD~`, or a SHA1) it will be
+supplied as it was originally given.
+
+If this hook exits with a non-zero status, 'git push' will abort without
+pushing anything. Information about why the push is rejected may be sent
+to the user by writing to standard error.
+
[[pre-receive]]
pre-receive
~~~~~~~~~~~
The default 'post-receive' hook is empty, but there is
a sample script `post-receive-email` provided in the `contrib/hooks`
- directory in git distribution, which implements sending commit
+ directory in Git distribution, which implements sending commit
emails.
[[post-update]]
When enabled, the default 'post-update' hook runs
'git update-server-info' to keep the information used by dumb
transports (e.g., HTTP) up-to-date. If you are publishing
- a git repository that is accessible via HTTP, you should
+ a Git repository that is accessible via HTTP, you should
probably enable this hook.
Both standard output and standard error output are forwarded to
-----------
A `gitignore` file specifies intentionally untracked files that
- git should ignore.
- Files already tracked by git are not affected; see the NOTES
+ Git should ignore.
+ Files already tracked by Git are not affected; see the NOTES
below for details.
Each line in a `gitignore` file specifies a pattern.
- When deciding whether to ignore a path, git normally checks
+ When deciding whether to ignore a path, Git normally checks
`gitignore` patterns from multiple sources, with the following
order of precedence, from highest to lowest (within one level of
precedence, the last matching pattern decides the outcome):
the repository but are specific to one user's workflow) should go into
the `$GIT_DIR/info/exclude` file.
- * Patterns which a user wants git to
+ * Patterns which a user wants Git to
ignore in all situations (e.g., backup or temporary files generated by
the user's editor of choice) generally go into a file specified by
`core.excludesfile` in the user's `~/.gitconfig`. Its default value is
$XDG_CONFIG_HOME/git/ignore. If $XDG_CONFIG_HOME is either not set or
empty, $HOME/.config/git/ignore is used instead.
- The underlying git plumbing tools, such as
+ The underlying Git plumbing tools, such as
'git ls-files' and 'git read-tree', read
`gitignore` patterns specified by command-line options, or from
- files specified by command-line options. Higher-level git
+ files specified by command-line options. Higher-level Git
tools, such as 'git status' and 'git add',
use patterns from the sources specified above.
a match with a directory. In other words, `foo/` will match a
directory `foo` and paths underneath it, but will not match a
regular file or a symbolic link `foo` (this is consistent
- with the way how pathspec works in general in git).
+ with the way how pathspec works in general in Git).
- - If the pattern does not contain a slash '/', git treats it as
+ - If the pattern does not contain a slash '/', Git treats it as
a shell glob pattern and checks for a match against the
pathname relative to the location of the `.gitignore` file
(relative to the toplevel of the work tree if not from a
`.gitignore` file).
- - Otherwise, git treats the pattern as a shell glob suitable
+ - Otherwise, Git treats the pattern as a shell glob suitable
for consumption by fnmatch(3) with the FNM_PATHNAME flag:
wildcards in the pattern will not match a / in the pathname.
For example, "Documentation/{asterisk}.html" matches
-----
The purpose of gitignore files is to ensure that certain files
- not tracked by git remain untracked.
+ not tracked by Git remain untracked.
To ignore uncommitted changes in a file that is already tracked,
use 'git update-index {litdd}assume-unchanged'.
$ echo '!/vmlinux*' >arch/foo/kernel/.gitignore
--------------------------------------------------------------
- The second .gitignore prevents git from ignoring
+ The second .gitignore prevents Git from ignoring
`arch/foo/kernel/vmlinux.lds.S`.
SEE ALSO
--------
-linkgit:git-rm[1], linkgit:git-update-index[1],
-linkgit:gitrepository-layout[5]
+linkgit:git-rm[1],
+linkgit:git-update-index[1],
+linkgit:gitrepository-layout[5],
+linkgit:git-check-ignore[1]
GIT
---
From: Junio C Hamano <gitster@pobox.com>
Date: Wed, 21 Nov 2007 16:32:55 -0800
Subject: Addendum to "MaintNotes"
- Abstract: Imagine that git development is racing along as usual, when our friendly
+ Abstract: Imagine that Git development is racing along as usual, when our friendly
neighborhood maintainer is struck down by a wayward bus. Out of the
hordes of suckers (loyal developers), you have been tricked (chosen) to
step up as the new maintainer. This howto will show you "how to" do it.
How to maintain Git
===================
- The maintainer's git time is spent on three activities.
+Activities
+----------
+
+ The maintainer's Git time is spent on three activities.
- - Communication (60%)
+ - Communication (45%)
Mailing list discussions on general design, fielding user
questions, diagnosing bug reports; reviewing, commenting on,
suggesting alternatives to, and rejecting patches.
- - Integration (30%)
+ - Integration (50%)
Applying new patches from the contributors while spotting and
correcting minor mistakes, shuffling the integration and
testing branches, pushing the results out, cutting the
releases, and making announcements.
- - Own development (10%)
+ - Own development (5%)
Scratching my own itch and sending proposed patch series out.
+The Policy
+----------
+
The policy on Integration is informally mentioned in "A Note
from the maintainer" message, which is periodically posted to
this mailing list after each feature release is made.
-The policy.
-
- Feature releases are numbered as vX.Y.Z and are meant to
contain bugfixes and enhancements in any area, including
functionality, performance and usability, without regression.
+ - One release cycle for a feature release is expected to last for
+ eight to ten weeks.
+
- Maintenance releases are numbered as vX.Y.Z.W and are meant
to contain only bugfixes for the corresponding vX.Y.Z feature
release and earlier maintenance releases vX.Y.Z.V (V < W).
- 'pu' branch is used to publish other proposed changes that do
not yet pass the criteria set for 'next'.
- - The tips of 'master', 'maint' and 'next' branches will always
- fast-forward, to allow people to build their own
- customization on top of them.
+ - The tips of 'master' and 'maint' branches will not be rewound to
+ allow people to build their own customization on top of them.
+ Early in a new development cycle, 'next' is rewound to the tip of
+ 'master' once, but otherwise it will not be rewound until the end
+ of the cycle.
- - Usually 'master' contains all of 'maint', 'next' contains all
- of 'master' and 'pu' contains all of 'next'.
+ - Usually 'master' contains all of 'maint' and 'next' contains all
+ of 'master'. 'pu' contains all the topics merged to 'next', but
+ is rebuilt directly on 'master'.
- The tip of 'master' is meant to be more stable than any
tagged releases, and the users are encouraged to follow it.
are found before new topics are merged to 'master'.
- A typical git day for the maintainer implements the above policy
+A Typical Git Day
+-----------------
+
+ A typical Git day for the maintainer implements the above policy
by doing the following:
- - Scan mailing list and #git channel log. Respond with review
- comments, suggestions etc. Kibitz. Collect potentially
- usable patches from the mailing list. Patches about a single
- topic go to one mailbox (I read my mail in Gnus, and type
- \C-o to save/append messages in files in mbox format).
+ - Scan mailing list. Respond with review comments, suggestions
+ etc. Kibitz. Collect potentially usable patches from the
+ mailing list. Patches about a single topic go to one mailbox (I
+ read my mail in Gnus, and type \C-o to save/append messages in
+ files in mbox format).
+
+ - Write his own patches to address issues raised on the list but
+ nobody has stepped up solving. Send it out just like other
+ contributors do, and pick them up just like patches from other
+ contributors (see above).
- Review the patches in the saved mailboxes. Edit proposed log
message for typofixes and clarifications, and add Acks
- Obviously correct fixes that pertain to the tip of 'master'
are directly applied to 'master'.
+ - Other topics are not handled in this step.
+
This step is done with "git am".
$ git checkout master ;# or "git checkout maint"
- $ git am -3 -s mailbox
+ $ git am -sc3 mailbox
$ make test
- - Merge downwards (maint->master):
-
- $ git checkout master
- $ git merge maint
- $ make test
+ In practice, almost no patch directly goes to 'master' or
+ 'maint'.
- Review the last issue of "What's cooking" message, review the
- topics scheduled for merging upwards (topic->master and
- topic->maint), and merge.
+ topics ready for merging (topic->master and topic->maint). Use
+ "Meta/cook -w" script (where Meta/ contains a checkout of the
+ 'todo' branch) to aid this step.
+
+ And perform the merge. Use "Meta/Reintegrate -e" script (see
+ later) to aid this step.
+
+ $ Meta/cook -w last-issue-of-whats-cooking.mbox
$ git checkout master ;# or "git checkout maint"
- $ git merge ai/topic ;# or "git merge ai/maint-topic"
+ $ echo ai/topic | Meta/Reintegrate -e ;# "git merge ai/topic"
$ git log -p ORIG_HEAD.. ;# final review
$ git diff ORIG_HEAD.. ;# final review
$ make test ;# final review
- $ git branch -d ai/topic ;# or "git branch -d ai/maint-topic"
-
- - Merge downwards (maint->master) if needed:
-
- $ git checkout master
- $ git merge maint
- $ make test
-
- - Merge downwards (master->next) if needed:
-
- $ git checkout next
- $ git merge master
- $ make test
- Handle the remaining patches:
and not in 'master') is applied to a new topic branch that
is forked from the tip of 'master'. This includes both
enhancements and unobvious fixes to 'master'. A topic
- branch is named as ai/topic where "ai" is typically
- author's initial and "topic" is a descriptive name of the
- topic (in other words, "what's the series is about").
+ branch is named as ai/topic where "ai" is two-letter string
+ named after author's initial and "topic" is a descriptive name
+ of the topic (in other words, "what's the series is about").
- An unobvious fix meant for 'maint' is applied to a new
topic branch that is forked from the tip of 'maint'. The
The above except the "replacement" are all done with:
- $ git am -3 -s mailbox
+ $ git checkout ai/topic ;# or "git checkout -b ai/topic master"
+ $ git am -sc3 mailbox
while patch replacement is often done by:
then replace some parts with the new patch, and reapplying:
+ $ git checkout ai/topic
$ git reset --hard ai/topic~$n
- $ git am -3 -s 000*.txt
+ $ git am -sc3 -s 000*.txt
The full test suite is always run for 'maint' and 'master'
after patch application; for topic branches the tests are run
as time permits.
- - Update "What's cooking" message to review the updates to
- existing topics, newly added topics and graduated topics.
+ - Merge maint to master as needed:
- This step is helped with Meta/cook script (where Meta/ contains
- a checkout of the 'todo' branch).
-
- - Merge topics to 'next'. For each branch whose tip is not
- merged to 'next', one of three things can happen:
+ $ git checkout master
+ $ git merge maint
+ $ make test
- - The commits are all next-worthy; merge the topic to next:
+ - Merge master to next as needed:
$ git checkout next
- $ git merge ai/topic ;# or "git merge ai/maint-topic"
+ $ git merge master
$ make test
+ - Review the last issue of "What's cooking" again and see if topics
+ that are ready to be merged to 'next' are still in good shape
+ (e.g. has there any new issue identified on the list with the
+ series?)
+
+ - Prepare 'jch' branch, which is used to represent somewhere
+ between 'master' and 'pu' and often is slightly ahead of 'next'.
+
+ $ Meta/Reintegrate master..pu >Meta/redo-jch.sh
+
+ The result is a script that lists topics to be merged in order to
+ rebuild 'pu' as the input to Meta/Reintegrate script. Remove
+ later topics that should not be in 'jch' yet. Add a line that
+ consists of '### match next' before the name of the first topic
+ in the output that should be in 'jch' but not in 'next' yet.
+
+ - Now we are ready to start merging topics to 'next'. For each
+ branch whose tip is not merged to 'next', one of three things can
+ happen:
+
+ - The commits are all next-worthy; merge the topic to next;
- The new parts are of mixed quality, but earlier ones are
- next-worthy; merge the early parts to next:
+ next-worthy; merge the early parts to next;
+ - Nothing is next-worthy; do not do anything.
+
+ This step is aided with Meta/redo-jch.sh script created earlier.
+ If a topic that was already in 'next' gained a patch, the script
+ would list it as "ai/topic~1". To include the new patch to the
+ updated 'next', drop the "~1" part; to keep it excluded, do not
+ touch the line. If a topic that was not in 'next' should be
+ merged to 'next', add it at the end of the list. Then:
+
+ $ git checkout -B jch master
+ $ Meta/redo-jch.sh -c1
+
+ to rebuild the 'jch' branch from scratch. "-c1" tells the script
+ to stop merging at the first line that begins with '###'
+ (i.e. the "### match next" line you added earlier).
+
+ At this point, build-test the result. It may reveal semantic
+ conflicts (e.g. a topic renamed a variable, another added a new
+ reference to the variable under its old name), in which case
+ prepare an appropriate merge-fix first (see appendix), and
+ rebuild the 'jch' branch from scratch, starting at the tip of
+ 'master'.
+
+ Then do the same to 'next'
$ git checkout next
- $ git merge ai/topic~2 ;# the tip two are dubious
- $ make test
+ $ sh Meta/redo-jch.sh -c1 -e
- - Nothing is next-worthy; do not do anything.
+ The "-e" option allows the merge message that comes from the
+ history of the topic and the comments in the "What's cooking" to
+ be edited. The resulting tree should match 'jch' as the same set
+ of topics are merged on 'master'; otherwise there is a mismerge.
+ Investigate why and do not proceed until the mismerge is found
+ and rectified.
- - [** OBSOLETE **] Optionally rebase topics that do not have any commit
- in next yet, when they can take advantage of low-level framework
- change that is merged to 'master' already.
+ $ git diff jch next
- $ git rebase master ai/topic
+ When all is well, clean up the redo-jch.sh script with
- This step is helped with Meta/git-topic.perl script to
- identify which topic is rebaseable. There also is a
- pre-rebase hook to make sure that topics that are already in
- 'next' are not rebased beyond the merged commit.
+ $ sh Meta/redo-jch.sh -u
- - [** OBSOLETE **] Rebuild "pu" to merge the tips of topics not in 'next'.
+ This removes topics listed in the script that have already been
+ merged to 'master'. This may lose '### match next' marker;
+ add it again to the appropriate place when it happens.
- $ git checkout pu
- $ git reset --hard next
- $ git merge ai/topic ;# repeat for all remaining topics
- $ make test
+ - Rebuild 'pu'.
- This step is helped with Meta/PU script
+ $ Meta/Reintegrate master..pu >Meta/redo-pu.sh
- - Push four integration branches to a private repository at
- k.org and run "make test" on all of them.
+ Edit the result by adding new topics that are not still in 'pu'
+ in the script. Then
- - Push four integration branches to /pub/scm/git/git.git at
- k.org. This triggers its post-update hook which:
+ $ git checkout -B pu jch
+ $ sh Meta/redo-pu.sh
- (1) runs "git pull" in $HOME/git-doc/ repository to pull
- 'master' just pushed out;
+ When all is well, clean up the redo-pu.sh script with
- (2) runs "make doc" in $HOME/git-doc/, install the generated
- documentation in staging areas, which are separate
- repositories that have html and man branches checked
- out.
+ $ sh Meta/redo-pu.sh -u
- (3) runs "git commit" in the staging areas, and run "git
- push" back to /pub/scm/git/git.git/ to update the html
- and man branches.
+ Double check by running
- (4) installs generated documentation to /pub/software/scm/git/docs/
- to be viewed from http://www.kernel.org/
+ $ git branch --no-merged pu
- - Fetch html and man branches back from k.org, and push four
- integration branches and the two documentation branches to
- repo.or.cz and other mirrors.
+ to see there is no unexpected leftover topics.
+ At this point, build-test the result for semantic conflicts, and
+ if there are, prepare an appropriate merge-fix first (see
+ appendix), and rebuild the 'pu' branch from scratch, starting at
+ the tip of 'jch'.
+
+ - Update "What's cooking" message to review the updates to
+ existing topics, newly added topics and graduated topics.
+
+ This step is helped with Meta/cook script.
+
+ $ Meta/cook
+
+ This script inspects the history between master..pu, finds tips
+ of topic branches, compares what it found with the current
+ contents in Meta/whats-cooking.txt, and updates that file.
+ Topics not listed in the file but are found in master..pu are
+ added to the "New topics" section, topics listed in the file that
+ are no longer found in master..pu are moved to the "Graduated to
+ master" section, and topics whose commits changed their states
+ (e.g. used to be only in 'pu', now merged to 'next') are updated
+ with change markers "<<" and ">>".
+
+ Look for lines enclosed in "<<" and ">>"; they hold contents from
+ old file that are replaced by this integration round. After
+ verifying them, remove the old part. Review the description for
+ each topic and update its doneness and plan as needed. To review
+ the updated plan, run
+
+ $ Meta/cook -w
+
+ which will pick up comments given to the topics, such as "Will
+ merge to 'next'", etc. (see Meta/cook script to learn what kind
+ of phrases are supported).
+
+ - Compile, test and install all four (five) integration branches;
+ Meta/Dothem script may aid this step.
+
+ - Format documentation if the 'master' branch was updated;
+ Meta/dodoc.sh script may aid this step.
+
+ - Push the integration branches out to public places; Meta/pushall
+ script may aid this step.
+
+Observations
+------------
Some observations to be made.
- * Each topic is tested individually, and also together with
- other topics cooking in 'next'. Until it matures, none part
- of it is merged to 'master'.
+ * Each topic is tested individually, and also together with other
+ topics cooking first in 'pu', then in 'jch' and then in 'next'.
+ Until it matures, no part of it is merged to 'master'.
* A topic already in 'next' can get fixes while still in
'next'. Such a topic will have many merges to 'next' (in
other words, "git log --first-parent next" will show many
- "Merge ai/topic to next" for the same topic.
+ "Merge branch 'ai/topic' to next" for the same topic.
* An unobvious fix for 'maint' is cooked in 'next' and then
merged to 'master' to make extra sure it is Ok and then
* Being in the 'next' branch is not a guarantee for a topic to
be included in the next feature release. Being in the
'master' branch typically is.
+
+
+Appendix
+--------
+
+Preparing a "merge-fix"
+~~~~~~~~~~~~~~~~~~~~~~~
+
+A merge of two topics may not textually conflict but still have
+conflict at the semantic level. A classic example is for one topic
+to rename an variable and all its uses, while another topic adds a
+new use of the variable under its old name. When these two topics
+are merged together, the reference to the variable newly added by
+the latter topic will still use the old name in the result.
+
+The Meta/Reintegrate script that is used by redo-jch and redo-pu
+scripts implements a crude but usable way to work this issue around.
+When the script merges branch $X, it checks if "refs/merge-fix/$X"
+exists, and if so, the effect of it is squashed into the result of
+the mechanical merge. In other words,
+
+ $ echo $X | Meta/Reintegrate
+
+is roughly equivalent to this sequence:
+
+ $ git merge --rerere-autoupdate $X
+ $ git commit
+ $ git cherry-pick -n refs/merge-fix/$X
+ $ git commit --amend
+
+The goal of this "prepare a merge-fix" step is to come up with a
+commit that can be squashed into a result of mechanical merge to
+correct semantic conflicts.
+
+After finding that the result of merging branch "ai/topic" to an
+integration branch had such a semantic conflict, say pu~4, check the
+problematic merge out on a detached HEAD, edit the working tree to
+fix the semantic conflict, and make a separate commit to record the
+fix-up:
+
+ $ git checkout pu~4
+ $ git show -s --pretty=%s ;# double check
+ Merge branch 'ai/topic' to pu
+ $ edit
+ $ git commit -m 'merge-fix/ai/topic' -a
+
+Then make a reference "refs/merge-fix/ai/topic" to point at this
+result:
+
+ $ git update-ref refs/merge-fix/ai/topic HEAD
+
+Then double check the result by asking Meta/Reintegrate to redo the
+merge:
+
+ $ git checkout pu~5 ;# the parent of the problem merge
+ $ echo ai/topic | Meta/Reintegrate
+ $ git diff pu~4
+
+This time, because you prepared refs/merge-fix/ai/topic, the
+resulting merge should have been tweaked to include the fix for the
+semantic conflict.
+
+Note that this assumes that the order in which conflicting branches
+are merged does not change. If the reason why merging ai/topic
+branch needs this merge-fix is because another branch merged earlier
+to the integration branch changed the underlying assumption ai/topic
+branch made (e.g. ai/topic branch added a site to refer to a
+variable, while the other branch renamed that variable and adjusted
+existing use sites), and if you changed redo-jch (or redo-pu) script
+to merge ai/topic branch before the other branch, then the above
+merge-fix should not be applied while merging ai/topic, but should
+instead be applied while merging the other branch. You would need
+to move the fix to apply to the other branch, perhaps like this:
+
+ $ mf=refs/merge-fix
+ $ git update-ref $mf/$the_other_branch $mf/ai/topic
+ $ git update-ref -d $mf/ai/topic
`DIR_NO_GITLINKS`:::
- If set, recurse into a directory that looks like a git
+ If set, recurse into a directory that looks like a Git
directory. Otherwise it is shown as a directory.
The result of the enumeration is left in these fields:
* Prepare `struct dir_struct dir` and clear it with `memset(&dir, 0,
sizeof(dir))`.
-* Call `add_exclude()` to add single exclude pattern,
- `add_excludes_from_file()` to add patterns from a file
- (e.g. `.git/info/exclude`), and/or set `dir.exclude_per_dir`. A
- short-hand function `setup_standard_excludes()` can be used to set up
- the standard set of exclude settings.
+* To add single exclude pattern, call `add_exclude_list()` and then
+ `add_exclude()`.
+
+* To add patterns from a file (e.g. `.git/info/exclude`), call
+ `add_excludes_from_file()` , and/or set `dir.exclude_per_dir`. A
+ short-hand function `setup_standard_excludes()` can be used to set
+ up the standard set of exclude settings.
* Set options described in the Data Structure section above.
* Use `dir.entries[]`.
+* Call `clear_directory()` when none of the contained elements are no longer in use.
+
(JC)
////////////////////////////////////////////////////////////////
- GIT - the stupid content tracker
+ Git - the stupid content tracker
////////////////////////////////////////////////////////////////
Documentation/SubmittingPatches for instructions on patch submission).
To subscribe to the list, send an email with just "subscribe git" in
the body to majordomo@vger.kernel.org. The mailing list archives are
-available at http://marc.theaimsgroup.com/?l=git and other archival
-sites.
-
-The messages titled "A note from the maintainer", "What's in
-git.git (stable)" and "What's cooking in git.git (topics)" and
-the discussion following them on the mailing list give a good
-reference for project status, development direction and
-remaining tasks.
+available at http://news.gmane.org/gmane.comp.version-control.git/,
+http://marc.info/?l=git and other archival sites.
+
+The maintainer frequently sends the "What's cooking" reports that
+list the current status of various development topics to the mailing
+list. The discussion following them give a good reference for
+project status, development direction and remaining tasks.