Re: Reiser4 Upstream Git Repositories on GitHub

[Edward Shishkin <edward.shishkin@gmail.com>]

On 09/30/2016 08:56 AM, Ivan Shapovalov wrote:
> On 2016-09-28 at 12:17 +0200, Edward Shishkin wrote:
>> On 09/27/2016 11:51 PM, Ivan Shapovalov wrote:
>>> On 2016-09-27 at 23:47 +0200, Edward Shishkin wrote:
>>>> On 09/27/2016 08:36 PM, Ivan Shapovalov wrote:
>>>>> On 2016-09-27 at 16:13 +0200, Edward Shishkin wrote:
>>>>>> On 09/27/2016 04:43 AM, Ivan Shapovalov wrote:
>>>>>>> On 2016-09-27 at 00:37 +0200, Edward Shishkin wrote:
>>>>>>>> On 09/27/2016 12:05 AM, Ivan Shapovalov wrote:
>>>>>>>>> On 2016-09-24 at 22:16 +0200, Edward Shishkin wrote:
>>>>>>>>>> Hello everyone,
>>>>>>>>>>
>>>>>>>>>> I have set up the updated Namesys repositories at my
>>>>>>>>>> Github
>>>>>>>>>> page.
>>>>>>>>>> Those repositories are supposed to contain the latest
>>>>>>>>>> updates
>>>>>>>>>> in
>>>>>>>>>> the (stable) master branch and in other
>>>>>>>>>> (experimental)
>>>>>>>>>> branches
>>>>>>>>>> that
>>>>>>>>>> I'll announce.
>>>>>>>>>>
>>>>>>>>>> 1) https://github.com/edward6/reiser4
>>>>>>>>>>
>>>>>>>>>> This is a "standalone" reiser4 tree, which doesn't
>>>>>>>>>> include
>>>>>>>>>> specific
>>>>>>>>>> changes of Linux kernel needed for reiser4 port. Such
>>>>>>>>>> changes
>>>>>>>>>> can
>>>>>>>>>> be
>>>>>>>>>> found at the project's page on Sourceforge:
>>>>>>>>>> https://sourceforge.net/projects/reiser4/
>>>>>>>>>>
>>>>>>>>>> An example of work with the standalone reiser4 tree:
>>>>>>>>>>
>>>>>>>>>> . Patch the respective kernel with the latest
>>>>>>>>>> available
>>>>>>>>>> stuff
>>>>>>>>>> from
>>>>>>>>>>         Sourceforge;
>>>>>>>>>> . cd to the "fs" directory;
>>>>>>>>>> . delete the directory reiser4;
>>>>>>>>>> . instead of the deleted stuff clone the standalone
>>>>>>>>>> reiser4
>>>>>>>>>>         repository from Github;
>>>>>>>>>> . build and install as usual.
>>>>>>>>>>
>>>>>>>>>> 2) Libaal and Reiser4progs:
>>>>>>>>>>
>>>>>>>>>> https://github.com/edward6/libaal
>>>>>>>>>> https://github.com/edward6/reiser4progs
>>>>>>>>>>
>>>>>>>>>> Before building Libaal and Reiser4progs execute the
>>>>>>>>>> ./prepare
>>>>>>>>>> script,
>>>>>>>>>> which will create files needed for build process.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Edward.
>>>>>>>>> Wow, finally.
>>>>>>>>>
>>>>>>>>> Maybe we could avoid that "all changes for 10 years"
>>>>>>>>> commit?
>>>>>>>> Hi Ivan,
>>>>>>>> Sorry, don't have a time to granulate it.
>>>>>>>>
>>>>>>>>> I tried to keep track of all patches since 3.2...
>>>>>>>> There will be "all changes for 6 years" commit.
>>>>>>>> Is it much better?
>>>>>>> So well, I finished splitting off all known diffs from that
>>>>>>> big
>>>>>>> commit.
>>>>>>> Tt was 12k(+)/8k(-), now it is 7k(+)/7k(-).
>>>>>>>
>>>>>>> The updated branch is here: https://github.com/intelfx/reis
>>>>>>> er4
>>>>>>> (unfortunately, not fast-forward).
>>>>>>>
>>>>>>> Moreover, my tree has accumulated quite a few differences
>>>>>>> from
>>>>>>> your
>>>>>>> one. I've dropped trivial discrepancies (comments,
>>>>>>> formatting
>>>>>>> etc.)
>>>>>>> and put the larger ones in separate branches:
>>>>>>>
>>>>>>> 1. https://github.com/intelfx/reiser4/tree/differences/enot
>>>>>>> ty
>>>>>>>        (unsupported ioctls return -ENOTTY, not -ENOSYS)
>>>>>>>
>>>>>>> 2. https://github.com/intelfx/reiser4/tree/differences/migr
>>>>>>> atep
>>>>>>> age
>>>>>>>        (the ->migratepage() implementation, which I still do
>>>>>>> not
>>>>>>> completely
>>>>>>>         understand, but it works)
>>>>>>>
>>>>>>> 3. https://github.com/intelfx/reiser4/tree/differences/rena
>>>>>>> meat
>>>>>>> 2
>>>>>>>        (renameat2(RENAME_NOREPLACE) implementation, which
>>>>>>> you
>>>>>>> haven't
>>>>>>>         merged somewhy)
>>>>>>>
>>>>>>> 4. https://github.com/intelfx/reiser4/tree/differences/adju
>>>>>>> st-t
>>>>>>> o-3.
>>>>>>> 15
>>>>>>>        (part of porting to 3.15 which, again, you haven't
>>>>>>> merged
>>>>>>> somewhy)
>>>>>>>
>>>>>>> These branches are on top of that granular "master".
>>>>>>> Anyway, please take a look.
>>>>>> It was definitely useful work,
>>>>>> I'll look at those differences..
>>>>> Maybe you could also consider rebasing things on top of that
>>>>> extracted
>>>>> granular history?
>>>>>
>>>> Interesting idea, but I am not able to estimate
>>>> complexity of such rebasing for now.
>>>>
>>> While we do not have any forks and can afford non-fast-forward
>>> updates
>>> of master, the complexity is almost nil.
>>>
>>> To rebase your format41 branch, one can do this:
>>>
>>> git rebase --preserve-merges --onto
>>> 3c7b3c5802e20381496f641fe64b6c1573228c6e
>>> 8a896fd48ed35c7dfa0188f9b7f4cbdfd469cacb format41
>>>
>>> where 8a896fd is merge-base of format41 and master (that big
>>> commit),
>>> and 3c7b3c5 is the corresponding commit of the synthesized history.
>>>
>>> Both commits have identical file content (`git diff 8a896fd
>>> 3c7b3c5`
>>> yields empty output).
>> OK, everything went smoothly,
>> Thanks for scrupulously archiving things!
>>
>> Edward.
> In meantime, I have also generated a history of the kernel side changes
> (again, starting with 3.2). They are pretty small.
> Do I understand correctly that the kernel folks are reluctant to merge
> these ~150 lines?

They are reluctant to merge stuff, which is not used by any subsystem
of upstream kernel.

Edward.