Re: Hi, about my experimental/VF2JS branch
Ok, in short: you're saying ALWAYS use rebase, so we get a nice flat 'history'? EdB On Fri, Jul 11, 2014 at 12:33 AM, Jose Barragan jose.barra...@codeoscopic.com wrote: Erik, The content in the two branches are exactly the same, but the new branch is composed by clean commits only, without any merge-commit in their change set. In your current branch, we have a serie of merge-commit in order to maintain the branch updated. Each of those commits contain all changes from develop at point where was created, collapsing on just one commit all relative change-set from develop until that point. In your case, the current branch has been contaminated with a partial changes from develop and your commits are less readable and reusables using this way. In other sort of things... when we use the git-merge as the only way, the complexity of commit tree, grows up exponentially. I hope that is helpful Best regards, __ Jose Barragan Senior Software Engineer Codeoscopic +34 912 94 80 80 http://www.codeoscopic.com On 10 Jul 2014, at 19:09, Erik de Bruin e...@ixsoftware.nl wrote: Jose, What is the difference between the 'experimental/VF2JS' and 'VF2JS' remote branches? EdB On Thu, Jul 10, 2014 at 6:18 PM, Jose Barragan jose.barra...@codeoscopic.com wrote: Hi Erik, Sorry about that, you're right. But after read the atlassian's article, I supposed that I hasn't any good reason to maintain the proposal alive, because seems as simply is one of two main flavours of work with git, even I keep on thinking that is the best, but maybe is just my point of view. Anyway, just now I remade again the “experimental/VF2JS” branch and push it. Thanks, __ Jose Barragan Senior Software Engineer Codeoscopic +34 912 94 80 80 http://www.codeoscopic.com On 10 Jul 2014, at 17:32, Erik de Bruin e...@ixsoftware.nl wrote: Jose, I'm not sure why you just now deleted the new branch you created? Like with your creation of it, that seems very sudden. I may still decide that your way is the way to go, but I need to understand first what I was doing wrong, and how your method is a better workflow. Everyone else, I'm just trying to understand how to work with git. @Fred: the wiki does not explain the use case where I'm working off a remotely published feature branch, I checked before I started. Since the wiki couldn't tell me what to do, I asked the question in this recent email thread: New Flex to JS project. I think I correctly implemented the most easy to follow instructions. So, first things first: what am I doing wrong in my workflow? EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: Hi, about my experimental/VF2JS branch
Hi Erik, Thats it, but… I recommend use of merge too, just for releases, hot-fixes y pull-request, due that those branches are in fact extremely dependents of their bases, but for normal developing (tickets, experimentals, etc…) the best is rebase way with git pull --rebase instead of git pull”. _ Jose Barragan Senior Software Engineer Codeoscopic +34 912 94 80 80 http://www.codeoscopic.com On 11 Jul 2014, at 09:03, Erik de Bruin e...@ixsoftware.nl wrote: Ok, in short: you're saying ALWAYS use rebase, so we get a nice flat 'history'? EdB
Re: Hi, about my experimental/VF2JS branch
I understand. I will default my IDE to always use rebase. I will keep working in my 'messed up' branch, if only to maintain a consistent naming across the 'flex-asjs', 'flex-falcon' and 'flex-sdk' repos. Thank you for your time and effort explaining this. I think I have learned something new about the use of git. EdB On Fri, Jul 11, 2014 at 10:03 AM, Jose Barragan jose.barra...@codeoscopic.com wrote: Hi Erik, Thats it, but… I recommend use of merge too, just for releases, hot-fixes y pull-request, due that those branches are in fact extremely dependents of their bases, but for normal developing (tickets, experimentals, etc…) the best is rebase way with git pull --rebase instead of git pull”. _ Jose Barragan Senior Software Engineer Codeoscopic +34 912 94 80 80 http://www.codeoscopic.com On 11 Jul 2014, at 09:03, Erik de Bruin e...@ixsoftware.nl wrote: Ok, in short: you're saying ALWAYS use rebase, so we get a nice flat 'history'? EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: Hi, about my experimental/VF2JS branch
Hi Erik, On 11 Jul 2014, at 10:22, Erik de Bruin e...@ixsoftware.nl wrote: I understand. I will default my IDE to always use rebase. I will keep working in my 'messed up' branch, if only to maintain a consistent naming across the 'flex-asjs', 'flex-falcon' and 'flex-sdk' repos. Great!, btw you could rename your current branch and the new branch, in order to switch their names each other, for maintain the coherence across all repos too. But, as you wish... Thank you for your time and effort explaining this. I think I have learned something new about the use of git. Thank you too, for your effort and interest. I feel happy with this. EdB __ Jose Barragan Senior Software Engineer Codeoscopic +34 912 94 80 80 http://www.codeoscopic.com
Re: Hi, about my experimental/VF2JS branch
Hi Erik, Nothing is really wrong there, is just for an philosophical criteria based on best practices of git. Currently, you and rest of apache flex team, maintains your branches updated using a commit merge node from latest commit on develop, isn’t it?. Well, this practice cause a big complexity on tree node and a messy traceability of branch content. I was proposing you another way, using a combination of git-rebase and git-merge operations, in order to use git-rebase onto develop to maintain your branch updated, and git-merge to apply the complete final change-set on develop when developing is finished. But, as I told you, it was a simple proposal only, and if you don't feel like to adopt it, just forget it and remove the proposed branch. I did the push to allow you can see the result of the proposed way vs your currently way at same time, on commits tree. Thanks, __ Jose Barragan Senior Software Engineer Codeoscopic +34 912 94 80 80 http://www.codeoscopic.com On 10 Jul 2014, at 07:29, Erik de Bruin e...@ixsoftware.nl wrote: José, I'm confused. What was I doing wrong that made this necessary? EdB On Thursday, July 10, 2014, Jose Barragan josebarra...@apache.org wrote: Hi Erik, While I was preparing to reactivate the maven branch of falcon's project, I have taken the opportunity to rebase your new branch VF2JS, onto the latest develop commit, with the intention that you get the new branch and could continue your develop on it, using “git rebase” to maintain your branch updated until the merge time. If you don’t feel happy with this proposal, feel free to completely remove it, but if you feel confortable with new branch and git practice, we can completely remove the old current branch version VS2JS. I was only tried to help, with our git usage on apache flex repositories. Thanks, __ *Jose Barragan* *Senior Software Engineer* *josebarra...@apache.org javascript:_e(%7B%7D,'cvml','josebarra...@apache.org');* -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: Hi, about my experimental/VF2JS branch
It was so much easier with SVN... Tom On 10/07/14 10:02, Jose Barragan wrote: Hi Erik, Nothing is really wrong there, is just for an philosophical criteria based on best practices of git. Currently, you and rest of apache flex team, maintains your branches updated using a commit merge node from latest commit on develop, isn’t it?. Well, this practice cause a big complexity on tree node and a messy traceability of branch content. I was proposing you another way, using a combination of git-rebase and git-merge operations, in order to use git-rebase onto develop to maintain your branch updated, and git-merge to apply the complete final change-set on develop when developing is finished. But, as I told you, it was a simple proposal only, and if you don't feel like to adopt it, just forget it and remove the proposed branch. I did the push to allow you can see the result of the proposed way vs your currently way at same time, on commits tree. Thanks, __ Jose Barragan Senior Software Engineer Codeoscopic +34 912 94 80 80 http://www.codeoscopic.com On 10 Jul 2014, at 07:29, Erik de Bruin e...@ixsoftware.nl wrote: José, I'm confused. What was I doing wrong that made this necessary? EdB On Thursday, July 10, 2014, Jose Barragan josebarra...@apache.org wrote: Hi Erik, While I was preparing to reactivate the maven branch of falcon's project, I have taken the opportunity to rebase your new branch VF2JS, onto the latest develop commit, with the intention that you get the new branch and could continue your develop on it, using “git rebase” to maintain your branch updated until the merge time. If you don’t feel happy with this proposal, feel free to completely remove it, but if you feel confortable with new branch and git practice, we can completely remove the old current branch version VS2JS. I was only tried to help, with our git usage on apache flex repositories. Thanks, __ *Jose Barragan* *Senior Software Engineer* *josebarra...@apache.org javascript:_e(%7B%7D,'cvml','josebarra...@apache.org');* -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl __ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com __
Re: Hi, about my experimental/VF2JS branch
Yeah!, It was even easier when we used an abacus ;) 2014-07-10 11:14 GMT+02:00 Tom Chiverton t...@extravision.com: It was so much easier with SVN... Tom On 10/07/14 10:02, Jose Barragan wrote: Hi Erik, Nothing is really wrong there, is just for an philosophical criteria based on best practices of git. Currently, you and rest of apache flex team, maintains your branches updated using a commit merge node from latest commit on develop, isn’t it?. Well, this practice cause a big complexity on tree node and a messy traceability of branch content. I was proposing you another way, using a combination of git-rebase and git-merge operations, in order to use git-rebase onto develop to maintain your branch updated, and git-merge to apply the complete final change-set on develop when developing is finished. But, as I told you, it was a simple proposal only, and if you don't feel like to adopt it, just forget it and remove the proposed branch. I did the push to allow you can see the result of the proposed way vs your currently way at same time, on commits tree. Thanks, __ Jose Barragan Senior Software Engineer Codeoscopic +34 912 94 80 80 http://www.codeoscopic.com On 10 Jul 2014, at 07:29, Erik de Bruin e...@ixsoftware.nl wrote: José, I'm confused. What was I doing wrong that made this necessary? EdB On Thursday, July 10, 2014, Jose Barragan josebarra...@apache.org wrote: Hi Erik, While I was preparing to reactivate the maven branch of falcon's project, I have taken the opportunity to rebase your new branch VF2JS, onto the latest develop commit, with the intention that you get the new branch and could continue your develop on it, using “git rebase” to maintain your branch updated until the merge time. If you don’t feel happy with this proposal, feel free to completely remove it, but if you feel confortable with new branch and git practice, we can completely remove the old current branch version VS2JS. I was only tried to help, with our git usage on apache flex repositories. Thanks, __ *Jose Barragan* *Senior Software Engineer* *josebarra...@apache.org javascript:_e(%7B%7D,'cvml','josebarra...@apache.org');* -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl __ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com __ -- Carlos Rovira Director de Tecnología M: +34 607 22 60 05 F: +34 912 94 80 80 http://www.codeoscopic.com http://www.directwriter.es http://www.avant2.es
Re: Hi, about my experimental/VF2JS branch
Thanks Chris, Regarding your recommendation Chris, follow this link to see it on UDemy: https://curiosity.com/courses/mccullough-and-berglund-on-mastering-git-udemy __ Jose Barragan Senior Software Engineer Codeoscopic +34 912 94 80 80 http://www.codeoscopic.com On 10 Jul 2014, at 11:37, Christofer Dutz christofer.d...@c-ware.de wrote: Usually there is a tight correlation between such statements and the lack of GIT knowledge. Sort of like the amount of the usage of the word stupid in scentances where somebody is talking about Maven ;-) And while noone will probably want to go back to Ant as soon as he has really understood Maven, you will love GIT as soon as you got the hang of it :-) I can certainly recommend the Video Tutorial McCullough and Berglund on Mastering Git to get up to speed with all of the new GIT stuff. Chris Von: Tom Chiverton t...@extravision.com Gesendet: Donnerstag, 10. Juli 2014 11:14 An: dev@flex.apache.org Betreff: Re: Hi, about my experimental/VF2JS branch It was so much easier with SVN... Tom On 10/07/14 10:02, Jose Barragan wrote: Hi Erik, Nothing is really wrong there, is just for an philosophical criteria based on best practices of git. Currently, you and rest of apache flex team, maintains your branches updated using a commit merge node from latest commit on develop, isn’t it?. Well, this practice cause a big complexity on tree node and a messy traceability of branch content. I was proposing you another way, using a combination of git-rebase and git-merge operations, in order to use git-rebase onto develop to maintain your branch updated, and git-merge to apply the complete final change-set on develop when developing is finished. But, as I told you, it was a simple proposal only, and if you don't feel like to adopt it, just forget it and remove the proposed branch. I did the push to allow you can see the result of the proposed way vs your currently way at same time, on commits tree. Thanks, __ Jose Barragan Senior Software Engineer Codeoscopic +34 912 94 80 80 http://www.codeoscopic.com On 10 Jul 2014, at 07:29, Erik de Bruin e...@ixsoftware.nl wrote: José, I'm confused. What was I doing wrong that made this necessary? EdB On Thursday, July 10, 2014, Jose Barragan josebarra...@apache.org wrote: Hi Erik, While I was preparing to reactivate the maven branch of falcon's project, I have taken the opportunity to rebase your new branch VF2JS, onto the latest develop commit, with the intention that you get the new branch and could continue your develop on it, using “git rebase” to maintain your branch updated until the merge time. If you don’t feel happy with this proposal, feel free to completely remove it, but if you feel confortable with new branch and git practice, we can completely remove the old current branch version VS2JS. I was only tried to help, with our git usage on apache flex repositories. Thanks, __ *Jose Barragan* *Senior Software Engineer* *josebarra...@apache.org javascript:_e(%7B%7D,'cvml','josebarra...@apache.org');* -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl __ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com __
Re: Hi, about my experimental/VF2JS branch
Took longer though :-) Tom On 10/07/14 10:42, Carlos Rovira wrote: Yeah!, It was even easier when we used an abacus ;) 2014-07-10 11:14 GMT+02:00 Tom Chiverton t...@extravision.com: It was so much easier with SVN... Tom On 10/07/14 10:02, Jose Barragan wrote: Hi Erik, Nothing is really wrong there, is just for an philosophical criteria based on best practices of git. Currently, you and rest of apache flex team, maintains your branches updated using a commit merge node from latest commit on develop, isn’t it?. Well, this practice cause a big complexity on tree node and a messy traceability of branch content. I was proposing you another way, using a combination of git-rebase and git-merge operations, in order to use git-rebase onto develop to maintain your branch updated, and git-merge to apply the complete final change-set on develop when developing is finished. But, as I told you, it was a simple proposal only, and if you don't feel like to adopt it, just forget it and remove the proposed branch. I did the push to allow you can see the result of the proposed way vs your currently way at same time, on commits tree. Thanks, __ Jose Barragan Senior Software Engineer Codeoscopic +34 912 94 80 80 http://www.codeoscopic.com On 10 Jul 2014, at 07:29, Erik de Bruin e...@ixsoftware.nl wrote: José, I'm confused. What was I doing wrong that made this necessary? EdB On Thursday, July 10, 2014, Jose Barragan josebarra...@apache.org wrote: Hi Erik, While I was preparing to reactivate the maven branch of falcon's project, I have taken the opportunity to rebase your new branch VF2JS, onto the latest develop commit, with the intention that you get the new branch and could continue your develop on it, using “git rebase” to maintain your branch updated until the merge time. If you don’t feel happy with this proposal, feel free to completely remove it, but if you feel confortable with new branch and git practice, we can completely remove the old current branch version VS2JS. I was only tried to help, with our git usage on apache flex repositories. Thanks, __ *Jose Barragan* *Senior Software Engineer* *josebarra...@apache.org javascript:_e(%7B%7D,'cvml','josebarra...@apache.org');* -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl __ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com __
Re: Hi, about my experimental/VF2JS branch
hehe :-) 2014-07-10 11:50 GMT+02:00 Tom Chiverton t...@extravision.com: Took longer though :-) Tom On 10/07/14 10:42, Carlos Rovira wrote: Yeah!, It was even easier when we used an abacus ;) 2014-07-10 11:14 GMT+02:00 Tom Chiverton t...@extravision.com: It was so much easier with SVN... Tom On 10/07/14 10:02, Jose Barragan wrote: Hi Erik, Nothing is really wrong there, is just for an philosophical criteria based on best practices of git. Currently, you and rest of apache flex team, maintains your branches updated using a commit merge node from latest commit on develop, isn’t it?. Well, this practice cause a big complexity on tree node and a messy traceability of branch content. I was proposing you another way, using a combination of git-rebase and git-merge operations, in order to use git-rebase onto develop to maintain your branch updated, and git-merge to apply the complete final change-set on develop when developing is finished. But, as I told you, it was a simple proposal only, and if you don't feel like to adopt it, just forget it and remove the proposed branch. I did the push to allow you can see the result of the proposed way vs your currently way at same time, on commits tree. Thanks, __ Jose Barragan Senior Software Engineer Codeoscopic +34 912 94 80 80 http://www.codeoscopic.com On 10 Jul 2014, at 07:29, Erik de Bruin e...@ixsoftware.nl wrote: José, I'm confused. What was I doing wrong that made this necessary? EdB On Thursday, July 10, 2014, Jose Barragan josebarra...@apache.org wrote: Hi Erik, While I was preparing to reactivate the maven branch of falcon's project, I have taken the opportunity to rebase your new branch VF2JS, onto the latest develop commit, with the intention that you get the new branch and could continue your develop on it, using “git rebase” to maintain your branch updated until the merge time. If you don’t feel happy with this proposal, feel free to completely remove it, but if you feel confortable with new branch and git practice, we can completely remove the old current branch version VS2JS. I was only tried to help, with our git usage on apache flex repositories. Thanks, __ *Jose Barragan* *Senior Software Engineer* *josebarra...@apache.org javascript:_e(%7B%7D,'cvml','josebarra...@apache.org');* -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl __ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com __ -- Carlos Rovira Director de Tecnología M: +34 607 22 60 05 F: +34 912 94 80 80 http://www.codeoscopic.com http://www.directwriter.es http://www.avant2.es
Re: Hi, about my experimental/VF2JS branch
Hi, Nothing is really wrong there, is just for an philosophical criteria based on best practices of git. Sorry but iMO it's not best practices, its just that a vocal group of git users think this it's the way to do things(tm) but other git users think otherwise. We also need to remember that have a central repo, need to apply with the Apache way of doing things and that can sometimes be at time odds with the git (or github) way of doing things. IMO Apache values traceability over a clean history. A good article about the pro and cons of merge and rebase can be found here [1], it's interesting to note the Atlasssian approach. Thanks, Justin 1. http://blogs.atlassian.com/2013/10/git-team-workflows-merge-or-rebase/
Re: Hi, about my experimental/VF2JS branch
Hi Justin, Under the new light from this article, I have anything else to say. Clearly I’m a rebase guy, over all, after suffering at our company the extremely complexity that we reached by using only the merge way. Well, as I told to @Erik, if my proposal didn't like it or didn't was candidate for adopt it, I'll delete it from repository asap. Thanks for your attention. Best regards, __ Jose Barragan Senior Software Engineer Codeoscopic +34 912 94 80 80 http://www.codeoscopic.com On 10 Jul 2014, at 15:37, Justin Mclean jus...@classsoftware.com wrote: Hi, Nothing is really wrong there, is just for an philosophical criteria based on best practices of git. Sorry but iMO it's not best practices, its just that a vocal group of git users think this it's the way to do things(tm) but other git users think otherwise. We also need to remember that have a central repo, need to apply with the Apache way of doing things and that can sometimes be at time odds with the git (or github) way of doing things. IMO Apache values traceability over a clean history. A good article about the pro and cons of merge and rebase can be found here [1], it's interesting to note the Atlasssian approach. Thanks, Justin 1. http://blogs.atlassian.com/2013/10/git-team-workflows-merge-or-rebase/
RE: Hi, about my experimental/VF2JS branch
If you and your team are not familiar with, or don’t understand the intricacies of rebase, then you probably shouldn’t use it. In this context, always merge is the safest option. That's what happen here despite my efforts to explain when and how to use rebase over merge (see the wiki) and my first main reason of being bored committing onto this repo over common stuffs. Frédéric THOMAS Subject: Re: Hi, about my experimental/VF2JS branch From: jose.barra...@codeoscopic.com Date: Thu, 10 Jul 2014 16:14:50 +0200 To: dev@flex.apache.org Hi Justin, Under the new light from this article, I have anything else to say. Clearly I’m a rebase guy, over all, after suffering at our company the extremely complexity that we reached by using only the merge way. Well, as I told to @Erik, if my proposal didn't like it or didn't was candidate for adopt it, I'll delete it from repository asap. Thanks for your attention. Best regards, __ Jose Barragan Senior Software Engineer Codeoscopic +34 912 94 80 80 http://www.codeoscopic.com On 10 Jul 2014, at 15:37, Justin Mclean jus...@classsoftware.com wrote: Hi, Nothing is really wrong there, is just for an philosophical criteria based on best practices of git. Sorry but iMO it's not best practices, its just that a vocal group of git users think this it's the way to do things(tm) but other git users think otherwise. We also need to remember that have a central repo, need to apply with the Apache way of doing things and that can sometimes be at time odds with the git (or github) way of doing things. IMO Apache values traceability over a clean history. A good article about the pro and cons of merge and rebase can be found here [1], it's interesting to note the Atlasssian approach. Thanks, Justin 1. http://blogs.atlassian.com/2013/10/git-team-workflows-merge-or-rebase/
Re: Hi, about my experimental/VF2JS branch
I'm with you @Jose and @Frederick. I remember that we was learning how to use GIT when Frederik wrote that article. and I think its the way to go. Many positive things, but as always it requires people to want to understand the git way. But if you try, you'll never go back. 2014-07-10 16:53 GMT+02:00 Frédéric THOMAS webdoubl...@hotmail.com: If you and your team are not familiar with, or don’t understand the intricacies of rebase, then you probably shouldn’t use it. In this context, always merge is the safest option. That's what happen here despite my efforts to explain when and how to use rebase over merge (see the wiki) and my first main reason of being bored committing onto this repo over common stuffs. Frédéric THOMAS Subject: Re: Hi, about my experimental/VF2JS branch From: jose.barra...@codeoscopic.com Date: Thu, 10 Jul 2014 16:14:50 +0200 To: dev@flex.apache.org Hi Justin, Under the new light from this article, I have anything else to say. Clearly I’m a rebase guy, over all, after suffering at our company the extremely complexity that we reached by using only the merge way. Well, as I told to @Erik, if my proposal didn't like it or didn't was candidate for adopt it, I'll delete it from repository asap. Thanks for your attention. Best regards, __ Jose Barragan Senior Software Engineer Codeoscopic +34 912 94 80 80 http://www.codeoscopic.com On 10 Jul 2014, at 15:37, Justin Mclean jus...@classsoftware.com wrote: Hi, Nothing is really wrong there, is just for an philosophical criteria based on best practices of git. Sorry but iMO it's not best practices, its just that a vocal group of git users think this it's the way to do things(tm) but other git users think otherwise. We also need to remember that have a central repo, need to apply with the Apache way of doing things and that can sometimes be at time odds with the git (or github) way of doing things. IMO Apache values traceability over a clean history. A good article about the pro and cons of merge and rebase can be found here [1], it's interesting to note the Atlasssian approach. Thanks, Justin 1. http://blogs.atlassian.com/2013/10/git-team-workflows-merge-or-rebase/ -- Carlos Rovira Director de Tecnología M: +34 607 22 60 05 F: +34 912 94 80 80 http://www.codeoscopic.com http://www.directwriter.es http://www.avant2.es
Re: Hi, about my experimental/VF2JS branch
Jose, I'm not sure why you just now deleted the new branch you created? Like with your creation of it, that seems very sudden. I may still decide that your way is the way to go, but I need to understand first what I was doing wrong, and how your method is a better workflow. Everyone else, I'm just trying to understand how to work with git. @Fred: the wiki does not explain the use case where I'm working off a remotely published feature branch, I checked before I started. Since the wiki couldn't tell me what to do, I asked the question in this recent email thread: New Flex to JS project. I think I correctly implemented the most easy to follow instructions. So, first things first: what am I doing wrong in my workflow? EdB On Thu, Jul 10, 2014 at 5:15 PM, Carlos Rovira carlos.rov...@codeoscopic.com wrote: I'm with you @Jose and @Frederick. I remember that we was learning how to use GIT when Frederik wrote that article. and I think its the way to go. Many positive things, but as always it requires people to want to understand the git way. But if you try, you'll never go back. 2014-07-10 16:53 GMT+02:00 Frédéric THOMAS webdoubl...@hotmail.com: If you and your team are not familiar with, or don’t understand the intricacies of rebase, then you probably shouldn’t use it. In this context, always merge is the safest option. That's what happen here despite my efforts to explain when and how to use rebase over merge (see the wiki) and my first main reason of being bored committing onto this repo over common stuffs. Frédéric THOMAS Subject: Re: Hi, about my experimental/VF2JS branch From: jose.barra...@codeoscopic.com Date: Thu, 10 Jul 2014 16:14:50 +0200 To: dev@flex.apache.org Hi Justin, Under the new light from this article, I have anything else to say. Clearly I’m a rebase guy, over all, after suffering at our company the extremely complexity that we reached by using only the merge way. Well, as I told to @Erik, if my proposal didn't like it or didn't was candidate for adopt it, I'll delete it from repository asap. Thanks for your attention. Best regards, __ Jose Barragan Senior Software Engineer Codeoscopic +34 912 94 80 80 http://www.codeoscopic.com On 10 Jul 2014, at 15:37, Justin Mclean jus...@classsoftware.com wrote: Hi, Nothing is really wrong there, is just for an philosophical criteria based on best practices of git. Sorry but iMO it's not best practices, its just that a vocal group of git users think this it's the way to do things(tm) but other git users think otherwise. We also need to remember that have a central repo, need to apply with the Apache way of doing things and that can sometimes be at time odds with the git (or github) way of doing things. IMO Apache values traceability over a clean history. A good article about the pro and cons of merge and rebase can be found here [1], it's interesting to note the Atlasssian approach. Thanks, Justin 1. http://blogs.atlassian.com/2013/10/git-team-workflows-merge-or-rebase/ -- Carlos Rovira Director de Tecnología M: +34 607 22 60 05 F: +34 912 94 80 80 http://www.codeoscopic.com http://www.directwriter.es http://www.avant2.es -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
RE: Hi, about my experimental/VF2JS branch
Hi Erik, I was only answering the 2 previous emails, nothing relative to what you or Jose did because I hadn't got a look at it but from what it wrote, he just updated your Branch from what has been done in develop, doing so, you can continue to work knowing that what others did on the develop branch doesn't break anything, a common process on long lived topic branches. I haven't seen how Jose did it but if you need, it is explain here [1] under the section Easy commit: (From a feature/bugfix branch 2/2) Frédéric THOMAS[1] https://cwiki.apache.org/confluence/display/FLEX/Good+vs+Bad+Git+usage From: e...@ixsoftware.nl Date: Thu, 10 Jul 2014 17:32:31 +0200 Subject: Re: Hi, about my experimental/VF2JS branch To: dev@flex.apache.org Jose, I'm not sure why you just now deleted the new branch you created? Like with your creation of it, that seems very sudden. I may still decide that your way is the way to go, but I need to understand first what I was doing wrong, and how your method is a better workflow. Everyone else, I'm just trying to understand how to work with git. @Fred: the wiki does not explain the use case where I'm working off a remotely published feature branch, I checked before I started. Since the wiki couldn't tell me what to do, I asked the question in this recent email thread: New Flex to JS project. I think I correctly implemented the most easy to follow instructions. So, first things first: what am I doing wrong in my workflow? EdB On Thu, Jul 10, 2014 at 5:15 PM, Carlos Rovira carlos.rov...@codeoscopic.com wrote: I'm with you @Jose and @Frederick. I remember that we was learning how to use GIT when Frederik wrote that article. and I think its the way to go. Many positive things, but as always it requires people to want to understand the git way. But if you try, you'll never go back. 2014-07-10 16:53 GMT+02:00 Frédéric THOMAS webdoubl...@hotmail.com: If you and your team are not familiar with, or don’t understand the intricacies of rebase, then you probably shouldn’t use it. In this context, always merge is the safest option. That's what happen here despite my efforts to explain when and how to use rebase over merge (see the wiki) and my first main reason of being bored committing onto this repo over common stuffs. Frédéric THOMAS Subject: Re: Hi, about my experimental/VF2JS branch From: jose.barra...@codeoscopic.com Date: Thu, 10 Jul 2014 16:14:50 +0200 To: dev@flex.apache.org Hi Justin, Under the new light from this article, I have anything else to say. Clearly I’m a rebase guy, over all, after suffering at our company the extremely complexity that we reached by using only the merge way. Well, as I told to @Erik, if my proposal didn't like it or didn't was candidate for adopt it, I'll delete it from repository asap. Thanks for your attention. Best regards, __ Jose Barragan Senior Software Engineer Codeoscopic +34 912 94 80 80 http://www.codeoscopic.com On 10 Jul 2014, at 15:37, Justin Mclean jus...@classsoftware.com wrote: Hi, Nothing is really wrong there, is just for an philosophical criteria based on best practices of git. Sorry but iMO it's not best practices, its just that a vocal group of git users think this it's the way to do things(tm) but other git users think otherwise. We also need to remember that have a central repo, need to apply with the Apache way of doing things and that can sometimes be at time odds with the git (or github) way of doing things. IMO Apache values traceability over a clean history. A good article about the pro and cons of merge and rebase can be found here [1], it's interesting to note the Atlasssian approach. Thanks, Justin 1. http://blogs.atlassian.com/2013/10/git-team-workflows-merge-or-rebase/ -- Carlos Rovira Director de Tecnología M: +34 607 22 60 05 F: +34 912 94 80 80 http://www.codeoscopic.com http://www.directwriter.es http://www.avant2.es -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: Hi, about my experimental/VF2JS branch
Hi Erik, Sorry about that, you're right. But after read the atlassian's article, I supposed that I hasn't any good reason to maintain the proposal alive, because seems as simply is one of two main flavours of work with git, even I keep on thinking that is the best, but maybe is just my point of view. Anyway, just now I remade again the “experimental/VF2JS” branch and push it. Thanks, __ Jose Barragan Senior Software Engineer Codeoscopic +34 912 94 80 80 http://www.codeoscopic.com On 10 Jul 2014, at 17:32, Erik de Bruin e...@ixsoftware.nl wrote: Jose, I'm not sure why you just now deleted the new branch you created? Like with your creation of it, that seems very sudden. I may still decide that your way is the way to go, but I need to understand first what I was doing wrong, and how your method is a better workflow. Everyone else, I'm just trying to understand how to work with git. @Fred: the wiki does not explain the use case where I'm working off a remotely published feature branch, I checked before I started. Since the wiki couldn't tell me what to do, I asked the question in this recent email thread: New Flex to JS project. I think I correctly implemented the most easy to follow instructions. So, first things first: what am I doing wrong in my workflow? EdB
Re: Hi, about my experimental/VF2JS branch
Rebase and merge both make sense depending on the situation. No need to have a hard and fast rule about it. This conversation is moot if folks don't understand Git properly. Let's give it time, no point in forcing this new. Thanks, Om On Jul 10, 2014 9:19 AM, Jose Barragan jose.barra...@codeoscopic.com wrote: Hi Erik, Sorry about that, you're right. But after read the atlassian's article, I supposed that I hasn't any good reason to maintain the proposal alive, because seems as simply is one of two main flavours of work with git, even I keep on thinking that is the best, but maybe is just my point of view. Anyway, just now I remade again the “experimental/VF2JS” branch and push it. Thanks, __ Jose Barragan Senior Software Engineer Codeoscopic +34 912 94 80 80 http://www.codeoscopic.com On 10 Jul 2014, at 17:32, Erik de Bruin e...@ixsoftware.nl wrote: Jose, I'm not sure why you just now deleted the new branch you created? Like with your creation of it, that seems very sudden. I may still decide that your way is the way to go, but I need to understand first what I was doing wrong, and how your method is a better workflow. Everyone else, I'm just trying to understand how to work with git. @Fred: the wiki does not explain the use case where I'm working off a remotely published feature branch, I checked before I started. Since the wiki couldn't tell me what to do, I asked the question in this recent email thread: New Flex to JS project. I think I correctly implemented the most easy to follow instructions. So, first things first: what am I doing wrong in my workflow? EdB
Re: Hi, about my experimental/VF2JS branch
Jose, What is the difference between the 'experimental/VF2JS' and 'VF2JS' remote branches? EdB On Thu, Jul 10, 2014 at 6:18 PM, Jose Barragan jose.barra...@codeoscopic.com wrote: Hi Erik, Sorry about that, you're right. But after read the atlassian's article, I supposed that I hasn't any good reason to maintain the proposal alive, because seems as simply is one of two main flavours of work with git, even I keep on thinking that is the best, but maybe is just my point of view. Anyway, just now I remade again the “experimental/VF2JS” branch and push it. Thanks, __ Jose Barragan Senior Software Engineer Codeoscopic +34 912 94 80 80 http://www.codeoscopic.com On 10 Jul 2014, at 17:32, Erik de Bruin e...@ixsoftware.nl wrote: Jose, I'm not sure why you just now deleted the new branch you created? Like with your creation of it, that seems very sudden. I may still decide that your way is the way to go, but I need to understand first what I was doing wrong, and how your method is a better workflow. Everyone else, I'm just trying to understand how to work with git. @Fred: the wiki does not explain the use case where I'm working off a remotely published feature branch, I checked before I started. Since the wiki couldn't tell me what to do, I asked the question in this recent email thread: New Flex to JS project. I think I correctly implemented the most easy to follow instructions. So, first things first: what am I doing wrong in my workflow? EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: Hi, about my experimental/VF2JS branch
Erik, The content in the two branches are exactly the same, but the new branch is composed by clean commits only, without any merge-commit in their change set. In your current branch, we have a serie of merge-commit in order to maintain the branch updated. Each of those commits contain all changes from develop at point where was created, collapsing on just one commit all relative change-set from develop until that point. In your case, the current branch has been contaminated with a partial changes from develop and your commits are less readable and reusables using this way. In other sort of things... when we use the git-merge as the only way, the complexity of commit tree, grows up exponentially. I hope that is helpful Best regards, __ Jose Barragan Senior Software Engineer Codeoscopic +34 912 94 80 80 http://www.codeoscopic.com On 10 Jul 2014, at 19:09, Erik de Bruin e...@ixsoftware.nl wrote: Jose, What is the difference between the 'experimental/VF2JS' and 'VF2JS' remote branches? EdB On Thu, Jul 10, 2014 at 6:18 PM, Jose Barragan jose.barra...@codeoscopic.com wrote: Hi Erik, Sorry about that, you're right. But after read the atlassian's article, I supposed that I hasn't any good reason to maintain the proposal alive, because seems as simply is one of two main flavours of work with git, even I keep on thinking that is the best, but maybe is just my point of view. Anyway, just now I remade again the “experimental/VF2JS” branch and push it. Thanks, __ Jose Barragan Senior Software Engineer Codeoscopic +34 912 94 80 80 http://www.codeoscopic.com On 10 Jul 2014, at 17:32, Erik de Bruin e...@ixsoftware.nl wrote: Jose, I'm not sure why you just now deleted the new branch you created? Like with your creation of it, that seems very sudden. I may still decide that your way is the way to go, but I need to understand first what I was doing wrong, and how your method is a better workflow. Everyone else, I'm just trying to understand how to work with git. @Fred: the wiki does not explain the use case where I'm working off a remotely published feature branch, I checked before I started. Since the wiki couldn't tell me what to do, I asked the question in this recent email thread: New Flex to JS project. I think I correctly implemented the most easy to follow instructions. So, first things first: what am I doing wrong in my workflow? EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: Hi, about my experimental/VF2JS branch
José, I'm confused. What was I doing wrong that made this necessary? EdB On Thursday, July 10, 2014, Jose Barragan josebarra...@apache.org wrote: Hi Erik, While I was preparing to reactivate the maven branch of falcon's project, I have taken the opportunity to rebase your new branch VF2JS, onto the latest develop commit, with the intention that you get the new branch and could continue your develop on it, using “git rebase” to maintain your branch updated until the merge time. If you don’t feel happy with this proposal, feel free to completely remove it, but if you feel confortable with new branch and git practice, we can completely remove the old current branch version VS2JS. I was only tried to help, with our git usage on apache flex repositories. Thanks, __ *Jose Barragan* *Senior Software Engineer* *josebarra...@apache.org javascript:_e(%7B%7D,'cvml','josebarra...@apache.org');* -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
