threads / rfc / 6402

RFC patchnew config option remote.<name>.pushexec

Subject: [PATCH RFC] new config option remote.<name>.pushexec

## tl;dr

19 messages between Jan 16, 2007 and Jan 25, 2007. Diffs are folded; open one to read it.

replies: 18people: 6as markdown or json

Uwe Kleine-König· Jan 16, 2007, 15:02 UTC · lore

git push --exec=... is fine, but having it to specify every time is annoying.

This sets the default remote program for pushing to remote <name>.
Signed-off-by: Uwe Kleine-König <zeisberg@informatik.uni-freiburg.de>
---
This has (still) a few short comings:
 a) compiler warning because execute has the type const char*.
 b) cmdline should overwrite remote.<name>.pushexec w/o the warning.
 c) the symmetric part for fetch is missing.
The idea should be clear.  Would a more complete patch be welcome?

Best regards Uwe

 Documentation/config.txt |    4 ++++
 builtin-push.c           |    7 +++++++
 2 files changed, 11 insertions(+), 0 deletions(-)
Show changes to 2 files +11 −0

Documentation/config.txt, builtin-push.c

diff --git a/Documentation/config.txt b/Documentation/config.txt
index faa17ba..667628a 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -351,6 +351,10 @@ remote.<name>.push::
 	The default set of "refspec" for gitlink:git-push[1]. See
 	gitlink:git-push[1].
 
+remote.<name>.pushexec::
+	The default program to execute on the remote side.  See
+	option \--exec of gitlink:git-push[1].
+
 repack.usedeltabaseoffset::
 	Allow gitlink:git-repack[1] to create packs that uses
 	delta-base offset.  Defaults to false.
diff --git a/builtin-push.c b/builtin-push.c
index 7a3d2bb..8ea5dea 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -157,6 +157,13 @@ static int get_remote_config(const char* key, const char* value)
 		else if (config_get_refspecs &&
 			 !strcmp(key + 7 + config_repo_len, ".push"))
 			add_refspec(xstrdup(value));
+		else if (!strcmp(key + 7 + config_repo_len, ".pushexec")) {
+			if (!execute) {
+				execute = xmalloc(strlen(value) + 8);
+				sprintf(execute, "--exec=%s", value);
+			} else
+				error("more than one pushexec given");
+		}
 	}
 	return 0;
 }

-- 
1.5.0.rc1.g581a


-- 
Uwe Kleine-König

http://www.google.com/search?q=5+choose+3
Johannes Schindelin· Jan 16, 2007, 15:16 UTC · re: Uwe Kleine-König · lore

Re: [PATCH RFC] new config option remote.<name>.pushexec

Hi,
On Tue, 16 Jan 2007, Uwe Kleine-König wrote:
> git push --exec=... is fine, but having it to specify every time is
> annoying.

What would you specify? The only sensible thing would be "--exec=blabla" where "blabla" is a workalike to git-receive-pack.

IMHO this is just an obscure option for obscure _really_ low-level git debugging, so it should not even be mentioned in the man page, let alone encouraged.

Ciao, Dscho

Uwe Kleine-König· Jan 16, 2007, 16:26 UTC · re: Johannes Schindelin · lore

Re: [PATCH RFC] new config option remote.<name>.pushexec

Hi Johannes,
Johannes Schindelin wrote:
Show 7 quoted lines
> On Tue, 16 Jan 2007, Uwe Kleine-König wrote:
> 
> > git push --exec=... is fine, but having it to specify every time is
> > annoying.
> 
> What would you specify? The only sensible thing would be "--exec=blabla" 
> where "blabla" is a workalike to git-receive-pack.
Exactly.  Quoting git-send-pack(1):
	Path to the git-receive-pack program on the remote end.
	Sometimes useful when pushing to a remote repository over ssh,
	and you do not have the program in a directory on the default
	$PATH.
For me it would be:
	pushexec = /home/zeisberg/usr/bin/git-receive-pack

