summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2012-10-16l10n: Update Swedish translation (1964t0f0u)Libravatar Peter Krefting1-441/+438
Signed-off-by: Peter Krefting <peter@softwolves.pp.se>
2012-10-16l10n: Update git.pot (3 new, 6 removed messages)Libravatar Jiang Xin1-437/+415
This po/git.pot update is generated from v1.8.0-rc2-4-g42e55. Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
2012-10-16Merge branch 'master' of git://github.com/vnwildman/gitLibravatar Jiang Xin1-672/+4096
* 'master' of git://github.com/vnwildman/git: l10n: vi.po: update translation upto cc76011
2012-10-15l10n: vi.po: update translation upto cc76011Libravatar Tran Ngoc Quan1-672/+4096
* translate all new messages (100%) * review some others Signed-off-by: Tran Ngoc Quan <vnwildman@gmail.com>
2012-10-13Merge branch 'maint'Libravatar Junio C Hamano1-1/+1
* maint: Fix spelling error in post-receive-email hook
2012-10-13Fix spelling error in post-receive-email hookLibravatar Richard Fearn1-1/+1
Signed-off-by: Richard Fearn <richardfearn@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-12Merge branch 'maint'Libravatar Junio C Hamano1-1/+1
* maint: gitweb.cgi: fix "comitter_tz" typo in feed
2012-10-12gitweb.cgi: fix "comitter_tz" typo in feedLibravatar Dylan Alex Simon1-1/+1
gitweb's feeds sometimes contained committer timestamps in the wrong timezone due to a misspelling. Signed-off-by: Dylan Simon <dylan@dylex.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-11Git 1.8.0-rc2Libravatar Junio C Hamano1-1/+1
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-10Merge branch 'rr/git-uri-doc'Libravatar Junio C Hamano1-2/+6
* rr/git-uri-doc: Git url doc: mark ftp/ftps as read-only and deprecate them
2012-10-10Merge branch 'bw/cp-a-is-gnuism'Libravatar Junio C Hamano3-3/+3
* bw/cp-a-is-gnuism: tests: "cp -a" is a GNUism
2012-10-10Merge branch 'nd/doc-ignore'Libravatar Junio C Hamano1-1/+5
* nd/doc-ignore: gitignore.txt: suggestions how to get literal # or ! at the beginning
2012-10-10Merge branch 'jc/doc-long-options'Libravatar Junio C Hamano1-1/+11
* jc/doc-long-options: gitcli: parse-options lets you omit tail of long options
2012-10-10Sync with maintLibravatar Junio C Hamano1-0/+5
* maint: attr: a note about the order of .gitattributes lookup
2012-10-10Merge git://bogomips.org/git-svnLibravatar Junio C Hamano2-2/+25
* git://bogomips.org/git-svn: svn test: escape peg revision separator using empty peg rev git svn: work around SVN 1.7 mishandling of svn:special changes
2012-10-10svn test: escape peg revision separator using empty peg revLibravatar Jonathan Nieder1-1/+1
This test script uses "svn cp" to create a branch with an @-sign in its name: svn cp "pr ject/trunk" "pr ject/branches/not-a@{0}reflog" That sets up for later tests that fetch the branch and check that git svn mangles the refname appropriately. Unfortunately, modern svn versions interpret path arguments with an @-sign as an example of path@revision syntax (which pegs a path to a particular revision) and truncate the path or error out with message "svn: E205000: Syntax error parsing peg revision '{0}reflog'". When using subversion 1.6.x, escaping the @ sign as %40 avoids trouble (see 08fd28bb, 2010-07-08). Newer versions are stricter: $ svn cp "$repo/pr ject/trunk" "$repo/pr ject/branches/not-a%40{reflog}" svn: E205000: Syntax error parsing peg revision '%7B0%7Dreflog' The recommended method for escaping a literal @ sign in a path passed to subversion is to add an empty peg revision at the end of the path ("branches/not-a@{0}reflog@"). Do that. Pre-1.6.12 versions of Subversion probably treat the trailing @ as another literal @-sign (svn issue 3651). Luckily ever since v1.8.0-rc0~155^2~7 (t9118: workaround inconsistency between SVN versions, 2012-07-28) the test can survive that. Tested with Debian Subversion 1.6.12dfsg-6 and 1.7.5-1 and r1395837 of Subversion trunk (1.8.x). Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Tested-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Eric Wong <normalperson@yhbt.net>
2012-10-10git svn: work around SVN 1.7 mishandling of svn:special changesLibravatar Jonathan Nieder1-1/+24
Subversion represents symlinks as ordinary files with content starting with "link " and the svn:special property set to "*". Thus a file can switch between being a symlink and a non-symlink simply by toggling its svn:special property, and new checkouts will automatically write a file of the appropriate type. Likewise, in subversion 1.6 and older, running "svn update" would notice changes in filetype and update the working copy appropriately. Starting in subversion 1.7 (issue 4091), changes to the svn:special property trip an assertion instead: $ svn up svn-tree Updating 'svn-tree': svn: E235000: In file 'subversion/libsvn_wc/update_editor.c' \ line 1583: assertion failed (action == svn_wc_conflict_action_edit \ || action == svn_wc_conflict_action_delete || action == \ svn_wc_conflict_action_replace) Revisions prepared with ordinary svn commands ("svn add" and not "svn propset") don't trip this because they represent these filetype changes using a replace operation, which is approximately equivalent to removal followed by adding a new file and works fine. Follow suit. Noticed using t9100. After this change, git-svn's file-to-symlink changes are sent in a format that modern "svn update" can handle and tests t9100.11-13 pass again. [ew: s,git-svn\.perl,perl/Git/SVN/Editor.pm,g] Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Eric Wong <normalperson@yhbt.net>
2012-10-10MALLOC_CHECK: Allow checking to be disabled from config.makLibravatar Ramsay Jones1-0/+1
The malloc checks can be disabled using the TEST_NO_MALLOC_CHECK variable, either from the environment or command line of an 'make test' invocation. In order to allow the malloc checks to be disabled from the 'config.mak' file, we add TEST_NO_MALLOC_CHECK to the environment using an export directive. Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-10attr: a note about the order of .gitattributes lookupLibravatar Nguyen Thai Ngoc Duy1-0/+5
This is the documentation part of 1a9d7e9 (attr.c: read .gitattributes from index as well. - 2007-08-14) 06f33c1 (Read attributes from the index that is being checked out - 2009-03-13) Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-09Merge branch 'maint'Libravatar Junio C Hamano1-7/+7
* maint: l10n: de.po: fix a few minor typos
2012-10-09configure.ac: Add missing comma to CC_LD_DYNPATHLibravatar Øyvind A. Holm1-1/+1
40bfbde ("build: don't duplicate substitution of make variables", 2012-09-11) by mistake removed a necessary comma at the end of "CC_LD_DYNPATH=-Wl,rpath," in line 414. When executing "./configure --with-zlib=PATH", this resulted in [...] CC xdiff/xhistogram.o AR xdiff/lib.a LINK git-credential-store /usr/bin/ld: bad -rpath option collect2: ld returned 1 exit status make: *** [git-credential-store] Error 1 $ during make. Signed-off-by: Øyvind A. Holm <sunny@sunbase.org> Acked-by: Stefano Lattarini <stefano.lattarini@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-09Merge branch 'maint' of git://github.com/git-l10n/git-po into maintLibravatar Junio C Hamano1-7/+7
* 'maint' of git://github.com/git-l10n/git-po: l10n: de.po: fix a few minor typos
2012-10-08tests: "cp -a" is a GNUismLibravatar Ben Walton3-3/+3
These tests just want a bit-for-bit identical copy; they do not need even -H (there is no symbolic link involved) nor -p (there is no funny permission or ownership issues involved). Just use "cp -R" instead. Signed-off-by: Ben Walton <bdwalton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-08Git url doc: mark ftp/ftps as read-only and deprecate themLibravatar Ramkumar Ramachandra1-2/+6
It is not even worth mentioning their removal; just discourage people from using them. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-08Git 1.8.0-rc1Libravatar Junio C Hamano2-12/+4
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-08Merge branch 'jc/maint-t1450-fsck-order-fix'Libravatar Junio C Hamano1-3/+1
The fsck test assumed too much on what kind of error it will detect. The only important thing is the inconsistency is detected as an error. * jc/maint-t1450-fsck-order-fix: t1450: the order the objects are checked is undefined
2012-10-08Merge branch 'jc/merge-bases-paint-fix'Libravatar Junio C Hamano1-0/+5
"git fmt-merge-msg" (an internal helper reduce_heads() it uses) had a severe performance regression; an empty "git pull" took forever to finish as the result. * jc/merge-bases-paint-fix: paint_down_to_common(): parse commit before relying on its timestamp
2012-10-08Sync with 1.7.12.3Libravatar Junio C Hamano2-1/+18
2012-10-08Git 1.7.12.3Libravatar Junio C Hamano3-2/+19
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-08Merge branch 'os/commit-submodule-ignore' into maintLibravatar Junio C Hamano1-0/+1
"git status" honored the ignore=dirty settings in .gitmodules but "git commit" didn't. * os/commit-submodule-ignore: commit: pay attention to submodule.$name.ignore in .gitmodules
2012-10-08Merge branch 'jk/receive-pack-unpack-error-to-pusher' into maintLibravatar Junio C Hamano2-5/+32
"git receive-pack" (the counterpart to "git push") did not give progress output while processing objects it received to the puser when run over the smart-http protocol. * jk/receive-pack-unpack-error-to-pusher: receive-pack: drop "n/a" on unpacker errors receive-pack: send pack-processing stderr over sideband receive-pack: redirect unpack-objects stdout to /dev/null
2012-10-08Merge branch 'rt/maint-clone-single' into maintLibravatar Junio C Hamano3-18/+218
A repository created with "git clone --single" had its fetch refspecs set up just like a clone without "--single", leading the subsequent "git fetch" to slurp all the other branches, defeating the whole point of specifying "only this branch". * rt/maint-clone-single: clone --single: limit the fetch refspec to fetched branch
2012-10-08Merge branch 'jc/blame-follows-renames' into maintLibravatar Junio C Hamano1-0/+6
It was unclear in the documentation for "git blame" that it is unnecessary for users to use the "--follow" option. * jc/blame-follows-renames: git blame: document that it always follows origin across whole-file renames
2012-10-08Merge branch 'lt/mailinfo-handle-attachment-more-sanely' into maintLibravatar Junio C Hamano1-11/+0
A patch attached as application/octet-stream (e.g. not text/*) were mishandled, not correctly honoring Content-Transfer-Encoding (e.g. base64). * lt/mailinfo-handle-attachment-more-sanely: mailinfo: don't require "text" mime type for attachments
2012-10-07gitignore.txt: suggestions how to get literal # or ! at the beginningLibravatar Nguyễn Thái Ngọc Duy1-1/+5
We support backslash escape, but we hide the details behind the phrase "a shell glob suitable for consumption by fnmatch(3)". So it may not be obvious how one can get literal # or ! at the beginning of pattern. Add a few lines on how to work around the magic characters. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-05git-svn: keep leading slash when canonicalizing paths (fallback case)Libravatar Jonathan Nieder1-1/+0
Subversion's svn_dirent_canonicalize() and svn_path_canonicalize() APIs keep a leading slash in the return value if one was present on the argument, which can be useful since it allows relative and absolute paths to be distinguished. When git-svn's canonicalize_path() learned to use these functions if available, its semantics changed in the corresponding way. Some new callers rely on the leading slash --- for example, if the slash is stripped out then _canonicalize_url_ourselves() will transform "proto://host/path/to/resource" to "proto://hostpath/to/resource". Unfortunately the fallback _canonicalize_path_ourselves(), used when the appropriate SVN APIs are not usable, still follows the old semantics, so if that code path is exercised then it breaks. Fix it to follow the new convention. Noticed by forcing the fallback on and running tests. Without this patch, t9101.4 fails: Bad URL passed to RA layer: Unable to open an ra_local session to \ URL: Local URL 'file://homejrnsrcgit-scratch/t/trash%20directory.\ t9101-git-svn-props/svnrepo' contains unsupported hostname at \ /home/jrn/src/git-scratch/perl/blib/lib/Git/SVN.pm line 148 With it, the git-svn tests pass again. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Eric Wong <normalperson@yhbt.net>
2012-10-05Git::SVN: rename private path fieldLibravatar Jonathan Nieder1-2/+2
All users of $gs->{path} should have been converted to use the accessor by now. Check our work by renaming the underlying variable to break callers that try to use it directly. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Eric Wong <normalperson@yhbt.net>
2012-10-05git-svn: use path accessor for Git::SVN objectsLibravatar Eric Wong2-2/+2
The accessors should improve maintainability and enforce consistent access to Git::SVN objects. Signed-off-by: Eric Wong <normalperson@yhbt.net> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
2012-10-05Make git-svn branch patterns match complete URLLibravatar Ammon Riley2-1/+12
When using the {word,[...]} style of configuration for tags and branches, it appears the intent is to only match whole path parts, since the words in the {} pattern are meta-character quoted. When the pattern word appears in the beginning or middle of the url, it's matched completely, since the left side, pattern, and (non-empty) right side are joined together with path separators. However, when the pattern word appears at the end of the URL, the right side is an empty pattern, and the resulting regex matches more than just the specified pattern. For example, if you specify something along the lines of branches = branches/project/{release_1,release_2} and your repository also contains "branches/project/release_1_2", you will also get the release_1_2 branch. By restricting the match regex with anchors, this is avoided. Signed-off-by: Ammon Riley <ammon.riley@gmail.com> Signed-off-by: Eric Wong <normalperson@yhbt.net>
2012-10-05t9164: Add missing quotes in testLibravatar Robert Luberda1-4/+4
This fixes `ambiguous redirect' error given by bash. [ew: fix misspelled test name, also eliminate space after ">>" to conform to guidelines] Signed-off-by: Eric Wong <normalperson@yhbt.net>
2012-10-05git-svn.perl: keep processing all commits in parents_excludeLibravatar Steven Walter2-1/+53
This fixes a bug where git finds the incorrect merge parent. Consider a repository with trunk, branch1 of trunk, and branch2 of branch1. Without this change, git interprets a merge of branch2 into trunk as a merge of branch1 into trunk. Signed-off-by: Steven Walter <stevenrwalter@gmail.com> Reviewed-by: Sam Vilain <sam@vilain.net> Signed-off-by: Eric Wong <normalperson@yhbt.net>
2012-10-05git-svn.perl: consider all ranges for a given merge, instead of only tip-by-tipLibravatar Steven Walter2-5/+63
Consider the case where you have trunk, branch1 of trunk, and branch2 of branch1. trunk is merged back into branch2, and then branch2 is reintegrated into trunk. The merge of branch2 into trunk will have svn:mergeinfo property references to both branch1 and branch2. When git-svn fetches the commit that merges branch2 (check_cherry_pick), it is necessary to eliminate the merged contents of branch1 as well as branch2, or else the merge will be incorrectly ignored as a cherry-pick. Signed-off-by: Steven Walter <stevenrwalter@gmail.com> Reviewed-by: Sam Vilain <sam@vilain.net> Signed-off-by: Eric Wong <normalperson@yhbt.net>
2012-10-04gitcli: parse-options lets you omit tail of long optionsLibravatar Junio C Hamano1-1/+11
Describe the behaviour, but do warn people against taking it too literally and expect an abbreviation valid today will stay valid forever. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-04paint_down_to_common(): parse commit before relying on its timestampLibravatar Junio C Hamano1-0/+5
When refactoring the merge-base computation to reduce the pairwise O(n*(n-1)) traversals to parallel O(n) traversals, the code forgot that timestamp based heuristics needs each commit to have been parsed. This caused an empty "git pull" to spend cycles, traversing the history all the way down to 0 (because an unparsed commit object has 0 timestamp, and any other commit object with positive timestamp will be processed for its parents, all getting parsed), only to come up with a merge message to be used. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-04l10n: de.po: fix a few minor typosLibravatar Simon Ruderich1-7/+7
Signed-off-by: Simon Ruderich <simon@ruderich.org> Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
2012-10-02Update draft release notes to 1.8.0Libravatar Junio C Hamano1-0/+12
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-02Merge branch 'nd/grep-reflog'Libravatar Junio C Hamano5-5/+105
Teach the commands from the "log" family the "--grep-reflog" option to limit output by string that appears in the reflog entry when the "--walk-reflogs" option is in effect. * nd/grep-reflog: revision: make --grep search in notes too if shown log --grep-reflog: reject the option without -g revision: add --grep-reflog to filter commits by reflog messages grep: prepare for new header field filter
2012-10-02Merge branch 'lt/mailinfo-handle-attachment-more-sanely'Libravatar Junio C Hamano1-11/+0
A patch attached as application/octet-stream (e.g. not text/*) were mishandled, not correctly honoring Content-Transfer-Encoding (e.g. base64). * lt/mailinfo-handle-attachment-more-sanely: mailinfo: don't require "text" mime type for attachments
2012-10-02Merge branch 'tu/gc-auto-quiet'Libravatar Junio C Hamano2-5/+2
"gc --auto" notified the user that auto-packing has triggered even under the "--quiet" option. * tu/gc-auto-quiet: silence git gc --auto --quiet output
2012-10-02t1450: the order the objects are checked is undefinedLibravatar Junio C Hamano1-3/+1
When a tag T points at an object X that is of a type that is different from what the tag records as, fsck should report it as an error. However, depending on the order X and T are checked individually, the actual error message can be different. If X is checked first, fsck remembers X's type and then when it checks T, it notices that T records X as a wrong type (i.e. the complaint is about a broken tag T). If T is checked first, on the other hand, fsck remembers that we need to verify X is of the type tag records, and when it later checks X, it notices that X is of a wrong type (i.e. the complaint is about a broken object X). The important thing is that fsck notices such an error and diagnoses the issue on object X, but the test was expecting that we happen to check objects in the order to make us detect issues with tag T, not with object X. Remove this unwarranted assumption. Signed-off-by: Junio C Hamano <gitster@pobox.com>