* Yaroslav Halchenko <deb...@onerussian.com> [100812]: > 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.
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. > http://kerneltrap.org/Linux/Git_Management 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 anyway. > > 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 ;-) Choice is always best :-) V- _______________________________________________ Pkg-ExpPsy-PyMVPA mailing list Pkg-ExpPsy-PyMVPA@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-exppsy-pymvpa
