Skip to contentSkip to conversation

new config option remote.<name>.pushexec

RFC PATCH In review Uwe Kleine-König 7 participants 19 messages Jun 15, 2016 Documentation

lore
Share & tools
lore

Uwe Kleine-König

author
#0 lore raw

RFC PATCH 1/1 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 <[email protected]>

---

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(-)
Documentation/config.txt +4 -0
index faa17ba..667628a 100644
@@ -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.
builtin-push.c +7 -0
index 7a3d2bb..8ea5dea 100644
@@ -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;
 }
Signature · 7 lines
1.5.0.rc1.g581a


-- 
Uwe Kleine-König

http://www.google.com/search?q=5+choose+3
#1 lore raw

Hi,

Quoted 2 lines · Uwe Kleine-König

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

author
#2 lore raw

Hi Johannes,

Quoted 7 lines · Johannes Schindelin
Quoted 2 lines · Uwe Kleine-König

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

Signature · 3 lines
Uwe Kleine-König

http://www.google.com/search?q=1+newton+in+kg*m+%2F+s%5E2
#3 lore raw

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?

Signature · 1 line
MST
#4 lore raw

Re: How to merge FETCH_HEAD?

Quoted 3 lines · Michael S. Tsirkin

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

Quoted 1 line

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.

Signature · 1 line
Shawn.
#5 lore raw

Re: How to merge FETCH_HEAD?

Quoted 22 lines

Quoting Shawn O. Pearce <[email protected]>:
Subject: Re: How to merge FETCH_HEAD?

Quoted 3 lines · Michael S. Tsirkin

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

Quoted 1 line

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
Quoted 6 lines

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?

Signature · 1 line
MST
#6 lore raw

Re: How to merge FETCH_HEAD?

Hi,

Quoted 1 line · Michael S. Tsirkin

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.

Ciao,
Dscho

#7 lore raw

Re: How to merge FETCH_HEAD?

Quoted 11 lines

Quoting Johannes Schindelin <[email protected]>:
Subject: Re: How to merge FETCH_HEAD?

Hi,

Quoted 1 line · Michael S. Tsirkin

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?

Signature · 1 line
MST
#8 lore raw

Re: How to merge FETCH_HEAD?

Quoted 5 lines · Michael S. Tsirkin
Quoted 2 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.

#9 lore raw

Re: How to merge FETCH_HEAD?

Quoted 8 lines

Quoting Junio C Hamano <[email protected]>:
Subject: Re: How to merge FETCH_HEAD?

Quoted 3 lines · Michael S. Tsirkin
Quoted 2 lines

No. FETCH_HEAD is local. And for local merges, you should use git-merge, not git-pull.

Quoted 8 lines
Quoted 2 lines

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!

Signature · 1 line
MST
#10 lore raw

Re: How to merge FETCH_HEAD?

In reply to Michael S. Tsirkin
Quoted 5 lines · Michael S. Tsirkin

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

Quoted 3 lines
$ 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:

Quoted 2 lines

$git merge FETCH_HEAD
FETCH_HEAD - not something we can merge

because at this point FETCH_HEAD is empty.

#11 lore raw
In reply to Uwe Kleine-König
Quoted 7 lines · Uwe Kleine-K?nig

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.

Quoted 7 lines

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.

Signature · 1 line
Shawn.
#12 lore raw

Hi,

Quoted 16 lines · Shawn O. Pearce
Quoted 7 lines · Uwe Kleine-K?nig

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.

Quoted 7 lines

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

Quoted 5 lines

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

author
#13 lore raw

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 <[email protected]>
---
 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

Documentation/config.txt +4 -0
index da7fde5..bd4f72a 100644
@@ -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.
builtin-push.c +11 -0
index 7a3d2bb..8ca5aee 100644
@@ -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;
Signature · 7 lines
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);}
#14 lore raw
Quoted 3 lines · Uwe Kleine-König

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.

git-fetch.sh +7 -0
index 87b940b..7372c5f 100755
@@ -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=
author
#15 lore raw

Hello Junio,

Quoted 8 lines · Junio C Hamano
Quoted 3 lines · Uwe Kleine-König

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.

Quoted 5 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.)

Quoted 8 lines
git-fetch.sh +0 -0
index 87b940b..7372c5f 100755
@@ -82,6 +82,13 @@ case "$#" in
 	set x $origin ; shift ;;
 esac

git-fetch.sh case "$#" in · line 94

Quoted 10 lines
git-fetch.sh +7 -0
+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

Signature · 4 lines
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?
#16 lore raw

PATCH 1/1 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 <[email protected]>

---

Quoted 8 lines
Quoted 8 lines
git-fetch.sh +0 -0
index 87b940b..7372c5f 100755
@@ -82,6 +82,13 @@ case "$#" in
 	set x $origin ; shift ;;
 esac
Quoted 13 lines

git-fetch.sh case "$#" in · line 94

Quoted 10 lines
git-fetch.sh +7 -0
+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(-)
git-fetch.sh +6 -0
index 07a1d05..61c8cf4 100755
@@ -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=
git-parse-remote.sh +13 -0
index 4fc6020..1122c83 100755
@@ -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
+}
Signature · 1 line
1.5.0.rc2.g3ea949
Quoted 13 lines · Uwe Kleine-König

Best regards
Uwe

Signature · 8 lines
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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Signature · 3 lines
Uwe Kleine-König

http://www.google.com/search?q=12+divided+by+3
#17 lore raw

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

Hello,

git-fetch.sh case "$#" in · line 92

Quoted 5 lines
git-fetch.sh +5 -0
+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: <[email protected]>)

Best regards
Uwe

Signature · 3 lines
Uwe Kleine-König

dd if=/proc/self/exe bs=1 skip=1 count=3 2>/dev/null
#18 lore raw
In reply to Johannes Schindelin
Quoted 7 lines · Johannes Schindelin

Hi,

Quoted 2 lines · Uwe Kleine-König

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

Quoted 8 lines

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