Re: [PATCH 2/4] XFS: Use the inode tree for finding dirty inodes

[Niv Sardi <xaiki@sgi.com>]

Russell Cattelan <cattelan@thebarn.com> writes:
> Mark Goodwin wrote:
>> Russell Cattelan wrote:
>>>> Internally, we're attempting to refine our patch acceptance processes,
>>>> (e.g. gitify our internal dev tree and mirror it on oss so it's much
>>>> easier to push back out to oss).
>>> I'm sure you have seen this before:
>>> http://oss.sgi.com/cgi-bin/gitweb.cgi?p=cattelan/xfs-import/.git;a=summary' 

moving from one SCM that is not syncable with the community to another
is not helping at all. While that clone is great to work *with* git, the
commit ids have nothing to do with the community's one, and we stil have
to convert all the work (to fixup commiter names and so forth too) to be
able to be integrated in the community.

>>> That is a running mirror of the ptools tree into git. (via the cvs tree)
>> yes. But it's git -> ptools scripts that we need, preserving
>> history, etc.
>> Niv has some scripts for this - they're not production quality yet, but
>> we're getting there. Once this transitions, it'll be a *lot* easier for
>> us to pull in patches from external developer branches because we'll all
>> be using git for checkin.
> Personally I don't see a reason to keep a ptools tree in lock step with
> with a git tree. I all for not losing history (and I spent a bit of
> time when
> the tree was re-organized to keep the rcs history in tack).
> At this point the git tree has full xfs history and I would think this would
> be sufficient for what ever code archeology  comes up.

for code archeology, we have many other trees. I'm more interested to be
able to answer things like: 'what commits have never made it to linus ?'
(dmapi, patches that had to be slightly changed) and be able to sort all
our mods in 3 categories: merged-upstream (git-patch-id equality),
partly-merged-upstream (commit title equality), unkonwn-upstream.

I have a tree here, ready to be used to replace the internal ptools
tree, it needs some more work to detect the non-merged part of the
partly-merged-upstream, but well, the diff is mostly whitespaces, and I
guess we can discard them.

Hopefully, this can be widely used RSN.

Cheers,
-- 
Niv Sardi