1

I'm currently working on an iOS project. I have a script which runs when I build. This script updates the build number and commits it into git as well as pushes it. However, after a few days of using it, I realized a side effect. I can have consecutive commits where it is incrementing the build number. So my commit logs are flooded with these commits. This gets particularly exacerbated because the project is broken up into a couple of core libraries. So working on the libs invariably results in a build increment (since it is the same workspace).

What I realize now is that I need a script smart enough to squash consecutive commits which are the update of the build number.

Running

git log -20 --pretty=format:"%h - %s"

for example, will yield

6add12a1 - Update the package from handle
70f438be - Updated client version to 0.15.0.2152 and next version to 0.15.0.2153
7d84151f - Updated client version to 0.15.0.2151 and next version to 0.15.0.2152
eace113b - Updated client version to 0.15.0.2150 and next version to 0.15.0.2151
e72624dd - Updated client version to 0.15.0.2149 and next version to 0.15.0.2150
85d15b6c - Updated client version to 0.15.0.2148 and next version to 0.15.0.2149
a4e140cd - Updated client version to 0.15.0.2147 and next version to 0.15.0.2148
ffb18892 - Updated client version to 0.15.0.2146 and next version to 0.15.0.2147
ebd33432 - Updated client version to 0.15.0.2145 and next version to 0.15.0.2146
f0727ca7 - Updated client version to 0.15.0.2144 and next version to 0.15.0.2145
80ab2939 - Adjust balance if FB rewards popup is shown
0c04a1d7 - Updated client version to 0.15.0.2143 and next version to 0.15.0.2144
e89fd769 - Updated client version to 0.15.0.2142 and next version to 0.15.0.2143
c404f9ce - Updated client version to 0.15.0.2141 and next version to 0.15.0.2142
3911fb31 - Updated client version to 0.15.0.2140 and next version to 0.15.0.2141
ee3b7056 - Updated client version to 0.15.0.2139 and next version to 0.15.0.2140
cfb3b2a7 - Updated client version to 0.15.0.2138 and next version to 0.15.0.2139
a11fa3d9 - Add conditionals compilation to remove some logging
b9d0f75a - Disable backlight
ba4447ae - Updated client version to 0.15.0.2137 and next version to 0.15.0.2138

So in this example, I'd want to squash down 70f438be to f0727ca7 and then update the commit to be something like "Updated client version from 0.15.0.2138 to 0.15.0.2152".

There are 2 things that need to be done.

  • Write a script or manually squash consecutive build number increment commits
  • Update my script to check if the previous commit(s) is/are build number increments and if so, squash.

I have no issues writing the scripts themselves. Rather the focus of this question is the git command itself. The details about the scripts are provided as context.

What I'm looking for is how to use git non-interactively to squash a specific consecutive range of commits that are not starting at the HEAD. References I've seen thus far have all squashed from the HEAD.

Such as this.

Is there a way to squash a number of commits non-interactively?.

I will go through that some more later today since it may hold the answer still.

Oh yeah and the clarify, these commits are all pushed already.

Note that this is on a Mac. And the latter script is run from Xcode (Build Phase) and is a Python script using GitPython.

Mobile Ben
  • 7,121
  • 1
  • 27
  • 43

1 Answers1

2

Okay, so I've done some experimentation and running it for a while, I've come up with a solution.

It would be helpful if those with better git-fu can validate this is indeed a good/safe way to go.

I abandoned trying to change the commit message to reflect the changes. I did find a way to do it, but as I now have a better understanding of what this all does to the repository, I've opted to not worry about this detail.

This seems this command will work out for squashing a range of commits not starting from the HEAD.

git rebase -Xtheirs --onto 80ab2939 7d84151f

The key here being -Xtheirs since at least in my application, it will otherwise result in a conflict. Note my case is special in that it relies on a known commit message pattern and the files are the same.

I ran the above on this history

6add12a1 - Update the package from handle
70f438be - Updated client version to 0.15.0.2152 and next version to 0.15.0.2153
7d84151f - Updated client version to 0.15.0.2151 and next version to 0.15.0.2152
eace113b - Updated client version to 0.15.0.2150 and next version to 0.15.0.2151
e72624dd - Updated client version to 0.15.0.2149 and next version to 0.15.0.2150
85d15b6c - Updated client version to 0.15.0.2148 and next version to 0.15.0.2149
a4e140cd - Updated client version to 0.15.0.2147 and next version to 0.15.0.2148
ffb18892 - Updated client version to 0.15.0.2146 and next version to 0.15.0.2147
ebd33432 - Updated client version to 0.15.0.2145 and next version to 0.15.0.2146
f0727ca7 - Updated client version to 0.15.0.2144 and next version to 0.15.0.2145
80ab2939 - Adjust balance if FB rewards popup is shown
0c04a1d7 - Updated client version to 0.15.0.2143 and next version to 0.15.0.2144

This generates some output:

First, rewinding head to replay your work on top of it...
Auto-merging resources/plists/jks-info.plist
Auto-merging resources/next_build_version.txt
[detached HEAD 8beac4c7] Updated client version to 0.15.0.2152 and next version to 0.15.0.2153
 Date: Mon Mar 4 02:01:15 2019 -0800
 2 files changed, 2 insertions(+), 2 deletions(-)
Committed: 0001 Updated client version to 0.15.0.2152 and next version to 0.15.0.2153
[detached HEAD 4ede3d58] Update the package from handle
 Date: Mon Mar 4 02:03:09 2019 -0800
 1 file changed, 4 insertions(+), 2 deletions(-)
Committed: 0002 Update the package from handle
All done

But the resulting history (git log) is good.

4ede3d58 - Update the package from handle
8beac4c7 - Updated client version to 0.15.0.2152 and next version to 0.15.0.2153
80ab2939 - Adjust balance if FB rewards popup is shown
0c04a1d7 - Updated client version to 0.15.0.2143 and next version to 0.15.0.2144
e89fd769 - Updated client version to 0.15.0.2142 and next version to 0.15.0.2143

My last step is to force push as the commits have already been pushed. Note the force push will rewrite your history. I actually use git push --force-with-lease to be safe.

Mobile Ben
  • 7,121
  • 1
  • 27
  • 43