Hello All, This query is not about Linux kernel, but is rather generic query on development framework with git. Since, Linux Kernel project is significantly large, with astonishing number of people involved and large number of branches, I'm assuming that people have faced similar situation and your advice and guidance would be of great help to me. I'm currently pursuing Masters program and also working in a small tech Startup in the IOT domain. I'm involved in Firmware Development on ARM based SOCs and our team comprise three Engineers. We use git for SCM. Since we are in a very early phase and have very little turnaround time, from the requirement to final integration, we do not have a proper review process and hence everyone is allowed to commit in the master branch, or create, delete a branch, or a tag at will. We also do not have much insight into, how long a feature based branch would last. In last couple of months, I've seen some stale branches on which the development stopped quite early and some very active branch as well. Without much insight and probably due to not so well defined process, It is already becoming difficult to properly maintain the code consistency, filtering etc across several branches. For example, I create a feature remote branch (say origin/featureX) on which I continue my development and soon I realize that part (There is no way to pick partial commit) or a full commit that I recently made for the featureX should also go into another branches such as master and say featureY branch as well. But since, my colleague has been working on master, I get conflicts when I try to cherry-pick (At this moment, I do not want to rebase or merge two branches, I only need few of the commits from featureX branch to go into master and featureY). I resolve the conflicts and life goes on, but problem happens again later in future, if the two branches divert too much and a further need for cherry-picking or rebasing or merging is required. The point is that I also believe that it is a very good idea to maintain separate branches, based on feature or some other requirements, but it is also a n00bs nightmare when the conflicts are very high. There are also incidents when somebody forgot to add a particular commit to another branch and realized only later, when he was faced with debugging a issue and had to go through the git history, to figure out the issue. It would be nice, If for example a particular commit can be automatically propagated to other branches in this case. Please pitch in your suggestions, rule of thumb, tools and your way of countering such issue with less pain. Thanks, Amit
On August 18, 2015 5:46:38 AM EDT, amit mehta <gmate.amit@gmail.com> wrote:
Hello All,
This query is not about Linux kernel, but is rather generic query on development framework with git. Since, Linux Kernel project is significantly large, with astonishing number of people involved and large number of branches, I'm assuming that people have faced similar situation and your advice and guidance would be of great help to me.
I'm currently pursuing Masters program and also working in a small tech Startup in the IOT domain. I'm involved in Firmware Development on ARM based SOCs and our team comprise three Engineers. We use git for SCM. Since we are in a very early phase and have very little turnaround time, from the requirement to final integration, we do not have a proper review process and hence everyone is allowed to commit in the master branch, or create, delete a branch, or a tag at will. We also do not have much insight into, how long a feature based branch would last. In last couple of months, I've seen some stale branches on which the development stopped quite early and some very active branch as well. Without much insight and probably due to not so well defined process, It is already becoming difficult to properly maintain the code consistency, filtering etc across several branches. For example, I create a feature remote branch (say origin/featureX) on which I continue my development and soon I realize that part (There is no way to pick partial commit) or a full commit that I recently made for the featureX should also go into another branches such as master and say featureY branch as well. But since, my colleague has been working on master, I get conflicts when I try to cherry-pick (At this moment, I do not want to rebase or merge two branches, I only need few of the commits from featureX branch to go into master and featureY). I resolve the conflicts and life goes on, but problem happens again later in future, if the two branches divert too much and a further need for cherry-picking or rebasing or merging is required.
The point is that I also believe that it is a very good idea to maintain separate branches, based on feature or some other requirements, but it is also a n00bs nightmare when the conflicts are very high. There are also incidents when somebody forgot to add a particular commit to another branch and realized only later, when he was faced with debugging a issue and had to go through the git history, to figure out the issue. It would be nice, If for example a particular commit can be automatically propagated to other branches in this case.
Please pitch in your suggestions, rule of thumb, tools and your way of countering such issue with less pain.
Thanks, Amit
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Personally, in young code I find long lived branches hard to work with. For new features I prefer to work first on the integration related code with a stub that gracefully does nothing or fails. So at the start of adding a new feature that will be implemented via a subroutine,write the invoking code a stub that gracefully does nothing. Often the invoking code and the stub can be written in 10 minutes or less. Then push/pull that into master immediately. Then I would use an ifdef to work on a real subroutine to implement the feature. ie. #ifndef FEATURE_X_TESTING /* Declare a a stub to use until the code is stable enough for master */ int new_function() { return(TRUE); } #else /* This is unstable code I am still writing */ int new_function() { /* New code */ } #endif Then in my local makefile (or via a environment variable, I set FEATURE_X_TESTING true. Now my new unstable code will have no negative impact on master, so I push it to master often. Probably at least once a day. When I'm ready to first enable it in master, I just define FEATURE_X_TESTING in master. Greg
On Tue, Aug 18, 2015 at 5:11 PM, Greg Freemyer <greg.freemyer@gmail.com> wrote:
Personally, in young code I find long lived branches hard to work with.
For new features I prefer to work first on the integration related code with a stub that gracefully does nothing or fails.
So at the start of adding a new feature that will be implemented via a subroutine,write the invoking code a stub that gracefully does nothing. Often the invoking code and the stub can be written in 10 minutes or less.
Then push/pull that into master immediately.
Then I would use an ifdef to work on a real subroutine to implement the feature. ie.
#ifndef FEATURE_X_TESTING /* Declare a a stub to use until the code is stable enough for master */ int new_function() { return(TRUE); } #else /* This is unstable code I am still writing */ int new_function() { /* New code */ } #endif
Then in my local makefile (or via a environment variable, I set FEATURE_X_TESTING true.
Now my new unstable code will have no negative impact on master, so I push it to master often. Probably at least once a day.
When I'm ready to first enable it in master, I just define FEATURE_X_TESTING in master.
This is interesting. However, I personally, don't like these preprocessor stuff, since a lot of those make it difficult for me to follow the code flow and we already have quite a few of them and was thinking of getting rid of as much I can. But, still a big thank you for your suggestion. - Amit
On Tue, Aug 18, 2015 at 3:16 PM, amit mehta <gmate.amit@gmail.com> wrote:
Hello All,
This query is not about Linux kernel, but is rather generic query on development framework with git. Since, Linux Kernel project is significantly large, with astonishing number of people involved and large number of branches, I'm assuming that people have faced similar situation and your advice and guidance would be of great help to me.
I'm currently pursuing Masters program and also working in a small tech Startup in the IOT domain. I'm involved in Firmware Development on ARM based SOCs and our team comprise three Engineers. We use git for SCM. Since we are in a very early phase and have very little turnaround time, from the requirement to final integration, we do not have a proper review process and hence everyone is allowed to commit in the master branch, or create, delete a branch, or a tag at will. We also do not have much insight into, how long a feature based branch would last. In last couple of months, I've seen some stale branches on which the development stopped quite early and some very active branch as well. Without much insight and probably due to not so well defined process, It is already becoming difficult to properly maintain the code consistency, filtering etc across several branches. For example, I create a feature remote branch (say origin/featureX) on which I continue my development and soon I realize that part (There is no way to pick partial commit) or a full commit that I recently made for the featureX should also go into another branches such as master and say featureY branch as well. But since, my colleague has been working on master, I get conflicts when I try to cherry-pick (At this moment, I do not want to rebase or merge two branches, I only need few of the commits from featureX branch to go into master and featureY). I resolve the conflicts and life goes on, but problem happens again later in future, if the two branches divert too much and a further need for cherry-picking or rebasing or merging is required.
The point is that I also believe that it is a very good idea to maintain separate branches, based on feature or some other requirements, but it is also a n00bs nightmare when the conflicts are very high. There are also incidents when somebody forgot to add a particular commit to another branch and realized only later, when he was faced with debugging a issue and had to go through the git history, to figure out the issue. It would be nice, If for example a particular commit can be automatically propagated to other branches in this case.
Please pitch in your suggestions, rule of thumb, tools and your way of countering such issue with less pain.
Few suggestions: 1. Better to have a proper review process in place, gerrit is one of the best tools I have used so far for reviewing, 2. Keep a master branch always compilable (run able) and merge rights should be only to integrator. once a feature is developed (on a feature branch) and ready to get into master, create a new commit for master branch for merging (of course after validating against the new head)
Thanks, Amit
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
On Wed, Aug 19, 2015 at 6:57 AM, Chetan Nanda <chetannanda@gmail.com> wrote:
1. Better to have a proper review process in place, gerrit is one of the best tools I have used so far for reviewing, 2. Keep a master branch always compilable (run able) and merge rights should be only to integrator. once a feature is developed (on a feature branch) and ready to get into master, create a new commit for master branch for merging (of course after validating against the new head)
Thank you so much for your advice. I had reviewboard [1] in mind for code review, going forward, but I'm not sure, how easy or difficult it is to integrate reviewboard with bitbucket. I did a quick web search about integrating bitbucket with gerrit (the one you have mentioned) and found cloudpipes [2] which is currently in beta phase. I've sent my request to join them, however It seems there is a long queue (40K+ people on the waiting list!!!) [1] https://www.reviewboard.org/ [2] https://www.cloudpipes.com/ - Amit
participants (3)
-
amit mehta -
Chetan Nanda -
Greg Freemyer