[pymvpa] /Developers only/ GIT repository/clones restructuring/migration
valentin.haenel at gmx.de
Thu Aug 12 10:08:44 UTC 2010
* Yaroslav Halchenko <debian at onerussian.com> :
> 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
That sounds like a good policy. Its all mostly clear now.
> On Wed, 11 Aug 2010, Valentin Haenel wrote:
> > > 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.
I like my development history as sane as possible and I agree that I may be very
pedantic ;P Since i know that no one is basing their work off my branches, i can
safely rebase them. Of course i would never rebase master ;p
> > 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?
M and M' point to the same commit, i.e. the commit with the same SHA1. The
conflicts are the same, of course. I just means that the core-developer gets
control over the merge. If i were a core-developer on a project, and someones
branch wouldn't merge cleanly, i would ask for a rebase.
> > 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.
Yes, but it introduces merge commits from upstream, something i would avoid,
boils down to personal taste, i guess.
> 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
I am not sure i understand. M...B shows all commits reachable from M and B, but
not from both.
> 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
Do you mean git merge --no-commit B, i.e. merging B into M, or the other way
round? You mean merging from upstream, i.e. pulling changes from
PyMVPA/PyMVPA.git into topic branch of developer clone?
> > 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).
yes yes ;) Avoid the upstream merges.
> > 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
In my example M' should always point to M, it points to the same place in the
DAG as the master of the PyMVPA/PyMVPA.git repository.
Of course the whole rebase or merge issue only applies _if_ there would be merge
conflicts, so i guess most of the time everything will be without problems
> > 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.
> 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 ;-)
Choice is always best :-)
More information about the Pkg-ExpPsy-PyMVPA