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

Question

Hi,

I got the following branches :

• master
• production

and the following remotes branches :

• origin/master
• origin/production

I got 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 tools.

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 got 2 scripts running, the one that fetch from origin/master, push commits details to a database, and merge, 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 it seems to me that I will need to switch between branches to do so ... :/)

Thanks in advance,

edit : I was thinking that, 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 commits 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 seperate question to keep things from getting confusing?