Re: [Git/Wiki] please review the proposed workflow and comment
Updated the FAQ [1], thank you to review, especially for my English. Thanks, -Fred [1] https://cwiki.apache.org/confluence/display/FLEX/Git+for+Apache+Flex+Guide -Message d'origine- From: Frédéric THOMAS Sent: Monday, March 25, 2013 7:02 PM To: dev@flex.apache.org Subject: Re: [Git/Wiki] please review the proposed workflow and comment Also, in the first scenario, it might be important to explain that you pushed your README change before Justin tried to push. You might need a two-column timeline to show what commands happened when. Arff, I don't like my last incomplete response, so the best way is that I'll have to create an other topic where I show how to create a bare shared repo and clones. -Fred -Message d'origine- From: Frédéric THOMAS Sent: Monday, March 25, 2013 6:53 PM To: dev@flex.apache.org Subject: Re: [Git/Wiki] please review the proposed workflow and comment I looked at your good/bad wiki page. Thanks for taking the time to add pictures. For me, instead of labeling things good and bad, it might be better to have an explanation or picture of the longer-term ramifications of each sequence and why one sequence is recommended. Ok, my next topic will be that showing up how it can be messy after only 3 commits. For example, I get that in the first scenario history gets flattened, but why does it really matter? And why, later, when you merge your branch, do you not want it flattened? Why will we all be glad some day that the history is flattened in certain cases but not others? It might be simple to think that working on the develop branch makes flattened because only one commit at time and working on a branch create a parallel line which shows that merged branch. Also, in the first scenario, it might be important to explain that you pushed your README change before Justin tried to push. You might need a two-column timeline to show what commands happened when. Actually, the Justin repo has this README at creation time, mine too, it's because it's not easily possible to keep an empty branch in Git, that's the reason why, but sure, I could have explained it. Thanks, -Fred -Message d'origine- From: Alex Harui Sent: Monday, March 25, 2013 6:40 PM To: dev@flex.apache.org Subject: Re: [Git/Wiki] please review the proposed workflow and comment Hi Fred, I looked at your good/bad wiki page. Thanks for taking the time to add pictures. For me, instead of labeling things good and bad, it might be better to have an explanation or picture of the longer-term ramifications of each sequence and why one sequence is recommended. For example, I get that in the first scenario history gets flattened, but why does it really matter? And why, later, when you merge your branch, do you not want it flattened? Why will we all be glad some day that the history is flattened in certain cases but not others? Also, in the first scenario, it might be important to explain that you pushed your README change before Justin tried to push. You might need a two-column timeline to show what commands happened when. Thanks, -Alex On 3/25/13 10:14 AM, Frédéric THOMAS webdoubl...@hotmail.com wrote: To me, many of the reasons you are favoring the rebase workflow is so that people can't accidently mess up a merge (and yes, it can keep the history cleaner) Yes, that's meanly that, it will work except if people doesn't want to push right after the merge, in this rare case, it's better to use 'git rebase -p' instead of 'git pull --rebase', that's the only exception, almost of the time people will push as there are no reason to not do it, the 'git pull --rebase' method will be enough, people can trust it and it's simple to use, no headaches due to how git works inside, that's the reason why I wrote this workflow on the main git wiki page, I think it is adapted at what we do here. In a more general way, I want to show more examples like managing conflicts, git undo (reverse / reset / reflog undo / checkout), collaboration, etc... which are technical particularities but useful to know. In a more particular one, the workflow and the doc for the release. Thanks Mike, -Fred -Message d'origine- From: Michael A. Labriola Sent: Monday, March 25, 2013 5:43 PM To: dev@flex.apache.org Subject: RE: [Git/Wiki] please review the proposed workflow and comment Ok, so, yes, it has been discussed on this list with the conclusion it wasn't feasible by INFRA but one one asked them. Okay, that's fine if the people here decided it was infeasible I can accept that. Sometimes I think we just solve the wrong problems and I was wondering if that was the case here. To me, many of the reasons you are favoring the rebase workflow is so that people can't accidently mess up a merge (and yes, it can keep the history cleaner). Places like the Linux kernel don't have that issue because people are effectively working in their own repo with a limited number of people actually
Re: [Git/Wiki] please review the proposed workflow and comment
Hi Alex, Does that [1] correspond better to what you described you wanted ? Thanks, -Fred [1] https://cwiki.apache.org/confluence/display/FLEX/Good+vs+Bad+Git+usage -Message d'origine- From: Alex Harui Sent: Sunday, March 24, 2013 5:39 AM To: dev@flex.apache.org Subject: Re: [Git/Wiki] please review the proposed workflow and comment Hi Guys, Sorry for writing in this late in your discussion. I really appreciate the time you both are putting into this. I finally got a chance to look at the wiki page. IMO, if you want to simplify, I think the first thing I would put on the wiki is the update the readme workflow. Most of us coming from SVN are not going to get the advantages of a branch right away and I think we've all agreed that it isn't always required. But after that, it seems like it would be better to explain the advantages of Git rather than trying to come up with a works most of the time solution that tries to make it so we don't have to learn key points about Git. I'd rather see links to the best example elsewhere on the net or short stories as to what rebase does, or why cutting a branch saved your ass, along with steps to do it and what those steps are doing. Git seems powerful enough that if you don't know what you are doing you can make a lot of work for yourself or others. And you can just link from this wiki to each of your own pages with your own workflows and commands instead of having to reach agreement. Just like there is some wiggle room in coding style it looks like there is some wiggle room in git style and, while that bugs me, I can live with it. I learned the finer aspects of writing code from several folks with different styles and I'm happy to learn the finer aspects of Git from several folks with different styles. If we all worked in the same room, I'd be asking Fred, how do you do this and Mike would overhear and offer his opinion and then I'd try one or both and learn something from it. On 3/23/13 5:38 PM, Frédéric THOMAS webdoubl...@hotmail.com wrote: Okay, I have a long plane flight tomorrow I thought you had a cape !?#** :-) -Fred -Message d'origine- From: Michael A. Labriola Sent: Sunday, March 24, 2013 1:33 AM To: dev@flex.apache.org Subject: RE: [Git/Wiki] please review the proposed workflow and comment Yes please. Okay, I have a long plane flight tomorrow. I will try to write something up so I can send it when I land. No problem, it just a talk, you and me want the best for Apache Flex. Thanks. Looking forward to figuring this out and helping everyone else get comfortable with git Mike -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
RE: [Git/Wiki] please review the proposed workflow and comment
I re-organized a bit to make it visually clearer but still, I guess it can be better and the text better written than with my words, I'm opened to see your suggestions. Okay, so, here is where we disagree. I do not think what you labeled as Bad is bad. It's not bad to me, it's an accurate depiction of what happened in git. The rebase on the other hand is rewriting history to make it seem linear when it *was not*. So, before saying we _want_ a linear history, let's discuss why. Mike
RE: [Git/Wiki] please review the proposed workflow and comment
I'm not sure what you mean talking about fork and repo, I might be wrong but that's more a GitHub concept to me but there's the concept of spare checkouts, it means, once you cloned the entirely repo, you can filter the directories you want to see which will make Git working easier, I mean with less memory. Fred, A fork is basically a server side clone. So, there is a server side repository belonging to the committers. We may not want to do this. I was asking if it had been discussed or considered rather than a branch approach for things like whiteboards. Mike
Re: [Git/Wiki] please review the proposed workflow and comment
Hi Mike, Sure, it can be discussed. So, I think that what I write after you has to be written after what you write and my own experience with no-linear commit history tells me it shouldn't be done, it becomes quickly messy. Thanks, -Fred -Message d'origine- From: Michael A. Labriola Sent: Monday, March 25, 2013 4:45 PM To: dev@flex.apache.org Subject: RE: [Git/Wiki] please review the proposed workflow and comment I re-organized a bit to make it visually clearer but still, I guess it can be better and the text better written than with my words, I'm opened to see your suggestions. Okay, so, here is where we disagree. I do not think what you labeled as Bad is bad. It's not bad to me, it's an accurate depiction of what happened in git. The rebase on the other hand is rewriting history to make it seem linear when it *was not*. So, before saying we _want_ a linear history, let's discuss why. Mike
RE: [Git/Wiki] please review the proposed workflow and comment
So, I think that what I write after you has to be written after what you write and my own experience with no-linear commit history tells me it shouldn't be done, it becomes quickly messy. I am just going to go through each of your examples (which are very well done) and show my thoughts on each and why I think rebasing should be done extremely infrequently. Mike
Re: [Git/Wiki] please review the proposed workflow and comment
Mike, Ok, so, yes, it has been discussed on this list with the conclusion it wasn't feasible by INFRA but one one asked them. AFAIK, it's technically possible to do it using git-svn to create users repo and then sharable bares repo (and there're maybe more direct ways to do it) but not possible from an existing git repo though. But what for new committers, should the INFRA create a new repo each time ? -Fred -Message d'origine- From: Michael A. Labriola Sent: Monday, March 25, 2013 4:47 PM To: dev@flex.apache.org Subject: RE: [Git/Wiki] please review the proposed workflow and comment I'm not sure what you mean talking about fork and repo, I might be wrong but that's more a GitHub concept to me but there's the concept of spare checkouts, it means, once you cloned the entirely repo, you can filter the directories you want to see which will make Git working easier, I mean with less memory. Fred, A fork is basically a server side clone. So, there is a server side repository belonging to the committers. We may not want to do this. I was asking if it had been discussed or considered rather than a branch approach for things like whiteboards. Mike
RE: [Git/Wiki] please review the proposed workflow and comment
Ok, so, yes, it has been discussed on this list with the conclusion it wasn't feasible by INFRA but one one asked them. Okay, that's fine if the people here decided it was infeasible I can accept that. Sometimes I think we just solve the wrong problems and I was wondering if that was the case here. To me, many of the reasons you are favoring the rebase workflow is so that people can't accidently mess up a merge (and yes, it can keep the history cleaner). Places like the Linux kernel don't have that issue because people are effectively working in their own repo with a limited number of people actually merging up into develop and managing master. It also makes the scenarios that I was describing to Alex, code reviewing someone's changes, jumping back and forth in time, all more feasible. Without it, we really do have everyone pushing their branches back into the same repo, etc. and it does feel (as several people have pointed out) like a more complicated SVN. Just thinking aloud. Mike
Re: [Git/Wiki] please review the proposed workflow and comment
To me, many of the reasons you are favoring the rebase workflow is so that people can't accidently mess up a merge (and yes, it can keep the history cleaner) Yes, that's meanly that, it will work except if people doesn't want to push right after the merge, in this rare case, it's better to use 'git rebase -p' instead of 'git pull --rebase', that's the only exception, almost of the time people will push as there are no reason to not do it, the 'git pull --rebase' method will be enough, people can trust it and it's simple to use, no headaches due to how git works inside, that's the reason why I wrote this workflow on the main git wiki page, I think it is adapted at what we do here. In a more general way, I want to show more examples like managing conflicts, git undo (reverse / reset / reflog undo / checkout), collaboration, etc... which are technical particularities but useful to know. In a more particular one, the workflow and the doc for the release. Thanks Mike, -Fred -Message d'origine- From: Michael A. Labriola Sent: Monday, March 25, 2013 5:43 PM To: dev@flex.apache.org Subject: RE: [Git/Wiki] please review the proposed workflow and comment Ok, so, yes, it has been discussed on this list with the conclusion it wasn't feasible by INFRA but one one asked them. Okay, that's fine if the people here decided it was infeasible I can accept that. Sometimes I think we just solve the wrong problems and I was wondering if that was the case here. To me, many of the reasons you are favoring the rebase workflow is so that people can't accidently mess up a merge (and yes, it can keep the history cleaner). Places like the Linux kernel don't have that issue because people are effectively working in their own repo with a limited number of people actually merging up into develop and managing master. It also makes the scenarios that I was describing to Alex, code reviewing someone's changes, jumping back and forth in time, all more feasible. Without it, we really do have everyone pushing their branches back into the same repo, etc. and it does feel (as several people have pointed out) like a more complicated SVN. Just thinking aloud. Mike
Re: [Git/Wiki] please review the proposed workflow and comment
Mike, Btw, for what I'm about to do as described previously, I'll be happy if you can review and say your point of view / way to do it. Cheers, -Fred -Message d'origine- From: Frédéric THOMAS Sent: Monday, March 25, 2013 6:14 PM To: dev@flex.apache.org Subject: Re: [Git/Wiki] please review the proposed workflow and comment To me, many of the reasons you are favoring the rebase workflow is so that people can't accidently mess up a merge (and yes, it can keep the history cleaner) Yes, that's meanly that, it will work except if people doesn't want to push right after the merge, in this rare case, it's better to use 'git rebase -p' instead of 'git pull --rebase', that's the only exception, almost of the time people will push as there are no reason to not do it, the 'git pull --rebase' method will be enough, people can trust it and it's simple to use, no headaches due to how git works inside, that's the reason why I wrote this workflow on the main git wiki page, I think it is adapted at what we do here. In a more general way, I want to show more examples like managing conflicts, git undo (reverse / reset / reflog undo / checkout), collaboration, etc... which are technical particularities but useful to know. In a more particular one, the workflow and the doc for the release. Thanks Mike, -Fred -Message d'origine- From: Michael A. Labriola Sent: Monday, March 25, 2013 5:43 PM To: dev@flex.apache.org Subject: RE: [Git/Wiki] please review the proposed workflow and comment Ok, so, yes, it has been discussed on this list with the conclusion it wasn't feasible by INFRA but one one asked them. Okay, that's fine if the people here decided it was infeasible I can accept that. Sometimes I think we just solve the wrong problems and I was wondering if that was the case here. To me, many of the reasons you are favoring the rebase workflow is so that people can't accidently mess up a merge (and yes, it can keep the history cleaner). Places like the Linux kernel don't have that issue because people are effectively working in their own repo with a limited number of people actually merging up into develop and managing master. It also makes the scenarios that I was describing to Alex, code reviewing someone's changes, jumping back and forth in time, all more feasible. Without it, we really do have everyone pushing their branches back into the same repo, etc. and it does feel (as several people have pointed out) like a more complicated SVN. Just thinking aloud. Mike
Re: [Git/Wiki] please review the proposed workflow and comment
Hi Fred, I looked at your good/bad wiki page. Thanks for taking the time to add pictures. For me, instead of labeling things good and bad, it might be better to have an explanation or picture of the longer-term ramifications of each sequence and why one sequence is recommended. For example, I get that in the first scenario history gets flattened, but why does it really matter? And why, later, when you merge your branch, do you not want it flattened? Why will we all be glad some day that the history is flattened in certain cases but not others? Also, in the first scenario, it might be important to explain that you pushed your README change before Justin tried to push. You might need a two-column timeline to show what commands happened when. Thanks, -Alex On 3/25/13 10:14 AM, Frédéric THOMAS webdoubl...@hotmail.com wrote: To me, many of the reasons you are favoring the rebase workflow is so that people can't accidently mess up a merge (and yes, it can keep the history cleaner) Yes, that's meanly that, it will work except if people doesn't want to push right after the merge, in this rare case, it's better to use 'git rebase -p' instead of 'git pull --rebase', that's the only exception, almost of the time people will push as there are no reason to not do it, the 'git pull --rebase' method will be enough, people can trust it and it's simple to use, no headaches due to how git works inside, that's the reason why I wrote this workflow on the main git wiki page, I think it is adapted at what we do here. In a more general way, I want to show more examples like managing conflicts, git undo (reverse / reset / reflog undo / checkout), collaboration, etc... which are technical particularities but useful to know. In a more particular one, the workflow and the doc for the release. Thanks Mike, -Fred -Message d'origine- From: Michael A. Labriola Sent: Monday, March 25, 2013 5:43 PM To: dev@flex.apache.org Subject: RE: [Git/Wiki] please review the proposed workflow and comment Ok, so, yes, it has been discussed on this list with the conclusion it wasn't feasible by INFRA but one one asked them. Okay, that's fine if the people here decided it was infeasible I can accept that. Sometimes I think we just solve the wrong problems and I was wondering if that was the case here. To me, many of the reasons you are favoring the rebase workflow is so that people can't accidently mess up a merge (and yes, it can keep the history cleaner). Places like the Linux kernel don't have that issue because people are effectively working in their own repo with a limited number of people actually merging up into develop and managing master. It also makes the scenarios that I was describing to Alex, code reviewing someone's changes, jumping back and forth in time, all more feasible. Without it, we really do have everyone pushing their branches back into the same repo, etc. and it does feel (as several people have pointed out) like a more complicated SVN. Just thinking aloud. Mike -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
Re: [Git/Wiki] please review the proposed workflow and comment
I looked at your good/bad wiki page. Thanks for taking the time to add pictures. For me, instead of labeling things good and bad, it might be better to have an explanation or picture of the longer-term ramifications of each sequence and why one sequence is recommended. Ok, my next topic will be that showing up how it can be messy after only 3 commits. For example, I get that in the first scenario history gets flattened, but why does it really matter? And why, later, when you merge your branch, do you not want it flattened? Why will we all be glad some day that the history is flattened in certain cases but not others? It might be simple to think that working on the develop branch makes flattened because only one commit at time and working on a branch create a parallel line which shows that merged branch. Also, in the first scenario, it might be important to explain that you pushed your README change before Justin tried to push. You might need a two-column timeline to show what commands happened when. Actually, the Justin repo has this README at creation time, mine too, it's because it's not easily possible to keep an empty branch in Git, that's the reason why, but sure, I could have explained it. Thanks, -Fred -Message d'origine- From: Alex Harui Sent: Monday, March 25, 2013 6:40 PM To: dev@flex.apache.org Subject: Re: [Git/Wiki] please review the proposed workflow and comment Hi Fred, I looked at your good/bad wiki page. Thanks for taking the time to add pictures. For me, instead of labeling things good and bad, it might be better to have an explanation or picture of the longer-term ramifications of each sequence and why one sequence is recommended. For example, I get that in the first scenario history gets flattened, but why does it really matter? And why, later, when you merge your branch, do you not want it flattened? Why will we all be glad some day that the history is flattened in certain cases but not others? Also, in the first scenario, it might be important to explain that you pushed your README change before Justin tried to push. You might need a two-column timeline to show what commands happened when. Thanks, -Alex On 3/25/13 10:14 AM, Frédéric THOMAS webdoubl...@hotmail.com wrote: To me, many of the reasons you are favoring the rebase workflow is so that people can't accidently mess up a merge (and yes, it can keep the history cleaner) Yes, that's meanly that, it will work except if people doesn't want to push right after the merge, in this rare case, it's better to use 'git rebase -p' instead of 'git pull --rebase', that's the only exception, almost of the time people will push as there are no reason to not do it, the 'git pull --rebase' method will be enough, people can trust it and it's simple to use, no headaches due to how git works inside, that's the reason why I wrote this workflow on the main git wiki page, I think it is adapted at what we do here. In a more general way, I want to show more examples like managing conflicts, git undo (reverse / reset / reflog undo / checkout), collaboration, etc... which are technical particularities but useful to know. In a more particular one, the workflow and the doc for the release. Thanks Mike, -Fred -Message d'origine- From: Michael A. Labriola Sent: Monday, March 25, 2013 5:43 PM To: dev@flex.apache.org Subject: RE: [Git/Wiki] please review the proposed workflow and comment Ok, so, yes, it has been discussed on this list with the conclusion it wasn't feasible by INFRA but one one asked them. Okay, that's fine if the people here decided it was infeasible I can accept that. Sometimes I think we just solve the wrong problems and I was wondering if that was the case here. To me, many of the reasons you are favoring the rebase workflow is so that people can't accidently mess up a merge (and yes, it can keep the history cleaner). Places like the Linux kernel don't have that issue because people are effectively working in their own repo with a limited number of people actually merging up into develop and managing master. It also makes the scenarios that I was describing to Alex, code reviewing someone's changes, jumping back and forth in time, all more feasible. Without it, we really do have everyone pushing their branches back into the same repo, etc. and it does feel (as several people have pointed out) like a more complicated SVN. Just thinking aloud. Mike -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
Re: [Git/Wiki] please review the proposed workflow and comment
Also, in the first scenario, it might be important to explain that you pushed your README change before Justin tried to push. You might need a two-column timeline to show what commands happened when. Arff, I don't like my last incomplete response, so the best way is that I'll have to create an other topic where I show how to create a bare shared repo and clones. -Fred -Message d'origine- From: Frédéric THOMAS Sent: Monday, March 25, 2013 6:53 PM To: dev@flex.apache.org Subject: Re: [Git/Wiki] please review the proposed workflow and comment I looked at your good/bad wiki page. Thanks for taking the time to add pictures. For me, instead of labeling things good and bad, it might be better to have an explanation or picture of the longer-term ramifications of each sequence and why one sequence is recommended. Ok, my next topic will be that showing up how it can be messy after only 3 commits. For example, I get that in the first scenario history gets flattened, but why does it really matter? And why, later, when you merge your branch, do you not want it flattened? Why will we all be glad some day that the history is flattened in certain cases but not others? It might be simple to think that working on the develop branch makes flattened because only one commit at time and working on a branch create a parallel line which shows that merged branch. Also, in the first scenario, it might be important to explain that you pushed your README change before Justin tried to push. You might need a two-column timeline to show what commands happened when. Actually, the Justin repo has this README at creation time, mine too, it's because it's not easily possible to keep an empty branch in Git, that's the reason why, but sure, I could have explained it. Thanks, -Fred -Message d'origine- From: Alex Harui Sent: Monday, March 25, 2013 6:40 PM To: dev@flex.apache.org Subject: Re: [Git/Wiki] please review the proposed workflow and comment Hi Fred, I looked at your good/bad wiki page. Thanks for taking the time to add pictures. For me, instead of labeling things good and bad, it might be better to have an explanation or picture of the longer-term ramifications of each sequence and why one sequence is recommended. For example, I get that in the first scenario history gets flattened, but why does it really matter? And why, later, when you merge your branch, do you not want it flattened? Why will we all be glad some day that the history is flattened in certain cases but not others? Also, in the first scenario, it might be important to explain that you pushed your README change before Justin tried to push. You might need a two-column timeline to show what commands happened when. Thanks, -Alex On 3/25/13 10:14 AM, Frédéric THOMAS webdoubl...@hotmail.com wrote: To me, many of the reasons you are favoring the rebase workflow is so that people can't accidently mess up a merge (and yes, it can keep the history cleaner) Yes, that's meanly that, it will work except if people doesn't want to push right after the merge, in this rare case, it's better to use 'git rebase -p' instead of 'git pull --rebase', that's the only exception, almost of the time people will push as there are no reason to not do it, the 'git pull --rebase' method will be enough, people can trust it and it's simple to use, no headaches due to how git works inside, that's the reason why I wrote this workflow on the main git wiki page, I think it is adapted at what we do here. In a more general way, I want to show more examples like managing conflicts, git undo (reverse / reset / reflog undo / checkout), collaboration, etc... which are technical particularities but useful to know. In a more particular one, the workflow and the doc for the release. Thanks Mike, -Fred -Message d'origine- From: Michael A. Labriola Sent: Monday, March 25, 2013 5:43 PM To: dev@flex.apache.org Subject: RE: [Git/Wiki] please review the proposed workflow and comment Ok, so, yes, it has been discussed on this list with the conclusion it wasn't feasible by INFRA but one one asked them. Okay, that's fine if the people here decided it was infeasible I can accept that. Sometimes I think we just solve the wrong problems and I was wondering if that was the case here. To me, many of the reasons you are favoring the rebase workflow is so that people can't accidently mess up a merge (and yes, it can keep the history cleaner). Places like the Linux kernel don't have that issue because people are effectively working in their own repo with a limited number of people actually merging up into develop and managing master. It also makes the scenarios that I was describing to Alex, code reviewing someone's changes, jumping back and forth in time, all more feasible. Without it, we really do have everyone pushing their branches back into the same repo, etc. and it does feel (as several people have pointed out) like a more
Re: [Git/Wiki] please review the proposed workflow and comment
As I am digging further into this though, I am coming up with a lot of questions. I am guessing, based on the fact that I am seeing whiteboards, etc. that committers don't really have their own forks in our current apache model, but rather everyone is using their own clone of the same fork. Am I right? Is there a particular reason we went this way? You are right and they just copied the whiteboards into one git repo. What to do with Whiteboard? 1. Use the sparse checkout option as described here ( http://markmail.org/message/dg7hplezkzwiroes) 2. Create a branch per user in the whiteboard 3. Move to github for whiteboards 4. Let whiteboards remain in SVN None of the above solutions suits me, my requirement would be (as it should from the Git model), not only to have one repo per person but one per project (people might have several projects in their whiteboard) which is not feasible, not even one per person as someone 'guessed', the only way I can see to reach it's requirement, is to stay in Svn and do and git-svn over the project you want to have a git equivalent if you really want it as git-svn is very slow to initialize. Thanks, -Fred -Message d'origine- From: Michael A. Labriola Sent: Sunday, March 24, 2013 6:48 AM To: dev@flex.apache.org Subject: RE: [Git/Wiki] please review the proposed workflow and comment I'd rather see links to the best example elsewhere on the net or short stories as to what rebase does, or why cutting a branch saved your ass, along with steps to do it and what those steps are doing. Git seems powerful enough that if you don't know what you are doing you can make a lot of work for yourself or others. Alex, Agreed. I think we will get there. Fred, As I am digging further into this though, I am coming up with a lot of questions. I am guessing, based on the fact that I am seeing whiteboards, etc. that committers don't really have their own forks in our current apache model, but rather everyone is using their own clone of the same fork. Am I right? Is there a particular reason we went this way? I am just trying to understand so I can do my best to guide us within the model that has been created. There could be many viable reasons for this but to me, right now, it's a little strange for a git project, so I am just trying to grok it all. This would change some of the advice I gave Alex, for example. Mike
Re: [Git/Wiki] please review the proposed workflow and comment
Hi, Would you mind if I wrote up a proposed alternate that doesn't use rebase and eliminate fast forwards? Yes, it will mean there is an extra 'useless' commit... which I don't actually always find useless, but I think it simpler. Then let's just discuss. +1 to at least considering this. Justin
Re: [Git/Wiki] please review the proposed workflow and comment
+ 1 on starting out simple and keeping the message clear. When needed, or as a suggested way to work for those who have a better than noob level understanding of git, I think we should keep the rebase workflow in the wiki. Furthermore, we should write up as much of this discussion in the wiki as we can, for future reference. EdB On Sun, Mar 24, 2013 at 10:04 AM, Justin Mclean jus...@classsoftware.com wrote: Hi, Would you mind if I wrote up a proposed alternate that doesn't use rebase and eliminate fast forwards? Yes, it will mean there is an extra 'useless' commit... which I don't actually always find useless, but I think it simpler. Then let's just discuss. +1 to at least considering this. Justin -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: [Git/Wiki] please review the proposed workflow and comment
Hi Guys, Just to say I created a new page on the wiki [1] to demonstrate Good vs Bad scenarios / Git usage, I'll fill it with more complex scenarios over the time. It can be reviewed too :) Thanks, -Fred [1] https://cwiki.apache.org/confluence/display/FLEX/Good+vs+Bad+Git+usage -Message d'origine- From: Erik de Bruin Sent: Sunday, March 24, 2013 11:51 AM To: dev@flex.apache.org Subject: Re: [Git/Wiki] please review the proposed workflow and comment + 1 on starting out simple and keeping the message clear. When needed, or as a suggested way to work for those who have a better than noob level understanding of git, I think we should keep the rebase workflow in the wiki. Furthermore, we should write up as much of this discussion in the wiki as we can, for future reference. EdB On Sun, Mar 24, 2013 at 10:04 AM, Justin Mclean jus...@classsoftware.com wrote: Hi, Would you mind if I wrote up a proposed alternate that doesn't use rebase and eliminate fast forwards? Yes, it will mean there is an extra 'useless' commit... which I don't actually always find useless, but I think it simpler. Then let's just discuss. +1 to at least considering this. Justin -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: [Git/Wiki] please review the proposed workflow and comment
Folks, During the review of [1] you'll probably do, I've got no doubts the explanation parts I wrote with my English will not be grammatically correct, I hope anyway, that will be understandable, feel free to make me some proposals to improve it, that will save headaches for the others. Thanks, -Fred [1] https://cwiki.apache.org/confluence/display/FLEX/Good+vs+Bad+Git+usage -Message d'origine- From: Frédéric THOMAS Sent: Sunday, March 24, 2013 2:43 PM To: dev@flex.apache.org Subject: Re: [Git/Wiki] please review the proposed workflow and comment Hi Guys, Just to say I created a new page on the wiki [1] to demonstrate Good vs Bad scenarios / Git usage, I'll fill it with more complex scenarios over the time. It can be reviewed too :) Thanks, -Fred [1] https://cwiki.apache.org/confluence/display/FLEX/Good+vs+Bad+Git+usage -Message d'origine- From: Erik de Bruin Sent: Sunday, March 24, 2013 11:51 AM To: dev@flex.apache.org Subject: Re: [Git/Wiki] please review the proposed workflow and comment + 1 on starting out simple and keeping the message clear. When needed, or as a suggested way to work for those who have a better than noob level understanding of git, I think we should keep the rebase workflow in the wiki. Furthermore, we should write up as much of this discussion in the wiki as we can, for future reference. EdB On Sun, Mar 24, 2013 at 10:04 AM, Justin Mclean jus...@classsoftware.com wrote: Hi, Would you mind if I wrote up a proposed alternate that doesn't use rebase and eliminate fast forwards? Yes, it will mean there is an extra 'useless' commit... which I don't actually always find useless, but I think it simpler. Then let's just discuss. +1 to at least considering this. Justin -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: [Git/Wiki] please review the proposed workflow and comment
Sorry, I meant sparse checkouts :P Me and my English... -Fred -Message d'origine- From: Frédéric THOMAS Sent: Sunday, March 24, 2013 9:34 PM To: dev@flex.apache.org Subject: Re: [Git/Wiki] please review the proposed workflow and comment Hi Mike, I'm not sure what you mean talking about fork and repo, I might be wrong but that's more a GitHub concept to me but there's the concept of spare checkouts, it means, once you cloned the entirely repo, you can filter the directories you want to see which will make Git working easier, I mean with less memory. Before I go further, is that what you're talking about ? -Fred -Message d'origine- From: Michael A. Labriola Sent: Sunday, March 24, 2013 9:16 PM To: dev@flex.apache.org Subject: RE: [Git/Wiki] please review the proposed workflow and comment None of the above solutions suits me, my requirement would be (as it should from the Git model), not only to have one repo per person but one per project (people might have several projects in their whiteboard) Fred, Out of curiosity, and I am sorry if this was discussed in another thread, is there anything from an infrastructure perspective that is stopping commiters from having forks of the main repo? Effectively the concept of a whiteboard is more or less redundant to me if people were using their own forks. Mike
Re: [Git/Wiki] please review the proposed workflow and comment
HI, Out of curiosity, and I am sorry if this was discussed in another thread, is there anything from an infrastructure perspective that is stopping commiters from having forks of the main repo? Effectively the concept of a whiteboard is more or less redundant to me if people were using their own forks. Issue here is that the whiteboard area is an unstructured playground, it may follow the structure of another repo or it may have it's own structure. Justin
Re: [Git/Wiki] please review the proposed workflow and comment
Hi, With 1. what happens if you do a pull before the commit like so: echo Create File1 File1 git add File1 git pull git commit -m Added File1 git push Justin
Re: [Git/Wiki] please review the proposed workflow and comment
Hi Justin, --- With 1. what happens if you do a pull before the commit like so: echo Create File1 File1 git add File1 git pull git commit -m Added File1 git push --- Nothing in this case as nothing happened remotely. Btw, I just did a git update + refacto that's the reason why I haven't see your post before. -Fred -Message d'origine- From: Justin Mclean Sent: Sunday, March 24, 2013 11:18 PM To: dev@flex.apache.org Subject: Re: [Git/Wiki] please review the proposed workflow and comment Hi, With 1. what happens if you do a pull before the commit like so: echo Create File1 File1 git add File1 git pull git commit -m Added File1 git push Justin
Re: [Git/Wiki] please review the proposed workflow and comment
I mean the pull does not anything. -Fred -Message d'origine- From: Frédéric THOMAS Sent: Monday, March 25, 2013 12:50 AM To: dev@flex.apache.org Subject: Re: [Git/Wiki] please review the proposed workflow and comment Hi Justin, --- With 1. what happens if you do a pull before the commit like so: echo Create File1 File1 git add File1 git pull git commit -m Added File1 git push --- Nothing in this case as nothing happened remotely. Btw, I just did a git update + refacto that's the reason why I haven't see your post before. -Fred -Message d'origine- From: Justin Mclean Sent: Sunday, March 24, 2013 11:18 PM To: dev@flex.apache.org Subject: Re: [Git/Wiki] please review the proposed workflow and comment Hi, With 1. what happens if you do a pull before the commit like so: echo Create File1 File1 git add File1 git pull git commit -m Added File1 git push Justin
Re: [Git/Wiki] please review the proposed workflow and comment
Hi, I mean the pull does not anything. The pull would do a fetch and then merge in the README change wouldn't it? Justin
Re: [Git/Wiki] please review the proposed workflow and comment
I guess you're talking about the really 1rst case ? Then, yes but nothing changed remotely, so, it doesn't pull anything. -Fred -Message d'origine- From: Justin Mclean Sent: Monday, March 25, 2013 1:05 AM To: dev@flex.apache.org Subject: Re: [Git/Wiki] please review the proposed workflow and comment Hi, I mean the pull does not anything. The pull would do a fetch and then merge in the README change wouldn't it? Justin
Re: [Git/Wiki] please review the proposed workflow and comment
Btw, even after the commit, it doesn't do anything and for the same reason, the point is as you used to do with Svn, you do an update before doing a commit, to check if there are conflicts. -Fred -Message d'origine- From: Frédéric THOMAS Sent: Monday, March 25, 2013 1:09 AM To: dev@flex.apache.org Subject: Re: [Git/Wiki] please review the proposed workflow and comment I guess you're talking about the really 1rst case ? Then, yes but nothing changed remotely, so, it doesn't pull anything. -Fred -Message d'origine- From: Justin Mclean Sent: Monday, March 25, 2013 1:05 AM To: dev@flex.apache.org Subject: Re: [Git/Wiki] please review the proposed workflow and comment Hi, I mean the pull does not anything. The pull would do a fetch and then merge in the README change wouldn't it? Justin
Re: [Git/Wiki] please review the proposed workflow and comment
Hi, Btw, even after the commit, it doesn't do anything and for the same reason, the point is as you used to do with Svn, you do an update before doing a commit, to check if there are conflicts. I assume you mean do a pull to merge any changes before you do a push? I don't see why you would want to do a pull before every local commit and in fact it may not be possible if you are offline. Justin
Re: [Git/Wiki] please review the proposed workflow and comment
You right, I meant a git push talking about svn commit. -Fred -Message d'origine- From: Justin Mclean Sent: Monday, March 25, 2013 1:20 AM To: dev@flex.apache.org Subject: Re: [Git/Wiki] please review the proposed workflow and comment Hi, Btw, even after the commit, it doesn't do anything and for the same reason, the point is as you used to do with Svn, you do an update before doing a commit, to check if there are conflicts. I assume you mean do a pull to merge any changes before you do a push? I don't see why you would want to do a pull before every local commit and in fact it may not be possible if you are offline. Justin
Re: [Git/Wiki] please review the proposed workflow and comment
Hi guys, I just a bit updated the git wiki [1], can you review it pls ? - Answered some the FAQs - Added Git configuration info - Added the case where time has elapsed between the merge and the push + some more details. Thanks, -Fred [1] https://cwiki.apache.org/confluence/display/FLEX/Git+for+Apache+Flex+Guide -Message d'origine- From: Erik de Bruin Sent: Friday, March 22, 2013 12:02 PM To: dev@flex.apache.org Subject: [Git/Wiki] please review the proposed workflow and comment Hi, Fred and I (mainly Fred) have written a proposed project specific workflow in the wiki [1]. Can anyone please review and comment (here or on the wiki page, preferably here)? Thanks! 1: -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
RE: [Git/Wiki] please review the proposed workflow and comment
I just a bit updated the git wiki [1], can you review it pls ? - Answered some the FAQs - Added Git configuration info - Added the case where time has elapsed between the merge and the push + some more details. Hi guys, A couple of things. I might have missed the reason why, but it seems like there is a perforce tool coded into the sample gitconfig. Reason? Regarding the working on code section. I think I see where some of the confusion comes from on the rebase thing. If, when you wanted to work on code, people just did either a pull (or a fetch + merge) on develop into their develop branch first. Then made their branch, they could skip that rebase step, which IMO is a positive thing especially when you are starting out... Regarding Step 2. So, this is sounding a little SVNish. Its not wrong by any means, but usually when people work with git, they are checking in a lot. So, I basically do it anytime I make any viable change.. so, step 2 and 3 repeat a lot for me. Regarding step 4, and I am sorry I didn't follow this earlier, is there a reason we are so concerned with rebasing right now? On Step 5, any particular reason we are using non-fast forward? Step 8 is optional if you wish, but I usually keep my branches around so I can visit changes again in the future in isolation. I will review the FAQ in another hour or so. Mike
Re: [Git/Wiki] please review the proposed workflow and comment
Hi Mike, Thanks for reviewing that, turning back on it I've seen that the step 5 of Initial setup should be the step 1 of Working on the code (bad rewrite, I'm going to take care of that right after I wrote this post :P ) First of all, I use pull with the rebasing option to keep my work on top of what the others already pushed until there's no issues for my local merges. Regarding the working on code section. I think I see where some of the confusion comes from on the rebase thing. If, when you wanted to work on code, people just did either a pull (or a fetch + merge) on develop into their develop branch first. Then made their branch, they could skip that rebase step, which IMO is a positive thing especially when you are starting out... Yes, it might have been an option but I preferred to rebase to make people to get the habit of getting the others' commits before starting a working session, making the eventual conflicts resolved first. Regarding Step 2. So, this is sounding a little SVNish. Its not wrong by any means, but usually when people work with git, they are checking in a lot. So, I basically do it anytime I make any viable change.. so, step 2 and 3 repeat a lot for me. How would you have write it so ? Regarding step 4, and I am sorry I didn't follow this earlier, is there a reason we are so concerned with rebasing right now? I generaly do a pull --rebase + git merge --no-ff + push in the same stream to avoid git rebase -p, which, in case of conflict would make me create an extra commit in more than the merge commit for the same feature/bugfix, with rebasing first solution, I can resolve the conflict, rebase again and then have a merge up to date relative to the main stream. On Step 5, any particular reason we are using non-fast forward? Yep, not every branches will be remote, most of the time, they're going to stay local, so, the merge commit allow to have a distinct line on the graph history log. Step 8 is optional if you wish, but I usually keep my branches around so I can visit changes again in the future in isolation. Good point, it has to be mentioned ! Thanks, -Fred -Message d'origine- From: Michael A. Labriola Sent: Saturday, March 23, 2013 6:20 PM To: dev@flex.apache.org Subject: RE: [Git/Wiki] please review the proposed workflow and comment I just a bit updated the git wiki [1], can you review it pls ? - Answered some the FAQs - Added Git configuration info - Added the case where time has elapsed between the merge and the push + some more details. Hi guys, A couple of things. I might have missed the reason why, but it seems like there is a perforce tool coded into the sample gitconfig. Reason? Regarding the working on code section. I think I see where some of the confusion comes from on the rebase thing. If, when you wanted to work on code, people just did either a pull (or a fetch + merge) on develop into their develop branch first. Then made their branch, they could skip that rebase step, which IMO is a positive thing especially when you are starting out... Regarding Step 2. So, this is sounding a little SVNish. Its not wrong by any means, but usually when people work with git, they are checking in a lot. So, I basically do it anytime I make any viable change.. so, step 2 and 3 repeat a lot for me. Regarding step 4, and I am sorry I didn't follow this earlier, is there a reason we are so concerned with rebasing right now? On Step 5, any particular reason we are using non-fast forward? Step 8 is optional if you wish, but I usually keep my branches around so I can visit changes again in the future in isolation. I will review the FAQ in another hour or so. Mike
Re: [Git/Wiki] please review the proposed workflow and comment
Mike, One more point, that's true that in some situations, less steps could be required, my point was to create a workflow that works in most of the cases without to think too much, I guess with the experience, folks will be able to manage the workflow as the situation require, at the moment, I guess, this one can reach simple and more complicated situations by itself, I would like to show how to work in collaboration (remote branches) too later, if you want to give a hand, I would appreciate it. Thanks, -Fred -Message d'origine- From: Frédéric THOMAS Sent: Saturday, March 23, 2013 6:52 PM To: dev@flex.apache.org Subject: Re: [Git/Wiki] please review the proposed workflow and comment Hi Mike, Thanks for reviewing that, turning back on it I've seen that the step 5 of Initial setup should be the step 1 of Working on the code (bad rewrite, I'm going to take care of that right after I wrote this post :P ) First of all, I use pull with the rebasing option to keep my work on top of what the others already pushed until there's no issues for my local merges. Regarding the working on code section. I think I see where some of the confusion comes from on the rebase thing. If, when you wanted to work on code, people just did either a pull (or a fetch + merge) on develop into their develop branch first. Then made their branch, they could skip that rebase step, which IMO is a positive thing especially when you are starting out... Yes, it might have been an option but I preferred to rebase to make people to get the habit of getting the others' commits before starting a working session, making the eventual conflicts resolved first. Regarding Step 2. So, this is sounding a little SVNish. Its not wrong by any means, but usually when people work with git, they are checking in a lot. So, I basically do it anytime I make any viable change.. so, step 2 and 3 repeat a lot for me. How would you have write it so ? Regarding step 4, and I am sorry I didn't follow this earlier, is there a reason we are so concerned with rebasing right now? I generaly do a pull --rebase + git merge --no-ff + push in the same stream to avoid git rebase -p, which, in case of conflict would make me create an extra commit in more than the merge commit for the same feature/bugfix, with rebasing first solution, I can resolve the conflict, rebase again and then have a merge up to date relative to the main stream. On Step 5, any particular reason we are using non-fast forward? Yep, not every branches will be remote, most of the time, they're going to stay local, so, the merge commit allow to have a distinct line on the graph history log. Step 8 is optional if you wish, but I usually keep my branches around so I can visit changes again in the future in isolation. Good point, it has to be mentioned ! Thanks, -Fred -Message d'origine- From: Michael A. Labriola Sent: Saturday, March 23, 2013 6:20 PM To: dev@flex.apache.org Subject: RE: [Git/Wiki] please review the proposed workflow and comment I just a bit updated the git wiki [1], can you review it pls ? - Answered some the FAQs - Added Git configuration info - Added the case where time has elapsed between the merge and the push + some more details. Hi guys, A couple of things. I might have missed the reason why, but it seems like there is a perforce tool coded into the sample gitconfig. Reason? Regarding the working on code section. I think I see where some of the confusion comes from on the rebase thing. If, when you wanted to work on code, people just did either a pull (or a fetch + merge) on develop into their develop branch first. Then made their branch, they could skip that rebase step, which IMO is a positive thing especially when you are starting out... Regarding Step 2. So, this is sounding a little SVNish. Its not wrong by any means, but usually when people work with git, they are checking in a lot. So, I basically do it anytime I make any viable change.. so, step 2 and 3 repeat a lot for me. Regarding step 4, and I am sorry I didn't follow this earlier, is there a reason we are so concerned with rebasing right now? On Step 5, any particular reason we are using non-fast forward? Step 8 is optional if you wish, but I usually keep my branches around so I can visit changes again in the future in isolation. I will review the FAQ in another hour or so. Mike
Re: [Git/Wiki] please review the proposed workflow and comment
Mike, I forgot one of your point. I might have missed the reason why, but it seems like there is a perforce tool coded into the sample gitconfig. Reason? That's only an example of how you can configure a external merge tool on a windows machine, I use P4Merge because it suits me, any other might apply, I just shown how it stands in the .gitconfig. If someone want to you WinMerge, just replace: [merge] tool = p4merge [mergetool p4merge] path = C:\\Program Files\\Perforce\\p4merge.exe by [merge] tool = winmerge [mergetool winmerge] path = PATH_TO WINMERGE\\winmerge.exe Thanks, -Fred
RE: [Git/Wiki] please review the proposed workflow and comment
That's only an example of how you can configure a external merge tool on a windows machine, I use P4Merge because it suits me, any other might apply, I just shown how it stands in the .gitconfig. I know, just wondering if we should show it commented out so that others don't copy and paste and cause themselves issues. Mike
RE: [Git/Wiki] please review the proposed workflow and comment
Sorry of you get multiple copies of this. I keep getting bounce messages. I messed up and sent a draft in my last response. I didn't want it to be more confusing, so, if you can. Read me instead: First of all, I use pull with the rebasing option to keep my work on top of what the others already pushed until there's no issues for my local merges. that's not actually what rebase is doing. Rebase is rewriting the commit history so it looks nice. It's not required to keep changes merged Yes, it might have been an option but I preferred to rebase to make people to get the habit of getting the others' commits before starting a working session, making the eventual conflicts resolved first. That was my point too... However doing so with pull (or fetch+merge)does the same thing, without the crazy flags or potential for really bad results. I am just saying that's not really what rebase is doing for us here so I am favoring the simpler approach. How would you have write it so ? I will write up something and post I generaly do a pull --rebase + git merge --no-ff + push in the same stream to avoid git rebase -p, which, in case of conflict would make me create an extra commit in more than the merge commit for the same feature/bugfix, with rebasing first solution, I can resolve the conflict, rebase again and then have a merge up to date relative to the main stream. Okay, although honestly, that seems a little bit like running before we walk. All we are saving is, at most an extra commit to indicate the merge and forcing people to understand rebase. Understand what I mean?
Re: [Git/Wiki] please review the proposed workflow and comment
that's not actually what rebase is doing. Rebase is rewriting the commit history so it looks nice. It doesn't have anything to do with keeping changes merged You right, Rebase is rewriting the commit history so it looks nice and so, if you have a local merged commit, it will be erased [1] by this operation. Okay, although honestly, that seems a little bit like running before we walk. All we are saving is, at most an extra commit to indicate the merge and forcing people to understand rebase. Understand what I mean? If conflicts occurs, the only way to not create an useless extra commit in more than the merge commit, it to use the command set pull --rebase + git merge --no-ff + push [2], if for some reasons, the committer has to wait between the merge and the push and that the reason why I added this one step, it can successfully update/resolve conficts using git rebase -p and then push [3]. Okay, although honestly, that seems a little bit like running before we walk. All we are saving is, at most an extra commit to indicate the merge and forcing people to understand rebase. Understand what I mean? As I said before, at least at the beginning, I wouldn't like committers new in git have a chance to run into problems and in the same time I wouldn't like they have to think to much about what should he use in that situation, that's the reason why I created this workflow and for sure if there is a better way to achieve this, amen. -Fred [1] Clone 1: 1- I checkout a new branch test1 2- I created a file test1.txt 3- I add/commit test1.txt 4- I checkout master 5- I merged --no-ff test1 Clone 2: 1- I created a file file1.txt 2- I add/commit file1.txt 3- git push Clone 1: 1- I pull --rebase [2] Clone 1: 1- I checkout a new branch test1 2- echo file1 edited by clone 1 file1.txt 2- I created a file test1.txt 3- I add/commit test1.txt Clone 2: 1- echo file1 edited by clone 2 file1.txt 2- I add/commit file1.txt 3- I push Clone 1: 1- git pull --rebase 2- resole the conflicts creating an extra commit that's going to be included in the same dev line than the all dev. 5- I checkout master 6- git push [3] Clone 1: 1- I checkout a new branch test1 2- echo file1 edited by clone 1 file1.txt 2- I created a file test1.txt 3- I add/commit test1.txt 5- I checkout master 6- I merged --no-ff test1 Clone 2: 1- echo file1 edited by clone 2 file1.txt 2- I add/commit file1.txt 3- I push Clone 1: 1- git pull --rebase 2- resole the conflicts creating an extra commit in more than the one of the merged commit. 3- git push -Message d'origine- From: Michael A. Labriola Sent: Sunday, March 24, 2013 12:14 AM To: dev@flex.apache.org Subject: RE: [Git/Wiki] please review the proposed workflow and comment First of all, I use pull with the rebasing option to keep my work on top of what the others already pushed until there's no issues for my local merges. that's not actually what rebase is doing. Rebase is rewriting the commit history so it looks nice. It doesn't have anything to do with keeping changes merged Yes, it might have been an option but I preferred to rebase to make people to get the habit of getting the others' commits before starting a working session, making the eventual conflicts resolved first. That was my point too... I am just saying that's not really what rebase is doing How would you have write it so ? I will write up something and post I generaly do a pull --rebase + git merge --no-ff + push in the same stream to avoid git rebase -p, which, in case of conflict would make me create an extra commit in more than the merge commit for the same feature/bugfix, with rebasing first solution, I can resolve the conflict, rebase again and then have a merge up to date relative to the main stream. Okay, although honestly, that seems a little bit like running before we walk. All we are saving is, at most an extra commit to indicate the merge and forcing people to understand rebase. Understand what I mean?
RE: [Git/Wiki] please review the proposed workflow and comment
Yes, only if there's nothing to merge, as soon as the remote HEAD is ahead of my branch HEAD, I'll have an extra merge commit I don't want in order to keep a clean, linear and readable history. We just disagree. How shall we proceed?
Re: [Git/Wiki] please review the proposed workflow and comment
It is exactly what I want too while I want it works in every situations, I guess it is good you here because you've got some git experiences and the respect of the committers and it's good we can discuss those Git points to make them clearer. Thanks, -Fred -Message d'origine- From: Michael A. Labriola Sent: Sunday, March 24, 2013 12:15 AM To: dev@flex.apache.org Subject: RE: [Git/Wiki] please review the proposed workflow and comment I would like to show how to work in collaboration (remote branches) too later, if you want to give a hand, I would appreciate it. I am happy to give a hand but I would like you to consider the idea of keeping the steps maybe a little simpler at the expense of clean merge lines for right now. Let's at least discuss it.
RE: [Git/Wiki] please review the proposed workflow and comment
As I said before, at least at the beginning, I wouldn't like committers new in git have a chance to run into problems and in the same time I wouldn't like they have to think to much about what should he use in that situation, that's the reason why I created this workflow and for sure if there is a better way to achieve this, amen. Would you mind if I wrote up a proposed alternate that doesn't use rebase and eliminate fast forwards? Yes, it will mean there is an extra 'useless' commit... which I don't actually always find useless, but I think it simpler. Then let's just discuss. I am not trying to assert my opinion over yours and you clearly did a lot of work to get us here. Just trying to offer some approaches since there is clearly confusion among the people using it, and I think some of it, in my opinion, is that we are showing something more complicated than is strictly necessary and I don't see the advantages outweighing the disadvantages. I would love to work on this with you if you are interested, Mike
Re: [Git/Wiki] please review the proposed workflow and comment
We just disagree. How shall we proceed? In what do you disagree, in what I'm technically stating or the fact I thing is better to have a clean, linear and readable history for the cost of not even an extra step if they follow the guideline ? I can create a simulation with 1 bare repo and 2 clones to demonstrate my point if needed ? -Fred -Message d'origine- From: Michael A. Labriola Sent: Sunday, March 24, 2013 1:15 AM To: dev@flex.apache.org Subject: RE: [Git/Wiki] please review the proposed workflow and comment Yes, only if there's nothing to merge, as soon as the remote HEAD is ahead of my branch HEAD, I'll have an extra merge commit I don't want in order to keep a clean, linear and readable history. We just disagree. How shall we proceed?
RE: [Git/Wiki] please review the proposed workflow and comment
In what do you disagree, in what I'm technically stating or the fact I thing is better to have a clean, linear and readable history for the cost of not even an extra step if they follow the guideline ? I can create a simulation with 1 bare repo and 2 clones to demonstrate my point if needed ? My bandwidth is just slow tonight and so my emails are lagging. So for any confusion. Ignore this and you will see my other post which is an offer to write up an alternative we can mutually consider and discuss. Thanks for your patience, Mike
RE: [Git/Wiki] please review the proposed workflow and comment
Yes please. Okay, I have a long plane flight tomorrow. I will try to write something up so I can send it when I land. No problem, it just a talk, you and me want the best for Apache Flex. Thanks. Looking forward to figuring this out and helping everyone else get comfortable with git Mike
Re: [Git/Wiki] please review the proposed workflow and comment
Okay, I have a long plane flight tomorrow I thought you had a cape !?#** :-) -Fred -Message d'origine- From: Michael A. Labriola Sent: Sunday, March 24, 2013 1:33 AM To: dev@flex.apache.org Subject: RE: [Git/Wiki] please review the proposed workflow and comment Yes please. Okay, I have a long plane flight tomorrow. I will try to write something up so I can send it when I land. No problem, it just a talk, you and me want the best for Apache Flex. Thanks. Looking forward to figuring this out and helping everyone else get comfortable with git Mike
Re: [Git/Wiki] please review the proposed workflow and comment
Hi Guys, Sorry for writing in this late in your discussion. I really appreciate the time you both are putting into this. I finally got a chance to look at the wiki page. IMO, if you want to simplify, I think the first thing I would put on the wiki is the update the readme workflow. Most of us coming from SVN are not going to get the advantages of a branch right away and I think we've all agreed that it isn't always required. But after that, it seems like it would be better to explain the advantages of Git rather than trying to come up with a works most of the time solution that tries to make it so we don't have to learn key points about Git. I'd rather see links to the best example elsewhere on the net or short stories as to what rebase does, or why cutting a branch saved your ass, along with steps to do it and what those steps are doing. Git seems powerful enough that if you don't know what you are doing you can make a lot of work for yourself or others. And you can just link from this wiki to each of your own pages with your own workflows and commands instead of having to reach agreement. Just like there is some wiggle room in coding style it looks like there is some wiggle room in git style and, while that bugs me, I can live with it. I learned the finer aspects of writing code from several folks with different styles and I'm happy to learn the finer aspects of Git from several folks with different styles. If we all worked in the same room, I'd be asking Fred, how do you do this and Mike would overhear and offer his opinion and then I'd try one or both and learn something from it. On 3/23/13 5:38 PM, Frédéric THOMAS webdoubl...@hotmail.com wrote: Okay, I have a long plane flight tomorrow I thought you had a cape !?#** :-) -Fred -Message d'origine- From: Michael A. Labriola Sent: Sunday, March 24, 2013 1:33 AM To: dev@flex.apache.org Subject: RE: [Git/Wiki] please review the proposed workflow and comment Yes please. Okay, I have a long plane flight tomorrow. I will try to write something up so I can send it when I land. No problem, it just a talk, you and me want the best for Apache Flex. Thanks. Looking forward to figuring this out and helping everyone else get comfortable with git Mike -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
RE: [Git/Wiki] please review the proposed workflow and comment
I'd rather see links to the best example elsewhere on the net or short stories as to what rebase does, or why cutting a branch saved your ass, along with steps to do it and what those steps are doing. Git seems powerful enough that if you don't know what you are doing you can make a lot of work for yourself or others. Alex, Agreed. I think we will get there. Fred, As I am digging further into this though, I am coming up with a lot of questions. I am guessing, based on the fact that I am seeing whiteboards, etc. that committers don't really have their own forks in our current apache model, but rather everyone is using their own clone of the same fork. Am I right? Is there a particular reason we went this way? I am just trying to understand so I can do my best to guide us within the model that has been created. There could be many viable reasons for this but to me, right now, it's a little strange for a git project, so I am just trying to grok it all. This would change some of the advice I gave Alex, for example. Mike
Re: [Git/Wiki] please review the proposed workflow and comment
The whiteboard was migrated from SVN, and I think folks did just copy SDKs in there so there is no common branch points. I wouldn't worry about a workflow for whiteboards, I want to get the workflow for flex-sdk, flex-falcon and flex-asjs in the wiki as that is where we have multiple folks working and where we are trying to use the nvie git branching model. On 3/23/13 10:48 PM, Michael A. Labriola labri...@digitalprimates.net wrote: I'd rather see links to the best example elsewhere on the net or short stories as to what rebase does, or why cutting a branch saved your ass, along with steps to do it and what those steps are doing. Git seems powerful enough that if you don't know what you are doing you can make a lot of work for yourself or others. Alex, Agreed. I think we will get there. Fred, As I am digging further into this though, I am coming up with a lot of questions. I am guessing, based on the fact that I am seeing whiteboards, etc. that committers don't really have their own forks in our current apache model, but rather everyone is using their own clone of the same fork. Am I right? Is there a particular reason we went this way? I am just trying to understand so I can do my best to guide us within the model that has been created. There could be many viable reasons for this but to me, right now, it's a little strange for a git project, so I am just trying to grok it all. This would change some of the advice I gave Alex, for example. Mike -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
Re: [Git/Wiki] please review the proposed workflow and comment
That should've been: 1: https://cwiki.apache.org/confluence/display/FLEX/Git+for+Apache+Flex+Guide Sorry about that, EdB On Fri, Mar 22, 2013 at 12:02 PM, Erik de Bruin e...@ixsoftware.nl wrote: Hi, Fred and I (mainly Fred) have written a proposed project specific workflow in the wiki [1]. Can anyone please review and comment (here or on the wiki page, preferably here)? Thanks! 1: -- 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: [Git/Wiki] please review the proposed workflow and comment
Hey, I haven't see, thank you for having rewriten it :) -Fred -Message d'origine- From: Erik de Bruin Sent: Friday, March 22, 2013 12:03 PM To: dev@flex.apache.org Subject: Re: [Git/Wiki] please review the proposed workflow and comment That should've been: 1: https://cwiki.apache.org/confluence/display/FLEX/Git+for+Apache+Flex+Guide Sorry about that, EdB On Fri, Mar 22, 2013 at 12:02 PM, Erik de Bruin e...@ixsoftware.nl wrote: Hi, Fred and I (mainly Fred) have written a proposed project specific workflow in the wiki [1]. Can anyone please review and comment (here or on the wiki page, preferably here)? Thanks! 1: -- 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: [Git/Wiki] please review the proposed workflow and comment
Hi Erik, I can't seem to find much information for non-committers (except for the GitHub line at the end). Will that be on a different page? Regarding the GitHub pull requests: I thought this was one of the major reasons to move to Git; to provide developers an easy means of contributing small improvements. Max
Re: [Git/Wiki] please review the proposed workflow and comment
Hi, A this is still (always?) a work in progress, contributions are welcome. I'm learning git as we go, and am not at all familiar with pull-requests or Github, I have little knowledge to contribute on that point. In the workflow section, the only difference between a committer and a contributor is in point 7. I guess that is where a pull request comes into play? How would that work, if you don't mind explaining? EdB On Fri, Mar 22, 2013 at 12:14 PM, RIAstar max...@riastar.net wrote: Hi Erik, I can't seem to find much information for non-committers (except for the GitHub line at the end). Will that be on a different page? Regarding the GitHub pull requests: I thought this was one of the major reasons to move to Git; to provide developers an easy means of contributing small improvements. Max -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: [Git/Wiki] please review the proposed workflow and comment
I can't seem to find much information for non-committers On second read I found 7b) Everyone else: create a patch. I didn't see it the first time because it was listed under *Committers: working on the code* Perhaps this could be made more apparent. Max
Re: [Git/Wiki] please review the proposed workflow and comment
Erik, why there are \-- instead of -- in the commands ? -Fred -Message d'origine- From: Erik de Bruin Sent: Friday, March 22, 2013 12:20 PM To: dev@flex.apache.org Subject: Re: [Git/Wiki] please review the proposed workflow and comment Hi, A this is still (always?) a work in progress, contributions are welcome. I'm learning git as we go, and am not at all familiar with pull-requests or Github, I have little knowledge to contribute on that point. In the workflow section, the only difference between a committer and a contributor is in point 7. I guess that is where a pull request comes into play? How would that work, if you don't mind explaining? EdB On Fri, Mar 22, 2013 at 12:14 PM, RIAstar max...@riastar.net wrote: Hi Erik, I can't seem to find much information for non-committers (except for the GitHub line at the end). Will that be on a different page? Regarding the GitHub pull requests: I thought this was one of the major reasons to move to Git; to provide developers an easy means of contributing small improvements. Max -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: [Git/Wiki] please review the proposed workflow and comment
Ah, the wiki fooling me: I wrapped the commands in a {code} block,
which negated the need to escape the special characters. Fixed now.
EdB
Re: [Git/Wiki] please review the proposed workflow and comment
I've removed Comitters: from that title. I agree that the layout is not optimal yet, will have another look once the text has stabilised a bit. EdB On Fri, Mar 22, 2013 at 12:22 PM, RIAstar max...@riastar.net wrote: I can't seem to find much information for non-committers On second read I found 7b) Everyone else: create a patch. I didn't see it the first time because it was listed under *Committers: working on the code* Perhaps this could be made more apparent. Max -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: [Git/Wiki] please review the proposed workflow and comment
Well, your English is way better than my French :-) Now, if we could
vote to change the main language on the list to Dutch, I would really
shine... not! I'm not a very good writer and in high school I always
failed miserably in writing/spelling. But in these times, with spell
and syntax checkers, who needs school, right?
;-)
EdB
On Fri, Mar 22, 2013 at 12:31 PM, Frédéric THOMAS
webdoubl...@hotmail.com wrote:
Much better ;-)
Cheers, btw, it looks much more better and with better English than when I
did it (for the latter, it wasn't too difficult I guess) :-)
-Fred
-Message d'origine- From: Erik de Bruin
Sent: Friday, March 22, 2013 12:28 PM
To: dev@flex.apache.org
Subject: Re: [Git/Wiki] please review the proposed workflow and comment
Ah, the wiki fooling me: I wrapped the commands in a {code} block,
which negated the need to escape the special characters. Fixed now.
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [Git/Wiki] please review the proposed workflow and comment
lol, me, as my mailler, correct only French language :P
-Fred
-Message d'origine-
From: Erik de Bruin
Sent: Friday, March 22, 2013 12:36 PM
To: dev@flex.apache.org
Subject: Re: [Git/Wiki] please review the proposed workflow and comment
Well, your English is way better than my French :-) Now, if we could
vote to change the main language on the list to Dutch, I would really
shine... not! I'm not a very good writer and in high school I always
failed miserably in writing/spelling. But in these times, with spell
and syntax checkers, who needs school, right?
;-)
EdB
On Fri, Mar 22, 2013 at 12:31 PM, Frédéric THOMAS
webdoubl...@hotmail.com wrote:
Much better ;-)
Cheers, btw, it looks much more better and with better English than when I
did it (for the latter, it wasn't too difficult I guess) :-)
-Fred
-Message d'origine- From: Erik de Bruin
Sent: Friday, March 22, 2013 12:28 PM
To: dev@flex.apache.org
Subject: Re: [Git/Wiki] please review the proposed workflow and comment
Ah, the wiki fooling me: I wrapped the commands in a {code} block,
which negated the need to escape the special characters. Fixed now.
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [Git/Wiki] please review the proposed workflow and comment
I just installed the English vocabulary, it seems to be better :)
Anyway, I'm still better to speak than to write :P
-Fred
-Message d'origine-
From: Frédéric THOMAS
Sent: Friday, March 22, 2013 12:39 PM
To: dev@flex.apache.org
Subject: Re: [Git/Wiki] please review the proposed workflow and comment
lol, me, as my mailler, correct only French language :P
-Fred
-Message d'origine-
From: Erik de Bruin
Sent: Friday, March 22, 2013 12:36 PM
To: dev@flex.apache.org
Subject: Re: [Git/Wiki] please review the proposed workflow and comment
Well, your English is way better than my French :-) Now, if we could
vote to change the main language on the list to Dutch, I would really
shine... not! I'm not a very good writer and in high school I always
failed miserably in writing/spelling. But in these times, with spell
and syntax checkers, who needs school, right?
;-)
EdB
On Fri, Mar 22, 2013 at 12:31 PM, Frédéric THOMAS
webdoubl...@hotmail.com wrote:
Much better ;-)
Cheers, btw, it looks much more better and with better English than when I
did it (for the latter, it wasn't too difficult I guess) :-)
-Fred
-Message d'origine- From: Erik de Bruin
Sent: Friday, March 22, 2013 12:28 PM
To: dev@flex.apache.org
Subject: Re: [Git/Wiki] please review the proposed workflow and comment
Ah, the wiki fooling me: I wrapped the commands in a {code} block,
which negated the need to escape the special characters. Fixed now.
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [Git/Wiki] please review the proposed workflow and comment
HI, Regarding the GitHub pull requests: I thought this was one of the major reasons to move to Git; to provide developers an easy means of contributing small improvements. Github != Git. However github pull request can be easily converted to patch files and applied. However currently we can't close pull requests. https://issues.apache.org/jira/browse/FLEX-33175 Justin
Re: [Git/Wiki] please review the proposed workflow and comment
How would that work, if you don't mind explaining? On the non-comitter's side: - A non-committer forks the GitHub repo - He now has a complete copy of this repo in his own account - He clones his own fork to work on it locally - He works locally, makes some commits, pushes to his fork, makes some more commits, pushes again, ... until he thinks his feature/bug fix/... is ready - On GitHub, he hits the pull request button - He selects the commits that he wants to be packaged in this pull request (if not all) - He chooses a source branch in his fork and a target branch in the original repo and sends the request On the committer's side: - A pull request appears in the list of pull requests (mails are also sent to notify interested people) - A committer reviews the commits (GitHub will list all the diffs) and - a/ sends a message back to the developer with instructions to tweak his changes in one way or the other - the non-committer fixes what was requested and submits his pull request again - b/ accepts the pull request and merges it into the target branch; this can happen in two ways 1/ it's a fast-forward merge: the committer just hits the button and the new code will be automatically merged 2/ it's not: the committer resolves conflicts and merges manually Regarding the workflow with big projects like Apache Flex: I don't think the pull request concept is mentioned in the nvie article. So I guess there's going to be questions like: - which branch(es) will non-committers have to target? - will their code be merged into 'develop' directly or is a different workflow required? - maybe bugfixes go directly into 'develop', but new components go into a feature branch?
Re: [Git/Wiki] please review the proposed workflow and comment
Hi, And is seem we already have a pull request. Who get notified when one occurs? Can we make it so it emails the list? https://github.com/apache/flex-sdk/pull/1 And how do we close the pull request it once it's been applied? Justin
Re: [Git/Wiki] please review the proposed workflow and comment
I don't know very well the GitHub workflow as even though I worked on public and privates ones but: A non-committer forks the GitHub repo Can't he clone directly the GitHub Repo ? which branch(es) will non-committers have to target? I would say, its own branch, I mean a branch with the name of the relative issues in the JIRA Thanks, -Fred -Message d'origine- From: RIAstar Sent: Friday, March 22, 2013 1:02 PM To: dev@flex.apache.org Subject: Re: [Git/Wiki] please review the proposed workflow and comment How would that work, if you don't mind explaining? On the non-comitter's side: - A non-committer forks the GitHub repo - He now has a complete copy of this repo in his own account - He clones his own fork to work on it locally - He works locally, makes some commits, pushes to his fork, makes some more commits, pushes again, ... until he thinks his feature/bug fix/... is ready - On GitHub, he hits the pull request button - He selects the commits that he wants to be packaged in this pull request (if not all) - He chooses a source branch in his fork and a target branch in the original repo and sends the request On the committer's side: - A pull request appears in the list of pull requests (mails are also sent to notify interested people) - A committer reviews the commits (GitHub will list all the diffs) and - a/ sends a message back to the developer with instructions to tweak his changes in one way or the other - the non-committer fixes what was requested and submits his pull request again - b/ accepts the pull request and merges it into the target branch; this can happen in two ways 1/ it's a fast-forward merge: the committer just hits the button and the new code will be automatically merged 2/ it's not: the committer resolves conflicts and merges manually Regarding the workflow with big projects like Apache Flex: I don't think the pull request concept is mentioned in the nvie article. So I guess there's going to be questions like: - which branch(es) will non-committers have to target? - will their code be merged into 'develop' directly or is a different workflow required? - maybe bugfixes go directly into 'develop', but new components go into a feature branch?
Re: [Git/Wiki] please review the proposed workflow and comment
Apache cordova has already a nice step by step manual for pull request on github - http://wiki.apache.org/cordova/CommitterWorkflow. It's not just a click on the accept pull request on github. :( Cyrill On Fri, Mar 22, 2013 at 10:11 PM, Frédéric THOMAS webdoubl...@hotmail.com wrote: I don't know very well the GitHub workflow as even though I worked on public and privates ones but: A non-committer forks the GitHub repo Can't he clone directly the GitHub Repo ? which branch(es) will non-committers have to target? I would say, its own branch, I mean a branch with the name of the relative issues in the JIRA Thanks, -Fred -Message d'origine- From: RIAstar Sent: Friday, March 22, 2013 1:02 PM To: dev@flex.apache.org Subject: Re: [Git/Wiki] please review the proposed workflow and comment How would that work, if you don't mind explaining? On the non-comitter's side: - A non-committer forks the GitHub repo - He now has a complete copy of this repo in his own account - He clones his own fork to work on it locally - He works locally, makes some commits, pushes to his fork, makes some more commits, pushes again, ... until he thinks his feature/bug fix/... is ready - On GitHub, he hits the pull request button - He selects the commits that he wants to be packaged in this pull request (if not all) - He chooses a source branch in his fork and a target branch in the original repo and sends the request On the committer's side: - A pull request appears in the list of pull requests (mails are also sent to notify interested people) - A committer reviews the commits (GitHub will list all the diffs) and - a/ sends a message back to the developer with instructions to tweak his changes in one way or the other - the non-committer fixes what was requested and submits his pull request again - b/ accepts the pull request and merges it into the target branch; this can happen in two ways 1/ it's a fast-forward merge: the committer just hits the button and the new code will be automatically merged 2/ it's not: the committer resolves conflicts and merges manually Regarding the workflow with big projects like Apache Flex: I don't think the pull request concept is mentioned in the nvie article. So I guess there's going to be questions like: - which branch(es) will non-committers have to target? - will their code be merged into 'develop' directly or is a different workflow required? - maybe bugfixes go directly into 'develop', but new components go into a feature branch?
Re: [Git/Wiki] please review the proposed workflow and comment
It's easy to create a .patch file using git and attach that to a JIRA ticket, isn't it? Why not declare that the as the default way to contribute code for non-committers, and revisit this if/when Github is in sync again? EdB On Fri, Mar 22, 2013 at 1:19 PM, Cyrill Zadra cyrill.za...@gmail.com wrote: Apache cordova has already a nice step by step manual for pull request on github - http://wiki.apache.org/cordova/CommitterWorkflow. It's not just a click on the accept pull request on github. :( Cyrill On Fri, Mar 22, 2013 at 10:11 PM, Frédéric THOMAS webdoubl...@hotmail.com wrote: I don't know very well the GitHub workflow as even though I worked on public and privates ones but: A non-committer forks the GitHub repo Can't he clone directly the GitHub Repo ? which branch(es) will non-committers have to target? I would say, its own branch, I mean a branch with the name of the relative issues in the JIRA Thanks, -Fred -Message d'origine- From: RIAstar Sent: Friday, March 22, 2013 1:02 PM To: dev@flex.apache.org Subject: Re: [Git/Wiki] please review the proposed workflow and comment How would that work, if you don't mind explaining? On the non-comitter's side: - A non-committer forks the GitHub repo - He now has a complete copy of this repo in his own account - He clones his own fork to work on it locally - He works locally, makes some commits, pushes to his fork, makes some more commits, pushes again, ... until he thinks his feature/bug fix/... is ready - On GitHub, he hits the pull request button - He selects the commits that he wants to be packaged in this pull request (if not all) - He chooses a source branch in his fork and a target branch in the original repo and sends the request On the committer's side: - A pull request appears in the list of pull requests (mails are also sent to notify interested people) - A committer reviews the commits (GitHub will list all the diffs) and - a/ sends a message back to the developer with instructions to tweak his changes in one way or the other - the non-committer fixes what was requested and submits his pull request again - b/ accepts the pull request and merges it into the target branch; this can happen in two ways 1/ it's a fast-forward merge: the committer just hits the button and the new code will be automatically merged 2/ it's not: the committer resolves conflicts and merges manually Regarding the workflow with big projects like Apache Flex: I don't think the pull request concept is mentioned in the nvie article. So I guess there's going to be questions like: - which branch(es) will non-committers have to target? - will their code be merged into 'develop' directly or is a different workflow required? - maybe bugfixes go directly into 'develop', but new components go into a feature branch? -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: [Git/Wiki] please review the proposed workflow and comment
It's not just a click on the accept pull request on github. I was afraid it would be harder than that with an Apache project :( Can't he clone directly the GitHub Repo ? Yes he can, but he will not be able to generate a pull request like that, because he has no write access to the remote repo. If he clones directly, he'll have a local copy of the repo to which he can commit, but not push. If he first creates a fork, he'll be able to push to his own fork, and then generate a pull request.
Re: [Git/Wiki] please review the proposed workflow and comment
Just found [1], that's the contributor side only but it pleased me, just replacing master by develop could be a good base for the wiki ? -Fred [1] https://www.openshift.com/wiki/github-workflow-for-submitting-pull-requests -Message d'origine- From: Erik de Bruin Sent: Friday, March 22, 2013 1:27 PM To: dev@flex.apache.org Subject: Re: [Git/Wiki] please review the proposed workflow and comment It's easy to create a .patch file using git and attach that to a JIRA ticket, isn't it? Why not declare that the as the default way to contribute code for non-committers, and revisit this if/when Github is in sync again? EdB On Fri, Mar 22, 2013 at 1:19 PM, Cyrill Zadra cyrill.za...@gmail.com wrote: Apache cordova has already a nice step by step manual for pull request on github - http://wiki.apache.org/cordova/CommitterWorkflow. It's not just a click on the accept pull request on github. :( Cyrill On Fri, Mar 22, 2013 at 10:11 PM, Frédéric THOMAS webdoubl...@hotmail.com wrote: I don't know very well the GitHub workflow as even though I worked on public and privates ones but: A non-committer forks the GitHub repo Can't he clone directly the GitHub Repo ? which branch(es) will non-committers have to target? I would say, its own branch, I mean a branch with the name of the relative issues in the JIRA Thanks, -Fred -Message d'origine- From: RIAstar Sent: Friday, March 22, 2013 1:02 PM To: dev@flex.apache.org Subject: Re: [Git/Wiki] please review the proposed workflow and comment How would that work, if you don't mind explaining? On the non-comitter's side: - A non-committer forks the GitHub repo - He now has a complete copy of this repo in his own account - He clones his own fork to work on it locally - He works locally, makes some commits, pushes to his fork, makes some more commits, pushes again, ... until he thinks his feature/bug fix/... is ready - On GitHub, he hits the pull request button - He selects the commits that he wants to be packaged in this pull request (if not all) - He chooses a source branch in his fork and a target branch in the original repo and sends the request On the committer's side: - A pull request appears in the list of pull requests (mails are also sent to notify interested people) - A committer reviews the commits (GitHub will list all the diffs) and - a/ sends a message back to the developer with instructions to tweak his changes in one way or the other - the non-committer fixes what was requested and submits his pull request again - b/ accepts the pull request and merges it into the target branch; this can happen in two ways 1/ it's a fast-forward merge: the committer just hits the button and the new code will be automatically merged 2/ it's not: the committer resolves conflicts and merges manually Regarding the workflow with big projects like Apache Flex: I don't think the pull request concept is mentioned in the nvie article. So I guess there's going to be questions like: - which branch(es) will non-committers have to target? - will their code be merged into 'develop' directly or is a different workflow required? - maybe bugfixes go directly into 'develop', but new components go into a feature branch? -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: [Git/Wiki] please review the proposed workflow and comment
Ok, I always worked with r/w access, that's the reason why I didn't know. Cheers, -Fred -Message d'origine- From: RIAstar Sent: Friday, March 22, 2013 1:31 PM To: dev@flex.apache.org Subject: Re: [Git/Wiki] please review the proposed workflow and comment It's not just a click on the accept pull request on github. I was afraid it would be harder than that with an Apache project :( Can't he clone directly the GitHub Repo ? Yes he can, but he will not be able to generate a pull request like that, because he has no write access to the remote repo. If he clones directly, he'll have a local copy of the repo to which he can commit, but not push. If he first creates a fork, he'll be able to push to his own fork, and then generate a pull request.
Re: [Git/Wiki] please review the proposed workflow and comment
And this one indeed https://help.github.com/articles/using-pull-requests -Fred -Message d'origine- From: Frédéric THOMAS Sent: Friday, March 22, 2013 1:34 PM To: dev@flex.apache.org Subject: Re: [Git/Wiki] please review the proposed workflow and comment Just found [1], that's the contributor side only but it pleased me, just replacing master by develop could be a good base for the wiki ? -Fred [1] https://www.openshift.com/wiki/github-workflow-for-submitting-pull-requests -Message d'origine- From: Erik de Bruin Sent: Friday, March 22, 2013 1:27 PM To: dev@flex.apache.org Subject: Re: [Git/Wiki] please review the proposed workflow and comment It's easy to create a .patch file using git and attach that to a JIRA ticket, isn't it? Why not declare that the as the default way to contribute code for non-committers, and revisit this if/when Github is in sync again? EdB On Fri, Mar 22, 2013 at 1:19 PM, Cyrill Zadra cyrill.za...@gmail.com wrote: Apache cordova has already a nice step by step manual for pull request on github - http://wiki.apache.org/cordova/CommitterWorkflow. It's not just a click on the accept pull request on github. :( Cyrill On Fri, Mar 22, 2013 at 10:11 PM, Frédéric THOMAS webdoubl...@hotmail.com wrote: I don't know very well the GitHub workflow as even though I worked on public and privates ones but: A non-committer forks the GitHub repo Can't he clone directly the GitHub Repo ? which branch(es) will non-committers have to target? I would say, its own branch, I mean a branch with the name of the relative issues in the JIRA Thanks, -Fred -Message d'origine- From: RIAstar Sent: Friday, March 22, 2013 1:02 PM To: dev@flex.apache.org Subject: Re: [Git/Wiki] please review the proposed workflow and comment How would that work, if you don't mind explaining? On the non-comitter's side: - A non-committer forks the GitHub repo - He now has a complete copy of this repo in his own account - He clones his own fork to work on it locally - He works locally, makes some commits, pushes to his fork, makes some more commits, pushes again, ... until he thinks his feature/bug fix/... is ready - On GitHub, he hits the pull request button - He selects the commits that he wants to be packaged in this pull request (if not all) - He chooses a source branch in his fork and a target branch in the original repo and sends the request On the committer's side: - A pull request appears in the list of pull requests (mails are also sent to notify interested people) - A committer reviews the commits (GitHub will list all the diffs) and - a/ sends a message back to the developer with instructions to tweak his changes in one way or the other - the non-committer fixes what was requested and submits his pull request again - b/ accepts the pull request and merges it into the target branch; this can happen in two ways 1/ it's a fast-forward merge: the committer just hits the button and the new code will be automatically merged 2/ it's not: the committer resolves conflicts and merges manually Regarding the workflow with big projects like Apache Flex: I don't think the pull request concept is mentioned in the nvie article. So I guess there's going to be questions like: - which branch(es) will non-committers have to target? - will their code be merged into 'develop' directly or is a different workflow required? - maybe bugfixes go directly into 'develop', but new components go into a feature branch? -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: [Git/Wiki] please review the proposed workflow and comment
Hi, Apache cordova has already a nice step by step manual for pull request on github - http://wiki.apache.org/cordova/CommitterWorkflow. Seems overly complex when a pull request can be converedt to a patch by adding .patch to the URL and applied something like this: curl https://github.com/apache/flex-sdk/pull/X.patch | git apply Justin
Re: [Git/Wiki] please review the proposed workflow and comment
They also have a nice page for contributors: http://wiki.apache.org/cordova/ContributorWorkflow On Mar 22, 2013, at 5:38 AM, Justin Mclean jus...@classsoftware.com wrote: Hi, Apache cordova has already a nice step by step manual for pull request on github - http://wiki.apache.org/cordova/CommitterWorkflow. Seems overly complex when a pull request can be converedt to a patch by adding .patch to the URL and applied something like this: curl https://github.com/apache/flex-sdk/pull/X.patch | git apply Justin
