In addition to the choice from "rebase, merge, or checkout-detach",
allow a custom command to be used in "submodule update" to update
the working tree of submodules.
* cp/submodule-custom-update:
submodule update: allow custom command to update submodule working tree
"git format-patch" learned "--from[=whom]" option, which sets the
"From: " header to the specified person (or the person who runs the
command, if "=whom" part is missing) and move the original author
information to an in-body From: header as necessary.
* jk/format-patch-from:
teach format-patch to place other authors into in-body "From"
pretty.c: drop const-ness from pretty_print_context
This reverts commit dacd2bcc41.
"It fails reliably without corrupting the receiving repository when
it should fail" may be better than the situation before the receiving
end was hardened recently, but the fact that sometimes the push does
not go through still remains. It is better to advice the users that
they cannot push from a shallow repository as a limitation before
they decide to use (or not to use) a shallow clone.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Introduce command check-mailmap, similar to check-attr and check-ignore,
which allows direct testing of .mailmap configuration.
As plumbing accessible to scripts and other porcelain, check-mailmap
publishes the stable, well-tested .mailmap functionality employed by
built-in Git commands. Consequently, script authors need not
re-implement .mailmap functionality manually, thus avoiding potential
quirks and behavioral differences.
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
An Gitweb installation that is a part of larger site can optionally
show extra links that point at the levels higher than the Gitweb
pages itself in the link hierarchy of pages.
* tf/gitweb-extra-breadcrumbs:
gitweb: allow extra breadcrumbs to prefix the trail
The document says one cannot push from a shallow clone. But that is
not true (maybe it was at some point in the past). The client does not
stop such a push nor does it give any indication to the receiver that
this is a shallow push. If the receiver accepts it, it's in.
Since 52fed6e (receive-pack: check connectivity before concluding "git
push" - 2011-09-02), receive-pack is prepared to deal with broken
push, a shallow push can't cause any corruption. Update the document
to reflect that.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This can be used to read configuration values directly from git's
database. For example it is useful for reading to be checked out
.gitmodules files directly from the database.
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If we get an input line to --batch or --batch-check that
looks like "HEAD foo bar", we will currently feed the whole
thing to get_sha1(). This means that to use --batch-check
with `rev-list --objects`, one must pre-process the input,
like:
git rev-list --objects HEAD |
cut -d' ' -f1 |
git cat-file --batch-check
Besides being more typing and slightly less efficient to
invoke `cut`, the result loses information: we no longer
know which path each object was found at.
This patch teaches cat-file to split input lines at the
first whitespace. Everything to the left of the whitespace
is considered an object name, and everything to the right is
made available as the %(reset) atom. So you can now do:
git rev-list --objects HEAD |
git cat-file --batch-check='%(objectsize) %(rest)'
to collect object sizes at particular paths.
Even if %(rest) is not used, we always do the whitespace
split (which means you can simply eliminate the `cut`
command from the first example above).
This whitespace split is backwards compatible for any
reasonable input. Object names cannot contain spaces, so any
input with spaces would have resulted in a "missing" line.
The only input hurt is if somebody really expected input of
the form "HEAD is a fine-looking ref!" to fail; it will now
parse HEAD, and make "is a fine-looking ref!" available as
%(rest).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This atom is just like %(objectsize), except that it shows
the on-disk size of the object rather than the object's true
size. In other words, it makes the "disk_size" query of
sha1_object_info_extended available via the command-line.
This can be used for rough attribution of disk usage to
particular refs, though see the caveats in the
documentation.
This patch does not include any tests, as the exact numbers
returned are volatile and subject to zlib and packing
decisions. We cannot even reliably guarantee that the
on-disk size is smaller than the object content (though in
general this should be the case for non-trivial objects).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The `cat-file --batch-check` command can be used to quickly
get information about a large number of objects. However, it
provides a fixed set of information.
This patch adds an optional <format> option to --batch-check
to allow a caller to specify which items they are interested
in, and in which order to output them. This is not very
exciting for now, since we provide the same limited set that
you could already get. However, it opens the door to adding
new format items in the future without breaking backwards
compatibility (or forcing callers to pay the cost to
calculate uninteresting items).
Since the --batch option shares code with --batch-check, it
receives the same feature, though it is less likely to be of
interest there.
The format atom names are chosen to match their counterparts
in for-each-ref. Though we do not (yet) share any code with
for-each-ref's formatter, this keeps the interface as
consistent as possible, and may help later on if the
implementations are unified.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git stash save" is not just about "saving" the local changes, but
also is to restore the working tree state to that of HEAD. If you
changed a non-directory into a directory in the local change, you
may have untracked files in that directory, which have to be killed
while doing so, unless you run it with --include-untracked. Teach
the command to detect and error out before spreading the damage.
This needed a small fix to "ls-files --killed".
* pb/stash-refuse-to-kill:
git stash: avoid data loss when "git stash save" kills a directory
treat_directory(): do not declare submodules to be untracked
"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
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
Since git-pull learned the --rebase option it has not just been about
merging changes from a remote repository (where "merge" is in the sense
of "git merge"). Change the description to use "integrate" instead of
"merge" in order to reflect this.
Signed-off-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In order to clarify which value is used when there are multiple values
defined for a key, re-order the list of file locations so that it runs
from least specific to most specific. Then add a paragraph which simply
says that the last value will be used.
Signed-off-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The default similarity index of 50% is documented in gitdiffcore(7)
but it is worth also mentioning it in the description of the
-M/--find-renames option.
Signed-off-by: Fraser Tweedale <frase@frase.id.au>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There are often parent pages logically above the gitweb projects
list, e.g. home pages of the organization and department that host
the gitweb server. This change allows you to include links to those
pages in gitweb's breadcrumb trail.
Signed-off-by: Tony Finch <dot@dotat.at>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Acked-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Fix a typo ("remote remote-tracking") going back to the big cleanup
in 2010 (8b3f3f84 etc). Also, remove some more occurrences of
"tracking" and "remote tracking" in favor of "remote-tracking".
Signed-off-by: Michael Schubert <mschub@elegosoft.com>
Reviewed-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Format-patch generates emails with the "From" address set to the
author of each patch. If you are going to send the emails, however,
you would want to replace the author identity with yours (if they
are not the same), and bump the author identity to an in-body
header.
Normally this is handled by git-send-email, which does the
transformation before sending out the emails. However, some
workflows may not use send-email (e.g., imap-send, or a custom
script which feeds the mbox to a non-git MUA). They could each
implement this feature themselves, but getting it right is
non-trivial (one must canonicalize the identities by reversing any
RFC2047 encoding or RFC822 quoting of the headers, which has caused
many bugs in send-email over the years).
This patch takes a different approach: it teaches format-patch a
"--from" option which handles the ident check and in-body header
while it is writing out the email. It's much simpler to do at this
level (because we haven't done any quoting yet), and any workflow
based on format-patch can easily turn it on.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since commit 00b347d (git-config: do not complain about duplicate
entries, 2012-10-23), "git config --get" does not exit with an error if
there are multiple values for the specified key but instead returns the
last value. Update the documentation to reflect this.
Signed-off-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add the --depth option to the add and update commands of "git submodule",
which is then passed on to the clone command. This is useful when the
submodule(s) are huge and you're not really interested in anything but
the latest commit.
Tests are added and some indention adjustments were made to conform to the
rest of the testfile on "submodule update can handle symbolic links in pwd".
Signed-off-by: Fredrik Gustafsson <iveqy@iveqy.com>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Users can set submodule.$name.update to '!command' which will cause
'command' to be run instead of checkout/merge/rebase. This allows
the user finer-grained control over how the update is done.
The primary motivation for this was interoperability with stgit;
however being able to intercept the submodule update process may
prove useful for integrating with or extending other tools.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"stash save" is about saving the local change to the working tree,
but also about restoring the state of the last commit to the working
tree. When a local change is to turn a non-directory to a directory,
in order to restore the non-directory, everything in the directory
needs to be removed.
Which is fine when running "git stash save --include-untracked",
but without that option, untracked, newly created files in the
directory will have to be discarded, if the state you are restoring
to has a non-directory at the same path as the directory.
Introduce a safety valve to fail the operation in such case, using
the "ls-files --killed" which was designed for this exact purpose.
The "stash save" is stopped when untracked files need to be
discarded because their leading path ceased to be a directory, and
the user is required to pass --force to really have the data
removed.
Signed-off-by: Petr Baudis <pasky@ucw.cz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The original way to specify remote repository using .git/branches/
used to have a nifty feature. The code to support the feature was
still in a function but the caller was changed not to call it 5
years ago, breaking that feature and leaving the supporting code
unreachable.
* rr/remote-branch-config-refresh:
t/t5505-remote: test multiple push/pull in remotes-file
ls-remote doc: don't encourage use of branches-file
ls-remote doc: rewrite <repository> paragraph
ls-remote doc: fix example invocation on git.git
t/t5505-remote: test url-with-# in branches-file
remote: remove dead code in read_branches_file()
t/t5505-remote: use test_path_is_missing
t/t5505-remote: test push-refspec in branches-file
t/t5505-remote: modernize style
Having multiple "fixup!" on a line in the rebase instruction sheet
did not work very well with "git rebase -i --autosquash".
* ap/rebase-multiple-fixups:
lib-rebase: style: use write_script, <<-\EOF
rebase -i: handle fixup! fixup! in --autosquash
Update documentation to match more recent realities.
* wk/doc-in-linux-3.x-era:
Documentation: Update 'linux-2.6.git' -> 'linux.git'
Documentation: Update the NFS remote examples to use the staging repo
doc/clone: Pick more compelling paths for the --reference example
doc/clone: Remove the '--bare -l -s' example
"git log" learned the "--author-date-order" option, with which the
output is topologically sorted and commits in parallel histories
are shown intermixed together based on the author timestamp.
* jc/topo-author-date-sort:
t6003: add --author-date-order test
topology tests: teach a helper to set author dates as well
t6003: add --date-order test
topology tests: teach a helper to take abbreviated timestamps
t/lib-t6000: style fixes
log: --author-date-order
sort-in-topological-order: use prio-queue
prio-queue: priority queue of pointers to structs
toposort: rename "lifo" field
* maint:
Start preparing for 1.8.3.3
check-ignore doc: fix broken link to ls-files page
test: spell 'ls-files --delete' option correctly in test descriptions
"git diff" learned a mode that ignores hunks whose change consists
only of additions and removals of blank lines, which is the same as
"diff -B" (ignore blank lines) of GNU diff.
* ap/diff-ignore-blank-lines:
diff: add --ignore-blank-lines option
"git name-rev --refs=tags/v*" were forbidden, which was a bit
inconvenient (you had to give a pattern to match refs fully, like
--refs=refs/tags/v*).
* nk/name-rev-abbreviated-refs:
name-rev: allow to specify a subpath for --refs option
Allow various subcommands of "git submodule" to be run not from the
top of the working tree of the superproject.
* jk/submodule-subdirectory-ok:
submodule: drop the top-level requirement
rev-parse: add --prefix option
submodule: show full path in error message
t7403: add missing && chaining
t7403: modernize style
t7401: make indentation consistent
* jh/checkout-auto-tracking:
glossary: Update and rephrase the definition of a remote-tracking branch
branch.c: Validate tracking branches with refspecs instead of refs/remotes/*
t9114.2: Don't use --track option against "svn-remote"-tracking branches
t7201.24: Add refspec to keep --track working
t3200.39: tracking setup should fail if there is no matching refspec.
checkout: Use remote refspecs when DWIMming tracking branches
t2024: Show failure to use refspec when DWIMming remote branch names
t2024: Add tests verifying current DWIM behavior of 'git checkout <branch>'
Finishing touches for the "git rebase --autostash" feature
introduced earlier.
* rr/rebase-stash-store:
rebase: use 'git stash store' to simplify logic
stash: introduce 'git stash store'
stash: simplify option parser for create
stash doc: document short form -p in synopsis
stash doc: add a warning about using create
In rebase -i --autosquash, ignore all "fixup! " or "squash! " after the
first. This supports the case when a git commit --fixup/--squash referred
to an earlier fixup/squash instead of the original commit (whether
intentionally, as when the user expressly meant to note that the commit
fixes an earlier fixup; or inadvertently, as when the user meant to refer to
the original commit with :/msg; or out of laziness, as when the user could
remember how to refer to the fixup but not the original).
In the todo list, the full commit message is preserved, in case it provides
useful cues to the user. A test helper set_cat_todo_editor is introduced to
check this.
Helped-by: Thomas Rast <trast@inf.ethz.ch>
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Andrew Pimlott <andrew@pimlott.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git am was previously modified to provide --continue for consistency
with rebase, merge etc, and the documentation changed to showing
--continue as the primary form.
Complete the work by replacing remaining uses of --resolved by
--continue, most notably in suggested command reminders.
Signed-off-by: Kevin Bracey <kevin@bracey.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
On Cygwin, recognize "cygstart" as a possible way to start a web
browser (used in "help -w" and "instaweb" among others).
* ys/cygstart:
web--browse: support /usr/bin/cygstart on Cygwin
The fact that the git:// transport does no authentication is easily
overlooked. For example, DNS poisoning may result in fetching from
somewhere that was not intended.
Add a brief security notice to the "GIT URLS" section
of the documentation stating that the git transport should be used
with caution on unsecured networks.
Signed-off-by: Fraser Tweedale <frase@frase.id.au>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add new section "Interactive mode" for documentation of interactive
git-clean.
Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>
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>
Show what would be done and the user must confirm before actually
cleaning.
Would remove ...
Would remove ...
Would remove ...
Remove [y/n]?
Press "y" to start cleaning, and press "n" if you want to abort.
Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>
For now, comment out the description on two "git status" UI
configuration, until the reverted topic can be resurrected.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Makefile cleanup.
* jk/doc-build-move-infordir-def:
Documentation/Makefile: move infodir to be with other '*dir's
Documentation/Makefile: fix spaces around assignments
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
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>
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>
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>
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.
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>
"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
One outdated example encourages the use of $GIT_DIR/branches files.
Replace it with an equivalent example using a remote.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Replace the <repository> paragraph containing specific references to
$GIT_DIR/branches and "." with a generic urls-or-remotes paragraph
referencing the relevant sections in the git-fetch(1) manpage.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Under the EXAMPLES section, there is one invocation on the git.git
repository that attempts to list the refs master, pu, and rc. The ref
rc does not exist in today's repository, so remove it. Among other
things, this example demonstrates that the "<refs>..." argument is
simply a filter; requesting a non-existent ref is not an error.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The 3.x tree has been out for a while now. The -2.6 repository name
survived the initial release [1], but kernel.org now only lists
'linux.git' (for aegl as well as torvalds) [2].
[1]: http://article.gmane.org/gmane.linux.kernel/1147422
On 2011-05-30 01:47:57 GMT, Linus Torvalds wrote:
> ... yes, that means that my git tree is still called
> "linux-2.6.git" on kernel.org.
[2]: http://git.kernel.org/cgit/
Signed-off-by: W. Trevor King <wking@tremily.us>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
linux-nfs.org seems to have restructured their repository layout since
8391c60 (git-remote.txt: fix example url, 2007-11-02), and Bruce's
repo is now at git://git.linux-nfs.org/projects/bfields/linux.git.
Bruce also has a more richer internal branch structure (master,
everything, for-3.1, ...), so updating the existing example to use his
current repo may be confusing.
To simplify, I've replaced the NFS repo with Greg's staging repo.
I've also updated the output of the surrounding commands to match the
output of a current run through.
Signed-off-by: W. Trevor King <wking@tremily.us>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There may be times when using one of your local repositories as a
reference for a new clone make sense, but the implied version-bump in
the old example isn't one of them. I think a more intuitive example
is multi-user system with a central reference clone, and the new paths
hint at this use case.
Signed-off-by: W. Trevor King <wking@tremily.us>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There are other examples in git-clone.txt demonstrating both '--bare'
and '-l -s'.
Signed-off-by: W. Trevor King <wking@tremily.us>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
While both GUI and console Cygwin browsers do exist, anecdotal evidence
suggests most users rely on their native Windows browser. cygstart,
which is a long-standing part of the base Cygwin installation, will
cause the page to be opened in the default Windows browser (the one
registered to open .html files).
Signed-off-by: Yaakov Selkowitz <yselkowitz@users.sourceforge.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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
The goal of the patch is to introduce the GNU diff
-B/--ignore-blank-lines as closely as possible. The short option is not
available because it's already used for "break-rewrites".
When this option is used, git-diff will not create hunks that simply
add or remove empty lines, but will still show empty lines
addition/suppression if they are close enough to "valuable" changes.
There are two differences between this option and GNU diff -B option:
- GNU diff doesn't have "--inter-hunk-context", so this must be handled
- The following sequence looks like a bug (context is displayed twice):
$ seq 5 >file1
$ cat <<EOF >file2
change
1
2
3
4
5
change
EOF
$ diff -u -B file1 file2
--- file1 2013-06-08 22:13:04.471517834 +0200
+++ file2 2013-06-08 22:13:23.275517855 +0200
@@ -1,5 +1,7 @@
+change
1
2
+
3
4
5
@@ -3,3 +5,4 @@
3
4
5
+change
So here is a more thorough description of the option:
- real changes are interesting
- blank lines that are close enough (less than context size) to
interesting changes are considered interesting (recursive definition)
- "context" lines are used around each hunk of interesting changes
- If two hunks are separated by less than "inter-hunk-context", they
will be merged into one.
The implementation does the "interesting changes selection" in a single
pass.
Signed-off-by: Antoine Pelisse <apelisse@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When an user wants to filter specific ref using the --refs option,
the pattern needs to match the full ref, e.g. --refs=refs/tags/v1.*.
It'd be convenient to specify a subpath of ref pattern. For
example, --refs=origin/* can find refs/remotes/origin/master by
searching the pattern against its substrings in turn:
refs/remotes/origin/master
remotes/origin/master
origin/master
If it finds a match in a subpath, unambigous part of the ref path will
be removed in the output.
Signed-off-by: Namhyung Kim <namhyung.kim@lge.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation and some comments still refer to files in builtin/
as 'builtin-*.[cho]'. Update these to show the correct location.
Signed-off-by: Phil Hord <hordp@cisco.com>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Assisted-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The section describing "git diff <blob> <blob>" had been placed in a
position that disrupted the statement "This is synonymous to the
previous form".
Reorder to place this form after all the <commit>-using forms, and the
note applying to them. Also mention this form in the initial description
paragraph.
Signed-off-by: Kevin Bracey <kevin@bracey.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 35d2fffd introduced 'git merge --abort' as a synonym to 'git reset
--merge', and added some failing tests in t7611-merge-abort.sh (search
'###' in this file) showing that 'git merge --abort' could not always
recover the pre-merge state.
Still, in many cases, 'git merge --abort' just works, and it is usually
considered that the ability to start a merge with uncommited changes is
an important property of Git.
Weaken the warning by discouraging only merge with /non-trivial/
uncommited changes.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The behavior of "git push --force" is rather clear when it updates only
one remote ref, but running it when pushing several branches can really
be dangerous. Warn the users a bit more and give them the alternative to
push only one branch.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This makes 'git rev-parse' behave as if it were invoked from the
specified subdirectory of a repository, with the difference that any
file paths which it prints are prefixed with the full path from the top
of the working tree.
This is useful for shell scripts where we may want to cd to the top of
the working tree but need to handle relative paths given by the user on
the command line.
Signed-off-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It was missed in the option list while mentioned from the general
description. Add it for completeness.
Signed-off-by: Namhyung Kim <namhyung@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
save_stash() contains the logic for doing two potentially independent
operations; the first is preparing the stash merge commit, and the
second is updating the stash ref/ reflog accordingly. While the first
operation is abstracted out into a create_stash() for callers to access
via 'git stash create', the second one is not. Fix this by factoring
out the logic for storing the stash into a store_stash() that callers
can access via 'git stash store'.
Like create, store is not intended for end user interactive use, but for
callers in other scripts. We can simplify the logic in the
rebase.autostash feature using this new subcommand.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
'git stash save' can take -p, the short form of --patch, as an option.
Document this.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add a note saying that the user probably wants "save" in the create
description. While at it, document that it can optionally take a
message in the synopsis.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>
Major update to the revision traversal logic to improve culling of
irrelevant parents while traversing a mergy history.
* kb/full-history-compute-treesame-carefully-2:
revision.c: make default history consider bottom commits
revision.c: don't show all merges for --parents
revision.c: discount side branches when computing TREESAME
revision.c: add BOTTOM flag for commits
simplify-merges: drop merge from irrelevant side branch
simplify-merges: never remove all TREESAME parents
t6012: update test for tweaked full-history traversal
revision.c: Make --full-history consider more merges
Documentation: avoid "uninteresting"
rev-list-options.txt: correct TREESAME for P
t6111: add parents to tests
t6111: allow checking the parents as well
t6111: new TREESAME test set
t6019: test file dropped in -s ours merge
decorate.c: compact table when growing
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>
Sometimes people would want to view the commits in parallel
histories in the order of author dates, not committer dates.
Teach "topo-order" sort machinery to do so, using a commit-info slab
to record the author dates of each commit, and prio-queue to sort
them.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>
* rr/rebase-autostash:
rebase: implement --[no-]autostash and rebase.autostash
rebase --merge: return control to caller, for housekeeping
rebase -i: return control to caller, for housekeeping
am: return control to caller, for housekeeping
rebase: prepare to do generic housekeeping
rebase -i: don't error out if $state_dir already exists
am: tighten a conditional that checks for $dotest
Update the low-level diffcore documentation on -S/-G and --pickaxe-all.
* rr/diffcore-pickaxe-doc:
diffcore-pickaxe doc: document -S and -G properly
diffcore-pickaxe: make error messages more consistent
These days, "git --work-tree=there cmd" without specifying an
explicit --git-dir=here will do the usual discovery, but we had a
description of older behaviour in the documentation.
* cr/git-work-tree-sans-git-dir:
git.txt: remove stale comment regarding GIT_WORK_TREE
Primarily to push out two regression issues that seem to affect many
people, namely, the ".gitignore !directory" bug and "daemon cannot
read from $HOME owned by root" bug.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>
"This can help with debugging object negotiation or other protocol
issues."
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5f44324 (core: log offset pack data accesses happened - 2011-07-06)
provides a way to observe pack access patterns via a config
switch. Setting an environment variable looks more obvious than a
config var, especially when you just need to _observe_, and more
inline with other tracing knobs we have.
Document it as it may be useful for remote troubleshooting.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A note in the beginning of this document describes the behavior already.
This patch just adds where to find the repositories.
Signed-off-by: Fredrik Gustafsson <iveqy@iveqy.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When explaining the "--tags" option as an equivalent to giving an
explicit "refs/tags/*:refs/tags/*" refspec, the two asterisks were
misinterpreted by AsciiDoc as a request to typeset the string
segment between them in bold.
We could fix it in two ways. We can replace them with {asterisk}s
while keeping the string as body text, or we can mark it as a
literal string with backquotes around it.
Let's do the latter, as it is teaching the user an "exactly as
typed" alternative.
Noticed-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Special case "git clone" and use lighter-weight implementation to
check the completeness of the history behind refs.
* nd/clone-connectivity-shortcut:
clone: open a shortcut for connectivity check
index-pack: remove dead code (it should never happen)
fetch-pack: prepare updated shallow file before fetching the pack
clone: let the user know when check_everything_connected is run
The documentation of -S and -G is very sketchy. Completely rewrite the
sections in Documentation/diff-options.txt and
Documentation/gitdiffcore.txt.
References:
52e9578 ([PATCH] Introducing software archaeologist's tool "pickaxe".)
f506b8e (git log/diff: add -G<regexp> that greps in the patch text)
Inputs-from: Phil Hord <phil.hord@gmail.com>
Co-authored-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Official support for specifying --work-tree/GIT_WORK_TREE without
--git-dir/GIT_DIR was added with v1.7.4-rc3~2^2~2. Update description
of GIT_WORK_TREE to reflect this.
Signed-off-by: Chris Rorvick <chris@rorvick.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* tr/line-log:
git-log(1): remove --full-line-diff description
line-log: fix documentation formatting
log -L: improve comments in process_all_files()
log -L: store the path instead of a diff_filespec
log -L: test merge of parallel modify/rename
t4211: pass -M to 'git log -M -L...' test
log -L: fix overlapping input ranges
log -L: check range set invariants when we look it up
Speed up log -L... -M
log -L: :pattern:file syntax to find by funcname
Implement line-history search (git log -L)
Export rewrite_parents() for 'log -L'
Refactor parse_loc
"git fetch origin master" unlike "git fetch origin" or "git fetch"
did not update "refs/remotes/origin/master"; this was an early
design decision to keep the update of remote tracking branches
predictable, but in practice it turns out that people find it more
convenient to opportunisticly update them whenever we have a chance,
and we have been updating them when we run "git push" which already
breaks the original "predictability" anyway.
Now such a fetch does update refs/remotes/origin/master.
* jk/fetch-always-update-tracking:
fetch: don't try to update unfetched tracking refs
fetch: opportunistically update tracking refs
refactor "ref->merge" flag
fetch/pull doc: untangle meaning of bare <ref>
t5510: start tracking-ref tests from a known state
"git clone foo/bar:baz" cannot be a request to clone from a remote
over git-over-ssh specified in the scp style. Detect this case and
clone from a local repository at "foo/bar:baz".
* nd/clone-local-with-colon:
clone: allow cloning local paths with colons in them