While having /home/zeisberg/usr/bin only in my PATH for interactive shells. (Yes I know I could expand my PATH which .<someshrc>, but I'd prefer it that way.)

Best regards Uwe

-- 
Uwe Kleine-König

http://www.google.com/search?q=1+newton+in+kg*m+%2F+s%5E2
Michael S. Tsirkin· Jan 16, 2007, 17:37 UTC · re: Uwe Kleine-König · lore

How to merge FETCH_HEAD?

OK, I did a fetch and now I can see remote history by
$git log FETCH_HEAD
But, how to merge it?

$ git pull . FETCH_HEAD error: no such remote ref refs/heads/FETCH_HEAD Fetch failure: .

$git merge FETCH_HEAD FETCH_HEAD - not something we can merge

So, how can I merge this without an extra fetch?
-- 
MST
Shawn O. Pearce· Jan 16, 2007, 19:59 UTC · re: Michael S. Tsirkin · lore

Re: How to merge FETCH_HEAD?

"Michael S. Tsirkin" <mst@mellanox.co.il> wrote:
> OK, I did a fetch and now I can see remote history by
> 
> $git log FETCH_HEAD
Wow, I'm suprised that works.  Handy feature.  Too bad rev-parse
--verify then chokes on it when we'll somehow consider it a ref
otherwise...
 
> But, how to merge it?
Look at git-pull.sh:
	merge_head=$(sed -e '/  not-for-merge   /d' \
		-e 's/  .*//' "$GIT_DIR"/FETCH_HEAD | \
			tr '\012' ' ')
	merge_name=$(git-fmt-merge-msg <"$GIT_DIR/FETCH_HEAD")
	git-merge "$merge_name" HEAD $merge_head

The not-for-merge keyword is included on lines that were fetched into tracking branches during the last fetch and which you don't want to merge right now. So those lines get dropped. Then the remainder of the line is stripped away, leaving you with only the sha1 sum. merge_name is computed from the FETCH_HEAD file, to get the pretty log message for git-merge.

-- 
Shawn.
Michael S. Tsirkin· Jan 16, 2007, 21:33 UTC · re: Shawn O. Pearce · lore

Re: How to merge FETCH_HEAD?

Show 28 quoted lines
> Quoting Shawn O. Pearce <spearce@spearce.org>:
> Subject: Re: How to merge FETCH_HEAD?
> 
> "Michael S. Tsirkin" <mst@mellanox.co.il> wrote:
> > OK, I did a fetch and now I can see remote history by
> > 
> > $git log FETCH_HEAD
> 
> Wow, I'm suprised that works.  Handy feature.  Too bad rev-parse
> --verify then chokes on it when we'll somehow consider it a ref
> otherwise...
>  
> > But, how to merge it?
> 
> Look at git-pull.sh:
> 
> 	merge_head=$(sed -e '/  not-for-merge   /d' \
> 		-e 's/  .*//' "$GIT_DIR"/FETCH_HEAD | \
> 			tr '\012' ' ')
> 	merge_name=$(git-fmt-merge-msg <"$GIT_DIR/FETCH_HEAD")
> 	git-merge "$merge_name" HEAD $merge_head
> 
> The not-for-merge keyword is included on lines that were fetched
> into tracking branches during the last fetch and which you don't
> want to merge right now.  So those lines get dropped.  Then the
> remainder of the line is stripped away, leaving you with only
> the sha1 sum.  merge_name is computed from the FETCH_HEAD file,
> to get the pretty log message for git-merge.
Would it be useful to have git-pull . FETCH_HEAD work?
-- 
MST
Michael S. Tsirkin· Jan 17, 2007, 05:09 UTC · re: Johannes Schindelin · lore

Re: How to merge FETCH_HEAD?

Show 11 quoted lines
> Quoting Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> Subject: Re: How to merge FETCH_HEAD?
> 
> Hi,
> 
> On Tue, 16 Jan 2007, Michael S. Tsirkin wrote:
> 
> > Would it be useful to have git-pull . FETCH_HEAD work?
> 
> No. FETCH_HEAD is local. And for local merges, you should use git-merge, 
> not git-pull.

But, that can not take FETCH_HEAD either. Would it be useful for git-merge FETCH_HEAD to work?

-- 
MST
Junio C Hamano· Jan 17, 2007, 06:14 UTC · re: Michael S. Tsirkin · lore

Re: How to merge FETCH_HEAD?

"Michael S. Tsirkin" <mst@mellanox.co.il> writes:
Show 5 quoted lines
>> No. FETCH_HEAD is local. And for local merges, you should use git-merge, 
>> not git-pull.
>
> But, that can not take FETCH_HEAD either.
> Would it be useful for git-merge FETCH_HEAD to work?
Please try again, starting from the "git fetch".

I suspect the reason you think "merge FETCH_HEAD" does not work is because you lost FETCH_HEAD when you did "git pull . FETCH_HEAD", as I explained to you in an earlier message.

Michael S. Tsirkin· Jan 17, 2007, 06:33 UTC · re: Junio C Hamano · lore

Re: How to merge FETCH_HEAD?

Show 16 quoted lines
> Quoting Junio C Hamano <junkio@cox.net>:
> Subject: Re: How to merge FETCH_HEAD?
> 
> "Michael S. Tsirkin" <mst@mellanox.co.il> writes:
> 
> >> No. FETCH_HEAD is local. And for local merges, you should use git-merge, 
> >> not git-pull.
> >
> > But, that can not take FETCH_HEAD either.
> > Would it be useful for git-merge FETCH_HEAD to work?
> 
> Please try again, starting from the "git fetch".
> 
> I suspect the reason you think "merge FETCH_HEAD" does not work
> is because you lost FETCH_HEAD when you did "git pull . FETCH_HEAD",
> as I explained to you in an earlier message.
Yes, that was it, thanks!
-- 
MST
Junio C Hamano· Jan 16, 2007, 20:15 UTC · re: Michael S. Tsirkin · lore

Re: How to merge FETCH_HEAD?

"Michael S. Tsirkin" <mst@mellanox.co.il> writes:
Show 5 quoted lines
> OK, I did a fetch and now I can see remote history by
>
> $git log FETCH_HEAD
>
> But, how to merge it?

You would do "git merge FETCH_HEAD" (note that this would not work for octopus).

> $ git pull . FETCH_HEAD
> error: no such remote ref refs/heads/FETCH_HEAD
> Fetch failure: .
This is wrong twice.
 (1) "git pull" and "git fetch" by design are to fetch what are
     exposed, and the remote refnames you give are perfixed with
     refs/heads (or refs/tags if you say "git fetch tag v1.0.0")
     unless the refnames begin with refs/ already.  In other
     words, FETCH_HEAD is not something you can "pull".
 (2) Remember, "pull is fetch followed by merge." And the way
     fetch communicates with the calling "pull" so that it can
     drive "merge" is via FETCH_HEAD.  So whatever pull you
     would do, FETCH_HEAD is cleared first to store the result.

So by doing this (and not redoing the fetch) you broke your own experiment sequence. And that is why you got this:

> $git merge FETCH_HEAD
> FETCH_HEAD - not something we can merge
because at this point FETCH_HEAD is empty.
Shawn O. Pearce· Jan 16, 2007, 20:08 UTC · re: Uwe Kleine-König · lore

Re: [PATCH RFC] new config option remote.<name>.pushexec

Uwe Kleine-K?nig <zeisberg@informatik.uni-freiburg.de> wrote:
Show 14 quoted lines
> Exactly.  Quoting git-send-pack(1):
> 
> 	Path to the git-receive-pack program on the remote end.
> 	Sometimes useful when pushing to a remote repository over ssh,
> 	and you do not have the program in a directory on the default
> 	$PATH.
> 
> For me it would be:
> 
> 	pushexec = /home/zeisberg/usr/bin/git-receive-pack
> 
> While having /home/zeisberg/usr/bin only in my PATH for interactive
> shells.  (Yes I know I could expand my PATH which .<someshrc>, but I'd
> prefer it that way.)

Some of us have UNIX accounts where our shell is the (retarded) /usr/bin/ksh on Solaris. And where the SSH daemon won't seem to let us set PATH, and where Git isn't in the PATH. This leaves us with some difficulty in pointing Git at itself on the remote system.

I've worked around it with a GIT_SSH wrapper, e.g.
	$ cat >~/bin/mygitssh.sh
	#!/bin/sh
	host="$1"; shift
	exec ssh "$host" "PATH=\"/path/to/git:\$PATH\"; exec $@"
	^D
	$ chmod 755 ~/bin/mygitssh.sh
	$ export GIT_SSH=~/bin/mygitssh.sh

Being able to just set pushexec and fetchexec in the .git/config file would be nice, but GIT_SSH works well for my sad needs.

-- 
Shawn.
Johannes Schindelin· Jan 16, 2007, 20:30 UTC · re: Shawn O. Pearce · lore

Re: [PATCH RFC] new config option remote.<name>.pushexec

Hi,
On Tue, 16 Jan 2007, Shawn O. Pearce wrote:
Show 21 quoted lines
> Uwe Kleine-K?nig <zeisberg@informatik.uni-freiburg.de> wrote:
> > Exactly.  Quoting git-send-pack(1):
> > 
> > 	Path to the git-receive-pack program on the remote end.
> > 	Sometimes useful when pushing to a remote repository over ssh,
> > 	and you do not have the program in a directory on the default
> > 	$PATH.
> > 
> > For me it would be:
> > 
> > 	pushexec = /home/zeisberg/usr/bin/git-receive-pack
> > 
> > While having /home/zeisberg/usr/bin only in my PATH for interactive
> > shells.  (Yes I know I could expand my PATH which .<someshrc>, but I'd
> > prefer it that way.)
> 
> Some of us have UNIX accounts where our shell is the (retarded)
> /usr/bin/ksh on Solaris.  And where the SSH daemon won't seem to
> let us set PATH, and where Git isn't in the PATH.  This leaves
> us with some difficulty in pointing Git at itself on the remote
> system.
Okay, I see your point now.

Ciao, Dscho

Uwe Kleine-König· Jan 17, 2007, 16:44 UTC · re: Johannes Schindelin · lore

Re: [PATCH RFC] new config option remote.<name>.pushexec

git push --exec=... is fine, but having it to specify every time is annoying.

This sets the default remote program for pushing to remote <name>.
Signed-off-by: Uwe Kleine-König <zeisberg@informatik.uni-freiburg.de>
---
 Documentation/config.txt |    4 ++++
 builtin-push.c           |   11 +++++++++++
 2 files changed, 15 insertions(+), 0 deletions(-)

This patch fixes two of three shortcomings pointed out at initial sending. The compiler warning is gone (but I'm not 100% sure if it is fixed correctly or if only my compiler doesn't warn) and the commandline can overwrite the value now without a warning.

I tried to do the symmetric part for fetch, but that shell script is too complicated for me and so I let this part to s.o. being more familiar with git-fetch.sh.

Best regards Uwe

Show changes to 2 files +15 −0

Documentation/config.txt, builtin-push.c

diff --git a/Documentation/config.txt b/Documentation/config.txt
index da7fde5..bd4f72a 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -356,6 +356,10 @@ remote.<name>.push::
 	The default set of "refspec" for gitlink:git-push[1]. See
 	gitlink:git-push[1].
 
+remote.<name>.pushexec::
+	The default program to execute on the remote side when pulling.  See
+	option \--exec of gitlink:git-push[1].
+
 repack.usedeltabaseoffset::
 	Allow gitlink:git-repack[1] to create packs that uses
 	delta-base offset.  Defaults to false.
diff --git a/builtin-push.c b/builtin-push.c
index 7a3d2bb..8ca5aee 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -143,6 +143,7 @@ static const char *config_repo;
 static int config_repo_len;
 static int config_current_uri;
 static int config_get_refspecs;
+static int config_get_pushexec;
 
 static int get_remote_config(const char* key, const char* value)
 {
@@ -157,6 +158,15 @@ static int get_remote_config(const char* key, const char* value)
 		else if (config_get_refspecs &&
 			 !strcmp(key + 7 + config_repo_len, ".push"))
 			add_refspec(xstrdup(value));
+		else if (config_get_pushexec &&
+			 !strcmp(key + 7 + config_repo_len, ".pushexec")) {
+			if (!execute) {
+				char *ex = xmalloc(strlen(value) + 8);
+				sprintf(ex, "--exec=%s", value);
+				execute = ex;
+			} else
+				error("more than one pushexec given, using the first");
+		}
 	}
 	return 0;
 }
