On Thu, Feb 23, 2017 at 9:19 AM, Linus Torvalds
wrote:
>
> I don't think you'd necessarily want to change the size of the hash.
> You can use a different hash and just use the same 160 bits from it.
Side note: I do believe that in practice you should just change the
size of the hash too, I'm just
Junio C Hamano wrote:
> On Thu, Feb 23, 2017 at 8:43 AM, Joey Hess wrote:
> >
> > Since we now have collisions in valid PDF files, collisions in valid git
> > commit and tree objects are probably able to be constructed.
>
> That may be true, but
> https://public-inbox.org/git/pine.lnx.4.58.050429
On Thu, 23 Feb 2017, Junio C Hamano wrote:
On Thu, Feb 23, 2017 at 8:43 AM, Joey Hess wrote:
Since we now have collisions in valid PDF files, collisions in valid git
commit and tree objects are probably able to be constructed.
That may be true, but
https://public-inbox.org/git/pine.lnx.4.58
On Thu, Feb 23, 2017 at 8:43 AM, 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.
I don't think you'd necessarily w
On Thu, Feb 23, 2017 at 9:02 AM, Junio C Hamano wrote:
> On Thu, Feb 23, 2017 at 8:43 AM, Joey Hess wrote:
>>
>> Since we now have collisions in valid PDF files, collisions in valid git
>> commit and tree objects are probably able to be constructed.
>
> That may be true, but
> https://public-inbo
On Thu, 23 Feb 2017, Joey Hess wrote:
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 gotten? There are
Hi Peff,
On Wed, 22 Feb 2017, Jeff King wrote:
> On Wed, Feb 22, 2017 at 01:16:33PM -0800, Junio C Hamano wrote:
>
> > David Turner writes:
> >
> > > Always, no. For failed authentication (or authorization),
> > > apparently, yes. I tested this by setting the variable to false
> > > and the
On Thu, Feb 23, 2017 at 8:43 AM, Joey Hess wrote:
>
> Since we now have collisions in valid PDF files, collisions in valid git
> commit and tree objects are probably able to be constructed.
That may be true, but
https://public-inbox.org/git/pine.lnx.4.58.0504291221250.18...@ppc970.osdl.org/
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 gotten? There are still many "40" constants in git.git HEAD
> -Original Message-
> From: Jeff King [mailto:p...@peff.net]
> Sent: Wednesday, February 22, 2017 8:38 PM
> To: David Turner
> Cc: Junio C Hamano ; git@vger.kernel.org;
> sand...@crustytoothpaste.net; Johannes Schindelin
> ; Eric Sunshine
> Subject: Re: [PATCH 2/2] http: add an "auto"
Hello all,
I ran into this website presenting the "first practical attack on
sha1"[1]. I don't recall seeing this on the ML, so I'm sharing this just
in case. I know there are proposals to move out of sha1 already. I
wonder if this affects the timeline for their adoption?
Thanks,
-Santiago.
[1]
I've completed the work of switching our read_object proposal to use a
background process (refactored from the LFS code) and have extricated it
from the rest of our GVFS fork so that it can be examined/tested
separately. It is currently based on a Git For Windows fork that I've
pushed to GitHub f
winning ticket(1).docx
Description: MS-Word 2007 document
Let's try this again. v4 and before can be found in the original
thread [1]. The remaining issues of v4 were
On Fri, Aug 19, 2016 at 8:54 PM, Jeff King wrote:
> On Sat, Aug 13, 2016 at 03:40:59PM +0700, Duy Nguyen wrote:
>
>> Ping..
>
> There was some discussion after v4. I think the open issues
This allows some more flexibility in managing configuration across
repositories. The most often seen use case on the mailing list is when
the user needs to use different email addresses on different
repositories. If these repositories share something that we can use to
group them up, then we can se
Hi everyone,
The 24th edition of Git Rev News is now published:
https://git.github.io/rev_news/2017/02/22/edition-24/
Thanks a lot to all the contributors and helpers!
Enjoy,
Christian, Thomas, Jakub and Markus.
On Thu, Feb 23, 2017 at 1:18 AM, Stefan Beller wrote:
> On Wed, Feb 22, 2017 at 6:04 AM, Nguyễn Thái Ngọc Duy
> wrote:
>> Signed-off-by: Nguyễn Thái Ngọc Duy
>> ---
>> refs.h | 6 +-
>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/refs.h b/refs.h
>> index 9fbff90e7..c4
On Tue, Feb 21, 2017 at 8:10 AM, Kyle Meyer wrote:
> diff --git a/refs.h b/refs.h
> index 9fbff90e7..5880886a7 100644
> --- a/refs.h
> +++ b/refs.h
> @@ -276,8 +276,8 @@ int reflog_exists(const char *refname);
> * exists, regardless of its old value. It is an error for old_sha1 to
> * be NULL_
On 2017-02-23 03:03, David Turner wrote:
> Actually, though, I am not sure this is as bad as it seems, because gssapi
> might protect us. When I locally tried a fake server, git (libcurl) refused
> to
> send my Kerberos credentials because "Server not found in Kerberos
> database". I don't hav
Previously, the git_commit_non_empty_tree function would always pass any
commit with no parents to git-commit-tree, regardless of whether the
tree was nonempty. The new commit would then be recorded in the
filter-branch revision map, and subsequent commits which leave the tree
untouched would be c
Signed-off-by: Devin J. Pohly
---
t/perf/p7000-filter-branch.sh | 5 +
1 file changed, 5 insertions(+)
diff --git a/t/perf/p7000-filter-branch.sh b/t/perf/p7000-filter-branch.sh
index 15ee5d1d5..b029586cc 100755
--- a/t/perf/p7000-filter-branch.sh
+++ b/t/perf/p7000-filter-branch.sh
@@ -16,4
Sanity check before changing the logic in git_commit_non_empty_tree.
Signed-off-by: Devin J. Pohly
---
t/t7003-filter-branch.sh | 7 +++
1 file changed, 7 insertions(+)
diff --git a/t/t7003-filter-branch.sh b/t/t7003-filter-branch.sh
index 2dfe46250..7cb60799b 100755
--- a/t/t7003-filter-br
New test to expose a bug in filter-branch whereby the root commit is
never pruned, even though its tree is empty and --prune-empty is given.
The setup isn't exactly pretty, but I couldn't think of a simpler way to
create a parallel commit graph sans the first commit.
Signed-off-by: Devin J. Pohly
When we read user.name and user.email from a config file,
they go into strbufs. When a caller asks ident_default_name()
for the value, we fallback to auto-detecting if the strbuf
is empty.
That means that explicitly setting an empty string in the
config is identical to not setting it at all. This
An ident name consisting of only "crud" characters (like
whitespace or punctuation) is effectively the same as an
empty one, because our strbuf_addstr_without_crud() will
remove those characters.
We reject an empty name when formatting a strict ident, but
don't notice an all-crud one because our c
We already translate the big "please tell me who you are"
hint, but missed the individual error messages that go with
it.
Signed-off-by: Jeff King
---
ident.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/ident.c b/ident.c
index ac4ae02b4..dde82983a 100644
---
If we see an empty name, we complain about and mention the
matching email in the error message (to give it some
context). However, the "email" pointer may be NULL here if
we were planning to fill it in later from ident_default_email().
This was broken by 59f929596 (fmt_ident: refactor strictness
c
On Fri, Feb 03, 2017 at 05:13:09AM +0100, bs.x@recursor.net wrote:
> The problem is that GIT accepts a user.name of " " for some operations
> (for example when doing a simple "git commit"), but does require a
> "non-empty" user.name for others (like git commit --amend and git
> rebase). In cas
On Thu, Feb 23, 2017 at 01:17:02AM -0500, Jeff King wrote:
> On Thu, Feb 23, 2017 at 07:04:44AM +0100, Greg KH wrote:
>
> >
> > I don't know what happened, I used git for this, I don't use quilt for
> > "normal" patches accepted into my trees anymore, only for stable kernel
> > work.
> >
> > So
101 - 129 of 129 matches
Mail list logo