Pull all commits from a branch, push specified commits to another

Question

I have the following branches:

• master
• production

and the following remote branches:

• origin/master
• origin/production

I have a script that fetches the origin/master branch and gets the diff of what changed from my last fetch (log -p master..origin/master). Then I merge origin/master.

The commits found are pushed to a code review tool.

I want to push the successful commits – and only them – to the production branch, and then of course to origin/production.

How can I do so?

Also, I have 2 scripts running: the one that fetch from origin/master, push commits details to a database, and merge, and the other that I'm currently writing that will have to push the successful commits.

I'd like to have those 2 scripts running while avoiding race conditions/merge conflict. Since I only want to work with specified commits, maybe there's a way to get rid of the commits that I don't want?

Answer 1

The term I think you're looking for is a 'cherry pick'. That is, take a single commit from the middle of one branch and add it to another:

A-----B------C  \   \    D 

becomes

A-----B------C  \   \    D-----C' 

This, of course, can be done with the git cherry-pick command.

The problem with this commit is that git considers commits to include all history before them - thus, if you have three commits like so:

A-----B-----C 

And try to get rid of B, you have to create an entirely new commit like so:

A-----------C' 

Where C' has a different SHA-1 ID. Likewise, cherry picking a commit from one branch to another basically involves generating a patch, then applying it, thus losing history that way as well.

This changing of commit IDs breaks git's merging functionality among other things (though if used sparingly there are heuristics that will paper over this). More importantly though, it ignores functional dependencies - if C actually used a function defined in B, you'll never know.

Perhaps a better way to handle this would be to have more fine grained branches. That is, instead of just having a 'master', have 'featureA', 'bugfixB', etc. Perform code review on an entire branch at a time - where each branch is very focused on doing only one thing - and then merge that one branch when you're done. This is the workflow that git is designed for, and what it's good at :)

If you insist on dealing with things at the level of patches, you may want to look at darcs - it considers a repository to be a set of patches, and thus cherry picking becomes the fundamental operation. However this has its own set of problems, such as being very slow :)

Edit: Also, I'm not sure I understand your second question, about the two scripts. Maybe you could describe it in more detail, possibly as a separate question to keep things from getting confusing?