{"thread":{"id":"49476","subject":"inside the git folder","startedAt":"2018-10-03T12:26:26Z","lastAt":"2018-10-04T13:16:40Z","messageCount":5,"participants":["Chris Jeschke","Stefan Beller","Johannes Schindelin","Stephen Smith"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"359512","messageId":"CADWf5z4pAR20qeoT1RnYENBB7Q5fA2fVVTNqPzMzvOE5Dq02qA@mail.gmail.com","threadId":"49476","inReplyTo":null,"subject":"inside the git folder","fromName":"Chris Jeschke","fromEmail":"chrisjberlin@googlemail.com","sentAt":"2018-10-03T12:26:11Z","receivedAt":"2018-10-03T12:26:26Z","isPatch":false,"sender":{"key":"chrisjberlin@googlemail.com","avatar":null},"body":"Hey git-team,\nI am working on a plug-in for a distributed pair programming tool. To\nskip the details: I was thinking about sending parts of the git folder\nas a zip folder with our own Bytestream instead of using the git API.\nIs there a common sense about what should and what shouldn't be done\nwhen working with the files inside the git folder?\n\nKind Regards,\n\nChristian\n"},{"id":"359563","messageId":"CAGZ79kZ=FXEgTgZ7hO_7O2Qo-ze9ykQW0_Vgr=m7MFe8mc9+Mg@mail.gmail.com","threadId":"49476","inReplyTo":"CADWf5z4pAR20qeoT1RnYENBB7Q5fA2fVVTNqPzMzvOE5Dq02qA@mail.gmail.com","subject":"Re: inside the git folder","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2018-10-03T18:51:27Z","receivedAt":"2018-10-03T18:51:42Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Wed, Oct 3, 2018 at 5:26 AM Chris Jeschke\n<chrisjberlin@googlemail.com> wrote:\n>\n> Hey git-team,\n> I am working on a plug-in for a distributed pair programming tool. To\n> skip the details: I was thinking about sending parts of the git folder\n> as a zip folder with our own Bytestream instead of using the git API.\n> Is there a common sense about what should and what shouldn't be done\n> when working with the files inside the git folder?\n\nThis contradicts the security model of git.\nLocally I can do things like:\n    git config alias.co \"rm -rf ~\"\n    echo \"rm -rf ~\" >.git/hooks/{...}\nand I would experience bad things, but that is ok,\nas I configured it locally (supposedly I know what\nI am doing); but if I have the ability to send these\ntricks to my beloved coworkers, hilarity might ensue.\n\nWhat stuff do you need to send around?\n\nobjects? Fine, as the receive could check they are\ngood using fsck.\n\nrefs/ ? Sure. It may be confusing to users,\nbut I am sure you'll figure UX out.\n\nlocal config, hooks ? I would not.\n\nNot sure what else you'd think of sending around.\n\nCheers,\nStefan\n"},{"id":"359609","messageId":"CADWf5z4DNRj=+X5pUF-Pe4vTq01OmFLk7KMP-=_hWWOEmsJg4A@mail.gmail.com","threadId":"49476","inReplyTo":"CAGZ79kZ=FXEgTgZ7hO_7O2Qo-ze9ykQW0_Vgr=m7MFe8mc9+Mg@mail.gmail.com","subject":"Re: inside the git folder","fromName":"Chris Jeschke","fromEmail":"chrisjberlin@googlemail.com","sentAt":"2018-10-04T07:42:02Z","receivedAt":"2018-10-04T07:42:17Z","isPatch":false,"sender":{"key":"chrisjberlin@googlemail.com","avatar":null},"body":"Hi Stefan,\n\nthanks for your answer.\n\nThe Goal after sending the files is to have a copy on the remote site.\nThis includes that the working directory is the same (what we already\nguarantee with our tool) and that git is at the same 'state' (that\nmeans that we have the same history and that we checkout at the same\nbranch/commit).\nMy idea:\nSend the working directory with our  tool\nInitialize a Git directory on the remote side\nSend the 'objects','refs', 'HEAD' and the 'gitignore' with our tool\n\nIs there anything else I should take care of?\n\nAm Mi., 3. Okt. 2018 um 20:51 Uhr schrieb Stefan Beller <sbeller@google.com>:\n>\n> On Wed, Oct 3, 2018 at 5:26 AM Chris Jeschke\n> <chrisjberlin@googlemail.com> wrote:\n> >\n> > Hey git-team,\n> > I am working on a plug-in for a distributed pair programming tool. To\n> > skip the details: I was thinking about sending parts of the git folder\n> > as a zip folder with our own Bytestream instead of using the git API.\n> > Is there a common sense about what should and what shouldn't be done\n> > when working with the files inside the git folder?\n>\n> This contradicts the security model of git.\n> Locally I can do things like:\n>     git config alias.co \"rm -rf ~\"\n>     echo \"rm -rf ~\" >.git/hooks/{...}\n> and I would experience bad things, but that is ok,\n> as I configured it locally (supposedly I know what\n> I am doing); but if I have the ability to send these\n> tricks to my beloved coworkers, hilarity might ensue.\n>\n> What stuff do you need to send around?\n>\n> objects? Fine, as the receive could check they are\n> good using fsck.\n>\n> refs/ ? Sure. It may be confusing to users,\n> but I am sure you'll figure UX out.\n>\n> local config, hooks ? I would not.\n>\n> Not sure what else you'd think of sending around.\n>\n> Cheers,\n> Stefan\n"},{"id":"359616","messageId":"nycvar.QRO.7.76.6.1810041257010.73@tvgsbejvaqbjf.bet","threadId":"49476","inReplyTo":"CADWf5z4DNRj=+X5pUF-Pe4vTq01OmFLk7KMP-=_hWWOEmsJg4A@mail.gmail.com","subject":"Re: inside the git folder","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2018-10-04T11:03:27Z","receivedAt":"2018-10-04T11:03:27Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Chris,\n\nas mentioned by Stefan (who is a respected, active core Git contributor,\nif you need any more arguments to listen to him), it is inappropriate to\ncopy the contents of the .git/ directory wholesale to another user's\nmachine.\n\nFor one, it would horribly break in case the user overrode `user.email` in\n`.git/config`. That's one setting that should not be copied *anywhere*.\nAnd that's just one, there are *plenty* more examples. Just think of\nabsolute paths referring to files that probably do not even exist on\nanother machine! Like, worktrees, etc.\n\nOf course, you could start a list of exceptions (files, config keys, etc)\nthat should not be copied. But that's very fragile a solution.\n\nSo no, copying the .git/ directory is always the wrong thing to do, as\nStefan pointed out.\n\nI could imagine that a much better idea is to identify a *positive* list\nof things you want to copy over. The output of `git rev-parse\n--symbolic-full-name HEAD`? Sure. Maybe even the output of `git rev-parse\n--symbolic-full-name HEAD@{u}`? And then the URL of the corresponding\nremote? Sure. `.git/objects/alternates/`? Absolutely not.\n\nIt is tedious, alright, but you simply cannot copy the contents of .git/\nto another machine and expect that to work.\n\nCiao,\nJohannes\n\nOn Thu, 4 Oct 2018, Chris Jeschke wrote:\n\n> Hi Stefan,\n> \n> thanks for your answer.\n> \n> The Goal after sending the files is to have a copy on the remote site.\n> This includes that the working directory is the same (what we already\n> guarantee with our tool) and that git is at the same 'state' (that\n> means that we have the same history and that we checkout at the same\n> branch/commit).\n> My idea:\n> Send the working directory with our  tool\n> Initialize a Git directory on the remote side\n> Send the 'objects','refs', 'HEAD' and the 'gitignore' with our tool\n> \n> Is there anything else I should take care of?\n> \n> Am Mi., 3. Okt. 2018 um 20:51 Uhr schrieb Stefan Beller <sbeller@google.com>:\n> >\n> > On Wed, Oct 3, 2018 at 5:26 AM Chris Jeschke\n> > <chrisjberlin@googlemail.com> wrote:\n> > >\n> > > Hey git-team,\n> > > I am working on a plug-in for a distributed pair programming tool. To\n> > > skip the details: I was thinking about sending parts of the git folder\n> > > as a zip folder with our own Bytestream instead of using the git API.\n> > > Is there a common sense about what should and what shouldn't be done\n> > > when working with the files inside the git folder?\n> >\n> > This contradicts the security model of git.\n> > Locally I can do things like:\n> >     git config alias.co \"rm -rf ~\"\n> >     echo \"rm -rf ~\" >.git/hooks/{...}\n> > and I would experience bad things, but that is ok,\n> > as I configured it locally (supposedly I know what\n> > I am doing); but if I have the ability to send these\n> > tricks to my beloved coworkers, hilarity might ensue.\n> >\n> > What stuff do you need to send around?\n> >\n> > objects? Fine, as the receive could check they are\n> > good using fsck.\n> >\n> > refs/ ? Sure. It may be confusing to users,\n> > but I am sure you'll figure UX out.\n> >\n> > local config, hooks ? I would not.\n> >\n> > Not sure what else you'd think of sending around.\n> >\n> > Cheers,\n> > Stefan\n> \n"},{"id":"359618","messageId":"384680468.dD3INfo3AG@thunderbird","threadId":"49476","inReplyTo":"CADWf5z4DNRj=+X5pUF-Pe4vTq01OmFLk7KMP-=_hWWOEmsJg4A@mail.gmail.com","subject":"Re: inside the git folder","fromName":"Stephen Smith","fromEmail":"ischis2@cox.net","sentAt":"2018-10-04T13:16:36Z","receivedAt":"2018-10-04T13:16:40Z","isPatch":false,"sender":{"key":"ishchis2@gmail.com","avatar":null},"body":"Chris -\n\nYou may want to look at \"git bundle\" to transfer the repository contents.   \nThen the recipient could fetch from the bundle to get the source git history.\n\nJust a thought.\n\nsps\n\nOn Thursday, October 4, 2018 4:03:27 AM MST Johannes Schindelin wrote:\n> Hi Chris,\n> \n> as mentioned by Stefan (who is a respected, active core Git contributor,\n> if you need any more arguments to listen to him), it is inappropriate to\n> copy the contents of the .git/ directory wholesale to another user's\n> machine.\n> \n> For one, it would horribly break in case the user overrode `user.email` in\n> `.git/config`. That's one setting that should not be copied *anywhere*.\n> And that's just one, there are *plenty* more examples. Just think of\n> absolute paths referring to files that probably do not even exist on\n> another machine! Like, worktrees, etc.\n> \n> Of course, you could start a list of exceptions (files, config keys, etc)\n> that should not be copied. But that's very fragile a solution.\n> \n> So no, copying the .git/ directory is always the wrong thing to do, as\n> Stefan pointed out.\n> \n> I could imagine that a much better idea is to identify a *positive* list\n> of things you want to copy over. The output of `git rev-parse\n> --symbolic-full-name HEAD`? Sure. Maybe even the output of `git rev-parse\n> --symbolic-full-name HEAD@{u}`? And then the URL of the corresponding\n> remote? Sure. `.git/objects/alternates/`? Absolutely not.\n> \n> It is tedious, alright, but you simply cannot copy the contents of .git/\n> to another machine and expect that to work.\n> \n> Ciao,\n> Johannes\n> \n> On Thu, 4 Oct 2018, Chris Jeschke wrote:\n> > Hi Stefan,\n> > \n> > thanks for your answer.\n> > \n> > The Goal after sending the files is to have a copy on the remote site.\n> > This includes that the working directory is the same (what we already\n> > guarantee with our tool) and that git is at the same 'state' (that\n> > means that we have the same history and that we checkout at the same\n> > branch/commit).\n> > My idea:\n> > Send the working directory with our  tool\n> > Initialize a Git directory on the remote side\n> > Send the 'objects','refs', 'HEAD' and the 'gitignore' with our tool\n> > \n> > Is there anything else I should take care of?\n> > \n> > Am Mi., 3. Okt. 2018 um 20:51 Uhr schrieb Stefan Beller \n<sbeller@google.com>:\n> > > On Wed, Oct 3, 2018 at 5:26 AM Chris Jeschke\n> > > \n> > > <chrisjberlin@googlemail.com> wrote:\n> > > > Hey git-team,\n> > > > I am working on a plug-in for a distributed pair programming tool. To\n> > > > skip the details: I was thinking about sending parts of the git folder\n> > > > as a zip folder with our own Bytestream instead of using the git API.\n> > > > Is there a common sense about what should and what shouldn't be done\n> > > > when working with the files inside the git folder?\n> > > \n> > > This contradicts the security model of git.\n> > > \n> > > Locally I can do things like:\n> > >     git config alias.co \"rm -rf ~\"\n> > >     echo \"rm -rf ~\" >.git/hooks/{...}\n> > > \n> > > and I would experience bad things, but that is ok,\n> > > as I configured it locally (supposedly I know what\n> > > I am doing); but if I have the ability to send these\n> > > tricks to my beloved coworkers, hilarity might ensue.\n> > > \n> > > What stuff do you need to send around?\n> > > \n> > > objects? Fine, as the receive could check they are\n> > > good using fsck.\n> > > \n> > > refs/ ? Sure. It may be confusing to users,\n> > > but I am sure you'll figure UX out.\n> > > \n> > > local config, hooks ? I would not.\n> > > \n> > > Not sure what else you'd think of sending around.\n> > > \n> > > Cheers,\n> > > Stefan\n\n\n\n\n"}]}