Граф коммитов

1081 Коммитов

Автор SHA1 Сообщение Дата
Junio C Hamano 5e519fb8b0 Sync with v1.9.5
* maint-1.9:
  Git 1.9.5
  Git 1.8.5.6
  fsck: complain about NTFS ".git" aliases in trees
  read-cache: optionally disallow NTFS .git variants
  path: add is_ntfs_dotgit() helper
  fsck: complain about HFS+ ".git" aliases in trees
  read-cache: optionally disallow HFS+ .git variants
  utf8: add is_hfs_dotgit() helper
  fsck: notice .git case-insensitively
  t1450: refactor ".", "..", and ".git" fsck tests
  verify_dotfile(): reject .git case-insensitively
  read-tree: add tests for confusing paths like ".." and ".git"
  unpack-trees: propagate errors adding entries to the index
2014-12-17 11:28:54 -08:00
Junio C Hamano 6898b79721 Sync with v1.8.5.6
* maint-1.8.5:
  Git 1.8.5.6
  fsck: complain about NTFS ".git" aliases in trees
  read-cache: optionally disallow NTFS .git variants
  path: add is_ntfs_dotgit() helper
  fsck: complain about HFS+ ".git" aliases in trees
  read-cache: optionally disallow HFS+ .git variants
  utf8: add is_hfs_dotgit() helper
  fsck: notice .git case-insensitively
  t1450: refactor ".", "..", and ".git" fsck tests
  verify_dotfile(): reject .git case-insensitively
  read-tree: add tests for confusing paths like ".." and ".git"
  unpack-trees: propagate errors adding entries to the index
2014-12-17 11:20:31 -08:00
Johannes Schindelin 2b4c6efc82 read-cache: optionally disallow NTFS .git variants
The point of disallowing ".git" in the index is that we
would never want to accidentally overwrite files in the
repository directory. But this means we need to respect the
filesystem's idea of when two paths are equal. The prior
commit added a helper to make such a comparison for NTFS
and FAT32; let's use it in verify_path().

We make this check optional for two reasons:

  1. It restricts the set of allowable filenames, which is
     unnecessary for people who are not on NTFS nor FAT32.
     In practice this probably doesn't matter, though, as
     the restricted names are rather obscure and almost
     certainly would never come up in practice.

  2. It has a minor performance penalty for every path we
     insert into the index.

This patch ties the check to the core.protectNTFS config
option. Though this is expected to be most useful on Windows,
we allow it to be set everywhere, as NTFS may be mounted on
other platforms. The variable does default to on for Windows,
though.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-17 11:04:45 -08:00
Jeff King a42643aa8d read-cache: optionally disallow HFS+ .git variants
The point of disallowing ".git" in the index is that we
would never want to accidentally overwrite files in the
repository directory. But this means we need to respect the
filesystem's idea of when two paths are equal. The prior
commit added a helper to make such a comparison for HFS+;
let's use it in verify_path.

We make this check optional for two reasons:

  1. It restricts the set of allowable filenames, which is
     unnecessary for people who are not on HFS+. In practice
     this probably doesn't matter, though, as the restricted
     names are rather obscure and almost certainly would
     never come up in practice.

  2. It has a minor performance penalty for every path we
     insert into the index.

This patch ties the check to the core.protectHFS config
option. Though this is expected to be most useful on OS X,
we allow it to be set everywhere, as HFS+ may be mounted on
other platforms. The variable does default to on for OS X,
though.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-17 11:04:44 -08:00
Luis Henriques ac1596a684 send-email: add --[no-]xmailer option
Add --[no-]xmailer that allows a user to disable adding the 'X-Mailer:'
header to the email being sent.

Signed-off-by: Luis Henriques <henrix@camandro.org>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-15 15:17:25 -08:00
Philip Oakley 1be976eeb4 doc: core.ignoreStat clarify the --assume-unchanged effect
The assume-unchanged bit can be misunderstood. Be assertive about
the expectation that file changes should update that flag.

Signed-off-by: Philip Oakley <philipoakley@iee.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-12 15:23:08 -08:00
Junio C Hamano e886efdb34 Merge branch 'jk/colors-fix'
* jk/colors-fix:
  t4026: test "normal" color
  config: fix parsing of "git config --get-color some.key -1"
  docs: describe ANSI 256-color mode
2014-12-12 14:31:39 -08:00
Nguyễn Thái Ngọc Duy e3df33bb1b gc: support prune --worktrees
Helped-by: Marc Branchaud <marcnarc@xiplink.com>
Signed-off-by: Marc Branchaud <marcnarc@xiplink.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-01 11:00:18 -08:00
Nguyễn Thái Ngọc Duy 31e26ebcb5 setup.c: support multi-checkout repo setup
The repo setup procedure is updated to detect $GIT_DIR/commondir and
set $GIT_COMMON_DIR properly.

The core.worktree is ignored when $GIT_COMMON_DIR is set. This is
because the config file is shared in multi-checkout setup, but
checkout directories _are_ different. Making core.worktree effective
in all checkouts mean it's back to a single checkout.

Helped-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-01 11:00:15 -08:00
Johannes Schindelin 1404bcbb6b receive-pack: add another option for receive.denyCurrentBranch
When synchronizing between working directories, it can be handy to update
the current branch via 'push' rather than 'pull', e.g. when pushing a fix
from inside a VM, or when pushing a fix made on a user's machine (where
the developer is not at liberty to install an ssh daemon let alone know
the user's password).

The common workaround – pushing into a temporary branch and then merging
on the other machine – is no longer necessary with this patch.

The new option is:

'updateInstead':
	Update the working tree accordingly, but refuse to do so if there
	are any uncommitted changes.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-30 17:15:13 -08:00
Paolo Bonzini 8d81408435 git-send-email: add --transfer-encoding option
The thread at http://thread.gmane.org/gmane.comp.version-control.git/257392
details problems when applying patches with "git am" in a repository with
CRLF line endings.  In the example in the thread, the repository originated
from "git-svn" so it is not possible to use core.eol and friends on it.

Right now, the best option is to use "git am --keep-cr".  However, when
a patch create new files, the patch application process will reject the
new file because it finds a "/dev/null\r" string instead of "/dev/null".

The problem is that SMTP transport is CRLF-unsafe.  Sending a patch by
email is the same as passing it through "dos2unix | unix2dos".  The newly
introduced CRLFs are normally transparent because git-am strips them. The
keepcr=true setting preserves them, but it is mostly working by chance
and it would be very problematic to have a "git am" workflow in a
repository with mixed LF and CRLF line endings.

The MIME solution to this is the quoted-printable transfer enconding.
This is not something that we want to enable by default, since it makes
received emails horrible to look at.  However, it is a very good match
for projects that store CRLF line endings in the repository.

The only disadvantage of quoted-printable is that quoted-printable
patches fail to apply if the maintainer uses "git am --keep-cr".  This
is because the decoded patch will have two carriage returns at the end
of the line.  Therefore, add support for base64 transfer encoding too,
which makes received emails downright impossible to look at outside
a MUA, but really just works.

The patch covers all bases, including users that still live in the late
80s, by also providing a 7bit content transfer encoding that refuses
to send emails with non-ASCII character in them.  And finally, "8bit"
will add a Content-Transfer-Encoding header but otherwise do nothing.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-25 14:00:15 -08:00
Jeff King ff40d185d2 parse_color: recognize "no$foo" to clear the $foo attribute
You can turn on ANSI text attributes like "reverse" by
putting "reverse" in your color spec. However, you cannot
ask to turn reverse off.

For common cases, this does not matter. You would turn on
"reverse" at the start of a colored section, and then clear
all attributes with a "reset". However, you may wish to turn
on some attributes, then selectively disable others. For
example:

  git log --format="%C(bold ul yellow)%h%C(noul) %s"

underlines just the hash, but without the need to re-specify
the rest of the attributes. This can also help third-party
programs, like contrib/diff-highlight, that want to turn
some attribute on/off without disrupting existing coloring.

Note that some attribute specifications are probably
nonsensical (e.g., "bold nobold"). We do not bother to flag
such constructs, and instead let the terminal sort it out.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-20 12:42:55 -08:00
Jeff King 17a4be2606 parse_color: support 24-bit RGB values
Some terminals (like XTerm) allow full 24-bit RGB color
specifications using an extension to the regular ANSI color
scheme. Let's allow users to specify hex RGB colors,
enabling the all-important feature of hot pink ref
decorations:

  git log --format="%h%C(#ff69b4)%d%C(reset) %s"

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-20 12:42:49 -08:00
Jeff King 0edad17d67 docs: describe ANSI 256-color mode
Our color specifications have supported the 256-color ANSI
extension for years, but we never documented it.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-20 10:13:25 -08:00
Junio C Hamano a4c4708fe6 Sync with maint
* maint:
  Documentation/config.txt: fix minor typo
  config.txt: fix typo
2014-11-10 11:26:18 -08:00
Thomas Quinot a79c3a1b81 Documentation/config.txt: fix minor typo
Add a missing article at the beginning of a sentence, and rephrase
slightly.

Signed-off-by: Thomas Quinot <thomas@quinot.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-10 11:25:26 -08:00
Nicolas Dermine 71069cdfc7 config.txt: fix typo
Signed-off-by: Nicolas Dermine <nicolas.dermine@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-10 10:06:25 -08:00
Thomas Ackermann f745acb028 Documentation: typofixes
In addition to fixing trivial and obvious typos, be careful about
the following points:

 - Spell ASCII, URL and CRC in ALL CAPS;
 - Spell Linux as Capitalized;
 - Do not omit periods in "i.e." and "e.g.".

Signed-off-by: Thomas Ackermann <th.acker@arcor.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-04 13:14:44 -08:00
Junio C Hamano bf1f639ea2 Merge branch 'rs/grep-color-words'
Allow painting or not painting (partial) matches in context lines
when showing "grep -C<num>" output in color.

* rs/grep-color-words:
  grep: add color.grep.matchcontext and color.grep.matchselected
2014-10-31 11:49:47 -07:00
Junio C Hamano e82935d917 Merge branch 'rb/pack-window-memory-config-doc'
* rb/pack-window-memory-config-doc:
  config.txt: pack.windowmemory limit applies per-thread
2014-10-29 10:09:31 -07:00
René Scharfe 79a77109d3 grep: add color.grep.matchcontext and color.grep.matchselected
The config option color.grep.match can be used to specify the highlighting
color for matching strings.  Add the options matchContext and matchSelected
to allow different colors to be specified for matching strings in the
context vs. in selected lines.  This is similar to the ms and mc specifiers
in GNU grep's environment variable GREP_COLORS.

Tests are from Zoltan Klinger's earlier attempt to solve the same
issue in a different way.

Signed-off-by: Rene Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-28 10:33:50 -07:00
Robert de Bath f4694a8c08 config.txt: pack.windowmemory limit applies per-thread
It took me a long time to notice the rider on the pack.threads
configuration option that it would multiple the memory consumption
by the number of CPUs in the machine.  Clarify that the limit
applies per-thread.

Signed-off-by: Robert de Bath <rdebath@tvisiontech.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-28 09:59:41 -07:00
Junio C Hamano 7fc311d5ff Merge branch 'tb/core-filemode-doc'
Doc update.

* tb/core-filemode-doc:
  core.filemode may need manual action
2014-10-24 14:57:57 -07:00
Junio C Hamano 48f662dd74 Merge branch 'da/mergetool-meld'
Newer versions of 'meld' breaks the auto-detection we use to see if
they are new enough to support the `--output` option.

* da/mergetool-meld:
  mergetools/meld: make usage of `--output` configurable and more robust
2014-10-21 13:28:48 -07:00
Junio C Hamano a46af5946c Merge branch 'da/mergetool-temporary-directory'
Allow a temporary directory specified to be used while running "git
mergetool" backend.

* da/mergetool-temporary-directory:
  t7610-mergetool: add test cases for mergetool.writeToTemp
  mergetool: add an option for writing to a temporary directory
2014-10-21 13:28:42 -07:00
Torsten Bögershausen ecdab41267 core.filemode may need manual action
core.filemode is set automatically when a repo is created.
But when a repo is exported via CIFS or cygwin is mixed with Git for Windows
or Eclipse core.filemode may better be set manually to false.
Update and improve the documentation

Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-19 20:47:40 -07:00
David Aguilar 8f0cb41da2 mergetool: add an option for writing to a temporary directory
Teach mergetool to write files in a temporary directory when
'mergetool.writeToTemp' is true.

This is helpful for tools such as Eclipse which cannot cope with
multiple copies of the same file in the worktree.

Suggested-by: Charles Bailey <charles@hashpling.org>
Signed-off-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-16 12:09:51 -07:00
David Aguilar b12d04503b mergetools/meld: make usage of `--output` configurable and more robust
Older versions of meld listed --output in `meld --help`.
Newer versions only mention `meld [OPTIONS...]`.
Improve the checks to catch these newer versions.

Add a `mergetool.meld.hasOutput` configuration to allow
overriding the heuristic.

Reported-by: Andrey Novoseltsev <novoselt@gmail.com>
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-16 11:58:11 -07:00
Junio C Hamano fb06b5280e Merge branch 'jc/push-cert'
Allow "git push" request to be signed, so that it can be verified and
audited, using the GPG signature of the person who pushed, that the
tips of branches at a public repository really point the commits
the pusher wanted to, without having to "trust" the server.

* jc/push-cert: (24 commits)
  receive-pack::hmac_sha1(): copy the entire SHA-1 hash out
  signed push: allow stale nonce in stateless mode
  signed push: teach smart-HTTP to pass "git push --signed" around
  signed push: fortify against replay attacks
  signed push: add "pushee" header to push certificate
  signed push: remove duplicated protocol info
  send-pack: send feature request on push-cert packet
  receive-pack: GPG-validate push certificates
  push: the beginning of "git push --signed"
  pack-protocol doc: typofix for PKT-LINE
  gpg-interface: move parse_signature() to where it should be
  gpg-interface: move parse_gpg_output() to where it should be
  send-pack: clarify that cmds_sent is a boolean
  send-pack: refactor inspecting and resetting status and sending commands
  send-pack: rename "new_refs" to "need_pack_data"
  receive-pack: factor out capability string generation
  send-pack: factor out capability string generation
  send-pack: always send capabilities
  send-pack: refactor decision to send update per ref
  send-pack: move REF_STATUS_REJECT_NODELETE logic a bit higher
  ...
2014-10-08 13:05:25 -07:00
Junio C Hamano 5732373daa signed push: allow stale nonce in stateless mode
When operating with the stateless RPC mode, we will receive a nonce
issued by another instance of us that advertised our capability and
refs some time ago.  Update the logic to check received nonce to
detect this case, compute how much time has passed since the nonce
was issued and report the status with a new environment variable
GIT_PUSH_CERT_NONCE_SLOP to the hooks.

GIT_PUSH_CERT_NONCE_STATUS will report "SLOP" in such a case.  The
hooks are free to decide how large a slop it is willing to accept.

Strictly speaking, the "nonce" is not really a "nonce" anymore in
the stateless RPC mode, as it will happily take any "nonce" issued
by it (which is protected by HMAC and its secret key) as long as it
is fresh enough.  The degree of this security degradation, relative
to the native protocol, is about the same as the "we make sure that
the 'git push' decided to update our refs with new objects based on
the freshest observation of our refs by making sure the values they
claim the original value of the refs they ask us to update exactly
match the current state" security is loosened to accomodate the
stateless RPC mode in the existing code without this series, so
there is no need for those who are already using smart HTTP to push
to their repositories to be alarmed any more than they already are.

In addition, the server operator can set receive.certnonceslop
configuration variable to specify how stale a nonce can be (in
seconds).  When this variable is set, and if the nonce received in
the certificate that passes the HMAC check was less than that many
seconds old, hooks are given "OK" in GIT_PUSH_CERT_NONCE_STATUS
(instead of "SLOP") and the received nonce value is given in
GIT_PUSH_CERT_NONCE, which makes it easier for a simple-minded
hook to check if the certificate we received is recent enough.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-17 15:19:54 -07:00
Junio C Hamano b89363e4a5 signed push: fortify against replay attacks
In order to prevent a valid push certificate for pushing into an
repository from getting replayed in a different push operation, send
a nonce string from the receive-pack process and have the signer
include it in the push certificate.  The receiving end uses an HMAC
hash of the path to the repository it serves and the current time
stamp, hashed with a secret seed (the secret seed does not have to
be per-repository but can be defined in /etc/gitconfig) to generate
the nonce, in order to ensure that a random third party cannot forge
a nonce that looks like it originated from it.

The original nonce is exported as GIT_PUSH_CERT_NONCE for the hooks
to examine and match against the value on the "nonce" header in the
certificate to notice a replay, but returned "nonce" header in the
push certificate is examined by receive-pack and the result is
exported as GIT_PUSH_CERT_NONCE_STATUS, whose value would be "OK"
if the nonce recorded in the certificate matches what we expect, so
that the hooks can more easily check.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-17 14:27:40 -07:00
Junio C Hamano a85b377d04 push: the beginning of "git push --signed"
While signed tags and commits assert that the objects thusly signed
came from you, who signed these objects, there is not a good way to
assert that you wanted to have a particular object at the tip of a
particular branch.  My signing v2.0.1 tag only means I want to call
the version v2.0.1, and it does not mean I want to push it out to my
'master' branch---it is likely that I only want it in 'maint', so
the signature on the object alone is insufficient.

The only assurance to you that 'maint' points at what I wanted to
place there comes from your trust on the hosting site and my
authentication with it, which cannot easily audited later.

Introduce a mechanism that allows you to sign a "push certificate"
(for the lack of better name) every time you push, asserting that
what object you are pushing to update which ref that used to point
at what other object.  Think of it as a cryptographic protection for
ref updates, similar to signed tags/commits but working on an
orthogonal axis.

The basic flow based on this mechanism goes like this:

 1. You push out your work with "git push --signed".

 2. The sending side learns where the remote refs are as usual,
    together with what protocol extension the receiving end
    supports.  If the receiving end does not advertise the protocol
    extension "push-cert", an attempt to "git push --signed" fails.

    Otherwise, a text file, that looks like the following, is
    prepared in core:

	certificate version 0.1
	pusher Junio C Hamano <gitster@pobox.com> 1315427886 -0700

	7339ca65... 21580ecb... refs/heads/master
	3793ac56... 12850bec... refs/heads/next

    The file begins with a few header lines, which may grow as we
    gain more experience.  The 'pusher' header records the name of
    the signer (the value of user.signingkey configuration variable,
    falling back to GIT_COMMITTER_{NAME|EMAIL}) and the time of the
    certificate generation.  After the header, a blank line follows,
    followed by a copy of the protocol message lines.

    Each line shows the old and the new object name at the tip of
    the ref this push tries to update, in the way identical to how
    the underlying "git push" protocol exchange tells the ref
    updates to the receiving end (by recording the "old" object
    name, the push certificate also protects against replaying).  It
    is expected that new command packet types other than the
    old-new-refname kind will be included in push certificate in the
    same way as would appear in the plain vanilla command packets in
    unsigned pushes.

    The user then is asked to sign this push certificate using GPG,
    formatted in a way similar to how signed tag objects are signed,
    and the result is sent to the other side (i.e. receive-pack).

    In the protocol exchange, this step comes immediately before the
    sender tells what the result of the push should be, which in
    turn comes before it sends the pack data.

 3. When the receiving end sees a push certificate, the certificate
    is written out as a blob.  The pre-receive hook can learn about
    the certificate by checking GIT_PUSH_CERT environment variable,
    which, if present, tells the object name of this blob, and make
    the decision to allow or reject this push.  Additionally, the
    post-receive hook can also look at the certificate, which may be
    a good place to log all the received certificates for later
    audits.

