1

Working for a small software company, I recently ran into a number of merge conflicts trying to pull in changes from a 3rd party upstream repository.

The problem is that the upstream repository includes a lot of constantly growing binary assets.

After some deliberation, it was decided that our fork would strip those out and place them into submodules.

As the maintainer of the original repo is against using submodules for the binary assets as well as third party libraries, this creates some difficulties merging changes.

What would be considered the best strategy here?

I've been thinking about adding a .gitattributes file and defining the "ours" merge target for the main repository and then separately pulling in changes for all the submodules.

Is there anything more straightforward? Perhaps a way to make the submodules behave just like the original directories during a merge?

PS: It probably doesn't matter much. But the original repo is on Github while ours is stored on bitbucket.

EDIT: I just realized the maintainer of the original repo has added .gitattributes to .gitignore. This will probably make it harder to apply a merge strategy, won't it?

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
user237251
  • 211
  • 1
  • 10

1 Answers1

0

By making the binary folder a binary, you replace an folder entry in the index by a gitlink (a special entry which records the SHA1 of the submodule repo you are using).

That means any merge from upstream should ignore that entry.

One simple way is described in "How to make git ignore a directory while merging", where you merge without making an immediate commit, and reset /path/to/folder

But you would still have to update the content of that binary folder after merging the rest of the repo.

The OP manage those steps by a script merge-upstream.sh.

Inside that script:

  • I make sure to initialize and update the submodules (apparently this is a requirement before doing a merge like that),
  • add the upstream remote target and
  • solve the merge conflict by running "git add *" followed by a 3 second timeout and a "git commit -m 'upstream merge'".

I still need to add a few lines to pull in changes for the submodules,

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Thanks for the input. The way I ended up doing it (for now) is by creating a shell script called merge-upstream.sh. Inside that script, I make sure to initialize and update the submodules (apparently this is a requirement before doing a merge like that), add the upstream remote target and solve the merge conflict by running "git add *" followed by a 3 second timeout and a "git commit -m 'upstream merge'". I still need to add a few lines to pull in changes for the submodules, but it's working great, so far. – user237251 Aug 13 '14 at 14:37
  • @user237251 That looks nice! I have included your comment in the answer for more visibility. – VonC Aug 13 '14 at 14:40