git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Ciprian Dorin, Craciun" <ciprian.craciun@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Jeff King <peff@peff.net>,
	"Shawn O. Pearce" <spearce@spearce.org>,
	git@vger.kernel.org
Subject: Re: Git push failure in the case of SSH to localhost
Date: Wed, 11 Feb 2009 22:49:44 +0200	[thread overview]
Message-ID: <8e04b5820902111249n5fb87ff1r3d030b008fec0c28@mail.gmail.com> (raw)
In-Reply-To: <7vvdrgd8pb.fsf@gitster.siamese.dyndns.org>

On Wed, Feb 11, 2009 at 10:23 PM, Junio C Hamano <gitster@pobox.com> wrote:
> "Ciprian Dorin, Craciun" <ciprian.craciun@gmail.com> writes:
>
>>     I'll merge both Junio's and Jeff's emails into one... My answers bellow.
>>
>> On Wed, Feb 11, 2009 at 9:40 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> "Ciprian Dorin, Craciun" <ciprian.craciun@gmail.com> writes:
>>>
>>>> On Wed, Feb 11, 2009 at 9:27 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>>>
>>>>> And why isn't it in $HOME/bin/?
>>>>
>>>>     No, it is inside .git/bin folder.
>>>
>>> You are not answering my question.
>>>
>>> I questioned the sanity of putting the scripts in .git/bin/ per
>>> repository.  Why shouldn't a useful script like your "branch-import"
>>> available to _all_ your repositories, possibly taking customization per
>>> repository from repository's .git/config file, so that it does what is
>>> appropriate in each repository?
>> ...
>>     Both these solutions work fine, except one concern: when moving
>> the repository I would also want to move my scripts,...
>
> Define "moving the repository".  More often than not, people move their
> repositories with "git clone" than "tar cf - | tar xf -".
>
> No matter how you are moving it to a new location, you would want to have
> a working set of "regular environment" you normally work in.  Why aren't
> you moving/copying your $HOME/bin at the same time to get a more familiar
> and useful environment?  Viewed under this light, I think your "I move my
> repository to a new machine" is a made up example that is not interesting
> at all, if you ask me.
>
> There are additional security implications.  You can invite a victim to
> run "git diff" in your repository which runs your .git/bin/git-diff, for
> example.


    By moving the repository I mean moving it on another machine...
Let me give you an example...

    Thus (inspired by one of my current usages of Git) suppose I'm
working at a scientific project (let's assume algorithmic nature) and
after I succeed in having a working version of my algorithm, I decide
to test it on a better hardware with bigger workloads... For this I
make a tar of my repository, and un-tar it on the remote machine. (On
this remote machine, as I don't have administrative rights, I've
compiled by hand the latest version of git and put it somewhere on my
path. But it would have been nice if I would have had the latest git
version already installed...)

    (Looking even further, I could use such a procedure to distribute
my code to an entire cluster... Which I'm working to do right now...)

    Where do the repository-custom commands get into the scene? Well
let's suppose I also want to track the run-traces of my algorithm for
results reproduction / debugging purposes. But these files are big
text files that differ in many unimportant places, and thus I would
like `git diff` to show me only the meaning-full differences (by using
external diff feature)... Also the custom diff is not very simple (it
needs a couple sed / grep / other pre-processing), so I decide to
create a special command (like git-diff-traces) that I put inside the
bin folder... (Maybe I would like also some cleaning of unimportant
lines before committing...)

    (About the cluster thing, what about a command like
git-cluster-push... This could be reused...)

    Now as you can see, the special commands that handle my traces are
only valid for this particular algorithm, thus for this particular
repository...

    Now suppose I want to send a tar-ball of this repository to
another person, and I weren't using the special purpose bin dir, I
would also have to remember to send him the scripts that are in some
other place than the repository, and also he would have to remember to
put them into the PATH each time he wants to use them... So as you
see, a lot of manual labor...

    The simplest way (by using my patch) is to do the following:
    * either send a tar of the repository (that contains the bin) (of
course he needs the patched version of Git);
    * either tell him to clone the repository and run a simple command
like ./git-repo-initialize that would create the .git/bin folder and
symlink or copy the special scripts there...

    About the security issue, I don't see any, if we add the bin
folder at the end of the search path, or just after the official
installation path...

    I don't think that this feature is more unsafe than the hooks system...

    Ciprian Craciun.

  reply	other threads:[~2009-02-11 20:51 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-11 16:24 Git push failure in the case of SSH to localhost Ciprian Dorin, Craciun
2009-02-11 18:05 ` Jeff King
2009-02-11 18:42   ` Ciprian Dorin, Craciun
2009-02-11 18:44     ` Jeff King
2009-02-11 19:03       ` Ciprian Dorin, Craciun
2009-02-11 19:14         ` Shawn O. Pearce
2009-02-11 19:20           ` Ciprian Dorin, Craciun
2009-02-11 19:22             ` Jeff King
2009-02-11 19:32               ` Ciprian Dorin, Craciun
2009-02-11 19:42                 ` Jeff King
2009-02-11 20:03                   ` Ciprian Dorin, Craciun
2009-02-11 20:23                     ` Junio C Hamano
2009-02-11 20:49                       ` Ciprian Dorin, Craciun [this message]
2009-02-11 21:03                         ` Johannes Schindelin
2009-02-11 19:27             ` Junio C Hamano
2009-02-11 19:34               ` Ciprian Dorin, Craciun
2009-02-11 19:40                 ` Junio C Hamano

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

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

  git send-email \
    --in-reply-to=8e04b5820902111249n5fb87ff1r3d030b008fec0c28@mail.gmail.com \
    --to=ciprian.craciun@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    --cc=spearce@spearce.org \
    /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.
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 NNTP newsgroup(s).