Because a push certificate carry the same information as the usual
command packets in the protocol exchange, we can omit the latter
when a push certificate is in use and reduce the protocol overhead.
This however is not included in this patch to make it easier to
review (in other words, the series at this step should never be
released without the remainder of the series, as it implements an
interim protocol that will be incompatible with the final one).
As such, the documentation update for the protocol is left out of
this step.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-15 13:23:20 -07:00
Nguyễn Thái Ngọc Duy 6bf3b81348 diff --stat: mark any file larger than core.bigfilethreshold binary
Too large files may lead to failure to allocate memory. If it happens
here, it could impact quite a few commands that involve
diff. Moreover, too large files are inefficient to compare anyway (and
most likely non-text), so mark them binary and skip looking at their
content.

Noticed-by: Dale R. Worley <worley@alum.mit.edu>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-08-18 10:16:45 -07:00
Junio C Hamano c3d2bc720c Merge branch 'jk/tag-sort'
* jk/tag-sort:
  tag: support configuring --sort via .gitconfig
  tag: fix --sort tests to use cat<<-\EOF format
2014-07-23 11:35:45 -07:00
Jacob Keller b150794daf tag: support configuring --sort via .gitconfig
Add support for configuring default sort ordering for git tags. Command
line option will override this configured value, using the exact same
syntax.

Cc: Jeff King <peff@peff.net>
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-17 09:22:20 -07:00
Junio C Hamano 25f3119000 Merge branch 'jk/repack-pack-writebitmaps-config'
* jk/repack-pack-writebitmaps-config:
  t7700: drop explicit --no-pack-kept-objects from .keep test
  repack: introduce repack.writeBitmaps config option
  repack: simplify handling of --write-bitmap-index
  pack-objects: stop respecting pack.writebitmaps
2014-06-25 12:23:19 -07:00
Junio C Hamano 287a8701f6 Merge branch 'jl/status-added-submodule-is-never-ignored' into maint
"git status" (and "git commit") behaved as if changes in a modified
submodule are not there if submodule.*.ignore configuration is set,
which was misleading.  The configuration is only to unclutter diff
output during the course of development, and should not to hide
changes in the "status" output to cause the users forget to commit
them.

* jl/status-added-submodule-is-never-ignored:
  commit -m: commit staged submodules regardless of ignore config
  status/commit: show staged submodules regardless of ignore config
2014-06-25 11:50:03 -07:00
Junio C Hamano 96b29bde91 Merge branch 'sh/enable-preloadindex'
* sh/enable-preloadindex:
  environment.c: enable core.preloadindex by default
2014-06-16 12:18:49 -07:00
Junio C Hamano f18871dcd4 Merge branch 'jm/format-patch-mail-sig'
* jm/format-patch-mail-sig:
  format-patch: add "--signature-file=<file>" option
  format-patch: make newline after signature conditional
2014-06-16 12:18:38 -07:00
Junio C Hamano 6d681f0a3e Merge branch 'jl/status-added-submodule-is-never-ignored'
submodule.*.ignore and diff.ignoresubmodules are used to ignore all
submodule changes in "diff" output, but it can be confusing to
apply these configuration values to status and commit.

This is a backward-incompatible change, but should be so in a good
way (aka bugfix).

* jl/status-added-submodule-is-never-ignored:
  commit -m: commit staged submodules regardless of ignore config
  status/commit: show staged submodules regardless of ignore config
2014-06-16 10:07:19 -07:00
Jeff King 71d76cb480 repack: introduce repack.writeBitmaps config option
We currently have pack.writeBitmaps, which originally
operated at the pack-objects level. This should really have
been a repack.* option from day one. Let's give it the more
sensible name, but keep the old version as a deprecated
synonym.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-10 14:05:19 -07:00
Junio C Hamano ed47bbd1d0 Merge branch 'jj/command-line-adjective'
* jj/command-line-adjective:
  Documentation: use "command-line" when used as a compound adjective, and fix other minor grammatical issues
2014-06-06 11:38:48 -07:00
Junio C Hamano 1e2600dd6a Merge branch 'nd/status-auto-comment-char'
* nd/status-auto-comment-char:
  commit: allow core.commentChar=auto for character auto selection
  config: be strict on core.commentChar
2014-06-06 11:36:10 -07:00
Junio C Hamano d2a274aa87 Merge branch 'dk/raise-core-deltabasecachelimit'
The `core.deltabasecachelimit` used to default to 16 MiB , but this
proved to be too small, and has been bumped to 96 MiB.

* dk/raise-core-deltabasecachelimit:
  Bump core.deltaBaseCacheLimit to 96m
2014-06-06 11:18:34 -07:00
Junio C Hamano 561d952ed4 Merge branch 'mm/pager-less-sans-S'
Since the very beginning of Git, we gave the LESS environment a
default value "FRSX" when we spawn "less" as the pager.  "S" (chop
long lines instead of wrapping) has been removed from this default
set of options, because it is more or less a personal taste thing,
as opposed to others that have good justifications (i.e. "R" is very
much justified because many kinds of output we produce are colored
and "FX" is justified because output we produce is often shorter
than a page).

Existing users who prefer not to see line-wrapped output may want to
set

  $ git config core.pager "less -S"

to restore the traditional behaviour.  It is expected that people
find output from the most subcommands easier to read with the new
default, except for "blame" which tends to produce really long
lines.  To override the new default only for "git blame", you can do
this:

  $ git config pager.blame "less -S"

* mm/pager-less-sans-S:
  pager: remove 'S' from $LESS by default
2014-06-06 11:02:59 -07:00
Steve Hoelzer 299e29870b environment.c: enable core.preloadindex by default
Many people are on filesystems with horrible stat latency (not
limited to Windows but also NFS), which core.preloadindex was
designed to help.  We discussed enabling it by default early in 2013
but didn't.

Per

  http://thread.gmane.org/gmane.comp.version-control.git/219273/focus=219322

let's enable the setting by default, with the original choice of max
20 threads / min 500 paths per thread parameters.

Signed-off-by: Steve Hoelzer <shoelzer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-03 10:06:53 -07:00
Jeremiah Mahler 7022650f61 format-patch: add "--signature-file=<file>" option
Add an option to format-patch for reading a signature from a file.

  $ git format-patch -1 --signature-file=$HOME/.signature

The config variable `format.signaturefile` can also be used to make
this the default.

  $ git config format.signaturefile $HOME/.signature

  $ git format-patch -1

Signed-off-by: Jeremiah Mahler <jmmahler@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-27 12:38:32 -07:00
Jason St. John 06ab60c066 Documentation: use "command-line" when used as a compound adjective, and fix other minor grammatical issues
Signed-off-by: Jason St. John <jstjohn@purdue.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-21 13:57:10 -07:00
Nguyễn Thái Ngọc Duy 84c9dc2c5a commit: allow core.commentChar=auto for character auto selection
When core.commentChar is "auto", the comment char starts with '#' as
in default but if it's already in the prepared message, find another
char in a small subset. This should stop surprises because git strips
some lines unexpectedly.

Note that git is not smart enough to recognize '#' as the comment char
in custom templates and convert it if the final comment char is
different. It thinks '#' lines in custom templates as part of the
commit message. So don't use this with custom templates.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-19 13:37:25 -07:00
Matthieu Moy b3275838d9 pager: remove 'S' from $LESS by default
By default, Git used to set $LESS to -FRSX if $LESS was not set by
the user. The FRX flags actually make sense for Git (F and X because
sometimes the output Git pipes to less is short, and R because Git
pipes colored output). The S flag (chop long lines), on the other
hand, is not related to Git and is a matter of user preference. Git
should not decide for the user to change LESS's default.

More specifically, the S flag harms users who review untrusted code
within a pager, since a patch looking like:

    -old code;
    +new good code; [... lots of tabs ...] malicious code;

would appear identical to:

    -old code;
    +new good code;

Users who prefer the old behavior can still set the $LESS environment
variable to -FRSX explicitly, or set core.pager to 'less -S'.

The documentation in config.txt is made a bit longer to keep both an
example setting the 'S' flag (needed to recover the old behavior)
and an example showing how to unset a flag set by Git.

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-07 13:41:04 -07:00
David Kastrup 4874f544f1 Bump core.deltaBaseCacheLimit to 96m
The default of 16m causes serious thrashing for large delta chains
combined with large files.

Here are some benchmarks (pu variant of git blame):

time git blame -C src/xdisp.c >/dev/null

for a repository of Emacs repacked with git gc --aggressive (v1.9,
resulting in a window size of 250) located on an SSD drive.  The file in
question has about 30000 lines, 1Mb of size, and a history with about
2500 commits.

    16m (previous default):
    real	3m33.936s
    user	2m15.396s
    sys	1m17.352s

    32m:
    real	3m1.319s
    user	2m8.660s
    sys	0m51.904s

    64m:
    real	2m20.636s
    user	1m55.780s
    sys	0m23.964s

    96m:
    real	2m5.668s
    user	1m50.784s
    sys	0m14.288s

    128m:
    real	2m4.337s
    user	1m50.764s
    sys	0m12.832s

    192m:
    real	2m3.567s
    user	1m49.508s
    sys	0m13.312s

Signed-off-by: David Kastrup <dak@gnu.org>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-06 15:32:21 -07:00
Max Kirillov ec9fa62a10 Documentation: git-gui: describe gui.displayuntracked
Signed-off-by: Max Kirillov <max@max630.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-21 10:33:20 -07:00
Junio C Hamano d59c12d7ad Merge branch 'jl/nor-or-nand-and'
Eradicate mistaken use of "nor" (that is, essentially "nor" used
not in "neither A nor B" ;-)) from in-code comments, command output
strings, and documentations.

* jl/nor-or-nand-and:
  code and test: fix misuses of "nor"
  comments: fix misuses of "nor"
  contrib: fix misuses of "nor"
  Documentation: fix misuses of "nor"
2014-04-08 12:00:28 -07:00
Jens Lehmann 1d2f393ac9 status/commit: show staged submodules regardless of ignore config
Currently setting submodule.<name>.ignore and/or diff.ignoreSubmodules to
"all" suppresses all output of submodule changes for the diff family,
status and commit. For status and commit this is really confusing, as it
even when the user chooses to record a new commit for an ignored submodule
by adding it manually this change won't show up under the to-be-committed
changes. To add insult to injury, a later "git commit" will error out with
"nothing to commit" when only ignored submodules are staged.

Fix that by making wt_status always print staged submodule changes, no
matter what ignore settings are configured. The only exception is when the
user explicitly uses the "--ignore-submodules=all" command line option, in
that case the submodule output is still suppressed. This also makes "git
commit" work again when only modifications of ignored submodules are
staged, as that command uses the "commitable" member of the wt_status
struct to determine if staged changes are present. But this only happens
when the commit command uses the wt_status* functions to produce status
output for human consumption (when forking an editor or with --dry-run),
in all other cases (e.g. when run in a script with '-m') another code path
is taken which uses index_differs_from() to determine if any changes are
staged which still ignores submodules according to their configuration.
This will be fixed in a follow-up commit.

Change t7508 to reflect this new behavior and add three new tests to show
that a single staged submodule configured to be ignored will be committed
when the status output is generated and won't be if not. Also update the
documentation of the ignore config options accordingly.

Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-07 10:32:20 -07:00
Junio C Hamano 8815d8aa7c Merge branch 'nd/gc-aggressive'
Allow tweaking the maximum length of the delta-chain produced by
"gc --aggressive".

* nd/gc-aggressive:
  environment.c: fix constness for odb_pack_keep()
  gc --aggressive: make --depth configurable
2014-04-03 12:38:47 -07:00
Junio C Hamano 76bc28a3bb Merge branch 'ca/doc-config-third-party'
* ca/doc-config-third-party:
  config.txt: third-party tools may and do use their own variables
2014-03-31 16:30:49 -07:00
Justin Lebar a58088abe2 Documentation: fix misuses of "nor"
Signed-off-by: Justin Lebar <jlebar@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-31 15:16:22 -07:00
Nguyễn Thái Ngọc Duy 125f81461d gc --aggressive: make --depth configurable
When 1c192f3 (gc --aggressive: make it really aggressive - 2007-12-06)
made --depth=250 the default value, it didn't really explain the
reason behind, especially the pros and cons of --depth=250.

An old mail from Linus below explains it at length. Long story short,
--depth=250 is a disk saver and a performance killer. Not everybody
agrees on that aggressiveness. Let the user configure it.

    From: Linus Torvalds <torvalds@linux-foundation.org>
    Subject: Re: [PATCH] gc --aggressive: make it really aggressive
    Date: Thu, 6 Dec 2007 08:19:24 -0800 (PST)
    Message-ID: <alpine.LFD.0.9999.0712060803430.13796@woody.linux-foundation.org>
    Gmane-URL: http://article.gmane.org/gmane.comp.gcc.devel/94637

    On Thu, 6 Dec 2007, Harvey Harrison wrote:
    >
    > 7:41:25elapsed 86%CPU

    Heh. And this is why you want to do it exactly *once*, and then just
    export the end result for others ;)

    > -r--r--r-- 1 hharrison hharrison 324094684 2007-12-06 07:26 pack-1d46...pack

    But yeah, especially if you allow longer delta chains, the end result can
    be much smaller (and what makes the one-time repack more expensive is the
    window size, not the delta chain - you could make the delta chains longer
    with no cost overhead at packing time)

    HOWEVER.

    The longer delta chains do make it potentially much more expensive to then
    use old history. So there's a trade-off. And quite frankly, a delta depth
    of 250 is likely going to cause overflows in the delta cache (which is
    only 256 entries in size *and* it's a hash, so it's going to start having
    hash conflicts long before hitting the 250 depth limit).

    So when I said "--depth=250 --window=250", I chose those numbers more as
    an example of extremely aggressive packing, and I'm not at all sure that
    the end result is necessarily wonderfully usable. It's going to save disk
    space (and network bandwidth - the delta's will be re-used for the network
    protocol too!), but there are definitely downsides too, and using long
    delta chains may simply not be worth it in practice.

    (And some of it might just want to have git tuning, ie if people think
    that long deltas are worth it, we could easily just expand on the delta
    hash, at the cost of some more memory used!)

    That said, the good news is that working with *new* history will not be
    affected negatively, and if you want to be _really_ sneaky, there are ways
    to say "create a pack that contains the history up to a version one year
    ago, and be very aggressive about those old versions that we still want to
    have around, but do a separate pack for newer stuff using less aggressive
    parameters"

    So this is something that can be tweaked, although we don't really have
    any really nice interfaces for stuff like that (ie the git delta cache
    size is hardcoded in the sources and cannot be set in the config file, and
    the "pack old history more aggressively" involves some manual scripting
    and knowing how "git pack-objects" works rather than any nice simple
    command line switch).

    So the thing to take away from this is:
     - git is certainly flexible as hell
     - .. but to get the full power you may need to tweak things
     - .. happily you really only need to have one person to do the tweaking,
       and the tweaked end results will be available to others that do not
       need to know/care.

    And whether the difference between 320MB and 500MB is worth any really
    involved tweaking (considering the potential downsides), I really don't
    know. Only testing will tell.

			    Linus

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-31 10:26:24 -07:00
Chris Angelico 93728b23ad config.txt: third-party tools may and do use their own variables
Signed-off-by: Chris Angelico <rosuav@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-21 11:55:07 -07:00
Junio C Hamano 249d54b231 Merge branch 'jk/repack-pack-keep-objects'
* jk/repack-pack-keep-objects:
  repack: add `repack.packKeptObjects` config var
2014-03-18 13:50:29 -07:00
Junio C Hamano e8cb4996ad Merge branch 'sr/add--interactive-term-readkey'
* sr/add--interactive-term-readkey:
  git-add--interactive: warn if module for interactive.singlekey is missing
  git-config: document interactive.singlekey requires Term::ReadKey
2014-03-14 14:27:21 -07:00
Junio C Hamano d552f8df1b Merge branch 'sg/archive-restrict-remote'
Allow loosening remote "git archive" invocation security check that
refuses to serve tree-ish not at the tip of any ref.

* sg/archive-restrict-remote:
  add uploadarchive.allowUnreachable option
  docs: clarify remote restrictions for git-upload-archive
2014-03-14 14:27:03 -07:00
Junio C Hamano 13b49f1e74 Merge branch 'tg/index-v4-format'
* tg/index-v4-format:
  read-cache: add index.version config variable
  test-lib: allow setting the index format version
  introduce GIT_INDEX_VERSION environment variable
2014-03-14 14:26:50 -07:00
Junio C Hamano 009055f3ec Merge branch 'jc/push-2.0-default-to-simple'
Finally update the "git push" default behaviour to "simple".
2014-03-07 15:13:15 -08:00
Junio C Hamano 4c4ac4db2c Merge branch 'nd/daemonize-gc'
Allow running "gc --auto" in the background.

* nd/daemonize-gc:
  gc: config option for running --auto in background
  daemon: move daemonize() to libgit.a
2014-03-05 15:06:39 -08:00
Simon Ruderich 8358f1acd5 git-config: document interactive.singlekey requires Term::ReadKey
Most distributions don't require Term::ReadKey as dependency, leaving
the user to wonder why the setting doesn't work.

Signed-off-by: Simon Ruderich <simon@ruderich.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-03 14:10:55 -08:00
Jeff King ee34a2bead repack: add `repack.packKeptObjects` config var
The git-repack command always passes `--honor-pack-keep`
to pack-objects. This has traditionally been a good thing,
as we do not want to duplicate those objects in a new pack,
and we are not going to delete the old pack.

However, when bitmaps are in use, it is important for a full
repack to include all reachable objects, even if they may be
duplicated in a .keep pack. Otherwise, we cannot generate
the bitmaps, as the on-disk format requires the set of
objects in the pack to be fully closed.

Even if the repository does not generally have .keep files,
a simultaneous push could cause a race condition in which a
.keep file exists at the moment of a repack. The repack may
try to include those objects in one of two situations:

  1. The pushed .keep pack contains objects that were
     already in the repository (e.g., blobs due to a revert of
     an old commit).

  2. Receive-pack updates the refs, making the objects
     reachable, but before it removes the .keep file, the
     repack runs.

In either case, we may prefer to duplicate some objects in
the new, full pack, and let the next repack (after the .keep
file is cleaned up) take care of removing them.

This patch introduces both a command-line and config option
to disable the `--honor-pack-keep` option.  By default, it
is triggered when pack.writeBitmaps (or `--write-bitmap-index`
is turned on), but specifying it explicitly can override the
behavior (e.g., in cases where you prefer .keep files to
bitmaps, but only when they are present).

Note that this option just disables the pack-objects
behavior. We still leave packs with a .keep in place, as we
do not necessarily know that we have duplicated all of their
objects.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-03 12:21:49 -08:00
Scott J. Goldman 7671b63211 add uploadarchive.allowUnreachable option
In commit ee27ca4, we started restricting remote git-archive
invocations to only accessing reachable commits. This
matches what upload-pack allows, but does restrict some
useful cases (e.g., HEAD:foo). We loosened this in 0f544ee,
which allows `foo:bar` as long as `foo` is a ref tip.
However, that still doesn't allow many useful things, like:

  1. Commits accessible from a ref, like `foo^:bar`, which
     are reachable

  2. Arbitrary sha1s, even if they are reachable.

We can do a full object-reachability check for these cases,
but it can be quite expensive if the client has sent us the
sha1 of a tree; we have to visit every sub-tree of every
commit in the worst case.

Let's instead give site admins an escape hatch, in case they
prefer the more liberal behavior.  For many sites, the full
object database is public anyway (e.g., if you allow dumb
walker access), or the site admin may simply decide the
security/convenience tradeoff is not worth it.

This patch adds a new config option to disable the
restrictions added in ee27ca4. It defaults to off, meaning
there is no change in behavior by default.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-28 09:55:37 -08:00
Junio C Hamano 0f9e62e084 Merge branch 'jk/pack-bitmap'
Borrow the bitmap index into packfiles from JGit to speed up
enumeration of objects involved in a commit range without having to
fully traverse the history.

