From: Fredrik Gustafsson <iveqy@iveqy.com>
To: Renuka Pampana <prenuka@gmail.com>
Cc: Fredrik Gustafsson <iveqy@iveqy.com>, git@vger.kernel.org
Subject: Re: Git status takes too long- How to improve the performance of git
Date: Wed, 16 Nov 2016 14:21:54 +0100 [thread overview]
Message-ID: <20161116132154.GA18362@paksenarrion.iveqy.com> (raw)
In-Reply-To: <CAEAva_1JAu+kWmk3MZDFK=4CgQB5M+JN8FwzMVr6zKgXTAhdXw@mail.gmail.com>
On Wed, Nov 16, 2016 at 05:13:57PM +0530, Renuka Pampana wrote:
> > On Tue, Nov 15, 2016 at 02:33:12AM -0700, ravalika wrote:
> > > It is an centralized server and git status takes too long
> >
> > A centralized server? How? git is designed to be runned locally. If
> > you're running git on a network file system, the performance will
> > suffer. Could you elaborate on how your environment is setup?
> >
> >
> We have setup main git repository in remote location on Linux server
> And created a git repository in local Linux server, as a reference for the
> remote git repository,
> And update the local git repository for every 15 min in local server
>
> Users will be able to access the local git repository through NFS
And each user will have their own copy of the repository locally on
their machine? That is having done a git clone?
>
> All users will clone the git repository from remote project url by using
> local git repo as reference
>
> For example : git clone --reference ~/gitcaches/reference user@drupal
> :/home/project/drupal.git
>
> All the users have ssh credentials for the remote server
Why are you using --reference for a 8.9MB big clone?
>
>
> What is the best way to implement remote git repo and able to access the
> git repo from other location, without any performance glitches?
> Users should be able to access git repo from different servers and from
> different locations.
The best way is to have it locally cloned. Yes the initial clone will be
expensive but operations after that will be fairly smooth. You do not(!)
want to execute git on one machine and having the repository beeing on
an other machine (for example via a network file system, except git
clone, git fetch, git push, etc.).
> >
> > > How to improve the performance of git status
> > >
> > > Git repo details:
> > >
> > > Size of the .git folder is 8.9MB
> > > Number of commits approx 53838 (git rev-list HEAD --count)
> > > Number of branches - 330
> > > Number of files - 63883
> > > Working tree clone size is 4.3GB
> >
> > .git folder of 8.9 MEGABYTE and working tree of 4.3 GIGABYTE? Is this a
> > typo?
> >
> > All git related information is stored in .git directory of the working
> directory
> It is 8.9M
> And size of the local workspace is 4.3G
Can you please elaborate on this? How can you store 8.9 MB of data that
will result in a 4.3 G workspace?
--
Fredrik Gustafsson
phone: +46 733-608274
e-mail: iveqy@iveqy.com
website: http://www.iveqy.com
next prev parent reply other threads:[~2016-11-16 13:16 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-15 9:33 Git status takes too long- How to improve the performance of git ravalika
2016-11-15 10:24 ` Fredrik Gustafsson
2016-11-15 11:44 ` Christian Couder
[not found] ` <CAEAva_1JAu+kWmk3MZDFK=4CgQB5M+JN8FwzMVr6zKgXTAhdXw@mail.gmail.com>
2016-11-16 13:21 ` Fredrik Gustafsson [this message]
2016-11-15 15:10 ` Heiko Voigt
2016-11-24 8:38 ` MaryTurner
Reply instructions:
You may reply publicly 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=20161116132154.GA18362@paksenarrion.iveqy.com \
--to=iveqy@iveqy.com \
--cc=git@vger.kernel.org \
--cc=prenuka@gmail.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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).