{"thread":{"id":"52735","subject":"RFC: Merge hints","startedAt":"2020-02-02T12:00:45Z","lastAt":"2020-02-14T06:44:30Z","messageCount":2,"participants":["Marius Bakke","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"391003","messageId":"87pnexmcjr.fsf@devup.no","threadId":"52735","inReplyTo":null,"subject":"RFC: Merge hints","fromName":"Marius Bakke","fromEmail":"marius@devup.no","sentAt":"2020-02-02T11:52:24Z","receivedAt":"2020-02-02T12:00:45Z","isPatch":false,"sender":{"key":"marius@devup.no","avatar":null},"body":"Hi,\n\nIt would be convenient if git had a facility for adding \"merge hints\",\nboth for automatic conflict resolution, as well as giving clues to\npersons inheriting or merging a branch.\n\nThe main use case here is aiding long-running branches.  Imagine a\nfeature branch where all uses of FOO_STR is replaced with STR.  For\nvarious reasons this branch cannot be merged to master, yet it needs to\nbe kept up to date, and new uses of FOO_STR keeps getting added.\n\nIf you are lucky, your compiler will complain that FOO_STR is undefined\nwhen running whatever tests you have after a merge.  But perhaps the new\ncode is for a different platform and not reached during a test run.  A\ndiligent developer might also run 'git grep FOO_STR' *if* they know\nabout the change.  Fixing these trivial problems is boring and manual.\n\nA more tricky case is where...\n\n  def foo(a,b)\n\nhas become\n\n  def foo(a,b,c)\n\n...and c is a required positional argument.  Any new uses of 'foo' will\nneed to be adjusted during a merge.  This function can be multi line and\nnot easily greppable.\n\nThe diligent developer is in no shortage of tools: \"git log -G foo\n..master\" will reveal any potential problems, even before the merge.\nYet, they still have to 1) know about the change; and 2) fix up the uses\nmanually.\n\nIt seems to me that git could offer better tools to deal with this.\nPerhaps a \".mergehints\", where you could provide a regular expression\neither for automatic merge resolution, or just have git complain loudly\nwhen a given pattern is merged (say, introduce conflict markers even\nthough there were no \"real\" conflicts).  I.e.:\n\n[hint1]\nfiles = *.c\npattern = FOO_STR\ntransform = s/FOO_STR/STR\n\n[hint2]\nfiles = *.py\npattern = 'foo('\nconflict = true\n\nThoughts?  Are there other tools at the diligent developers disposal\nthat can aid with these kinds of problems?\n"},{"id":"391742","messageId":"20200214064428.GE605125@coredump.intra.peff.net","threadId":"52735","inReplyTo":"87pnexmcjr.fsf@devup.no","subject":"Re: RFC: Merge hints","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-02-14T06:44:28Z","receivedAt":"2020-02-14T06:44:30Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Feb 02, 2020 at 12:52:24PM +0100, Marius Bakke wrote:\n\n> It would be convenient if git had a facility for adding \"merge hints\",\n> both for automatic conflict resolution, as well as giving clues to\n> persons inheriting or merging a branch.\n\nTo some degree, the git-rerere command does this.\n\nIt doesn't let you do the kind of pattern transformations you suggested,\nbut it does let you resolve a _particular_ conflict once, and then\nrepeat it again. So it's useful if you're going to find the same\nconflict multiple times (e.g., merging to multiple long-running\nbranches) or if you want to communicate resolutions to somebody (you can\nshare your merge result, and they can use rerere-train to seed their own\ndatabase).\n\nBut it sounds like you're more interested in the pattern ones, where you\ndon't see the _same_ conflict over and over, but rather just similar\nones (your example where one side changes the signature of foo(), but\nthe other side keeps adding new callers).\n\nIn my experience you can't really solve that in an automated way (you\nhave to decide in each case what should go into the new parameter!). But\nassuming you could, it seems like this could all be done outside of Git\nitself.\n\nFor example:\n\n> It seems to me that git could offer better tools to deal with this.\n> Perhaps a \".mergehints\", where you could provide a regular expression\n> either for automatic merge resolution, or just have git complain loudly\n> when a given pattern is merged (say, introduce conflict markers even\n> though there were no \"real\" conflicts).  I.e.:\n> \n> [hint1]\n> files = *.c\n> pattern = FOO_STR\n> transform = s/FOO_STR/STR\n> \n> [hint2]\n> files = *.py\n> pattern = 'foo('\n> conflict = true\n\nOnce Git sees the conflicted state, you should be able to mark up those\nconflicts using an external tool. You operate on the file with conflict\nmarkers from your working tree, or you can access the original base,\n\"theirs\" and \"ours\" content in stages 1, 2, and 3 of the index. So if\nyou have a smart tool which understands merging and understands the\nsyntax of your files, it could apply those transforms.\n\nThat's more or less how git-mergetool works (feeding those three files\nto whatever custom tool you like). I don't have a good knowledge of what\ntools are out there that might support something like this, though (I\ntypically just look at the conflicts manually in an editor).\n\n-Peff\n"}]}