* jk/pack-bitmap: (26 commits)
  ewah: unconditionally ntohll ewah data
  ewah: support platforms that require aligned reads
  read-cache: use get_be32 instead of hand-rolled ntoh_l
  block-sha1: factor out get_be and put_be wrappers
  do not discard revindex when re-preparing packfiles
  pack-bitmap: implement optional name_hash cache
  t/perf: add tests for pack bitmaps
  t: add basic bitmap functionality tests
  count-objects: recognize .bitmap in garbage-checking
  repack: consider bitmaps when performing repacks
  repack: handle optional files created by pack-objects
  repack: turn exts array into array-of-struct
  repack: stop using magic number for ARRAY_SIZE(exts)
  pack-objects: implement bitmap writing
  rev-list: add bitmap mode to speed up object lists
  pack-objects: use bitmaps when packing objects
  pack-objects: split add_object_entry
  pack-bitmap: add support for bitmap indexes
  documentation: add documentation for the bitmap format
  ewah: compressed bitmap implementation
  ...
2014-02-27 14:01:48 -08:00
Junio C Hamano 7da5fd6895 Merge branch 'da/pull-ff-configuration'
"git pull" learned to pay attention to pull.ff configuration
variable.

* da/pull-ff-configuration:
  pull: add --ff-only to the help text
  pull: add pull.ff configuration
2014-02-27 14:01:11 -08:00
Junio C Hamano 810273bc33 Merge branch 'nv/commit-gpgsign-config'
Introduce commit.gpgsign configuration variable to force every
commit to be GPG signed.  The variable cannot be overriden from the
command line of some of the commands that create commits except for
"git commit" and "git commit-tree", but I am not convinced that it
is a good idea to sprinkle support for --no-gpg-sign everywhere,
which in turn means that this configuration variable may not be
such a good idea.

* nv/commit-gpgsign-config:
  test the commit.gpgsign config option
  commit-tree: add and document --no-gpg-sign
  commit-tree: add the commit.gpgsign option to sign all commits
2014-02-27 14:01:03 -08:00
Nicolas Vigier d95bfb12b8 commit-tree: add the commit.gpgsign option to sign all commits
If you want to GPG sign all your commits, you have to add the -S option
all the time. The commit.gpgsign config option allows to sign all
commits automatically.

Signed-off-by: Nicolas Vigier <boklm@mars-attacks.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-24 14:50:56 -08:00
Thomas Gummerer 3c09d6845d read-cache: add index.version config variable
Add a config variable that allows setting the default index version when
initializing a new index file.  Similar to the GIT_INDEX_VERSION
environment variable this only affects new index files.

Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-24 13:33:17 -08:00
Nguyễn Thái Ngọc Duy 9f673f9477 gc: config option for running --auto in background
`gc --auto` takes time and can block the user temporarily (but not any
less annoyingly). Make it run in background on systems that support
it. The only thing lost with running in background is printouts. But
gc output is not really interesting. You can keep it in foreground by
changing gc.autodetach.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-10 10:46:37 -08:00
Junio C Hamano 92251b1b5b Merge branch 'nd/shallow-clone'
Fetching from a shallow-cloned repository used to be forbidden,
primarily because the codepaths involved were not carefully vetted
and we did not bother supporting such usage. This attempts to allow
object transfer out of a shallow-cloned repository in a controlled
way (i.e. the receiver become a shallow repository with truncated
history).

* nd/shallow-clone: (31 commits)
  t5537: fix incorrect expectation in test case 10
  shallow: remove unused code
  send-pack.c: mark a file-local function static
  git-clone.txt: remove shallow clone limitations
  prune: clean .git/shallow after pruning objects
  clone: use git protocol for cloning shallow repo locally
  send-pack: support pushing from a shallow clone via http
  receive-pack: support pushing to a shallow clone via http
  smart-http: support shallow fetch/clone
  remote-curl: pass ref SHA-1 to fetch-pack as well
  send-pack: support pushing to a shallow clone
  receive-pack: allow pushes that update .git/shallow
  connected.c: add new variant that runs with --shallow-file
  add GIT_SHALLOW_FILE to propagate --shallow-file to subprocesses
  receive/send-pack: support pushing from a shallow clone
  receive-pack: reorder some code in unpack()
  fetch: add --update-shallow to accept refs that update .git/shallow
  upload-pack: make sure deepening preserves shallow roots
  fetch: support fetching from a shallow repository
  clone: support remote shallow repository
  ...
2014-01-17 12:21:20 -08:00
David Aguilar b814da891e pull: add pull.ff configuration
Add a `pull.ff` configuration option that is analogous
to the `merge.ff` option.

This allows us to control the fast-forward behavior for
pull-initiated merges only.

Signed-off-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-15 16:01:06 -08:00
Junio C Hamano 9fac0777e1 Merge branch 'jn/pager-lv-default-env'
Just like we give a reasonable default for "less" via the LESS
environment variable, specify a reasonable default for "lv" via the
"LV" environment variable when spawning the pager.

* jn/pager-lv-default-env:
  pager: set LV=-c alongside LESS=FRSX
