1

We're trying to maintain a set of configuration files in a git repo.

From time to time, we make a release of the latest configuration to a target system.

We then make further changes to the repo

While we do this the users of that system may update some configuration files manually.

Before we make the next release, we want to detect and review the user changes. Some will be discarded, some will be new additional files, some will be updates to files we've not changed since the last release, some will be updates to files we have changed.

However, this is not source code. We need to review all changes (in other words, ALL changes from the users should be regarded as potential merge conflicts, not just the ones that overlap) because non-overlapping changes can operationally conflict.

Mostly, I think I can do this with

git checkout -b latest-from-users tag-for-previous-release

# [copy the files from the target system]

git add .
git commit

now I have a branch with the latest commit having all the users changes since the last release.

I can compare this to the base of the branch to see what the users have changed.

But the files may also have changed in master since the last release. For files that both have changed in master, and been changed by the user, it's the latest in master I want to consider, and not the base of the branch.

I can rebase this latest-from-user branch to the HEAD of master, but I don't know how to make git regard ANY change in a file as a conflict that needs resolution.

(EDIT: Ideally I want:

  • If it's changed in master but not by the user -> accept the change
  • if it's not changed in master but changed by the user -> merge "conflict"
  • If it's changed in other -> merge "conflict"

because there's no need to further review changes made in master only)

I've had a read of merge strategies but that's just left me more confused. I think I want a merge strategy of "don't" - if a file has changed at all, mark up the changes and leave it for the user to resolve.

Can this be done?

The Archetypal Paul
  • 41,321
  • 20
  • 104
  • 134
  • If you want to inspect, choose and discard any part of a merge, maybe just avoid committing and review all you want. There's been [a similar question](https://stackoverflow.com/questions/70793783/how-to-merge-a-remote-branch-into-my-current-branch-but-only-stage-the-changes) yesterday, could it help you? – Romain Valeri Jan 22 '22 at 11:44
  • "avoid committing and review what all you want". What do you mean by this? I'm trying to use git features to identify what needs to be reviewed. – The Archetypal Paul Jan 22 '22 at 11:49
  • You would need to write a custom merge driver. See https://stackoverflow.com/questions/7607125/git-merge-conflict-to-always-take-the-newest-file for instance. – matt Jan 22 '22 at 12:32
  • @matt, thanks. Not really what I wanted to hear, but thanks anyway! – The Archetypal Paul Jan 22 '22 at 12:41

0 Answers0