0

Our git process involves merging features into development, from feature branches, and when stable, these get merged into master.

If a bug is found in a feature, that branch is reverted from development making it a little difficult to figure out what is finally going into master.

I was thinking of a simple shell script to generate a list of merges (that were not reverted), that are in development, but not in master, but cant figure out how to generate this. I know it can be done using basic git and bash, so any pointers would be much appreciated.

Update:

From the answer here, I could get something close with:

git rev-list release_2013_05_20 --not master --merges | xargs -L1 git name-rev | grep -oE '[0-9a-f]{40}\s[^\~\^]*'

But this shows multiple entries if a feature was reverted, and then merged back again.

Community
  • 1
  • 1
zsquare
  • 9,916
  • 6
  • 53
  • 87
  • Reverting merges is an ugly affair. You could consider using a throwaway integration branch instead for early testing (most often called `pu`, _proposed updates_). – chirlu May 20 '13 at 10:05
  • They are always no-ff merges into development. Hasnt been very painful so far. – zsquare May 20 '13 at 10:06
  • how do you merge them in again later? If you mere, revert the merge commit and then merge again, that is not supposed to work. – Chronial May 20 '13 at 11:01
  • We revert the revert in the feature branch, fix the issue, then merge it back in again. Its a little convoluted, I know, but it works for us, and allows us to pull out features with a single revert. – zsquare May 20 '13 at 11:32
  • You’ll need some out-of-band data, like the commit messages of the reverts (if they are machine-parseable). – chirlu May 20 '13 at 11:57

1 Answers1

1

What is the shape of your history, and what are you trying to do? From your description, what I understood so far is:

You have a faulty merge commit M in your development branch coming from a topic branch (heads commits: A, B):

 ---o---o---o---M---x---x
               /
       ---A---B

and you revert it with $ git revert -m 1 M to get this:

 ---o---o---o---M---x---x---W
               /
       ---A---B

Then, you make more changes to your topic branch and development branch:

 ---o---o---o---M---x---x---W---x
               /
       ---A---B-------------------C---D

And merge it back into development as M2 when you feel that it is mature:

 ---o---o---o---M---x---x---W---x---M2
               /                     \
       ---A---B-------------------C---D

Now, you want to find out all the M commits that don't have a corresponding W commit, correct? The only way to do this (assuming full generality) is to actually take the patch text of M and verify that it is the inverse of the patch text of W. Since, W is just a regular commit, you have to walk every single commit and compare it with every merge commit that comes before it in the entire branch. How else would you handle this clusterfuck?

---o---o---o---M1---x---x---M2---x---x--W1---M3---x---W3---x
               /             \                \
       ---A---B-----------C---D------------E---F

Have I conclusively proved that your workflow is broken, and that you must change your ways? Now go read gitworkflows(7) and reflect on this disaster.

artagnon
  • 3,609
  • 3
  • 23
  • 26