[PATCH] Prefer "long" key format output when verifying pgp signatures

From: Linus Torvalds <torva...@linux-foundation.org> Date: Tue, 16 Aug 2016 13:10:24 -0700 Subject: [PATCH] Prefer "long" key format output when verifying pgp signatures Yes, gpg2 already uses the long format by default, but most distributions seem to still have "gpg"

Re: [PATCH] ls-remote: add "--diff" option to show only refs that differ

On Thu, Feb 2, 2017 at 12:03 PM, Junio C Hamano wrote: > > Most downstream folks seem to care about refs/remotes/origin/$branch > and I think in that context "git ls-remote --diff [origin]" that > compares their refs/heads/* and refs/remotes/origin/* would make > sense. Hmm.

Re: [PATCH] ls-remote: add "--diff" option to show only refs that differ

On Thu, Feb 2, 2017 at 1:05 PM, Junio C Hamano wrote: > > Another case I can think of that "--diff" would help is when you are > inspecting your own mirror (but that can be seen as a special case > of the "they have copies of yours plus their own", if you think of > your mirror

[PATCH] ls-remote: add "--diff" option to show only refs that differ

From: Linus Torvalds <torva...@linux-foundation.org> Date: Thu, 2 Feb 2017 11:37:49 -0800 Subject: [PATCH] ls-remote: add "--diff" option to show only refs that differ My main use of "git ls-remote" tends to be to check what the other end has when some pull reque

Fwd: Possibly nicer pathspec syntax?

[ Duh, I sent this just to Junio initially due to a brainfart. Here goes the list also ] Most of the time when I use pathspecs, I just use the bog-standard normal ones, and everything works wonderfully. But then occasionally I want to exclude a directory (usually "drivers/"), and it all works

Re: [PATCH 2/2] pathspec: don't error out on all-exclusionary pathspec patterns

On Wed, Feb 8, 2017 at 1:59 PM, Junio C Hamano wrote: > > Thanks. Even though the current code does not refer to the original > prefixlen after the added hunk, I'd prefer not to destroy it to > avoid future troubles, so I'll queue with a bit of tweak there, > perhaps like the

[PATCH 1/2] pathspec magic: add '^' as alias for '!'

From: Linus Torvalds <torva...@linux-foundation.org> Date: Tue, 7 Feb 2017 21:05:28 -0800 Subject: [PATCH 1/2] pathspec magic: add '^' as alias for '!' The choice of '!' for a negative pathspec ends up not only not matching what we do for revisions, it's also a horrible character for

Re: Fwd: Possibly nicer pathspec syntax?

On Tue, 7 Feb 2017, Junio C Hamano wrote: > > + // Special case alias for '!' > > /* style? */ Will fix. > I somehow do not think this is correct. I expect > > cd t && git grep -e foo -- :^perf/ > > to look into things in 't' except for things in 't/perf', but the > above

[PATCH 2/2] pathspec: don't error out on all-exclusionary pathspec patterns

From: Linus Torvalds <torva...@linux-foundation.org> Date: Tue, 7 Feb 2017 21:08:15 -0800 Subject: [PATCH 2/2] pathspec: don't error out on all-exclusionary pathspec patterns Instead of erroring out and telling the user that they should add a positive pattern that covers everything else

Re: Fwd: Possibly nicer pathspec syntax?

On Tue, Feb 7, 2017 at 6:40 PM, Mike Hommey wrote: > > As such, the default positive match should be ':/' (which is shorter and > less cumbersome than ':(top)', btw) So that's what my patch does. However, it's actually very counter-intuitive in a subdirectory. Git doesn't do

Re: Fwd: Possibly nicer pathspec syntax?

