In order to employ signed keys in an automated way it is absolutely
necessary to check which keys the signatures come from.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
pathspec is the most widely used term, and is the one defined in
gitglossary.txt. <filepattern> was used only in the synopsys for git-add
and git-commit, and in git-add.txt. Get rid of it.
This patch is obtained with by running:
perl -pi -e 's/filepattern/pathspec/' `git grep -l filepattern`
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"reset" can be easily misunderstood as resetting a bisect session to its
start without finishing it. Clarify that it actually quits the bisect
session.
Reported-by: Andreas Mohr <andi@lisas.de>
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This should have happened back in 2007, when `git gc` learned about
auto (e9831e8, git-gc --auto: add documentation, 2007-09-17).
Signed-off-by: W. Trevor King <wking@tremily.us>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use an em-dash, not a hyphen, to join these clauses.
Signed-off-by: W. Trevor King <wking@tremily.us>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
HTTP is an acronym which has not (yet) made the transition to word
status (unlike "laser", probably because lasers are inherently cooler
than HTTP ;).
Signed-off-by: W. Trevor King <wking@tremily.us>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The clause "so `git log ...` will return no commits..." is
independent, not a description of "both", so a semicolon is more
appropriate.
Signed-off-by: W. Trevor King <wking@tremily.us>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The current description requires a bit of guessing (what clause
corresponds to what printed line?) and lacks information, such as
the unit of size and size-pack.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Build on top of the clean-up done by jk/mergetool and automatically
generate the list of mergetool and difftool backends the build
supports to be included in the documentation.
* da/mergetool-docs:
doc: generate a list of valid merge tools
mergetool--lib: list user configured tools in '--tool-help'
mergetool--lib: add functions for finding available tools
mergetool--lib: improve the help text in guess_merge_tool()
mergetool--lib: simplify command expressions
"git help remote-helpers" did not work; 'remote-helpers' is not
a subcommand name but a concept, so its documentation should have
been in gitremote-helpers, not git-remote-helpers.
* jk/remote-helpers-doc:
Rename {git- => git}remote-helpers.txt
Fix various error messages and conditions in "git branch", e.g. we
advertised "branch -d/-D" to remove one or more branches but actually
implemented removal of zero or more branches---request to remove no
branches was not rejected.
* nd/branch-error-cases:
branch: let branch filters imply --list
docs: clarify git-branch --list behavior
branch: mark more strings for translation
branch: give a more helpful message on redundant arguments
branch: reject -D/-d without branch name
With uploadpack.allowtipsha1inwant configuration option set, future
versions of "git fetch" that allow an exact object name (likely to
have been obtained out of band) on the LHS of the fetch refspec can
make a request with a "want" line that names an object that may not
have been advertised due to transfer.hiderefs configuration.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A repository may have refs that are only used for its internal
bookkeeping purposes that should not be exposed to the others that
come over the network.
Teach upload-pack to omit some refs from its initial advertisement
by paying attention to the uploadpack.hiderefs multi-valued
configuration variable. Do the same to receive-pack via the
receive.hiderefs variable. As a convenient short-hand, allow using
transfer.hiderefs to set the value to both of these variables.
Any ref that is under the hierarchies listed on the value of these
variable is excluded from responses to requests made by "ls-remote",
"fetch", etc. (for upload-pack) and "push" (for receive-pack).
Because these hidden refs do not count as OUR_REF, an attempt to
fetch objects at the tip of them will be rejected, and because these
refs do not get advertised, "git push :" will not see local branches
that have the same name as them as "matching" ones to be sent.
An attempt to update/delete these hidden refs with an explicit
refspec, e.g. "git push origin :refs/hidden/22", is rejected. This
is not a new restriction. To the pusher, it would appear that there
is no such ref, so its push request will conclude with "Now that I
sent you all the data, it is time for you to update the refs. I saw
that the ref did not exist when I started pushing, and I want the
result to point at this commit". The receiving end will apply the
compare-and-swap rule to this request and rejects the push with
"Well, your update request conflicts with somebody else; I see there
is such a ref.", which is the right thing to do. Otherwise a push to
a hidden ref will always be "the last one wins", which is not a good
default.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Update documentation to change "GIT" which was a poor-man's small
caps to "Git". The latter was the intended spelling.
Also change "git" spelled in all-lowercase to "Git" when it refers
to the system as the whole or the concept it embodies, as opposed to
the command the end users would type.
* ta/doc-no-small-caps:
Documentation: StGit is the right spelling, not StGIT
Documentation: describe the "repository" in repository-layout
Documentation: add a description for 'gitfile' to glossary
Documentation: do not use undefined terms git-dir and git-file
Documentation: the name of the system is 'Git', not 'git'
Documentation: avoid poor-man's small caps GIT
Forbid "git add -u" and "git add -A" without pathspec run from a
subdirectory, to train people to type "." (or ":/") to make the
choice of default does not matter.
* mm/add-u-A-sans-pathspec:
add: warn when -u or -A is used without pathspec
Improve error and advice messages given locally when "git push"
refuses when it cannot compute fast-forwardness by separating these
cases from the normal "not a fast-forward; merge first and push
again" case.
* jc/push-reject-reasons:
push: finishing touches to explain REJECT_ALREADY_EXISTS better
push: introduce REJECT_FETCH_FIRST and REJECT_NEEDS_FORCE
push: further simplify the logic to assign rejection reason
push: further clean up fields of "struct ref"
Allow a configuration variable core.commentchar to customize the
character used to comment out the hint lines in the edited text from
the default '#'.
* jc/custom-comment-char:
Allow custom "comment char"
Use the show_tool_names() function to build lists of all
the built-in tools supported by difftool and mergetool.
This frees us from needing to update the documentation
whenever a new tool is added.
Signed-off-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When looking up a topic via "git help <topic>", git-help prepends "git-"
to topics that are the names of commands (either builtin or found on the
path) and "git" (no hyphen) to any other topic name.
"git-remote-helpers" is not the name of a command, so "git help
remote-helpers" looks for "gitremote-helpers" and does not find it.
Fix this by renaming "git-remote-helpers.txt" to
"gitremote-helpers.txt".
Signed-off-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
They refer themselves as such at https://gna.org/projects/stgit/
Signed-off-by: Thomas Ackermann <th.acker@arcor.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Update the introductory part and concisely explain how gitfile is
handled, what it is used for and for what effect.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We will add gitfile to the glossary in a separate commit.
Signed-off-by: Thomas Ackermann <th.acker@arcor.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In the earlier days, we used to spell the name of the system as GIT,
to simulate as if it were typeset with capital G and IT in small
caps. Later we stopped doing so at around 1.6.5 days.
Let's stop doing so throughout the documentation. The name to refer
to the whole system (and the concept it embodies) is "Git"; the
command end-users type is "git". And document this in the coding
guideline.
Signed-off-by: Thomas Ackermann <th.acker@arcor.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Warn people that other tools are more recommendable over
cvsimport+cvsps2 combo when doing a one-shot import, and cvsimport
will not work with cvsps3.
* jk/cvsimport-does-not-work-with-cvsps3:
git-cvsimport.txt: cvsps-2 is deprecated
"git fetch --depth" was broken in at least three ways. The
resulting history was deeper than specified by one commit, it was
unclear how to wipe the shallowness of the repository with the
command, and documentation was misleading.
* nd/fetch-depth-is-broken:
fetch: elaborate --depth action
upload-pack: fix off-by-one depth calculation in shallow clone
fetch: add --unshallow for turning shallow repo into complete one
We keep a list of the various files that end up as man1,
man5, etc. Let's break these single-line lists into sorted
multi-line lists, which makes diffs that touch them much
easier to read.
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When looking at a configuration file edited long time ago, a user
may find 'pull.default = tracking' and wonder what it means, but
earlier we stopped mentioning this value, even though the code still
support it and more importantly, we have no intention to force old
timers to update their configuration files.
Instead of not mentioning it, add it to the description in a way
that makes it clear that users have no reason to add new uses of it
preferring over 'upstream', by not listing it as a separate item on
the same footing as other values but as a deprecated synonym of the
'upstream' in its description.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently, a branch filter like `--contains`, `--merged`, or
`--no-merged` is ignored when we are not in listing mode.
For example:
git branch --contains=foo bar
will create the branch "bar" from the current HEAD, ignoring
the `--contains` argument entirely. This is not very
helpful. There are two reasonable behaviors for git here:
1. Flag an error; the arguments do not make sense.
2. Implicitly go into `--list` mode
This patch chooses the latter, as it is more convenient, and
there should not be any ambiguity with attempting to create
a branch; using `--contains` and not wanting to list is
nonsensical.
That leaves the case where an explicit modification option
like `-d` is given. We already catch the case where
`--list` is given alongside `-d` and flag an error. With
this patch, we will also catch the use of `--contains` and
other filter options alongside `-d`.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It was not clear from the "description" section of git-branch(1)
that using a <pattern> meant that you _had_ to use the --list
option. Let's clarify that, and while we're at it, reword some
clunky and ambiguous sentences.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These are kept short by simply deferring to PEP-8. Most of the Python
code in Git is already very close to this style (some things in contrib/
are not).
Rationale for version suggestions:
- Amongst the noise in [1], there isn't any disagreement about using
2.6 as a base (see also [2]), although Brandon Casey recently added
support for 2.4 and 2.5 to git-p4 [3].
- Restricting ourselves to 2.6+ makes aiming for Python 3 compatibility
significantly easier [4].
- Advocating Python 3 support in all scripts is currently unrealistic
because:
- 'p4 -G' provides output in a format that is very hard to use with
Python 3 (and its documentation claims Python 3 is unsupported).
- Mercurial does not support Python 3.
- Bazaar does not support Python 3.
- But we should try to make new scripts compatible with Python 3
because all new Python development is happening on version 3 and the
Python community will eventually stop supporting Python 2 [5].
- Python 3.1 is required to support the 'surrogateescape' error handler
for encoding/decodng filenames to/from Unicode strings and Python 3.0
is not longer supported.
[1] http://thread.gmane.org/gmane.comp.version-control.git/210329
[2] http://article.gmane.org/gmane.comp.version-control.git/210429
[3] http://thread.gmane.org/gmane.comp.version-control.git/214579
[4] http://docs.python.org/3.3/howto/pyporting.html#try-to-support-python-2-6-and-newer-only
[5] http://www.python.org/dev/peps/pep-0404/
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some reimplementations of Git does not write all the stat info back
to the index due to their implementation limitations (e.g. jgit
running on Java). A configuration option can tell Git to ignore
changes to most of the stat fields and only pay attention to mtime
and size, which these implementations can reliably update. This
avoids excessive revalidation of contents.
* rr/minimal-stat:
Enable minimal stat checking
An element on GIT_CEILING_DIRECTORIES list that does not name the
real path to a directory (i.e. a symbolic link) could have caused
the GIT_DIR discovery logic to escape the ceiling.
* mh/ceiling:
string_list_longest_prefix(): remove function
setup_git_directory_gently_1(): resolve symlinks in ceiling paths
longest_ancestor_length(): require prefix list entries to be normalized
longest_ancestor_length(): take a string_list argument for prefixes
longest_ancestor_length(): use string_list_split()
Introduce new function real_path_if_valid()
real_path_internal(): add comment explaining use of cwd
Introduce new static function real_path_internal()
Most Git commands that can be used with or without pathspec operate
tree-wide by default, the pathspec being used to restrict their
scope. A few exceptions are: 'git grep', 'git clean', 'git add -u'
and 'git add -A'. When run in a subdirectory without pathspec, they
operate only on paths in the current directory.
The inconsistency of 'git add -u' and 'git add -A' is particularly
problematic since other 'git add' subcommands (namely 'git add -p'
and 'git add -e') are tree-wide by default. It also means that "git
add -u && git commit" will record a state that is different from
what is recorded with "git commit -a".
Flipping the default now is unacceptable, so let's start training
users to type 'git add -u|-A :/' or 'git add -u|-A .' explicitly, to
prepare for the next steps:
* forbid 'git add -u|-A' without pathspec (like 'git add' without
option)
* much later, maybe, re-allow 'git add -u|-A' without pathspec, that
will add all tracked and modified files, or all files, tree-wide.
A nice side effect of this patch is that it makes the :/ magic
pathspec easier to discover for users.
When the command is called from the root of the tree, there is no
ambiguity and no need to change the behavior, hence no need to warn.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Describe tools for automation that were invented since this
document was originally written.
* jc/doc-maintainer:
howto/maintain: document "### match next" convention in jch/pu branch
howto/maintain: mark titles for asciidoc
Documentation: update "howto maintain git"
When we push to update an existing ref, if:
* the object at the tip of the remote is not a commit; or
* the object we are pushing is not a commit,
it won't be correct to suggest to fetch, integrate and push again,
as the old and new objects will not "merge". We should explain that
the push must be forced when there is a non-committish object is
involved in such a case.
If we do not have the current object at the tip of the remote, we do
not even know that object, when fetched, is something that can be
merged. In such a case, suggesting to pull first just like
non-fast-forward case may not be technically correct, but in
practice, most such failures are seen when you try to push your work
to a branch without knowing that somebody else already pushed to
update the same branch since you forked, so "pull first" would work
as a suggestion most of the time. And if the object at the tip is
not a commit, "pull first" will fail, without making any permanent
damage. As a side effect, it also makes the error message the user
will get during the next "push" attempt easier to understand, now
the user is aware that a non-commit object is involved.
In these cases, the current code already rejects such a push on the
client end, but we used the same error and advice messages as the
ones used when rejecting a non-fast-forward push, i.e. pull from
there and integrate before pushing again.
Introduce new rejection reasons and reword the messages
appropriately.
[jc: with help by Peff on message details]
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-cvsimport relies on version 2 of cvsps and does not work with the
new version 3. Since cvsps 3.x does not currently work as well as
version 2 for incremental import, document this fact.
Specifically, there is no way to make new git-cvsimport that supports
cvsps 3.x and have a seamless transition for existing users since cvsps
3.x needs a time from which to continue importing and git-cvsimport does
not save the time of the last import or import into a specific namespace
so there is no safe way to calculate the time of the last import.
Signed-off-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add an extra hook so that "git push" that is run without making
sure what is being pushed is sane can be checked and rejected (as
opposed to the user deciding not pushing).
* as/pre-push-hook:
Add sample pre-push hook script
push: Add support for pre-push hooks
hooks: Add function to check if a hook exists
Add a new command "git check-ignore" for debugging .gitignore
files.
The variable names may want to get cleaned up but that can be done
in-tree.
* as/check-ignore:
clean.c, ls-files.c: respect encapsulation of exclude_list_groups
t0008: avoid brace expansion
add git-check-ignore sub-command
setup.c: document get_pathspec()
add.c: extract new die_if_path_beyond_symlink() for reuse
add.c: extract check_path_for_gitlink() from treat_gitlinks() for reuse
pathspec.c: rename newly public functions for clarity
add.c: move pathspec matchers into new pathspec.c for reuse
add.c: remove unused argument from validate_pathspec()
dir.c: improve docs for match_pathspec() and match_pathspec_depth()
dir.c: provide clear_directory() for reclaiming dir_struct memory
dir.c: keep track of where patterns came from
dir.c: use a single struct exclude_list per source of excludes
Conflicts:
builtin/ls-files.c
dir.c
Various git-cvsserver updates.
* mo/cvs-server-updates:
t9402: Use TABs for indentation
t9402: Rename check.cvsCount and check.list
t9402: Simplify git ls-tree
t9402: Add missing &&; Code style
t9402: No space after IO-redirection
t9402: Dont use test_must_fail cvs
t9402: improve check_end_tree() and check_end_full_tree()
t9402: sed -i is not portable
cvsserver Documentation: new cvs ... -r support
cvsserver: add t9402 to test branch and tag refs
cvsserver: support -r and sticky tags for most operations
cvsserver: Add version awareness to argsfromdir
cvsserver: generalize getmeta() to recognize commit refs
cvsserver: implement req_Sticky and related utilities
cvsserver: add misc commit lookup, file meta data, and file listing functions
cvsserver: define a tag name character escape mechanism
cvsserver: cleanup extra slashes in filename arguments
cvsserver: factor out git-log parsing logic
Various 'reset' optimizations and clean-ups, followed by a change
to allow "git reset" to work even on an unborn branch.
* mz/reset-misc:
reset: update documentation to require only tree-ish with paths
reset [--mixed]: use diff-based reset whether or not pathspec was given
reset: allow reset on unborn branch
reset $sha1 $pathspec: require $sha1 only to be treeish
reset.c: inline update_index_refresh()
reset.c: finish entire cmd_reset() whether or not pathspec is given
reset [--mixed]: only write index file once
reset.c: move lock, write and commit out of update_index_refresh()
reset.c: move update_index_refresh() call out of read_from_tree()
reset.c: replace switch by if-else
reset: avoid redundant error message
reset --keep: only write index file once
reset.c: share call to die_if_unmerged_cache()
reset.c: extract function for updating {ORIG_,}HEAD
reset.c: remove unnecessary variable 'i'
reset.c: extract function for parsing arguments
reset: don't allow "git reset -- $pathspec" in bare repo
reset.c: pass pathspec around instead of (prefix, argv) pair
reset $pathspec: exit with code 0 if successful
reset $pathspec: no need to discard index
Specifically the fields uid, gid, ctime, ino and dev are set to zero
by JGit. Other implementations, eg. Git in cygwin are allegedly also
somewhat incompatible with Git For Windows and on *nix platforms
the resolution of the timestamps may differ.
Any stat checking by git will then need to check content, which may
be very slow, particularly on Windows. Since mtime and size
is typically enough we should allow the user to tell git to avoid
checking these fields if they are set to zero in the index.
This change introduces a core.checkstat config option where the
the user can select to check all fields (default), or just size
and the whole second part of mtime (minimal).
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 7dff9b3 (Support 'raw' date format) added a raw date format.
Update the git-for-each-ref documentation to include this.
Signed-off-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add a configuration variable to set default clean-up mode other
than "strip".
* rt/commit-cleanup-config:
commit: make default of "cleanup" option configurable
Teach commands in the "log" family to optionally pay attention to
the mailmap.
* ap/log-mailmap:
log --use-mailmap: optimize for cases without --author/--committer search
log: add log.mailmap configuration option
log: grep author/committer using mailmap
test: add test for --use-mailmap option
log: add --use-mailmap option
pretty: use mailmap to display username and email
mailmap: add mailmap structure to rev_info and pp
mailmap: simplify map_user() interface
mailmap: remove email copy and length limitation
Use split_ident_line to parse author and committer
string-list: allow case-insensitive string list
* git://bogomips.org/git-svn:
git-svn: teach find-rev to find near matches
git svn: do not overescape URLs (fallback case)
Git::SVN::Editor::T: pass $deletions to ->A and ->D
In the precedence order, the environment variable $EMAIL comes
between the built-in default (i.e. taking value by asking the
system's gethostname() etc.) and the user.email configuration
variable; the documentation implied that it is stronger than the
configuration like $GIT_COMMITTER_EMAIL is, which is wrong.
* pe/doc-email-env-is-trumped-by-config:
git-commit-tree(1): correct description of defaults
Add support for a pre-push hook which can be used to determine if the
set of refs to be pushed is suitable for the target repository. The
hook is run with two arguments specifying the name and location of the
destination repository.
Information about what is to be pushed is provided by sending lines of
the following form to the hook's standard input:
<local ref> SP <local sha1> SP <remote ref> SP <remote sha1> LF
If the hook exits with a non-zero status, the push will be aborted.
This will allow the script to determine if the push is acceptable based
on the target repository and branch(es), the commits which are to be
pushed, and even the source branches in some cases.
Signed-off-by: Aaron Schrab <aaron@schrab.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When a single SVN repository is split into multiple Git repositories
many SVN revisions will exist in only one of the Git repositories
created. For some projects the only way to build a working artifact is
to check out corresponding versions of various repositories, with no
indication of what those are in the Git world - in the SVN world the
revision numbers are sufficient.
By adding "--before" to "git-svn find-rev" we can say "tell me what this
repository looked like when that other repository looked like this":
git svn find-rev --before \
r$(git --git-dir=/over/there.git svn find-rev HEAD)
Signed-off-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
When resetting with paths, we no longer require a commit argument, but
only a tree-ish. Update the documentation and synopsis accordingly.
Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some users do want to write a line that begin with a pound sign, #,
in their commit log message. Many tracking system recognise
a token of #<bugid> form, for example.
The support we offer these use cases is not very friendly to the end
users. They have a choice between
- Don't do it. Avoid such a line by rewrapping or indenting; and
- Use --cleanup=whitespace but remove all the hint lines we add.
Give them a way to set a custom comment char, e.g.
$ git -c core.commentchar="%" commit
so that they do not have to do either of the two workarounds.
[jc: although I started the topic, all the tests and documentation
updates, many of the call sites of the new strbuf_add_commented_*()
functions, and the change to git-submodule.sh scripted Porcelain are
from Ralf.]
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since command line options have higher priority than config file
variables and taking previous commit into account, we need a way
how to specify myers algorithm on command line. However,
inventing `--myers` is not the right answer. We need far more
general option, and that is `--diff-algorithm`.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some users or projects prefer different algorithms over others, e.g.
patience over myers or similar. However, specifying appropriate
argument every time diff is to be used is impractical. Moreover,
creating an alias doesn't play nicely with other tools based on diff
(git-show for instance). Hence, a configuration variable which is able
to set specific algorithm is needed. For now, these four values are
accepted: 'myers' (which has the same effect as not setting the config
variable at all), 'minimal', 'patience' and 'histogram'.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It finds its upstream and applies the commit properly, but
the sync step will fail unless it is told which branch to
work on.
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It is legal to sync a branch with a different name than
refs/remotes/p4/master, and to do so even when master does
not exist.
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
For a clone or sync, --branch says where the newly imported
branch should go, or which existing branch to sync up. It
takes an argument, which is currently either something that
starts with "refs/", or if not, "refs/heads/p4" is prepended.
Putting it in heads seems like a bad default; these should
go in remotes/p4/ in most situations. Make that the new default,
and be more liberal in the form of the branch name.
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make sure that the example on how to use git-p4.branchList
works if typed directly. In particular, it does not make sense
to set a config variable until the git repository has been
initialized.
Reported-by: Olivier Delalleau <shish@keba.be>
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When using the --branch argument to "git p4 clone", one
might specify a destination for p4 changes different from
the default refs/remotes/p4/master. Both cases should
create a master branch and checkout files.
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The internal logic had to deal with two representations of a death
of a child process by a signal.
* jk/unify-exit-code-by-receiving-signal:
run-command: encode signal death as a positive integer
Teach "format-patch" to prefix v4- to its output files for the
fourth iteration of a patch series, to make it easier for the
submitter to keep separate copies for iterations.
* jc/format-patch-reroll:
format-patch: give --reroll-count a short synonym -v
format-patch: document and test --reroll-count
format-patch: add --reroll-count=$N option
get_patch_filename(): split into two functions
get_patch_filename(): drop "just-numbers" hack
get_patch_filename(): simplify function signature
builtin/log.c: stop using global patch_suffix
builtin/log.c: drop redundant "numbered_files" parameter from make_cover_letter()
builtin/log.c: drop unused "numbered" parameter from make_cover_letter()
* jc/submittingpatches:
SubmittingPatches: give list and maintainer addresses
SubmittingPatches: remove overlong checklist
SubmittingPatches: mention subsystems with dedicated repositories
SubmittingPatches: who am I and who cares?
When attempting to read the XDG-style $HOME/.config/git/config and
finding that $HOME/.config/git is a file, we gave a wrong error
message, instead of treating the case as "a custom config file does
not exist there" and moving on.
* jn/warn-on-inaccessible-loosen:
config: exit on error accessing any config file
doc: advertise GIT_CONFIG_NOSYSTEM
config: treat user and xdg config permission problems as errors
config, gitignore: failure to access with ENOTDIR is ok
--depth is explained as deepen, but the way it's applied, it can
shorten the history as well. Keen users may have noticed the
implication by the phrase "the specified number of commits from the
tip of each remote branch". Put "shorten" in the description to make
it clearer.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The user can do --depth=2147483647 (*) for restoring complete repo
now. But it's hard to remember. Any other numbers larger than the
longest commit chain in the repository would also do, but some
guessing may be involved. Make easy-to-remember --unshallow an alias
for --depth=2147483647.
Make upload-pack recognize this special number as infinite depth. The
effect is essentially the same as before, except that upload-pack is
more efficient because it does not have to traverse to the bottom
anymore.
The chance of a user actually wanting exactly 2147483647 commits
depth, not infinite, on a repository with a history that long, is
probably too small to consider. The client can learn to add or
subtract one commit to avoid the special treatment when that actually
happens.
(*) This is the largest positive number a 32-bit signed integer can
contain. JGit and older C Git store depth as "int" so both are OK
with this number. Dulwich does not support shallow clone.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Refactor and generally clean up the directory traversal API
implementation.
* as/dir-c-cleanup:
dir.c: rename free_excludes() to clear_exclude_list()
dir.c: refactor is_path_excluded()
dir.c: refactor is_excluded()
dir.c: refactor is_excluded_from_list()
dir.c: rename excluded() to is_excluded()
dir.c: rename excluded_from_list() to is_excluded_from_list()
dir.c: rename path_excluded() to is_path_excluded()
dir.c: rename cryptic 'which' variable to more consistent name
Improve documentation and comments regarding directory traversal API
api-directory-listing.txt: update to match code
Allows pathname patterns in .gitignore and .gitattributes files
with double-asterisks "foo/**/bar" to match any number of directory
hierarchies.
* nd/wildmatch:
wildmatch: replace variable 'special' with better named ones
compat/fnmatch: respect NO_FNMATCH* even on glibc
wildmatch: fix "**" special case
t3070: Disable some failing fnmatch tests
test-wildmatch: avoid Windows path mangling
Support "**" wildcard in .gitignore and .gitattributes
wildmatch: make /**/ match zero or more directories
wildmatch: adjust "**" behavior
wildmatch: fix case-insensitive matching
wildmatch: remove static variable force_lower_case
wildmatch: make wildmatch's return value compatible with fnmatch
t3070: disable unreliable fnmatch tests
Integrate wildmatch to git
wildmatch: follow Git's coding convention
wildmatch: remove unnecessary functions
Import wildmatch from rsync
ctype: support iscntrl, ispunct, isxdigit and isprint
ctype: make sane_ctype[] const array
Conflicts:
Makefile
Teach "log.mailmap" configuration variable to turn "--use-mailmap"
option on to "git log", "git show" and "git whatchanged".
The "--no-use-mailmap" option from the command line can countermand
the setting.
Signed-off-by: Antoine Pelisse <apelisse@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add the --use-mailmap option to log commands. It allows to display
names from mailmap file when displaying logs, whatever the format
used.
Signed-off-by: Antoine Pelisse <apelisse@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The default of the "cleanup" option in "git commit"
is not configurable. Users who don't want to use the
default have to pass this option on every commit since
there's no way to configure it. This commit introduces
a new config option "commit.cleanup" which can be used
to change the default of the "cleanup" option in
"git commit".
Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The old phrasing indicated that the EMAIL environment variable takes
precedence over the user.email configuration setting, but it is the
other way around.
Signed-off-by: Peter Eisentraut <peter@eisentraut.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The options in git-fast-import(1) are not currently arranged in a
logical order, which has caused the '--done' options to be documented
twice (commit 3266de10).
Rearrange them into logical groups under subheadings.
Suggested-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The descriptions of '--relative-marks' and '--no-relative-marks' make
more sense when read together instead of as two independent options.
Combine them into a single description block.
Signed-off-by: John Keeping <john@keeping.me.uk>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 00d3947 (Teach --wrap to only indent without wrapping) added
special behaviour for a width of zero in the '-w' argument to
'git-shortlog' but this was not documented. Fix this.
Signed-off-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Teach various forms of "format-patch" command line to identify what
branch the patches are taken from, so that the branch description
is picked up in more cases.
* nd/maint-branch-desc-doc:
format-patch: pick up branch description when no ref is specified
format-patch: pick up correct branch name from symbolic ref
t4014: a few more tests on cover letter using branch description
branch: delete branch description if it's empty
config.txt: a few lines about branch.<name>.description
Streamline the document and update with a few e-mail addresses the
patches should be sent to.
* jc/submittingpatches:
SubmittingPatches: give list and maintainer addresses
SubmittingPatches: remove overlong checklist
SubmittingPatches: mention subsystems with dedicated repositories
SubmittingPatches: who am I and who cares?
The '--done' option to git-fast-import is documented twice in its manual
page. Combine the best bits of each description, keeping the location
of the instance that was added first.
Signed-off-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Deal with a situation where .config/git is a file and we notice
.config/git/config is not readable due to ENOTDIR, not ENOENT.
* jn/warn-on-inaccessible-loosen:
config: exit on error accessing any config file
doc: advertise GIT_CONFIG_NOSYSTEM
config: treat user and xdg config permission problems as errors
config, gitignore: failure to access with ENOTDIR is ok
By the end of a directory traversal, a dir_struct instance will
typically contains pointers to various data structures on the heap.
clear_directory() provides a convenient way to reclaim that memory.
Signed-off-by: Adam Spiers <git@adamspiers.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously each exclude_list could potentially contain patterns
from multiple sources. For example dir->exclude_list[EXC_FILE]
would typically contain patterns from .git/info/exclude and
core.excludesfile, and dir->exclude_list[EXC_DIRS] could contain
patterns from multiple per-directory .gitignore files during
directory traversal (i.e. when dir->exclude_stack was more than
one item deep).
We split these composite exclude_lists up into three groups of
exclude_lists (EXC_CMDL / EXC_DIRS / EXC_FILE as before), so that each
exclude_list now contains patterns from a single source. This will
allow us to cleanly track the origin of each pattern simply by adding
a src field to struct exclude_list, rather than to struct exclude,
which would make memory management of the source string tricky in the
EXC_DIRS case where its contents are dynamically generated.
Similarly, by moving the filebuf member from struct exclude_stack to
struct exclude_list, it allows us to track and subsequently free
memory buffers allocated during the parsing of all exclude files,
rather than only tracking buffers allocated for files in the EXC_DIRS
group.
Signed-off-by: Adam Spiers <git@adamspiers.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The documentation for the ALLOC_GROW API implicitly encouraged
developers to use "ary" as the variable name for the array which is
dynamically grown. However "ary" is an unusual abbreviation hardly
used anywhere else in the source tree, and it is also better to name
variables based on their contents not on their type.
Signed-off-by: Adam Spiers <git@adamspiers.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When building manual pages, the source text is transformed to XML with
AsciiDoc before the man pages are generated from the XML with xmlto.
Fix the dependencies in the Makefile so that the XML files are rebuilt
when asciidoc.conf changes and not just the manual pages from
unchanged XML, and move the dependencies from a recipeless rule to the
rules with commands that use asciidoc.conf to make the dependencies
easier to understand and maintain.
Reported-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Tested-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When a sub-command dies due to a signal, we encode the
signal number into the numeric exit status as "signal -
128". This is easy to identify (versus a regular positive
error code), and when cast to an unsigned integer (e.g., by
feeding it to exit), matches what a POSIX shell would return
when reporting a signal death in $? or through its own exit
code.
So we have a negative value inside the code, but once it
passes across an exit() barrier, it looks positive (and any
code we receive from a sub-shell will have the positive
form). E.g., death by SIGPIPE (signal 13) will look like
-115 to us in inside git, but will end up as 141 when we
call exit() with it. And a program killed by SIGPIPE but run
via the shell will come to us with an exit code of 141.
Unfortunately, this means that when the "use_shell" option
is set, we need to be on the lookout for _both_ forms. We
might or might not have actually invoked the shell (because
we optimize out some useless shell calls). If we didn't invoke
the shell, we will will see the sub-process's signal death
directly, and run-command converts it into a negative value.
But if we did invoke the shell, we will see the shell's
128+signal exit status. To be thorough, we would need to
check both, or cast the value to an unsigned char (after
checking that it is not -1, which is a magic error value).
Fortunately, most callsites do not care at all whether the
exit was from a code or from a signal; they merely check for
a non-zero status, and sometimes propagate the error via
exit(). But for the callers that do care, we can make life
slightly easier by just using the consistent positive form.
This actually fixes two minor bugs:
1. In launch_editor, we check whether the editor died from
SIGINT or SIGQUIT. But we checked only the negative
form, meaning that we would fail to notice a signal
death exit code which was propagated through the shell.
2. In handle_alias, we assume that a negative return value
from run_command means that errno tells us something
interesting (like a fork failure, or ENOENT).
Otherwise, we simply propagate the exit code. Negative
signal death codes confuse us, and we print a useless
"unable to run alias 'foo': Success" message. By
encoding signal deaths using the positive form, the
existing code just propagates it as it would a normal
non-zero exit code.
The downside is that callers of run_command can no longer
differentiate between a signal received directly by the
sub-process, and one propagated. However, no caller
currently cares, and since we already optimize out some
calls to the shell under the hood, that distinction is not
something that should be relied upon by callers.
Fix the same logic in t/test-terminal.perl for consistency [jc:
raised by Jonathan in the discussion].
Signed-off-by: Jeff King <peff@peff.net>
Acked-by: Johannes Sixt <j6t@kdbg.org>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The beginning of 'integrate with the tip of the remote branch, not
the commit recorded in the superproject gitlink' support.
* wk/submodule-update-remote:
submodule add: If --branch is given, record it in .gitmodules
submodule update: add --remote for submodule's upstream changes
submodule: add get_submodule_config helper funtion
Allow scripts to feed literal paths to commands that take
pathspecs, by disabling wildcard globbing.
* jk/pathspec-literal:
add global --literal-pathspecs option
Conflicts:
dir.c
Introduce "log --format=%C(auto,blue)Foo%C(auto,reset)" that does
not color its output when writing to a non-terminal.
* jc/format-color-auto:
log --format: teach %C(auto,black) to respect color config
t6006: clean up whitespace
Allow us to read, and default to read, mailmap files from the tip
of the history in bare repositories. This will help running tools
like shortlog in server settings.
* jk/mailmap-from-blob:
mailmap: default mailmap.blob in bare repositories
mailmap: fix some documentation loose-ends for mailmap.blob
mailmap: clean up read_mailmap error handling
mailmap: support reading mailmap from blobs
mailmap: refactor mailmap parsing for non-file sources
Require "-f" for push to update a tag, even if it is a fast-forward.
* cr/push-force-tag-update:
push: allow already-exists advice to be disabled
push: rename config variable for more general use
push: cleanup push rules comment
push: clarify rejection of update to non-commit-ish
push: require force for annotated tags
push: require force for refs under refs/tags/
push: flag updates that require force
push: keep track of "update" state separately
push: add advice for rejected tag reference
push: return reject reasons as a bitset
Various updates to fast-export used in the context of the remote
helper interface.
* fc/fast-export-fixes:
fast-export: make sure updated refs get updated
fast-export: don't handle uninteresting refs
fast-export: fix comparison in tests
fast-export: trivial cleanup
remote-testgit: implement the "done" feature manually
remote-testgit: report success after an import
remote-testgit: exercise more features
remote-testgit: cleanup tests
remote-testgit: remove irrelevant test
remote-testgit: remove non-local functionality
Add new simplified git-remote-testgit
Rename git-remote-testgit to git-remote-testpy
remote-helpers: fix failure message
remote-testgit: fix direction of marks
fast-export: avoid importing blob marks
Accept "-v" as a synonym to "--reroll-count", so that users can say
"git format-patch -v4 master", instead of having to fully spell it
out as "git format-patch --reroll-count=4 master".
As I do not think of a reason why users would want to tell the
command to be "verbose", I think this should be OK.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The flow described in the document is still correct, but over time I
have automated various parts of the workflow with tools and their
use was not explained at all.
Update it and outline the use of two key scripts from the 'todo'
branch, "Reintegrate" and "cook".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Various fixes that have been cooking in 'next' have been merged. All
of them should go to 'maint' for 1.8.1.1 later.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The --graph code fell into infinite loop when asked to do what the
code did not expect.
* mk/maint-graph-infinity-loop:
graph.c: infinite loop in git whatchanged --graph -m
An element on GIT_CEILING_DIRECTORIES list that does not name the
real path to a directory (i.e. a symbolic link) could have caused
the GIT_DIR discovery logic to escape the ceiling.
* mh/ceiling:
string_list_longest_prefix(): remove function
setup_git_directory_gently_1(): resolve symlinks in ceiling paths
longest_ancestor_length(): require prefix list entries to be normalized
longest_ancestor_length(): take a string_list argument for prefixes
longest_ancestor_length(): use string_list_split()
Introduce new function real_path_if_valid()
real_path_internal(): add comment explaining use of cwd
Introduce new static function real_path_internal()
We told readers to "send it to the list" (or the maintainer) without
telling what addresses are to be used. Correct this.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The section is no longer a concise checklist. It also talks about
things that are not covered in the "Long version" text, which means
people need to read both, covering more or less the same thing in
different phrasing.
Fold the details into the main text and remove the section.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Not necessarily every bundle file can be cloned from. Only the ones
that do not need prerequisites can.
When 1d52b02 (Documentation: minor grammatical fixes and rewording
in git-bundle.txt, 2009-03-22) reworded this paragraph, it lost a
critical hint to tell readers why this particular bundle can be
cloned from. Resurrect it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These were only mentioned in periodical "A note from the maintainer"
posting and not in the documentation suite. SubmittingPatches has a
section to help contributors decide on what commit to base their
changes, which is the most suitable place for this information.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The introductory text in the "long version" talks about the origin
of this document with "I started ...", but it is unclear who that I
is, and more importantly, it is not interesting how it was started.
Just state the purpose of the document to help readers decide if it
is releavant to them.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Because the bundle created in the example does not record HEAD, "git
clone" will not check out the files to the working tree:
$ git clone pr.bundle q/
Cloning into 'q'...
Receiving objects: 100% (619/619), 13.52 MiB | 18.74 MiB/s, done.
Resolving deltas: 100% (413/413), done.
warning: remote HEAD refers to nonexistent ref, unable to checkout.
Avoid alarming the readers by adding "-b master" to the example. A
better fix may be to arrange the bundle created in the earlier step
to record HEAD, so that it can be cloned without this workaround.
Signed-off-by: Brilliantov Kirill Vladimirovich <brilliantov@inbox.ru>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
traversal API has a few potentially confusing properties. These
comments clarify a few key aspects and will hopefully make it easier
to understand for other newcomers in the future.
Signed-off-by: Adam Spiers <git@adamspiers.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
7c4c97c0ac turned the flags in struct dir_struct into a single bitfield
variable, but forgot to update this document.
Signed-off-by: Adam Spiers <git@adamspiers.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The parsecvs code has been neglected for a long time, and the only
public version does not even build correctly. I have been handed
control of the project and intend to fix this, but until I do it
cannot be recommended.
Also, the project URL given for Subversion needed to be updated
to follow their site move.
Signed-off-by: Eric S. Raymond <esr@thyrsus.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We earlier removed a link to list of contributors that pointed to a
defunct page; let's use a working one from Ohloh.net to replace it
instead.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* sl/maint-git-svn-docs:
git-svn: Note about tags.
git-svn: Expand documentation for --follow-parent
git-svn: Recommend use of structure options.
git-svn: Document branches with at-sign(@).
Document that 'git svn' will import SVN tags as branches.
Signed-off-by: Sebastian Leske <sebastian.leske@sleske.name>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Describe what the option --follow-parent does, and what happens if it is
set or unset.
Signed-off-by: Sebastian Leske <sebastian.leske@sleske.name>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Document that when using git svn, one should usually either use the
directory structure options to import branches as branches, or only
import one subdirectory. The default behaviour of cloning all branches
and tags as subdirectories in the working copy is usually not what the
user wants.
Signed-off-by: Sebastian Leske <sebastian.leske@sleske.name>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git svn sometimes creates branches with an at-sign in the name
(branchname@revision). These branches confuse many users and it is a FAQ
why they are created. Document when git svn creates them.
Signed-off-by: Sebastian Leske <sebastian.leske@sleske.name>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In the distant past, the order things were documented was
'Invocation', 'Commands', 'Capabilities', ...
Then it was decided that before giving a list of Commands, there
should be an overall description of the 'Input format', which was
a wise decision. However, this description was put as the very
first thing, with the rationale that any implementor would want
to know that first.
However, it seems an implementor would actually first need to
know how the remote helper will be invoked, so moving
'Invocation' to the front again seems logical. Moreover, we now
don't switch from discussing the input format to the invocation
style and then back to input related stuff.
Signed-off-by: Max Horn <max@quendi.de>
Acked-by: Sverre Rabbelier <srabbelier@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
19299a8 (Documentation: Move diff.<driver>.* from config.txt to
diff-config.txt, 2011-04-07) moved the diff configuration options to
diff-config.txt, but forgot about diff.wordRegex, which was left
behind in config.txt. Fix this.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This file is rather outdated and IMHO shouldn't be there in the first place.
(If there are translations of the Git documentation they are better be kept
separate from the original documentation.)
Signed-off-by: Thomas Ackermann <th.acker@arcor.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* ta/doc-cleanup:
Documentation: build html for all files in technical and howto
Documentation/howto: convert plain text files to asciidoc
Documentation/technical: convert plain text files to asciidoc
Change headline of technical/send-pack-pipeline.txt to not confuse its content with content from git-send-pack.txt
Shorten two over-long lines in git-bisect-lk2009.txt by abbreviating some sha1
Split over-long synopsis in git-fetch-pack.txt into several lines
Howto documents in howto-index.txt were listed in a rather
random order. So better sort them.
Signed-off-by: Thomas Ackermann <th.acker@arcor.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git diff <blob> <blob>" was not documented and was only hinted as
an extension to "git diff <commit> <commit> -- <pathspec>", but
comparison between two blobs are more special than that. It does
not take any pathspec to begin with.
* jc/doc-diff-blobs:
Documentation: Describe "git diff <blob> <blob>" separately
Document the magic "git checkout <no-such-branch>" hack to create
local branch out of a remote tracking branch that hasn't been
documented so far.
* cr/doc-checkout-branch:
Documentation/git-checkout.txt: document 70c9ac2 behavior
Documentation/git-checkout.txt: clarify usage
Avoids invalid sample e-mail addresses from becoming mailto links
in the formatted output.
* jk/avoid-mailto-invalid-in-doc:
Documentation: don't link to example mail addresses
It might be a better idea to move the text the bottom one adds to
the extended description from the quick checklist part.
* as/doc-for-devs:
Documentation: move support for old compilers to CodingGuidelines
SubmittingPatches: add convention of prefixing commit messages
"git fetch --tags" was explained as if it were "git fetch
--no-no-tags", which is not the case, causing confusion.
* jc/fetch-tags-doc:
fetch --tags: clarify documentation
* sl/git-svn-docs:
git-svn: Note about tags.
git-svn: Expand documentation for --follow-parent
git-svn: Recommend use of structure options.
git-svn: Document branches with at-sign(@).
The contents of this document does not describe any particular API, but
is more about the way to add a new command, which belongs to the "How To"
section of the documentation suite.
Signed-off-by: Thomas Ackermann <th.acker@arcor.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Git takes pathspec arguments in many places to limit the
scope of an operation. These pathspecs are treated not as
literal paths, but as glob patterns that can be fed to
fnmatch. When a user is giving a specific pattern, this is a
nice feature.
However, when programatically providing pathspecs, it can be
a nuisance. For example, to find the latest revision which
modified "$foo", one can use "git rev-list -- $foo". But if
"$foo" contains glob characters (e.g., "f*"), it will
erroneously match more entries than desired. The caller
needs to quote the characters in $foo, and even then, the
results may not be exactly the same as with a literal
pathspec. For instance, the depth checks in
match_pathspec_depth do not kick in if we match via fnmatch.
This patch introduces a global command-line option (i.e.,
one for "git" itself, not for specific commands) to turn
this behavior off. It also has a matching environment
variable, which can make it easier if you are a script or
porcelain interface that is going to issue many such
commands.
This option cannot turn off globbing for particular
pathspecs. That could eventually be done with a ":(noglob)"
magic pathspec prefix. However, that level of granularity is
more cumbersome to use for many cases, and doing ":(noglob)"
right would mean converting the whole codebase to use
"struct pathspec", as the usual "const char **pathspec"
cannot represent extra per-item flags.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This allows you to easily record a submodule.<name>.branch option in
.gitmodules when you add a new submodule. With this patch,
$ git submodule add -b <branch> <repository> [<path>]
$ git config -f .gitmodules submodule.<path>.branch <branch>
reduces to
$ git submodule add -b <branch> <repository> [<path>]
This means that future calls to
$ git submodule update --remote ...
will get updates from the same branch that you used to initialize the
submodule, which is usually what you want.
Signed-off-by: W. Trevor King <wking@tremily.us>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The current `update` command incorporates the superproject's gitlinked
SHA-1 ($sha1) into the submodule HEAD ($subsha1). Depending on the
options you use, it may checkout $sha1, rebase the $subsha1 onto
$sha1, or merge $sha1 into $subsha1. This helps you keep up with
changes in the upstream superproject.
However, it's also useful to stay up to date with changes in the
upstream subproject. Previous workflows for incorporating such
changes include the ungainly:
$ git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull'
With this patch, all of the useful functionality for incorporating
superproject changes can be reused to incorporate upstream subproject
updates. When you specify --remote, the target $sha1 is replaced with
a $sha1 of the submodule's origin/master tracking branch. If you want
to merge a different tracking branch, you can configure the
`submodule.<name>.branch` option in `.gitmodules`. You can override
the `.gitmodules` configuration setting for a particular superproject
by configuring the option in that superproject's default configuration
(using the usual configuration hierarchy, e.g. `.git/config`,
`~/.gitconfig`, etc.).
Previous use of submodule.<name>.branch
=======================================
Because we're adding a new configuration option, it's a good idea to
check if anyone else is already using the option. The foreach-pull
example above was described by Ævar in
commit f030c96d86
Author: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Fri May 21 16:10:10 2010 +0000
git-submodule foreach: Add $toplevel variable
Gerrit uses the same interpretation for the setting, but because
Gerrit has direct access to the subproject repositories, it updates
the superproject repositories automatically when a subproject changes.
Gerrit also accepts the special value '.', which it expands into the
superproject's branch name.
Although the --remote functionality is using `submodule.<name>.branch`
slightly differently, the effect is the same. The foreach-pull
example uses the option to record the name of the local branch to
checkout before pulls. The tracking branch to be pulled is recorded
in `.git/modules/<name>/config`, which was initialized by the module
clone during `submodule add` or `submodule init`. Because the branch
name stored in `submodule.<name>.branch` was likely the same as the
branch name used during the initial `submodule add`, the same branch
will be pulled in each workflow.
Implementation details
======================
In order to ensure a current tracking branch state, `update --remote`
fetches the submodule's remote repository before calculating the
SHA-1. However, I didn't change the logic guarding the existing fetch:
if test -z "$nofetch"
then
# Run fetch only if $sha1 isn't present or it
# is not reachable from a ref.
(clear_local_git_env; cd "$path" &&
( (rev=$(git rev-list -n 1 $sha1 --not --all 2>/dev/null) &&
test -z "$rev") || git-fetch)) ||
die "$(eval_gettext "Unable to fetch in submodule path '\$path'")"
fi
There will not be a double-fetch, because the new $sha1 determined
after the `--remote` triggered fetch should always exist in the
repository. If it doesn't, it's because some racy process removed it
from the submodule's repository and we *should* be re-fetching.
Signed-off-by: W. Trevor King <wking@tremily.us>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As it was not a common operation, it was described as if it is a
side note for the more common two-commit variant, but this mode
behaves very differently, e.g. it does not make any sense to ask
recursive behaviour, or give the command a pathspec.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Document the behavior implemented in 70c9ac2 (DWIM "git checkout
frotz" to "git checkout -b frotz origin/frotz").
Signed-off-by: Chris Rorvick <chris@rorvick.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The forms of checkout that do not take a path are lumped together in
the DESCRIPTION section, but the description for this group is
dominated by explanation of the -b|-B form.
Split these apart for more clarity.
Signed-off-by: Chris Rorvick <chris@rorvick.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Traditionally, %C(color attr) always emitted the ANSI color
sequence; it was up to the scripts that wanted to conditionally
color their output to omit %C(...) specifier when they do not want
colors.
Optionally allow "auto," to be prefixed to the color, so that the
output is colored iff we would color regular "log" output
(e.g., taking into account color.* and --color command line
options).
Tests and pretty_context bits by Jeff King <peff@peff.net>.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The "Try to be nice to older C compilers" text is clearly a guideline
to be borne in mind whilst coding rather than when submitting patches.
Signed-off-by: Adam Spiers <git@adamspiers.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Conscientious newcomers to git development will read SubmittingPatches
and CodingGuidelines, but could easily miss the convention of
prefixing commit messages with a single word identifying the file
or area the commit touches.
Signed-off-by: Adam Spiers <git@adamspiers.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Email addresses in documentation are converted into mailto: hyperlinks
in the HTML output and footnotes in man pages. This isn't desirable for
cases where the address is used as an example and is not valid.
Particularly annoying is the example "jane@laptop.(none)" which appears
in git-shortlog(1) as "jane@laptop[1].(none)", with note 1 saying:
1. jane@laptop
mailto:jane@laptop
Fix this by escaping these email addresses with a leading backslash, to
prevent Asciidoc expanding them as inline macros.
In the case of mailmap.txt, render the address monospaced so that it
matches the block examples surrounding that paragraph.
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Start list with 1 instead of 0; ASCIIDOC will renumber it anyway.
Signed-off-by: Thomas Ackermann <th.acker@arcor.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Explain that --tags is just like another explicit refspec on the
command line and as such overrides the default refspecs configured
via the remote.$name.fetch variable.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Unlike other environment variables (e.g. GIT_WORK_TREE, GIT_NAMESPACE),
the Documentation/git.txt file did not mention that the GIT_DIR
environment variable can also be set using the --git-dir command line
option.
Signed-off-by: Manlio Perillo <manlio.perillo@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The motivation for mailmap.blob is to let users of bare
repositories use the mailmap feature, as they would not have
a checkout containing the .mailmap file. We can make it even
easier for them by just looking in HEAD:.mailmap by default.
We can't know for sure that this is where they would keep a
mailmap, of course, but it is the best guess (and it matches
the non-bare behavior, which reads from HEAD:.mailmap in the
working tree). If it's missing, git will silently ignore the
setting.
We do not do the same magic in the non-bare case, because:
1. In the common case, HEAD:.mailmap will be the same as
the .mailmap in the working tree, which is a no-op.
2. In the uncommon case, the user has modified .mailmap
but not yet committed it, and would expect the working
tree version to take precedence.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Anywhere we mention mailmap.file, it is probably worth
mentioning mailmap.blob, as well.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A cache-tree entry with a negative entry count is considered invalid
by the current Git; it records that we do not know the object name
of a tree that would result by writing the directory covered by the
cache-tree as a tree object.
Clarify that any entry with a negative entry count is invalid, but
the implementations must write -1 there. This way, we can later
decide to allow writers to use negative values other than -1 to
encode optional information on such invalidated entries without
harming interoperability; we do not know what will be encoded and
how, so we keep these other negative values as reserved for now.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We earlier removed a link to list of contributors that pointed to a
defunct page; let's use a working one from Ohloh.net to replace it
instead.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In a bare repository, there isn't a simple way to respect an
in-tree mailmap without extracting it to a temporary file.
This patch provides a config variable, similar to
mailmap.file, which reads the mailmap from a blob in the
repository.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
Git 1.8.0.2
Documentation/git-stash.txt: add a missing verb
git(1): remove a defunct link to "list of authors"
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The linked page has not been showing the promised "more complete
list" for more than 6 months by now, and nobody has resurrected
the list there nor elsewhere since then.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The line that happens to begin with indent followed by "3. " was
interpreted as if it was an enumerated list; just wrap the lines
differently to work it around for now.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The documentation was misleading in that it gave the impression that
'for-push' could be used as a ref attribute in the output of the
'list' command. That is wrong.
Also, explicitly point out the connection between the commands
'list' and 'options' on the one hand, and the sections
'REF LIST ATTRIBUTES' and 'OPTIONS' on the other hand.
Signed-off-by: Max Horn <max@quendi.de>
Acked-by: Sverre Rabbelier <srabbelier@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In particular, document 'list for-push' separately from 'list', as
the former needs only be supported for the push/export
capabilities, and the latter only for fetch/import. Indeed, a
hypothetically 'push-only' helper would only need to support the
former, not the latter.
Signed-off-by: Max Horn <max@quendi.de>
Acked-by: Sverre Rabbelier <srabbelier@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This also remove some duplication in the descriptions
(e.g. refspec was explained twice with similar level of detail).
Signed-off-by: Max Horn <max@quendi.de>
Acked-by: Sverre Rabbelier <srabbelier@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Specifically, document the 'export' and '(im|ex)port-marks'
capabilities as well as the export command, which were
undocumented (but in active use).
Signed-off-by: Max Horn <max@quendi.de>
Acked-by: Sverre Rabbelier <srabbelier@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In the distant past, the order things were documented was
'Invocation', 'Commands', 'Capabilities', ...
Then it was decided that before giving a list of Commands, there
should be an overall description of the 'Input format', which was
a wise decision. However, this description was put as the very
first thing, with the rationale that any implementor would want
to know that first.
However, it seems an implementor would actually first need to
know how the remote helper will be invoked, so moving
'Invocation' to the front again seems logical. Moreover, we now
don't switch from discussing the input format to the invocation
style and then back to input related stuff.
Signed-off-by: Max Horn <max@quendi.de>
Acked-by: Sverre Rabbelier <srabbelier@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Document that 'git svn' will import SVN tags as branches.
Signed-off-by: Sebastian Leske <sebastian.leske@sleske.name>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Describe what the option --follow-parent does, and what happens if it is
set or unset.
Signed-off-by: Sebastian Leske <sebastian.leske@sleske.name>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Document that when using git svn, one should usually either use the
directory structure options to import branches as branches, or only
import one subdirectory. The default behaviour of cloning all branches
and tags as subdirectories in the working copy is usually not what the
user wants.
Signed-off-by: Sebastian Leske <sebastian.leske@sleske.name>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git svn sometimes creates branches with an at-sign in the name
(branchname@revision). These branches confuse many users and it is a FAQ
why they are created. Document when git svn creates them.
Signed-off-by: Sebastian Leske <sebastian.leske@sleske.name>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add 'advice.pushAlreadyExists' option to disable the advice shown when
an update is rejected for a reference that is not allowed to update at
all (verses those that are allowed to fast-forward.)
Signed-off-by: Chris Rorvick <chris@rorvick.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The 'pushNonFastForward' advice config can be used to squelch several
instances of push-related advice. Rename it to 'pushUpdateRejected' to
cover other reject scenarios that are unrelated to fast-forwarding.
Retain the old name for compatibility.
Signed-off-by: Chris Rorvick <chris@rorvick.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Do not allow fast-forwarding of references that point to a tag object.
Updating from a tag is potentially destructive since it would likely
leave the tag dangling. Disallowing updates to a tag also makes sense
semantically and is consistent with the behavior of lightweight tags.
Signed-off-by: Chris Rorvick <chris@rorvick.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
References are allowed to update from one commit-ish to another if the
former is an ancestor of the latter. This behavior is oriented to
branches which are expected to move with commits. Tag references are
expected to be static in a repository, though, thus an update to
something under refs/tags/ should be rejected unless the update is
forced.
Signed-off-by: Chris Rorvick <chris@rorvick.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Exercising the python remote helper framework is for another tool and
another test. This is about testing the remote-helper interface.
It's way simpler, it exercises the same features of remote helpers, it's
easy to read and understand, and it doesn't depend on python.
For now let's just copy the old remote-helpers test script, although
some of those tests don't make sense. In addition, this script would be
able to test other features not currently being tested.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The documentation mentioned only newlines and double quotes as
characters needing escaping, but the backslash also needs it. Also, the
documentation was not clearly saying that double quotes around the file
name were required (double quotes in the examples could be interpreted as
part of the sentence, not part of the actual string).
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The context of the example to push into refs/remotes/satellite/
hierarchy of the other repository needs to be spelled out explicitly
for the value of this example to be fully appreciated. Make it so.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The current version contains the sentence:
Further suppose that the other person already pushed changes leading to
A back to the original repository you two obtained the original commit
X.
which doesn't parse for me; I've changed it to
Further suppose that the other person already pushed changes leading to
A back to the original repository from which you two obtained the
original commit X.
Signed-off-by: Mark Szepieniec <mszepien@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This document contains no new policies or proposals; it attempts to
document established practices and interface requirements.
Signed-off-by: Eric S. Raymond <esr@thyrsus.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Allow "git diff --submodule=log" to set to be the default via
configuration.
* rr/submodule-diff-config:
submodule: display summary header in bold
diff: rename "set" variable
diff: introduce diff.submodule configuration variable
Documentation: move diff.wordRegex from config.txt to diff-config.txt
* ta/doc-cleanup:
Documentation: build html for all files in technical and howto
Documentation/howto: convert plain text files to asciidoc
Documentation/technical: convert plain text files to asciidoc
Change headline of technical/send-pack-pipeline.txt to not confuse its content with content from git-send-pack.txt
Shorten two over-long lines in git-bisect-lk2009.txt by abbreviating some sha1
Split over-long synopsis in git-fetch-pack.txt into several lines
Introduce a diff.submodule configuration variable corresponding to the
'--submodule' command-line option of 'git diff'.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
19299a8 (Documentation: Move diff.<driver>.* from config.txt to
diff-config.txt, 2011-04-07) moved the diff configuration options to
diff-config.txt, but forgot about diff.wordRegex, which was left
behind in config.txt. Fix this.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Prepare the release notes for the upcoming release, and describe
changes up to the 5th batch we just merged.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Emit the notes attached to the commit in "format-patch --notes"
output after three-dashes.
* jc/prettier-pretty-note:
format-patch: add a blank line between notes and diffstat
Doc User-Manual: Patch cover letter, three dashes, and --notes
Doc format-patch: clarify --notes use case
Doc notes: Include the format-patch --notes option
Doc SubmittingPatches: Mention --notes option after "cover letter"
Documentation: decribe format-patch --notes
format-patch --notes: show notes after three-dashes
format-patch: append --signature after notes
pretty_print_commit(): do not append notes message
pretty: prepare notes message at a centralized place
format_note(): simplify API
pretty: remove reencode_commit_message()
Improve the asymptotic performance of the cat_sort_uniq notes merge
strategy.
* mh/notes-string-list:
string_list_add_refs_from_colon_sep(): use string_list_split()
notes: fix handling of colon-separated values
combine_notes_cat_sort_uniq(): sort and dedup lines all at once
Initialize sort_uniq_list using named constant
string_list: add a function string_list_remove_empty_items()
Allows "cvsimport" to read per-author timezone from the author info
file.
* cr/cvsimport-local-zone:
cvsimport: work around perl tzset issue
git-cvsimport: allow author-specific timezones
Add "symbolic-ref -d SYM" to delete a symbolic ref SYM.
It is already possible to remove a symbolic ref with "update-ref -d
--no-deref", but it may be a good addition for completeness.
* jh/symbolic-ref-d:
git symbolic-ref --delete $symref
293ab15e ("submodule: teach rm to remove submodules unless they
contain a git directory", 2012-09-26) inserted the "Submodules"
section between a sentence describing a command and the command. Move
the "Submodules" section further down.
Noticed-by: Horst H. von Brand
Signed-off-by: Matt Kraai <kraai@ftbfs.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git send-email --compose" can let the user create a non-ascii
cover letter message, but there was not a way to mark it with
appropriate content type before sending it out.
Further updates fix subject quoting.
* km/send-email-compose-encoding:
git-send-email: add rfc2047 quoting for "=?"
git-send-email: introduce quote_subject()
git-send-email: skip RFC2047 quoting for ASCII subjects
git-send-email: use compose-encoding for Subject
git-send-email: introduce compose-encoding
Start laying the foundation to build the "wildmatch" after we can
agree on its desired semantics.
* nd/attr-match-optim-more:
attr: more matching optimizations from .gitignore
gitignore: make pattern parsing code a separate function
exclude: split pathname matching code into a separate function
exclude: fix a bug in prefix compare optimization
exclude: split basename matching code into a separate function
exclude: stricten a length check in EXC_FLAG_ENDSWITH case
We long ago hyphenated "remote-tracking branch"; this
catches some new instances added since then.
* mm/maint-doc-remote-tracking:
Documentation: remote tracking branch -> remote-tracking branch
Document strbuf_split_buf(), strbuf_split_str(), strbuf_split_max(),
strbuf_split(), and strbuf_list_free() in the header file and in
api-strbuf.txt. (These functions were previously completely
undocumented.)
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Jeff King <peff@peff.net>
In e858af6 (commit: document a couple of options) the description of the
--no-post-rewrite option was put inside the paragraph for the --amend
option. Move it down after the paragraph.
Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
Signed-off-by: Jeff King <peff@peff.net>
git commit -S, --gpg-sign was mentioned in the program's help message,
but not in the manpage.
This adds an equivalent entry for the option in the manpage.
Signed-off-by: Tom Jones <tom@oxix.org>
Signed-off-by: Jeff King <peff@peff.net>
Allow an earlier "--short" option on the command line to be
countermanded with the "--long" option for "git status" and "git
commit".
* nd/status-long:
status: add --long output format option
"git log -F -E --grep='<ere>'" failed to use the given <ere>
pattern as extended regular expression, and instead looked for the
string literally. The early part of this series is a fix for it;
the latter part teaches log to respect the grep.* configuration.
* jc/grep-pcre-loose-ends:
log: honor grep.* configuration
log --grep: accept --basic-regexp and --perl-regexp
log --grep: use the same helper to set -E/-F options as "git grep"
revisions: initialize revs->grep_filter using grep_init()
grep: move pattern-type bits support to top-level grep.[ch]
grep: move the configuration parsing logic to grep.[ch]
builtin/grep.c: make configuration callback more reusable
If you remove a submodule, in order to keep the repository so that
"git checkout" to an older commit in the superproject history can
resurrect the submodule, the real repository will stay in $GIT_DIR
of the superproject. A later "git submodule add $path" to add a
different submodule at the same path will fail. Diagnose this case
a bit better, and if the user really wants to add an unrelated
submodule at the same path, give the "--name" option to give it a
place in $GIT_DIR of the superproject that does not conflict with
the original submodule.
* jl/submodule-add-by-name:
submodule add: Fail when .git/modules/<name> already exists unless forced
Teach "git submodule add" the --name option
"git rm submodule" cannot blindly remove a submodule directory as
its working tree may have local changes, and worse yet, it may even
have its repository embedded in it. Teach it some special cases
where it is safe to remove a submodule, specifically, when there is
no local changes in the submodule working tree, and its repository
is not embedded in its working tree but is elsewhere and uses the
gitfile mechanism to point at it.
* jl/submodule-rm:
submodule: teach rm to remove submodules unless they contain a git directory
This function was added in f103f95b11 in
the erroneous expectation that it would be used in the
reimplementation of longest_ancestor_length(). But it turned out to
be easier to use a function specialized for comparing path prefixes
(i.e., one that knows about slashes and root paths) than to prepare
the paths in such a way that a generic string prefix comparison
function can be used. So delete string_list_longest_prefix() and its
documentation and test cases.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Jeff King <peff@peff.net>
You can override an option set in the LESS variable by simply prefixing
the command line option with `-+`. This is more robust than the previous
example if the default LESS options are to ever change.
Signed-off-by: Patrick Palka <patrick@parcs.ath.cx>
Signed-off-by: Jeff King <peff@peff.net>
The git-reset's "<mode>" is an optional argument, however it was
documented as required.
The "<mode>" is documented as one of: --soft, --mixed, --hard, --merge
or --keep, so "<mode>" should be used instead of "--<mode>".
Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net>
Signed-off-by: Jeff King <peff@peff.net>
Show that git format-patch can have a cover letter, include patch
commentary below the three dashes, and notes can also be
included.
Signed-off-by: Philip Oakley <philipoakley@iee.org>
Signed-off-by: Jeff King <peff@peff.net>
The --log-window-size parameter to git-svn fetch is undocumented.
Minimally describe what it does and why the user might change it.
Signed-off-by: Gunnlaugur Þór Briem <gunnlaugur@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
Remove double negative, and include the repeat usage across
versions of a patch series.
Signed-off-by: Philip Oakley <philipoakley@iee.org>
Signed-off-by: Jeff King <peff@peff.net>
This change was already done by 0e615b252f (Matthieu Moy, Tue Nov 2
2010, Replace "remote tracking" with "remote-tracking"), but new
instances of remote tracking (without dash) were introduced in the
meantime.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Jeff King <peff@peff.net>
A GSoC project.
* fa/remote-svn:
Add a test script for remote-svn
remote-svn: add marks-file regeneration
Add a svnrdump-simulator replaying a dump file for testing
remote-svn: add incremental import
remote-svn: Activate import/export-marks for fast-import
Create a note for every imported commit containing svn metadata
vcs-svn: add fast_export_note to create notes
Allow reading svn dumps from files via file:// urls
remote-svn, vcs-svn: Enable fetching to private refs
When debug==1, start fast-import with "--stats" instead of "--quiet"
Add documentation for the 'bidi-import' capability of remote-helpers
Connect fast-import to the remote-helper via pipe, adding 'bidi-import' capability
Add argv_array_detach and argv_array_free_detached
Add svndump_init_fd to allow reading dumps from arbitrary FDs
Add git-remote-testsvn to Makefile
Implement a remote helper for svn in C
Teaches a new configuration variable to "git diff" Porcelain and
its friends.
* jm/diff-context-config:
t4055: avoid use of sed 'a' command
diff: diff.context configuration gives default to -U
git format-patch gained a --notes option. Tell the notes user.
Signed-off-by: Philip Oakley <philipoakley@iee.org>
Signed-off-by: Jeff King <peff@peff.net>
The git format-patch --notes option can now insert the commit notes
after the three dashes. Mention this after the regular cover letter
guidance for submitting patches.
Signed-off-by: Philip Oakley <philipoakley@iee.org>
Signed-off-by: Jeff King <peff@peff.net>
These files were recently revised to be valid asciidoc, so
there is no reason not to build html versions.
Signed-off-by: Thomas Ackermann <th.acker66@arcor.de>
Signed-off-by: Jeff King <peff@peff.net>
Use "-b <branch>" instead of "-b branch". This brings the usage
strings in line with other options, e.g. "--reference <repository>".
Signed-off-by: W. Trevor King <wking@tremily.us>
Signed-off-by: Jeff King <peff@peff.net>
Teach symbolic-ref to delete symrefs by adding the -d/--delete option to
git-symbolic-ref. Both proper and dangling symrefs are deleted by this
option, but other refs - or anything else that is not a symref - is not.
The symref deletion is performed by first verifying that we are given a
proper symref, and then invoking delete_ref() on it with the REF_NODEREF
flag.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Even though I coded this, I am not sure what use scenarios would benefit
from this option, so the description is unnecessarily negative at this
moment. People who do want to use this feature need to come up with a
more plausible use case and replace it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
You can currently set the output format to --short or
--porcelain. There is no --long, because we default to it
already. However, you may want to override an alias that
uses "--short" to get back to the default.
This requires a little bit of refactoring, because currently
we use STATUS_FORMAT_LONG internally to mean the same as
"the user did not specify anything". By expanding the enum
to include STATUS_FORMAT_NONE, we can distinguish between
the implicit and explicit cases. This effects these
conditions:
1. The user has asked for NUL termination. With NONE, we
currently default to turning on the porcelain mode.
With an explicit --long, we would in theory use NUL
termination with the long mode, but it does not support
it. So we can just complain and die.
2. When an output format is given to "git commit", we
default to "--dry-run". This behavior would now kick in
when "--long" is given, too.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These were not originally meant for asciidoc, but they are already
so close. Mark them up in asciidoc.
Signed-off-by: Thomas Ackermann <th.acker@arcor.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* po/maint-docs:
Doc branch: show -vv option and alternative
Doc clean: add See Also link
Doc add: link gitignore
Doc: separate gitignore pattern sources
Doc: shallow clone deepens _to_ new depth
* jc/ll-merge-binary-ours:
ll-merge: warn about inability to merge binary files only when we can't
attr: "binary" attribute should choose built-in "binary" merge driver
merge: teach -Xours/-Xtheirs to binary ll-merge driver
CVS patchsets are imported with timestamps having an offset of +0000
(UTC). The cvs-authors file is already used to translate the CVS
username to full name and email in the corresponding commit. Extend
this file to support an optional timezone for calculating a user-
specific timestamp offset.
Signed-off-by: Chris Rorvick <chris@rorvick.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These were not originally meant for asciidoc, but they are already
so close. Mark them up in asciidoc.
Signed-off-by: Thomas Ackermann <th.acker@arcor.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These were used to keep track of the last commit a release notes
entry was written for, and should have been removed when cutting
the final release.
Signed-off-by: Thomas Ackermann <th.acker@arcor.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
.gitattributes and .gitignore share the same pattern syntax but has
separate matching implementation. Over the years, ignore's
implementation accumulates more optimizations while attr's stays the
same.
This patch reuses the core matching functions that are also used by
excluded_from_list. excluded_from_list and path_matches can't be
merged due to differences in exclude and attr, for example:
* "!pattern" syntax is forbidden in .gitattributes. As an attribute
can be unset (i.e. set to a special value "false") or made back to
unspecified (i.e. not even set to "false"), "!pattern attr" is unclear
which one it means.
* we support attaching attributes to directories, but git-core
internally does not currently make use of attributes on
directories.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
On a multiuser system where mortals do not have write access to /etc,
the GIT_CONFIG_NOSYSTEM variable is the best tool we have to keep
getting work done when a syntax error or other problem renders
/etc/gitconfig buggy, until the sysadmin sorts the problem out.
Noticed while experimenting with teaching git to error out when
/etc/gitconfig is unreadable.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is the documentation part of
1a9d7e9 (attr.c: read .gitattributes from index as well. - 2007-08-14)
06f33c1 (Read attributes from the index that is being checked out - 2009-03-13)
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The introduction email (--compose option) have encoding hardcoded to
UTF-8, but invoked editor may not use UTF-8 encoding.
The encoding used by patches can be changed by the "8bit-encoding"
option, but this option does not have effect on introduction email
and equivalent for introduction email is missing.
Added compose-encoding command line option and sendemail.composeencoding
configuration option specify encoding of introduction email.
Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we added the "--perl-regexp" option (or "-P") to "git grep", we
should have done the same for the commands in the "git log" family,
but somehow we forgot to do so. This corrects it, but we will
reserve the short-and-sweet "-P" option for something else for now.
Also introduce the "--basic-regexp" option for completeness, so that
the "last one wins" principle can be used to defeat an earlier -E
option, e.g. "git log -E --basic-regexp --grep='<bre>'". Note that
it cannot have the short "-G" option as the option is to grep in the
patch text in the context of "log" family.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It is not even worth mentioning their removal; just discourage
people from using them.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A repository created with "git clone --single" had its fetch
refspecs set up just like a clone without "--single", leading the
subsequent "git fetch" to slurp all the other branches, defeating
the whole point of specifying "only this branch".
* rt/maint-clone-single:
clone --single: limit the fetch refspec to fetched branch
It was unclear in the documentation for "git blame" that it is
unnecessary for users to use the "--follow" option.
* jc/blame-follows-renames:
git blame: document that it always follows origin across whole-file renames
We support backslash escape, but we hide the details behind the phrase
"a shell glob suitable for consumption by fnmatch(3)". So it may not
be obvious how one can get literal # or ! at the beginning of pattern.
Add a few lines on how to work around the magic characters.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Florian Achleitner <florian.achleitner.2.6.31@gmail.com>
Acked-by: David Michael Barr <b@rr-dav.id.au>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Allow detaching of ownership of the argv_array's contents and add a
function to free those detached argv_arrays later.
This makes it possible to use argv_array efficiently with the exiting
struct child_process which only contains a member char **argv.
Add to documentation.
Signed-off-by: Florian Achleitner <florian.achleitner.2.6.31@gmail.com>
Acked-by: David Michael Barr <b@rr-dav.id.au>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Describe the behaviour, but do warn people against taking it too
literally and expect an abbreviation valid today will stay valid
forever.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Teach the commands from the "log" family the "--grep-reflog" option
to limit output by string that appears in the reflog entry when the
"--walk-reflogs" option is in effect.
* nd/grep-reflog:
revision: make --grep search in notes too if shown
log --grep-reflog: reject the option without -g
revision: add --grep-reflog to filter commits by reflog messages
grep: prepare for new header field filter
"git submodule frotz" was not diagnosed as "frotz" being an unknown
subcommand to "git submodule"; the user instead got a complaint that
"git submodule status" was run with an unknown path "frotz".
* rr/maint-submodule-unknown-cmd:
submodule: if $command was not matched, don't parse other args
It already is listed in the "git config" documentation, but people
interested in pushing would first look at "git push" documentation.
Noticed-by: David Glasser
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Acked-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Fixed-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Clarify the "blame" documentation to tell the users that there is
no need to ask for "--follow".
* jc/blame-follows-renames:
git blame: document that it always follows origin across whole-file renames
Running "git fetch" in a repository made with "git clone --single"
slurps all the branches, defeating the point of "--single".
* rt/maint-clone-single:
clone --single: limit the fetch refspec to fetched branch
Introduce a configuration variable diff.context that tells
Porcelain commands to use a non-default number of context
lines instead of 3 (the default). With this variable, users
do not have to keep repeating "git log -U8" from the command
line; instead, it becomes sufficient to say "git config
diff.context 8" just once.
Signed-off-by: Jeff Muizelaar <jmuizelaar@mozilla.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jc/maint-log-grep-all-match-1:
grep.c: make two symbols really file-scope static this time
t7810-grep: test --all-match with multiple --grep and --author options
t7810-grep: test interaction of multiple --grep and --author options
t7810-grep: test multiple --author with --all-match
t7810-grep: test multiple --grep with and without --all-match
t7810-grep: bring log --grep tests in common form
grep.c: mark private file-scope symbols as static
log: document use of multiple commit limiting options
log --grep/--author: honor --all-match honored for multiple --grep patterns
grep: show --debug output only once
grep: teach --debug option to dump the parse tree
Teach an option to edit the insn sheet to "git rebase -i".
* aw/rebase-i-edit-todo:
rebase -i: suggest using --edit-todo to fix an unknown instruction
rebase -i: Add tests for "--edit-todo"
rebase -i: Teach "--edit-todo" action
rebase -i: Refactor help messages for todo file
rebase usage: subcommands can not be combined with -i
"git submodule add" initializes the name of a submodule to its path. This
was ok as long as the .git directory lived inside the submodule's work
tree, but since 1.7.8 it is stored in the .git/modules/<name> directory of
the superproject, making the submodule name survive the removal of the
submodule's work tree. This leads to problems when the user tries to add a
different submodule at the same path - and thus the same name - later, as
that will happily try to restore the submodule from the old repository
instead of the one the user specified and will lead to a checkout of the
wrong repository.
Add the new "--name" option to let the user provide a name for the
submodule. This enables the user to solve this conflict without having to
remove .git/modules/<name> by hand (which is no viable solution as it
makes it impossible to checkout a commit that records the old submodule
and populate it, as that will still check out the new submodule for the
same reason).
To achieve that the submodule's name is added to the parameter list of
the module_clone() helper function. This makes it possible to remove the
call of module_name() there because both callers of module_clone() already
know the name and can provide it as argument number two.
Reported-by: Jonathan Johnson <me@jondavidjohn.com>
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Notes are shown after commit body. From user perspective it looks
pretty much like commit body and they may assume --grep would search
in that part too.
Make it so.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Similar to --author/--committer which filters commits by author and
committer header fields. --grep-reflog adds a fake "reflog" header to
commit and a grep filter to search on that line.
All rules to --author/--committer apply except no timestamp stripping.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently using "git rm" on a submodule - populated or not - fails with
this error:
fatal: git rm: '<submodule path>': Is a directory
This made sense in the past as there was no way to remove a submodule
without possibly removing unpushed parts of the submodule's history
contained in its .git directory too, so erroring out here protected the
user from possible loss of data.
But submodules cloned with a recent git version do not contain the .git
directory anymore, they use a gitfile to point to their git directory
which is safely stored inside the superproject's .git directory. The work
tree of these submodules can safely be removed without losing history, so
let's teach git to do so.
Using rm on an unpopulated submodule now removes the empty directory from
the work tree and the gitlink from the index. If the submodule's directory
is missing from the work tree, it will still be removed from the index.
Using rm on a populated submodule using a gitfile will apply the usual
checks for work tree modification adapted to submodules (unless forced).
For a submodule that means that the HEAD is the same as recorded in the
index, no tracked files are modified and no untracked files that aren't
ignored are present in the submodules work tree (ignored files are deemed
expendable and won't stop a submodule's work tree from being removed).
That logic has to be applied in all nested submodules too.
Using rm on a submodule which has its .git directory inside the work trees
top level directory will just error out like it did before to protect the
repository, even when forced. In the future git could either provide a
message informing the user to convert the submodule to use a gitfile or
even attempt to do the conversion itself, but that is not part of this
change.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git submodule" command DWIMs the command line and assumes a
unspecified action word for 'status' action. This is a UI mistake
that leads to a confusing behaviour. A mistyped command name is
instead treated as a request for 'status' of the submodule with that
name, e.g.
$ git submodule show
error: pathspec 'show' did not match any file(s) known to git.
Did you forget to 'git add'?
Stop DWIMming an unknown or mistyped subcommand name as pathspec
given to unspelled "status" subcommand. "git submodule" without any
argument is still interpreted as "git submodule status", but its
value is questionable.
Adjust t7400 to match, and stop advertising the default subcommand
being 'status' which does not help much in practice, other than
promoting laziness and confusion.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Running "whatchanged --graph -m" on a simple two-head merges
can fall into infinite loop.
Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Various documentation fixups.
* po/maint-docs:
Doc branch: show -vv option and alternative
Doc clean: add See Also link
Doc add: link gitignore
Doc: separate gitignore pattern sources
Doc: shallow clone deepens _to_ new depth
"git fetch --all", when passed "--no-tags", did not honor the
"--no-tags" option while fetching from individual remotes (the same
issue existed with "--tags", but combination "--all --tags" makes
much less sense than "--all --no-tags").
* dj/fetch-all-tags:
fetch --all: pass --tags/--no-tags through to each remote
submodule: use argv_array instead of hand-building arrays
fetch: use argv_array instead of hand-building arrays
argv-array: fix bogus cast when freeing array
argv-array: add pop function
Make it clear to people who (rightly or wrongly) think that the
"--follow" option should follow origin across while-file renames
that we already do so. That would explain the output that they see
when they do give the "--follow" option to the command.
We may or may not want to do a "--no-follow" patch as a follow-up,
but that is a separate topic.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Finishing touch to update documentation of string-list to make sure
the earlier rewrite of ref-list match logic that depends on its sort
order will not get broken.
* mh/fetch-filter-refs:
string_list API: document what "sorted" means
After running "git clone --single", the resulting repository has the
usual default "+refs/heads/*:refs/remotes/origin/*" wildcard fetch
refspec installed, which means that a subsequent "git fetch" will
end up grabbing all the other branches.
Update the fetch refspec to cover only the singly cloned ref instead
to correct this.
That means:
If "--single" is used without "--branch" or "--mirror", the
fetch refspec covers the branch on which remote's HEAD points to.
If "--single" is used with "--branch", it'll cover only the branch
specified in the "--branch" option.
If "--single" is combined with "--mirror", then it'll cover all
refs of the cloned repository.
If "--single" is used with "--branch" that specifies a tag, then
it'll cover only the ref for this tag.
Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The pretty formats for GPG signatures were introduced but never
documented. Use the documentation from the commit that introduced them.
Do the same for the --show-signature option added to git log and
friends.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Indicate that the -v option can be given twice in the short options.
Without it users pass over the option. Also indicate the alternate
'git remote show' method.
Signed-off-by: Philip Oakley <philipoakley@iee.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
'git clean' is controlled by gitignore. Provide See Also link for it.
Use of core.excludesfile is implied.
Signed-off-by: Philip Oakley <philipoakley@iee.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use a gitignore link rather than the gitrepository-
layout link.
Signed-off-by: Philip Oakley <philipoakley@iee.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use separate bulleted paragraphs for the three different gitignore
pattern sources.
Signed-off-by: Philip Oakley <philipoakley@iee.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Clarify that 'depth=' specifies the new depth from the remote's
branch tip. It does not add the depth to the existing shallow clone.
(details from pack-protocol.txt).
Clarify that tags are not fetched. (details from shallow.txt)
Signed-off-by: Philip Oakley <philipoakley@iee.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Fix a long-standing bug in "git log --grep" when multiple "--grep"
are used together with "--all-match" and "--author" or "--committer".
* jc/maint-log-grep-all-match:
t7810-grep: test --all-match with multiple --grep and --author options
t7810-grep: test interaction of multiple --grep and --author options
t7810-grep: test multiple --author with --all-match
t7810-grep: test multiple --grep with and without --all-match
t7810-grep: bring log --grep tests in common form
grep.c: mark private file-scope symbols as static
log: document use of multiple commit limiting options
log --grep/--author: honor --all-match honored for multiple --grep patterns
grep: show --debug output only once
grep: teach --debug option to dump the parse tree
Turn many file-scope private symbols to static to reduce the
global namespace contamination.
* jc/make-static:
sequencer.c: mark a private file-scope symbol as static
ident.c: mark private file-scope symbols as static
trace.c: mark a private file-scope symbol as static
wt-status.c: mark a private file-scope symbol as static
read-cache.c: mark a private file-scope symbol as static
strbuf.c: mark a private file-scope symbol as static
sha1-array.c: mark a private file-scope symbol as static
symlinks.c: mark private file-scope symbols as static
notes.c: mark a private file-scope symbol as static
rerere.c: mark private file-scope symbols as static
graph.c: mark private file-scope symbols as static
diff.c: mark a private file-scope symbol as static
commit.c: mark a file-scope private symbol as static
builtin/notes.c: mark file-scope private symbols as static
Add '--conflict' option to git-p4 subcommand to specify what action
to take when conflicts are found during 'p4 submit'.
* pw/p4-submit-conflicts:
git-p4: add submit --conflict option and config varaiable
git p4: add submit --prepare-p4-only option
git p4: add submit --dry-run option
git p4: accept -v for --verbose
git p4: revert deleted files after submit cancel
git p4: rearrange submit template construction
git p4: test clean-up after failed submit, fix added files
git p4: standardize submit cancel due to unchanged template
git p4: move conflict prompt into run, add [q]uit input
git p4: remove submit failure options [a]pply and [w]rite
git p4: gracefully fail if some commits could not be applied
git p4 test: remove bash-ism of combined export/assignment
Avoid confusion in compound sentence about the start of the commit set
and the depth measure. Use two sentences.
Signed-off-by: Philip Oakley <philipoakley@iee.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The note that explains that changes introduced by removed commits are
preserved should be placed directly after the paragraph that describes
such commits removal. Otherwise the reference to "the commits" appears
out of context.
Also the big example that follows "Consider this history" is about
rewriting part of the history DAG. Move the paragraph that
describes the operation close to it.
Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The recent work on using string_list to represent the list of refs
that matched with the refs on the other side during fetch heavily
depends on the sort order by string_list's implementation, and
changing string_list will break it. Document that it uses strcmp()
order, at least for now.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This allows users to edit the todo file while they're stopped in the
middle of an interactive rebase. When this action is executed, all
comments from the original todo file are stripped, and new help messages
are appended to the end.
Signed-off-by: Andrew Wong <andrew.kw.w@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
t/perf: add "trash directory" to .gitignore
Add missing -z to git check-attr usage text for consistency with man page
git-jump: ignore (custom) prefix in diff mode
Documentation: indent-with-non-tab uses "equivalent tabs" not 8
completion: add --no-edit to git-commit
Update parts of document that talked about "first line of commit
log" to say "title of commit" with definition of what that "title"
is.
* jw/doc-commit-title:
Documentation: describe subject more precisely
* mh/string-list:
api-string-list.txt: initialize the string_list the easy way
string_list: add a function string_list_longest_prefix()
string_list: add a new function, string_list_remove_duplicates()
string_list: add a new function, filter_string_list()
string_list: add two new functions for splitting strings
string_list: add function string_list_append_nodup()
Update the documentation of the core.whitespace option
"indent-with-non-tab" to correctly reflect that it catches the use of
spaces instead of the equivalent tabs, rather than a fixed number.
Signed-off-by: Wesley J. Landaker <wjl@icecavern.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add Ada xfuncname and wordRegex patterns to the list of builtin
patterns.
Signed-off-by: Adrian Johnson <ajohnson@redneon.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This allows specifying what to do when a conflict
happens when applying a commit to p4, automating the
interactive prompt.
Signed-off-by: Pete Wyckoff <pw@padd.com>
Acked-by: Luke Diamand <luke@diamand.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This option can be used to prepare the client workspace for
submission, only. It does not invoke the final "p4 submit".
A message describes how to proceed, either submitting the
changes or reverting.
Signed-off-by: Pete Wyckoff <pw@padd.com>
Acked-by: Luke Diamand <luke@diamand.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A new option, "git p4 submit --dry-run" can be used to verify
what commits and labels would be moved into p4.
Signed-off-by: Pete Wyckoff <pw@padd.com>
Acked-by: Luke Diamand <luke@diamand.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The short form "-v" is common in many git commands as an
alias for "--verbose".
Signed-off-by: Pete Wyckoff <pw@padd.com>
Acked-by: Luke Diamand <luke@diamand.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git merge -Xtheirs" did not help content-level merge of binary
files; it should just take their version. Also "*.jpg binary" in
the attributes did not imply they should use the binary ll-merge
driver.
* jc/ll-merge-binary-ours:
ll-merge: warn about inability to merge binary files only when we can't
attr: "binary" attribute should choose built-in "binary" merge driver
merge: teach -Xours/-Xtheirs to binary ll-merge driver
* mz/cherry-pick-cmdline-order:
cherry-pick/revert: respect order of revisions to pick
demonstrate broken 'git cherry-pick three one two'
teach log --no-walk=unsorted, which avoids sorting
* jc/maint-checkout-fileglob-doc:
gitcli: contrast wildcard given to shell and to git
gitcli: formatting fix
Document file-glob for "git checkout -- '*.c'"
Generally speaking, using more options will further narrow the
selection, but there are a few exceptions. Document them.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The discussion of email subject throughout the documentation is
misleading; it indicates that the first line will always become
the subject. In fact, the subject is generally all lines up until
the first full blank line.
This patch refines that, and makes more use of the concept of a
commit title, with the title being all text up to the first blank line.
Signed-off-by: Jeremy White <jwhite@codeweavers.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Updated with help from Peff.
* jc/maint-checkout-fileglob-doc:
gitcli: contrast wildcard given to shell and to git
gitcli: formatting fix
Document file-glob for "git checkout -- '*.c'"
Describe the following in the draft release notes:
. jc/apply-binary-p0
. jc/dotdot-is-parent-directory
. jc/maint-doc-checkout-b-always-takes-branch-name
. jk/maint-http-half-auth-push
. kk/maint-for-each-ref-multi-sort
Yet to be merged before 1.7.12.1 are:
. jk/config-warn-on-inaccessible-paths
. jk/maint-quiet-is-synonym-to-s-in-log
. mz/cherry-pick-cmdline-order
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git log .." errored out saying it is both rev range and a path when
there is no disambiguating "--" is on the command line. Update the
command line parser to interpret ".." as a path in such a case.
* jc/dotdot-is-parent-directory:
specifying ranges: we did not mean to make ".." an empty set
The synopsis said "checkout [-B branch]" to make it clear the
branch name is a parameter to the option, but the heading for the
option description was "-B::", not "-B branch::", making the
documentation misleading.
* jc/maint-doc-checkout-b-always-takes-branch-name:
doc: "git checkout -b/-B/--orphan" always takes a branch name
In the demo code blurb, show how to initialize the string_list using
STRING_LIST_INIT_NODUP rather than memset().
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add a function that finds the longest string from a string_list that
is a prefix of a given string.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add a function that deletes duplicate entries from a sorted
string_list.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This function allows entries that don't match a specified criterion to
be discarded from a string_list while preserving the order of the
remaining entries.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add two new functions, string_list_split() and
string_list_split_in_place(). These split a string into a string_list
on a separator character. The first makes copies of the substrings
(leaving the input string untouched) and the second splits the
original string in place, overwriting the separator characters with
NULs and referring to the original string's memory.
These functions are similar to the strbuf_split_*() functions except
that they work with the more powerful string_list interface.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add a new function that appends a string to a string_list without
copying it. This can be used to pass ownership of an already-copied
string to a string_list that has strdup_strings set.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use argv-array API in "git fetch" implementation.
* jk/argv-array:
submodule: use argv_array instead of hand-building arrays
fetch: use argv_array instead of hand-building arrays
argv-array: fix bogus cast when freeing array
argv-array: add pop function
Optimise the "merge-base" computation a bit, and also update its
users that do not need the full merge-base information to call a
cheaper subset.
* jc/merge-bases:
reduce_heads(): reimplement on top of remove_redundant()
merge-base: "--is-ancestor A B"
get_merge_bases_many(): walk from many tips in parallel
in_merge_bases(): use paint_down_to_common()
merge_bases_many(): split out the logic to paint history
in_merge_bases(): omit unnecessary redundant common ancestor reduction
http-push: use in_merge_bases() for fast-forward check
receive-pack: use in_merge_bases() for fast-forward check
in_merge_bases(): support only one "other" commit
We will wait for a handful of other fixes that have graduated to the
'master' for 1.8.0 to be tested in the wild and then tag 1.7.12.1:
. mz/cherry-pick-cmdline-order
. jk/maint-quiet-is-synonym-to-s-in-log
. jk/maint-http-half-auth-push
. jc/apply-binary-p0
. jk/config-warn-on-inaccessible-paths
. kk/maint-for-each-ref-multi-sort
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jk/check-docs-update:
check-docs: get documented command list from Makefile
check-docs: drop git-help special-case
check-docs: list git-gui as a command
check-docs: factor out command-list
command-list: mention git-credential-* helpers
command-list: add git-sh-i18n
check-docs: update non-command documentation list
check-docs: mention gitweb specially
"git branch --set-upstream origin/master" is a common mistake to
create a local branch 'origin/master' and set it to integrate with
the current branch. With a plan to deprecate this option, introduce
"git branch (-u|--set-upstream-to) origin/master" that sets the
current branch to integrate with 'origin/master' remote tracking
branch.
* cn/branch-set-upstream-to:
branch: deprecate --set-upstream and show help if we detect possible mistaken use
branch: add --unset-upstream option
branch: introduce --set-upstream-to
"git cherry-pick A C B" used to replay changes in A and then B and
then C if these three commits had committer timestamps in that
order, which is not what the user who said "A C B" naturally expects.
* mz/cherry-pick-cmdline-order:
cherry-pick/revert: respect order of revisions to pick
demonstrate broken 'git cherry-pick three one two'
teach log --no-walk=unsorted, which avoids sorting
* maint-1.7.11:
Almost 1.7.11.6
gitweb: URL-decode $my_url/$my_uri when stripping PATH_INFO
rebase -i: use full onto sha1 in reflog
sh-setup: protect from exported IFS
receive-pack: do not leak output from auto-gc to standard output
t/t5400: demonstrate breakage caused by informational message from prune
setup: clarify error messages for file/revisions ambiguity
send-email: improve RFC2047 quote parsing
fsck: detect null sha1 in tree entries
do not write null sha1s to on-disk index
diff: do not use null sha1 as a sentinel value
People who are not used to working with shell may intellectually
understand how the command line argument is massaged by the shell
but still have a hard time visualizing the difference between
letting the shell expand fileglobs and having Git see the fileglob
to use as a pathspec.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The paragraph to encourage use of "--" in scripts belongs to the
bullet point that describes the behaviour for a command line without
the explicit "--" disambiguation; it is not a supporting explanation
for the entire bulletted list, and it is wrong to make it a separate
paragraph outside the list.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The built-in "binary" attribute macro expands to "-diff -text", so
that textual diff is not produced, and the contents will not go
through any CR/LF conversion ever. During a merge, it should also
choose the "binary" low-level merge driver, but it didn't.
Make it expand to "-diff -merge -text".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The (discouraged) -Xours/-Xtheirs modes of merge are supposed to
give a quick and dirty way to come up with a random mixture of
cleanly merged parts and punted conflict resolution to take contents
from one side in conflicting parts. These options however were only
passed down to the low level merge driver for text.
Teach the built-in binary merge driver to notice them as well.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Output from "git branch -v" contains "(no branch)" that could be
localized, but the code to align it along with the names of branches
were counting in bytes, not in display columns.
* nd/branch-v-alignment:
branch -v: align even when branch names are in UTF-8
The synopsis said "checkout [-B branch]" to make it clear the branch
name is a parameter to the option, but the heading for the option
description was "-B::", not "-B branch::", making the documentation
misleading. There may be room in documentation pages of other
commands for similar improvements.
* jc/maint-doc-checkout-b-always-takes-branch-name:
doc: "git checkout -b/-B/--orphan" always takes a branch name
"git log .." errored out saying it is both rev range and a path when
there is no disambiguating "--" is on the command line. Update the
command line parser to interpret ".." as a path in such a case.
* jc/dotdot-is-parent-directory:
specifying ranges: we did not mean to make ".." an empty set
While looking for a way to expand the URL of a remote
that uses a 'url.<name>.insteadOf' config option I stumbled
over the undocumented '--get-url' option of 'git ls-remote'.
This adds some minimum documentation for that option.
And while at it, also add that option to the '-h' output.
Signed-off-by: Stefan Naewe <stefan.naewe@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
rev-list-options.txt is included in git-rev-list.txt. This makes sure
rev-list man page also shows that, and at one place, together with
equivalent options -n and --max-count.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
All remote subcommands are spelled out words except 'rm'. 'rm', being a
popular UNIX command name, may mislead users that there are also 'ls' or
'mv'. Use 'remove' to fit with the rest of subcommands.
'rm' is still supported and used in the test suite. It's just not
widely advertised.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git submodule update --force" used to leave the working tree of the
submodule intact when there were local changes. It is more intiutive
to make "--force" a sign to run "checkout -f" to overwrite them.
* sz/submodule-force-update:
Make 'git submodule update --force' always check out submodules.
Allow an external command to tell git-daemon to decline service
based on the client address, repository path, etc.
* jc/daemon-access-hook:
daemon: --access-hook option
"git cherry-pick" by default stops when it sees a commit without any
log message. The "--allow-empty-message" option can be used to
silently proceed.
* cw/cherry-pick-allow-empty-message:
cherry-pick: add --allow-empty-message option
The exit status code from "git config" was way overspecified while
being incorrect. Update the implementation to give the documented
status for a case that was documented, and introduce a new code for
"all other errors".
* jc/maint-config-exit-status:
config: "git config baa" should exit with status 1
Sometimes we build a set of similar command lines, differing
only in the final arguments (e.g., "fetch --multiple"). To
use argv_array for this, you have to either push the same
set of elements repeatedly, or break the abstraction by
manually manipulating the array's internal members.
Instead, let's provide a sanctioned "pop" function to remove
elements from the end.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In many scripted Porcelain commands, we find this idiom:
if test "$(git rev-parse --verify A)" = "$(git merge-base A B)"
then
... A is an ancestor of B ...
fi
But you do not have to compute exact merge-base only to see if A is
an ancestor of B. Give them a more direct way to use the underlying
machinery.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When 'git log' is passed the --no-walk option, no revision walk takes
place, naturally. Perhaps somewhat surprisingly, however, the provided
revisions still get sorted by commit date. So e.g 'git log --no-walk
HEAD HEAD~1' and 'git log --no-walk HEAD~1 HEAD' give the same result
(unless the two revisions share the commit date, in which case they
will retain the order given on the command line). As the commit that
introduced --no-walk (8e64006 (Teach revision machinery about
--no-walk, 2007-07-24)) points out, the sorting is intentional, to
allow things like
git log --abbrev-commit --pretty=oneline --decorate --all --no-walk
to show all refs in order by commit date.
But there are also other cases where the sorting is not wanted, such
as
<command producing revisions in order> |
git log --oneline --no-walk --stdin
To accomodate both cases, leave the decision of whether or not to sort
up to the caller, by allowing --no-walk={sorted,unsorted}, defaulting
to 'sorted' for backward-compatibility reasons.
Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We have ways of setting the upstream information, but if we want to
unset it, we need to resort to modifying the configuration manually.
Teach branch an --unset-upstream option that unsets this information.
Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The documentation in the TeXinfo format was using indented output
for materials meant to be examples that are better typeset in
monospace.
* jk/docs-docbook-monospace-display:
docs: monospace listings in docbook output
"git difftool --dir-diff" learned to use symbolic links to prepare
temporary copy of the working tree when available.
* da/difftool-updates:
difftool: silence warning
Add Code Compare v2.80.4 as a merge / diff tool for Windows
mergetool,difftool: Document --tool-help consistently
difftool: Disable --symlinks on cygwin
difftool: Handle compare() returning -1
difftool: Wrap long lines for readability
difftool: Check all return codes from compare()
difftool: Handle finding mergetools/ in a path with spaces
difftool: Use symlinks when diffing against the worktree
difftool: Call the temp directory "git-difftool"
difftool: Move option values into a hash
difftool: Eliminate global variables
difftool: Simplify print_tool_help()
"grep" learned to use a non-standard pattern type by default if a
configuration variable tells it to.
* js/grep-patterntype-config:
grep: add a grep.patternType configuration setting
Branch names are usually in ASCII so they are not the problem. The
problem most likely comes from "(no branch)" translation, which is
in UTF-8 and makes display-width calculation just wrong. Clarify
this by renaming the field "len" in struct ref_item to "width", as
it stores the display-width and is used to compute the width of the
screen needed to show the names of all the branches, and compute the
display width using utf8_strwidth(), not byte-length with strlen().
Update document to mention the fact that we may want ref names in
UTF-8. Encodings that produce invalid UTF-8 are safe as utf8_strwidth()
falls back to strlen(). The ones that incidentally produce valid UTF-8
sequences will cause misalignment.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
While the synopsis section makes it clear that the new branch name
is the parameter to these flags, the option description did not.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint-1.7.11:
Prepare for 1.7.11.6
Make the ciabot scripts completely self-configuring in the normal case.
Improved documentation for the ciabot scripts.
man: git pull -r is a short for --rebase
gitcli: describe abbreviation of long options
rev-list docs: clarify --topo-order description
Documentation/CodingGuidelines: spell out more shell guidelines
Documentation: do not mention .git/refs/* directories
tests: Introduce test_seq
We did not document that many commands take unique prefix
abbreviations of long options (e.g. "--option" may be the only flag
that the command accepts that begin with "--opt", in which case you
can give "--opt") anywhere easy to find for new people.
* jc/maint-abbrev-option-cli:
gitcli: describe abbreviation of long options
It was unclear what "--topo-order" was really about in the
documentation. It is not just about "children before parent", but
also about "don't mix lineages".
* jc/maint-rev-list-topo-doc:
rev-list docs: clarify --topo-order description
In earlier days, "imitate the style in the neibouring code" was
sufficient to keep the coherent style, but over time some parts of
the codebase have drifted enough to make it ineffective.
* hv/coding-guidelines:
Documentation/CodingGuidelines: spell out more shell guidelines
Our documentation used to assume having files in .git/refs/*
directories was the only to have branches and tags, but that is not
true for quite some time.
* jc/tag-doc:
Documentation: do not mention .git/refs/* directories
Currently, it will only do a checkout if the sha1 registered in the containing
repository doesn't match the HEAD of the submodule, regardless of whether the
submodule is dirty. As discussed on the mailing list, the '--force' flag is a
strong indicator that the state of the submodule is suspect, and should be reset
to HEAD.
Signed-off-by: Stefan Zager <szager@google.com>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Either end of revision range operator can be omitted to default to HEAD,
as in "origin.." (what did I do since I forked) or "..origin" (what did
they do since I forked). But the current parser interprets ".." as an
empty range "HEAD..HEAD", and worse yet, because ".." does exist on the
filesystem, we get this annoying output:
$ cd Documentation/howto
$ git log .. ;# give me recent commits that touch Documentation/ area.
fatal: ambiguous argument '..': both revision and filename
Use '--' to separate filenames from revisions
Surely we could say "git log ../" or even "git log -- .." to disambiguate,
but we shouldn't have to.
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The existing --set-uptream option can cause confusion, as it uses the
usual branch convention of assuming a starting point of HEAD if none
is specified, causing
git branch --set-upstream origin/master
to create a new local branch 'origin/master' that tracks the current
branch. As --set-upstream already exists, we can't simply change its
behaviour. To work around this, introduce --set-upstream-to which
accepts a compulsory argument indicating what the new upstream branch
should be and one optinal argument indicating which branch to change,
defaulting to HEAD.
The new options allows us to type
git branch --set-upstream-to origin/master
to set the current branch's upstream to be origin's master.
Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We did not document that many commands take unique prefix
abbreviations of long options (e.g. "--option" may be the only flag
that the command accepts that begin with "--opt", in which case you
can give "--opt") anywhere easy to find for new people.
* jc/maint-abbrev-option-cli:
gitcli: describe abbreviation of long options
It was unclear what "--topo-order" was really about in the
documentation. It is not just about "children before parent", but
also about "don't mix lineages".
* jc/maint-rev-list-topo-doc:
rev-list docs: clarify --topo-order description
In earlier days, "imitate the style in the neibouring code" was
sufficient to keep the coherent style, but over time some parts of
the codebase have drifted enough to make it ineffective.
* hv/coding-guidelines:
Documentation/CodingGuidelines: spell out more shell guidelines
Simplify "make check-docs" implementation and update its coverage.
* jk/check-docs-update:
check-docs: get documented command list from Makefile
check-docs: drop git-help special-case
check-docs: list git-gui as a command
check-docs: factor out command-list
command-list: mention git-credential-* helpers
command-list: add git-sh-i18n
check-docs: update non-command documentation list
check-docs: mention gitweb specially
Our documentation used to assume having files in .git/refs/*
directories was the only to have branches and tags, but that is not
true for quite some time.
* jc/tag-doc:
Documentation: do not mention .git/refs/* directories
One fictitious command "proxy-command" is enclosed inside a double
quote pair, while another fictitious command "default-proxy" is not
in the example, but the quoting does not change anything in the pair
of examples. Remove the quotes to avoid unnecessary confusion.
Noticed by Michael Haggerty.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The "--add" option is required to add a new value to a multivalued
configuration entry.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The second paragraph in the git(1) description section were meant to
guide people who are not ready to dive into this page away from here.
Referring migrating CVS users to another page before they get
acquainted with Git was somewhat out of place. Move the reference to
the "FURTHER DOCUMENTATION" section and push that section down.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The one at kernel.org has not been updated for quite a while and
can no longer be called "the latest".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Letting the "--rebase" option squat on the short-and-sweet single
letter option "-r" was an unintended accident and was not even
documented, but the short option seems to be already used in the
wild. Let's document it so that other options that begin with "r"
would not be tempted to steal it.
Signed-off-by: Miklos Vajna <vmiklos@suse.cz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It was unclear what "--topo-order" was really about in the
documentation. It is not just about "children before parent", but
also about "don't mix lineages".
Reword the description for both "--date-order" and "--topo-order",
and add an illustration to it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The --access-hook option to "git daemon" specifies an external
command to be run every time a client connects, with
- service name (e.g. "upload-pack", etc.),
- path to the repository,
- hostname (%H),
- canonical hostname (%CH),
- ip address (%IP),
- tcp port (%P)
as its command line arguments. The external command can decide to
decline the service by exiting with a non-zero status (or to allow it
by exiting with a zero status). It can also look at the $REMOTE_ADDR
and $REMOTE_PORT environment variables to learn about the requestor
when making this decision.
The external command can optionally write a single line to its
standard output to be sent to the requestor as an error message when
it declines the service.
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In earlier days, "imitate the style in the neibouring code" was
sufficient to keep the coherent style, but over time some parts of
the codebase have drifted enough to make it ineffective.
Spell some of the guidelines out.
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add an entry for --tool-help to the mergetool documentation.
Move --tool-help in the difftool documentation so that it is
listed immediately after --tool so that it is easier to find.
Signed-off-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The current code tries to get a list of documented commands
by doing "ls Documentation/git*txt" and culling a bunch of
special cases from the result. Looking for "git-*.txt" would
be more accurate, but would miss a few commands like
"gitweb" and "gitk".
Fortunately, Documentation/Makefile already knows what this
list is, so we can just ask it. Annoyingly, we still have to
post-process its output a little, since make will print
extra cruft like "GIT-VERSION-FILE is up to date" to stdout.
Now that our list is accurate, we can remove all of the ugly
special-cases.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These commands were never added to the command-list. Adding
them makes "make check-docs" run without complaint.
While we're at it, let's capitalize the first letter of
their one-line summaries to match the rest of the git
manpages.
The credential-cache--daemon command is somewhat special. It
is already ignored by check-docs because it contains a "--",
marking it as a non-interesting implementation detail. It
is, in fact, documented, but since the documentation
basically just redirects you to a more appropriate command
anyway, let's explicitly omit it so it is not mentioned in
git(1).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit e30b2feb1b (Jun 24 2012, add 'git credential' plumbing command)
forgot to add git-credential to command-list.txt, hence the command was
not appearing in the documentation, making it hard for users to discover
it.
While we're there, capitalize the description line for git-crendential
for consistency with other commands.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When asciidoc converts a listing block like:
----------------------
$ git log --merge
----------------------
it marks it to be displayed in a monospace font. This works
fine when generating HTML output. However, when generating
docbook output, we override the expansion of a listingblock
to work around bugs in some versions of the docbook
toolchain. Our override did not mark the listingblock with
the "monospaced" class.
The main output that uses docbook as an intermediate format
is the manpages. We didn't notice any issue there because
the monospaced class seems to be ignored when generating
roff from the docbook manpages.
However, when generating texinfo to make info pages, docbook
does respect this class. The resulting texinfo output
properly uses "@example" blocks to display the listing in
this case. Besides possibly looking prettier in some texinfo
backends, one important effect is that the monospace font
suppresses texinfo's expansion of "--" and "---" into
en-dashes and em-dashes. With the current code, the example
above ends up looking like "git log -merge", which is
confusing and wrong.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
- (glossary) the quotes around the Wikipedia URL prevented its
linkification in frontends that support it; remove them
- (manual) newer version (SHA-1) == following, older == preceding, not
the other way around
- trivial typo and wording fixes
Signed-off-by: Štěpán Němec <stepnem@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It is an implementation detail that a new tag is created by adding a
file in the .git/refs/tags directory. The only thing the user needs
to know is that a "git tag" creates a ref in the refs/tags namespace,
and without "-f", it does not overwrite an existing tag.
Inspired by a report from 乙酸鋰 <ch3cooli@gmail.com>; I think I
caught all the existing mention in Documentation/ directory in the
tip of 1.7.9.X maintenance track, but we may have added new ones
since then.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Scripts such as "git rebase -i" cannot currently cherry-pick commits
which have an empty commit message, as git cherry-pick calls git
commit without the --allow-empty-message option.
Add an --allow-empty-message option to git cherry-pick which is passed
through to git commit, so this behaviour can be overridden.
Signed-off-by: Chris Webb <chris@arachsys.com>
Reviewed-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The grep.extendedRegexp configuration setting enables the -E flag on grep
by default but there are no equivalents for the -G, -F and -P flags.
Rather than adding an additional setting for grep.fooRegexp for current
and future pattern matching options, add a grep.patternType setting that
can accept appropriate values for modifying the default grep pattern
matching behavior. The current values are "basic", "extended", "fixed",
"perl" and "default" for setting -G, -E, -F, -P and the default behavior
respectively.
When grep.patternType is set to a value other than "default", the
grep.extendedRegexp setting is ignored. The value of "default" restores
the current default behavior, including the grep.extendedRegexp
behavior.
Signed-off-by: J Smith <dark.panda@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"$GIT_DIR/COMMIT_EDITMSG" file that is used to hold the commit log
message user edits was not documented.
* jk/maint-commit-document-editmsg:
commit: document the temporary commit message file
"git commit-tree" learned a more natural "-p <parent> <tree>" order
of arguments long time ago, but recently forgot it by mistake.
* kk/maint-commit-tree:
Revert "git-commit-tree(1): update synopsis"
commit-tree: resurrect command line parsing updates
When "git am" failed, old timers knew to check .git/rebase-apply/patch
to see what went wrong, but we never told the users about it.
* pg/maint-1.7.9-am-where-is-patch:
am: indicate where a failed patch is to be found
We instead failed with an undocumented exit status 255.
Also define a "catch-all" status and document it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It was a bit hard to learn how <rev>^@, <rev>^! and various other
forms of range specifiers are used, because they were discussed
mostly in the prose part of the documentation, unlike various forms
of extended SHA-1 expressions that are listed in an enumerated list.
Also add a few more examples showing use of <rev>, <rev>..<rev> and
<rev>^! forms, stolen from a patch by Max Horn.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git mergetool" did not support --tool-help option to give the list
of supported backends, like "git difftool" does.
* jc/mergetool-tool-help:
mergetool: support --tool-help option like difftool does
We do not document COMMIT_EDITMSG at all, but users may want
to know about it for two reasons:
1. They may want to tell their editor to configure itself
for formatting a commit message.
2. If a commit is aborted by an error, the user may want
to recover the commit message they typed.
Let's put a note in git-commit(1).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This way we do not have to risk the list of tools going out of sync
between the implementation and the documentation.
In the same spirit as bf73fc2 (difftool: print list of valid tools
with '--tool-help', 2012-03-29), trim the list of merge backends in
the documentation. We do not want to have a complete list of valid
tools; we only want a list to help people guess what kind of things
the tools do to be specified there, and refer them to --tool-help
for a complete list.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Teach difftool's --dir-diff mode to use symlinks to represent
files from the working copy, and make it the default behavior
for the non-Windows platforms.
Using symlinks is simpler and safer since we do not need to
worry about copying files back into the worktree.
The old behavior is still available as --no-symlinks.
Signed-off-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When "git am" failed, old timers knew to check .git/rebase-apply/patch
to see what went wrong, but we never told the users about it.
* pg/maint-1.7.9-am-where-is-patch:
am: indicate where a failed patch is to be found
Teaches the object name parser things like a "git describe" output
is always a commit object, "A" in "git log A" must be a committish,
and "A" and "B" in "git log A...B" both must be committish, etc., to
prolong the lifetime of abbreviated object names.
* jc/sha1-name-more: (27 commits)
t1512: match the "other" object names
t1512: ignore whitespaces in wc -l output
rev-parse --disambiguate=<prefix>
rev-parse: A and B in "rev-parse A..B" refer to committish
reset: the command takes committish
commit-tree: the command wants a tree and commits
apply: --build-fake-ancestor expects blobs
sha1_name.c: add support for disambiguating other types
revision.c: the "log" family, except for "show", takes committish
revision.c: allow handle_revision_arg() to take other flags
sha1_name.c: introduce get_sha1_committish()
sha1_name.c: teach lookup context to get_sha1_with_context()
sha1_name.c: many short names can only be committish
sha1_name.c: get_sha1_1() takes lookup flags
sha1_name.c: get_describe_name() by definition groks only commits
sha1_name.c: teach get_short_sha1() a commit-only option
sha1_name.c: allow get_short_sha1() to take other flags
get_sha1(): fix error status regression
sha1_name.c: restructure disambiguation of short names
sha1_name.c: correct misnamed "canonical" and "res"
...
The git-credential command requires that you feed it a
broken-down credential, which means that the client needs to
parse a URL itself. Since we have our own URL-parsing
routines, we can easily allow the caller to just give us the
URL as-is, saving them some code.
Signed-off-by: Jeff King <peff@peff.net>
Acked-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The text in git-credential(1) was copied from
technical/api-credentials, so it still talks about the
input/output format as coming from git to the helper. Since
the surrounding text already indicates that this format is
used for reading and writing with git credential, we can
just remove the extraneous confusing bits.
Signed-off-by: Jeff King <peff@peff.net>
Acked-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git apply" learned to wiggle the base version and perform three-way
merge when a patch does not exactly apply to the version you have.
* jc/apply-3way:
apply: tests for the --3way option
apply: document --3way option
apply: allow rerere() to work on --3way results
apply: register conflicted stages to the index
apply: --3way with add/add conflict
apply: move verify_index_match() higher
apply: plug the three-way merge logic in
apply: fall back on three-way merge
apply: accept -3/--3way command line option
apply: move "already exists" logic to check_to_create()
apply: move check_to_create_blob() closer to its sole caller
apply: further split load_preimage()
apply: refactor "previous patch" logic
apply: split load_preimage() helper function out
apply: factor out checkout_target() helper function
apply: refactor read_file_or_gitlink()
apply: clear_image() clears things a bit more
apply: a bit more comments on PATH_TO_BE_DELETED
apply: fix an incomplete comment in check_patch()
"git rebase [-i] --root $tip" can now be used to rewrite all the
history down to the root.
* cw/rebase-i-root:
t3404: make test 57 work with dash and others
Add tests for rebase -i --root without --onto
rebase -i: support --root without --onto
- (glossary) the quotes around the Wikipedia URL prevented its
linkification in frontends that support it; remove them
- (manual) newer version (SHA-1) == following, older == preceding, not
the other way around
- trivial typo and wording fixes
Signed-off-by: Štěpán Němec <stepnem@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If "git am" fails to apply something, the end user may need to know
where to find the patch that failed to apply, so that the user can
do other things (e.g. trying "GNU patch" on it, running "diffstat"
to see what it tried to change, etc.) The input to "am" may have
contained more than one patch, or the message may have been MIME
encoded, and knowing what the user fed to "am" does not help very
much for this purpose.
Also introduce advice.amworkdir configuration to allow people who
learned where to look to squelch this message.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Teaches git to normalize pathnames read from readdir(3) and all
arguments from the command line into precomposed UTF-8 (assuming
that they come as decomposed UTF-8) to work around issues on Mac OS.
I think there still are other places that need conversion
(e.g. paths that are read from stdin for some commands), but this
should be a good first step in the right direction.
* tb/sanitize-decomposed-utf-8-pathname:
git on Mac OS and precomposed unicode
The documentation for "git cherry-pick A B..C" was misleading.
* cn/cherry-pick-range-docs:
git-cherry-pick.txt: clarify the use of revision range notation
Documentation: --no-walk is no-op if range is specified
The new option allows you to feed an ambiguous prefix and enumerate
all the objects that share it as a prefix of their object names.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Expose the credential API to scripted Porcelain writers.
* mm/credential-plumbing:
git-remote-mediawiki: update comments to reflect credential support
git-remote-mediawiki: add credential support
git credential fill: output the whole 'struct credential'
add 'git credential' plumbing command
Teach git to read various information from $XDG_CONFIG_HOME/git/ to allow
the user to avoid cluttering $HOME.
* mm/config-xdg:
config: write to $XDG_CONFIG_HOME/git/config file when appropriate
Let core.attributesfile default to $XDG_CONFIG_HOME/git/attributes
Let core.excludesfile default to $XDG_CONFIG_HOME/git/ignore
config: read (but not write) from $XDG_CONFIG_HOME/git/config file
Mac OS X mangles file names containing unicode on file systems HFS+,
VFAT or SAMBA. When a file using unicode code points outside ASCII
is created on a HFS+ drive, the file name is converted into
decomposed unicode and written to disk. No conversion is done if
the file name is already decomposed unicode.
Calling open("\xc3\x84", ...) with a precomposed "Ä" yields the same
result as open("\x41\xcc\x88",...) with a decomposed "Ä".
As a consequence, readdir() returns the file names in decomposed
unicode, even if the user expects precomposed unicode. Unlike on
HFS+, Mac OS X stores files on a VFAT drive (e.g. an USB drive) in
precomposed unicode, but readdir() still returns file names in
decomposed unicode. When a git repository is stored on a network
share using SAMBA, file names are send over the wire and written to
disk on the remote system in precomposed unicode, but Mac OS X
readdir() returns decomposed unicode to be compatible with its
behaviour on HFS+ and VFAT.
The unicode decomposition causes many problems:
- The names "git add" and other commands get from the end user may
often be precomposed form (the decomposed form is not easily input
from the keyboard), but when the commands read from the filesystem
to see what it is going to update the index with already is on the
filesystem, readdir() will give decomposed form, which is different.
- Similarly "git log", "git mv" and all other commands that need to
compare pathnames found on the command line (often but not always
precomposed form; a command line input resulting from globbing may
be in decomposed) with pathnames found in the tree objects (should
be precomposed form to be compatible with other systems and for
consistency in general).
- The same for names stored in the index, which should be
precomposed, that may need to be compared with the names read from
readdir().
NFS mounted from Linux is fully transparent and does not suffer from
the above.
As Mac OS X treats precomposed and decomposed file names as equal,
we can
- wrap readdir() on Mac OS X to return the precomposed form, and
- normalize decomposed form given from the command line also to the
precomposed form,
to ensure that all pathnames used in Git are always in the
precomposed form. This behaviour can be requested by setting
"core.precomposedunicode" configuration variable to true.
The code in compat/precomposed_utf8.c implements basically 4 new
functions: precomposed_utf8_opendir(), precomposed_utf8_readdir(),
precomposed_utf8_closedir() and precompose_argv(). The first three
are to wrap opendir(3), readdir(3), and closedir(3) functions.
The argv[] conversion allows to use the TAB filename completion done
by the shell on command line. It tolerates other tools which use
readdir() to feed decomposed file names into git.
When creating a new git repository with "git init" or "git clone",
"core.precomposedunicode" will be set "false".
The user needs to activate this feature manually. She typically
sets core.precomposedunicode to "true" on HFS and VFAT, or file
systems mounted via SAMBA.
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Formerly, the documentation for <refname> would occasionally say
<name> instead of <refname>. Now it uniformly uses <refname>.
Signed-off-by: Max Horn <max@quendi.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
P4Submit.applyCommit()
To avoid recalculating the same diffOpts for each commit, move it
out of applyCommit() and into the top-level run(). Also fix a bug
in that code which interpreted the value of detectRenames as a
string rather than as a boolean.
[pw: fix documentation, rearrange code a bit]
Signed-off-by: Gary Gibbons <ggibbons@perforce.com>
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This fixes two formatting bugs in the git-config documentation:
- in the column.ui entry don't indent the last paragraph so that it isn't
formatted as a literal paragraph
- in the push.default entry separate the last paragraph from the
nested list.
Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Allow --root to be specified to rebase -i without --onto, making it
possible to edit and re-order all commits right back to the root(s).
If there is a conflict to be resolved when applying the first change,
the user will expect a sane index and working tree to get sensible
behaviour from git-diff and friends, so create a sentinel commit with an
empty tree to rebase onto. Automatically squash the sentinel with any
commits rebased directly onto it, so they end up as root commits in
their own right and retain their authorship and commit message.
Implicitly use rebase -i for non-interactive rebase of --root without
an --onto argument now that rebase -i can correctly do this.
Signed-off-by: Chris Webb <chris@arachsys.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Instead of outputing only the username and password, print all the
attributes, even those that already appeared in the input.
This is closer to what the C API does, and allows one to take the exact
output of "git credential fill" as input to "git credential approve" or
"git credential reject".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The credential API is in C, and not available to scripting languages.
Expose the functionalities of the API by wrapping them into a new
plumbing command "git credentials".
In other words, replace the internal "test-credential" by an official Git
command.
Most documentation writen by: Jeff King <peff@peff.net>
Signed-off-by: Pavel Volek <Pavel.Volek@ensimag.imag.fr>
Signed-off-by: Kim Thuat Nguyen <Kim-Thuat.Nguyen@ensimag.imag.fr>
Signed-off-by: Javier Roucher Iglesias <Javier.Roucher-Iglesias@ensimag.imag.fr>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The command line argument of "git cherry-pick maint master..next" is
just an ordinary revision range, which is unintuitive and at least
deserves documentation.
* cn/cherry-pick-range-docs:
git-cherry-pick.txt: clarify the use of revision range notation
Documentation: --no-walk is no-op if range is specified
We no longer use AsciiDoc7 syntax in our documentation and favor a
more modern style.
* jk/no-more-asciidoc7:
docs: drop antique comment from Makefile
docs: drop asciidoc7compatible flag
Teach git to write to $XDG_CONFIG_HOME/git/config if
- it already exists,
- $HOME/.gitconfig file doesn't, and
- The --global option is used.
Otherwise, write to $HOME/.gitconfig when the --global option is
given, as before.
If the user doesn't create $XDG_CONFIG_HOME/git/config, there is
absolutely no change. Users can use this new file only if they want.
If $XDG_CONFIG_HOME is either not set or empty, $HOME/.config/git/config
will be used.
Advice for users who often come back to an old version of Git: you
shouldn't create this file.
Signed-off-by: Huynh Khoi Nguyen Nguyen <Huynh-Khoi-Nguyen.Nguyen@ensimag.imag.fr>
Signed-off-by: Valentin Duperray <Valentin.Duperray@ensimag.imag.fr>
Signed-off-by: Franck Jonas <Franck.Jonas@ensimag.imag.fr>
Signed-off-by: Lucien Kong <Lucien.Kong@ensimag.imag.fr>
Signed-off-by: Thomas Nguy <Thomas.Nguy@ensimag.imag.fr>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This gives the default value for the core.attributesfile variable
following the exact same logic of the previous change for the
core.excludesfile setting.
Signed-off-by: Huynh Khoi Nguyen Nguyen <Huynh-Khoi-Nguyen.Nguyen@ensimag.imag.fr>
Signed-off-by: Valentin Duperray <Valentin.Duperray@ensimag.imag.fr>
Signed-off-by: Franck Jonas <Franck.Jonas@ensimag.imag.fr>
Signed-off-by: Lucien Kong <Lucien.Kong@ensimag.imag.fr>
Signed-off-by: Thomas Nguy <Thomas.Nguy@ensimag.imag.fr>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
To use the feature of core.excludesfile, the user needs:
1. to create such a file,
2. and add configuration variable to point at it.
Instead, we can make this a one-step process by choosing a default value
which points to a filename in the user's $HOME, that is unlikely to
already exist on the system, and only use the presence of the file as a
cue that the user wants to use that feature.
And we use "${XDG_CONFIG_HOME:-$HOME/.config/git}/ignore" as such a
file, in the same directory as the newly added configuration file
("${XDG_CONFIG_HOME:-$HOME/.config/git}/config). The use of this
directory is in line with XDG specification as a location to store
such application specific files.
Signed-off-by: Huynh Khoi Nguyen Nguyen <Huynh-Khoi-Nguyen.Nguyen@ensimag.imag.fr>
Signed-off-by: Valentin Duperray <Valentin.Duperray@ensimag.imag.fr>
Signed-off-by: Franck Jonas <Franck.Jonas@ensimag.imag.fr>
Signed-off-by: Lucien Kong <Lucien.Kong@ensimag.imag.fr>
Signed-off-by: Thomas Nguy <Thomas.Nguy@ensimag.imag.fr>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Teach git to read the "gitconfig" information from a new location,
$XDG_CONFIG_HOME/git/config; this allows the user to avoid
cluttering $HOME with many per-application configuration files.
In the order of reading, this file comes between the global
configuration file (typically $HOME/.gitconfig) and the system wide
configuration file (typically /etc/gitconfig).
We do not write to this new location (yet).
If $XDG_CONFIG_HOME is either not set or empty, $HOME/.config/git/config
will be used. This is in line with XDG specification.
If the new file does not exist, the behavior is unchanged.
Signed-off-by: Huynh Khoi Nguyen Nguyen <Huynh-Khoi-Nguyen.Nguyen@ensimag.imag.fr>
Signed-off-by: Valentin Duperray <Valentin.Duperray@ensimag.imag.fr>
Signed-off-by: Franck Jonas <Franck.Jonas@ensimag.imag.fr>
Signed-off-by: Lucien Kong <Lucien.Kong@ensimag.imag.fr>
Signed-off-by: Thomas Nguy <Thomas.Nguy@ensimag.imag.fr>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git clone --local $path" started its life as an experiment to
optionally use link/copy when cloning a repository on the disk, but
we didn't deprecate it after we made the option a no-op to always
use the optimization.
The command learns "--no-local" option to turn this off, as a more
explicit alternative over use of file:// URL.
* jk/clone-local:
clone: allow --no-local to turn off local optimizations
docs/clone: mention that --local may be ignored
Commit fe77b41 introduced a new attribute to let the linkgit macro
create cross-directory HTML references from the technical/ and howto/
subdirectories back to the main documentation. We define that attribute
to "../" on the command-line when building inside those subdirectories,
and otherwise leave it unset under the assumption that it would default
to being blank. Instead, asciidoc omits the link entirely, leading to
broken documentation. Fix this by defining git-relative-html-prefix to
blank in asciidoc.conf (and an instance on the command-line, when
present, will override it).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Even with many new kinds of options, the command still takes the
single <tree> as the first argument.
Probably we would want to update the command to allow it to take
<tree>-ish at the end for consistency.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When given a set of commits, cherry-pick will apply the changes for
all of them. Specifying a simple range will also work as expected.
This can lead the user to think that
git cherry-pick A B..C
may apply A and then B..C, but that is not what happens.
Instead the revs are given to a single invocation of rev-list, which
will consider A and C as positive revs and B as a negative one. The
commit A will not be used if it is an ancestor of B.
Add a note about this and add an example with this particular
syntax, which has shown up on the list a few times.
Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The existing description can be misleading and cause the reader to
think that --no-walk will do something if they specify a range in the
command line instead of a set of revs.
Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch provides new informative help messages in the display of
'git status' (at the top) during conflicts, rebase, am, bisect or
cherry-pick process.
The new messages are not shown when using options such as -s or
--porcelain. The messages about the current situation of the user are
always displayed but the advices on what the user needs to do in order
to resume a rebase/bisect/am/commit after resolving conflicts can be
hidden by setting advice.statushints to 'false' in the config file.
Thus, information about the updated advice.statushints key are added
in Documentation/config.txt.
Also, the test t7060-wt-status.sh is now working with the new help
messages. Tests about suggestions of "git rm" are also added.
Signed-off-by: Lucien Kong <Lucien.Kong@ensimag.imag.fr>
Signed-off-by: Valentin Duperray <Valentin.Duperray@ensimag.imag.fr>
Signed-off-by: Franck Jonas <Franck.Jonas@ensimag.imag.fr>
Signed-off-by: Thomas Nguy <Thomas.Nguy@ensimag.imag.fr>
Signed-off-by: Huynh Khoi Nguyen Nguyen <Huynh-Khoi-Nguyen.Nguyen@ensimag.imag.fr>
Signed-off-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
During an interactive rebase session, it is sometimes desirable to
run tests on each commit in the resulting history. This can be done
by adding "exec <test command>" when editing the insn sheet, but the
command used for testing is often the same for all resulting commits.
By passing "--exec <cmd>" from the command line, automatically add
these "exec" lines after each commit in the final history. To work
well with the --autosquash option, these are added at the end of
each run of "fixup" and "squash".
Helped-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Lucien Kong <Lucien.Kong@ensimag.imag.fr>
Signed-off-by: Valentin Duperray <Valentin.Duperray@ensimag.imag.fr>
Signed-off-by: Franck Jonas <Franck.Jonas@ensimag.imag.fr>
Signed-off-by: Thomas Nguy <Thomas.Nguy@ensimag.imag.fr>
Signed-off-by: Huynh Khoi Nguyen Nguyen <Huynh-Khoi-Nguyen.Nguyen@ensimag.imag.fr>
Signed-off-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It was unclear whether the field was to be specified by the user of the
API.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Most of our documentation is in a single directory, so using
linkgit:git-config[1] just generates a relative link in the
same directory. However, this is not the case with the API
documentation in technical/*, which need to refer to
git-config from the parent directory.
We can fix this by passing a special prefix attribute when building
in a subdirectory, and respecting that prefix in our linkgit
definitions.
We only have to modify the html linkgit definition. For
manpages, we can ignore this for two reasons:
1. we do not generate actual links to the file in
manpages, but instead just give the name and section of
the linked manpage
2. we do not currently build manpages for subdirectories,
only html
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Document git commit '--branch' and '--no-post-rewrite'. Mention that
'-z' can also be spelt as '--null'.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* mm/api-credentials-doc:
api-credentials.txt: add "see also" section
api-credentials.txt: mention credential.helper explicitly
api-credentials.txt: show the big picture first
doc: fix xref link from api docs to manual pages
The name of the configuration variable was mentioned only at the very
end of the explanation, in a place specific to a specific rule, hence it
was not very clear what the specification was about.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The API documentation targets two kinds of developers: those using the
C API, and those writing remote-helpers. The document was not clear
about which part was useful to which category, and for example, the C API
could be mistakenly thought as an API for writting remote helpers.
Based-on-patch-by: Jeff King <peff@peff.net>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git grep -e '$pattern'", unlike the case where the patterns are read from
a file, did not treat individual lines in the given pattern argument as
separate regular expressions as it should.
By René Scharfe
* rs/maint-grep-F:
grep: stop leaking line strings with -f
grep: support newline separated pattern list
grep: factor out do_append_grep_pat()
grep: factor out create_grep_pat()
This is basically the same as using "file://", but is a
little less subtle for the end user. It also allows relative
paths to be specified.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The --local flag is not "treat this like a local
repository", but rather "if we are local, turn on
optimizations". Therefore it does nothing in the case of:
git clone --local file:///path/to/repo
Let's make that more clear in the documentation.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This comment warns about a bug in asciidoc 6, and points to
a patch from 2005. Since we don't even support versions of
asciidoc that old, we can safely get rid of the warning.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we made the switch to supporting asciidoc 8 in 4c7100a
(Documentation: adjust to AsciiDoc 8, 2007-06-14), we were
able to leave most of the documentation intact by defining
asciidoc7compatible.
Since commit 6cf378f (docs: stop using asciidoc no-inline-literal,
2012-04-26), we don't support versions of asciidoc older
than 8.4.1, which is when inline literals were introduced.
Therefore there is not much point in keeping our
documentation compatible with asciidoc 7.
So we are now free to drop the asciidoc7compatible flag and
update the documentation itself to assume asciidoc8.
Fortunately, doing the latter is very easy; we weren't using
any of the constructs impacted by asciidoc7compatible, so
there are no changes to make.
The reason is somewhat subtle. The asciidoc7compatible
affects only super/sub-scripts ("^" and "~") and index
terms. We don't use the latter at all. Nor we do we use the
former, but we did have to protect them from accidental
expansion in constructs like "rev^1". However, all of our
uses of "~" and "^" are either in code blocks (which are
rendered literally), or inside backticks. Prior to 6cf378f,
backticks were not inline literals, and needed proper
quoting. But post-6cf378f, we don't have to worry whether we
are using the old or new rules, as those characters are not
interpreted at all in either case.
I verified that the result of "make install-html
install-man" is identical before and after this patch on
asciidoc 8.6.7.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Fixes quite a lot of brokenness when ident information needs to be taken
from the system and cleans up the code.
By Jeff King
* jk/ident-gecos-strbuf: (22 commits)
format-patch: do not use bogus email addresses in message ids
ident: reject bogus email addresses with IDENT_STRICT
ident: rename IDENT_ERROR_ON_NO_NAME to IDENT_STRICT
format-patch: use GIT_COMMITTER_EMAIL in message ids
ident: let callers omit name with fmt_indent
ident: refactor NO_DATE flag in fmt_ident
ident: reword empty ident error message
format-patch: refactor get_patch_filename
ident: trim whitespace from default name/email
ident: use a dynamic strbuf in fmt_ident
ident: use full dns names to generate email addresses
ident: report passwd errors with a more friendly message
drop length limitations on gecos-derived names and emails
ident: don't write fallback username into git_default_name
fmt_ident: drop IDENT_WARN_ON_NO_NAME code
format-patch: use default email for generating message ids
ident: trim trailing newline from /etc/mailname
move git_default_* variables to ident.c
move identity config parsing to ident.c
fmt-merge-msg: don't use static buffer in record_person
...
"git grep -e '$pattern'", unlike the case where the patterns are read from
a file, did not treat individual lines in the given pattern argument as
separate regular expressions as it should.
From the FILES section of the git-config(1) manual:
$GIT_DIR/config::
Repository specific configuration file. (The filename is
of course relative to the repository root, not the working
directory.)
That's confusing because $GIT_DIR really is relative to the working
directory.
$ GIT_DIR=.git GIT_EDITOR='pwd; echo editing'
$ export GIT_DIR GIT_EDITOR
$ git config --edit --local
/home/jrn/src/git/Documentation
editing .git/config
It turns out that the comment is a remnant from older days when the
heading said ".git/config" (which is indeed relative to the top of the
worktree).
It was only when the heading was changed to refer more precisely to
<git dir>/config (see v1.5.3.2~18, AsciiDoc tweak to avoid leading
dot, 2007-09-14) that the parenthesis stopped making sense. Remove
it.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git status --porcelain" ignored "--branch" option by mistake. The output
for "git status --branch -z" was also incorrect and did not terminate the
record for the current branch name with NUL as asked.
By Jeff King
* jk/maint-status-porcelain-z-b:
status: respect "-b" for porcelain format
status: fix null termination with "-b"
status: refactor null_termination option
commit: refactor option parsing
When getpwuid fails, we give a cute but cryptic message.
While it makes sense if you know that getpwuid or identity
functions are being called, this code is triggered behind
the scenes by quite a few git commands these days (e.g.,
receive-pack on a remote server might use it for a reflog;
the current message is hard to distinguish from an
authentication error). Let's switch to something that gives
a little more context.
While we're at it, we can factor out all of the
cut-and-pastes of the "you don't exist" message into a
wrapper function. Rather than provide xgetpwuid, let's make
it even more specific to just getting the passwd entry for
the current uid. That's the only way we use getpwuid anyway,
and it lets us make an even more specific error message.
The current message also fails to mention errno. While the
usual cause for getpwuid failing is that the user does not
exist, mentioning errno makes it easier to diagnose these
problems. Note that POSIX specifies that errno remain
untouched if the passwd entry does not exist (but will be
set on actual errors), whereas some systems will return
ENOENT or similar for a missing entry. We handle both cases
in our wrapper.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we pull the user's name from the GECOS field of the
passwd file (or generate an email address based on their
username and hostname), we put the result into a
static buffer. While it's extremely unlikely that anybody
ever hit these limits (after all, in such a case their
parents must have hated them), we still had to deal with the
error cases in our code.
Converting these static buffers to strbufs lets us simplify
the code and drop some error messages from the documentation
that have confused some users.
The conversion is mostly mechanical: replace string copies
with strbuf equivalents, and access the strbuf.buf directly.
There are a few exceptions:
- copy_gecos and copy_email are the big winners in code
reduction (since they no longer have to manage the
string length manually)
- git_ident_config wants to replace old versions of
the default name (e.g., if we read the config multiple
times), so it must reset+add to the strbuf instead of
just adding
Note that there is still one length limitation: the
gethostname interface requires us to provide a static
buffer, so we arbitrarily choose 1024 bytes for the
hostname.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently, patterns that contain newline characters don't match anything
when given to git grep. Regular grep(1) interprets patterns as lists of
newline separated search strings instead.
Implement this functionality by creating and inserting extra grep_pat
structures for patterns consisting of multiple lines when appending to
the pattern lists. For simplicity, all pattern strings are duplicated.
The original pattern is truncated in place to make it contain only the
first line.
Requested-by: Torne (Richard Coles) <torne@google.com>
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The description was misleading because it lead the reader to believe
that --git-dir would always show a relative path when, in fact, the
actual behaviour does not guarantee this.
Rather, it was intended that the advice be given that if a relative
path is shown, then the path is relative to the current working
directory and not some other directory (for example, the root of the
working tree).
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
Acked-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The documentation of the dcommit subcommand is reworded to clarify that
the optional argument refers to a git branch, not an SVN branch.
The discussion of the optional argument is put into its own paragraph
as is the guidance about using 'dcommit' in preference to 'set-tree'.
The section on REBASE vs. PULL/MERGE is reworded to incorporate the
advice to prefer 'git rebase' previously in the description of 'dcommit'.
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
When git svn rebase is performed after an unpushed merge, the
rebase operation follows both parents and replays both the user's
local commits and those from the merged branch. This is usually
not the intended behavior.
This patch adds support for the --preserve-merges/-p flag which
allows for a better workflow by re-applying merge commits as merges.
[ew: fixed a minor syntax error]
Signed-off-by: Avishay Lavie <avishay.lavie@gmail.com>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Enables threading in index-pack to resolve base data in parallel.
By Nguyễn Thái Ngọc Duy (3) and Ramsay Jones (1)
* nd/threaded-index-pack:
index-pack: disable threading if NO_PREAD is defined
index-pack: support multithreaded delta resolving
index-pack: restructure pack processing into three main functions
compat/win32/pthread.h: Add an pthread_key_delete() implementation
This way the user does not have to scroll down to the bottom to find
it.
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When sending the "want" list, the capabilities list is separated from
the obj-id by a SP instead of NUL as in the ref advertisement. The
text is correct, but the examples wrongly show the separator as
NUL. Fix the example so it uses SP.
Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The cases "git push" fails due to non-ff can be broken into three
categories; each case is given a separate advise message.
By Christopher Tiwald (2) and Jeff King (1)
* ct/advise-push-default:
Fix httpd tests that broke when non-ff push advice changed
clean up struct ref's nonfastforward field
push: Provide situational hints for non-fast-forward errors
"git repack" used to write out unreachable objects as loose objects
when repacking, even if such loose objects will immediately pruned
due to its age.
By Jeff King
* jk/repack-no-explode-objects-from-old-pack:
gc: use argv-array for sub-commands
argv-array: add a new "pushl" method
argv-array: refactor empty_argv initialization
gc: do not explode objects which will be immediately pruned
This option was not yet described in the gitmodules documentation. We
only described it in the 'git submodule' command documentation but
gitmodules is the more natural place to look.
A short reference in the 'git submodule' documentation should be
sufficient since the details can now be found in the documentation to
gitmodules.
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git status --porcelain" ignored "--branch" option by mistake. The output
for "git status --branch -z" was also incorrect and did not terminate the
record for the current branch name with NUL as asked.
By Jeff King
via Jeff King
* jk/status-porcelain-z-b:
status: refactor colopts handling
status: respect "-b" for porcelain format
status: fix null termination with "-b"
status: refactor null_termination option
commit: refactor option parsing
There is no reason not to, as the user has to explicitly ask
for it, so we are not breaking compatibility by doing so. We
can do this simply by moving the "show_branch" flag into
the wt_status struct. As a bonus, this saves us from passing
it explicitly, simplifying the code.
Signed-off-by: Jeff King <peff@peff.net>
This puts delta resolving on each base on a separate thread, one base
cache per thread. Per-thread data is grouped in struct thread_local.
When running with nr_threads == 1, no pthreads calls are made. The
system essentially runs in non-thread mode.
An experiment on a Xeon 24 core machine with git.git shows that
performance does not increase proportional to the number of cores. So
by default, we use maximum 3 cores. Some numbers with --threads from 1
to 16:
1..4
real 0m8.003s 0m5.307s 0m4.321s 0m3.830s
user 0m7.720s 0m8.009s 0m8.133s 0m8.305s
sys 0m0.224s 0m0.372s 0m0.360s 0m0.360s
5..8
real 0m3.727s 0m3.604s 0m3.332s 0m3.369s
user 0m9.361s 0m9.817s 0m9.525s 0m9.769s
sys 0m0.584s 0m0.624s 0m0.540s 0m0.560s
9..12
real 0m3.036s 0m3.139s 0m3.177s 0m2.961s
user 0m8.977s 0m10.205s 0m9.737s 0m10.073s
sys 0m0.596s 0m0.680s 0m0.684s 0m0.680s
13..16
real 0m2.985s 0m2.894s 0m2.975s 0m2.971s
user 0m9.825s 0m10.573s 0m10.833s 0m11.361s
sys 0m0.788s 0m0.732s 0m0.904s 0m1.016s
On an Intel dual core and linux-2.6.git
1..4
real 2m37.789s 2m7.963s 2m0.920s 1m58.213s
user 2m28.415s 2m52.325s 2m50.176s 2m41.187s
sys 0m7.808s 0m11.181s 0m11.224s 0m10.731s
Thanks Ramsay Jones for troubleshooting and support on MinGW platform.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Describe config file selection in git-config. While the usage message of
git-config shows --local, the documentation page did not contain anything
about that.
Signed-off-by: Florian Achleitner <florian.achleitner.2.6.31@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Rolls the two-directory-diff logic from diffall script (in contrib/) into
"git difftool" framework.
By Tim Henigan
* th/difftool-diffall:
difftool: print list of valid tools with '--tool-help'
difftool: teach difftool to handle directory diffs
difftool: eliminate setup_environment function
difftool: stop appending '.exe' to git
difftool: remove explicit change of PATH
difftool: exit(0) when usage is printed
difftool: add '--no-gui' option
difftool: parse options using Getopt::Long
Attach example sections to previous level of indenting.
Fix a trailing ::
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A couple of commands learn --column option to produce columnar output.
By Nguyễn Thái Ngọc Duy (9) and Zbigniew Jędrzejewski-Szmek (1)
* nd/columns:
tag: add --column
column: support piping stdout to external git-column process
status: add --column
branch: add --column
help: reuse print_columns() for help -a
column: add dense layout support
t9002: work around shells that are unable to set COLUMNS to 1
column: add columnar layout
Stop starting pager recursively
Add column layout skeleton and git-column
Since commit 6cf378f, asciidoc backticks are now inline
literals; therefore quoting {tilde} inside them is wrong
(this instance was missed in 6cf378f because it happened on
a parallel line of development).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Spend only minimum number of columns necessary to show the number of lines
in the output from "diff --stat", instead of always allocating 4 columns
even when showing changes that are much smaller than 1000 lines.
By Zbigniew Jędrzejewski-Szmek
* zj/diff-stat-smaller-num-columns:
diff --stat: use less columns for change counts
Our documentation was written for an ancient version of AsciiDoc,
making the source not very readable.
By Jeff King
* jk/doc-asciidoc-inline-literal:
docs: stop using asciidoc no-inline-literal
New users tend to work on one branch at a time and push the result
out. The current and upstream modes of push is a more suitable default
mode than matching mode for these people, but neither is surprise-free
depending on how the project is set up. Introduce a "simple" mode that
is a subset of "upstream" but only works when the branch is named the same
between the remote and local repositories.
The plan is to make it the new default when push.default is not
configured.
By Matthieu Moy (5) and others
* mm/simple-push:
push.default doc: explain simple after upstream
push: document the future default change for push.default (matching -> simple)
t5570: use explicit push refspec
push: introduce new push.default mode "simple"
t5528-push-default.sh: add helper functions
Undocument deprecated alias 'push.default=tracking'
Documentation: explain push.default option a bit more
Trivially shrinks the on-disk size of the index file to save both I/O and
checksum overhead.
The topic should give a solid base to build on further updates, with the
code refactoring in its earlier parts, and the backward compatibility
mechanism in its later parts.
* jc/index-v4:
index-v4: document the entry format
unpack-trees: preserve the index file version of original
update-index: upgrade/downgrade on-disk index version
read-cache.c: write prefix-compressed names in the index
read-cache.c: read prefix-compressed names in index on-disk version v4
read-cache.c: move code to copy incore to ondisk cache to a helper function
read-cache.c: move code to copy ondisk to incore cache to a helper function
read-cache.c: report the header version we do not understand
read-cache.c: make create_from_disk() report number of bytes it consumed
read-cache.c: allow unaligned mapping of the index file
cache.h: hide on-disk index details
varint: make it available outside the context of pack
When "git fetch" encounters repositories with too many references, the
command line of "fetch-pack" that is run by a helper e.g. remote-curl, may
fail to hold all of them. Now such an internal invocation can feed the
references through the standard input of "fetch-pack".
By Ivan Todoroski
* it/fetch-pack-many-refs:
remote-curl: main test case for the OS command line overflow
fetch-pack: test cases for the new --stdin option
remote-curl: send the refs to fetch-pack on stdin
fetch-pack: new --stdin option to read refs from stdin
Conflicts:
t/t5500-fetch-pack.sh
By Luke Diamand
* ld/git-p4-tags-and-labels:
git p4: fix unit tests
git p4: move verbose to base class
git p4: Ignore P4EDITOR if it is empty
git p4: Squash P4EDITOR in test harness
git p4: fix-up "import/export of labels to/from p4"
git p4: import/export of labels to/from p4
git p4: Fixing script editor checks
"git rebase" learned to optionally keep commits that do not introduce
any change in the original history.
By Neil Horman
* nh/empty-rebase:
git-rebase: add keep_empty flag
git-cherry-pick: Add test to validate new options
git-cherry-pick: Add keep-redundant-commits option
git-cherry-pick: add allow-empty option
Number of columns required for change counts is now computed based on
the maximum number of changed lines instead of being fixed. This means
that usually a few more columns will be available for the filenames
and the graph.
The graph width logic is also modified to include enough space for
"Bin XXX -> YYY bytes".
If changes to binary files are mixed with changes to text files,
change counts are padded to take at least three columns. And the other
way around, if change counts require more than three columns, then
"Bin"s are padded to align with the change count. This way, the +-
part starts in the same column as "XXX -> YYY" part for binary files.
This makes the graph easier to parse visually thanks to the empty
column. This mimics the layout of diff --stat before this change.
Tests and the tutorial are updated to reflect the new --stat output.
This means either the removal of extra padding and/or the addition of
up to three extra characters to truncated filenames. One test is added
to check the graph alignment when a binary file change and text file
change of more than 999 lines are committed together.
Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"gitweb" learned to optionally omit output of fields that are expensive
to generate.
By Kacper Kornet
* kk/gitweb-omit-expensive:
gitweb: Option to not display information about owner
gitweb: Option to omit column with time of the last change
The new "include.path" directive in the configuration files learned
to understand "~/path" and "~user/path".
By Jeff King
* mm/include-userpath:
config: expand tildes in include.path variable
Avoid writing out unreachable objects as loose objects when repacking,
if such loose objects will immediately pruned due to its age anyway.
By Jeff King
* jk/repack-no-explode-objects-from-old-pack:
gc: use argv-array for sub-commands
argv-array: add a new "pushl" method
argv-array: refactor empty_argv initialization
gc: do not explode objects which will be immediately pruned
You can already use relative paths in include.path, which
means that including "foo" from your global "~/.gitconfig"
will look in your home directory. However, you might want to
do something clever like putting "~/.gitconfig-foo" in a
specific repository's config file.
Signed-off-by: Jeff King <peff@peff.net>
Acked-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Normally all cells (and in turn columns) share the same width. This
layout mode can waste space because one long item can stretch our all
columns.
With COL_DENSE enabled, column width is calculated indepdendently. All
columns are shrunk to minimum, then it attempts to push cells of the
last row over to the next column with hope that everything still fits
even there's one row less. The process is repeated until the new layout
cannot fit in given width any more, or there's only one row left
(perfect!).
Apparently, this mode consumes more cpu than the old one, but it makes
better use of terminal space. For layouting one or two screens, cpu
usage should not be detectable.
This patch introduces option handling code besides layout modes and
enable/disable to expose this feature as "dense". The feature can be
turned off by specifying "nodense".
Thanks-to: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
COL_COLUMN and COL_ROW fill column by column (or row by row
respectively), given the terminal width and how many space between
columns. All cells have equal width.
Strings are supposed to be in UTF-8. Valid ANSI escape strings are OK.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A column option string consists of many token separated by either
a space or a comma. A token belongs to one of three groups:
- enabling: always, never and auto
- layout mode: currently plain (which does not layout at all)
- other future tuning flags
git-column can be used to pipe output to from a command that wants
column layout, but not to mess with its own output code. Simpler output
code can be changed to use column layout code directly.
Thanks-to: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In asciidoc 7, backticks like `foo` produced a typographic
effect, but did not otherwise affect the syntax. In asciidoc
8, backticks introduce an "inline literal" inside which markup
is not interpreted. To keep compatibility with existing
documents, asciidoc 8 has a "no-inline-literal" attribute to
keep the old behavior. We enabled this so that the
documentation could be built on either version.
It has been several years now, and asciidoc 7 is no longer
in wide use. We can now decide whether or not we want
inline literals on their own merits, which are:
1. The source is much easier to read when the literal
contains punctuation. You can use `master~1` instead
of `master{tilde}1`.
2. They are less error-prone. Because of point (1), we
tend to make mistakes and forget the extra layer of
quoting.
This patch removes the no-inline-literal attribute from the
Makefile and converts every use of backticks in the
documentation to an inline literal (they must be cleaned up,
or the example above would literally show "{tilde}" in the
output).
Problematic sites were found by grepping for '`.*[{\\]' and
examined and fixed manually. The results were then verified
by comparing the output of "html2text" on the set of
generated html pages. Doing so revealed that in addition to
making the source more readable, this patch fixes several
formatting bugs:
- HTML rendering used the ellipsis character instead of
literal "..." in code examples (like "git log A...B")
- some code examples used the right-arrow character
instead of '->' because they failed to quote
- api-config.txt did not quote tilde, and the resulting
HTML contained a bogus snippet like:
<tt><sub></tt> foo <tt></sub>bar</tt>
which caused some parsers to choke and omit whole
sections of the page.
- git-commit.txt confused ``foo`` (backticks inside a
literal) with ``foo'' (matched double-quotes)
- mentions of `A U Thor <author@example.com>` used to
erroneously auto-generate a mailto footnote for
author@example.com
- the description of --word-diff=plain incorrectly showed
the output as "[-removed-] and {added}", not "{+added+}".
- using "prime" notation like:
commit `C` and its replacement `C'`
confused asciidoc into thinking that everything between
the first backtick and the final apostrophe were meant
to be inside matched quotes
- asciidoc got confused by the escaping of some of our
asterisks. In particular,
`credential.\*` and `credential.<url>.\*`
properly escaped the asterisk in the first case, but
literally passed through the backslash in the second
case.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In some setups the repository owner is not a well defined concept
and administrator can prefer it to be not shown. This commit add
and an option that enable to reach this effect.
Signed-off-by: Kacper Kornet <draenog@pld-linux.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A handful of topics have been merged to maintenance releases, and
the first half of 6th batch graduates to 'master'.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When "git commit --template F" errors out because the user did not
touch the message, it claimed that it aborts due to "empty message",
which was utterly wrong.
By Junio C Hamano (4) and Adam Monsen (1)
* jc/commit-unedited-template:
Documentation/git-commit: rephrase the "initial-ness" of templates
git-commit.txt: clarify -t requires editing message
commit: rephrase the error when user did not touch templated log message
commit: do not trigger bogus "has templated message edited" check
t7501: test the right kind of breakage
Generating information about last change for a large number of git
repositories can be very time consuming. This commit add an option to
omit 'Last Change' column when presenting the list of repositories.
Signed-off-by: Kacper Kornet <draenog@pld-linux.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add a command line switch to git-rebase to allow a user the ability to specify
that they want to keep any commits in a series that are empty.
When git-rebase's type is am, then this option will automatically keep any
commit that has a tree object identical to its parent.
This patch changes the default behavior of interactive rebases as well. With
this patch, git-rebase -i will produce a revision set passed to
git-revision-editor, in which empty commits are commented out. Empty commits
may be kept manually by uncommenting them. If the new --keep-empty option is
used in an interactive rebase the empty commits will automatically all be
uncommented in the editor.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As the "simple" mode is described in terms of what "upstream" does,
swap the order of these two entries so that the reader sees "upstream"
first and then reads "simple" with the knowledge of what "upstream"
does.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It is too early to start warning loudly about the future default change
in favor of 'simple', since many users use different versions of Git, and
would be harmed if we advised them to explicitely set
'push.default=simple' when using old versions of Git.
Still, we want to document the upcomming change so that:
* Users who may be affected by the change get one more chance to know it
in advance.
* We actually commit to changing the default, and avoid repeating past
errors.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When calling "git push" without argument, we want to allow Git to do
something simple to explain and safe. push.default=matching is unsafe
when used to push to shared repositories, and hard to explain to
beginners in some contexts. It is debatable whether 'upstream' or
'current' is the safest or the easiest to explain, so introduce a new
mode called 'simple' that is the intersection of them: push to the
upstream branch, but only if it has the same name remotely. If not, give
an error that suggests the right command to push explicitely to
'upstream' or 'current'.
A question is whether to allow pushing when no upstream is configured. An
argument in favor of allowing the push is that it makes the new mode work
in more cases. On the other hand, refusing to push when no upstream is
configured encourages the user to set the upstream, which will be
beneficial on the next pull. Lacking better argument, we chose to deny
the push, because it will be easier to change in the future if someone
shows us wrong.
Original-patch-by: Jeff King <peff@peff.net>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The git-cherry-pick --allow-empty command by default only preserves empty
commits that were originally empty, i.e only those commits for which
<commit>^{tree} and <commit>^^{tree} are equal. By default commits which are
non-empty, but were made empty by the inclusion of a prior commit on the current
history are filtered out. This option allows us to override that behavior and
include redundant commits as empty commits in the change history.
Note that this patch changes the default behavior of git cherry-pick slightly.
Prior to this patch all commits in a cherry-pick sequence were applied and git
commit was run. The implication here was that, if a commit was redundant, and
the commit did not trigger the fast forward logic, the git commit operation, and
therefore the git cherry-pick operation would fail, displaying the cherry pick
advice (i.e. run git commit --allow-empty). With this patch however, such
redundant commits are automatically skipped without stopping, unless
--keep-redundant-commits is specified, in which case, they are automatically
applied as empty commits.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When "git fetch" encounters repositories with too many references, the
command line of "fetch-pack" that is run by a helper e.g. remote-curl,
may fail to hold all of them. Now such an internal invocation can feed
the references through the standard input of "fetch-pack".
By Ivan Todoroski
* it/fetch-pack-many-refs:
remote-curl: main test case for the OS command line overflow
fetch-pack: test cases for the new --stdin option
remote-curl: send the refs to fetch-pack on stdin
fetch-pack: new --stdin option to read refs from stdin
"git push --recurse-submodules" learns to optionally look into the
histories of submodules bound to the superproject and push them out.
By Heiko Voigt
* hv/submodule-recurse-push:
push: teach --recurse-submodules the on-demand option
Refactor submodule push check to use string list instead of integer
Teach revision walking machinery to walk multiple times sequencially
The verbose flag is common to all classes, or at least should be.
Make it a member of the base Command class, rather than
reimplementing for each class. Make option parsing mirror this.
Signed-off-by: Luke Diamand <luke@diamand.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The previous one is already in 'next' but was somewhat lacking.
The configuration "git-p4.validLabelRegexp" is now called
"labelExportRegexp", and its default covers lowercase alphabets as
well.
Signed-off-by: Luke Diamand <luke@diamand.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It's been deprecated since 53c4031 (Johan Herland, Wed Feb 16 2011,
push.default: Rename 'tracking' to 'upstream'), so it's OK to remove it
from documentation (even though it's still supported) to make the
explanations more readable.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The previous documentation was explaining _what_ the options were doing,
but were of little help explaining _why_ a user should set his default to
either of the options.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make it easier for distros to document custom pager and editor they
used when building their binary releases in "git var" documentation.
By Jonathan Nieder
* jn/debian-customizes-default-editor:
var doc: advertise current DEFAULT_PAGER and DEFAULT_EDITOR settings
var doc: default editor and pager are configurable at build time
Since bc7a96a (mergetool--lib: Refactor tools into separate files,
2011-08-18), it is possible to add a new diff tool by creating a simple
script in the '$(git --exec-path)/mergetools' directory. Updating the
difftool help text is still a manual process, and the documentation can
easily go out of sync.
This commit teaches difftool the '--tool-help' option, which:
- Reads the list of valid tools from 'mergetools/*'
- Determines which of them are actually installed
- Determines which are capable of diffing (i.e. not just a merge tool)
- Prints the resulting list for the user
Signed-off-by: Tim Henigan <tim.henigan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When 'difftool' is called to compare a range of commits that modify
more than one file, it opens a separate instance of the diff tool for
each file that changed.
The new '--dir-diff' option copies all the modified files to a temporary
location and runs a directory diff on them in a single instance of the
diff tool.
Signed-off-by: Tim Henigan <tim.henigan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Break down the cases in which "git push" fails due to non-ff into
three categories, and give separate advise messages for each case.
By Christopher Tiwald (2) and Jeff King (1)
* ct/advise-push-default:
Fix httpd tests that broke when non-ff push advice changed
clean up struct ref's nonfastforward field
push: Provide situational hints for non-fast-forward errors
"git am" learned the "--include" option, which is an opposite of existing
the "--exclude" option.
By Johannes Berg
* jb/am-include:
am: support --include option
It can be convenient to push many strings in a single line
(e.g., if you are initializing an array with defaults). This
patch provides a convenience wrapper to allow this.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When "git commit --template F" errors out because the user did not touch
the message, it claimed that it aborts due to "empty message", which was
utterly wrong.
By Junio C Hamano (4) and Adam Monsen (1)
* jc/commit-unedited-template:
Documentation/git-commit: rephrase the "initial-ness" of templates
git-commit.txt: clarify -t requires editing message
commit: rephrase the error when user did not touch templated log message
commit: do not trigger bogus "has templated message edited" check
t7501: test the right kind of breakage
Even with "-q"uiet option, "checkout" used to report setting up tracking.
Also "branch" learns "-q"uiet option to squelch informational message.
By Jeff King
* jk/branch-quiet:
teach "git branch" a --quiet option
checkout: suppress tracking message with "-q"
If fast-import's command pipe and the frontend's cat-blob/ls response
pipe are both filled, there can be a deadlock. Luckily all existing
frontends consume any pending cat-blob/ls responses completely before
writing the next command.
Document the requirements so future frontend authors and users can be
spared from the problem, too. It is not always easy to catch that
kind of bug by testing.
To set the scene, add some words of explanation to help the novice
understand that "cat-blob" and "ls" output are meant for consumption
by the frontend.
Reported-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git cherry-pick fails when picking a non-ff commit that is empty. The advice
given with the failure is that a git-commit --allow-empty should be issued to
explicitly add the empty commit during the cherry pick. This option allows a
user to specify before hand that they want to keep the empty commit. This
eliminates the need to issue both a cherry pick and a commit operation.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
I tentatively named the release notes "1.7.11" but this may have to
be renamed to "1.8" or some other name later. Let's see how well
we would do during this cycle.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The existing label import code looks at each commit being
imported, and then checks for labels at that commit. This
doesn't work in the real world though because it will drop
labels applied on changelists that have already been imported,
a common pattern.
This change adds a new --import-labels option. With this option,
at the end of the sync, git p4 gets sets of labels in p4 and git,
and then creates a git tag for each missing p4 label.
This means that tags created on older changelists are
still imported.
Tags that could not be imported are added to an ignore
list.
The same sets of git and p4 tags and labels can also be used to
derive a list of git tags to export to p4. This is enabled with
--export-labels in 'git p4 submit'.
Signed-off-by: Luke Diamand <luke@diamand.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Document the default pager and editor chosen at compile time in the
git-var(1) manpage so users curious about what command _this_ copy of
git will fall back to when EDITOR, VISUAL, and PAGER are unset can
find the answer quickly.
In builds leaving those settings uncustomized, this patch makes the
manpage continue to say "usually vi" and "usually less" so the
formatted documentation is usable for a wide audience including users
of custom builds that change those settings. If you would like your
copy of the docs to be less noncommittal, you will need to set
DEFAULT_PAGER=less and DEFAULT_EDITOR=vi explicitly.
Suggested-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Move git-p4 out of contrib/fast-import into the main code base,
aside other foreign SCM tools.
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* tr/maint-bundle-long-subject:
t5704: match tests to modern style
strbuf: improve strbuf_get*line documentation
bundle: use a strbuf to scan the log for boundary commits
bundle: put strbuf_readline_fd in strbuf.c with adjustments
With the "--index-version <n>" parameter, write the index out in the
specified version. With this, an index file that is written in newer
format (say v4) can be downgraded to be read by older versions of Git.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The description of "commit -t <file>" said the file is used "as the
initial version" of the commit message, but in the context of an SCM,
"version" is a loaded word that can needlesslyl confuse readers.
Explain the purpose of the mechanism without using "version".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If a remote repo has too many tags (or branches), cloning it over the
smart HTTP transport can fail because remote-curl.c puts all the refs
from the remote repo on the fetch-pack command line. This can make the
command line longer than the global OS command line limit, causing
fetch-pack to fail.
This is especially a problem on Windows where the command line limit is
orders of magnitude shorter than Linux. There are already real repos out
there that msysGit cannot clone over smart HTTP due to this problem.
Here is an easy way to trigger this problem:
git init too-many-refs
cd too-many-refs
echo bla > bla.txt
git add .
git commit -m test
sha=$(git rev-parse HEAD)
tag=$(perl -e 'print "bla" x 30')
for i in `seq 50000`; do
echo $sha refs/tags/$tag-$i >> .git/packed-refs
done
Then share this repo over the smart HTTP protocol and try cloning it:
$ git clone http://localhost/.../too-many-refs/.git
Cloning into 'too-many-refs'...
fatal: cannot exec 'fetch-pack': Argument list too long
50k tags is obviously an absurd number, but it is required to
demonstrate the problem on Linux because it has a much more generous
command line limit. On Windows the clone fails with as little as 500
tags in the above loop, which is getting uncomfortably close to the
number of tags you might see in real long lived repos.
This is not just theoretical, msysGit is already failing to clone our
company repo due to this. It's a large repo converted from CVS, nearly
10 years of history.
Four possible solutions were discussed on the Git mailing list (in no
particular order):
1) Call fetch-pack multiple times with smaller batches of refs.
This was dismissed as inefficient and inelegant.
2) Add option --refs-fd=$n to pass a an fd from where to read the refs.
This was rejected because inheriting descriptors other than
stdin/stdout/stderr through exec() is apparently problematic on Windows,
plus it would require changes to the run-command API to open extra
pipes.
3) Add option --refs-from=$tmpfile to pass the refs using a temp file.
This was not favored because of the temp file requirement.
4) Add option --stdin to pass the refs on stdin, one per line.
In the end this option was chosen as the most efficient and most
desirable from scripting perspective.
There was however a small complication when using stdin to pass refs to
fetch-pack. The --stateless-rpc option to fetch-pack also uses stdin for
communication with the remote server.
If we are going to sneak refs on stdin line by line, it would have to be
done very carefully in the presence of --stateless-rpc, because when
reading refs line by line we might read ahead too much data into our
buffer and eat some of the remote protocol data which is also coming on
stdin.
One way to solve this would be to refactor get_remote_heads() in
fetch-pack.c to accept a residual buffer from our stdin line parsing
above, but this function is used in several places so other callers
would be burdened by this residual buffer interface even when most of
them don't need it.
In the end we settled on the following solution:
If --stdin is specified without --stateless-rpc, fetch-pack would read
the refs from stdin one per line, in a script friendly format.
However if --stdin is specified together with --stateless-rpc,
fetch-pack would read the refs from stdin in packetized format
(pkt-line) with a flush packet terminating the list of refs. This way we
can read the exact number of bytes that we need from stdin, and then
get_remote_heads() can continue reading from the same fd without losing
a single byte of remote protocol data.
This way the --stdin option only loses generality and scriptability when
used together with --stateless-rpc, which is not easily scriptable
anyway because it also uses pkt-line when talking to the remote server.
Signed-off-by: Ivan Todoroski <grnch@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make it clear that, when using commit --template, the message *must* be
changed or the commit will be aborted.
Helped-by: Junio C Hamano <gitster@pobox.com>
Helped-by: Ivan Heffner <iheffner@gmail.com>
Signed-off-by: Adam Monsen <haircut@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some distributors customize the fallback pager and editor used by git
commands when the user has not indicated a preference via the
core.editor/core.pager configuration or GIT_EDITOR, GIT_PAGER, VISUAL,
EDITOR, and PAGER environment variables, and git's build system
provides DEFAULT_PAGER and DEFAULT_EDITOR makefile settings to help
them with that (see v1.6.6-rc0~24, 2009-11-20).
Unfortunately those compile-time settings do not affect the
documentation, so the uninitiated user who tries to understand git by
reading the git-var(1) manpage can easily be confused when git falls
back to 'nano' and 'more' instead of 'vi' and 'less'. Even if the
distributor patches the distributed docs to reflect the new default,
the user may read the official documentation from the git-htmldocs
repository online and be confused in the same way.
Add a few words stating that the defaults are customizable at
compile time to make the behavior crystal clear.
Reported-by: Rodrigo Silva (MestreLion) <linux@rodrigosilva.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When using this option git will search for all submodules that
have changed in the revisions to be send. It will then try to
push the currently checked out branch of each submodule.
This helps when a user has finished working on a change which
involves submodules and just wants to push everything in one go.
Signed-off-by: Fredrik Gustafsson <iveqy@iveqy.com>
Mentored-by: Jens Lehmann <Jens.Lehmann@web.de>
Mentored-by: Heiko Voigt <hvoigt@hvoigt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously it was not possible to iterate revisions twice using the
revision walking api. We add a reset_revision_walk() which clears the
used flags. This allows us to do multiple sequencial revision walks.
We add the appropriate calls to the existing submodule machinery doing
revision walks. This is done to avoid surprises if future code wants to
call these functions more than once during the processes lifetime.
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Found by running this command:
$ git ls-files -z|xargs -0 perl -0777 -n \
-e 'while (/\b(then?|[iao]n|i[fst]|but|f?or|at|and|[dt]o)\s+\1\b/gims)' \
-e ' {' \
-e ' $n = ($` =~ tr/\n/\n/ + 1);' \
-e ' ($v = $&) =~ s/\n/\\n/g;' \
-e ' print "$ARGV:$n:$v\n";' \
-e ' }'
Why not just git grep -E ...?
That wouldn't work then the doubled words are separated by a newline.
This is derived from a Makefile syntax-check rule in gnulib's maint.mk:
http://git.sv.gnu.org/cgit/gnulib.git/tree/top/maint.mk
Signed-off-by: Jim Meyering <meyering@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
am supports a number of pass-through options
to apply, like --exclude and --directory. Add
--include to this list.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There's currently no way to suppress the informational
"deleted branch..." or "set up tracking..." messages. This
patch provides a "-q" option to do so.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
All of the other options were included in the synopsis, so it makes
sense to include these as well.
Signed-off-by: Mark Lodato <lodatom@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously GIT_EDITOR was not listed in git(1) "Environment Variables" section,
which could be very confusing to users. Include it in "other" subsection along
with a link to git-var(1), since that is the page that fully describes all
places where editor can be set and also their preference order.
Also, git-var(1) did not say that hardcoded fallback 'vi' may have been changed
at build time. A user could be puzzled if 'nano' pops up even when none of the
mentioned environment vars or config.editor are set. Clarify this.
Ideally, the build system should be changed to reflect the chosen fallback
editor when creating the man pages. Not sure if that is even possible though.
Signed-off-by: Rodrigo Silva (MestreLion) <linux@rodrigosilva.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
An alphabetic ordered list (a.) is converted to numerical in
the man page (1.) so context comments naming 'a' were confusing,
fix that by not using ordered list notation for 'a' anb 'b' items.
Signed-off-by: Nelson Benitez Leon <nelsonjesus.benitez@seap.minhap.es>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Change "it's" to "its" where a possessive is intended. Also add two
missing "the" that were noticed by Ben Walton.
Signed-off-by: David Waitzman <djw@bbn.com>
Even though 1.7.9.x series does not open the editor by default
when merging in general, it does do so in one occassion: when
merging an annotated tag. And worse yet, there is no good way
for older scripts to decline this.
Backport the support for GIT_MERGE_AUTOEDIT environment variable
from 1.7.10 track to help those stuck on 1.7.9.x maintenance
track.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Pushing a non-fast-forward update to a remote repository will result in
an error, but the hint text doesn't provide the correct resolution in
every case. Give better resolution advice in three push scenarios:
1) If you push your current branch and it triggers a non-fast-forward
error, you should merge remote changes with 'git pull' before pushing
again.
2) If you push to a shared repository others push to, and your local
tracking branches are not kept up to date, the 'matching refs' default
will generate non-fast-forward errors on outdated branches. If this is
your workflow, the 'matching refs' default is not for you. Consider
setting the 'push.default' configuration variable to 'current' or
'upstream' to ensure only your current branch is pushed.
3) If you explicitly specify a ref that is not your current branch or
push matching branches with ':', you will generate a non-fast-forward
error if any pushed branch tip is out of date. You should checkout the
offending branch and merge remote changes before pushing again.
Teach transport.c to recognize these scenarios and configure push.c
to hint for them. If 'git push's default behavior changes or we
discover more scenarios, extension is easy. Standardize on the
advice API and add three new advice variables, 'pushNonFFCurrent',
'pushNonFFDefault', and 'pushNonFFMatching'. Setting any of these
to 'false' will disable their affiliated advice. Setting
'pushNonFastForward' to false will disable all three, thus preserving the
config option for users who already set it, but guaranteeing new
users won't disable push advice accidentally.
Based-on-patch-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Christopher Tiwald <christiwald@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
deltawalker has been supported since 284a126c3e, but was not added
to the list of valid diff tools reported by 'git difftool --help'.
Signed-off-by: Tim Henigan <tim.henigan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The previous description was confusing. This rewrite makes it easier
to understand.
Signed-off-by: Tim Henigan <tim.henigan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We have had these options as harmless no-op for more than 3 years without
officially deprecating them. Let's announce the deprecation and start
warning against their use, but without failing the command just not yet,
so that we can later repurpose the option if we want to in the future.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This adds the 'remaining' command to the documentation of
'git rerere'. This command was added in ac49f5ca (Feb 16 2011;
Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>) but
it was never documented.
Touch up the other rerere commands to reduce noise.
First noticed by Vincent van Ravesteijn.
Signed-off-by: Phil Hord <phil.hord@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
By Vincent van Ravesteijn
* vr/branch-doc:
Documentation/git-branch: add default for --contains
Documentation/git-branch: fix a typo
Documentation/git-branch: cleanups
By Zbigniew Jędrzejewski-Szmek (8) and Junio C Hamano (1)
* zj/diff-stat-dyncol:
: This breaks tests. Perhaps it is not worth using the decimal-width stuff
: for this series, at least initially.
diff --stat: add config option to limit graph width
diff --stat: enable limiting of the graph part
diff --stat: add a test for output with COLUMNS=40
diff --stat: use a maximum of 5/8 for the filename part
merge --stat: use the full terminal width
log --stat: use the full terminal width
show --stat: use the full terminal width
diff --stat: use the full terminal width
diff --stat: tests for long filenames and big change counts
Indicate that the commit parameter of --contains defaults to HEAD.
Signed-off-by: Vincent van Ravesteijn <vfr@lyx.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Most of the exact option strings to be typed by end users are
already set in typewriter font by using `--option`, but a few places
used '--option' to call for italics or with no quoting. Uniformly
use `--option`.
Also add a full-stop after a sentence that missed one.
Signed-off-by: Vincent van Ravesteijn <vfr@lyx.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Reword the misspelled "squelch" noticed by Hermann Gaustere to say
"omit", which would sit better anyway.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
Update draft release notes to 1.7.9.3 for the last time
http.proxy: also mention https_proxy and all_proxy
t0300: work around bug in dash 0.5.6
t5512 (ls-remote): modernize style
tests: fix spurious error when run directly with Solaris /usr/xpg4/bin/sh
* tr/maint-bundle-long-subject:
t5704: match tests to modern style
strbuf: improve strbuf_get*line documentation
bundle: use a strbuf to scan the log for boundary commits
bundle: put strbuf_readline_fd in strbuf.c with adjustments
The current wording of the http.proxy documentation suggests that
http_proxy is somehow equivalent to http.proxy. However, while
http.proxy (by the means of curl's CURLOPT_PROXY option) overrides the
proxy for both HTTP and HTTPS protocols, the http_proxy environment
variable is used only for HTTP. But since the docs mention only
http_proxy, a user might expect it to apply to all HTTP-like protocols.
Avoid any such misunderstanding by explicitly mentioning https_proxy and
all_proxy as well.
Also replace linkgit:curl[1] with a literal 'curl(1)', because the
former gets translated to a dead link in the HTML pages.
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We explained <rev>~<n> as <n>th generation grand-parent, but a reader got
confused by the "grand-" part when <n> is 1.
Reword it with "ancestor"; with the "generation" and "following only the
first parents" around there, what we try to describe should be clear
enough now.
Noticed-by: Luke Diamand <luke@diamand.org>
Helped-by: Thomas Rast <trast@inf.ethz.ch>
Helped-by: Andreas Ericsson <ae@op5.se>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Config option diff.statGraphWidth=<width> is equivalent to
--stat-graph-width=<width>, except that the config option is ignored
by format-patch.
For the graph-width limiting to be usable, it should happen
'automatically' once configured, hence the config option.
Nevertheless, graph width limiting only makes sense when used on a
wide terminal, so it should not influence the output of format-patch,
which adheres to the 80-column standard.
Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A new option --stat-graph-width=<width> can be used to limit the width
of the graph part even is more space is available. Up to <width>
columns will be used for the graph.
If commits changing a lot of lines are displayed in a wide terminal
window (200 or more columns), and the +- graph uses the full width,
the output can be hard to comfortably scan with a horizontal movement
of human eyes. Messages wrapped to about 80 columns would be
interspersed with very long +- lines. It makes sense to limit the
width of the graph part to a fixed value (e.g. 70 columns), even if
more columns are available.
Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The way that available columns are divided between the filename part
and the graph part is modified to use as many columns as necessary for
the filenames and the rest for the graph.
If there isn't enough columns to print both the filename and the
graph, at least 5/8 of available space is devoted to filenames. On a
standard 80 column terminal, or if not connected to a terminal and
using the default of 80 columns, this gives the same partition as
before.
The effect of this change is visible in the patch to the test vector
in t4052; with a small change with long filename, it stops truncating
the name part too short, and also allocates a bit more columns to the
graph for larger changes.
Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Variable names must start with an alphabetic character, regexp config key
matching has its limits, sentence grammar.
Signed-off-by: Libor Pechacek <lpechacek@suse.cz>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The default output from "fsck" is often overwhelmed by informational
message on dangling objects, especially if you do not repack often, and a
real error can easily be buried.
Add "--no-dangling" option to omit them, and update the user manual to
demonstrate its use.
Based on a patch by Clemens Buchacher, but reverted the part to change
the default to --no-dangling, which is unsuitable for the first patch.
The usual three-step procedure to break the backward compatibility over
time needs to happen on top of this, if we were to go in that direction.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Text between two '*' is emphasized in AsciiDoc and makes explanations in
rev-list-options.txt on glob-related options very confusing, as the
rendered text would be missing two asterisks and the text between them
would be emphasized instead.
Use '{asterisk}' where needed to make them show up as asterisks in the
rendered text.
Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It can be helpful to resolve a symbolic ref and output the result in a
shortened form, such as for use in shell prompts. Add a "--short" option
to do so.
Signed-off-by: Jan Krüger <jk@jk.gs>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
Update draft release notes to 1.7.9.3
CodingGuidelines: do not use 'which' in shell scripts
CodingGuidelines: Add a note about spaces after redirection
post-receive-email: match up $LOGBEGIN..$LOGEND pairs correctly
post-receive-email: remove unused variable
During the code review of a recent patch, it was noted that shell scripts
must not use 'which $cmd' to check the availability of the command $cmd.
The output of the command is not machine parseable and its exit code is
not reliable across platforms.
It is better to use 'type' to accomplish this task.
Signed-off-by: Tim Henigan <tim.henigan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
During code review of some patches, it was noted that redirection operators
should have space before, but no space after them.
Signed-off-by: Tim Henigan <tim.henigan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The option was already shown in -h output, so it should be documented
in the man page.
Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Suggested-by: David A. Greene <greened@obbligato.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* tr/maint-bundle-long-subject:
t5704: match tests to modern style
strbuf: improve strbuf_get*line documentation
bundle: use a strbuf to scan the log for boundary commits
bundle: put strbuf_readline_fd in strbuf.c with adjustments
* fc/push-prune:
push: add '--prune' option
remote: refactor code into alloc_delete_ref()
remote: reorganize check_pattern_match()
remote: use a local variable in match_push_refs()
Conflicts:
builtin/push.c
* maint:
Document accumulated fixes since 1.7.9.2
Git 1.7.8.5
grep -P: Fix matching ^ and $
am: don't infloop for an empty input file
rebase -m: only call "notes copy" when rewritten exists and is non-empty
git-p4: remove bash-ism in t9800
git-p4: remove bash-ism in t9809
git-p4: fix submit regression with clientSpec and subdir clone
git-p4: set useClientSpec variable on initial clone
Makefile: add thread-utils.h to LIB_H
Conflicts:
RelNotes
t/t9809-git-p4-client-view.sh
If --use-client-spec was given, set the matching configuration
variable. This is necessary to ensure that future submits
work properly.
The alternatives of requiring the user to set it, or providing
a command-line option on every submit, are error prone.
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Long options can be negated by adding no- right after the leading
two dashes. This is useful e.g. to override options set by aliases.
For options that are defined to start with no- already, this looks
a bit funny. Allow such options to also be negated by removing the
prefix.
The following thirteen options are affected:
apply --no-add
bisect--helper --no-checkout
checkout-index --no-create
clone --no-checkout --no-hardlinks
commit --no-verify --no-post-rewrite
format-patch --no-binary
hash-object --no-filters
read-tree --no-sparse-checkout
revert --no-commit
show-branch --no-name
update-ref --no-deref
The following five are NOT affected because they are defined with
PARSE_OPT_NONEG or the non-negated version is defined as well:
branch --no-merged
format-patch --no-stat --no-numbered
update-index --no-assume-unchanged --no-skip-worktree
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Clarify strbuf_getline() documentation, and add the missing documentation
for strbuf_getwholeline() and strbuf_getwholeline_fd().
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* ld/git-p4-expanded-keywords:
: Teach git-p4 to unexpand $RCS$-like keywords that are embedded in
: tracked contents in order to reduce unnecessary merge conflicts.
git-p4: add initial support for RCS keywords
* jk/config-include:
: An assignment to the include.path pseudo-variable causes the named file
: to be included in-place when Git looks up configuration variables.
config: add include directive
config: eliminate config_exclusive_filename
config: stop using config_exclusive_filename
config: provide a version of git_config with more options
config: teach git_config_rename_section a file argument
config: teach git_config_set_multivar_in_file a default path
config: copy the return value of prefix_filename
t1300: add missing &&-chaining
docs/api-config: minor clarifications
docs: add a basic description of the config API
RCS keywords cause problems for git-p4 as perforce always
expands them (if +k is set) and so when applying the patch,
git reports that the files have been modified by both sides,
when in fact they haven't.
This change means that when git-p4 detects a problem applying
a patch, it will check to see if keyword expansion could be
the culprit. If it is, it strips the keywords in the p4
repository so that they match what git is expecting. It then
has another go at applying the patch.
This behaviour is enabled with a new git-p4 configuration
option and is off by default.
Acked-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Luke Diamand <luke@diamand.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This was part of the "branch description" feature in the larger
"help people communicate better during their pull based workflow"
topic, but was never documented.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When pushing groups of refs to a remote, there is no simple way to remove
old refs that still exist at the remote that is no longer updated from us.
This will allow us to remove such refs from the remote.
With this change, running this command
$ git push --prune remote refs/heads/*:refs/remotes/laptop/*
removes refs/remotes/laptop/foo from the remote if we do not have branch
"foo" locally anymore.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The --ff-only option was not described next to --ff and --no-ff options in
"git merge" documentation, even though these three are logically together,
describing how to choose one of three possibilities.
Also the description for '--ff' and '--no-ff' discussed what '--ff' means,
and mentioned '--no-ff' as if it were a side-note to '--ff'.
Make them into three top-level entries and list them together. This way,
it would be more clear that the user can choose one from these three.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The canonical order of command line arguments is always to have dashed
commands before other parameters, but the "git remote set-branches"
subcommand was described to take "name" before an optional "--add".
Signed-off-by: Philip Jägenstedt <philip@foolip.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It can be useful to split your ~/.gitconfig across multiple
files. For example, you might have a "main" file which is
used on many machines, but a small set of per-machine
tweaks. Or you may want to make some of your config public
(e.g., clever aliases) while keeping other data back (e.g.,
your name or other identifying information). Or you may want
to include a number of config options in some subset of your
repos without copying and pasting (e.g., you want to
reference them from the .git/config of participating repos).
This patch introduces an include directive for config files.
It looks like:
[include]
path = /path/to/file
This is syntactically backwards-compatible with existing git
config parsers (i.e., they will see it as another config
entry and ignore it unless you are looking up include.path).
The implementation provides a "git_config_include" callback
which wraps regular config callbacks. Callers can pass it to
git_config_from_file, and it will transparently follow any
include directives, passing all of the discovered options to
the real callback.
Include directives are turned on automatically for "regular"
git config parsing. This includes calls to git_config, as
well as calls to the "git config" program that do not
specify a single file (e.g., using "-f", "--global", etc).
They are not turned on in other cases, including:
1. Parsing of other config-like files, like .gitmodules.
There isn't a real need, and I'd rather be conservative
and avoid unnecessary incompatibility or confusion.
2. Reading single files via "git config". This is for two
reasons:
a. backwards compatibility with scripts looking at
config-like files.
b. inspection of a specific file probably means you
care about just what's in that file, not a general
lookup for "do we have this value anywhere at
all". If that is not the case, the caller can
always specify "--includes".
3. Writing files via "git config"; we want to treat
include.* variables as literal items to be copied (or
modified), and not expand them. So "git config
--unset-all foo.bar" would operate _only_ on
.git/config, not any of its included files (just as it
also does not operate on ~/.gitconfig).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Callers may want to provide a specific version of a file in which to look
for config. Right now this can be done by setting the magic global
config_exclusive_filename variable. By providing a version of git_config
that takes a filename, we can take a step towards making this magic global
go away.
Furthermore, by providing a more "advanced" interface, we now have a a
natural place to add new options for callers like git-config, which care
about tweaking the specifics of config lookup, without disturbing the
large number of "simple" users (i.e., every other part of git).
The astute reader of this patch may notice that the logic for handling
config_exclusive_filename was taken out of git_config_early, but added
into git_config. This means that git_config_early will no longer respect
config_exclusive_filename. That's OK, because the only other caller of
git_config_early is check_repository_format_gently, but the only function
which sets config_exclusive_filename is cmd_config, which does not call
check_repository_format_gently (and if it did, it would have been a bug,
anyway, as we would be checking the repository format in the wrong file).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The first change simply drops some parentheses to make a
statement more clear. The seconds clarifies that almost
nobody wants to call git_config_early.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
By default, a missing filter driver or a failure from the filter driver is
not an error, but merely makes the filter operation a no-op pass through.
This is useful to massage the content into a shape that is more convenient
for the platform, filesystem, and the user to use, and the content filter
mechanism is not used to turn something unusable into usable.
However, we could also use of the content filtering mechanism and store
the content that cannot be directly used in the repository (e.g. a UUID
that refers to the true content stored outside git, or an encrypted
content) and turn it into a usable form upon checkout (e.g. download the
external content, or decrypt the encrypted content). For such a use case,
the content cannot be used when filter driver fails, and we need a way to
tell Git to abort the whole operation for such a failing or missing filter
driver.
Add a new "filter.<driver>.required" configuration variable to mark the
second use case. When it is set, git will abort the operation when the
filter driver does not exist or exits with a non-zero status code.
Signed-off-by: Jehan Bing <jehan@orb.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The line was extended in 2dd8c3 ('git: add --info-path and --man-path
options'), and the formatted man output stopped fitting into the 80
column window.
Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Again this round mostly consists of fixes for 1.7.9 in preparation for
merging these topics down to maint for 1.7.9.1
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Document bunch of bugfix topics to be merged down to 'maint' soonish
for 1.7.9.1 maintenance release.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This filters the list for tags of the given object.
Example,
john$ git tag v1.0-john v1.0
john$ git tag -l --points-at v1.0
v1.0-john
v1.0
Signed-off-by: Tom Grennan <tmgrennan@gmail.com>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This wasn't documented at all; this is pretty bare-bones,
but it should at least give new git hackers a basic idea of
how the reading side works.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git diff --stat" and "git apply --stat" now learn to print the line
"%d files changed, %d insertions(+), %d deletions(-)" in singular form
whenever applicable. "0 insertions" and "0 deletions" are also omitted
unless they are both zero.
This matches how versions of "diffstat" that are not prehistoric produced
their output, and also makes this line translatable.
[jc: with help from Thomas Dickey in archaeology of "diffstat"]
[jc: squashed Jonathan's updates to illustrations in tutorials and a test]
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* nd/clone-detached:
clone: fix up delay cloning conditions
push: do not let configured foreign-vcs permanently clobbered
clone: print advice on checking out detached HEAD
clone: allow --branch to take a tag
clone: refuse to clone if --branch points to bogus ref
clone: --branch=<branch> always means refs/heads/<branch>
clone: delay cloning until after remote HEAD checking
clone: factor out remote ref writing
clone: factor out HEAD update code
clone: factor out checkout code
clone: write detached HEAD in bare repositories
t5601: add missing && cascade
When asking for a tag to be pulled, disambiguate by leaving tags/ prefix
in front of the name of the tag. E.g.
... in the git repository at:
git://example.com/git/git.git/ tags/v1.2.3
for you to fetch changes up to 123456...
This way, older versions of "git pull" can be used to respond to such a
request more easily, as "git pull $URL v1.2.3" did not DWIM to fetch
v1.2.3 tag in older versions. Also this makes it clearer for humans that
the pull request is made for a tag and he should anticipate a signed one.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* pw/p4-view-updates:
git-p4: add tests demonstrating spec overlay ambiguities
git-p4: adjust test to adhere to stricter useClientSpec
git-p4: clarify comment
git-p4: fix verbose comment typo
git-p4: only a single ... wildcard is supported
Traditionally, a cleanly resolved merge was committed by "git merge" using
the auto-generated merge commit log message without invoking the editor.
After 5 years of use in the field, it turns out that people perform too
many unjustified merges of the upstream history into their topic branches.
These merges are not just useless, but they are often not explained well,
and making the end result unreadable when it gets time for merging their
history back to their upstream.
Earlier we added the "--edit" option to the command, so that people can
edit the log message to explain and justify their merge commits. Let's
take it one step further and spawn the editor by default when we are in an
interactive session (i.e. the standard input and the standard output are
pointing at the same tty device).
There may be existing scripts that leave the standard input and the
standard output of the "git merge" connected to whatever environment the
scripts were started, and such invocation might trigger the above
"interactive session" heuristics. GIT_MERGE_AUTOEDIT environment variable
can be set to "no" at the beginning of such scripts to use the historical
behaviour while the script runs.
Note that this backward compatibility is meant only for scripts, and we
deliberately do *not* support "merge.edit = yes/no/auto" configuration
option to allow people to keep the historical behaviour.
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Because a tag ref cannot be put to HEAD, HEAD will become detached.
This is consistent with "git checkout <tag>".
This is mostly useful in shallow clone, where it allows you to clone a
tag in addtion to branches.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-am could pass -k to mailinfo, but not -b. Introduce an option
that does so. We change the meaning of the 'keep' state file, but are
careful not to cause a problem unless you downgrade in the middle of
an 'am' run.
This uncovers a bug in mailinfo -b, hence the failing test.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It's actually unlimited recursion if wildcards are active regardless
--max-depth
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Two "^" characters were incorrectly being interpreted as markup for
superscripting. Fix them by writing them as attribute references
"{caret}".
Although a single "^" character in a paragraph cannot be
misinterpreted in this way, also write other "^" characters as
"{caret}" in the interest of good hygiene (unless they are in literal
paragraphs, of course, in which context attribute references are not
recognized).
Spell "{}" consistently, namely *not* quoted as "\{\}". Since the
braces are empty, they cannot be interpreted as an attribute
reference, and either spelling is OK. So arbitrarily choose one
variation and use it consistently.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
Update draft release notes to 1.7.8.4
Update draft release notes to 1.7.7.6
Update draft release notes to 1.7.6.6
thin-pack: try harder to use preferred base objects as base
Since its very first description of -k, the documentation for
git-mailinfo claimed that (in the case without -k) after cleaning up
bracketed strings [blah], it would insert [PATCH].
It doesn't; on the contrary, one of the important jobs of mailinfo is
to remove those strings.
Since we're already there, rewrite the paragraph to give a complete
enumeration of all the transformations. Specifically, it was missing
the whitespace normalization (run of isspace(c) -> ' ') and the
removal of leading ':'.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Introduce new tests that look more closely at overlay situations
when there are conflicting files. Five of these are broken.
Document the brokenness.
This is a fundamental problem with how git-p4 only "borrows" a
client spec. At some sync operation, a new change can contain
a file which is already in the repo or explicitly deleted through
another mapping. To sort this out would involve listing all the
files in the client spec to find one with a higher priority.
While this is not too hard for the initial import, subsequent
sync operations would be very costly.
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The description of rerere.enabled left the user in the dark as to who
might create an rr-cache directory. Add a note that simply invoking
rerere does this.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When --single-branch is given, only one branch, either HEAD or one
specified by --branch, will be fetched. Also only tags that point to
the downloaded history are fetched.
This helps most in shallow clones, where it can reduce the download to
minimum and that is why it is enabled by default when --depth is given.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jc/show-sig:
log --show-signature: reword the common two-head merge case
log-tree: show mergetag in log --show-signature output
log-tree.c: small refactor in show_signature()
commit --amend -S: strip existing gpgsig headers
verify_signed_buffer: fix stale comment
gpg-interface: allow use of a custom GPG binary
pretty: %G[?GS] placeholders
test "commit -S" and "log --show-signature"
log: --show-signature
commit: teach --gpg-sign option
Conflicts:
builtin/commit-tree.c
builtin/commit.c
builtin/merge.c
notes-cache.c
pretty.c
The wording seems to suggest that creating the directory is needed and the
setting of rerere.enabled is only for disabling the feature by setting it
to 'false'. But the configuration is meant to be the primary control and
setting it to 'true' will enable it; the rr-cache directory will be
created as necessary and the user does not have to create it.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The FETCH_HEAD refname is supposed to refer to the ref that was fetched
and should be merged. However all fetched refs are written to
.git/FETCH_HEAD in an arbitrary order, and resolve_ref_unsafe simply
takes the first ref as the FETCH_HEAD, which is often the wrong one,
when other branches were also fetched.
The solution is to write the for-merge ref(s) to FETCH_HEAD first.
Then, unless --append is used, the FETCH_HEAD refname behaves as intended.
If the user uses --append, they presumably are doing so in order to
preserve the old FETCH_HEAD.
While we are at it, update an old example in the read-tree documentation
that implied that each entry in FETCH_HEAD only has the object name, which
is not true for quite a while.
[jc: adjusted tests]
Signed-off-by: Joey Hess <joey@kitenet.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* pw/p4-docs-and-tests:
git-p4: document and test submit options
git-p4: test and document --use-client-spec
git-p4: test --keep-path
git-p4: test --max-changes
git-p4: document and test --import-local
git-p4: honor --changesfile option and test
git-p4: document and test clone --branch
git-p4: test cloning with two dirs, clarify doc
git-p4: clone does not use --git-dir
git-p4: introduce asciidoc documentation
rename git-p4 tests
* maint:
docs: describe behavior of relative submodule URLs
fix hang in git fetch if pointed at a 0 length bundle
Documentation: read-tree --prefix works with existing subtrees
Add MYMETA.json to perl/.gitignore
* maint-1.7.7:
docs: describe behavior of relative submodule URLs
Documentation: read-tree --prefix works with existing subtrees
Add MYMETA.json to perl/.gitignore
Since the relative submodule URLs have been introduced in f31a522a2d, they
do not conform to the rules for resolving relative URIs but rather to
those of relative directories.
Document that behavior.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since 34110cd4 (Make 'unpack_trees()' have a separate source and
destination index) it is no longer true that a subdirectory with
the same prefix must not exist.
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Contains accumulated fixes since 1.7.8 that have been merged to the
'master' branch in preparation for the 1.7.9 release.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jk/maint-mv:
mv: be quiet about overwriting
mv: improve overwrite warning
mv: make non-directory destination error more clear
mv: honor --verbose flag
docs: mention "-k" for both forms of "git mv"
Clarify there is a -M option, but no -C. These are both
configurable through variables.
Explain that the allowSubmit variable takes a comma-separated
list of branch names.
Catch earlier an invalid branch name given as an argument to
"git p4 clone".
Test option --origin, variable allowSubmit, and explicit master
branch name.
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The depot path is required, even with this option. Make sure
git-p4 fails and exits with non-zero.
Contents in the specified depot path will be rearranged according
to the client spec. Test this and add a note in the docs.
Leave an XXX suggesting that this is somewhat confusing behavior
that might be good to fix later.
Function stripRepoPath() looks at self.useClientSpec. Make sure
this is set both for command-line option --use-client-spec and
for configuration variable git-p4.useClientSpec. Test this.
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Explain that it is needed on future syncs to find p4 branches
in refs/heads. Test this behavior.
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Clone with --branch will not checkout HEAD, unless the branch
happens to be called the default refs/remotes/p4/master. The
--branch option is most useful with sync; give an example of
that.
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Document how git-p4 currently works when specifying multiple
depot paths:
1. No branches or directories are named.
2. Conflicting files are silently ignored---the last change
wins.
2. Option --destination is required, else the last path is construed
to be a directory.
3. Revision specifiers must be the same on all paths for them to
take effect.
Test this behavior.
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add proper documentation for git-p4. Delete the old .txt
documentation from contrib/fast-import.
Cc: Frans Klaver <fransklaver@gmail.com>
Cc: Luke Diamand <luke@diamand.org>
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
92c62a3 (Porcelain scripts: Rewrite cryptic "needs update" error
message, 2010-10-19) refactored git's own checking to a function in
git-sh-setup. This is a very useful thing for script writers, so
document it.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jk/maint-mv:
mv: be quiet about overwriting
mv: improve overwrite warning
mv: make non-directory destination error more clear
mv: honor --verbose flag
docs: mention "-k" for both forms of "git mv"
* jk/credentials:
t: add test harness for external credential helpers
credentials: add "store" helper
strbuf: add strbuf_add*_urlencode
Makefile: unix sockets may not available on some platforms
credentials: add "cache" helper
docs: end-user documentation for the credential subsystem
credential: make relevance of http path configurable
credential: add credential.*.username
credential: apply helper config
http: use credential API to get passwords
credential: add function for parsing url components
introduce credentials API
t5550: fix typo
test-lib: add test_config_global variant
Conflicts:
strbuf.c
By definition, the default value of "advice.*" variables must be true and
they all control various additional help messages that are designed to aid
new users. Setting one to false is to tell Git that the user understands
the nature of the error and does not need the additional verbose help
message.
Also fix the asciidoc markup for linkgit:git-checkout[1] in the
description of the detachedHead advice by removing an excess colon.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
After the description and options, the fsck manpage contains
some discussion about what it does. Over time, this
discussion has become somewhat obsolete, both in content and
formatting. In particular:
1. There are many options now, so starting the discussion
with "It tests..." makes it unclear whether we are
talking about the last option, or about the tool in
general. Let's start a new "discussion" section and
make our antecedent more clear.
2. It gave an example for --unreachable using for-each-ref
to mention all of the heads, saying that it will do "a
_lot_ of verification". This is hopelessly out-of-date,
as giving no arguments will check much more (reflogs,
the index, non-head refs).
3. It goes on to mention tests "to be added" (like tree
object sorting). We now have these tests.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When doing a reflog walk, you can get some information about
the reflog (such as the subject line), but not the identity
information (i.e., name and email).
Let's make those available, mimicing the options for author
and committer identity.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint-1.7.7:
Git 1.7.7.5
Git 1.7.6.5
blame: don't overflow time buffer
fetch: create status table using strbuf
checkout,merge: loosen overwriting untracked file check based on info/exclude
cast variable in call to free() in builtin/diff.c and submodule.c
apply: get rid of useless x < 0 comparison on a size_t type
Conflicts:
Documentation/git.txt
GIT-VERSION-GEN
RelNotes
builtin/fetch.c
Tell the user what this command is intended for, and expand the
description of what it does.
Signed-off-by: Conrad Irwin <conrad.irwin@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is like "cache", except that we actually put the
credentials on disk. This can be terribly insecure, of
course, but we do what we can to protect them by filesystem
permissions, and we warn the user in the documentation.
This is not unlike using .netrc to store entries, but it's a
little more user-friendly. Instead of putting credentials in
place ahead of time, we transparently store them after
prompting the user for them once.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The code for a verbose flag has been here since "git mv" was
converted to C many years ago, but actually getting the "-v"
flag from the command line was accidentally lost in the
transition.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The "git mv" synopsis shows two forms: renaming a file, and
moving files into a directory. They can both make use of the
"-k" flag to ignore errors, so mention it in both places.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If you access repositories over smart-http using http
authentication, then it can be annoying to have git ask you
for your password repeatedly. We cache credentials in
memory, of course, but git is composed of many small
programs. Having to input your password for each one can be
frustrating.
This patch introduces a credential helper that will cache
passwords in memory for a short period of time.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The credential API and helper format is already defined in
technical/api-credentials.txt. This presents the end-user
view.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
All of the components of a credential struct can be found in
a URL. For example, the URL:
http://foo:bar@example.com/repo.git
contains:
protocol=http
host=example.com
path=repo.git
username=foo
password=bar
We want to be able to turn URLs into broken-down credential
structs so that we know two things:
1. Which parts of the username/password we still need
2. What the context of the request is (for prompting or
as a key for storing credentials).
This code is based on http_auth_init in http.c, but needed a
few modifications in order to get all of the components that
the credential object is interested in.
Once the http code is switched over to the credential API,
then http_auth_init can just go away.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There are a few places in git that need to get a username
and password credential from the user; the most notable one
is HTTP authentication for smart-http pushing.
Right now the only choices for providing credentials are to
put them plaintext into your ~/.netrc, or to have git prompt
you (either on the terminal or via an askpass program). The
former is not very secure, and the latter is not very
convenient.
Unfortunately, there is no "always best" solution for
password management. The details will depend on the tradeoff
you want between security and convenience, as well as how
git can integrate with other security systems (e.g., many
operating systems provide a keychain or password wallet for
single sign-on).
This patch provides an abstract notion of credentials as a
data item, and provides three basic operations:
- fill (i.e., acquire from external storage or from the
user)
- approve (mark a credential as "working" for further
storage)
- reject (mark a credential as "not working", so it can
be removed from storage)
These operations can be backed by external helper processes
that interact with system- or user-specific secure storage.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jc/pull-signed-tag:
commit-tree: teach -m/-F options to read logs from elsewhere
commit-tree: update the command line parsing
commit: teach --amend to carry forward extra headers
merge: force edit and no-ff mode when merging a tag object
commit: copy merged signed tags to headers of merge commit
merge: record tag objects without peeling in MERGE_HEAD
merge: make usage of commit->util more extensible
fmt-merge-msg: Add contents of merged tag in the merge message
fmt-merge-msg: package options into a structure
fmt-merge-msg: avoid early returns
refs DWIMmery: use the same rule for both "git fetch" and others
fetch: allow "git fetch $there v1.0" to fetch a tag
merge: notice local merging of tags and keep it unwrapped
fetch: do not store peeled tag object names in FETCH_HEAD
Split GPG interface into its own helper library
Conflicts:
builtin/fmt-merge-msg.c
builtin/merge.c
* jc/request-pull-show-head-4:
request-pull: use the annotated tag contents
fmt-merge-msg.c: Fix an "dubious one-bit signed bitfield" sparse error
environment.c: Fix an sparse "symbol not declared" warning
builtin/log.c: Fix an "Using plain integer as NULL pointer" warning
fmt-merge-msg: use branch.$name.description
request-pull: use the branch description
request-pull: state what commit to expect
request-pull: modernize style
branch: teach --edit-description option
format-patch: use branch description in cover letter
branch: add read_branch_desc() helper function
Conflicts:
builtin/branch.c
Normally git tag strips tag message lines starting with '#', trailing
spaces from every line and empty lines from the beginning and end.
--cleanup allows to select different cleanup modes for tag message.
It provides the same interface as --cleanup option in git-commit.
Signed-off-by: Kirill A. Shutemov <kirill@shutemov.name>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The old "git symbolic-ref" manpage seemed to imply in one place that
symlinks are still the default way to represent symbolic references
and in another that symlinks are deprecated. Fix the text and shorten
the justification for the change of implementation.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Change the skeleton implementation of i18n in Git to one that can show
localized strings to users for our C, Shell and Perl programs using
either GNU libintl or the Solaris gettext implementation.
This new internationalization support is enabled by default. If
gettext isn't available, or if Git is compiled with
NO_GETTEXT=YesPlease, Git falls back on its current behavior of
showing interface messages in English. When using the autoconf script
we'll auto-detect if the gettext libraries are installed and act
appropriately.
This change is somewhat large because as well as adding a C, Shell and
Perl i18n interface we're adding a lot of tests for them, and for
those tests to work we need a skeleton PO file to actually test
translations. A minimal Icelandic translation is included for this
purpose. Icelandic includes multi-byte characters which makes it easy
to test various edge cases, and it's a language I happen to
understand.
The rest of the commit message goes into detail about various
sub-parts of this commit.
= Installation
Gettext .mo files will be installed and looked for in the standard
$(prefix)/share/locale path. GIT_TEXTDOMAINDIR can also be set to
override that, but that's only intended to be used to test Git itself.
= Perl
Perl code that's to be localized should use the new Git::I18n
module. It imports a __ function into the caller's package by default.
Instead of using the high level Locale::TextDomain interface I've
opted to use the low-level (equivalent to the C interface)
Locale::Messages module, which Locale::TextDomain itself uses.
Locale::TextDomain does a lot of redundant work we don't need, and
some of it would potentially introduce bugs. It tries to set the
$TEXTDOMAIN based on package of the caller, and has its own
hardcoded paths where it'll search for messages.
I found it easier just to completely avoid it rather than try to
circumvent its behavior. In any case, this is an issue wholly
internal Git::I18N. Its guts can be changed later if that's deemed
necessary.
See <AANLkTilYD_NyIZMyj9dHtVk-ylVBfvyxpCC7982LWnVd@mail.gmail.com> for
a further elaboration on this topic.
= Shell
Shell code that's to be localized should use the git-sh-i18n
library. It's basically just a wrapper for the system's gettext.sh.
If gettext.sh isn't available we'll fall back on gettext(1) if it's
available. The latter is available without the former on Solaris,
which has its own non-GNU gettext implementation. We also need to
emulate eval_gettext() there.
If neither are present we'll use a dumb printf(1) fall-through
wrapper.
= About libcharset.h and langinfo.h
We use libcharset to query the character set of the current locale if
it's available. I.e. we'll use it instead of nl_langinfo if
HAVE_LIBCHARSET_H is set.
The GNU gettext manual recommends using langinfo.h's
nl_langinfo(CODESET) to acquire the current character set, but on
systems that have libcharset.h's locale_charset() using the latter is
either saner, or the only option on those systems.
GNU and Solaris have a nl_langinfo(CODESET), FreeBSD can use either,
but MinGW and some others need to use libcharset.h's locale_charset()
instead.
=Credits
This patch is based on work by Jeff Epler <jepler@unpythonic.net> who
did the initial Makefile / C work, and a lot of comments from the Git
mailing list, including Jonathan Nieder, Jakub Narebski, Johannes
Sixt, Erik Faye-Lund, Peter Krefting, Junio C Hamano, Thomas Rast and
others.
[jc: squashed a small Makefile fix from Ramsay]
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* nd/fsck-progress:
fsck: print progress
fsck: avoid reading every object twice
verify_packfile(): check as many object as possible in a pack
fsck: return error code when verify_pack() goes wrong
The first paragraph inside of a list item does not need a preceding line
consisting of a single '+', and in fact this causes the text to be
misrendered. Fix it.
Signed-off-by: Jack Nagel <jacknagel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The second mode of 'git reset' is defined by the --patch
option, while the third mode is defined by the <mode> option.
Hence, these options are mandatory in the description of the
individual modes.
Signed-off-by: Vincent van Ravesteijn <vfr@lyx.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
After running some ill-advised command like "git cherry-pick
HEAD..linux-next", the bewildered novice may want to return to more
familiar territory. Introduce a "git cherry-pick --abort" command
that rolls back the entire cherry-pick sequence and places the
repository back on solid ground.
Just like "git merge --abort", this internally uses "git reset
--merge", so local changes not involved in the conflict resolution are
preserved.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The option to "git cherry-pick" and "git revert" to discard the
sequencer state introduced by v1.7.8-rc0~141^2~6 (revert: Introduce
--reset to remove sequencer state, 2011-08-04) has a confusing name.
Change it now, while we still have the time.
The new name for "cherry-pick, please get out of my way, since I've
long forgotten about the sequence of commits I was cherry-picking when
you wrote that old .git/sequencer directory" is --quit. Mnemonic:
this is analagous to quiting a program the user is no longer using ---
we just want to get out of the multiple-command cherry-pick procedure
and not to reset HEAD or rewind any other old state.
The "--reset" option is kept as a synonym to minimize the impact. We
might consider dropping it for simplicity in a separate patch, though.
Adjust documentation and tests to use the newly preferred name (--quit)
instead of --reset. While at it, let's clarify the short descriptions
of these operations in "-h" output.
Before:
--reset forget the current operation
--continue continue the current operation
After:
--quit end revert or cherry-pick sequence
--continue resume revert or cherry-pick sequence
Noticed-by: Phil Hord <phil.hord@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Let the documentation for -t list valid *diff* tools,
not valid *merge* tools.
Signed-off-by: Thomas Hochstein <thh@inter.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
MATLAB is often used in industry and academia for scientific
computations motivating it being included as a built-in pattern.
Signed-off-by: Gustaf Hendeby <hendeby@isy.liu.se>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The preformatted documentation pages live in their own repositories
these days. Adjust the installation procedure to the updated layout.
Tested-by: Stefan Naewe <stefan.naewe@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These are diff-options, but they don't actually make sense
in the context of log.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently we either need to set branch.<name>.rebase for existing
branches if we'd like "git pull" to mean "git pull --rebase", or have
the forethought of setting "branch.autosetuprebase" before we create
the branch.
Introduce a "pull.rebase" option to globally configure "git pull" to
mean "git pull --rebase" for any branch.
This option will be considered at a lower priority than
branch.<name>.rebase, i.e. we could set pull.rebase=true and
branch.<name>.rebase=false and the latter configuration option would
win.
Reviewed-by: Sverre Rabbelier <srabbelier@gmail.com>
Reviewed-by: Fernando Vezzosi <buccia@repnz.net>
Reviewed-by: Eric Herman <eric@freesa.org>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Liked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
fsck is usually a long process and it would be nice if it prints
progress from time to time.
Progress meter is not printed when --verbose is given because
--verbose prints a lot, there's no need for "alive" indicator.
Progress meter may provide "% complete" information but it would
be lost anyway in the flood of text.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jk/argv-array:
run_hook: use argv_array API
checkout: use argv_array API
bisect: use argv_array API
quote: provide sq_dequote_to_argv_array
refactor argv_array into generic code
quote.h: fix bogus comment
add sha1_array API docs
* maint-1.7.6:
notes_merge_commit(): do not pass temporary buffer to other function
gitweb: Fix links to lines in blobs when javascript-actions are enabled
mergetool: no longer need to save standard input
mergetool: Use args as pathspec to unmerged files
t9159-*.sh: skip for mergeinfo test for svn <= 1.4
date.c: Support iso8601 timezone formats
remote: only update remote-tracking branch if updating refspec
remote rename: warn when refspec was not updated
remote: "rename o foo" should not rename ref "origin/bar"
remote: write correct fetch spec when renaming remote 'remote'
* maint-1.7.6:
make the sample pre-commit hook script reject names with newlines, too
git-read-tree.txt: update sparse checkout examples
git-read-tree.txt: correct sparse-checkout and skip-worktree description
git-read-tree.txt: language and typography fixes
unpack-trees: print "Aborting" to stderr
Documentation/git-update-index: refer to 'ls-files'
Documentation: basic configuration of notes.rewriteRef
