Re: Embedded Linux development with GIT

[Johannes Sixt <J.Sixt@eudaptics.com>]

Sean Kelley wrote:
> 
> Hi,
> 
> I have a situation where we have a local GIT repository that is based
> on v2.6.17.  We initially added the source tarball to an empty
> repository and then started applying changes to it.  Looking back,
> that might not have been the best idea 400 commits later.
> 
> My goal is to eventually bring our repository closer to mainline
> revisions so as to make it easier to actually contribute back to the
> community.  So how can I fix my repository so as to give it visibility
> to Linus' kernel?
> 
> Here is my initial thoughts:
> 
> 1) Clone kernel.org kernel and it is Master
> 2) Create a local Head based on 2.6.17 and call it Local
> 3) Pull my existing heavily patched repository into the Local branch and merge
> 
> Is it possible then to see our 400 odd commits then in the Local
> branch on top of 2.6.17 so that we can see not only our history but
> also the history that came before?  Then as Master advances we can see
> about backporting and bringing our code close enough to mainline
> kernel to actually be able to contribute back to the community and
> submit patches.  Is this realistic approach.  I am unsure of the GIT
> commands that I need to do this?

That is possible using a graft:

  $ echo "$x $(git rev-parse v2.6.17^0)" >> .git/info/grafts

where $x is the SHA1 of the first commit you made on top of the imported
tarball. This way you have spliced your history with Linus's history.
(This is a strictly _local_ matter! Every clone of your history must
repeat the game!)

Now, Linus will not be able to pull from your faked history because he
doesn't know about the graft. In order to fix that, you can run
git-filter-branch from current git's master branch to rewrite your
history:

  $ git filter-branch new-master v2.6.17..master

Read the man page of git-filter-branch, and understand the implications
before you publish the result.

-- Hannes