@@ -168,6 +178,7 @@ static int get_config_remotes_uri(const char *repo, const char *uri[MAX_URI])
 	config_current_uri = 0;
 	config_uri = uri;
 	config_get_refspecs = !(refspec_nr || all || tags);
+	config_get_pushexec = (execute == NULL);
 
 	git_config(get_remote_config);
 	return config_current_uri;

-- 
1.5.0.rc1.g581a

-- 
Uwe Kleine-König

main(){char*a="main(){char*a=%c%s%c;printf(a,34,a,34%c";printf(a,34,a,34
,10);a=",10);a=%c%s%c;printf(a,34,a,34,10);}%c";printf(a,34,a,34,10);}
Junio C Hamano· Jan 17, 2007, 17:32 UTC · re: Uwe Kleine-König · lore

Re: [PATCH RFC] new config option remote.<name>.pushexec

Uwe Kleine-König  <zeisberg@informatik.uni-freiburg.de> writes:
> I tried to do the symmetric part for fetch, but that shell script is too
> complicated for me and so I let this part to s.o. being more familiar
> with git-fetch.sh.

I do not know what s.o. is but something like this untested patch would do.

I do not have strong objection to the configuration on the push side, but I am not sure if we want to call it pushexec -- it is naming receive-pack so remote.*.receivepack might be more appropriate, just in case we update the fetch/push protocol someday to run more than one program on the other end.

