Re: [ANNOUNCE] Git v2.12.0

On Sat, Feb 25, 2017 at 12:31:21AM -0800, Junio C Hamano wrote: > Willy Tarreau writes: > > > Hi Junio, > > > > On Fri, Feb 24, 2017 at 11:28:58AM -0800, Junio C Hamano wrote: > >> * Use of an empty string that is used for 'everything matches' is > >>still warned and Git asks

[PATCH 1/2] t: add an interoperability test harness

The current test suite is good at letting you test a particular version of Git. But it's not very good at letting you test _two_ versions and seeing how they interact (e.g., one cloning from the other). This commit adds a test harness that will build two arbitrary versions of git and make it easy

[PATCH] sha1_file: release fallback base's memory in unpack_entry()

If a pack entry that's used as a delta base is corrupt, unpack_entry() marks it as unusable and then searches the object again in the hope that it can be found in another pack or in a loose file. The memory for this external base object is never released. Free it after use. Signed-off-by: Rene

[PATCH 2/2] t/interop: add test of old clients against modern git-daemon

This test just checks that old clients can clone and fetch from a newer git-daemon. The opposite should also be true, but it's hard to test ancient versions of git-daemon because they lack basic options like "--listen". Note that we have to make a slight tweak to the lib-git-daemon helper from

Re: [ANNOUNCE] Git v2.12.0

Willy Tarreau writes: > Hi Junio, > > On Fri, Feb 24, 2017 at 11:28:58AM -0800, Junio C Hamano wrote: >> * Use of an empty string that is used for 'everything matches' is >>still warned and Git asks users to use a more explicit '.' for that >>instead. The hope is that

[PATCH 0/2] interoperability test harness

This series adds a small test harness for interoperability tests. The heavy lifting is done by the normal test-lib.sh; this just makes it easy for you to have access to two git versions at the same time. This is something I've wanted a few times in the past when we make a fix that can only be

[PATCH 1/2] apply: guard against renames of non-existant empty files

If we have a patch like the one in the new test-case, then we will try to rename a non-existant empty file, i.e. patch->old_name will be NULL. In this case, a NULL entry will be added to fn_table, which is not allowed (a subsequent binary search will die with a NULL pointer dereference). The

git status --> Out of memory, realloc failed

Dear Git group, I use Git at a web hosting service, where my user account has a memory limit of 768 MB: (uiserver):p7715773:~$ uname -a Linux infongp-de15 3.14.0-ui16322-uiabi1-infong-amd64 #1 SMP Debian 3.14.79-2~ui80+4 (2016-11-17) x86_64 GNU/Linux (uiserver):p7715773:~$ git --version

[PATCH 2/2] apply: handle assertion failure gracefully

