Re: [DISCUSS] Migrate from svn to git for source control?
Thanks Steve. Including that in the proposal. By the way, from our project bylaws (http://hadoop.apache.org/bylaws.html), I can't tell what kind of a vote this would be. On Thu, Aug 7, 2014 at 1:22 AM, Steve Loughran ste...@hortonworks.com wrote: On 6 August 2014 22:16, Karthik Kambatla ka...@cloudera.com wrote: 3. Force-push on feature-branches is allowed. Before pulling in a feature, the feature-branch should be rebased on latest trunk and the changes applied to trunk through git rebase --onto or git cherry-pick commit-range. I'd add to this process the requirement to tag any feature branch before a rebase, with some standard naming like tag_feature_JIRA-2454_2014-08-07_rebase Why? it keeps the state of the branch before the rebase in case you ever want it back again. Without the tag: lost data. Once the feature is merged in you can rm the tags, but until then they give you a log of what changes went on, and make it possible to switch back to the pre-rebase version. Without those tags you do lose history of the development. -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You.
Re: [DISCUSS] Migrate from svn to git for source control?
funny, i'd treat it as a merge vote. On Fri, Aug 8, 2014 at 11:44 AM, Karthik Kambatla ka...@cloudera.com wrote: Thanks Steve. Including that in the proposal. By the way, from our project bylaws (http://hadoop.apache.org/bylaws.html ), I can't tell what kind of a vote this would be. On Thu, Aug 7, 2014 at 1:22 AM, Steve Loughran ste...@hortonworks.com wrote: On 6 August 2014 22:16, Karthik Kambatla ka...@cloudera.com wrote: 3. Force-push on feature-branches is allowed. Before pulling in a feature, the feature-branch should be rebased on latest trunk and the changes applied to trunk through git rebase --onto or git cherry-pick commit-range. I'd add to this process the requirement to tag any feature branch before a rebase, with some standard naming like tag_feature_JIRA-2454_2014-08-07_rebase Why? it keeps the state of the branch before the rebase in case you ever want it back again. Without the tag: lost data. Once the feature is merged in you can rm the tags, but until then they give you a log of what changes went on, and make it possible to switch back to the pre-rebase version. Without those tags you do lose history of the development. -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You. -- Alejandro
Re: [DISCUSS] Migrate from svn to git for source control?
In the bylaws, I see this under PMC responsibilities: * Maintaining the project's shared resources, including the codebase repository, mailing lists, websites. This seems to indicate that the repo (i.e. svn or git) is managed by the PMC. Of the available PMC vote actions, the closest seems to be Adoption of New Codebase: When the codebase for an existing, released product is to be replaced with an alternative codebase. If such a vote fails to gain approval, the existing code base will continue. This also covers the creation of new sub-projects within the project Lazy 2/3 majority of PMC members This would be my recommendation for the vote, but I'll defer to more experienced PMC members. Thanks, Andrew On Fri, Aug 8, 2014 at 1:18 PM, Alejandro Abdelnur t...@cloudera.com wrote: funny, i'd treat it as a merge vote. On Fri, Aug 8, 2014 at 11:44 AM, Karthik Kambatla ka...@cloudera.com wrote: Thanks Steve. Including that in the proposal. By the way, from our project bylaws ( http://hadoop.apache.org/bylaws.html ), I can't tell what kind of a vote this would be. On Thu, Aug 7, 2014 at 1:22 AM, Steve Loughran ste...@hortonworks.com wrote: On 6 August 2014 22:16, Karthik Kambatla ka...@cloudera.com wrote: 3. Force-push on feature-branches is allowed. Before pulling in a feature, the feature-branch should be rebased on latest trunk and the changes applied to trunk through git rebase --onto or git cherry-pick commit-range. I'd add to this process the requirement to tag any feature branch before a rebase, with some standard naming like tag_feature_JIRA-2454_2014-08-07_rebase Why? it keeps the state of the branch before the rebase in case you ever want it back again. Without the tag: lost data. Once the feature is merged in you can rm the tags, but until then they give you a log of what changes went on, and make it possible to switch back to the pre-rebase version. Without those tags you do lose history of the development. -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You. -- Alejandro
Re: [DISCUSS] Migrate from svn to git for source control?
On 6 August 2014 22:16, Karthik Kambatla ka...@cloudera.com wrote: 3. Force-push on feature-branches is allowed. Before pulling in a feature, the feature-branch should be rebased on latest trunk and the changes applied to trunk through git rebase --onto or git cherry-pick commit-range. I'd add to this process the requirement to tag any feature branch before a rebase, with some standard naming like tag_feature_JIRA-2454_2014-08-07_rebase Why? it keeps the state of the branch before the rebase in case you ever want it back again. Without the tag: lost data. Once the feature is merged in you can rm the tags, but until then they give you a log of what changes went on, and make it possible to switch back to the pre-rebase version. Without those tags you do lose history of the development. -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You.
Re: [DISCUSS] Migrate from svn to git for source control?
By merge-based workflow, this is referring to branch development and merging? I don't see much issue with allowing a rebase-based workflow if we're okay with allowing force-push on feature branches. If anything, the next step would be disallowing merge-based workflows and mandating rebases for a clean linear history, but it sounds like we'd rather not for now. Also, to state the obvious, for trunk-branch-2-etc backports, I'd expect us to be doing git cherry-picks. I think it'd be good to disable force-push for the main branches as Arpit recommends, we could include that in the VOTE as well. Thanks, Andrew On Tue, Aug 5, 2014 at 9:27 PM, Arpit Agarwal aagar...@hortonworks.com wrote: If by very same workflow you mean a merge-based workflow that would be fine to call out in the vote proposal. Separately, do we want to disable force push for version branches (branch-x) and point release branches (branch-x.y) in addition to trunk? On Tue, Aug 5, 2014 at 8:18 PM, Alejandro Abdelnur tuc...@gmail.com wrote: I would say we can first move to git and keep the very same workflow we have today, then we can evolve it. On Tue, Aug 5, 2014 at 6:46 PM, Arpit Agarwal aagar...@hortonworks.com wrote: +1 to voting on specific workflow(s). On Tue, Aug 5, 2014 at 5:49 PM, Karthik Kambatla ka...@cloudera.com wrote: If we are to start a vote thread, will people prefer a vote thread that includes potential workflows as well? On Tue, Aug 5, 2014 at 5:40 PM, Karthik Kambatla ka...@cloudera.com wrote: Thanks for your opinions, everyone. Looks like most people are for the change and no one is against it. Let me start a vote for this. On Mon, Aug 4, 2014 at 4:44 PM, Tsuyoshi OZAWA ozawa.tsuyo...@gmail.com wrote: Thank you for supplementation, Andrew. Yes, we should go step by step and let's discuss review workflows on a another thread. Thanks, - Tsuyoshi On Tue, Aug 5, 2014 at 8:23 AM, Andrew Wang andrew.w...@cloudera.com wrote: I think we should take things one step at a time. Switching to git definitely opens up the possibility for better review workflows, but we can discuss that on a different thread. A few different people have also mentioned Gerrit, so that'd be in the running along with Github (and I guess ReviewBoard). Thanks, Andrew On Mon, Aug 4, 2014 at 4:17 PM, Tsuyoshi OZAWA ozawa.tsuyo...@gmail.com wrote: Thank you for great suggestion, Karthik. +1(non-binding) to use git. I'm also using private git repository. Additionally, I have one question. Will we accept github-based development like Apache Spark? IHMO, it allow us to leverage Hadoop development, because the cost of sending pull request is very low and its review board is great. One concern is that the development workflow can change and it can confuse us. What do you think? Thanks, - Tsuyoshi On Sat, Aug 2, 2014 at 8:43 AM, Karthik Kambatla ka...@cloudera.com wrote: Hi folks, From what I hear, a lot of devs use the git mirror for development/reviews and use subversion primarily for checking code in. I was wondering if it would make more sense just to move to git. In addition to subjective liking of git, I see the following advantages in our workflow: 1. Feature branches - it becomes easier to work on them and keep rebasing against the latest trunk. 2. Cherry-picks between branches automatically ensures the exact same commit message and tracks the lineage as well. 3. When cutting new branches and/or updating maven versions etc., it allows doing all the work locally before pushing it to the main branch. 4. Opens us up to potentially using other code-review tools. (Gerrit?) 5. It is just more convenient. I am sure this was brought up before in different capacities. I believe the support for git in ASF is healthy now and several downstream projects have moved. Again, from what I hear, ASF INFRA folks make the migration process fairly easy. What do you all think? Thanks Karthik -- - Tsuyoshi -- - Tsuyoshi -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby
Re: [DISCUSS] Migrate from svn to git for source control?
I personally use github for most of my projects because it gives me power over my code versions. I'm a linux user and thats where github takes over.. no offfense but svn is good too but most people know github including the novice On Wed, Aug 6, 2014 at 9:41 AM, Andrew Wang andrew.w...@cloudera.com wrote: By merge-based workflow, this is referring to branch development and merging? I don't see much issue with allowing a rebase-based workflow if we're okay with allowing force-push on feature branches. If anything, the next step would be disallowing merge-based workflows and mandating rebases for a clean linear history, but it sounds like we'd rather not for now. Also, to state the obvious, for trunk-branch-2-etc backports, I'd expect us to be doing git cherry-picks. I think it'd be good to disable force-push for the main branches as Arpit recommends, we could include that in the VOTE as well. Thanks, Andrew On Tue, Aug 5, 2014 at 9:27 PM, Arpit Agarwal aagar...@hortonworks.com wrote: If by very same workflow you mean a merge-based workflow that would be fine to call out in the vote proposal. Separately, do we want to disable force push for version branches (branch-x) and point release branches (branch-x.y) in addition to trunk? On Tue, Aug 5, 2014 at 8:18 PM, Alejandro Abdelnur tuc...@gmail.com wrote: I would say we can first move to git and keep the very same workflow we have today, then we can evolve it. On Tue, Aug 5, 2014 at 6:46 PM, Arpit Agarwal aagar...@hortonworks.com wrote: +1 to voting on specific workflow(s). On Tue, Aug 5, 2014 at 5:49 PM, Karthik Kambatla ka...@cloudera.com wrote: If we are to start a vote thread, will people prefer a vote thread that includes potential workflows as well? On Tue, Aug 5, 2014 at 5:40 PM, Karthik Kambatla ka...@cloudera.com wrote: Thanks for your opinions, everyone. Looks like most people are for the change and no one is against it. Let me start a vote for this. On Mon, Aug 4, 2014 at 4:44 PM, Tsuyoshi OZAWA ozawa.tsuyo...@gmail.com wrote: Thank you for supplementation, Andrew. Yes, we should go step by step and let's discuss review workflows on a another thread. Thanks, - Tsuyoshi On Tue, Aug 5, 2014 at 8:23 AM, Andrew Wang andrew.w...@cloudera.com wrote: I think we should take things one step at a time. Switching to git definitely opens up the possibility for better review workflows, but we can discuss that on a different thread. A few different people have also mentioned Gerrit, so that'd be in the running along with Github (and I guess ReviewBoard). Thanks, Andrew On Mon, Aug 4, 2014 at 4:17 PM, Tsuyoshi OZAWA ozawa.tsuyo...@gmail.com wrote: Thank you for great suggestion, Karthik. +1(non-binding) to use git. I'm also using private git repository. Additionally, I have one question. Will we accept github-based development like Apache Spark? IHMO, it allow us to leverage Hadoop development, because the cost of sending pull request is very low and its review board is great. One concern is that the development workflow can change and it can confuse us. What do you think? Thanks, - Tsuyoshi On Sat, Aug 2, 2014 at 8:43 AM, Karthik Kambatla ka...@cloudera.com wrote: Hi folks, From what I hear, a lot of devs use the git mirror for development/reviews and use subversion primarily for checking code in. I was wondering if it would make more sense just to move to git. In addition to subjective liking of git, I see the following advantages in our workflow: 1. Feature branches - it becomes easier to work on them and keep rebasing against the latest trunk. 2. Cherry-picks between branches automatically ensures the exact same commit message and tracks the lineage as well. 3. When cutting new branches and/or updating maven versions etc., it allows doing all the work locally before pushing it to the main branch. 4. Opens us up to potentially using other code-review tools. (Gerrit?) 5. It is just more convenient. I am sure this was brought up before in different capacities. I believe the support for git in ASF is healthy now and several downstream projects have moved. Again, from what I hear, ASF INFRA folks make the migration process fairly easy. What do you all think?
Re: [DISCUSS] Migrate from svn to git for source control?
I plan to propose the following in the vote thread. Please advise on more details to be added and/or concerns you have so we avoid the overhead of doing this in the vote thread. 1. Migrate from subversion to git for version control 2. Force-push to be disabled on trunk and branch-* branches. Applying changes from any of trunk/branch-* to any of branch-* should be through git cherry-pick -x. 3. Force-push on feature-branches is allowed. Before pulling in a feature, the feature-branch should be rebased on latest trunk and the changes applied to trunk through git rebase --onto or git cherry-pick commit-range. 4. The use of tags stay the same after the migration. On Tue, Aug 5, 2014 at 11:41 PM, Andrew Wang andrew.w...@cloudera.com wrote: By merge-based workflow, this is referring to branch development and merging? I don't see much issue with allowing a rebase-based workflow if we're okay with allowing force-push on feature branches. If anything, the next step would be disallowing merge-based workflows and mandating rebases for a clean linear history, but it sounds like we'd rather not for now. Also, to state the obvious, for trunk-branch-2-etc backports, I'd expect us to be doing git cherry-picks. I think it'd be good to disable force-push for the main branches as Arpit recommends, we could include that in the VOTE as well. Thanks, Andrew On Tue, Aug 5, 2014 at 9:27 PM, Arpit Agarwal aagar...@hortonworks.com wrote: If by very same workflow you mean a merge-based workflow that would be fine to call out in the vote proposal. Separately, do we want to disable force push for version branches (branch-x) and point release branches (branch-x.y) in addition to trunk? On Tue, Aug 5, 2014 at 8:18 PM, Alejandro Abdelnur tuc...@gmail.com wrote: I would say we can first move to git and keep the very same workflow we have today, then we can evolve it. On Tue, Aug 5, 2014 at 6:46 PM, Arpit Agarwal aagar...@hortonworks.com wrote: +1 to voting on specific workflow(s). On Tue, Aug 5, 2014 at 5:49 PM, Karthik Kambatla ka...@cloudera.com wrote: If we are to start a vote thread, will people prefer a vote thread that includes potential workflows as well? On Tue, Aug 5, 2014 at 5:40 PM, Karthik Kambatla ka...@cloudera.com wrote: Thanks for your opinions, everyone. Looks like most people are for the change and no one is against it. Let me start a vote for this. On Mon, Aug 4, 2014 at 4:44 PM, Tsuyoshi OZAWA ozawa.tsuyo...@gmail.com wrote: Thank you for supplementation, Andrew. Yes, we should go step by step and let's discuss review workflows on a another thread. Thanks, - Tsuyoshi On Tue, Aug 5, 2014 at 8:23 AM, Andrew Wang andrew.w...@cloudera.com wrote: I think we should take things one step at a time. Switching to git definitely opens up the possibility for better review workflows, but we can discuss that on a different thread. A few different people have also mentioned Gerrit, so that'd be in the running along with Github (and I guess ReviewBoard). Thanks, Andrew On Mon, Aug 4, 2014 at 4:17 PM, Tsuyoshi OZAWA ozawa.tsuyo...@gmail.com wrote: Thank you for great suggestion, Karthik. +1(non-binding) to use git. I'm also using private git repository. Additionally, I have one question. Will we accept github-based development like Apache Spark? IHMO, it allow us to leverage Hadoop development, because the cost of sending pull request is very low and its review board is great. One concern is that the development workflow can change and it can confuse us. What do you think? Thanks, - Tsuyoshi On Sat, Aug 2, 2014 at 8:43 AM, Karthik Kambatla ka...@cloudera.com wrote: Hi folks, From what I hear, a lot of devs use the git mirror for development/reviews and use subversion primarily for checking code in. I was wondering if it would make more sense just to move to git. In addition to subjective liking of git, I see the following advantages in our workflow: 1. Feature branches - it becomes easier to work on them and keep rebasing against the latest trunk. 2. Cherry-picks between branches automatically ensures the exact same commit message and tracks the lineage as well. 3. When cutting new branches and/or updating maven versions etc., it allows doing all the work locally before pushing it to the main branch. 4. Opens us up to potentially using other
Re: [DISCUSS] Migrate from svn to git for source control?
Thanks for your opinions, everyone. Looks like most people are for the change and no one is against it. Let me start a vote for this. On Mon, Aug 4, 2014 at 4:44 PM, Tsuyoshi OZAWA ozawa.tsuyo...@gmail.com wrote: Thank you for supplementation, Andrew. Yes, we should go step by step and let's discuss review workflows on a another thread. Thanks, - Tsuyoshi On Tue, Aug 5, 2014 at 8:23 AM, Andrew Wang andrew.w...@cloudera.com wrote: I think we should take things one step at a time. Switching to git definitely opens up the possibility for better review workflows, but we can discuss that on a different thread. A few different people have also mentioned Gerrit, so that'd be in the running along with Github (and I guess ReviewBoard). Thanks, Andrew On Mon, Aug 4, 2014 at 4:17 PM, Tsuyoshi OZAWA ozawa.tsuyo...@gmail.com wrote: Thank you for great suggestion, Karthik. +1(non-binding) to use git. I'm also using private git repository. Additionally, I have one question. Will we accept github-based development like Apache Spark? IHMO, it allow us to leverage Hadoop development, because the cost of sending pull request is very low and its review board is great. One concern is that the development workflow can change and it can confuse us. What do you think? Thanks, - Tsuyoshi On Sat, Aug 2, 2014 at 8:43 AM, Karthik Kambatla ka...@cloudera.com wrote: Hi folks, From what I hear, a lot of devs use the git mirror for development/reviews and use subversion primarily for checking code in. I was wondering if it would make more sense just to move to git. In addition to subjective liking of git, I see the following advantages in our workflow: 1. Feature branches - it becomes easier to work on them and keep rebasing against the latest trunk. 2. Cherry-picks between branches automatically ensures the exact same commit message and tracks the lineage as well. 3. When cutting new branches and/or updating maven versions etc., it allows doing all the work locally before pushing it to the main branch. 4. Opens us up to potentially using other code-review tools. (Gerrit?) 5. It is just more convenient. I am sure this was brought up before in different capacities. I believe the support for git in ASF is healthy now and several downstream projects have moved. Again, from what I hear, ASF INFRA folks make the migration process fairly easy. What do you all think? Thanks Karthik -- - Tsuyoshi -- - Tsuyoshi
Re: [DISCUSS] Migrate from svn to git for source control?
If we are to start a vote thread, will people prefer a vote thread that includes potential workflows as well? On Tue, Aug 5, 2014 at 5:40 PM, Karthik Kambatla ka...@cloudera.com wrote: Thanks for your opinions, everyone. Looks like most people are for the change and no one is against it. Let me start a vote for this. On Mon, Aug 4, 2014 at 4:44 PM, Tsuyoshi OZAWA ozawa.tsuyo...@gmail.com wrote: Thank you for supplementation, Andrew. Yes, we should go step by step and let's discuss review workflows on a another thread. Thanks, - Tsuyoshi On Tue, Aug 5, 2014 at 8:23 AM, Andrew Wang andrew.w...@cloudera.com wrote: I think we should take things one step at a time. Switching to git definitely opens up the possibility for better review workflows, but we can discuss that on a different thread. A few different people have also mentioned Gerrit, so that'd be in the running along with Github (and I guess ReviewBoard). Thanks, Andrew On Mon, Aug 4, 2014 at 4:17 PM, Tsuyoshi OZAWA ozawa.tsuyo...@gmail.com wrote: Thank you for great suggestion, Karthik. +1(non-binding) to use git. I'm also using private git repository. Additionally, I have one question. Will we accept github-based development like Apache Spark? IHMO, it allow us to leverage Hadoop development, because the cost of sending pull request is very low and its review board is great. One concern is that the development workflow can change and it can confuse us. What do you think? Thanks, - Tsuyoshi On Sat, Aug 2, 2014 at 8:43 AM, Karthik Kambatla ka...@cloudera.com wrote: Hi folks, From what I hear, a lot of devs use the git mirror for development/reviews and use subversion primarily for checking code in. I was wondering if it would make more sense just to move to git. In addition to subjective liking of git, I see the following advantages in our workflow: 1. Feature branches - it becomes easier to work on them and keep rebasing against the latest trunk. 2. Cherry-picks between branches automatically ensures the exact same commit message and tracks the lineage as well. 3. When cutting new branches and/or updating maven versions etc., it allows doing all the work locally before pushing it to the main branch. 4. Opens us up to potentially using other code-review tools. (Gerrit?) 5. It is just more convenient. I am sure this was brought up before in different capacities. I believe the support for git in ASF is healthy now and several downstream projects have moved. Again, from what I hear, ASF INFRA folks make the migration process fairly easy. What do you all think? Thanks Karthik -- - Tsuyoshi -- - Tsuyoshi
Re: [DISCUSS] Migrate from svn to git for source control?
+1 to voting on specific workflow(s). On Tue, Aug 5, 2014 at 5:49 PM, Karthik Kambatla ka...@cloudera.com wrote: If we are to start a vote thread, will people prefer a vote thread that includes potential workflows as well? On Tue, Aug 5, 2014 at 5:40 PM, Karthik Kambatla ka...@cloudera.com wrote: Thanks for your opinions, everyone. Looks like most people are for the change and no one is against it. Let me start a vote for this. On Mon, Aug 4, 2014 at 4:44 PM, Tsuyoshi OZAWA ozawa.tsuyo...@gmail.com wrote: Thank you for supplementation, Andrew. Yes, we should go step by step and let's discuss review workflows on a another thread. Thanks, - Tsuyoshi On Tue, Aug 5, 2014 at 8:23 AM, Andrew Wang andrew.w...@cloudera.com wrote: I think we should take things one step at a time. Switching to git definitely opens up the possibility for better review workflows, but we can discuss that on a different thread. A few different people have also mentioned Gerrit, so that'd be in the running along with Github (and I guess ReviewBoard). Thanks, Andrew On Mon, Aug 4, 2014 at 4:17 PM, Tsuyoshi OZAWA ozawa.tsuyo...@gmail.com wrote: Thank you for great suggestion, Karthik. +1(non-binding) to use git. I'm also using private git repository. Additionally, I have one question. Will we accept github-based development like Apache Spark? IHMO, it allow us to leverage Hadoop development, because the cost of sending pull request is very low and its review board is great. One concern is that the development workflow can change and it can confuse us. What do you think? Thanks, - Tsuyoshi On Sat, Aug 2, 2014 at 8:43 AM, Karthik Kambatla ka...@cloudera.com wrote: Hi folks, From what I hear, a lot of devs use the git mirror for development/reviews and use subversion primarily for checking code in. I was wondering if it would make more sense just to move to git. In addition to subjective liking of git, I see the following advantages in our workflow: 1. Feature branches - it becomes easier to work on them and keep rebasing against the latest trunk. 2. Cherry-picks between branches automatically ensures the exact same commit message and tracks the lineage as well. 3. When cutting new branches and/or updating maven versions etc., it allows doing all the work locally before pushing it to the main branch. 4. Opens us up to potentially using other code-review tools. (Gerrit?) 5. It is just more convenient. I am sure this was brought up before in different capacities. I believe the support for git in ASF is healthy now and several downstream projects have moved. Again, from what I hear, ASF INFRA folks make the migration process fairly easy. What do you all think? Thanks Karthik -- - Tsuyoshi -- - Tsuyoshi -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You.
Re: [DISCUSS] Migrate from svn to git for source control?
I would say we can first move to git and keep the very same workflow we have today, then we can evolve it. On Tue, Aug 5, 2014 at 6:46 PM, Arpit Agarwal aagar...@hortonworks.com wrote: +1 to voting on specific workflow(s). On Tue, Aug 5, 2014 at 5:49 PM, Karthik Kambatla ka...@cloudera.com wrote: If we are to start a vote thread, will people prefer a vote thread that includes potential workflows as well? On Tue, Aug 5, 2014 at 5:40 PM, Karthik Kambatla ka...@cloudera.com wrote: Thanks for your opinions, everyone. Looks like most people are for the change and no one is against it. Let me start a vote for this. On Mon, Aug 4, 2014 at 4:44 PM, Tsuyoshi OZAWA ozawa.tsuyo...@gmail.com wrote: Thank you for supplementation, Andrew. Yes, we should go step by step and let's discuss review workflows on a another thread. Thanks, - Tsuyoshi On Tue, Aug 5, 2014 at 8:23 AM, Andrew Wang andrew.w...@cloudera.com wrote: I think we should take things one step at a time. Switching to git definitely opens up the possibility for better review workflows, but we can discuss that on a different thread. A few different people have also mentioned Gerrit, so that'd be in the running along with Github (and I guess ReviewBoard). Thanks, Andrew On Mon, Aug 4, 2014 at 4:17 PM, Tsuyoshi OZAWA ozawa.tsuyo...@gmail.com wrote: Thank you for great suggestion, Karthik. +1(non-binding) to use git. I'm also using private git repository. Additionally, I have one question. Will we accept github-based development like Apache Spark? IHMO, it allow us to leverage Hadoop development, because the cost of sending pull request is very low and its review board is great. One concern is that the development workflow can change and it can confuse us. What do you think? Thanks, - Tsuyoshi On Sat, Aug 2, 2014 at 8:43 AM, Karthik Kambatla ka...@cloudera.com wrote: Hi folks, From what I hear, a lot of devs use the git mirror for development/reviews and use subversion primarily for checking code in. I was wondering if it would make more sense just to move to git. In addition to subjective liking of git, I see the following advantages in our workflow: 1. Feature branches - it becomes easier to work on them and keep rebasing against the latest trunk. 2. Cherry-picks between branches automatically ensures the exact same commit message and tracks the lineage as well. 3. When cutting new branches and/or updating maven versions etc., it allows doing all the work locally before pushing it to the main branch. 4. Opens us up to potentially using other code-review tools. (Gerrit?) 5. It is just more convenient. I am sure this was brought up before in different capacities. I believe the support for git in ASF is healthy now and several downstream projects have moved. Again, from what I hear, ASF INFRA folks make the migration process fairly easy. What do you all think? Thanks Karthik -- - Tsuyoshi -- - Tsuyoshi -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You.
Re: [DISCUSS] Migrate from svn to git for source control?
If by very same workflow you mean a merge-based workflow that would be fine to call out in the vote proposal. Separately, do we want to disable force push for version branches (branch-x) and point release branches (branch-x.y) in addition to trunk? On Tue, Aug 5, 2014 at 8:18 PM, Alejandro Abdelnur tuc...@gmail.com wrote: I would say we can first move to git and keep the very same workflow we have today, then we can evolve it. On Tue, Aug 5, 2014 at 6:46 PM, Arpit Agarwal aagar...@hortonworks.com wrote: +1 to voting on specific workflow(s). On Tue, Aug 5, 2014 at 5:49 PM, Karthik Kambatla ka...@cloudera.com wrote: If we are to start a vote thread, will people prefer a vote thread that includes potential workflows as well? On Tue, Aug 5, 2014 at 5:40 PM, Karthik Kambatla ka...@cloudera.com wrote: Thanks for your opinions, everyone. Looks like most people are for the change and no one is against it. Let me start a vote for this. On Mon, Aug 4, 2014 at 4:44 PM, Tsuyoshi OZAWA ozawa.tsuyo...@gmail.com wrote: Thank you for supplementation, Andrew. Yes, we should go step by step and let's discuss review workflows on a another thread. Thanks, - Tsuyoshi On Tue, Aug 5, 2014 at 8:23 AM, Andrew Wang andrew.w...@cloudera.com wrote: I think we should take things one step at a time. Switching to git definitely opens up the possibility for better review workflows, but we can discuss that on a different thread. A few different people have also mentioned Gerrit, so that'd be in the running along with Github (and I guess ReviewBoard). Thanks, Andrew On Mon, Aug 4, 2014 at 4:17 PM, Tsuyoshi OZAWA ozawa.tsuyo...@gmail.com wrote: Thank you for great suggestion, Karthik. +1(non-binding) to use git. I'm also using private git repository. Additionally, I have one question. Will we accept github-based development like Apache Spark? IHMO, it allow us to leverage Hadoop development, because the cost of sending pull request is very low and its review board is great. One concern is that the development workflow can change and it can confuse us. What do you think? Thanks, - Tsuyoshi On Sat, Aug 2, 2014 at 8:43 AM, Karthik Kambatla ka...@cloudera.com wrote: Hi folks, From what I hear, a lot of devs use the git mirror for development/reviews and use subversion primarily for checking code in. I was wondering if it would make more sense just to move to git. In addition to subjective liking of git, I see the following advantages in our workflow: 1. Feature branches - it becomes easier to work on them and keep rebasing against the latest trunk. 2. Cherry-picks between branches automatically ensures the exact same commit message and tracks the lineage as well. 3. When cutting new branches and/or updating maven versions etc., it allows doing all the work locally before pushing it to the main branch. 4. Opens us up to potentially using other code-review tools. (Gerrit?) 5. It is just more convenient. I am sure this was brought up before in different capacities. I believe the support for git in ASF is healthy now and several downstream projects have moved. Again, from what I hear, ASF INFRA folks make the migration process fairly easy. What do you all think? Thanks Karthik -- - Tsuyoshi -- - Tsuyoshi -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You. -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank
Re: [DISCUSS] Migrate from svn to git for source control?
I'm =0 on convenience, but like you said, that's because most people have drifted into public/private git repos for development of branches (though that's partly to avoid the ongoing review-before-each commit overhead) -moving to Git could encourage more in-ASF branch dev by committers -if we adopt gerrit then code review would be significantly easier -it'd reduce the latency from an svn commit to a git pull on the git.apache.org repo -we could take (compressed) git am patches with provenance. Other ASF projects (Twill) do this. -could maybe field git pull requests from outside I didn't think cherry picking did lineage so well, and svn merge does that too. It's just a bit more fiddly. Given the overhead of actually applying patches to 2+ branches, I'm grateful for anything that improves this. But...for a move to git, I'd like to see what the big gains are, which seems to me to be in Gerrit. On 2 August 2014 00:43, Karthik Kambatla ka...@cloudera.com wrote: Hi folks, From what I hear, a lot of devs use the git mirror for development/reviews and use subversion primarily for checking code in. I was wondering if it would make more sense just to move to git. In addition to subjective liking of git, I see the following advantages in our workflow: 1. Feature branches - it becomes easier to work on them and keep rebasing against the latest trunk. 2. Cherry-picks between branches automatically ensures the exact same commit message and tracks the lineage as well. 3. When cutting new branches and/or updating maven versions etc., it allows doing all the work locally before pushing it to the main branch. 4. Opens us up to potentially using other code-review tools. (Gerrit?) 5. It is just more convenient. I am sure this was brought up before in different capacities. I believe the support for git in ASF is healthy now and several downstream projects have moved. Again, from what I hear, ASF INFRA folks make the migration process fairly easy. What do you all think? Thanks Karthik -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You.
Re: [DISCUSS] Migrate from svn to git for source control?
merging a multi jiras feature from one branch to another is much easier in git, you can keep all jiras as single commits, you can do any necessary rebasing locally, you cant tweak CHANGES.txt locally, tweak and rebase and squash as necessary, check everything locally, iterate, then push when things are ready. adopting gerrit would be gr8 too. thx Alejandro (phone typing) On Aug 4, 2014, at 2:36, Steve Loughran ste...@hortonworks.com wrote: I'm =0 on convenience, but like you said, that's because most people have drifted into public/private git repos for development of branches (though that's partly to avoid the ongoing review-before-each commit overhead) -moving to Git could encourage more in-ASF branch dev by committers -if we adopt gerrit then code review would be significantly easier -it'd reduce the latency from an svn commit to a git pull on the git.apache.org repo -we could take (compressed) git am patches with provenance. Other ASF projects (Twill) do this. -could maybe field git pull requests from outside I didn't think cherry picking did lineage so well, and svn merge does that too. It's just a bit more fiddly. Given the overhead of actually applying patches to 2+ branches, I'm grateful for anything that improves this. But...for a move to git, I'd like to see what the big gains are, which seems to me to be in Gerrit. On 2 August 2014 00:43, Karthik Kambatla ka...@cloudera.com wrote: Hi folks, From what I hear, a lot of devs use the git mirror for development/reviews and use subversion primarily for checking code in. I was wondering if it would make more sense just to move to git. In addition to subjective liking of git, I see the following advantages in our workflow: 1. Feature branches - it becomes easier to work on them and keep rebasing against the latest trunk. 2. Cherry-picks between branches automatically ensures the exact same commit message and tracks the lineage as well. 3. When cutting new branches and/or updating maven versions etc., it allows doing all the work locally before pushing it to the main branch. 4. Opens us up to potentially using other code-review tools. (Gerrit?) 5. It is just more convenient. I am sure this was brought up before in different capacities. I believe the support for git in ASF is healthy now and several downstream projects have moved. Again, from what I hear, ASF INFRA folks make the migration process fairly easy. What do you all think? Thanks Karthik -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You.
Re: [DISCUSS] Migrate from svn to git for source control?
Personally, I would love us to use something like gerrit. My current review workflow requires me to download the patch, apply it on latest trunk and look at the diff in an IDE. I still might want to do it for big patches, but I would love to be able to just see the diff directly. Also, it would be nicer to look at the diff between versions. I understand RB provides most of these, but I felt and heard gerrit is somehow better. I am not sure using gerrit to commit to different branches is possible though. I heard about other ASF projects getting resistance because it is a headless user (gerrit) committing and not a person. On Mon, Aug 4, 2014 at 9:54 AM, Alejandro Abdelnur t...@cloudera.com wrote: merging a multi jiras feature from one branch to another is much easier in git, you can keep all jiras as single commits, you can do any necessary rebasing locally, you cant tweak CHANGES.txt locally, tweak and rebase and squash as necessary, check everything locally, iterate, then push when things are ready. adopting gerrit would be gr8 too. thx Alejandro (phone typing) On Aug 4, 2014, at 2:36, Steve Loughran ste...@hortonworks.com wrote: I'm =0 on convenience, but like you said, that's because most people have drifted into public/private git repos for development of branches (though that's partly to avoid the ongoing review-before-each commit overhead) -moving to Git could encourage more in-ASF branch dev by committers -if we adopt gerrit then code review would be significantly easier -it'd reduce the latency from an svn commit to a git pull on the git.apache.org repo -we could take (compressed) git am patches with provenance. Other ASF projects (Twill) do this. -could maybe field git pull requests from outside I didn't think cherry picking did lineage so well, and svn merge does that too. It's just a bit more fiddly. Given the overhead of actually applying patches to 2+ branches, I'm grateful for anything that improves this. But...for a move to git, I'd like to see what the big gains are, which seems to me to be in Gerrit. On 2 August 2014 00:43, Karthik Kambatla ka...@cloudera.com wrote: Hi folks, From what I hear, a lot of devs use the git mirror for development/reviews and use subversion primarily for checking code in. I was wondering if it would make more sense just to move to git. In addition to subjective liking of git, I see the following advantages in our workflow: 1. Feature branches - it becomes easier to work on them and keep rebasing against the latest trunk. 2. Cherry-picks between branches automatically ensures the exact same commit message and tracks the lineage as well. 3. When cutting new branches and/or updating maven versions etc., it allows doing all the work locally before pushing it to the main branch. 4. Opens us up to potentially using other code-review tools. (Gerrit?) 5. It is just more convenient. I am sure this was brought up before in different capacities. I believe the support for git in ASF is healthy now and several downstream projects have moved. Again, from what I hear, ASF INFRA folks make the migration process fairly easy. What do you all think? Thanks Karthik -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You.
Re: [DISCUSS] Migrate from svn to git for source control?
HBase recently made the leap from SVN to Git. Our early experience is positive, I think. My observations: When you commit a merge in git, the software will generate a merge commit message in the target branch's history. HBasers decided these pollute history - although an option to 'git log' can elide them - so instead of using 'git merge' for merging we are using alternate workflows that build on 'git rebase'. Rebasing has sharper edges. Occasionally a committer will forget and we will have a merge commit in history. Now and then isn't much of an issue. As committers migrate from svn to git you will need to deal with the occasional botch in history, though. Git allows you to rewrite history but there are consequences to that and default protections in place to prevent it. Infra has something set up to protect against force pushing to certain protected branch names, such as master and trunk. Otherwise you are able to force push by default. I think you will want to work with Infra to prevent force pushing to your branch-* branches as well. Conversely, a force push after rebasing a feature branch on trunk will not be an issue, if you exclude feature branches from this protection. That could be a good thing. If for some reason someone pushes toxic waste to a protected branch, it's easy to work with Infra to temporarily relax force push protections for cleanup. Finally, a force push will cause issues with any checkout tracking the old history, so you'll want to notify all committers in advance so they can take steps. This isn't an issue with SVN, so that's a consideration, but force pushes should be rare outside of feature branches (we haven't had one yet for ~months over in HBase). I found it convenient to tag a release candidate in SVN, then commit CHANGES.txt and other release specific modifications to the tag, since in SVN a tag is a branch is a tag, rather than mix release mechanics with the rest of branch history. This may be an unorthodox practice. I only mention it because with git tags don't work that way. I think it is possible to emulate this by pushing a temporary branch and the desired tag pointing to a commit on that branch, and then another push that removes the temporary branch, leaving only the tag as a ref to that part of history. If you like. We are having some minor discussions about commit formats, how we'd like to do contributor attribution. (This is my fault.) As with everything else about git, there are a couple of ways to do it. On Mon, Aug 4, 2014 at 9:54 AM, Alejandro Abdelnur t...@cloudera.com wrote: merging a multi jiras feature from one branch to another is much easier in git, you can keep all jiras as single commits, you can do any necessary rebasing locally, you cant tweak CHANGES.txt locally, tweak and rebase and squash as necessary, check everything locally, iterate, then push when things are ready. adopting gerrit would be gr8 too. thx Alejandro (phone typing) On Aug 4, 2014, at 2:36, Steve Loughran ste...@hortonworks.com wrote: I'm =0 on convenience, but like you said, that's because most people have drifted into public/private git repos for development of branches (though that's partly to avoid the ongoing review-before-each commit overhead) -moving to Git could encourage more in-ASF branch dev by committers -if we adopt gerrit then code review would be significantly easier -it'd reduce the latency from an svn commit to a git pull on the git.apache.org repo -we could take (compressed) git am patches with provenance. Other ASF projects (Twill) do this. -could maybe field git pull requests from outside I didn't think cherry picking did lineage so well, and svn merge does that too. It's just a bit more fiddly. Given the overhead of actually applying patches to 2+ branches, I'm grateful for anything that improves this. But...for a move to git, I'd like to see what the big gains are, which seems to me to be in Gerrit. On 2 August 2014 00:43, Karthik Kambatla ka...@cloudera.com wrote: Hi folks, From what I hear, a lot of devs use the git mirror for development/reviews and use subversion primarily for checking code in. I was wondering if it would make more sense just to move to git. In addition to subjective liking of git, I see the following advantages in our workflow: 1. Feature branches - it becomes easier to work on them and keep rebasing against the latest trunk. 2. Cherry-picks between branches automatically ensures the exact same commit message and tracks the lineage as well. 3. When cutting new branches and/or updating maven versions etc., it allows doing all the work locally before pushing it to the main branch. 4. Opens us up to potentially using other code-review tools. (Gerrit?) 5. It is just more convenient. I am sure this was brought up before in different capacities. I believe the support for git in ASF is healthy now and several
Re: [DISCUSS] Migrate from svn to git for source control?
+1 to going with git, and +1 to a rebase flow if we do so. On Mon, Aug 4, 2014 at 10:43 AM, Andrew Purtell apurt...@apache.org wrote: HBase recently made the leap from SVN to Git. Our early experience is positive, I think. My observations: When you commit a merge in git, the software will generate a merge commit message in the target branch's history. HBasers decided these pollute history - although an option to 'git log' can elide them - so instead of using 'git merge' for merging we are using alternate workflows that build on 'git rebase'. Rebasing has sharper edges. Occasionally a committer will forget and we will have a merge commit in history. Now and then isn't much of an issue. As committers migrate from svn to git you will need to deal with the occasional botch in history, though. Git allows you to rewrite history but there are consequences to that and default protections in place to prevent it. Infra has something set up to protect against force pushing to certain protected branch names, such as master and trunk. Otherwise you are able to force push by default. I think you will want to work with Infra to prevent force pushing to your branch-* branches as well. Conversely, a force push after rebasing a feature branch on trunk will not be an issue, if you exclude feature branches from this protection. That could be a good thing. If for some reason someone pushes toxic waste to a protected branch, it's easy to work with Infra to temporarily relax force push protections for cleanup. Finally, a force push will cause issues with any checkout tracking the old history, so you'll want to notify all committers in advance so they can take steps. This isn't an issue with SVN, so that's a consideration, but force pushes should be rare outside of feature branches (we haven't had one yet for ~months over in HBase). I found it convenient to tag a release candidate in SVN, then commit CHANGES.txt and other release specific modifications to the tag, since in SVN a tag is a branch is a tag, rather than mix release mechanics with the rest of branch history. This may be an unorthodox practice. I only mention it because with git tags don't work that way. I think it is possible to emulate this by pushing a temporary branch and the desired tag pointing to a commit on that branch, and then another push that removes the temporary branch, leaving only the tag as a ref to that part of history. If you like. We are having some minor discussions about commit formats, how we'd like to do contributor attribution. (This is my fault.) As with everything else about git, there are a couple of ways to do it. On Mon, Aug 4, 2014 at 9:54 AM, Alejandro Abdelnur t...@cloudera.com wrote: merging a multi jiras feature from one branch to another is much easier in git, you can keep all jiras as single commits, you can do any necessary rebasing locally, you cant tweak CHANGES.txt locally, tweak and rebase and squash as necessary, check everything locally, iterate, then push when things are ready. adopting gerrit would be gr8 too. thx Alejandro (phone typing) On Aug 4, 2014, at 2:36, Steve Loughran ste...@hortonworks.com wrote: I'm =0 on convenience, but like you said, that's because most people have drifted into public/private git repos for development of branches (though that's partly to avoid the ongoing review-before-each commit overhead) -moving to Git could encourage more in-ASF branch dev by committers -if we adopt gerrit then code review would be significantly easier -it'd reduce the latency from an svn commit to a git pull on the git.apache.org repo -we could take (compressed) git am patches with provenance. Other ASF projects (Twill) do this. -could maybe field git pull requests from outside I didn't think cherry picking did lineage so well, and svn merge does that too. It's just a bit more fiddly. Given the overhead of actually applying patches to 2+ branches, I'm grateful for anything that improves this. But...for a move to git, I'd like to see what the big gains are, which seems to me to be in Gerrit. On 2 August 2014 00:43, Karthik Kambatla ka...@cloudera.com wrote: Hi folks, From what I hear, a lot of devs use the git mirror for development/reviews and use subversion primarily for checking code in. I was wondering if it would make more sense just to move to git. In addition to subjective liking of git, I see the following advantages in our workflow: 1. Feature branches - it becomes easier to work on them and keep rebasing against the latest trunk. 2. Cherry-picks between branches automatically ensures the exact same commit message and tracks the lineage as well. 3. When cutting new branches and/or updating maven versions etc., it allows doing all the work locally before pushing it to the main branch.
Re: [DISCUSS] Migrate from svn to git for source control?
neat, didn't know about the selective force push. On Mon, Aug 4, 2014 at 10:43 AM, Andrew Purtell apurt...@apache.org wrote: HBase recently made the leap from SVN to Git. Our early experience is positive, I think. My observations: When you commit a merge in git, the software will generate a merge commit message in the target branch's history. HBasers decided these pollute history - although an option to 'git log' can elide them - so instead of using 'git merge' for merging we are using alternate workflows that build on 'git rebase'. Rebasing has sharper edges. Occasionally a committer will forget and we will have a merge commit in history. Now and then isn't much of an issue. As committers migrate from svn to git you will need to deal with the occasional botch in history, though. Git allows you to rewrite history but there are consequences to that and default protections in place to prevent it. Infra has something set up to protect against force pushing to certain protected branch names, such as master and trunk. Otherwise you are able to force push by default. I think you will want to work with Infra to prevent force pushing to your branch-* branches as well. Conversely, a force push after rebasing a feature branch on trunk will not be an issue, if you exclude feature branches from this protection. That could be a good thing. If for some reason someone pushes toxic waste to a protected branch, it's easy to work with Infra to temporarily relax force push protections for cleanup. Finally, a force push will cause issues with any checkout tracking the old history, so you'll want to notify all committers in advance so they can take steps. This isn't an issue with SVN, so that's a consideration, but force pushes should be rare outside of feature branches (we haven't had one yet for ~months over in HBase). I found it convenient to tag a release candidate in SVN, then commit CHANGES.txt and other release specific modifications to the tag, since in SVN a tag is a branch is a tag, rather than mix release mechanics with the rest of branch history. This may be an unorthodox practice. I only mention it because with git tags don't work that way. I think it is possible to emulate this by pushing a temporary branch and the desired tag pointing to a commit on that branch, and then another push that removes the temporary branch, leaving only the tag as a ref to that part of history. If you like. We are having some minor discussions about commit formats, how we'd like to do contributor attribution. (This is my fault.) As with everything else about git, there are a couple of ways to do it. On Mon, Aug 4, 2014 at 9:54 AM, Alejandro Abdelnur t...@cloudera.com wrote: merging a multi jiras feature from one branch to another is much easier in git, you can keep all jiras as single commits, you can do any necessary rebasing locally, you cant tweak CHANGES.txt locally, tweak and rebase and squash as necessary, check everything locally, iterate, then push when things are ready. adopting gerrit would be gr8 too. thx Alejandro (phone typing) On Aug 4, 2014, at 2:36, Steve Loughran ste...@hortonworks.com wrote: I'm =0 on convenience, but like you said, that's because most people have drifted into public/private git repos for development of branches (though that's partly to avoid the ongoing review-before-each commit overhead) -moving to Git could encourage more in-ASF branch dev by committers -if we adopt gerrit then code review would be significantly easier -it'd reduce the latency from an svn commit to a git pull on the git.apache.org repo -we could take (compressed) git am patches with provenance. Other ASF projects (Twill) do this. -could maybe field git pull requests from outside I didn't think cherry picking did lineage so well, and svn merge does that too. It's just a bit more fiddly. Given the overhead of actually applying patches to 2+ branches, I'm grateful for anything that improves this. But...for a move to git, I'd like to see what the big gains are, which seems to me to be in Gerrit. On 2 August 2014 00:43, Karthik Kambatla ka...@cloudera.com wrote: Hi folks, From what I hear, a lot of devs use the git mirror for development/reviews and use subversion primarily for checking code in. I was wondering if it would make more sense just to move to git. In addition to subjective liking of git, I see the following advantages in our workflow: 1. Feature branches - it becomes easier to work on them and keep rebasing against the latest trunk. 2. Cherry-picks between branches automatically ensures the exact same commit message and tracks the lineage as well. 3. When cutting new branches and/or updating maven versions etc., it allows doing all the work locally before pushing it to the main branch. 4. Opens
Re: [DISCUSS] Migrate from svn to git for source control?
Thank you for great suggestion, Karthik. +1(non-binding) to use git. I'm also using private git repository. Additionally, I have one question. Will we accept github-based development like Apache Spark? IHMO, it allow us to leverage Hadoop development, because the cost of sending pull request is very low and its review board is great. One concern is that the development workflow can change and it can confuse us. What do you think? Thanks, - Tsuyoshi On Sat, Aug 2, 2014 at 8:43 AM, Karthik Kambatla ka...@cloudera.com wrote: Hi folks, From what I hear, a lot of devs use the git mirror for development/reviews and use subversion primarily for checking code in. I was wondering if it would make more sense just to move to git. In addition to subjective liking of git, I see the following advantages in our workflow: 1. Feature branches - it becomes easier to work on them and keep rebasing against the latest trunk. 2. Cherry-picks between branches automatically ensures the exact same commit message and tracks the lineage as well. 3. When cutting new branches and/or updating maven versions etc., it allows doing all the work locally before pushing it to the main branch. 4. Opens us up to potentially using other code-review tools. (Gerrit?) 5. It is just more convenient. I am sure this was brought up before in different capacities. I believe the support for git in ASF is healthy now and several downstream projects have moved. Again, from what I hear, ASF INFRA folks make the migration process fairly easy. What do you all think? Thanks Karthik -- - Tsuyoshi
Re: [DISCUSS] Migrate from svn to git for source control?
I think we should take things one step at a time. Switching to git definitely opens up the possibility for better review workflows, but we can discuss that on a different thread. A few different people have also mentioned Gerrit, so that'd be in the running along with Github (and I guess ReviewBoard). Thanks, Andrew On Mon, Aug 4, 2014 at 4:17 PM, Tsuyoshi OZAWA ozawa.tsuyo...@gmail.com wrote: Thank you for great suggestion, Karthik. +1(non-binding) to use git. I'm also using private git repository. Additionally, I have one question. Will we accept github-based development like Apache Spark? IHMO, it allow us to leverage Hadoop development, because the cost of sending pull request is very low and its review board is great. One concern is that the development workflow can change and it can confuse us. What do you think? Thanks, - Tsuyoshi On Sat, Aug 2, 2014 at 8:43 AM, Karthik Kambatla ka...@cloudera.com wrote: Hi folks, From what I hear, a lot of devs use the git mirror for development/reviews and use subversion primarily for checking code in. I was wondering if it would make more sense just to move to git. In addition to subjective liking of git, I see the following advantages in our workflow: 1. Feature branches - it becomes easier to work on them and keep rebasing against the latest trunk. 2. Cherry-picks between branches automatically ensures the exact same commit message and tracks the lineage as well. 3. When cutting new branches and/or updating maven versions etc., it allows doing all the work locally before pushing it to the main branch. 4. Opens us up to potentially using other code-review tools. (Gerrit?) 5. It is just more convenient. I am sure this was brought up before in different capacities. I believe the support for git in ASF is healthy now and several downstream projects have moved. Again, from what I hear, ASF INFRA folks make the migration process fairly easy. What do you all think? Thanks Karthik -- - Tsuyoshi
Re: [DISCUSS] Migrate from svn to git for source control?
Thank you for supplementation, Andrew. Yes, we should go step by step and let's discuss review workflows on a another thread. Thanks, - Tsuyoshi On Tue, Aug 5, 2014 at 8:23 AM, Andrew Wang andrew.w...@cloudera.com wrote: I think we should take things one step at a time. Switching to git definitely opens up the possibility for better review workflows, but we can discuss that on a different thread. A few different people have also mentioned Gerrit, so that'd be in the running along with Github (and I guess ReviewBoard). Thanks, Andrew On Mon, Aug 4, 2014 at 4:17 PM, Tsuyoshi OZAWA ozawa.tsuyo...@gmail.com wrote: Thank you for great suggestion, Karthik. +1(non-binding) to use git. I'm also using private git repository. Additionally, I have one question. Will we accept github-based development like Apache Spark? IHMO, it allow us to leverage Hadoop development, because the cost of sending pull request is very low and its review board is great. One concern is that the development workflow can change and it can confuse us. What do you think? Thanks, - Tsuyoshi On Sat, Aug 2, 2014 at 8:43 AM, Karthik Kambatla ka...@cloudera.com wrote: Hi folks, From what I hear, a lot of devs use the git mirror for development/reviews and use subversion primarily for checking code in. I was wondering if it would make more sense just to move to git. In addition to subjective liking of git, I see the following advantages in our workflow: 1. Feature branches - it becomes easier to work on them and keep rebasing against the latest trunk. 2. Cherry-picks between branches automatically ensures the exact same commit message and tracks the lineage as well. 3. When cutting new branches and/or updating maven versions etc., it allows doing all the work locally before pushing it to the main branch. 4. Opens us up to potentially using other code-review tools. (Gerrit?) 5. It is just more convenient. I am sure this was brought up before in different capacities. I believe the support for git in ASF is healthy now and several downstream projects have moved. Again, from what I hear, ASF INFRA folks make the migration process fairly easy. What do you all think? Thanks Karthik -- - Tsuyoshi -- - Tsuyoshi
RE: [DISCUSS] Migrate from svn to git for source control?
+1, Git is more convenient for development and we can switch easily between branches and can have local branches. Regards, Yi Liu -Original Message- From: Karthik Kambatla [mailto:ka...@cloudera.com] Sent: Saturday, August 02, 2014 7:44 AM To: common-dev@hadoop.apache.org; hdfs-...@hadoop.apache.org; mapreduce-...@hadoop.apache.org; yarn-...@hadoop.apache.org Subject: [DISCUSS] Migrate from svn to git for source control? Hi folks, From what I hear, a lot of devs use the git mirror for development/reviews and use subversion primarily for checking code in. I was wondering if it would make more sense just to move to git. In addition to subjective liking of git, I see the following advantages in our workflow: 1. Feature branches - it becomes easier to work on them and keep rebasing against the latest trunk. 2. Cherry-picks between branches automatically ensures the exact same commit message and tracks the lineage as well. 3. When cutting new branches and/or updating maven versions etc., it allows doing all the work locally before pushing it to the main branch. 4. Opens us up to potentially using other code-review tools. (Gerrit?) 5. It is just more convenient. I am sure this was brought up before in different capacities. I believe the support for git in ASF is healthy now and several downstream projects have moved. Again, from what I hear, ASF INFRA folks make the migration process fairly easy. What do you all think? Thanks Karthik
Re: [DISCUSS] Migrate from svn to git for source control?
+1 for this =) Been using Github mirror for development anyway =) We at Apache Gora moved to Git recently and it had been pretty smooth transition. - Henry On Fri, Aug 1, 2014 at 4:43 PM, Karthik Kambatla ka...@cloudera.com wrote: Hi folks, From what I hear, a lot of devs use the git mirror for development/reviews and use subversion primarily for checking code in. I was wondering if it would make more sense just to move to git. In addition to subjective liking of git, I see the following advantages in our workflow: 1. Feature branches - it becomes easier to work on them and keep rebasing against the latest trunk. 2. Cherry-picks between branches automatically ensures the exact same commit message and tracks the lineage as well. 3. When cutting new branches and/or updating maven versions etc., it allows doing all the work locally before pushing it to the main branch. 4. Opens us up to potentially using other code-review tools. (Gerrit?) 5. It is just more convenient. I am sure this was brought up before in different capacities. I believe the support for git in ASF is healthy now and several downstream projects have moved. Again, from what I hear, ASF INFRA folks make the migration process fairly easy. What do you all think? Thanks Karthik
Re: [DISCUSS] Migrate from svn to git for source control?
Thanks for starting this thread Karthik! Big +1 from me. I only use svn when I have to commit things or work on the site, otherwise it's always the git mirror or local git repos. Considering that the git mirror works as well as it does, I'd expect this to be a pretty smooth transition. Best, Andrew On Fri, Aug 1, 2014 at 4:43 PM, Karthik Kambatla ka...@cloudera.com wrote: Hi folks, From what I hear, a lot of devs use the git mirror for development/reviews and use subversion primarily for checking code in. I was wondering if it would make more sense just to move to git. In addition to subjective liking of git, I see the following advantages in our workflow: 1. Feature branches - it becomes easier to work on them and keep rebasing against the latest trunk. 2. Cherry-picks between branches automatically ensures the exact same commit message and tracks the lineage as well. 3. When cutting new branches and/or updating maven versions etc., it allows doing all the work locally before pushing it to the main branch. 4. Opens us up to potentially using other code-review tools. (Gerrit?) 5. It is just more convenient. I am sure this was brought up before in different capacities. I believe the support for git in ASF is healthy now and several downstream projects have moved. Again, from what I hear, ASF INFRA folks make the migration process fairly easy. What do you all think? Thanks Karthik
Re: [DISCUSS] Migrate from svn to git for source control?
+1, we did it for Oozie a while back and was painless with minor issues in Jenkins jobs Rebasing feature branches on latest trunk may be tricky as that may require a force push and if I'm not mistaken force pushes are disabled in Apache GIT. thx On Fri, Aug 1, 2014 at 4:43 PM, Karthik Kambatla ka...@cloudera.com wrote: Hi folks, From what I hear, a lot of devs use the git mirror for development/reviews and use subversion primarily for checking code in. I was wondering if it would make more sense just to move to git. In addition to subjective liking of git, I see the following advantages in our workflow: 1. Feature branches - it becomes easier to work on them and keep rebasing against the latest trunk. 2. Cherry-picks between branches automatically ensures the exact same commit message and tracks the lineage as well. 3. When cutting new branches and/or updating maven versions etc., it allows doing all the work locally before pushing it to the main branch. 4. Opens us up to potentially using other code-review tools. (Gerrit?) 5. It is just more convenient. I am sure this was brought up before in different capacities. I believe the support for git in ASF is healthy now and several downstream projects have moved. Again, from what I hear, ASF INFRA folks make the migration process fairly easy. What do you all think? Thanks Karthik
