Hi Stefan,
thanks for your answer.
The Goal after sending the files is to have a copy on the remote site.
This includes that the working directory is the same (what we already
guarantee with our tool) and that git is at the same 'state' (that
means that we have the same history and that we checkout at the same
branch/commit).
My idea:
Send the working directory with our tool
Initialize a Git directory on the remote side
Send the 'objects','refs', 'HEAD' and the 'gitignore' with our tool
Is there anything else I should take care of?
Am Mi., 3. Okt. 2018 um 20:51 Uhr schrieb Stefan Beller <sbeller@xxxxxxxxxx>:
>
> On Wed, Oct 3, 2018 at 5:26 AM Chris Jeschke
> <chrisjberlin@xxxxxxxxxxxxxx> wrote:
> >
> > Hey git-team,
> > I am working on a plug-in for a distributed pair programming tool. To
> > skip the details: I was thinking about sending parts of the git folder
> > as a zip folder with our own Bytestream instead of using the git API.
> > Is there a common sense about what should and what shouldn't be done
> > when working with the files inside the git folder?
>
> This contradicts the security model of git.
> Locally I can do things like:
> git config alias.co "rm -rf ~"
> echo "rm -rf ~" >.git/hooks/{...}
> and I would experience bad things, but that is ok,
> as I configured it locally (supposedly I know what
> I am doing); but if I have the ability to send these
> tricks to my beloved coworkers, hilarity might ensue.
>
> What stuff do you need to send around?
>
> objects? Fine, as the receive could check they are
> good using fsck.
>
> refs/ ? Sure. It may be confusing to users,
> but I am sure you'll figure UX out.
>
> local config, hooks ? I would not.
>
> Not sure what else you'd think of sending around.
>
> Cheers,
> Stefan
