summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2014-01-27Merge branch 'mh/safe-create-leading-directories'Libravatar Junio C Hamano6-67/+155
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
2014-01-27Merge branch 'tr/nth-previous-is-a-commit'Libravatar Junio C Hamano2-3/+3
* tr/nth-previous-is-a-commit: Documentation: @{-N} can refer to a commit
2014-01-27Merge branch 'tr/gitk-doc-range-trace'Libravatar Junio C Hamano1-0/+16
* tr/gitk-doc-range-trace: Documentation/gitk: document -L option
2014-01-27Merge branch 'jk/mark-edges-uninteresting'Libravatar Junio C Hamano2-9/+23
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
2014-01-27Merge branch 'jk/diff-filespec-cleanup'Libravatar Junio C Hamano2-7/+5
* 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
2014-01-27Merge branch 'ef/mingw-write'Libravatar Junio C Hamano5-25/+4
* ef/mingw-write: mingw: remove mingw_write prefer xwrite instead of write
2014-01-27Merge branch 'rk/send-email-ssl-cert'Libravatar Junio C Hamano1-1/+2
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
2014-01-27Merge branch 'jn/ignore-doc'Libravatar Junio C Hamano1-1/+1
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
2014-01-27Merge branch 'jk/interpret-branch-name-fix'Libravatar Junio C Hamano3-45/+124
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
2014-01-27Merge branch 'jk/allow-fetch-onelevel-refname'Libravatar Junio C Hamano2-1/+12
"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
2014-01-27Merge branch 'jc/revision-range-unpeel'Libravatar Junio C Hamano2-12/+33
"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
2014-01-27Merge branch 'mh/retire-ref-fetch-rules'Libravatar Junio C Hamano3-10/+13
Code simplification. * mh/retire-ref-fetch-rules: refname_match(): always use the rules in ref_rev_parse_rules
2014-01-27Merge branch 'mh/attr-macro-doc'Libravatar Junio C Hamano1-3/+6
* mh/attr-macro-doc: gitattributes: document more clearly where macros are allowed
2014-01-27Merge branch 'jc/maint-pull-docfix'Libravatar Junio C Hamano2-5/+8
* jc/maint-pull-docfix: Documentation: "git pull" does not have the "-m" option Documentation: exclude irrelevant options from "git pull"
2014-01-27Merge branch 'jk/complete-merge-base'Libravatar Junio C Hamano1-1/+7
* jk/complete-merge-base: completion: handle --[no-]fork-point options to git-rebase completion: complete merge-base options
2014-01-27Merge branch 'ab/subtree-doc'Libravatar Junio C Hamano2-13/+23
* ab/subtree-doc: subtree: fix argument validation in add/pull/push
2014-01-23Makefile: Fix compilation of Windows resource fileLibravatar Johannes Sixt2-3/+3
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>
2014-01-23Merge git://git.bogomips.org/git-svnLibravatar Junio C Hamano1-3/+38
* 'master' of git://git.bogomips.org/git-svn: git-svn: memoize _rev_list and rebuild
2014-01-23Merge git://ozlabs.org/~paulus/gitkLibravatar Junio C Hamano3-11/+1396
* '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
2014-01-23gitk: Indent word-wrapped lines in commit display headerLibravatar Paul Mackerras1-1/+1
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>
2014-01-23git-svn: memoize _rev_list and rebuildLibravatar lin zuojian1-3/+38
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>
2014-01-22Add cross-references between docs for for-each-ref and show-refLibravatar Michael Haggerty2-0/+5
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>
2014-01-22gitk: Comply with XDG base directory specificationLibravatar Astril Hayato1-5/+30
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>
2014-01-21list-objects: only look at cmdline trees with edge_hintLibravatar Jeff King1-9/+11
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>
2014-01-21t/perf: time rev-list with UNINTERESTING commitsLibravatar Jeff King1-0/+12
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>
2014-01-21Documentation: @{-N} can refer to a commitLibravatar Thomas Rast2-3/+3
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>
2014-01-21rename_tmp_log(): on SCLD_VANISHED, retryLibravatar Michael Haggerty1-1/+8
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>
2014-01-21rename_tmp_log(): limit the number of remote_empty_directories() attemptsLibravatar Michael Haggerty1-2/+2
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>
2014-01-21rename_tmp_log(): handle a possible mkdir/rmdir raceLibravatar Michael Haggerty1-1/+10
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>
2014-01-21rename_ref(): extract function rename_tmp_log()Libravatar Michael Haggerty1-22/+30
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>
2014-01-21remove_dir_recurse(): handle disappearing files and directoriesLibravatar Michael Haggerty1-6/+16
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>
2014-01-21remove_dir_recurse(): tighten condition for removing unreadable dirLibravatar Michael Haggerty1-2/+5
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>
2014-01-21lock_ref_sha1_basic(): if locking fails with ENOENT, retryLibravatar Michael Haggerty1-1/+12
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>
2014-01-21lock_ref_sha1_basic(): on SCLD_VANISHED, retryLibravatar Michael Haggerty1-1/+10
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>
2014-01-21Documentation/gitk: document -L optionLibravatar Thomas Rast1-0/+16
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>
2014-01-21Merge tag 'gitgui-0.19.0' of http://repo.or.cz/r/git-guiLibravatar Junio C Hamano7-12/+3032
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
2014-01-21gitk: Replace "next" and "prev" buttons with down and up arrowsLibravatar Marc Branchaud1-2/+28
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>
2014-01-21gitk: chmod +x po2msg.shLibravatar Jonathan Nieder1-0/+0
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>
2014-01-21gitk: Update copyright datesLibravatar Paul Mackerras1-2/+2
Signed-off-by: Paul Mackerras <paulus@samba.org>
2014-01-21gitk: Add Bulgarian translation (304t)Libravatar Alexander Shopov1-0/+1334
Signed-off-by: Alexander Shopov <ash@kambanaria.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2014-01-21gitk: Fix mistypeLibravatar Max Kirillov1-1/+1
Signed-off-by: Max Kirillov <max@max630.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2014-01-18git-gui 0.19Libravatar Pat Thoyts1-1/+1
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
2014-01-18git-gui: chmod +x po2msg, windows/git-gui.shLibravatar Jonathan Nieder2-0/+0
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>
2014-01-18git-gui: fallback right pane to packed widgets with Tk 8.4Libravatar Max Kirillov1-11/+21
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>
2014-01-18git-gui i18n: Added Bulgarian translationLibravatar Alexander Shopov1-0/+2694
Signed-off-by: Alexander Shopov <ash@kambanaria.org> Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
2014-01-18git-gui l10n: Add 29 more terms to glossaryLibravatar Alexander Shopov1-0/+29
Signed-off-by: Alexander Shopov <ash@kambanaria.org> Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
2014-01-18git-gui i18n: Initial glossary in BulgarianLibravatar Alexander Shopov1-0/+287
Signed-off-by: Alexander Shopov <ash@kambanaria.org> Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
2014-01-17Git 1.9-rc0Libravatar Junio C Hamano2-1/+13
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-17Merge branch 'maint'Libravatar Junio C Hamano0-0/+0
* maint: git-svn: workaround for a bug in svn serf backend
2014-01-17Merge branch 'fp/submodule-checkout-mode'Libravatar Junio C Hamano1-1/+12
"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