OSDN Git Service
Nguyễn Thái Ngọc Duy [Fri, 24 Jan 2014 13:40:33 +0000 (20:40 +0700)]
pathspec: pass directory indicator to match_pathspec_item()
This patch activates the DO_MATCH_DIRECTORY code in m_p_i(), which
makes "git diff HEAD submodule/" and "git diff HEAD submodule" produce
the same output. Previously only the version without trailing slash
returns the difference (if any).
That's the effect of new ce_path_match(). dir_path_match() is not
executed by the new tests. And it should not introduce regressions.
Previously if path "dir/" is passed in with pathspec "dir/", they
obviously match. With new dir_path_match(), the path becomes
_directory_ "dir" vs pathspec "dir/", which is not executed by the old
code path in m_p_i(). The new code path is executed and produces the
same result.
The other case is pathspec "dir" and path "dir/" is now turned to
"dir" (with DO_MATCH_DIRECTORY). Still the same result before or after
the patch.
So why change? Because of the next patch about clean.c.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Nguyễn Thái Ngọc Duy [Fri, 24 Jan 2014 13:40:32 +0000 (20:40 +0700)]
match_pathspec: match pathspec "foo/" against directory "foo"
Currently we do support matching pathspec "foo/" against directory
"foo". That is because match_pathspec() has no way to tell "foo" is a
directory and matching "foo/" against _file_ "foo" is wrong.
The callers can now tell match_pathspec if "foo" is a directory, we
could make an exception for this case. Code is not executed though
because no callers pass the flag yet.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Nguyễn Thái Ngọc Duy [Fri, 24 Jan 2014 13:40:31 +0000 (20:40 +0700)]
dir.c: prepare match_pathspec_item for taking more flags
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Nguyễn Thái Ngọc Duy [Fri, 24 Jan 2014 13:40:30 +0000 (20:40 +0700)]
pathspec: rename match_pathspec_depth() to match_pathspec()
A long time ago, for some reason I was not happy with
match_pathspec(). I created a better version, match_pathspec_depth()
that was suppose to replace match_pathspec()
eventually. match_pathspec() has finally been gone since 6 months
ago. Use the shorter name for match_pathspec_depth().
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Nguyễn Thái Ngọc Duy [Fri, 24 Jan 2014 13:40:29 +0000 (20:40 +0700)]
pathspec: convert some match_pathspec_depth() to dir_path_match()
This helps reduce the number of match_pathspec_depth() call sites and
show how m_p_d() is used. And it usage is:
- match against an index entry (ce_path_match or match_pathspec_depth
in ls-files)
- match against a dir_entry from read_directory (dir_path_match and
match_pathspec_depth in clean.c, which will be converted later)
- resolve-undo (rerere.c and ls-files.c)
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Nguyễn Thái Ngọc Duy [Fri, 24 Jan 2014 13:40:28 +0000 (20:40 +0700)]
pathspec: convert some match_pathspec_depth() to ce_path_match()
This helps reduce the number of match_pathspec_depth() call sites and
show how match_pathspec_depth() is used.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Mon, 27 Jan 2014 18:45:43 +0000 (10:45 -0800)]
Merge branch 'nd/negative-pathspec'
* nd/negative-pathspec:
tree-walk.c: ignore trailing slash on submodule in tree_entry_interesting()
Junio C Hamano [Mon, 27 Jan 2014 18:45:41 +0000 (10:45 -0800)]
Merge branch 'pw/git-p4'
Various "git p4" updates.
* pw/git-p4:
git p4 doc: use two-line style for options with multiple spellings
git p4 test: examine behavior with locked (+l) files
git p4: fix an error message when "p4 where" fails
git p4: handle files with wildcards when doing RCS scrubbing
git p4 test: do not pollute /tmp
git p4 test: run as user "author"
git p4 test: is_cli_file_writeable succeeds
git p4 test: explicitly check p4 wildcard delete
git p4: work around p4 bug that causes empty symlinks
git p4 test: ensure p4 symlink parsing works
git p4 test: wildcards are supported
Junio C Hamano [Mon, 27 Jan 2014 18:45:37 +0000 (10:45 -0800)]
Merge branch 'ss/safe-create-leading-dir-with-slash'
"git clone $origin foo\bar\baz" on Windows failed to create the
leading directories (i.e. a moral-equivalent of "mkdir -p").
* ss/safe-create-leading-dir-with-slash:
safe_create_leading_directories(): on Windows, \ can separate path components
Junio C Hamano [Mon, 27 Jan 2014 18:45:33 +0000 (10:45 -0800)]
Merge branch 'mh/safe-create-leading-directories'
Code clean-up and protection against concurrent write access to the
ref namespace.
* mh/safe-create-leading-directories:
rename_tmp_log(): on SCLD_VANISHED, retry
rename_tmp_log(): limit the number of remote_empty_directories() attempts
rename_tmp_log(): handle a possible mkdir/rmdir race
rename_ref(): extract function rename_tmp_log()
remove_dir_recurse(): handle disappearing files and directories
remove_dir_recurse(): tighten condition for removing unreadable dir
lock_ref_sha1_basic(): if locking fails with ENOENT, retry
lock_ref_sha1_basic(): on SCLD_VANISHED, retry
safe_create_leading_directories(): add new error value SCLD_VANISHED
cmd_init_db(): when creating directories, handle errors conservatively
safe_create_leading_directories(): introduce enum for return values
safe_create_leading_directories(): always restore slash at end of loop
safe_create_leading_directories(): split on first of multiple slashes
safe_create_leading_directories(): rename local variable
safe_create_leading_directories(): add explicit "slash" pointer
safe_create_leading_directories(): reduce scope of local variable
safe_create_leading_directories(): fix format of "if" chaining
Junio C Hamano [Mon, 27 Jan 2014 18:45:30 +0000 (10:45 -0800)]
Merge branch 'tr/nth-previous-is-a-commit'
* tr/nth-previous-is-a-commit:
Documentation: @{-N} can refer to a commit
Junio C Hamano [Mon, 27 Jan 2014 18:45:23 +0000 (10:45 -0800)]
Merge branch 'tr/gitk-doc-range-trace'
* tr/gitk-doc-range-trace:
Documentation/gitk: document -L option
Junio C Hamano [Mon, 27 Jan 2014 18:45:08 +0000 (10:45 -0800)]
Merge branch 'jk/mark-edges-uninteresting'
Fix performance regression in v1.8.4.x and later.
* jk/mark-edges-uninteresting:
list-objects: only look at cmdline trees with edge_hint
t/perf: time rev-list with UNINTERESTING commits
Junio C Hamano [Mon, 27 Jan 2014 18:45:02 +0000 (10:45 -0800)]
Merge branch 'jk/diff-filespec-cleanup'
* jk/diff-filespec-cleanup:
diff_filespec: use only 2 bits for is_binary flag
diff_filespec: reorder is_binary field
diff_filespec: drop xfrm_flags field
diff_filespec: drop funcname_pattern_ident field
diff_filespec: reorder dirty_submodule macro definitions
Junio C Hamano [Mon, 27 Jan 2014 18:44:59 +0000 (10:44 -0800)]
Merge branch 'ef/mingw-write'
* ef/mingw-write:
mingw: remove mingw_write
prefer xwrite instead of write
Junio C Hamano [Mon, 27 Jan 2014 18:44:34 +0000 (10:44 -0800)]
Merge branch 'rk/send-email-ssl-cert'
The "if /etc/ssl/certs/ directory exists, explicitly telling the
library to use it as SSL_ca_path" blind-defaulting in "git
send-email" broke platforms where /etc/ssl/certs/ directory exists,
but it cannot used as SSL_ca_path (e.g. Fedora rawhide). Fix it by
not specifying any SSL_ca_path/SSL_ca_file but still asking for peer
verification in such a case.
* rk/send-email-ssl-cert:
send-email: /etc/ssl/certs/ directory may not be usable as ca_path
Junio C Hamano [Mon, 27 Jan 2014 18:44:26 +0000 (10:44 -0800)]
Merge branch 'jn/ignore-doc'
Explicitly list $HOME/.config/git/ignore as one of the places you
can use to keep ignore patterns that depend on your personal choice
of tools, e.g. *~ for Emacs users.
* jn/ignore-doc:
gitignore doc: add global gitignore to synopsis
Junio C Hamano [Mon, 27 Jan 2014 18:44:20 +0000 (10:44 -0800)]
Merge branch 'jk/interpret-branch-name-fix'
Fix a handful of bugs around interpreting $branch@{upstream}
notation and its lookalike, when $branch part has interesting
characters, e.g. "@", and ":".
* jk/interpret-branch-name-fix:
interpret_branch_name: find all possible @-marks
interpret_branch_name: avoid @{upstream} past colon
interpret_branch_name: always respect "namelen" parameter
interpret_branch_name: rename "cp" variable to "at"
interpret_branch_name: factor out upstream handling
Junio C Hamano [Mon, 27 Jan 2014 18:44:13 +0000 (10:44 -0800)]
Merge branch 'jk/allow-fetch-onelevel-refname'
"git clone" would fail to clone from a repository that has a ref
directly under "refs/", e.g. "refs/stash", because different
validation paths do different things on such a refname. Loosen the
client side's validation to allow such a ref.
* jk/allow-fetch-onelevel-refname:
fetch-pack: do not filter out one-level refs
Junio C Hamano [Mon, 27 Jan 2014 18:44:09 +0000 (10:44 -0800)]
Merge branch 'jc/revision-range-unpeel'
"git log --left-right A...B" lost the "leftness" of commits
reachable from A when A is a tag as a side effect of a recent
bugfix. This is a regression in 1.8.4.x series.
* jc/revision-range-unpeel:
revision: propagate flag bits from tags to pointees
revision: mark contents of an uninteresting tree uninteresting
Junio C Hamano [Mon, 27 Jan 2014 18:44:06 +0000 (10:44 -0800)]
Merge branch 'mh/retire-ref-fetch-rules'
Code simplification.
* mh/retire-ref-fetch-rules:
refname_match(): always use the rules in ref_rev_parse_rules
Junio C Hamano [Mon, 27 Jan 2014 18:44:04 +0000 (10:44 -0800)]
Merge branch 'mh/attr-macro-doc'
* mh/attr-macro-doc:
gitattributes: document more clearly where macros are allowed
Junio C Hamano [Mon, 27 Jan 2014 18:44:00 +0000 (10:44 -0800)]
Merge branch 'jc/maint-pull-docfix'
* jc/maint-pull-docfix:
Documentation: "git pull" does not have the "-m" option
Documentation: exclude irrelevant options from "git pull"
Junio C Hamano [Mon, 27 Jan 2014 18:43:55 +0000 (10:43 -0800)]
Merge branch 'jk/complete-merge-base'
* jk/complete-merge-base:
completion: handle --[no-]fork-point options to git-rebase
completion: complete merge-base options
Junio C Hamano [Mon, 27 Jan 2014 18:43:51 +0000 (10:43 -0800)]
Merge branch 'ab/subtree-doc'
* ab/subtree-doc:
subtree: fix argument validation in add/pull/push
Nguyễn Thái Ngọc Duy [Thu, 23 Jan 2014 13:22:05 +0000 (20:22 +0700)]
tree-walk.c: ignore trailing slash on submodule in tree_entry_interesting()
We do ignore trailing slash on a directory, so pathspec "abc/" matches
directory "abc". A submodule is also a directory. Apply the same logic
to it. This makes "git log submodule-path" and "git log submodule-path/"
produce the same output.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Johannes Sixt [Thu, 23 Jan 2014 07:28:58 +0000 (08:28 +0100)]
Makefile: Fix compilation of Windows resource file
If the git version number consists of less than three period
separated numbers, then the Windows resource file compilation
issues a syntax error:
$ touch git.rc
$ make V=1 git.res
GIT_VERSION = 1.9.rc0
windres -O coff \
-DMAJOR=1 -DMINOR=9 -DPATCH=rc0 \
-DGIT_VERSION="\\\"1.9.rc0\\\"" git.rc -o git.res
C:\msysgit\msysgit\mingw\bin\windres.exe: git.rc:2: syntax error
make: *** [git.res] Error 1
$
Note that -DPATCH=rc0.
The values passed via -DMAJOR=, -DMINOR=, and -DPATCH= are used in
FILEVERSION and PRODUCTVERSION statements, which expect up to four numeric
values. These version numbers are intended for machine consumption. They
are typically inspected by installers to decide whether a file to be
installed is newer than one that exists on the system, but are not used
for much else.
We can be pretty certain that there are no tools that look at these
version numbers, not even the installer of Git for Windows does.
Therefore, to fix the syntax error, fill in only the first two numbers,
which we are guaranteed to find in Git version numbers.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Acked-by: Pat Thoyts <patthoyts@users.sourceforge.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Thu, 23 Jan 2014 16:51:14 +0000 (08:51 -0800)]
Merge git://git.bogomips.org/git-svn
* 'master' of git://git.bogomips.org/git-svn:
git-svn: memoize _rev_list and rebuild
Junio C Hamano [Thu, 23 Jan 2014 16:50:50 +0000 (08:50 -0800)]
Merge git://ozlabs.org/~paulus/gitk
* 'master' of git://ozlabs.org/~paulus/gitk:
gitk: Indent word-wrapped lines in commit display header
gitk: Comply with XDG base directory specification
gitk: Replace "next" and "prev" buttons with down and up arrows
gitk: chmod +x po2msg.sh
gitk: Update copyright dates
gitk: Add Bulgarian translation (304t)
gitk: Fix mistype
Paul Mackerras [Thu, 23 Jan 2014 11:06:22 +0000 (22:06 +1100)]
gitk: Indent word-wrapped lines in commit display header
In the cases where the lines starting with Precedes:, Follows: and
Branches: in the commit display are long enough to be word-wrapped,
this adds a 1cm margin on the left of the wrapped lines, to make
the display more readable. Suggested by Stephen Rothwell.
Signed-off-by: Paul Mackerras <paulus@samba.org>
lin zuojian [Thu, 23 Jan 2014 02:15:19 +0000 (10:15 +0800)]
git-svn: memoize _rev_list and rebuild
According to profile data, _rev_list and rebuild consume a large
portion of time. Memoize the results of _rev_list and memoize
rebuild internals to avoid subprocess invocation.
When importing 15152 revisions on a LAN, time improved from 10
hours to 3-4 hours.
Signed-off-by: lin zuojian <manjian2006@gmail.com>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Michael Haggerty [Wed, 22 Jan 2014 11:23:20 +0000 (12:23 +0100)]
Add cross-references between docs for for-each-ref and show-ref
Add cross-references between the manpages for git-for-each-ref(1) and
git-show-ref(1).
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Michael Haggerty [Sat, 18 Jan 2014 23:40:44 +0000 (00:40 +0100)]
safe_create_leading_directories(): on Windows, \ can separate path components
When cloning to a directory "C:\foo\bar" from Windows' cmd.exe where
"foo" does not exist yet, Git would throw an error like
fatal: could not create work tree dir 'c:\foo\bar'.: No such file or directory
Fix this by not hard-coding a platform specific directory separator
into safe_create_leading_directories().
This patch, including its entire commit message, is derived from a
patch by Sebastian Schuberth.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Pete Wyckoff [Tue, 21 Jan 2014 23:16:48 +0000 (18:16 -0500)]
git p4 doc: use two-line style for options with multiple spellings
Thomas Rast noticed the docs have a mix of styles when
it comes to options with multiple spellings. Standardize
the couple in git-p4.txt that are odd.
Instead of:
-n, --dry-run::
Do this:
-n::
--dry-run::
See
http://thread.gmane.org/gmane.comp.version-control.git/219936/focus=219945
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Pete Wyckoff [Tue, 21 Jan 2014 23:16:47 +0000 (18:16 -0500)]
git p4 test: examine behavior with locked (+l) files
The p4 server can enforce file locking, so that only one user
can edit a file at a time. Git p4 is unable to submit changes
to locked files. Currently it exits poorly. Ideally it would
notice the locked condition and clean up nicely.
Add a bunch of tests that describe the problem, hoping that
fixes appear in the future.
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Pete Wyckoff [Tue, 21 Jan 2014 23:16:46 +0000 (18:16 -0500)]
git p4: fix an error message when "p4 where" fails
When "p4 where" fails, for whatever reason, the error message tries to
show an undefined variable. This minor bug applies only when using a
client spec, and was introduced recently in
9d57c4a (git p4: implement
view spec wildcards with "p4 where", 2013-08-30).
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Pete Wyckoff [Tue, 21 Jan 2014 23:16:45 +0000 (18:16 -0500)]
git p4: handle files with wildcards when doing RCS scrubbing
Commit
9d7d446 (git p4: submit files with wildcards, 2012-04-29)
fixed problems with handling files that had p4 wildcard
characters, like "@" and "*". But it missed one case, that of
RCS keyword scrubbing, which uses "p4 fstat" to extract type
information. Fix it by calling wildcard_encode() on the raw
filename.
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Pete Wyckoff [Tue, 21 Jan 2014 23:16:44 +0000 (18:16 -0500)]
git p4 test: do not pollute /tmp
Generating the submit template for p4 uses tempfile.mkstemp(),
which by default puts files in /tmp. For a test that fails,
possibly on purpose, this is not cleaned up. Run with TMPDIR
pointing into the trash directory so the temp files go away
with the test results.
To do this required some other minor changes. First, the editor
is launched using system(editor + " " + template_file), using
shell expansion to build the command string. This doesn't work
if editor has a space in it. And is generally unwise as it's
easy to fool the shell into doing extra work. Exec the args
directly, without shell expansion.
Second, without shell expansion, the trick of "P4EDITOR=:" used
in the tests doesn't work. Use a real command, true, as the
non-interactive editor for testing.
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Pete Wyckoff [Tue, 21 Jan 2014 23:16:43 +0000 (18:16 -0500)]
git p4 test: run as user "author"
The tests use author@example.com as the canonical submitter,
but he does not have an entry in the p4 users database.
This causes the generated change description to complain
that the git and p4 users disagree. The complaint message
is still valid, but isn't useful in tests. It was introduced
in
848de9c (git-p4: warn if git authorship won't be retained,
2011-05-13).
Fix t9813 to use @example.com instead of @localhost due to
change in p4_add_user(). Move the function into the git p4
test library so author can be added at initialization time.
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Pete Wyckoff [Tue, 21 Jan 2014 23:16:42 +0000 (18:16 -0500)]
git p4 test: is_cli_file_writeable succeeds
Commit
e9df0f9 (git p4: cygwin p4 client does not mark read-only,
2013-01-26) fixed a problem with "test -w" on cygwin, but mistakenly
marked the new test as failing. Fix this.
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Pete Wyckoff [Tue, 21 Jan 2014 23:16:41 +0000 (18:16 -0500)]
git p4 test: explicitly check p4 wildcard delete
There was no test where p4 deleted a file with a wildcard
character. Make sure git p4 applies the wildcard decoding
properly when importing a delete that includes a wildcard.
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Pete Wyckoff [Tue, 21 Jan 2014 23:16:40 +0000 (18:16 -0500)]
git p4: work around p4 bug that causes empty symlinks
Damien Gérard highlights an interesting problem. Some p4
repositories end up with symlinks that have an empty target. It
is not possible to create this with current p4, but they do
indeed exist.
The effect in git p4 is that "p4 print" on the symlink returns an
empty string, confusing the curret symlink-handling code.
Such broken repositories cause problems in p4 as well, even with
no git involved. In p4, syncing to a change that includes a
bogus symlink causes errors:
//depot/empty-symlink - updating /home/me/p4/empty-symlink
rename: /home/me/p4/empty-symlink: No such file or directory
and leaves no symlink.
In git, replicate the p4 behavior by ignoring these bad symlinks.
If, in a later p4 revision, the symlink happens to point to
something non-null, the symlink will be replaced properly.
Add a big test for all this too.
This happens to be a regression introduced by
1292df1 (git-p4:
Fix occasional truncation of symlink contents., 2013-08-08) and
appeared first in 1.8.5. But it shows up only in p4 repositories
of dubious character, so can wait for a proper release.
Tested-by: Damien Gérard <damien@iwi.me>
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Astril Hayato [Tue, 21 Jan 2014 19:10:16 +0000 (19:10 +0000)]
gitk: Comply with XDG base directory specification
Write the gitk config data to $XDG_CONFIG_HOME/git/gitk ($HOME/.config/git/gitk
by default) in line with the XDG specification. This makes it consistent with
git which also follows the spec.
If $HOME/.gitk already exists use that for backward compatibility, so only new
installations are affected.
Signed-off-by: Astril Hayato <astrilhayato@gmail.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Pete Wyckoff [Tue, 21 Jan 2014 23:16:39 +0000 (18:16 -0500)]
git p4 test: ensure p4 symlink parsing works
While this happens to work, there was no test to make sure
that the basic importing of a symlink from p4 to git functioned.
Add a simple test to create a symlink in p4 and import it into git,
then verify that the symlink exists and has the correct target.
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Pete Wyckoff [Tue, 21 Jan 2014 23:16:38 +0000 (18:16 -0500)]
git p4 test: wildcards are supported
Since
9d57c4a (git p4: implement view spec wildcards with "p4
where", 2013-08-30), all the wildcard types should be supported.
Change must-fail tests to mark that they now pass.
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Tue, 21 Jan 2014 02:25:40 +0000 (21:25 -0500)]
list-objects: only look at cmdline trees with edge_hint
When rev-list is given a command-line like:
git rev-list --objects $commit --not --all
the most accurate answer is the difference between the set
of objects reachable from $commit and the set reachable from
all of the existing refs. However, we have not historically
provided that answer, because it is very expensive to
calculate. We would have to open every tree of every commit
in the entire history.
Instead, we find the accurate set difference of the
reachable commits, and then mark the trees at the boundaries
as uninteresting. This misses objects which appear in the
trees of both the interesting commits and deep within the
uninteresting history.
Commit
fbd4a70 (list-objects: mark more commits as edges in
mark_edges_uninteresting, 2013-08-16) noticed that we miss
those objects during pack-objects, and added code to examine
the trees of all of the "--not" refs given on the
command-line. Note that this is still not the complete set
difference, because we look only at the tips of the
command-line arguments, not all of their reachable commits.
But it increases the set of boundary objects we consider,
which is especially important for shallow fetches. So we
are trading extra CPU time for a larger set of boundary
objects, which can improve the resulting pack size for a
--thin pack.
This tradeoff probably makes sense in the context of
pack-objects, where we have set revs->edge_hint to have the
traversal feed us the set of boundary objects. For a
regular rev-list, though, it is probably not a good
tradeoff. It is true that it makes our list slightly closer
to a true set difference, but it is a rare case where this
is important. And because we do not have revs->edge_hint
set, we do nothing useful with the larger set of boundary
objects.
This patch therefore ties the extra tree examination to the
revs->edge_hint flag; it is the presence of that flag that
makes the tradeoff worthwhile.
Here is output from the p0001-rev-list showing the
improvement in performance:
Test HEAD^ HEAD
-----------------------------------------------------------------------------------------
0001.1: rev-list --all 0.69(0.65+0.02) 0.69(0.66+0.02) +0.0%
0001.2: rev-list --all --objects 3.22(3.19+0.03) 3.23(3.20+0.03) +0.3%
0001.4: rev-list $commit --not --all 0.04(0.04+0.00) 0.04(0.04+0.00) +0.0%
0001.5: rev-list --objects $commit --not --all 0.27(0.26+0.01) 0.04(0.04+0.00) -85.2%
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Tue, 21 Jan 2014 02:25:12 +0000 (21:25 -0500)]
t/perf: time rev-list with UNINTERESTING commits
We time a straight "rev-list --all" and its "--object"
counterpart, both going all the way to the root. However, we
do not time a partial history walk. This patch adds an
extreme case: a walk over a very small slice of history, but
with a very large set of UNINTERESTING tips. This is similar
to the connectivity check run by git on a small fetch, or
the walk done by any pre-receive hooks that want to check
incoming commits.
This test reveals a performance regression in git v1.8.4.2,
caused by
fbd4a70 (list-objects: mark more commits as edges
in mark_edges_uninteresting, 2013-08-16):
Test
fbd4a703^
fbd4a703
------------------------------------------------------------------------------------------
0001.1: rev-list --all 0.69(0.67+0.02) 0.69(0.68+0.01) +0.0%
0001.2: rev-list --all --objects 3.47(3.44+0.02) 3.48(3.44+0.03) +0.3%
0001.4: rev-list $commit --not --all 0.04(0.04+0.00) 0.04(0.04+0.00) +0.0%
0001.5: rev-list --objects $commit --not --all 0.04(0.03+0.00) 0.27(0.24+0.02) +575.0%
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Thomas Rast [Sun, 19 Jan 2014 07:01:15 +0000 (08:01 +0100)]
Documentation: @{-N} can refer to a commit
The @{-N} syntax always referred to the N-th last thing checked out,
which can be either a branch or a commit (for detached HEAD cases).
However, the documentation only mentioned branches.
Edit in a "/commit" in the appropriate places.
Reported-by: Kevin <ikke@ikke.info>
Signed-off-by: Thomas Rast <tr@thomasrast.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Michael Haggerty [Sat, 18 Jan 2014 22:49:01 +0000 (23:49 +0100)]
rename_tmp_log(): on SCLD_VANISHED, retry
If safe_create_leading_directories() fails because a file along the
path unexpectedly vanished, try again from the beginning. Try at most
4 times.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Michael Haggerty [Sat, 18 Jan 2014 22:49:00 +0000 (23:49 +0100)]
rename_tmp_log(): limit the number of remote_empty_directories() attempts
This doesn't seem to be a likely error, but we've got the counter
anyway, so we might as well use it for an added bit of safety.
Please note that the first call to rename() is optimistic, and it is
normal for it to fail if there is a directory in the way. So bump the
total number of allowed attempts to 4, to be sure that we can still
have at least 3 retries in the case of a race.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Michael Haggerty [Sat, 18 Jan 2014 22:48:59 +0000 (23:48 +0100)]
rename_tmp_log(): handle a possible mkdir/rmdir race
If a directory vanishes while renaming the temporary reflog file,
retry (up to 3 times). This could happen if another process deletes
the directory created by safe_create_leading_directories() just before
we rename the file into the directory.
As far as I can tell, this race could not occur internal to git. The
only time that a directory under $GIT_DIR/logs is deleted is if room
has to be made for a log file for a reference with the same name;
for example, in the following sequence:
git branch foo/bar # Creates file .git/logs/refs/heads/foo/bar
git branch -d foo/bar # Deletes file but leaves .git/logs/refs/heads/foo/
git branch foo # Deletes .git/logs/refs/heads/foo/
But the only reason the last command deletes the directory is because
it wants to create a file with the same name. So if another process
(e.g.,
git branch foo/baz
) wants to create that directory, one of the two is doomed to failure
anyway because of a D/F conflict.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Michael Haggerty [Sat, 18 Jan 2014 22:48:58 +0000 (23:48 +0100)]
rename_ref(): extract function rename_tmp_log()
It's about to become a bit more complex.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Michael Haggerty [Sat, 18 Jan 2014 22:48:57 +0000 (23:48 +0100)]
remove_dir_recurse(): handle disappearing files and directories
If a file or directory that we are trying to remove disappears (e.g.,
because another process has pruned it), do not consider it an error.
However, if REMOVE_DIR_KEEP_TOPLEVEL is set, and the toplevel
directory is missing, then consider it an error (like before).
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Michael Haggerty [Sat, 18 Jan 2014 22:48:56 +0000 (23:48 +0100)]
remove_dir_recurse(): tighten condition for removing unreadable dir
If opendir() fails on the top-level directory, it makes sense to try
to delete it anyway--but only if the failure was due to EACCES.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Michael Haggerty [Sat, 18 Jan 2014 22:48:55 +0000 (23:48 +0100)]
lock_ref_sha1_basic(): if locking fails with ENOENT, retry
If hold_lock_file_for_update() fails with errno==ENOENT, it might be
because somebody else (for example, a pack-refs process) has just
deleted one of the lockfile's ancestor directories. So if this
condition is detected, try again (up to 3 times).
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Michael Haggerty [Sat, 18 Jan 2014 22:48:54 +0000 (23:48 +0100)]
lock_ref_sha1_basic(): on SCLD_VANISHED, retry
If safe_create_leading_directories() fails because a file along the
path unexpectedly vanished, try again (up to 3 times).
This can occur if another process is deleting directories at the same
time as we are trying to make them. For example, "git pack-refs
--all" tries to delete the loose refs and any empty directories that
are left behind. If a pack-refs process is running, then it might
delete a directory that we need to put a new loose reference in.
If safe_create_leading_directories() thinks this might have happened,
then take its advice and try again (maximum three attempts).
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Thomas Rast [Sat, 16 Nov 2013 17:37:57 +0000 (18:37 +0100)]
Documentation/gitk: document -L option
The -L option is the same as for git-log, so the entire block is just
copied from git-log.txt. However, until the parser is fixed we add a
caveat that gitk only understands the stuck form.
Signed-off-by: Thomas Rast <tr@thomasrast.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Tue, 21 Jan 2014 21:16:17 +0000 (13:16 -0800)]
Merge tag 'gitgui-0.19.0' of repo.or.cz/r/git-gui
git-gui 0.19.0
* tag 'gitgui-0.19.0' of http://repo.or.cz/r/git-gui:
git-gui 0.19
git-gui: chmod +x po2msg, windows/git-gui.sh
git-gui: fallback right pane to packed widgets with Tk 8.4
git-gui i18n: Added Bulgarian translation
git-gui l10n: Add 29 more terms to glossary
git-gui i18n: Initial glossary in Bulgarian
Marc Branchaud [Wed, 18 Dec 2013 16:04:13 +0000 (11:04 -0500)]
gitk: Replace "next" and "prev" buttons with down and up arrows
Users often find that "next" and "prev" do the opposite of what they
expect. For example, "next" moves to the next match down the list, but
that is almost always backwards in time. Replacing the text with arrows
makes it clear where the buttons will take the user.
Signed-off-by: Marc Branchaud <marcnarc@xiplink.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Jonathan Nieder [Mon, 25 Nov 2013 21:00:10 +0000 (13:00 -0800)]
gitk: chmod +x po2msg.sh
The Makefile only runs it using tclsh, but because the fallback po2msg
script has the usual tcl preamble starting with #!/bin/sh it can also
be run directly.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Paul Mackerras [Tue, 21 Jan 2014 11:02:27 +0000 (22:02 +1100)]
gitk: Update copyright dates
Signed-off-by: Paul Mackerras <paulus@samba.org>
Alexander Shopov [Wed, 15 Jan 2014 11:27:29 +0000 (13:27 +0200)]
gitk: Add Bulgarian translation (304t)
Signed-off-by: Alexander Shopov <ash@kambanaria.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Max Kirillov [Sat, 18 Jan 2014 12:58:51 +0000 (14:58 +0200)]
gitk: Fix mistype
Signed-off-by: Max Kirillov <max@max630.net>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Pat Thoyts [Sat, 18 Jan 2014 17:29:34 +0000 (17:29 +0000)]
git-gui 0.19
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
Jonathan Nieder [Mon, 25 Nov 2013 21:01:05 +0000 (13:01 -0800)]
git-gui: chmod +x po2msg, windows/git-gui.sh
The Makefile only runs po/po2msg.sh using tclsh, but because the
script has the usual tcl preamble starting with #!/bin/sh it can also
be run directly.
The Windows git-gui wrapper is usable in-place for the same reason.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
Max Kirillov [Tue, 14 Jan 2014 23:58:09 +0000 (01:58 +0200)]
git-gui: fallback right pane to packed widgets with Tk 8.4
Since
918dbf58, git-gui crashes if started with Tk 8.4. The reason is that
tk < 8.5 does not support -stretch option for panedwindow.
Without the option it's not possible to properly expand the right half -
the commit area is expanded, while desired behavior is to expand the diff
area. So the whole feature should be disabled with Tk
version less than 8.5.
Signed-off-by: Max Kirillov <max@max630.net>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
Alexander Shopov [Wed, 15 Jan 2014 11:07:56 +0000 (13:07 +0200)]
git-gui i18n: Added Bulgarian translation
Signed-off-by: Alexander Shopov <ash@kambanaria.org>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
Alexander Shopov [Wed, 15 Jan 2014 11:07:57 +0000 (13:07 +0200)]
git-gui l10n: Add 29 more terms to glossary
Signed-off-by: Alexander Shopov <ash@kambanaria.org>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
Alexander Shopov [Wed, 15 Jan 2014 11:07:55 +0000 (13:07 +0200)]
git-gui i18n: Initial glossary in Bulgarian
Signed-off-by: Alexander Shopov <ash@kambanaria.org>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
Junio C Hamano [Fri, 17 Jan 2014 20:30:14 +0000 (12:30 -0800)]
Git 1.9-rc0
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Fri, 17 Jan 2014 20:21:39 +0000 (12:21 -0800)]
Merge branch 'maint'
* maint:
git-svn: workaround for a bug in svn serf backend
Junio C Hamano [Fri, 17 Jan 2014 20:21:20 +0000 (12:21 -0800)]
Merge branch 'fp/submodule-checkout-mode'
"submodule.*.update=checkout", when propagated from .gitmodules to
.git/config, turned into a "submodule.*.update=none", which did not
make much sense.
* fp/submodule-checkout-mode:
git-submodule.sh: 'checkout' is a valid update mode
Junio C Hamano [Fri, 17 Jan 2014 20:21:14 +0000 (12:21 -0800)]
Merge branch 'nd/shallow-clone'
Fetching from a shallow-cloned repository used to be forbidden,
primarily because the codepaths involved were not carefully vetted
and we did not bother supporting such usage. This attempts to allow
object transfer out of a shallow-cloned repository in a controlled
way (i.e. the receiver become a shallow repository with truncated
history).
* nd/shallow-clone: (31 commits)
t5537: fix incorrect expectation in test case 10
shallow: remove unused code
send-pack.c: mark a file-local function static
git-clone.txt: remove shallow clone limitations
prune: clean .git/shallow after pruning objects
clone: use git protocol for cloning shallow repo locally
send-pack: support pushing from a shallow clone via http
receive-pack: support pushing to a shallow clone via http
smart-http: support shallow fetch/clone
remote-curl: pass ref SHA-1 to fetch-pack as well
send-pack: support pushing to a shallow clone
receive-pack: allow pushes that update .git/shallow
connected.c: add new variant that runs with --shallow-file
add GIT_SHALLOW_FILE to propagate --shallow-file to subprocesses
receive/send-pack: support pushing from a shallow clone
receive-pack: reorder some code in unpack()
fetch: add --update-shallow to accept refs that update .git/shallow
upload-pack: make sure deepening preserves shallow roots
fetch: support fetching from a shallow repository
clone: support remote shallow repository
...
Erik Faye-Lund [Fri, 17 Jan 2014 14:17:10 +0000 (15:17 +0100)]
mingw: remove mingw_write
Since
0b6806b9 ("xread, xwrite: limit size of IO to 8MB"), this
wrapper is no longer needed, as read and write are already split
into small chunks.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Erik Faye-Lund [Fri, 17 Jan 2014 14:17:09 +0000 (15:17 +0100)]
prefer xwrite instead of write
Our xwrite wrapper already deals with a few potential hazards, and
are as such more robust. Prefer it instead of write to get the
robustness benefits everywhere.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
Reviewed-and-improved-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Fri, 17 Jan 2014 20:04:29 +0000 (12:04 -0800)]
Merge branch 'jk/pull-rebase-using-fork-point'
Finishing touches so that an expected error message will not leak to
the UI.
* jk/pull-rebase-using-fork-point:
pull: suppress error when no remoteref is found
John Keeping [Fri, 17 Jan 2014 20:00:20 +0000 (20:00 +0000)]
pull: suppress error when no remoteref is found
Commit
48059e4 (pull: use merge-base --fork-point when appropriate,
2013-12-08) incorrectly assumes that get_remote_merge_branch will either
yield a non-empty string or return an error, but there are circumstances
where it will yield an empty string.
The previous code then invoked git-rev-list with no arguments, which
results in an error suppressed by redirecting stderr to /dev/null. Now
we invoke git-merge-base with an empty branch name, which also results
in an error. Suppress this in the same way.
Signed-off-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Roman Kagan [Fri, 27 Dec 2013 08:05:15 +0000 (12:05 +0400)]
git-svn: workaround for a bug in svn serf backend
Subversion serf backend in versions 1.8.5 and below has a bug(*) that the
function creating the descriptor of a file change -- add_file() --
doesn't make a copy of its third argument when storing it on the
returned descriptor. As a result, by the time this field is used (in
transactions of file copying or renaming) it may well be released, and
the memory reused.
One of its possible manifestations is the svn assertion triggering on an
invalid path, with a message
svn_fspath__skip_ancestor: Assertion
`svn_fspath__is_canonical(child_fspath)' failed.
This patch works around this bug, by storing the value to be passed as
the third argument to add_file() in a local variable with the same scope
as the file change descriptor, making sure their lifetime is the same.
* [ew: fixed in Subversion r1553376 as noted by Jonathan Nieder]
Cc: Benjamin Pabst <benjamin.pabst85@gmail.com>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Roman Kagan <rkagan@mail.ru>
Jeff King [Fri, 17 Jan 2014 01:25:40 +0000 (20:25 -0500)]
diff_filespec: use only 2 bits for is_binary flag
The is_binary flag needs only three values: -1, 0, and 1.
However, we use a whole 32-bit int for it on most systems
(both 32- and 64- bit).
Instead, we can mark it to use only 2 bits. On 32-bit
systems, this lets it end up as part of the bitfield above
(saving 4 bytes). On 64-bit systems, we don't see any change
(because the savings end up as padding), but it does leave
room for another "free" 32-bit value to be added later.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Fri, 17 Jan 2014 01:22:56 +0000 (20:22 -0500)]
diff_filespec: reorder is_binary field
The middle of the diff_filespec struct contains a mixture of
ints, shorts, and bit-fields, followed by a pointer. On an
x86-64 system with an LP64 or LLP64 data model (i.e., most
of them), the integers and flags end up being padded out by
41 bits to put the pointer at an 8-byte boundary.
After the pointer, we have the "int is_binary" field, which
is only 32 bits. We end up wasting another 32 bits to pad
the struct size up to a multiple of 64 bits.
We can move the is_binary field before the pointer, which
lets the compiler store it where we used to have padding.
This shrinks the top padding to only 9 bits (from the
bit-fields), and eliminates the bottom padding entirely,
dropping the struct size from 88 to 80 bytes.
On a 32-bit system, there is no benefit, but nor should
there be any harm (we only need 4-byte alignment there, so
we were already using only 9 bits of padding).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Fri, 17 Jan 2014 01:21:59 +0000 (20:21 -0500)]
diff_filespec: drop xfrm_flags field
The only mention of this field in the code is by some
debugging code which prints it out (and it will always be
zero, since we never touch it otherwise). It was obsoleted
very early on by
25d5ea4 ([PATCH] Redo rename/copy detection
logic., 2005-05-24).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Fri, 17 Jan 2014 01:20:11 +0000 (20:20 -0500)]
diff_filespec: drop funcname_pattern_ident field
This struct field was obsoleted by
be58e70 (diff: unify
external diff and funcname parsing code, 2008-10-05), but we
forgot to remove it.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Fri, 17 Jan 2014 01:19:46 +0000 (20:19 -0500)]
diff_filespec: reorder dirty_submodule macro definitions
diff_filespec has a 2-bit "dirty_submodule" field and
defines two flags as macros. Originally these were right
next to each other, but a new field was accidentally added
in between in commit
4682d85. This patch puts the field and
its flags back together.
Using an enum like:
enum {
DIRTY_SUBMODULE_UNTRACKED = 1,
DIRTY_SUBMODULE_MODIFIED = 2
} dirty_submodule;
would be more obvious, but it bloats the structure. Limiting
the enum size like:
} dirty_submodule : 2;
might work, but it is not portable.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jonathan Nieder [Thu, 16 Jan 2014 22:43:34 +0000 (14:43 -0800)]
gitignore doc: add global gitignore to synopsis
The gitignore(5) manpage already documents $XDG_CONFIG_HOME/git/ignore
but it is easy to forget that it exists. Add a reminder to the
synopsis.
Noticed while looking for a place to put a list of scratch filenames
in the cwd used by one's editor of choice.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Ruben Kerkhof [Wed, 15 Jan 2014 17:31:11 +0000 (21:31 +0400)]
send-email: /etc/ssl/certs/ directory may not be usable as ca_path
When sending patches on Fedora rawhide with
git-1.8.5.2-1.fc21.x86_64 and perl-IO-Socket-SSL-1.962-1.fc21.noarch,
with the following
[sendemail]
smtpencryption = tls
smtpserver = smtp.gmail.com
smtpuser = ruben@rubenkerkhof.com
smtpserverport = 587
git-send-email fails with:
STARTTLS failed! SSL connect attempt failed with unknown error
error:
14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate
verify failed at /usr/libexec/git-core/git-send-email line 1236.
The current code detects the presence of /etc/ssl/certs directory
(it actually is a symlink to another directory, but that does not
matter) and uses SSL_ca_path to point at it when initializing the
connection with IO::Socket::SSL or Net::SMTP::SSL. However, on the
said platform, it seems that this directory is not designed to be
used as SSL_ca_path. Using a single file inside that directory
(cert.pem, which is a Mozilla CA bundle) with SSL_ca_file does work,
and also not specifying any SSL_ca_file/SSL_ca_path (and letting the
library use its own default) and asking for peer verification does
work.
By removing the code that blindly defaults $smtp_ssl_cert_path to
"/etc/ssl/certs", we can prevent the codepath that treats any
directory specified with that variable as usable for SSL_ca_path
from incorrectly triggering.
This change could introduce a regression for people on a platform
whose certificate directory is /etc/ssl/certs but its IO::Socket:SSL
somehow fails to use it as SSL_ca_path without being told. Using
/etc/ssl/certs directory as SSL_ca_path by default like the current
code does would have been hiding such a broken installation without
its user needing to do anything. These users can still work around
such a platform bug by setting the configuration variable explicitly
to point at /etc/ssl/certs.
This change should not negate what
35035bbf (send-email: be explicit
with SSL certificate verification, 2013-07-18), which was the
original change that introduced the defaulting to /etc/ssl/certs/,
attempted to do, which is to make sure we do not communicate over
insecure connection by default, triggering warning from the library.
Cf. https://bugzilla.redhat.com/show_bug.cgi?id=
1043194
Tested-by: Igor Gnatenko <i.gnatenko.brain@gmail.com>
Signed-off-by: Ruben Kerkhof <ruben@rubenkerkhof.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Wed, 15 Jan 2014 20:26:13 +0000 (12:26 -0800)]
revision: propagate flag bits from tags to pointees
With the previous fix
895c5ba3 (revision: do not peel tags used in
range notation, 2013-09-19), handle_revision_arg() that processes
command line arguments for the "git log" family of commands no
longer directly places the object pointed by the tag in the pending
object array when it sees a tag object. We used to place pointee
there after copying the flag bits like UNINTERESTING and
SYMMETRIC_LEFT.
This change meant that any flag that is relevant to later history
traversal must now be propagated to the pointed objects (most often
these are commits) while starting the traversal, which is partly
done by handle_commit() that is called from prepare_revision_walk().
We did propagate UNINTERESTING, but did not do so for others, most
notably SYMMETRIC_LEFT. This caused "git log --left-right v1.0..."
(where "v1.0" is a tag) to start losing the "leftness" from the
commit the tag points at.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Wed, 15 Jan 2014 23:38:01 +0000 (15:38 -0800)]
revision: mark contents of an uninteresting tree uninteresting
"git rev-list --objects ^A^{tree} B^{tree}" ought to mean "I want a
list of objects inside B's tree, but please exclude the objects that
appear inside A's tree".
we see the top-level tree marked as uninteresting (i.e. ^A^{tree} in
the above example) and call mark_tree_uninteresting() on it; this
unfortunately prevents us from recursing into the tree and marking
the objects in the tree as uninteresting.
The reason why "git log ^A A" yields an empty set of commits,
i.e. we do not have a similar issue for commits, is because we call
mark_parents_uninteresting() after seeing an uninteresting commit.
The uninteresting-ness of the commit itself does not prevent its
parents from being marked as uninteresting.
Introduce mark_tree_contents_uninteresting() and structure the code
in handle_commit() in such a way that it makes it the responsibility
of the callchain leading to this function to mark commits, trees and
blobs as uninteresting, and also make it the responsibility of the
helpers called from this function to mark objects that are reachable
from them.
Note that this is a very old bug that probably dates back to the day
when "rev-list --objects" was introduced. The line to clear
tree->object.parsed at the end of mark_tree_contents_uninteresting()
can be removed when this fix is merged to the codebase after
6e454b9a (clear parsed flag when we free tree buffers, 2013-06-05).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Wed, 15 Jan 2014 08:40:46 +0000 (03:40 -0500)]
interpret_branch_name: find all possible @-marks
When we parse a string like "foo@{upstream}", we look for
the first "@"-sign, and check to see if it is an upstream
mark. However, since branch names can contain an @, we may
also see "@foo@{upstream}". In this case, we check only the
first @, and ignore the second. As a result, we do not find
the upstream.
We can solve this by iterating through all @-marks in the
string, and seeing if any is a legitimate upstream or
empty-at mark.
Another strategy would be to parse from the right-hand side
of the string. However, that does not work for the
"empty_at" case, which allows "@@{upstream}". We need to
find the left-most one in this case (and we then recurse as
"HEAD@{upstream}").
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Wed, 15 Jan 2014 08:37:23 +0000 (03:37 -0500)]
interpret_branch_name: avoid @{upstream} past colon
get_sha1() cannot currently parse a valid object name like
"HEAD:@{upstream}" (assuming that such an oddly named file
exists in the HEAD commit). It takes two passes to parse the
string:
1. It first considers the whole thing as a ref, which
results in looking for the upstream of "HEAD:".
2. It finds the colon, parses "HEAD" as a tree-ish, and then
finds the path "@{upstream}" in the tree.
For a path that looks like a normal reflog (e.g.,
"HEAD:@{yesterday}"), the first pass is a no-op. We try to
dwim_ref("HEAD:"), that returns zero refs, and we proceed
with colon-parsing.
For "HEAD:@{upstream}", though, the first pass ends up in
interpret_upstream_mark, which tries to find the branch
"HEAD:". When it sees that the branch does not exist, it
actually dies rather than returning an error to the caller.
As a result, we never make it to the second pass.
One obvious way of fixing this would be to teach
interpret_upstream_mark to simply report "no, this isn't an
upstream" in such a case. However, that would make the
error-reporting for legitimate upstream cases significantly
worse. Something like "bogus@{upstream}" would simply report
"unknown revision: bogus@{upstream}", while the current code
diagnoses a wide variety of possible misconfigurations (no
such branch, branch exists but does not have upstream, etc).
However, we can take advantage of the fact that a branch
name cannot contain a colon. Therefore even if we find an
upstream mark, any prefix with a colon must mean that
the upstream mark we found is actually a pathname, and
should be disregarded completely. This patch implements that
logic.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Wed, 15 Jan 2014 08:31:57 +0000 (03:31 -0500)]
interpret_branch_name: always respect "namelen" parameter
interpret_branch_name gets passed a "name" buffer to parse,
along with a "namelen" parameter representing its length. If
"namelen" is zero, we fallback to the NUL-terminated
string-length of "name".
However, it does not necessarily follow that if we have
gotten a non-zero "namelen", it is the NUL-terminated
string-length of "name". E.g., when get_sha1() is parsing
"foo:bar", we will be asked to operate only on the first
three characters.
Yet in interpret_branch_name and its helpers, we use string
functions like strchr() to operate on "name", looking past
the length we were given. This can result in us mis-parsing
object names. We should instead be limiting our search to
"namelen" bytes.
There are three distinct types of object names this patch
addresses:
- The intrepret_empty_at helper uses strchr to find the
next @-expression after our potential empty-at. In an
expression like "@:foo@bar", it erroneously thinks that
the second "@" is relevant, even if we were asked only
to look at the first character. This case is easy to
trigger (and we test it in this patch).
- When finding the initial @-mark for @{upstream}, we use
strchr. This means we might treat "foo:@{upstream}" as
the upstream for "foo:", even though we were asked only
to look at "foo". We cannot test this one in practice,
because it is masked by another bug (which is fixed in
the next patch).
- The interpret_nth_prior_checkout helper did not receive
the name length at all. This turns out not to be a
problem in practice, though, because its parsing is so
limited: it always starts from the far-left of the
string, and will not tolerate a colon (which is
currently the only way to get a smaller-than-strlen
"namelen"). However, it's still worth fixing to make the
code more obviously correct, and to future-proof us
against callers with more exotic buffers.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Wed, 15 Jan 2014 08:27:32 +0000 (03:27 -0500)]
interpret_branch_name: rename "cp" variable to "at"
In the original version of this function, "cp" acted as a
pointer to many different things. Since the refactoring in
the last patch, it only marks the at-sign in the string.
Let's use a more descriptive variable name.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Wed, 15 Jan 2014 08:26:33 +0000 (03:26 -0500)]
interpret_branch_name: factor out upstream handling
This function checks a few different @{}-constructs. The
early part checks for and dispatches us to helpers for each
construct, but the code for handling @{upstream} is inline.
Let's factor this out into its own function. This makes
interpret_branch_name more readable, and will make it much
simpler to further refactor the function in future patches.
While we're at it, let's also break apart the refactored
code into a few helper functions. These will be useful if we
eventually implement similar @{upstream}-like constructs.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Wed, 15 Jan 2014 10:46:13 +0000 (05:46 -0500)]
fetch-pack: do not filter out one-level refs
Currently fetching a one-level ref like "refs/foo" does not
work consistently. The outer "git fetch" program filters the
list of refs, checking each against check_refname_format.
Then it feeds the result to do_fetch_pack to actually
negotiate the haves/wants and get the pack. The fetch-pack
code does its own filter, and it behaves differently.
The fetch-pack filter looks for refs in "refs/", and then
feeds everything _after_ the slash (i.e., just "foo") into
check_refname_format. But check_refname_format is not
designed to look at a partial refname. It complains that the
ref has only one component, thinking it is at the root
(i.e., alongside "HEAD"), when in reality we just fed it a
partial refname.
As a result, we omit a ref like "refs/foo" from the pack
request, even though "git fetch" then tries to store the
resulting ref. If we happen to get the object anyway (e.g.,
because the ref is contained in another ref we are
fetching), then the fetch succeeds. But if it is a unique
object, we fail when trying to update "refs/foo".
We can fix this by just passing the whole refname into
check_refname_format; we know the part we were omitting is
"refs/", which is acceptable in a refname. This at least
makes the checks consistent with each other.
This problem happens most commonly with "refs/stash", which
is the only one-level ref in wide use. However, our test
does not use "refs/stash", as we may later want to restrict
it specifically (not because it is one-level, but because
of the semantics of stashes).
We may also want to do away with the multiple levels of
filtering (which can cause problems when they are out of
sync), or even forbid one-level refs entirely. However,
those decisions can come later; this fixes the most
immediate problem, which is the mismatch between the two.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Michael Haggerty [Tue, 14 Jan 2014 03:16:07 +0000 (04:16 +0100)]
refname_match(): always use the rules in ref_rev_parse_rules
We used to use two separate rules for the normal ref resolution
dwimming and dwimming done to decide which remote ref to grab. The
third parameter to refname_match() selected which rules to use.
When these two rules were harmonized in
2011-11-04
dd621df9cd refs DWIMmery: use the same rule for both "git fetch" and others
, ref_fetch_rules was #defined to avoid potential breakages for
in-flight topics.
It is now safe to remove the backwards-compatibility code, so remove
refname_match()'s third parameter, make ref_rev_parse_rules private to
refs.c, and remove ref_fetch_rules entirely.
Suggested-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Michael Haggerty [Tue, 14 Jan 2014 02:58:49 +0000 (03:58 +0100)]
gitattributes: document more clearly where macros are allowed
The old text made it sound like macros are only allowed in the
.gitattributes file at the top-level of the working tree. Make it
clear that they are also allowed in $GIT_DIR/info/attributes and in
the global and system-wide gitattributes files.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Tue, 14 Jan 2014 18:26:21 +0000 (10:26 -0800)]
Documentation: "git pull" does not have the "-m" option
Even though "--[no-]edit" can be used with "git pull", the
explanation of the interaction between this option and the "-m"
option does not make sense within the context of "git pull". Use
the conditional inclusion mechanism to remove this part from "git
pull" documentation, while keeping it for "git merge".
Reported-by: Ivan Zakharyaschev
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Tue, 14 Jan 2014 18:47:09 +0000 (10:47 -0800)]
Merge branch 'jc/maint-pull-docfix-for-
409b8d82' into jc/maint-pull-docfix
* jc/maint-pull-docfix-for-
409b8d82:
Documentation: exclude irrelevant options from "git pull"
Junio C Hamano [Tue, 14 Jan 2014 18:26:21 +0000 (10:26 -0800)]
Documentation: exclude irrelevant options from "git pull"
10eb64f5 (git pull manpage: don't include -n from fetch-options.txt,
2008-01-25) introduced a way to exclude some parts of included
source when building git-pull documentation, and later
409b8d82
(Documentation/git-pull: put verbosity options before merge/fetch
ones, 2010-02-24) attempted to use the mechanism to exclude some
parts of merge-options.txt when used from git-pull.txt.
However, the latter did not have an intended effect, because the
macro "git-pull" used to decide if the source is included in
git-pull documentation were defined a bit too late.
Define the macro before it is used to fix this.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Anthony Baire [Wed, 27 Nov 2013 18:34:09 +0000 (19:34 +0100)]
subtree: fix argument validation in add/pull/push
When working with a remote repository add/pull/push do not accept a
<refspec> as parameter but just a <ref>. They should accept any
well-formatted ref name.
This patch:
- relaxes the check the <ref> argument in "git subtree add <repo>"
(previous code would not accept a ref name that does not exist
locally too, new code only ensures that the ref is well formatted)
- add the same check in "git subtree pull/push" + check the number of
parameters
- update the doc to use <ref> instead of <refspec>
Signed-off-by: Anthony Baire <Anthony.Baire@irisa.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
John Keeping [Sat, 11 Jan 2014 14:27:13 +0000 (14:27 +0000)]
completion: handle --[no-]fork-point options to git-rebase
Signed-off-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>