Git repositories created and how to work with them

[Vladimir Prus]

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?

- Volodya