[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5595C067.1030308@landley.net>
Date: Thu, 02 Jul 2015 17:51:19 -0500
From: Rob Landley <rob@...dley.net>
To: "Maciej W. Rozycki" <macro@...ux-mips.org>
CC: Geert Uytterhoeven <geert@...ux-m68k.org>,
Rich Felker <dalias@...c.org>,
Andreas Schwab <schwab@...ux-m68k.org>, musl@...ts.openwall.com,
libc-alpha@...rceware.org, Linux-sh list <linux-sh@...r.kernel.org>
Subject: Re: Re: SH sigcontext ABI is broken
On 07/02/2015 02:23 PM, Maciej W. Rozycki wrote:
> On Sat, 20 Jun 2015, Rob Landley wrote:
>
>>>>>> Thanks, but most of the links seem to be broken.
>>>>>
>>>>> Are they? I'm only seeing a single broken link, which has a mirror.
>>>>
>>>> My bad. Indeed only the davej one is broken, but that's where the code
>>>> must have been introduced (even the earliest commit in tglx
>>>> history.git has the #ifdef __SH4__ for FPU regs) and I can't find a
>>>> cgit interface to it. Fetching several GB to browse history locally is
>>>> going to take a while if I have to do that..
>>>
>>> Using web interfaces for archeology doesn't fly.
>>> If you're doing serious Linux work, you should already have a git repository
>>> of the kernel. full-history-linux.git.tar weights in at only ca. 0.5 giB.
>>
>> I have a somewhat updated version of that at
>> http://landley.net/kdocs/local/linux-fullhist.tar.bz2 which I should
>> probably update for the 4.0 release. (It's pulled to 3.0 currently.)
>
> For the record the LMO tree <git://git.linux-mips.org/pub/scm/ralf/linux>
> has a full history recorded and is in sync with kernel.org. There's some
> GIT magic that cuts some operations like `git log' at 2.6.12-rc2, but you
> can go beyond that if you know the right commit id, e.g.:
>
> $ git log -p 66f0a432 -- arch/sh
>
> I can see the initial SH import was with 2.3.19.
If you grab the above tarball, git checkout -f, and git pull, operations
like git log work just fine all the way back to 0.0.1.
The problem is that each git commit hash includes metadata that
describes the parents, so if you retroactively insert parent commits you
change the hash ID of every single descendant.
You can add extra metadata nodes that glue commits together, but "git
clone" won't always look for that extra metadata when working out what
constitutes the branch of the tree you asked for.
I just found something that worked and stopped fiddling with it. The guy
who did it used "git graft" ala http://www.padator.org/linux.php
And apparently you're supposed to use "subtree" commands instead these
days (as opposed to "splice" which may or may not have anything to do
with graft?):
https://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html
Because it just wouldn't be git if there weren't 3 subtly different ways
to do the same thing. (And this is ignore the actual history rewriting
packages people made which _do_ change the sha1sums.)
In any case, the tag list only goes back to 2.6.12-rc2. I never went
back and tagged the earlier commits when I put my tree up on
kernel.org/doc back when 3.0 came out.
Rob
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
