Hello, On Fri, 17 Dec 2010 08:58:49 +0100 Max Kellermann <m...@duempel.org> wrote:
> Hi, > > good to see some activity over here again. I'm a developer on the > XCSoar project, which ultimately needs mingw32ce to compile for > Windows CE targets, so this project is vital for us. Unfortunately, I > didn't have any chance to free some time to work on mingw32ce/cegcc so > far. > > I have imported the cegcc subversion trunk into a git repository (with > git-svn), just in case anybody here finds that useful: > > git://git.xcsoar.org/xcsoar/max/cegcc.git > http://git.xcsoar.org/cgit/max/cegcc.git/ Thanks! Quite useful already for revision browsing. > > It might be a good start to get more people involved quickly. Clone > it, and hack it. If nobody else steps up, maybe I would volunteer to > manage the "main" repository, and handle pull requests from you. I'd > really love to hack the code myself, if only the day had 96 hours... > > It might be a good idea to make separate git repositories for gcc, > binutils etc., to sync with the upstream projects in the long run, so > this could just be a temporary solution until some brave person > decides to start this upstream merge. Yes, to get some real boon out of it, all of gcc, binutils, mingw and w32api need to split into own repos. But what's next? Well, it's clear that cegcc commits should be "rebased" to git-managed mirror of pristine repos, but in what form - as a big flattened patch, or as sequence of original individual commits? One big flat patch is what should be output of such project IMHO, and yet if to think about upstreaming it, it should at least somehow split. In this regard, sequence of original individual commits is not much useful, and yet they represent detailed history and useful as a reference... And I have no idea how to "copy" them from an "alien" branch which mixes upstream merges and actual useful commits. Apart from manual cherry-picking each commit, of course. Or, it would be possible to produce list of all commits on branch, manually filter out merge commits from it, and then pass to some "mass cherry-pick" tool. Of course, there will be conflicts, so that tool must behave like rebase - stop on cnflict, allow to inspect, fix, or skip it, and then continue with the sequence. Well, does such mass c-p tool exist? It must be ;-) But it seems that the ideal solution is mid-way: big flat patch is too big and flat, while bothering to faithfully port commits like "Oops, I added file to wrong dir" makes little use too. So, I'm going to (subject to time constraints) make a proof of concept migration of w32api with following procedure: 1. git svn import cegcc's w32api 2. git cvs import upstream w32api (yeah, they use CVS by the end of 2010, whoa!) 3. Then, put these two imports as separate branches into one repo. They are not expected to be merged. 4. cegcc's w32api will be there for reference at fingertips, and to pull from SVN, if there will be changes (and cherry-pick them). 5. Upstream w32api will track upstream closely. 6. From it, work branch will be created. 7. One big flat patch will be produced from cegcc w32api repo and its upstream. 8. Then, it will be cleaned up based on ideas in my other today's mails. 9. Then, it will be split per some usefull, yet simple, criteria, like separate patch for each header vs build changes vs bulk .def additions. 10. Those patches will be applied one by one to work branch. 11. Regarding attribution, ChangeLog.ce will be there. Not sure how to deal with it, ideally each patch should include relevant bits from it, but that doesn't qualify as "simple". So, likely will be dropped in intact, elaboration of that can be left for later, if there ever be upstream submission. -- Best regards, Paul mailto:pmis...@gmail.com ------------------------------------------------------------------------------ Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d _______________________________________________ Cegcc-devel mailing list Cegcc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cegcc-devel