On Tue, 7 Feb 2017, Linus Torvalds wrote: > > [ Clarification from original message, since Junio asked: I didn't > actually want the semantics of '.' at all, since in a subdirectory it > limits to the current subdirectory. So I'd suggest that in the absence > of any p

Re: Fwd: Possibly nicer pathspec syntax?

On Tue, Feb 7, 2017 at 6:42 PM, Junio C Hamano wrote: > > 1. I think some commands limit their operands to cwd and some work > on the whole tree when given no pathspec. I think the "no > positive? then let's give you everything except these you > excluded" should

Re: Fwd: Possibly nicer pathspec syntax?

On Tue, Feb 7, 2017 at 7:12 PM, Junio C Hamano wrote: > > But that is not what I was talking about. Let's simplify. I'd say > for any command that acts on "everything" when pathspec is not > given, the two sets of actual paths affected by these two: > > git cmd --

Re:

On Tue, Jan 24, 2017 at 4:21 PM, Stefan Beller wrote: > > +Do not PGP sign your patch. Most likely, your maintainer or other > +people on the list would not have your PGP key and would not bother > +obtaining it anyway. I think even that could be further simplified - by just

Re: [RFC PATCH] show decorations at the end of the line

On Tue, Feb 21, 2017 at 12:11 PM, Junio C Hamano wrote: > > The updated organization smells a lot better to me ;-) So I have been using the original patch for a bit over a week now, and I have to say that I'm not sure it's the right thing to do after all. Most of the time I

Re: body-CC-comment regression

On Fri, Feb 17, 2017 at 5:16 AM, Matthieu Moy wrote: > > I mostly agree for the SoB, but why should a Cc tag have only one email? Because changing that clearly broke real and useful behavior. The "multiple email addresses" thing is bogus and wrong. Just don't do

Re: SHA1 collisions found

