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,

[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 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 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 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

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

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: [PATCH v2 1/4] delete_ref: accept a reflog message argument

Duy Nguyen writes: > You'll probably want to update the comment block above if msg can be > NULL. We have _very_ good documentation in this file, let's keep it > uptodate. Looking at how other functions in refs.h document their "msg" or "logmsg" parameter, none seem to

Hello

Hello

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 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, 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 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: 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

[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

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 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

[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 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 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

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

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: [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 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 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 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

Ian Jackson writes ("Re: SHA1 collisions found"): > The idea of using the length is a neat trick, but it cannot support > the dcurrent object name abbreviation approach unworkable. Sorry, it's late here and my grammar seems to have disintegrated ! Ian.

[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

[PATCH 3/5] grep: fix bug when recuring with relative pathspec

Fix a bug which causes a child process for a submodule to error out when a relative pathspec with a ".." is provided in the superproject. While at it, correctly construct the super-prefix to be used in a submodule when not at the root of the repository. Signed-off-by: Brandon Williams

[PATCH 5/5] ls-files: fix bug when recuring with relative pathspec

Fix a bug which causes a child process for a submodule to error out when a relative pathspec with a ".." is provided in the superproject. While at it, correctly construct the super-prefix to be used in a submodule when not at the root of the repository. Signed-off-by: Brandon Williams

[PATCH 2/5] pathspec: add PATHSPEC_FROMROOT flag

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 of the repository from erroring out during the pathspec struct construction.

[PATCH 1/5] grep: 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

[PATCH 0/5] recursing submodules with relative pathspec (grep and ls-files)

It was discovered that when using the --recurse-submodules flag with `git grep` and `git ls-files` and specifying a relative path when not at the root causes the child processes spawned to error out with an error like: fatal: ..: '..' is outside repository While true that ".." is outside the

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

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

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: [PATCH 3/3] parse_hide_refs_config: tell parse_config_key we don't want a subsection

On Fri, Feb 24, 2017 at 1:08 PM, Jeff King wrote: > + (!parse_config_key(var, section, NULL, NULL, ) && > +!strcmp(key, "hiderefs"))) { Heh, see how fast my code gets replaced with even better code? ;) All three patches look good, Thanks, Stefan

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

Re: SHA1 collisions found

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 collision, while as said elsewhere > in this thread

Re: SHA1 collisions found

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 spend great amount >> of resources creating their own

Re: SHA1 collisions found

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 collision, while as said elsewhere > in this thread

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: [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 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 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 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

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] 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: [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

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: [PATCH] refs: parse_hide_refs_config to use parse_config_key

Jeff King writes: > 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")

[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

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

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 who _only_ want "section.key" would just use a

[PATCH 1/3] parse_config_key: use skip_prefix instead of starts_with

This saves us having to repeatedly add in "section_len" (and also avoids walking over the first part of the string multiple times for a strlen() and strrchr()). Signed-off-by: Jeff King --- config.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git

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

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] 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 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

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

[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

[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] 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 +++

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

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". Signed-off-by: Andreas Heiduk ---

[PATCH v2 0/2] Documentation: Link git-ls-files to core.quotePath variable.

These two patches replace and extend the precious patches with the same subject. Suggestions from Philip Oakley and Junio C Hamano are included. I tried to find and adjust all places where pathname quoting and "-z" were described. I omitted these places: * Here "-z" is for input only. Quoting is

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)) { >

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: 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: [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

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

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 indicates to be relative, then the url is computed > relative to its default remote. The

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: 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: [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

[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

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

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

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 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

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 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: 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: 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 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: [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

[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

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: [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

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: 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: 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: [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: 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

  1   2   >