Git repositories created and how to work with them

[Milian Wolff]

Vladimir Prus, 12.05.2010:
> On Wednesday 12 May 2010 11:29:26 Andreas Pakulat wrote:
> > On 12.05.10 09:04:05, Vladimir Prus wrote:
> > > On Tuesday 04 May 2010 11:21:11 Andreas Pakulat wrote:
> > > > I've pushed all 5 repositories to gitorious.org/kdevelop (and the
> > > > project page also works now): kdevplatform, kdevelop, quanta, php,
> > > > php-docs. They're open for comitting, hence I'd like to talk a bit
> > > > about our workflow with that. (this is not set in stone of course)
> > > > 
> > > > I've created a 4.0 branch already from master, thats our stable
> > > > branch and should get all bugfix commits on it. We'll than have to
> > > > make sure that its merged once a week (or more often for important
> > > > fixes) into master so that master also gets the bugfixes. I don't
> > > > want to be responsible alone for that, so if anybody notices no
> > > > merge on sunday evening if there's been commits to 4.0 branch in the
> > > > week, please just do the merge.
> > > > 
> > > > The master branch is open for any kind of commits, but only
> > > > single-commit-change should be pushed to it directly. Everything else
> > > > should be done in a local branch and the branch then merged into
> > > > master. I'm thinking it makes sense to use --no-ff when doing the
> > > > merge so that even if a fast-forward is possible we'll get a
> > > > merge-commit.
> > > 
> > > Was there a final agreement on workflow? Reading this thread, it looks
> > > like there's a number of different opinions.
> > 
> > The last mail was the one from Niko on May 4th (20:.. pm) which I agreed
> > with and nobody commented anything afterwards. Hence I'm considering
> > the silence as agreement for myself and thus the workflow is:
> > 
> > Bugfixes to be done in the stable branch directly or as small
> > topic-branch branched off the stable branch. If the fix is important
> > (like last nights commit to help scripty), merge directly to master and
> > push both. If it can wait a day or two the merging can be done later
> > together with other fixes so we don't end up with tons of merge-commits
> > in master.
> 
> Ok, thanks.
> 
> > > Also, it's not exactly clear to me how I am supposed to arrange my
> > > working copies. Should I just clone kdevelop repository locally, or
> > > else, make gitorious clone it, and then clone gitorious clone?
> > 
> > This is what I'm planning to do for myself: Have a local clone of the
> > original repo to do bugfixes in stable branch and smaller features
> > directly in master (single-commit-stuff basically). Anything bigger gets
> > a new branch branched off of master. If I then want to share this local
> > branch with others to work on it together or just have it more widely
> > tested then I'd add a remote for a clone of the repo on gitorious and
> > push the branch to that repo. Once its ready either merge it back into
> > master and push that to the original repo,
> 
> Is there a reason why merge from topic branch to master is preferrable
> to rebase onto master -- which would create a more linear history?
> 
> > or generate a merge-request
> 
> Just to clarify -- suppose I have a local clone, and a branch in it.
> How do I generate this 'merge-request' thing?

you need a gitorious clone and once you pushed your stuff there you'll see a 
link "create review request" to the right on your clone's site.
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20100512/25007424/attachment.sig>