0

TL;DR :

I want to avoid conflicts each time I'm merging my bumped base project package.version in the forked one containing a different package.name.

Issue :

Context

I maintain two git repos, named here base and fork, each contains a shared package.json and the package-lock.json accordingly. They got a propert name to base and base_fork respectively, the second has been updated since the first commit after forking. Each lives in gitlab context and the second is created with the fork option of gitlab.

Workflow

A version bump happen in base, I update the lockfile with an npm i then push to base master branch. I'm starting a merge request with gitlab from base master to fork master. This one fail due to conflict that I need to resolve manually in package.json and package-lock.json :

<<<<<<< HEAD
  "name": "fork",
  "version": "1.0.0",
=======
  "name": "base",
  "version": "1.0.1"
>>>>>>> xxxxxxxx

So, I'm taking name from HEAD and version from commit xxxxxxxx. And push to resolve conflict.

Problem

The conflict appear due to name change + version change. Technically, git detect a conflict, I can understand why, but it's boring me ^^ . So, I moved away the version line from package.json that's fixing the problem for this file but the package-lock.json is a solid I can't manage like that.

So!

I think the problem can be reproduce with a branching system since it's just a merging business but this case happen clearly in a fork context with this kind of change. I understand my problem come from the conflict detection I could solve but there is one file I can't manage.

To be clear a last time about what I'm waiting for here :

A way to avoid conflict during merge from base to fork on specific declared lines. In this case the lines 2~3 of package-lock.json.

Any ways are welcome :)

EDIT:

Following @inigo solution, I'm investigate custom merge driver solutions taking praqma sample as model.

HollyPony
  • 817
  • 9
  • 15
  • Please update this question with details per my comment below. It appears you want something that is logically unreasonable. If not, explain. Flagging as needing clarification. – Inigo May 29 '20 at 21:01

1 Answers1

0

Set up a custom merge driver with the merge=ours strategy in .gitattributes:

package-lock.json merge=ours

Enable this strategy with:

git config --global merge.ours.driver true

You could do the same for package.json and discard the workaround you're using now.

Inigo
  • 12,186
  • 5
  • 41
  • 70
  • Sounds great ! I'll try that but I prefer keep conflicts that could happen on package.json if dependencies differ ^^ – HollyPony May 25 '20 at 07:31
  • IMO, that's not solving my issue but moving it. I prefer to keep conflicts happens on the other lines. Not marking the whole package-lock.json as "merge-ours". Assuming I have a new dependency in "fork" my conflict, this solution will result to a painful bug detection from package-lock. – HollyPony May 29 '20 at 07:35
  • Then what you're asking for is **completely unreasonable**. How do you expect git to magically know how to resolve the conflicts? That's the whole point: git is telling you: *I DON'T KNOW WHAT TO DO*. If I am misunderstanding your request, then **please update the details of your question** with how you expect conflicts to be resolved automatically, with machine logic that doesn't require what's in your head. Otherwise my solution is the best you can get. All you do is run `npm install` after the merge and it will put back in the missing items in `package-lock.json` from `package.json`. – Inigo May 29 '20 at 20:58
  • The point is I'm using `npm ci` which is using only the lock file. In another hand, I don't know if there is an npm way to solve it, I'm not lock with the git one. And as far I know, there is commands for `git rebase` allowing to select specific lines for operations. Your solution bring me to another complex merge drivers calling shell file that could be fit my case. Still WIP. – HollyPony May 30 '20 at 07:48
  • I can't assume marking "solve" if solution pop another issues relative to the problem. I prefer this way to say "That's impossible" and keep the conflicts. Sounds like more reasonable. – HollyPony May 30 '20 at 07:51
  • Yup, you're being completely unreasonable, with procedures and desires that contradict each other. You aren't even willing to update your question with clearly defined specifics as I've requested. – Inigo Jun 03 '20 at 21:31