I was going to make a bug-report about this funny behavior, but
decided to search the list first.
Yeah, I smiled at
Expanding reachable commits in commit graph: 139276% (870481/625), done.
when I did the "git gc --prune=now" on the kernel, and apparently
actually looked at the noise for the
[ Adding git people due to
On Sat, Aug 3, 2019 at 10:24 AM Andrew Morton wrote:
>
> Aside. I guess renames are just a wee bit dangerous. There's no
> guarantee that the file which you rename is exactly the same as the one
> which I renamed, which could result in breakage. Such as, ummm, if
> s
On Sun, May 26, 2019 at 10:53 AM Paolo Bonzini wrote:
>
> The interesting thing is that not only git will treat lightweight tags
> like, well, tags:
Yeah, that's very much by design - lightweight tags are very
comvenient for local temporary stuff where you don't want signing etc
(think automated
On Sat, Mar 16, 2019 at 1:31 PM Richard Hipp wrote:
>
> Maybe I'm doing something wrong with the fast-import stream that is
> defeating Git's attempts at delta compression
fast-import doesn't do fancy delta compression becayse that would
defeat the "fast" part of fast-import.
Just do a git r
On Thu, Mar 14, 2019 at 9:47 PM Junio C Hamano wrote:
>
> Linus Torvalds writes:
>
> > While it's true that header ordering isn't specified, there's a common
> > "canonical" order that the headers are listed in. To quote rfc822:
> > ...
>
in having some odd ordering requirement.
But git format-patch does create the email headers out in a different
order than the one recommended. When you do "git format-patch
--thread" to create the emails, the header ordering looks roughly like
this:
Message-Id:
From: Linus Torval
On Wed, Jan 9, 2019 at 9:21 AM Stefan Beller wrote:
>
> Sounds reasonable to me to have such functionality,
> as I tend to use
> git log --oneline origin/master..origin/next --no-merges |wc -l
> for such queries, which I always assume to be doing useless
> work as I'd be interested in *only* the
pe out "git
rev-list". Because "git log" does actually take the "--count"
argument, it just doesn't honor it.
This is that patch.
Linus
From e3bc5387404bcefbd86081fbc82a93fc5c9efa99 Mon Sep 17 00:00:00 2001
From: Linus Torvalds
Date: Sat, 5 Jan
On Wed, Nov 21, 2018 at 6:08 PM Stephen P. Smith wrote:
>
> Picking up someones stalled patch is one thing, picking up Linus' patch is in
> a different league.
No, I think it works the other way - my random patches are likely the
_least_ important ones, simply because I can carry them around in m
On Tue, Sep 18, 2018 at 8:18 AM Joan Daemen wrote:
>
> 3) The relatively large state in the sponge construction increases the
> generic strength against attacks when the input contains redundancy or
> has a certain form. For instance, if the input is restricted to be text in
> ASCII (such as sou
On Thu, Aug 16, 2018 at 9:50 AM Mark Nudelman
wrote:
>
> So I'm not sure what the best solution is. Linus's proposal to disable
> the line counting stuff if -X is set seems reasonable. I will look into
> that and see if there are any issues with it.
One option that I didn't try to go for - beca
On Wed, Aug 15, 2018 at 2:29 PM Ævar Arnfjörð Bjarmason
wrote:
>
> Downloading & trying versions of it locally reveals that it's as of
> version 520, not 530. The last version before 520 is 487. Presumably
> it's covered by this item in the changelog:
>
> Don't output terminal init sequence if
On Wed, Aug 15, 2018 at 2:29 PM Ævar Arnfjörð Bjarmason
wrote:
>
> FWIW they're not linked from
> http://www.greenwoodsoftware.com/less/download.html but you can just URL
> hack and see releases http://www.greenwoodsoftware.com/less/ and change
> links like http://www.greenwoodsoftware.com/less/le
Sadly, as of less-530, the behavior of "less -F" is broken enough that
I think git needs to potentially think about changing the defaults for
the pager, or people should at least be aware of it.
Older versions of less (at least up to less-487 - March 2017) do not
have this bug. There were apparen
On Fri, Aug 3, 2018 at 9:40 AM Junio C Hamano wrote:
>
> > [...]
> >> - - 20-byte NewHash checksum of all of the above.
> >> + - 20-byte SHA-256 checksum of all of the above.
> >
> > Likewise.
>
> Hmph, I've always assumed since NewHash plan was written that this
> part was not about tamper resi
On Fri, Aug 3, 2018 at 12:20 AM Jonathan Nieder wrote:
>
>
> Here I'd want to put a pile of acks, e.g.:
>
> Acked-by: Linus Torvalds
> ..
Sure, feel free to add my Ack for this.
Linus
On Tue, Jul 24, 2018 at 2:49 PM Junio C Hamano wrote:
>
> But lack of TZ does not give me enough hint about which content it
> happened. The fact that this was done late at night on weekend is
> indeed interesting, and I may not care what time it locally was for
> me, so perhaps this is an intend
On Tue, Jul 24, 2018 at 12:01 PM Edward Thomson
wrote:
>
> Switching gears, if I look at this from the perspective of the libgit2
> project, I would also prefer SHA-256 or SHA3 over blake2b. To support
> blake2b, we'd have to include - and support - that code ourselves. But
> to support SHA-256,
On Mon, Jul 23, 2018 at 5:48 AM Sitaram Chamarty wrote:
>
> I would suggest (a) hash size of 256 bits and (b) choice of any hash
> function that can produce such a hash. If people feel strongly that 256
> bits may also turn out to be too small (really?) then a choice of 256 or
> 512, but not arbi
On Sat, Jul 21, 2018 at 3:39 PM Johannes Schindelin
wrote:
>
> Do you really want to value contributors' opinion more than
> cryptographers'? I mean, that's exactly what got us into this hard-coded
> SHA-1 mess in the first place.
Don't be silly.
Other real cryptographers consider SHA256 to be a
On Wed, Jul 11, 2018 at 2:24 PM Ævar Arnfjörð Bjarmason
wrote:
>
> I think that's true for the likes of linux.git & git.git, but a lot of
> users of git say work in some corporate setting entirely or mostly in
> the same timezone.
>
> In that case, knowing if some commit whose sole message was "fi
[ Trying to come up with crazy special cases ]
On Wed, Jul 11, 2018 at 1:49 PM Linus Torvalds
wrote:
>
> But it could be anything else invalid, of course. It could be MAX_INT
> or something like that.
That might be better. A timezone of -1 isn't actually a valid
timezone, but I g
On Wed, Jul 11, 2018 at 1:34 PM Andrei Rybak wrote:
>
> > + int human_tz = -1;
>
> Is -1 an OK initial value for timezone if local_time_tzoffset returns
> negative values as well? It looks like it doesn't matter for from functional
The value was intentionally picked to *not* be a valid timezo
From: Linus Torvalds
This adds --date=human, which skips the timezone if it matches the
current time-zone, and doesn't print the whole date if that matches (ie
skip printing year for dates that are "this year", but also skip the
whole date itself if it's in the last few
On Sat, Jul 7, 2018 at 12:58 PM Linus Torvalds
wrote:
>
> I'm playing with making all "today" dates just use the relative
> format.
Here's the incremental patch for that if people want to compare the output.
With this, you never get the "just time" case, b
On Sat, Jul 7, 2018 at 12:39 PM Linus Torvalds
wrote:
> to me, but with "--date=human", right now it just says
>
> Date: 12:21
Side note: this is probably my least favorite of the formats.
I'm playing with making all "today" dates just use the relative
From: Linus Torvalds
This adds --date=human, which skips the timezone if it matches the
current time-zone, and doesn't print the whole date if that matches (ie
skip printing year for dates that are "this year", but also skip the
whole date itself if it's in the last few
On Mon, Jun 11, 2018 at 4:27 PM Ævar Arnfjörð Bjarmason
wrote:
> >
> > And no, I'm not a cryptographer. But honestly, length extension
> > attacks were how both md5 and sha1 were broken in practice, so I'm
> > just going "why would we go with a crypto choice that has that known
> > weakness? That'
On Mon, Jun 11, 2018 at 12:29 PM Jonathan Nieder wrote:
>
> Yves Orton and Linus Torvalds prefer[5] SHA3 over SHA2 because of how
> it is constructed.
Yeah, I really think that it's a mistake to switch to something that
has the same problem SHA1 had.
That doesn't necessaril
On Fri, Jun 1, 2018 at 2:04 AM Jeff King wrote:
>
> We'd also accept relative times like "5.minutes.ago" (in fact, the
> default is a relative 2.weeks.ago, though it's long enough that the
> difference between "2 weeks" and "2 weeks plus 5 minutes" may not matter
> much). So we probably ought to j
On Sat, May 26, 2018 at 4:31 PM Junio C Hamano wrote:
> *That* is something I don't do. After all, I am fully aware that I
> have started end-of-day ritual by that time, so I won't even look at
> a new patch (or a pull request for that matter).
Sounds like you're more organized about the end-of
So this is a RFC patch, I'm not sure how much people really care, but I
find the current behavior of "git gc --prune=now" to be unnecessarily
dangerous.
There's two issues with it:
(a) parse_expiry_date() considers "now" to be special, and it actually
doesn't mean "now" at all, it means
On Wed, Apr 18, 2018 at 7:16 PM, Junio C Hamano wrote:
> A few commands that parse --expire= command line option
> behaves silly when given nonsense input. For example
So this patch definitely improves on the error message.
But look at what happens for the kernel:
[torvalds@i7 linux]$ time
On Wed, Apr 18, 2018 at 6:52 PM, Junio C Hamano wrote:
>
> Regardless of your originai "git gc" issue, we should make "prune"
> say something on this error. And when we do so, I would think that
> error message will come before the final "error: failed to run
> prune".
So to me, the real failure
Ok, this is ridiculous, but I've done it several times, so I thought
I'd finally mention it to somebody on the git list that may care:
"My name is Linus, and I'm a klutz".
what does that have to do with anything?
Now, imagine you're a klutz. Imagine you want to clean up your .git
directory. Co
On Sun, Apr 15, 2018 at 6:44 PM, Junio C Hamano wrote:
>
> I think Elijah's corrected was_tracked() also does not care "has
> this been renamed".
I'm perfectly happy with the slightly smarter patches. My patch was
really just an RFC and because I had tried it out.
> One thing that makes me curio
On Fri, Apr 13, 2018 at 10:39 AM, Stefan Beller wrote:
>
> Would s/read/xread/ make sense in working_tree_matches ?
Makes sense, yes.
That patch was really more of a RFD than anything that should be applied.
I would like to see the "might be same" flag pushed down so that we
don't do this compa
On Fri, Apr 13, 2018 at 12:02 AM, Elijah Newren wrote:
>
> I hope you don't mind me barging into your conversation
I was getting tired of my own rambling anyway..
> However, it turns out we have this awesome function called
> "was_tracked(const char *path)" that was intended for answering this
>
[ Still talking to myself. Very soothing. ]
On Thu, Apr 12, 2018 at 4:55 PM, Linus Torvalds
wrote:
> [ Talking to myself ]
>
> Did it perhaps mean to say
>
> path_renamed_outside_HEAD = path2 && !strcmp(path, path2);
>
> instead?
Probably not co
[ Talking to myself ]
On Thu, Apr 12, 2018 at 4:41 PM, Linus Torvalds
wrote:
>
> Oddly, that *already* has the check:
>
> if (mfi.clean && !df_conflict_remains &&
> oid_eq(&mfi.oid, a_oid) && mfi.mode == a_mode) {
>
On Thu, Apr 12, 2018 at 4:35 PM, Linus Torvalds
wrote:
>
> in process_entry(), and I think we could just there add a test for if
> o_old,o_mod == a_oid,a_mode or something?
Actually, not process_entry, but merge_content().
Oddly, that *already* has the check:
if (
On Thu, Apr 12, 2018 at 4:17 PM, Junio C Hamano wrote:
>
> A bit of detour. "Change in side branch happened to be a subset of
> the change in trunk and gets subsumed, but we end up writing the
> same result" happens also with the simpler resolve strategy.
>
> Here is a fix.
Heh. Except git-merge
On Thu, Apr 12, 2018 at 2:46 PM, Junio C Hamano wrote:
>
> Thanks for a clear description of the issue. It does sound
> interesting.
I decided to show it with a simpler case that could be scripted and
doesn't need the kernel.
NOTE! This obviously doesn't happen for files with the trivial merge
So I just had an interesting experience that has happened before too,
but this time I decided to try to figure out *why* it happened.
I'm obviously in the latter part of the kernel merge window, and
things are slowly calming down. I do the second XFS merge during this
window, and it brings in upda
On Mon, Mar 19, 2018, 04:34 Johannes Schindelin
wrote:
>
> This is a real problem.
No it isn't.
We already handle those special cases specially, and install them in
the bin directory (as opposed to libexec). And it all works fine.
Look into the bin directory some day. You'll find things like
On Thu, Mar 15, 2018 at 10:05 AM, Johannes Schindelin
wrote:
> The most sensible thing, of course, would be to *not* link the builtins at
> all. I mean, we deprecated the dashed form (which was a design mistake,
> whether you admit it or not) a long time ago.
That's probably not a bad idea for th
On Wed, Mar 14, 2018 at 3:14 AM, Ævar Arnfjörð Bjarmason
wrote:
> On Wed, Mar 14 2018, Johannes Sixt jotted:
>>
>> It is important to leave the default at hard-linking the binaries,
>> because on Windows symbolic links are second class citizens (they
>> require special privileges and there is a di
On Wed, Feb 21, 2018 at 3:27 PM, Jeff King wrote:
>
> We'll skip the usual deprecation period because this was
> explicitly a debugging aid that was never documented.
Ack. I don't think I've used it since, and probably nobody else ever used it.
Linus
On Tue, Feb 13, 2018 at 9:18 AM, Junio C Hamano wrote:
>
> That makes me wonder if another heuristic I floated earlier is more
> appropriate. When merging a tag object T, if refs/tags/T exists and
> it is that tag object, then an updated "merge" would default to "--ff";
> otherwise, it would keep
On Mon, Feb 12, 2018 at 1:44 PM, Junio C Hamano wrote:
>
> But I wonder why "update to upstream" is merging a signed tag in the
> first place. Wouldn't downstream's "try to keep up with" pull be
> grabbing from branch tips, not tags?
I'm actually encouraging maintainers to *not* start their work
On Mon, Feb 12, 2018 at 1:15 PM, Linus Torvalds
wrote:
>
> The reasoning is to avoid losing the signature from the tag (when
> merging a signed tag, the signature gets inserted into the merge
> commit itself - use "git log --show-signature" to see them).
I think th
On Mon, Feb 12, 2018 at 1:00 PM, Stephen Rothwell wrote:
>
> Linus, this happens a bit after the merge window, so I am wondering
> about the rational of not doing a fast forward merge when merging a
> signed tag (I forget the reasoning).
The reasoning is to avoid losing the signature from the tag
This may be intentional, but if so, it's not obvious..
Back long long ago, the original "git commit" shell script got rewritten in C.
In that rewrite, removing some temporary files seems to have been left
out. At least one: .git/COMMIT_EDITMSG.
In the original commit.sh shell script, we can find
On Wed, Jan 17, 2018 at 3:52 PM, Theodore Ts'o wrote:
>
> Well, let's be fair; this is something *ext3* got wrong, and it was
> the default file system back them.
I'm pretty sure reiserfs and btrfs did too..
Linus
On Wed, Jan 17, 2018 at 3:16 PM, Ævar Arnfjörð Bjarmason
wrote:
>
> Or does overall FS activity and raw throughput (e.g. with an ISO copy)
> matter more than general FS contention?
Traditionally, yes.
Also note that none of this is about "throughput". It's about waiting
for a second or two when
On Wed, Jan 17, 2018 at 2:07 PM, Linus Torvalds
wrote:
>
> The original git design was very much to write each object file
> without any syncing, because they don't matter since a new object file
> - by definition - isn't really reachable. Then sync before writing the
>
On Wed, Jan 17, 2018 at 1:44 PM, Ævar Arnfjörð Bjarmason
wrote:
>
> I ran a small test myself on CentOS 7 (3.10) with ext4 data=ordered
> on the tests I thought might do a lot of loose object writes:
>
> $ GIT_PERF_REPEAT_COUNT=10 GIT_PERF_LARGE_REPO=~/g/linux
> GIT_PERF_MAKE_OPTS="
On Sun, Nov 19, 2017 at 7:37 PM, Junio C Hamano wrote:
>> ...
>> Which is simple. Just create a .git/hooks/prepare-commit-msg file that
>> contains
>>
>> #!/bin/sh
>> sed -i 's|ssh://gitolite.kernel.org/|git://git.kernel.org/|g' "$1"
>>
>> and make it executable, and git will do that commit m
On Mon, Oct 2, 2017 at 7:00 AM, Jason Cooper wrote:
>
> Ahhh, so if I understand you correctly, you'd prefer SHA-256 over
> SHA3-256 because it's more performant for your usecase? Well, that's a
> completely different animal that cryptographic suitability.
In almost all loads I've seen, zlib inf
On Wed, Sep 27, 2017 at 2:58 PM, Stefan Beller wrote:
>
> Linus, I assumed your sign off for the original patch. Thanks for spotting.
>
> Adding the mode change to t4016 seems like the easiest way to test it.
Looks good to me, and you don't need to give me authorship credit.
Just a "Reported-by
On Wed, Sep 27, 2017 at 1:40 PM, Stefan Beller wrote:
>
> I disagree with this analysis, as the fix you propose adds the
> new line unconditionally, i.e. this code path would be broken
> regardless of "show filename or not".
Right. Because it is what we want.
The old code (before that commit) us
Current git shows file-mode changes incorrectly in the diffstat
summary, as I just noted from a pull request I did on the kernel.
The pull request *should* have resulted in a summary like this:
...
21 files changed, 247 insertions(+), 67 deletions(-)
mode change 100644 => 100755 tools/te
On Wed, Sep 13, 2017 at 6:43 AM, demerphq wrote:
>
> SHA3 however uses a completely different design where it mixes a 1088
> bit block into a 1600 bit state, for a leverage of 2:3, and the excess
> is *preserved between each block*.
Yes. And considering that the SHA1 attack was actually predicate
command line, but normal people would obviously do "gitk --bisect"
that then does that "git rev-parse" internally and shows a UI error
box instead).
Linus
On Tue, Sep 5, 2017 at 3:03 PM, Jeff King wrote:
> On Tue, Sep 05, 2017 at 02:55:08PM -0700, Linus Torvalds
On Tue, Sep 5, 2017 at 3:03 PM, Jeff King wrote:
>
> This probably fixes it:
Yup. Thanks.
Linus
On Tue, Sep 5, 2017 at 2:50 PM, Jeff King wrote:
>
> What version of git are you running? This should be fixed by 03df567fbf
> (for_each_bisect_ref(): don't trim refnames, 2017-06-18) which is in
> v2.14.
I'm way more recent than 2.14.
I'm at commit 238e487ea ("The fifth batch post 2.14")
I just got this with
gitk --bisect
while doing some bisection on my current kernel.
It happens with "git rev-parse --bisect" too, but interestingly, "git
log --bisect" works fine.
I have not tried to figure out anything further, except that it was
introduced by commit b9c8e7f2f ("prefix_ref_
On Mon, Jun 12, 2017 at 2:10 PM, Jeff King wrote:
>
> I suspect nobody has complained because we generally encourage real
> "-0800" names when specifying zones.
That's what any sane person uses, and it's what SMTP requiries.
The timezone names are a (bad) joke. If a human can't understand them
(
On Fri, Jun 2, 2017 at 1:17 PM, demerphq wrote:
> Most hash function implementations have code like the following
> (extracted and reduced from hv_macro.h in perl.git [which only
> supports little-endian hash functions]):
Yes.
Please do *not* try to make things overly portable by adding random
m
On Thu, May 18, 2017 at 4:23 PM, Stephen Rothwell wrote:
>
> Just a reminder that if you are merging Linus' tree (or any tree
> really) via a tag, git was changed some time ago so that merging a tag
> will not do a fast forward (there is a good reason for this - I just
> can't recall it ATM).
The
On Tue, May 16, 2017 at 12:35 PM, Eric Wong wrote:
>
> Fwiw, most of the vfork preparation was already done by Brandon
> and myself a few weeks ago, and cooking in pu.
Oh, interesting. Was that done for vfork(), or is it for something
else? Some of the changes seem almost overly careful. Is this
On Tue, May 16, 2017 at 1:12 PM, Johannes Schindelin
wrote:
>>
>> I think it would be better to just
>>
>> (a) get rid of the magic strcspn() entirely
>>
>> (b) make the 'can we optimize this' test be simply just looking up
>> 'argv[0]' in $PATH
>
> What about
>
> ABC=1 my-executable my-
On Tue, May 16, 2017 at 10:23 AM, Jeff King wrote:
>
> I think the logic here would be more like:
>
> 1. During prepare_shell_cmd(), even if we optimize out the shell call,
> still prepare a fallback argv (since we can't allocate memory
> post-fork).
>
> 2. In the forked child, if we
From: Linus Torvalds
Date: Sat, 1 Apr 2017 12:14:39 -0700
Subject: [PATCH] Fix 'git am' in-body header continuations
An empty line should stop any pending in-body headers, and start the
actual body parsing.
This also modifies the original test for the in-body headers to actually
h
On Fri, Mar 31, 2017 at 5:52 PM, Linus Torvalds
wrote:
>
> The continuation logic is oddly complex, and I can't follow the logic.
> But it is completely broken in how it thinks empty lines are somehow
> "continuations".
The attached patch seems to work for me. Com
nuations".
Jonathan?
Linus
On Fri, Mar 31, 2017 at 5:24 PM, Linus Torvalds
wrote:
>
> I think the reason is that the "header continuation line" logic kicks
> in because the lines in the body start with spaces, but that's
> entirely incorrect, since
>
> (a) w
ines.
I didn't check how far back this goes, I guess I'll do that next. But
I thought I'd report it here first in case somebody else goes "ahhh".
Linus
From ad65cf7ba97ac071da1f845ec854165e7bf1efdf Mon Sep 17 00:00:00 2001
From: Linus Torvalds
Date: Fri
On Thu, Mar 23, 2017 at 9:43 AM, Johannes Schindelin
wrote:
>
> What I am saying is that this should be a more fine-grained, runtime knob.
No it really shouldn't.
> If I write out an index, I should not suffer the slowdown from detecting
> collisions.
The index case is a complete red herring.
On Thu, Mar 16, 2017 at 3:04 PM, Jeff King wrote:
>
> There are a few things I think are worth changing. The die() message
> should mention the sha1 we computed. That will be a big help if an old
> version of git tries to unknowingly push a colliding object to a newer
> version. The user will see
From: Linus Torvalds
Date: Thu, 16 Mar 2017 13:08:38 -0700
Subject: [PATCH 2/2] Integrate the sha1dc code with the git build
This adds the proper magic to actually build the sha1dc code as part of
git when USE_SHA1DC is enabled.
This includes
- adjusting the sha1dc include directives for git
On Thu, Mar 16, 2017 at 12:51 PM, Linus Torvalds
wrote:
>
> I'll send a patch on top of 'next', which already has the header file changes.
Patches sent. It all looked fairly straightforward to me, but maybe I
missed something.
Linus
I suspect the first patch will not make it to the list since it's over
100kB in size, but oh well.. Junio and Jeff will see it.
This is sent as two patches, just to have the original upstream code as a
first step, and then the second patch does the small modifications to
integrate it with git.
On Thu, Mar 16, 2017 at 12:46 PM, Junio C Hamano wrote:
>
> That's easy to answer. What we have on 'pu' is a fair game for
> wholesale replacement. That is the whole point of not merging
> topics in flux to 'next' and declaring that 'pu' will constantly
> rewind.
Ok.
I'll send a patch on top o
On Thu, Mar 16, 2017 at 12:41 PM, Jeff King wrote:
>
> Potentially we should just eject sha1dc from "pu" for the moment. It
> needs re-rolled with the most recent version of the collision library
> (and I see Marc just posted that they hit a stable point, which is
> perhaps why you're looking at i
I think there's a semantic merge error and it clashes with
f18f816cb158 ("hash.h: move SHA-1 implementation selection into a
header file").
Suggested possible merge resolution attached.
Linus
Makefile | 2 +-
hash.h | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
di
On Mon, Mar 13, 2017 at 1:12 PM, Marc Stevens wrote:
> Indeed, I've committed a fix, and a small bug fix for the new code just now.
Unrelated side note: there may be some missing dependencies in the
build infrastructure or something, because when I tried Jeff's script
that did that "test the merg
On Fri, Mar 10, 2017 at 2:00 AM, Bernhard E. Reiter
wrote:
>
> git uses an pipe-and-exec approach to running a GnuPG binary
> as writen in the documentation [1]:
>
> gpg.program
>Use this custom program instead of "gpg" found on $PATH when making
>or verifying a PGP sig
On Tue, Mar 7, 2017 at 10:57 AM, Ian Jackson
wrote:
>
> Also I think you need to specify how abbreviated object names are
> interpreted.
One option might be to not use hex for the new hash, but base64 encoding.
That would make the full size ASCII hash encoding length roughly
similar (43 base64 c
On Mon, Mar 6, 2017 at 10:39 AM, Jonathan Tan wrote:
>
> I think "nohash" can be explained in 2 points:
I do think that that was my least favorite part of the suggestion. Not
just "nohash", but all the special "hash" lines too.
I would honestly hope that the design should not be about "other
has
On Sat, Mar 4, 2017 at 12:27 AM, Marius Storm-Olsen wrote:
>
> I reran the repack with the options above (dropping the zlib=9, as you
> suggested)
>
> $ time git -c pack.threads=4 repack -a -d -F \
>--window=350 --depth=250 --window-memory=30g
>
> and ended up with
> $ du -
On Fri, Mar 3, 2017 at 5:12 PM, Jonathan Nieder wrote:
>
> This document is still in flux but I thought it best to send it out
> early to start getting feedback.
This actually looks very reasonable if you can implement it cleanly
enough. In many ways the "convert entirely to a new 256-bit hash" i
On Thu, Mar 2, 2017 at 5:50 PM, Mike Hommey wrote:
>
> What if the "object version" is a hash of the content (as opposed to
> header + content like the normal git hash)?
It doesn't actually matter for that attack.
The concept of the attack is actually fairly simple: generate a lot of
collisions
On Thu, Mar 2, 2017 at 12:43 PM, Junio C Hamano wrote:
>
> My reaction heavily depends on how that "object version" thing
> works.
>
> Would "object version" be like a truncated SHA-1 over the same data
> but with different IV or something, i.e. something that guarantees
> anybody would get the sa
On Thu, Mar 2, 2017 at 1:54 PM, Joey Hess wrote:
>
> There's a surprising result of combining iterated hash functions, that
> the combination is no more difficult to attack than the strongest hash
> function used.
Duh. I should actually have known that. I started reading the paper
and went "this
On Fri, Feb 24, 2017 at 4:39 PM, Linus Torvalds
wrote:
>
> Honestly, I think that a primary goal for a new hash implementation
> absolutely needs to be to minimize mixing.
>
> Not for security issues, but because of combinatorics. You want to
> have a model that basically reads
On Thu, Mar 2, 2017 at 10:37 AM, Jeff Hostetler wrote:
>>
>> Now, if your _file_ index is 300-400MB (and I do think we check the
>> SHA fingerprint on that even on just reading it - verify_hdr() in
>> do_read_index()), then that's going to be a somewhat noticeable hit on
>> every normal "git diff"
On Thu, Mar 2, 2017 at 6:45 AM, Johannes Schindelin
wrote:
>
> It would probably make sense to switch the index integrity check away from
> SHA-1 because we really only care about detecting bit flips there, and we
> have no need for the computational overhead of using a full-blown
> cryptographic
On Wed, Mar 1, 2017 at 11:07 AM, Jeff King wrote:
>
> So obviously the smaller object size is nice, and the diffstat is
> certainly satisfying. My only qualm would be whether this conflicts with
> the optimizations that Dan is working on (probably not conceptually, but
> textually).
Yeah. But I'l
On Wed, Mar 1, 2017 at 4:12 PM, Marius Storm-Olsen wrote:
>
> No, the list of git verify-objects in the previous post was from the bottom
> of the sorted list, so those are the largest blobs, ~249MB..
.. so with a 6GB window, you should easily sill have 20+ objects. Not
a huge window, but it shou
On Wed, Mar 1, 2017 at 12:34 PM, Jeff King wrote:
>
> I don't think that helps. The sha1 over the pack-file takes about 1.3s
> with openssl, and 5s with sha1dc. So we already know the increase there
> is only a few seconds, not a few minutes.
Yeah, I did a few statistics by adding just logging of
1 - 100 of 779 matches
Mail list logo
