[closed] 100USD bounty for map conflict resolution tool

[actioninja]

Said tool in fact already exists at: https://github.com/SpaiR/JTGMerge
Perhaps a better tooling language than java could be used, but it does exist for now.
Someone just needs to in fact make the automation tooling which naturally is not a trivial task.

Requirements:
- Runnable from CLI with no user input outside of initial command (automation friendly)
- Input is map file with git conflict already in it
- GUI interface is preferred but not required
- Output in TGM format
- Change output path via command line flag
- Automatically resolve spurious conflicts (conflicts due to line number changes but otherwise do not conflict in any way, no key conflicts and no placement conflicts)
- Automatically resolve key conflicts
- Ability to pick which trunk you want to resolve the conflict with, controllable via prompt or command line parameter being passed
- Command line flag that causes a different return code and an error message when conflict is not automatically resolvable
- End product licensed under GPL

$50 bonus if it is written in Rust

Contact me on discord gunch#6969 if you want to negotiate or discuss requirements, and you don't have a forum account here.

[SpaceManiac]

I recently picked up work on a tool along these lines and gave it to a downstream (Mojave Sun) to test, but it's rather barebones and I haven't got any feedback to know if it's actually good.

My opinions on what you've listed so far

• "automation friendly" can best be accomplished using a Git merge driver, but it might make sense to offer an alternative mode that picks up the pieces if you `git merge` without having installed it yet
  • this mode would also help users of certain Git GUIs (e.g. GitKraken)
  • use as a merge driver may not play well with command-line interactivity if used from within Git GUIs (haven't tested)
• GUI is the most work out of this, but possibly the highest impact if done well
  • possibly best implemented as a mode for an existing map editor because of the DM parsing prerequisite to rendering maps
    • FastDMM2 is not currently suitable for use on a local filesystem
    • StrongDMM has awkward compilation requirements on Linux which currently prevent me from hacking on it
    • DreamMaker isn't customizable, but maybe there exists a good "conflict, please resolve" output that is easy to work with in it anyways
    • SpacemanDMM is currently just a map viewer and not deployed, but it's the most hackable
  • that would mean the merge driver (or post-merge tool) spits out a "to-be-manually-resolved" file which you then open in an editor and resolve there, rather than doing it in the tool
  • raises questions about what functionality is the responsibility of which component
• line-number conflicts & key conflicts are totally eliminated by using a tool which actually knows how to parse .dmm files
• implementation (except GUI) would likely be in Python and have the same requirements as the poorly-named mapmerge2 does
  • as much as I would love free money to write it in Rust, I'm not 100% sure it makes the most sense given the requirements

May dig in on this if further discussion allows me to see a path from "crappy prototype" to "production-ready", which I haven't yet been able to do in the time I've been sitting on this issue

Response to edits

• "Input is map.file with git conflict already in it"
  • probably impossible to literally do this, but digging the "ours" and "theirs" versions out of Git and operating on those should work

[actioninja]

I recently picked up work on a tool along these lines and gave it to a downstream (Mojave Sun) to test, but it's rather barebones and I haven't got any feedback to know if it's actually good.

My opinions on what you've listed so far

• "automation friendly" can best be accomplished using a Git merge driver, but it might make sense to offer an alternative mode that picks up the pieces if you `git merge` without having installed it yet
  • this mode would also help users of certain Git GUIs (e.g. GitKraken)
  • use as a merge driver may not play well with command-line interactivity if used from within Git GUIs (haven't tested)
• GUI is the most work out of this, but possibly the highest impact if done well
  • possibly best implemented as a mode for an existing map editor because of the DM parsing prerequisite to rendering maps
    • FastDMM2 is not currently suitable for use on a local filesystem
    • StrongDMM has awkward compilation requirements on Linux which currently prevent me from hacking on it
    • DreamMaker isn't customizable, but maybe there exists a good "conflict, please resolve" output that is easy to work with in it anyways
    • SpacemanDMM is currently just a map viewer and not deployed, but it's the most hackable
  • that would mean the merge driver (or post-merge tool) spits out a "to-be-manually-resolved" file which you then open in an editor and resolve there, rather than doing it in the tool
  • raises questions about what functionality is the responsibility of which component
• line-number conflicts & key conflicts are totally eliminated by using a tool which actually knows how to parse .dmm files
• implementation (except GUI) would likely be in Python and have the same requirements as the poorly-named mapmerge2 does
  • as much as I would love free money to write it in Rust, I'm not 100% sure it makes the most sense given the requirements

May dig in on this if further discussion allows me to see a path from "crappy prototype" to "production-ready", which I haven't yet been able to do in the time I've been sitting on this issue

Response to edits

• "Input is map.file with git conflict already in it"
  • probably impossible to literally do this, but digging the "ours" and "theirs" versions out of Git and operating on those should work

Alright so here's some followup:
A merge driver hook would be useful, but an explicit tool to pick up the pieces of a conflict is what's being looked for here.

GUI would be huge and hence why it's not actually part of the bounty and more of a wishlist. I assume the issues related to SDMM on linux have to do with the usage of Dear Imgui?

I wanted Rust because while Python is powerful and not really any issue for internal scripts, having a static binary that you could tell clueless mappers to download and drag their map on to and it's AUTOMAGICALLY fixed would reduce the amount of headache significantly. Especially now StrongDMM is more popular, a lot don't have mapmerge setup correctly and mapmerge can be problematic to setup, especially with the recent windows 10 store python nonsense.

You'd have to reparse the whole file twice to operate on an already conflicted file.

[SpaceManiac]

A merge driver hook would be useful, but an explicit tool to pick up the pieces of a conflict is what's being looked for here.

It should be possible to make a merge driver only one possible entry-point of the tool.

GUI would be huge and hence why it's not actually part of the bounty and more of a wishlist. I assume the issues related to SDMM on linux have to do with the usage of Dear Imgui?

Sure, let's punt on that then. StrongDMM's Java<->C imgui bindings don't compile correctly on my system and the precompiled libs require a too-new glibc

I wanted Rust because while Python is powerful and not really any issue for internal scripts, having a static binary that you could tell clueless mappers to download and drag their map on to and it's AUTOMAGICALLY fixed would reduce the amount of headache significantly. Especially now StrongDMM is more popular, a lot don't have mapmerge setup correctly and mapmerge can be problematic to setup, especially with the recent windows 10 store python nonsense.

My preference is strongly for scripts which live in the /tg/station13 repo and can be edited by anyone and are right there rather than .exes that you only know about if you ask the right person on Discord

The Windows 10 store nonsense was fixed. The hooks now know to skip that entry in %PATH%. If you have other problems with a tool try reporting or even fixing them instead of just deciding the tool is now "problematic" and therefore useless

You'd have to reparse the whole file twice to operate on an already conflicted file.

I mean it's literally impossible. The default "text" merge driver simply mangles the file too much to be able to recover the different "base", "ours", and "theirs" versions that are the needed inputs to a merge algorithm. Good thing it's also unnecessary.

[SpaceManiac]

I wanted Rust because while Python is powerful and not really any issue for internal scripts, having a static binary that you could tell clueless mappers to download and drag their map on to and it's AUTOMAGICALLY fixed would reduce the amount of headache significantly

My preference is strongly for scripts which live in the /tg/station13 repo and can be edited by anyone and are right there rather than .exes that you only know about if you ask the right person on Discord.

Given your silence, I'm not particularly cheesed if you intend to neglect or rescind this bounty offer, but for posterity I wanted to elaborate on this thought.

My main objection to using Rust is the distribution channel issue. We'd need:

• a CI system to generate Windows binaries (and possibly musl Linux binaries)
• a place to host them (GitHub Actions currently offers .zip artifacts only, but maybe this is good enough)
• a place they're supposed to be installed on the user's machine. only sane options are a .gitignored location in-repo (if we want any automation whatsoever) or "your Downloads folder" (if we want to eliminate the possibility of automation, which does not seem like a good plan to me)
• a way to push updates to users (this is harder than it sounds) - important because people WILL keep using old and busted versions if given the opportunity

If we use a language distributable as source code (that is, with the UX of an interpreted language), there's no binaries to generate or host and updating is totally automatic because it happens with every "git pull", which is an unavoidable part of doing map changes.

The obvious downside is that Windows is a binary-distribution-first platform so ultimately you have to install a binary of something from somewhere. It's then a matter of making sure it's something useful, and something that's not a huge pain in the ass to install.

For "drag and drop map file" workflows, a .bat (which is a valid drop target) can be strategically placed to invoke the .py as needed. The script could also look for all unmerged map files if double-clicked.

Python is not the only choice, but existing map tooling is in Python so at least some mappers are used to it. The specific Python implementation does have a big unresolved problems in the form of pygit2 wheel compatibility issues which mandate us to churn requirements.txt for every Python 3.X release, which I would like to solve someday.

Perl is another which would save an additional install for anyone who already has Git for Windows installed, but I would have to learn Perl and port the .dmm parser to it and the code would probably not be very good, and almost nobody else on the team knows Perl either. I don't think skipping one download for some users would outweigh the downsides of Perl -- GitHub Desktop and GitKraken users would still be forced to install something, although that something would be Git for Windows instead of Python. TortoiseGit comes with Git for Windows included. (While I'm discussing this, GitHub Desktop bundles a sh.exe but not a bash.exe, but GitKraken bundles neither).

It might be possible to pull some Powershell chicanery (end-user experience: double-click this .bat file) which automatically installs a private copy of a pinned version of Python in a .gitignored directory but I haven't looked heavily into this.

[Stickymayhem]

this has to be the programmer equivalent of a back alley knife fight

[actioninja]

Just clarifying that I intend to update this but I've been really busy and haven't had the time to properly think about it.
Spacemaniac has a strong point on the "update delivery" part and that's something I didn't initially consider.
imo the CI and hosting is a non issue due to the easy avalibility of tooling for rust.