[oe] Old OE history

[Paul Eggleton]

On Tuesday 10 June 2014 20:19:53 Christopher Larson wrote:
> On Mon, Jun 9, 2014 at 10:34 AM, Paul Eggleton <paul.eggleton at intel.com>
> wrote:
> > Looking back through OE-Classic git commit history, the first commit (from
> > Chris) is basically an import; so it seems to me that at one point we did
> > have
> > some more history from before then. This was before my time on the
> > project so
> > I'm not sure what we had before bitkeeper (if anything).
> 
> This doesn't seem accurate to me. The first commit is
> bda361cba6cf49d92d21f44c87a9d2f13511d551, which created an initial mostly
> empty repository, which was followed by
> c11afe579262bdabdf3af8fdfcb24b3598bf0232 which added a couple initial
> recipes, etc.
> 
> At one point we used cvs, which got imported into bk, which got re-exported
> as cvs, which got imported into mtn, which got converted to git, or
> something like that, if I'm remembering correctly, anyway :) And of course
> I did some careful grafting of the earliest histories. I'm pretty sure we
> have most of the historical repositories around somewhere or another. I
> know I have copies of the bkbits repository for bitbake, the oz buildroot
> repo from various places, and  the cvs exports of the bkbits repositories.
> It is of course possible that something got lost in the translations
> between scm types along the way, but I'm not aware of anything missing
> offhand. And of course the initial repository was prior to bitbake being
> split out, the split of the early history between bitbake and openembedded
> was done by me, as carefully as I could, but iirc we still have the old
> 'oe' repository which was prior to the split.
> 
> If I dump a list of every file which has ever existed in the oe classic
> repository, and then grep out qt.*/compile.patch from that, and use git log
> on those files, you can see all the way back to the import of the initial
> qt/qte patches from the oz buildroot, and subsequent changes to it after
> that:
> 
>     git log -- (git rev-list --reverse HEAD | git diff-tree --stdin
> --no-commit-id --name-only -r | sort -u | grep 'qt.*/compile.patch')
> 
> Aside: I have 'git rev-list --reverse HEAD | git diff-tree --stdin
> --no-commit-id --name-only -r | sort -u' as a standalone git-ls-files-ever
> script. this is particularly useful when splitting git repositories up, or
> doing complete svn to git conversions, to ensure that you don't miss any
> files, as git's --follow isn't always sufficient, nor are other uses of its
> copy/move detection.

Ah, thanks for this - this works a lot better. However, I think the reason 
that I was getting confused before is that some of the patch files I'm trying 
to trace appear to start with zero size in the history, which leads git's 
rename detection with --follow down the wrong path. I'd also missed that some 
of the BK merge commits actually have useful information about the commits 
they contained; if you know what you're looking for you can match them up with 
the file(s) they refer to.

Cheers,
Paul
---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.