[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnu-arch-users] (no subject)
From: |
Tom Lord |
Subject: |
[Gnu-arch-users] (no subject) |
Date: |
Thu, 15 Jan 2004 15:31:21 -0800 (PST) |
In-reply-to: <address@hidden> (message from Robert Collins
on Thu, 15 Jan 2004 17:16:57 +1100)
Subject: Re: [Gnu-arch-users] please merge from
address@hidden/tla--integration--1.1
References: <address@hidden>
> Subject: please merge
No can do, pardner. You're branch commits the moral sin of BREAKING
MKPATCH.
> From: Robert Collins <address@hidden>
> This has a few goodies:
> full vim swap file support.
> safe performance enhancements on changes/commit.
> changes --link
> sha1 support.
"safe performance enhancements on changes/commit" is a nice theory but
turns out to be false. Hopefully it's only false in a trivial way. I
know I didn't spot anything when I reviewed the code by eye.
Here's what I know so far:
I've merged you up to your patch-55. That's fine.
Your patches 55-59 merge in some changes from Aaron Bentley and make
some code formatting tweaks to them:
patch-55
merge address@hidden/tlasrc--local--1.2--patch-9
patch-56
formatting fixes for address@hidden/tlasrc--local--1.2--patch-9
patch-57
merge in address@hidden/tlasrc--local--1.2--patch-10
patch-58
style fix for address@hidden/tlasrc--local--1.2--patch-10
patch-59
merge address@hidden/tlasrc--local--1.2--patch-11 (including adjustments
for conflicts)
Somewhere in there, mkpatch breaks. I haven't tracked down where yet
-- I only know that the burn-in test fails when patch complains about
getting nothing but garbage on input.
-t
- [Gnu-arch-users] (no subject),
Tom Lord <=