Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lock file format to minimize conflicts #1066

Open
alexdlm opened this issue Jun 29, 2023 · 3 comments
Open

Lock file format to minimize conflicts #1066

alexdlm opened this issue Jun 29, 2023 · 3 comments

Comments

@alexdlm
Copy link

alexdlm commented Jun 29, 2023

What happened?

My repos have constantly conflicting version.locks, particularly exacerbated by various excavators racing each other. The CI expense alone must be high, plus I have to waste my time managing all these PRs.

Less frequently, versions.props conflicts as well, but at least that's within my power to manage to minimize these by separating the more frequently changing deps.

What did you want to happen?

#1001 had a go at adding three comments to space the lock lines out. Can this be (spiritually) revived, or at least the way forward determined?

@gluxon pushed through a similar change to pnpm (pnpm/pnpm#5091) which has since become default. Could we adopt similar inline format here? I'm not a fan of the empty comments from #1001, but perhaps one of these ticks the box for git and is functional?

Option 1

ch.qos.logback:logback-classic:1.2.3
  constraints: 1
  hash: 0805f935

org.slf4j:slf4j-api:1.7.25
  constraints: 1
  hash: 400d4d2a

(Actually this might still trip git up 🤔)

Option 2

ch.qos.logback:logback-classic
  1.2.3 (1 constraints: 0805f935)

org.slf4j:slf4j-api
  1.7.25 (1 constraints: 400d4d2a)

Trivial regex to match the old one line format and this two line format.


I'm happy to make a PR if we can reach a consensus.

@alexdlm
Copy link
Author

alexdlm commented Jun 29, 2023

From #1001:
@iamdanfox

Before we go down this route, I've found that apparently git has some built in merge drivers (e.g. one called union) and also allows us to configure a custom one. Maybe it's worth pursuing this?? http://schacon.github.io/git/gitattributes.html

I'm not sure if anyone did any investigations down this route, it doesn't look particularly useful here to me (at least without dedupe/sorting as well I guess).

But most importantly IMO, ideally we don't need to make any extra configuration changes to every repo and our fix here just works OOTB.

@iamdanfox
Copy link
Contributor

My concerns with @schlosna's approach (#1001) are pretty mild/cosmetic tbh, if people are experiencing a lot of pain from these adjacent line merge conflicts and current maintainers want to go for this approach then I'd say go for it!

@schlosna
Copy link

I don't have super strong feelings about the format, mostly interested in avoiding merge conflicts where possible to allow automation & 🤖 to do their thing while I sleep. I've updated #1001 to just use blank lines as buffer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants