git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Chris Jeschke <chrisjberlin@googlemail.com>
Cc: sbeller@google.com, git@vger.kernel.org
Subject: Re: inside the git folder
Date: Thu, 4 Oct 2018 13:03:27 +0200 (DST)	[thread overview]
Message-ID: <nycvar.QRO.7.76.6.1810041257010.73@tvgsbejvaqbjf.bet> (raw)
In-Reply-To: <CADWf5z4DNRj=+X5pUF-Pe4vTq01OmFLk7KMP-=_hWWOEmsJg4A@mail.gmail.com>

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
> 

  reply	other threads:[~2018-10-04 11:03 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-03 12:26 inside the git folder Chris Jeschke
2018-10-03 18:51 ` Stefan Beller
2018-10-04  7:42   ` Chris Jeschke
2018-10-04 11:03     ` Johannes Schindelin [this message]
2018-10-04 13:16     ` Stephen Smith

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=nycvar.QRO.7.76.6.1810041257010.73@tvgsbejvaqbjf.bet \
    --to=johannes.schindelin@gmx.de \
    --cc=chrisjberlin@googlemail.com \
    --cc=git@vger.kernel.org \
    --cc=sbeller@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).