On Wed, Feb 11, 2009 at 10:23 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> "Ciprian Dorin, Craciun" <ciprian.craciun@xxxxxxxxx> 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@xxxxxxxxx> wrote:
>>> "Ciprian Dorin, Craciun" <ciprian.craciun@xxxxxxxxx> writes:
>>>
>>>> On Wed, Feb 11, 2009 at 9:27 PM, Junio C Hamano <gitster@xxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
