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

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

[Uwe Kleine-König]

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

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

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

[Johannes Schindelin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 431 bytes --]

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

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

[Uwe Kleine-König]

Hi Johannes,

Johannes Schindelin wrote:
> 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

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

[Brian Gernhardt]

On Jan 16, 2007, at 10:16 AM, Johannes Schindelin wrote:

> 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

How to merge FETCH_HEAD?

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

$ 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

Re: How to merge FETCH_HEAD?

[Shawn O. Pearce]

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

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

[Shawn O. Pearce]

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.

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.

Re: How to merge FETCH_HEAD?

[Junio C Hamano]

"Michael S. Tsirkin" <mst@mellanox.co.il> writes:

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

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

[Johannes Schindelin]

Hi,

On Tue, 16 Jan 2007, Shawn O. Pearce wrote:

> 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

Re: How to merge FETCH_HEAD?

[Michael S. Tsirkin]

> 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

Re: How to merge FETCH_HEAD?

[Johannes Schindelin]

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.

Ciao,
Dscho

Re: How to merge FETCH_HEAD?

[Michael S. Tsirkin]

> 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

Re: How to merge FETCH_HEAD?

[Junio C Hamano]

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

Re: How to merge FETCH_HEAD?

[Michael S. Tsirkin]

> 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

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

[Uwe Kleine-König]

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

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);}

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

[Junio C Hamano]

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.


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=

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

[Uwe Kleine-König]

Hello Junio,

Junio C Hamano wrote:
> 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.
 
> 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.)
 
> 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?

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

[Uwe Kleine-König]

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

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

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

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

[Uwe Kleine-König]

Hello,

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