Show changes to git-fetch.sh +7 −0
diff --git a/git-fetch.sh b/git-fetch.sh
index 87b940b..7372c5f 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -82,6 +82,13 @@ case "$#" in
 	set x $origin ; shift ;;
 esac
 
+if test -z "$exec" && exec=$(git-repo-config "remote.$1.uploadpack")
+then
+	# No command line override and we have configuration for the remote.
+	upload_pack="-u $exec"
+	exec="--exec=$exec"
+fi
+
 remote_nick="$1"
 remote=$(get_remote_url "$@")
 refs=
Uwe Kleine-König· Jan 18, 2007, 07:17 UTC · re: Junio C Hamano · lore

Re: [PATCH RFC] new config option remote.<name>.pushexec

Hello Junio,
Junio C Hamano wrote:
Show 8 quoted lines
> Uwe Kleine-König  <zeisberg@informatik.uni-freiburg.de> writes:
> 
> > I tried to do the symmetric part for fetch, but that shell script is too
> > complicated for me and so I let this part to s.o. being more familiar
> > with git-fetch.sh.
> 
> I do not know what s.o. is but something like this untested
> patch would do.
s.o. = someone, I thought it's a usual abbreviation.
Show 5 quoted lines
> I do not have strong objection to the configuration on the push
> side, but I am not sure if we want to call it pushexec -- it is
> naming receive-pack so remote.*.receivepack might be more
> appropriate, just in case we update the fetch/push protocol
> someday to run more than one program on the other end.
I wondered about that, too.  In the docs we currently have:
	git-send-pack ... [--exec=<git-receive-pack>]
	git-fetch-pack ... [--exec=<git-upload-pack>]
	git-push ... [--exec=<receive-pack>]
	git-pull ... [--upload-pack <upload-pack>]
	git-fetch ... [--upload-pack <upload-pack>]

