The underlying plumbing commands are not run with -z option, so the paths
returned from them need to be unquoted as needed.
Remove the now stale BUGS section from git-add documentaiton as suggested
by Teemu Likonen.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Ward Wouts reports that git-svn barfed like this:
Unable to parse date: 2004-03-09T09:44:33.Z at /usr/bin/git-svn line 3995
The parse_svn_date sub expects there always are one or more digits after
the decimal point to record fractional seconds, but this example does not
and results in a failure like this.
The fix is based on the original fix by the reporter, further cleaned up.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
When a feature like "blame" is permitted to be overridden in the
repository configuration but it is not actually set in the repository,
a warning is emitted due to the undefined value of the repository
configuration, even though it's a perfectly normal condition.
Emitting warning is grounds for test failure in the gitweb test
script.
This error was caused by rewrite of git_get_project_config from using
"git config [<type>] <name>" for each individual configuration
variable checked to parsing "git config --list --null" output in
commit b201927 (gitweb: Read repo config using 'git config -z -l').
Earlier version of git_get_project_config was returning empty string
if variable do not exist in config; newer version is meant to return
undef in this case, therefore change in feature_bool was needed.
Additionally config_to_* subroutines were meant to be invoked only if
configuration variable exists; therefore we added early return to
git_get_project_config: it now returns no value if variable does not
exists in config. Otherwise config_to_* subroutines (config_to_bool
in paryicular) wouldn't be able to distinguish between the case where
variable does not exist and the case where variable doesn't have value
(the "[section] noval" case, which evaluates to true for boolean).
While at it fix bug in config_to_bool, where checking if $val is
defined (if config variable has value) was done _after_ stripping
leading and trailing whitespace, which lead to 'Use of uninitialized
value' warning.
Add test case for features overridable but not overriden in repo
config, and case for no value boolean configuration variable.
Signed-off-by: Marcel M. Cary <marcel@oak.homeunix.org>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
While b259f09 made git-push output a better error message for 'git-push
--all --tags', this commit fixes the synopsis in the documentation.
Inconsistency spotted and fix suggested by Jari Aalto through
http://bugs.debian.org/502567
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The gitk completion only shows --merge if MERGE_HEAD is present.
Do it the same way for git-log completion.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Refactor options that are useful for more than one of them into a
variable used by the relevant completions. This has the effect of
adding the following options to git-log:
--branches --tags --remotes --first-parent --dense --sparse
--simplify-merges --simplify-by-decoration --first-parent
--no-merges
The following to git-shortlog:
--branches --tags --remotes --first-parent
And the following to gitk:
--branches --tags --remotes --first-parent --no-merges --max-count=
--max-age= --since= --after= --min-age= --until= --before= --dense
--sparse --full-history --simplify-merges --simplify-by-decoration
--left-right
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
CGI::url() has some issues when rebuilding the script URL if the script
is a DirectoryIndex.
One of these issue is the inability to strip PATH_INFO, which is why
we had to do it ourselves.
Another issue is that the resulting URL cannot be used for the <base>
tag: it works if we're the DirectoryIndex at the root level, but not
otherwise.
We fix this by building the proper base URL ourselves, and improve the
comment about the need to strip PATH_INFO manually while we're at it.
Additionally t/t9500-gitweb-standalone-no-errors.sh had to be modified
to set SCRIPT_NAME variable (CGI standard states that it MUST be set,
and now gitweb uses it if PATH_INFO is not empty, as is the case for
some of tests in t9500).
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
'git svn' got some new subcommands and otions in the last couple of
months. This patch adds completion support for them.
In particular:
* 'fetch', 'clone', etc.: '--ignore-paths='
* 'init' and 'clone': '--prefix=', '--use-log-author',
'--add-author-from'
* 'dcommit': '--commit-url', '--revision'
* 'log': '--color'
* 'rebase': '--dry-run'
* 'branch', 'tag', 'blame', 'migrate' subcommands and their options
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Namely: '--commit', '--stat', '--no-squash', '--ff', '--no-ff'.
One might wonder why add options that specify the default behaviour
anyway (e.g. '--commit', '--no-squash', etc.). Users can override the
default with config options (e.g. 'branch.<name>.mergeoptions',
'merge.log'), but sometimes might still need the default behaviour.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If the new svn root URL given with the svn-remote.<repo>.rewriteRoot config option
(or by the --rewrite-root option to 'git svn init') contains a username
(such as 'svn+ssh://username@example.com/repo'), find_by_url() cannot find
the repository URL, because the URL contained in the commit message does have
the username removed.
Signed-off-by: Dévai Tamás <devait@mailbox.sk>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
While all of the strings passed to warning() are, in fact, literals, the
compiler doesn't recognize them as such because it doesn't see through
the loop used to iterate over them:
builtin-receive-pack.c: In function 'warn_unconfigured_deny':
builtin-receive-pack.c:247: warning: format not a string literal and no format arguments
builtin-receive-pack.c: In function 'warn_unconfigured_deny_delete_current':
builtin-receive-pack.c:273: warning: format not a string literal and no format arguments
Calm the compiler by adding easily recognizable format string literals.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* ms/mailmap:
Move mailmap documentation into separate file
Change current mailmap usage to do matching on both name and email of author/committer.
Add map_user() and clear_mailmap() to mailmap
Add find_insert_index, insert_at_index and clear_func functions to string_list
Add mailmap.file as configurational option for mailmap location
After 753bc91 ("Remove the requirement opaquelocktoken uri scheme"),
lock tokens are in the URI forms in which they are received from the
server, eg. 'opaquelocktoken:', 'urn:uuid:'.
However, "start_put" (and consequently "start_move"), which attempts to
create a unique temporary file using the UUID of the lock token,
inadvertently uses the lock token in its URI form. These file
operations on the server may not be successful (specifically, in
Windows), due to the colon ':' character from the URI form of the lock
token in the file path.
This patch uses a hash of the lock token instead, guaranteeing only
"safe" characters (a-f, 0-9) are used in the file path.
The token's hash is generated when the lock token is received from the
server in handle_new_lock_ctx, minimizing the number of times of
hashing.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since 6564828 (git-send-email: Generalize auto-cc recipient
mechanism., 2007-12-25) we can suppress automatic Cc generation
separately for each of the possible address sources. However,
--suppress-cc=sob suppressed both SOB lines and body (but not header)
Cc lines, contrary to the name.
Change --suppress-cc=sob to mean only SOB lines, and add separate
choices 'bodycc' (body Cc lines) and 'body' (both 'sob' and 'bodycc').
The option --no-signed-off-by-cc now acts like --suppress-cc=sob,
which is not backwards compatible but matches the name of the option.
Also update the documentation and add a few tests.
Original patch by me. Revised by Thomas Rast, who contributed the
documentation and test updates.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When git format-patch is given multiple --cc arguments, it generates a
Cc header that looks like:
Cc: first@example.com,
second@example.com,
third@example.com
Before this commit, send-email was unable to handle such a message as it
did not handle folded header lines, nor multiple recipients in a Cc
line.
This patch:
- Unfolds header lines by pre-processing the header before extracting
any of its fields.
- Handles Cc lines with multiple recipients.
- Adds use of Mail::Address if available for splitting Cc line and
the "Who should the emails be sent to?" prompt", with fall back to
existing split_addrs() function.
- Tests the new functionality and adds two tests for detecting whether
"From:" appears correctly in message body when patch author differs
from patch sender.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
send-email is supposed to be able to run from outside a repo. This
ability was broken by commits caf0c3d6 (make the message file name more
specific) and 5df9fcf6 (interpret unknown files as revision lists).
This commit provides a fix for both.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Extend t1500 with tests of 'git rev-parse --git-dir' when invoked from
other directories of the repository or the work tree.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 72183cb2 (Fix gitdir detection when in subdir of
gitdir, 2009-01-16) added a test to 't1501-worktree' to check the
behaviour of 'git rev-parse --git-dir' in a special case. However,
t1501 is about testing separate work tree setups, and not about basic
'rev-parse' functionality, which is tested in t1500-rev-parse.
Therefore, this patch moves that test to t1500.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add a section about how to shrink a repository's size after running
git-filter-branch to remove large blobs from history.
This comes up every week or so on IRC, and the commands required to
handle every case are not very newbie-friendly, so hopefully writing
them down somewhere leads to fewer questions.
It may seem contradictory to document fallbacks for older Gits in
newer docs, but we want to point people at this as a FAQ answer, and
they will frequently not have the newest version installed.
Thanks to Björn Steinbrink and Junio C Hamano for comments and
corrections.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
With this patch, "git gc --no-prune" will not prune any loose (and
dangling) object, and "git gc --prune=5.minutes.ago" will prune
all loose objects older than 5 minutes.
This patch benefitted from suggestions by Thomas Rast and Jan Krï¿œger.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
1.6.2 will have @{-1} syntax advertised as "usable anywhere you can use
a branch name". However, "git merge @{-1}" did not work.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This teaches the new "@{-1} syntax to refer to the previous branch to "git
branch". After looking at somebody's faulty patch series on a topic
branch too long, if you decide it is not worth merging, you can just say:
$ git checkout master
$ git branch -D @{-1}
to get rid of it without having to type the name of the topic you now hate
so much for wasting a lot of your time.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit afe5d3d5 introduced a safety valve to symbolic-ref to
disallow installing an invalid HEAD. It was accompanied by
b229d18a, which changed validate_headref to require that
HEAD contain a pointer to refs/heads/ instead of just refs/.
Therefore, the safety valve also checked for refs/heads/.
As it turns out, topgit is using refs/top-bases/ in HEAD,
leading us to re-loosen (at least temporarily) the
validate_headref check made in b229d18a. This patch does the
corresponding loosening for the symbolic-ref safety valve,
so that the two are in agreement once more.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
'git log --abbrev-commit' added an ellipsis to all commit names that
were abbreviated. This was particularly annoying if you wanted to
cut&paste the sha1 from the terminal, since selecting by word would
pick up '...' too.
So use find_unique_abbrev() instead of diff_unique_abbrev() in all
log-related commit sha1 printing routines, and also change the
formatting of the 'Merge: parent1 parent2' line output via
pretty_print_commit().
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
After "cloning from an empty repository", we have a configuration to
describe the remote's URL and the default ref mappings, but we lack the
branch configuration for the default branch we create on our end,
"master".
It is likely that the empty repository we cloned from will point the
default "master" branch with its HEAD, so prepare the local configuration
to match.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This reverts commit b229d18a809c169314b7f0d048dc5a7632e8f916, at least
until we figure out how to work better with TopGit that points HEAD to
refs/top-bases/ hierarchy.
When there is more than one file that are changed, running git diff with
GIT_EXTERNAL_DIFF incorrectly diagnoses an programming error and dies.
The check introduced in 479b0ae (diff: refactor tempfile cleanup handling,
2009-01-22) to detect a temporary file slot that forgot to remove its
temporary file was inconsistent with the way the codepath to remove the
temporary to mark the slot that it is done with it.
This patch fixes this problem and adds a test case for it.
Signed-off-by: Nazri Ramliy <ayiehere@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"\" was treated differently in exclude rules depending on whether a
wildcard match was done. For wildcard rules, "\" was de-escaped in
fnmatch, but this was not done for other rules since they used strcmp
instead. A file named "#foo" would not be excluded by "\#foo", but would
be excluded by "\#foo*".
We now treat all rules with "\" as wildcard rules.
Another solution could be to de-escape all non-wildcard rules as we
read them, but we would have to do the de-escaping exactly as fnmatch
does it to avoid inconsistencies.
Signed-off-by: Finn Arne Gangstad <finnag@pvv.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
Prepare for 1.6.1.4.
Make repack less likely to corrupt repository
fast-export: ensure we traverse commits in topological order
Clear the delta base cache if a pack is rebuilt
Conflicts:
RelNotes
* maint-1.6.0:
Make repack less likely to corrupt repository
fast-export: ensure we traverse commits in topological order
Clear the delta base cache if a pack is rebuilt
Some platforms refuse to rename a file that is open. When repacking an
already packed repository without adding any new object, the resulting
pack will contain the same set of objects as an existing pack, and on such
platforms, a newly created packfile cannot replace the existing one.
The logic detected this issue but did not try hard enough to recover from
it. Especially because the files that needs renaming come in pairs, there
potentially are different failure modes that one can be renamed but the
others cannot. Asking manual recovery to end users were error prone.
This patch tries to make it more robust by first making sure all the
existing files that need to be renamed have been renamed before
continuing, and attempts to roll back if some failed to rename.
This is based on an initial patch by Robin Rosenberg.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
fast-export will only list as parents those commits which have already
been traversed (making it appear as if merges have been squashed if not
all parents have been traversed). To avoid this silent squashing of
merge commits, we request commits in topological order.
Signed-off-by: Elijah Newren <newren@gmail.com>
Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
9273b56 (filter-branch: Fix fatal error on bare repositories, 2009-02-03)
fixed a missing check of return status from an underlying command in
git-filter-branch, but there still are places that do not check errors.
For example, the command does not pay attention to the exit status of the
command given by --commit-filter. It should abort in such a case.
This attempts to fix all the remaining places that fails to checks errors.
In two places, I've had to break apart pipelines in order to check the
error code for the first stage of the pipeline, as discussed here:
http://kerneltrap.org/mailarchive/git/2009/1/28/4835614
Feedback on this patch was provided by Johannes Sixt, Johannes Schindelin
and Junio C Hamano. Thomas Rast helped with pipeline error handling.
Signed-off-by: Eric Kidd <git@randomhacks.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In the show_new_revisions function, the original code:
git rev-parse --not --branches | grep -v $(git rev-parse $refname) |
isn't quite right since one can create a new branch and push it
without any new commits. In that case, two refs will have the same
sha1 but both would get filtered by the 'grep'. In the end, we'll
show ALL the history which is not what we want. Instead, we should
list the branches by name and remove the branch being updated and THEN
pass that list through rev-parse.
Revised as suggested by Jakub Narebski and Junio C Hamano to use
git-for-each-ref instead of git-branch. (Thanks!)
Signed-off-by: Pat Notz <pknotz@sandia.gov>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There is some risk that re-opening a regenerated pack file with
different offsets could leave stale entries within the delta base
cache that could be matched up against other objects using the same
"struct packed_git*" and pack offset.
Throwing away the entire delta base cache in this case is safer,
as we don't have to worry about a recycled "struct packed_git*"
matching to the wrong base object, resulting in delta apply
errors while unpacking an object.
Suggested-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
