summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2014-12-05First batch for 2.3 cycleJunio C Hamano
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-05Merge branch 'mh/config-flip-xbit-back-after-checking'Junio C Hamano
* mh/config-flip-xbit-back-after-checking: create_default_files(): don't set u+x bit on $GIT_DIR/config
2014-12-05Merge branch 'jk/gitweb-with-newer-cgi-multi-param'Junio C Hamano
* jk/gitweb-with-newer-cgi-multi-param: gitweb: hack around CGI's list-context param() handling
2014-12-05Merge branch 'rs/receive-pack-use-labs'Junio C Hamano
* rs/receive-pack-use-labs: use labs() for variables of type long instead of abs()
2014-12-05Merge branch 'rs/maint-config-use-labs'Junio C Hamano
* rs/maint-config-use-labs: use labs() for variables of type long instead of abs()
2014-12-05Merge branch 'js/windows-open-eisdir-error'Junio C Hamano
* js/windows-open-eisdir-error: Windows: correct detection of EISDIR in mingw_open()
2014-12-05Merge branch 'jh/empty-notes'Junio C Hamano
A request to store an empty note via "git notes" meant to remove note from the object but with --allow-empty we will store a (surprise!) note that is empty. In the longer run, we might want to deprecate the somewhat unintuitive "emptying means deletion" behaviour. * jh/empty-notes: t3301: modernize style notes: empty notes should be shown by 'git log' builtin/notes: add --allow-empty, to allow storing empty notes builtin/notes: split create_note() to clarify add vs. remove logic builtin/notes: simplify early exit code in add() builtin/notes: refactor note file path into struct note_data builtin/notes: improve naming t3301: verify that 'git notes' removes empty notes by default builtin/notes: fix premature failure when trying to add the empty blob
2014-12-05Merge branch 'sv/get-builtin'Junio C Hamano
* sv/get-builtin: builtin: move builtin retrieval to get_builtin()
2014-12-05Merge branch 'jk/checkout-from-tree'Junio C Hamano
"git checkout $treeish $path", when $path in the index and the working tree already matched what is in $treeish at the $path, still overwrote the $path unnecessarily. * jk/checkout-from-tree: checkout $tree: do not throw away unchanged index entries
2014-12-05Merge branch 'tq/git-ssh-command'Junio C Hamano
Allow passing extra set of arguments when ssh is invoked to create an encrypted & authenticated connection by introducing a new environment variable GIT_SSH_COMMAND, whose contents is interpreted by shells. This is not possible with existing GIT_SSH mechanism whose invocation bypasses shells, which was designed more to match what other programs with similar variables did, not necessarily to be more useful. * tq/git-ssh-command: git_connect: set ssh shell command in GIT_SSH_COMMAND
2014-12-05Merge branch 'rs/env-array-in-child-process'Junio C Hamano
* rs/env-array-in-child-process: use args member of struct child_process
2014-12-05Merge branch 'maint' of git://github.com/git-l10n/git-po into maintJunio C Hamano
* 'maint' of git://github.com/git-l10n/git-po: l10n: de.po: fix typos
2014-12-05Start post 2.2 cycleJunio C Hamano
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-01for-each-ref: correct spelling of Tcl in option descriptionRalf Thielow
Tcl is conventionally spelled "Tcl". The description of option "--tcl", however, spells it "tcl". Let's follow the convention. Reported-by: Hartmut Henkel <hartmut_henkel@gmx.de> Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-01t0050-*.sh: mark the rename (case change) test as passingRamsay Jones
Since commit baa37bff ("mv: allow renaming to fix case on case insensitive filesystems", 08-05-2014), the 'git mv' command has been able to rename a file, to one which differs only in case, on a case insensitive filesystem. This results in the 'rename (case change)' test, which used to fail prior to this commit, to now (unexpectedly) pass. Mark this test as passing. [jc: Ramsay's tests on Cygwin, Eric's on Mac OS X] Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Tested-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-01push: truly use "simple" as default, not "upstream"Jeff King
The plan for the push.default transition had all along been to use the "simple" method rather than "upstream" as a default if the user did not specify their own push.default value. Commit 11037ee (push: switch default from "matching" to "simple", 2013-01-04) tried to implement that by moving PUSH_DEFAULT_UNSPECIFIED in our switch statement to fall-through to the PUSH_DEFAULT_SIMPLE case. When the commit that became 11037ee was originally written, that would have been enough. We would fall through to calling setup_push_upstream() with the "simple" parameter set to 1. However, it was delayed for a while until we were ready to make the transition in Git 2.0. And in the meantime, commit ed2b182 (push: change `simple` to accommodate triangular workflows, 2013-06-19) threw a monkey wrench into the works. That commit drops the "simple" parameter to setup_push_upstream, and instead checks whether the global "push_default" is PUSH_DEFAULT_SIMPLE. This is right when the user has explicitly configured push.default to simple, but wrong when we are a fall-through for the "unspecified" case. We never noticed because our push.default tests do not cover the case of the variable being totally unset; they only check the "simple" behavior itself. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-01pack-bitmap: do not use gcc packed attributeKarsten Blees
The "__attribute__" flag may be a noop on some compilers. That's OK as long as the code is correct without the attribute, but in this case it is not. We would typically end up with a struct that is 2 bytes too long due to struct padding, breaking both reading and writing of bitmaps. Instead of marshalling the data in a struct, let's just provide helpers for reading and writing the appropriate types. Besides being correct on all platforms, the result is more efficient and simpler to read. Signed-off-by: Karsten Blees <blees@dcon.de> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-01t5516: more tests for receive.denyCurrentBranch=updateInsteadJunio C Hamano
The previous one tests only the case where a path to be updated by the push-to-deploy has an incompatible change in the target's working tree that has already been added to the index, but the feature itself wants to require the working tree to be a lot cleaner than what is tested. Add a handful more tests to protect the feature from future changes that mistakenly (from the viewpoint of the inventor of the feature) loosens the cleanliness requirement, namely: - A change only to the working tree but not to the index is still a change to be protected; - An untracked file in the working tree that would be overwritten by a push-to-deploy needs to be protected; - A change that happens to make a file identical to what is being pushed is still a change to be protected (i.e. the feature's cleanliness requirement is more strict than that of checkout). Also, test that a stat-only change to the working tree is not a reason to reject a push-to-deploy. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-01receive-pack: add another option for receive.denyCurrentBranchJohannes Schindelin
When synchronizing between working directories, it can be handy to update the current branch via 'push' rather than 'pull', e.g. when pushing a fix from inside a VM, or when pushing a fix made on a user's machine (where the developer is not at liberty to install an ssh daemon let alone know the user's password). The common workaround – pushing into a temporary branch and then merging on the other machine – is no longer necessary with this patch. The new option is: 'updateInstead': Update the working tree accordingly, but refuse to do so if there are any uncommitted changes. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-01system_path(): always return free'able memory to the callerJunio C Hamano
The function sometimes returns a newly allocated string and sometimes returns a borrowed string, the latter of which the callers must not free(). The existing callers all assume that the return value belongs to the callee and most of them copy it with strdup() when they want to keep it around. They end up leaking the returned copy when the callee returned a new string because they cannot tell if they should free it. Change the contract between the callers and system_path() to make the returned string owned by the callers; they are responsible for freeing it when done, but they do not have to make their own copy to store it away. Adjust the callers to make sure they do not leak the returned string once they are done, but do not bother freeing it just before dying, exiting or exec'ing other program to avoid unnecessary churn. Reported-by: Alexander Kuleshov <kuleshovmail@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-29Merge branch 'master' of https://github.com/ralfth/git-po-deJiang Xin
* 'master' of https://github.com/ralfth/git-po-de: l10n: de.po: fix typos
2014-11-28l10n: de.po: fix typosHartmut Henkel
Signed-off-by: Hartmut Henkel <hartmut_henkel@gmx.de> Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
2014-11-26Git 2.2v2.2.0Junio C Hamano
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-26RelNotes: spelling & grammar tweaksMarc Branchaud
Signed-off-by: Marc Branchaud <marcnarc@xiplink.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-26sha1_name: avoid unnecessary sha1 lookup in find_unique_abbrevMike Hommey
An example where this happens is when doing an ls-tree on a tree that contains a commit link. In that case, find_unique_abbrev is called to get a non-abbreviated hex sha1, but still, a lookup is done as to whether the sha1 is in the repository (which ends up looking for a loose object in .git/objects), while the result of that lookup is not used when returning a non-abbreviated hex sha1. Signed-off-by: Mike Hommey <mh@glandium.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-25git-am: add --message-id/--no-message-idPaolo Bonzini
Parse the option and pass it directly to git-mailinfo. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-25git-mailinfo: add --message-idPaolo Bonzini
This option adds the content of the Message-Id header at the end of the commit message prepared by git-mailinfo. This is useful in order to associate commit messages automatically with mailing list discussions. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-25git-send-email: add --transfer-encoding optionPaolo Bonzini
The thread at http://thread.gmane.org/gmane.comp.version-control.git/257392 details problems when applying patches with "git am" in a repository with CRLF line endings. In the example in the thread, the repository originated from "git-svn" so it is not possible to use core.eol and friends on it. Right now, the best option is to use "git am --keep-cr". However, when a patch create new files, the patch application process will reject the new file because it finds a "/dev/null\r" string instead of "/dev/null". The problem is that SMTP transport is CRLF-unsafe. Sending a patch by email is the same as passing it through "dos2unix | unix2dos". The newly introduced CRLFs are normally transparent because git-am strips them. The keepcr=true setting preserves them, but it is mostly working by chance and it would be very problematic to have a "git am" workflow in a repository with mixed LF and CRLF line endings. The MIME solution to this is the quoted-printable transfer enconding. This is not something that we want to enable by default, since it makes received emails horrible to look at. However, it is a very good match for projects that store CRLF line endings in the repository. The only disadvantage of quoted-printable is that quoted-printable patches fail to apply if the maintainer uses "git am --keep-cr". This is because the decoded patch will have two carriage returns at the end of the line. Therefore, add support for base64 transfer encoding too, which makes received emails downright impossible to look at outside a MUA, but really just works. The patch covers all bases, including users that still live in the late 80s, by also providing a 7bit content transfer encoding that refuses to send emails with non-ASCII character in them. And finally, "8bit" will add a Content-Transfer-Encoding header but otherwise do nothing. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-25git-send-email: delay creation of MIME headersPaolo Bonzini
After the next patch, git-send-email will sometimes modify existing Content-Transfer-Encoding headers. Delay the addition of the header to @xh until just before sending. Do the same for MIME-Version, to avoid adding it twice. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-25sort_string_list(): rename to string_list_sort()Michael Haggerty
The new name is more consistent with the names of other string_list-related functions. Suggested-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-25prune_remote(): iterate using for_each_string_list_item()Michael Haggerty
Iterate over refs_to_prune using for_each_string_list_item() rather than writing out the loop in longhand. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-25prune_remote(): rename local variableMichael Haggerty
Rename "delete_refs_list" to "refs_to_prune". The new name is more self-explanatory. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-25repack_without_refs(): make the refnames argument a string_listMichael Haggerty
Most of the callers have string_lists available already, whereas two of them had to read data out of a string_list into an array of strings just to call this function. So change repack_without_refs() to take the list of refnames to omit as a string_list, and change the callers accordingly. Suggested-by: Ronnie Sahlberg <sahlberg@google.com> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-25prune_remote(): sort delete_refs_list references en masseMichael Haggerty
Inserting items into a list in sorted order is O(N^2) whereas appending them unsorted and then sorting the list all at once is O(N lg N). string_list_insert() also removes duplicates, and this change loses that functionality. But the strings in this list, which ultimately come from a for_each_ref() iteration, cannot contain duplicates. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-25prune_remote(): initialize both delete_refs lists in a single loopMichael Haggerty
Also free them together at the end of the function. In a moment, the array version will become redundant. Managing them together makes later steps more obvious. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-25prune_remote(): exit early if there are no stale referencesMichael Haggerty
Aside from making the logic clearer, this avoids a call to warn_dangling_symrefs(), which always does a for_each_rawref() iteration. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-25git-sh-setup.sh: use dashdash with basename callDan Wyand
Calling basename on a argument that starts with a dash, like a login shell, will result in an error. Add '--' before the argument so that the argument is interpreted properly. Signed-off-by: Dan Wyand <danwyand@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-25git-compat-util.h: don't define _XOPEN_SOURCE on cygwinRamsay Jones
A recent update to the gcc compiler (v4.8.3-5 x86_64) on 64-bit cygwin leads to several new warnings about the implicit declaration of the memmem(), strlcpy() and strcasestr() functions. For example: CC archive.o archive.c: In function 'format_subst': archive.c:44:3: warning: implicit declaration of function 'memmem' \ [-Wimplicit-function-declaration] b = memmem(src, len, "$Format:", 8); ^ archive.c:44:5: warning: assignment makes pointer from integer \ without a cast [enabled by default] b = memmem(src, len, "$Format:", 8); ^ This is because <string.h> on Cygwin used to always declare the above functions, but a recent version of it no longer make them visible when _XOPEN_SOURCE is set (even if _GNU_SOURCE and _BSD_SOURCE is set). In order to suppress the warnings, don't define the _XOPEN_SOURCE macro on cygwin. Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-24t5000 on Windows: do not mistake "sh.exe" as "sh"Johannes Sixt
In their effort to emulate POSIX as close as possible, the MSYS tools and Cygwin treat the file name "foo.exe" as "foo" when the latter is asked for, but not present, but the former is present. Following this rule, 'cp /bin/sh a/bin' actually copies the file /bin/sh.exe, so that we now have a/bin/sh.exe in the repository. This difference did not matter in the tests in the past because we were only interested in the equality of contents generated in various ways. But recently added tests check file names, in particular, the presence of "a/bin/sh". This test fails on Windows, as we do not have a file by this name, but "a/bin/sh.exe". Use test-genrandom to generate the large binary file in the repository under the expected name. We could change the guilty line to 'cat /bin/sh >a/bin/sh', but it is better for test reproducibility to ensure that the test data is the same across platforms, which test-genrandom can guarantee. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-24t/README: justify why "! grep foo" is sufficientJunio C Hamano
We require use of test_must_fail to check expected non-zero exit by Git itself, but discourage test_must_fail to be used for checking exit status of non Git commands that are supplied by the system. The current text explains the reason for the former but not the latter. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-24SubmittingPatches: refer to t/README for testsJunio C Hamano
There are general guidelines for writing good tests in t/README but neither SubmittingPatches nor CodingGuidelines refers to it, which makes the document easy to be missed. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-21Git 2.2.0-rc3v2.2.0-rc3Junio C Hamano
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-21mergetools: stop setting $status in merge_cmd()David Aguilar
No callers rely on $status so there's don't need to set it during merge_cmd() for diffmerge, emerge, and kdiff3. Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-21mergetool: simplify conditionalsDavid Aguilar
Combine the $last_status checks into a single conditional. Replace $last_status and $rollup_status with a single variable. Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-21difftool--helper: add explicit exit statementDavid Aguilar
git-difftool--helper returns a zero exit status unless --trust-exit-code is in effect. Add an explicit exit statement to make this clearer. Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-21mergetool--lib: remove use of $status globalDavid Aguilar
Remove return statements and rework check_unchanged() so that the exit status from the last evaluated expression bubbles up to the callers. Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-21mergetool--lib: remove no-op assignment to $status from setup_user_toolJunio C Hamano
Even though setup_user_tool assigns the exit status from "eval $merge_tool_cmd" to $status, the variable is overwritten by the function it calls next, check_unchanged, without ever getting looked at by anybody. And "return $status" at the end of this function returns the value check_unchanged assigned to it (which is the same as the value the function returns). Which makes the assignment a no-op. Remove it. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-21init-db: improve the filemode trustability checkTorsten Bögershausen
Some file systems do not support the executable bit: a) The user executable bit is always 0, e.g. VFAT mounted with -onoexec b) The user executable bit is always 1, e.g. cifs mounted with -ofile_mode=0755 c) There are system where user executable bit is 1 even if it should be 0 like b), but the file mode can be maintained locally. chmod -x changes the file mode from 0766 to 0666, until the file system is unmounted and remounted and the file mode is 0766 again. This been observed when a Windows machine with NTFS exports a share to Mac OS X via smb or afp. Case a) and b) are handled by the current code. Case c) qualifies as "non trustable executable bit" and core.filemode should be false, but this is currently not done. Detect when ".git/config" has the user executable bit set after creat(".git/config", 0666) and set core.filemode to false. Because the permission bits on the file is whatever the end user already had when we are asked to reinitialise an existing repository, and do not give any information on the filesystem behaviour, do this only when running "git init" to create a new repository. Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-21add: ignore only ignored filesMichael J Gruber
"git add foo bar" adds neither foo nor bar when bar is ignored, but dies to let the user recheck their command invocation. This becomes less helpful when "git add foo.*" is subject to shell expansion and some of the expanded files are ignored. "git add --ignore-errors" is supposed to ignore errors when indexing some files and adds the others. It does ignore errors from actual indexing attempts, but does not ignore the error "file is ignored" as outlined above. This is unexpected. Change "git add foo bar" to add foo when bar is ignored, but issue a warning and return a failure code as before the change. That is, in the case of trying to add ignored files we now act the same way (with or without "--ignore-errors") in which we act for more severe indexing errors when "--ignore-errors" is specified. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-20t4026: test "normal" colorJeff King
If the user specifiers "normal" for a foreground color, this should be a noop (while this may sound useless, it is the only way to specify an unchanged foreground color followed by a specific background color). We also check that color "-1" does the same thing. This is not documented, but has worked forever, so let's make sure we keep supporting it. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>