Source Mage code commit list

[Arwed von Merkatz <v.merkatz AT gmx.net>]

On Sat, May 06, 2006 at 03:40:02PM -0700, Eric Sandall wrote:
[...]
> >>> That's why we use test as main branch in git, and why I don't want a
> >>> standing devel branch.
> >>> Overall I'd say just pull whatever changes you want into devel and then
> >>> deal with any conflicts when cherry-picking them to test. Or sync the
> >>> whole libs into devel and go from there.
> >> The devel changes were done in P4 and not integrated into test. The git
> >> repo just grabbed what was in P4 at the time.
> >>
> >> I thought of that after I synced from test -> devel and then became
> >> stuck on the 'proper' method (I could cherry-pick the two commits) to
> >> bring all of devel back into test.
> >>
> >> I thought git would want an integration path between the two, which is
> >> why I synced test -> devel before trying to pull devel back to test, but
> >> perhaps I'm too used to Perforce?
> >  
> > git prefers to have a common ancestor, not sure how important that is.
> > Anyway, you have that in our case as devel is a branch of test in our
> > git repo. I haven't actually done any such integrations, but at least
> > cherry-picking won't really care much about changes in-between as long
> > as the cherry-pick applies.
> > Using a permantent devel branch as we have it right now with git,
> > merging from test to devel before doing changes in devel is probably a
> > good idea.
> > 
> 
> So the current 'proper' method is to now cherry-pick each commit (just
> two: the original change and my sync from test) individually (since
> cherry-pick only works on one at a time) back to test?
 
I really don't know as we just simply haven't done any such change yet.
It should be easy enough to script though, as long as you can give the
first of a series of commits to that directory. git log dir/ | grep
commit will give the commit ids, just need to cherry-pick those
one-by-one (I tried using git-format-patches | git-am to do it faster
but that fails if any binary files are affected).

-- 
Arwed v. Merkatz                              Source Mage GNU/Linux developer
                                                    http://www.sourcemage.org