Hello Max,
On Sat, 18 Dec 2010 01:39:01 +0100
Max Kellermann <m...@duempel.org> wrote:
> On 2010/12/18 01:26, Paul Sokolovsky <pmis...@gmail.com> wrote:
> > 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 ;-)
>
> As always with git, there are several ways of doing that. Here's how
> I would do it:
>
> First, "git filter-branch" may be used to get only a sub tree (such as
> src/gcc-4.4.0). That will leave only commits touching gcc.
Yeah, or just git svn import gcc subdir.
> Then use "stg uncommit"
So, is stgit still alive? They r.i.p.ed cogito, so I worry for any
other wrapper, taking into account pace with which git develops.
Anyway, my idea was that git rebase -i should be good enough for
in-repo patch maintenance (even though I have to admit I didn't try it
for that use in prolonged time).
> to convert all commits after the pristine
> import to stgit patches.
>
> Import the newest upstream gcc into a new branch.
>
> Use "stg rebase" to replace cegcc's initial gcc import with the new
Somehow it seems that you either presume, or simplify, that cegcc was
developed in linear manner, with single initial import, followed with
just cegcc-related commits. But it's not like that. There're multiple
upstream syncs/merges, cherry-picks from upstream or elsewhere
("updated to 3.15 with patches"), post-merge updates (can be part of
merge or no), etc. That's what complicates commit re-extraction. Some
parts like gcc might be not too affected; I may imagine, gcc 4.4.0
indeed was dropped once and then mostly cegcc-patched, but gcc at all
has cleaned up patchset from Pedro Alves:
http://article.gmane.org/gmane.comp.gnu.cegcc.devel/2841
But for other tools, I don't see how stgit would help without even
more work than mass c-p approach I imagined.
> upstream version, and stgit will push all the patches on top of the
> new upstream version (with lots and lots of conflicts, of course).
>
> In the end (after a few days of hard work), you'll have a branch full
> of patches, and these need to be sorted, folded, submitted.
Just to make it clear - I'm not interested in upstreaming anything. I'm
interested in making it maintainable outside of upstream. I also have
-10 free hours a day (that's why noise on ML - I can be swayed away
tomorrow for unknown period of time, so would rather leave some traces
for next session, be it mine or somebody else's) and intend cegcc for
higher-level goals than itself, so hacking on it is nuisance. But if
doing that, I try to do it in such way that result will be a cleaner
thing than before. Well, there may be some Guardian knot cuts (and I
may fail to produce something).
--
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
