How to maintain independence of pull request branches in the face of shared code
Here’s the scenario…
I’ve forked a git repo, and plan to submit a number of pull requests: e.g.,
At some point, before submitting any pull requests, I realize I want to create another feature (call it feature-q), which is conceptually independent of any of the other features, but requires at least one generic utility function that was added as part of the implementation of feature-a. Feature-a has been tested, and I’d really like to go ahead and submit its pull request before implementing feature-q. The most natural course would be to create the feature-q branch from the feature-a branch, but doing so would introduce a dependency on feature-a I’d like to avoid, for the simple reason that I’d like the project owner to be able to “mix and match” the features he ultimately chooses to merge, and the aforementioned dependency would preclude his choosing feature-q but rejecting feature-a. Also, even if he ultimately chose to accept both pull requests, the dependency would constrain the order in which he merged.
In retrospect, it would have been simpler if I’d committed the utility function(s) on a separate branch, but this would have complicated development, and in any case, I didn’t know about feature-q when I was developing feature-a. I suppose I could simply copy the utility function(s) into feature-q manually (or possibly using the git merge option that supports hunk-by-hunk merging), but this feels a bit kludgy.
Just wondering whether this is the sort of problem that arises often enough to warrant its own “best practice”. Also, are there any downsides, from a git perspective, of doing the manual copy of the utility function(s) into feature-q: i.e., of introducing common code independently into distinct branches? (My guess is that it will not cause problems, other than to give the misleading impression that identical code was developed independently on separate branches…)