Re: Migrating away from SHA-1?

On April 14, 2016 10:23:03 AM PDT, David Turner wrote: >On Wed, 2016-04-13 at 21:53 -0400, Theodore Ts'o wrote: >> On Tue, Apr 12, 2016 at 07:15:34PM -0400, David Turner wrote: >> > >> > If SHA-1 is broken (in certain ways), someone *can* replace an >> > arbitrary

Re: Migrating away from SHA-1?

On April 12, 2016 6:51:12 PM PDT, Duy Nguyen <pclo...@gmail.com> wrote: >On Wed, Apr 13, 2016 at 5:38 AM, H. Peter Anvin <h...@zytor.com> wrote: >> OK, I'm going to open this can of worms... >> >> At what point do we migrate from SHA-1? > >Brian Carlson ha

Re: Migrating away from SHA-1?

On 04/12/16 18:03, Junio C Hamano wrote: and so on. Of course trees don't have any space for this; they have a fixed-length for the hash part of each record, which is basically: NUL <20-byte-sha1> So we'd probably need a "treev2" object type that gives room for an algorithm byte (or we'd

Re: Migrating away from SHA-1?

On 04/12/16 16:00, Stefan Beller wrote: On Tue, Apr 12, 2016 at 3:38 PM, H. Peter Anvin <h...@zytor.com> wrote: OK, I'm going to open this can of worms... At what point do we migrate from SHA-1? At this point the cryptoanalysis of SHA-1 is most likely a matter of time. And I t

Migrating away from SHA-1?

OK, I'm going to open this can of worms... At what point do we migrate from SHA-1? At this point the cryptoanalysis of SHA-1 is most likely a matter of time. For existing repositories we will need to have a migration mechanism. Since we can't modify objects without completely invalidating

Re: [RFC/PATCH 1/1] format-patch: add an option to record base tree info

On 02/23/2016 01:49 PM, Eric W. Biederman wrote: > > So I could really respect a patch header line that said: > tree abcdef0123456789...0123456789abcdef > > Where the numbers where the truncated tree hash before and after a patch > was applied. That would seem to give a little bit of extra

Re: [RFC/PATCH 1/1] format-patch: add an option to record base tree info

On February 23, 2016 12:35:12 PM PST, Junio C Hamano wrote: >ebied...@xmission.com (Eric W. Biederman) writes: > >> Junio C Hamano writes: >> >>> It is valuable for a testing organization to say "We tested this >>> series on top of version X. We know it

Re: [RFC/PATCH 1/1] format-patch: add an option to record base tree info

On 02/23/16 01:17, Fengguang Wu wrote: > > However we are facing a new situation: in test robot POV, IMHO there > are values to test exactly the same tree as the patch submitter. > Otherwise the robot risks > > - false negative: failing to apply and test some patches > - false positive: sending

Re: Request: timeout option for remote operations, esp. git fetch

On 11/10/2013 12:17 PM, Eric Wong wrote: H. Peter Anvin h...@zytor.com wrote: When a remote server is unavailable or very slow, some git commands can stall out indefinitely. It would be a very good thing if remote commands -- but especially git fetch -- could be given a timeout. We've had

Re: Request: timeout option for remote operations, esp. git fetch

On 11/12/2013 09:45 AM, Junio C Hamano wrote: H. Peter Anvin h...@zytor.com writes: On 11/10/2013 12:17 PM, Eric Wong wrote: H. Peter Anvin h...@zytor.com wrote: When a remote server is unavailable or very slow, some git commands can stall out indefinitely. It would be a very good thing

Request: timeout option for remote operations, esp. git fetch

When a remote server is unavailable or very slow, some git commands can stall out indefinitely. It would be a very good thing if remote commands -- but especially git fetch -- could be given a timeout. -hpa -- To unsubscribe from this list: send the line unsubscribe git in the body of a

Re: Git-aware HTTP transport docs

Hi Shawn, You wrote a really great protocol spec for the smart HTTP protocol back in the day. It would be really great if it could be checked into the git repository (updated if need be). Someone mentioned today trying to reverse-engineer the protocol because of a lack of specs, and I was a bit

Request: git fetch --timeout

Right now, there are events which can cause git fetch to hang forever. This is really problematic in automatic use. A git fetch --timeout which would exit with a nonzero exit code if no forward progress is made would be really helpful. -hpa -- To unsubscribe from this list: send the line

Re: git am and the wrong chunk of ---

The users I am referring to generally have a --- line, rather than a scissor, between the cover text and commit. Also, there is (almost) always a From: line and subject at the top of the patch proper. Junio C Hamano gits...@pobox.com wrote: Jeff King p...@peff.net writes: If I understand

Re: git am and the wrong chunk of ---

On 08/10/2012 09:15 AM, Junio C Hamano wrote: H. Peter Anvin h...@zytor.com writes: The users I am referring to generally have a --- line, rather than a scissor, between the cover text and commit. Also, there is (almost) always a From: line and subject at the top of the patch proper. Oh

git am and the wrong chunk of ---

and it doesn't seem to solve the problem. Is there any other option which can be used to automatically process such a patch? -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line

[PATCH] git-cvsimport-script: handling of tags

This patch changes git-cvsimport-script so that it creates tag objects instead of refs to commits, and adds an option, -u, to convert underscores in branch and tag names to dots (since CVS doesn't allow dots in branches and tags.) Pullable tree at

Re: [PATCH] git-cvsimport-script: handling of tags

H. Peter Anvin wrote: This patch changes git-cvsimport-script so that it creates tag objects instead of refs to commits, and adds an option, -u, to convert underscores in branch and tag names to dots (since CVS doesn't allow dots in branches and tags.) Pullable tree at master.kernel.org

Re: [PATCH] git-cvsimport-script: handling of tags

H. Peter Anvin wrote: H. Peter Anvin wrote: This patch changes git-cvsimport-script so that it creates tag objects instead of refs to commits, and adds an option, -u, to convert underscores in branch and tag names to dots (since CVS doesn't allow dots in branches and tags.) Pullable tree

cg-update (cogito-0.13) bug: changed heads

I just found a bug in cogito-0.13, at least to the best of my understanding of the situation. Simplified, the problem looks like this: two sides, A and B, pull from repository C. The head of this pull we call 0. Now commit 1 is added to A. B pulls commit 1 from A, not though C. Later, A

Re: [PATCH] git-cvsimport-script: handling of tags

Martin Langhoff wrote: My style has always be to use tags for merges; tag the origin branch as well as before and after on the receiving branch. Do you move the tags with cvs tag -F? If that's the case, the data you need to merge is lost... otherwise, you could hack an alternative merge

Re: cg-update (cogito-0.13) bug: changed heads

Petr Baudis wrote: Dear diary, on Tue, Sep 06, 2005 at 11:01:25PM CEST, I got a letter where H. Peter Anvin [EMAIL PROTECTED] told me that... I just found a bug in cogito-0.13, at least to the best of my understanding of the situation. Simplified, the problem looks like this: two sides

Re: cg-update (cogito-0.13) bug: changed heads

H. Peter Anvin wrote: So, C surely has its head updated? Does cg-update fail silently, or does it utter anything? C has its head updated, yes. cg-update says Branches already fully merged. OK, now later in the day I could not reproduce this on another box. Either the situation

Re: [PATCH] git-cvsimport-script: handling of tags

Martin Langhoff wrote: On 9/7/05, H. Peter Anvin [EMAIL PROTECTED] wrote: This patch changes git-cvsimport-script so that it creates tag objects instead of refs to commits, and adds an option, -u, to convert underscores in branch and tag names to dots (since CVS doesn't allow dots in branches

Re: Moved files and merges

Junio C Hamano wrote: 1 / \ 0-2-3-5-7 \ / 4-6 It shouldn't matter to the merge at 7 if the 2-3 reorganization was done locally, by applying a patch, or by merging. There was another problem in my message that treated #3 specially. I did it that way primarily because I wanted to

Re: Moved files and merges

Linus Torvalds wrote: It's a totally broken model. Really. You think it solves issues, but it just creates more bugs and problems than it solves. Trust me. The whole point of git is that content is the only thing that matters, and that there isn't any other meta-data. If you break that

Re: Moved files and merges

Martin Langhoff wrote: Probably should be hacked into cg-merge. When the merge reports a file is missing, what happens? Does it leave a .rej file or anything? The error message is: MERGE ERROR: nfsmount/mount.c: Not handling case 3225ecdf8d172cda2a6ea5276af0d3edc566a0e7 - -

Re: Cloning speed comparison

Linus Torvalds wrote: On Fri, 12 Aug 2005, H. Peter Anvin wrote: Running it over ssh would be a good way to do authentication... Well, if you have ssh as an option, you don't need git-daemon any more, since the protocol that git-daemon does runs quite well over ssh on its own

Re: Cloning speed comparison

Petr Baudis wrote: In my tests, the git daemon was noticeably faster than ssh, if only because the authentication actually tends to be a big part of the overhead in small pulls. Oh. Sounds nice, are there plans to run this on kernel.org too? (So far, 90% of my GIT network activity happens

Re: Email patch - git commit?

Sam Ravnborg wrote: On Tue, Aug 02, 2005 at 03:15:19PM -0700, H. Peter Anvin wrote: Anyone have any good scripts for taking patches in email and turning them into git commits, preferrably while preserving the author information? git-applymbox seems to be what you are looking

Re: Linus kernel tree corrupt?

Petr Baudis wrote: It _is_ unsafe for individual objects, and your packfile will be corrupt if you break it in the middle and not have --whole-file turned on, I assume. It would be ideal if we could make rsync allow resuming download of the file if interrupted, but not under the final name but

Re: Linus kernel tree corrupt?

Petr Baudis wrote: Yes, please do. I deprecated rsync a day before Linus broke http-pull. It's un-deprecated again for now in the latest Cogito. Presumably for packed repos you want to drop the --ignore-existing --whole-file options I assume? Also, pulling with cogito-0.12: cg-clone -s

Re: [PATCH] write-tree performance problems

Linus Torvalds wrote: So I'll see if I can turn the current fsck into a convert into uncompressed format, and do a nice clean format conversion. Just let me know what you want to do, and I can trivially change the conversion scripts I've already written to do what you want. -hpa - To

Re: Yet another base64 patch

Linus Torvalds wrote: So why is base64 worse than the stock one? As mentioned, the flat version may be faster, but it really isn't an option. 32000 objects is peanuts. Any respectable source tree may hit that in a short time, and will break in horrible ways on many Linux filesystems. If it does,

Re: Handling renames.

Linus Torvalds wrote: On Thu, 14 Apr 2005, H. Peter Anvin wrote: Although Linus is correct in that an SCM doesn't *have* to handle this, it really feels like shooting for mediocracy to me. We might as well design it right from the beginning. No. git is not an SCM. it's a filesystem designed