inside the git folder

inside the git folder

[Chris Jeschke]

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?

Kind Regards,

Christian

Re: inside the git folder

[Stefan Beller]

On Wed, Oct 3, 2018 at 5:26 AM Chris Jeschke
<chrisjberlin@googlemail.com> 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

Re: inside the git folder

[Chris Jeschke]

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@google.com>:
>
> On Wed, Oct 3, 2018 at 5:26 AM Chris Jeschke
> <chrisjberlin@googlemail.com> 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

Re: inside the git folder

[Johannes Schindelin]

Hi Chris,

as mentioned by Stefan (who is a respected, active core Git contributor,
if you need any more arguments to listen to him), it is inappropriate to
copy the contents of the .git/ directory wholesale to another user's
machine.

For one, it would horribly break in case the user overrode `user.email` in
`.git/config`. That's one setting that should not be copied *anywhere*.
And that's just one, there are *plenty* more examples. Just think of
absolute paths referring to files that probably do not even exist on
another machine! Like, worktrees, etc.

Of course, you could start a list of exceptions (files, config keys, etc)
that should not be copied. But that's very fragile a solution.

So no, copying the .git/ directory is always the wrong thing to do, as
Stefan pointed out.

I could imagine that a much better idea is to identify a *positive* list
of things you want to copy over. The output of `git rev-parse
--symbolic-full-name HEAD`? Sure. Maybe even the output of `git rev-parse
--symbolic-full-name HEAD@{u}`? And then the URL of the corresponding
remote? Sure. `.git/objects/alternates/`? Absolutely not.

It is tedious, alright, but you simply cannot copy the contents of .git/
to another machine and expect that to work.

Ciao,
Johannes

On Thu, 4 Oct 2018, Chris Jeschke wrote:

> 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@google.com>:
> >
> > On Wed, Oct 3, 2018 at 5:26 AM Chris Jeschke
> > <chrisjberlin@googlemail.com> 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
> 

Re: inside the git folder

[Stephen Smith]

Chris -

You may want to look at "git bundle" to transfer the repository contents.   
Then the recipient could fetch from the bundle to get the source git history.

Just a thought.

sps

On Thursday, October 4, 2018 4:03:27 AM MST Johannes Schindelin wrote:
> Hi Chris,
> 
> as mentioned by Stefan (who is a respected, active core Git contributor,
> if you need any more arguments to listen to him), it is inappropriate to
> copy the contents of the .git/ directory wholesale to another user's
> machine.
> 
> For one, it would horribly break in case the user overrode `user.email` in
> `.git/config`. That's one setting that should not be copied *anywhere*.
> And that's just one, there are *plenty* more examples. Just think of
> absolute paths referring to files that probably do not even exist on
> another machine! Like, worktrees, etc.
> 
> Of course, you could start a list of exceptions (files, config keys, etc)
> that should not be copied. But that's very fragile a solution.
> 
> So no, copying the .git/ directory is always the wrong thing to do, as
> Stefan pointed out.
> 
> I could imagine that a much better idea is to identify a *positive* list
> of things you want to copy over. The output of `git rev-parse
> --symbolic-full-name HEAD`? Sure. Maybe even the output of `git rev-parse
> --symbolic-full-name HEAD@{u}`? And then the URL of the corresponding
> remote? Sure. `.git/objects/alternates/`? Absolutely not.
> 
> It is tedious, alright, but you simply cannot copy the contents of .git/
> to another machine and expect that to work.
> 
> Ciao,
> Johannes
> 
> On Thu, 4 Oct 2018, Chris Jeschke wrote:
> > 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@google.com>:
> > > On Wed, Oct 3, 2018 at 5:26 AM Chris Jeschke
> > > 
> > > <chrisjberlin@googlemail.com> 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