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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 - -
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
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
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
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
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
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
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,
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
35 matches
Mail list logo