Re: merging other repos into linux-2.6

["Kyle Moffett" <kyle@moffetthome.net>]

On Fri, Oct 31, 2008 at 8:57 AM, J.R. Mauro <jrm8005@gmail.com> wrote:
> On Fri, Oct 31, 2008 at 12:08 AM, Kyle Moffett <kyle@moffetthome.net> wrote:
>> Now the history of $KIDBRANCH will appear to be a series of commits
>> which add files in $SUBDIR of the parent project, without any changes
>> at all to the parent project's tree.  You can then do a merge of what
>> appears to be a normal development branch into the main repository.
>>
>> Since none of the files are even remotely referenced, there can be no
>> possible build failures (hence bisection is not broken).  You may then
>> add commits which add Kconfig options and Makefile references and
>> happily develop away.
>
> So this would keep their history but make it look like their first
> commit (years ago) happened today? Or do I misunderstand you?

Not really, since GIT will preserve the original commit date
information when doing the filtering.  Essentially it's equivalent to
taking some ancient long git branch of a project and doing a "git
rebase" onto a recent kernel.  The difference is that there is no
common ancestor and the entire contents of one are mapped onto a
subdirectory of the other.  I'm trying to figure out if this would be
a useful addition to the "git rebase" functionality (since that's
essentially what it is).

> But then if Greg thinks the history is rubbish, I doubt it will get
> imported, although I think these methods are worth experimenting with
> for the future.

Oh, I very much agree that importing a bunch of dodgy changelogs is
hardly worth it.  The biggest difference between the Linux kernel and
most other software projects is the Linux kernel has some of the best
changelogs and one of the most bisectable histories.

Greg did say he had another project he wanted to import, though, so I
figured I'd post another suggestion about how to merge the projects
histories together.

Cheers,
Kyle Moffett