On Wed, 13 Apr 2016 08:37:35 -0700
Michael wrote:
> > There's actually nothing to be surprised about: Git was explicitly
> > designed in a way to abstrain itself from managing authentication,
> > authorization and access controls. Hence, when a Git process is
> > being run to serve a push to a r
On Wed, 13 Apr 2016 17:34:00 +0300
Konstantin Khomoutov wrote:
[...]
> I should add that in my opinion, I'd better work towards having a
> written down policy on how to use the public repositories,
> *explained* and handed down to your developers. I mean, if a
> developer tries a push which fail
On 2016-04-13, at 7:34 AM, Konstantin Khomoutov
wrote:
>
> There's actually nothing to be surprised about: Git was explicitly
> designed in a way to abstrain itself from managing authentication,
> authorization and access controls. Hence, when a Git process is being
> run to serve a push to a
On Wed, 13 Apr 2016 06:43:11 -0700 (PDT)
JIMIT JOSHI wrote:
> Few days ago, One of my team mate done
> force push and we lost entire history of commit from the remote
> machine. Hopefully we have the up to date local branch in other
> developer's machine so things came back to normal in few hours
Hi There,
I am a big fan of GIT and uses it for most of my projects. I have heard
about force push since long ago but haven't tried it ever as it's
destructive command. Few days ago, One of my team mate done force push and
we lost entire history of commit from the remote machine. Hopefully we h
