[pymvpa] /Developers only/ GIT repository/clones restructuring/migration

[Valentin Haenel]

* Yaroslav Halchenko <debian at onerussian.com> [100811]:
> > > alioth.debian.org (AKA git.debian.org) Will eventually be ...
> > Why don't you remove push access for anyone except the
> > core-developers?
> I am not sure if we have that much of granularity of control over it
> (everyone within pkg-exppsy project has rights atm), besides ACL at
> filesystem level which I am not fluent with or adjusting the hook
> further...  but introduced hook already should forbid most of evil
> actions (besides fast-forwarding branches and pushing new tags) so
> we should be safe.  We even thought to provide custom commit on top of
> master which removes everything and adds README describing the migration
> -- that would forbid further pushes of code, and provide proper
> referencing... but we decided to postpone such radical step for now

I know that gitolite apparently provides fine grained control over who is
allowed to push to what branch, but i have yet to use it. You could just
implement a soft policy whereby non-core developers, who are in the pkg-exppsy
group are kindly asked not to push to alioth although it would be technically
possible. I think it shouldn't be a problem. :)

> > >   No _tent branches, nor +tent tags should be pushed in there.  Only
> > >   annotated tags for upstream or distribution releases should end up
> > >   there
> > Again, the same comment as for alioth.
> That is trickier one to assure (besides that I already hardcoded in my
> .git/config only what gets pushed) since I have not got myself familiar
> yet with ways on how to provide hooks on github, please see/answer
> my question at nipy-devel:
> http://mail.scipy.org/pipermail/nipy-devel/2010-August/004455.html

In fact, unless you add collaborators to the PyMVPA/PyMVPA.git repository should be
setup like this per default. I.e. only you and Michael are allowed to push
_anything_ to it. I have no idea if you could mod the hooks from github
repos... But i wouldn't count on it.

> > >   - master branch -- development/integration branch, intended to be
> > > 	eventually pushed (thus fast-forward only) as master of
> > > 	PyMVPA/PyMVPA repository
> > What does this mean exactly? Should the branches in the developers repository
> > reflect the state of master in the PyMVPA repository?
> They should be based on it
> 
> > Can developers use their master to develop stuff in?
> yes
> 
> > Will you merge the developers masters?
> yes, upon pull request (via github system or just email)

ok. so when you merge my master branch, i can then fast forward the master
branch of my repo to the master branch of the PyMVPA/PyMVPA.git repo, i see :-)

> Also I've forgotten to mention that bugfixes for maintenance versions
> should be in _bf/ branches on top of maint/x.y, not sure but it might be
> also useful to embed maintenance version into branch name, e.g.
> _bf/0.4.5_... ?
> 
> > >   - _tent/ (tentative) feature and _bf/ (bugfix) branches which you
> > > 	would like us (or you into your master first) to integrate
> 
> > >   - +tent/ unsigned/unannotated tags to point at the locations when
> > >     your corresponding _tent/ branch got accepted (not necessary if
> > > 	feature is "minimalistic" and not worth memorizing)
> > Would you want us to rebase topic branches onto the PyMVPA master, so that
> > merges go cleanly?
> in general rebases should be avoided as soon as branch is seen publicly,

Well, that depends. Some projects specify branches that will be rebased etc...
and therefore no one should ever base any work of those branches, but only the
stable ones. We regularly rebase pushed branches in psignifit. I guess it also
depends on the number of devs, the number of users etc..

> so the flow could be
> 
> * if branch you want to be merged was not yet pushed online, please
>   rebase it against corresponding branch current HEAD, before pushing it
>   online

So rebase onto the master of the PyMVPA/PyMVPA.git repository.

> * if branch was already pushed, please do not bother with rebasing, but
>   make sure that it merges fine into current HEAD before pushing -- may
>   be even merge corresponding HEAD before pushing? what would you
>   advise?

Hmm, so you suggest merging from upstream, i.e. merge the master of the
PyMVPA/PyMVPA.git repo into developer master. I think this is whats called
criss-cross merging and is discouraged. This is a bit of a tricky subject, let
me try to explain.

we have the following situation.


PyMVPA/PyMVPA.git          developer.git

M                          M'   B
|                          |   /
|                          |  /
|                          | /

M is the PyMVPA/PyMVPA.git master, M' is the developers version of M, kind of
like a tracking branch, and B is the developer topic branch. The developer has
been writing code in B, and in the meantime some other stuff was merged into M.
A core developer fetches B, tries to merge into M, and encounters a merge
conflict.  Since the core-developer didn't write the code, has limited time,
etc... he does not wish to fix the conflict, but instead would like to delegate
the job to the developer who wrote the code in the first place.

This developer has a number of options, the recommended way of dealing with this
issue is to rebase, rebase B onto M fixing conflicts. The core-developer may now
fast-forward M to B, or alternatively, merge B into M using the flag '--no-ff' to
force a merge commit, including the nice summary of commits if merge.summary =
true. (As it should for PyMVAP). Of course rebasing allows for linear history,
in case you fancy that.

The alternative is to merge M into B, fixing the conflicts. In a distributed
setup, this requires of course that the developer make a branch reflecting
the state of M, namely M'. The core developer may then fast-forward his M to the
merge-commit that B now points to. The disadvantage is that the merge summary
contains items from M and not from B, and the commit message isn't that
meaningful. Its a merge in the wrong direction. Branches should only ever be
merged into master, and not vice versa.

One other alternative w/o rebasing is for the developer to merge B into M'
in his developer repository, and then allow the core-developer to fetch that
merge commit, and fast forward M to the state of M'. This is what i would
advise. So basically each developer repo has an extra branch pymvpa/master which
tracks the master of that developer, and can be used to communicate merge
commits to the core-developers. (however be warned, i am prone to
over-engineering, and it might be total hokum, with a much easier solution at
hand ;) )

Of course the situation is slightly more difficult if i need up-to-date changes
from pymvpa/master in my topic branch, but since the topic branch isn't ready
yet, i don't want to contaminate pymvpa/master with unfinished work.

Hope that helps.

V-