RFC: Merge hints

RFC: Merge hints

[Marius Bakke]

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?

Re: RFC: Merge hints

[Jeff King]

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

> 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.

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:

> 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

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