Re: RFC: Another proposed hash function transition plan

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

Re: Delta compression not so effective

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

Re: SHA1 collisions found

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

Re: SHA1 collisions found

On Fri, Feb 24, 2017 at 4:39 PM, Linus Torvalds <torva...@linux-foundation.org> 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 w

Re: [PATCH] Put sha1dc on a diet

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

Re: [PATCH] Put sha1dc on a diet

On Wed, Mar 1, 2017 at 10:42 AM, Junio C Hamano wrote: > I see //c99 comments sha1dc is already full of // style comments. I just followed the existing practice. > and also T array[] = { [58] = val } both of > which I think we stay away from (and the former is from the

Re: SHA1 collisions found

On Tue, Feb 28, 2017 at 11:07 AM, Junio C Hamano wrote: > > In a way similar to 8415558f55 ("sha1dc: avoid c99 > declaration-after-statement", 2017-02-24), we would want this on > top. There's a few other simplifications that could be done: (1) make the symbols static that

Re: Delta compression not so effective

On Wed, Mar 1, 2017 at 9:57 AM, Marius Storm-Olsen wrote: > > Indeed, I did do a > -c pack.threads=20 --window-memory=6g > to 'git repack', since the machine is a 20-core (40 threads) machine with > 126GB of RAM. > > So I guess with these sized objects, even at 6GB per

Re: SHA1 collisions found

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 >

Re: SHA1 collisions found

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

Re: [PATCH] Put sha1dc on a diet

On Wed, Mar 1, 2017 at 1:56 PM, Johannes Schindelin wrote: > Footnote *1*: I know, it is easy to forget that some developers cannot > choose their tools, or even their hardware. In the past, we seemed to take > appropriate care, though. I don't think you need to worry

Re: RFC: Another proposed hash function transition plan

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

Re: git rebase regression: cannot pass a shell expression directly to --exec

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

Re: git merges of tags

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 >

Re: git rebase regression: cannot pass a shell expression directly to --exec

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

Re: [TANGENT] run-command: use vfork instead of fork

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

Re: Unaligned accesses in sha1dc

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

Re: [PATCH] strbuf: let strbuf_addftime handle %z and %Z itself

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

Re: RFC v3: Another proposed hash function transition plan

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

Re: BUG: attempt to trim too many characters

On Tue, Sep 5, 2017 at 3:03 PM, Jeff King wrote: > > This probably fixes it: Yup. Thanks. Linus

BUG: attempt to trim too many characters

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

Re: BUG: attempt to trim too many characters

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

Re: BUG: attempt to trim too many characters

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 <p...@peff.net> wrote: > On Tue, Sep 05, 2017 at 02:55:08PM -0700, Linus T

diffstat summary mode change bug

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

Re: RFC v3: Another proposed hash function transition plan

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

Re: [PATCH] diff: correct newline in summary for renamed files

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

Re: diffstat summary mode change bug

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

Re: git pull

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

Re: Hash algorithm analysis

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?

Re: Hash algorithm analysis

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 necessarily

[RFC] git gc "--prune=now" semantics considered harmful

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

Re: [RFC] git gc "--prune=now" semantics considered harmful

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

Re: [RFC] git gc "--prune=now" semantics considered harmful

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

Re: [PATCH] enable core.fsyncObjectFiles by default

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 >

Re: [PATCH] enable core.fsyncObjectFiles by default

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

Re: [PATCH] enable core.fsyncObjectFiles by default

On Wed, Jan 17, 2018 at 2:07 PM, Linus Torvalds <torva...@linux-foundation.org> 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 s

Re: [PATCH] enable core.fsyncObjectFiles by default

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

Left-over COMMIT_EDITMSG file in gitdir

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

Re: linux-next: unnecessary merge in the v4l-dvb tree

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

Re: linux-next: unnecessary merge in the v4l-dvb tree

On Mon, Feb 12, 2018 at 1:15 PM, Linus Torvalds <torva...@linux-foundation.org> 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&

Re: linux-next: unnecessary merge in the v4l-dvb tree

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

Re: linux-next: unnecessary merge in the v4l-dvb tree

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

Re: [PATCH] revision: drop --show-all option

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

Re: [PATCH v2 2/2] doc hash-function-transition: pick SHA-256 as NewHash

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

Re: [PATCH v2 2/2] doc hash-function-transition: pick SHA-256 as NewHash

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

"less -F" is broken

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

Re: "less -F" is broken

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

Re: "less -F" is broken

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

Re: "less -F" is broken

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 -

Re: Hash algorithm analysis

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

Re: Hash algorithm analysis

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

Re: [RFC PATCH v2] Add 'human' date format

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

Re: Hash algorithm analysis

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

[RFC PATCH] Add 'human' date format

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 days and w

Re: [RFC PATCH] Add 'human' date format

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 f

[RFC PATCH v2] Add 'human' date format

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 days and w

Re: [RFC PATCH] Add 'human' date format

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, because tha

Re: [RFC PATCH v2] Add 'human' date format

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

Re: [RFC PATCH v2] Add 'human' date format

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

Re: [RFC PATCH v2] Add 'human' date format

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

Re: [PATCH 3/3] Makefile: optionally symlink libexec/git-core binaries to bin/git

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

Re: [PATCH 3/3] Makefile: optionally symlink libexec/git-core binaries to bin/git

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

Optimizing writes to unchanged files during merges?

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

Re: Optimizing writes to unchanged files during merges?

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

Re: Optimizing writes to unchanged files during merges?

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

Re: Optimizing writes to unchanged files during merges?

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

Re: Optimizing writes to unchanged files during merges?

On Thu, Apr 12, 2018 at 4:35 PM, Linus Torvalds <torva...@linux-foundation.org> 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

Re: Optimizing writes to unchanged files during merges?

[ Talking to myself ] On Thu, Apr 12, 2018 at 4:41 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: > > Oddly, that *already* has the check: > > if (mfi.clean && !df_conflict_remains && > oid_eq(, a_oid) &&

Re: Optimizing writes to unchanged files during merges?

[ Still talking to myself. Very soothing. ] On Thu, Apr 12, 2018 at 4:55 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: > [ Talking to myself ] > > Did it perhaps mean to say > > path_renamed_outside_HEAD = path2 && !strcmp(path, p

Re: Optimizing writes to unchanged files during merges?

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.

Re: Optimizing writes to unchanged files during merges?

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

Re: Silly "git gc" UI issue.

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:

Silly "git gc" UI issue.

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.

Re: Silly "git gc" UI issue.

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

Re: [PATCH 3/3] Makefile: optionally symlink libexec/git-core binaries to bin/git

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

Re: What's cooking in git.git (Nov 2018, #06; Wed, 21)

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

Re: Hash algorithm analysis

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

<    1   2   3   4   5   6