* Re: setting up tracking on push
From: Jay Soffian @ 2009-03-11 4:15 UTC (permalink / raw)
To: Jeff King; +Cc: Marc Branchaud, Miles Bader, git
In-Reply-To: <20090311035701.GA6089@coredump.intra.peff.net>
On Tue, Mar 10, 2009 at 11:57 PM, Jeff King <peff@peff.net> wrote:
>> -u w/o --track/--no-track is a usage error.
>
> Then what is the point of "-u"? You said before that it was a new
> operation with room for future growth of additional options. Either it
> is _just_ for --track, in which case I think you are better to have a
> single option representing the notion of "update the tracking setup", or
> it isn't, in which case it needs to have room for future expansion.
For *now*, it is just for --track/--no-track, since I can't think of
anything sensible that "-u" without --track nor --no-track would do.
So it means, update the branch config, but you have to tell it what
aspect of the branch config to update.
I agree that currently, a single option could do here, but I can't
think of a good one. --add-tracking and --delete-tracking? I was
trying to re-use the fact that we already have --track and --no-track,
but I needed some way to differentiate the mode from "create a new
branch". Hence -u.
j.
^ permalink raw reply
* Re: setting up tracking on push
From: Jeff King @ 2009-03-11 3:57 UTC (permalink / raw)
To: Jay Soffian; +Cc: Marc Branchaud, Miles Bader, git
In-Reply-To: <76718490903102044j4ca3462eye5ffcb178608dc29@mail.gmail.com>
On Tue, Mar 10, 2009 at 11:44:14PM -0400, Jay Soffian wrote:
> > Hmm. I think of that as "make <newbranch>, move from <oldbranch> or
> > HEAD".
>
> Um, I think of it as "rename <oldbranch> to <newbranch>" where
> <oldbranch> defaults to the current branch (aka HEAD).
Perhaps it is because it was added onto "git branch" which already had
an existing syntax and meaning, but I have always seen it as "operating"
on the new branch.
There was some debate about this when "-m" came about (with respect to
the order of arguments).
So I think it is largely a matter of perception and mental model.
> -u w/o --track/--no-track is a usage error.
Then what is the point of "-u"? You said before that it was a new
operation with room for future growth of additional options. Either it
is _just_ for --track, in which case I think you are better to have a
single option representing the notion of "update the tracking setup", or
it isn't, in which case it needs to have room for future expansion.
-Peff
^ permalink raw reply
* Re: setting up tracking on push
From: Jay Soffian @ 2009-03-11 3:44 UTC (permalink / raw)
To: Jeff King; +Cc: Marc Branchaud, Miles Bader, git
In-Reply-To: <20090311030604.GA3044@coredump.intra.peff.net>
On Tue, Mar 10, 2009 at 11:06 PM, Jeff King <peff@peff.net> wrote:
>> No, look at how -m works. [<oldbranch>] <newbranch>. I modeled it after that.
>
> Hmm. I think of that as "make <newbranch>, move from <oldbranch> or
> HEAD".
Um, I think of it as "rename <oldbranch> to <newbranch>" where
<oldbranch> defaults to the current branch (aka HEAD).
> Just as regular branch is "make <newbranch>, start from
> <oldbranch> or HEAD". But your proposal is "update <newbranch> or HEAD,
> from <oldbranch>".
Wait, what? No it isn't. My proposal is add or remove tracking
information to <branch> where <branch> defaults to the current branch
(aka HEAD).
-u w/o --track/--no-track is a usage error.
j.
^ permalink raw reply
* Re: setting up tracking on push
From: Jay Soffian @ 2009-03-11 3:40 UTC (permalink / raw)
To: Jeff King; +Cc: Marc Branchaud, Miles Bader, git
In-Reply-To: <20090311030604.GA3044@coredump.intra.peff.net>
On Tue, Mar 10, 2009 at 11:06 PM, Jeff King <peff@peff.net> wrote:
> If "-u" is supposed to be a general mode, then what does it mean to say:
>
> git branch -u foo
Nothing, that would emit the usage message since it's not valid.
> ? I would expect that to "update" foo. But if --track is given, then it
> means "update HEAD to track foo".
Maybe branch isn't the best place to put this feature, but it's where
I'd look. I'm not married to -u, it was just the first thing that came
to mind. But I still can't think of anything better.
j.
^ permalink raw reply
* [PATCH] Include log_config module in apache.conf
From: Daniel Barkalow @ 2009-03-11 3:23 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano
The log_config module is needed for at least some versions of apache to
support the LogFormat directive.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
---
Johannes, you added the LogFormat line without this; does the test still
work for you with this added, or do we need something clever to decide
whether the module needs to be loaded or needs to not be loaded?
t/lib-httpd/apache.conf | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/t/lib-httpd/apache.conf b/t/lib-httpd/apache.conf
index af6e5e1..a0d4077 100644
--- a/t/lib-httpd/apache.conf
+++ b/t/lib-httpd/apache.conf
@@ -4,6 +4,7 @@ DocumentRoot www
LogFormat "%h %l %u %t \"%r\" %>s %b" common
CustomLog access.log common
ErrorLog error.log
+LoadModule log_config_module modules/mod_log_config.so
<IfDefine Darwin>
LoadModule log_config_module modules/mod_log_config.so
--
1.6.2.77.g8cc3f.dirty
^ permalink raw reply related
* Re: setting up tracking on push
From: Jeff King @ 2009-03-11 3:06 UTC (permalink / raw)
To: Jay Soffian; +Cc: Marc Branchaud, Miles Bader, git
In-Reply-To: <76718490903101959i61df26aagdff44bb9ab4593ab@mail.gmail.com>
On Tue, Mar 10, 2009 at 10:59:01PM -0400, Jay Soffian wrote:
> But the primary reason for the -u is to differentiate the operation,
> just like -m and -d.
OK, that at least makes a bit of sense to me.
> > 2. In your example, if I give only a single non-option argument, it is
> > interpreted as the upstream (and presumably the branch defaults to
> > HEAD). But in other branch commands, it is interpreted as the
> > branch, and the upstream defaults to HEAD.
>
> No, look at how -m works. [<oldbranch>] <newbranch>. I modeled it after that.
Hmm. I think of that as "make <newbranch>, move from <oldbranch> or
HEAD". Just as regular branch is "make <newbranch>, start from
<oldbranch> or HEAD". But your proposal is "update <newbranch> or HEAD,
from <oldbranch>".
If "-u" is supposed to be a general mode, then what does it mean to say:
git branch -u foo
? I would expect that to "update" foo. But if --track is given, then it
means "update HEAD to track foo".
-Peff
^ permalink raw reply
* Re: setting up tracking on push
From: Jay Soffian @ 2009-03-11 2:59 UTC (permalink / raw)
To: Jeff King; +Cc: Marc Branchaud, Miles Bader, git
In-Reply-To: <20090311020409.GA31365@coredump.intra.peff.net>
On Tue, Mar 10, 2009 at 10:04 PM, Jeff King <peff@peff.net> wrote:
>
>> -u --track [<branch>] <upstream>
>
> Hmm. This seems not quite right to me. Specifically:
>
> 1. Would you ever want to use "-u" without "--track"? If so, then why
> are they two separate options?
For when branch grows additional long options that update, er,
something else. :-)
And you can also use it with --no-track.
But the primary reason for the -u is to differentiate the operation,
just like -m and -d.
> 2. In your example, if I give only a single non-option argument, it is
> interpreted as the upstream (and presumably the branch defaults to
> HEAD). But in other branch commands, it is interpreted as the
> branch, and the upstream defaults to HEAD.
No, look at how -m works. [<oldbranch>] <newbranch>. I modeled it after that.
> For (1), you could just have a single option. Unfortunately --track is
> taken. But maybe you could do --track=. And that helps with (2), as
> well, since this syntax would only ever have one or zero arguments. And
> then you can default zero to HEAD.
>
> IOW:
>
> # track origin/master with the current branch
> git branch --track=origin/master
>
> # track origin/master with a different branch
> git branch --track=origin/master other_branch
>
> # stop tracking
> git branch --track=
>
> The only two problems I can think of are:
>
> 1. It is perhaps a little confusing that --track= means "don't do the
> normal branch operation, but instead do this totally different
> thing. Of course we already have a similar situation with "-m", but
> it is perhaps more confusing since "--track" and "--track=" have
> totally different semantics.
>
> 2. This would be the only branch command to operate on HEAD if given
> no argument. That isn't necessary for this proposal, but I think it
> makes it nicer to use. An alternative would be for git-branch to
> resolve symrefs (which would also be nice for "git branch -m HEAD
> foo").
Yeah, I like that less than -u, which I agree isn't perfect, but I
think it's closer.
j.
^ permalink raw reply
* [PATCH v2] connect.c: remove a few globals by using git_config callback data
From: Erik Faye-Lund @ 2009-03-11 2:38 UTC (permalink / raw)
To: git; +Cc: Erik Faye-Lund
Since ef90d6d (Provide git_config with a callback-data parameter,
2008-05-14), git_config() takes a callback data pointer that can be
used to pass extra parameters to the parsing function. The codepath
to parse configuration variables related to git proxy predates this
facility and used a pair of file scope static variables instead.
This patch removes the need for these global variables by passing the
name of the host we are trying to access as the callback data.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
connect.c | 9 +++------
1 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/connect.c b/connect.c
index 2f23ab3..0a35cc1 100644
--- a/connect.c
+++ b/connect.c
@@ -373,8 +373,6 @@ static void git_tcp_connect(int fd[2], char *host, int flags)
static char *git_proxy_command;
-static const char *rhost_name;
-static int rhost_len;
static int git_proxy_command_options(const char *var, const char *value,
void *cb)
@@ -383,6 +381,8 @@ static int git_proxy_command_options(const char *var, const char *value,
const char *for_pos;
int matchlen = -1;
int hostlen;
+ const char *rhost_name = cb;
+ int rhost_len = strlen(rhost_name);
if (git_proxy_command)
return 0;
@@ -426,11 +426,8 @@ static int git_proxy_command_options(const char *var, const char *value,
static int git_use_proxy(const char *host)
{
- rhost_name = host;
- rhost_len = strlen(host);
git_proxy_command = getenv("GIT_PROXY_COMMAND");
- git_config(git_proxy_command_options, NULL);
- rhost_name = NULL;
+ git_config(git_proxy_command_options, (void*)host);
return (git_proxy_command && *git_proxy_command);
}
--
1.6.2.GIT
^ permalink raw reply related
* Re: setting up tracking on push
From: Jeff King @ 2009-03-11 2:04 UTC (permalink / raw)
To: Jay Soffian; +Cc: Marc Branchaud, Miles Bader, git
In-Reply-To: <76718490903101852y2c90e0abi8e0e4f71e6f0bc52@mail.gmail.com>
On Tue, Mar 10, 2009 at 09:52:44PM -0400, Jay Soffian wrote:
> Maybe a new switch, say -u for update:
>
> -u --track [<branch>] <upstream>
>
> Update tracking information for an existing branch. <branch> is
> optional and defaults to the current branch. <upstream> is the branch
> you wish to track, e.g. origin/master; normally <upstream> is a remote
> tracking branch, but specifying a local branch is valid as well.
>
> -u --no-track [<branch>]
>
> Remove tracking information for an existing branch. <branch> is
> optional and defaults to the current branch.
Hmm. This seems not quite right to me. Specifically:
1. Would you ever want to use "-u" without "--track"? If so, then why
are they two separate options?
2. In your example, if I give only a single non-option argument, it is
interpreted as the upstream (and presumably the branch defaults to
HEAD). But in other branch commands, it is interpreted as the
branch, and the upstream defaults to HEAD.
For (1), you could just have a single option. Unfortunately --track is
taken. But maybe you could do --track=. And that helps with (2), as
well, since this syntax would only ever have one or zero arguments. And
then you can default zero to HEAD.
IOW:
# track origin/master with the current branch
git branch --track=origin/master
# track origin/master with a different branch
git branch --track=origin/master other_branch
# stop tracking
git branch --track=
The only two problems I can think of are:
1. It is perhaps a little confusing that --track= means "don't do the
normal branch operation, but instead do this totally different
thing. Of course we already have a similar situation with "-m", but
it is perhaps more confusing since "--track" and "--track=" have
totally different semantics.
2. This would be the only branch command to operate on HEAD if given
no argument. That isn't necessary for this proposal, but I think it
makes it nicer to use. An alternative would be for git-branch to
resolve symrefs (which would also be nice for "git branch -m HEAD
foo").
-Peff
^ permalink raw reply
* Re: [RFC/PATCH] git push usability improvements and default change
From: Jay Soffian @ 2009-03-11 1:57 UTC (permalink / raw)
To: Finn Arne Gangstad; +Cc: Jeff King, git
In-Reply-To: <20090310220400.GA9612@pvv.org>
On Tue, Mar 10, 2009 at 6:04 PM, Finn Arne Gangstad <finnag@pvv.org> wrote:
> --current pushs the current branch to whatever it is tracking, no
> matter what name it has (i.e. it can push to a branch of different
> name). If it is not tracking anything, it will not push.
I think the option is definitely misnamed then. If it survives the
list feedback, it should probably be called something like --tracked.
j.
^ permalink raw reply
* Re: [PATCH] Removed unnecessary use of global variables.
From: Junio C Hamano @ 2009-03-11 1:52 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: git, Johannes.Schindelin
In-Reply-To: <1236733524-8892-1-git-send-email-kusmabite@gmail.com>
Erik Faye-Lund <kusmabite@gmail.com> writes:
> Subject: Re: [PATCH] Removed unnecessary use of global variables.
Please review "git log" and "git shortlog" output for the past dozen or so
commits to learn the style used in the project.
The first paragraph is a single line that goes to "Subject: ". It
typically:
- mentions what area, file, or function is affected;
- a colon;
- command the person who applies the patch to do something, iow,
phrased in imperative mood; and
- lacks the terminating full-stop.
That is:
Subject: connect.c: remove a few globals by using git_config callback data
> git_config() now takes a third data-parameter that is passed back
> to the callback-function. At the time this code was written, that
> parameter did not exist, so a somewhat nasty (but by all means
> correct) use of global variables was introduced. In commit
> ef90d6d4208a5130185b04f06e5f90a5f9959fe3 Johannes Schindelin
> <Johannes.Schindelin@gmx.de> introduced a parameter for similar
> purposes.
Perfect, even though I would have abbreviated the commit object name and
said:
Since ef90d6d (Provide git_config with a callback-data parameter,
2008-05-14), git_config() takes a callback data pointer that can be
used to pass extra parameters to the parsing function. The codepath
to parse configuration variables related to git proxy predates this
facility and used a pair of file scope static variables instead.
> I've changed the code to utilize this parameter to pass the
> string. In addition, I've made the function calculate the string
> length on usage instead, to reduce the parameters needed to what
> the callback-interface supplies.
We tend to avoid saying "I did this", i.e.
This patch removes the need for these global variables by passing the
name of the host we are trying to access as the callback data.
> Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
> ---
> connect.c | 16 ++++++----------
> 1 files changed, 6 insertions(+), 10 deletions(-)
>
> diff --git a/connect.c b/connect.c
> index 2f23ab3..98fbaea 100644
> --- a/connect.c
> +++ b/connect.c
> @@ -371,14 +371,13 @@ static void git_tcp_connect(int fd[2], char *host, int flags)
> fd[1] = dup(sockfd);
> }
>
> -
> static char *git_proxy_command;
> -static const char *rhost_name;
> -static int rhost_len;
> -
> static int git_proxy_command_options(const char *var, const char *value,
> - void *cb)
> + void *data)
> {
> + const char *rhost_name = data;
> + const size_t rhost_len = strlen(rhost_name);
> +
This is bad for two and half reasons.
- The original said "cb" and we use that to denote "callback"
everywhere. Renaming it to "data" adds noise to the patch without
adding any extra value.
- The original used "int" but you made it to an unsigned "size_t"; a
type-change like this could change the semantics.
I've read the codepath and it does not seem to introduce a bug, but if
you are changing it to size_t, then you should change the other two
variables (host_len and match_len) that are compared with (and are
involved in subtraction with) rhost_len to the same type at the same
time to avoid confusion and potential for a bug.
- Parser functions given to git_config(), such as this one, are called
for each and every configuration datum encountered in the config files
(/etc/gitconfig, $HOME/.gitconfig, and .git/config). Because you
decided not to precompute rhost_len at the calling site, you are
recomputing it every time this function is called. Worse yet, you
compute it even before deciding if the call is about "core.gitproxy"
variable.
Moving these two variables down one scope would be a reasonable
compromise. You could introduce a structure with two members (name,
len) and pass it as a call-back data, but for this particular case,
counting the length of the name every time you see "core.gitproxy" in
the configuration file is acceptable.
Thanks.
^ permalink raw reply
* Re: setting up tracking on push
From: Jay Soffian @ 2009-03-11 1:52 UTC (permalink / raw)
To: Jeff King; +Cc: Marc Branchaud, Miles Bader, git
In-Reply-To: <20090310230939.GB14083@sigio.peff.net>
On Tue, Mar 10, 2009 at 7:09 PM, Jeff King <peff@peff.net> wrote:
> On Tue, Mar 10, 2009 at 04:26:03PM -0400, Marc Branchaud wrote:
>
>> It would be good if the branch command allowed modification of a
>> branch's properties. At the very least, branch-creation commands like
>> "git branch --track foobranch origin/master" could offer to modify if
>> the branch already exists, instead of just quitting.
>
> I agree that it would be nice if an interface could be made around
> "branch --track". However, the problem with
>
> git branch --track foobranch origin/master
>
> is that it does two things: it sets up tracking, and it resets the
> foobranch ref. Right now we complain if foobranch already exists. We
> have a "-f" to override. But what you want to say is "set foobranch to
> track origin/master, but _don't_ actually reset where it points". And I
> don't see an intuitive way of doing that with that syntax. If you don't
> require "-f", then you are silently ignoring half of what the user asked
> you to do.
Maybe a new switch, say -u for update:
-u --track [<branch>] <upstream>
Update tracking information for an existing branch. <branch> is
optional and defaults to the current branch. <upstream> is the branch
you wish to track, e.g. origin/master; normally <upstream> is a remote
tracking branch, but specifying a local branch is valid as well.
-u --no-track [<branch>]
Remove tracking information for an existing branch. <branch> is
optional and defaults to the current branch.
j.
^ permalink raw reply
* Re: Removed unnecessary use of global variables.
From: Erik Faye-Lund @ 2009-03-11 1:19 UTC (permalink / raw)
To: git
In-Reply-To: <1236730168-7164-1-git-send-email-kusmabite@gmail.com>
Sorry about the whole double-post thing, this whole submitting patches
over email thing is new to me, and I'm making too many mistakes right
now. Hopefully, I'll improve in the future ;)
On Mar 11, 1:09 am, Erik Faye-Lund <kusmab...@gmail.com> wrote:
> git_config() now takes a third data-parameter that is passed back
> to the callback-function. At the time this code was written, that
> parameter did not exist, so a somewhat nasty (but by all means
> correct) use of global variables was introduced. In commit
> ef90d6d4208a5130185b04f06e5f90a5f9959fe3 Johannes Schindelin
> <Johannes.Schinde...@gmx.de> introduced a parameter for similar
> purposes.
>
> I've changed the code to utilize this parameter to pass the
> string. In addition, I've made the function calculate the string
> length on usage instead, to reduce the parameters needed to what
> the callback-interface supplies.
>
> Signed-off-by: Erik Faye-Lund <kusmab...@gmail.com>
> ---
> connect.c | 16 ++++++----------
> 1 files changed, 6 insertions(+), 10 deletions(-)
>
> diff --git a/connect.c b/connect.c
> index 2f23ab3..98fbaea 100644
> --- a/connect.c
> +++ b/connect.c
> @@ -371,14 +371,13 @@ static void git_tcp_connect(int fd[2], char *host, int flags)
> fd[1] = dup(sockfd);
> }
>
> -
> static char *git_proxy_command;
> -static const char *rhost_name;
> -static int rhost_len;
> -
> static int git_proxy_command_options(const char *var, const char *value,
> - void *cb)
> + void *data)
> {
> + const char *rhost_name = data;
> + const size_t rhost_len = strlen(rhost_name);
> +
> if (!strcmp(var, "core.gitproxy")) {
> const char *for_pos;
> int matchlen = -1;
> @@ -421,16 +420,13 @@ static int git_proxy_command_options(const char *var, const char *value,
> return 0;
> }
>
> - return git_default_config(var, value, cb);
> + return git_default_config(var, value, data);
> }
>
> static int git_use_proxy(const char *host)
> {
> - rhost_name = host;
> - rhost_len = strlen(host);
> git_proxy_command = getenv("GIT_PROXY_COMMAND");
> - git_config(git_proxy_command_options, NULL);
> - rhost_name = NULL;
> + git_config(git_proxy_command_options, (void*)host);
> return (git_proxy_command && *git_proxy_command);
> }
>
> --
> 1.6.2.GIT
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] Removed unnecessary use of global variables.
From: Erik Faye-Lund @ 2009-03-11 0:09 UTC (permalink / raw)
To: git; +Cc: Johannes.Schindelin, Erik Faye-Lund
git_config() now takes a third data-parameter that is passed back
to the callback-function. At the time this code was written, that
parameter did not exist, so a somewhat nasty (but by all means
correct) use of global variables was introduced. In commit
ef90d6d4208a5130185b04f06e5f90a5f9959fe3 Johannes Schindelin
<Johannes.Schindelin@gmx.de> introduced a parameter for similar
purposes.
I've changed the code to utilize this parameter to pass the
string. In addition, I've made the function calculate the string
length on usage instead, to reduce the parameters needed to what
the callback-interface supplies.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
connect.c | 16 ++++++----------
1 files changed, 6 insertions(+), 10 deletions(-)
diff --git a/connect.c b/connect.c
index 2f23ab3..98fbaea 100644
--- a/connect.c
+++ b/connect.c
@@ -371,14 +371,13 @@ static void git_tcp_connect(int fd[2], char *host, int flags)
fd[1] = dup(sockfd);
}
-
static char *git_proxy_command;
-static const char *rhost_name;
-static int rhost_len;
-
static int git_proxy_command_options(const char *var, const char *value,
- void *cb)
+ void *data)
{
+ const char *rhost_name = data;
+ const size_t rhost_len = strlen(rhost_name);
+
if (!strcmp(var, "core.gitproxy")) {
const char *for_pos;
int matchlen = -1;
@@ -421,16 +420,13 @@ static int git_proxy_command_options(const char *var, const char *value,
return 0;
}
- return git_default_config(var, value, cb);
+ return git_default_config(var, value, data);
}
static int git_use_proxy(const char *host)
{
- rhost_name = host;
- rhost_len = strlen(host);
git_proxy_command = getenv("GIT_PROXY_COMMAND");
- git_config(git_proxy_command_options, NULL);
- rhost_name = NULL;
+ git_config(git_proxy_command_options, (void*)host);
return (git_proxy_command && *git_proxy_command);
}
--
1.6.2.GIT
^ permalink raw reply related
* [PATCH] Removed unnecessary use of global variables.
From: Erik Faye-Lund @ 2009-03-11 1:05 UTC (permalink / raw)
To: git; +Cc: Johannes.Schindelin, Erik Faye-Lund
git_config() now takes a third data-parameter that is passed back
to the callback-function. At the time this code was written, that
parameter did not exist, so a somewhat nasty (but by all means
correct) use of global variables was introduced. In commit
ef90d6d4208a5130185b04f06e5f90a5f9959fe3 Johannes Schindelin
<Johannes.Schindelin@gmx.de> introduced a parameter for similar
purposes.
I've changed the code to utilize this parameter to pass the
string. In addition, I've made the function calculate the string
length on usage instead, to reduce the parameters needed to what
the callback-interface supplies.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
connect.c | 16 ++++++----------
1 files changed, 6 insertions(+), 10 deletions(-)
diff --git a/connect.c b/connect.c
index 2f23ab3..98fbaea 100644
--- a/connect.c
+++ b/connect.c
@@ -371,14 +371,13 @@ static void git_tcp_connect(int fd[2], char *host, int flags)
fd[1] = dup(sockfd);
}
-
static char *git_proxy_command;
-static const char *rhost_name;
-static int rhost_len;
-
static int git_proxy_command_options(const char *var, const char *value,
- void *cb)
+ void *data)
{
+ const char *rhost_name = data;
+ const size_t rhost_len = strlen(rhost_name);
+
if (!strcmp(var, "core.gitproxy")) {
const char *for_pos;
int matchlen = -1;
@@ -421,16 +420,13 @@ static int git_proxy_command_options(const char *var, const char *value,
return 0;
}
- return git_default_config(var, value, cb);
+ return git_default_config(var, value, data);
}
static int git_use_proxy(const char *host)
{
- rhost_name = host;
- rhost_len = strlen(host);
git_proxy_command = getenv("GIT_PROXY_COMMAND");
- git_config(git_proxy_command_options, NULL);
- rhost_name = NULL;
+ git_config(git_proxy_command_options, (void*)host);
return (git_proxy_command && *git_proxy_command);
}
--
1.6.2.GIT
^ permalink raw reply related
* Re: filter-branch --subdirectory-filter prematurely truncating history?
From: Cap Petschulat @ 2009-03-11 0:37 UTC (permalink / raw)
To: git
In-Reply-To: <49B60FF9.9020805@viscovery.net>
Johannes Sixt <j.sixt <at> viscovery.net> writes:
> A bug in this area was fixed in git v1.6.0-rc3. Which version are you using?
I was using 1.5.4.3 from Ubuntu Hardy, but I just rebuilt git from the most
recent sources and now filter-branch does what I want. Thanks for the suggestion!
^ permalink raw reply
* Re: [PATCH/RFD] builtin-revert.c: release index lock when cherry-picking an empty commit
From: Jeff King @ 2009-03-11 0:30 UTC (permalink / raw)
To: Chris Johnsen; +Cc: Junio C Hamano, git, Miklos Vajna
In-Reply-To: <AA6A171F-70CE-4CB3-9AE1-27CD69C3202C@pobox.com>
On Tue, Mar 10, 2009 at 06:57:55PM -0500, Chris Johnsen wrote:
> On 2009 Mar 10, at 13:17, Jeff King wrote:
>> Can somebody with an OS X box try:
>>
>> $ /bin/sh
>> $ eval 'false
>>
>> '
>> $ echo $?
>>
>> It should print '1'; if it prints '0', the shell is broken.
>
> I wrote t3505 on a Mac OS X 10.4.11 system. On that system, /bin/sh is a
> copy of bash v2.05b. Your test code prints 1 here.
OK, then nothing to worry about there. I have no idea which shell
OpenBSD and NetBSD use these days, and I don't have access to a box.
Anybody?
-Peff
^ permalink raw reply
* Re: import files w/ history
From: Csaba Henk @ 2009-03-11 0:11 UTC (permalink / raw)
To: git
In-Reply-To: <20090310180353.GC26351@sigill.intra.peff.net>
On 2009-03-10, Jeff King <peff@peff.net> wrote:
> I think passing path limiters to filter-branch is just something that
> nobody ever really tried before. I think the solutions are, in order of
> decreasing easiness and increasing difficulty:
>
> 1. document the problem in Documentation/git-filter-branch.txt
>
> 2. create a failing test for it in the test suite
>
> 3. fix the failing test. ;)
>
> Do you want to try a patch for one (or more!) of those?
I'm eager to contribute... next month. I'm pretty much overwhelmed
now. (Accidentally I almost wrote "overclocked" instead of
"overwhelmed"... only if that were true!)
Regards,
Csaba
^ permalink raw reply
* Re: [PATCH/RFC] recv_sideband: Band #2 always goes to stderr
From: Junio C Hamano @ 2009-03-10 23:59 UTC (permalink / raw)
To: Johannes Sixt
Cc: Johannes Schindelin, git, gitster, Peter Harris,
Sebastian Schuberth, Nicolas Pitre
In-Reply-To: <49B64ADC.2090406@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> All data producers and data consumers *in git* use band #2 to transport
> error messages and progress report.
Correct; I wrote that in the big comment at the beginning of sideband.c.
Of course we could enhance the protocol to use more bands as needed. #2
and #3 have their own meanings and they both map well to "send to stderr".
^ permalink raw reply
* Re: [PATCH/RFD] builtin-revert.c: release index lock when cherry-picking an empty commit
From: Chris Johnsen @ 2009-03-10 23:57 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git, Miklos Vajna
In-Reply-To: <20090310181730.GD26351@sigill.intra.peff.net>
On 2009 Mar 10, at 13:17, Jeff King wrote:
> Can somebody with an OS X box try:
>
> $ /bin/sh
> $ eval 'false
>
> '
> $ echo $?
>
> It should print '1'; if it prints '0', the shell is broken.
I wrote t3505 on a Mac OS X 10.4.11 system. On that system, /bin/sh
is a copy of bash v2.05b. Your test code prints 1 here.
--
Chris
^ permalink raw reply
* Re: [PATCH JGIT] Add "compare with Git Index" action.
From: Robin Rosenberg @ 2009-03-10 23:22 UTC (permalink / raw)
To: Yann Simon; +Cc: Shawn O. Pearce, git
In-Reply-To: <49B63ADC.4080009@gmail.com>
tisdag 10 mars 2009 11:03:08 skrev Yann Simon <yann.simon.fr@gmail.com>:
> In the Compare With... menu, the "Git Index" action opens
> a diff editor that compares the workspace version of a file and its
> index version.
>
> The local file can be modified and saved.
>
> The staged version can be modified and saved. This updates the index.
> For this, add methods into GitIndex to allow to specify a content
> different from the file.
>
> Signed-off-by: Yann Simon <yann.simon.fr@gmail.com>
> ---
> Changed comapred to previous version:
> - fix saving the index version.
Saving works, but the diff regions aren't updated on save. When there is a diff
this would give us the partial staging similar to git gui, if only (not your fault) the
commit dialog would allow us to make a distinction between changes in the
workdir and the index.
-- robin
^ permalink raw reply
* Re: setting up tracking on push
From: Jeff King @ 2009-03-10 23:09 UTC (permalink / raw)
To: Marc Branchaud; +Cc: Miles Bader, git
In-Reply-To: <49B6CCDB.8010305@xiplink.com>
On Tue, Mar 10, 2009 at 04:26:03PM -0400, Marc Branchaud wrote:
> It would be good if the branch command allowed modification of a
> branch's properties. At the very least, branch-creation commands like
> "git branch --track foobranch origin/master" could offer to modify if
> the branch already exists, instead of just quitting.
I agree that it would be nice if an interface could be made around
"branch --track". However, the problem with
git branch --track foobranch origin/master
is that it does two things: it sets up tracking, and it resets the
foobranch ref. Right now we complain if foobranch already exists. We
have a "-f" to override. But what you want to say is "set foobranch to
track origin/master, but _don't_ actually reset where it points". And I
don't see an intuitive way of doing that with that syntax. If you don't
require "-f", then you are silently ignoring half of what the user asked
you to do.
> BTW, I think the following (untested) incantation adds tracking to a branch:
>
> git config branch.foobranch.remote origin
> git config branch.foobranch.merge refs/heads/master
Yes, that is right. The only reason it is not a two-line script to
convert "git branch --track" into that is that you have to actually
resolve origin/master into "remote origin, branch refs/heads/master".
-Peff
^ permalink raw reply
* Re: [PATCH 2/2] ls-files: fix broken --no-empty-directory
From: Miklos Vajna @ 2009-03-10 22:16 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20090310191111.GA27662@sigill.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 487 bytes --]
On Tue, Mar 10, 2009 at 03:11:11PM -0400, Jeff King <peff@peff.net> wrote:
> which is even still a little confusing, as you get "--empty-directory"
> in the usage message. But you would almost never want to use that, as it
> is already the default.
Exactly, that's why I suggested the usage of PARSE_OPT_NONEG, which
would avoid a new no-op option. ;-)
But I'm fine with the above patch as well, in case having the "no-"
prefix in an option name is considered as an improper negation.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [RFC/PATCH] git push usability improvements and default change
From: Jeff King @ 2009-03-10 22:10 UTC (permalink / raw)
To: Finn Arne Gangstad; +Cc: git
In-Reply-To: <20090310220400.GA9612@pvv.org>
On Tue, Mar 10, 2009 at 11:04:00PM +0100, Finn Arne Gangstad wrote:
> --current pushs the current branch to whatever it is tracking, no
> matter what name it has (i.e. it can push to a branch of different
> name). If it is not tracking anything, it will not push.
>
> git push - HEAD pushes the current branch to a branch of the same name
> on the "current remote", which defaults to origin if nothing is set up
> for the branch.
OK, that's what I was missing. Thanks.
-Peff
^ permalink raw reply
* Re: [RFC/PATCH] git push usability improvements and default change
From: Finn Arne Gangstad @ 2009-03-10 22:04 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20090310175233.GA26351@sigill.intra.peff.net>
On Tue, Mar 10, 2009 at 01:52:33PM -0400, Jeff King wrote:
>
> I have not been following this topic too closely, so can you please
> explain (or point me to an explanation about) something? How do these
> options interact with refspecs given on the command line? That is, why
> would I choose to use:
>
> git push --current
>
> over
>
> git push - HEAD
--current pushs the current branch to whatever it is tracking, no
matter what name it has (i.e. it can push to a branch of different
name). If it is not tracking anything, it will not push.
git push - HEAD pushes the current branch to a branch of the same name
on the "current remote", which defaults to origin if nothing is set up
for the branch.
> (assuming your earlier patch is applied, or "git push HEAD" if Junio's
> suggested DWIMmery is implemented). And what does it mean to say
>
> git push --matching - HEAD
>
> ? Those are conflicting instructions. Is one followed and one discarded?
> Are they merged?
It would be an error, no refspecs can be specified with --matching.
- Finn Arne
^ 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