On Fri, 2013-01-04 at 00:40 +0100, foobar wrote: […] > Let's clarify a bunch of things here: > 1. There is no overhead with maintaining many feature brunches.
Which is why Git is superior to Mercurial for the sort of process going on here. > 2. Feature branches can be safely removed after their contents > have been merged. This is useful for avoiding clutter. See above :-) > 3. There is no need to re-review the _same_ code on each branch > it is merged to. That's just plain stupid. I am not so sure on this. A changeset in a different context is a different changeset, which is why Mercurial is the way it is and why it has some benefits overf Git. The effect of a code change in one branch is not necessarily the same as the effect of the same change in a different branch. However review is not the right tool here, CI is. Each and every branch in the mainline must have a CI listener that runs all the code on every commit. Branches in the mainline are CVCS thinking, not wrong, but must be treated as an integral part of the project, hence the CI requirement. Branches held in forks of the mainline have no such requirement, but people should run all the tests after each commit as a matter of professionalism. Others can of course pull these feature branches into their own fork repository for working on. This is the DVCS way. Eventually of course commit to the mainline is required otherwise a project fork has been made. > 4. Chery picking is a HORRIBLE idea for managing releases and > should only be used on development. Chery-picking COPIES commits > and thus loses the connections in the history graph. Agreed. > 5. There is no problem developing bug_fixes on separate topic > branches. See 1 above. Git makes this trivially easy. > 6. There is no problem merging back to master. See 1 above. Git makes this trivially easy. > 7. Let me say this again. Merges are cheap and easy in git. So > are re-merges. Avoiding merges is an artifact of client-server > designs such as SVN and is NOT compatible with Git's conceptual > model. It is important to note that Mercurial has different properties again, so leads to different workflow. Given the choice has been Git then Git workflows apply. Every developer should be keeping master as a mirror of the mainline master and working on feature branches. When a changeset is accepted after review, the committer commits to the mainline and then everyone can pull and garbage collect, and in the process delete the feature branch they have. I tend to fork the mainline repository locally and also on GitHub and then manually link my two forks. This means "git pull" locally pulls all branches from the mainline repository. I work on feature branches pushed to my GitHub fork, people can then pull them as they wish. You have to remember to fetch from all the remote branches you are tracking. I can then make a pull request on my GitHub fork and still continue to track the mainline locally. > I suggest to read about how git works and how best to utilize its > features, and NOT apply common wisdom from CVS/SVN/RCS which are > based on a _completely different_ conceptual model. Indeed. Star model has a role in DVCS, the mainline repository is the mainline from which all else stems. But not all traffic has to be routed through it with Git. People can share feature branches between themselves to collaborate to create a pull request without ever having to use the mainline. That is the whole point. It means that the mainline committer role is not to do all the development work, but is to coordinate and mentor activity which they then review and when happy merge into mainline. No-one should ever be doing development on master. No-one should ever push to mainline without someone at least knowing they are about to do it and have previously checked the work. No mainline repository should ever be without a full CI. http://d.puremagic.com/test-results/ Looks like part of a solution. It should also provides artefacts for download and install as nightly releases. It assumes there is only master in the repository. If there are any other branches in the mainline repository then where are the CIs for those? In my clone of DMD I see master, staging, dmd-1.x branches. Given DMD is a single branch development, I don't see a need for staging. I shall have to go through all the email to find the rationale, unless someone has a short paragraph rationale. What I find really bizarre is that the tags v2.061 and v1.076 are on branches other than master. To me the whole Git history looks a mess, essentially broken. I suggest some serious rebasing and merging to make the history consistent with the version numbering. The questions to ask: If I want to create a feature branch, which branch do I use as a base? Is staging just the 2.x maintenance branch? When do changes on master make it to staging? Should staging and dmd-1.x branch HEADS be moved forwards on the branch? Sorry if this is all answered somewhere, just point me at the URL where the answers are explained. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part