All of lore.kernel.org
 help / color / mirror / Atom feed
* Git push failure in the case of SSH to localhost
@ 2009-02-11 16:24 Ciprian Dorin, Craciun
  2009-02-11 18:05 ` Jeff King
  0 siblings, 1 reply; 17+ messages in thread
From: Ciprian Dorin, Craciun @ 2009-02-11 16:24 UTC (permalink / raw)
  To: git

    Hello all!

    I've encountered the following error situations: git fails to push
a branch over ssh to localhost, even with file: protocol it has the
same behaviour... Please see the transcript... (Git version is
1.6.1.1) I don't think I'm doing something wrong, because this works
just fine with a real remote host...

    Thanks,
    Ciprian Craciun.

    P.S.: I'm using a slightly modified version of Git, but this patch
affects only the PATH-like search mechanism for git commands.

----

    0  git version
git version 1.6.1.1.dirty

    1  cd /tmp
    2  mkdir r1
    3  cd r1
    4  git init
    5  cd ..
    6  mkdir r2
    7  cd r2
    8  git init --bare
    9  cd ..
   10  cd r1
   11  echo a>a
   12  git add .
   13  git commit -m '--'

   14  git push ssh://localhost/tmp/r2 master
Counting objects: 3, done.
Writing objects: 100% (3/3), 197 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
error: unpack should have generated
ea8c5601f49a4bdeea03db3adb909d590ea730d3, but I can't find it!
To ssh://localhost/tmp/r2
 ! [remote rejected] master -> master (bad pack)
error: failed to push some refs to 'ssh://localhost/tmp/r2'

   15  git push file:///tmp/r2 master
Counting objects: 3, done.
Writing objects: 100% (3/3), 197 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
error: unpack should have generated
ea8c5601f49a4bdeea03db3adb909d590ea730d3, but I can't find it!
To file:///tmp/r2
 ! [remote rejected] master -> master (bad pack)
error: failed to push some refs to 'file:///tmp/r2'

    16 git push ssh://hephaistos.tartarus./tmp/r2 master
Counting objects: 3, done.
Writing objects: 100% (3/3), 197 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To ssh://dom1.hephaistos.tartarus./tmp/r2
 * [new branch]      master -> master

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Git push failure in the case of SSH to localhost
  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
  0 siblings, 1 reply; 17+ messages in thread
From: Jeff King @ 2009-02-11 18:05 UTC (permalink / raw)
  To: Ciprian Dorin, Craciun; +Cc: git

On Wed, Feb 11, 2009 at 06:24:29PM +0200, Ciprian Dorin, Craciun wrote:

>    15  git push file:///tmp/r2 master
> Counting objects: 3, done.
> Writing objects: 100% (3/3), 197 bytes, done.
> Total 3 (delta 0), reused 0 (delta 0)
> error: unpack should have generated
> ea8c5601f49a4bdeea03db3adb909d590ea730d3, but I can't find it!
> To file:///tmp/r2
>  ! [remote rejected] master -> master (bad pack)
> error: failed to push some refs to 'file:///tmp/r2'

I can't reproduce the problem here. It looks like your receive-pack is
somehow broken (which should be the only difference between pushing to a
local repo and a remote one).

Can you try with a vanilla version of git to be sure it is not your
add-on patch responsible?

-Peff

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Git push failure in the case of SSH to localhost
  2009-02-11 18:05 ` Jeff King
@ 2009-02-11 18:42   ` Ciprian Dorin, Craciun
  2009-02-11 18:44     ` Jeff King
  0 siblings, 1 reply; 17+ messages in thread
From: Ciprian Dorin, Craciun @ 2009-02-11 18:42 UTC (permalink / raw)
  To: Jeff King; +Cc: git

