* git blame --porcelain
From: Sverre Rabbelier @ 2008-07-20 20:28 UTC (permalink / raw)
To: Git Mailinglist
Heya,
Contrary to what one would expect, the '--porcelain' switch to 'git
blame' makes the output suitable for... plumbing use? As far as 'git
blame builtin-blame.c' tells me (gotta love the recursion there) it
has been this way since cee7f245 when the option was introduced. What
is the rationale behind this? Is it called '--porcelain' because it is
meant to be used by the plumbing to create new porcelain? That seems a
bit far-fetched though...
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH/rfc] git-svn.perl: workaround assertions in svn library 1.5.0
From: Dmitry Potapov @ 2008-07-20 20:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Gerrit Pape, git, Eric Wong
In-Reply-To: <7vbq0tibuf.fsf@gitster.siamese.dyndns.org>
On Sat, Jul 19, 2008 at 06:27:36PM -0700, Junio C Hamano wrote:
>
> So what's the conclusion of this issue?
>
> I'll just revert 2fe403e (git-svn.perl: workaround assertions in svn
> library 1.5.0, 2008-07-06) for 1.6.0-rc0 unless I hear better
> suggestions.
I have tested the change that I proposed, and it seems to solve the
problem and, as far as I can tell, no other correction is necessary.
Yet, I don't really understand git-svn well, so I could be wrong.
Reverting 2fe403e will only help users of svn library 1.4, while all
new linux distributives, which will include Git 1.6.0, are going to
install svn library 1.5.0, and if you use svn library 1.5.0, reverting
2fe403e does not fix anything but only add one more bug. Thus, unless
we are going to require to install git-svn only with svn library 1.4,
reverting this change does not seem to be very helpful for most users.
So, I hope my patch is better solution...
Dmitry
-- 8< --
From: Dmitry Potapov <dpotapov@gmail.com>
Date: Thu, 17 Jul 2008 22:32:02 +0400
Subject: [PATCH] git-svn: fix git svn info to work without arguments
commit 2fe403e7452bd6e1e8232445cf5434ce8f1af973 broke "git-svn info ."
due to replacing '.' with '' in canonicalize_path for the top directory,
while find_file_type_and_diff_status was not corrected.
Bug reports:
http://thread.gmane.org/gmane.comp.version-control.git/87822/
http://bugs.debian.org/490400
Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
---
git-svn.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index a366c89..b00a91a 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -1226,7 +1226,7 @@ sub linearize_history {
sub find_file_type_and_diff_status {
my ($path) = @_;
- return ('dir', '') if $path eq '.';
+ return ('dir', '') if $path eq '';
my $diff_output =
command_oneline(qw(diff --cached --name-status --), $path) || "";
--
1.5.6.3
^ permalink raw reply related
* Re: What's cooking in git.git (topics)
From: Sverre Rabbelier @ 2008-07-20 20:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Miklos Vajna, Nanako Shiraishi, git
In-Reply-To: <7vd4l85nv5.fsf@gitster.siamese.dyndns.org>
On Sun, Jul 20, 2008 at 9:58 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> You mean something like
>>
>> $ git merge -s subtree -X --path -X git-gui/ git-gui/master
>>
>> Wow. :-)
>
> I would envision it to be more like:
>
> $ git merge -s subtree -Xpath=git-gui git-gui/master
Whatever happened to quotes?
$ git merge -s subtree -Xpath="git-gui git-gui/master"
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Junio C Hamano @ 2008-07-20 19:58 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Miklos Vajna, Nanako Shiraishi, git
In-Reply-To: <alpine.DEB.1.00.0807202102370.3305@eeepc-johanness>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> I personally think -sstrategy=string1,string2,... is simply a bad taste.
>>
>> Why force yourself to parse things by having the users to concatenate
>> something that the user could give us separated? If you care about the
>> order and association between strategy and their options, you can always
>> do:
>>
>> -s strategy1 -X option-1-for-strategy-1 -X option-2-for-strategy-1 \
>> -s strategy2 -X option-1-for-strategy-2 ...
>
> You mean something like
>
> $ git merge -s subtree -X --path -X git-gui/ git-gui/master
>
> Wow. :-)
I would envision it to be more like:
$ git merge -s subtree -Xpath=git-gui git-gui/master
which git-merge internally would turn into:
$ git-merge-subtree --path=git-gui HEAD -- OURS THEIRS
That way both the external command line (that the end users do care about)
and the internal one (that the strategy programmer would care about) look
a lot more sensible than your command line, don't they?
^ permalink raw reply
* Re: [PATCH] Ensure that SSH runs in non-interactive mode
From: Junio C Hamano @ 2008-07-20 19:51 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Fredrik Tolf, Keith Packard, git, Edward Z. Yang,
Steffen Prohaska
In-Reply-To: <alpine.DEB.1.00.0807202035090.3305@eeepc-johanness>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> How about this instead?
>
> -- snipsnap --
> diff --git a/connect.c b/connect.c
> index 574f42f..7e7f4d3 100644
> --- a/connect.c
> +++ b/connect.c
> @@ -603,7 +603,8 @@ struct child_process *git_connect(int fd[2], const char *url
>
> *arg++ = ssh;
> if (port) {
> - *arg++ = "-p";
> + const char *opt = getenv("GIT_SSH_PORT_OPTION");
> + *arg++ = opt ? opt : "-p";
> *arg++ = port;
> }
> *arg++ = host;
If you only care only about the ones we currently want to support, I do
not htink it makes any difference either way, but if we are shooting for
having a minimum-but-reasonable framework to make it easy to support other
ones that we haven't seen, it feels very much like an inadequate hack to
waste an envirnoment variable for such a narrow special case. With this,
what you really mean is "Plink uses -P instead of -p", right?
I do not know if "plink" is used widely enough to be special cased, but if
so, I think we would better have an explicit support for it. Will we add
GIT_SSH_FORBID_X11_FORWARDING_OPTION environment variable and friends,
too?
The extra environment would not help dealing with an implementation that
wants --port=90222 (i.e. not as two separate arguments but a single one),
for example. You would need the extra wrapper support for that kind of
thing anyway. That extra environment _solution_ will need to make an
assuption that any reasonable implementation would have an option string
to specify port which may not be "-p" and that is to be followed by a
separate argument that is a decimal port number, which probably is
reasonable for this particular "port" thing, but as a general design
principle I do not think it is a good direction to go.
^ permalink raw reply
* Re: [RFC variant 2 of 2] "needs update" considered harmful
From: Junio C Hamano @ 2008-07-20 19:29 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Petr Baudis, git
In-Reply-To: <alpine.DEB.1.00.0807201435450.3305@eeepc-johanness>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Sun, 20 Jul 2008, Petr Baudis wrote:
>
>> Scripts need to be modified for the reorganization anyway,
>
> No. They do not, if the 1st variant is applied.
I think Pasky's point is that people who did not bother updating their
scripts with PATH=$(git --exec-path):$PATH as described in the deprecation
notice when we went 1.5.4 now have to do so.
But if they did, they have to update again. The more elaborate variant
avoids that, at the expense of different wordings between Porcelain and
plumbing.
I personally think there is nothing wrong if Porcelain and plumbing use
different languages, by the way. It seems that the general concensus will
be to split the Porcelain and the plumbing manuals into separate volumes
targetted for different audiences, and it is more important to keep the
plumbing output stable as part of an established API than making the same
thing called using the same wording in different languages.
^ permalink raw reply
* [PATCH] fix usage string for git grep
From: Jonathan Nieder @ 2008-07-20 19:13 UTC (permalink / raw)
To: git
Without this patch, git-grep gives confusing usage information:
$ git grep --confused
usage: git grep <option>* <rev>* [-e] <pattern> [<path>...]
$ git grep HEAD pattern
fatal: ambiguous argument 'pattern': unknown revision or path no
t in the working tree.
Use '--' to separate paths from revisions
So put <pattern> before the <rev>s, in accordance with actual correct
usage. While we're changing the usage string, we might as well include
the "--" separating revisions and paths, too.
Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu>
---
Thanks!
builtin-grep.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-grep.c b/builtin-grep.c
index 7bf6a71..631129d 100644
--- a/builtin-grep.c
+++ b/builtin-grep.c
@@ -498,7 +498,7 @@ static int grep_object(struct grep_opt *opt, const char **paths,
}
static const char builtin_grep_usage[] =
-"git grep <option>* <rev>* [-e] <pattern> [<path>...]";
+"git grep <option>* [-e] <pattern> <rev>* [[--] <path>...]";
static const char emsg_invalid_context_len[] =
"%s: invalid context length argument";
--
1.5.6.4.441.g4b4e9
^ permalink raw reply related
* [PATCH] git-shell needs $(COMPAT_OBJS)
From: Johannes Sixt @ 2008-07-20 19:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
Discovered by an accidental NO_MMAP=1 in config.mak.
-- Hannes
Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index c676d97..2be40eb 100644
--- a/Makefile
+++ b/Makefile
@@ -1203,7 +1203,7 @@ git-http-push$X: revision.o http.o http-push.o $(GITLIBS)
$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
$(LIBS) $(CURL_LIBCURL) $(EXPAT_LIBEXPAT)
-git-shell$X: compat/strlcpy.o abspath.o ctype.o exec_cmd.o quote.o strbuf.o usage.o wrapper.o shell.o
+git-shell$X: abspath.o ctype.o exec_cmd.o quote.o strbuf.o usage.o wrapper.o shell.o $(COMPAT_OBJS)
$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^)
$(LIB_OBJS) $(BUILTIN_OBJS): $(LIB_H)
--
1.5.6.3.443.g5f70e
^ permalink raw reply related
* Re: What's cooking in git.git (topics)
From: Johannes Schindelin @ 2008-07-20 19:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miklos Vajna, Nanako Shiraishi, git
In-Reply-To: <7vd4l88l77.fsf@gitster.siamese.dyndns.org>
Hi,
On Sun, 20 Jul 2008, Junio C Hamano wrote:
> Miklos Vajna <vmiklos@frugalware.org> writes:
>
> > Third, it would be nice to allow passing extra parameter(s) to the
> > backends, but I do not know what concept is the best here. The
> > strategy1=foo,stategy2=bar limits the input to a single string. Is that
> > enough? Given that recursive=theirs was considered harmful, we don't
> > have too much examples;...
>
> I personally think -sstrategy=string1,string2,... is simply a bad taste.
>
> Why force yourself to parse things by having the users to concatenate
> something that the user could give us separated? If you care about the
> order and association between strategy and their options, you can always
> do:
>
> -s strategy1 -X option-1-for-strategy-1 -X option-2-for-strategy-1 \
> -s strategy2 -X option-1-for-strategy-2 ...
You mean something like
$ git merge -s subtree -X --path -X git-gui/ git-gui/master
Wow. :-)
Speechless,
Dscho
^ permalink raw reply
* Re: [PATCH] Ensure that SSH runs in non-interactive mode
From: Johannes Schindelin @ 2008-07-20 18:57 UTC (permalink / raw)
To: Junio C Hamano
Cc: Fredrik Tolf, Keith Packard, git, Edward Z. Yang,
Steffen Prohaska
In-Reply-To: <7v63r0bejy.fsf@gitster.siamese.dyndns.org>
Hi,
On Sun, 20 Jul 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> Ah, right. Would it be OK to add the `-x' flag to ssh instead?
> >
> > I think this would be the correct way, together with "-T".
> >
> >> I imagine that that might make git less portable to SSH implementations
> >> other than OpenSSH, but I don't know if that is considered a problem.
> >
> > Well, this was to be expected, after what I wrote in response to 3. in
> > http://thread.gmane.org/gmane.comp.version-control.git/76650/focus=2598
> >
> > Reality always catches up with you, and here again we see that plink and
> > other siblings of OpenSSH should be best handled with scripts, preferably
> > ones that strip out options they do not recognize.
> >
> > IOW something like
> >
> > -- snip --
> > #!/bin/bash
> >
> > plinkopt=
> > while test $# != 0
> > do
> > case "$1" in
> > -p)
> > plinkopt="$plinkopt -P $2"
> > shift
> > ;;
> > -*)
> > # unrecognized; strip out
> > ;;
> > *)
> > break
> > ;;
> > esac
> > shift
> > done
> >
> > exec plink $plinkopt "$@"
> > -- snap --
>
> I think that is a very sensible approach, but just like we have a few
> "built-in" function-header regexps with customization possibilities for
> the user, we might want to:
>
> * Have that "-x", "-T" in the command line we generate for OpenSSH;
>
> * Allow users to specify OpenSSH substitute via a configuration and/or
> environment variable, and have them use your script; and
>
> * Have a built-in logic for selected and common "OpenSSH substitute",
> e.g. plink.
>
> There is no reason to make users suffer an extra redirection for common
> enough alternatives.
>
> Here is to get it started...
How about this instead?
-- snipsnap --
diff --git a/connect.c b/connect.c
index 574f42f..7e7f4d3 100644
--- a/connect.c
+++ b/connect.c
@@ -603,7 +603,8 @@ struct child_process *git_connect(int fd[2], const char *url
*arg++ = ssh;
if (port) {
- *arg++ = "-p";
+ const char *opt = getenv("GIT_SSH_PORT_OPTION");
+ *arg++ = opt ? opt : "-p";
*arg++ = port;
}
*arg++ = host;
^ permalink raw reply related
* Re: [PATCH] Teach 'git merge' that 'recur' merge strategy no longer exists
From: Miklos Vajna @ 2008-07-20 18:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, git
In-Reply-To: <7vmykc76dn.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 260 bytes --]
On Sun, Jul 20, 2008 at 11:33:24AM -0700, Junio C Hamano <gitster@pobox.com> wrote:
> Good eyes, both of you. Will roll a die and commit one squashed,
> creditting one of you at random ;-)
I thought commit messages can have multiple Signed-off-by lines. ;-)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Ensure that SSH runs in non-interactive mode
From: Fredrik Tolf @ 2008-07-20 18:42 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Keith Packard, git, Edward Z. Yang, Steffen Prohaska
In-Reply-To: <alpine.DEB.1.00.0807202029310.3305@eeepc-johanness>
On Sun, 2008-07-20 at 20:33 +0200, Johannes Schindelin wrote:
> > Otherwise, an alternative may be to always install a script, say
> > `git-ssh', that would invoke the real SSH in a manner specific for the
> > platform. The exact script installed could even be parametrized by the
> > Makefile. For systems using OpenSSH, it would probably just consist of
> > `ssh -xT "$@"'.
> >
> > What do you think?
>
> Umm, why? I fully expect OpenSSH to be the most common ssh helper. I
> fail to see why we should optimize for something else.
I guess I just thought the guys trying to port Git to Windows might find
it helpful as well. I don't really care myself.
> The GIT_SSH solution works. Why not just leave things like they are?
I don't think it is a good idea to leave it like it is, because I think
it is unreasonable to run Git traffic with Minimize-Delay TOS by
default. If for no other reason, changing the TOS would at least make
many networks happier.
Fredrik Tolf
^ permalink raw reply
* Re: [PATCH] Teach 'git merge' that 'recur' merge strategy no longer exists
From: Junio C Hamano @ 2008-07-20 18:33 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Nanako Shiraishi, git
In-Reply-To: <1216555968-31406-1-git-send-email-vmiklos@frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> It co-existed with 'recursive' when rewriting it in C, but it no longer
> available.
>
> Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
> ---
>
> On Sun, Jul 20, 2008 at 07:21:25PM +0900, Nanako Shiraishi <nanako3@lavabit.com> wrote:
>> - { "stupid", 0 },
>
> If we are at it, recur is also something unnecessary here.
Good eyes, both of you. Will roll a die and commit one squashed,
creditting one of you at random ;-)
^ permalink raw reply
* Re: [PATCH] Ensure that SSH runs in non-interactive mode
From: Johannes Schindelin @ 2008-07-20 18:33 UTC (permalink / raw)
To: Fredrik Tolf; +Cc: Keith Packard, git, Edward Z. Yang, Steffen Prohaska
In-Reply-To: <1216576183.3673.2.camel@pc7.dolda2000.com>
Hi,
On Sun, 20 Jul 2008, Fredrik Tolf wrote:
> On Sun, 2008-07-20 at 12:27 +0200, Johannes Schindelin wrote:
>
> > Well, this was to be expected, after what I wrote in response to 3. in
> > http://thread.gmane.org/gmane.comp.version-control.git/76650/focus=2598
> >
> > Reality always catches up with you, and here again we see that plink
> > and other siblings of OpenSSH should be best handled with scripts,
> > preferably ones that strip out options they do not recognize.
>
> Otherwise, an alternative may be to always install a script, say
> `git-ssh', that would invoke the real SSH in a manner specific for the
> platform. The exact script installed could even be parametrized by the
> Makefile. For systems using OpenSSH, it would probably just consist of
> `ssh -xT "$@"'.
>
> What do you think?
Umm, why? I fully expect OpenSSH to be the most common ssh helper. I
fail to see why we should optimize for something else.
The GIT_SSH solution works. Why not just leave things like they are?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Enable git rev-list to parse --quiet
From: Junio C Hamano @ 2008-07-20 18:31 UTC (permalink / raw)
To: Nick Andrew; +Cc: git
In-Reply-To: <20080720120437.GC15586@mail.local.tull.net>
Nick Andrew <nick@nick-andrew.net> writes:
> Exiting a process from within a callback function seems to me to violate
> the principle of least surprise.
Huh? Who is surprised?
I do not know who taught you that "do not exit in a callback" dogma, but I
suspect it was misrepresented when it was taught to you.
A library that calls your function back could be structured this way:
lib() {
perform some set-up that affects external world;
call your callback function;
clean-up the effect of previous set-up action;
}
and exiting from your callback function is not a good idea as it prevents
the library from doing the necessary clean-up in such a case.
But that is true just in a(n extremely) general case. Your generalization
is not particularly useful, methinks, and use of exit(0) in the patch is
very well justified (rather, I do not think they even need justifying).
- The callback you are looking at is not a general purpose callback for
other program's use, but written for a specific use of rev-list;
- The purpose of that exit(0) is to signal "there is something" as
quickly as possible, which was what you wanted out of rev-list;
- Revision traversal is a read-only operation and we know that there is
no externally visible set-up done in the function you are calling to
get your callback called, that needs cleaning up later --- this is not
expected to change, as there are longstanding existing callback
functions supplied to traverse_commit_list() that die() upon seeing
errors already.
^ permalink raw reply
* Re: [PATCH 2/2] git-add -a: add all files
From: Junio C Hamano @ 2008-07-20 18:30 UTC (permalink / raw)
To: Jay Soffian
Cc: Johannes Schindelin, Tarmigan, Junio C Hamano, git,
Michael J Gruber
In-Reply-To: <76718490807200545l653bbda1l4d13f1e1e698c855@mail.gmail.com>
"Jay Soffian" <jaysoffian@gmail.com> writes:
> On Sun, Jul 20, 2008 at 6:56 AM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>> Two things:
>>
>> - add and commit are two _different_ operations, not only in name, but
>> also in nature. The fact that "commit -a" calls "add" is a _pure_
>> convenience. It does not change the fact that "add" and "commit" are
>> completely, utterly different.
>>
>> - if you are a heavy user of "commit -a", chances are that your history is
>> not really useful, because you committed unrelated changes accidentally
>> in the same commit.
>>
>> The latter point, BTW, is the reason I _never_ teach the "-a" option
>> (actually, I teach no option at all) in my first two Git lessons.
>
> I don't like "commit -a" and never use it and wonder why a
> short-option was wasted on it.
>
> I do like the new "add -a" (thank you Junio) but I will rarely use it.
I do not understand either of you. If for whatever reason "add -A" makes
sense in your workflow, it's a sign that you are extremely disciplined
that changes in your working tree at one point of time where you would
issue "add -A" are concentrated on a single topic, and at one of such
points you may want to commit. For such a disciplined person, "commit -a"
would make perfect sense there.
So for such people who would find "add -A" useful, "commit -a" will not be
"unrelated changes in the same commit". And for such people, I would even
say "commit -A" would be even more useful, too.
I'll never be in that camp of perfect people myself, though..
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Junio C Hamano @ 2008-07-20 18:27 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Johannes Schindelin, Nanako Shiraishi, git
In-Reply-To: <20080720130407.GF10347@genesis.frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> Third, it would be nice to allow passing extra parameter(s) to the
> backends, but I do not know what concept is the best here. The
> strategy1=foo,stategy2=bar limits the input to a single string. Is that
> enough? Given that recursive=theirs was considered harmful, we don't
> have too much examples;...
I personally think -sstrategy=string1,string2,... is simply a bad taste.
Why force yourself to parse things by having the users to concatenate
something that the user could give us separated? If you care about the
order and association between strategy and their options, you can always
do:
-s strategy1 -X option-1-for-strategy-1 -X option-2-for-strategy-1 \
-s strategy2 -X option-1-for-strategy-2 ...
^ permalink raw reply
* Re: What's in git.git (stable)
From: Junio C Hamano @ 2008-07-20 18:27 UTC (permalink / raw)
To: Lars Noschinski; +Cc: git
In-Reply-To: <20080720112034.GA27984@lars.home.noschinski.de>
Lars Noschinski <lars-2008-1@usenet.noschinski.de> writes:
> * Junio C Hamano <gitster@pobox.com> [08-07-20 03:59]:
>>Lars Noschinski (2):
>> cvsserver: Add support for packed refs
>> cvsserver: Add cvs co -c support
>
> Any specific reason why you did not merge the test for packed refs
> support? Was it considered superfluous?
No, it was not even considered. This phenomenon is called "lost in the
noise" ;-)
Thanks for reminding. Applied.
^ permalink raw reply
* Re: [PATCH] Ensure that SSH runs in non-interactive mode
From: Junio C Hamano @ 2008-07-20 18:23 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Fredrik Tolf, Keith Packard, git, Edward Z. Yang,
Steffen Prohaska
In-Reply-To: <alpine.DEB.1.00.0807201214060.3305@eeepc-johanness>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> Ah, right. Would it be OK to add the `-x' flag to ssh instead?
>
> I think this would be the correct way, together with "-T".
>
>> I imagine that that might make git less portable to SSH implementations
>> other than OpenSSH, but I don't know if that is considered a problem.
>
> Well, this was to be expected, after what I wrote in response to 3. in
> http://thread.gmane.org/gmane.comp.version-control.git/76650/focus=2598
>
> Reality always catches up with you, and here again we see that plink and
> other siblings of OpenSSH should be best handled with scripts, preferably
> ones that strip out options they do not recognize.
>
> IOW something like
>
> -- snip --
> #!/bin/bash
>
> plinkopt=
> while test $# != 0
> do
> case "$1" in
> -p)
> plinkopt="$plinkopt -P $2"
> shift
> ;;
> -*)
> # unrecognized; strip out
> ;;
> *)
> break
> ;;
> esac
> shift
> done
>
> exec plink $plinkopt "$@"
> -- snap --
I think that is a very sensible approach, but just like we have a few
"built-in" function-header regexps with customization possibilities for
the user, we might want to:
* Have that "-x", "-T" in the command line we generate for OpenSSH;
* Allow users to specify OpenSSH substitute via a configuration and/or
environment variable, and have them use your script; and
* Have a built-in logic for selected and common "OpenSSH substitute",
e.g. plink.
There is no reason to make users suffer an extra redirection for common
enough alternatives.
Here is to get it started...
connect.c | 30 +++++++++++++++++++++++++++---
1 files changed, 27 insertions(+), 3 deletions(-)
diff --git a/connect.c b/connect.c
index 574f42f..c72dd9e 100644
--- a/connect.c
+++ b/connect.c
@@ -599,12 +599,36 @@ struct child_process *git_connect(int fd[2], const char *url_orig,
conn->argv = arg = xcalloc(6, sizeof(*arg));
if (protocol == PROTO_SSH) {
const char *ssh = getenv("GIT_SSH");
+ const char *ssh_basename;
if (!ssh) ssh = "ssh";
+ ssh_basename = strrchr(ssh, '/');
+ ssh_basename = ssh_basename ? (ssh_basename + 1) : ssh;
+
*arg++ = ssh;
- if (port) {
- *arg++ = "-p";
- *arg++ = port;
+ /*
+ * Make sure to enlarge conn->argv if you add more
+ * paremeters here.
+ *
+ * We know how to invoke a few ssh implementations
+ * ourselves.
+ */
+ if (!strcmp(ssh_basename, "plink")) {
+ if (port) {
+ *arg++ = "-P";
+ *arg++ = port;
+ }
+ } else {
+ /*
+ * This is for stock OpenSSH, but you can have
+ * your custom wrapper script to parse this
+ * and invoke other ssh implementations after
+ * rearranging parameters as well.
+ */
+ if (port) {
+ *arg++ = "-p";
+ *arg++ = port;
+ }
}
*arg++ = host;
}
^ permalink raw reply related
* Re: git cvsimport and deleted files
From: Lars Noschinski @ 2008-07-20 18:05 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.DEB.1.00.0807201448020.3305@eeepc-johanness>
* Johannes Schindelin <Johannes.Schindelin@gmx.de> [08-07-20 14:49]:
>>I just tried importing the CVS repository for a long-running project
>>(ppp) into git using git cvsimport. It looks like git cvsimport
>>doesn't notice when files have been deleted, so files that used to be
>>present and were subsequently deleted are present in the git tree for
>>the most recent commit.
>
>I never had that problem. See
>http://repo.or.cz/w/libvncserver.git?a=commit;h=8dead0759febaa7176507e1bde13ebd9d2a30720
>for a commit that was imported with cvsimport.
>
>So your issue must lie somewhere else.
I encountered such an issue some time ago in incremental mode, when
another person did some cvs branch stuff. The error persisted even as I
did a clean checkout, but disappeared, after I deleted all the cvsps
cache files.
I failed to report the error, because I had not much time for debugging
at that time and I would not have been able to publish the repository.
That's when I switched to fromcvs, which seems to work reliably so far
(and much faster), but requires a local repository.
^ permalink raw reply
* Re: git cvsimport and deleted files
From: Lars Noschinski @ 2008-07-20 18:04 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.DEB.1.00.0807201448020.3305@eeepc-johanness>
* Johannes Schindelin <Johannes.Schindelin@gmx.de> [08-07-20 14:49]:
>> I just tried importing the CVS repository for a long-running project
>> (ppp) into git using git cvsimport. It looks like git cvsimport
>> doesn't notice when files have been deleted, so files that used to be
>> present and were subsequently deleted are present in the git tree for
>> the most recent commit.
>
>I never had that problem. See
>http://repo.or.cz/w/libvncserver.git?a=commit;h=8dead0759febaa7176507e1bde13ebd9d2a30720
>for a commit that was imported with cvsimport.
>
>So your issue must lie somewhere else.
I encountered such an issue some time ago in incremental mode, when
another person did some cvs branch stuff. The error persisted even as I
did a clean checkout, but disappeared, after I deleted all the cvsps
cache files.
I failed to report the error, because I had not much time for debugging
at that time and I would not have been able to publish the repository.
That's when I switched to fromcvs, which seems to work reliably so far (and
much faster), but requires a local repository.
^ permalink raw reply
* Re: [PATCH] Ensure that SSH runs in non-interactive mode
From: Fredrik Tolf @ 2008-07-20 17:49 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Keith Packard, git, Edward Z. Yang, Steffen Prohaska
In-Reply-To: <alpine.DEB.1.00.0807201214060.3305@eeepc-johanness>
On Sun, 2008-07-20 at 12:27 +0200, Johannes Schindelin wrote:
> Well, this was to be expected, after what I wrote in response to 3. in
> http://thread.gmane.org/gmane.comp.version-control.git/76650/focus=2598
>
> Reality always catches up with you, and here again we see that plink and
> other siblings of OpenSSH should be best handled with scripts, preferably
> ones that strip out options they do not recognize.
Otherwise, an alternative may be to always install a script, say
`git-ssh', that would invoke the real SSH in a manner specific for the
platform. The exact script installed could even be parametrized by the
Makefile. For systems using OpenSSH, it would probably just consist of
`ssh -xT "$@"'.
What do you think?
Fredrik Tolf
^ permalink raw reply
* Re: [RFC variant 2 of 2] "needs update" considered harmful
From: André Goddard Rosa @ 2008-07-20 14:03 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20080720112957.GE32184@machine.or.cz>
On Sun, Jul 20, 2008 at 8:29 AM, Petr Baudis <pasky@suse.cz> wrote:
> On Sun, Jul 20, 2008 at 12:48:21AM -0700, Junio C Hamano wrote:
>> "git update-index --refresh", "git reset" and "git add --refresh" have
>> reported paths that have local modifications as "needs update" since the
>> beginning of git.
>>
>> Although this is logically correct in that you need to update the index at
>> that path before you can commit that change, it is now becoming more and
>> more clear, especially with the continuous push for user friendliness
>> since 1.5.0 series, that the message is suboptimal. After all, the change
>> may be something the user might want to get rid of, and "updating" would
>> be absolutely a wrong thing to do if that is the case.
>>
>> I prepared two alternatives to solve this. Both aim to reword the message
>> to more neutral "locally modified".
>>
>> This patch is a more straightforward variant that changes the message not
>> only for Porcelain commands ("add" and "reset") but also changes the
>> output from the plumbing command "update-index".
>>
>> Signed-off-by: Junio C Hamano <gitster@pobox.com>
>
> I believe this is a good thing. Scripts need to be modified for the
Thanks for doing that. I hope this goes mainline soon.
--
[]s,
André Goddard
^ permalink raw reply
* Re: Statictics on Git.pm usage in git commands (was: [PATCH 2/3] add new Git::Repo API)
From: Johannes Schindelin @ 2008-07-20 13:21 UTC (permalink / raw)
To: Petr Baudis; +Cc: Jakub Narebski, Lea Wiemann, git, John Hawley
In-Reply-To: <20080720125841.GD10151@machine.or.cz>
Hi,
On Sun, 20 Jul 2008, Petr Baudis wrote:
> On Sun, Jul 20, 2008 at 02:33:46PM +0200, Johannes Schindelin wrote:
> > On Sun, 20 Jul 2008, Petr Baudis wrote:
> >
> > > On Sun, Jul 20, 2008 at 12:38:07PM +0200, Johannes Schindelin wrote:
> > >
> > > > Pasky tried to convert all Perl scripts at once IIRC, and my
> > > > numerous problems just _making_ the Git scripts led me to rewrite
> > > > a few Perl scripts in C, so I could safely exclude the Perl
> > > > scripts from my personal fork.
> > >
> > > I don't remember any concrete report of such problems ever reaching
> > > me; exactly what trouble are you hitting with the Perl scripts using
> > > Git.pm? I will be glad to try to fix it.
> >
> > They reached you:
> >
> > http://article.gmane.org/gmane.comp.version-control.git/23153
>
> running Git in-place without correctly setting the prefix is not
> supported anyway; git wrapper will still be using non-builtin commands
> from the prefix location instead of your fresh build.
There were none. Anyway, because Git makes it _really_ hard to run
in-place, I gave in. I run Git from $HOME/bin now.
> > http://thread.gmane.org/gmane.comp.version-control.git/22764/focus=22778
>
> It seems I fixed this right away?
That is not what I remember. I remember that I had the next issue right
away. I remember that there were problems with ActiveState Perl+Cygwin.
And I remember that the Git.xs was not merged in the end.
Anyway, this whole discussion is moot, methinks.
Let's concentrate back on the real issue: merging the two as-of-now
incompatible Perl modules. It really would be nice to have one pony with
one saddle in the end, so that the use of Lea's GSoC project is not
limited to gitweb with enabled caching.
Ciao,
Dscho
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Johannes Schindelin @ 2008-07-20 13:16 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Junio C Hamano, Nanako Shiraishi, git
In-Reply-To: <20080720130407.GF10347@genesis.frugalware.org>
Hi,
On Sun, 20 Jul 2008, Miklos Vajna wrote:
> First, currently you can specify multiple strategies in the config
> (pull.twohead, pull.octopus) using a space separated list.
Oh, I did not mean to change that. I just misremembered.
> Second, we could allow custom strategies, as we started to discuss here:
>
> http://thread.gmane.org/gmane.comp.version-control.git/86584/focus=87684
In my opinion, this would make it easier for interested parties to start
implementing that blame-based merge strategy I mentioned.
> Third, it would be nice to allow passing extra parameter(s) to the
> backends, but I do not know what concept is the best here. The
> strategy1=foo,stategy2=bar limits the input to a single string. Is that
> enough? Given that recursive=theirs was considered harmful, we don't
> have too much examples; for subtree the only parameter I could think of
> is the path, so a string there is enough.
>
> However, further strategies, like blame, could take more parameters,
> like git blame -C<num> -M<othernum>. Or do I just overcomplicate it? ;-)
The common solution is like with gcc's -Wl option, which translates
commata into spaces, like so: "-Wl,--machine,i386" is added as "--machine
i386" to the linker command line.
Our own cvsimport implements the same principle:
$ git cvsimport -p -b,HEAD
will only update the main branch.
Ciao,
Dscho
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox