0

I have been observing some very odd behavior with our Azure Devops Server 2019 server. Occasionally fetches pull down vastly more data than necessary to complete a fetch. This usually happens around large merges, however yesterday it happened with a relatively simple one.

I had two branches which were diverged by about a dozen commits. I had both branches fully checked out on my machine. I used a pull request to merge them together. Upon doing a fetch from my machine after the pull request completed, it required pulling down 28,000 files and 2GB of information and took an exceedingly long time to pull.

Any ideas why this would happen? The merge did not have any conflicts, only one side of the merge had changes since the last merge. (An ours merge indicating that a set of environmental configuration changes from the branch being merged in were irrelevant.) All the commits aside from the clean merge commit were already on my machine and checked out. This should have been a very simple operation, not require resending an appreciable portion of my repository.

AJ Henderson
  • 1,120
  • 1
  • 12
  • 32
  • Are you sure people didn't make giant commits, push them, then delete the files in the giant commits? Git repos contain **all** the history of **every** commit, even if files are later deleted. – Daniel Mann Nov 06 '19 at 14:56
  • Yes, it's all small project work. Even if I had to pull down the full 9 commits, pulling every file every time, it would be about 45 files and about 60MB, not 28,000 files and 2GB. – AJ Henderson Nov 06 '19 at 15:03

2 Answers2

0

I was able to solve the major case we were running in to, but not the initial illustration I used in this question.

The majority of our users that were running in to a problem like this were due to limited refs being enabled and a large limited ref got joined to the history chain by an "ours" merge. That isn't relevant to the particular case I experienced as I had relevant histories locally, but other people may encounter this problem due to a merge including previously unreferenced history much earlier in the history.

For now I haven't been able to reproduce my initial error, so I'll have to wait until the next time I see it (it tends to happen around branch cuts where the hidden history isn't a factor as well.) But if anyone else has any additional ideas, I'd love to hear them.

If anyone else encounters a similar error, using GIT_TRACE_PACKET to get the list of haves and wants is super helpful for working your way through the history and finding out the origin of the objects being fetched.

AJ Henderson
  • 1,120
  • 1
  • 12
  • 32
0

I was able to track down the root issue to a defect in Azure Devops Server. It appears that Azure Devops Server responds with an "ACK ready" prematurely during the fetch_pack/upload_pack negotiation phase. Despite two entire branch histories being undiscovered (for branches currently in the want list), Azure Devops gives a ready and begins the pack transfer.

AJ Henderson
  • 1,120
  • 1
  • 12
  • 32