On Wed, Feb 11, 2009 at 8:05 PM, Jeff King <peff@peff.net> wrote:
> On Wed, Feb 11, 2009 at 06:24:29PM +0200, Ciprian Dorin, Craciun wrote:
>
>>    15  git push file:///tmp/r2 master
>> Counting objects: 3, done.
>> Writing objects: 100% (3/3), 197 bytes, done.
>> Total 3 (delta 0), reused 0 (delta 0)
>> error: unpack should have generated
>> ea8c5601f49a4bdeea03db3adb909d590ea730d3, but I can't find it!
>> To file:///tmp/r2
>>  ! [remote rejected] master -> master (bad pack)
>> error: failed to push some refs to 'file:///tmp/r2'
>
> I can't reproduce the problem here. It looks like your receive-pack is
> somehow broken (which should be the only difference between pushing to a
> local repo and a remote one).
>
> Can you try with a vanilla version of git to be sure it is not your
> add-on patch responsible?
>
> -Peff

    Indeed it seems it's from my patch... Because with a vanila
1.6.1.1 it works perfectly... I'll dig into what I've done, although I
couldn't imagine that it was from my patch...

    For now I see that the problem comes from the function
setup_git_directory_gentry which I call inside the setup_path function
in exec_cmd.c
    Can someone help? (My patch is below...)

    Thanks,
    Ciprian Craciun.

--------

diff --git a/exec_cmd.c b/exec_cmd.c
index cdd35f9..1513ee0 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -44,6 +44,44 @@ const char *git_exec_path(void)
 	return system_path(GIT_EXEC_PATH);
 }

