Re: inside the git folder

[Stephen Smith <ischis2@cox.net>]

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