sort by:
Revision Author Date Message Commit Date
d8acfe1 test-regex: expose full regcomp() to the command line Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 27 June 2016, 14:31:35 UTC
949782d test-regex: isolate the bug test code This is in preparation to turn test-regex into some generic regex testing command. Helped-by: Eric Sunshine <sunshine@sunshineco.com> Helped-by: Ramsay Jones <ramsay@ramsayjones.plus.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 27 June 2016, 14:31:35 UTC
60452a3 grep: break down an "if" stmt in preparation for next changes Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 27 June 2016, 14:31:35 UTC
82f6178 new-command.txt: correct the command description file It has always been command-list.txt even at the time this new-command.txt document is added. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 27 June 2016, 13:11:57 UTC
412b9a1 t2300: "git --exec-path" is not usable in $PATH on Windows as-is The "git" command prepends the exec-path to the PATH environment variable for processes it spawns. That is how ". git-sh-setup" in our scripted Porcelains can find the dot-sourced file in the exec-path location that is not usually on user's PATH. When t2300 runs, because it is not spawned by the "git" command, the scriptlet being tested did not run with a realistic setting of PATH environment. It lacked the exec-path on the PATH, and failed to find the dot-sourced file. A recent update to t2300 attempted to fix this, with "PATH=$(git --exec-path):$PATH", which has been the recommended way around v1.6.0 days (a script whose original was written before that release that survives to this day is likely to have such a line). However, the "git --exec-path" command outputs C:\path\to\exec\dir (not /c/path/to/exec/dir) on Windows; the recent update failed to consider the problem that comes from it. Even though Git itself, when doing the equivalent internally, does so in a platform native way (i.e. on Windows, C:\path\to\exec\dir is prepended to the existing value of %PATH% using ';' as a component separator), the result is further massaged by bash and gets turned into $PATH that uses /c/path/to/exec/dir with ':' separating the components, which is the form understood by bash, so scripted Porcelains find commands from PATH correctly. An end user script written in shell, however, cannot prepend "C:\path\to\exec\dir:" to the existing value of $PATH and expect bash to magically turn it into the form it understands. In other words, "PATH=$(git --exec-path):$PATH" does not work as an emulation of what "Git" internally does to the PATH on Windows. To correctly emulate how exec-path is prepended to the PATH environment internally on Windows, we'd need to convert C:\git-sdk-64\usr\src\git to at least /c\git-sdk-64\usr\src\git ourselves before prepending it to PATH. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 22 June 2016, 21:47:36 UTC
4e1b06d commit.c: make find_commit_subject() more robust Just like the pretty printing machinery, we should simply ignore blank lines at the beginning of the commit messages. This discrepancy was noticed when an early version of the rebase--helper produced commit objects with more than one empty line between the header and the commit message. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 22 June 2016, 20:24:17 UTC
7735612 pretty: make the skip_blank_lines() function public This function will be used also in the find_commit_subject() function. While at it, rename the function to reflect that it skips not only empty lines, but any lines consisting of only whitespace, too. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 22 June 2016, 20:23:56 UTC
f793582 doc: git-htmldocs.googlecode.com is no more http://git-htmldocs.googlecode.com/git/git.html says There was no service found for the uri requested. Link to the rendered documentation on Jekyll instead. Reported-by: Andrea Stacchiotti <andreastacchiotti@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 22 June 2016, 19:37:33 UTC
09667d0 git-p4: correct hasBranchPrefix verbose output The logic here was inverted, you got a message saying the file is ignored for each file that is not ignored. Signed-off-by: Andrew Oakley <aoakley@roku.com> Acked-by: Lars Schneider <larsxschneider@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 22 June 2016, 16:45:15 UTC
fe0537a t7810: fix duplicated test title Signed-off-by: Charles Bailey <charles@hashpling.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 21 June 2016, 22:33:34 UTC
5819c2e t5614: don't use subshells Using a subshell for just one git command is both a waste in compute overhead (create a new process) as well as in line count. Suggested-by: Jeff King <peff@peff.net> Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 21 June 2016, 19:08:38 UTC
d2addc3 t7800: readlink may not be available The readlink(1) command is not available on all platforms (notably not on AIX and HP-UX) and can be replaced in this test with the "workaround" ls -ld <name> | sed -e 's/.* -> //' This is no universal readlink replacement but works in the controlled test environment well enough. Signed-off-by: Armin Kunaschik <megabreit@googlemail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 21 June 2016, 18:41:31 UTC
e3efa94 perf: accommodate for MacOSX As this developer has no access to MacOSX developer setups anymore, Travis becomes the best bet to run performance tests on that OS. However, on MacOSX /usr/bin/time is that good old BSD executable that no Linux user cares about, as demonstrated by the perf-lib.sh's use of GNU-ish extensions. And by the hard-coded path. Let's just work around this issue by using gtime on MacOSX, the Homebrew-provided GNU implementation onto which pretty much every MacOSX power user falls back anyway. To help other developers use Travis to run performance tests on MacOSX, the .travis.yml file now sports a commented-out line that installs GNU time via Homebrew. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Reviewed-by: Lars Schneider <larsxschneider@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 21 June 2016, 18:18:17 UTC
bab7483 local_tzoffset: detect errors from tm_to_time_t When we want to know the local timezone offset at a given timestamp, we compute it by asking for localtime() at the given time, and comparing the offset to GMT at that time. However, there's some juggling between time_t and "struct tm" which happens, which involves calling our own tm_to_time_t(). If that function returns an error (e.g., because it only handles dates up to the year 2099), it returns "-1", which we treat as a time_t, and is clearly bogus, leading to bizarre timestamps (that seem to always adjust the time back to (time_t)(uint32_t)-1, in the year 2106). It's not a good idea for local_tzoffset() to simply die here; it would make it hard to run "git log" on a repository with funny timestamps. Instead, let's just treat such cases as "zero offset". Reported-by: Norbert Kiesel <nkiesel@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 20 June 2016, 22:08:07 UTC
36d6792 t0006: test various date formats We ended up testing some of these date formats throughout the rest of the suite (e.g., via for-each-ref's "$(authordate:...)" format), but we never did so systematically. t0006 is the right place for unit-testing of our date-handling code. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 20 June 2016, 22:08:07 UTC
fdba2cd t0006: rename test-date's "show" to "relative" The "show" tests are really only checking relative formats; we should make that more clear. This also frees up the "show" name to later check other formats. We could later fold "relative" into a more generic "show" command, but it's not worth it. Relative times are a special case already because we have to munge the concept of "now" in our tests. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 20 June 2016, 22:08:07 UTC
0767172 mingw: let the build succeed with DEVELOPER=1 The recently introduced developer flags identified a couple of old-style function declarations in the Windows-specific code where the parameter list was left empty instead of specifying "void" explicitly. Let's just fix them. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 20 June 2016, 19:12:12 UTC
18a74a0 clone: do not let --depth imply --shallow-submodules In v2.9.0, we prematurely flipped the default to force cloning submodules shallowly, when the superproject is getting cloned shallowly. This is likely to fail when the upstream repositories submodules are cloned from a repository that is not prepared to serve histories that ends at a commit that is not at the tip of a branch, and we know the world is not yet ready. Use a safer default to clone the submodules fully, unless the user tells us that she knows that the upstream repository of the submodules are willing to cooperate with "--shallow-submodules" option. Noticed-by: Vadim Eisenberg <VADIME@il.ibm.com> Helped-by: Jeff King <peff@peff.net> Helped-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 20 June 2016, 18:35:28 UTC
01247e0 sh-setup: enclose setting of ${VAR=default} in double-quotes We often make sure an environment variable is set to something, either set by the user (in which case we do not molest it) or set it to our default value (otherwise), with : ${VAR=default value} i.e. running the no-op command ":" with ${VAR} as its parameters (or the default value we supply), relying on that ":" is a no-op. This pattern, even though it is no-op from correctness point of view, still can be expensive if the existing value in VAR has shell glob (because they will be expanded against filesystem entities) and IFS whitespaces (because the value need to be split into multiple parameters). Our invocation of ":" command does not care if the parameter given to it is after the value in VAR goes through these processing. Enclosing the whole thing in double-quote, i.e. : "${VAR=default value}" avoids paying the unnecessary cost, so let's do so. Signed-off-by: LE Manh Cuong <cuong.manhle.vn@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 19 June 2016, 21:07:04 UTC
cc6ee97 Documentation/technical: signed merge tag format Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 17 June 2016, 19:10:48 UTC
eda2f11 Documentation/technical: signed commit format Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 17 June 2016, 19:10:30 UTC
5f1abfe Documentation/technical: signed tag format Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 17 June 2016, 18:40:58 UTC
76f9d8b Documentation/technical: describe signature formats We use different types of signature formats in different places. Set up the infrastructure and overview to describe them systematically in our technical documentation. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 17 June 2016, 18:39:05 UTC
9b35cad rebase: update comment about FreeBSD /bin/sh Commit 9f50d32 introduced a fix for FreeBSD /bin/sh misbehaviour when dot-sourcing a file containing "return" statements outside of any function, from a function in another shell script. That issue affects FreeBSD 9.x, and is not present in the /bin/sh in FreeBSD 10.3 and later. Update the comment to clarify this. The example from 9f50d32's commit message produces the expected output on FreeBSD 10.3 and -CURRENT (the upcoming 11.0): % sh script1.sh only this line should show % Signed-off-by: Ed Maste <emaste@freebsd.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 17 June 2016, 18:04:38 UTC
bc91316 Documentation: GPG capitalization When "GPG" is used in a sentence it is now consistently capitalized. When referring to the binary it is left as "gpg". Signed-off-by: David Nicolson <david.nicolson@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 17 June 2016, 00:32:28 UTC
43ec550 bisect: always call setup_revisions after init_revisions init_revisions() initializes the rev_info struct to default values, and setup_revisions() parses any command-line arguments and finalizes the struct. In e22278c (bisect: display first bad commit without forking a new process, 2009-05-28), a show_diff_tree() was added that calls the former but not the latter. It doesn't have any arguments to parse, but it still should do the finalizing step. This may have caused other minor bugs over the years, but it became much more prominent after fe37a9c (pretty: allow tweaking tabwidth in --expand-tabs, 2016-03-29). That leaves the expected tab width as "-1", rather than the true default of "8". When we see a commit with tabs to be expanded, we end up trying to add (size_t)-1 spaces to a strbuf, which complains about the integer overflow. The fix is easy: just call setup_revisions() with no arguments. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 17 June 2016, 00:21:48 UTC
066790d pretty.c: support <direction>|(<negative number>) forms %>|(num), %><|(num) and %<|(num), where num is a positive number, sets a fixed column from the screen's left border. There is no way for us to specifiy a column relative to the right border, which is useful when you want to make use of all terminal space (on big screens). Use negative num for that. Inspired by Go's array syntax (*). (*) I know Python has this first (or before Go, at least) but the idea didn't occur to me until I learned Go. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 16 June 2016, 18:43:37 UTC
3ad87c8 pretty: pass graph width to pretty formatting for use in '%>|(N)' Pass graph width to pretty formatting, to make N in '%>|(N)' include columns consumed by graph rendered when --graph option is in use. For example, in the output of git log --all --graph --pretty='format: [%>|(20)%h] %ar%d' this change will make all commit hashes align at 20th column from the edge of the terminal, not from the edge of the graph. Signed-off-by: Josef Kufner <josef@kufner.cz> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 16 June 2016, 18:43:36 UTC
46e3d17 add--interactive: respect diff.compactionHeuristic We use plumbing to generate the diff, so it doesn't automatically pick up UI config like compactionHeuristic. Let's forward it on, since interactive adding is porcelain. Note that we only need to handle the "true" case. There's no point in passing --no-compaction-heuristic when the variable is false, since nothing else could have turned it on. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 16 June 2016, 18:38:58 UTC
19a7f24 git-svn: document the 'git svn propset' command Add example usage to the git-svn documentation. Reported-by: Joseph Pecoraro <pecoraro@apple.com> Signed-off-by: Alfred Perlstein <alfred@freebsd.org> Reviewed-by: Eric Wong <e@80x24.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 15 June 2016, 20:21:11 UTC
31da121 blame, line-log: do not loop around deref_tag() These callers appear to expect that deref_tag() is to peel one layer of a tag, but the function does not work that way; it has its own loop to unwrap tags until an object that is not a tag appears. Signed-off-by: Junio C Hamano <gitster@pobox.com> 14 June 2016, 20:38:14 UTC
3cddb00 gnome-keyring: Don't hard-code pkg-config executable Helpful if your pkg-config executable has a prefix based on the architecture, for example. Signed-off-by: Heiko Becker <heirecka@exherbo.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 14 June 2016, 20:06:10 UTC
b7410f6 builtin/fetch.c: don't free remote->name after fetch Make fetch's string_list of remote names own all of its string items (strdup'ing when necessary) so that it can deallocate them safely when clearing. Signed-off-by: Keith McGuigan <kmcguigan@twopensource.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 14 June 2016, 18:58:05 UTC
ed008d7 strbuf: describe the return value of strbuf_read_file Mentored-by: Lars Schneider <larsxschneider@gmail.com> Mentored-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 14 June 2016, 17:57:21 UTC
9e70233 fetch: document that pruning happens before fetching This was changed in 10a6cc8 (fetch --prune: Run prune before fetching, 2014-01-02), but it seems that nobody in that discussion realized we were advertising the "after" explicitly. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 14 June 2016, 17:56:27 UTC
05219a1 Git 2.9 Signed-off-by: Junio C Hamano <gitster@pobox.com> 13 June 2016, 17:42:13 UTC
25c7aeb Merge tag 'l10n-2.9.0-rc0' of git://github.com/git-l10n/git-po l10n-2.9.0-rc0 * tag 'l10n-2.9.0-rc0' of git://github.com/git-l10n/git-po: l10n: ko.po: Update Korean translation l10n: ru.po: update Russian translation l10n: de.po: translate 104 new messages l10n: zh_CN: review for git v2.9.0 l10n round 1 l10n: zh_CN: for git v2.9.0 l10n round 1 l10n: pt_PT: update Portuguese translation l10n: pt_PT: update according to git-gui glossary l10n: pt_PT: merge git.pot file l10n: Updated Bulgarian translation of git (2597t,0f,0u) l10n: sv.po: Update Swedish translation (2597t0f0u) l10n: fr.po v2.9.0rnd1 l10n: Updated Vietnamese translation (2597t) l10n: git.pot: v2.9.0 round 1 (104 new, 37 removed) l10n: fr.po Fixed grammar mistake 13 June 2016, 01:00:57 UTC
ad583eb l10n: ko.po: Update Korean translation 11 June 2016, 16:25:58 UTC
091a8f7 Merge branch 'russian-l10n' of https://github.com/DJm00n/git-po-ru * 'russian-l10n' of https://github.com/DJm00n/git-po-ru: l10n: ru.po: update Russian translation 11 June 2016, 12:21:52 UTC
92c2852 l10n: ru.po: update Russian translation Signed-off-by: Dimitriy Ryazantcev <dimitriy.ryazantcev@gmail.com> 11 June 2016, 09:53:43 UTC
a28705d Hopefully the final last-minute update before 2.9 final Signed-off-by: Junio C Hamano <gitster@pobox.com> 10 June 2016, 22:30:19 UTC
e5f7675 Merge branch 'jk/diff-compact-heuristic' It turns out that the earlier effort to update the heuristics may want to use a bit more time to mature. Turn it off by default. * jk/diff-compact-heuristic: diff: disable compaction heuristic for now 10 June 2016, 22:26:06 UTC
45c0c21 Merge branch 'jk/shell-portability' test fixes. * jk/shell-portability: t5500 & t7403: lose bash-ism "local" test-lib: add in-shell "env" replacement 10 June 2016, 22:26:05 UTC
8ffc9d2 Merge branch 'jc/t2300-setup' A test fix. * jc/t2300-setup: t2300: run git-sh-setup in an environment that better mimics the real life 10 June 2016, 22:26:04 UTC
3a39f61 config.c: fix misspelt "occurred" in an error message Signed-off-by: Peter Colberg <peter@colberg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 10 June 2016, 21:53:39 UTC
dc72b50 refs.h: fix misspelt "occurred" in a comment Signed-off-by: Peter Colberg <peter@colberg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 10 June 2016, 21:53:32 UTC
5580b27 diff: disable compaction heuristic for now http://lkml.kernel.org/g/20160610075043.GA13411@sigill.intra.peff.net reports that a change to add a new "function" with common ending with the existing one at the end of the file is shown like this: def foo do_foo_stuff() + common_ending() +end + +def bar + do_bar_stuff() + common_ending() end when the new heuristic is in use. In reality, the change is to add the blank line before "def bar" and everything below, which is what the code without the new heuristic shows. Disable the heuristics by default, and resurrect the documentation for the option and the configuration variables, while clearly marking the feature as still experimental. Signed-off-by: Junio C Hamano <gitster@pobox.com> 10 June 2016, 20:45:23 UTC
b0e098c l10n: de.po: translate 104 new messages Translate 104 new messages came from git.pot update in f517e50 (l10n: git.pot: v2.9.0 round 1 (104 new, 37 removed)). Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com> 10 June 2016, 16:00:46 UTC
6f8d9bc xdiff: fix merging of appended hunk with -W When -W is given we search the lines between the end of the current context and the next change for a function line. If there is none then we merge those two hunks as they must be part of the same function. If the next change is an appended chunk we abort the search early in get_func_line(), however, because its line number is out of range. Fix that by searching from the end of the pre-image in that case instead. Reported-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 09 June 2016, 22:27:26 UTC
2a0e6cd Use "working tree" instead of "working directory" for git status Working directory can be easily confused with the current directory. In one of my patches I already updated the usage of working directory with working tree for the man page but I noticed that git status also uses this incorrect term. Signed-off-by: Lars Vogel <Lars.Vogel@vogella.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 09 June 2016, 19:21:52 UTC
aef18cc l10n: zh_CN: review for git v2.9.0 l10n round 1 Signed-off-by: Ray Chen <oldsharp@gmail.com> Signed-off-by: Jiang Xin <worldhello.net@gmail.com> 09 June 2016, 14:08:39 UTC
ae9f631 doc: change configuration variables format This change configuration variables that where in italic style to monospace font according to the guideline. It was obtained with grep '[[:alpha:]]*\.[[:alpha:]]*::$' config.txt | \ sed -e 's/::$//' -e 's/\./\\\\./' | \ xargs -iP perl -pi -e "s/\'P\'/\`P\`/g" ./*.txt Signed-off-by: Tom Russello <tom.russello@grenoble-inp.org> Signed-off-by: Erwan Mathoniere <erwan.mathoniere@grenoble-inp.org> Signed-off-by: Samuel Groot <samuel.groot@grenoble-inp.org> Signed-off-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr> Reviewed-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com> 08 June 2016, 19:04:55 UTC
47d81b5 doc: more consistency in environment variables format Wrap with backticks (monospaced font) unwrapped or single-quotes wrapped (italic type) environment variables which are followed by the word "environment". It was obtained with: perl -pi -e "s/\'?(\\\$?[0-9A-Z\_]+)\'?(?= environment ?)/\`\1\`/g" *.txt One of the main purposes is to stick to the CodingGuidelines as possible so that people writting new documentation by mimicking the existing are more likely to have it right (even if they didn't read the CodingGuidelines). Signed-off-by: Tom Russello <tom.russello@grenoble-inp.org> Signed-off-by: Erwan Mathoniere <erwan.mathoniere@grenoble-inp.org> Signed-off-by: Samuel Groot <samuel.groot@grenoble-inp.org> Signed-off-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr> Reviewed-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com> 08 June 2016, 19:04:37 UTC
eee7f4a doc: change environment variables format This change GIT_* variables that where in italic style to monospaced font according to the guideline. It was obtained with perl -pi -e "s/\'(GIT_.*?)\'/\`\1\`/g" *.txt One of the main purposes is to stick to the CodingGuidelines as possible so that people writting new documentation by mimicking the existing are more likely to have it right (even if they didn't read the CodingGuidelines). Signed-off-by: Tom Russello <tom.russello@grenoble-inp.org> Signed-off-by: Erwan Mathoniere <erwan.mathoniere@grenoble-inp.org> Signed-off-by: Samuel Groot <samuel.groot@grenoble-inp.org> Signed-off-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr> Reviewed-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com> 08 June 2016, 19:04:37 UTC
41f5b21 doc: clearer rule about formatting literals Make the guideline text that we want for our documentation clearer. Signed-off-by: Tom Russello <tom.russello@grenoble-inp.org> Signed-off-by: Erwan Mathoniere <erwan.mathoniere@grenoble-inp.org> Signed-off-by: Samuel Groot <samuel.groot@grenoble-inp.org> Signed-off-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr> Reviewed-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com> 08 June 2016, 19:04:37 UTC
b8ba412 tree-diff: avoid alloca for large allocations Commit 72441af (tree-diff: rework diff_tree() to generate diffs for multiparent cases as well, 2014-04-07) introduced the use of alloca so that the common cases of commits with 1 or 2 parents would not be adversely affected by going through the multi-parent code. However, our xalloca is not ideal when the number of parents grows very large: 1. If the requested size is too large for our stack, alloca() has no way to tell us, and we simply segfault while trying to access the memory. 2. It does not use our usual memory_limit_check() logic. I measured, and alloca is indeed buying us a very small speedup over xmalloc()/free(). So we'd want to keep something like it. This patch simply puts a conditional in place at each callsite: we use alloca for common known-small numbers of parents, and otherwise use the heap. We are technically still vulnerable to (1), but no more so than if we simply put a few dozen bytes on the stack, which we must do all the time anyway. And likewise, we technically miss a memory limit check if it is tiny, but such a limit is pointless. An alternative to this would be implement something like: struct tree *tp, tp_fallback[2]; if (nparent <= ARRAY_SIZE(tp_fallback)) tp = tp_fallback; else ALLOC_ARRAY(tp, nparent); ... if (tp != tp_fallback) free(tp); That would let us drop our xalloca() portability code entirely. But in my measurements, this seemed to perform slightly worse than the xalloca solution. Note in the example above, and in the patch below, I've used ALLOC_ARRAY() to replace the manual xmalloc(nr * sizeof(*x)). Besides being shorter, this has the bonus that one cannot accidentally overflow a size_t during that computation. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 08 June 2016, 00:47:34 UTC
4e55ed3 add: add --chmod=+x / --chmod=-x options The executable bit will not be detected (and therefore will not be set) for paths in a repository with `core.filemode` set to false, though the users may still wish to add files as executable for compatibility with other users who _do_ have `core.filemode` functionality. For example, Windows users adding shell scripts may wish to add them as executable for compatibility with users on non-Windows. Although this can be done with a plumbing command (`git update-index --add --chmod=+x foo`), teaching the `git-add` command allows users to set a file executable with a command that they're already familiar with. Signed-off-by: Edward Thomson <ethomson@edwardthomson.com> Helped-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 08 June 2016, 00:43:39 UTC
bd8f005 regex: fix a SIZE_MAX macro redefinition warning Since commit 56a1a3ab ("Silence GCC's \"cast of pointer to integer of a different size\" warning", 26-10-2015), sparse has been issuing a macro redefinition warning for the SIZE_MAX macro. However, gcc did not issue any such warning. After commit 56a1a3ab, in terms of the order of #includes and #defines, the code looked something like: $ cat -n junk.c 1 #include <stddef.h> 2 3 #define SIZE_MAX ((size_t) -1) 4 5 #include <stdint.h> 6 7 int main(int argc, char *argv[]) 8 { 9 return 0; 10 } $ $ gcc junk.c $ However, if you compile that file with -Wsystem-headers, then it will also issue a warning. Having set -Wsystem-headers in CFLAGS, using the config.mak file, then (on cygwin): $ make compat/regex/regex.o CC compat/regex/regex.o In file included from /usr/lib/gcc/x86_64-pc-cygwin/4.9.3/include/stdint.h:9:0, from compat/regex/regcomp.c:21, from compat/regex/regex.c:77: /usr/include/stdint.h:362:0: warning: "SIZE_MAX" redefined #define SIZE_MAX (__SIZE_MAX__) ^ In file included from compat/regex/regex.c:69:0: compat/regex/regex_internal.h:108:0: note: this is the location of the previous definition # define SIZE_MAX ((size_t) -1) ^ $ The compilation of the compat/regex code is somewhat unusual in that the regex.c file directly #includes the other c files (regcomp.c, regexec.c and regex_internal.c). Commit 56a1a3ab added an #include of <stdint.h> to the regcomp.c file, which results in the redefinition, since this is included after the regex_internal.h header. This header file contains a 'fallback' definition for SIZE_MAX, in order to support systems which do not have the <stdint.h> header (the HAVE_STDINT_H macro is not defined). In order to suppress the warning, we move the #include of <stdint.h> from regcomp.c to the start of the compilation unit, close to the top of regex.c, prior to the #include of the regex_internal.h header. Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 07 June 2016, 02:22:00 UTC
71abeb7 reflog: continue walking the reflog past root commits If a repository contains more than one root commit, then its HEAD reflog may contain multiple "creation events", i.e. entries whose "from" value is the null sha1. Listing such a reflog currently stops prematurely at the first such entry, even when the reflog still contains older entries. This can scare users into thinking that their reflog got truncated after 'git checkout --orphan'. Continue walking the reflog past such creation events based on the preceeding reflog entry's "new" value. The test 'symbolic-ref writes reflog entry' in t1401-symbolic-ref implicitly relies on the current behavior of the reflog walker to stop at a root commit and thus to list only the reflog entries that are relevant for that test. Adjust the test to explicitly specify the number of relevant reflog entries to be listed. Reported-by: Patrik Gustafsson <pvn@textalk.se> Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 06 June 2016, 22:06:44 UTC
49fa3dc Git 2.9-rc2 Signed-off-by: Junio C Hamano <gitster@pobox.com> 06 June 2016, 21:34:52 UTC
c42b5d8 Sync with 2.8.4 * maint: Git 2.8.4 06 June 2016, 21:30:49 UTC
0b65a8d Git 2.8.4 Signed-off-by: Junio C Hamano <gitster@pobox.com> 06 June 2016, 21:29:32 UTC
1676827 Merge branch 'kb/msys2-tty' into maint The "are we talking with TTY, doing an interactive session?" detection has been updated to work better for "Git for Windows". * kb/msys2-tty: mingw: make isatty() recognize MSYS2's pseudo terminals (/dev/pty*) 06 June 2016, 21:27:38 UTC
389c328 Merge branch 'da/difftool' into maint "git difftool" learned to handle unmerged paths correctly in dir-diff mode. * da/difftool: difftool: handle unmerged files in dir-diff mode difftool: initialize variables for readability 06 June 2016, 21:27:37 UTC
7dcbf89 Merge branch 'tb/core-eol-fix' into maint A couple of bugs around core.autocrlf have been fixed. * tb/core-eol-fix: convert.c: ident + core.autocrlf didn't work t0027: test cases for combined attributes convert: allow core.autocrlf=input and core.eol=crlf t0027: make commit_chk_wrnNNO() reliable 06 June 2016, 21:27:36 UTC
05781d3 Merge branch 'ar/diff-args-osx-precompose' into maint Many commands normalize command line arguments from NFD to NFC variant of UTF-8 on OSX, but commands in the "diff" family did not, causing "git diff $path" to complain that no such path is known to Git. They have been taught to do the normalization. * ar/diff-args-osx-precompose: diff: run arguments through precompose_argv 06 June 2016, 21:27:35 UTC
283badc Merge branch 'sb/submodule-helper-relative-path' A bash-ism "local" has been removed from "git submodule" scripted Porcelain. * sb/submodule-helper-relative-path: submodule: remove bashism from shell script 06 June 2016, 21:18:55 UTC
f6136f3 Merge branch 'sb/submodule-helper-list-signal-unmatch-via-exit-status' The way how "submodule--helper list" signals unmatch error to its callers has been updated. * sb/submodule-helper-list-signal-unmatch-via-exit-status: submodule--helper: offer a consistent API 06 June 2016, 21:18:55 UTC
34d8f5a git-prompt.sh: Don't error on null ${ZSH,BASH}_VERSION, $short_sha When the shell is in "nounset" or "set -u" mode, referencing unset or null variables results in an error. Protect $ZSH_VERSION and $BASH_VERSION against that, and initialize $short_sha before use. Signed-off-by: Ville Skyttä <ville.skytta@iki.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com> 06 June 2016, 20:09:07 UTC
0f974e2 cherry-pick: allow to pick to unborn branches cherry-pick allows to pick single commits to an empty HEAD, but not multiple commits. Allow the multiple commit case, too. Reported-by: Fabrizio Cucci <fabrizio.cucci@gmail.com> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 06 June 2016, 19:59:28 UTC
5b04ee3 l10n: zh_CN: for git v2.9.0 l10n round 1 Update 104 new translations (2596t1f0u) for git v2.9.0-rc0. Signed-off-by: Jiang Xin <worldhello.net@gmail.com> 06 June 2016, 14:33:59 UTC
6326f19 Almost ready for 2.9-rc2 Signed-off-by: Junio C Hamano <gitster@pobox.com> 03 June 2016, 21:38:35 UTC
bf523da Merge branch 'rs/apply-name-terminate' Code clean-up. * rs/apply-name-terminate: apply: remove unused parameters from name_terminate() 03 June 2016, 21:38:04 UTC
29e54b0 Merge branch 'rs/patch-id-use-skip-prefix' Code clean-up. * rs/patch-id-use-skip-prefix: patch-id: use starts_with() and skip_prefix() 03 June 2016, 21:38:03 UTC
fb14575 Merge branch 'bd/readme.markdown-more' The mark-up in the top-level README.md file has been updated to typeset CLI command names differently from the body text. * bd/readme.markdown-more: README.md: format CLI commands with code syntax 03 June 2016, 21:38:02 UTC
ec5ad66 Merge branch 'mm/makefile-developer-can-be-in-config-mak' "make DEVELOPER=1" worked as expected; setting DEVELOPER=1 in config.mak didn't. * mm/makefile-developer-can-be-in-config-mak: Makefile: add $(DEVELOPER_CFLAGS) variable Makefile: move 'ifdef DEVELOPER' after config.mak* inclusion 03 June 2016, 21:38:02 UTC
a8398b9 Merge branch 'em/man-bold-literal' The manpage output of our documentation did not render well in terminal; typeset literals in bold by default to make them stand out more. * em/man-bold-literal: Documentation: bold literals in man 03 June 2016, 21:38:02 UTC
1df2d6e Merge branch 'pa/cherry-pick-doc-typo' "git cherry-pick --help" had three instances of word "behavior", one of which was spelled "behaviour", which is updated to match the other two. * pa/cherry-pick-doc-typo: git-cherry-pick.txt: correct a small typo 03 June 2016, 21:38:02 UTC
160ef79 Merge branch 'mr/send-email-doc-gmail-2fa' Typofix. * mr/send-email-doc-gmail-2fa: Documentation/git-send-email: fix typo in gmail 2FA section 03 June 2016, 21:38:01 UTC
7267404 Merge branch 'js/rebase-i-dedup-call-to-rerere' "git rebase -i", after it fails to auto-resolve the conflict, had an unnecessary call to "git rerere" from its very early days, which was spotted recently; the call has been removed. * js/rebase-i-dedup-call-to-rerere: rebase -i: remove an unnecessary 'rerere' invocation 03 June 2016, 21:38:01 UTC
be3ac81 Merge branch 'js/perf-rebase-i' The one in 'master' has a brown-paper-bag bug that breaks the perf test when used inside a usual Git repository with a working tree. * js/perf-rebase-i: perf: make the tests work without a worktree 03 June 2016, 21:38:00 UTC
fb85db8 rev-list: disable bitmaps when "-n" is used with listing objects You can ask rev-list to use bitmaps to speed up an --objects traversal, which should generally give you your answers much faster. Likewise, you can ask rev-list to limit such a traversal with `-n`, in which case we'll show only a limited set of commits (and only the tree and commit objects directly reachable from those commits). But if you do both together, the results are nonsensical. We end up limiting any fallback traversal we do to _find_ the bitmaps, but the actual set of objects we output will be picked arbitrarily from the union of any bitmaps we do find, and will involve the objects of many more commits. It's possible that somebody might want this as a "show me what you can, but limit the amount of work you do" flag. But as with the prior commit clamping "--count", the results are basically non-deterministic; you'll get the values from some commits between `n` and the total number, and you can't tell which. And unlike the `--count` case, we can't easily generate the "real" value from the bitmap values (you can't just walk back `-n` commits and subtract out the reachable objects from the boundary commits; the bitmaps for `X` record its total reachability, so you don't know which objects are directly from `X` itself, which from `X^`, and so on). So let's just fallback to the non-bitmap code path in this case, so we always give a sane answer. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 03 June 2016, 16:01:02 UTC
5c9f9bf rev-list: "adjust" results of "--count --use-bitmap-index -n" If you ask rev-list for: git rev-list --count --use-bitmap-index HEAD we optimize out the actual traversal and just give you the number of bits set in the commit bitmap. This is faster, which is good. But if you ask to limit the size of the traversal, like: git rev-list --count --use-bitmap-index -n 100 HEAD we'll still output the full bitmapped number we found. On the surface, that might even seem OK. You explicitly asked to use the bitmap index, and it was cheap to compute the real answer, so we gave it to you. But there's something much more complicated going on under the hood. If we don't have a bitmap directly for HEAD, then we have to actually traverse backwards, looking for a bitmapped commit. And _that_ traversal is bounded by our `-n` count. This is a good thing, because it bounds the work we have to do, which is probably what the user wanted by asking for `-n`. But now it makes the output quite confusing. You might get many values: - your `-n` value, if we walked back and never found a bitmap (or fewer if there weren't that many commits) - the actual full count, if we found a bitmap root for every path of our traversal with in the `-n` limit - any number in between! We might have walked back and found _some_ bitmaps, but then cut off the traversal early with some commits not accounted for in the result. So you cannot even see a value higher than your `-n` and say "OK, bitmaps kicked in, this must be the real full count". The only sane thing is for git to just clamp the value to a maximum of the `-n` value, which means we should output the exact same results whether bitmaps are in use or not. The test in t5310 demonstrates this by using `-n 1`. Without this patch we fail in the full-bitmap case (where we do not have to traverse at all) but _not_ in the partial-bitmap case (where we have to walk down to find an actual bitmap). With this patch, both cases just work. I didn't implement the crazy in-between case, just because it's complicated to set up, and is really a subset of the full-count case, which we do cover. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 03 June 2016, 16:00:59 UTC
1df036e Documentation/git-send-email: fix typo in gmail 2FA section Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 02 June 2016, 00:23:38 UTC
fe17fc0 t2300: run git-sh-setup in an environment that better mimics the real life When we run scripted Porcelains, "git" potty has set up the $PATH by prepending $GIT_EXEC_PATH, the path given by "git --exec-path=$there $cmd", etc. already. Because of this, scripted Porcelains can dot-source shell script library like git-sh-setup with simple dot without specifying any path. t2300 however dot-sources git-sh-setup without adjusting $PATH like the real "git" potty does. This has not been a problem so far, but once git-sh-setup wants to rely on the $PATH adjustment, just like any scripted Porcelains already do, it would become one. It cannot for example dot-source another shell library without specifying the full path to it by prefixing $(git --exec-path). Signed-off-by: Junio C Hamano <gitster@pobox.com> 01 June 2016, 21:15:17 UTC
e256eec t5500 & t7403: lose bash-ism "local" In t5500::check_prot_host_port_path(), diagport is not a variable used elsewhere and the function is not recursively called so this can simply lose the "local", which may not be supported by shell (besides, the function liberally clobbers other variables without making them "local"). t7403::reset_submodule_urls() overrides the "root" variable used in the test framework for no good reason; its use is not about temporarily relocating where the test repositories are created. This assignment can be made not to clobber the variable by moving them into the subshells it already uses. Its value is always $TRASH_DIRECTORY, so we could use it instead there, and this function that is called only once and its two subshells may not be necessary (instead, the caller can use "git -C $there config" and set a value that is derived from $TRASH_DIRECTORY), but this is a minimum fix that is needed to lose "local". Helped-by: John Keeping <john@keeping.me.uk> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 01 June 2016, 21:00:33 UTC
44431df submodule: remove bashism from shell script Junio pointed out `relative_path` was using bashisms via the local variables. As the longer term goal is to rewrite most of the submodule code in C, do it now. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 01 June 2016, 18:32:53 UTC
b0f4b40 submodule--helper: offer a consistent API In 48308681 (2016-02-29, git submodule update: have a dedicated helper for cloning), the helper communicated errors back only via exit code, and dance with printing '#unmatched' in case of error was left to git-submodule.sh as it uses the output of the helper and pipes it into shell commands. This change makes the helper consistent by never printing '#unmatched' in the helper but always handling these piping issues in the actual shell script. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 01 June 2016, 18:31:49 UTC
51dd3e8 Makefile: add $(DEVELOPER_CFLAGS) variable This does not change the behavior, but allows the user to tweak DEVELOPER_CFLAGS on the command-line or in a config.mak* file if needed. This also makes the code somewhat cleaner as it follows the pattern <initialisation of variables> <include statements> <actual build logic> by specifying which flags to activate in the first part, and actually activating them in the last one. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com> 01 June 2016, 15:17:15 UTC
d2554c7 test-lib: add in-shell "env" replacement The one-shot environment variable syntax: FOO=BAR some-program is unportable when some-program is actually a shell function, like test_must_fail (on some shells FOO remains set after the function returns, and on others it does not). We sometimes get around this by using env, like: test_must_fail env FOO=BAR some-program But that only works because test_must_fail's arguments are themselves a command which can be run. You can't run: env FOO=BAR test_must_fail some-program because env does not know about our shell functions. So there is no equivalent for test_commit, for example, and one must resort to: ( FOO=BAR export FOO test_commit ) which is a bit verbose. Let's add a version of "env" that works _inside_ the shell, by creating a subshell, exporting variables from its argument list, and running the command. Its use is demonstrated on a currently-unportable case in t4014. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 01 June 2016, 15:04:08 UTC
60bd4b1 Git 2.9-rc1 Signed-off-by: Junio C Hamano <gitster@pobox.com> 31 May 2016, 21:12:15 UTC
257f6f4 Merge branch 'maint' * maint: More topics for 2.8.4 31 May 2016, 21:12:08 UTC
4b0891f More topics for 2.8.4 Signed-off-by: Junio C Hamano <gitster@pobox.com> 31 May 2016, 21:11:38 UTC
3296e1a Merge branch 'sb/submodule-deinit-all' into maint Correct faulty recommendation to use "git submodule deinit ." when de-initialising all submodules, which would result in a strange error message in a pathological corner case. * sb/submodule-deinit-all: submodule deinit: require '--all' instead of '.' for all submodules 31 May 2016, 21:09:46 UTC
e646a82 Merge branch 'bn/http-cookiefile-config' into maint "http.cookieFile" configuration variable clearly wants a pathname, but we forgot to treat it as such by e.g. applying tilde expansion. * bn/http-cookiefile-config: http: expand http.cookieFile as a path Documentation: config: improve word ordering for http.cookieFile 31 May 2016, 21:08:28 UTC
68a6e97 Merge branch 'jk/test-send-sh-x-trace-elsewhere' into maint Running tests with '-x' option to trace the individual command executions is a useful way to debug test scripts, but some tests that capture the standard error stream and check what the command said can be broken with the trace output mixed in. When running our tests under "bash", however, we can redirect the trace output to another file descriptor to keep the standard error of programs being tested intact. * jk/test-send-sh-x-trace-elsewhere: test-lib: set BASH_XTRACEFD automatically 31 May 2016, 21:08:27 UTC
9ee8f94 Merge branch 'js/name-rev-use-oldest-ref' into maint "git describe --contains" often made a hard-to-justify choice of tag to give name to a given commit, because it tried to come up with a name with smallest number of hops from a tag, causing an old commit whose close descendant that is recently tagged were not described with respect to an old tag but with a newer tag. It did not help that its computation of "hop" count was further tweaked to penalize being on a side branch of a merge. The logic has been updated to favor using the tag with the oldest tagger date, which is a lot easier to explain to the end users: "We describe a commit in terms of the (chronologically) oldest tag that contains the commit." * js/name-rev-use-oldest-ref: name-rev: include taggerdate in considering the best name 31 May 2016, 21:08:26 UTC
7063693 rebase -i: remove an unnecessary 'rerere' invocation Interactive rebase uses 'git cherry-pick' and 'git merge' to replay commits. Both invoke the 'rerere' machinery when they fail due to merge conflicts. Note that all code paths with these two commands also invoke the shell function die_with_patch when the commands fail. Since commit 629716d2 ("rerere: do use multiple variants") the second operation of the rerere machinery can be observed by a duplicated message "Recorded preimage for 'file'". This second operation records the same preimage as the first one and, hence, only wastes cycles. Remove the 'git rerere' invocation from die_with_patch. Shell function die_with_patch can be called after the failure of "git commit", too, which also calls into the rerere machinery, but it does so only after a successful commit to record the resolution. Therefore, it is wrong to call 'git rerere' from die_with_patch after "git commit" fails. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 31 May 2016, 20:47:18 UTC
e2522f2 perf: make the tests work without a worktree In regular repositories $source_git and $objects_dir contain relative paths based on $source. Go there to allow cp to resolve them. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 31 May 2016, 20:44:59 UTC
4aa2c47 grep: -W: don't extend context to trailing empty lines Empty lines between functions are shown by grep -W, as it considers them to be part of the function preceding them. They are not interesting in most languages. The previous patches stopped showing them for diff -W. Stop showing empty lines trailing a function with grep -W. Grep scans the lines of a buffer from top to bottom and prints matching lines immediately. Thus we need to peek ahead in order to determine if an empty line is part of a function body and worth showing or not. Remember how far ahead we peeked in order to avoid having to do so repeatedly when handling multiple consecutive empty lines. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 31 May 2016, 20:08:56 UTC
back to top