The current technical documentation for the packfile protocol is both
sparse and incorrect. This documents the fetch-pack/upload-pack and
send-pack/ receive-pack protocols much more fully.
Add documentation from Shawn's upcoming http-protocol docs that is
shared by the packfile protocol. protocol-common.txt describes ABNF
notation amendments, refname rules and the packet line format.
Add documentation on the various capabilities supported by the
upload-pack and receive-pack protocols. protocol-capabilities.txt
describes multi-ack, thin-pack, side-band[-64k], shallow, no-progress,
include-tag, ofs-delta, delete-refs and report-status.
Signed-off-by: Scott Chacon <schacon@gmail.com>
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since a0e4639 (filter-branch: fix ref rewriting with
--subdirectory-filter, 2008-08-12) git-filter-branch has done
nearest-ancestor rewriting when using a --subdirectory-filter.
However, that rewriting strategy is also a useful building block in
other tasks. For example, if you want to split out a subset of files
from your history, you would typically call
git filter-branch -- <refs> -- <files>
But this fails for all refs that do not point directly to a commit
that affects <files>, because their referenced commit will not be
rewritten and the ref remains untouched.
The code was already there for the --subdirectory-filter case, so just
introduce an option that enables it independently.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"-p" means "generate patch" in 'git log' and 'git diff', so it's
quite surprising that it means "suppress diffstat" in
'git format-patch'.
Keep the "-p" option for backward compatibility, but add
"--no-stat" as a more intuitive synonym. For backward compatibility
with scripts, we must allow combinations of --stat and --no-stat.
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Format git commands and options consistently using back quotes
(i.e. a fixed font in the resulting HTML document).
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
To simplify reading the documentation for format-patch, remove the
description of common diff options that are not useful for the
purpose of the command (i.e. "Prepare patches for e-mail submission").
Specifically, this removes the description of the following options:
--raw
-z
--color
--no-color
--color-words
--diff-filter
-S
--pickaxe-all
--pickaxe-regex
-R
--relative
--exit-code
--quiet
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King recently reinstated -p to suppress the default diffstat
(as -p used to work before 68daa64, about 14 months ago).
However, -p is also needed in combination with certain options
(e.g. --stat or --numstat) in order to produce any patch at all.
The documentation does not mention this.
Since the purpose of format-patch is to produce a patch that
can be emailed, it does not make sense that certain combination
of options will suppress the generation of the patch itself.
Therefore:
* Update 'git format-patch' to always generate a patch.
* Since the --name-only, --name-status, and --check suppresses
the generation of the patch, disallow those options,
and remove the description of them in the documentation.
* Remove the reference to -p in the description of -U.
* Remove the descriptions of the options that are synonyms for -p
plus another option (--patch-with-raw and --patch-with-stat).
* While at it, slightly tweak the description of -p itself
to say that it generates "plain patches", so that you can
think of -p as "plain patch" as an mnemonic aid.
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add the description next to --assume-unchanged because this option is only
useful in a special case of using that option.
Signed-off-by: Štěpán Němec <stepnem@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Teach fetch --dry-run as users of "git remote prune" switching to "git fetch
--prune" may expect it. Unfortunately OPT__DRY_RUN() cannot be used as fetch
already uses "-n" for something else.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Teach fetch to cull stale remote tracking branches after fetching via --prune.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Implement the configuration skipFetchAll option to allow
certain remotes to be skipped when doing 'git fetch --all' and
'git remote update'. The existing skipDefaultUpdate variable
is still honored (by 'git fetch --all' and 'git remote update').
(If both are set in the configuration file with different values,
the value of the last occurrence will be used.)
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add the --multiple option to specify that all arguments are either
groups or remotes. The primary reason for adding this option is
to allow us to re-implement 'git remote update' using fetch.
It would have been nice if this option was not needed, but since
the colon in a refspec is optional, it is in general not possible
to know whether a single, colon-less argument is a remote or a
refspec.
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
'git remote' is meant for managing remotes and 'git fetch' is meant
for actually fetching data from remote repositories. Therefore, it is
not logical that you must use 'git remote update' to fetch from
more than one repository at once.
Add the --all option to 'git fetch', to tell it to attempt to fetch
from all remotes. Also, if --all is not given, the <repository>
argument is allowed to be the name of a group, to allow fetching
from all repositories in the group.
Other options except -v and -q are silently ignored.
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This only changes the behavior of "git show-ref -h" without any
other options and arguments.
"show-ref -h" currently is short for "show-ref --head", which
shows all the refs/* and HEAD, as opposed to "show-ref" that
shows all the refs/* and not HEAD.
Does anybody use "show-ref -h"? It was in Linus's original, most
likely only because "it might be handy", not because "the command
should not show the HEAD by default for such and such reasons".
So I think it is okay if "show-ref -h" (but not "show-ref
--head") gives help and exits.
If a current script uses "git show-ref -h" without any other
arguments, it would have to be adapted by changing "-h" to
"--head".
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch adds an asciidoc version of the "Fighting regressions with
git bisect" article that the author wrote for the Linux-Kongress
2009 (http://www.linux-kongress.org/2009).
This paper might be interesting to people who want to learn as much as
possible about "git bisect" from a single document.
The slides of the related presentation are available at:
http://www.linux-kongress.org/2009/slides/fighting_regressions_with_git_bisect_christian_couder.pdf
But the Linux Kongress people will not publish this paper online because
they print the papers on their UpTimes magazine
(http://www.lob.de/isbn/978-3-86541-358-1). But they don't take away the
rights of the author (which is very nice), so I have the right to publish
it.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There were some differences between t1200 and the gitcore-tutorial. Add
missing tests for manually merging two branches, and use the same
commands in both files.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some repository owners may wish to enable smart HTTP, but disallow
dumb content serving. Disallowing dumb serving might be because
the owners want to rely upon reachability to control which objects
clients may access from the repository, or they just want to
encourage clients to use the more bandwidth efficient transport.
If http.getanyfile is set to false the backend CGI will return with
'403 Forbidden' when an object file is accessed by a dumb client.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The git-remote-curl backend detects if the remote server supports
the git-receive-pack service, and if so, runs git-send-pack in a
pipe to dump the command and pack data as a single POST request.
The advertisements from the server that were obtained during the
discovery are passed into git-send-pack before the POST request
starts. This permits git-send-pack to operate largely unmodified.
For smaller packs (those under 1 MiB) a HTTP/1.0 POST with a
Content-Length is used, permitting interaction with any server.
The 1 MiB limit is arbitrary, but is sufficent to fit most deltas
created by human authors against text sources with the occasional
small binary file (e.g. few KiB icon image). The configuration
option http.postBuffer can be used to increase (or shink) this
buffer if the default is not sufficient.
For larger packs which cannot be spooled entirely into the helper's
memory space (due to http.postBuffer being too small), the POST
request requires HTTP/1.1 and sets "Transfer-Encoding: chunked".
This permits the client to upload an unknown amount of data in one
HTTP transaction without needing to pregenerate the entire pack
file locally.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
CC: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In the git-http-backend examples, only match git-receive-pack within
/git/.
Signed-off-by: Mark Lodato <lodatom@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In the git-http-backend documentation, add an example of how to set up
gitweb and git-http-backend on the same URL by using a series of
mod_alias commands.
Signed-off-by: Mark Lodato <lodatom@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In the git-http-backend documentation, use mod_alias exlusively, instead
of using a combination of mod_alias and mod_rewrite. This makes the
example slightly shorted and a bit more clear.
Signed-off-by: Mark Lodato <lodatom@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Clarify some of the git-http-backend documentation, particularly:
* In the Description, state that smart/dumb HTTP fetch and smart HTTP
push are supported, state that authenticated clients allow push, and
remove the note that this is only suited for read-only updates.
* At the start of Examples, state explicitly what URL is mapping to what
location on disk.
Signed-off-by: Mark Lodato <lodatom@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add a new environment variable, GIT_PROJECT_ROOT, to override the
method of using PATH_TRANSLATED to find the git repository on disk.
This makes it much easier to configure the web server, especially when
the web server's DocumentRoot does not contain the git repositories,
which is the usual case.
Signed-off-by: Mark Lodato <lodatom@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Requests for $GIT_URL/git-receive-pack and $GIT_URL/git-upload-pack
are forwarded to the corresponding backend process by directly
executing it and leaving stdin and stdout connected to the invoking
web server. Prior to starting the backend process the HTTP response
headers are sent, thereby freeing the backend from needing to know
about the HTTP protocol.
Requests that are encoded with Content-Encoding: gzip are
automatically inflated before being streamed into the backend.
This is primarily useful for the git-upload-pack backend, which
receives highly repetitive text data from clients that easily
compresses to 50% of its original size.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The git-http-backend CGI can be configured into any Apache server
using ScriptAlias, such as with the following configuration:
LoadModule cgi_module /usr/libexec/apache2/mod_cgi.so
LoadModule alias_module /usr/libexec/apache2/mod_alias.so
ScriptAlias /git/ /usr/libexec/git-core/git-http-backend/
Repositories are accessed via the translated PATH_INFO.
The CGI is backwards compatible with the dumb client, allowing all
older HTTP clients to continue to download repositories which are
managed by the CGI.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we use -c, -C, or --amend, we are trying one of two things: using the
source as a template or modifying a commit with corrections.
When these options are used, the authorship and timestamp recorded in the
newly created commit are always taken from the original commit. This is
inconvenient when we just want to borrow the commit log message or when
our change to the code is so significant that we should take over the
authorship (with the blame for bugs we introduce, of course).
The new --reset-author option is meant to solve this need by regenerating
the timestamp and setting the committer as the new author.
Signed-off-by: Erick Mattos <erick.mattos@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Introduced in 492cf3f (More precise description of 'git describe --abbrev', 2009-10-29)
Signed-off-by: Gisle Aas <gisle@aas.no>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* ja/fetch-doc:
Documentation/merge-options.txt: order options in alphabetical groups
Documentation/git-pull.txt: Add subtitles above included option files
Documentation/fetch-options.txt: order options alphabetically
The remote helper interface now supports the push capability,
which can be used to ask the implementation to push one or more
specs to the remote repository. For remote-curl we implement this
by calling the existing WebDAV based git-http-push executable.
Internally the helper interface uses the push_refs transport hook
so that the complexity of the refspec parsing and matching can be
reused between remote implementations. When possible however the
helper protocol uses source ref name rather than the source SHA-1,
thereby allowing the helper to access this name if it is useful.
>From Clemens Buchacher <drizzd@aon.at>:
update http tests according to remote-curl capabilities
o Pushing packed refs is now fixed.
o The transport helper fails if refs are already up-to-date. Add
a test for that.
o The transport helper will notice if refs are already
up-to-date. We therefore need to update server info in the
unpacked-refs test.
o The transport helper will purge deleted branches automatically.
o Use a variable ($ORIG_HEAD) instead of full SHA-1 name.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
CC: Daniel Barkalow <barkalow@iabervon.org>
CC: Mike Hommey <mh@glandium.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some transports, like the native pack transport implemented by
fetch-pack, support useful features like depth or include tags.
These should be exposed if the underlying helper knows how to
use them.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
CC: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some network protocols (e.g. native git://) are able to fetch more
than one ref at a time and reduce the overall transfer cost by
combining the requests into a single exchange. Instead of feeding
each fetch request one at a time to the helper, feed all of them
at once so the helper can decide whether or not it should batch them.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
CC: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
For convenience in scripts and aliases, add the option
--ff-only to only allow fast-forwards (and up-to-date,
despite the name).
Disallow combining --ff-only and --no-ff, since they
flatly contradict each other.
Allow all other options to be combined with --ff-only
(i.e. do not add any code to handle them specially),
including the following options:
* --strategy (one or more): As long as the chosen merge
strategy results in up-to-date or fast-forward, the
command will succeed.
* --squash: I cannot imagine why anyone would want to
squash commits only if fast-forward is possible, but I
also see no reason why it should not be allowed.
* --message: The message will always be ignored, but I see
no need to explicitly disallow providing a redundant message.
Acknowledgements: I did look at Yuval Kogman's earlier
patch (107768 in gmane), mainly as shortcut to find my
way in the code, but I did not copy anything directly.
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Also adds a note about why the output in the examples might give
different output today.
Signed-off-by: Gisle Aas <gisle@aas.no>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit b5227d8 changed the behavior of "ls-files" with
respect to includes, but accidentally broke the "-i" option
The original behavior was:
1. if no "-i" is given, cull all results according to --exclude*
2. if "-i" is given, show the inverse of (1)
The broken behavior was:
1. if no "-i" is given:
a. for "-o", cull results according to --exclude*
b. for index files, always show all
2. if "-i" is given:
a. for "-o", shows the inverse of (1a)
b. for index files, always show all
The fixed behavior keeps the new (1b) behavior introduced
by b5227d8, but fixes the (2b) behavior to show only ignored
files, not all files.
This patch also tweaks the documentation. The original text
was somewhat obscure in the first place, but it is also now
inaccurate (the relationship between (1b) and (2b) is not
quite a "reverse").
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add p4merge to the set of built-in diff/merge tools, and update
bash completion and documentation.
Signed-off-by: Scott Chacon <schacon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
With the --dirty option, git describe works on HEAD but append s"-dirty"
iff the contents of the work tree differs from HEAD. E.g.
$ git describe --dirty
v1.6.5-15-gc274db7
$ echo >> Makefile
$ git describe --dirty
v1.6.5-15-gc274db7-dirty
The --dirty option can also be used to specify what is appended, instead
of the default string "-dirty".
$ git describe --dirty=.mod
v1.6.5-15-gc274db7.mod
Many build scripts use `git describe` to produce a version number based on
the description of HEAD (on which the work tree is based) + saying that if
the build contains uncommitted changes. This patch helps the writing of
such scripts since `git describe --dirty` does directly the intended thing.
Three possiblities were considered while discussing this new feature:
1. Describe the work tree by default and describe HEAD only if "HEAD" is
explicitly specified
Pro: does the right thing by default (both for users and for scripts)
Pro: other git commands that works on the work tree by default
Con: breaks existing scripts used by the Linux kernel and other projects
2. Use --worktree instead of --dirty
Pro: does what it says: "git describe --worktree" describes the work tree
Con: other commands do not require a --worktree option when working
on the work tree (it often is the default mode for them)
Con: unusable with an optional value: "git describe --worktree=.mod"
is quite unintuitive.
3. Use --dirty as in this patch
Pro: makes sense to specify an optional value (what the dirty mark is)
Pro: does not have any of the big cons of previous alternatives
* does not break scripts
* is not inconsistent with other git commands
This patch takes the third approach.
Signed-off-by: Jean Privat <jean@pryen.org>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jc/receive-pack-auto:
receive-pack: run "gc --auto --quiet" and optionally "update-server-info"
gc --auto --quiet: make the notice a bit less verboase
The docbook/xmlto toolchain insists on quoting ' as \'. This does
achieve the quoting goal, but modern 'man' implementations turn the
apostrophe into a unicode "proper" apostrophe (given the right
circumstances), breaking code examples in many of our manpages.
Quote them as \(aq instead, which is an "apostrophe quote" as per the
groff_char manpage.
Unfortunately, as Anders Kaseorg kindly pointed out, this is not
portable beyond groff, so we add an extra Makefile variable GNU_ROFF
which you need to enable to get the new quoting.
Thanks also to Miklos Vajna for documentation.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add the missing definite article ("the") in several places.
Change "note to..." to "note for...", since "note to" means that
that the note is addressed to someone (source: Google search).
Change "progressbar" to "progress bar" (source: Wikipedia).
Format git commands, options, and file names consistently using
back quotes (i.e. a fixed font in the resulting HTML document).
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Introduce two new configuration variables, receive.autogc (defaults to
true) and receive.updateserverinfo (defaults to false). When these are
set, receive-pack runs "gc --auto --quiet" and "update-server-info"
respectively after it finishes receiving data from "git push" and updating
refs.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Acked-by: Nicolas Pitre <nico@fluxnic.net>
The "git pull" documentation has examples which follow an outdated
style. Update the examples to use "git merge" where appropriate and
move the examples to the corresponding manpages.
Furthermore,
- show that pull is equivalent to fetch and merge, which is still a
frequently asked question,
- explain the default fetch refspec.
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Linus and other git developers from the early days trained their fingers
to type the command, every once in a while even without thinking, to check
the consistency of the repository back when the lower core part of the git
was still being developed. Developers who wanted to make sure that git
correctly dealt with packfiles could deliberately trigger their creation
and checked them after they were created carefully, but loose objects are
the ones that are written by various commands from random codepaths. It
made some technical sense to have a mode that checked only loose objects
from the debugging point of view for that reason.
Even for git developers, there no longer is any reason to type "git fsck"
every five minutes these days, worried that some newly created objects
might be corrupt due to recent change to git.
The reason we did not make "--full" the default is probably we trust our
filesystems a bit too much. At least, we trusted filesystems more than we
trusted the lower core part of git that was under development.
Once a packfile is created and we always use it read-only, there didn't
seem to be much point in suspecting that the underlying filesystems or
disks may corrupt them in such a way that is not caught by the SHA-1
checksum over the entire packfile and per object checksum. That trust in
the filesystems might have been a good tradeoff between fsck performance
and reliability on platforms git was initially developed on and for, but
it may not be true anymore as we run on many more platforms these days.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When you use the option --submodule=log you can see the submodule
summaries inlined in the diff, instead of not-quite-helpful SHA-1 pairs.
The format imitates what "git submodule summary" shows.
To do that, <path>/.git/objects/ is added to the alternate object
databases (if that directory exists).
This option was requested by Jens Lehmann at the GitTogether in Berlin.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
'git stash list' had an undocumented limit of 10 stashes, unless other
git-log arguments were specified. This surprised at least one user,
but possibly served to cut the output below a screenful without using
a pager.
Since the last commit, 'git stash list' will fire up a pager according
to the same rules as the 'git log' it calls, so we can drop the limit.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add three new --pretty=format escapes:
%gD long reflog descriptor (e.g. refs/stash@{0})
%gd short reflog descriptor (e.g. stash@{0})
%gs reflog message
This is achieved by passing down the reflog info, if any, inside the
pretty_print_context struct.
We use the newly refactored get_reflog_selector(), and give it some
extra functionality to extract a shortened ref. The shortening is
cached inside the commit_reflogs struct; the only allocation of it
happens in read_complete_reflog(), where it is initialised to 0. Also
add another helper get_reflog_message() for the message extraction.
Note that the --format="%h %gD: %gs" tests may not work in real
repositories, as the --pretty formatter doesn't know to leave away the
": " on the last commit in an incomplete (because git-gc removed the
old part) reflog. This equivalence is nevertheless the main goal of
this patch.
Thanks to Jeff King for reviews, the %gd testcase and documentation.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Introduce a 'notemodify' subcommand of the 'commit' command. This subcommand
is similar to 'filemodify', except that no mode is supplied (all notes have
mode 0644), and the path is set to the hex SHA1 of the given "comittish".
This enables fast import of note objects along with their associated commits,
since the notes can now be named using the mark references of their
corresponding commits.
The patch also includes a test case of the added functionality.
Signed-off-by: Johan Herland <johan@herland.net>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The "-m" and "-F" options are already the established method
(in both git-commit and git-tag) to specify a commit/tag message
without invoking the editor. This patch teaches "git notes edit"
to respect the same options for specifying a notes message without
invoking the editor.
Multiple "-m" and/or "-F" options are concatenated as separate
paragraphs.
The patch also updates the "git notes" documentation and adds
selftests for the new functionality. Unfortunately, the added
selftests include a couple of lines with trailing whitespace
(without these the test will fail). This may cause git to warn
about "whitespace errors".
This patch has been improved by the following contributions:
- Thomas Rast: fix trailing whitespace in t3301
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The script 'git notes' allows you to edit and show commit notes, by
calling either
git notes show <commit>
or
git notes edit <commit>
This patch has been improved by the following contributions:
- Tor Arne Vestbø: fix printing of multi-line notes
- Michael J Gruber: test and handle empty notes gracefully
- Thomas Rast:
- only clean up message file when editing
- use GIT_EDITOR and core.editor over VISUAL/EDITOR
- t3301: fix confusing quoting in test for valid notes ref
- t3301: use test_must_fail instead of !
- refuse to edit notes outside refs/notes/
- Junio C Hamano: tests: fix "export var=val"
- Christian Couder: documentation: fix 'linkgit' macro in "git-notes.txt"
- Johan Herland: minor cleanup and bugfixing in git-notes.sh (v2)
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Tor Arne Vestbø <tavestbo@trolltech.com>
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit notes are blobs which are shown together with the commit
message. These blobs are taken from the notes ref, which you can
configure by the config variable core.notesRef, which in turn can
be overridden by the environment variable GIT_NOTES_REF.
The notes ref is a branch which contains "files" whose names are
the names of the corresponding commits (i.e. the SHA-1).
The rationale for putting this information into a ref is this: we
want to be able to fetch and possibly union-merge the notes,
maybe even look at the date when a note was introduced, and we
want to store them efficiently together with the other objects.
This patch has been improved by the following contributions:
- Thomas Rast: fix core.notesRef documentation
- Tor Arne Vestbø: fix printing of multi-line notes
- Alex Riesen: Using char array instead of char pointer costs less BSS
- Johan Herland: Plug leak when msg is good, but msglen or type causes return
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Tor Arne Vestbø <tavestbo@trolltech.com>
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
get_commit_notes(): Plug memory leak when 'if' triggers, but not because of read_sha1_file() failure
* maint:
git push: say that --tag can't be used with --all or --mirror in help text
git push: remove incomplete options list from help text
document push's new quiet option
Makefile: clean block-sha1/ directory instead of mozilla-sha1/
* jc/maint-blank-at-eof:
diff -B: colour whitespace errors
diff.c: emit_add_line() takes only the rest of the line
diff.c: split emit_line() from the first char and the rest of the line
diff.c: shuffling code around
diff --whitespace: fix blank lines at end
core.whitespace: split trailing-space into blank-at-{eol,eof}
diff --color: color blank-at-eof
diff --whitespace=warn/error: fix blank-at-eof check
diff --whitespace=warn/error: obey blank-at-eof
diff.c: the builtin_diff() deals with only two-file comparison
apply --whitespace: warn blank but not necessarily empty lines at EOF
apply --whitespace=warn/error: diagnose blank at EOF
apply.c: split check_whitespace() into two
apply --whitespace=fix: detect new blank lines at eof correctly
apply --whitespace=fix: fix handling of blank lines at the eof
‘git bisect reset’ accepts an optional argument specifying a branch to
check out after cleaning up the bisection state. This lets you
specify an arbitrary commit.
In particular, this provides a way to clean the bisection state
without moving HEAD: ‘git bisect reset HEAD’. This may be useful if
you are not interested in the state before you began a bisect,
especially if checking out the old commit would be expensive and
invalidate most of your compiled tree.
Clarify the ‘git bisect reset’ documentation to explain this optional
argument, which was previously mentioned only in the usage message.
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit dae556b (environment: add global variable to disable replacement)
adds a variable to enable/disable replacement, and it is enabled by
default for most commands.
So there is no way to disable it for some commands, which is annoying
when we want to get information about a commit that has been replaced.
For example:
$ git cat-file -p N
would output information about the replacement commit if commit N is
replaced.
With the "--no-replace-objects" option that this patch adds it is
possible to get information about the original commit using:
$ git --no-replace-objects cat-file -p N
While at it, let's add some documentation about this new option in the
"git replace" man page too.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Tolerating empty path components in ref names means each ref does
not have a unique name. This creates difficulty for porcelains
that want to see if two branches are equal. Add a helper associating
to each ref a canonical name.
If a user asks a porcelain to create a ref "refs/heads//master",
the porcelain can run "git check-ref-format --print refs/heads//master"
and only deal with "refs/heads/master" from then on.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Unless one already knew, it was not obvious what sort of shorthand
"git check-ref-format --branch" expands. Explain it.
The --branch argument is not optional.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When saying the initial branch is equal to the currently active
remote branch, it is probably intended that the branch heads
point to the same commit. Maybe it would be more useful to a
new user to emphasize that the tree contents and history are the
same.
More important, probably, is that this new branch is set up so
that "git pull" merges changes from the corresponding remote
branch. The next paragraph addresses that directly. What the
reader needs to know to begin with is that (1) the initial branch
is your own; if you do not pull, it won't get updated, and that
(2) the initial branch starts out at the same commit as the
upstream.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Idealists may want USE_NSEC to be the default on Linux some day.
Point to a patch to better explain the requirements on
filesystem code for that to happen.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It is not necessarily obvious to a git novice what it means for a
filesystem tree to be equal to the HEAD. Spell it out.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The documentation seems to assume that the starting point for a new
branch is the tip of an existing (ordinary) branch, but that is not
the most common case. More often, "git branch" is used to begin
a branch from a remote-tracking branch, a tag, or an interesting
commit (e.g. origin/pu^2). Clarify the language so it can apply
to these cases. Thanks to Sean Estabrooks for the wording.
Also add a pointer to the user's manual for the bewildered.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Update the documentation for --merged and --no-merged to explain
the meaning of the optional parameter introduced in commit 049716b
(branch --merged/--no-merged: allow specifying arbitrary commit,
2008-07-08).
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Sounds better this way, at least to my ears. ("The syntax and
supported options of git merge" is a plural noun. "the same"
instead of "equal" sounds less technical and seems to convey
the meaning better here.)
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The fmt-merge-message builtin can be invoked as "git fmt-merge-msg" rather
than through the hard link in GIT_EXEC_PATH. Although this is unlikely to
confuse most script writers, it should not hurt to make the documentation
a little clearer anyway.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make it easier to edit just the commit message for a commit
using 'git rebase -i' by introducing the "reword" command.
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This teaches the "pretty" machinery to expand '%+x' to a LF followed by
the expansion of '%x' if and only if '%x' expands to a non-empty string,
and to remove LFs before '%-x' if '%x' expands to an empty string. This
works for any supported expansion placeholder 'x'.
This is expected to be immediately useful to reproduce the commit log
message with "%s%+b%n"; "%s%n%b%n" adds one extra LF if the log message is
a one-liner.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Translate some english words to portuguese and fix some
typos on translation.
Signed-off-by: Thiago Farina <tfransosi@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
The default --aggressive window has been 250 since 1c192f34 "gc
--aggressive: make it really aggressive", released in git v1.6.3.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
A sample "git describe -h" did not match what the program actually says.
Signed-off-by: Thiago Farina <tfransosi@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When <path> is not given, use the "humanish" part of the source repository
instead.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* 'jc/maint-1.6.0-blank-at-eof' (early part):
diff --whitespace: fix blank lines at end
core.whitespace: split trailing-space into blank-at-{eol,eof}
diff --color: color blank-at-eof
diff --whitespace=warn/error: fix blank-at-eof check
diff --whitespace=warn/error: obey blank-at-eof
diff.c: the builtin_diff() deals with only two-file comparison
apply --whitespace: warn blank but not necessarily empty lines at EOF
apply --whitespace=warn/error: diagnose blank at EOF
apply.c: split check_whitespace() into two
apply --whitespace=fix: detect new blank lines at eof correctly
apply --whitespace=fix: fix handling of blank lines at the eof
A command line
$ git archive -o my-v2.0.zip v2.0
almost certainly wants the output in zip format, even though it does not
specify any --format option.
When --format is not given, but output filename is, try to infer what
format is requested from the filename extension. Currently this code only
knows about '.zip'. When the format is unspecified and the filename does
not tell us, the output will be in 'tar' format as before.
Of course, an explicit --format will not trigger this guesswork.
Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The '-o' option is commonly used in many tools to specify the output file.
Typing '--output' every time is a bit too long to be a practical alternative
to redirecting output. But specifying the output name has the advantage of
making possible to guess the desired output format by filename extension.
Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-push is not currently using -n for anything else, and it seems
unlikely we will want to use it to mean anything else in the future,
so add it as an alias for convenience.
Signed-off-by: Nelson Elhage <nelhage@mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
60c2993 (Documentation/git-commit.txt: describe --dry-run, 2009-08-15)
wanted to update the documentation to say that "git status" is not the
same as "git commit --dry-run" anymore, but it screwed up and also added
the description of --dry-run that was already present.
Noticed by Johannes Gilger.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* db/vcs-helper:
Makefile: remove remnant of separate http/https/ftp helpers
Use a clearer style to issue commands to remote helpers
Make the "traditionally-supported" URLs a special case
Makefile: install hardlinks for git-remote-<scheme> supported by libcurl if possible
Makefile: do not link three copies of git-remote-* programs
Makefile: git-http-fetch does not need expat
http-fetch: Fix Makefile dependancies
Add transport native helper executables to .gitignore
git-http-fetch: not a builtin
Use an external program to implement fetching with curl
Add support for external programs for handling native fetches
These messages are nice for new users, but experienced git
users know how to manipulate the index, and these messages
waste a lot of screen real estate.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This message is designed to help new users understand what
has happened when refs fail to push. However, it does not
help experienced users at all, and significantly clutters
the output, frequently dwarfing the regular status table and
making it harder to see.
This patch introduces a general configuration mechanism for
optional messages, with this push message as the first
example.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This configuration option allows systematically rewriting fetch-only URLs
to push-capable URLs when used with push. For instance:
[url "ssh://example.org/"]
pushInsteadOf = "git://example.org/"
This will allow clones of "git://example.org/path/to/repo" to subsequently
push to "ssh://example.org/path/to/repo", without manually configuring
pushurl for that remote.
Includes documentation for the new option, bash completion updates, and
test cases (both that pushInsteadOf applies to push, that it does not
apply to fetch, and that it is ignored when pushURL is already defined).
Signed-off-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-pull.txt includes fetch-options.txt and merge-options.txt, both of
which document the --quiet and --verbose.
Supress the ones from fetch-options.txt.
Signed-off-by: Emmanuel Trillaud <etrillaud@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
All hooks are currently in its own section. Which may confuse users,
because the section name serves as the hook file name and sections are
all caps for man pages. Putting them into a new HOOKS section and each
hook into a subsection keeps the case to lower case.
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jc/mailinfo-scissors:
mailinfo.scissors: new configuration
am/mailinfo: Disable scissors processing by default
Documentation: describe the scissors mark support of "git am"
Teach mailinfo to ignore everything before -- >8 -- mark
builtin-mailinfo.c: fix confusing internal API to mailinfo()
* tr/reset-checkout-patch:
stash: simplify defaulting to "save" and reject unknown options
Make test case number unique
tests: disable interactive hunk selection tests if perl is not available
DWIM 'git stash save -p' for 'git stash -p'
Implement 'git stash save --patch'
Implement 'git checkout --patch'
Implement 'git reset --patch'
builtin-add: refactor the meat of interactive_add()
Add a small patch-mode testing library
git-apply--interactive: Refactor patch mode code
Make 'git stash -k' a short form for 'git stash save --keep-index'
The short format does not respect any of the usual status.*
configuration.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The status command recently grew "short" and "porcelain"
options for alternate output formats. Since status is no
longer "commit --dry-run", these formats are inaccessible to
people who do want to see a dry-run in a parseable form.
This patch makes those formats available to "git commit",
implying the "dry-run" option when they are used.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The "short" format was added to "git status" recently to
provide a less verbose way of looking at the same
information. This has two practical uses:
1. Users who want a more dense display of the information.
2. Scripts which want to parse the information and need a
stable, easy-to-parse interface.
For now, the "--short" format covers both of those uses.
However, as time goes on, users of (1) may want additional
format tweaks, or for "git status" to change its behavior
based on configuration variables. Those wishes will be at
odds with (2), which wants to stability for scripts.
This patch introduces a separate --porcelain option early to
avoid problems later on. Right now the --short and
--porcelain outputs are identical. However, as time goes on,
we will have the freedom to customize --short for human
consumption while keeping --porcelain stable.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
People who configured trailing-space depended on it to catch both extra
white space at the end of line, and extra blank lines at the end of file.
Earlier attempt to introduce only blank-at-eof gave them an escape hatch
to keep the old behaviour, but it is a regression until they explicitly
specify the new error class.
This introduces a blank-at-eol that only catches extra white space at the
end of line, and makes the traditional trailing-space a convenient synonym
to catch both blank-at-eol and blank-at-eof. This way, people who used
trailing-space continue to catch both classes of errors.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git apply" strips new blank lines at EOF under --whitespace=fix option,
but neigher --whitespace=warn nor --whitespace=error paid any attention to
these errors.
Introduce a new whitespace error class, blank-at-eof, to make the
whitespace error handling more consistent.
The patch adds a new "linenr" field to the struct fragment in order to
record which line the hunk started in the input file, but this is needed
solely for reporting purposes. The detection of this class of whitespace
errors cannot be done while parsing a patch like we do for all the other
classes of whitespace errors. It instead has to wait until we find where
to apply the hunk, but at that point, we do not have an access to the
original line number in the input file anymore, hence the new field.
Depending on your point of view, this may be a bugfix that makes warn and
error in line with fix. Or you could call it a new feature. The line
between them is somewhat fuzzy in this case.
Strictly speaking, triggering more errors than before is a change in
behaviour that is not backward compatible, even though the reason for the
change is because the code was not checking for an error that it should
have. People who do not want added blank lines at EOF to trigger an error
can disable the new error class.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint-1.6.3:
git-clone: add missing comma in --reference documentation
git-cvsserver: no longer use deprecated 'git-subcommand' commands
clone: disconnect transport after fetching
With the earlier DWIM patches, certain combination of options defaulted
to the "save" command correctly while certain equally valid combination
did not. For example, "git stash -k" were Ok but "git stash -q -k" did
not work.
This makes the logic of defaulting to "save" much simpler. If there are no
non-flag arguments, it is clear that there is no command word, and we
default to "save" subcommand. This rule prevents "git stash -q apply"
from quietly creating a stash with "apply" as the message.
This also teaches "git stash save" to reject an unknown option. This is
to keep a mistyped "git stash save --quite" from creating a stash with a
message "--quite", and this safety is more important with the new logic
to default to "save" with any option-looking argument without an explicit
comand word.
[jc: this is based on Matthieu's 3-patch series, and a follow-up
discussion, and he and Peff take all the credit; if I have introduced bugs
while reworking, they are mine.]
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git branch, checkout, clean, mv and tag all have an option -f to override
certain checks. This patch makes them accept the long option --force as
a synonym.
While we're at it, document that checkout support --quiet as synonym for
its short option -q.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A request to clone the repository does not give any "have" but asks for
all the refs we offer with "want". When a request does not ask to clone
the repository fully, but asks to fetch some refs into an empty
repository, it will not give any "have" but its "want" won't ask for all
the refs we offer.
If we suppose (and I would say this is a rather big if) that it makes
sense to distinguish these two cases, a hook cannot reliably do this
alone. The hook can detect lack of "have" and bunch of "want", but there
is no direct way to tell if the other end asked for all refs we offered,
or merely most of them.
Between the time we talked with the other end and the time the hook got
called, we may have acquired more refs or lost some refs in the repository
by concurrent operations. Given that we plan to introduce selective
advertisement of refs with a protocol extension, it would become even more
difficult for hooks to guess between these two cases.
This adds "kind [clone|fetch]" to hook's input, as a stable interface to
allow the hooks to tell these cases apart.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
After upload-pack successfully finishes its operation, post-upload-pack
hook can be called for logging purposes.
The hook is passed various pieces of information, one per line, from its
standard input. Currently the following items can be fed to the hook, but
more types of information may be added in the future:
want SHA-1::
40-byte hexadecimal object name the client asked to include in the
resulting pack. Can occur one or more times in the input.
have SHA-1::
40-byte hexadecimal object name the client asked to exclude from
the resulting pack, claiming to have them already. Can occur zero
or more times in the input.
time float::
Number of seconds spent for creating the packfile.
size decimal::
Size of the resulting packfile in bytes.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jc/shortstatus:
git commit --dry-run -v: show diff in color when asked
Documentation/git-commit.txt: describe --dry-run
wt-status: collect untracked files in a separate "collect" phase
Make git_status_config() file scope static to builtin-commit.c
wt-status: move wt_status_colors[] into wt_status structure
wt-status: move many global settings to wt_status structure
commit: --dry-run
status: show worktree status of conflicted paths separately
wt-status.c: rework the way changes to the index and work tree are summarized
diff-index: keep the original index intact
diff-index: report unmerged new entries
* maint:
Fix overridable written with an extra 'e'
Documentation: git-archive: mark --format as optional in summary
Round-down years in "years+months" relative date view
* maint-1.6.3:
Fix overridable written with an extra 'e'
Documentation: git-archive: mark --format as optional in summary
Round-down years in "years+months" relative date view
* maint-1.6.2:
Fix overridable written with an extra 'e'
Documentation: git-archive: mark --format as optional in summary
Round-down years in "years+months" relative date view
Conflicts:
Documentation/git-archive.txt
The --format option was made optional in 8ff21b1 (git-archive: make
tar the default format, 2007-04-09), but it was not marked as optional
in the summary. This trival patch just changes the summary to match
the rest of the documentation.
Signed-off-by: Wesley J. Landaker <wjl@icecavern.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jh/submodule-foreach:
git clone: Add --recursive to automatically checkout (nested) submodules
t7407: Use 'rev-parse --short' rather than bash's substring expansion notation
git submodule status: Add --recursive to recurse into nested submodules
git submodule update: Introduce --recursive to update nested submodules
git submodule foreach: Add --recursive to recurse into nested submodules
git submodule foreach: test access to submodule name as '$name'
Add selftest for 'git submodule foreach'
git submodule: Cleanup usage string and add option parsing to cmd_foreach()
git submodule foreach: Provide access to submodule name, as '$name'
Conflicts:
Documentation/git-submodule.txt
git-submodule.sh
Describe what a scissors mark looks like, and explain in what situation
it is often used.
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We currently point the HEAD of a newly cloned repo to the
same ref as the parent repo's HEAD. While a user can then
"git checkout -b foo origin/foo" whichever branch they
choose, it is more convenient and more efficient to tell
clone which branch you want in the first place.
Based on a patch by Kirill A. Korinskiy.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
git-log: allow --decorate[=short|full]
Minor improvement to the write-tree documentation
git-bisect: call the found commit "*the* first bad commit"
Commit de435ac0 changed the behavior of --decorate from printing the
full ref (e.g., "refs/heads/master") to a shorter, more human-readable
version (e.g., just "master"). While this is nice for human readers,
external tools using the output from "git log" may prefer the full
version.
This patch introduces an extension to --decorate to allow the caller to
specify either the short or the full versions.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Change the <name> placeholder to <tagname> in the SYNOPSIS section of
git-tag documentation, and describe it in the OPTIONS section in a way
similar to how documentation for git-branch does.
Add SEE ALSO section to list the other documentation pages these two pages
refer to.
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch introduces core.sparseCheckout, which will control whether
sparse checkout support is enabled in unpack_trees()
It also loads sparse-checkout file that will be used in the next patch.
I split it out so the next patch will be shorter, easier to read.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
With skip-worktree bit, you can manually set it to unwanted files,
then remove them: you would have the so-called sparse checkout. The
disadvantages are:
- Porcelain tools are not aware of this. Everytime you do an
operation that may update working directory, skip-worktree may be
cleared out. You have to set them again.
- You still have to remove skip-worktree'd files manually, which is
boring and ineffective.
These will be addressed in the following patches. This patch gives an
idea what is "sparse checkout" in Documentation/git-read-tree.txt.
This file is chosen instead of git-checkout.txt because it is quite
technical and user-unfriendly. I'd expect git-checkout.txt to have
something when Porcelain support is done.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This adds index as a prerequisite for directory listing (with
exclude). At the moment directory listing is used by "git clean",
"git add", "git ls-files" and "git status"/"git commit" and
unpack_trees()-related commands. These commands have been
checked/modified to populate index before doing directory listing.
add_excludes_from_file() does not enable this feature, because it
is used to read .git/info/exclude and some explicit files specified
by "git ls-files".
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Detail about this bit is in Documentation/git-update-index.txt.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Mongoose (http://code.google.com/p/mongoose/) is a lightweight web
server. It's just a single binary so it's a lot simpler to configure and
install.
Signed-off-by: Wilhansen Li <wil@nohakostudios.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In http://article.gmane.org/gmane.comp.version-control.git/109790 I
threatened to announce a change to the default threading style used by
send-email to no-chain-reply-to (i.e. the second and subsequent messages
will all be replies to the first one), unless nobody objected, in 1.6.3.
Nobody objected, as far as I can dig the list archive. But when nothing
happened in 1.6.3 nor 1.6.4, nobody from the camp who complained loudly
that led to the message did not complain either.
So I am guessing that after all nobody cares about this. But 1.7.0 is a
good time to change this, and as I said in the message, I personally think
it is a good change, so here it is.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This removes tentative "git stat" and make it take over "git status".
There are some tests that expect "git status" to exit with non-zero status
when there is something staged. Some tests expect "git status path..." to
show the status for a partial commit.
For these, replace "git status" with "git commit --dry-run". For the
ones that do not attempt a dry-run of a partial commit that check the
output from the command, check the output from "git status" as well, as
they should be identical.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* cc/replace:
t6050: check pushing something based on a replaced commit
Documentation: add documentation for "git replace"
Add git-replace to .gitignore
builtin-replace: use "usage_msg_opt" to give better error messages
parse-options: add new function "usage_msg_opt"
builtin-replace: teach "git replace" to actually replace
Add new "git replace" command
environment: add global variable to disable replacement
mktag: call "check_sha1_signature" with the replacement sha1
replace_object: add a test case
object: call "check_sha1_signature" with the replacement sha1
sha1_file: add a "read_sha1_file_repl" function
replace_object: add mechanism to replace objects found in "refs/replace/"
refs: add a "for_each_replace_ref" function
Many projects using submodules expect all submodules to be checked out
in order to build/work correctly. A common command sequence for
developers on such projects is:
git clone url/to/project
cd project
git submodule update --init (--recursive)
This patch introduces the --recursive option to git-clone. The new
option causes git-clone to recursively clone and checkout all
submodules of the cloned project. Hence, the above command sequence
can be reduced to:
git clone --recursive url/to/project
--recursive is ignored if no checkout is done by the git-clone.
The patch also includes documentation and a selftest.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In very large and hierarchically structured projects, one may encounter
nested submodules. In these situations, it is valuable to not only show
status for all the submodules in the current repo (which is what is
currently done by 'git submodule status'), but also to show status for
all submodules at all levels (i.e. recursing into nested submodules as
well).
This patch teaches the new --recursive option to the 'git submodule status'
command. The patch also includes documentation and selftests.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In very large and hierarchically structured projects, one may encounter
nested submodules. In these situations, it is valuable to not only update
the submodules in the current repo (which is what is currently done by
'git submodule update'), but also to operate on all submodules at all
levels (i.e. recursing into nested submodules as well).
This patch teaches the new --recursive option to the 'git submodule update'
command. The patch also includes documentation and selftests.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In very large and hierarchically structured projects, one may encounter
nested submodules. In these situations, it is valuable to not only operate
on all the submodules in the current repo (which is what is currently done
by 'git submodule foreach'), but also to operate on all submodules at all
levels (i.e. recursing into nested submodules as well).
This patch teaches the new --recursive option to the 'git submodule foreach'
command. The patch also includes documentation and selftests.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The note about interoperating in different timezones and such is about
localtime argument, not parent.
Signed-off-by: Tuomas Suutari <tuomas.suutari@gmail.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
* maint:
filter-branch: make the usage string fit on 80 chars terminals.
filter-branch: add an example how to add ACKs to a range of commits
docs: describe impact of repack on "clone -s"
Commit de435ac0 changed the behavior of --decorate from printing the
full ref (e.g., "refs/heads/master") to a shorter, more human-readable
version (e.g., just "master"). While this is nice for human readers,
external tools using the output from "git log" may prefer the full
version.
This patch introduces an extension to --decorate to allow the caller to
specify either the short or the full versions.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The argument to 'git submodule foreach' already has access to the variables
'$path' (the path to the submodule, relative to the superproject) and '$sha1'
(the submodule commit recorded by the superproject).
This patch adds another variable -- '$name' -- which contains the name of the
submodule, as recorded in the superproject's .gitmodules file.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When you have to add certain lines like ACKs (or for that matter,
Signed-off-by:s) to a range of commits starting with HEAD, you might
be tempted to use 'git rebase -i -10', but that is a waste of your
time.
It is better to use 'git filter-branch' with an appropriate message
filter, and this commit adds an example how to do so to
filter-branch's man page.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The effects of repacking on a repository with alternates are a bit
subtle. The two main things users will want are:
1. Not to waste disk space by accidentally copying objects which could
be shared.
2. Copying all objects explicitly to break the dependency on the source
repo.
This patch describes both under the "clone -s" documentation. It makes
sense to put it there rather than in git-repack.txt for both cases.
For (1), we are warning the user who is using "clone -s" about what _not_
to do, so we need to get their attention when reading about "clone -s".
For (2), we are telling them how git-repack can be used to accomplish a
task, but until they know that git-repack is the right tool, they have no
reason to look at the repack documentation.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This adds a hunk-based mode to git-stash. You can select hunks from
the difference between HEAD and worktree, and git-stash will build a
stash that reflects these changes. The index state of the stash is
the same as your current index, and we also let --patch imply
--keep-index.
Note that because the selected hunks are rolled back from the worktree
but not the index, the resulting state may appear somewhat confusing
if you had also staged these changes. This is not entirely
satisfactory, but due to the way stashes are applied, other solutions
would require a change to the stash format.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This introduces a --patch mode for git-checkout. In the index usage
git checkout --patch -- [files...]
it lets the user discard edits from the <files> at the granularity of
hunks (by selecting hunks from 'git diff' and then reverse applying
them to the worktree).
We also accept a revision argument. In the case
git checkout --patch HEAD -- [files...]
we offer hunks from the difference between HEAD and the worktree, and
reverse applies them to both index and worktree, allowing you to
discard staged changes completely. In the non-HEAD usage
git checkout --patch <revision> -- [files...]
it offers hunks from the difference between the worktree and
<revision>. The chosen hunks are then applied to both index and
worktree.
The application to worktree and index is done "atomically" in the
sense that we first check if the patch applies to the index (it should
always apply to the worktree). If it does not, we give the user a
choice to either abort or apply to the worktree anyway.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This introduces a --patch mode for git-reset. The basic case is
git reset --patch -- [files...]
which acts as the opposite of 'git add --patch -- [files...]': it
offers hunks for *un*staging. Advanced usage is
git reset --patch <revision> -- [files...]
which offers hunks from the diff between the index and <revision> for
forward application to the index. (That is, the basic case is just
<revision> = HEAD.)
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git submodule summary is providing similar functionality for submodules as
git diff-index does for a git project (including the meaning of --cached).
But the analogon to git diff-files is missing, so add a --files option to
summarize the differences between the index of the super project and the
last commit checked out in the working tree of the submodule.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
push: point to 'git pull' and 'git push --force' in case of non-fast forward
Documentation: add: <filepattern>... is optional
Change mentions of "git programs" to "git commands"
Documentation: merge: one <remote> is required
help.c: give correct structure's size to memset()
* maint-1.6.3:
Change mentions of "git programs" to "git commands"
Documentation: merge: one <remote> is required
help.c: give correct structure's size to memset()
'git push' failing because of non-fast forward is a very common situation,
and a beginner does not necessarily understand "fast forward" immediately.
Add a new section to the git-push documentation and refer them to it.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
<filepattern>... is optional (e.g. when the --all or --update
options are used) so use square brackets in the synopsis.
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Most of the docs and printouts refer to "commands" when discussing what
the end users call via the "git" top-level program. We should refer them
as "git programs" when we discuss the fact that the commands are
implemented as separate programs, but in other contexts, it is better to
use the term "git commands" consistently.
Signed-off-by: Ori Avtalion <ori@avtalion.name>
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
merge only requires one <remote>, so "<remote>..." should be used in the
synopsis (and not "<remote> <remote>...").
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* js/run-command-updates:
api-run-command.txt: describe error behavior of run_command functions
run-command.c: squelch a "use before assignment" warning
receive-pack: remove unnecessary run_status report
run_command: report failure to execute the program, but optionally don't
run_command: encode deadly signal number in the return value
run_command: report system call errors instead of returning error codes
run_command: return exit code as positive value
MinGW: simplify waitpid() emulation macros
Add an example to the stash documentation that shows how to quickly
find candidate commits among the 'git fsck --unreachable' output.
Unless you have merges of branch names containing WIP, or edit your
merge messages to say WIP, there will be no false positives.
Snippet written by Björn "doener" Steinbrink and me after zepolen_
asked on IRC.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This teaches --dry-run option to "git commit".
It is the same as "git status", but in the longer term we would want to
change the semantics of "git status" not to be the preview of commit, and
this is the first step for doing so.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When this option is given, the command does not verify the pack contents,
but shows the delta chain histogram. If used with --verbose, the usual
list of objects is also shown.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint: (95 commits)
verify-pack -v: do not report "chain length 0"
t5510: harden the way verify-pack is used
gitweb/README: Document $base_url
Documentation: git submodule: add missing options to synopsis
Better usage string for reflog.
hg-to-git: don't import the unused popen2 module
send-email: remove debug trace
config: Keep inner whitespace verbatim
GIT 1.6.4
GIT 1.6.3.4
config.txt: document add.ignore-errors
request-pull: allow ls-remote to notice remote.$nickname.uploadpack
Update the documentation of the raw diff output format
git-rerere.txt: Clarify ambiguity of the config variable
t9143: do not fail if Compress::Zlib is missing
Trivial path quoting fixes in git-instaweb
GIT 1.6.4-rc3
Documentation/config.txt: a variable can be defined on the section header line
git svn: make minimize URL more reliable over http(s)
Disable asciidoc 8.4.1+ semantics for `{plus}` and friends
...
Explain briefly what characters are prohibited in tag <name>
and point to git-check-ref-format(1) manual page for
further information.
Signed-off-by: Jari Aalto <jari.aalto@cante.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If one thinks of a revision as the set of commits which can be reached
from the rev, and of ^rev as the complement, then multiple arguments to
git rev-list can be neither understood as the intersection nor the union
of the individual sets.
But set language is the natural as well as logical language in which to
phrase this. So, add a paragraph which explains multiple arguments using
set language.
Suggested-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
I have 4GB of RAM on my system which should, in theory, be quite enough
to repack a 600 MB repository. However the unbounded delta cache size
always pushes it into swap, at which point everything virtually comes to
a halt. So unbounded caches are never a good idea.
A default of 256MB should be a good compromize between memory usage and
speed where medium sized repositories are still likely to fit in the
cache with a reasonable memory usage, and larger repositories are going
to take quite some time to repack already anyway.
While at it, clarify the associated config variable documentation
entries a bit.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* sb/parse-options:
prune-packed: migrate to parse-options
verify-pack: migrate to parse-options
verify-tag: migrate to parse-options
write-tree: migrate to parse-options
The option --merge was missing for submodule update and --cached for
submodule summary.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Introduce --ignore-whitespace option and corresponding config bool to
ignore whitespace differences while applying patches, akin to the
'patch' program.
'git am', 'git rebase' and the bash git completion are made aware of
this option.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
transport_get() can call transport_native_helper_init() to have list and
fetch-ref operations handled by running a separate program as:
git remote-<something> <remote> [<url>]
This program then accepts, on its stdin, "list" and "fetch <hex>
<name>" commands; the former prints out a list of available refs and
either their hashes or what they are symrefs to, while the latter
fetches them into the local object database and prints a newline when done.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently, the documentation suggests that 'git merge-base -a' and 'git
show-branch --merge-base' are equivalent (in fact it claims that the
former cannot handle more than two revs).
Alas, the handling of more than two revs is very different. Document
this by tests and correct the documentation to reflect this.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make sure that usage strings and documentation coincide with each other
and with the actual code.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
With extra fixes from Thadeu and Carlos as well.
Signed-off-by: André Goddard Rosa <andre.goddard@gmail.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
Signed-off-by: Carlos R. Mafra <crmafra2@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The current documentation states that servers typically listen on port
465 and calls this "ssmtp". While it's true that many mail servers use
port 465 for SSL smtp, this is non-standard, and hails from the days
before smtp and submission TLS support, that arrived in RFC2487 and
RFC3207. Port 465 is actually assigned by IANA for unrelated purposes,
and is mostly still used by mail servers today only to support Outlook
Express.
In any case, this patch helps the documentation better reflect both
standards and reality, while still helpfully mentioning ports numbers
that a user may wish to specify.
Signed-off-by: Wesley J. Landaker <wjl@icecavern.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The current documentation confuses non-standard SSL smtp port 465 with
submission port 587 (RFC 4406). This patch just changes the referenced
number.
Signed-off-by: Wesley J. Landaker <wjl@icecavern.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When using git fast-export and git fast-import to rewrite the history
of a repository with large binary files, almost all of the time is
spent dealing with blobs. This is extremely inefficient if all we want
to do is rewrite the commits and tree structure. --no-data skips the
output of blobs and writes SHA-1s instead of marks, which provides a
massive speedup.
Signed-off-by: Geoffrey Irving <irving@naml.us>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
To save me from the carpal tunnel syndrome, make 'git stash' accept
the short option '-k' instead of '--keep-index', and for even more
convenience, let's DWIM when this developer forgot to type the 'save'
command.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
By default, we remove leading [bracketed] [strings] from the Subject:
header when coming up with the summary of the patch. This is because
there are mailing lists etc that add their own headers to the subject, and
they know they can add things in brackets. The most obvious example is the
Linux kernel security list. Their emails look like
Subject: [Security] [patch] random: make get_random_int() more random
and other people mangle Subject: themselves in a similar way, e.g.:
Subject: [PATCH -rc] [BUGFIX] x86: fix kernel_trap_sp()
Subject: [BUGFIX][PATCH] fix bad page removal from LRU (Was Re: [RFC][PATCH] ..
even though "fix" is more than enough cue to mark it as a [BUGFIX].
Some projects however want to keep these bracketed strings. With this
option, we remove only [bracketed strings that contain word PATCH], so we
will turn things like these
[PATCH] [mailinfo] -b ...
[PATCH v2] [mailinfo] -b ...
[PATCH (v2) 1/4] [mailinfo] -b ...
into
[mailinfo] -b ...
This lacks tests and integration to the "git am" toolchain to be useful,
but it is a start.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When you have an embedded git work tree in your work tree (be it
an orphaned submodule, or an independent checkout of an unrelated
project), "git clean -d -f" blindly descended into it and removed
everything. This is rarely what the user wants.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The next major release will be 1.6.5, hopefully with a shorter cycle
than the 1.6.4 cycle. After that in 1.7.0 we can make potentially
backward incompatible changes if necessary.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use the description of "--ignore-errors" from git-add.txt as
inspiration.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This includes mentioning the initial hash output of diff-tree, and
changes the header to "raw output format" which is more descriptive.
Signed-off-by: David Kågedal <davidk@lysator.liu.se>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use the less ambiguous
"set variable foo in order to enable bar"
rather than
"set variable foo to enable bar" which may trick users into
assuming that "enable" is a good value for "foo".
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* en/fast-export:
fast-export: Document the fact that git-rev-list arguments are accepted
Add new fast-export testcases
fast-export: Add a --tag-of-filtered-object option for newly dangling tags
fast-export: Do parent rewriting to avoid dropping relevant commits
fast-export: Make sure we show actual ref names instead of "(null)"
fast-export: Omit tags that tag trees
fast-export: Set revs.topo_order before calling setup_revisions
* git://git.bogomips.org/git-svn:
git svn: make minimize URL more reliable over http(s)
git svn: avoid escaping '/' when renaming/copying files
t9142: stop httpd after the test
git svn: the branch command no longer needs the full path
git svn: revert default behavior for --minimize-url
git svn: add gc command
asciidoc 8.4.1 changed the semantics of inline backtick quoting so
that they disable parsing of inline constructs, i.e.,
Input: `{plus}`
Pre 8.4.1: +
Post 8.4.1: {plus}
Fix this by defining the asciidoc attribute 'no-inline-literal'
(which, per the 8.4.1 changelog, is the toggle to return to the old
behaviour) when under ASCIIDOC8.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This reverts the --minimize-url behavior change that
appeared recently in commit 0b2af457a4
("Fix branch detection when repository root is inaccessible").
However, we now allow the option to be turned off by allowing
"--no-minimize-url" so people with limited-access setups can
still take advantage of the fix in
0b2af457a4.
Also document the behavior and default settings of minimize-url
in the manpage for the first time.
This introduces a temporary UI regression to allow t9141 to pass
that will be reverted (fixed) in the next commit.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Add a git svn gc command that gzips all unhandled.log files, and
removes all index files under .git/svn.
Signed-off-by: Robert Allan Zeh <robert.a.zeh@gmail.com>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
When starting a new repository, I see my students often say
% git init newrepo
and curse git. They could say
% mkdir newrepo; cd newrepo; git init
but allowing it as an obvious short-cut may be nicer.
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* js/maint-graft-unhide-true-parents:
git repack: keep commits hidden by a graft
Add a test showing that 'git repack' throws away grafted-away parents
Conflicts:
git-repack.sh
When you have grafts that pretend that a given commit has different
parents than the ones recorded in the commit object, it is dangerous
to let 'git repack' remove those hidden parents, as you can easily
remove the graft and end up with a broken repository.
So let's play it safe and keep those parent objects and everything
that is reachable by them, in addition to the grafted parents.
As this behavior can only be triggered by git pack-objects, and as that
command handles duplicate parents gracefully, we do not bother to cull
duplicated parents that may result by using both true and grafted
parents.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This hopefully makes the relationship between threading options of
format-patch and send-email easier to grasp.
Signed-off-by: Yann Dirson <ydirson@altern.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Also mention deprecated aliases that do not appear in the send-email
manpage.
Signed-off-by: Yann Dirson <ydirson@altern.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It is useful to grep directories non-recursively, e.g. when one wants to
look for all files in the toplevel directory, but not in any subdirectory,
or in Documentation/, but not in Documentation/technical/.
This patch adds support for --max-depth <depth> option to git-grep. If it is
given, git-grep descends at most <depth> levels of directories below paths
specified on the command line.
Note that if path specified on command line contains wildcards, this option
makes no sense, e.g.
$ git grep -l --max-depth 0 GNU -- 'contrib/*'
(note the quotes) will search all files in contrib/, even in
subdirectories, because '*' matches all files.
Documentation updates, bash-completion and simple test cases are also
provided.
Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Also add missing --bare to init-db synopsis.
Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add long options for dry run and quiet to be more consistent with the
rest of git.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
OPT__VERBOSE introduces the long option (--verbose) in addition to the
already present short option (-v), so document this new addition.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* rs/grep-p:
grep: simplify -p output
grep -p: support user defined regular expressions
grep: add option -p/--show-function
grep: handle pre context lines on demand
grep: print context hunk marks between files
grep: move context hunk mark handling into show_line()
userdiff: add xdiff_clear_find_func()
- correctly link paragraphs within list items
- consistently format examples
- put option alernatives on separate lines
- always use [verse] for config items
- always indent 1st paragraph of a list item, with a tab
Signed-off-by: Yann Dirson <ydirson@altern.org>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Also consistently use single quotes around git commands to make things clear
(was only needed at a couple of places).
Signed-off-by: Yann Dirson <ydirson@altern.org>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Aliases that invoke shell commands start from the top-level directory,
but this was not documented.
Signed-off-by: Sitaram Chamarty <sitaramc@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* cc/bisect:
Documentation: remove warning saying that "git bisect skip" may slow bisection
bisect: use a PRNG with a bias when skipping away from untestable commits
* sb/quiet-porcelains:
stash: teach quiet option
am, rebase: teach quiet option
submodule, repack: migrate to git-sh-setup's say()
git-sh-setup: introduce say() for quiet options
am: suppress apply errors when using 3-way
t4150: test applying with a newline in subject
Respect the userdiff attributes and config settings when looking for
lines with function definitions in git grep -p.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The new option -p instructs git grep to print the previous function
definition as a context line, similar to diff -p. Such context lines
are marked with an equal sign instead of a dash. This option
complements the existing context options -A, -B, -C.
Function definitions are detected using the same heuristic that diff
uses. User defined regular expressions are not supported, yet.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
attr: plug minor memory leak
request-pull: really disable pager
Makes some cleanup/review in gittutorial
Makefile: git.o depends on library headers
git-submodule documentation: fix foreach example
There are some different but little cleanup changes to fix some missing
quotes, to fix what seemed to be an unended sentence, to reident a
little paragraph with too large a sentence and fix a branch name that
was referred to twice later by another name.
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Backtick and apostrophe are asciidoc markup, so they should be escaped
in order to get the expected result in the rendered manual page.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If --porcelain is used git-push will produce machine-readable output. The
output status line for each ref will be tab-separated and sent to stdout instead
of stderr. The full symbolic names of the refs will be given. For example
$ git push --dry-run --porcelain master :foobar 2>/dev/null \
| perl -pe 's/\t/ TAB /g'
= TAB refs/heads/master:refs/heads/master TAB [up to date]
- TAB :refs/heads/foobar TAB [deleted]
Signed-off-by: Larry D'Anna <larry@elder-gods.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Cleanup the documentation to explicitly state that --exclude-directory
is only meaningful when used with -u. Also make the documentation more
consistent with the usage message printed with read-tree --help-all.
The -m, --prefix, --reset options are performing similar actions
(setting some flags, read_cache_unmerged(), checking for illegal option
combinations). Instead of performing these actions when the options are
parsed, we delay performing them until after parse-opts has finished.
The bit fields in struct unpack_trees_options have been promoted to full
unsigned ints. This is necessary to avoid "foo ? 1 : 0" constructs to
set these fields.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When providing a list of paths to limit what is exported, the object that
a tag points to can be filtered out entirely. This new switch allows
the user to specify what should happen to the tag in such a case. The
default action, 'abort' will exit with an error message. With 'drop', the
tag will simply be omitted from the output. With 'rewrite', if the object
tagged was a commit, the tag will be modified to tag an alternate commit.
The alternate commit is determined by treating the original commit as the
"parent" of the tag and then using the parent rewriting algorithm of the
revision traversal machinery (related to the "--parents" option of "git
rev-list")
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add a command to unwind the effects of fetch by moving the rev_map
and refs/remotes/git-svn back to an old SVN revision. This allows
revisions to be re-fetched. Ideally SVN revs would be immutable,
but permissions changes in the SVN repository or indiscriminate use
of '--ignore-paths' can create situations where fetch cannot make
progress.
Signed-off-by: Ben Jackson <ben@ben.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
'git svn dcommit' takes an optional revision argument, but the meaning
of it was rather scary. It completely ignored the current state of
the HEAD, only looking at the revisions between SVN and $rev. If HEAD
was attached to $branch, the branch lost all commits $rev..$branch in
the process.
Considering that 'git svn dcommit HEAD^' has the intuitive meaning
"dcommit all changes on my branch except the last one", we change the
meaning of the revision argument. git-svn temporarily checks out $rev
for its work, meaning that
* if a branch is specified, that branch (_not_ the HEAD) is rebased as
part of the dcommit,
* if some other revision is specified, as in the example, all work
happens on a detached HEAD and no branch is affected.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Acked-by: Eric Wong <normalperson@yhbt.net>
Also make the docs more consistent with the usage message. While we're
here remove the zero initializers from the static variables as they're
unnecessary.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint-1.6.2:
git-show-ref.txt: remove word and make consistent
git-svn documentation: fix typo in 'rebase vs. pull/merge' section
use xstrdup, not strdup in ll-merge.c
* maint-1.6.1:
git-show-ref.txt: remove word and make consistent
git-svn documentation: fix typo in 'rebase vs. pull/merge' section
use xstrdup, not strdup in ll-merge.c
* maint-1.6.0:
git-show-ref.txt: remove word and make consistent
git-svn documentation: fix typo in 'rebase vs. pull/merge' section
use xstrdup, not strdup in ll-merge.c
Under is better than in because of the nested nature of the .git
directory.
"also using" sounds a little odd, plus we say combined with later on so
just use that.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* mg/pushurl:
avoid NULL dereference on failed malloc
builtin-remote: Make "remote -v" display push urls
builtin-remote: Show push urls as well
technical/api-remote: Describe new struct remote member pushurl
t5516: Check pushurl config setting
Allow push and fetch urls to be different
* sb/pull-rebase:
parse-remote: remove unused functions
parse-remote: support default reflist in get_remote_merge_branch
parse-remote: function to get the tracking branch to be merge
Teach stash pop, apply, save, and drop to be quiet when told. By using
the quiet option (-q), these actions will be silent unless errors are
encountered.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-am and git-rebase are talkative scripts. Teach them to be quiet when
told, allowing them to speak only when they fail or experience errors.
The quiet option is maintained when git-am or git-rebase fails to apply
a patch. This means subsequent --resolved, --continue, --skip, --abort
invocations will be quiet if the original invocation was quiet.
Drop a handful of >&2 redirection; the rest of the program sends all the
info messages to stdout, not to stderr.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add a configuration option, http.sslCertPasswordProtected, and associated
environment variable, GIT_SSL_CERT_PASSWORD_PROTECTED, to enable SSL client
certificate password prompt from within git. If this option is false and
if the environment variable does not exist, git falls back to OpenSSL's
prompts (as in earlier versions of git).
The environment variable may only be used to enable, not to disable
git's password prompt. This behavior mimics GIT_NO_VERIFY; the mere
existence of the variable is all that is checked.
Signed-off-by: Mark Lodato <lodatom@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Depending on how your CVS->GIT conversion went you will have some
unexpanded CVS keywords in your GIT repo. If any of your git commits
touch these lines then the patch application will fail. This patch
addresses that by adding an option that will revert and expanded CVS
keywords to files in the working CVS directory that are affected by
the commit being applied.
Signed-off-by: Alex Bennée <alex@bennee.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
For another patch series I'm working on I needed some tests
for the cc-cmd feature of git-send-email.
This patch adds 3 tests for the feature and for the possibility
to specify --suppress-cc multiple times, and fixes two bugs.
The first bug is that the --suppress-cc option for `cccmd' was
misspelled as `ccmd' in the code. The second bug, which is
actually found only with my other series, is that the argument
to the cccmd is never quoted, so the cccmd would fail with
patch file names containing a space.
A third bug I fix (in the docs) is that the bodycc argument was
actually spelled ccbody in the documentation and bash completion.
Signed-off-by: Paolo Bonzini <bonzini@gnu.org>
Cc: Markus Heidelberg <markus.heidelberg@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* mh/fix-send-email-threaded:
send-email: fix a typo in a comment
send-email: fix threaded mails without chain-reply-to
add a test for git-send-email for threaded mails without chain-reply-to
doc/send-email: clarify the behavior of --in-reply-to with --no-thread
send-email: fix non-threaded mails
add a test for git-send-email for non-threaded mails
Rewrite the gc section using unresolved and resolved instead of "not
recorded". Add plurals and missing articles. Make some sentences have
consistent tense. Try and be more active by removing "that" and
simplifying sentences.
The terms "hand-resolve" and "hand resolve" were used, so just use "hand
resolve" to be more consistent.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This warning was probably useless anyway, but it is even more so now
that filtering of skipped commits is done in C and that there is a
mechanism to skip away from broken commits.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* mh/maint-fix-send-email-threaded:
doc/send-email: clarify the behavior of --in-reply-to with --no-thread
send-email: fix non-threaded mails
add a test for git-send-email for non-threaded mails
Conflicts:
git-send-email.perl
t/t9001-send-email.sh
Also remove the argument from --[no-]chain-reply-to.
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The git-send-email docs do not mention except in the usage lines
the combined patch formatting/sending ability of git-send-email.
This patch expands on the possible arguments to git-send-email
and explains the meaning of the rev-list argument.
Signed-off-by: Paolo Bonzini <bonzini@gnu.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The current text makes some users feel uneasy, worrying whether
'-a' could lead to corrupt repositories. Clarify that '-a'
may lead to performance issues only for dumb protocols.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Helped-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This introduces a config setting remote.$remotename.pushurl which is
used for pushes only. If absent remote.$remotename.url is used for
pushes and fetches as before.
This is useful, for example, in order to do passwordless fetches
(remote update) over the git transport but pushes over ssh.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
'git stash pop' supports the '--index' option since its initial
implementation (bd56ff54, git-stash: add new 'pop' subcommand,
2008-02-22), but its documentation does not mention it explicitly.
Moreover, both the usage shown by 'git stash -h' and the synopsis
section in the man page imply that 'git stash pop' does not have an
'--index' option.
First, this patch corrects the usage and the synopsis section.
Second, the patch moves the description of the '--index' option to the
'git stash pop' section in the documentation, and refers to it from
the 'git stash apply' section. This way it follows the intentions of
commit d1836637 (Documentation: teach stash/pop workflow instead of
stash/apply, 2009-05-28), as all 'git stash pop'-related documentation
will be in one place without references to 'git stash apply'.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add references to the gitworkflows(7) manpage added in f948dd8
(Documentation: add manpage about workflows, 2008-10-19) to both
gittutorial(1) and git(1), so that new users might actually discover
and read it.
Noticed by Randal L. Schwartz.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
blame: correctly handle a path that used to be a directory
add -i: do not dump patch during application
Update draft release notes for 1.6.3.2
grep: fix colouring of matches with zero length
Documentation: teach stash/pop workflow instead of stash/apply
Change xdl_merge to generate output even for null merges
t6023: merge-file fails to output anything for a degenerate merge
'git submodule update --merge' merges the commit referenced by the
superproject into your local branch, instead of checking it out on
a detached HEAD.
As evidenced by the addition of "git submodule update --rebase", it
is useful to provide alternatives to the default 'checkout' behaviour
of "git submodule update". One such alternative is, when updating a
submodule to a new commit, to merge that commit into the current
local branch in that submodule. This is useful in workflows where
you want to update your submodule from its upstream, but you cannot
use --rebase, because you have downstream people working on top of
your submodule branch, and you don't want to disrupt their work.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The addition of "submodule.<name>.rebase" demonstrates the usefulness of
alternatives to the default behaviour of "git submodule update". However,
by naming the config variable "submodule.<name>.rebase", and making it a
boolean choice, we are artificially constraining future git versions that
may want to add _more_ alternatives than just "rebase".
Therefore, while "submodule.<name>.rebase" is not yet in a stable git
release, future-proof it, by changing it from
submodule.<name>.rebase = true/false
to
submodule.<name>.update = rebase/checkout
where "checkout" specifies the default behaviour of "git submodule update"
(checking out the new commit to a detached HEAD), and "rebase" specifies
the --rebase behaviour (where the current local branch in the submodule is
rebase onto the new commit). Thus .update == checkout is equivalent to
.rebase == false, and .update == rebase is equivalent to .rebase == true.
Finally, leaving .update unset is equivalent to leaving .rebase unset.
In future git versions, other alternatives to "git submodule update"
behaviour can be included by adding them to the list of allowable values
for the submodule.<name>.update variable.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Copy the description of date-order from rev-list-options.txt, and then
reword it to be commit specific. While we're at it, put <rev> <glob>...
on a new line to not exceed 80 characters.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jc/mktree:
mktree: validate entry type in input
mktree --batch: build more than one tree object
mktree --missing: updated usage message and man page
mktree --missing: allow missing objects
t1010: add mktree test
mktree: do not barf on a submodule commit
builtin-mktree.c: use a helper function to handle one line of input
mktree: use parse-options
build-in git-mktree
* mw/send-email:
send-email: Remove superfluous `my $editor = ...'
send-email: 'References:' should only reference what is sent
send-email: Handle "GIT:" rather than "GIT: " during --compose
Docs: send-email: --smtp-server-port can take symbolic ports
Docs: send-email: Refer to CONFIGURATION section for sendemail.multiedit
Docs: send-email: Put options back into alphabetical order
