On Thu, 14 Feb 2013 12:04:49 -0200 Lucas De Marchi <lucas.demar...@profusion.mobi> wrote:
> On Thu, Feb 14, 2013 at 9:12 AM, David Seikel <onef...@gmail.com> > wrote: > > On Thu, 14 Feb 2013 08:53:22 -0200 Bruno Dilly > > <bdi...@profusion.mobi> wrote: > > > >> On Wed, Feb 13, 2013 at 8:42 AM, Daniel Willmann > >> <d.willm...@samsung.com> wrote: > >> > On 13/02/13 00:36, Bruno Dilly wrote: > >> >> On Mon, Feb 11, 2013 at 2:07 PM, Daniel Willmann > >> >> <d.willm...@samsung.com> wrote: > >> >>> > >> >>> Topic branches: > >> >>> * In each repository every developer with commit access will be > >> >>> able to push/update branches in their own namespace > >> >>> (devs/<name>/*). These branches will allow non-fastforward > >> >>> updates and no one should expect these to be stable. > >> >>> * This is a testing ground for developers where new features > >> >>> can be developed, debugged and shared with fellow developers. > >> >>> Ideally any new feature would live in its own branch until it > >> >>> matures and is merged into master. > >> >> > >> >> Hey Daniel, > >> >> > >> >> It's a nice proposal, but what about master branch permissions ? > >> >> Every developer would be allowed to push stuff on there (with a > >> >> flow similar to svn) ? Or we'll try to establish some kind of > >> >> policy about it (maintainers, review, etc) ? > >> > > >> > As others have already pointed out there seems to be consensus > >> > that we don't have enough manpower to work with an integrator > >> > workflow (whether or not that's true I don't know). > >> > >> ok, I got it. > >> > >> > > >> > What I want to achieve with the topic branches is that whoever > >> > wants to can maintain an integrator-like workflow. You develop > >> > your feature in a topic branch, then post a request for > >> > review/review and test yourself and if everything looks good you > >> > can merge into master. > >> > > >> > Speaking of merging...is there any preference on merge vs. > >> > rebase? > >> > > >> > Lots of small merges can really pollute your history and I don't > >> > really like them. For larger topic branches I think merging makes > >> > sense. > >> > >> I agree with Tom here. > >> I'm always trying to keep a linear history, focusing on rebases > >> instead of merges. > >> We've used this approach on Profusion projects for years and it > >> worked fine so far. > >> > >> Maybe it will give you a little bit more work, you'll have to fix > >> conflicts in the commits it happens instead of only once in a final > >> merge commit, but it will be nicer to review or look > >> for issues later, imo. > >> > >> Using the merge approach, in a project with so many commiters could > >> lead us to a very confuse history. > > > > If the history is confused, then that's what it should show. I > > really don't like the idea of rewriting history just to make it > > easier for > > ahn?? nobody is talking about rewriting the history of the public > repository > > > some people. Sometimes you just need to track down what actually > > happened, not the convenient lie we tell ourselves is what happened. > > > > Those who don't know history are destined to repeat it. B-) > > /me confused and so seems you are. You are talking about changing a non linear history to a linear one. That removes that portion of the information in the history that concerns what branched / merged from what and when. In other words the essence of the non linearness is being removed. I have dealt with big git projects with lots of contributors and complex merges. Sometimes that info has been useful. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world.
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
