Skip to main content

Browse the archive

swh:1:snp:bb8853bfef8fcf2b1d37fd6404912c7606c98e48
sort by:
Revision Author Date Message Commit Date
9eabf5b Junio C Hamano 26 May 2015, 20:49:59 UTC Git 2.4.2 Signed-off-by: Junio C Hamano <gitster@pobox.com> 26 May 2015, 20:49:59 UTC
df08eb3 Junio C Hamano 26 May 2015, 20:49:26 UTC Merge branch 'jk/still-interesting' into maint "git rev-list --objects $old --not --all" to see if everything that is reachable from $old is already connected to the existing refs was very inefficient. * jk/still-interesting: limit_list: avoid quadratic behavior from still_interesting 26 May 2015, 20:49:26 UTC
1e6c8ba Junio C Hamano 26 May 2015, 20:49:24 UTC Merge branch 'jc/hash-object' into maint "hash-object --literally" introduced in v2.2 was not prepared to take a really long object type name. * jc/hash-object: write_sha1_file(): do not use a separate sha1[] array t1007: add hash-object --literally tests hash-object --literally: fix buffer overrun with extra-long object type git-hash-object.txt: document --literally option 26 May 2015, 20:49:25 UTC
5d53433 Junio C Hamano 26 May 2015, 20:49:23 UTC Merge branch 'jk/rebase-quiet-noop' into maint "git rebase --quiet" was not quite quiet when there is nothing to do. * jk/rebase-quiet-noop: rebase: silence "git checkout" for noop rebase 26 May 2015, 20:49:23 UTC
23903b9 Junio C Hamano 26 May 2015, 20:49:22 UTC Merge branch 'sg/complete-decorate-full-not-long' into maint The completion for "log --decorate=" parameter value was incorrect. * sg/complete-decorate-full-not-long: completion: fix and update 'git log --decorate=' options 26 May 2015, 20:49:22 UTC
a2e5c79 Junio C Hamano 26 May 2015, 20:49:20 UTC Merge branch 'jk/filter-branch-use-of-sed-on-incomplete-line' into maint "filter-branch" corrupted commit log message that ends with an incomplete line on platforms with some "sed" implementations that munge such a line. Work it around by avoiding to use "sed". * jk/filter-branch-use-of-sed-on-incomplete-line: filter-branch: avoid passing commit message through sed 26 May 2015, 20:49:20 UTC
6fd5836 Junio C Hamano 26 May 2015, 20:49:19 UTC Merge branch 'jc/daemon-no-ipv6-for-2.4.1' into maint "git daemon" fails to build from the source under NO_IPV6 configuration (regression in 2.4). * jc/daemon-no-ipv6-for-2.4.1: daemon: unbreak NO_IPV6 build regression 26 May 2015, 20:49:19 UTC
cb9ec8e Junio C Hamano 26 May 2015, 20:49:19 UTC Merge branch 'jk/stash-require-clean-index' into maint "git stash pop/apply" forgot to make sure that not just the working tree is clean but also the index is clean. The latter is important as a stash application can conflict and the index will be used for conflict resolution. * jk/stash-require-clean-index: stash: require a clean index to apply t3903: avoid applying onto dirty index t3903: stop hard-coding commit sha1s 26 May 2015, 20:49:19 UTC
af6d7a6 Junio C Hamano 26 May 2015, 20:49:18 UTC Merge branch 'jk/git-no-more-argv0-path-munging' into maint We have prepended $GIT_EXEC_PATH and the path "git" is installed in (typically "/usr/bin") to $PATH when invoking subprograms and hooks for almost eternity, but the original use case the latter tried to support was semi-bogus (i.e. install git to /opt/foo/git and run it without having /opt/foo on $PATH), and more importantly it has become less and less relevant as Git grew more mainstream (i.e. the users would _want_ to have it on their $PATH). Stop prepending the path in which "git" is installed to users' $PATH, as that would interfere the command search order people depend on (e.g. they may not like versions of programs that are unrelated to Git in /usr/bin and want to override them by having different ones in /usr/local/bin and have the latter directory earlier in their $PATH). * jk/git-no-more-argv0-path-munging: stop putting argv[0] dirname at front of PATH 26 May 2015, 20:49:18 UTC
aaa7e0d Junio C Hamano 13 May 2015, 21:11:43 UTC Git 2.4.1 Signed-off-by: Junio C Hamano <gitster@pobox.com> 13 May 2015, 21:11:43 UTC
a379f25 Junio C Hamano 13 May 2015, 21:05:56 UTC Merge branch 'sb/line-log-plug-pairdiff-leak' into maint * sb/line-log-plug-pairdiff-leak: line-log.c: fix a memleak 13 May 2015, 21:05:56 UTC
071e93a Junio C Hamano 13 May 2015, 21:05:55 UTC Merge branch 'sb/test-bitmap-free-at-end' into maint * sb/test-bitmap-free-at-end: pack-bitmap.c: fix a memleak 13 May 2015, 21:05:56 UTC
36ec67d Junio C Hamano 13 May 2015, 21:05:55 UTC Merge branch 'nd/t1509-chroot-test' into maint Correct test bitrot. * nd/t1509-chroot-test: t1509: update prepare script to be able to run t1509 in chroot again 13 May 2015, 21:05:55 UTC
c1c4a87 Junio C Hamano 13 May 2015, 21:05:54 UTC Merge branch 'jk/type-from-string-gently' into maint "git cat-file bl $blob" failed to barf even though there is no object type that is "bl". * jk/type-from-string-gently: type_from_string_gently: make sure length matches 13 May 2015, 21:05:54 UTC
21b56b9 Junio C Hamano 13 May 2015, 21:05:52 UTC Merge branch 'ep/fix-test-lib-functions-report' into maint * ep/fix-test-lib-functions-report: test-lib-functions.sh: fix the second argument to some helper functions 13 May 2015, 21:05:53 UTC
8a1d897 Junio C Hamano 13 May 2015, 21:05:51 UTC Merge branch 'cn/bom-in-gitignore' into maint Teach the codepaths that read .gitignore and .gitattributes files that these files encoded in UTF-8 may have UTF-8 BOM marker at the beginning; this makes it in line with what we do for configuration files already. * cn/bom-in-gitignore: attr: skip UTF8 BOM at the beginning of the input file config: use utf8_bom[] from utf.[ch] in git_parse_source() utf8-bom: introduce skip_utf8_bom() helper add_excludes_from_file: clarify the bom skipping logic dir: allow a BOM at the beginning of exclude files 13 May 2015, 21:05:51 UTC
ebb464f Junio C Hamano 13 May 2015, 21:05:50 UTC Merge branch 'jk/prune-mtime' into maint Access to objects in repositories that borrow from another one on a slow NFS server unnecessarily got more expensive due to recent code becoming more cautious in a naive way not to lose objects to pruning. * jk/prune-mtime: sha1_file: only freshen packs once per run sha1_file: freshen pack objects before loose reachable: only mark local objects as recent 13 May 2015, 21:05:50 UTC
a60abe1 Junio C Hamano 13 May 2015, 21:05:49 UTC Merge branch 'jk/init-core-worktree-at-root' into maint We avoid setting core.worktree when the repository location is the ".git" directory directly at the top level of the working tree, but the code misdetected the case in which the working tree is at the root level of the filesystem (which arguably is a silly thing to do, but still valid). * jk/init-core-worktree-at-root: init: don't set core.worktree when initializing /.git 13 May 2015, 21:05:49 UTC
c99fec6 Junio C Hamano 11 May 2015, 21:39:28 UTC Sync with 2.3.8 Signed-off-by: Junio C Hamano <gitster@pobox.com> 11 May 2015, 21:39:28 UTC
9a3d637 Junio C Hamano 11 May 2015, 21:36:31 UTC Git 2.3.8 Signed-off-by: Junio C Hamano <gitster@pobox.com> 11 May 2015, 21:36:31 UTC
811ce1b Junio C Hamano 11 May 2015, 21:34:01 UTC Merge branch 'mm/usage-log-l-can-take-regex' into maint-2.3 Documentation fix. * mm/usage-log-l-can-take-regex: log -L: improve error message on malformed argument Documentation: change -L:<regex> to -L:<funcname> 11 May 2015, 21:34:01 UTC
cd01208 Junio C Hamano 11 May 2015, 21:34:00 UTC Merge branch 'jc/diff-no-index-d-f' into maint-2.3 The usual "git diff" when seeing a file turning into a directory showed a patchset to remove the file and create all files in the directory, but "git diff --no-index" simply refused to work. Also, when asked to compare a file and a directory, imitate POSIX "diff" and compare the file with the file with the same name in the directory, instead of refusing to run. * jc/diff-no-index-d-f: diff-no-index: align D/F handling with that of normal Git diff-no-index: DWIM "diff D F" into "diff D/F F" 11 May 2015, 21:34:00 UTC
1add9ae Junio C Hamano 11 May 2015, 21:33:59 UTC Merge branch 'oh/fix-config-default-user-name-section' into maint-2.3 The default $HOME/.gitconfig file created upon "git config --global" that edits it had incorrectly spelled user.name and user.email entries in it. * oh/fix-config-default-user-name-section: config: fix settings in default_user_config template 11 May 2015, 21:33:59 UTC
13ec221 Junio C Hamano 11 May 2015, 21:33:58 UTC Merge branch 'jc/epochtime-wo-tz' into maint-2.3 "git commit --date=now" or anything that relies on approxidate lost the daylight-saving-time offset. * jc/epochtime-wo-tz: parse_date_basic(): let the system handle DST conversion parse_date_basic(): return early when given a bogus timestamp 11 May 2015, 21:33:58 UTC
d358f77 Junio C Hamano 05 May 2015, 18:03:24 UTC daemon: unbreak NO_IPV6 build regression When 01cec54e (daemon: deglobalize hostname information, 2015-03-07) wrapped the global variables such as hostname inside a struct, it forgot to convert one location that spelled "hostname" that needs to be updated to "hi->hostname". This was inside NO_IPV6 block, and was not caught by anybody. Signed-off-by: Junio C Hamano <gitster@pobox.com> 05 May 2015, 18:03:24 UTC
1427a7f Junio C Hamano 04 May 2015, 18:08:10 UTC write_sha1_file(): do not use a separate sha1[] array In the beginning, write_sha1_file() did not have a way to tell the caller the name of the object it wrote to the caller. This was changed in d6d3f9d0 (This implements the new "recursive tree" write-tree., 2005-04-09) by adding the "returnsha1" parameter to the function so that the callers who are interested in the value can optionally pass a pointer to receive it. It turns out that all callers do want to know the name of the object it just has written. Nobody passes a NULL to this parameter, hence it is not necessary to use a separate sha1[] array to receive the result from write_sha1_file_prepare(), and copy the result to the returnsha1 supplied by the caller. Signed-off-by: Junio C Hamano <gitster@pobox.com> 05 May 2015, 17:17:56 UTC
383c342 Eric Sunshine 04 May 2015, 07:25:14 UTC t1007: add hash-object --literally tests git-hash-object learned a --literally option in 5ba9a93 (hash-object: add --literally option, 2014-09-11). Check that --literally allows object creation with a bogus type, with two type strings whose length is reasonably short and very long. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 05 May 2015, 17:17:54 UTC
0c3db67 Eric Sunshine 04 May 2015, 07:25:15 UTC hash-object --literally: fix buffer overrun with extra-long object type "hash-object" learned in 5ba9a93 (hash-object: add --literally option, 2014-09-11) to allow crafting a corrupt/broken object of unknown type. When the user-provided type is particularly long, however, it can overflow the relatively small stack-based character array handed to write_sha1_file_prepare() by hash_sha1_file() and write_sha1_file(), leading to stack corruption (and crash). Introduce a custom helper to allow arbitrarily long typenames just for "hash-object --literally". [jc: Eric's original used a strbuf in the more common codepaths, and I rewrote it to avoid penalizing the non-literally code. Bugs are mine] Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 05 May 2015, 17:14:18 UTC
83115ac Eric Sunshine 04 May 2015, 07:25:13 UTC git-hash-object.txt: document --literally option Document the git-hash-object --literally option added by 5ba9a93 (hash-object: add --literally option, 2014-09-11). While here, also correct a minor typesetting oversight. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 04 May 2015, 21:19:23 UTC
af16bda SZEDER Gábor 01 May 2015, 17:21:00 UTC completion: fix and update 'git log --decorate=' options 'git log --decorate=' understands the 'full', 'short' and 'no' options. From these the completion script only offered 'short' and it offered 'long' instead of 'full'. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 03 May 2015, 18:46:14 UTC
3d4a3ff Junio C Hamano 30 April 2015, 18:25:06 UTC Git 2.4 Signed-off-by: Junio C Hamano <gitster@pobox.com> 30 April 2015, 18:25:06 UTC
df06201 Jeff King 29 April 2015, 15:48:58 UTC filter-branch: avoid passing commit message through sed On some systems (like OS X), if sed encounters input without a trailing newline, it will silently add it. As a result, "git filter-branch" on such systems may silently rewrite commit messages that omit a trailing newline. Even though this is not something we generate ourselves with "git commit", it's better for filter-branch to preserve the original data as closely as possible. We're using sed here only to strip the header fields from the commit object. We can accomplish the same thing with a shell loop. Since shell "read" calls are slow (usually one syscall per byte), we use "cat" once we've skipped past the header. Depending on the size of your commit messages, this is probably faster (you pay the cost to fork, but then read the data in saner-sized chunks). This idea is shamelessly stolen from Junio. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 29 April 2015, 17:01:04 UTC
0ab00b9 Junio C Hamano 28 April 2015, 20:01:29 UTC Merge branch 'mh/multimail-renewal' * mh/multimail-renewal: Update git-multimail to version 1.0.2 28 April 2015, 20:01:29 UTC
3f58726 Junio C Hamano 28 April 2015, 20:00:20 UTC Merge branch 'mg/show-notes-doc' Documentation fix. * mg/show-notes-doc: rev-list-options.txt: complete sentence about notes matching 28 April 2015, 20:00:20 UTC
b799052 Junio C Hamano 28 April 2015, 20:00:19 UTC Merge branch 'nd/versioncmp-prereleases' * nd/versioncmp-prereleases: git tag: mention versionsort.prereleaseSuffix in manpage 28 April 2015, 20:00:19 UTC
5b94967 Junio C Hamano 28 April 2015, 20:00:18 UTC Merge branch 'mg/status-v-v' * mg/status-v-v: status: document the -v/--verbose option 28 April 2015, 20:00:18 UTC
22946a9 Jeff King 28 April 2015, 05:17:37 UTC rebase: silence "git checkout" for noop rebase When the branch to be rebased is already up to date, we "git checkout" the branch, print an "up to date" message, and end the rebase early. However, our checkout may print "Switched to branch 'foo'" or "Already on 'foo'", even if the user has asked for "--quiet". We should avoid printing these messages at all, "--quiet" or no. Since the rebase is a noop, this checkout can be seen as optimizing out these other two checkout operations (that happen in a real rebase): 1. Moving to the detached HEAD to start the rebase; we always feed "-q" to checkout there, and instead rely on our own custom message (which respects --quiet). 2. Finishing a rebase, where we move to the final branch. Here we actually use update-ref rather than git-checkout, and produce no messages. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 28 April 2015, 18:38:40 UTC
36bf6d4 Michael Haggerty 27 April 2015, 11:17:25 UTC Update git-multimail to version 1.0.2 The only changes are to the README files, most notably the list of maintainers and the project URL. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com> 28 April 2015, 18:37:09 UTC
fb3e7d5 Junio C Hamano 27 April 2015, 19:26:21 UTC Sync with 2.3.7 27 April 2015, 19:26:21 UTC
16018ae Junio C Hamano 27 April 2015, 19:25:36 UTC Git 2.3.7 Signed-off-by: Junio C Hamano <gitster@pobox.com> 27 April 2015, 19:25:36 UTC
ad34ad6 Junio C Hamano 27 April 2015, 19:23:53 UTC Merge branch 'tb/connect-ipv6-parse-fix' into maint An earlier update to the parser that disects a URL broke an address, followed by a colon, followed by an empty string (instead of the port number), e.g. ssh://example.com:/path/to/repo. * tb/connect-ipv6-parse-fix: connect.c: ignore extra colon after hostname 27 April 2015, 19:23:54 UTC
89ba311 Junio C Hamano 27 April 2015, 19:23:51 UTC Merge branch 'ma/bash-completion-leaking-x' into maint The completion script (in contrib/) contaminated global namespace and clobbered on a shell variable $x. * ma/bash-completion-leaking-x: completion: fix global bash variable leak on __gitcompappend 27 April 2015, 19:23:51 UTC
631f6f1 Junio C Hamano 27 April 2015, 19:23:47 UTC Merge branch 'jc/push-cert' into maint The "git push --signed" protocol extension did not limit what the "nonce" that is a server-chosen string can contain or how long it can be, which was unnecessarily lax. Limit both the length and the alphabet to a reasonably small space that can still have enough entropy. * jc/push-cert: push --signed: tighten what the receiving end can ask to sign 27 April 2015, 19:23:50 UTC
9c589d9 Michael Haggerty 23 April 2015, 12:27:46 UTC status: document the -v/--verbose option Document `git status -v`, including its new doubled `-vv` form. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com> 24 April 2015, 01:45:33 UTC
6eb1401 Michael Haggerty 23 April 2015, 12:27:50 UTC RelNotes: wordsmithing Make many textual tweaks to the 2.4.0 release notes. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com> 23 April 2015, 18:32:08 UTC
2eac035 Michael Haggerty 23 April 2015, 12:27:49 UTC RelNotes: refer to the rebase -i "todo list", not "insn sheet" "Todo list" is the name that is used in the user-facing documentation. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com> 23 April 2015, 18:32:05 UTC
37f4bed Michael Haggerty 23 April 2015, 12:27:48 UTC RelNotes: correct name of versionsort.prereleaseSuffix Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com> 23 April 2015, 18:29:22 UTC
64f7a26 Michael Haggerty 23 April 2015, 12:27:47 UTC git tag: mention versionsort.prereleaseSuffix in manpage Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com> 23 April 2015, 18:28:24 UTC
564705c Junio C Hamano 22 April 2015, 20:52:43 UTC Git 2.4.0-rc3 Signed-off-by: Junio C Hamano <gitster@pobox.com> 22 April 2015, 20:52:43 UTC
a0b4507 Jeff King 22 April 2015, 18:14:02 UTC stop putting argv[0] dirname at front of PATH When the "git" wrapper is invoked, we prepend the baked-in exec-path to our PATH, so that any sub-processes we exec will all find the git-foo commands that match the wrapper version. If you invoke git with an absolute path, like: /usr/bin/git foo we also prepend "/usr/bin" to the PATH. This was added long ago by by 231af83 (Teach the "git" command to handle some commands internally, 2006-02-26), with the intent that things would just work if you did something like: cd /opt tar xzf premade-git-package.tar.gz alias git=/opt/git/bin/git as we would then find all of the related external commands in /opt/git/bin. I.e., it made git runtime-relocatable, since at the time of 231af83, we installed all of the git commands into $(bindir). But these days, that is not enough. Since f28ac70 (Move all dashed-form commands to libexecdir, 2007-11-28), we do not put commands into $(bindir), and you actually need to convert "/usr/bin" into "/usr/libexec". And not just for finding binaries; we want to find $(sharedir), etc, the same way. The RUNTIME_PREFIX build knob does this the right way, by assuming a sane hierarchy rooted at "$prefix" when we run "$prefix/bin/git", and inferring "$prefix/libexec/git-core", etc. So this feature (prepending the argv[0] dirname to the PATH) is broken for providing a runtime prefix, and has been for many years. Does it do anything for other cases? For the "git" wrapper itself, as well as any commands shipped by "git", the answer is no. Those are already in git's exec-path, which is consulted first. For third-party commands which you've dropped into the same directory, it does include them. So if you do cd /opt tar xzf git-built-specifically-for-opt-git.tar.gz cp third-party/git-foo /opt/git/bin/git-foo alias git=/opt/git/bin/git it does mean that we will find the third-party "git-foo", even if you do not put /opt/git/bin into your $PATH. But the flipside of this is that we will bump the precedence of _other_ third-party tools that happen to be in the same directory as git. For example, consider this setup: 1. Git is installed by the system in /usr/bin. There are other system utilities in /usr/bin. E.g., a system "vi". 2. The user installs tools they prefer in /usr/local/bin. E.g., vim with a "vi" symlink. They set their PATH to /usr/local/bin:/usr/bin to prefer their custom tools. 3. Running /usr/bin/git puts "/usr/bin" at the front of their PATH. When git invokes the editor on behalf of the user, they get the system vi, not their normal vim. There are other variants of this, including overriding system ruby and python (which is quite common using tools like "rvm" and "virtualenv", which use relocatable hierarchies and $PATH settings to get a consistent environment). Given that the main motivation for git placing the argv[0] dirname into the PATH has been broken for years, that the remaining cases are obscure and unlikely (and easily fixed by the user just setting up their $PATH sanely), and that the behavior is hurting real, reasonably common use cases, it's not worth continuing to do so. Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 22 April 2015, 20:41:31 UTC
ed178ef Jeff King 22 April 2015, 19:31:02 UTC stash: require a clean index to apply If you have staged contents in your index and run "stash apply", we may hit a conflict and put new entries into the index. Recovering to your original state is difficult at that point, because tools like "git reset --keep" will blow away anything staged. We can make this safer by refusing to apply when there are staged changes. It's possible we could provide better tooling here, as "git stash apply" should be writing only conflicts to the index (so we know that any stage-0 entries are potentially precious). But it is the odd duck; most "mergy" commands will update the index for cleanly merged entries, and it is not worth updating our tooling to support this use case which is unlikely to be of interest (besides which, we would still need to block a dirty index for "stash apply --index", since that case _would_ be ambiguous). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 22 April 2015, 20:38:58 UTC
88bab59 Jeff King 22 April 2015, 19:30:58 UTC t3903: avoid applying onto dirty index One of the tests in t3903 wants to make sure that applying a stash that touches only "file" can still happen even if there are working tree changes to "other-file". To do so, it adds "other-file" to the index (since otherwise it is an untracked file, voiding the purpose of the test). But as we are about to refactor the dirty-index handling, and as this test does not actually care about having a dirty index (only a dirty working tree), let's bump the tracking of "other-file" into the setup phase, so we can have _just_ a dirty working tree here. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 22 April 2015, 20:38:58 UTC
f2f3fc9 Jeff King 22 April 2015, 19:30:52 UTC t3903: stop hard-coding commit sha1s When testing the diff output of "git stash list", we look for the stash's subject of "WIP on master: $sha1", even though it's not relevant to the diff output. This makes the test brittle to refactoring, as any changes to earlier tests may impact the commit sha1. Since we don't care about the commit subject here, we can simply ask stash not to print it. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 22 April 2015, 20:38:58 UTC
fb89636 Junio C Hamano 21 April 2015, 19:58:50 UTC Sync with maint 21 April 2015, 19:58:50 UTC
ba63bfa Junio C Hamano 21 April 2015, 19:17:09 UTC Git 2.3.6 Signed-off-by: Junio C Hamano <gitster@pobox.com> 21 April 2015, 19:17:09 UTC
d544696 Junio C Hamano 21 April 2015, 19:12:25 UTC Merge branch 'jk/colors' into maint "diff-highlight" (in contrib/) used to show byte-by-byte differences, which meant that multi-byte characters can be chopped in the middle. It learned to pay attention to character boundaries (assuming the UTF-8 payload). * jk/colors: diff-highlight: do not split multibyte characters 21 April 2015, 19:12:25 UTC
d3115a3 Junio C Hamano 21 April 2015, 19:12:24 UTC Merge branch 'jk/test-annoyances' into maint Test fixes. * jk/test-annoyances: t5551: make EXPENSIVE test cheaper t5541: move run_with_cmdline_limit to test-lib.sh t: pass GIT_TRACE through Apache t: redirect stderr GIT_TRACE to descriptor 4 t: translate SIGINT to an exit 21 April 2015, 19:12:24 UTC
42b2f89 Junio C Hamano 21 April 2015, 19:12:23 UTC Merge branch 'pt/enter-repo-comment-fix' into maint Documentation update. * pt/enter-repo-comment-fix: enter_repo(): fix docs to match code 21 April 2015, 19:12:23 UTC
1c30f8e Junio C Hamano 21 April 2015, 19:12:22 UTC Merge branch 'jz/gitweb-conf-doc-fix' into maint Documentation update. * jz/gitweb-conf-doc-fix: gitweb.conf.txt: say "build-time", not "built-time" 21 April 2015, 19:12:22 UTC
c809f42 Junio C Hamano 21 April 2015, 19:12:21 UTC Merge branch 'jk/cherry-pick-docfix' into maint * jk/cherry-pick-docfix: cherry-pick: fix docs describing handling of empty commits 21 April 2015, 19:12:21 UTC
c84364a Junio C Hamano 21 April 2015, 19:12:20 UTC Merge branch 'iu/fix-parse-options-h-comment' into maint * iu/fix-parse-options-h-comment: parse-options.h: OPTION_{BIT,SET_INT} do not store pointer to defval 21 April 2015, 19:12:20 UTC
e8281f0 Junio C Hamano 21 April 2015, 19:12:19 UTC Merge branch 'jg/cguide-we-cannot-count' into maint * jg/cguide-we-cannot-count: CodingGuidelines: update 'rough' rule count 21 April 2015, 19:12:19 UTC
2e0aabe Junio C Hamano 21 April 2015, 19:12:18 UTC Merge branch 'jk/pack-corruption-post-mortem' into maint Documentation update. * jk/pack-corruption-post-mortem: howto: document more tools for recovery corruption 21 April 2015, 19:12:18 UTC
e9ab76d Junio C Hamano 21 April 2015, 19:12:17 UTC Merge branch 'jn/doc-fast-import-no-16-octopus-limit' into maint Documentation update. * jn/doc-fast-import-no-16-octopus-limit: fast-import doc: remove suggested 16-parent limit 21 April 2015, 19:12:17 UTC
ef05a39 Junio C Hamano 21 April 2015, 18:09:19 UTC RelNotes: "merge --quiet" change has been reverted Signed-off-by: Junio C Hamano <gitster@pobox.com> 21 April 2015, 18:09:19 UTC
7c597ef Junio C Hamano 20 April 2015, 22:30:13 UTC Hopefully the last batch for 2.4 Signed-off-by: Junio C Hamano <gitster@pobox.com> 20 April 2015, 22:30:13 UTC
7ff1402 Junio C Hamano 20 April 2015, 22:28:34 UTC Merge branch 'ps/grep-help-all-callback-arg' Code clean-up. * ps/grep-help-all-callback-arg: grep: correctly initialize help-all option 20 April 2015, 22:28:34 UTC
9718c7c Junio C Hamano 20 April 2015, 22:28:33 UTC Merge branch 'tb/connect-ipv6-parse-fix' An earlier update to the parser that disects an address broke an address, followed by a colon, followed by an empty string (instead of the port number). * tb/connect-ipv6-parse-fix: connect.c: ignore extra colon after hostname 20 April 2015, 22:28:33 UTC
a59ac46 Junio C Hamano 20 April 2015, 22:28:32 UTC Merge branch 'va/fix-git-p4-tests' Test fixes for git-p4. * va/fix-git-p4-tests: t9814: guarantee only one source exists in git-p4 copy tests git-p4: fix copy detection test t9814: fix broken shell syntax in git-p4 rename test 20 April 2015, 22:28:32 UTC
268d5bc Junio C Hamano 20 April 2015, 22:28:31 UTC Merge branch 'jc/push-cert' The "git push --signed" protocol extension did not limit what the "nonce" that is a server-chosen string can contain or how long it can be, which was unnecessarily lax. Limit both the length and the alphabet to a reasonably small space that can still have enough entropy. * jc/push-cert: push --signed: tighten what the receiving end can ask to sign 20 April 2015, 22:28:31 UTC
6b1258b Junio C Hamano 20 April 2015, 22:28:29 UTC Merge branch 'ma/bash-completion-leaking-x' The completion script (in contrib/) contaminated global namespace and clobbered on a shell variable $x. * ma/bash-completion-leaking-x: completion: fix global bash variable leak on __gitcompappend 20 April 2015, 22:28:30 UTC
ee1c6c3 Jeff King 20 April 2015, 19:55:00 UTC sha1_file: only freshen packs once per run Since 33d4221 (write_sha1_file: freshen existing objects, 2014-10-15), we update the mtime of existing objects that we would have written out (had they not existed). For the common case in which many objects are packed, we may update the mtime on a single packfile repeatedly. This can result in a noticeable performance problem if calling utime() is expensive (e.g., because your storage is on NFS). We can fix this by keeping a per-pack flag that lets us freshen only once per program invocation. An alternative would be to keep the packed_git.mtime flag up to date as we freshen, and freshen only once every N seconds. In practice, it's not worth the complexity. We are racing against prune expiration times here, which inherently must be set to accomodate reasonable program running times (because they really care about the time between an object being written and it becoming referenced, and the latter is typically the last step a program takes). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 20 April 2015, 20:09:40 UTC
b5f52f3 Jeff King 20 April 2015, 19:54:03 UTC sha1_file: freshen pack objects before loose When writing out an object file, we first check whether it already exists and if so optimize out the write. Prior to 33d4221, we did this by calling has_sha1_file(), which will check for packed objects followed by loose. Since that commit, we check loose objects first. For the common case of a repository whose objects are mostly packed, this means we will make a lot of extra access() system calls checking for loose objects. We should follow the same packed-then-loose order that all of our other lookups use. Reported-by: Stefan Saasen <ssaasen@atlassian.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 20 April 2015, 20:09:38 UTC
1385bb7 Jeff King 27 March 2015, 11:32:41 UTC reachable: only mark local objects as recent When pruning and repacking a repository that has an alternate object store configured, we may traverse a large number of objects in the alternate. This serves no purpose, and may be expensive to do. A longer explanation is below. Commits d3038d2 and abcb865 taught prune and pack-objects (respectively) to treat "recent" objects as tips for reachability, so that we keep whole chunks of history. They built on the object traversal in 660c889 (sha1_file: add for_each iterators for loose and packed objects, 2014-10-15), which covers both local and alternate objects. In both cases, covering alternate objects is unnecessary, as both commands can only drop objects from the local repository. In the case of prune, we traverse only the local object directory. And in the case of repacking, while we may or may not include local objects in our pack, we will never reach into the alternate with "repack -d". The "-l" option is only a question of whether we are migrating objects from the alternate into our repository, or leaving them untouched. It is possible that we may drop an object that is depended upon by another object in the alternate. For example, imagine two repositories, A and B, with A pointing to B as an alternate. Now imagine a commit that is in B which references a tree that is only in A. Traversing from recent objects in B might prevent A from dropping that tree. But this case isn't worth covering. Repo B should take responsibility for its own objects. It would never have had the commit in the first place if it did not also have the tree, and assuming it is using the same "keep recent chunks of history" scheme, then it would itself keep the tree, as well. So checking the alternate objects is not worth doing, and come with a significant performance impact. In both cases, we skip any recent objects that have already been marked SEEN (i.e., that we know are already reachable for prune, or included in the pack for a repack). So there is a slight waste of time in opening the alternate packs at all, only to notice that we have already considered each object. But much worse, the alternate repository may have a large number of objects that are not reachable from the local repository at all, and we end up adding them to the traversal. We can fix this by considering only local unseen objects. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 20 April 2015, 20:09:27 UTC
0269f96 Matthieu Moy 20 April 2015, 12:09:07 UTC log -L: improve error message on malformed argument The old message did not mention the :regex:file form. To avoid overly long lines, split the message into two lines (in case item->string is long, it will be the only part truncated in a narrow terminal). Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com> 20 April 2015, 18:06:10 UTC
d349e0e Matthieu Moy 20 April 2015, 12:09:06 UTC Documentation: change -L:<regex> to -L:<funcname> The old wording was somehow implying that <start> and <end> were not regular expressions. Also, the common case is to use a plain function name here so <funcname> makes sense (the fact that it is a regular expression is documented in line-range-format.txt). Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com> 20 April 2015, 18:05:50 UTC
1eb0545 Junio C Hamano 19 April 2015, 01:35:48 UTC Merge tag 'gitgui-0.20.0' of http://repo.or.cz/r/git-gui git-gui 0.20.0 * tag 'gitgui-0.20.0' of http://repo.or.cz/r/git-gui: git-gui: set version 0.20 git-gui: sv.po: Update Swedish translation (547t0f0u) git-gui i18n: Updated Bulgarian translation (547t,0f,0u) git-gui: Makes chooser set 'gitdir' to the resolved path git-gui: Fixes chooser not accepting gitfiles git-gui: reinstate support for Tcl 8.4 git-gui: fix problem with gui.maxfilesdisplayed git-gui: fix verbose loading when git path contains spaces. git-gui/gitk: Do not depend on Cygwin's "kill" command on Windows git-gui: add configurable tab size to the diff view git-gui: Make git-gui lib dir configurable at runime git-gui i18n: Updated Bulgarian translation (520t,0f,0u) L10n: vi.po (543t): Init translation for Vietnamese git-gui: align the new recursive checkbox with the radiobuttons. git-gui: Add a 'recursive' checkbox in the clone menu. 19 April 2015, 01:35:48 UTC
64f2589 Nguyễn Thái Ngọc Duy 18 April 2015, 11:22:53 UTC t1509: update prepare script to be able to run t1509 in chroot again Tested on Gentoo and OpenSUSE 13.1, both x86-64 Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 19 April 2015, 00:51:04 UTC
4498b3a Pat Thoyts 18 April 2015, 11:15:32 UTC git-gui: set version 0.20 Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net> 18 April 2015, 11:15:32 UTC
5a5c11f Peter Krefting 27 March 2015, 09:25:32 UTC git-gui: sv.po: Update Swedish translation (547t0f0u) Signed-off-by: Peter Krefting <peter@softwolves.pp.se> Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net> 18 April 2015, 11:03:50 UTC
de18648 Alexander Shopov 07 April 2015, 15:29:46 UTC git-gui i18n: Updated Bulgarian translation (547t,0f,0u) Signed-off-by: Alexander Shopov <ash@kambanaria.org> Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net> 18 April 2015, 10:51:39 UTC
b6e8a3b Jeff King 17 April 2015, 22:11:04 UTC limit_list: avoid quadratic behavior from still_interesting When we are limiting a rev-list traversal due to UNINTERESTING refs, we have to walk down the tips (both interesting and uninteresting) to find where they intersect. We keep a queue of commits to examine, pop commits off the queue one by one, and potentially add their parents. The size of the queue will naturally fluctuate based on the "width" of the history graph; i.e., the number of simultaneous lines of development. But for the most part it will stay in the same ballpark as the initial number of tips we fed, shrinking over time (as we hit common ancestors of the tips). So roughly speaking, if we start with `N` tips, we'll spend much of the time with a queue around `N` items. For each UNINTERESTING commit we pop, we call still_interesting to check whether marking its parents as UNINTERESTING has made the whole queue uninteresting (in which case we can quit early). Because the queue is stored as a linked list, this is `O(N)`, where `N` is the number of items in the queue. So processing a queue with `N` commits marked UNINTERESTING (and one or more interesting commits) will take `O(N^2)`. If you feed a lot of positive tips, this isn't a problem. They aren't UNINTERESTING, so they don't incur the still_interesting check. It also isn't a problem if you traverse from an interesting tip to some UNINTERESTING bases. We order the queue by recency, so the interesting commits stay at the front of the queue as we walk down them. The linear check can exit early as soon as it sees one interesting commit left in the queue. But if you want to know whether an older commit is reachable from a set of newer tips, we end up processing in the opposite direction: from the UNINTERESTING ones down to the interesting one. This may happen when we call: git rev-list $commits --not --all in check_everything_connected after a fetch. If we fetched something much older than most of our refs, and if we have a large number of refs, the traversal cost is dominated by the quadratic behavior. These commands simulate the connectivity check of such a fetch, when you have `$n` distinct refs in the receiver: # positive ref is 100,000 commits deep git rev-list --all | head -100000 | tail -1 >input # huge number of more recent negative refs git rev-list --all | head -$n | sed s/^/^/ >>input time git rev-list --stdin <input Here are timings for various `n` on the linux.git repository. The `n=1` case provides a baseline for just walking the commits, which lets us see the still_interesting overhead. The times marked with `+` subtract that baseline to show just the extra time growth due to the large number of refs. The `x` numbers show the slowdown of the adjusted time versus the prior trial. n | before | after -------------------------------------------------------- 1 | 0.991s | 0.848s 10000 | 1.120s (+0.129s) | 0.885s (+0.037s) 20000 | 1.451s (+0.460s, 3.5x) | 0.923s (+0.075s, 2.0x) 40000 | 2.731s (+1.740s, 3.8x) | 0.994s (+0.146s, 1.9x) 80000 | 8.235s (+7.244s, 4.2x) | 1.123s (+0.275s, 1.9x) Each trial doubles `n`, so you can see the quadratic (`4x`) behavior before this patch. Afterwards, we have a roughly linear relationship. The implementation is fairly straightforward. Whenever we do the linear search, we cache the interesting commit we find, and next time check it before doing another linear search. If that commit is removed from the list or becomes UNINTERESTING itself, then we fall back to the linear search. This is very similar to the trick used by fce87ae (Fix quadratic performance in rewrite_one., 2008-07-12). I considered and rejected several possible alternatives: 1. Keep a count of UNINTERESTING commits in the queue. This requires managing the count not only when removing an item from the queue, but also when marking an item as UNINTERESTING. That requires touching the other functions which mark commits, and would require knowing quickly which commits are in the queue (lookup in the queue is linear, so we would need an auxiliary structure or to also maintain an IN_QUEUE flag in each commit object). 2. Keep a separate list of interesting commits. Drop items from it when they are dropped from the queue, or if they become UNINTERESTING. This again suffers from extra complexity to maintain the list, not to mention CPU and memory. 3. Use a better data structure for the queue. This is something that could help the fix in fce87ae, because we order the queue by recency, and it is about inserting quickly in recency order. So a normal priority queue would help there. But here, we cannot disturb the order of the queue, which makes things harder. We really do need an auxiliary index to track the flag we care about, which is basically option (2) above. The "cache" trick is simple, and the numbers above show that it works well in practice. This is because the length of time it takes to find an interesting commit is proportional to the length of time it will remain cached (i.e., if we have to walk a long way to find it, it also means we have to pop a lot of elements in the queue until we get rid of it and have to find another interesting commit). The worst case is still quadratic, though. We could have `N` uninteresting commits at the front of the queue, followed by `N` interesting commits, where commit `i` has parent `i+N`. When we pop commit `i`, we will notice that the parent of the next commit, `i+1+N` is still interesting and cache it. But then handling commit `i+1`, we will mark its parent `i+1+N` uninteresting, and immediately invalidate our cache. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 17 April 2015, 22:22:05 UTC
b7994af Jeff King 17 April 2015, 14:52:48 UTC type_from_string_gently: make sure length matches When commit fe8e3b7 refactored type_from_string to allow input that was not NUL-terminated, it switched to using strncmp instead of strcmp. But this means we check only the first "len" bytes of the strings, and ignore any remaining bytes in the object_type_string. We should make sure that it is also "len" bytes, or else we would accept "comm" as "commit", and so forth. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 17 April 2015, 20:54:39 UTC
7e11052 Ossi Herrala 17 April 2015, 14:50:10 UTC config: fix settings in default_user_config template The name (not user) and email setting should be in config section "user" and not in "core" as documented in Documentation/config.txt. Signed-off-by: Ossi Herrala <oherrala@gmail.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 17 April 2015, 17:32:46 UTC
7348cde Michael J Gruber 17 April 2015, 14:28:56 UTC rev-list-options.txt: complete sentence about notes matching Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 17 April 2015, 17:30:51 UTC
de248e9 Elia Pinto 16 April 2015, 14:12:07 UTC test-lib-functions.sh: fix the second argument to some helper functions The second argument to test_path_is_file and test_path_is_dir must be $2 and not $*, which instead would repeat the file name in the error message. Signed-off-by: Elia Pinto <gitter.spiros@gmail.com> Reviewed-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com> 16 April 2015, 20:31:35 UTC
27547e5 Junio C Hamano 16 April 2015, 17:48:58 UTC attr: skip UTF8 BOM at the beginning of the input file Signed-off-by: Junio C Hamano <gitster@pobox.com> 16 April 2015, 18:35:38 UTC
599446d Junio C Hamano 16 April 2015, 17:47:45 UTC config: use utf8_bom[] from utf.[ch] in git_parse_source() Because the function reads one character at the time, unfortunately we cannot use the easier skip_utf8_bom() helper, but at least we do not have to duplicate the constant string this way. Signed-off-by: Junio C Hamano <gitster@pobox.com> 16 April 2015, 18:35:27 UTC
dde843e Junio C Hamano 16 April 2015, 17:45:29 UTC utf8-bom: introduce skip_utf8_bom() helper With the recent change to ignore the UTF8 BOM at the beginning of .gitignore files, we now have two codepaths that do such a skipping (the other one is for reading the configuration files). Introduce utf8_bom[] constant string and skip_utf8_bom() helper and teach .gitignore code how to use it. Signed-off-by: Junio C Hamano <gitster@pobox.com> 16 April 2015, 18:35:06 UTC
cb0abea Junio C Hamano 16 April 2015, 18:26:29 UTC add_excludes_from_file: clarify the bom skipping logic Even though the previous step shifts where the "entry" begins, we still iterate over the original buf[], which may begin with the UTF-8 BOM we are supposed to be skipping. At the end of the first line, the code grabs the contents of it starting at "entry", so there is nothing wrong per-se, but the logic looks really confused. Instead, move the buf pointer and shrink its size, to truly pretend that UTF-8 BOM did not exist in the input. Signed-off-by: Junio C Hamano <gitster@pobox.com> 16 April 2015, 18:26:29 UTC
245e1c1 Carlos Martín Nieto 16 April 2015, 14:05:12 UTC dir: allow a BOM at the beginning of exclude files Some text editors like Notepad or LibreOffice write an UTF-8 BOM in order to indicate that the file is Unicode text rather than whatever the current locale would indicate. If someone uses such an editor to edit a gitignore file, we are left with those three bytes at the beginning of the file. If we do not skip them, we will attempt to match a filename with the BOM as prefix, which won't match the files the user is expecting. Signed-off-by: Carlos Martín Nieto <cmn@elego.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 16 April 2015, 17:17:04 UTC
3d6bc9a Junio C Hamano 16 April 2015, 15:03:14 UTC Revert "merge: pass verbosity flag down to merge-recursive" This reverts commit 2bf15a3330a26183adc8563dbeeacc11294b8a01, whose intention was good, but the verbosity levels used in merge-recursive turns out to be rather uneven. For example, a merge of two branches with conflicting submodule updates used to report CONFLICT: output with --quiet but no longer (which *is* desired), while the final "Automatic merge failed; fix conflicts and then commit" message is still shown even with --quiet (which *is* inconsistent). Originally reported by Bryan Turner; it is too early to declare what the concensus is, but it seems that we would need to level the verbosity levels used in merge strategy backends before we can go forward. In the meantime, we'd revert to the old behaviour until that happens. cf. $gmane/267245 16 April 2015, 15:03:14 UTC
f6e6362 Junio C Hamano 15 April 2015, 15:47:48 UTC parse_date_basic(): let the system handle DST conversion The function parses the input to compute the broken-down time in "struct tm", and the GMT timezone offset. If the timezone offset does not exist in the input, the broken-down time is turned into the number of seconds since epoch both in the current timezone and in GMT and the offset is computed as their difference. However, we forgot to make sure tm.tm_isdst is set to -1 (i.e. let the system figure out if DST is in effect in the current timezone when turning the broken-down time to the number of seconds since epoch); it is done so at the beginning of the function, but a call to match_digit() in the function can lead to a call to gmtime_r() to clobber the field. Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Diagnosed-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 15 April 2015, 17:25:32 UTC
7fcec48 Junio C Hamano 15 April 2015, 15:43:58 UTC parse_date_basic(): return early when given a bogus timestamp When the input does not have GMT timezone offset, the code computes it by computing the local and GMT time for the given timestamp. But there is no point doing so if the given timestamp is known to be a bogus one. Signed-off-by: Junio C Hamano <gitster@pobox.com> 15 April 2015, 17:25:05 UTC
e46fe3d Junio C Hamano 14 April 2015, 18:57:13 UTC Git 2.4.0-rc2 Signed-off-by: Junio C Hamano <gitster@pobox.com> 14 April 2015, 18:57:13 UTC
7a1aa0c Junio C Hamano 14 April 2015, 18:49:13 UTC Merge branch 'jk/colors' "diff-highlight" (in contrib/) used to show byte-by-byte differences, which meant that multi-byte characters can be chopped in the middle. It learned to pay attention to character boundaries (assuming the UTF-8 payload). * jk/colors: diff-highlight: do not split multibyte characters 14 April 2015, 18:49:13 UTC
3cdff83 Junio C Hamano 14 April 2015, 18:49:12 UTC Merge branch 'jk/merge-quiet' "git merge --quiet" did not squelch messages from the underlying merge-recursive strategy. * jk/merge-quiet: merge: pass verbosity flag down to merge-recursive 14 April 2015, 18:49:12 UTC
f8e593e Junio C Hamano 14 April 2015, 18:49:11 UTC Merge branch 'jk/pack-corruption-post-mortem' Documentation update. * jk/pack-corruption-post-mortem: howto: document more tools for recovery corruption 14 April 2015, 18:49:11 UTC
fa9aaa8 Junio C Hamano 14 April 2015, 18:49:10 UTC Merge branch 'jc/update-instead-into-void' A push into an unborn branch, with "receive.denyCurrentBranch" set to "updateInstead", did not check out the working tree as expected. * jc/update-instead-into-void: push-to-deploy: allow pushing into an unborn branch and updating it 14 April 2015, 18:49:10 UTC
d2ae751 Junio C Hamano 14 April 2015, 18:49:09 UTC Merge branch 'sb/plug-streaming-leak' * sb/plug-streaming-leak: streaming.c: fix a memleak 14 April 2015, 18:49:09 UTC
back to top