list mirror (unofficial, one of many)
 help / color / Atom feed
From: "Aram Maliachi (WIPRO LIMITED)" <>
To: "" <>
Cc: "Kranz, Peter" <>,
	Marco"  <>
Subject: commit sized around 100 gb in changes failed to push to a TFS remote - Git
Date: Fri, 14 Jun 2019 16:47:59 +0000
Message-ID: <> (raw)
In-Reply-To: <>

To @Git Community
From the perspective of an Azure DevOps support engineer. I have a customer who is unable to make a push with following error:

fatal: The remote end hung up unexpectedly
failed to push some refs into

The local repository has only one change when comparing it to the remote and it is a commit labelled with SHA value: 504aedfdbb to a branch called gitTest
This being said the scheme is as following:

[Remote] - master

[Local] - gitTest branch

Important data:
- The commit 504aedfdbb contains +100 GB in file changes 
- The remote git repository is a TFS server
- Customer isn't building code - it is using the remote kind of as a storage service <- We understand these are not best practices but is the way customer is using Git and TFS. If @Git Community could confirm/elaborate on this customer may change up the current approach he is using.

Things tried:
- reset the history for the local repository back to the latest shared commit b946c27c  and committed something small which succeeded to push into remote into a brand new branch by running $ git push origin <name of local branch>
- cherry-picked the commit into local master and attempted to push = failed. <- this makes me think this is entirely caused by the oversized commit
- boosted up the http post buffer configuration = failed. Rolled configuration back to default according to the MSFT docs
- since this is a TFS server I initially though this could be caused by insufficient disk storage capacity in the server containing the TFS product. But @Vimal Thiagaraj has confirmed that the repositories size limit depend upon the remote TFS databases and not the server itself. Is there a limit on these databases or on how much changes can a git commit contain?

Things I've suggested to customer:
- commit more frequently in smaller batches
- understand that the nature of git is to collaborate and track versions of files over time - not a cloud storage provider

Would appreciate any insight on this @Git Community. Thanks to @Phillip Oakley who took the time to answer last time I posted a question to this mailing list.

       reply index

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
     [not found] ` <>
2019-06-14 16:47   ` Aram Maliachi (WIPRO LIMITED) [this message]
2019-06-14 18:40     ` Aram Maliachi (WIPRO LIMITED)
2019-06-16 22:49     ` Philip Oakley

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link list mirror (unofficial, one of many)

Archives are clonable:
	git clone --mirror
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Newsgroups are available over NNTP:

 note: .onion URLs require Tor:

AGPL code for this site: git clone public-inbox