On August 18, 2015 5:46:38 AM EDT, amit mehta [off-list ref] 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 at 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