Add a custom Git merge tool for Cargo.locks and Cargo.tomls

[pcwalton]

It's terribly annoying to have tons of Cargo.lock and Cargo.toml merge conflicts when rebasing pretty much any Rust PR on any large repo. It would be nice to have custom merge tools that automatically do the right thing here.

[dwijnand]

see "Defining a custom merge driver": https://git-scm.com/docs/gitattributes#_defining_a_custom_merge_driver

[ishitatsuyuki]

To add to this, NPM/Yarn have already implemented this feature officially.

[Eh2406]

cc #5831

[wycats]

I really like this feature, and enjoy it a lot in yarn.

[dwijnand]

So there are actually two different solutions here, and I think we should follow npm's lead and implement both:

• Teach cargo (or the TOML parser(s) cargo uses) to consume TOML files with merge conflict marks and resolve them
• Implement a custom merge driver that can resolve merge conflicts in TOML files

Here are some references:

• yarn impl: https://github.com/yarnpkg/yarn/pull/3544/files
• npm impl: npm/npm@e27674c
• npm custom merge driver: https://github.com/npm/npm-merge-driver
• a blog post: https://blog.scottlogic.com/2018/02/13/npm-shrikwrap-merges-and-conflicts.html

[thomaseizinger]

From reading the documentation/PRs linked in this ticket, I get the following understanding (please correct at any stage if I am wrong):

• Custom git merge drivers need to be registered in .git/config and .gitattributes.
• Custom git merge drivers are automatically invoked as soon as the conflict occurs. Hence we could start implementing this as a totally separate binary without needing any support for it in cargo.
  If the custom merge driver is activated in a repository, cargo would practically never see a lock file with merge conflicts again, unless the driver fails to resolve the conflicts.
• Once the tool is mature enough, it could be included in cargo as a subcommand and cargo could automatically register the merge driver when it initializes a project.

Thoughts?
If my understanding is correct, then I would start working on such a merge driver :)

[mightyiam]

It's unfortunate you only got reactions for this and not a real response, @thomaseizinger.

• Custom git merge drivers are automatically invoked as soon as the conflict occurs.

I can confirm this from experience. Here's an example from npm:
https://github.com/npm/npm-merge-driver

Hence we could start implementing this as a totally separate binary without needing any support for it in cargo.

Sounds like standard practice in Rust-land.

If the custom merge driver is activated in a repository, cargo would practically never see a lock file with merge conflicts again, unless the driver fails to resolve the conflicts.

Right. Emphasis on "unless". I don't expect this to always be able to resolve them.

• Once the tool is mature enough, it could be included in cargo as a subcommand and cargo could automatically register the merge driver when it initializes a project.

That would be super sweet.

[thomaseizinger]

Thanks @mightyiam !

I have to admit, this was no longer on my radar at all. The latest lockfile version only rarely produces conflicts in my experience.

For Cargo.toml, I am not sure we can automatically resolve conflicts at all?

[mightyiam]

I haven't thought this through. I hope some smart people will!

[epage]

The latest lockfile version only rarely produces conflicts in my experience.

In case anyone else wants context on this, #7070 changed the lockfile to make it produce fewer conflicts

[afranchuk]

Note that https://github.com/relrelb/cargo-merge-driver exists, which seems to work (though it could maybe do with some updating of e.g. the beta clap version it's using).

Edit: updated deps and README at https://github.com/afranchuk/cargo-merge-driver

[Kixunil]

@afranchuk sadly, that's not a real merge driver, just a hack that always updates all packages to their latest versions. A real merger should parse all lock files, identify the changes and merge them roughly according to these rules:

• Independent packages added - add them all
• Same package, same version added - add it just once
• Added or updated package version but different versions: pick the higher one but maybe emit a warning
• A package removed and updated - conflict
• Same version of a package but different hashes - conflict
• Same package removed in both - just remove it.

Also FYI I made a merge tool to resolve use statements. It's quite sketchy so far but does work in some cases. I've since learned about merge drivers and I think it'd be better suitable as a driver.