Skip to Content.
Sympa Menu

sm-commit - Re: [SM-Commit] GIT changes to devel grimoire by Eric Sandall

sm-commit AT lists.ibiblio.org

Subject: Source Mage code commit list

List archive

Chronological Thread  
  • From: Arwed von Merkatz <v.merkatz AT gmx.net>
  • To: sm-commit AT lists.ibiblio.org
  • Subject: Re: [SM-Commit] GIT changes to devel grimoire by Eric Sandall
  • Date: Sun, 7 May 2006 00:08:45 +0200

On Sat, May 06, 2006 at 02:55:02PM -0700, Eric Sandall wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Arwed von Merkatz wrote:
> > On Sat, May 06, 2006 at 02:42:10PM -0700, Eric Sandall wrote:
> >> Arwed von Merkatz wrote:
> >>> On Sat, May 06, 2006 at 03:40:30PM -0500, Eric Sandall wrote:
> >>>> GIT changes to devel grimoire by Eric Sandall
> >>>> <sandalle AT sourcemage.org>:
> >>>>
> >>>> libs/aqbanking/BUILD | 15 ++++++---------
> >>>> libs/aqbanking/DEPENDS | 8 ++++----
> >>>> libs/aqbanking/HISTORY | 10 ++++++++++
> >>>> 3 files changed, 20 insertions(+), 13 deletions(-)
> >>>>
> >>>> New commits:
> >>>> commit 84aa8430647bdc1ceed56a6849c69bd335559b86
> >>>> Author: Eric Sandall <sandalle AT sourcemage.org>
> >>>> Commit: Eric Sandall <sandalle AT sourcemage.org>
> >>>>
> >>>> Merging changes from test (master) to devel
> >>> Why? In my working with git I came to the conclusion that a standing
> >>> devel branch is probably not a good idea, instead we should create new
> >>> branches for WIP stuff if that's possible. Does anyone know whether it's
> >>> possible with git to create a new branch in a remote repository? If not,
> >>> a standing devel branch is what we'd have to deal with, but there's
> >>> various drawbacks to that compared to 'real' feature branches.
> >> <snip>
> >>
> >> Because devel has changes that weren't integrated to test in P4 and I
> >> made changes in test via git and now need to sync test -> devel so I can
> >> then sync devel -> test (if I'm understanding correctly).
> >>
> >> I am now trying to figure out, since devel is now in sync, how to pull
> >> everything in devel (multiple changes) into test, but cherry-pick is
> >> only for a single change. I think I need to use `git merge` and list
> >> multiple remotes and use the octopus strategy, but I have not tried that
> >> yet.
> >
> > 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.

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




Archive powered by MHonArc 2.6.24.

Top of Page