On Sat, 24 Oct 2009, David Brownell wrote:
> > I'm very pleased we have successfully migrated to git
> > before 0.3.
>
> Yes; though as Nico pointed out, doing some work in
> branches would be a good thing. (I'm thinking of
> checking out "stgit" myself ... )
I was a quilt user before Git. These days however I do all my stuff
with native Git branches only. I looked at StGit at some point and came
back to native Git. When you get used to it, you don't want to look
back.
Creating a new branch is easy:
git branch new_branch_name
And then:
git checkout new_branch_name
You can add new commits as usual. Then if you want to do the equivalent
of "quilt pop -a; (update repo); quilt push -a" then you can do that and
much more with "git fetch; git rebase ...". The --interactive mode to
'git rebase' is incredibly useful. No need for quilt nor stgit anymore
at that point (IMHO of course).
> During a bugfix-only RC phase, it'd be natural for
> folk to have ongoing development in branches. Then
> there would be some post-release merges of those
> branches into the mainline.
Right. And to let people have easy access to those branches, my
suggestion is for major contributors to publish those branches in the
main Git repo on sourceforge. Suffice to establish a branch namespace
such as:
oyvind/mcrmrc
oyvind/vector_catch
david/thumb2
zach/install_script
and so on. Once a branch is ready then someone simply checks out master
and merges that branch:
git checkout master
git merge foobar/perfect_feature
And at that point the branch can be deleted from the main repository.
And so on. Unlike CVS, and even SVN to a certain extent, Branches are
extremely easy to work with Git and people should not be afraid of using
them at will.
Eventually, when OpenOCD will become a project as big as the Linux
kernel ;-) then major developers could keep separate Git repositories of
their own that get pulled in the main repository. But for now I think
the above suggestion should be good enough and simple.
Nicolas
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