2014-01-13 11:33:35 -08:00
Jonathan Nieder e54c1f2d25 pager: set LV=-c alongside LESS=FRSX
On systems with lv configured as the preferred pager (i.e.,
DEFAULT_PAGER=lv at build time, or PAGER=lv exported in the
environment) git commands that use color show control codes instead of
color in the pager:

	$ git diff
	^[[1mdiff --git a/.mailfilter b/.mailfilter^[[m
	^[[1mindex aa4f0b2..17e113e 100644^[[m
	^[[1m--- a/.mailfilter^[[m
	^[[1m+++ b/.mailfilter^[[m
	^[[36m@@ -1,11 +1,58 @@^[[m

"less" avoids this problem because git uses the LESS environment
variable to pass the -R option ('output ANSI color escapes in raw
form') by default.  Use the LV environment variable to pass 'lv' the
-c option ('allow ANSI escape sequences for text decoration / color')
to fix it for lv, too.

Noticed when the default value for color.ui flipped to 'auto' in
v1.8.4-rc0~36^2~1 (2013-06-10).

Reported-by: Olaf Meeuwissen <olaf.meeuwissen@avasys.jp>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-07 09:23:41 -08:00
Vicent Marti ae4f07fbcc pack-bitmap: implement optional name_hash cache
When we use pack bitmaps rather than walking the object
graph, we end up with the list of objects to include in the
packfile, but we do not know the path at which any tree or
blob objects would be found.

In a recently packed repository, this is fine. A fetch would
use the paths only as a heuristic in the delta compression
phase, and a fully packed repository should not need to do
much delta compression.

As time passes, though, we may acquire more objects on top
of our large bitmapped pack. If clients fetch frequently,
then they never even look at the bitmapped history, and all
works as usual. However, a client who has not fetched since
the last bitmap repack will have "have" tips in the
bitmapped history, but "want" newer objects.

The bitmaps themselves degrade gracefully in this
circumstance. We manually walk the more recent bits of
history, and then use bitmaps when we hit them.

But we would also like to perform delta compression between
the newer objects and the bitmapped objects (both to delta
against what we know the user already has, but also between
"new" and "old" objects that the user is fetching). The lack
of pathnames makes our delta heuristics much less effective.

This patch adds an optional cache of the 32-bit name_hash
values to the end of the bitmap file. If present, a reader
can use it to match bitmapped and non-bitmapped names during
delta compression.

Here are perf results for p5310:

Test                      origin/master       HEAD^                      HEAD
-------------------------------------------------------------------------------------------------
5310.2: repack to disk    36.81(37.82+1.43)   47.70(48.74+1.41) +29.6%   47.75(48.70+1.51) +29.7%
5310.3: simulated clone   30.78(29.70+2.14)   1.08(0.97+0.10) -96.5%     1.07(0.94+0.12) -96.5%
5310.4: simulated fetch   3.16(6.10+0.08)     3.54(10.65+0.06) +12.0%    1.70(3.07+0.06) -46.2%
5310.6: partial bitmap    36.76(43.19+1.81)   6.71(11.25+0.76) -81.7%    4.08(6.26+0.46) -88.9%

You can see that the time spent on an incremental fetch goes
down, as our delta heuristics are able to do their work.
And we save time on the partial bitmap clone for the same
reason.

Signed-off-by: Vicent Marti <tanoku@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-30 12:19:23 -08:00
Vicent Marti 7cc8f97108 pack-objects: implement bitmap writing
This commit extends more the functionality of `pack-objects` by allowing
it to write out a `.bitmap` index next to any written packs, together
with the `.idx` index that currently gets written.

If bitmap writing is enabled for a given repository (either by calling
`pack-objects` with the `--write-bitmap-index` flag or by having
`pack.writebitmaps` set to `true` in the config) and pack-objects is
writing a packfile that would normally be indexed (i.e. not piping to
stdout), we will attempt to write the corresponding bitmap index for the
packfile.

Bitmap index writing happens after the packfile and its index has been
successfully written to disk (`finish_tmp_packfile`). The process is
performed in several steps:

    1. `bitmap_writer_set_checksum`: this call stores the partial
       checksum for the packfile being written; the checksum will be
       written in the resulting bitmap index to verify its integrity

    2. `bitmap_writer_build_type_index`: this call uses the array of
       `struct object_entry` that has just been sorted when writing out
       the actual packfile index to disk to generate 4 type-index bitmaps
       (one for each object type).

       These bitmaps have their nth bit set if the given object is of
       the bitmap's type. E.g. the nth bit of the Commits bitmap will be
       1 if the nth object in the packfile index is a commit.

       This is a very cheap operation because the bitmap writing code has
       access to the metadata stored in the `struct object_entry` array,
       and hence the real type for each object in the packfile.

    3. `bitmap_writer_reuse_bitmaps`: if there exists an existing bitmap
       index for one of the packfiles we're trying to repack, this call
       will efficiently rebuild the existing bitmaps so they can be
       reused on the new index. All the existing bitmaps will be stored
       in a `reuse` hash table, and the commit selection phase will
       prioritize these when selecting, as they can be written directly
       to the new index without having to perform a revision walk to
       fill the bitmap. This can greatly speed up the repack of a
       repository that already has bitmaps.

    4. `bitmap_writer_select_commits`: if bitmap writing is enabled for
       a given `pack-objects` run, the sequence of commits generated
       during the Counting Objects phase will be stored in an array.

       We then use that array to build up the list of selected commits.
       Writing a bitmap in the index for each object in the repository
       would be cost-prohibitive, so we use a simple heuristic to pick
       the commits that will be indexed with bitmaps.

       The current heuristics are a simplified version of JGit's
       original implementation. We select a higher density of commits
       depending on their age: the 100 most recent commits are always
       selected, after that we pick 1 commit of each 100, and the gap
       increases as the commits grow older. On top of that, we make sure
       that every single branch that has not been merged (all the tips
       that would be required from a clone) gets their own bitmap, and
       when selecting commits between a gap, we tend to prioritize the
       commit with the most parents.

       Do note that there is no right/wrong way to perform commit
       selection; different selection algorithms will result in
       different commits being selected, but there's no such thing as
       "missing a commit". The bitmap walker algorithm implemented in
       `prepare_bitmap_walk` is able to adapt to missing bitmaps by
       performing manual walks that complete the bitmap: the ideal
       selection algorithm, however, would select the commits that are
       more likely to be used as roots for a walk in the future (e.g.
       the tips of each branch, and so on) to ensure a bitmap for them
       is always available.

    5. `bitmap_writer_build`: this is the computationally expensive part
       of bitmap generation. Based on the list of commits that were
       selected in the previous step, we perform several incremental
       walks to generate the bitmap for each commit.

       The walks begin from the oldest commit, and are built up
       incrementally for each branch. E.g. consider this dag where A, B,
       C, D, E, F are the selected commits, and a, b, c, e are a chunk
       of simplified history that will not receive bitmaps.

            A---a---B--b--C--c--D
                     \
                      E--e--F

       We start by building the bitmap for A, using A as the root for a
       revision walk and marking all the objects that are reachable
       until the walk is over. Once this bitmap is stored, we reuse the
       bitmap walker to perform the walk for B, assuming that once we
       reach A again, the walk will be terminated because A has already
       been SEEN on the previous walk.

       This process is repeated for C, and D, but when we try to
       generate the bitmaps for E, we can reuse neither the current walk
       nor the bitmap we have generated so far.

       What we do now is resetting both the walk and clearing the
       bitmap, and performing the walk from scratch using E as the
       origin. This new walk, however, does not need to be completed.
       Once we hit B, we can lookup the bitmap we have already stored
       for that commit and OR it with the existing bitmap we've composed
       so far, allowing us to limit the walk early.

       After all the bitmaps have been generated, another iteration
       through the list of commits is performed to find the best XOR
       offsets for compression before writing them to disk. Because of
       the incremental nature of these bitmaps, XORing one of them with
       its predecesor results in a minimal "bitmap delta" most of the
       time. We can write this delta to the on-disk bitmap index, and
       then re-compose the original bitmaps by XORing them again when
       loaded.

       This is a phase very similar to pack-object's `find_delta` (using
       bitmaps instead of objects, of course), except the heuristics
       have been greatly simplified: we only check the 10 bitmaps before
       any given one to find best compressing one. This gives good
       results in practice, because there is locality in the ordering of
       the objects (and therefore bitmaps) in the packfile.

     6. `bitmap_writer_finish`: the last step in the process is
	serializing to disk all the bitmap data that has been generated
	in the two previous steps.

	The bitmap is written to a tmp file and then moved atomically to
	its final destination, using the same process as
	`pack-write.c:write_idx_file`.

Signed-off-by: Vicent Marti <tanoku@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-30 12:19:22 -08:00
Vicent Marti 6b8fda2db1 pack-objects: use bitmaps when packing objects
In this patch, we use the bitmap API to perform the `Counting Objects`
phase in pack-objects, rather than a traditional walk through the object
graph. For a reasonably-packed large repo, the time to fetch and clone
is often dominated by the full-object revision walk during the Counting
Objects phase. Using bitmaps can reduce the CPU time required on the
server (and therefore start sending the actual pack data with less
delay).

For bitmaps to be used, the following must be true:

  1. We must be packing to stdout (as a normal `pack-objects` from
     `upload-pack` would do).

  2. There must be a .bitmap index containing at least one of the
     "have" objects that the client is asking for.

  3. Bitmaps must be enabled (they are enabled by default, but can be
     disabled by setting `pack.usebitmaps` to false, or by using
     `--no-use-bitmap-index` on the command-line).

If any of these is not true, we fall back to doing a normal walk of the
object graph.

Here are some sample timings from a full pack of `torvalds/linux` (i.e.
something very similar to what would be generated for a clone of the
repository) that show the speedup produced by various
methods:

    [existing graph traversal]
    $ time git pack-objects --all --stdout --no-use-bitmap-index \
			    </dev/null >/dev/null
    Counting objects: 3237103, done.
    Compressing objects: 100% (508752/508752), done.
    Total 3237103 (delta 2699584), reused 3237103 (delta 2699584)

    real    0m44.111s
    user    0m42.396s
    sys     0m3.544s

    [bitmaps only, without partial pack reuse; note that
     pack reuse is automatic, so timing this required a
     patch to disable it]
    $ time git pack-objects --all --stdout </dev/null >/dev/null
    Counting objects: 3237103, done.
    Compressing objects: 100% (508752/508752), done.
    Total 3237103 (delta 2699584), reused 3237103 (delta 2699584)

    real    0m5.413s
    user    0m5.604s
    sys     0m1.804s

    [bitmaps with pack reuse (what you get with this patch)]
    $ time git pack-objects --all --stdout </dev/null >/dev/null
    Reusing existing pack: 3237103, done.
    Total 3237103 (delta 0), reused 0 (delta 0)

    real    0m1.636s
    user    0m1.460s
    sys     0m0.172s

Signed-off-by: Vicent Marti <tanoku@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-30 12:19:22 -08:00
Nguyễn Thái Ngọc Duy 0a1bc12b6e receive-pack: allow pushes that update .git/shallow
The basic 8 steps to update .git/shallow does not fully apply here
because the user may choose to accept just a few refs (while fetch
always accepts all refs). The steps are modified a bit.

1-6. same as before. After calling assign_shallow_commits_to_refs at
   step 6, each shallow commit has a bitmap that marks all refs that
   require it.

7. mark all "ours" shallow commits that are reachable from any
   refs. We will need to do the original step 7 on them later.

8. go over all shallow commit bitmaps, mark refs that require new
   shallow commits.

9. setup a strict temporary shallow file to plug all the holes, even
   if it may cut some of our history short. This file is used by all
   hooks. The hooks could use --shallow-file=$GIT_DIR/shallow to
   overcome this and reach everything in current repo.

10. go over the new refs one by one. For each ref, do the reachability
   test if it needs a shallow commit on the list from step 7. Remove
   it if it's reachable from our refs. Gather all required shallow
   commits, run check_everything_connected() with the new ref, then
   install them to .git/shallow.

This mode is disabled by default and can be turned on with
receive.shallowupdate

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-10 16:14:18 -08:00
Michael Haggerty 0838bf47b3 fetch --prune: prune only based on explicit refspecs
The old behavior of "fetch --prune" was to prune whatever was being
fetched.  In particular, "fetch --prune --tags" caused tags not only
to be fetched, but also to be pruned.  This is inappropriate because
there is only one tags namespace that is shared among the local
repository and all remotes.  Therefore, if the user defines a local
tag and then runs "git fetch --prune --tags", then the local tag is
deleted.  Moreover, "--prune" and "--tags" can also be configured via
fetch.prune / remote.<name>.prune and remote.<name>.tagopt, making it
even less obvious that an invocation of "git fetch" could result in
tag lossage.

Since the command "git remote update" invokes "git fetch", it had the
same problem.

The command "git remote prune", on the other hand, disregarded the
setting of remote.<name>.tagopt, and so its behavior was inconsistent
with that of the other commands.

So the old behavior made it too easy to lose tags.  To fix this
problem, change "fetch --prune" to prune references based only on
refspecs specified explicitly by the user, either on the command line
or via remote.<name>.fetch.  Thus, tags are no longer made subject to
pruning by the --tags option or the remote.<name>.tagopt setting.

However, tags *are* still subject to pruning if they are fetched as
part of a refspec, and that is good.  For example:

* On the command line,

      git fetch --prune 'refs/tags/*:refs/tags/*'

  causes tags, and only tags, to be fetched and pruned, and is
  therefore a simple way for the user to get the equivalent of the old
  behavior of "--prune --tag".

* For a remote that was configured with the "--mirror" option, the
  configuration is set to include

      [remote "name"]
              fetch = +refs/*:refs/*

  , which causes tags to be subject to pruning along with all other
  references.  This is the behavior that will typically be desired for
  a mirror.

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-30 14:16:37 -07:00
Junio C Hamano f92f068e76 Merge branch 'po/dot-url'
Explain how '.' can be used to refer to the "current repository"
in the documentation.

* po/dot-url:
  doc/cli: make "dot repository" an independent bullet point
  config doc: update dot-repository notes
  doc: command line interface (cli) dot-repository dwimmery
2013-10-23 13:21:48 -07:00
Jonathan Nieder 110f415ce8 Merge branch 'nv/doc-config-signingkey'
* nv/doc-config-signingkey:
  config doc: user.signingkey is also used for signed commits
2013-10-14 12:45:50 -07:00
Nicolas Vigier f0551693cc config doc: user.signingkey is also used for signed commits
The description of the user.signingkey option only mentioned its use
when creating a signed tag. Make it clear that is is also used when
creating signed commits.

Signed-off-by: Nicolas Vigier <boklm@mars-attacks.org>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
2013-10-14 12:45:22 -07:00
Jonathan Nieder 5636a20070 Merge branch 'bc/submodule-status-ignored'
* bc/submodule-status-ignored:
  Improve documentation concerning the status.submodulesummary setting
  submodule: don't print status output with ignore=all
  submodule: fix confusing variable name
2013-09-24 23:36:08 -07:00
Junio C Hamano 7b8315bb59 Merge branch 'jk/upload-pack-keepalive'
When running "fetch -q", a long silence while the sender side
computes the set of objects to send can be mistaken by proxies as
dropped connection.  The server side has been taught to send a small
empty messages to keep the connection alive.

* jk/upload-pack-keepalive:
  upload-pack: bump keepalive default to 5 seconds
  upload-pack: send keepalive packets during pack computation
2013-09-20 12:39:05 -07:00
Junio C Hamano 6d3e1f2e45 Merge branch 'mm/status-without-comment-char'
"git status" now omits the prefix to make its output a comment in a
commit log editor, which is not necessary for human consumption.

We may want to tighten the output to omit unnecessary trailing blank
lines, but that does not have to be in the scope of this series.

* mm/status-without-comment-char:
  t7508: avoid non-portable sed expression
  status: add missing blank line after list of "other" files
  tests: don't set status.displayCommentPrefix file-wide
  status: disable display of '#' comment prefix by default
  submodule summary: ignore --for-status option
  wt-status: use argv_array API
  builtin/stripspace.c: fix broken indentation
2013-09-20 12:29:01 -07:00
Junio C Hamano 89dde7882f Merge branch 'rh/ishes-doc'
We liberally use "committish" and "commit-ish" (and "treeish" and
"tree-ish"); as these are non-words, let's unify these terms to
their dashed form.  More importantly, clarify the documentation on
object peeling using these terms.

* rh/ishes-doc:
  glossary: fix and clarify the definition of 'ref'
  revisions.txt: fix and clarify <rev>^{<type>}
  glossary: more precise definition of tree-ish (a.k.a. treeish)
  use 'commit-ish' instead of 'committish'
  use 'tree-ish' instead of 'treeish'
  glossary: define commit-ish (a.k.a. committish)
  glossary: mention 'treeish' as an alternative to 'tree-ish'
2013-09-17 11:42:51 -07:00
Junio C Hamano 9b4aa47e7d Merge branch 'jx/clean-interactive'
Finishing touches to update the document to adjust to a new option
"git clean" learned recently.

* jx/clean-interactive:
  documentation: clarify notes for clean.requireForce
2013-09-17 11:40:23 -07:00
Philip Oakley b85ecea625 config doc: update dot-repository notes
branch.<name>.remote can be set to '.' (period) as the repository
path (URL) as part of the remote name dwimmery. Tell the reader.

Such relative paths are not 'special'. Correct the branch.<name>.merge
note.

Signed-off-by: Philip Oakley <philipoakley@iee.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-13 15:30:01 -07:00
Junio C Hamano d5d0a23dbb Merge branch 'jc/pager-configuration-doc'
It was unclear in the documentation how various configurations and
environment variables determine which pager is eventually used.

* jc/pager-configuration-doc:
  config: rewrite core.pager documentation
2013-09-12 14:41:54 -07:00
Junio C Hamano 6026f68652 Merge branch 'sh/pull-rebase-preserve'
"git pull --rebase" always flattened the history; pull.rebase can
now be set to "preserve" to invoke "rebase --preserve-merges".

* sh/pull-rebase-preserve:
  pull: allow pull to preserve merges when rebasing
2013-09-11 14:57:49 -07:00
Jens Lehmann bb58b696c6 Improve documentation concerning the status.submodulesummary setting
'git status' and 'git commit' can be told to also show the output of "git
submodule summary" by setting the "status.submodulesummary" config option.
But status and commit also honor the "diff.ignoreSubmodules" and the
"submodule.<name>.ignore" settings, which then disable the summary partly
or completely. This - and the fact that the last two settings do not
affect the "git submodule" commands at all - is not well documented.

Extend the documentation in those places where "status.submodulesummary",
"diff.ignoreSubmodules" and "submodule.<name>.ignore" are described to
better explain these dependencies.

Thanks-to: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-11 12:20:41 -07:00
Junio C Hamano a0a08d48d0 Merge branch 'jc/url-match'
Allow section.<urlpattern>.var configuration variables to be
treated as a "virtual" section.var given a URL, and use the
mechanism to enhance http.* configuration variables.

This is a reroll of Kyle J. McKay's work.

* jc/url-match:
  builtin/config.c: compilation fix
  config: "git config --get-urlmatch" parses section.<url>.key
  builtin/config: refactor collect_config()
  config: parse http.<url>.<variable> using urlmatch
  config: add generic callback wrapper to parse section.<url>.key
  config: add helper to normalize and match URLs
  http.c: fix parsing of http.sslCertPasswordProtected variable
2013-09-09 14:50:36 -07:00
Junio C Hamano 4301262640 Merge branch 'db/http-savecookies'
* db/http-savecookies:
  t5551: Remove header from curl cookie file
  http: add http.savecookies option to write out HTTP cookies
2013-09-09 14:32:08 -07:00
Junio C Hamano a5e10f8bc1 Merge branch 'ms/fetch-prune-configuration'
Allow fetch.prune and remote.*.prune configuration variables to be set,
and "git fetch" to behave as if "--prune" is given.

"git fetch" that honors remote.*.prune is fine, but I wonder if we
should somehow make "git push" aware of it as well.  Perhaps
remote.*.prune should not be just a boolean, but a 4-way "none",
"push", "fetch", "both"?

* ms/fetch-prune-configuration:
  fetch: make --prune configurable
2013-09-09 14:27:11 -07:00
Jeff King 115dedd722 upload-pack: bump keepalive default to 5 seconds
There is no reason not to turn on keepalives by default.
They take very little bandwidth, and significantly less than
the progress reporting they are replacing. And in the case
that progress reporting is on, we should never need to send
a keepalive anyway, as we will constantly be showing
progress and resetting the keepalive timer.

We do not necessarily know what the client's idea of a
reasonable timeout is, so let's keep this on the low side of
5 seconds. That is high enough that we will always prefer
our normal 1-second progress reports to sending a keepalive
packet, but low enough that no sane client should consider
the connection hung.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-09 11:15:17 -07:00
Jeff King 05e95155a1 upload-pack: send keepalive packets during pack computation
When upload-pack has started pack-objects, there may be a quiet
period while pack-objects prepares the pack (i.e., counting objects
and delta compression). Normally we would see (and send to the
client) progress information, but if "--quiet" is in effect,
pack-objects will produce nothing at all until the pack data is
ready. On a large repository, this can take tens of seconds (or even
minutes if the system is loaded or the repository is badly packed).
Clients or intermediate proxies can sometimes give up in this
situation, assuming that the server or connection has hung.

This patch introduces a "keepalive" option; if upload-pack sees no
data from pack-objects for a certain number of seconds, it will send
an empty sideband data packet to let the other side know that we are
still working on it.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-09 11:14:37 -07:00
Matthieu Moy 2556b9962e status: disable display of '#' comment prefix by default
Historically, "git status" needed to prefix each output line with '#' so
that the output could be added as comment to the commit message. This
prefix comment has no real purpose when "git status" is ran from the
command-line, and this may distract users from the real content.

Disable this prefix comment by default, and make it re-activable for
users needing backward compatibility with status.displayCommentPrefix.

Obviously, "git commit" ignores status.displayCommentPrefix and keeps the
comment unconditionnaly when writing to COMMIT_EDITMSG (but not when
writing to stdout for an error message or with --dry-run).

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-06 13:33:18 -07:00
Richard Hansen a8a5406ab3 use 'commit-ish' instead of 'committish'
Replace 'committish' in documentation and comments with 'commit-ish'
to match gitglossary(7) and to be consistent with 'tree-ish'.

The only remaining instances of 'committish' are:
  * variable, function, and macro names
  * "(also committish)" in the definition of commit-ish in
    gitglossary[7]

Signed-off-by: Richard Hansen <rhansen@bbn.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-04 15:03:03 -07:00
Stephen Haberman 66713ef3b0 pull: allow pull to preserve merges when rebasing
If a user is working on master, and has merged in their feature branch, but now
has to "git pull" because master moved, with pull.rebase their feature branch
will be flattened into master.

This is because "git pull" currently does not know about rebase's preserve
merges flag, which would avoid this behavior, as it would instead replay just
the merge commit of the feature branch onto the new master, and not replay each
individual commit in the feature branch.

Add a --rebase=preserve option, which will pass along --preserve-merges to
rebase.

Also add 'preserve' to the allowed values for the pull.rebase config setting.

Signed-off-by: Stephen Haberman <stephen@exigencecorp.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-04 12:45:48 -07:00
Junio C Hamano 97d01f2a88 config: rewrite core.pager documentation
The text mentions core.pager and GIT_PAGER without giving the
overall picture of precedences.  Borrow a better description from
the git-var(1) documentation.

The use of the mechanism to allow system-wide, global and
per-repository configuration files is not limited to this particular
variable.  Remove it to clarify the paragraph.

Rewrite the part that explains how the environment variable LESS is
set to Git's default value, and how to selectively customize it.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-29 12:03:08 -07:00
Jiang Xin f85f7947c3 documentation: clarify notes for clean.requireForce
Add "-i" (interactive clean option) to clarify the documentation for
"clean.requireForce" config variable.

Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-28 12:51:46 -07:00
Kyle J. McKay 6a56993b2e config: parse http.<url>.<variable> using urlmatch
Use the urlmatch_config_entry() to wrap the underlying
http_options() two-level variable parser in order to set
http.<variable> to the value with the most specific URL in the
configuration.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Kyle J. McKay <mackyle@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-05 16:02:03 -07:00
Junio C Hamano d6cbf2fa7a Merge branch 'rj/cygwin-clarify-use-of-cheating-lstat'
Cygwin port added a "not quite correct but a lot faster and good
enough for many lstat() calls that are only used to see if the
working tree entity matches the index entry" lstat() emulation some
time ago, and it started biting us in places.  This removes it and
uses the standard lstat() that comes with Cygwin.

Recent topic that uses lstat on packed-refs file is broken when
this cheating lstat is used, and this is a simplest fix that is
also the cleanest direction to go in the long run.

* rj/cygwin-clarify-use-of-cheating-lstat:
  cygwin: Remove the Win32 l/stat() implementation
2013-08-02 11:01:01 -07:00
Dave Borowitz 912b2acf2f http: add http.savecookies option to write out HTTP cookies
HTTP servers may send Set-Cookie headers in a response and expect them
to be set on subsequent requests. By default, libcurl behavior is to
store such cookies in memory and reuse them across requests within a
single session. However, it may also make sense, depending on the
server and the cookies, to store them across sessions. Provide users
an option to enable this behavior, writing cookies out to the same
file specified in http.cookiefile.

Signed-off-by: Dave Borowitz <dborowitz@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-30 09:19:04 -07:00
Junio C Hamano 07b83b5d98 Merge branch 'rr/send-email-ssl-verify'
Newer Net::SMTP::SSL module does not want the user programs to use
the default behaviour to let server certificate go without
verification, so by default enable the verification with a
mechanism to turn it off if needed.

* rr/send-email-ssl-verify:
  send-email: be explicit with SSL certificate verification
2013-07-22 11:24:17 -07:00
Junio C Hamano 988f98f61f Merge branch 'jx/clean-interactive'
Add "interactive" mode to "git clean".

The early part to refactor relative path related helper functions
looked sensible.

* jx/clean-interactive:
  test: run testcases with POSIX absolute paths on Windows
  test: add t7301 for git-clean--interactive
  git-clean: add documentation for interactive git-clean
  git-clean: add ask each interactive action
  git-clean: add select by numbers interactive action
  git-clean: add filter by pattern interactive action
  git-clean: use a git-add-interactive compatible UI
  git-clean: add colors to interactive git-clean
  git-clean: show items of del_list in columns
  git-clean: add support for -i/--interactive
  git-clean: refactor git-clean into two phases
  write_name{_quoted_relative,}(): remove redundant parameters
  quote_path_relative(): remove redundant parameter
  quote.c: substitute path_relative with relative_path
  path.c: refactor relative_path(), not only strip prefix
  test: add test cases for relative_path
2013-07-22 11:24:11 -07:00
Ramkumar Ramachandra 35035bbf07 send-email: be explicit with SSL certificate verification
When initiating an SSL connection without explicitly specifying the
SSL certificate verification mode, Net::SMTP::SSL defaults to no
verification, but recent versions of the module gives a warning
against this use of the default.

Enable certificate verification by default, using /etc/ssl/certs as
the default path for certificates of certificate authorities.  This
path can be overriden by the --smtp-ssl-cert-path command line
option and the sendemail.smtpSSLCertPath configuration variable.

Passing an empty string as the path for CA certificates path disables
the SSL certificate verification explicitly, which does not trigger
the warning from recent versions of Net::SMTP::SSL.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Helped-by: Brian M. Carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-18 16:01:30 -07:00
Michael Schubert 737c5a9cde fetch: make --prune configurable
Without "git fetch --prune", remote-tracking branches for a branch
the other side already has removed will stay forever.  Some people
want to always run "git fetch --prune".

To accommodate users who want to either prune always or when fetching
from a particular remote, add two new configuration variables
"fetch.prune" and "remote.<name>.prune":

 - "fetch.prune" allows to enable prune for all fetch operations.

 - "remote.<name>.prune" allows to change the behaviour per remote.

The latter will naturally override the former, and the --[no-]prune
option from the command line will override the configured default.

Since --prune is a potentially destructive operation (Git doesn't
keep reflogs for deleted references yet), we don't want to prune
without users consent, so this configuration will not be on by
default.

Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Michael Schubert <mschub@elegosoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-18 15:59:46 -07:00
Ramsay Jones f66450ae94 cygwin: Remove the Win32 l/stat() implementation
Commit adbc0b6b ("cygwin: Use native Win32 API for stat", 30-09-2008)
added a Win32 specific implementation of the stat functions. In order
to handle absolute paths, cygwin mount points and symbolic links, this
implementation may fall back on the standard cygwin l/stat() functions.
Also, the choice of cygwin or Win32 functions is made lazily (by the
first call(s) to l/stat) based on the state of some config variables.

Unfortunately, this "schizophrenic stat" implementation has been the
source of many problems ever since. For example, see commits 7faee6b8,
79748439, 452993c2, 085479e7, b8a97333, 924aaf3e, 05bab3ea and 0117c2f0.

In order to avoid further problems, such as the issue raised by the new
reference handling API, remove the Win32 l/stat() implementation.

Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-18 10:44:17 -07:00
Junio C Hamano e29497d28c Merge branch 'jg/status-config'
"git status" learned status.branch and status.short configuration
variables to use --branch and --short options by default (override
with --no-branch and --no-short options from the command line).

* jg/status-config:
  status/commit: make sure --porcelain is not affected by user-facing config
  commit: make it work with status.short
  status: introduce status.branch to enable --branch by default
  status: introduce status.short to enable --short by default
2013-07-11 13:05:34 -07:00
Junio C Hamano 3b8d2765c7 Merge branch 'jc/triangle-push-fixup'
Earlier remote.pushdefault (and per-branch branch.*.pushremote)
were introduced as an additional mechanism to choose what
repository to push into when "git push" did not say it from the
command line, to help people who push to a repository that is
different from where they fetch from.  This attempts to finish that
topic by teaching the default mechanism to choose branch in the
remote repository to be updated by such a push.

The 'current', 'matching' and 'nothing' modes (specified by the
push.default configuration variable) extend to such a "triangular"
workflow naturally, but 'upstream' and 'simple' have to be updated.

. 'upstream' is about pushing back to update the branch in the
  remote repository that the current branch fetches from and
  integrates with, it errors out in a triangular workflow.

. 'simple' is meant to help new people by avoiding mistakes, and
  will be the safe default in Git 2.0.

  In a non-triangular workflow, it will continue to act as a cross
  between 'upstream' and 'current' in that it pushes to the current
  branch's @{upstream} only when it is set to the same name as the
  current branch (e.g. your 'master' forks from the 'master' from
  the central repository).

  In a triangular workflow, this series tentatively defines it as
  the same as 'current', but we may have to tighten it to avoid
  surprises in some way.

* jc/triangle-push-fixup:
  t/t5528-push-default: test pushdefault workflows
  t/t5528-push-default: generalize test_push_*
  push: change `simple` to accommodate triangular workflows
  config doc: rewrite push.default section
  t/t5528-push-default: remove redundant test_config lines
2013-07-11 13:03:21 -07:00
Junio C Hamano 66929c423a Merge branch 'rr/column-doc'
* rr/column-doc:
  column doc: rewrite documentation for column.ui
2013-07-01 12:41:46 -07:00
Jiang Xin 7a9b0b802e git-clean: add colors to interactive git-clean
Show header, help, error messages, and prompt in colors for interactive
git-clean. Re-use config variables, such as "color.interactive" and
"color.interactive.<slot>" for command `git-add--interactive`.

Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
Comments-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-26 11:25:11 -07:00
Jiang Xin 1b8fd46732 git-clean: show items of del_list in columns
When there are lots of items to be cleaned, it is hard to see them all
in one screen. Show them in columns will solve this problem.

Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
Comments-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-26 11:25:11 -07:00
Ramkumar Ramachandra 5e62cc14c3 column doc: rewrite documentation for column.ui
The configuration option column.ui is very poorly documented, and it is
unclear what the defaults are, and what option can be combined with
what.  Rewrite it by splitting up the options into three sections
clearly showing how COL_ENABLED, COL_LAYOUT_MASK, and COL_DENSE work.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-26 08:51:43 -07:00
Junio C Hamano 8d8975aca7 Merge branch 'mm/rm-coalesce-errors'
Give a single message followed by list of paths from "git rm" to
report multiple paths that cannot be removed.

* mm/rm-coalesce-errors:
  rm: introduce advice.rmHints to shorten messages
  rm: better error message on failure for multiple files
2013-06-24 13:48:35 -07:00
Jorge Juan Garcia Garcia ec85d0700f status: introduce status.branch to enable --branch by default
Some people often run 'git status -b'.
The config variable status.branch allows to set it by default.

Signed-off-by: Jorge Juan Garcia Garcia <Jorge-Juan.Garcia-Garcia@ensimag.imag.fr>
Signed-off-by: Mathieu Lienard--Mayor <Mathieu.Lienard--Mayor@ensimag.imag.fr>
Reviewed-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Signed-off-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-24 10:25:49 -07:00
Jorge Juan Garcia Garcia 4fb5166ab5 status: introduce status.short to enable --short by default
Some people always run 'git status -s'.
The configuration variable status.short allows to set it by default.

Signed-off-by: Jorge Juan Garcia Garcia <Jorge-Juan.Garcia-Garcia@ensimag.imag.fr>
Signed-off-by: Mathieu Lienard--Mayor <Mathieu.Lienard--Mayor@ensimag.imag.fr>
Reviewed-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Signed-off-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-24 10:25:49 -07:00
Ramkumar Ramachandra ed2b18292b push: change `simple` to accommodate triangular workflows
When remote.pushdefault or branch.<name>.pushremote is set to a
remote that is different from where you usually fetch from (i.e. a
triangular workflow), master@{u} != origin, and push.default is set
to `upstream` or `simple` would fail with this error:

  $ git push
  fatal: You are pushing to remote 'origin', which is not the upstream of
  your current branch 'master', without telling me what to push
  to update which remote branch.

The very name of "upstream" indicates that it is only suitable for
use in central workflows; let us not even attempt to give it a new
meaning in triangular workflows, and error out as before.

However, the `simple` does not have to share this error.  It is
poised to be the default for Git 2.0, and we would like it to do
something sensible in triangular workflows.

Redefine "simple" as "safer upstream" for centralized workflow as
before, but work as "current" for triangular workflow.

We may want to make it "safer current", but that is a separate
issue.

Reported-by: Leandro Lucarella <leandro.lucarella@sociomantic.com>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-24 10:16:49 -07:00
Junio C Hamano 908a0e6b98 Revert "Merge branch 'jg/status-config'"
This reverts commit 1a22bd31f0, reversing
changes made to 3e7a5b489e.

It makes it impossible to "git commit" when status.short is set, and
also "git status --porcelain" output is affected by status.branch.
2013-06-24 08:18:07 -07:00
Ramkumar Ramachandra 87a70e4ce8 config doc: rewrite push.default section
4d35924e (Merge branch 'rr/triangle', 2013-04-07) introduced support
for triangular workflows, but the push.default values still assume
central workflows.

Rewrite the descriptions of `nothing`, `current`, `upstream` and
`matching` for greater clarity, and explicitly explain how they
should behave in triangular workflows.

Leave `simple` as it is for the moment, as we plan to change its
meaning to accommodate triangular workflows in a later patch.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-23 20:50:34 -07:00
Junio C Hamano 1a22bd31f0 Merge branch 'jg/status-config'
"git status" learned status.branch and status.short configuration
variables to use --branch and --short options by default (override
with --no-branch and --no-short options from the command line).

* jg/status-config:
  status: introduce status.branch to enable --branch by default
  status: introduce status.short to enable --short by default
2013-06-23 14:51:59 -07:00
Junio C Hamano 73018c0f0b Merge branch 'mm/color-auto-default'
Flip the default for color.ui to 'auto', which is what many
tutorials recommend new users to do.

* mm/color-auto-default:
  make color.ui default to 'auto'
  config: refactor management of color.ui's default value
2013-06-20 16:02:33 -07:00
Junio C Hamano b2ed944af7 push: switch default from "matching" to "simple"
We promised to change the behaviour of lazy "git push [there]" that
does not say what to push on the command line from "matching" to
"simple" in Git 2.0.

This finally flips that bit.

Helped-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-18 12:36:00 -07:00
Jorge Juan Garcia Garcia 0e254bbd22 status: introduce status.branch to enable --branch by default
Some people often run 'git status -b'.
The config variable status.branch allows to set it by default.

Signed-off-by: Jorge Juan Garcia Garcia <Jorge-Juan.Garcia-Garcia@ensimag.imag.fr>
Signed-off-by: Mathieu Lienard--Mayor <Mathieu.Lienard--Mayor@ensimag.imag.fr>
Reviewed-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Signed-off-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-15 22:15:28 -07:00
Mathieu Lienard--Mayor 7e30944622 rm: introduce advice.rmHints to shorten messages
Introduce advice.rmHints to choose whether to display advice or not
when git rm fails. Defaults to true, in order to preserve current behavior.

As an example, the message:
	error: 'foo.txt' has changes staged in the index
	(use --cached to keep the file, or -f to force removal)

would look like, with advice.rmHints=false:
	error: 'foo.txt' has changes staged in the index

Signed-off-by: Mathieu Lienard--Mayor <Mathieu.Lienard--Mayor@ensimag.imag.fr>
Signed-off-by: Jorge Juan Garcia Garcia <Jorge-Juan.Garcia-Garcia@ensimag.imag.fr>
Signed-off-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-12 16:59:55 -07:00
Jorge Juan Garcia Garcia 50e4f757f4 status: introduce status.short to enable --short by default
Some people always run 'git status -s'.
The configuration variable status.short allows to set it by default.

Signed-off-by: Jorge Juan Garcia Garcia <Jorge-Juan.Garcia-Garcia@ensimag.imag.fr>
Signed-off-by: Mathieu Lienard--Mayor <Mathieu.Lienard--Mayor@ensimag.imag.fr>
Reviewed-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Signed-off-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-11 14:38:08 -07:00
Matthieu Moy 4c7f1819b3 make color.ui default to 'auto'
Most users seem to like having colors enabled, and colors can help
beginners to understand the output of some commands (e.g. notice
immediately the boundary between commits in the output of "git log").

Many tutorials tell the users to set color.ui=auto as a very first step,
which tend to indicate that color.ui=none is not the recommanded value,
hence should not be the default.

These tutorials would benefit from skipping this step and starting the
real Git manipulations earlier. Other beginners do not know about
color.ui=auto, and may not discover it by themselves, hence live with
black&white outputs while they may have preferred colors.

A few people (e.g. color-blind) prefer having no colors, but they can
easily set color.ui=never for this (and googling "disable colors in git"
already tells them how to do so), but this needs not occupy space in
beginner-oriented documentations.

A transition period with Git emitting a warning when color.ui is unset
would be possible, but the discomfort of having the warning seems
superior to the benefit: users may be surprised by the change, but not
harmed by it.

The default value is changed, and the documentation is reworded to
mention "color.ui=false" first, since the primary use of color.ui after
this change is to disable colors, not to enable it.

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-10 10:55:42 -07:00
Ramkumar Ramachandra 587947750b rebase: implement --[no-]autostash and rebase.autostash
This new feature allows a rebase to be executed on a dirty worktree or
index.  It works by creating a temporary "dangling merge commit" out
of the worktree and index changes (via 'git stash create'), and
automatically applying it after a successful rebase or abort.

rebase stores the SHA-1 hex of the temporary merge commit, along with
the rest of the rebase state, in either
.git/{rebase-merge,rebase-apply}/autostash depending on the kind of
rebase.  Since $state_dir is automatically removed at the end of a
successful rebase or abort, so is the autostash.

The advantage of this approach is that we do not affect the normal
stash's reflogs, making the autostash invisible to the end-user.  This
means that you can use 'git stash' during a rebase as usual.

When the autostash application results in a conflict, we push
$state_dir/autostash onto the normal stash and remove $state_dir
ending the rebase.  The user can inspect the stash, and pop or drop at
any time.

Most significantly, this feature means that a caller like pull (with
pull.rebase set to true) can easily be patched to remove the
require_clean_work_tree restriction.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-29 10:34:54 -07:00
Junio C Hamano 89740333e8 Merge branch 'maint'
* maint:
  documentation: trivial whitespace cleanups
  t/Makefile: remove smoke test targets
2013-04-28 14:47:24 -07:00
Felipe Contreras 240ae2b8c9 documentation: trivial whitespace cleanups
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-28 14:46:52 -07:00
Junio C Hamano ad77690fe4 Merge branch 'ta/glossary'
* ta/glossary:
  glossary: improve definitions of refspec and pathspec
  The name of the hash function is "SHA-1", not "SHA1"
  glossary: improve description of SHA-1 related topics
  glossary: remove outdated/misleading/irrelevant entries
2013-04-21 18:40:15 -07:00
Junio C Hamano 4059da3352 Merge branch 'fc/branch-upstream-color'
Add more colors to "git branch -vv" output.

* fc/branch-upstream-color:
  branch: colour upstream branches
2013-04-19 13:31:24 -07:00
Junio C Hamano 574d51b575 Merge branch 'mv/ssl-ftp-curl'
Does anybody really use commit walkers over (s)ftp?

* mv/ssl-ftp-curl:
  Support FTP-over-SSL/TLS for regular FTP
2013-04-19 13:31:08 -07:00
Junio C Hamano 288aa7534a Merge branch 'fc/send-email-annotate'
Allows format-patch --cover-letter to be configurable; the most
notable is the "auto" mode to create cover-letter only for multi
patch series.

* fc/send-email-annotate:
  rebase-am: explicitly disable cover-letter
  format-patch: trivial cleanups
  format-patch: add format.coverLetter configuration variable
  log: update to OPT_BOOL
  format-patch: refactor branch name calculation
  format-patch: improve head calculation for cover-letter
  send-email: make annotate configurable
2013-04-18 11:49:11 -07:00
Thomas Ackermann d5fa1f1a69 The name of the hash function is "SHA-1", not "SHA1"
Use "SHA-1" instead of "SHA1" whenever we talk about the hash function.
When used as a programming symbol, we keep "SHA1".

Signed-off-by: Thomas Ackermann <th.acker@arcor.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-15 11:08:37 -07:00
Felipe Contreras dbda21fa87 branch: colour upstream branches
Otherwise when using 'git branch -vv' it's hard to see them among so
much output.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-15 11:04:44 -07:00
Modestas Vainius 4bc444eb64 Support FTP-over-SSL/TLS for regular FTP
Add a boolean http.sslTry option which allows to enable AUTH SSL/TLS and
encrypted data transfers when connecting via regular FTP protocol.

Default is false since it might trigger certificate verification errors on
misconfigured servers.

Signed-off-by: Modestas Vainius <modestas@vainius.eu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-12 08:52:23 -07:00
Felipe Contreras 2a4c26076c format-patch: add format.coverLetter configuration variable
Also, add a new option: 'auto', so if there's more than one patch, the
cover letter is generated, otherwise it's not.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-07 13:37:47 -07:00
Felipe Contreras 402596aafa send-email: make annotate configurable
Some people always do --annotate, lets not force them to always type
that.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-07 00:42:29 -07:00
Ramkumar Ramachandra 9f765ce62f remote.c: introduce branch.<name>.pushremote
This new configuration variable overrides `remote.pushdefault` and
`branch.<name>.remote` for pushes.  When you pull from one
place (e.g. your upstream) and push to another place (e.g. your own
publishing repository), you would want to set `remote.pushdefault` to
specify the remote to push to for all branches, and use this option to
override it for a specific branch.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-02 10:41:43 -07:00
Ramkumar Ramachandra 224c217163 remote.c: introduce remote.pushdefault
This new configuration variable defines the default remote to push to,
and overrides `branch.<name>.remote` for all branches.  It is useful
in the typical triangular-workflow setup, where the remote you're
fetching from is different from the remote you're pushing to.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-02 10:41:42 -07:00
Junio C Hamano fec274b01f Merge branch 'tb/document-status-u-tradeoff' into maint
* tb/document-status-u-tradeoff:
  status: advise to consider use of -u when read_directory takes too long
  git status: document trade-offs in choosing parameters to the -u option
2013-04-01 09:19:30 -07:00
Junio C Hamano d8355e5eae Merge branch 'maint'
* maint:
  git help config: s/insn/instruction/
2013-03-28 14:34:55 -07:00
Junio C Hamano 5e950c2199 Merge branch 'maint-1.8.1' into maint
* maint-1.8.1:
  git help config: s/insn/instruction/
2013-03-28 14:34:07 -07:00
Matthias Krüger 3322ad4284 git help config: s/insn/instruction/
"insn" appears to be an in-code abbreviation and should not appear
in manual/help pages.

Signed-off-by: Matthias Krüger <matthias.krueger@famsik.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-28 08:53:47 -07:00
Junio C Hamano c17866d7b6 Merge branch 'gp/avoid-explicit-mention-of-dot-git-refs' into maint
* gp/avoid-explicit-mention-of-dot-git-refs:
  Fix ".git/refs" stragglers
2013-03-26 12:40:04 -07:00
Junio C Hamano e4e1c54990 Merge branch 'jc/fetch-raw-sha1'
Allows requests to fetch objects at any tip of refs (including
hidden ones).  It seems that there may be use cases even outside
Gerrit (e.g. $gmane/215701).

* jc/fetch-raw-sha1:
  fetch: fetch objects by their exact SHA-1 object names
  upload-pack: optionally allow fetching from the tips of hidden refs
  fetch: use struct ref to represent refs to be fetched
  parse_fetch_refspec(): clarify the codeflow a bit
2013-03-21 14:02:27 -07:00
Junio C Hamano 5d04924e19 Merge branch 'tb/document-status-u-tradeoff'
Suggest users to look into using--untracked=no option when "git
status" takes too long.

* tb/document-status-u-tradeoff:
  status: advise to consider use of -u when read_directory takes too long
  git status: document trade-offs in choosing parameters to the -u option
2013-03-21 14:02:10 -07:00
Junio C Hamano 9adf272a38 Merge branch 'gp/avoid-explicit-mention-of-dot-git-refs'
* gp/avoid-explicit-mention-of-dot-git-refs:
  Fix ".git/refs" stragglers
2013-03-19 12:16:22 -07:00
Nguyễn Thái Ngọc Duy 6a38ef2ced status: advise to consider use of -u when read_directory takes too long
Introduce advice.statusUoption to suggest considering use of -u to
strike different trade-off when it took more than 2 seconds to
enumerate untracked/ignored files.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-16 21:44:58 -07:00
Junio C Hamano 2a4a26b53d Sync with 'maint'
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-25 08:28:06 -08:00
Junio C Hamano cd9c038ac9 Merge branch 'jc/mention-tracking-for-pull-default' into maint
* jc/mention-tracking-for-pull-default:
  doc: mention tracking for pull.default
2013-02-25 08:04:20 -08:00
Greg Price 4f021b34f2 Documentation: "advice" is uncountable
"Advice" is a mass noun, not a count noun; it's not ordinarily
pluralized.

Signed-off-by: Greg Price <price@mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-25 07:31:28 -08:00
Greg Price 48dfe969fc Fix ".git/refs" stragglers
A couple of references still survive to .git/refs as a tree
of all refs.  Fix one in docs, one in a -h message, one in
a -h message quoted in docs.

Signed-off-by: Greg Price <price@mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-24 22:23:32 -08:00
Junio C Hamano 20a599e2c1 Merge branch 'jc/mention-tracking-for-pull-default'
We stopped mentioning `tracking` is a deprecated but supported
synonym for `upstream` in pull.default even though we have no
intention of removing the support for it.

* jc/mention-tracking-for-pull-default:
  doc: mention tracking for pull.default
2013-02-18 16:05:03 -08:00
Junio C Hamano ce735bf7fd Merge branch 'jc/hidden-refs'
Allow the server side to redact the refs/ namespace it shows to the
client.

Will merge to 'master'.

* jc/hidden-refs:
  upload/receive-pack: allow hiding ref hierarchies
  upload-pack: simplify request validation
  upload-pack: share more code
2013-02-17 15:25:57 -08:00
Junio C Hamano 390eb36b0a upload-pack: optionally allow fetching from the tips of hidden refs
With uploadpack.allowtipsha1inwant configuration option set, future
versions of "git fetch" that allow an exact object name (likely to
have been obtained out of band) on the LHS of the fetch refspec can
make a request with a "want" line that names an object that may not
have been advertised due to transfer.hiderefs configuration.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-07 13:56:52 -08:00
Junio C Hamano daebaa7813 upload/receive-pack: allow hiding ref hierarchies
A repository may have refs that are only used for its internal
bookkeeping purposes that should not be exposed to the others that
come over the network.

Teach upload-pack to omit some refs from its initial advertisement
by paying attention to the uploadpack.hiderefs multi-valued
configuration variable.  Do the same to receive-pack via the
receive.hiderefs variable.  As a convenient short-hand, allow using
transfer.hiderefs to set the value to both of these variables.

Any ref that is under the hierarchies listed on the value of these
variable is excluded from responses to requests made by "ls-remote",
"fetch", etc. (for upload-pack) and "push" (for receive-pack).

Because these hidden refs do not count as OUR_REF, an attempt to
fetch objects at the tip of them will be rejected, and because these
refs do not get advertised, "git push :" will not see local branches
that have the same name as them as "matching" ones to be sent.

An attempt to update/delete these hidden refs with an explicit
refspec, e.g. "git push origin :refs/hidden/22", is rejected.  This
is not a new restriction.  To the pusher, it would appear that there
is no such ref, so its push request will conclude with "Now that I
sent you all the data, it is time for you to update the refs.  I saw
that the ref did not exist when I started pushing, and I want the
result to point at this commit".  The receiving end will apply the
compare-and-swap rule to this request and rejects the push with
"Well, your update request conflicts with somebody else; I see there
is such a ref.", which is the right thing to do. Otherwise a push to
a hidden ref will always be "the last one wins", which is not a good
default.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-07 13:48:47 -08:00
Junio C Hamano e34c7e2b51 Merge branch 'ta/doc-no-small-caps'
Update documentation to change "GIT" which was a poor-man's small
caps to "Git".  The latter was the intended spelling.

Also change "git" spelled in all-lowercase to "Git" when it refers
to the system as the whole or the concept it embodies, as opposed to
the command the end users would type.

* ta/doc-no-small-caps:
  Documentation: StGit is the right spelling, not StGIT
  Documentation: describe the "repository" in repository-layout
  Documentation: add a description for 'gitfile' to glossary
  Documentation: do not use undefined terms git-dir and git-file
  Documentation: the name of the system is 'Git', not 'git'
  Documentation: avoid poor-man's small caps GIT
2013-02-05 16:13:32 -08:00
Junio C Hamano 370855e967 Merge branch 'jc/push-reject-reasons'
Improve error and advice messages given locally when "git push"
refuses when it cannot compute fast-forwardness by separating these
cases from the normal "not a fast-forward; merge first and push
again" case.

* jc/push-reject-reasons:
  push: finishing touches to explain REJECT_ALREADY_EXISTS better
  push: introduce REJECT_FETCH_FIRST and REJECT_NEEDS_FORCE
  push: further simplify the logic to assign rejection reason
  push: further clean up fields of "struct ref"
2013-02-04 10:25:04 -08:00
Junio C Hamano 149a4211a4 Merge branch 'jc/custom-comment-char'
Allow a configuration variable core.commentchar to customize the
character used to comment out the hint lines in the edited text from
the default '#'.

* jc/custom-comment-char:
  Allow custom "comment char"
2013-02-04 10:23:49 -08:00
Thomas Ackermann 2de9b71138 Documentation: the name of the system is 'Git', not 'git'
Signed-off-by: Thomas Ackermann <th.acker@arcor.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-01 13:53:33 -08:00
Junio C Hamano fa23348e95 doc: mention tracking for pull.default
When looking at a configuration file edited long time ago, a user
may find 'pull.default = tracking' and wonder what it means, but
earlier we stopped mentioning this value, even though the code still
support it and more importantly, we have no intention to force old
timers to update their configuration files.

Instead of not mentioning it, add it to the description in a way
that makes it clear that users have no reason to add new uses of it
preferring over 'upstream', by not listing it as a separate item on
the same footing as other values but as a deprecated synonym of the
'upstream' in its description.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-31 17:00:56 -08:00
Junio C Hamano a77133e383 Merge branch 'ss/help-htmlpath-config-doc' into maint
* ss/help-htmlpath-config-doc:
  config.txt: Document help.htmlpath config parameter
2013-01-28 11:13:31 -08:00
Junio C Hamano 75e5c0dc55 push: introduce REJECT_FETCH_FIRST and REJECT_NEEDS_FORCE
When we push to update an existing ref, if:

 * the object at the tip of the remote is not a commit; or
 * the object we are pushing is not a commit,

it won't be correct to suggest to fetch, integrate and push again,
as the old and new objects will not "merge".  We should explain that
the push must be forced when there is a non-committish object is
involved in such a case.

If we do not have the current object at the tip of the remote, we do
not even know that object, when fetched, is something that can be
merged.  In such a case, suggesting to pull first just like
non-fast-forward case may not be technically correct, but in
practice, most such failures are seen when you try to push your work
to a branch without knowing that somebody else already pushed to
update the same branch since you forked, so "pull first" would work
as a suggestion most of the time.  And if the object at the tip is
not a commit, "pull first" will fail, without making any permanent
damage.  As a side effect, it also makes the error message the user
will get during the next "push" attempt easier to understand, now
the user is aware that a non-commit object is involved.

In these cases, the current code already rejects such a push on the
client end, but we used the same error and advice messages as the
ones used when rejecting a non-fast-forward push, i.e. pull from
there and integrate before pushing again.

Introduce new rejection reasons and reword the messages
appropriately.

[jc: with help by Peff on message details]

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-24 14:37:23 -08:00
Robin Rosenberg c08e4d5b5c Enable minimal stat checking
Specifically the fields uid, gid, ctime, ino and dev are set to zero
by JGit. Other implementations, eg. Git in cygwin are allegedly also
somewhat incompatible with Git For Windows and on *nix platforms
the resolution of the timestamps may differ.

Any stat checking by git will then need to check content, which may
be very slow, particularly on Windows. Since mtime and size
is typically enough we should allow the user to tell git to avoid
checking these fields if they are set to zero in the index.

This change introduces a core.checkstat config option where the
the user can select to check all fields (default), or just size
and the whole second part of mtime (minimal).

Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-22 09:33:16 -08:00
Junio C Hamano 28f04f3463 Merge branch 'rt/commit-cleanup-config'
Add a configuration variable to set default clean-up mode other
than "strip".

* rt/commit-cleanup-config:
  commit: make default of "cleanup" option configurable
2013-01-20 17:07:04 -08:00
Junio C Hamano 577f63e781 Merge branch 'ap/log-mailmap'
Teach commands in the "log" family to optionally pay attention to
the mailmap.

* ap/log-mailmap:
  log --use-mailmap: optimize for cases without --author/--committer search
  log: add log.mailmap configuration option
  log: grep author/committer using mailmap
  test: add test for --use-mailmap option
  log: add --use-mailmap option
  pretty: use mailmap to display username and email
  mailmap: add mailmap structure to rev_info and pp
  mailmap: simplify map_user() interface
  mailmap: remove email copy and length limitation
  Use split_ident_line to parse author and committer
  string-list: allow case-insensitive string list
2013-01-20 17:06:53 -08:00
Junio C Hamano 264238f7bd Merge branch 'ss/help-htmlpath-config-doc'
Add missing doc.

* ss/help-htmlpath-config-doc:
  config.txt: Document help.htmlpath config parameter
2013-01-18 11:20:20 -08:00
Junio C Hamano eff80a9fd9 Allow custom "comment char"
Some users do want to write a line that begin with a pound sign, #,
in their commit log message.  Many tracking system recognise
a token of #<bugid> form, for example.

The support we offer these use cases is not very friendly to the end
users.  They have a choice between

 - Don't do it.  Avoid such a line by rewrapping or indenting; and

 - Use --cleanup=whitespace but remove all the hint lines we add.

Give them a way to set a custom comment char, e.g.

    $ git -c core.commentchar="%" commit

so that they do not have to do either of the two workarounds.

[jc: although I started the topic, all the tests and documentation
updates, many of the call sites of the new strbuf_add_commented_*()
functions, and the change to git-submodule.sh scripted Porcelain are
from Ralf.]

Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-16 12:48:22 -08:00
Sebastian Staudt b1f809d0ae config.txt: Document help.htmlpath config parameter
Signed-off-by: Sebastian Staudt <koraktor@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-15 13:08:45 -08:00
Antoine Pelisse e6bb5f78fb log: add log.mailmap configuration option
Teach "log.mailmap" configuration variable to turn "--use-mailmap"
option on to "git log", "git show" and "git whatchanged".

The "--no-use-mailmap" option from the command line can countermand
the setting.

Signed-off-by: Antoine Pelisse <apelisse@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-10 12:33:09 -08:00
Ralf Thielow 51fb3a3dfa commit: make default of "cleanup" option configurable
The default of the "cleanup" option in "git commit"
is not configurable. Users who don't want to use the
default have to pass this option on every commit since
there's no way to configure it. This commit introduces
a new config option "commit.cleanup" which can be used
to change the default of the "cleanup" option in
"git commit".

Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-10 11:45:02 -08:00
Junio C Hamano 3a2ce79981 Merge branch 'nd/maint-branch-desc-doc'
Teach various forms of "format-patch" command line to identify what
branch the patches are taken from, so that the branch description
is picked up in more cases.

* nd/maint-branch-desc-doc:
  format-patch: pick up branch description when no ref is specified
  format-patch: pick up correct branch name from symbolic ref
  t4014: a few more tests on cover letter using branch description
  branch: delete branch description if it's empty
  config.txt: a few lines about branch.<name>.description
2013-01-09 08:27:09 -08:00
Junio C Hamano 902f2f4f0a Merge branch 'wk/submodule-update-remote'
The beginning of 'integrate with the tip of the remote branch, not
the commit recorded in the superproject gitlink' support.

* wk/submodule-update-remote:
  submodule add: If --branch is given, record it in .gitmodules
  submodule update: add --remote for submodule's upstream changes
  submodule: add get_submodule_config helper funtion
2013-01-05 23:42:11 -08:00
Junio C Hamano 3a3100a889 Merge branch 'jk/mailmap-from-blob'
Allow us to read, and default to read, mailmap files from the tip
of the history in bare repositories.  This will help running tools
like shortlog in server settings.

* jk/mailmap-from-blob:
  mailmap: default mailmap.blob in bare repositories
  mailmap: fix some documentation loose-ends for mailmap.blob
  mailmap: clean up read_mailmap error handling
  mailmap: support reading mailmap from blobs
  mailmap: refactor mailmap parsing for non-file sources
2013-01-05 23:41:42 -08:00
Junio C Hamano 9a2c83d24c Merge branch 'cr/push-force-tag-update'
Require "-f" for push to update a tag, even if it is a fast-forward.

* cr/push-force-tag-update:
  push: allow already-exists advice to be disabled
  push: rename config variable for more general use
  push: cleanup push rules comment
  push: clarify rejection of update to non-commit-ish
  push: require force for annotated tags
  push: require force for refs under refs/tags/
  push: flag updates that require force
  push: keep track of "update" state separately
  push: add advice for rejected tag reference
  push: return reject reasons as a bitset
2013-01-05 23:41:34 -08:00
Nguyễn Thái Ngọc Duy a5ba2cbe14 config.txt: a few lines about branch.<name>.description
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-01 12:13:43 -08:00
Ramkumar Ramachandra 0b830ac521 Documentation: move diff.wordRegex from config.txt to diff-config.txt
19299a8 (Documentation: Move diff.<driver>.* from config.txt to
diff-config.txt, 2011-04-07) moved the diff configuration options to
diff-config.txt, but forgot about diff.wordRegex, which was left
behind in config.txt.  Fix this.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-27 15:21:46 -08:00
W. Trevor King 06b1abb5bd submodule update: add --remote for submodule's upstream changes
The current `update` command incorporates the superproject's gitlinked
SHA-1 ($sha1) into the submodule HEAD ($subsha1).  Depending on the
options you use, it may checkout $sha1, rebase the $subsha1 onto
$sha1, or merge $sha1 into $subsha1.  This helps you keep up with
changes in the upstream superproject.

However, it's also useful to stay up to date with changes in the
upstream subproject.  Previous workflows for incorporating such
changes include the ungainly:

  $ git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull'

With this patch, all of the useful functionality for incorporating
superproject changes can be reused to incorporate upstream subproject
updates.  When you specify --remote, the target $sha1 is replaced with
a $sha1 of the submodule's origin/master tracking branch.  If you want
to merge a different tracking branch, you can configure the
`submodule.<name>.branch` option in `.gitmodules`.  You can override
the `.gitmodules` configuration setting for a particular superproject
by configuring the option in that superproject's default configuration
(using the usual configuration hierarchy, e.g. `.git/config`,
`~/.gitconfig`, etc.).

Previous use of submodule.<name>.branch
=======================================

Because we're adding a new configuration option, it's a good idea to
check if anyone else is already using the option.  The foreach-pull
example above was described by Ævar in

  commit f030c96d86
  Author: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
  Date:   Fri May 21 16:10:10 2010 +0000

    git-submodule foreach: Add $toplevel variable

Gerrit uses the same interpretation for the setting, but because
Gerrit has direct access to the subproject repositories, it updates
the superproject repositories automatically when a subproject changes.
Gerrit also accepts the special value '.', which it expands into the
superproject's branch name.

Although the --remote functionality is using `submodule.<name>.branch`
slightly differently, the effect is the same.  The foreach-pull
example uses the option to record the name of the local branch to
checkout before pulls.  The tracking branch to be pulled is recorded
in `.git/modules/<name>/config`, which was initialized by the module
clone during `submodule add` or `submodule init`.  Because the branch
name stored in `submodule.<name>.branch` was likely the same as the
branch name used during the initial `submodule add`, the same branch
will be pulled in each workflow.

Implementation details
======================

In order to ensure a current tracking branch state, `update --remote`
fetches the submodule's remote repository before calculating the
SHA-1.  However, I didn't change the logic guarding the existing fetch:

  if test -z "$nofetch"
  then
    # Run fetch only if $sha1 isn't present or it
    # is not reachable from a ref.
    (clear_local_git_env; cd "$path" &&
      ( (rev=$(git rev-list -n 1 $sha1 --not --all 2>/dev/null) &&
       test -z "$rev") || git-fetch)) ||
    die "$(eval_gettext "Unable to fetch in submodule path '\$path'")"
  fi

There will not be a double-fetch, because the new $sha1 determined
after the `--remote` triggered fetch should always exist in the
repository.  If it doesn't, it's because some racy process removed it
from the submodule's repository and we *should* be re-fetching.

Signed-off-by: W. Trevor King <wking@tremily.us>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-19 09:40:01 -08:00
Jeff King 8c473cecfd mailmap: default mailmap.blob in bare repositories
The motivation for mailmap.blob is to let users of bare
repositories use the mailmap feature, as they would not have
a checkout containing the .mailmap file. We can make it even
easier for them by just looking in HEAD:.mailmap by default.

We can't know for sure that this is where they would keep a
mailmap, of course, but it is the best guess (and it matches
the non-bare behavior, which reads from HEAD:.mailmap in the
working tree). If it's missing, git will silently ignore the
setting.

We do not do the same magic in the non-bare case, because:

  1. In the common case, HEAD:.mailmap will be the same as
     the .mailmap in the working tree, which is a no-op.

  2. In the uncommon case, the user has modified .mailmap
     but not yet committed it, and would expect the working
     tree version to take precedence.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-13 10:22:13 -08:00
Jeff King 086109006f mailmap: support reading mailmap from blobs
In a bare repository, there isn't a simple way to respect an
in-tree mailmap without extracting it to a temporary file.
This patch provides a config variable, similar to
mailmap.file, which reads the mailmap from a blob in the
repository.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-12 11:12:35 -08:00
Junio C Hamano fb4c62235f Merge branch 'mm/status-push-pull-advise'
* mm/status-push-pull-advise:
  document that statusHints affects git checkout
2012-12-04 13:34:10 -08:00
Matthieu Moy 552755a88b document that statusHints affects git checkout
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-04 07:57:30 -08:00
Chris Rorvick b450568209 push: allow already-exists advice to be disabled
Add 'advice.pushAlreadyExists' option to disable the advice shown when
an update is rejected for a reference that is not allowed to update at
all (verses those that are allowed to fast-forward.)

Signed-off-by: Chris Rorvick <chris@rorvick.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-03 08:04:09 -08:00
Chris Rorvick 1184564eac push: rename config variable for more general use
The 'pushNonFastForward' advice config can be used to squelch several
instances of push-related advice.  Rename it to 'pushUpdateRejected' to
cover other reject scenarios that are unrelated to fast-forwarding.
Retain the old name for compatibility.

Signed-off-by: Chris Rorvick <chris@rorvick.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-03 08:04:08 -08:00
Ramkumar Ramachandra 22bc70fdf9 Documentation: move diff.wordRegex from config.txt to diff-config.txt
19299a8 (Documentation: Move diff.<driver>.* from config.txt to
diff-config.txt, 2011-04-07) moved the diff configuration options to
diff-config.txt, but forgot about diff.wordRegex, which was left
behind in config.txt.  Fix this.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-18 19:18:13 -08:00
Jeff King 0d2605112e Merge branch 'pp/maint-doc-pager-config'
* pp/maint-doc-pager-config:
  Documentation: improve the example of overriding LESS via core.pager
2012-11-04 08:00:38 -05:00
Patrick Palka 3a599b832b Documentation: improve the example of overriding LESS via core.pager
You can override an option set in the LESS variable by simply prefixing
the command line option with `-+`. This is more robust than the previous
example if the default LESS options are to ever change.

Signed-off-by: Patrick Palka <patrick@parcs.ath.cx>
Signed-off-by: Jeff King <peff@peff.net>
2012-10-29 02:27:13 -04:00
Junio C Hamano b61f55be00 Merge branch 'maint'
* maint:
  t/perf: add "trash directory" to .gitignore
  Add missing -z to git check-attr usage text for consistency with man page
  git-jump: ignore (custom) prefix in diff mode
  Documentation: indent-with-non-tab uses "equivalent tabs" not 8
  completion: add --no-edit to git-commit
2012-09-17 15:59:34 -07:00
Wesley J. Landaker 2ce4fee878 Documentation: indent-with-non-tab uses "equivalent tabs" not 8
Update the documentation of the core.whitespace option
"indent-with-non-tab" to correctly reflect that it catches the use of
spaces instead of the equivalent tabs, rather than a fixed number.

Signed-off-by: Wesley J. Landaker <wjl@icecavern.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-17 10:23:21 -07:00
Junio C Hamano 445d2c51a4 Merge branch 'js/grep-patterntype-config'
"grep" learned to use a non-standard pattern type by default if a
configuration variable tells it to.

* js/grep-patterntype-config:
  grep: add a grep.patternType configuration setting
2012-08-27 11:55:09 -07:00
J Smith 84befcd0a4 grep: add a grep.patternType configuration setting
The grep.extendedRegexp configuration setting enables the -E flag on grep
by default but there are no equivalents for the -G, -F and -P flags.

Rather than adding an additional setting for grep.fooRegexp for current
and future pattern matching options, add a grep.patternType setting that
can accept appropriate values for modifying the default grep pattern
matching behavior. The current values are "basic", "extended", "fixed",
"perl" and "default" for setting -G, -E, -F, -P and the default behavior
respectively.

When grep.patternType is set to a value other than "default", the
grep.extendedRegexp setting is ignored. The value of "default" restores
the current default behavior, including the grep.extendedRegexp
behavior.

Signed-off-by: J Smith <dark.panda@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-03 09:58:02 -07:00
Junio C Hamano 9b67f560f4 Merge branch 'pg/maint-1.7.9-am-where-is-patch' into maint
When "git am" failed, old timers knew to check .git/rebase-apply/patch
to see what went wrong, but we never told the users about it.

* pg/maint-1.7.9-am-where-is-patch:
  am: indicate where a failed patch is to be found
2012-07-30 13:04:39 -07:00
Junio C Hamano 80ee1e0469 Merge branch 'pg/maint-1.7.9-am-where-is-patch'
When "git am" failed, old timers knew to check .git/rebase-apply/patch
to see what went wrong, but we never told the users about it.

* pg/maint-1.7.9-am-where-is-patch:
  am: indicate where a failed patch is to be found
2012-07-22 12:56:02 -07:00
Paul Gortmaker 14bf2d58bc am: indicate where a failed patch is to be found
If "git am" fails to apply something, the end user may need to know
where to find the patch that failed to apply, so that the user can
do other things (e.g. trying "GNU patch" on it, running "diffstat"
to see what it tried to change, etc.)  The input to "am" may have
contained more than one patch, or the message may have been MIME
encoded, and knowing what the user fed to "am" does not help very
much for this purpose.

Also introduce advice.amworkdir configuration to allow people who
learned where to look to squelch this message.

Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-13 16:02:48 -07:00
Junio C Hamano b856ad623e Merge branch 'tb/sanitize-decomposed-utf-8-pathname'
Teaches git to normalize pathnames read from readdir(3) and all
arguments from the command line into precomposed UTF-8 (assuming
that they come as decomposed UTF-8) to work around issues on Mac OS.

I think there still are other places that need conversion
(e.g. paths that are read from stdin for some commands), but this
should be a good first step in the right direction.

* tb/sanitize-decomposed-utf-8-pathname:
  git on Mac OS and precomposed unicode
2012-07-13 15:37:51 -07:00
Junio C Hamano d02d7ac303 Merge branch 'mm/config-xdg'
Teach git to read various information from $XDG_CONFIG_HOME/git/ to allow
the user to avoid cluttering $HOME.

* mm/config-xdg:
  config: write to $XDG_CONFIG_HOME/git/config file when appropriate
  Let core.attributesfile default to $XDG_CONFIG_HOME/git/attributes
  Let core.excludesfile default to $XDG_CONFIG_HOME/git/ignore
  config: read (but not write) from $XDG_CONFIG_HOME/git/config file
2012-07-09 09:00:36 -07:00
Torsten Bögershausen 76759c7dff git on Mac OS and precomposed unicode
Mac OS X mangles file names containing unicode on file systems HFS+,
VFAT or SAMBA.  When a file using unicode code points outside ASCII
is created on a HFS+ drive, the file name is converted into
decomposed unicode and written to disk. No conversion is done if
the file name is already decomposed unicode.

Calling open("\xc3\x84", ...) with a precomposed "Ä" yields the same
result as open("\x41\xcc\x88",...) with a decomposed "Ä".

As a consequence, readdir() returns the file names in decomposed
unicode, even if the user expects precomposed unicode.  Unlike on
HFS+, Mac OS X stores files on a VFAT drive (e.g. an USB drive) in
precomposed unicode, but readdir() still returns file names in
decomposed unicode.  When a git repository is stored on a network
share using SAMBA, file names are send over the wire and written to
disk on the remote system in precomposed unicode, but Mac OS X
readdir() returns decomposed unicode to be compatible with its
behaviour on HFS+ and VFAT.

The unicode decomposition causes many problems:

- The names "git add" and other commands get from the end user may
  often be precomposed form (the decomposed form is not easily input
  from the keyboard), but when the commands read from the filesystem
  to see what it is going to update the index with already is on the
  filesystem, readdir() will give decomposed form, which is different.

- Similarly "git log", "git mv" and all other commands that need to
  compare pathnames found on the command line (often but not always
  precomposed form; a command line input resulting from globbing may
  be in decomposed) with pathnames found in the tree objects (should
  be precomposed form to be compatible with other systems and for
  consistency in general).

- The same for names stored in the index, which should be
  precomposed, that may need to be compared with the names read from
  readdir().

NFS mounted from Linux is fully transparent and does not suffer from
the above.

As Mac OS X treats precomposed and decomposed file names as equal,
we can

 - wrap readdir() on Mac OS X to return the precomposed form, and

 - normalize decomposed form given from the command line also to the
   precomposed form,

to ensure that all pathnames used in Git are always in the
precomposed form.  This behaviour can be requested by setting
"core.precomposedunicode" configuration variable to true.

The code in compat/precomposed_utf8.c implements basically 4 new
functions: precomposed_utf8_opendir(), precomposed_utf8_readdir(),
precomposed_utf8_closedir() and precompose_argv().  The first three
are to wrap opendir(3), readdir(3), and closedir(3) functions.

The argv[] conversion allows to use the TAB filename completion done
by the shell on command line.  It tolerates other tools which use
readdir() to feed decomposed file names into git.

When creating a new git repository with "git init" or "git clone",
"core.precomposedunicode" will be set "false".

The user needs to activate this feature manually.  She typically
sets core.precomposedunicode to "true" on HFS and VFAT, or file
systems mounted via SAMBA.

Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-08 22:03:46 -07:00
Andreas Schwab b12905140a Fix formatting in git-config(1)
This fixes two formatting bugs in the git-config documentation:

- in the column.ui entry don't indent the last paragraph so that it isn't
  formatted as a literal paragraph
- in the push.default entry separate the last paragraph from the
  nested list.

Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-03 12:13:19 -07:00
Huynh Khoi Nguyen Nguyen 684e40f657 Let core.attributesfile default to $XDG_CONFIG_HOME/git/attributes
This gives the default value for the core.attributesfile variable
following the exact same logic of the previous change for the
core.excludesfile setting.

Signed-off-by: Huynh Khoi Nguyen Nguyen <Huynh-Khoi-Nguyen.Nguyen@ensimag.imag.fr>
Signed-off-by: Valentin Duperray <Valentin.Duperray@ensimag.imag.fr>
Signed-off-by: Franck Jonas <Franck.Jonas@ensimag.imag.fr>
Signed-off-by: Lucien Kong <Lucien.Kong@ensimag.imag.fr>
Signed-off-by: Thomas Nguy <Thomas.Nguy@ensimag.imag.fr>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-25 09:06:15 -07:00
Huynh Khoi Nguyen Nguyen dc79687e0b Let core.excludesfile default to $XDG_CONFIG_HOME/git/ignore
To use the feature of core.excludesfile, the user needs:

 1. to create such a file,

 2. and add configuration variable to point at it.

Instead, we can make this a one-step process by choosing a default value
which points to a filename in the user's $HOME, that is unlikely to
already exist on the system, and only use the presence of the file as a
cue that the user wants to use that feature.

And we use "${XDG_CONFIG_HOME:-$HOME/.config/git}/ignore" as such a
file, in the same directory as the newly added configuration file
("${XDG_CONFIG_HOME:-$HOME/.config/git}/config).  The use of this
directory is in line with XDG specification as a location to store
such application specific files.

Signed-off-by: Huynh Khoi Nguyen Nguyen <Huynh-Khoi-Nguyen.Nguyen@ensimag.imag.fr>
Signed-off-by: Valentin Duperray <Valentin.Duperray@ensimag.imag.fr>
Signed-off-by: Franck Jonas <Franck.Jonas@ensimag.imag.fr>
Signed-off-by: Lucien Kong <Lucien.Kong@ensimag.imag.fr>
Signed-off-by: Thomas Nguy <Thomas.Nguy@ensimag.imag.fr>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-25 09:06:15 -07:00
Lucien Kong 83c750acde wt-status.*: better advices for git status added
This patch provides new informative help messages in the display of
'git status' (at the top) during conflicts, rebase, am, bisect or
cherry-pick process.

The new messages are not shown when using options such as -s or
--porcelain. The messages about the current situation of the user are
always displayed but the advices on what the user needs to do in order
to resume a rebase/bisect/am/commit after resolving conflicts can be
hidden by setting advice.statushints to 'false' in the config file.

Thus, information about the updated advice.statushints key are added
in Documentation/config.txt.

Also, the test t7060-wt-status.sh is now working with the new help
messages. Tests about suggestions of "git rm" are also added.

Signed-off-by: Lucien Kong <Lucien.Kong@ensimag.imag.fr>
Signed-off-by: Valentin Duperray <Valentin.Duperray@ensimag.imag.fr>
Signed-off-by: Franck Jonas <Franck.Jonas@ensimag.imag.fr>
Signed-off-by: Thomas Nguy <Thomas.Nguy@ensimag.imag.fr>
Signed-off-by: Huynh Khoi Nguyen Nguyen <Huynh-Khoi-Nguyen.Nguyen@ensimag.imag.fr>
Signed-off-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-14 10:15:19 -07:00
Junio C Hamano f4ed0af6e2 Merge branch 'nd/columns'
A couple of commands learn --column option to produce columnar output.

By Nguyễn Thái Ngọc Duy (9) and Zbigniew Jędrzejewski-Szmek (1)
* nd/columns:
  tag: add --column
  column: support piping stdout to external git-column process
  status: add --column
  branch: add --column
  help: reuse print_columns() for help -a
  column: add dense layout support
  t9002: work around shells that are unable to set COLUMNS to 1
  column: add columnar layout
  Stop starting pager recursively
  Add column layout skeleton and git-column
2012-05-03 15:13:31 -07:00
Jeff King 9a7b0bca36 doc/config: fix inline literals
Since commit 6cf378f, asciidoc backticks are now inline
literals; therefore quoting {tilde} inside them is wrong
(this instance was missed in 6cf378f because it happened on
a parallel line of development).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-03 00:05:01 -07:00
Junio C Hamano d274fc093c Merge branch 'jk/doc-asciidoc-inline-literal'
Our documentation was written for an ancient version of AsciiDoc,
making the source not very readable.

By Jeff King
* jk/doc-asciidoc-inline-literal:
  docs: stop using asciidoc no-inline-literal
2012-05-02 13:51:45 -07:00
Junio C Hamano a3db8511b7 Merge branch 'mm/simple-push'
New users tend to work on one branch at a time and push the result
out. The current and upstream modes of push is a more suitable default
mode than matching mode for these people, but neither is surprise-free
depending on how the project is set up. Introduce a "simple" mode that
is a subset of "upstream" but only works when the branch is named the same
between the remote and local repositories.

The plan is to make it the new default when push.default is not
configured.

By Matthieu Moy (5) and others
* mm/simple-push:
  push.default doc: explain simple after upstream
  push: document the future default change for push.default (matching -> simple)
  t5570: use explicit push refspec
  push: introduce new push.default mode "simple"
  t5528-push-default.sh: add helper functions
  Undocument deprecated alias 'push.default=tracking'
  Documentation: explain push.default option a bit more
2012-05-02 13:51:24 -07:00
Junio C Hamano 5fa8bf6bf9 Merge branch 'mm/include-userpath'
The new "include.path" directive in the configuration files learned
to understand "~/path" and "~user/path".

By Jeff King
* mm/include-userpath:
  config: expand tildes in include.path variable
2012-04-29 17:51:27 -07:00
Jeff King 4c0a89fcde config: expand tildes in include.path variable
You can already use relative paths in include.path, which
means that including "foo" from your global "~/.gitconfig"
will look in your home directory. However, you might want to
do something clever like putting "~/.gitconfig-foo" in a
specific repository's config file.

Signed-off-by: Jeff King <peff@peff.net>
Acked-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-29 17:46:32 -07:00
Nguyễn Thái Ngọc Duy d96e3c150f tag: add --column
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-27 09:26:39 -07:00
Nguyễn Thái Ngọc Duy 323d053091 status: add --column
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-27 09:26:38 -07:00
Nguyễn Thái Ngọc Duy ebe31ef2ed branch: add --column
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-27 09:26:38 -07:00
Nguyễn Thái Ngọc Duy 3f8eccbe16 column: add dense layout support
Normally all cells (and in turn columns) share the same width. This
layout mode can waste space because one long item can stretch our all
columns.

With COL_DENSE enabled, column width is calculated indepdendently. All
columns are shrunk to minimum, then it attempts to push cells of the
last row over to the next column with hope that everything still fits
even there's one row less. The process is repeated until the new layout
cannot fit in given width any more, or there's only one row left
(perfect!).

Apparently, this mode consumes more cpu than the old one, but it makes
better use of terminal space. For layouting one or two screens, cpu
usage should not be detectable.

This patch introduces option handling code besides layout modes and
enable/disable to expose this feature as "dense". The feature can be
turned off by specifying "nodense".

Thanks-to: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-27 09:26:38 -07:00
Nguyễn Thái Ngọc Duy 077539d734 column: add columnar layout
COL_COLUMN and COL_ROW fill column by column (or row by row
respectively), given the terminal width and how many space between
columns. All cells have equal width.

Strings are supposed to be in UTF-8. Valid ANSI escape strings are OK.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-27 09:26:38 -07:00
Nguyễn Thái Ngọc Duy 7e29b8254f Add column layout skeleton and git-column
A column option string consists of many token separated by either
a space or a  comma. A token belongs to one of three groups:

 - enabling: always, never and auto
 - layout mode: currently plain (which does not layout at all)
 - other future tuning flags

git-column can be used to pipe output to from a command that wants
column layout, but not to mess with its own output code. Simpler output
code can be changed to use column layout code directly.

Thanks-to: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-27 09:26:37 -07:00
Jeff King 6cf378f0cb docs: stop using asciidoc no-inline-literal
In asciidoc 7, backticks like `foo` produced a typographic
effect, but did not otherwise affect the syntax. In asciidoc
8, backticks introduce an "inline literal" inside which markup
is not interpreted. To keep compatibility with existing
documents, asciidoc 8 has a "no-inline-literal" attribute to
keep the old behavior. We enabled this so that the
documentation could be built on either version.

It has been several years now, and asciidoc 7 is no longer
in wide use. We can now decide whether or not we want
inline literals on their own merits, which are:

  1. The source is much easier to read when the literal
     contains punctuation. You can use `master~1` instead
     of `master{tilde}1`.

  2. They are less error-prone. Because of point (1), we
     tend to make mistakes and forget the extra layer of
     quoting.

This patch removes the no-inline-literal attribute from the
Makefile and converts every use of backticks in the
documentation to an inline literal (they must be cleaned up,
or the example above would literally show "{tilde}" in the
output).

Problematic sites were found by grepping for '`.*[{\\]' and
examined and fixed manually. The results were then verified
by comparing the output of "html2text" on the set of
generated html pages. Doing so revealed that in addition to
making the source more readable, this patch fixes several
formatting bugs:

  - HTML rendering used the ellipsis character instead of
    literal "..." in code examples (like "git log A...B")

  - some code examples used the right-arrow character
    instead of '->' because they failed to quote

  - api-config.txt did not quote tilde, and the resulting
    HTML contained a bogus snippet like:

      <tt><sub></tt> foo <tt></sub>bar</tt>

    which caused some parsers to choke and omit whole
    sections of the page.

  - git-commit.txt confused ``foo`` (backticks inside a
    literal) with ``foo'' (matched double-quotes)

  - mentions of `A U Thor <author@example.com>` used to
    erroneously auto-generate a mailto footnote for
    author@example.com

  - the description of --word-diff=plain incorrectly showed
    the output as "[-removed-] and {added}", not "{+added+}".

  - using "prime" notation like:

      commit `C` and its replacement `C'`

    confused asciidoc into thinking that everything between
    the first backtick and the final apostrophe were meant
    to be inside matched quotes

  - asciidoc got confused by the escaping of some of our
    asterisks. In particular,

      `credential.\*` and `credential.<url>.\*`

    properly escaped the asterisk in the first case, but
    literally passed through the backslash in the second
    case.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-26 13:19:06 -07:00
Junio C Hamano f4d80d2639 push.default doc: explain simple after upstream
As the "simple" mode is described in terms of what "upstream" does,
swap the order of these two entries so that the reader sees "upstream"
first and then reads "simple" with the knowledge of what "upstream"
does.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-24 15:22:17 -07:00
Matthieu Moy 67804c2731 push: document the future default change for push.default (matching -> simple)
It is too early to start warning loudly about the future default change
in favor of 'simple', since many users use different versions of Git, and
would be harmed if we advised them to explicitely set
'push.default=simple' when using old versions of Git.

Still, we want to document the upcomming change so that:

* Users who may be affected by the change get one more chance to know it
  in advance.

* We actually commit to changing the default, and avoid repeating past
  errors.

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-24 15:22:17 -07:00
Matthieu Moy b55e677522 push: introduce new push.default mode "simple"
When calling "git push" without argument, we want to allow Git to do
something simple to explain and safe. push.default=matching is unsafe
when used to push to shared repositories, and hard to explain to
beginners in some contexts. It is debatable whether 'upstream' or
'current' is the safest or the easiest to explain, so introduce a new
mode called 'simple' that is the intersection of them: push to the
upstream branch, but only if it has the same name remotely. If not, give
an error that suggests the right command to push explicitely to
'upstream' or 'current'.

A question is whether to allow pushing when no upstream is configured. An
argument in favor of allowing the push is that it makes the new mode work
in more cases. On the other hand, refusing to push when no upstream is
configured encourages the user to set the upstream, which will be
beneficial on the next pull. Lacking better argument, we chose to deny
the push, because it will be easier to change in the future if someone
shows us wrong.

Original-patch-by: Jeff King <peff@peff.net>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-24 15:22:16 -07:00
Matthieu Moy 628ab0ea10 Undocument deprecated alias 'push.default=tracking'
It's been deprecated since 53c4031 (Johan Herland, Wed Feb 16 2011,
push.default: Rename 'tracking' to 'upstream'), so it's OK to remove it
from documentation (even though it's still supported) to make the
explanations more readable.

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-24 12:11:58 -07:00
Matthieu Moy 185c0874b1 Documentation: explain push.default option a bit more
The previous documentation was explaining _what_ the options were doing,
but were of little help explaining _why_ a user should set his default to
either of the options.

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-24 12:11:58 -07:00
Christopher Tiwald f25950f347 push: Provide situational hints for non-fast-forward errors
Pushing a non-fast-forward update to a remote repository will result in
an error, but the hint text doesn't provide the correct resolution in
every case. Give better resolution advice in three push scenarios:

1) If you push your current branch and it triggers a non-fast-forward
error, you should merge remote changes with 'git pull' before pushing
again.

2) If you push to a shared repository others push to, and your local
tracking branches are not kept up to date, the 'matching refs' default
will generate non-fast-forward errors on outdated branches. If this is
your workflow, the 'matching refs' default is not for you. Consider
setting the 'push.default' configuration variable to 'current' or
'upstream' to ensure only your current branch is pushed.

3) If you explicitly specify a ref that is not your current branch or
push matching branches with ':', you will generate a non-fast-forward
error if any pushed branch tip is out of date. You should checkout the
offending branch and merge remote changes before pushing again.

Teach transport.c to recognize these scenarios and configure push.c
to hint for them. If 'git push's default behavior changes or we
discover more scenarios, extension is easy. Standardize on the
advice API and add three new advice variables, 'pushNonFFCurrent',
'pushNonFFDefault', and 'pushNonFFMatching'. Setting any of these
to 'false' will disable their affiliated advice. Setting
'pushNonFastForward' to false will disable all three, thus preserving the
config option for users who already set it, but guaranteeing new
users won't disable push advice accidentally.

Based-on-patch-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Christopher Tiwald <christiwald@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-19 21:42:06 -07:00
Junio C Hamano 91527e54d5 Merge branch 'maint'
* maint:
  Update draft release notes to 1.7.9.3 for the last time
  http.proxy: also mention https_proxy and all_proxy
  t0300: work around bug in dash 0.5.6
  t5512 (ls-remote): modernize style
  tests: fix spurious error when run directly with Solaris /usr/xpg4/bin/sh
2012-03-04 22:21:52 -08:00
Clemens Buchacher b2c8c6d944 http.proxy: also mention https_proxy and all_proxy
The current wording of the http.proxy documentation suggests that
http_proxy is somehow equivalent to http.proxy. However, while
http.proxy (by the means of curl's CURLOPT_PROXY option) overrides the
proxy for both HTTP and HTTPS protocols, the http_proxy environment
variable is used only for HTTP. But since the docs mention only
http_proxy, a user might expect it to apply to all HTTP-like protocols.

Avoid any such misunderstanding by explicitly mentioning https_proxy and
all_proxy as well.

Also replace linkgit:curl[1] with a literal 'curl(1)', because the
former gets translated to a dead link in the HTML pages.

Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-04 21:11:06 -08:00
Junio C Hamano 797166cfaf Merge branch 'maint'
* maint:
  Documentation fixes in git-config
2012-03-01 14:45:14 -08:00
Libor Pechacek e0a4aae865 Documentation fixes in git-config
Variable names must start with an alphabetic character, regexp config key
matching has its limits, sentence grammar.

Signed-off-by: Libor Pechacek <lpechacek@suse.cz>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-01 08:22:24 -08:00
Jeff King 9b25a0b52e config: add include directive
It can be useful to split your ~/.gitconfig across multiple
files. For example, you might have a "main" file which is
used on many machines, but a small set of per-machine
tweaks. Or you may want to make some of your config public
(e.g., clever aliases) while keeping other data back (e.g.,
your name or other identifying information). Or you may want
to include a number of config options in some subset of your
repos without copying and pasting (e.g., you want to
reference them from the .git/config of participating repos).

This patch introduces an include directive for config files.
It looks like:

  [include]
    path = /path/to/file

This is syntactically backwards-compatible with existing git
config parsers (i.e., they will see it as another config
entry and ignore it unless you are looking up include.path).

The implementation provides a "git_config_include" callback
which wraps regular config callbacks. Callers can pass it to
git_config_from_file, and it will transparently follow any
include directives, passing all of the discovered options to
the real callback.

Include directives are turned on automatically for "regular"
git config parsing. This includes calls to git_config, as
well as calls to the "git config" program that do not
specify a single file (e.g., using "-f", "--global", etc).
They are not turned on in other cases, including:

  1. Parsing of other config-like files, like .gitmodules.
     There isn't a real need, and I'd rather be conservative
     and avoid unnecessary incompatibility or confusion.

  2. Reading single files via "git config". This is for two
     reasons:

       a. backwards compatibility with scripts looking at
          config-like files.

       b. inspection of a specific file probably means you
	  care about just what's in that file, not a general
          lookup for "do we have this value anywhere at
	  all". If that is not the case, the caller can
	  always specify "--includes".

  3. Writing files via "git config"; we want to treat
     include.* variables as literal items to be copied (or
     modified), and not expand them. So "git config
     --unset-all foo.bar" would operate _only_ on
     .git/config, not any of its included files (just as it
     also does not operate on ~/.gitconfig).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-17 07:59:55 -08:00
Junio C Hamano e04dc492ac Sync with maint
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-10 14:46:22 -08:00
Junio C Hamano 55dcc2ebad Merge the attributes fix in from maint-1.6.7 branch
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-10 14:24:01 -08:00
Junio C Hamano 6c65b5ea43 Merge the attributes fix in from maint-1.6.6 branch
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-10 14:14:26 -08:00
Junio C Hamano b6fb7fed6a Documentation: rerere's rr-cache auto-creation and rerere.enabled
The description of rerere.enabled left the user in the dark as to who
might create an rr-cache directory.  Add a note that simply invoking
rerere does this.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-10 12:59:31 -08:00
Junio C Hamano 5de89d3abf Merge branch 'jc/show-sig'
* jc/show-sig:
  log --show-signature: reword the common two-head merge case
  log-tree: show mergetag in log --show-signature output
  log-tree.c: small refactor in show_signature()
  commit --amend -S: strip existing gpgsig headers
  verify_signed_buffer: fix stale comment
  gpg-interface: allow use of a custom GPG binary
  pretty: %G[?GS] placeholders
  test "commit -S" and "log --show-signature"
  log: --show-signature
  commit: teach --gpg-sign option

Conflicts:
	builtin/commit-tree.c
	builtin/commit.c
	builtin/merge.c
	notes-cache.c
	pretty.c
2012-01-06 12:44:07 -08:00
Junio C Hamano 21c6a18c75 Sync with 1.7.8.3 2012-01-06 12:42:48 -08:00
Junio C Hamano cfdfc5a3b2 Merge branch 'maint-1.7.7' into maint
* maint-1.7.7:
  Documentation: rerere.enabled is the primary way to configure rerere
2012-01-06 12:35:12 -08:00
Junio C Hamano 8769e93327 Merge branch 'maint-1.7.6' into maint-1.7.7
* maint-1.7.6:
  Documentation: rerere.enabled is the primary way to configure rerere
2012-01-06 12:35:05 -08:00
Thomas Rast 07b88a00c0 Documentation: rerere.enabled is the primary way to configure rerere
The wording seems to suggest that creating the directory is needed and the
setting of rerere.enabled is only for disabling the feature by setting it
to 'false'. But the configuration is meant to be the primary control and
setting it to 'true' will enable it; the rr-cache directory will be
created as necessary and the user does not have to create it.

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-06 12:27:59 -08:00
Junio C Hamano 184a541fb5 Merge branch 'jc/advice-doc'
* jc/advice-doc:
  advice: Document that they all default to true
2011-12-20 13:25:29 -08:00
Junio C Hamano 367d20ec6b Merge branch 'jk/credentials'
* jk/credentials:
  t: add test harness for external credential helpers
  credentials: add "store" helper
  strbuf: add strbuf_add*_urlencode
  Makefile: unix sockets may not available on some platforms
  credentials: add "cache" helper
  docs: end-user documentation for the credential subsystem
  credential: make relevance of http path configurable
  credential: add credential.*.username
  credential: apply helper config
  http: use credential API to get passwords
  credential: add function for parsing url components
  introduce credentials API
  t5550: fix typo
  test-lib: add test_config_global variant

Conflicts:
	strbuf.c
2011-12-19 16:05:16 -08:00
Junio C Hamano 26e94af0ba advice: Document that they all default to true
By definition, the default value of "advice.*" variables must be true and
they all control various additional help messages that are designed to aid
new users. Setting one to false is to tell Git that the user understands
the nature of the error and does not need the additional verbose help
message.

Also fix the asciidoc markup for linkgit:git-checkout[1] in the
description of the detachedHead advice by removing an excess colon.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-18 21:38:55 -08:00
Jeff King a6fc9fd3f4 docs: end-user documentation for the credential subsystem
The credential API and helper format is already defined in
technical/api-credentials.txt.  This presents the end-user
view.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-11 23:16:25 -08:00
Junio C Hamano 1ee740e669 Merge branch 'ab/pull-rebase-config'
* ab/pull-rebase-config:
  pull: introduce a pull.rebase option to enable --rebase
2011-12-09 13:37:01 -08:00
Junio C Hamano 0c5e70f041 gpg-interface: allow use of a custom GPG binary
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-29 12:30:02 -08:00
Ævar Arnfjörð Bjarmason 6b37dff17f pull: introduce a pull.rebase option to enable --rebase
Currently we either need to set branch.<name>.rebase for existing
branches if we'd like "git pull" to mean "git pull --rebase", or have
the forethought of setting "branch.autosetuprebase" before we create
the branch.

Introduce a "pull.rebase" option to globally configure "git pull" to
mean "git pull --rebase" for any branch.

This option will be considered at a lower priority than
branch.<name>.rebase, i.e. we could set pull.rebase=true and
branch.<name>.rebase=false and the latter configuration option would
win.

Reviewed-by: Sverre Rabbelier <srabbelier@gmail.com>
Reviewed-by: Fernando Vezzosi <buccia@repnz.net>
Reviewed-by: Eric Herman <eric@freesa.org>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Liked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-07 08:43:11 -08:00
Junio C Hamano a5ad8d1bdd Merge branch 'cn/eradicate-working-copy' into maint
* cn/eradicate-working-copy:
  Remove 'working copy' from the documentation and C code
2011-10-26 16:13:31 -07:00
Junio C Hamano 411e6cf197 Merge branch 'maint-1.7.6' into maint
* maint-1.7.6:
  make the sample pre-commit hook script reject names with newlines, too
  git-read-tree.txt: update sparse checkout examples
  git-read-tree.txt: correct sparse-checkout and skip-worktree description
  git-read-tree.txt: language and typography fixes
  unpack-trees: print "Aborting" to stderr
  Documentation/git-update-index: refer to 'ls-files'
  Documentation: basic configuration of notes.rewriteRef
2011-10-26 16:09:28 -07:00
Junio C Hamano 588150b023 Merge branch 'tr/doc-note-rewrite' into maint-1.7.6
* tr/doc-note-rewrite:
  Documentation: basic configuration of notes.rewriteRef
2011-10-26 16:09:04 -07:00
Junio C Hamano 9ee3d37743 Merge branch 'po/insn-editor'
* po/insn-editor:
  "rebase -i": support special-purpose editor to edit insn sheet
2011-10-21 16:04:37 -07:00
Junio C Hamano abe2773019 Merge branch 'cn/doc-config-bare-subsection'
* cn/doc-config-bare-subsection:
  Documentation: update [section.subsection] to reflect what git does
2011-10-21 16:04:33 -07:00
Junio C Hamano 380f26c29b Merge branch 'jn/gitweb-manpages'
* jn/gitweb-manpages:
  gitweb: Add gitweb manpages to 'gitweb' package in git.spec
  Documentation: Add gitweb config variables to git-config(1)
  Documentation: Link to gitweb(1) and gitweb.conf(5) in other manpages
  gitweb: Add gitweb(1) manpage for gitweb itself
  gitweb: Add gitweb.conf(5) manpage for gitweb configuration files
2011-10-18 21:59:11 -07:00
Peter Oberndorfer 821881d88d "rebase -i": support special-purpose editor to edit insn sheet
The insn sheet used by "rebase -i" is designed to be easily editable by
any text editor, but an editor that is specifically meant for it (but
is otherwise unsuitable for editing regular text files) could be useful
by allowing drag & drop reordering in a GUI environment, for example.

The GIT_SEQUENCE_EDITOR environment variable and/or the sequence.editor
configuration variable can be used to specify such an editor, while
allowing the usual editor to be used to edit commit log messages. As
usual, the environment variable takes precedence over the configuration
variable.

It is envisioned that other "sequencer" based tools will use the same
mechanism.

Signed-off-by: Peter Oberndorfer <kumbayo84@arcor.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-17 14:40:07 -07:00
Jakub Narebski cd82323fbc Documentation: Add gitweb config variables to git-config(1)
Add a list of gitweb config variables to git-config(1) manpage, just
linking to gitweb(1) or gitweb.conf(5).

Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-16 11:09:35 -07:00
Carlos Martín Nieto f737632938 Documentation: update [section.subsection] to reflect what git does
Using the [section.subsection] syntax, the subsection is transformed
to lower-case and is matched case sensitively. Say so in the
documentation and mention that you shouldn't be using it anyway.

Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-16 00:22:31 -07:00
Junio C Hamano 9a33b691aa Merge branch 'cn/eradicate-working-copy'
* cn/eradicate-working-copy:
  Remove 'working copy' from the documentation and C code
2011-10-05 12:36:26 -07:00
Junio C Hamano b5b6521645 Merge branch 'tr/doc-note-rewrite'
* tr/doc-note-rewrite:
  Documentation: basic configuration of notes.rewriteRef
2011-10-05 12:36:24 -07:00
Junio C Hamano ca0c9764bf Merge branch 'jc/fetch-pack-fsck-objects'
* jc/fetch-pack-fsck-objects:
  test: fetch/receive with fsckobjects
  transfer.fsckobjects: unify fetch/receive.fsckobjects
  fetch.fsckobjects: verify downloaded objects

Conflicts:
	Documentation/config.txt
	builtin/fetch-pack.c
2011-10-05 12:36:20 -07:00
Carlos Martín Nieto f7d650c06e Remove 'working copy' from the documentation and C code
The git term is 'working tree', so replace the most public references
to 'working copy'.

Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-21 14:26:38 -07:00
Thomas Rast 2b4aa89c27 Documentation: basic configuration of notes.rewriteRef
Users had problems finding a working setting for notes.rewriteRef.
Document how to enable rewriting for notes/commits, which should be a
safe setting.

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-13 08:35:38 -07:00
Junio C Hamano 7baf32a829 Merge branch 'jn/doc-dashdash' into maint
* jn/doc-dashdash:
  Documentation/i18n: quote double-dash for AsciiDoc
  Documentation: quote double-dash for AsciiDoc

Conflicts:
	Documentation/git-mergetool--lib.txt
2011-09-11 21:52:18 -07:00
Junio C Hamano dab76d3aa6 transfer.fsckobjects: unify fetch/receive.fsckobjects
This single variable can be used to set instead of setting fsckobjects
variable for fetch & receive independently.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-04 12:39:32 -07:00
Junio C Hamano 5e838ea7aa fetch.fsckobjects: verify downloaded objects
This corresponds to receive.fsckobjects configuration variable added (a
lot) earlier in 20dc001 (receive-pack: allow using --strict mode for
unpacking objects, 2008-02-25).

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-04 12:27:17 -07:00
Junio C Hamano 22d9b79370 Merge branch 'bw/log-all-ref-updates-doc' into maint
* bw/log-all-ref-updates-doc:
  Documentation: clearly specify what refs are honored by core.logAllRefUpdates
2011-08-16 11:41:28 -07:00
Junio C Hamano ef6663b3db Merge branch 'bw/log-all-ref-updates-doc'
* bw/log-all-ref-updates-doc:
  Documentation: clearly specify what refs are honored by core.logAllRefUpdates
2011-07-22 14:43:51 -07:00
Junio C Hamano af52e6b06a Merge branch 'jn/doc-dashdash'
* jn/doc-dashdash:
  Documentation/i18n: quote double-dash for AsciiDoc
  Documentation: quote double-dash for AsciiDoc
2011-07-13 14:31:37 -07:00
Bert Wesarg cd8e3711bf Documentation: clearly specify what refs are honored by core.logAllRefUpdates
The documentation for logging updates in git-update-ref, doesn't make it
clear that only a specific subset of refs are honored by this variable.

Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-07-12 09:11:14 -07:00
Junio C Hamano 347231f735 Merge branch 'jn/maint-doc-dashdash' into jn/doc-dashdash
* jn/maint-doc-dashdash:
  Documentation: quote double-dash for AsciiDoc
2011-06-29 09:25:51 -07:00
Jonathan Nieder 565e135a1e Documentation: quote double-dash for AsciiDoc
AsciiDoc versions since 5.0.6 treat a double-dash surrounded by spaces
(outside of verbatim environments) as a request to insert an em dash.
Such versions also treat the three-character sequence "\--", when not
followed by another dash, as a request to insert two literal minus
signs.  Thus from time to time there have been patches to add
backslashes to AsciiDoc markup to escape double-dashes that are meant
to be represent '--' characters used literally on the command line;
see v1.4.0-rc1~174, Fix up docs where "--" isn't displayed correctly,
2006-05-05, for example.

AsciiDoc 6.0.3 (2005-04-20) made life harder by also treating
double-dashes without surrounding whitespace as markup for an em dash,
though only when formatting for backends other than the manpages
(e.g., HTML).  Many pages needed to be changed to use a backslash
before the "--" in names of command-line flags like "--add" (see
v0.99.6~37, Update tutorial, 2005-08-30).

AsciiDoc 8.3.0 (2008-11-29) refined the em-dash rule to avoid that
requirement.  Double-dashes without surrounding spaces are not
rendered as em dashes any more unless bordered on both sides by
alphanumeric characters.  The unescaped markup for option names (e.g.,
"--add") works fine, and many instances of this style have leaked into
Documentation/; git's HTML documentation contains many spurious em
dashes when formatted by an older toolchain.  (This patch will not
change that.)

The upshot: "--" as an isolated word and in phrases like "git
web--browse" must be escaped if it is not to be rendered as an em dash
by current asciidoc.  Use "\--" to avoid such misformatting in
sentences in which "--" represents a literal double-minus command line
argument that separates options and revs from pathspecs, and use
"{litdd}" in cases where the double-dash is embedded in the command
name.  The latter is just for consistency with v1.7.3-rc0~13^2 (Work
around em-dash handling in newer AsciiDoc, 2010-08-23).

List of lines to fix found by grepping manpages for "(em".

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Improved-by: Junio C Hamano <gitster@pobox.com>
Improved-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-29 09:24:26 -07:00
Duncan Brown bcfb95dde4 http: pass http.cookiefile using CURLOPT_COOKIEFILE
If the config option http.cookiefile is set, pass this file to libCURL using
the CURLOPT_COOKIEFILE option. This is similar to calling curl with the -b
option.  This allows git http authorization with authentication mechanisms
that use cookies, such as SAML Enhanced Client or Proxy (ECP) used by
Shibboleth.

To use SAML/ECP, the user needs to request a session cookie with their own ECP
code. See for example:

<https://wiki.shibboleth.net/confluence/display/SHIB2/ECP>

Once the cookie file has been created, it can be passed to git with, e.g.

git config --global http.cookiefile "/home/dbrown/.curlcookies"

libCURL will then pass the appropriate session cookies to the git http server.

Signed-off-by: Duncan Brown <duncan.brown@ligo.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-03 09:29:19 -07:00
Jay Soffian 0c47695a69 Add log.abbrevCommit config variable
Add log.abbrevCommit config variable as a convenience for users who
often use --abbrev-commit with git log and friends. Allow the option
to be overridden with --no-abbrev-commit. Per 635530a2fc and 4f62c2bc57,
the config variable is ignored when log is given "--pretty=raw".

(Also, a drive-by spelling correction in git log's short help.)

Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-18 12:40:15 -07:00
Junio C Hamano 7a77754cf6 Merge branch 'ci/commit--interactive-atomic'
* ci/commit--interactive-atomic:
  Test atomic git-commit --interactive
  Add commit to list of config.singlekey commands
  Add support for -p/--patch to git-commit
  Allow git commit --interactive with paths
  t7501.8: feed a meaningful command
  Use a temporary index for git commit --interactive
2011-05-16 16:47:10 -07:00
Junio C Hamano 0c529e44d3 Merge branch 'vh/config-interactive-singlekey-doc'
* vh/config-interactive-singlekey-doc:
  git-reset.txt: better docs for '--patch'
  git-checkout.txt: better docs for '--patch'
  git-stash.txt: better docs for '--patch'
  git-add.txt: document 'interactive.singlekey'
  config.txt: 'interactive.singlekey; is used by...
2011-05-11 11:38:06 -07:00
Conrad Irwin e6b57a8a4e Add commit to list of config.singlekey commands
Signed-off-by: Conrad Irwin <conrad.irwin@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-09 17:02:33 -07:00
Junio C Hamano 76f4f74a44 Merge branch 'mg/alias-expose-prefix'
* mg/alias-expose-prefix:
  handle_alias: provide GIT_PREFIX to !alias
  t1020: test !alias in subdirectory
2011-05-06 10:49:57 -07:00
Junio C Hamano 12b99a3598 Merge branch 'mg/diff-uiconfig-doc'
* mg/diff-uiconfig-doc:
  config.txt,diff-options.txt: porcelain vs. plumbing for color.diff
2011-05-06 10:49:53 -07:00
Valentin Haenel 31be5d87a2 config.txt: 'interactive.singlekey; is used by...
The config variable 'interactive.singlekey' influences also '--patch' mode of
git-add, git-reset, and git-checkout.

Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Valentin Haenel <valentin.haenel@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-05 12:43:06 -07:00
Junio C Hamano 78c6e0f3fa Merge branch 'mz/rebase'
* mz/rebase: (34 commits)
  rebase: define options in OPTIONS_SPEC
  Makefile: do not install sourced rebase scripts
  rebase: use @{upstream} if no upstream specified
  rebase -i: remove unnecessary state rebase-root
  rebase -i: don't read unused variable preserve_merges
  git-rebase--am: remove unnecessary --3way option
  rebase -m: don't print exit code 2 when merge fails
  rebase -m: remember allow_rerere_autoupdate option
  rebase: remember strategy and strategy options
  rebase: remember verbose option
  rebase: extract code for writing basic state
  rebase: factor out sub command handling
  rebase: make -v a tiny bit more verbose
  rebase -i: align variable names
  rebase: show consistent conflict resolution hint
  rebase: extract am code to new source file
  rebase: extract merge code to new source file
  rebase: remove $branch as synonym for $orig_head
  rebase -i: support --stat
  rebase: factor out call to pre-rebase hook
  ...
2011-04-28 14:11:39 -07:00
Junio C Hamano 2a2dbd2770 Merge branch 'rr/doc-content-type'
* rr/doc-content-type:
  Documentation: Allow custom diff tools to be specified in 'diff.tool'
  Documentation: Add diff.<driver>.* to config
  Documentation: Move diff.<driver>.* from config.txt to diff-config.txt
  Documentation: Add filter.<driver>.* to config
2011-04-27 11:36:43 -07:00
Junio C Hamano 9cedd16c62 Merge branch 'jc/pack-objects-bigfile'
* jc/pack-objects-bigfile:
  Teach core.bigfilethreashold to pack-objects
2011-04-27 11:36:41 -07:00
Michael J Gruber 6999c54029 config.txt,diff-options.txt: porcelain vs. plumbing for color.diff
Reading the diff-family and config man pages one may think that the
color.diff and color.ui settings apply to all diff commands. Make it
clearer that they do not apply to the plumbing variants
diff-{files,index,tree}.

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-27 11:25:47 -07:00
Michael J Gruber 7cf16a14f5 handle_alias: provide GIT_PREFIX to !alias
Provide an environment variable GIT_PREFIX which contains the subdirectory
from which a !alias was called (i.e. 'git rev-parse --show-prefix') since
these cd to the to level directory before they are executed.

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-27 10:50:05 -07:00
Ramkumar Ramachandra 19299a84f7 Documentation: Move diff.<driver>.* from config.txt to diff-config.txt
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-06 15:19:53 -07:00
Ramkumar Ramachandra 26488f5922 Documentation: Add filter.<driver>.* to config
Although the gitattributes page contains comprehensive information
about these configuration options, they should be included in the
config documentation for completeness.

Helped-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-06 15:17:06 -07:00
Junio C Hamano 15366280c2 Teach core.bigfilethreashold to pack-objects
The pack-objects command should take notice of the object file and
refrain from attempting to delta large ones, to be consistent with
the fast-import command.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-05 20:25:49 -07:00
Junio C Hamano fa38cfc2c6 Merge branch 'maint'
* maint:
  Documentation: trivial grammar fix in core.worktree description
  gitweb: Fix parsing of negative fractional timezones in JavaScript
2011-04-04 15:02:08 -07:00
Junio C Hamano 2071fb015b Merge branch 'jl/submodule-fetch-on-demand'
* jl/submodule-fetch-on-demand:
  fetch/pull: Describe --recurse-submodule restrictions in the BUGS section
  submodule update: Don't fetch when the submodule commit is already present
  fetch/pull: Don't recurse into a submodule when commits are already present
  Submodules: Add 'on-demand' value for the 'fetchRecurseSubmodule' option
  config: teach the fetch.recurseSubmodules option the 'on-demand' value
  fetch/pull: Add the 'on-demand' value to the --recurse-submodules option
  fetch/pull: recurse into submodules when necessary

Conflicts:
	builtin/fetch.c
	submodule.c
2011-04-04 15:02:01 -07:00
SZEDER Gábor d424a47e34 Documentation: trivial grammar fix in core.worktree description
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-04 10:25:21 -07:00
Junio C Hamano be57695d77 Merge branch 'lt/default-abbrev' into maint
* lt/default-abbrev:
  Rename core.abbrevlength back to core.abbrev
  Make the default abbrev length configurable
2011-04-03 12:32:51 -07:00
Junio C Hamano b966427b53 Merge branch 'jr/grep-en-config'
* jr/grep-en-config:
  grep: allow -E and -n to be turned on by default via configuration
2011-04-01 17:56:27 -07:00
Junio C Hamano 17a0299807 Merge branch 'maint'
* maint:
  contrib/thunderbird-patch-inline: do not require bash to run the script
  t8001: check the exit status of the command being tested
  strbuf.h: remove a tad stale docs-in-comment and reference api-doc instead
  Typos: t/README
  Documentation/config.txt: make truth value of numbers more explicit
  git-pack-objects.txt: fix grammatical errors
  parse-remote: replace unnecessary sed invocation
2011-03-30 14:10:41 -07:00
Joe Ratterman b22520a37c grep: allow -E and -n to be turned on by default via configuration
Add two configration variables grep.extendedRegexp and grep.lineNumbers to
allow the user to skip typing -E and -n on the command line, respectively.

Scripts that are meant to be used by random users and/or in random
repositories now have use -G and/or --no-line-number options as
appropriately to override the settings in the repository or user's
~/.gitconfig settings. Just because the script didn't say "git grep -n" no
longer guarantees that the output from the command will not have line
numbers.

Signed-off-by: Joe Ratterman <jratt0@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-30 13:17:07 -07:00
Carlos Martín Nieto 18b19e443b Documentation/config.txt: make truth value of numbers more explicit
Change the order to 1/0 to have the same true/false order as the rest
of the possibilities for a boolean variable in order not not confuse
users.

Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-30 11:44:59 -07:00
Junio C Hamano da2584243e Merge branch 'lt/default-abbrev'
* lt/default-abbrev:
  Rename core.abbrevlength back to core.abbrev
  Make the default abbrev length configurable
2011-03-23 14:55:40 -07:00
Junio C Hamano a71f09fe3e Rename core.abbrevlength back to core.abbrev
It corresponds to --abbrev=$n command line option after all.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-20 22:26:24 -07:00
Junio C Hamano 61a6f1faec Merge branch 'jh/push-default-upstream-configname' into maint
* jh/push-default-upstream-configname:
  push.default: Rename 'tracking' to 'upstream'
2011-03-16 16:47:26 -07:00
Linus Torvalds dce9648916 Make the default abbrev length configurable
The default of 7 comes from fairly early in git development, when
seven hex digits was a lot (it covers about 250+ million hash
values). Back then I thought that 65k revisions was a lot (it was what
we were about to hit in BK), and each revision tends to be about 5-10
new objects or so, so a million objects was a big number.

These days, the kernel isn't even the largest git project, and even
the kernel has about 220k revisions (_much_ bigger than the BK tree
ever was) and we are approaching two million objects. At that point,
seven hex digits is still unique for a lot of them, but when we're
talking about just two orders of magnitude difference between number
of objects and the hash size, there _will_ be collisions in truncated
hash values. It's no longer even close to unrealistic - it happens all
the time.

We should both increase the default abbrev that was unrealistically
small, _and_ add a way for people to set their own default per-project
in the git config file.

This is the first step to first make it configurable; the default of 7
is not raised yet.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-11 14:42:54 -08:00
Junio C Hamano adfe4e1ff2 Merge branch 'maint'
* maint:
  Revert "core.abbrevguard: Ensure short object names stay unique a bit longer"
2011-03-10 22:45:49 -08:00