Re: SHA1 collisions found

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? There are still many "40" constants in git.git HEAD. Michael asked

Re: [PATCH] submodule init: warn about falling back to a local path

Am 24.02.2017 um 01:17 schrieb Stefan Beller: --- a/Documentation/git-submodule.txt +++ b/Documentation/git-submodule.txt @@ -73,13 +73,17 @@ configuration entries unless `--name` is used to specify a logical name. ... +The default remote is the remote of the remote tracking branch +of the

[PATCH] docs/git-gc: fix default value for `--aggressiveDepth`

In commit 07e7dbf0d (gc: default aggressive depth to 50, 2016-08-11), the default aggressive depth of git-gc has been changed to 50. While git-config(1) has been updated to represent the new default value, git-gc(1) still mentions the old value. This patch fixes it. Signed-off-by: Patrick

Re: [PATCH] docs/git-gc: fix default value for `--aggressiveDepth`

On Fri, Feb 24, 2017 at 09:46:45AM +0100, Patrick Steinhardt wrote: > In commit 07e7dbf0d (gc: default aggressive depth to 50, 2016-08-11), > the default aggressive depth of git-gc has been changed to 50. While > git-config(1) has been updated to represent the new default value, > git-gc(1) still

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

On Fri, Feb 24, 2017 at 2:59 AM, Junio C Hamano wrote: > The variable is obviously not treated the same way as include.path ;-) > > When includeIf..path variable is set in a > configuration file, the configuration file named by that > variable is included (in a way

fatal error when diffing changed symlinks

Hi, with the commands below, you will get : > fatal: bad object > show : command returned error: 128 > I am using version 2.5.5 fedora 23 cd /tmp mkdir a cd a git init touch b ln -s b c git add . git commit -m

Re: git email From: parsing (was Re: [GIT PULL] Staging/IIO driver patches for 4.11-rc1)

On Thu, Feb 23, 2017 at 7:17 AM, Jeff King wrote: > On Thu, Feb 23, 2017 at 07:04:44AM +0100, Greg KH wrote: >> > Poor Simon Sandström. >> > >> > Funnily enough, this only exists for one commit. You've got several >> > other commits from Simon that get his name right. >> > >> >

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

Sometimes a set of repositories want to share configuration settings among themselves that are distinct from other such sets of repositories. A user may work on two projects, each of which have multiple repositories, and use one user.email for one project while using another for the other.

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

Sometimes a set of repositories want to share configuration settings among themselves that are distinct from other such sets of repositories. A user may work on two projects, each of which have multiple repositories, and use one user.email for one project while using another for the other.

[PATCH v6 0/1] Conditional config include

v6 has lots of text changes, most of which I shamelessly copied from Junio's, with some minor edits. The biggest edit is the mention of .git files, which is probably a good idea since .git files are used by multi worktrees and submodules. I could not move the "notes about matching" block into the

Re: [PATCH v6 0/1] Conditional config include

And sorry for duplicates :P Somehow I managed to --dry-run correctly the first time, then had _two_ 000*.patch in the command line. And send-email happily let me shoot myself in the foot. -- Duy

[PATCH v6 0/1] Conditional config include

v6 has lots of text changes, most of which I shamelessly copied from Junio's, with some minor edits. The biggest edit is the mention of .git files, which is probably a good idea since .git files are used by multi worktrees and submodules. I could not move the "notes about matching" block into the

Re: SHA1 collisions found

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/ > > > > IIRC someone has been working on parameterizing git's SHA1 assumptions

Re: SHA1 collisions found

David Lang writes: > On Fri, 24 Feb 2017, Junio C Hamano wrote: > >> *1* In the above toy example, length being 40 vs 64 is used as a >>sign between SHA-1 and the new hash, and careful readers may >>wonder if we should use sha-3,20769079d22... or something like >>that

Re: fatal error when diffing changed symlinks

Junio C Hamano writes: >> cd /tmp >> mkdir a >> cd a >> git init >> touch b >> ln -s b c >> git add . >> git commit -m 'first' >> touch d >> rm c >> ln -s d c >> git difftool --dir-diff > > A slightly worse is that the upcoming Git will ship with a rewritten > "difftool" that

Re: SHA1 collisions found

On Fri, 24 Feb 2017, Jeff King wrote: what if they are forks of each other? (LEDE and OpenWRT, or just linux-kernel and linux-kernel-stable) Once one flips, the other one needs to flip to, or can't interact with them. I know that's harsh, and is likely to create headaches. But in the long

Re: SHA1 collisions found

On Fri, Feb 24, 2017 at 05:39:43PM -0800, David Lang wrote: > On Fri, 24 Feb 2017, Jeff King wrote: > > > > what if they are forks of each other? (LEDE and OpenWRT, or just > > > linux-kernel and linux-kernel-stable) > > > > Once one flips, the other one needs to flip to, or can't interact with

Re: SHA1 collisions found

On Fri, 24 Feb 2017, Jeff King wrote: OpenWRT/LEDE have their core repo, and they pull from many other (unrelated) projects into that repo (and then have 'feeds', which is sort-of-like-submodules to pull in other software that's maintained completely independently) I think with submodules

Re: SHA1 collisions found

On Fri, Feb 24, 2017 at 5:21 PM, Jeff King wrote: > On Fri, Feb 24, 2017 at 05:00:55PM -0800, David Lang wrote: > >> On Fri, 24 Feb 2017, Jeff King wrote: >> >> > >> > So I'd much rather see strong rules like: >> > >> > 1. Once a repo has flag-day switched over to the new hash

Re: SHA1 collisions found

On Fri, Feb 24, 2017 at 5:39 PM, David Lang wrote: > On Fri, 24 Feb 2017, Jeff King wrote: > >>> what if they are forks of each other? (LEDE and OpenWRT, or just >>> linux-kernel and linux-kernel-stable) >> >> >> Once one flips, the other one needs to flip to, or can't interact

Re: SHA1 collisions found

On 24 February 2017 at 21:32, Junio C Hamano wrote: > ankostis writes: > >> Let's assume that git is retroffited to always support the "default" >> SHA-3, but support additionally more hash-funcs. >> If in the future SHA-3 also gets defeated, it would be

Re: SHA1 collisions found

On Fri, Feb 24, 2017 at 5:00 PM, David Lang wrote: > On Fri, 24 Feb 2017, Jeff King wrote: > >> >> So I'd much rather see strong rules like: >> >> 1. Once a repo has flag-day switched over to the new hash format[1], >> new references are _always_ done with the new hash. Even

[PATCH 3/3] upload-pack: compute blob reachability correctly

If allowreachablesha1inwant is set, upload-pack will provide a blob to a user, provided its hash, regardless of whether the blob is reachable or not. Teach upload-pack to compute reachability correctly by passing the "--objects" argument when it invokes "rev-list" if necessary. This commit only

[PATCH 1/3] revision: unify {tree,blob}_objects in rev_info

Whenever tree_objects is set to 1 in revision.h's struct rev_info, blob_objects is likewise set, and vice versa. Combine those two fields into one. Some of the existing code does not handle tree_objects being different from blob_objects properly. For example, "handle_commit" in revision.c

[PATCH 0/3] Test fetch-pack's ability to fetch arbitrary blobs

As stated in a previous e-mail [1], I was trying to think a way to allow Git to fetch arbitrary blobs from another Git server, and it turned out that fetch-pack already can. However, there were some bugs with blob reachability. This patch set fixes those bugs, and verifies (with tests) that

Re: [PATCH 2/5] pathspec: add PATHSPEC_FROMROOT flag

On Fri, Feb 24, 2017 at 3:50 PM, Brandon Williams wrote: > Add the `PATHSPEC_FROMROOT` flag to allow callers to instruct > 'parse_pathspec()' that all provided pathspecs are relative to the root > of the repository. This allows a caller to prevent a path that may be > outside

Re: SHA1 collisions found

On Fri, Feb 24, 2017 at 3:39 PM, Jeff King wrote: > > One thing I worry about in a mixed-hash setting is how often the two > will be mixed. Honestly, I think that a primary goal for a new hash implementation absolutely needs to be to minimize mixing. Not for security issues, but

Re: [PATCH] mingw: use OpenSSL's SHA-1 routines

On Thu, Feb 9, 2017 at 9:02 PM, Jeff King wrote: > > I think this is only half the story. A heavy-sha1 workload is faster, > which is good. But one of the original reasons to prefer blk-sha1 (at > least on Linux) is that resolving libcrypto.so symbols takes a > non-trivial amount

Re: SHA1 collisions found

On Fri, Feb 24, 2017 at 4:39 PM, Linus Torvalds wrote: > > - you'd see in the "object->type" whether it's a new or old-style hash. Actually, I take that back. I think it might be easier to keep "object->type" as-is, and it would only show the current OBJ_xyz

Re: SHA1 collisions found

On Fri, 24 Feb 2017, Jeff King wrote: So I'd much rather see strong rules like: 1. Once a repo has flag-day switched over to the new hash format[1], new references are _always_ done with the new hash. Even ones that point to pre-flag-day objects! how do you define when a repo has

[PATCH 2/3] revision: exclude trees/blobs given commit

When the --objects argument is given to rev-list, an argument of the form "^$tree" can be given to exclude all blobs and trees reachable from that tree, but an argument of the form "^$commit" only excludes that commit, not any blob or tree reachable from it. Make "^$commit" behave consistent to

Re: SHA1 collisions found

On Fri, Feb 24, 2017 at 04:39:45PM -0800, Linus Torvalds wrote: > For example, what I would suggest the rules be is something like this: > > - introduce new tag2/commit2/tree2/blob2 object type tags that imply > that they were hashed using the new hash > > - an old type obviously can never

Re: SHA1 collisions found

On Fri, Feb 24, 2017 at 05:00:55PM -0800, David Lang wrote: > On Fri, 24 Feb 2017, Jeff King wrote: > > > > > So I'd much rather see strong rules like: > > > > 1. Once a repo has flag-day switched over to the new hash format[1], > > new references are _always_ done with the new hash. Even

[PATCH] submodule init: warn about falling back to a local path

When a submodule is initialized, the config variable 'submodule..url' is set depending on the value of the same variable in the .gitmodules file. When the URL indicates to be relative, then the url is computed relative to its default remote. The default remote cannot be determined accurately in

Re: SHA1 collisions found

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 past few days in response to shattered, but over the last 10 years, yet

Re: SHA1 collisions found

On Thu, Feb 23, 2017 at 8:13 PM, Morten Welinder wrote: > The attack seems to generate two 64-bytes blocks, one quarter of which > is repeated data. (Table-1 in the paper.) > > Assuming the result of that is evenly distributed and that bytes are > independent, we can

Re: SHA1 collisions found

On 24 February 2017 at 16:13, 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/ > > > > IIRC someone has been working on parameterizing git's

Re: SHA1 collisions found

Joey Hess writes ("SHA1 collisions found"): > https://shattered.io/static/shattered.pdf > https://freedom-to-tinker.com/2017/02/23/rip-sha-1/ > > 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

Re: git bugs

Hi, On Thu, 23 Feb 2017, Sean Hunt wrote: > There are a few bugs I git I noticed when using mingw, mingw64, > cygwin, and cygwin64. These bugs are the following: > > if I do git ``rebase -i --root`` and tell it to edit every commit to > gpg sign all my commits it bugs out and merges all of the

[GIT PULL] l10n updates for 2.12.0

Hi Junio, Please pull l10n updates for Git 2.12.0: The following changes since commit 076c05393a047247ea723896289b48d6549ed7d0: Hopefully the final batch of mini-topics before the final (2017-02-16 14:46:35 -0800) are available in the git repository at: git://github.com/git-l10n/git-po

Re: [PATCH 3/3] Makefile: add USE_SHA1DC knob

On Fri, Feb 24, 2017 at 06:36:00PM +, HW42 wrote: > > +ifdef USE_SHA1DC > > + SHA1_HEADER = "sha1dc/sha1.h" > > + LIB_OBJS += sha1dc/sha1.o > > + LIB_OBJS += sha1dc/ubc_check.o > > +else > > ifdef BLK_SHA1 > > SHA1_HEADER = "block-sha1/sha1.h" > > LIB_OBJS += block-sha1/sha1.o

Re: [GIT PULL] l10n updates for 2.12.0

Jiang Xin writes: > Hi Junio, > > Please pull l10n updates for Git 2.12.0: > > The following changes since commit 076c05393a047247ea723896289b48d6549ed7d0: > > Hopefully the final batch of mini-topics before the final > (2017-02-16 14:46:35 -0800) > > are available in

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

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 allow scan-build to be invoked without referencing the full path). --- A build

Re: fatal error when diffing changed symlinks

Christophe Macabiau writes: > with the commands below, you will get : > >> fatal: bad object >> show : command returned error: 128 >> > > I am using version 2.5.5 fedora 23 > > cd /tmp

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

Nguyễn Thái Ngọc Duy writes: > +Conditional includes > + > + > +You can include one config file from another conditionally by setting > +a `includeIf..path` variable to the name of the file to be > +included. The variable's value is treated the same way as

Re: git email From: parsing (was Re: [GIT PULL] Staging/IIO driver patches for 4.11-rc1)

On Fri, Feb 24, 2017 at 12:03:45PM +0100, Geert Uytterhoeven wrote: > > The problem isn't on the applying end, but rather on the generating end. > > The From header in the attached mbox is: > > > > From: =?us-ascii?B?PT9VVEYtOD9xP1NpbW9uPTIwU2FuZHN0cj1DMz1CNm0/PQ==?= > > >

Re: [PATCH 3/3] Makefile: add USE_SHA1DC knob

Jeff King: > diff --git a/Makefile b/Makefile > index 8e4081e06..7c4906250 100644 > --- a/Makefile > +++ b/Makefile > @@ -1386,6 +1390,11 @@ ifdef APPLE_COMMON_CRYPTO > SHA1_MAX_BLOCK_SIZE = 1024L*1024L*1024L > endif > > +ifdef USE_SHA1DC > + SHA1_HEADER = "sha1dc/sha1.h" > +

Re: [PATCH] docs/git-gc: fix default value for `--aggressiveDepth`

Jeff King writes: > On Fri, Feb 24, 2017 at 09:46:45AM +0100, Patrick Steinhardt wrote: > >> In commit 07e7dbf0d (gc: default aggressive depth to 50, 2016-08-11), >> the default aggressive depth of git-gc has been changed to 50. While >> git-config(1) has been updated to represent

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

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, "gitdir/i:", , >>> _len)) >>> + return include_by_gitdir(cond,

Re: SHA1 collisions found

On 24 February 2017 at 20:20, Junio C Hamano wrote: > Stefan Beller writes: > >> On Fri, Feb 24, 2017 at 10:14 AM, Junio C Hamano wrote: >> >>> you are inviting people to start using >>> >>> md5,54ddf8d47340e048166c45f439ce65fd >>>

Re: SHA1 collisions found

Junio C Hamano writes: > The not-so-well-hidden agenda was exactly that we _SHOULD_ not > mimick PGP. They do not have a requirement to encourage everybody > to use the same thing because each message is encrypted/signed > independently, i.e. they do not have to chain things

Re: SHA1 collisions found

On Fri, 24 Feb 2017, Junio C Hamano wrote: *1* In the above toy example, length being 40 vs 64 is used as a sign between SHA-1 and the new hash, and careful readers may wonder if we should use sha-3,20769079d22... or something like that that more explicity identifies what hash is used,

Re: SHA1 collisions found

On Fri, Feb 24, 2017 at 10:14 AM, Junio C Hamano wrote: > you are inviting people to start using > > md5,54ddf8d47340e048166c45f439ce65fd > > as object names. which might even be okay for specific subsets of operations. (e.g. all local work including staging things,

Re: [PATCH 10/15] update submodules: add submodule_move_head

On Thu, Feb 23, 2017 at 5:21 PM, Ramsay Jones wrote: > > > On 23/02/17 22:57, Stefan Beller wrote: >> In later patches we introduce the options and flag for commands >> that modify the working directory, e.g. git-checkout. >> >> This piece of code will be used

Re: SHA1 collisions found

Stefan Beller writes: > On Fri, Feb 24, 2017 at 10:14 AM, Junio C Hamano wrote: > >> you are inviting people to start using >> >> md5,54ddf8d47340e048166c45f439ce65fd >> >> as object names. > > which might even be okay for specific subsets of

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

On 24/02/17 13:14, Nguyễn Thái Ngọc Duy wrote: [snip] > Signed-off-by: Nguyễn Thái Ngọc Duy > --- > Documentation/config.txt | 61 + > config.c | 97 > +++ > t/t1305-config-include.sh

Re: [PATCH 15/15] builtin/checkout: add --recurse-submodules switch

On Thu, Feb 23, 2017 at 5:25 PM, Ramsay Jones wrote: >> +int option_parse_recurse_submodules(const struct option *opt, >> + const char *arg, int unset) > > Again, this function should be marked static. > > [I also noted _two_ other

[PATCH] submodule init: warn about falling back to a local path

When a submodule is initialized, the config variable 'submodule..url' is set depending on the value of the same variable in the .gitmodules file. When the URL indicates to be relative, then the url is computed relative to its default remote. The default remote cannot be determined accurately in

[ANNOUNCE] Git v2.12.0

The latest feature release Git v2.12.0 is now available at the usual places. It is comprised of 517 non-merge commits since v2.11.0, contributed by 80 people, 24 of which are new faces. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/ The following public

A note from the maintainer

Welcome to the Git development community. This message is written by the maintainer and talks about how Git project is managed, and how you can work with it. * Mailing list and the community The development is primarily done on the Git mailing list. Help requests, feature proposals, bug reports

What's cooking in git.git (Feb 2017, #08; Fri, 24)

What's cooking in git.git (Feb 2017, #08; Fri, 24) -- Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The ones marked with '.' do not appear

Re: fatal error when diffing changed symlinks

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 lines in run_dir_diff(): > > if (S_ISLNK(lmode)) { >

[PATCH 3/3] parse_hide_refs_config: tell parse_config_key we don't want a subsection

This lets us avoid declaring some otherwise useless variables. Signed-off-by: Jeff King --- refs.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/refs.c b/refs.c index 21bc8c910..b9188908b 100644 --- a/refs.c +++ b/refs.c @@ -1034,11 +1034,10 @@ static

Re: [PATCH] refs: parse_hide_refs_config to use parse_config_key

On Fri, Feb 24, 2017 at 12:33:35PM -0800, Stefan Beller wrote: > parse_config_key was introduced in 1b86bbb0ade (config: add helper > function for parsing key names, 2013-01-22), the NEEDSWORK that is removed > in this patch was introduced at daebaa7813 (upload/receive-pack: allow > hiding ref

[PATCH v2 1/2] Documentation: Improve description for core.quotePath

Signed-off-by: Andreas Heiduk --- Documentation/config.txt | 24 ++-- 1 file changed, 14 insertions(+), 10 deletions(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index 1fee83c..fa06c2a 100644 --- a/Documentation/config.txt +++

Re: [PATCH 01/10] submodule: decouple url and submodule existence

Brandon Williams writes: > Currently the submodule..url config option is used to determine > if a given submodule exists and is interesting to the user. This > however doesn't work very well because the URL is a config option for > the scope of a repository, whereas the

Re: [PATCH v2 1/2] Documentation: Improve description for core.quotePath

W dniu 24.02.2017 o 21:37, Andreas Heiduk pisze: > Signed-off-by: Andreas Heiduk Thanks. This is good work. > --- > Documentation/config.txt | 24 ++-- > 1 file changed, 14 insertions(+), 10 deletions(-) > > diff --git a/Documentation/config.txt

Re: [PATCH v2 2/2] Documentation: Link descriptions of -z to core.quotePath

W dniu 24.02.2017 o 21:37, Andreas Heiduk pisze: > Linking the description for pathname quoting to the configuration > variable "core.quotePath" removes inconstistent and incomplete > sections while also giving two hints how to deal with it: Either with > "-c core.quotePath=false" or with "-z".

Re: [PATCH] mingw: use OpenSSL's SHA-1 routines

Johannes Sixt writes: > It can be argued that in normal interactive use, it is hard to notice > that another DLL is loaded. Don't forget, though, that on Windows it > is not only the pure time to resolve the entry points, but also that > typically virus scanners inspect every

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

From: "Nguyễn Thái Ngọc Duy" Sometimes a set of repositories want to share configuration settings among themselves that are distinct from other such sets of repositories. A user may work on two projects, each of which have multiple repositories, and use one user.email for one

Re: [PATCH] submodule init: warn about falling back to a local path

On Fri, Feb 24, 2017 at 12:19 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> When a submodule is initialized, the config variable 'submodule..url' >> is set depending on the value of the same variable in the .gitmodules >> file. When the URL

hi

Hello Dear Friend, My name is Samfo Abudu I have decided to seek a confidential co-operation with you in the execution of the deal described here-under for our both mutual benefit and I hope you will keep it a top secret because of the nature of the transaction, During the course of our bank

Re: [PATCH] refs: parse_hide_refs_config to use parse_config_key

Jeff King writes: > On Fri, Feb 24, 2017 at 01:18:48PM -0800, Junio C Hamano wrote: > >> > While I'm thinking about it, here are patches to do that. The third one >> > I'd probably squash into yours (after ordering it to the end). >> > >> > [1/3]: parse_config_key: use

Re: SHA1 collisions found

ankostis writes: > Let's assume that git is retroffited to always support the "default" > SHA-3, but support additionally more hash-funcs. > If in the future SHA-3 also gets defeated, it would be highly unlikely > that the same math would also break e.g. Blake. > So certain

Re: SHA1 collisions found

From: "Stefan Beller" On Fri, Feb 24, 2017 at 10:14 AM, Junio C Hamano wrote: you are inviting people to start using md5,54ddf8d47340e048166c45f439ce65fd as object names. which might even be okay for specific subsets of operations. (e.g. all

Re: [PATCH] refs: parse_hide_refs_config to use parse_config_key

On Fri, Feb 24, 2017 at 12:43:35PM -0800, Stefan Beller wrote: > parse_config_key was introduced in 1b86bbb0ade (config: add helper > function for parsing key names, 2013-01-22), the NEEDSWORK that is removed > in this patch was introduced at daebaa7813 (upload/receive-pack: allow > hiding ref

Re: [PATCH] refs: parse_hide_refs_config to use parse_config_key

Stefan Beller writes: > parse_config_key was introduced in 1b86bbb0ade (config: add helper > function for parsing key names, 2013-01-22), the NEEDSWORK that is removed > in this patch was introduced at daebaa7813 (upload/receive-pack: allow > hiding ref hierarchies,

Re: [PATCH] refs: parse_hide_refs_config to use parse_config_key

On Fri, Feb 24, 2017 at 03:39:40PM -0500, Jeff King wrote: > This will start parsing "receive.foobar.hiderefs", which we don't want. > I think you need: > > !parse_config_key(var, section, , _len, ) && > !subsection && > !strcmp(key, "hiderefs") > > Perhaps passing NULL for the subsection

[PATCH] refs: parse_hide_refs_config to use parse_config_key

parse_config_key was introduced in 1b86bbb0ade (config: add helper function for parsing key names, 2013-01-22), the NEEDSWORK that is removed in this patch was introduced at daebaa7813 (upload/receive-pack: allow hiding ref hierarchies, 2013-01-18), which is only a couple days apart, so presumably

Re: [PATCH 2/3] parse_config_key: allow matching single-level config

Jeff King writes: > The parse_config_key() function was introduced to make it > easier to match "section.subsection.key" variables. It also > handles the simpler "section.key", and the caller is > responsible for distinguishing the two from its > out-parameters. > > Most callers

Re: [PATCH 2/3] parse_config_key: allow matching single-level config

On Fri, Feb 24, 2017 at 01:20:48PM -0800, Junio C Hamano wrote: > Jeff King writes: > > > The parse_config_key() function was introduced to make it > > easier to match "section.subsection.key" variables. It also > > handles the simpler "section.key", and the caller is > >

Re: [PATCH 2/3] parse_config_key: allow matching single-level config

Junio C Hamano writes: > Jeff King writes: > >> The parse_config_key() function was introduced to make it >> easier to match "section.subsection.key" variables. It also >> handles the simpler "section.key", and the caller is >> responsible for distinguishing

Re: [PATCH] refs: parse_hide_refs_config to use parse_config_key

On Fri, Feb 24, 2017 at 01:18:48PM -0800, Junio C Hamano wrote: > > While I'm thinking about it, here are patches to do that. The third one > > I'd probably squash into yours (after ordering it to the end). > > > > [1/3]: parse_config_key: use skip_prefix instead of starts_with > > [2/3]:

Re: SHA1 collisions found

Repos should address keeping / 'fixing' broken sha-1 as needed. They also really need to create new native modes so users can initialize and use repos with (sha-3 / sha-256 / whatever) going forward. Backward compatibility with sha-1 or 'fixed sha-1' will be fine. Clients can 'taste' and 'test'

Re: SHA1 collisions found

Linus Torvalds writes: > For example, what I would suggest the rules be is something like this: > > - introduce new tag2/commit2/tree2/blob2 object type tags that imply > that they were hashed using the new hash > > - an old type obviously can never contain a

[PATCH 3/6 v5] revision.c: args starting with "-" might be a revision

setup_revisions used to consider any argument starting with "-" to be either a valid or an unknown option. Teach setup_revisions to check if an argument is a revision before adding it as an unknown option (something that setup_revisions didn't understand) to argv, and moving on to the next

[PATCH 0/6 v5] allow "-" as a shorthand for "previous branch"

An updated version of the patch [1]. Discussion here[1] has been taken into account. The test for "-@{yesterday}" is there inside the log-shorthand test, it is commented out for now. I have removed the redundant pieces of code in merge.c and revert.c as mentioned by Matthieu in [2]. As analysed

[PATCH 6/6 v5] revert.c: delegate handling of "-" shorthand to setup_revisions

revert.c:run_sequencer calls setup_revisions right after replacing "-" with "@{-1}" for this shorthand. A previous patch taught setup_revisions to handle this shorthand by doing the required replacement inside revision.c:get_sha1_1. Hence, the code here is redundant and has been removed. This

[PATCH 5/6 v5] merge.c: delegate handling of "-" shorthand to revision.c:get_sha1

The callchain for handling each argument contains the function revision.c:get_sha1 where the shorthand for "-" ~ "@{-1}" has already been implemented in a previous patch; the complete callchain leading to that function is: 1. merge.c:collect_parents 2. commit.c:get_merge_parent : this function

[PATCH 4/6 v5] sha1_name.c: teach get_sha1_1 "-" shorthand for "@{-1}"

This patch introduces "-" as a method to refer to a revision, and adds tests to test that git-log works with this shorthand. This change will touch the following commands (through revision.c:setup_revisions): * builtin/blame.c * builtin/diff.c * builtin/diff-files.c * builtin/diff-index.c *

[PATCH 1/6 v5] revision.c: do not update argv with unknown option

handle_revision_opt() tries to recognize and handle the given argument. If an option was unknown to it, it used to add the option to unkv[(*unkc)++]. This increment of unkc causes the variable in the caller to change. Teach handle_revision_opt to not update unknown arguments inside unkc anymore.

[PATCH 2/6 v5] revision.c: swap if/else blocks

Swap the condition and bodies of an "if (A) do_A else do_B" in setup_revisions() to "if (!A) do_B else do A", to make the change in the the next step easier to read. No behaviour change is intended in this step. Signed-off-by: Siddharth Kannan --- revision.c | 6

[PATCH 1/6 v5] revision.c: do not update argv with unknown option

handle_revision_opt() tries to recognize and handle the given argument. If an option was unknown to it, it used to add the option to unkv[(*unkc)++]. This increment of unkc causes the variable in the caller to change. Teach handle_revision_opt to not update unknown arguments inside unkc anymore.

Re: [ANNOUNCE] Git v2.12.0

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 existing users will not mind this >change,

Re: SHA1 collisions found

W dniu 25.02.2017 o 00:06, Jeff King pisze: > 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 creating their own

Re: SHA1 collisions found

On Fri, Feb 24, 2017 at 09:32:13AM -0800, Junio C Hamano wrote: > > * Therefore the transition needs to be done by giving every object > >two names (old and new hash function). Objects may refer to each > >other by either name, but must pick one. The usual shape of > > I do not think

Re: SHA1 collisions found

Junio C Hamano writes ("Re: SHA1 collisions found"): > Ian Jackson writes: > > * Therefore the transition needs to be done by giving every object > >two names (old and new hash function). Objects may refer to each > >other by either name, but must pick

Re: SHA1 collisions found

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 creating their own collision, while as said elsewhere in this thread allegedly easy to detect), putting two proof-of-concept different PDFs with

Re: SHA1 collisions found

On 2017-02-25 00:05:34, Jakub Narębski wrote: > W dniu 24.02.2017 o 23:53, Santiago Torres pisze: > > 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

[PATCH 4/5] ls-files: illustrate bug when recursing with relative pathspec

When using the --recurse-submodules flag with a relative pathspec which includes "..", an error is produced inside the child process spawned for a submodule. When creating the pathspec struct in the child, the ".." is interpreted to mean "go up a directory" which causes an error stating that the

  1   2   >