I have choosen 'pushexec' because that's the name of the option to push. remote.*.receivepack is cleaner, as is

	git-push ...  [--receive-pack=...]
.  If we choose remote.*.receivepack, we should consider deprecating
--exec and introduce --receive-pack (--upload-pack resp.)
Show 18 quoted lines
> diff --git a/git-fetch.sh b/git-fetch.sh
> index 87b940b..7372c5f 100755
> --- a/git-fetch.sh
> +++ b/git-fetch.sh
> @@ -82,6 +82,13 @@ case "$#" in
>  	set x $origin ; shift ;;
>  esac
>  
> +if test -z "$exec" && exec=$(git-repo-config "remote.$1.uploadpack")
> +then
> +	# No command line override and we have configuration for the remote.
> +	upload_pack="-u $exec"
> +	exec="--exec=$exec"
> +fi
> +
>  remote_nick="$1"
>  remote=$(get_remote_url "$@")
>  refs=

I thought that it would be cleaner to add this code to git-parse-remote.sh and only do it if $(get_data_source) == 'config'. But it's OK for me this way, too.

Best regards Uwe

-- 
Uwe Kleine-König

If a lawyer and an IRS agent were both drowning, and you could only save
one of them, would you go to lunch or read the paper?
Uwe Kleine-König· Jan 25, 2007, 04:45 UTC · re: Uwe Kleine-König · lore

[PATCH] make --upload-pack option to git-fetch configurable

This introduces the config item remote.<name>.uploadpack to override the default value (which is "git-upload-pack").

