Thanks for the follow up ideas.

We also decided to access the repos through ssh. With that, there is
no delay at all.


On 13 June 2013 16:29, Thomas Rast <> wrote:
> Tamas Csabina <> writes:
>> Meanwhile I`ve figured it out that the sluggish post-receive execution
>> was due to a (mis)-configuration in the samba share where the remote
>> repository is hosted. These are:
>> oplocks = No
>> level2 oplocks = No
> [...]
>> Now, do I have to worry about allowing oplocks on the remote
>> repository from the git point of view? Thinking about concurrent push
>> operations from different developers?
> From a brief glance at the relevant docs [1], it would seem that oplocks
> are actually just an implementation detail for safe (in the context of
> parallel access) client caching.  So they should be fully transparent to
> any application usage.  However, the docs do mention that you may be in
> trouble if the connection to the server times out.
> That being said, some FSes see more usage and thus have been tested more
> in this context, and git does tend to show some pretty weird issues on
> broken network FSes (one such case: Lustre[2]).
> In addition, there are some known races w.r.t. the handling of refs, and
> of pruning, if you run git-gc while concurrent pushes are going on.
> Jeff King and Michael Haggerty are currently working on getting them
> fixed, see e.g. [3].  To see these, you'll have to hit the repo much
> harder than a small team can.
> So it *should* work, at least if you disable and run git-gc
> manually at some safe time.  But I wouldn't be surprised if there are
> bugs lurking in the context of Windows usage on a Samba-hosted repo,
> which sounds like a very rare combination.
> And in any case, don't take my word for it; if your life or company
> depends on this, you'll need to do your own testing to ensure that it
> holds up.
> Oh, and why do it that way?  You would most likely get much better
> performance out of it if you hosted the repo over ssh (e.g. with
> gitolite[4]) or a smart-http server, since the expensive operations (and
> they are *expensive*) would be completely local to the server.  The
> tradeoff there is that it also shifts a lot of CPU work to the server,
> but if you can afford it, you should see a great speedup especially when
> fetching large amounts of data (e.g. at cloen time).
> [1]  
> [2]
> [3]
> [4]
> --
> Thomas Rast
> trast@{inf,student}
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to