On Thu, Feb 23, 2017 at 3:05 PM, Jeff King wrote: > > (By the way, I don't see your version on the list, Linus, which probably > means it was eaten by the 100K filter). Ahh. I didn't even think about a size filter. Doesn't matter, your version looks fine. Linus

Re: [PATCH 1/3] add collision-detecting sha1 implementation

On Thu, Feb 23, 2017 at 4:01 PM, Jeff King wrote: > > You know, I didn't even look at the LICENSE file, since it said MIT and > had a link here. It would be trivial to copy it over, too, of course. You should do it. It's just good to be careful and clear with licenses, and the

Re: SHA1 collisions found

On Thu, Feb 23, 2017 at 11:32 AM, Jeff King wrote: > > Yeah, they're not expensive. We've discussed enabling them by default. > The sticking point is that there is old history with minor bugs which > triggers some warnings (e.g., malformed committer names), and it would > be

Re: SHA1 collisions found

On Thu, Feb 23, 2017 at 2:43 PM, Jeff King wrote: > > Yeah. I started looking at that, but the ubc check happens after the > initial expansion. Yes. That's the point where I gave up and just included their ugly sha1.c file. I suspect it can be done, but it would need somebody to

Re: SHA1 collisions found

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

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

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

Re: SHA1 collisions found

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

Re: SHA1 collisions found

On Thu, Feb 23, 2017 at 9:35 AM, Joey Hess wrote: > > Attacks using this SHA1 break will look something more like: We don't actually know what the break is, but it's likely that you can't actually do what you think you can do: > * I push a "bad" object to a repo on github I set

Re: SHA1 collisions found

On Thu, Feb 23, 2017 at 9:19 AM, Linus Torvalds <torva...@linux-foundation.org> 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 sho

Re: SHA1 collisions found

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

Re: SHA1 collisions found

On Thu, Feb 23, 2017 at 10:21 AM, Joey Hess <i...@joeyh.name> wrote: > Linus Torvalds wrote: >> What you describe pretty much already requires a pre-image attack, >> which the new attack is _not_. >> >> It's not clear that the "good" object can be a

Re: SHA1 collisions found

On Thu, Feb 23, 2017 at 10:46 AM, Jeff King wrote: >> >> So I agree with you that we need to make git check for the opaque >> data. I think I was the one who brought that whole argument up. > > We do already. I'm aware of the fsck checks, but I have to admit I wasn't aware of

Re: SHA1 collisions found

On Thu, Feb 23, 2017 at 10:10 AM, Joey Hess wrote: > > It would cost 6500 CPU years + 100 GPU years to generate valid colliding > git objects using the methods of the paper's authors. That might be cost > effective if it helped get a backdoor into eg, the kernel. I still think

Re: [RFC PATCH] show decorations at the end of the line

On Fri, Feb 17, 2017 at 9:27 PM, Junio C Hamano wrote: > > I just got bitten by a fallout. I have > > $ git recent --help > `git recent' is aliased to `log --oneline --branches --no-merges \ > --source --since=3.weeks' > > but now the branch names are shown at

Re: [RFC PATCH] show decorations at the end of the line

ations()", and show it where it used to be. Maybe this works for Junio's alias? Linus From 97abab56fed451476f6ec676346b1e66001ef864 Mon Sep 17 00:00:00 2001 From: Linus Torvalds <torva...@linux-foundation.org> Date: Sat, 11 Feb 2017 10:03:33 -0800 Subject: [PATCH] show decorations

Re: `git show --oneline commit` does not do what's intuitively expected

On Thu, Feb 16, 2017 at 8:05 PM, Jeff King wrote: > On Fri, Feb 17, 2017 at 02:51:36AM +0100, Luna Kid wrote: > >> tl;dr; --> Please add --no-diff (or --msg-only) to git show. We'll >> love you for that. :) > > I think it is already spelled "--no-patch", or "-s" for short. I think

[RFC PATCH] show decorations at the end of the line

e format for that alone, along with a comment about how it's not at the end of line. Signed-off-by: Linus Torvalds <torva...@linux-foundation.org> --- I've signed off on this, because I think it's an "obvious" improvement, but I'm putting the "RFC" in the subject line beca

Re: [RFC PATCH] show decorations at the end of the line

On Sat, Feb 11, 2017 at 10:02 AM, Linus Torvalds <torva...@linux-foundation.org> wrote: > > I've signed off on this, because I think it's an "obvious" improvement, > but I'm putting the "RFC" in the subject line because this is clearly a > subjective thing.

Re: [RFC PATCH] show decorations at the end of the line

On Mon, Feb 13, 2017 at 12:30 AM, Junio C Hamano wrote: > > An obvious downside is that people (against all recommendations) are > likely to have written a loose script expecting the --oneline format > is cast in stone. Actually, I don't believe that is the case wrt

Re: Git: new feature suggestion

On Wed, Jan 18, 2017 at 10:33 PM, Konstantin Khomoutov <kostix+...@007spb.ru> wrote: > > Still, I welcome you to read the sort-of "reference" post by Linus > Torvalds [1] in which he explains the reasoning behind this approach > implemented in Git. It's worth noting t

Re: Git: new feature suggestion

On Thu, Jan 19, 2017 at 10:54 AM, Joao Pinto wrote: > > I am currently facing some challenges in one of Linux subsystems where a > rename > of a set of folders and files would be the perfect scenario for future > development, but the suggestion is not accepted, not

Re: Git: new feature suggestion

On Thu, Jan 19, 2017 at 1:48 PM, Jakub Narębski <jna...@gmail.com> wrote: > W dniu 19.01.2017 o 19:39, Linus Torvalds pisze: >> >> You can do it in tig, but I suspect a more graphical tool might be better. > > Well, we do have "git gui blame". Does that actual

Typesafer git hash patch

So because of the whole SHA1 discussion, I started looking at what it would involve to turn unsigned char *sha1 style arguments (and various structure members) in the git source into typedef struct { ... } hash_t; hash_t *hash; The answer is that it's pretty painful - more so than I

Re: Typesafer git hash patch

On Tue, Feb 28, 2017 at 11:53 AM, Junio C Hamano <gits...@pobox.com> wrote: > Linus Torvalds <torva...@linux-foundation.org> writes: >> >> Having the hashes be more encapsulated does seem to make things better >> in many ways. What I did was to also just unify the

Re: Delta compression not so effective

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

Re: [PATCH] Put sha1dc on a diet

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

Re: [PATCH] Put sha1dc on a diet

On Wed, Mar 1, 2017 at 2:51 PM, Johannes Schindelin wrote: > > But I think bigger than just developers on Windows OS. There are many > developers out there working on large repositories (yes, much larger than > Linux). Also using Macs and Linux. I am not at all sure

[PATCH] Put sha1dc on a diet

From: Linus Torvalds <torva...@linux-foundation.org> Date: Tue, 28 Feb 2017 16:12:32 -0800 Subject: [PATCH] Put sha1dc on a diet This removes the unnecessary parts of the sha1dc code, shrinking things from [torvalds@i7 git]$ size sha1dc/*.o textdata bss

Re: SHA1 collisions found

On Tue, Feb 28, 2017 at 11:52 AM, Shawn Pearce wrote: > >> and from what I can tell, the 'maski' value is always 0, so the >> looping over 80 state masks is really just a loop over two. > > Actually, look closer at that loop: No, sorry, I wasn't clear and took some shortcuts

Re: SHA1 collisions found

On Tue, Feb 28, 2017 at 2:50 PM, Marc Stevens wrote: > > Because we only have 32 disturbance vectors to check, we have DVMASKSIZE > equal to 1 and maski always 0. > In the more general case when we add disturbance vectors this will not > remain the case. Ok, I didn't get why

Re: Typesafer git hash patch

On Tue, Feb 28, 2017 at 12:19 PM, brian m. carlson wrote: > > The bigger issue is the assumptions in the code base that assume a given > hash size. Absolutely. And I think those are going to be the "real" patches. I actually saw your status report about "After

Re: Delta compression not so effective

On Wed, Mar 1, 2017 at 5:51 AM, Marius Storm-Olsen wrote: > > When first importing, I disabled gc to avoid any repacking until completed. > When done importing, there was 209GB of all loose objects (~670k files). > With the hopes of quick consolidation, I did a > git -c

Re: [PATCH] Put sha1dc on a diet

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 >

Re: SHA1 collisions found

On Sun, Feb 26, 2017 at 9:38 AM, brian m. carlson wrote: > > SHA-256: > Common, but cryptanalysis has advanced. Preimage resistance (which is > even more important than collision resistance) has gotten to 52 of 64 > rounds. Pseudo-collision attacks are

Changing the default for "core.abbrev"?

The default value for commit abbreviation (environment.c: 19) is seven: int minimum_abbrev = 4, default_abbrev = 7; which back in the dark early days of git was fairly reasonable. It's probably still a perfectly fine default for lots of projects, since 7 hex digits is a few hundred million

Re: [PATCH 10/10] get_short_sha1: list ambiguous objects on error

On Mon, Sep 26, 2016 at 5:00 AM, Jeff King wrote: > > This patch teaches get_short_sha1() to list the sha1s of the > objects it found, along with a few bits of information that > may help the user decide which one they meant. This looks very good to me, but I wonder if it couldn't

Re: [PATCH 4/4] core.abbrev: raise the default abbreviation to 12 hexdigits

On Thu, Sep 29, 2016 at 9:10 PM, Junio C Hamano wrote: > > A quick and dirty fix for it may look like this. Crossed emails. Indeed, I just solved the builtin/rev-parse.c thing slightly differently. And you found another failure in the diff code similarly not liking the

Re: [PATCH 4/4] core.abbrev: raise the default abbreviation to 12 hexdigits

On Thu, Sep 29, 2016 at 8:54 PM, Junio C Hamano wrote: > > * The script uses "git rev-parse --short HEAD"; I suspect that it >says "ah, default_abbrev is -1 and minimum_abbrev is 4, so let's >try abbreviating to 4 hexdigits". Ahh, right you are. The logic there is

Re: [PATCH 4/4] core.abbrev: raise the default abbreviation to 12 hexdigits

On Thu, Sep 29, 2016 at 9:18 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: > > There are probably other things like that. t5510-fetch.sh fails oddly, looks like the output is off by one character. not ok 77 - fetch aligned output It has a magic "cut -c

Re: [PATCH 4/4] core.abbrev: raise the default abbreviation to 12 hexdigits

On Thu, Sep 29, 2016 at 11:05 AM, Junio C Hamano wrote: > > Yes, "git log --oneline" looks somewhat different and strange for > me, too ;-) I'm playing with an early patch to make the default more dynamic. Let's see how well it works in practice, but it looks fairly promising.

Re: [PATCH 4/4] core.abbrev: raise the default abbreviation to 12 hexdigits

On Thu, Sep 29, 2016 at 11:55 AM, Linus Torvalds <torva...@linux-foundation.org> wrote: > > For the kernel, just the *math* right now actually gives 12 > characters. For current git it actually seems to say that 8 is the > correct number. For small projects, you'll still see

Re: [PATCH 4/4] core.abbrev: raise the default abbreviation to 12 hexdigits

On Thu, Sep 29, 2016 at 12:45 PM, Junio C Hamano wrote: > > I think that is a reasonable way to go. > > #define DEFAULT_ABBREV get_default_abbrev() > > would help. So something like this that replaces the previous patch? Somebody should really double-check my heuristics, to

Re: [PATCH 4/4] core.abbrev: raise the default abbreviation to 12 hexdigits

On Thu, Sep 29, 2016 at 12:16 PM, Jeff King wrote: > > Hmm. So at length 7, we expect collisions at 2^14, which is 16384. That > seems really low. I mean, by the birthday paradox that's where expect > a 50% chance of a collision. But that's a single collision. We > definitely don't

Re: [PATCH 4/4] core.abbrev: raise the default abbreviation to 12 hexdigits

On Thu, Sep 29, 2016 at 11:37 AM, Linus Torvalds <torva...@linux-foundation.org> wrote: > > I'm playing with an early patch to make the default more dynamic. > Let's see how well it works in practice, but it looks fairly > promising. Let me test a bit more and send out

Re: [PATCH 4/4] core.abbrev: raise the default abbreviation to 12 hexdigits

On Fri, Sep 30, 2016 at 1:06 AM, Jeff King wrote: > > I agree that this deals with the performance concerns by caching the > default_abbrev_len and starting there. I still think it's unnecessarily > invasive to touch get_short_sha1() at all, which is otherwise only a > reading

Re: [PATCH 4/4] core.abbrev: raise the default abbreviation to 12 hexdigits

On Fri, Sep 30, 2016 at 10:54 AM, Linus Torvalds <torva...@linux-foundation.org> wrote: > >> So IMHO, the best combination is the init_default_abbrev() you posted in >> [1], but initialized at the top of find_unique_abbrev(). And cached >> there, obviously, in a simila

Re: [PATCH 3/3] abbrev: auto size the default abbreviation

On Mon, Oct 3, 2016 at 3:27 PM, Jeff King wrote: > > + if (len < 0) { > + unsigned long count = approximate_object_count(); > + len = (msb(count) + 1) / 2; > + if (len < 0) > + len = FALLBACK_DEFAULT_ABBREV; > +

Slow pushes on 'pu' - even when up-to-date..

This seems to be because I'm now on 'pu' as of a day or two ago in order to test the abbrev logic, but lookie here: time git ls-remote ra.kernel.org:/pub/scm/linux/kernel/git/torvalds/linux .. shows all the branches and tags .. real 0m0.655s user 0m0.011s sys 0m0.004s so the

Re: [PATCH 4/4] core.abbrev: raise the default abbreviation to 12 hexdigits

On Fri, Sep 30, 2016 at 11:40 AM, Junio C Hamano wrote: > > There is another instance buried deep in an obscure macro. A > minimum fix may look like this, but I really hope somebody else > finds a better approach. Heh. Yeah, that's just ugly. I assume this is why the odd git

Re: [PATCH 4/4] core.abbrev: raise the default abbreviation to 12 hexdigits

On Thu, Sep 29, 2016 at 5:28 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: > > To be fair, my original patch had a different worry that I didn't > bother with: what if one of the _other_ callers of "get_short_sha1()" > passed in -1 to it. I only handled

Re: [PATCH 4/4] core.abbrev: raise the default abbreviation to 12 hexdigits

On Thu, Sep 29, 2016 at 5:56 PM, Mike Hommey wrote: > > OTOH, how often does one refer to trees or blobs with abbreviated sha1s? > Most of the time, you'd use abbreviated sha1s for commits. And the number > of commits in git and the kernel repositories are much lower than the >

Re: [PATCH 4/4] core.abbrev: raise the default abbreviation to 12 hexdigits

On Thu, Sep 29, 2016 at 5:57 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: > > Actually, all the other cases seem to be "parse a SHA1 with a known > length", so they really don't have a negative length. So this seems > ok, and is easier to verify than the

Re: [PATCH 4/4] core.abbrev: raise the default abbreviation to 12 hexdigits

On Thu, Sep 29, 2016 at 4:13 PM, Junio C Hamano wrote: > > One thing that worries me is if we are ready to start accessing the > object store in all codepaths when we ask for DEFAULT_ABBREV. Yes. That was my main worry too. I also looked at just doing an explicit if

Re: [PATCH 4/4] core.abbrev: raise the default abbreviation to 12 hexdigits

On Thu, Sep 29, 2016 at 5:20 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: > > As you say, my original patch had neither of those issues. To be fair, my original patch had a different worry that I didn't bother with: what if one of the _other_ callers of "get_sho

Re: [PATCH v3 2/3] sha1_file: open window into packfiles with O_CLOEXEC

On Thu, Oct 27, 2016 at 3:24 AM, Jeff King wrote: > > +cc Linus as the original author of 144bde78e9 in case there is > something subtle I'm missing, but this really just seems like it's > an outdated optimization. I'd *really* like to keep O_NOATIME if at all possible. It made a

Re: [PATCH v3 2/3] sha1_file: open window into packfiles with O_CLOEXEC

On Fri, Oct 28, 2016 at 9:48 AM, Junio C Hamano wrote: > > Excuse me, but care to elaborate a bit more? It just seems entirely pointless to change the games with O_xyz. > Setting FD_CLOEXEC with fcntl(2) may be racy, but in what way > it is broken to open(2) with O_CLOEXEC?

Re: [PATCH v3 2/3] sha1_file: open window into packfiles with O_CLOEXEC

On Fri, Oct 28, 2016 at 4:11 AM, Johannes Schindelin wrote: > > You guys. I mean: You guys! You sure make my life hard. A brief look at > mingw.h could have answered your implicit question: So here's what you guys should do: - leave O_NOATIME damn well alone. It

Re: [PATCH v3 2/3] sha1_file: open window into packfiles with O_CLOEXEC

On Sat, Oct 29, 2016 at 1:25 AM, Johannes Schindelin wrote: > > Correct. We cannot change an open file handle's state ("FD_CLOEXEC") on > Windows, but we can ask open() to open said file handle with the correct > flag ("O_CLOEXEC", which is mapped to O_NOINHERIT on

Re: [PATCH v3 2/3] sha1_file: open window into packfiles with O_CLOEXEC

On Thu, Oct 27, 2016 at 3:56 PM, Junio C Hamano wrote: > > I also thought O_NOATIME shouldn't be an effective fcntl(2) thing, > for the reasons you stated above, when I was studying the area > because of the discussion on these patches. I was surprised to see > that

Re: [PATCH v3 2/3] sha1_file: open window into packfiles with O_CLOEXEC

On Thu, Oct 27, 2016 at 4:09 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: > > That said, now that I think about it, I should double-check: maybe > open() doesn't actually set atime at all, and we *could* do NOATIME > with SETFL after all. Checked. Yup. O_NOATIME co

Re: [PATCH v3 2/3] sha1_file: open window into packfiles with O_CLOEXEC

On Thu, Oct 27, 2016 at 4:36 PM, Junio C Hamano wrote: > > Would the best endgame shape for this function be to open with > O_NOATIME (and retry without), and then add CLOEXEC with fcntl(2) > but ignoring an error from it, I guess? That would be the closest > to what we

Allow "git shortlog" to group by committer information

boils down to "who committed it". So make git shortlog take a "-c" or "--committer" option to switch grouping to that. Signed-off-by: Linus Torvalds <torva...@linux-foundation.org> builtin/shortlog.c | 15 --- shortlog.h | 1 + 2 files ch

Re: Allow "git shortlog" to group by committer information

On Tue, Oct 11, 2016 at 12:01 PM, Jeff King wrote: > > My implementation is a little more complicated because it's also setting > things up for grouping by trailers (so you can group by "signed-off-by", > for example). I don't know if that's useful to your or not. Hmm. Maybe in

Re: Allow "git shortlog" to group by committer information

On Thu, Dec 15, 2016 at 4:19 PM, Junio C Hamano wrote: > > This fell off the radar partly because of the distractions like > "there are other attempts and other ways", and also because the > message was not a text-plain that can be reviewed inline. Let me > try to dig it up

Re: Allow "git shortlog" to group by committer information

On Thu, Dec 15, 2016 at 5:51 PM, Stephen & Linda Smith wrote: > > Why does gmail make it unnecessarily hard? I read email with the gmail web interface, which is wonderful because of the server-side searching etc. The only real downside is the weak threading, but you get used to

[PATCH 1/1] Allow "git shortlog" to group by committer information

From: Linus Torvalds <torva...@linux-foundation.org> Subject: Allow "git shortlog" to group by committer information Date: Tue, 11 Oct 2016 11:45:58 -0700 In some situations you may want to group the commits not by author, but by committer instead. For example, when I just w

Re: Allow "git shortlog" to group by committer information

Just a ping on this patch.. On Tue, Oct 11, 2016 at 11:45 AM, Linus Torvalds <torva...@linux-foundation.org> wrote: > In some situations you may want to group the commits not by author, > but by committer instead. > > For example, when I just wanted to look up what I'm still mi

Re: [PATCH v2 02/34] sequencer (rebase -i): implement the 'noop' command

On Tue, Dec 13, 2016 at 12:38 PM, Junio C Hamano wrote: > Johannes Schindelin writes: > >> +/* >> + * Note that ordering matters in this enum. Not only must it match the >> mapping >> + * below, it is also divided into several sections that matter.

Re: USE_SHA1DC is broken in pu

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

Re: USE_SHA1DC is broken in pu

On Thu, Mar 16, 2017 at 12:51 PM, Linus Torvalds <torva...@linux-foundation.org> 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

[PATCH 0/2] Re-integrate sha1dc

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

[PATCH 2/2] Integrate the sha1dc code with the git build

From: Linus Torvalds <torva...@linux-foundation.org> 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 - adj

USE_SHA1DC is broken in pu

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

Re: USE_SHA1DC is broken in pu

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

Re: USE_SHA1DC is broken in pu

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

Re: [PATCH 0/2] Re-integrate sha1dc

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.

Re: Bug in "git am" when the body starts with spaces

On Fri, Mar 31, 2017 at 5:52 PM, Linus Torvalds <torva...@linux-foundation.org> 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 attache

Bug in "git am" when the body starts with spaces

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 <torva...@linux-foundation.org> Date:

Re: Bug in "git am" when the body starts with spaces

ons". Jonathan? Linus On Fri, Mar 31, 2017 at 5:24 PM, Linus Torvalds <torva...@linux-foundation.org> 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 incorr

[PATCH] Fix 'git am' in-body header continuations

From: Linus Torvalds <torva...@linux-foundation.org> 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 i

Re: [PATCH] Put sha1dc on a diet

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

Re: Stable GnuPG interface, git should use GPGME

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 >

Re: [PATCH] Put sha1dc on a diet

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

Re: RFC: Another proposed hash function transition plan

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

<    1   2   3   4   5   6   >