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

[Yaroslav Halchenko]

summary first: indeed rebasing in _tent/* branches within private
clones should be fine in general if we setup the policy that noone
merges _tent/ branches before they get merged into integration
master/'s.  Alternatively, continuous merging of master/'s into your
_tent/ branches is fine as well if you promise to provide
human-readable summary of the changes in your _tent/* branch upon pull
request.

On Wed, 11 Aug 2010, Valentin Haenel wrote:
> 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. :)
I thought that is what I described in the original email ;-)

> > 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 know and that is how it is now

> I have no idea if you could mod the hooks from github
> repos...
yeap -- and that is what was question to nipy-devel about... the main
purpose of hooks for that repository would be to avoid human errors of
the "core developers" who are still somewhat humans ;)

> > > 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 :-)
yeap

> > 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..
yeah -- but what would be the advantage, besides saner development
history with no too many of parallel lines in the DAG? if none -- I
would simply avoid public rebases in general... I think in general it
goes along with Linus's vision on that, e.g.
http://kerneltrap.org/Linux/Git_Management

> > * 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.
or maint/0.4 if the branch is a bugfix (or may be even a new feature for
god sake) for 0.4

> 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.
> >...<
> 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.
which would be afaik the same conflicts as if he does merge PyMVPA/PyMVPA.git
which is a predecessor of M', right?  so is rebasing worth it now?

> 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.
and at the end linear history is the only advantage I see in this
case over preliminary merging of M into B, which could be without
additional pain done as many times as possible.

another advantage of rebase someone could mention -- easier way to see
all differences introduced by B, BUT I think most of the times, if not
always, it should be the same as

diff M...B

even if there were subsequent merges of M into B

> The alternative is to merge M into B, fixing the conflicts.
ha -- I guess I typed my comment above too early.  BTW -- we haven't
mentioned possible slight divergence which I've mentioned in my original
email with
" make sure that it merges fine into current HEAD before pushing "
which could be accomplished with

git merge --no-commit M
# verifying that no conflicts present
git reset --hard

> 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.
aha... I see now another (besides linear history) possible
advantage of rebase which could be summarized as 'meaningful merge
summary' in the case of present conflicts (since otherwise simple
with verification described above, merge of M could be avoided, thus B
would get merged into M and get meaningfull summary).

> 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 ;) )
yes -- it is a viable solution as well, unless M' is not yet ready to be
merged into M and developer asks pull only for B

> 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.
yes

I guess we will leave it up to you on either to continue rebasing of the
feature branch in your private clone, or keep merging M and then
providing good "human" summary to be included with the final merge into
pymvpa/master ;-)

-- 
                                  .-.
=------------------------------   /v\  ----------------------------=
Keep in touch                    // \\     (yoh@|www.)onerussian.com
Yaroslav Halchenko              /(   )\               ICQ#: 60653192
                   Linux User    ^^-^^    [175555]