RFC: Merge hints

Hi,

It would be convenient if git had a facility for adding "merge hints", both for automatic conflict resolution, as well as giving clues to persons inheriting or merging a branch.

The main use case here is aiding long-running branches. Imagine a feature branch where all uses of FOO_STR is replaced with STR. For various reasons this branch cannot be merged to master, yet it needs to be kept up to date, and new uses of FOO_STR keeps getting added.

If you are lucky, your compiler will complain that FOO_STR is undefined when running whatever tests you have after a merge. But perhaps the new code is for a different platform and not reached during a test run. A diligent developer might also run 'git grep FOO_STR' *if* they know about the change. Fixing these trivial problems is boring and manual.

A more tricky case is where...

  def foo(a,b)

has become

  def foo(a,b,c)

...and c is a required positional argument. Any new uses of 'foo' will need to be adjusted during a merge. This function can be multi line and not easily greppable.

The diligent developer is in no shortage of tools: "git log -G foo ..master" will reveal any potential problems, even before the merge. Yet, they still have to 1) know about the change; and 2) fix up the uses manually.

It seems to me that git could offer better tools to deal with this. Perhaps a ".mergehints", where you could provide a regular expression either for automatic merge resolution, or just have git complain loudly when a given pattern is merged (say, introduce conflict markers even though there were no "real" conflicts). I.e.:

[hint1] files = *.c pattern = FOO_STR transform = s/FOO_STR/STR

[hint2] files = *.py pattern = 'foo(' conflict = true

Thoughts? Are there other tools at the diligent developers disposal that can aid with these kinds of problems?

On Sun, Feb 02, 2020 at 12:52:24PM +0100, Marius Bakke wrote:

To some degree, the git-rerere command does this.

It doesn't let you do the kind of pattern transformations you suggested, but it does let you resolve a _particular_ conflict once, and then repeat it again. So it's useful if you're going to find the same conflict multiple times (e.g., merging to multiple long-running branches) or if you want to communicate resolutions to somebody (you can share your merge result, and they can use rerere-train to seed their own database).

But it sounds like you're more interested in the pattern ones, where you don't see the _same_ conflict over and over, but rather just similar ones (your example where one side changes the signature of foo(), but the other side keeps adding new callers).

In my experience you can't really solve that in an automated way (you have to decide in each case what should go into the new parameter!). But assuming you could, it seems like this could all be done outside of Git itself.

For example:

Once Git sees the conflicted state, you should be able to mark up those conflicts using an external tool. You operate on the file with conflict markers from your working tree, or you can access the original base, "theirs" and "ours" content in stages 1, 2, and 3 of the index. So if you have a smart tool which understands merging and understands the syntax of your files, it could apply those transforms.

That's more or less how git-mergetool works (feeding those three files to whatever custom tool you like). I don't have a good knowledge of what tools are out there that might support something like this, though (I typically just look at the conflicts manually in an editor).

-Peff