Signed-off-by: Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
---
Show 21 quoted lines
> > diff --git a/git-fetch.sh b/git-fetch.sh
> > index 87b940b..7372c5f 100755
> > --- a/git-fetch.sh
> > +++ b/git-fetch.sh
> > @@ -82,6 +82,13 @@ case "$#" in
> >  	set x $origin ; shift ;;
> >  esac
> >  
> > +if test -z "$exec" && exec=$(git-repo-config "remote.$1.uploadpack")
> > +then
> > +	# No command line override and we have configuration for the remote.
> > +	upload_pack="-u $exec"
> > +	exec="--exec=$exec"
> > +fi
> > +
> >  remote_nick="$1"
> >  remote=$(get_remote_url "$@")
> >  refs=
> 
> I thought that it would be cleaner to add this code to
> git-parse-remote.sh and only do it if $(get_data_source) == 'config'.
This is, what this patch does.  Actually it was easier than I feared.
 git-fetch.sh        |    6 ++++++
 git-parse-remote.sh |   13 +++++++++++++
 2 files changed, 19 insertions(+), 0 deletions(-)
Show changes to 2 files +19 −0

git-fetch.sh, git-parse-remote.sh

diff --git a/git-fetch.sh b/git-fetch.sh
index 07a1d05..61c8cf4 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -85,6 +85,12 @@ case "$#" in
 	set x $origin ; shift ;;
 esac
 
+if test -z "$exec"
+then
+	# No command line override and we have configuration for the remote.
+	exec="--upload-pack=$(get_uploadpack $1)"
+fi
+
 remote_nick="$1"
 remote=$(get_remote_url "$@")
 refs=
diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index 4fc6020..1122c83 100755
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -279,3 +279,16 @@ resolve_alternates () {
 		esac
 	done
 }
+
+get_uploadpack () {
+	data_source=$(get_data_source "$1")
+	case "$data_source" in
+	config)
+		uplp=$(git-repo-config --get "remote.$1.uploadpack")
+		echo ${uplp:-git-upload-pack}
+		;;
+	*)
+		echo "git-upload-pack"
+		;;
+	esac
+}

-- 
1.5.0.rc2.g3ea949



Uwe Kleine-König wrote:
> 
> Best regards
> Uwe
> 
> -- 
> Uwe Kleine-König
> 
> If a lawyer and an IRS agent were both drowning, and you could only save
> one of them, would you go to lunch or read the paper?
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Uwe Kleine-König

http://www.google.com/search?q=12+divided+by+3
Uwe Kleine-König· Jan 25, 2007, 04:53 UTC · re: Uwe Kleine-König · lore

Re: [PATCH] make --upload-pack option to git-fetch configurable

Hello,
Show 5 quoted lines
> +if test -z "$exec"
> +then
> +	# No command line override and we have configuration for the remote.
> +	exec="--upload-pack=$(get_uploadpack $1)"
> +fi
I forgot to mention that this needs the patches
	rename --exec to --upload-pack for fetch-pack and peek-remote
		(Message-ID: <20070123082017.GA10007@cepheus>)
and
	ls-remote and clone: accept --upload-pack=<path> as well.
		by Junio  (Message-ID: <7vlkjunlgk.fsf@assigned-by-dhcp.cox.net>)

Best regards Uwe

-- 
Uwe Kleine-König

dd if=/proc/self/exe bs=1 skip=1 count=3 2>/dev/null
Brian Gernhardt· Jan 16, 2007, 16:27 UTC · re: Johannes Schindelin · lore

Re: [PATCH RFC] new config option remote.<name>.pushexec

On Jan 16, 2007, at 10:16 AM, Johannes Schindelin wrote:
Show 15 quoted lines
> Hi,
>
> On Tue, 16 Jan 2007, Uwe Kleine-König wrote:
>
>> git push --exec=... is fine, but having it to specify every time is
>> annoying.
>
> What would you specify? The only sensible thing would be "-- 
> exec=blabla"
> where "blabla" is a workalike to git-receive-pack.
>
> IMHO this is just an obscure option for obscure _really_ low-level git
> debugging, so it should not even be mentioned in the man page, let  
> alone
> encouraged.

It should be documented somewhere so that for the few odd cases where you need it you can find it. The most likely case I can think of is an SSH push where git isn't in your path for some reason.

Undocumented options are a bane to users. Document everything, and put BIG WARNINGS on things that shouldn't be used. Or put them in their own man page.

~~ Brian

← back to recent threads