Noticed-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Lars Schneider <larsxschneider@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The default behavior is well documented already in git-config(1), but
git-push(1) itself did not mention it at all. For users willing to learn
how "git push" works but not how to configure it, this makes the
documentation cumbersome to read.
Make the git-push(1) page self-contained by adding a short summary of
what 'push.default=simple' does, early in the page.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The usual pattern for an argv array is to initialize it,
push in some strings, and then clear it when done. Very
occasionally, though, we must do other exotic things with
the memory, like freeing the list but keeping the strings.
Let's provide a detach function so that callers can make use
of our API to build up the array, and then take ownership of
it.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The latter half of this sentence, the removal of the submodules, was
never done with (or without) double -f back when it was written, and
we still do not do so.
Signed-off-by: Matt McCutchen <matt@mattmccutchen.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since b7cc53e9 (tag.c: use 'ref-filter' APIs, 2015-07-11),
git-tag has started showing tags with ambiguous names (i.e.,
when both "heads/foo" and "tags/foo" exists) as "tags/foo"
instead of just "foo". This is both:
- pointless; the output of "git tag" includes only
refs/tags, so we know that "foo" means the one in
"refs/tags".
and
- ambiguous; in the original output, we know that the line
"foo" means that "refs/tags/foo" exists. In the new
output, it is unclear whether we mean "refs/tags/foo" or
"refs/tags/tags/foo".
The reason this happens is that commit b7cc53e9 switched
git-tag to use ref-filter's "%(refname:short)" output
formatting, which was adapted from for-each-ref. This more
general code does not know that we care only about tags, and
uses shorten_unambiguous_ref to get the short-name. We need
to tell it that we care only about "refs/tags/", and it
should shorten with respect to that value.
In theory, the ref-filter code could figure this out by us
passing FILTER_REFS_TAGS. But there are two complications
there:
1. The handling of refname:short is deep in formatting
code that does not even have our ref_filter struct, let
alone the arguments to the filter_ref struct.
2. In git v2.7.0, we expose the formatting language to the
user. If we follow this path, it will mean that
"%(refname:short)" behaves differently for "tag" versus
"for-each-ref" (including "for-each-ref refs/tags/"),
which can lead to confusion.
Instead, let's add a new modifier to the formatting
language, "strip", to remove a specific set of prefix
components. This fixes "git tag", and lets users invoke the
same behavior from their own custom formats (for "tag" or
"for-each-ref") while leaving ":short" with its same
consistent meaning in all places.
We introduce a test in t7004 for "git tag", which fails
without this patch. We also add a similar test in t3203 for
"git branch", which does not actually fail. But since it is
likely that "branch" will eventually use the same formatting
code, the test helps defend against future regressions.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The current update_linked_gitdir() has a bug that can create "gitdir"
file in non-multi-worktree setup. Worse, sometimes it can write relative
path to "gitdir" file, which will not work (e.g. "git worktree list"
will display the worktree's location incorrectly)
Instead of fixing this, we step back a bit. The original design was
probably not well thought out. For now, if the user manually moves a
worktree, they have to fix up "gitdir" file manually or the worktree
will get pruned.
Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The usage of working directory is inconsistent in the git add help.
Also http://git-scm.com/docs/git-clone speaks only about working tree.
Remaining entry found by "git grep -B1 '^directory' git-add.txt" really
relates to a directory.
Signed-off-by: Lars Vogel <Lars.Vogel@vogella.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The original wording sounded as if --depth could only be used to deepen or
shorten the history of existing repos. However, that is not the case. In a
workflow like
$ git init
$ git remote add origin https://github.com/git/git.git
$ git fetch --depth=1
The newly initialized repo is properly created as a shallow repo.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It is not wrong to talk about "revisions" here, but in this context
revisions are always commits, and that is how we already name it in the
git-fetch docs. So align the docs by always referring to "commits".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This reverts commit 57534ee77d. The
feature added in that commit requires that patterns behave the same way
from anywhere. But some patterns can behave differently depending on
current "working" directory. The conditions to catch and avoid these
patterns are too loose. The untracked listing[1] and sparse-checkout
selection[2] can become incorrect as a result.
[1] http://article.gmane.org/gmane.comp.version-control.git/283520
[2] http://article.gmane.org/gmane.comp.version-control.git/283532
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It is confusing to document how --depth behaves as part of the
--single-branch docs. Better move that part to the --depth docs, saying
that it implies --single-branch by default.
Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Modify various document (man page) files to explain
in more detail what --signoff means.
This was inspired by https://lwn.net/Articles/669976/ where
paulj noted, "adding [the] '-s' argument to [a] git commit
doesn't really mean you have even heard of the DCO...".
Extending git's documentation will make it easier to argue
that developers understood --signoff when they use it.
Signed-off-by: David A. Wheeler <dwheeler@dwheeler.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These were introduced back in 2006 at 3175aa1ec2 but
never documented.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Rework the section on gitweb to add information about the cgi script
and the instaweb command.
Signed-off-by: Stephen P. Smith <ischis2@cox.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There are several places in the documentation that
the term shallow clone is used. Defining the term
enables its use elsewhere with a known definition.
Signed-off-by: Stephen P. Smith <ischis2@cox.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In the section on "How to check out a different version of a
project" the "new" branch is used as a temporary branch. A detached
HEAD was not used since it was a new feature introduced just a
couple weeks prior.
The section could be changed to use and explain a detached HEAD,
except that would increase the learning curve early in the manual.
Detached HEADs are discussed a couple sections later under
"Examining an old version without creating a new branch".
Let's declare that it is a bad idea to rewrite the example that
uses a temporary branch to do the sightseeing on a detached HEAD.
Signed-off-by: Stephen P. Smith <ischis2@cox.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Oftentimes, patches created by git format-patch will be stored in
version control or compared with diff. In these cases, two otherwise
identical patches can have different commit hashes, leading to diff
noise. Teach git format-patch a --zero-commit option that instead
produces an all-zero hash to avoid this diff noise.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This back-merges hopefully the last batch of trivially correct fixes
to the 2.6.x maintenance track from the master branch.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Split index related options should appear in the 'SYNOPSIS'
section.
These options are already documented in the 'OPTIONS' section.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A changelist that contains only excluded files due to a client spec was
imported as an empty commit. Fix that issue by ignoring these commits.
Add option "git-p4.keepEmptyCommits" to make the previous behavior
available.
Signed-off-by: Lars Schneider <larsxschneider@gmail.com>
Helped-by: Pete Harlan
Acked-by: Luke Diamand <luke@diamand.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The git-submodule(1) is inconsistent. In the synopsis, it says:
git submodule [--quiet] sync [--recursive] [--] [<path>...]
The description of the sync does not mention --recursive, and the
description of --recursive says that it is only available for foreach,
update and status.
The option was introduced (82f49f294c, Teach --recursive to submodule
sync, 2012-10-26) a while ago, so let's document it, too.
Reported-by: Per Cederqvist <cederp@opera.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
By default git check-ignore shows only the filenames that will be
ignored, not the pattern that causes their exclusion. Instead of moving
the partial exclude pattern precendence information to the -v option
where it belongs, link to gitignore(5) which describes this more
thoroughly.
Signed-off-by: Dennis Kaarsemaker <dennis@kaarsemaker.net>
Signed-off-by: Jeff King <peff@peff.net>
Untracked cache related options should appear in the synopsis.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Jeff King <peff@peff.net>
The --recurse-submodules command line parameter has existed for some
time but it has no config file equivalent.
Following the style of the corresponding parameter for git fetch, let's
invent push.recurseSubmodules to provide a default for this
parameter. This also requires the addition of --recurse-submodules=no to
allow the configuration to be overridden on the command line when
required.
The most straightforward way to implement this appears to be to make
push use code in submodule-config in a similar way to fetch.
Signed-off-by: Mike Crowe <mac@mcrowe.com>
Signed-off-by: Jeff King <peff@peff.net>
Introduce new option "credentialCache.ignoreSIGHUP" which stops
git-credential-cache--daemon from quitting on SIGHUP. This is useful
when "git push" is started from Emacs, because all child
processes (including the daemon) will receive a SIGHUP when "git push"
exits.
Signed-off-by: Noam Postavsky <npostavs@users.sourceforge.net>
Signed-off-by: Jeff King <peff@peff.net>
Add an option "--dump-aliases" which changes the default behavior of
git-send-email. This mode will simply read the alias files configured by
sendemail.aliasesfile and sendemail.aliasfiletype and dump a list of all
configured aliases, one per line. The intended use case for this option
is the bash-completion script which will use it to autocomplete aliases
on the options which take addresses.
Add some tests for the new option using various alias file formats.
A possible future extension to the alias dump format could be done by
extending the --dump-aliases to take an optional argument defining the
format to display. This has not been done in this patch as no user of
this information has been identified.
Signed-off-by: Jacob Keller <jacob.keller@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
Lars Schneider