Menu
This question is not iOS-specific, but I'm including the actual use case here for clarity
I run an iOS project called Foobar, obviously kept under version control.
Amongst the project files in the iOS project environment there's something called Foobar-Info.plist, an XML file which stores interesting information about the project, like versions and the number of builds I've made.
Every time I build the project, I increment the build count stored in to this file like so:
...
<key>BuildCount</key>
<string>2203</string>
<key>CFBundleShortVersionString</key>
<string>0.0.4</string>
<key>CFBundleVersion</key>
<string>0.0.4-release/0.0.4.2203</string>
...
where '0.0.4-release' is a git-flow branch name, and 2203 is a build number. This is used in the CFBundleVersion field, so that it's really obvious to me where the build came from.
Imagine in another branch, I've made a lot of progress since the release and the same fields look like:
...
<key>BuildCount</key>
<string>2754</string>
<key>CFBundleShortVersionString</key>
<string>0.0.4</string>
<key>CFBundleVersion</key>
<string>0.0.4-feature/add-quux-and-baz.2754</string>
...
Let's say I'm done with release, and it's merged into the mainline develop branch.
The problem
In order to get the latest changes made in the release branch, I want to rebase the feature branch onto develop.
when this happens, Foobar-Info.plist will cause a conflict at EVERY commit in the rebase process. This is because the build numbers will have incremented for every commit; I must manually merge by choosing the lines manually specify the lines with the latest version. Note that the base version of the 3-way diff will ALSO be different.
<string>2000</string> // Base
<string>2754</string> // Local ** always pick this one; it's the latest
<string>2203</string> // Remote
How can I tell git that for one specific file, Foobar-Info.plist, I want it to resolve my conflicts for me by taking the LATEST change?
EDIT: The file must be kept under source-control. I want to keep the BuildCount because it's a cool indication of effort put into my project and I want to keep it! I know that the figure only indicates the MINIMUM number of builds done, but that'll be good enough for me.
217
Recursive is the default merge strategy when pulling or merging one branch. Additionally this can detect and handle merges involving renames, but currently cannot make use of detected copies. This is the default merge strategy when pulling or merging one branch.
We can use git checkout for far more than simply changing branches. If we supply it with a branch name and a file, we can replace a corrupted or broken file. Instead, if we want to pass some of the changed content we can use the --patch flag to manually merge an individual file.
I realize this is a late answer, but if I understand your question, what you're looking for is a .gitattributes file.
You can specify merge strategies for specific files or folders with relative paths from the .gitattributes file, which looks like this:
* text=auto
path/to/your/file.plist merge=union
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
