kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
Martin Stenberg	4b34059355	config: report errors at the EOL with correct line number A section in a config file with a missing "]" reports the next line as bad, same goes to a value with a missing end quote. This happens because the error is not detected until the end of the line, when line number is already increased. Fix this by decreasing line number by one for these cases. Signed-off-by: Martin Stenberg <martin@gnutiken.se> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Jonathan Nieder	178e1deaae	fast-import: don't allow 'ls' of path with empty components As the fast-import manual explains: The value of <path> must be in canonical form. That is it must not: . contain an empty directory component (e.g. foo//bar is invalid), . end with a directory separator (e.g. foo/ is invalid), . start with a directory separator (e.g. /foo is invalid), Unfortunately the "ls" command accepts these invalid syntaxes and responds by declaring that the indicated path is missing. This is too subtle and causes importers to silently misbehave; better to error out so the operator knows what's happening. The C, R, and M commands already error out for such paths. Reported-by: Andrew Sayers <andrew-git@pileofstuff.org> Analysis-by: David Barr <davidbarr@google.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>	13 years ago
Thomas Rast	0dbe6592cc	t5704: fix nonportable sed/grep usages OS X's sed and grep would complain with (respectively) sed: 1: "/^-/{p;q}": extra characters at the end of q command grep: Regular expression too big For sed, use an explicit ; to terminate the q command. For grep, spell the "40 hex digits" explicitly in the regex, which should be safe as other tests already use this and we haven't got breakage reports on OS X about them. Signed-off-by: Thomas Rast <trast@inf.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Michael J Gruber	78ed1d2d63	t0300: work around bug in dash 0.5.6 The construct 'while IFS== read' makes dash 0.5.6 execute read without changing IFS, which results in test breakages all over the place in t0300. Neither dash 0.5.5.1 and older nor dash 0.5.7 and newer are affected: The problem was introduded resp. fixed by the commits 55c46b7 ([BUILTIN] Honor tab as IFS whitespace when splitting fields in readcmd, 2009-08-11) 1d806ac ([VAR] Do not poplocalvars prematurely on regular utilities, 2010-05-27) in http://git.kernel.org/?p=utils/dash/dash.git Putting 'IFS==' before that line makes all versions of dash work. This looks like a dash bug, not a misinterpretation of the standard. However, it's worth working around for two reasons. One, this version of dash was released in Fedora 14-16, so the bug is found in the wild. And two, at least one other shell, Solaris /bin/sh, choked on this by persisting IFS after the read invocation. That is not a shell we usually care about, and I think this use of IFS is acceptable by POSIX (which allows other behavior near "special builtins", but "read" is not one of those). But it seems that this may be a subtle, not-well-tested case for some shells. Given that the workaround is so simple, it's worth just being defensive. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Tom Grennan	fe6c64ab0b	t5512 (ls-remote): modernize style Prepare expected output inside test_expect_success that uses it. Also remove excess blank lines. Signed-off-by: Tom Grennan <tmgrennan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Stefano Lattarini	661bfd13b4	tests: fix spurious error when run directly with Solaris /usr/xpg4/bin/sh If any test script is run directly with Solaris 10 /usr/xpg4/bin/sh or /bin/ksh, it fails spuriously with a message like: t0000-basic.sh[31]: unset: bad argument count This happens because those shells bail out when encountering a call to "unset" with no arguments, and such unset call could take place in 'test-lib.sh'. Fix that issue, and add a proper comment to ensure we don't regress in this respect. Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Thomas Rast	efe4be1249	bundle: keep around names passed to add_pending_object() The 'name' field passed to add_pending_object() is used to later deduplicate in object_array_remove_duplicates(). git-bundle had a bug in this area since `18449ab` (git-bundle: avoid packing objects which are in the prerequisites, 2007-03-08): it passed the name of each boundary object in a static buffer. In other words, all that object_array_remove_duplicates() saw was the name of the last added boundary object. The recent switch to a strbuf in `bc2fed4` (bundle: use a strbuf to scan the log for boundary commits, 2012-02-22) made this slightly worse: we now free the buffer at the end, so it is not even guaranteed that it still points into addressable memory by the time object_array_remove_ duplicates looks at it. On the plus side however, it was now detectable by valgrind. The fix is easy: pass a copy of the string to add_pending_object. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Thomas Rast	aa9828561e	t5510: ensure we stay in the toplevel test dir The last test descended into a subdir without ever re-emerging, which is not so nice to the next test writer. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Thomas Rast	61821aaa12	t5510: refactor bundle->pack conversion It's not so much a conversion as a "strip everything up to and including the first blank line", but it will come in handy again. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Junio C Hamano	b3f01ff29f	diff -p: squelch "diff --git" header for stat-dirty paths The plumbing "diff" commands look at the working tree files without refreshing the index themselves for performance reasons (the calling script is expected to do that upfront just once, before calling one or more of them). In the early days of git, they showed the "diff --git" header before they actually ask the xdiff machinery to produce patches, and ended up showing only these headers if the real contents are the same and the difference they noticed was only because the stat info cached in the index did not match that of the working tree. It was too late for the implementation to take the header that it already emitted back. But `3e97c7c` (No diff -b/-w output for all-whitespace changes, 2009-11-19) introduced necessary logic to keep the meta-information headers in a strbuf and delay their output until the xdiff machinery noticed actual changes. This was primarily in order to generate patches that ignore whitespaces. When operating under "-w" mode, we wouldn't know if the header is needed until we actually look at the resulting patch, so it was a sensible thing to do, but we did not realize that the same reasoning applies to stat-dirty paths. Later, `296c6bb` (diff: fix "git show -C -C" output when renaming a binary file, 2010-05-26) generalized this machinery and added must_show_header toggle. This is turned on when the header must be shown even when there is no patch to be produced, e.g. only the mode was changed, or the path was renamed, without changing the contents. However, when it did so, it still kept the special case for the "-w" mode, which meant that the plumbing would keep showing these phantom changes. This corrects this historical inconsistency by allowing the plumbing to omit paths that are only stat-dirty from its output in the same way as it handles whitespace only changes under "-w" option. The change in the behaviour can be seen in the updated test. Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Junio C Hamano	5597e84b51	t4011: illustrate "diff-index -p" on stat-dirty paths The plumbing that looks at the working tree, i.e. "diff-index" and "diff-files", always emit the "diff --git a/path b/path" header lines without anything else for paths that are only stat-dirty (i.e. different only because the cached stat information in the index no longer matches that of the working tree, but the real contents are the same), when these commands are run with "-p" option to produce patches. Illustrate this current behaviour. Also demonstrate that with the "-w" option, we (correctly) hold off showing a "diff --git" header until actual differences have been found. This also suppresses the header for merely stat-dirty files, which is inconsistent. Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Junio C Hamano	13a4899886	t4011: modernise style Match the style to more modern test scripts, namely: - The first line of each test has prereq, title and opening sq for the script body. This makes the test shorter while reducing the need for backslashes. - Be prepared for the case in which the previous test may have failed. If a test wants to start from not having "frotz" that the previous test may have created, write "rm -f frotz", not "rm frotz". - Prepare the expected output inside your own test. - The order of comparison to check the result is "diff expected actual", so that the output will show how the output from the git you just broke is different from what is expected. - Write no SP between redirection '>' (or '<' for that matter) and the filename. Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Jakub Narebski	36612e4daf	gitweb: Handle invalid regexp in regexp search When using regexp search ('sr' parameter / $search_use_regexp variable is true), check first that regexp is valid. Without this patch we would get an error from Perl during search (if searching is performed by gitweb), or highlighting matches substring (if applicable), if user provided invalid regexp... which means broken HTML, with error page (including HTTP headers) generated after gitweb already produced some output. Add test that illustrates such error: for example for regexp "\.git" we would get the following error: Quantifier follows nothing in regex; marked by <-- HERE in m/ <-- HERE \.git/ at /var/www/cgi-bin/gitweb.cgi line 3084. Reported-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Carlos Martín Nieto	6c41e97557	branch: don't assume the merge filter ref exists print_ref_list looks up the merge_filter_ref and assumes that a valid pointer is returned. When the object doesn't exist, it tries to dereference a NULL pointer. This can be the case when git branch --merged is given an argument that isn't a valid commit name. Check whether the lookup returns a NULL pointer and die with an error if it does. Add a test, while we're at it. Signed-off-by: Carlos Martín Nieto <cmn@elego.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Junio C Hamano	a61ba26a47	test: "am -3" can accept non-standard -p<num> This adds a test for the previous one to make sure that "am -3 -p0" can read patches created with the --no-prefix option. Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Jim Meyering	f0c5793b37	am: don't infloop for an empty input file git-am.sh's check_patch_format function would attempt to preview the patch to guess its format, but would go into an infinite loop when the patch file happened to be empty. The solution: exit the loop when "read" fails, not when the line var, "$l1" becomes empty. Signed-off-by: Jim Meyering <meyering@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Pete Wyckoff	09ccbd34f4	git-p4: remove bash-ism in t9800 This works in both bash and dash: $ bash -c 'VAR=1 env' \| grep VAR VAR=1 $ dash -c 'VAR=1 env' \| grep VAR VAR=1 But environment variables assigned this way are not necessarily propagated through a function in POSIX compliant shells: $ bash -c 'f() { "$@" }; VAR=1 f "env"' \| grep VAR VAR=1 $ dash -c 'f() { "$@" }; VAR=1 f "env"' \| grep VAR Fix constructs like this, in particular, setting variables through test_must_fail. Based-on-patch-by: Vitor Antunes <vitor.hda@gmail.com> Signed-off-by: Pete Wyckoff <pw@padd.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Pete Wyckoff	8d93a5ac68	git-p4: remove bash-ism in t9809 Plain old $# works to count the number of arguments in either bash or dash, even if the arguments have spaces. Based-on-patch-by: Vitor Antunes <vitor.hda@gmail.com> Signed-off-by: Pete Wyckoff <pw@padd.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Pete Wyckoff	543987bd47	git-p4: fix submit regression with clientSpec and subdir clone When the --use-client-spec is given to clone, and the clone path is a subset of the full tree as specified in the client, future submits will go to the wrong place. Factor out getClientSpec() so both clone/sync and submit can use it. Introduce getClientRoot() that is needed for the client spec case, and use it instead of p4Where(). Test the five possible submit behaviors (add, modify, rename, copy, delete). Reported-by: Laurent Charrière <lcharriere@promptu.com> Signed-off-by: Pete Wyckoff <pw@padd.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Pete Wyckoff	a93d33ee7b	git-p4: set useClientSpec variable on initial clone If --use-client-spec was given, set the matching configuration variable. This is necessary to ensure that future submits work properly. The alternatives of requiring the user to set it, or providing a command-line option on every submit, are error prone. Signed-off-by: Pete Wyckoff <pw@padd.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Jeff King	4f22b1015d	do not stream large files to pack when filters are in use Because git's object format requires us to specify the number of bytes in the object in its header, we must know the size before streaming a blob into the object database. This is not a problem when adding a regular file, as we can get the size from stat(). However, when filters are in use (such as autocrlf, or the ident, filter, or eol gitattributes), we have no idea what the ultimate size will be. The current code just punts on the whole issue and ignores filter configuration entirely for files larger than core.bigfilethreshold. This can generate confusing results if you use filters for large binary files, as the filter will suddenly stop working as the file goes over a certain size. Rather than try to handle unknown input sizes with streaming, this patch just turns off the streaming optimization when filters are in use. This has a slight performance regression in a very specific case: if you have autocrlf on, but no gitattributes, a large binary file will avoid the streaming code path because we don't know beforehand whether it will need conversion or not. But if you are handling large binary files, you should be marking them as such via attributes (or at least not using autocrlf, and instead marking your text files as such). And the flip side is that if you have a large _non_-binary file, there is a correctness improvement; before we did not apply the conversion at all. The first half of the new t1051 script covers these failures on input. The second half tests the matching output code paths. These already work correctly, and do not need any adjustment. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Thomas Rast	8a557bb77f	t5704: match tests to modern style The test did not adhere to the current style on several counts: . empty lines around the test blocks, but within the test string . ': > file' or even just '> file' with an extra space . inconsistent indentation . hand-rolled commits instead of using test_commit Fix all of them. There's a catch to the last point: test_commit creates a tag, which the original test did not create. We still change it to test_commit, and explicitly delete the tags, so as to highlight that the test relies on not having them. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Thomas Rast	bc2fed496b	bundle: use a strbuf to scan the log for boundary commits The first part of the bundle header contains the boundary commits, and could be approximated by # v2 git bundle $(git rev-list --pretty=oneline --boundary <ARGS> \| grep ^-) git-bundle actually spawns exactly this rev-list invocation, and does the grepping internally. There was a subtle bug in the latter step: it used fgets() with a 1024-byte buffer. If the user has sufficiently long subjects (e.g., by not adhering to the git oneline-subject convention in the first place), the 'oneline' format can easily overflow the buffer. fgets() then returns the rest of the line in the next call(s). If one of these remaining parts started with '-', git-bundle would mistakenly insert it into the bundle thinking it was a boundary commit. Fix it by using strbuf_getwholeline() instead, which handles arbitrary line lengths correctly. Note that on the receiving side in parse_bundle_header() we were already using strbuf_getwholeline_fd(), so that part is safe. Reported-by: Jannis Pohlmann <jannis.pohlmann@codethink.co.uk> Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Jakub Narebski	fc8fcd27e6	gitweb: Fix 'grep' search for multiple matches in file Commit `ff7f218` (gitweb: Fix file links in "grep" search, 2012-01-05), added $file_href variable, to reduce duplication and have the fix applied in single place. Unfortunately it made variable defined inside the loop, not taking into account the fact that $file_href was set only if file changed. Therefore for files with multiple matches $file_href was undefined for second and subsequent matches. Fix this bug by moving $file_href declaration outside loop. Adds tests for almost all forms of sarch in gitweb, which were missing from testuite. Note that it only tests if there are no warnings, and it doesn't check that gitweb finds what it should find. Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Junio C Hamano	3d1f148c33	refresh_index: do not show unmerged path that is outside pathspec When running "git add --refresh <pathspec>", we incorrectly showed the path that is unmerged even if it is outside the specified pathspec, even though we did honor pathspec and refreshed only the paths that matched. Note that this cange does not affect "git update-index --refresh"; for hysterical raisins, it does not take a pathspec (it takes real paths) and more importantly itss command line options are parsed and executed one by one as they are encountered, so "git update-index --refresh foo" means "first refresh the index, and then update the entry 'foo' by hashing the contents in file 'foo'", not "refresh only entry 'foo'". Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Jakub Narebski	fd49e56af6	gitweb: Fix "heads" view when there is no current branch In a repository whose HEAD points to an unborn branch with no commits, "heads" view and "summary" view (which shows what is shown in "heads" view) compared the object names of commits at the tip of branches with the output from "git rev-parse HEAD", which caused comparison of a string with undef and resulted in a warning in the server log. This can happen if non-bare repository (with default 'master' branch) is updated not via committing but by other means like push to it, or Gerrit. It can happen also just after running "git checkout --orphan <new branch>" but before creating any new commit on this branch. Rewrite the comparison so that it also works when $head points at nothing; in such a case, no branch can be "the current branch", add a test for it. While at it, rename local variable $head to $head_at, as it points to current commit rather than current branch name (HEAD contents). The code still incorrectly shows all branches that point at the same commit as what HEAD points as "the current branch", even when HEAD is detached. Fixing this bug is outside the scope of this patch. Reported-by: Rajesh Boyapati Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Clemens Buchacher	ef7e93d908	do not override receive-pack errors Receive runs rev-list --verify-objects in order to detect missing objects. However, such errors are ignored and overridden later. Instead, consequently ignore all update commands for which an error has already been detected. Some tests in t5504 are obsoleted by this change, because invalid objects are detected even if fsck is not enabled. Instead, they now test for different error messages depending on whether or not fsck is turned on. A better fix would be to force a corruption that will be detected by fsck but not by rev-list. Signed-off-by: Clemens Buchacher <drizzd@aon.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Clemens Buchacher	d202a513a4	t5541: check error message against the real port number used Otherwise the test cannot be run with custom port set to LIB_HTTPD_PORT. Signed-off-by: Clemens Buchacher <drizzd@aon.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Clemens Buchacher	01fdc21f6e	push/fetch/clone --no-progress suppresses progress output By default, progress output is disabled if stderr is not a terminal. The --progress option can be used to force progress output anyways. Conversely, --no-progress does not force progress output. In particular, if stderr is a terminal, progress output is enabled. This is unintuitive. Change --no-progress to force output off. Signed-off-by: Clemens Buchacher <drizzd@aon.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Clemens Buchacher	cb8da70547	git rev-list: fix invalid typecast git rev-list passes rev_list_info, not rev_list objects. Without this fix, rev-list enables or disables the --verify-objects option depending on a read from an undefined memory location. Signed-off-by: Clemens Buchacher <drizzd@aon.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Ævar Arnfjörð Bjarmason	1f5ad6b1a7	t: use sane_unset instead of unset Change several tests to use the sane_unset function introduced in v1.7.3.1-35-g00648ba instead of the built-in unset function. This fixes a failure I was having on t9130-git-svn-authors-file.sh on Solaris, and prevents several other issues from occurring. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Ævar Arnfjörð Bjarmason	d24fbca7a5	Remove Git's support for smoke testing I'm no longer running the Git smoke testing service at smoke.git.nix.is due to Smolder being a fragile piece of software not having time to follow through on making it easy for third parties to run and submit their own smoke tests. So remove the support in Git for sending smoke tests to smoke.git.nix.is, it's still easy to modify the test suite to submit smokes somewhere else. This reverts the following commits: Revert "t/README: Add SMOKE_{COMMENT,TAGS}= to smoke_report target" -- `e38efac87d` Revert "t/README: Document the Smoke testing" -- `d15e9ebc5c` Revert "t/Makefile: Create test-results dir for smoke target" -- `617344d77b` Revert "tests: Infrastructure for Git smoke testing" -- `b6b84d1b74` Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Junio C Hamano	3adab6f3a7	merge: do not launch an editor on "--no-edit $tag" When the user explicitly asked us not to, don't launch an editor. But do everything else the same way as the "edit" case, i.e. leave the comment with verification result in the log template and record the mergesig in the resulting merge commit for later inspection. Based on initiail analysis by Jonathan Nieder. Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Junio C Hamano	31fd8d72f2	tag: do not show non-tag contents with "-n" "git tag -n" did not check the type of the object it is reading the top n lines from. At least, avoid showing the beginning of trees and blobs when dealing with lightweight tags that point at them. As the payload of a tag and a commit look similar in that they both start with a header block, which is skipped for the purpose of "-n" output, followed by human readable text, allow the message of commit objects to be shown just like the contents of tag objects. This avoids regression for people who have been using "tag -n" to show the log messages of commits that are pointed at by lightweight tags. Test script is from Jeff King. Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Junio C Hamano	3f6d56de5f	commit: ignore intent-to-add entries instead of refusing Originally, "git add -N" was introduced to help users from forgetting to add new files to the index before they ran "git commit -a". As an attempt to help them further so that they do not forget to say "-a", "git commit" to commit the index as-is was taught to error out, reminding the user that they may have forgotten to add the final contents of the paths before running the command. This turned out to be a false "safety" that is useless. If the user made changes to already tracked paths and paths added with "git add -N", and then ran "git add" to register the final contents of the paths added with "git add -N", "git commit" will happily create a commit out of the index, without including the local changes made to the already tracked paths. It was not a useful "safety" measure to prevent "forgetful" mistakes from happening. It turns out that this behaviour is not just a useless false "safety", but actively hurts use cases of "git add -N" that were discovered later and have become popular, namely, to tell Git to be aware of these paths added by "git add -N", so that commands like "git status" and "git diff" would include them in their output, even though the user is not interested in including them in the next commit they are going to make. Fix this ancient UI mistake, and instead make a commit from the index ignoring the paths added by "git add -N" without adding real contents. Based on the work by Nguyễn Thái Ngọc Duy, and helped by injection of sanity from Jonathan Nieder and others on the Git mailing list. Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Junio C Hamano	abe199808c	git checkout -b: allow switching out of an unborn branch Running "git checkout -b another" immediately after "git init" when you do not even have a commit on 'master' fails with: $ git checkout -b another fatal: You are on a branch yet to be born This is unnecessary, if we redefine "git checkout -b $name" that does not take any $start_point (which has to be a commit) as "I want to check out a new branch $name from the state I am in". Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Junio C Hamano	c2d17ba3db	branch --edit-description: protect against mistyped branch name It is very easy to mistype the branch name when editing its description, e.g. $ git checkout -b my-topic master : work work work : now we are at a good point to switch working something else $ git checkout master : ah, let's write it down before we forget what we were doing $ git branch --edit-description my-tpoic The command does not notice that branch 'my-tpoic' does not exist. It is not lost (it becomes description of an unborn my-tpoic branch), but is not very useful. So detect such a case and error out to reduce the grief factor from this common mistake. This incidentally also errors out --edit-description when the HEAD points at an unborn branch (immediately after "init", or "checkout --orphan"), because at that point, you do not even have any commit that is part of your history and there is no point in describing how this particular branch is different from the branch it forked off of, which is the useful bit of information the branch description is designed to capture. We may want to special case the unborn case later, but that is outside the scope of this patch to prevent more common mistakes before 1.7.9 series gains too much widespread use. Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Junio C Hamano	b5c9f1c1b0	merge: do not create a signed tag merge under --ff-only option Starting at release v1.7.9, if you ask to merge a signed tag, "git merge" always creates a merge commit, even when the tag points at a commit that happens to be a descendant of your current commit. Unfortunately, this interacts rather badly for people who use --ff-only to make sure that their branch is free of local developments. It used to be possible to say: $ git checkout -b frotz v1.7.9~30 $ git merge --ff-only v1.7.9 and expect that the resulting tip of frotz branch matches v1.7.9^0 (aka the commit tagged as v1.7.9), but this fails with the updated Git with: fatal: Not possible to fast-forward, aborting. because a merge that merges v1.7.9 tag to v1.7.9~30 cannot be created by fast forwarding. We could teach users that now they have to do $ git merge --ff-only v1.7.9^0 but it is far more pleasant for users if we DWIMmed this ourselves. When an integrator pulls in a topic from a lieutenant via a signed tag, even when the work done by the lieutenant happens to fast-forward, the integrator wants to have a merge record, so the integrator will not be asking for --ff-only when running "git pull" in such a case. Therefore, this change should not regress the support for the use case v1.7.9 wanted to add. Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Nguyễn Thái Ngọc Duy	7f814632f5	Use correct grammar in diffstat summary line "git diff --stat" and "git apply --stat" now learn to print the line "%d files changed, %d insertions(+), %d deletions(-)" in singular form whenever applicable. "0 insertions" and "0 deletions" are also omitted unless they are both zero. This matches how versions of "diffstat" that are not prehistoric produced their output, and also makes this line translatable. [jc: with help from Thomas Dickey in archaeology of "diffstat"] [jc: squashed Jonathan's updates to illustrations in tutorials and a test] Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Junio C Hamano	2c733fb24c	parse_date(): '@' prefix forces git-timestamp The only place that the issue this series addresses was observed where we read "cat-file commit" output and put it in GIT_AUTHOR_DATE in order to replay a commit with an ancient timestamp. With the previous patch alone, "git commit --date='20100917 +0900'" can be misinterpreted to mean an ancient timestamp, not September in year 2010. Guard this codepath by requring an extra '@' in front of the raw git timestamp on the parsing side. This of course needs to be compensated by updating get_author_ident_from_commit and the code for "git commit --amend" to prepend '@' to the string read from the existing commit in the GIT_AUTHOR_DATE environment variable. Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Junio C Hamano	840c519d7e	tests: add write_script helper function Many of the scripts in the test suite write small helper shell scripts to disk. It's best if these shell scripts start with "#!$SHELL_PATH" rather than "#!/bin/sh", because /bin/sh on some platforms is too buggy to be used. However, it can be cumbersome to expand $SHELL_PATH, because the usual recipe for writing a script is: cat >foo.sh <<-\EOF #!/bin/sh echo my arguments are "$@" EOF To expand $SHELL_PATH, you have to either interpolate the here-doc (which would require quoting "\$@"), or split the creation into two commands (interpolating the $SHELL_PATH line, but not the rest of the script). Let's provide a helper function that makes that less syntactically painful. While we're at it, this helper can also take care of the "chmod +x" that typically comes after the creation of such a script, saving the caller a line. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Jeff King	b3256eb8b3	standardize and improve lookup rules for external local repos When you specify a local repository on the command line of clone, ls-remote, upload-pack, receive-pack, or upload-archive, or in a request to git-daemon, we perform a little bit of lookup magic, doing things like looking in working trees for .git directories and appending ".git" for bare repos. For clone, this magic happens in get_repo_path. For everything else, it happens in enter_repo. In both cases, there are some ambiguous or confusing cases that aren't handled well, and there is one case that is not handled the same by both methods. This patch tries to provide (and test!) standard, sensible lookup rules for both code paths. The intended changes are: 1. When looking up "foo", we have always preferred a working tree "foo" (containing "foo/.git" over the bare "foo.git". But we did not prefer a bare "foo" over "foo.git". With this patch, we do so. 2. We would select directories that existed but didn't actually look like git repositories. With this patch, we make sure a selected directory looks like a git repo. Not only is this more sensible in general, but it will help anybody who is negatively affected by change (1) negatively (e.g., if they had "foo.git" next to its separate work tree "foo", and expect to keep finding "foo.git" when they reference "foo"). 3. The enter_repo code path would, given "foo", look for "foo.git/.git" (i.e., do the ".git" append magic even for a repo with working tree). The clone code path did not; with this patch, they now behave the same. In the unlikely case of a working tree overlaying a bare repo (i.e., a ".git" directory _inside_ a bare repo), we continue to treat it as a working tree (prefering the "inner" .git over the bare repo). This is mainly because the combination seems nonsensical, and I'd rather stick with existing behavior on the off chance that somebody is relying on it. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Jeff King	41b59bfcb1	grep: respect diff attributes for binary-ness There is currently no way for users to tell git-grep that a particular path is or is not a binary file; instead, grep always relies on its auto-detection (or the user specifying "-a" to treat all binary-looking files like text). This patch teaches git-grep to use the same attribute lookup that is used by git-diff. We could add a new "grep" flag, but that is unnecessarily complex and unlikely to be useful. Despite the name, the "-diff" attribute (or "diff=foo" and the associated diff.foo.binary config option) are really about describing the contents of the path. It's simply historical that diff was the only thing that cared about these attributes in the past. And if this simple approach turns out to be insufficient, we still have a backwards-compatible path forward: we can add a separate "grep" attribute, and fall back to respecting "diff" if it is unset. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Junio C Hamano	2ad9ba0382	request-pull: explicitly ask tags/$name to be pulled When asking for a tag to be pulled, disambiguate by leaving tags/ prefix in front of the name of the tag. E.g. ... in the git repository at: git://example.com/git/git.git/ tags/v1.2.3 for you to fetch changes up to 123456... This way, older versions of "git pull" can be used to respond to such a request more easily, as "git pull $URL v1.2.3" did not DWIM to fetch v1.2.3 tag in older versions. Also this makes it clearer for humans that the pull request is made for a tag and he should anticipate a signed one. Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Jens Lehmann	1017c1abcb	submodule add: fix breakage when re-adding a deep submodule Since recently a submodule with name <name> has its git directory in the .git/modules/<name> directory of the superproject while the work tree contains a gitfile pointing there. When the same submodule is added on a branch where it wasn't present so far (it is not found in the .gitmodules file), the name is not initialized from the path as it should. This leads to a wrong path entered in the gitfile when the .git/modules/<name> directory is found, as this happily uses the - now empty - name. It then always points only a single directory up, even if we have a path deeper in the directory hierarchy. Fix that by initializing the name of the submodule early in module_clone() if module_name() returned an empty name and add a test to catch that bug. Reported-by: Jehan Bing <jehan@orb.com> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
David Aguilar	ec245ba049	mergetool: Provide an empty file when needed Some merge tools cannot cope when $LOCAL, $BASE, or $REMOTE are missing. $BASE can be missing when two branches independently add the same filename. Provide an empty file to make these tools happy. When a delete/modify conflict occurs, $LOCAL and $REMOTE can also be missing. We have special case code to handle such case so this change may not affect that codepath, but try to be consistent and create an empty file for them anyway. Reported-by: Jason Wenger <jcwenger@gmail.com> Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Albert Yale	50dd0f2fd9	grep: fix -l/-L interaction with decoration lines In threaded mode, git-grep emits file breaks (enabled with context, -W and --break) into the accumulation buffers even if they are not required. The output collection thread then uses skip_first_line to skip the first such line in the output, which would otherwise be at the very top. This is wrong when the user also specified -l/-L/-c, in which case every line is relevant. While arguably giving these options together doesn't make any sense, git-grep has always quietly accepted it. So do not skip anything in these cases. Signed-off-by: Albert Yale <surfingalbert@gmail.com> Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Kirill Smelkov	aae5239be2	t/Makefile: Use $(sort ...) explicitly where needed Starting from GNU Make 3.82 $(wildcard ...) no longer sorts the result (from NEWS): * WARNING: Backward-incompatibility! Wildcards were not documented as returning sorted values, but the results have been sorted up until this release.. If your makefiles require sorted results from wildcard expansions, use the $(sort ...) function to request it explicitly. `2a59dc32aa` I usually watch test progress visually, and if tests are sorted, even with make -j4 they go more or less incrementally by their t number. On the other side, without sorting, tests are executed in seemingly random order even for -j1. Let's please maintain sane tests order for perceived prettyness. Another note is that in GNU Make sort also works as uniq, so after sort being removed, we might expect e.g. $(wildcard .sh a.) to produce duplicates for e.g. "a.sh". From this point of view, adding sort could be seen as hardening t/Makefile from accidentally introduced dups. It turned out that prevous releases of GNU Make did not perform full sort in $(wildcard), only sorting results for each pattern, that's why explicit sort-as-uniq is relevant even for older makes. Signed-off-by: Kirill Smelkov <kirr@navytux.spb.ru> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Shawn O. Pearce	5238cbf656	remote-curl: Fix push status report when all branches fail The protocol between transport-helper.c and remote-curl requires remote-curl to always print a blank line after the push command has run. If the blank line is ommitted, transport-helper kills its container process (the git push the user started) with exit(128) and no message indicating a problem, assuming the helper already printed reasonable error text to the console. However if the remote rejects all branches with "ng" commands in the report-status reply, send-pack terminates with non-zero status, and in turn remote-curl exited with non-zero status before outputting the blank line after the helper status printed by send-pack. No error messages reach the user. This caused users to see the following from git push over HTTP when the remote side's update hook rejected the branch: $ git push http://... master Counting objects: 4, done. Delta compression using up to 6 threads. Compressing objects: 100% (2/2), done. Writing objects: 100% (3/3), 301 bytes, done. Total 3 (delta 0), reused 0 (delta 0) $ Always print a blank line after the send-pack process terminates, ensuring the helper status report (if it was output) will be correctly parsed by the calling transport-helper.c. This ensures the helper doesn't abort before the status report can be shown to the user. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Junio C Hamano	36ed1913e1	Making pathspec limited log play nicer with --first-parent In a topic branch workflow, you often want to find the latest commit that merged a side branch that touched a particular area of the system, so that a new topic branch to work on that area can be forked from that commit. For example, I wanted to find an appropriate fork-point to queue Luke's changes related to git-p4 in contrib/fast-import/. "git log --first-parent" traverses the first-parent chain, and "-m --stat" shows the list of paths touched by commits including merge commits. We could ask the question this way: # What is the latest commit that touched that path? $ git log --first-parent --oneline -m --stat master \| sed -e '/^ contrib\/fast-import\/git-p4 /q' \| tail The above finds that `8cbfc11` (Merge branch 'pw/p4-view-updates', 2012-01-06) was such a commit. But a more natural way to spell this question is this: $ git log --first-parent --oneline -m --stat -1 master -- \ contrib/fast-import/git-p4 Unfortunately, this does not work. It finds `ecb7cf9` (git-p4: rewrite view handling, 2012-01-02). This commit is a part of the merged topic branch and is _not_ on the first-parent path from the 'master': $ git show-branch `8cbfc11` `ecb7cf9` ! [`8cbfc11`] Merge branch 'pw/p4-view-updates' ! [`ecb7cf9`] git-p4: rewrite view handling -- - [`8cbfc11`] Merge branch 'pw/p4-view-updates' + [8cbfc11^2] git-p4: view spec documentation ++ [`ecb7cf9`] git-p4: rewrite view handling The problem is caused by the merge simplification logic when it inspects the merge commit `8cbfc11`. In this case, the history leading to the tip of 'master' did not touch git-p4 since 'pw/p4-view-updates' topic forked, and the result of the merge is simply a copy from the tip of the topic branch in the view limited by the given pathspec. The merge simplification logic discards the history on the mainline side of the merge, and pretends as if the sole parent of the merge is its second parent, i.e. the tip of the topic. While this simplification is correct in the general case, it is at least surprising if not outright wrong when the user explicitly asked to show the first-parent history. Here is an attempt to fix this issue, by not allowing us to compare the merge result with anything but the first parent when --first-parent is in effect, to avoid the history traversal veering off to the side branch. Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago

1 2 3 4 5 ...

6040 Commits (a9c7a8a8bef30bbbf87e0d4c0e64d50c676f70ed)