Hi David, 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 > some people. Sometimes you just need to track down what actually > happened, not the convenient lie we tell ourselves is what happened.
I don't think those that a rebased branch history is a lie. Each commit will still have the original commit date (if the author did not change it). You can use that to know when the feature started to be developed. OK, you lose a way to track the parent commit for that feature branch, but on the other hand you earn something important here: the knowledge that the commits from that feature branch will apply correctly on top of the current state of the tree, without a magic merge commit fixing stuff later since some things on the tree are not exactly as they seem to be in the diff from this commit. The changes that appear in the diff from a given commit are exactly what that commit is doing. I know that this is not a poll, but I particularly prefer rebased branches/commits too. -- Rafael Antognolli http://antognolli.org/ ------------------------------------------------------------------------------ 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