For the patches in the added testcases, we were crashing with: git-apply: apply.c:3665: check_preimage: Assertion `patch->is_new <= 0' failed. As it turns out, check_preimage() is prepared to handle these conditions, so we can remove the assertion. Found using AFL. Signed-off-by: Vegard

[PATCH] cocci: use ALLOC_ARRAY

Add a semantic patch for using ALLOC_ARRAY to allocate arrays and apply the transformation on the current source tree. The macro checks for multiplication overflow and infers the element size automatically; the result is shorter and safer code. Signed-off-by: Rene Scharfe ---

Re: [PATCH 2/2] http: add an "auto" mode for http.emptyauth

Hi, On Wed, 22 Feb 2017, Jeff King wrote: > [two beautiful patches] I applied them and verified that the reported issue is fixed. Thank you! Hopefully you do not mind that I cherry-picked them in preparation for Git for Windows v2.12.0? I added a small fixup

Re: [PATCH] http(s): automatically try NTLM authentication first

Hi Peff, On Thu, 23 Feb 2017, Jeff King wrote: > For Git for Windows, [PATCH 2/2] seems like the auto behavior would be a > strict improvement over the "true" default they've been shipping. Absolutely. Thank you for your tremendous help! Ciao, Dscho

Re: [PATCH 1/2] apply: guard against renames of non-existant empty files

From: "Vegard Nossum" If we have a patch like the one in the new test-case, then we will "the one in the new test-case" needs a clearer reference to the particular case so that future readers will know what it refers to. Noticed while browsing the commit message..

Re: [PATCH 1/2] apply: guard against renames of non-existant empty files

On 25/02/2017 12:59, Philip Oakley wrote: From: "Vegard Nossum" If we have a patch like the one in the new test-case, then we will "the one in the new test-case" needs a clearer reference to the particular case so that future readers will know what it refers to.

Re: fatal error when diffing changed symlinks

Hi Peff & Junio, On Fri, 24 Feb 2017, Jeff King wrote: > On Fri, Feb 24, 2017 at 11:51:22AM -0800, Junio C Hamano wrote: > > > > A slightly worse is that the upcoming Git will ship with a rewritten > > > "difftool" that makes the above sequence segfault. > > > > The culprit seems to be these

Re: [PATCH 1/2] apply: guard against renames of non-existant empty files

From: "Vegard Nossum" On 25/02/2017 12:59, Philip Oakley wrote: From: "Vegard Nossum" If we have a patch like the one in the new test-case, then we will "the one in the new test-case" needs a clearer reference to the particular case so

FROM AISHA GADDAFI

for more details,contact me at my private email : agaddafi752(at)gmail. com Dr. Aisha Gaddafi, the daughter of late Libyan president, I need a partner or an investor that will help me in investing the sum of $87.5 million USD in his or her country, the funds is deposited here in Burkina Faso

Selamlarım sana

Selamlarım sana Ben çavuşum. Rachel Washburn, umarım hepiniz iyi olur. Birleşmiş Milletler barış muhafızları Afganistan'da terörle savaş için çalışmadan önce kadın bir askerim ancak geçen yıl Eylül 2016'da askeri yönetim devrilmesine karşı özel görev yapmak üzere Burkina Faso'ya taşındı.

Re: [PATCH v6 0/6] stash: support pathspec argument

On 02/20, Junio C Hamano wrote: > Thomas Gummerer writes: > > > @@ -55,10 +53,13 @@ push [-p|--patch] [-k|--[no-]keep-index] > > [-u|--include-untracked] [-a|--all] [-q > > > > Save your local modifications to a new 'stash', and run `git reset > > --hard` to

[PATCH] strbuf: add strbuf_add_real_path()

Add a function for appending the canonized absolute pathname of a given path to a strbuf. It keeps the existing contents intact, as expected of a function of the strbuf_add() family, while avoiding copying the result if the given strbuf is empty. It's more consistent with the rest of the strbuf

Re: git diff --quiet exits with 1 on clean tree with CRLF conversions

On Monday 20 February 2017 at 13:25:01 -0800, Junio C Hamano wrote: > This almost makes me suspect that the place that checks lengths of > one and two in order to refrain from running more expensive content > comparison you found earlier need to ask would_convert_to_git() > before taking the

[ANNOUNCE] Git for Windows 2.12.0

MIME-Version: 1.0 Fcc: Sent Dear Git users, It is my pleasure to announce that Git for Windows 2.12.0 is available from: https://git-for-windows.github.io/ Changes since Git for Windows v2.11.1 (February 3rd 2017) New Features • Comes with Git v2.12.0. • The builtin difftool is

Re: SHA1 collisions found

On Fri, Feb 24, 2017 at 09:32:13AM -0800, Junio C Hamano wrote: > Ian Jackson writes: > > > I have been thinking about how to do a transition from SHA1 to another > > hash function. > > Good. I think many of us have also been, too, not necessarily just > in the

Re: SHA1 collisions found

On Fri, Feb 24, 2017 at 04:42:38PM +0700, Duy Nguyen wrote: > On Thu, Feb 23, 2017 at 11:43 PM, Joey Hess wrote: > > IIRC someone has been working on parameterizing git's SHA1 assumptions > > so a repository could eventually use a more secure hash. How far has > > that gotten?

git-clone --config order & fetching extra refs during initial clone

TL;DR: git-clone ignores any fetch specs passed via --config. The documentation for git-clone --config says: | Set a configuration variable in the newly-created repository; this takes | effect immediately __AFTER__ the repository is initialized, but __BEFORE__ | the remote history is fetched or

Re: SHA1 collisions found

On Sat, Feb 25, 2017 at 06:50:50PM +, brian m. carlson wrote: > > As long as the reader can tell from the format of object names > > stored in the "new object format" object from what era is being > > referred to in some way [*1*], we can name new objects with only new > > hash, I would

Re: [PATCH 1/2] commit: be more precise when searching for headers

On Sat, Feb 25, 2017 at 08:21:52PM +0100, René Scharfe wrote: > Search for a space character only within the current line in > read_commit_extra_header_lines() instead of searching in the whole > buffer (and possibly beyond, if it's not NUL-terminated) and then > discarding any results after the

Re: git-clone --config order & fetching extra refs during initial clone

On Sat, Feb 25, 2017 at 07:12:38PM +, Robin H. Johnson wrote: > TL;DR: git-clone ignores any fetch specs passed via --config. I agree that this is a bug. There's some previous discussion and an RFC patch from lat March (author cc'd):

[PATCH v7 1/6] stash: introduce push verb

Introduce a new git stash push verb in addition to git stash save. The push verb is used to transition from the current command line arguments to a more conventional way, in which the message is given as an argument to the -m option. This allows us to have pathspecs at the end of the command

[PATCH v7 4/6] stash: teach 'push' (and 'create_stash') to honor pathspec

While working on a repository, it's often helpful to stash the changes of a single or multiple files, and leave others alone. Unfortunately git currently offers no such option. git stash -p can be used to work around this, but it's often impractical when there are a lot of changes over multiple

[PATCH v7 5/6] stash: use stash_push for no verb form

Now that we have stash_push, which accepts pathspec arguments, use it instead of stash_save in git stash without any additional verbs. Previously we allowed git stash -- -message, which is no longer allowed after this patch. Messages starting with a hyphen was allowed since 3c2eb80f, ("stash:

Re: [PATCH] sha1_file: release fallback base's memory in unpack_entry()

On Sat, Feb 25, 2017 at 11:02:28AM +0100, René Scharfe wrote: > If a pack entry that's used as a delta base is corrupt, unpack_entry() > marks it as unusable and then searches the object again in the hope that > it can be found in another pack or in a loose file. The memory for this > external

[PATCH] http: add an "auto" mode for http.emptyauth

This variable needs to be specified to make some types of non-basic authentication work, but ideally this would just work out of the box for everyone. However, simply setting it to "1" by default introduces an extra round-trip for cases where it _isn't_ useful. We end up sending a bogus empty

Re: [PATCH v6 4/6] stash: teach 'push' (and 'create_stash') to honor pathspec

On 02/21, Junio C Hamano wrote: > Thomas Gummerer writes: > > > - git reset --hard ${GIT_QUIET:+-q} > > This hunk is probably the most important one to review in the whole > series, in the sense that these are entirely new code that didn't > exist in the

Re: [PATCH 2/2] http: add an "auto" mode for http.emptyauth

On Sat, Feb 25, 2017 at 12:48:54PM +0100, Johannes Schindelin wrote: > Hi, > > On Wed, 22 Feb 2017, Jeff King wrote: > > > [two beautiful patches] > > I applied them and verified that the reported issue is fixed. Thank you! > > Hopefully you do not mind that I cherry-picked them in

[PATCH 1/2] commit: be more precise when searching for headers

Search for a space character only within the current line in read_commit_extra_header_lines() instead of searching in the whole buffer (and possibly beyond, if it's not NUL-terminated) and then discarding any results after the end of the current line. Signed-off-by: Rene Scharfe

[PATCH 2/2] commit: don't check for space twice when looking for header

Both standard_header_field() and excluded_header_field() check if there's a space after the buffer that's handed to them. We already check in the caller if that space is present. Don't bother calling the functions if it's missing, as they are guaranteed to return 0 in that case, and remove the

Re: [PATCH 2/2] commit: don't check for space twice when looking for header

On Sat, Feb 25, 2017 at 08:27:40PM +0100, René Scharfe wrote: > Both standard_header_field() and excluded_header_field() check if > there's a space after the buffer that's handed to them. We already > check in the caller if that space is present. Don't bother calling > the functions if it's

[PATCH v7 6/6] stash: allow pathspecs in the no verb form

Now that stash_push is used in the no verb form of stash, allow specifying the command line for this form as well. Always use -- to disambiguate pathspecs from other non-option arguments. Also make git stash -p an alias for git stash push -p. This allows users to use git stash -p .

[PATCH v7 0/6] stash: support pathspec argument

Thanks Junio for more comments on the last round, and Peff for reading through it as well. Changes since v6: - If no --include-untracked option is given to git stash push, and a pathspec is not in the repository, error out instead of ignoring it. This brings it in line with things like

[PATCH v7 3/6] stash: refactor stash_create

Refactor the internal stash_create function to use a -m flag for specifying the message and -u flag to indicate whether untracked files should be added to the stash. This makes it easier to pass a pathspec argument to stash_create in the next patch. The user interface for git stash create stays

[PATCH v7 2/6] stash: add test for the create command line arguments

Currently there is no test showing the expected behaviour of git stash create's command line arguments. Add a test for that to show the current expected behaviour and to make sure future refactorings don't break those expectations. Signed-off-by: Thomas Gummerer ---

Re: git-clone --config order & fetching extra refs during initial clone

[Re-sending, as I used an old address for Gábor on the original] On Sat, Feb 25, 2017 at 07:12:38PM +, Robin H. Johnson wrote: > TL;DR: git-clone ignores any fetch specs passed via --config. I agree that this is a bug. There's some previous discussion and an RFC patch from lat March (author

Re: [PATCH 1/2] apply: guard against renames of non-existant empty files

Am 25.02.2017 um 11:13 schrieb Vegard Nossum: If we have a patch like the one in the new test-case, then we will try to rename a non-existant empty file, i.e. patch->old_name will be NULL. In this case, a NULL entry will be added to fn_table, which is not allowed (a subsequent binary search will

Re: [PATCH 2/2] apply: handle assertion failure gracefully

Am 25.02.2017 um 11:13 schrieb Vegard Nossum: For the patches in the added testcases, we were crashing with: git-apply: apply.c:3665: check_preimage: Assertion `patch->is_new <= 0' failed. As it turns out, check_preimage() is prepared to handle these conditions, so we can remove the

