summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2014-02-04setup: don't dereference in-tree symlinks for absolute pathsLibravatar Martin Erik Werner3-22/+12
The prefix_path_gently() function currently applies real_path to everything if given an absolute path, dereferencing symlinks both outside and inside the work tree. This causes most high-level functions to misbehave when acting on symlinks given via absolute paths. For example $ git add /dir/repo/symlink attempts to add the target of the symlink rather than the symlink itself, which is usually not what the user intends to do. In order to manipulate symlinks in the work tree using absolute paths, symlinks should only be dereferenced outside the work tree. Modify the prefix_path_gently() to first normalize the path in order to make sure path levels are separated by '/', then pass the result to 'abspath_part_inside_repo' to find the part inside the work tree (without dereferencing any symlinks inside the work tree). For absolute paths, prefix_path_gently() did not, nor does now do, any actual prefixing, hence the result from abspath_part_in_repo() is returned as-is. Fixes t0060-82 and t3004-5. Signed-off-by: Martin Erik Werner <martinerikwerner@gmail.com> Reviewed-by: Duy Nguyen <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-04setup: add abspath_part_inside_repo() functionLibravatar Martin Erik Werner1-0/+64
In order to extract the part of an absolute path which lies inside the repo, it is not possible to directly use real_path, since that would dereference symlinks both outside and inside the work tree. Add an abspath_part_inside_repo() function which first checks if the work tree is already the prefix, then incrementally checks each path level by temporarily NUL-terminating at each '/' and comparing against the work tree path. If a match is found, it overwrites the input path with the remainder past the work tree (which will be the part inside the work tree). This function is currently only intended for use in 'prefix_path_gently'. Signed-off-by: Martin Erik Werner <martinerikwerner@gmail.com> Reviewed-by: Duy Nguyen <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-04t0060: add tests for prefix_path when path begins with work treeLibravatar Martin Erik Werner1-0/+10
One edge-case that isn't currently checked in the tests is the beginning of the path matching the work tree, despite the target not actually being the work tree, for example: path = /dir/repoa work_tree = /dir/repo should fail since the path is outside the repo. However, if /dir/repoa is in fact a symlink that points to /dir/repo, it should instead succeed. Add two tests covering these cases, since they might be potential regression points. Signed-off-by: Martin Erik Werner <martinerikwerner@gmail.com> Reviewed-by: Duy Nguyen <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-04t0060: add test for prefix_path when path == work treeLibravatar Martin Erik Werner1-0/+6
The current behaviour of prefix_path is to return an empty string if prefixing and absolute path that only contains exactly the work tree. This behaviour is a potential regression point. Signed-off-by: Martin Erik Werner <martinerikwerner@gmail.com> Reviewed-by: Duy Nguyen <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-04t0060: add test for prefix_path on symlinks via absolute pathsLibravatar Martin Erik Werner1-0/+5
When symlinks in the working tree are manipulated using the absolute path, git dereferences them, and tries to manipulate the link target instead. This applies to most high-level commands but prefix_path is the common denominator for all of them. Add a known-breakage tests using the prefix_path function, which currently uses real_path, causing the dereference. Signed-off-by: Martin Erik Werner <martinerikwerner@gmail.com> Reviewed-by: Duy Nguyen <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-04t3004: add test for ls-files on symlinks via absolute pathsLibravatar Junio C Hamano1-0/+17
When symlinks in the working tree are manipulated using the absolute path, git dereferences them, and tries to manipulate the link target instead. This causes most high-level functions to misbehave when acting on symlinks given via absolute paths. For example $ git add /dir/repo/symlink attempts to add the target of the symlink rather than the symlink itself, which is usually not what the user intends to do. This is a regression introduced by 18e051a: setup: translate symlinks in filename when using absolute paths (which did not take symlinks inside the work tree into consideration). Add a known-breakage test using the ls-files function, checking both if the symlink leads to a target in the same directory, and a target in the above directory. Signed-off-by: Martin Erik Werner <martinerikwerner@gmail.com> Tested-by: Martin Erik Werner <martinerikwerner@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-17git-svn: workaround for a bug in svn serf backendLibravatar Roman Kagan1-2/+8
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>
2014-01-13Git 1.8.5.3Libravatar Junio C Hamano4-3/+31
2014-01-13Merge branch 'nd/daemon-informative-errors-typofix' into maintLibravatar Junio C Hamano1-2/+2
The "--[no-]informative-errors" options to "git daemon" were parsed a bit too loosely, allowing any other string after these option names. * nd/daemon-informative-errors-typofix: daemon: be strict at parsing parameters --[no-]informative-errors
2014-01-13Merge branch 'km/gc-eperm' into maintLibravatar Junio C Hamano1-1/+1
A "gc" process running as a different user should be able to stop a new "gc" process from starting. * km/gc-eperm: gc: notice gc processes run by other users
2014-01-13Merge branch 'jk/credential-plug-leak' into maintLibravatar Junio C Hamano1-1/+2
An earlier "clean-up" introduced an unnecessary memory leak. * jk/credential-plug-leak: Revert "prompt: clean up strbuf usage"
2014-01-13Merge branch 'mm/mv-file-to-no-such-dir-with-slash' into maintLibravatar Junio C Hamano2-7/+47
"git mv A B/", when B does not exist as a directory, should error out, but it didn't. * mm/mv-file-to-no-such-dir-with-slash: mv: let 'git mv file no-such-dir/' error out on Windows, too mv: let 'git mv file no-such-dir/' error out
2014-01-13Merge branch 'jk/rev-parse-double-dashes' into maintLibravatar Junio C Hamano2-1/+39
"git rev-parse <revs> -- <paths>" did not implement the usual disambiguation rules the commands in the "git log" family used in the same way. * jk/rev-parse-double-dashes: rev-parse: be more careful with munging arguments rev-parse: correctly diagnose revision errors before "--"
2014-01-13Merge branch 'jk/cat-file-regression-fix' into maintLibravatar Junio C Hamano2-10/+42
"git cat-file --batch=", an admittedly useless command, did not behave very well. * jk/cat-file-regression-fix: cat-file: handle --batch format with missing type/size cat-file: pass expand_data to print_object_or_die
2014-01-13pack-heuristics.txt: mark up the file header properlyLibravatar Thomas Ackermann1-2/+2
AsciiDoc wants these header-lines left-aligned. Signed-off-by: Thomas Ackermann <th.acker@arcor.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-10mv: let 'git mv file no-such-dir/' error out on Windows, tooLibravatar Johannes Sixt1-0/+2
The previous commit c57f628 (mv: let 'git mv file no-such-dir/' error out) relies on that rename("file", "no-such-dir/") fails if the directory does not exist (note the trailing slash). This does not work as expected on Windows: This rename() call does not fail, but renames "file" to "no-such-dir" (not to "no-such-dir/file"). Insert an explicit check for this case to force an error. This changes the error message from $ git mv file no-such-dir/ fatal: renaming 'file' failed: Not a directory to $ git mv file no-such-dir/ fatal: destination directory does not exist, source=file, destination=no-such-dir/ Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-06Merge branch 'maint' of git://github.com/git-l10n/git-po into maintLibravatar Junio C Hamano1-8/+8
* 'maint' of git://github.com/git-l10n/git-po: l10n: de.po: fix translation of 'prefix'
2014-01-06Documentation/gitmodules: Only 'update' and 'url' are requiredLibravatar W. Trevor King1-0/+2
Descriptions for all the settings fell under the initial "Each submodule section also contains the following required keys:". The example shows sections with just 'path' and 'url' entries, which are indeed required, but we should still make the required/optional distinction explicit to clarify that the rest of them are optional. Signed-off-by: W. Trevor King <wking@tremily.us> Reviewed-by: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-03l10n: de.po: fix translation of 'prefix'Libravatar Ralf Thielow1-8/+8
The word 'prefix' is currently translated as 'Prefix' which is not a German word. It should be translated as 'Präfix'. Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
2014-01-02gc: notice gc processes run by other usersLibravatar Kyle J. McKay1-1/+1
Since 64a99eb4 git gc refuses to run without the --force option if another gc process on the same repository is already running. However, if the repository is shared and user A runs git gc on the repository and while that gc is still running user B runs git gc on the same repository the gc process run by user A will not be noticed and the gc run by user B will go ahead and run. The problem is that the kill(pid, 0) test fails with an EPERM error since user B is not allowed to signal processes owned by user A (unless user B is root). Update the test to recognize an EPERM error as meaning the process exists and another gc should not be run (unless --force is given). Signed-off-by: Kyle J. McKay <mackyle@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-02Revert "prompt: clean up strbuf usage"Libravatar Jeff King1-1/+2
This reverts commit 31b49d9b653803e7c7fd18b21c8bdd86e3421668. That commit taught do_askpass to hand ownership of our buffer back to the caller rather than simply return a pointer into our internal strbuf. What it failed to notice, though, was that our internal strbuf is static, because we are trying to emulate the getpass() interface. By handing off ownership, we created a memory leak that cannot be solved. Sometimes git_prompt returns a static buffer from getpass() (or our smarter git_terminal_prompt wrapper), and sometimes it returns an allocated string from do_askpass. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-30for-each-ref: remove unused variableLibravatar Ramkumar Ramachandra1-2/+1
No code ever used this symbol since the command was introduced at 9f613ddd (Add git-for-each-ref: helper for language bindings, 2006-09-15). Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-20daemon: be strict at parsing parameters --[no-]informative-errorsLibravatar Nguyễn Thái Ngọc Duy1-2/+2
Use strcmp() instead of starts_with()/!prefixcmp() to stop accepting --informative-errors-just-a-little Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-17Git 1.8.5.2Libravatar Junio C Hamano4-3/+24
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-17Merge branch 'rs/doc-submitting-patches' into maintLibravatar Junio C Hamano1-2/+9
* rs/doc-submitting-patches: SubmittingPatches: document how to handle multiple patches
2013-12-17Merge branch 'tr/doc-git-cherry' into maintLibravatar Junio C Hamano1-33/+110
* tr/doc-git-cherry: Documentation: revamp git-cherry(1)
2013-12-17Merge branch 'nd/glossary-content-pathspec-markup' into maintLibravatar Junio C Hamano1-3/+3
* nd/glossary-content-pathspec-markup: glossary-content.txt: fix documentation of "**" patterns
2013-12-17Merge branch 'jj/doc-markup-gitcli' into maintLibravatar Junio C Hamano1-5/+5
* jj/doc-markup-gitcli: Documentation/gitcli.txt: fix double quotes
2013-12-17Merge branch 'jj/doc-markup-hints-in-coding-guidelines' into maintLibravatar Junio C Hamano1-3/+31
* jj/doc-markup-hints-in-coding-guidelines: State correct usage of literal examples in man pages in the coding standards
2013-12-17Merge branch 'jj/log-doc' into maintLibravatar Junio C Hamano1-26/+25
* jj/log-doc: Documentation/git-log.txt: mark-up fix and minor rephasing Documentation/git-log: update "--log-size" description
2013-12-17Merge branch 'jj/rev-list-options-doc' into maintLibravatar Junio C Hamano1-156/+87
* jj/rev-list-options-doc: Documentation/rev-list-options.txt: fix some grammatical issues and typos Documentation/rev-list-options.txt: fix mark-up
2013-12-17Merge branch 'tb/doc-fetch-pack-url' into maintLibravatar Junio C Hamano1-8/+7
* tb/doc-fetch-pack-url: git-fetch-pack uses URLs like git-fetch
2013-12-17Merge branch 'mi/typofixes' into maintLibravatar Junio C Hamano8-10/+10
* mi/typofixes: contrib: typofixes Documentation/technical/http-protocol.txt: typofixes typofixes: fix misspelt comments
2013-12-17Merge branch 'jh/loose-object-dirs-creation-race' into maintLibravatar Junio C Hamano1-1/+3
Two processes creating loose objects at the same time could have failed unnecessarily when the name of their new objects started with the same byte value, due to a race condition. * jh/loose-object-dirs-creation-race: sha1_file.c:create_tmpfile(): Fix race when creating loose object dirs
2013-12-17Merge branch 'jk/two-way-merge-corner-case-fix' into maintLibravatar Junio C Hamano3-97/+121
"git am --abort" sometimes complained about not being able to write a tree with an 0{40} object in it. * jk/two-way-merge-corner-case-fix: t1005: add test for "read-tree --reset -u A B" t1005: reindent unpack-trees: fix "read-tree -u --reset A B" with conflicted index
2013-12-17Merge branch 'sb/sha1-loose-object-info-check-existence' into maintLibravatar Junio C Hamano2-6/+15
"git cat-file --batch-check=ok" did not check the existence of the named object. * sb/sha1-loose-object-info-check-existence: sha1_loose_object_info(): do not return success on missing object
2013-12-17Merge branch 'nd/magic-pathspec' into maintLibravatar Junio C Hamano2-10/+13
"git diff -- ':(icase)makefile'" was unnecessarily rejected at the command line parser. * nd/magic-pathspec: diff: restrict pathspec limitations to diff b/f case only
2013-12-17cmd_repack(): remove redundant local variable "nr_packs"Libravatar Michael Haggerty1-4/+2
Its value is the same as the number of entries in the "names" string_list, so just use "names.nr" in its place. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Acked-by: Stefan Beller <stefanbeller@googlemail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-12cat-file: handle --batch format with missing type/sizeLibravatar Jeff King2-1/+32
Commit 98e2092 taught cat-file to stream blobs with --batch, which requires that we look up the object type before loading it into memory. As a result, we now print the object header from information in sha1_object_info, and the actual contents from the read_sha1_file. We double-check that the information we printed in the header matches the content we are about to show. Later, commit 93d2a60 allowed custom header lines for --batch, and commit 5b08640 made type lookups optional. As a result, specifying a header line without the type or size means that we will not look up those items at all. This causes our double-checking to erroneously die with an error; we think the type or size has changed, when in fact it was simply left at "0". For the size, we can fix this by only doing the consistency double-check when we have retrieved the size via sha1_object_info. In the case that we have not retrieved the value, that means we also did not print it, so there is nothing for us to check that we are consistent with. We could do the same for the type. However, besides our consistency check, we also care about the type in deciding whether to stream or not. So instead of handling the case where we do not know the type, this patch instead makes sure that we always trigger a type lookup when we are printing, so that even a format without the type will stream as we would in the normal case. Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-12cat-file: pass expand_data to print_object_or_dieLibravatar Jeff King1-10/+11
We currently individually pass the sha1, type, and size fields calculated by sha1_object_info. However, if we pass the whole struct, the called function can make more intelligent decisions about which fields were actually filled by sha1_object_info. This patch takes that first refactoring step, passing the whole struct, so further patches can make those decisions with less noise in their diffs. There should be no functional change to this patch (aside from a minor typo fix in the error message). As a side effect, we can rename the local variables in the function to "type" and "size", since the names are no longer taken. Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-09rev-parse: be more careful with munging argumentsLibravatar Jeff King1-1/+5
When rev-parse looks at whether an argument like "foo..bar" or "foobar^@" is a difference or parent-shorthand, it internally munges the arguments so that it can pass the individual rev arguments to get_sha1(). However, we do not consistently un-munge the result. For cases where we do not match (e.g., "doesnotexist..HEAD"), we would then want to try to treat the argument as a filename. try_difference gets() this right, and always unmunges in this case. However, try_parent_shorthand() never unmunges, leading to incorrect error messages, or even incorrect results: $ git rev-parse foobar^@ foobar fatal: ambiguous argument 'foobar': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git <command> [<revision>...] -- [<file>...]' $ >foobar $ git rev-parse foobar^@ foobar For cases where we do match, neither function unmunges. This does not currently matter, since we are done with the argument. However, a future patch will do further processing, and this prepares for it. In addition, it's simply a confusing interface for some cases to modify the const argument, and others not to. Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-09rev-parse: correctly diagnose revision errors before "--"Libravatar Jeff King2-0/+34
Rev-parse understands that a "--" may separate revisions and filenames, and that anything after the "--" is taken as-is. However, it does not understand that anything before the token must be a revision (which is the usual rule implemented by the setup_revisions parser). Since rev-parse prefers revisions to files when parsing before the "--", we end up with the correct result (if such an argument is a revision, we parse it as one, and if it is not, it is an error either way). However, we misdiagnose the errors: $ git rev-parse foobar -- >/dev/null fatal: ambiguous argument 'foobar': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git <command> [<revision>...] -- [<file>...]' $ >foobar $ git rev-parse foobar -- >/dev/null fatal: bad flag '--' used after filename In both cases, we should know that the real error is that "foobar" is meant to be a revision, but could not be resolved. Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-04mv: let 'git mv file no-such-dir/' error outLibravatar Matthieu Moy2-7/+45
Git used to trim the trailing slash, and make the command equivalent to 'git mv file no-such-dir', which created the file no-such-dir (while the trailing slash explicitly stated that it could only be a directory). This patch skips the trailing slash removal for the destination path. The path with its trailing slash is passed to rename(2), which errors out with the appropriate message: $ git mv file no-such-dir/ fatal: renaming 'file' failed: Not a directory Original-patch-by: Duy Nguyen <pclouds@gmail.com> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-03Git 1.8.5.1Libravatar Junio C Hamano4-3/+13
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-03ref-iteration doc: add_submodule_odb() returns 0 for successLibravatar Nick Townsend1-2/+2
The usage sample of add_submodule_odb() function in the Submodules section expects non-zero return value for success, but the function actually reports success with zero. Helped-by: René Scharfe <l.s.r@web.de> Reviewed-by: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Nick Townsend <nick.townsend@mac.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-02Sync with 1.8.4.5Libravatar Junio C Hamano4-6/+45
2013-12-02Git 1.8.4.5Libravatar Junio C Hamano4-3/+17
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-02submodule: do not copy unknown update mode from .gitmodulesLibravatar Junio C Hamano2-5/+30
When submodule.$name.update is given as hint from the upstream in the .gitmodules file, we used to blindly copy it to .git/config, unless there already is a value defined for the submodule. However, there is no reason to expect that the update mode hinted by the upstream is available in the version of Git the user is using, and a really custom "!cmd" prepared by an upstream person running on Linux may not even be available to a user on Windows. It is simply irresponsible to copy the setting blindly and to attempt to use it during a later "submodule update" without validating it first. Just show the suggested value to the diagnostic output, and set the value to 'none' in the configuration, if it is not one of the ones that are known to be supported by this version of Git. Helped-by: Jens Lehmann <Jens.Lehmann@web.de> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-11-27Documentation: revamp git-cherry(1)Libravatar Thomas Rast1-33/+110
git-cherry(1)'s "description" section has never really managed to explain to me what the command does. It contains too much explanation of the algorithm instead of simply saying what goals it achieves, and too much terminology that we otherwise do not use (fork-point instead of merge-base). Try a much more concise approach: state what it finds out, why this is neat, and how the output is formatted, in a few short paragraphs. In return, provide much longer examples of how it fits into a "format-patch | am" based workflow, and how it compares to reading the same from git-log. Also carefully avoid using "merge" in a context where it does not mean something that comes from git-merge(1). Instead, say "apply" in an attempt to further link to patch workflow concepts. While there, also omit the language about _which_ upstream branch we treat as the default. I literally just learned that we support having several, so let's not confuse new users here, especially considering that git-config(1) does not document this. Prompted-by: a.huemer@commend.com on #git Signed-off-by: Thomas Rast <tr@thomasrast.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-11-27Git 1.8.5Libravatar Junio C Hamano2-1/+6
Signed-off-by: Junio C Hamano <gitster@pobox.com>