From: "Aram Maliachi (WIPRO LIMITED)" <email@example.com> To: "firstname.lastname@example.org" <email@example.com> Cc: "Kranz, Peter" <firstname.lastname@example.org>, "Brettschneider, Marco" <email@example.com> 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: <MN2PR21MB1231DB1D2FCE7622F0AED616E9EE0@MN2PR21MB1231.namprd21.prod.outlook.com> (raw) In-Reply-To: <DE8A44FD55B8BE44AC9861D8ECF567F801FEEC1D@DEFTHW99EM2MSX.ww902.siemens.net> 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 https://zelos.healthcare.siemens.com/tfs/Hoover/VA20A.DevInt.Gvfs/_git/Saturn 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 b946c27c [Local] - gitTest branch 504aedfdbb b946c27c 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 https://docs.microsoft.com/en-us/azure/devops/repos/git/rpc-failures-http-postbuffer?view=azure-devops - 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.
next parent reply index Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <MN2PR21MB1231B057E9E662BB151B2819E9EF0@MN2PR21MB1231.namprd21.prod.outlook.com> [not found] ` <DE8A44FD55B8BE44AC9861D8ECF567F801FEEC1D@DEFTHW99EM2MSX.ww902.siemens.net> 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: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: http://vger.kernel.org/majordomo-info.html * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=MN2PR21MB1231DB1D2FCE7622F0AED616E9EE0@MN2PR21MB1231.namprd21.prod.outlook.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
firstname.lastname@example.org list mirror (unofficial, one of many) Archives are clonable: git clone --mirror http://public-inbox.org/git 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: nntp://news.public-inbox.org/inbox.comp.version-control.git nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git nntp://news.gmane.org/gmane.comp.version-control.git note: .onion URLs require Tor: https://www.torproject.org/ AGPL code for this site: git clone https://public-inbox.org/ public-inbox