While consolidating repos, I was able to merge history to a single repo successfully, into a feature branch (not master branch), using the --allow-unrelated-histories parameter. Issue is, we are using Azure DevOps, so when I pushed the changes to the central repo, and completed the pull request to our QA (parent) branch, the history did not follow. I am pretty sure it's because our merge strategy is squash commit.

I then did the following:

• In my local QA branch, I did git merge <feature-branch>, followed by git log and verified all the unrelated history showed up.
• I then did git push (I am project administrator and was able to bypass branch policies), which was successful. However in Azure DevOps, the history for a given file in the QA branch is still not there.

Short of redoing everything from scratch and ensuring I disable squash commit, is there a way I can merge the history after the fact, when it's on my local branch but not in the central repo?

CodePudding user response：

tl;dr: I think what you did actually worked, but I would consider redoing it anyway.

Details:

The problem was definitely caused by the squash merge, and your follow-up regular merge did have the desired effect. When viewing the history of a file in AzureDevOps you have different views, and the default is "Simple history". Try changing it to "Full history" or "Full history (simplify merges)" and my hunch is you'll see the additional commits. The second merge you did actually had no effect on the files, which I assume is why the default view doesn't include them.

Now, even if that solves your immediate desire of seeing the history, I'd consider fixing this regardless. If I were in your shoes, I would not want to have a big squashed commit followed by another merge with no effective changes, in the history forever. It's sort of messy, especially considering that certain default views won't include that history as you've witnessed. Since it sounds like you're in rewrite mode anyway right now, I would take this opportunity to redo that merge properly. Note it doesn't have to be "redoing everything from scratch", since all you have to do is reset the QA branch to where it was just before the squash commit, force push it out, and then re-do the PR with the same feature branch. Note even if that feature branch no longer exists you can simply re-create it from the commit ID it was on, which should be viewable in the PR history in AzureDevOps if you need to reference it. Obviously the simplicity of just redoing that one PR assumes there are no other PRs that hit the QA branch since yours. If there are more that need to be redone, you'll need to decide if it's worth the effort to redo those as well.

Additional Thoughts:

You may not actually have to redo the PR(s) if you'd prefer to skip it. You could consider doing a rebase and combining the --onto and --rebase-merges options and then force pushing out your rewritten QA branch. (I'll leave determining how to do that as a separate exercise, particularly because I don't actually recommend doing it in this case.) However, if you only have a small number of PRs to redo I'd probably go that route, so that the commit IDs in the PR history match up with those in the repo. Another option, since you have the ability to bypass PR policies, is to redo the PR(s), and then complete it with an override, in case you don't wish to involve other people in this process.

Lastly, this is a very minor point, but I want to mention a wording mishap in one of your statements:

In my local QA branch, I did git merge , followed by git log and verified all the unrelated history showed up.

Actually, that history is related. The word "unrelated" means that there is no shared commit in the history. Unrelated happens when you're merging two repos that began from different root commits, and that's why you must use the --allow-unrelated-histories option for merging two repos together.