Re: [PATCH 2/2] commit: don't check for space twice when looking for header

Am 25.02.2017 um 21:15 schrieb Jeff King: On Sat, Feb 25, 2017 at 08:27:40PM +0100, René Scharfe wrote: Both standard_header_field() and excluded_header_field() check if there's a space after the buffer that's handed to them. We already check in the caller if that space is present. Don't

Re: [PATCH] travis-ci: run scan-build every time

> On 24 Feb 2017, at 18:29, Samuel Lijin wrote: > > Introduces the scan-build static code analysis tool from the Clang > project to all Travis CI builds. Installs clang (since scan-build > needs clang as a dependency) to make this possible (on macOS, also > updates PATH to

Re: [PATCH 2/2] commit: don't check for space twice when looking for header

On Sat, Feb 25, 2017 at 10:39:29PM +0100, René Scharfe wrote: > > > + (len == 8 && !memcmp(field, "encoding", 8))); > > > > Unrelated, but this could probably be spelled with a macro and strlen() > > to avoid the magic numbers. It would probably be measurably slower for a > > compiler

Re: SHA1 collisions found

On Sat, Feb 25, 2017 at 02:26:56PM -0500, Jeff King wrote: > On Sat, Feb 25, 2017 at 06:50:50PM +, brian m. carlson wrote: > > > > As long as the reader can tell from the format of object names > > > stored in the "new object format" object from what era is being > > > referred to in some way

