When running log/show/whatchanged from the command line, the user may
want to use a preferred format without having to pass --pretty=<fmt>
option every time from the command line. This teaches these three
commands to honor a new configuration variable, format.pretty.
The --pretty option given from the command line will override the
configured format.
The earlier patch fixed the in-tree callers that run these commands
for purposes other than showing the output directly to the end user
(the only other in-tree caller is "git bisect visualize", whose output
directly goes to the end user and should be affected by this patch).
Similar fixes will be needed for end-user scripts that parse the
output from these commands and expect them to be in the default pretty
format.
Signed-off-by: Denis Cheng <crquan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The documentation had its own description for --pretty and did not
include pretty-options/formats as documentation for other commands in
the "log" family did.
Signed-off-by: Denis Cheng <crquan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It has been supported for a long time, but I do not think this feature has
been in use in the real world at all. We would eventually move this out
of the toplevel of the work tree and to somewhere under $GIT_DIR, so let's
remove the command line option to specify the location now.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The new protocol extension "include-tag" allows the client side
of the connection (fetch-pack) to request that the server side of the
native git protocol (upload-pack / pack-objects) use --include-tag
as it prepares the packfile, thus ensuring that an annotated tag object
will be included in the resulting packfile if the object it refers to
was also included into the packfile.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The new option "--include-tag" allows the caller to request that
any annotated tag be included into the packfile if the object the tag
references was also included as part of the packfile.
This option can be useful on the server side of a native git transport,
where the server knows what commits it is including into a packfile to
update the client. If new annotated tags have been introduced then we
can also include them in the packfile, saving the client from needing
to request them through a second connection.
This change only introduces the backend option and provides a test.
Protocol extensions to make this useful in fetch-pack/upload-pack
are still necessary to activate the logic during transport.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
Fix 'git remote show' regression on empty repository in 1.5.4
Fix incorrect wording in git-merge.txt.
git-merge.sh: better handling of combined --squash,--no-ff,--no-commit options
Fix random crashes in http_cleanup()
A merge is not necessarily with a remote branch, it can be with any
commit.
Thanks to Paolo Ciarrocchi for pointing out the problem, and to
Nicolas Pitre for pointing out the fact that a merge is not
necessarily with a branch head.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* commit '74359821': (128 commits)
tests: introduce test_must_fail
Fix builtin checkout crashing when given an invalid path
templates/Makefile: don't depend on local umask setting
Correct name of diff_flush() in API documentation
Start preparing for 1.5.4.4
format-patch: remove a leftover debugging message
completion: support format-patch's --cover-letter option
Eliminate confusing "won't bisect on seeked tree" failure
builtin-reflog.c: don't install new reflog on write failure
send-email: fix In-Reply-To regression
git-svn: Don't prompt for client cert password everytime.
git.el: Do not display empty directories.
Fix 'git cvsexportcommit -w $cvsdir ...' when used with relative $GIT_DIR
Add testcase for 'git cvsexportcommit -w $cvsdir ...' with relative $GIT_DIR
Prompt to continue when editing during rebase --interactive
Documentation/git svn log: add a note about timezones.
git-p4: Support usage of perforce client spec
git-p4: git-p4 submit cleanups.
git-p4: Removed git-p4 submit --direct.
git-p4: Clean up git-p4 submit's log message handling.
...
* maint:
Update draft release notes for 1.5.4.4
revert: actually check for a dirty index
tests: introduce test_must_fail
git-submodule: Fix typo 'url' which should be '$url'
receive-pack: Initialize PATH to include exec-dir.
Conflicts:
builtin-revert.c
* np/verify-pack:
add storage size output to 'git verify-pack -v'
fix unimplemented packed_object_info_detail() features
make verify_one_pack() a bit less wrong wrt packed_git structure
factorize revindex code out of builtin-pack-objects.c
Conflicts:
Makefile
* pb/cvsimport:
cvsimport: document that -M can be used multiple times
cvsimport: allow for multiple -M options
cvsimport: have default merge regex allow for dashes in the branch name
* mk/maint-parse-careful:
receive-pack: use strict mode for unpacking objects
index-pack: introduce checking mode
unpack-objects: prevent writing of inconsistent objects
unpack-object: cache for non written objects
add common fsck error printing function
builtin-fsck: move common object checking code to fsck.c
builtin-fsck: reports missing parent commits
Remove unused object-ref code
builtin-fsck: move away from object-refs to fsck_walk
add generic, type aware object chain walker
Conflicts:
Makefile
builtin-fsck.c
The --max-age=<timestamp> and --min-age=<timestamp> are now shown only
in the git-rev-list manpage (plumbing).
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Our scripts try to stick to fairly limited subset of POSIX BRE for
portability. It is unclear from manual page from GNU grep which is GNU
extension and which is portable, so let's spell it out to help new people
to keep their contributions from hurting porters.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This can possibly break external scripts that depend on the previous
output, but those script can't possibly be critical to Git usage, and
fixing them should be trivial.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Also document the capture behaviour (source branch name in $1)
Signed-off-by: Philippe Bruhat (BooK) <book@cpan.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
Documentation cherry-pick: Fix cut-and-paste error
git.el: find the git-status buffer whatever its name is
git-gui: Paper bag fix info dialog when no files are staged at commit
These flags are already known to rev-parse and have the same meaning.
This patch allows to run gitk as follows:
gitk --branches --not --remotes
to show only your local work.
Signed-off-by: Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
templates/Makefile: don't depend on local umask setting
Correct name of diff_flush() in API documentation
Start preparing for 1.5.4.4
Conflicts:
RelNotes
Adds strict option, which bails out if the pack would
introduces broken object or links in the repository.
Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch introduces a strict mode, which ensures that:
- no malformed object will be written
- no object with broken links will be written
The patch ensures this by delaying the write of all non blob object.
These object are written, after all objects they link to are written.
An error can only result in unreferenced objects.
Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
Eliminate confusing "won't bisect on seeked tree" failure
builtin-reflog.c: don't install new reflog on write failure
send-email: fix In-Reply-To regression
Fix 'git cvsexportcommit -w $cvsdir ...' when used with relative $GIT_DIR
Add testcase for 'git cvsexportcommit -w $cvsdir ...' with relative $GIT_DIR
Prompt to continue when editing during rebase --interactive
Documentation/git svn log: add a note about timezones.
Don't use GIT_CONFIG in t5505-remote
Conflicts:
t/t9001-send-email.sh
t/t9200-git-cvsexportcommit.sh
* db/cover-letter:
Improve collection of information for format-patch --cover-letter
Add API access to shortlog
t4014: Replace sed's non-standard 'Q' by standard 'q'
Support a --cc=<email> option in format-patch
Combine To: and Cc: headers
Fix format.headers not ending with a newline
Add tests for extra headers in format-patch
Add a --cover-letter option to format-patch
Export some email and pretty-printing functions
Improve message-id generation flow control for format-patch
Add more tests for format-patch
Conflicts:
builtin-log.c
builtin-shortlog.c
pretty.c
* ae/pack-autothread:
Revert "pack-objects: Print a message describing the number of threads for packing"
pack-objects: Print a message describing the number of threads for packing
pack-objects: Add runtime detection of online CPU's
* sp/describe:
Use git-describe --exact-match in bash prompt on detached HEAD
Teach git-describe --exact-match to avoid expensive tag searches
Avoid accessing non-tag refs in git-describe unless --all is requested
Teach git-describe to use peeled ref information when scanning tags
Optimize peel_ref for the current ref of a for_each_ref callback
git svn log mimics the timezone converting behaviour of svn log, but
this was undocumented.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add support for -F | --fixed-strings option to "git log --grep"
and friends: "git log --author", "git log --committer=<pattern>".
Code is based on implementation of this option in "git grep".
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
Documentation/git-am.txt: Pass -r in the example invocation of rm -f .dotest
timezone_names[]: fixed the tz offset for New Zealand.
filter-branch documentation: non-zero exit status in command abort the filter
rev-parse: fix potential bus error with --parseopt option spec handling
Use a single implementation and API for copy_file()
Documentation/git-filter-branch: add a new msg-filter example
Correct fast-export file mode strings to match fast-import standard
Since commit 8c1ce0f46b filter-branch fails
when a <command> has a non-zero exit status. This commit makes it clear
in the documentation and also fixes the parent-filter example, that was
incorrectly returning non-zero when the commit being tested wasn't the
one to be rewritten.
Signed-off-by: Caio Marcelo de Oliveira Filho <cmarcelo@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is useful when you want to see parts of the commit object name
in "describe" output, even when the commit in question happens to be
a tagged version. Instead of just emitting the tag name, it will
describe such a commit as v1.2-0-deadbeef (0th commit since tag v1.2
that points at object deadbeef....).
Signed-off-by: Santi Béjar <sbejar@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There were no example on how to edit commit messages, so add an msg-filter
example.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Earlier we had a cop-out in the documentation to make the
behaviour "undefined" if configuration had more than one
insteadOf that would match the target URL, like this:
[url "git://git.or.cz/"]
insteadOf = "git.or.cz:" ; (1)
insteadOf = "repo.or.cz:" ; (2)
[url "/local/mirror/"]
insteadOf = "git.or.cz:myrepo" ; (3)
insteadOf = "repo.or.cz:" ; (4)
It would be most natural to take the longest and first match, i.e.
- rewrite "git.or.cz:frotz" to "git://git.or.cz/frotz" by using
(1),
- rewrite "git.or.cz:myrepo/xyzzy" to "/local/mirror/xyzzy" by favoring
(3) over (1), and
- rewrite "repo.or.cz:frotz" to "git://git.or.cz/frotz" by
favoring (2) over (4).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This allows users with different preferences for access methods to the
same remote repositories to rewrite each other's URLs by pattern
matching across a large set of similiarly set up repositories to each
get the desired access.
For example, if you don't have a kernel.org account, you might want
settings like:
[url "git://git.kernel.org/pub/"]
insteadOf = master.kernel.org:/pub
Then, if you give git a URL like:
master.kernel.org:/pub/scm/linux/kernel/git/linville/wireless-2.6.git
it will act like you gave it:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
and you can cut-and-paste pull requests in email without fixing them
by hand, for example.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jc/apply-whitespace:
ws_fix_copy(): move the whitespace fixing function to ws.c
apply: do not barf on patch with too large an offset
core.whitespace: cr-at-eol
git-apply --whitespace=fix: fix whitespace fuzz introduced by previous run
builtin-apply.c: pass ws_rule down to match_fragment()
builtin-apply.c: move copy_wsfix() function a bit higher.
builtin-apply.c: do not feed copy_wsfix() leading '+'
builtin-apply.c: simplify calling site to apply_line()
builtin-apply.c: clean-up apply_one_fragment()
builtin-apply.c: mark common context lines in lineinfo structure.
builtin-apply.c: optimize match_beginning/end processing a bit.
builtin-apply.c: make it more line oriented
builtin-apply.c: push match-beginning/end logic down
builtin-apply.c: restructure "offset" matching
builtin-apply.c: refactor small part that matches context
Sometimes scripts want (or need) the annotated tag name that exactly
matches a specific commit, or no tag at all. In such cases it can be
difficult to determine if the output of `git describe $commit` is a
real tag name or a tag+abbreviated commit. A common idiom is to run
git-describe twice:
if test $(git describe $commit) = $(git describe --abbrev=0 $commit)
...
but this is a huge waste of time if the caller is just going to pick a
different method to describe $commit or abort because it is not exactly
an annotated tag.
Setting the maximum number of candidates to 0 allows the caller to ask
for only a tag that directly points at the supplied commit, or to have
git-describe abort if no such item exists.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Packing objects can be done in parallell nowadays, but it's
only done if the config option pack.threads is set to a value
above 1. Because of that, the code-path used is often not the
most optimal one.
This patch adds a routine to detect the number of online CPU's
at runtime (online_cpus()). When pack.threads (or --threads=) is
given a value of 0, the number of threads is set to the number of
online CPU's. This feature is also documented.
As per Nicolas Pitre's recommendations, the default is still to
run pack-objects single-threaded unless explicitly activated,
either by configuration or by command line parameter.
The routine online_cpus() is a rework of "numcpus.c", written by
one Philip Willoughby <pgw99@doc.ic.ac.uk>. numcpus.c is in the
public domain and can presently be downloaded from
http://csgsoft.doc.ic.ac.uk/numcpus/
Signed-off-by: Andreas Ericsson <ae@op5.se>
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This combines the existing stash subcommands 'apply' and 'drop' to
allow a single stash entry to be applied and then dropped, in other
words 'popped', from the stash list.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This allows a single stash entry to be deleted. It takes an
optional argument which is a stash reflog entry. If no
arguments are supplied, it drops the most recent stash entry.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* bc/reflog-fix: (1490 commits)
builtin-reflog.c: don't install new reflog on write failure
hash: fix lookup_hash semantics
gitweb: Better chopping in commit search results
builtin-tag.c: remove cruft
git-merge-index documentation: clarify synopsis
send-email: fix In-Reply-To regression
git-reset --hard and git-read-tree --reset: fix read_cache_unmerged()
Teach git-grep --name-only as synonym for -l
diff: fix java funcname pattern for solaris
t3404: use configured shell instead of /bin/sh
git_config_*: don't assume we are parsing a config file
prefix_path: use is_absolute_path() instead of *orig == '/'
git-clean: handle errors if removing files fails
Clarified the meaning of git-add -u in the documentation
git-clone.sh: properly configure remote even if remote's head is dangling
git.el: Set process-environment instead of invoking env
Documentation/git-stash: document options for git stash list
send-email: squelch warning due to comparing undefined $_ to ""
cvsexportcommit: be graceful when "cvs status" reorders the arguments
Rename git-core rpm to just git and rename the meta-pacakge to git-all.
...
Conflicts:
Documentation/git-reflog.txt
t/t1410-reflog.sh
The options following <merge-program> are not -a, --, or <file>...,
but either -a, or -- <file>..., while -- is optional.
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
I expected git grep --name-only to give me only the file names,
much as git diff --name-only only generates filenames. Alas the
option is -l, which matches common external greps but doesn't match
other parts of the git UI.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
Clarified the meaning of git-add -u in the documentation
git-clone.sh: properly configure remote even if remote's head is dangling
Documentation/git-stash: document options for git stash list
send-email: squelch warning due to comparing undefined $_ to ""
The git-add documentation did not state clearly that the -u switch
updates only the tracked files that are in the current directory and
its subdirectories.
Signed-off-by: Pekka Kaitaniemi <kaitanie@cc.helsinki.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
Rename git-core rpm to just git and rename the meta-pacakge to git-all.
push: document the status output
Documentation/push: clarify matching refspec behavior
push: indicate partialness of error message
When you have particular reviewers you want to sent particular series
to, it's nice to be able to generate the whole series with them as
additional recipients, without configuring them into your general
headers or adding them by hand afterwards.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If --cover-letter is provided, generate a cover letter message before
the patches, numbered 0.
Original patch thanks to Johannes Schindelin
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The --rebase option was documented in the wrong place (under MERGE
STRATEGIES instead of OPTIONS). Noted the branch.<name>.rebase
option.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documents the branch.autosetupmerge=always setting and usage of --track
when branching from a local branch.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The output was meant to be a balance of self-explanatory and
terse. In case we have erred too far on the terse side, it
doesn't hurt to explain in more detail what each line means.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The previous text was correct, but it was easy to miss the
fact that we are talking about "matching" refs. That is, the
text can be parsed as "we push the union of the sets
of remote and local heads" and not "we push the intersection
of the sets of remote and local heads". (The former actually
doesn't make sense if you think about it, since we don't
even _have_ some of those heads). A careful reading would
reveal the correct meaning, but it makes sense to be as
explicit as possible in documentation.
We also explicitly use and introduce the term "matching";
this is a term discussed on the list, and it seems useful
to for users to be able to refer to this behavior by name.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* cc/browser:
Documentation: add 'git-web--browse.txt' and simplify other docs.
git-web--browse: fix misplaced quote in init_browser_path()
web--browse: Add a few quotes in 'init_browser_path'.
Documentation: instaweb: add 'git-web--browse' information.
Adjust .gitignore for 5884f1(Rename 'git-help--browse.sh'...)
git-web--browse: do not start the browser with nohup
instaweb: use 'git-web--browse' to launch browser.
Rename 'git-help--browse.sh' to 'git-web--browse.sh'.
help--browse: add '--config' option to check a config option for a browser.
help: make 'git-help--browse' usable outside 'git-help'.
Conflicts:
git-web--browse.sh
* pb/prepare-commit-msg:
git-commit: add a prepare-commit-msg hook
git-commit: Refactor creation of log message.
git-commit: set GIT_EDITOR=: if editor will not be launched
git-commit: support variable number of hook arguments
* jc/submittingpatches:
Documentation/SubmittingPatches - a suggested patch flow
Documentation/SubmittingPatches: What's Acked-by and Tested-by?
Documentation/SubmittingPatches: discuss first then submit
Documentation/SubmittingPatches: Instruct how to use [PATCH] Subject header
* maint:
Documentation/git-reset: Add an example of resetting selected paths
Documentation/git-reset: don't mention --mixed for selected-paths reset
Documentation/git-reset:
The option is accepted, but that is the only form selected-paths
variant of the reset command takes, so there is no point mentioning it.
And while we're at it, use the dashless git call.
Signed-off-by: Pieter de Bie <pdebie@ai.rug.nl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since 3368d11 (Remove unnecessary git-rm --cached reference from
status output), the status output marks the "Added but not yet
committed" section as "Changes to be committed".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Recent versions of fast-import will now dump information out upon
crashing, making it possible for the frontend developer to review
some state information and possibly restart the import from the
point where it crashed.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
'git-help.txt' and 'git-instaweb.txt' contained duplicated
information about 'git-web--browse'.
This patch puts this information where it belongs.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This allows the --relative option to say which subdirectory to
pretend to be in, so that in a bare repository, you can say:
$ git log --relative=drivers/ v2.6.20..v2.6.22 -- drivers/scsi/
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This adds --relative option to the diff family. When you start
from a subdirectory:
$ git diff --relative
shows only the diff that is inside your current subdirectory,
and without $prefix part. People who usually live in
subdirectories may like it.
There are a few things I should also mention about the change:
- This works not just with diff but also works with the log
family of commands, but the history pruning is not affected.
In other words, if you go to a subdirectory, you can say:
$ git log --relative -p
but it will show the log message even for commits that do not
touch the current directory. You can limit it by giving
pathspec yourself:
$ git log --relative -p .
This originally was not a conscious design choice, but we
have a way to affect diff pathspec and pruning pathspec
independently. IOW "git log --full-diff -p ." tells it to
prune history to commits that affect the current subdirectory
but show the changes with full context. I think it makes
more sense to leave pruning independent from --relative than
the obvious alternative of always pruning with the current
subdirectory, which would break the symmetry.
- Because this works also with the log family, you could
format-patch a single change, limiting the effect to your
subdirectory, like so:
$ cd gitk-git
$ git format-patch -1 --relative 911f1eb
But because that is a special purpose usage, this option will
never become the default, with or without repository or user
preference configuration. The risk of producing a partial
patch and sending it out by mistake is too great if we did
so.
- This is inherently incompatible with --no-index, which is a
bolted-on hack that does not have much to do with git
itself. I didn't bother checking and erroring out on the
combined use of the options, but probably I should.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
config: add test cases for empty value and no value config variables.
cvsimport: have default merge regex also match beginning of commit message
git clone -s documentation: force a new paragraph for the NOTE
status: suggest "git rm --cached" to unstage for initial commit
Protect get_author_ident_from_commit() from filenames in work tree
upload-pack: Initialize the exec-path.
bisect: use verbatim commit subject in the bisect log
git-cvsimport.txt: fix '-M' description.
Revert "pack-objects: only throw away data during memory pressure"
Fix '-M' description. Old one reads as if the user can somehow "see"
the default regex when using -M along with -m.
Signed-off-by: Sergei Organov <osv@javad.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This establishes what the "bad" whitespaces are for this
project.
The rules are:
- Unless otherwise specified, indent with SP that could be
replaced with HT are not "bad". But SP before HT in the
indent is "bad", and trailing whitespaces are "bad".
- For C source files, initial indent by SP that can be replaced
with HT is also "bad".
- Test scripts in t/ and test vectors in its subdirectories can
contain anything, so we make it unrestricted for now.
Anything "bad" will be shown in WHITESPACE error indicator in
diff output, and "apply --whitespace=warn" will warn about it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This command is identical to `git blame', but it shows SVN revision
numbers instead of git commit hashes.
[ew: support "^initial commit" and minor formatting fixes]
Signed-off-by: Tim Stoakes <tim@stoakes.net>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jakub Narebski <jnareb@gmail.com> wrote Sun, Feb 03, 2008:
> Junio C Hamano wrote:
> > Jakub Narebski <jnareb@gmail.com> writes:
> >
> > [From] http://thread.gmane.org/gmane.comp.version-control.git/53457/focus=53458
> Julian Phillips:
> > Are you using docbook xsl 1.72? There are known problems building the
> > manpages with that version. 1.71 works, and 1.73 should work when it get
> > released.
I was able to solve this problem with this patch, which adds a XSL file
used specifically for DOCBOOK_XSL_172=YesPlease and where dots and
backslashes are escaped properly so they won't be substituted to the
wrong thing further down the "DocBook XSL pipeline". Doing the escaping
in the existing callout.xsl breaks v1.70.1. Hopefully v1.73 will end
this part of the manpage nightmare.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In 34a3e69 (git-branch: default to --track) the default was changed to
true, to help new git users. But yours truly forgot to update the
documentation. This fixes it.
Noticed by Kalle Olavi Niemitalo.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Now that 'git-instaweb' uses 'git-web--browse', update the
documentation accordingly.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git pack-objects" has the option --max-pack-size to limit the file
size of the packs to a certain amount of bytes. On platforms where
the pack file size is limited by filesystem constraints, it is easy
to forget this option, and this option does not exist for "git gc"
to begin with.
So introduce a config variable to set the default maximum, but make
this overrideable by the command line.
Suggested by Tor Arvid Lund.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
CRLF conversion bears a slight chance of corrupting data.
autocrlf=true will convert CRLF to LF during commit and LF to
CRLF during checkout. A file that contains a mixture of LF and
CRLF before the commit cannot be recreated by git. For text
files this is the right thing to do: it corrects line endings
such that we have only LF line endings in the repository.
But for binary files that are accidentally classified as text the
conversion can corrupt data.
If you recognize such corruption early you can easily fix it by
setting the conversion type explicitly in .gitattributes. Right
after committing you still have the original file in your work
tree and this file is not yet corrupted. You can explicitly tell
git that this file is binary and git will handle the file
appropriately.
Unfortunately, the desired effect of cleaning up text files with
mixed line endings and the undesired effect of corrupting binary
files cannot be distinguished. In both cases CRLFs are removed
in an irreversible way. For text files this is the right thing
to do because CRLFs are line endings, while for binary files
converting CRLFs corrupts data.
This patch adds a mechanism that can either warn the user about
an irreversible conversion or can even refuse to convert. The
mechanism is controlled by the variable core.safecrlf, with the
following values:
- false: disable safecrlf mechanism
- warn: warn about irreversible conversions
- true: refuse irreversible conversions
The default is to warn. Users are only affected by this default
if core.autocrlf is set. But the current default of git is to
leave core.autocrlf unset, so users will not see warnings unless
they deliberately chose to activate the autocrlf mechanism.
The safecrlf mechanism's details depend on the git command. The
general principles when safecrlf is active (not false) are:
- we warn/error out if files in the work tree can modified in an
irreversible way without giving the user a chance to backup the
original file.
- for read-only operations that do not modify files in the work tree
we do not not print annoying warnings.
There are exceptions. Even though...
- "git add" itself does not touch the files in the work tree, the
next checkout would, so the safety triggers;
- "git apply" to update a text file with a patch does touch the files
in the work tree, but the operation is about text files and CRLF
conversion is about fixing the line ending inconsistencies, so the
safety does not trigger;
- "git diff" itself does not touch the files in the work tree, it is
often run to inspect the changes you intend to next "git add". To
catch potential problems early, safety triggers.
The concept of a safety check was originally proposed in a similar
way by Linus Torvalds. Thanks to Dimitry Potapov for insisting
on getting the naked LF/autocrlf=true case right.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
The prepare-commit-msg hook is run whenever a "fresh" commit message
is prepared, just before it is shown in the editor (if it is).
Its purpose is to modify the commit message in-place.
It takes one to three parameters. The first is the name of the file that
the commit log message. The second is the source of the commit message,
and can be: "message" (if a -m or -F option was given); "template" (if a
-t option was given or the configuration option commit.template is set);
"merge" (if the commit is a merge or a .git/MERGE_MSG file exists);
"squash" (if a .git/SQUASH_MSG file exists); or "commit", followed by
a commit SHA1 as the third parameter (if a -c, -C or --amend option
was given).
If its exit status is non-zero, git-commit will abort. The hook is
not suppressed by the --no-verify option, so it should not be used
as a replacement for the pre-commit hook.
The sample prepare-commit-msg comments out the `Conflicts:` part of
a merge's commit message; other examples are commented out, including
adding a Signed-off-by line at the bottom of the commit messsage,
that the user can then edit or discard altogether.
Signed-off-by: Paolo Bonzini <bonzini@gnu.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is a preparatory patch that provides a simple way for the future
prepare-commit-msg hook to discover if the editor will be launched.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A pattern "foo/" in the exclude list did not match directory
"foo", but a pattern "foo" did. This attempts to extend the
exclude mechanism so that it would while not matching a regular
file or a symbolic link "foo". In order to differentiate a
directory and non directory, this passes down the type of path
being checked to excluded() function.
A downside is that the recursive directory walk may need to run
lstat(2) more often on systems whose "struct dirent" do not give
the type of the entry; earlier it did not have to do so for an
excluded path, but we now need to figure out if a path is a
directory before deciding to exclude it. This is especially bad
because an idea similar to the earlier CE_UPTODATE optimization
to reduce number of lstat(2) calls would by definition not apply
to the codepaths involved, as (1) directories will not be
registered in the index, and (2) excluded paths will not be in
the index anyway.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There are a few options to git-send-email to suppress the automatic
generation of 'Cc' fields: --suppress-from, and --signed-off-cc.
However, there are other times that git-send-email automatically
includes Cc'd recipients. This is not desirable for all development
environments.
Add a new option --suppress-cc, which can be specified one or more
times to list the categories of auto-cc fields that should be
suppressed. If not specified, it defaults to values to give the same
behavior as specified by --suppress-from, and --signed-off-cc. The
categories are:
self - patch sender. Same as --suppress-from.
author - patch author.
cc - cc lines mentioned in the patch.
cccmd - avoid running the cccmd.
sob - signed off by lines.
all - all non-explicit recipients
Signed-off-by: David Brown <git@davidb.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We used to talk about "internal company procedures", but this
document is about submitting patches to the git mailing list.
More useful information is when to say Acked-by: and Tested-by:.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is something I've had in mind for some time. I get enough
e-mails as-is, and I suspect the workflow to get list members
involved would work better if we get the discussion concluded on
the list first before patches hit my tree (even 'next').
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This new error mode allows a line to have a carriage return at the
end of the line when checking and fixing trailing whitespace errors.
Some people like to keep CRLF line ending recorded in the repository,
and still want to take advantage of the automated trailing whitespace
stripping. We still show ^M in the diff output piped to "less" to
remind them that they do have the CR at the end, but these carriage
return characters at the end are no longer flagged as errors.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Whilst convenient, it is most unwise to record passwords
in any place but one's brain. Moreover, it is especially
foolish to store them in configuration files, even with
access permissions set accordingly.
git-send-email has been amended, so that if it detects
an smtp username without a password, it promptly prompts
for the password and masks the input for privacy.
Furthermore, the argument to --smtp-pass has been rendered
optional.
The documentation has been updated to reflect these changes.
Signed-off-by: Michael Witten <mfwitten@mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jakub Narebski <jnareb@gmail.com> wrote Sun, Feb 03, 2008:
> Junio C Hamano wrote:
> > Jakub Narebski <jnareb@gmail.com> writes:
> >
> > [From] http://thread.gmane.org/gmane.comp.version-control.git/53457/focus=53458
> Julian Phillips:
> > Are you using docbook xsl 1.72? There are known problems building the
> > manpages with that version. 1.71 works, and 1.73 should work when it get
> > released.
I was able to solve this problem with this patch, which adds a XSL file
used specifically for DOCBOOK_XSL_172=YesPlease and where dots and
backslashes are escaped properly so they won't be substituted to the
wrong thing further down the "DocBook XSL pipeline". Doing the escaping
in the existing callout.xsl breaks v1.70.1. Hopefully v1.73 will end
this part of the manpage nightmare.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In the text, the argument of -m is <master> which should be used in the
command synopsis, too.
Signed-off-by: Jörg Sommer <joerg@alea.gnuu.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Adjust the command syntax to better reflect the call parameters:
[save] [message...] => [save [<message>]].
Signed-off-by: Jari Aalto <jari.aalto AT cante.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When the upstream branch is tracked, we can detect if that branch
was rebased since it was last fetched. Teach git to use that
information to rebase from the old remote head onto the new remote head.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
While there is information about this in the configuration section, it was
missing in the options section.
Signed-off-by: Mike Hommey <mh@glandium.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The -n option stands for --no-summary in git pull
[jes: reworded the description to avoid mentioning 'git-fetch';
also exclude '-n' conditional on git-pull -- ugly because of
the missing "else" statement in asciidoc]
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-svn expects its references under refs/remotes/*; but these will
not be copied or set by "git clone"; put in this man page the manual
fiddling that is required with current git-svn to get this to work.
Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There is a scenario when using git clone -s and git gc --prune togother is
dangerous. Document this.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Only "status" accepts "--cached" and the preferred way of
passing sub-command specific options is after the sub-command.
The documentation is adapted to reflect this.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Replace the "This manual page describes only the most frequently used options."
text with the list of rev-list options in git-log manpage. (The git-diff-tree
options are already included.)
Move these options to a separate file and include it from both
git-rev-list.txt and git-log.txt.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The lockfile API is a handy way to obtain a file that is cleaned
up if you die(). But sometimes you would need this sequence to
work:
1. hold_lock_file_for_update() to get a file descriptor for
writing;
2. write the contents out, without being able to decide if the
results should be committed or rolled back;
3. do something else that makes the decision --- and this
"something else" needs the lockfile not to have an open file
descriptor for writing (e.g. Windows do not want a open file
to be renamed);
4. call commit_lock_file() or rollback_lock_file() as
appropriately.
This adds close_lock_file() you can call between step 2 and 3 in
the above sequence.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We have nice set of placeholders, but nobody stepped in to fill
the gap in the API documentation, so I am doing it myself.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
