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

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

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: [PATCH] mingw: use OpenSSL's SHA-1 routines

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

Re: SHA1 collisions found

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

Re: [PATCH 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 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: 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 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 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: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: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: 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: `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

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

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

[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

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

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

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.

[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

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

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

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

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

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

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

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

[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] reset cached ident date before creating objects

On Fri, Jul 29, 2016 at 11:05 AM, Jeff King wrote: > > Linus suggested resetting the timestamp after making the commit, to > clear the way for the next commit. But if we reset any cached value > _before_ making the commit, this has a few advantages: Looks fine to me. It should

Re: Small trivial annoyance with the nice new builtin "git am"

On Thu, Jul 28, 2016 at 5:29 PM, Jeff King wrote: > > I guess we want something like: > > +void reset_ident_date(void) > +{ > + strbuf_reset(_default_date); > +} Looks sane. > and then to sprinkle calls liberally through builtin-ified programs when > they move from one unit

Re: Small trivial annoyance with the nice new builtin "git am"

On Thu, Jul 28, 2016 at 5:21 PM, Jeff King wrote: > > I do wonder if you would be happier giving each commit a "fake" > monotonically increasing time, so they are correctly ordered by commit > date. No, that would be nasty, partly for the corner case you mention, but partly

Small trivial annoyance with the nice new builtin "git am"

Ok, it's no longer *that* new, but I only now noticed.. So I noticed that when I applied the last patch-bomb series from Andrew, all the commit date-stamps are idential. Now, it would be lovely if the new builtin git-am really was *so* fast that it applies a 100+-patch series in under a second,

Re: Odd git overrflow bug?

On Sun, Jul 10, 2016 at 2:21 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: > > I'm not sure why it doesn't happen in current git master, because that > function is the same, and the logic around expand_tabs_in_log looks > similar too. Ahh. Commit 43ec55091553 (&q

Re: Odd git overrflow bug?

On Sun, Jul 10, 2016 at 2:05 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: > > I'm getting "extra" being -1 in strbuf_grow(). Let me dog deeper. "dog deeper"? My typing skills are deteriorating. Anyway, I dug deeper, and the reason is that "tabw

Re: Odd git overrflow bug?

On Sun, Jul 10, 2016 at 2:01 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: > > I'll try to figure out why git-2.9.0 fails. I'm getting "extra" being -1 in strbuf_grow(). Let me dog deeper. Linus -- To unsubscribe from this list: send the line "u

Re: Odd git overrflow bug?

On Sun, Jul 10, 2016 at 11:41 AM, Andreas Schwab wrote: > > I've seen that too, but only at the end of bisection, when it tries to > display the bad commit. That's apparently what the kernel bug reporter sees too now. However, I cannot reproduce the problem with the

Odd git overrflow bug?

We have an odd bug report in the kernel, where somebody had trouble bisecting all the way due to "git is failing with "you are trying to use to much memory"(?!)" which can't be an exact error message quote, but the closest I can find smells like the "unsigned_add_overflows()" check in the

Re: topological index field for commit objects

On Thu, Jun 30, 2016 at 3:30 AM, Jakub Narębski wrote: > > P.S. Having Git ensure that committerdate (as an epoch) is greater > than committerdates of its parents at the commit creation time (with > providing warning about time skew, perhaps not doing it if skew is > too large)

RFC: dynamic "auto" date formats

This is a throw-away idea with a simple patch attached, which I don't think anybody should really take all that seriously per se, but I thought I'd throw it out and see if it generates any discussion. I almost never use anything but the default date format (DATE_NORMAL), but every once in a while

Re: [PATCH] name-rev: include taggerdate in considering the best name

On Fri, Apr 22, 2016 at 11:11 AM, Jeff King wrote: > > I confirmed that it does find the "optimal" tag for the case we've been > discussing. Yes. I'm a bit more worried about the date behavior for projects that merge back stable branches into their development trees (is the

Re: history damage in linux.git

On Thu, Apr 21, 2016 at 12:27 PM, Junio C Hamano <gits...@pobox.com> wrote: > Linus Torvalds <torva...@linux-foundation.org> writes: > >> But this patch is small and simple, and has some excuses for its >> behavior. What do people think? > > I like it that

Re: history damage in linux.git

On Thu, Apr 21, 2016 at 11:05 AM, Jeff King wrote: > > I actually think the best name for aed06b9 is probably: > > v3.13-rc1~65^2^2~42 Sounds likely. I don't know how to find that best match without a complete rewrite, though. My recent patch that got v3.13-rc2~32^2^2~47

Re: history damage in linux.git

On Thu, Apr 21, 2016 at 10:43 AM, Linus Torvalds <torva...@linux-foundation.org> wrote: > > In other words, I'm trying to convince people that my patch not only > gives a good result, but that the "weight numbers" I use make some > kind of conceptual sense from a compl

Re: history damage in linux.git

On Thu, Apr 21, 2016 at 10:23 AM, Junio C Hamano wrote: > > I think avoiding side branches to describe with the weight is a > right thing to do, i.e. if you have this history: > > X---o---o---o---o---v4.6 > \ / > o---o > > you do not want to

Re: history damage in linux.git

On Thu, Apr 21, 2016 at 10:08 AM, Jeff King wrote: > > Right, because it makes the names longer. We give the second-parent > traversal a heuristic cost. If we drop that cost to "1", like: So I dropped it to 500 (removed the two last digits), and it gave a reasonable answer. With

Re: history damage in linux.git

On Thu, Apr 21, 2016 at 9:36 AM, Linus Torvalds <torva...@linux-foundation.org> wrote: > > This seems to be a git bug. > > That commit aed06b9 can also be described as > > v3.13-rc7~9^2~14^2~42 > > so describing it as 'v4.6-rc1~9^2~792' is clearly not closer i

Re: history damage in linux.git

On Thu, Apr 21, 2016 at 6:24 AM, Andreas Schwab wrote: > > The branches recently pulled by Linus contain commits with rather old > author dates, eg 8cad489261c564d4ee1db4de4ac365af56807d8a or > 281baf7a702693deaa45c98ef0c5161006b48257. That will probably cause git >

Re: [PATCH] merge: refuse to create too cool a merge by default

On Wed, Apr 6, 2016 at 11:36 AM, Junio C Hamano wrote: > > I was reviewing the topics to merge to 'master', and a thought > crossed my mind. Both of our series only refuse to create a merge > that does not have any common ancestor, but shouldn't the right > solution refuse to

Re: [PATCH v3 0/5] Expanding tabs in "git log" output

On Wed, Mar 23, 2016 at 4:23 PM, Junio C Hamano wrote: > So here is the third try (previous round is found at $gmane/289166 > and the very first one is at $gmane/288987). > > The first three patches are essentially the same as v2. The last > two updates how the tab-expansion

Re: [PATCH] pretty-print: de-tabify indented logs to make things line up properly

On Wed, Mar 16, 2016 at 9:29 AM, Linus Torvalds <torva...@linux-foundation.org> wrote: > > This should all line up: > > Column 1 Column 2 > > A B > ABCD EFGH > SPACESInstead of Tabs > >

Re: [PATCH] pretty-print: de-tabify indented logs to make things line up properly

On Wed, Mar 16, 2016 at 12:32 PM, Junio C Hamano wrote: > > may give us a better structure if we are going to give users a knob > to disable this tab expansion, i.e. move the addition of 4 spaces to > the caller, name the body of such a function strbuf_expand_add(), > and then

<    1   2   3   4   5   6   >