Re: [PATCH] travis-ci: run scan-build every time

On Sat, Feb 25, 2017 at 10:48:52PM +0100, Lars Schneider wrote: > > > On 24 Feb 2017, at 18:29, Samuel Lijin wrote: > > > > Introduces the scan-build static code analysis tool from the Clang > > project to all Travis CI builds. Installs clang (since scan-build > > needs

Re: SHA1 collisions found

> On 25 Feb 2017, at 00:06, Jeff King wrote: > > On Fri, Feb 24, 2017 at 11:47:46PM +0100, Jakub Narębski wrote: > >> I have just read on ArsTechnica[1] that while Git repository could be >> corrupted (though this would require attackers to spend great amount >> of resources

Re: [PATCH] travis-ci: run scan-build every time

> On 25 Feb 2017, at 23:31, Jeff King wrote: > > On Sat, Feb 25, 2017 at 10:48:52PM +0100, Lars Schneider wrote: > >> >>> On 24 Feb 2017, at 18:29, Samuel Lijin wrote: >>> >>> Introduces the scan-build static code analysis tool from the Clang >>> project to

Re: [PATCH v6 1/1] config: add conditional include

On Fri, Feb 24, 2017 at 08:14:25PM +0700, Nguyễn Thái Ngọc Duy wrote: > +static int include_condition_is_true(const char *cond, size_t cond_len) > +{ > + /* no condition (i.e., "include.path") is always true */ > + if (!cond) > + return 1; > + > + if (skip_prefix_mem(cond,

Re: SHA1 collisions found

Hi Junio, On Fri, Feb 24, 2017 at 10:10:01PM -0800, Junio C Hamano wrote: > I was thinking we would need mixed mode support for smoother > transition, but it now seems to me that the approach to stratify the > history into old and new is workable. As someone looking to deploy (and having

Re: [PATCH] travis-ci: run scan-build every time

On Sat, Feb 25, 2017 at 3:48 PM, Lars Schneider wrote: > >> On 24 Feb 2017, at 18:29, Samuel Lijin wrote: >> >> It's worth noting that there seems to be a weird issue with scan-build >> where it *will* generate a report for something locally, but

Re: [PATCH v5 1/1] config: add conditional include

On Fri, Feb 24, 2017 at 09:46:17AM -0800, Junio C Hamano wrote: > Duy Nguyen writes: > > >>> + if (skip_prefix_mem(cond, cond_len, "gitdir:", , _len)) > >>> + return include_by_gitdir(cond, cond_len, 0); > >>> + else if (skip_prefix_mem(cond, cond_len,

Re: SHA1 collisions found

On Sat, Feb 25, 2017 at 11:35:27PM +0100, Lars Schneider wrote: > > So we don't actually know how Git would behave in the face of a SHA-1 > > collision. It would be pretty easy to simulate it with something like: > [...] > > That's a good idea! I wonder if it would make sense to setup an >

Re: [PATCH v6 1/1] config: add conditional include

On Sat, Feb 25, 2017 at 5:08 AM, Philip Oakley wrote: >> +Conditional includes >> + >> + >> +You can include one config file from another conditionally by setting > > > On first reading I thought this implied you can only have one `includeIf` > within the

Re: SHA1 collisions found

Hi, On Sat, Feb 25, 2017 at 01:31:32AM +0100, ankostis wrote: > That is why I believe that some HASH (e.g. SHA-3) must be the blessed one. > All git >= 3.x.x must support at least this one (for naming and > cross-referencing between objects). I would stress caution here. SHA3 has survived the

Re: SHA1 collisions found

On Sun, Feb 26, 2017 at 01:13:59AM +, Jason Cooper wrote: > On Fri, Feb 24, 2017 at 10:10:01PM -0800, Junio C Hamano wrote: > > I was thinking we would need mixed mode support for smoother > > transition, but it now seems to me that the approach to stratify the > > history into old and new is

Re: SHA1 collisions found

On 24 February 2017 at 18:23, Jason Cooper wrote: > Hi Ian, > > On Fri, Feb 24, 2017 at 03:13:37PM +, Ian Jackson wrote: >> Joey Hess writes ("SHA1 collisions found"): >> > https://shattered.io/static/shattered.pdf >> > https://freedom-to-tinker.com/2017/02/23/rip-sha-1/