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