0

I'm having issues with merging branches of a shallow clone, and I can't seem to work my way through the steps required to make it happen. This one's a real git puzzler, and I look forward to finding someone who knows how to work this out.

I've written a Github Action that creates release builds for Hugo website projects. As provided by Github, I use actions/checkout to checkout the source branch of a repo, and I include the option to recurse submodules. (This is important because the merge conflict is happening as a result of the submodule references here.)

After checkout, my deploy scripts do a few things:

  1. Fetch and checkout the release branch where the build will be made
  2. Merge latest changes from the source branch to the release branch
  3. Build, commit, and push the release

If I set fetch-depth: 0 during the checkout step (clones the full history of the repo), it works great! The merge is handled by -s recursive Xtheirs, and everything is fine.

However, if I leave the default fetch-depth setting resulting in --depth=1, I get a shallow clone in which the merge always results in a conflict because I don't have enough branch history for the merge to know how it should resolve itself. The merge fails, and nothing else can happen after that.

Based on that info --

  • What git steps would I have to take to deepen the fetch history of the source branch, the target branch, and the submodule(s) enough to be able to merge the branches without conflict?

Test Cases --

I set up 2 test repos that you can find on this action wiki page. If you want to check out the action, the success/failure output, run your own tests, or just read more about what I've tried, please take a look. It would be too much to add here.

I struggled with this problem for a while before coming here, and now I'm hoping y'all can help me. Let me know if I missed any crucial info. Cheers!

aormsby
  • 126
  • 5
  • The submodule itself is not relevant: what you need is enough depth—some number N—such that the merge base(s) of the two to-be-merged commits are in the repository, along with the two to-be-merged commits. This integer N is at least 1 and at most the maximum depth of the repository (which cannot exceed the number of commits in the repository, but is usually smaller than that). So if there are T total commits, we know 1 ≤ N ≤ T. *Probably* N ≪ T. But: how much "much less than"? The answer depends on the shape of the commit graph. To compute it, we need ... the commit graph. – torek Oct 17 '21 at 05:25
  • What all this means is that the only guaranteed way to find N all at once is if you have the entire repository. Whoever *does* have the repository can find N. Whoever doesn't, either has to clone the entire thing to find N to find how shallow he can go, or else use an iterative approach: try something shallow-ish and if that's not enough, deepen repeatedly. Note that repeatedly deepening is somewhat expensive, so you will probably want to do it by "chunk" (eg 50 commits at a time). – torek Oct 17 '21 at 05:27

0 Answers0