Re: [E-devel] SVN-Git Migration (was: (no subject))
On Sat, Feb 16, 2013 at 4:42 AM, Jérôme Pinot ngc...@gmail.com wrote: On 02/16/13 15:58, David Seikel wrote: On Fri, 15 Feb 2013 11:56:06 -0200 Rafael Antognolli antogno...@gmail.com wrote: 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. It is a lie, it's changing the history to say it was all done one after the other, when in fact a major feature of distributed development was used to branch then merge. It was not done in a linear fashion, thus making it be linear after the fact is not representing the truth. Sure SOME parts of the commit history are still the truth, but not all. 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. That's what I'm saying, loosing information to make things more convenient. I'd prefer to err on the side of not loosing information. But then again, I'm a hoarder. B-) I know that this is not a poll, but I particularly prefer rebased branches/commits too. LWN has a neat article about the git rebase thing: http://lwn.net/Articles/328436/ Thou Shalt Not Rebase Trees With History Visible To Others Hey Jérôme, Just to make things clear, nobody is suggesting to rebase master branch (or any public branch). Only devs/* will accept non-fastforward updates. But nobody else should be based on these. -- Jérôme Pinot http://ngc891.blogdns.net/ -- The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials, tech docs,
Re: [E-devel] SVN-Git Migration (was: (no subject))
By the way, Daniel, Could it possible to make git mail title messages to be more meaningful? i.e) [core/efl] xxxmaster updated. f27ff2fbf31a01c2f8d98e773bed6cc4298749bd - [core/efl/evas] xxxmaster updated. f27ff2fbf31a01c2f8d98e773bed6cc4298749bd If the title shows any detailed core lib name that was changed, it would be better to know what is changed in abstractly. -Regards, Hermet- -Original Message- From: David Seikelonef...@gmail.com To: enlightenment-devel@lists.sourceforge.net; Cc: Sent: 2013-02-16 (토) 16:19:58 Subject: Re: [E-devel] SVN-Git Migration (was: (no subject)) On Sat, 16 Feb 2013 15:42:46 +0900 Jérôme Pinot ngc891@gmail.com wrote: On 02/16/13 15:58, David Seikel wrote: On Fri, 15 Feb 2013 11:56:06 -0200 Rafael Antognolli antognolli@gmail.com wrote: Hi David, On Thu, Feb 14, 2013 at 9:12 AM, David Seikel onefang@gmail.com wrote: On Thu, 14 Feb 2013 08:53:22 -0200 Bruno Dilly bdilly@profusion.mobi wrote: On Wed, Feb 13, 2013 at 8:42 AM, Daniel Willmann d.willmann@samsung.com wrote: On 13/02/13 00:36, Bruno Dilly wrote: On Mon, Feb 11, 2013 at 2:07 PM, Daniel Willmann d.willmann@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. It is a lie, it's changing the history to say it was all done one after the other, when in fact a major feature of distributed development was used to branch then merge. It was not done in a linear fashion, thus making it be linear after the fact is not representing the truth. Sure SOME parts of the commit history are still the truth, but not all. 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. That's what I'm saying, loosing information to make things more convenient. I'd prefer to err on the side of not loosing information. But then again, I'm a hoarder. B-) I know that this is not a poll, but I particularly prefer rebased
Re: [E-devel] SVN-Git Migration (was: (no subject))
And it'll be great if the title includes the first line of commit message. That should be way more useful. Thanks. Daniel Juyung Seo (SeoZ) On Mon, Feb 18, 2013 at 10:14 AM, ChunEon Park her...@naver.com wrote: By the way, Daniel, Could it possible to make git mail title messages to be more meaningful? i.e) [core/efl] xxxmaster updated. f27ff2fbf31a01c2f8d98e773bed6cc4298749bd - [core/efl/evas] xxxmaster updated. f27ff2fbf31a01c2f8d98e773bed6cc4298749bd If the title shows any detailed core lib name that was changed, it would be better to know what is changed in abstractly. -Regards, Hermet- -Original Message- From: David Seikelonef...@gmail.com To: enlightenment-devel@lists.sourceforge.net; Cc: Sent: 2013-02-16 (토) 16:19:58 Subject: Re: [E-devel] SVN-Git Migration (was: (no subject)) On Sat, 16 Feb 2013 15:42:46 +0900 Jérôme Pinot ngc891@gmail.com wrote: On 02/16/13 15:58, David Seikel wrote: On Fri, 15 Feb 2013 11:56:06 -0200 Rafael Antognolli antognolli@gmail.com wrote: Hi David, On Thu, Feb 14, 2013 at 9:12 AM, David Seikel onefang@gmail.com wrote: On Thu, 14 Feb 2013 08:53:22 -0200 Bruno Dilly bdilly@profusion.mobi wrote: On Wed, Feb 13, 2013 at 8:42 AM, Daniel Willmann d.willmann@samsung.com wrote: On 13/02/13 00:36, Bruno Dilly wrote: On Mon, Feb 11, 2013 at 2:07 PM, Daniel Willmann d.willmann@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. It is a lie, it's changing the history to say it was all done one after the other, when in fact a major feature of distributed development was used to branch then merge. It was not done in a linear fashion, thus making it be linear after the fact is not representing the truth. Sure SOME parts of the commit history are still the truth, but not all. 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
Re: [E-devel] SVN-Git Migration (was: (no subject))
On Mon, Feb 18, 2013 at 1:02 PM, Daniel Juyung Seo seojuyu...@gmail.com wrote: And it'll be great if the title includes the first line of commit message. That should be way more useful. Indeed. -- Cedric BAIL -- The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials, tech docs, whitepapers, evaluation guides, and opinion stories. Check out the most recent posts - join the conversation now. http://goparallel.sourceforge.net/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] SVN-Git Migration (was: (no subject))
+1 I strongly agree. Commit id title is inconvenient. 2013. 2. 18. 오후 1:04에 Daniel Juyung Seo seojuyu...@gmail.com님이 작성: And it'll be great if the title includes the first line of commit message. That should be way more useful. Thanks. Daniel Juyung Seo (SeoZ) On Mon, Feb 18, 2013 at 10:14 AM, ChunEon Park her...@naver.com wrote: By the way, Daniel, Could it possible to make git mail title messages to be more meaningful? i.e) [core/efl] xxxmaster updated. f27ff2fbf31a01c2f8d98e773bed6cc4298749bd - [core/efl/evas] xxxmaster updated. f27ff2fbf31a01c2f8d98e773bed6cc4298749bd If the title shows any detailed core lib name that was changed, it would be better to know what is changed in abstractly. -Regards, Hermet- -Original Message- From: David Seikelonef...@gmail.com To: enlightenment-devel@lists.sourceforge.net; Cc: Sent: 2013-02-16 (토) 16:19:58 Subject: Re: [E-devel] SVN-Git Migration (was: (no subject)) On Sat, 16 Feb 2013 15:42:46 +0900 Jérôme Pinot ngc891@gmail.com wrote: On 02/16/13 15:58, David Seikel wrote: On Fri, 15 Feb 2013 11:56:06 -0200 Rafael Antognolli antognolli@gmail.com wrote: Hi David, On Thu, Feb 14, 2013 at 9:12 AM, David Seikel onefang@gmail.com wrote: On Thu, 14 Feb 2013 08:53:22 -0200 Bruno Dilly bdilly@profusion.mobi wrote: On Wed, Feb 13, 2013 at 8:42 AM, Daniel Willmann d.willmann@samsung.com wrote: On 13/02/13 00:36, Bruno Dilly wrote: On Mon, Feb 11, 2013 at 2:07 PM, Daniel Willmann d.willmann@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. It is a lie, it's changing the history to say it was all done one after the other, when in fact a major feature of distributed development was used to branch then merge. It was not done in a linear fashion, thus making it be linear after the fact is not representing the truth. Sure SOME parts of the commit history are still the truth, but not all. 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
Re: [E-devel] SVN-Git Migration (was: (no subject))
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
Re: [E-devel] SVN-Git Migration (was: (no subject))
On Fri, Feb 15, 2013 at 11:56 AM, Rafael Antognolli antogno...@gmail.com wrote: 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. me too. Merges only make sense when there are maintainers of particular pieces of the repository. The best example of this is the Linux Kernel. You merge what the submaintainers send to you. They can't rebase on top of you because otherwise they would break the history for whoever is basing their development on their tree. On the other side, take projects like BlueZ, ConnMan, WebKit. There aren't merges... and there's no lie as you are implying. People are used to rebase before sending the features they developed. Also we don't need to be black or white here. Sometimes it's easier to use merges and still don't pollute the repository. I myself sometimes use merges in the projects I maintain, though most of the times rebases are better. Lucas De Marchi -- 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
Re: [E-devel] SVN-Git Migration (was: (no subject))
Hi, On Fri, Feb 15, 2013 at 3:16 PM, Lucas De Marchi lucas.demar...@profusion.mobi wrote: On Fri, Feb 15, 2013 at 11:56 AM, Rafael Antognolli antogno...@gmail.com wrote: I know that this is not a poll, but I particularly prefer rebased branches/commits too. me too. Merges only make sense when there are maintainers of particular pieces of the repository. The best example of this is the Linux Kernel. You merge what the submaintainers send to you. They can't rebase on top of you because otherwise they would break the history for whoever is basing their development on their tree. On the other side, take projects like BlueZ, ConnMan, WebKit. There aren't merges... and there's no lie as you are implying. People are used to rebase before sending the features they developed. Also we don't need to be black or white here. Sometimes it's easier to use merges and still don't pollute the repository. I myself sometimes use merges in the projects I maintain, though most of the times rebases are better. +1 -- Ulisses Furquim -- The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials, tech docs, whitepapers, evaluation guides, and opinion stories. Check out the most recent posts - join the conversation now. http://goparallel.sourceforge.net/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] SVN-Git Migration (was: (no subject))
On Fri, 15 Feb 2013 11:56:06 -0200 Rafael Antognolli antogno...@gmail.com wrote: 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. It is a lie, it's changing the history to say it was all done one after the other, when in fact a major feature of distributed development was used to branch then merge. It was not done in a linear fashion, thus making it be linear after the fact is not representing the truth. Sure SOME parts of the commit history are still the truth, but not all. 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. That's what I'm saying, loosing information to make things more convenient. I'd prefer to err on the side of not loosing information. But then again, I'm a hoarder. B-) I know that this is not a poll, but I particularly prefer rebased branches/commits too. -- 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 -- The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials, tech docs, whitepapers, evaluation guides, and opinion stories. Check out the most recent posts - join the conversation now. http://goparallel.sourceforge.net/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] SVN-Git Migration (was: (no subject))
On 02/16/13 15:58, David Seikel wrote: On Fri, 15 Feb 2013 11:56:06 -0200 Rafael Antognolli antogno...@gmail.com wrote: 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. It is a lie, it's changing the history to say it was all done one after the other, when in fact a major feature of distributed development was used to branch then merge. It was not done in a linear fashion, thus making it be linear after the fact is not representing the truth. Sure SOME parts of the commit history are still the truth, but not all. 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. That's what I'm saying, loosing information to make things more convenient. I'd prefer to err on the side of not loosing information. But then again, I'm a hoarder. B-) I know that this is not a poll, but I particularly prefer rebased branches/commits too. LWN has a neat article about the git rebase thing: http://lwn.net/Articles/328436/ Thou Shalt Not Rebase Trees With History Visible To Others -- Jérôme Pinot http://ngc891.blogdns.net/ signature.asc Description: Digital signature -- The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials, tech docs, whitepapers, evaluation guides, and opinion stories. Check out the most recent posts - join the conversation now. http://goparallel.sourceforge.net/___ enlightenment-devel mailing list
Re: [E-devel] SVN-Git Migration (was: (no subject))
On Sat, 16 Feb 2013 15:42:46 +0900 Jérôme Pinot ngc...@gmail.com wrote: On 02/16/13 15:58, David Seikel wrote: On Fri, 15 Feb 2013 11:56:06 -0200 Rafael Antognolli antogno...@gmail.com wrote: 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. It is a lie, it's changing the history to say it was all done one after the other, when in fact a major feature of distributed development was used to branch then merge. It was not done in a linear fashion, thus making it be linear after the fact is not representing the truth. Sure SOME parts of the commit history are still the truth, but not all. 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. That's what I'm saying, loosing information to make things more convenient. I'd prefer to err on the side of not loosing information. But then again, I'm a hoarder. B-) I know that this is not a poll, but I particularly prefer rebased branches/commits too. LWN has a neat article about the git rebase thing: http://lwn.net/Articles/328436/ Thou Shalt Not Rebase Trees With History Visible To Others I was easily able to come up with many rebase is evil things with a web search engine, and it turned up a few rebase is not evil things as well. -- 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 -- The Go Parallel Website, sponsored by Intel - in
Re: [E-devel] SVN-Git Migration (was: (no subject))
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. Regards, Daniel -- 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 -- Bruno Dilly Lead Developer ProFUSION embedded systems http://profusion.mobi -- 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
Re: [E-devel] SVN-Git Migration (was: (no subject))
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. Those who don't know history are destined to repeat it. B-) -- 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
Re: [E-devel] SVN-Git Migration (was: (no subject))
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. Lucas De Marchi -- 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
Re: [E-devel] SVN-Git Migration (was: (no subject))
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
Re: [E-devel] SVN-Git Migration (was: (no subject))
On Thu, Feb 14, 2013 at 08:53:22AM -0200, Bruno Dilly 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. It's usually less work for me, because it's easier for me to reapply patches I had in my own branch and check if they still do what they did before rebase correctly, then to resolve one big merge conflict where you can get 5 different people touching the same code as what you had in branch and you have to be sure that your resolution does not only keep your change correct, but also does not break those 5 different changes. Using the merge approach, in a project with so many commiters could lead us to a very confuse history. -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital 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
[E-devel] SVN-Git Migration (was: (no subject))
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). 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. Regards, Daniel -- 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
Re: [E-devel] SVN-Git Migration (was: (no subject))
On Wed, 13 Feb 2013 10:42:17 + Daniel Willmann d.willm...@samsung.com said: 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). the day the pending patches on our mailing lists are all handled before i get around to them is the day i might consider we do... but i have maybe 30-50+ pending patches in my backlog that havent (seemingly) been dealt with. :) 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. Regards, Daniel -- 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 -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- 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
