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
Stefan BellerRe: inside the git folder
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
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
Johannes SchindelinRe: inside the git folder
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
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