+/* Returns the path of the bin folder inside the .git folder. */
+/* (This could be used to store repository specific git programs.) */
+const char *git_repo_exec_path(void)
+{
+	static char path_buffer[PATH_MAX + 1];
+	static char *path = NULL;
+	
+	int non_git;
+	const char *git_dir;
+	char cwd[PATH_MAX + 1];
+	
+	if (!path) {
+		
+		path = path_buffer;
+		path[0] = '\0';
+		
+		if (!getcwd(cwd, PATH_MAX))
+			die("git_repo_exec_path: can not getcwd");
+		
+		setup_git_directory_gently(&non_git);
+		
+		if (!non_git) {
+			
+			git_dir = get_git_dir();
+			strncat(path, git_dir, PATH_MAX);
+			strncat(path, "/", PATH_MAX);
+			strncat(path, "bin", PATH_MAX);
+			
+			strncpy(path, make_absolute_path(path), PATH_MAX);
+			
+			if (chdir(cwd))
+				die("git_repo_exec_path: can not chdir to '%s'", cwd);
+		}
+	}
+	
+	return path;
+}
+
 static void add_path(struct strbuf *out, const char *path)
 {
 	if (path && *path) {
@@ -61,6 +99,7 @@ void setup_path(void)
 	const char *old_path = getenv("PATH");
 	struct strbuf new_path = STRBUF_INIT;

+	add_path(&new_path, git_repo_exec_path());
 	add_path(&new_path, argv_exec_path);
 	add_path(&new_path, getenv(EXEC_PATH_ENVIRONMENT));
 	add_path(&new_path, system_path(GIT_EXEC_PATH));

^ permalink raw reply related	[flat|nested] 17+ messages in thread

* Re: Git push failure in the case of SSH to localhost
  2009-02-11 18:42   ` Ciprian Dorin, Craciun
@ 2009-02-11 18:44     ` Jeff King
  2009-02-11 19:03       ` Ciprian Dorin, Craciun
  0 siblings, 1 reply; 17+ messages in thread
From: Jeff King @ 2009-02-11 18:44 UTC (permalink / raw)
  To: Ciprian Dorin, Craciun; +Cc: git

On Wed, Feb 11, 2009 at 08:42:25PM +0200, Ciprian Dorin, Craciun wrote:

>     For now I see that the problem comes from the function
> setup_git_directory_gentry which I call inside the setup_path function
> in exec_cmd.c

I think you probably end up calling setup_git_directory_gently twice,
which is known to have weird interactions.

-Peff

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Git push failure in the case of SSH to localhost
  2009-02-11 18:44     ` Jeff King
@ 2009-02-11 19:03       ` Ciprian Dorin, Craciun
  2009-02-11 19:14         ` Shawn O. Pearce
  0 siblings, 1 reply; 17+ messages in thread
From: Ciprian Dorin, Craciun @ 2009-02-11 19:03 UTC (permalink / raw)
  To: Jeff King; +Cc: git

On Wed, Feb 11, 2009 at 8:44 PM, Jeff King <peff@peff.net> wrote:
> On Wed, Feb 11, 2009 at 08:42:25PM +0200, Ciprian Dorin, Craciun wrote:
>
>>     For now I see that the problem comes from the function
>> setup_git_directory_gentry which I call inside the setup_path function
>> in exec_cmd.c
>
> I think you probably end up calling setup_git_directory_gently twice,
> which is known to have weird interactions.
>
> -Peff

    Indeed it gets called twice...

    Here is what I'm trying to accomplish: I want to add to the git
search path also the folder ${GIT_DIR}/bin if this already exists...
(This allows me to have repository specific commands...)

    So in order to obtain GIT_DIR (get_git_dir function), I have to
call setup_git_directory_gently...

    Is there another way to obtain the right GIT_DIR?

    Ciprian.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Git push failure in the case of SSH to localhost
  2009-02-11 19:03       ` Ciprian Dorin, Craciun
@ 2009-02-11 19:14         ` Shawn O. Pearce
  2009-02-11 19:20           ` Ciprian Dorin, Craciun
  0 siblings, 1 reply; 17+ messages in thread
From: Shawn O. Pearce @ 2009-02-11 19:14 UTC (permalink / raw)
  To: Ciprian Dorin, Craciun; +Cc: Jeff King, git

"Ciprian Dorin, Craciun" <ciprian.craciun@gmail.com> wrote:
> 
>     Here is what I'm trying to accomplish: I want to add to the git
> search path also the folder ${GIT_DIR}/bin if this already exists...
> (This allows me to have repository specific commands...)

for f in `cd $(git rev-parse --git-dir)/bin && ls *`; do
  git config alias.$f '!$(git rev-parse --git-dir)/bin/'$f
done

No need to patch git.
 
-- 
Shawn.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Git push failure in the case of SSH to localhost
  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:27             ` Junio C Hamano
  0 siblings, 2 replies; 17+ messages in thread
From: Ciprian Dorin, Craciun @ 2009-02-11 19:20 UTC (permalink / raw)
  To: Shawn O. Pearce; +Cc: Jeff King, git

On Wed, Feb 11, 2009 at 9:14 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
> "Ciprian Dorin, Craciun" <ciprian.craciun@gmail.com> wrote:
>>
>>     Here is what I'm trying to accomplish: I want to add to the git
>> search path also the folder ${GIT_DIR}/bin if this already exists...
>> (This allows me to have repository specific commands...)
>
> for f in `cd $(git rev-parse --git-dir)/bin && ls *`; do
>  git config alias.$f '!$(git rev-parse --git-dir)/bin/'$f
> done
>
> No need to patch git.
>
> --
> Shawn.

    :) Yes I know about the alias trick...

    But I find it easier to just create a bin folder and drop my
scripts there... (For example git-branch-import that takes a new
branch name and an URL and creates the branch with no ancestry and
knows http, ftp, svn, tar.{gz,bz2}, zip, etc...)

    Ciprian.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Git push failure in the case of SSH to localhost
  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:27             ` Junio C Hamano
  1 sibling, 1 reply; 17+ messages in thread
From: Jeff King @ 2009-02-11 19:22 UTC (permalink / raw)
  To: Ciprian Dorin, Craciun; +Cc: Shawn O. Pearce, git

On Wed, Feb 11, 2009 at 09:20:51PM +0200, Ciprian Dorin, Craciun wrote:

>     But I find it easier to just create a bin folder and drop my
> scripts there... (For example git-branch-import that takes a new
> branch name and an URL and creates the branch with no ancestry and
> knows http, ftp, svn, tar.{gz,bz2}, zip, etc...)

I don't see what is per-repo about that. That is, why not put it in a
PATH directory accessible by all repos. And if there is some
repo-specific data, you can have the script read it from the current
repo by "git config".

-Peff

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Git push failure in the case of SSH to localhost
  2009-02-11 19:20           ` Ciprian Dorin, Craciun
  2009-02-11 19:22             ` Jeff King
@ 2009-02-11 19:27             ` Junio C Hamano
  2009-02-11 19:34               ` Ciprian Dorin, Craciun
  1 sibling, 1 reply; 17+ messages in thread
From: Junio C Hamano @ 2009-02-11 19:27 UTC (permalink / raw)
  To: Ciprian Dorin, Craciun; +Cc: Shawn O. Pearce, Jeff King, git

"Ciprian Dorin, Craciun" <ciprian.craciun@gmail.com> writes:

> On Wed, Feb 11, 2009 at 9:14 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
>> "Ciprian Dorin, Craciun" <ciprian.craciun@gmail.com> wrote:
>>>
>>>     Here is what I'm trying to accomplish: I want to add to the git
>>> search path also the folder ${GIT_DIR}/bin if this already exists...
>>> (This allows me to have repository specific commands...)
>>
>> for f in `cd $(git rev-parse --git-dir)/bin && ls *`; do
>>  git config alias.$f '!$(git rev-parse --git-dir)/bin/'$f
>> done
>>
>> No need to patch git.
>>
>> --
>> Shawn.
>
>     :) Yes I know about the alias trick...
>
>     But I find it easier to just create a bin folder and drop my
> scripts there... (For example git-branch-import that takes a new
> branch name and an URL and creates the branch with no ancestry and
> knows http, ftp, svn, tar.{gz,bz2}, zip, etc...)

And why isn't it in $HOME/bin/?

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Git push failure in the case of SSH to localhost
  2009-02-11 19:22             ` Jeff King
@ 2009-02-11 19:32               ` Ciprian Dorin, Craciun
  2009-02-11 19:42                 ` Jeff King
  0 siblings, 1 reply; 17+ messages in thread
From: Ciprian Dorin, Craciun @ 2009-02-11 19:32 UTC (permalink / raw)
  To: Jeff King; +Cc: Shawn O. Pearce, git

On Wed, Feb 11, 2009 at 9:22 PM, Jeff King <peff@peff.net> wrote:
> On Wed, Feb 11, 2009 at 09:20:51PM +0200, Ciprian Dorin, Craciun wrote:
>
>>     But I find it easier to just create a bin folder and drop my
>> scripts there... (For example git-branch-import that takes a new
>> branch name and an URL and creates the branch with no ancestry and
>> knows http, ftp, svn, tar.{gz,bz2}, zip, etc...)
>
> I don't see what is per-repo about that. That is, why not put it in a
> PATH directory accessible by all repos. And if there is some
> repo-specific data, you can have the script read it from the current
> repo by "git config".
>
> -Peff

    Well, it is per-repo because I've left out to tell you that the
git-branch-import command I use to track non-git source code
distributions for other projects... And my command constructs the
branch name in a certain way...

    Anyway, I don't see why it's wrong to have such a bin folder per
repository... Let's for a moment assume that there is a use case for
such a thing, I'm wondering what is wrong with this solution from a
Git perspective???

    Ciprian.

    P.S.: It seems that indeed setup_git_directory_gently (or
something in the setup system) is kind of broken if I call it twice...
So I'm trying to solve the problem from another angle... It seems that
setup_paths is called only from git.c, builtin-receive-pack.c,
upload-pack.c and shell.c... Thus I'll just work-around the problem by
adding the bin path only when it is called from git.c (which it has
worked for almost a year...)

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Git push failure in the case of SSH to localhost
  2009-02-11 19:27             ` Junio C Hamano
@ 2009-02-11 19:34               ` Ciprian Dorin, Craciun
  2009-02-11 19:40                 ` Junio C Hamano
  0 siblings, 1 reply; 17+ messages in thread
From: Ciprian Dorin, Craciun @ 2009-02-11 19:34 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Shawn O. Pearce, Jeff King, git

On Wed, Feb 11, 2009 at 9:27 PM, Junio C Hamano <gitster@pobox.com> wrote:
> "Ciprian Dorin, Craciun" <ciprian.craciun@gmail.com> writes:
>
>> On Wed, Feb 11, 2009 at 9:14 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
>>> "Ciprian Dorin, Craciun" <ciprian.craciun@gmail.com> wrote:
>>>>
>>>>     Here is what I'm trying to accomplish: I want to add to the git
>>>> search path also the folder ${GIT_DIR}/bin if this already exists...
>>>> (This allows me to have repository specific commands...)
>>>
>>> for f in `cd $(git rev-parse --git-dir)/bin && ls *`; do
>>>  git config alias.$f '!$(git rev-parse --git-dir)/bin/'$f
>>> done
>>>
>>> No need to patch git.
>>>
>>> --
>>> Shawn.
>>
>>     :) Yes I know about the alias trick...
>>
>>     But I find it easier to just create a bin folder and drop my
>> scripts there... (For example git-branch-import that takes a new
>> branch name and an URL and creates the branch with no ancestry and
>> knows http, ftp, svn, tar.{gz,bz2}, zip, etc...)
>
> And why isn't it in $HOME/bin/?

    No, it is inside .git/bin folder. I like to think to my bin folder
like the hooks folder... This way when I move a repository I move the
hooks and the specific commands.

    Ciprian.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Git push failure in the case of SSH to localhost
  2009-02-11 19:34               ` Ciprian Dorin, Craciun
@ 2009-02-11 19:40                 ` Junio C Hamano
  0 siblings, 0 replies; 17+ messages in thread
From: Junio C Hamano @ 2009-02-11 19:40 UTC (permalink / raw)
  To: Ciprian Dorin, Craciun; +Cc: Shawn O. Pearce, Jeff King, git

"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?

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Git push failure in the case of SSH to localhost
  2009-02-11 19:32               ` Ciprian Dorin, Craciun
@ 2009-02-11 19:42                 ` Jeff King
  2009-02-11 20:03                   ` Ciprian Dorin, Craciun
  0 siblings, 1 reply; 17+ messages in thread
From: Jeff King @ 2009-02-11 19:42 UTC (permalink / raw)
  To: Ciprian Dorin, Craciun; +Cc: Shawn O. Pearce, git

On Wed, Feb 11, 2009 at 09:32:29PM +0200, Ciprian Dorin, Craciun wrote:

>     Anyway, I don't see why it's wrong to have such a bin folder per
> repository... Let's for a moment assume that there is a use case for
> such a thing, I'm wondering what is wrong with this solution from a
> Git perspective???

It's not _wrong_, we're just suggesting ways that the same thing might
be accomplished more easily.

>     P.S.: It seems that indeed setup_git_directory_gently (or
> something in the setup system) is kind of broken if I call it twice...

Yes, I think your patch is running into a long-standing problem in the
git initialization code. There are problems if you need to look into the
repo dir to find out which command to execute, because finding the repo
dir changes the environment. There is a similar problem with aliases.

So I think getting your patch to run correctly may be hard. But I admit
I didn't look at it that closely.

-Peff

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Git push failure in the case of SSH to localhost
  2009-02-11 19:42                 ` Jeff King
@ 2009-02-11 20:03                   ` Ciprian Dorin, Craciun
  2009-02-11 20:23                     ` Junio C Hamano
  0 siblings, 1 reply; 17+ messages in thread
From: Ciprian Dorin, Craciun @ 2009-02-11 20:03 UTC (permalink / raw)
  To: Jeff King, Junio C Hamano; +Cc: Shawn O. Pearce, git

    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?

    Indeed my problem could be solved by either of the solutions
proposed (I'll summarize them for the sake of completeness):
    * using git alias to put simple inline scripts (without need of a
new file), or to put the path to the real script;
    * putting the new command into a directory that is referenced from PATH;

    Both these solutions work fine, except one concern: when moving
the repository I would also want to move my scripts, and so I'm
remaining with only one candidate: git aliases... (For example I could
move the repository to another machine that I haven't setup with my
own scripts... Of course neither my solution would work, because I
would need a patched Git, but this could be changed if Git would have
this feature built-in :) )

    But, there is a disadvantage with git aliases, meaning if I want a
bigger script then I must keep in sync both config file and script
names... Moreover, if I use git from another folder than the work-tree
would the alias still work if I used relative paths? (I don't know but
someone could clear this up as there is no mention about it in the
documentation...)

    So my proposal is very simple: make git look inside the GIT_DIR
and see if there is a bin folder; if so add it in the front of path
(thus overriding built-in commands??).

    The advantage is that is much simpler to setup commands by just
dropping git-something files inside .git/bin... No config editing, no
relative path problems...

    As a conclusion, I've patched Git myself to support such a
feature... (See patch bellow...)

    So? Having explained in detail the problem and solutions what is
(are) yours (or others) opinions?


On Wed, Feb 11, 2009 at 9:42 PM, Jeff King <peff@peff.net> wrote:
> On Wed, Feb 11, 2009 at 09:32:29PM +0200, Ciprian Dorin, Craciun wrote:
>
>>     Anyway, I don't see why it's wrong to have such a bin folder per
>> repository... Let's for a moment assume that there is a use case for
>> such a thing, I'm wondering what is wrong with this solution from a
>> Git perspective???
>
> It's not _wrong_, we're just suggesting ways that the same thing might
> be accomplished more easily.
>
>>     P.S.: It seems that indeed setup_git_directory_gently (or
>> something in the setup system) is kind of broken if I call it twice...
>
> Yes, I think your patch is running into a long-standing problem in the
> git initialization code. There are problems if you need to look into the
> repo dir to find out which command to execute, because finding the repo
> dir changes the environment. There is a similar problem with aliases.
>
> So I think getting your patch to run correctly may be hard. But I admit
> I didn't look at it that closely.
>
> -Peff

    :) I've skipped around the problem (in a non-engineering way) by
adding a variable which enables or disables my feature... And I only
enable it for git.c... :)


    Thanks both Junio, Jeff and Shawn for your answers!
    Ciprian Craciun.

    P.S.: My final (working (hopefully, although tested)) patch bellow.

--------

diff --git a/exec_cmd.c b/exec_cmd.c
index cdd35f9..8d707e1 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -44,6 +44,45 @@ const char *git_exec_path(void)
 	return system_path(GIT_EXEC_PATH);
 }

+/* Returns the path of the bin folder inside the .git folder. */
+/* (This could be used to store repository specific git programs.) */
+
+int enable_git_repo_exec_path = 0;
+
+const char *git_repo_exec_path(void)
+{
+	static char path_buffer[PATH_MAX + 1];
+	static char *path = NULL;
+	
+	int non_git;
+	const char *git_dir;
+	
+	if (!path && enable_git_repo_exec_path) {
+		
+		path = path_buffer;
+		path[0] = '\0';
+		
+		setup_git_directory_gently(&non_git);
+		
+		if (!non_git) {
+			
+			git_dir = get_git_dir();
+			
+			strncat(path, git_dir, PATH_MAX);
+			strncat(path, "/", PATH_MAX);
+			strncat(path, "bin", PATH_MAX);
+			strncpy(path, make_absolute_path(path), PATH_MAX);
+			if (access(path, F_OK) != 0)
+				path[0] = '\0';
+		}
+	}
+	
+	if (!path || (path[0] == '\0'))
+		return NULL;
+	
+	return path;
+}
+
 static void add_path(struct strbuf *out, const char *path)
 {
 	if (path && *path) {
@@ -61,6 +100,8 @@ void setup_path(void)
 	const char *old_path = getenv("PATH");
 	struct strbuf new_path = STRBUF_INIT;

+	if (git_repo_exec_path() != NULL)
+		add_path(&new_path, git_repo_exec_path());
 	add_path(&new_path, argv_exec_path);
 	add_path(&new_path, getenv(EXEC_PATH_ENVIRONMENT));
 	add_path(&new_path, system_path(GIT_EXEC_PATH));
diff --git a/exec_cmd.h b/exec_cmd.h
index 594f961..a02256b 100644
--- a/exec_cmd.h
+++ b/exec_cmd.h
@@ -10,4 +10,6 @@ extern int execv_git_cmd(const char **argv); /* NULL
terminated */
 extern int execl_git_cmd(const char *cmd, ...);
 extern const char *system_path(const char *path);

+extern int enable_git_repo_exec_path;
+
 #endif /* GIT_EXEC_CMD_H */
diff --git a/git.c b/git.c
index 940a498..d312ab9 100644
--- a/git.c
+++ b/git.c
@@ -477,6 +477,7 @@ int main(int argc, const char **argv)
 	 * environment, and the $(gitexecdir) from the Makefile at build
 	 * time.
 	 */
+	enable_git_repo_exec_path = 1;
 	setup_path();

 	while (1) {

^ permalink raw reply related	[flat|nested] 17+ messages in thread

* Re: Git push failure in the case of SSH to localhost
  2009-02-11 20:03                   ` Ciprian Dorin, Craciun
@ 2009-02-11 20:23                     ` Junio C Hamano
  2009-02-11 20:49                       ` Ciprian Dorin, Craciun
  0 siblings, 1 reply; 17+ messages in thread
From: Junio C Hamano @ 2009-02-11 20:23 UTC (permalink / raw)
  To: Ciprian Dorin, Craciun; +Cc: Jeff King, Shawn O. Pearce, git

"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.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Git push failure in the case of SSH to localhost
  2009-02-11 20:23                     ` Junio C Hamano
@ 2009-02-11 20:49                       ` Ciprian Dorin, Craciun
  2009-02-11 21:03                         ` Johannes Schindelin
  0 siblings, 1 reply; 17+ messages in thread
From: Ciprian Dorin, Craciun @ 2009-02-11 20:49 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Jeff King, Shawn O. Pearce, git

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.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Git push failure in the case of SSH to localhost
  2009-02-11 20:49                       ` Ciprian Dorin, Craciun
@ 2009-02-11 21:03                         ` Johannes Schindelin
  0 siblings, 0 replies; 17+ messages in thread
From: Johannes Schindelin @ 2009-02-11 21:03 UTC (permalink / raw)
  To: Ciprian Dorin, Craciun; +Cc: Junio C Hamano, Jeff King, Shawn O. Pearce, git

Hi,

On Wed, 11 Feb 2009, Ciprian Dorin, Craciun wrote:

>     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...

Already you showed that your workflow leaves to be desired.  You need to 
move the repository using filesystem commands now.  Why?  Because you have 
stuff in .git/ that does not belong there, and does not get pushed or 
fetched as a consequence.

In similar cases, I followed three different options (and yes, I use all 
of them, in different repositories):

- commit the scripts (that works amazingly well with Git :-)

- have an independent branch for the scripts that I check out in a 
  subdirectory, or

- put the scripts into a submodule right away, when they are useful for 
  more than one project.

Hth,
Dscho

^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2009-02-11 21:04 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.