* [PATCH 2/2] Add an option for using any HTTP authentication scheme, not only basic
From: Tay Ray Chuan @ 2009-11-27 15:43 UTC (permalink / raw)
To: git
In-Reply-To: <20091127234226.8b158336.rctay89@gmail.com>
From: =?ISO-8859-15?Q?Martin_Storsj=F6?= <martin@martin.st>
This adds the configuration option http.authAny (overridable with
the environment variable GIT_HTTP_AUTH_ANY), for instructing curl
to allow any HTTP authentication scheme, not only basic (which
sends the password in plaintext).
When this is enabled, curl has to do double requests most of the time,
in order to discover which HTTP authentication method to use, which
lowers the performance slightly. Therefore this isn't enabled by default.
One example of another authentication scheme to use is digest, which
doesn't send the password in plaintext, but uses a challenge-response
mechanism instead. Using digest authentication in practice requires
at least curl 7.18.1, due to bugs in the digest handling in earlier
versions of curl.
Signed-off-by: Martin Storsjo <martin@martin.st>
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
Martin, I've not made any changes, except to make it apply cleanly.
Documentation/config.txt | 7 +++++++
http.c | 22 ++++++++++++++++++++++
2 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index b77d66d..a54ede3 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1158,6 +1158,13 @@ http.noEPSV::
support EPSV mode. Can be overridden by the 'GIT_CURL_FTP_NO_EPSV'
environment variable. Default is false (curl will use EPSV).
+http.authAny::
+ Allow any HTTP authentication method, not only basic. Enabling
+ this lowers the performance slightly, by having to do requests
+ without any authentication to discover the authentication method
+ to use. Can be overridden by the 'GIT_HTTP_AUTH_ANY'
+ environment variable. Default is false.
+
i18n.commitEncoding::
Character encoding the commit messages are stored in; git itself
does not care per se, but this information is necessary e.g. when
diff --git a/http.c b/http.c
index fb0a97b..aeb69b3 100644
--- a/http.c
+++ b/http.c
@@ -7,6 +7,10 @@ int active_requests;
int http_is_verbose;
size_t http_post_buffer = 16 * LARGE_PACKET_MAX;
+#if LIBCURL_VERSION_NUM >= 0x070a06
+#define LIBCURL_CAN_HANDLE_AUTH_ANY
+#endif
+
static int min_curl_sessions = 1;
static int curl_session_count;
#ifdef USE_CURL_MULTI
@@ -36,6 +40,9 @@ static long curl_low_speed_time = -1;
static int curl_ftp_no_epsv;
static const char *curl_http_proxy;
static char *user_name, *user_pass;
+#ifdef LIBCURL_CAN_HANDLE_AUTH_ANY
+static int curl_http_auth_any = 0;
+#endif
#if LIBCURL_VERSION_NUM >= 0x071700
/* Use CURLOPT_KEYPASSWD as is */
@@ -190,6 +197,12 @@ static int http_options(const char *var, const char *value, void *cb)
http_post_buffer = LARGE_PACKET_MAX;
return 0;
}
+#ifdef LIBCURL_CAN_HANDLE_AUTH_ANY
+ if (!strcmp("http.authany", var)) {
+ curl_http_auth_any = git_config_bool(var, value);
+ return 0;
+ }
+#endif
/* Fall back on the default ones */
return git_default_config(var, value, cb);
@@ -240,6 +253,10 @@ static CURL *get_curl_handle(void)
#if LIBCURL_VERSION_NUM >= 0x070907
curl_easy_setopt(result, CURLOPT_NETRC, CURL_NETRC_OPTIONAL);
#endif
+#ifdef LIBCURL_CAN_HANDLE_AUTH_ANY
+ if (curl_http_auth_any)
+ curl_easy_setopt(result, CURLOPT_HTTPAUTH, CURLAUTH_ANY);
+#endif
init_curl_http_auth(result);
@@ -391,6 +408,11 @@ void http_init(struct remote *remote)
if (getenv("GIT_CURL_FTP_NO_EPSV"))
curl_ftp_no_epsv = 1;
+#ifdef LIBCURL_CAN_HANDLE_AUTH_ANY
+ if (getenv("GIT_HTTP_AUTH_ANY"))
+ curl_http_auth_any = 1;
+#endif
+
if (remote && remote->url && remote->url[0]) {
http_auth_init(remote->url[0]);
if (!ssl_cert_password_required &&
--
1.6.4.4
^ permalink raw reply related
* Re: [msysGit] [PATCH/RFC 08/11] daemon: use explicit file descriptor
From: Erik Faye-Lund @ 2009-11-27 15:46 UTC (permalink / raw)
To: Johannes Sixt; +Cc: msysgit, git, dotzenlabs
In-Reply-To: <40aa078e0911270623m1a06890cmd2d46b3d9e216769@mail.gmail.com>
On Fri, Nov 27, 2009 at 3:23 PM, Erik Faye-Lund
<kusmabite@googlemail.com> wrote:
> Sorry for the long delay in the reply, but I'm a little low on time
> these days (and I've already spent some time trying to figure out what
> I was thinking - I wrote these patches a while ago).
>
> On Thu, Nov 26, 2009 at 11:03 PM, Johannes Sixt <j6t@kdbg.org> wrote:
>> On Donnerstag, 26. November 2009, Erik Faye-Lund wrote:
>>> @@ -372,37 +372,35 @@ static int run_service_command(const char **argv)
>>> cld.argv = argv;
>>> cld.git_cmd = 1;
>>> cld.err = -1;
>>> + cld.in = cld.out = fd;
>>
>> You shouldn't do that. In fact, the next patch 9 has a hunk that correctly
>> calls dup() once.
>>
>
> OK, as long as it works as expected, sure. But perhaps this needs a
> little change (see discussion later)
>
>>> - close(0);
>>> - close(1);
>>
>> Here, stdin and stdout were closed and start_command() used both. But these
>> two new calls
>>
>>> + exit(execute(0, addr));
>>> ...
>>> + return execute(0, peer);
>>
>> are the only places where a value is assigned to fd. Now it is always only
>> stdin. Where does the old code initialize stdout? Shouldn't this place need a
>> change, too?
>
> The "dup2(incoming, 0)"-call in handle() is AFAICT what makes it work
> to use the forked process' stdin as both stdin and stdout for the
> service-process pipe (since fd 0 now becomes a pipe that is both
> readable and writable). This isn't exactly a pretty mechanism, and I
> guess I should rework it. At the very least, I should remove the
> "dup2(incoming, 1)"-call, but I'm open to other suggestions. Perhaps I
> can change this patch to do the entire socket-passing (which is
> currently in the next patch)?
>
Something along these lines?
---8<---
diff --git a/daemon.c b/daemon.c
index a0aead5..8774ed5 100644
--- a/daemon.c
+++ b/daemon.c
@@ -372,7 +372,8 @@ static int run_service_command(int fd, const char **argv)
cld.argv = argv;
cld.git_cmd = 1;
cld.err = -1;
- cld.in = cld.out = fd;
+ cld.in = dup(fd);
+ cld.out = fd;
if (start_command(&cld))
return -1;
@@ -707,11 +708,7 @@ static void handle(int incoming, struct sockaddr
*addr, int addrlen)
return;
}
- dup2(incoming, 0);
- dup2(incoming, 1);
- close(incoming);
-
- exit(execute(0, addr));
+ exit(execute(incoming, addr));
}
static void child_handler(int signo)
---8<---
When I think more about it, I might've broken the inetd-mode as it
should communicate over stdin and stdout (not just stdin as it would
try to do now)... I don't know the inetd internals, but this frightens
me a bit.
So perhaps I'll need to provide support for two unidirectional file
descriptors after all?
--
Erik "kusma" Faye-Lund
^ permalink raw reply related
* Re: [msysGit] [PATCH/RFC 06/11] run-command: add kill_async() and is_async_alive()
From: Erik Faye-Lund @ 2009-11-27 16:04 UTC (permalink / raw)
To: Johannes Sixt; +Cc: msysgit, git, dotzenlabs
In-Reply-To: <200911262246.13342.j6t@kdbg.org>
On Thu, Nov 26, 2009 at 10:46 PM, Johannes Sixt <j6t@kdbg.org> wrote:
> On Donnerstag, 26. November 2009, Erik Faye-Lund wrote:
>> +int kill_async(struct async *async)
>> +{
>> +#ifndef WIN32
>> + return kill(async->pid, SIGTERM);
>> +#else
>> + DWORD ret = 0;
>> + if (!TerminateThread(async->tid, 0))
>> + ret = error("killing thread failed: %lu", GetLastError());
>
> Ugh! Did you read the documentation of TerminateThread()?
>
> We need to kill processes/threads when we detect that there are too many
> connections. But TerminateThread() is such a dangerous function that we
> cannot pretend that everything is good, and we continue to accept
> connections.
>
Ouch, this is nasty. Something else needs to be done.
> Unless we find a different solution, I would prefer to punt and die instead.
>
Do you really think it's better to unconditionally take down the
entire process with an error, instead of having a relatively small
chance of stuff blowing up without any sensible error? I'm not 100%
convinced - but let's hope we'll find a proper fix.
>> + else if (!GetExitCodeThread(async->tid, &ret))
>> + ret = error("cannot get thread exit code: %lu", GetLastError());
>
> What should the exit code be good for? The return value of this function can
> only be -1 (failure, could not kill) or 0 (success, process killed).
>
I thought wait_or_whine() returned the exit-code, so I wanted to be
somewhat consistent. But even if it does (haven't checked), it's
probably not be worth it - I'll remove this for the next iteration.
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Uri Okrent @ 2009-11-27 16:27 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, James Pickens, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0911271144230.4521@intel-tinevez-2-302>
I've been following this thread for a long time and now I feel the
need to chime in...
On Fri, Nov 27, 2009 at 2:53 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> And it makes things inconsistent. That is why I do not use it.
The number one problem my users have with git is inconsistent
behavior, both internally to git, and externally with respect to the
rest of the OS. But really, the issue is one of managing expectations,
which is where we here tend to fall down.
When you name the command grep, whether you like it of not,
you've bought into a certain set of expectations from the user
who has been using unix's grep since she was a baby. Saying,
"well, in git it works this way", (or saying "well in git those path
looking things you've been providing to commands are not really
paths, so don't expect them to act as such"), would make my
users want to vomit all over me, and then, not use git (a shame
since it's the best scm system around IMHO).
If we intend the behavior of the command to be materially different
from the good old unix standby, then we shouldn't use the same
name, and create the expectation that they are getting essentially
the same thing (git search, git pickaxe, or something carries no
semantic baggage---and no, I'm not suggesting we change the
name).
> I, for one, do not like Git's reputation...
There's the rub. How do we achieve consistency without breaking the
world? The short answer is, you really can't. As programmers we tend
to be a very timid bunch, but sometimes (and David A. can attest to
this, at least at dayjob) it's better to just make a change for the better,
and just deal with the breakages. It is possible to change behavior (and
even break some scripts! I firmly believe it is worthwhile sacrificing
some scripts on the altar of consistency).
The key once again, is managing expectations. We can't go around
changing everything willy-nilly, and we can't be continually changing
things. Here is where we could take a lesson from the python
community.
When they decided they needed to change things, they bundled a
bunch of backwards incompatible changes together and went for it.
Yes, Python 3 will break your scripts, but the most important thing is,
everybody knows it.
A similar thing was done here with the huge warning that push spits
out, but in the general case I would argue, that the wisest course is to
save backwards incompatible changes for a git 2 or something, where
we know we're breaking the world, and then scratch all our (well thought
out) backwards incompatible itches at once.
Whew. A bit of a rant, but there you go...
--
Uri
Please consider the environment before printing this message.
http://www.panda.org/how_you_can_help/
^ permalink raw reply
* Re: qgit question: tagged commits not on a branch
From: Chris.Cheney @ 2009-11-27 17:21 UTC (permalink / raw)
To: git
In-Reply-To: <4B0FECFA.9040307@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> wrote in
news:4B0FECFA.9040307@drmicha.warpmail.net:
> Chris.Cheney venit, vidit, dixit 26.11.2009 22:54:
>> My commit graph has a number of forks (I can't use the word
>> "branches" here) that are referenced only by a tag. Whereas gitk
>> --all displays this graph including those forks, qgit does not
>> display those forks - I don't see a way to make it do so, other than
>> by adding branches to those tagged commits.
>>
>> Have I overlooked something?
>>
>
> qgit --all does it for me. It may not be the newest qgit, though.
> I use tags like that to mark a version of a topic branch before
> rebasing, so that on old version won't be gc'ed away and the branch
> name space is not too crowded. Poor man's topgit, so to say. I guess
> it's a common use case.
>
> Michael
>
Doh, indeed it does.
The problem was that qgit isn't (by default) installed in the git program
directory, as is gitk. Ok, I'll need to add a script in the git directory
to invoke qgit (passing the command-line arguments through) from where it
resides.
(WIBNI qgit and gitk provided a menu item to switch to --all mode.)
Thanks for your help
Chris
^ permalink raw reply
* Re: Strange behavior of gitweb
From: Alan Stern @ 2009-11-27 17:29 UTC (permalink / raw)
To: Andreas Schwab; +Cc: git
In-Reply-To: <m24oogyh2o.fsf@igel.home>
On Fri, 27 Nov 2009, Andreas Schwab wrote:
> Alan Stern <stern@rowland.harvard.edu> writes:
>
> > I recently ran across this strange behavior in the gitweb server at
> > git.kernel.org. The following URL:
> >
> > http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.27.y.git;a=commit;h=2d93148ab6988cad872e65d694c95e8944e1b62
> >
> > brings up a page containing commit 2d93148[...]. But that commit isn't
> > part of the 2.6.27.y tree! It belongs to Linus's main tree, and it was
> > added long after 2.6.27.y was forked off. The actual commit applied to
> > 2.6.27.y was 070bb0f3b6df167554f0ecdeb17a5bcdb1cd7b83.
> >
> > So what's going on here?
>
> Nothing mysterious. Every tree on kernel.org borrows from Linus' main
> tree via .git/objects/info/alternates, thus includes its whole object
> database by reference.
Hmm. That's all fine, but it can produce very misleading results like
the one above. I can imagine the same sort of thing happening in other
situations not involving alternates (e.g., orphaned commits).
Is there any way the web software can check whether the commit it found
is actually an ancestor of the tip node in the requested tree, and if
not add a big warning near the top of the page?
Alan Stern
^ permalink raw reply
* [PATCH/RFC 0/2] Lazily generate header dependencies
From: Jonathan Nieder @ 2009-11-27 17:45 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Johannes Sixt, Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0911271033460.4521@intel-tinevez-2-302>
Johannes Schindelin wrote:
> Funny; I thought that not all header files are library header files, i.e.
> not all header changes should trigger a full new build of libgit.a.
Maybe something like this could help?
Jonathan Nieder (2):
Makefile: use target-specific variable to pass flags to cc
Makefile: automatically track header dependencies
.gitignore | 1 +
Makefile | 46 +++++++++++++++++++++++++++++-----------------
2 files changed, 30 insertions(+), 17 deletions(-)
^ permalink raw reply
* [PATCH/RFC 1/2] Makefile: use target-specific variable to pass flags to cc
From: Jonathan Nieder @ 2009-11-27 17:49 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Johannes Sixt, Junio C Hamano, Git Mailing List
In-Reply-To: <20091127174558.GA3461@progeny.tock>
Remove some duplicated Makefile code by reusing the %.o: %.c rule
even for objects that need to be built with special flags. This
makes the relevant -D parameters more prominent on the command
line and means any changes to the rules for compilation only have
to happen in one place.
Target-specific variables have been supported in GNU make since
version 3.77 from 1998.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Makefile | 31 +++++++++++++++----------------
1 files changed, 15 insertions(+), 16 deletions(-)
diff --git a/Makefile b/Makefile
index 5a0b3d4..ed0f461 100644
--- a/Makefile
+++ b/Makefile
@@ -1440,19 +1440,18 @@ strip: $(PROGRAMS) git$X
$(STRIP) $(STRIP_OPTS) $(PROGRAMS) git$X
git.o: git.c common-cmds.h GIT-CFLAGS
- $(QUIET_CC)$(CC) -DGIT_VERSION='"$(GIT_VERSION)"' \
- '-DGIT_HTML_PATH="$(htmldir_SQ)"' \
- $(ALL_CFLAGS) -o $@ -c $(filter %.c,$^)
+git.o: ALL_CFLAGS += -DGIT_VERSION='"$(GIT_VERSION)"' \
+ '-DGIT_HTML_PATH="$(htmldir_SQ)"'
git$X: git.o $(BUILTIN_OBJS) $(GITLIBS)
$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ git.o \
$(BUILTIN_OBJS) $(ALL_LDFLAGS) $(LIBS)
builtin-help.o: builtin-help.c common-cmds.h GIT-CFLAGS
- $(QUIET_CC)$(CC) -o $*.o -c $(ALL_CFLAGS) \
- '-DGIT_HTML_PATH="$(htmldir_SQ)"' \
- '-DGIT_MAN_PATH="$(mandir_SQ)"' \
- '-DGIT_INFO_PATH="$(infodir_SQ)"' $<
+builtin-help.o: ALL_CFLAGS += \
+ '-DGIT_HTML_PATH="$(htmldir_SQ)"' \
+ '-DGIT_MAN_PATH="$(mandir_SQ)"' \
+ '-DGIT_INFO_PATH="$(infodir_SQ)"'
$(BUILT_INS): git$X
$(QUIET_BUILT_IN)$(RM) $@ && \
@@ -1568,24 +1567,24 @@ git.o git.spec \
$(QUIET_CC)$(CC) -o $*.o -c $(ALL_CFLAGS) $<
exec_cmd.o: exec_cmd.c GIT-CFLAGS
- $(QUIET_CC)$(CC) -o $*.o -c $(ALL_CFLAGS) \
- '-DGIT_EXEC_PATH="$(gitexecdir_SQ)"' \
- '-DBINDIR="$(bindir_relative_SQ)"' \
- '-DPREFIX="$(prefix_SQ)"' \
- $<
+exec_cmd.o: ALL_CFLAGS += \
+ '-DGIT_EXEC_PATH="$(gitexecdir_SQ)"' \
+ '-DBINDIR="$(bindir_relative_SQ)"' \
+ '-DPREFIX="$(prefix_SQ)"'
builtin-init-db.o: builtin-init-db.c GIT-CFLAGS
- $(QUIET_CC)$(CC) -o $*.o -c $(ALL_CFLAGS) -DDEFAULT_GIT_TEMPLATE_DIR='"$(template_dir_SQ)"' $<
+builtin-init-db.o: ALL_CFLAGS += \
+ -DDEFAULT_GIT_TEMPLATE_DIR='"$(template_dir_SQ)"'
config.o: config.c GIT-CFLAGS
- $(QUIET_CC)$(CC) -o $*.o -c $(ALL_CFLAGS) -DETC_GITCONFIG='"$(ETC_GITCONFIG_SQ)"' $<
+config.o: ALL_CFLAGS += -DETC_GITCONFIG='"$(ETC_GITCONFIG_SQ)"'
http.o: http.c GIT-CFLAGS
- $(QUIET_CC)$(CC) -o $*.o -c $(ALL_CFLAGS) -DGIT_USER_AGENT='"git/$(GIT_VERSION)"' $<
+http.o: ALL_CFLAGS += -DGIT_USER_AGENT='"git/$(GIT_VERSION)"'
ifdef NO_EXPAT
http-walker.o: http-walker.c http.h GIT-CFLAGS
- $(QUIET_CC)$(CC) -o $*.o -c $(ALL_CFLAGS) -DNO_EXPAT $<
+http-walker.o: ALL_CFLAGS += -DNO_EXPAT
endif
git-%$X: %.o $(GITLIBS)
--
1.6.5.3
^ permalink raw reply related
* [PATCH/RFC 2/2] Makefile: automatically compute header dependencies
From: Jonathan Nieder @ 2009-11-27 17:50 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Johannes Sixt, Junio C Hamano, Git Mailing List
In-Reply-To: <20091127174558.GA3461@progeny.tock>
Use the gcc -MMD -MP -MF options to generate dependency rules as a
byproduct when building .o files.
A bit remains to be done:
- add the same support to the .c.s rule
- make this optional (not all compilers support this, and not all
developers necessarily want to litter the directory with .*.o.d
files)
- document what gcc version introduced these options
- find equivalent options for other compilers (e.g., Intel C,
SunWSPro, MSVC)
but this should give the idea.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Good idea? Bad idea?
Good night,
Jonathan
.gitignore | 1 +
Makefile | 15 ++++++++++++++-
2 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/.gitignore b/.gitignore
index ac02a58..c7b2736 100644
--- a/.gitignore
+++ b/.gitignore
@@ -170,6 +170,7 @@
*.exe
*.[aos]
*.py[co]
+.*.o.d
*+
/config.mak
/autom4te.cache
diff --git a/Makefile b/Makefile
index ed0f461..af3f874 100644
--- a/Makefile
+++ b/Makefile
@@ -488,6 +488,7 @@ LIB_H += unpack-trees.h
LIB_H += userdiff.h
LIB_H += utf8.h
LIB_H += wt-status.h
+LIB_H :=
LIB_OBJS += abspath.o
LIB_OBJS += advice.o
@@ -1559,13 +1560,23 @@ git.o git.spec \
$(patsubst %.perl,%,$(SCRIPT_PERL)) \
: GIT-VERSION-FILE
+dep_file = $(dir $@).$(notdir $@).d
+dep_args = -MF $(dep_file) -MMD -MP
+
%.o: %.c GIT-CFLAGS
- $(QUIET_CC)$(CC) -o $*.o -c $(ALL_CFLAGS) $<
+ $(QUIET_CC)$(CC) -o $*.o -c $(dep_args) $(ALL_CFLAGS) $<
%.s: %.c GIT-CFLAGS
$(QUIET_CC)$(CC) -S $(ALL_CFLAGS) $<
%.o: %.S
$(QUIET_CC)$(CC) -o $*.o -c $(ALL_CFLAGS) $<
+objects := $(wildcard *.o block-sha1/*.o arm/*.o ppc/*.o \
+ compat/*.o compat/*/*.o xdiff/*.o)
+dep_files := $(wildcard $(foreach f,$(objects),$(dir $f).$(notdir $f).d))
+ifneq ($(dep_files),)
+include $(dep_files)
+endif
+
exec_cmd.o: exec_cmd.c GIT-CFLAGS
exec_cmd.o: ALL_CFLAGS += \
'-DGIT_EXEC_PATH="$(gitexecdir_SQ)"' \
@@ -1875,6 +1886,8 @@ distclean: clean
clean:
$(RM) *.o block-sha1/*.o arm/*.o ppc/*.o compat/*.o compat/*/*.o xdiff/*.o \
$(LIB_FILE) $(XDIFF_LIB)
+ $(RM) .*.o.d block-sha1/.*.o.d arm/.*.o.d ppc/.*.o.d compat/.*.o.d \
+ compat/*/.*.o.d xdiff/.*.o.d
$(RM) $(ALL_PROGRAMS) $(BUILT_INS) git$X
$(RM) $(TEST_PROGRAMS)
$(RM) *.spec *.pyc *.pyo */*.pyc */*.pyo common-cmds.h TAGS tags cscope*
--
1.6.5.3
^ permalink raw reply related
* Re: [PATCH] grep: --full-tree
From: Jeff King @ 2009-11-27 18:02 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: James Pickens, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0911271144230.4521@intel-tinevez-2-302>
On Fri, Nov 27, 2009 at 11:53:42AM +0100, Johannes Schindelin wrote:
> > If only somebody had written a "pager.status" configuration variable,
> > you could use that. Oh wait. I did. And it shipped in v1.6.0.
>
> And it makes things inconsistent. That is why I do not use it.
Then you can not use this configuration variable, too. Has the existence
of pager.status, since you do not use it, been a problem for you so far?
> Do you work on 10 different computers? I do. And nothing is more
> unnerving than the same command producing something different on the
> different computers.
Yes, as a matter of fact, I do work on 10 different computers. I'm sorry
that you find managing your configuration so challenging. But if you
don't use the configuration variable, then your own personal setup is
totally irrelevant.
If your argument is that this lack of consistency will irritate users,
you need to show that:
1. There are users who switch between a large number of setups, but
will not apply config consistently.
2. Some of these setups will be using the new config option.
If they are all controlled by a single user, how is that user any worse
off for the config option existing? They can choose not to use it if
the hassle is not worth it. I do not think the existence of an option is
giving too much rope to these users.
If you are talking about 10 machines, all controlled by different users,
whose terminals you have to sit down on to help them, then yes, it will
be inconvenient for you. But if users are setting up configuration for
these machines, shouldn't _their_ convenience in using configuration
trump _your_ convenience for occasionally sitting down and helping them?
> I, for one, do not like Git's reputation, but I am tired of trying to
> fight for the users. BTW quick question: how many Git _users_ were at the
> GitTogether at MV? 0?
In my opinion, you are actively fighting _against_ a user in this case.
And the GitTogether had a "users complain about git, and we try to
listen" session. There were two google users in person, but we also went
through a list of pre-made questions from other googlers. This issue
wasn't discussed, though. Nor was the question of consistency between
configurations, to my recollection. I think Shawn may have taken notes,
and could be more specific.
> > http://article.gmane.org/gmane.comp.version-control.git/133672
>
> I only skimmed it, yes. And I did not plan to participate in this thread.
> But it seems that my views are not represented enough, even if gitzilla
> chimed in with the very valid, under-acknowledged and over-ignored
> message: consistency is good. Corollary: inconsistency is bad.
That is an over-simplification. Inconsistency between setups is bad. But
so is inconsistency between git commands, and between git and other
commands. So is not supporting a user's workflow, or supporting it in a
way that is tedious and error-prone. You have to weigh the badness of
those things against each other in finding a solution.
But then, that was the point I already made in the article linked above.
-Peff
^ permalink raw reply
* Re: Breaking expectations in 1.7.0, was Re: What's cooking in git.git (Nov 2009, #06; Wed, 25)
From: Jonathan Nieder @ 2009-11-27 18:32 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Jeff King
In-Reply-To: <20091127153349.GA24647@progeny.tock>
Hi again,
I wrote:
> I was trained by 1.6.0 and 1.5.0, I guess.
This misses the point. The big difference is that 1.7.0 is not that far
away, so it is not the time to tack on world-shaking changes.
So please substitute 1.8.0 or 1.9.0 for 1.7.0 in my message to Peff.
The point doesn’t change, though, which is that I think it makes no
sense to add a configuration variable for this before changing the
default.
Thanks for the clarification,
Jonathan
^ permalink raw reply
* Re: [PATCH] Makefile: determine the list of header files using a glob
From: Junio C Hamano @ 2009-11-27 18:28 UTC (permalink / raw)
To: Mike Hommey; +Cc: Johannes Sixt, Git Mailing List
In-Reply-To: <20091127085802.GA21217@glandium.org>
Mike Hommey <mh@glandium.org> writes:
> On Fri, Nov 27, 2009 at 09:50:47AM +0100, Johannes Sixt wrote:
>> Mike Hommey schrieb:
>> > I don't know if the current Makefile works with Solaris' make,...
>>
>> No, it doesn't. You have to use GNU make anyway.
>
> Then it's fine. But shouldn't that be noted somewhere, like in the
> INSTALL file ?
Surely. Please make it so.
^ permalink raw reply
* Re: [PATCH] Makefile: determine the list of header files using a glob
From: Junio C Hamano @ 2009-11-27 18:28 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Johannes Sixt, Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0911271033460.4521@intel-tinevez-2-302>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> Sidestep the issue by computing the list using $(wildcard).
>
> Funny; I thought that not all header files are library header files, i.e.
> not all header changes should trigger a full new build of libgit.a.
>
> Am I wrong?
You are right.
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2009, #06; Wed, 25)
From: Junio C Hamano @ 2009-11-27 18:29 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Jeff King, git
In-Reply-To: <20091127144553.GA24366@progeny.tock>
Jonathan Nieder <jrnieder@gmail.com> writes:
>> I can try to pick this up. But did we reach a decision on having a
>> configuration variable?
>
> I am not sure, but I will say I would prefer not to have one. Surely
> we can come up with a UI that does not require searching through
> git-config(1) to be made convenient.
>
> Couldn’t we just add the option (with test and documentation) first,
> to get some experience with how we end up using the two forms?
>
> If --full-tree does become the default, I think it should be in 1.7.0,
> when it is expected for some habits to break (with a configuration
> variable for the transition, I guess). This might be okay, since
> constructions like 'git grep foo -- "./*.h"' should still work.
The flipping of "grep" default is too late for 1.7.0, as we have only
started discussing it, and I want the release after 1.6.6 to be 1.7.0.
I do not think we want nor need to have other things we have already
prepared and have been advertising for 1.7.0 to wait one more cycle.
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Junio C Hamano @ 2009-11-27 18:29 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, James Pickens, git
In-Reply-To: <20091127095914.GA4865@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Fri, Nov 27, 2009 at 10:31:30AM +0100, Johannes Schindelin wrote:
>
>> Guess what. I have a similar problem, only it is that my "git status"
>> output is _always_ too long, so I always have to page it.
>>
>> Once upon a time, Junio applied a patch that implied -p with status. I
>> was overjoyed. He reverted that patch later. Yes, exactly.
It would have been more fair to me if Dscho said "He had to revert", to
hint that it was not due to me changing the preference left and right on a
whim.
>> So I end up doing "git config --global ps '-p status'" on every new
>
> If only somebody had written a "pager.status" configuration variable,
> you could use that. Oh wait. I did. And it shipped in v1.6.0.
Nice try but, "grep" and "status" are apples and oranges comparision.
A "status" command that pages or does not page the output only when
spitting out to a terminal won't hurt somebody who helps another with the
configuration set differently, as much as a "grep" that shows or not shows
matches from other parts of the tree would, and when used by a script to
make a decision based on the output, the caller has to capture the output
first, and unless the caller drives "status" via pty, e.g. using "expect",
paging behaviour will be disabled no matter what the configuration setting
is.
So neither "it would hurt people who help others" nor "it would hurt
scripts" would apply to "status". But both would apply to "grep".
>> The further benefit is that we stop talking about breaking backwards
>> compatibility, and we stop talking about making it hard for Git experts to
>> help newbies.
>
> I guess you missed the part of the thread where I already discussed
> this. It was here:
>
> http://article.gmane.org/gmane.comp.version-control.git/133672
This was a very good summary, and was one of the reasons that made me
reconsider placing too much weight on "it would hurt people who help
others" (but not on "it would hurt scripts").
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Junio C Hamano @ 2009-11-27 18:29 UTC (permalink / raw)
To: Uri Okrent; +Cc: Johannes Schindelin, Jeff King, James Pickens, git
In-Reply-To: <6839293b0911270827x54947c64q5f93e37664bc20f3@mail.gmail.com>
Uri Okrent <uokrent@gmail.com> writes:
> The key once again, is managing expectations. We can't go around
> changing everything willy-nilly, and we can't be continually changing
> things. Here is where we could take a lesson from the python
> community.
>
> When they decided they needed to change things, they bundled a
> bunch of backwards incompatible changes together and went for it.
> Yes, Python 3 will break your scripts, but the most important thing is,
> everybody knows it.
>
> A similar thing was done here with the huge warning that push spits
> out, but in the general case I would argue, that the wisest course is to
> save backwards incompatible changes for a git 2 or something, where
> we know we're breaking the world, and then scratch all our (well thought
> out) backwards incompatible itches at once.
You preach to the choir.
That is exactly how we work and what people have been working hard for
1.7.0. Check the planned changes listed in the recent (and not so recent)
"What's cooking" summary reports.
Changing "grep" is too late for 1.7.0, but we are trying to find an easy
migration path like you mentioned in your message and that is exactly what
this thread is about.
^ permalink raw reply
* Re: [RFC/PATCH] gitweb: Make linking to actions requiring JavaScript a feature
From: Junio C Hamano @ 2009-11-27 18:29 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Stephen Boyd, git, Martin Koegler
In-Reply-To: <200911271641.40947.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Would turning
>
> "blame"
>
> link ito pair of links
>
> "blame (incremental)"
>
> be a good solution? I'm trying to come up with good naming for extra link
> to 'blame_incremental' action...
I had to step back a bit and ask myself what we are trying to achieve
here. When the current blame and incremental one are both working
perfectly and well, will there be a reason for the end users to choose
between them when they click?
My answer is no. If the incremental one gives nicer user experience in
all cases, it will be shown without the non-incremental one; if the
incremental one makes the server or network load too heavy, a site owner
may decide to show only the non-incremental one.
That makes my addLinks suggestion a change that would help _only_ while we
are working kinks out of the incremental one.
Let's not waste too much effort doing that. Sorry for suggesting.
Letting the site owner choose if the site wants to set the "incremental if
possible" boolean would be more than adequate, I think.
^ permalink raw reply
* Re: OS X and umlauts in file names
From: Thomas Singer @ 2009-11-27 18:35 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Jay Soffian, Daniel Barkalow, git
In-Reply-To: <46a038f90911270256w57487e6cq9bda8b98a5384799@mail.gmail.com>
Martin Langhoff wrote:
> have you tried calling git-update-index --add
> --stdin -z? Your original email stated
No, we don't do such a massive change immediately before a release.
>> we've got a problem report regarding our SmartGit GUI client
>
> so it sounds like you are building a porcelain. In that case, the
> sanest approach is to invoke git-update-index and write to its stdin.
We will try this out after release.
For those who are interested: I've got it working on OS X and Git was not
the problem, but Java. A longer time ago directory.list() or
directory.listFiles() returned the file names with decomposed characters (as
they are stored on OS X hard disk). Now (don't know which Java update
introduced this change) these methods return file names with composed
characters, so I had to decompose them before handing them to the git
executable call.
Nevertheless, the cross-platform-problem remains: if you add files with
umlauts in their names on non-OS X, you will not be able to use them on OS X.
--
Tom
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2009, #06; Wed, 25)
From: Jonathan Nieder @ 2009-11-27 18:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7vvdgvn7ny.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> The flipping of "grep" default is too late for 1.7.0, as we have only
> started discussing it, and I want the release after 1.6.6 to be 1.7.0.
Yes, I’m sorry I suggested it. I think you had mentioned this plan
before, but somehow it escaped my mind.
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Uri Okrent @ 2009-11-27 18:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Jeff King, James Pickens, git
In-Reply-To: <7vk4xbn7nl.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> You preach to the choir.
>
> That is exactly how we work and what people have been working hard for
> 1.7.0. Check the planned changes listed in the recent (and not so recent)
> "What's cooking" summary reports.
Yes, I guess my only point here was that maybe even 1.7 is not enough of
a "Big Deal" (in the eyes of the public) to warrant breaking scripts. A
2.0 version would be a more visible way to say "Hey test your scripts
before upgrading". Adopting a strategy like that would mean making
backwards incompatible changes a lot let frequently, but when we do we
go for broke.
> Changing "grep" is too late for 1.7.0, but we are trying to find an easy
> migration path like you mentioned in your message and that is exactly what
> this thread is about.
I wasn't actually suggesting we change grep for 1.7. As a matter of
fact, my personal opinion (which I probably neglected to mention) is
that grep default behavior should stay the same since it is semantically
closer to unix (or gnu) grep.
--
Uri
Please consider the environment before printing this message.
http://www.panda.org/how_you_can_help/
^ permalink raw reply
* Re: [msysGit] [PATCH/RFC 03/11] mingw: implement syslog
From: Johannes Sixt @ 2009-11-27 19:23 UTC (permalink / raw)
To: kusmabite; +Cc: msysgit, git, dotzenlabs
In-Reply-To: <40aa078e0911270009u7569cfe5gb250092c8d2c0eac@mail.gmail.com>
On Freitag, 27. November 2009, Erik Faye-Lund wrote:
> On Thu, Nov 26, 2009 at 10:23 PM, Johannes Sixt <j6t@kdbg.org> wrote:
> > I would
> >
> > const char* arg;
> > if (strcmp(fmt, "%s"))
> > die("format string of syslog() not implemented")
> > va_start(va, fmt);
> > arg = va_arg(va, char*);
> > va_end(va);
> >
> > because we have exactly one invocation of syslog(), which passes "%s" as
> > format string. Then strbuf_vaddf is not needed. Or even simpler: declare
> > the function as
> >
> > void syslog(int priority, const char *fmt, const char*arg);
>
> After reading this again, I agree that this is the best solution. I'll
> update for the next iteration.
Except that you shouldn't die like I proposed because here we are already in
the die_routine, no?
> > "Note that the string that you log cannot contain %n, where n is an
> > integer value (for example, %1) because the event viewer treats it as an
> > insertion string. ..."
> >
> > How are the chances that this condition applies to our use of the
> > function?
>
> Ugh, increasingly high since we're adding IPv6 support, I guess.
> Perhaps some form of escaping needs to be done?
I think so, but actually I have no clue.
-- Hannes
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2009, #06; Wed, 25)
From: Daniel Barkalow @ 2009-11-27 19:17 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Junio C Hamano, Johan Herland, git
In-Reply-To: <fabb9a1e0911251715u661ce0aem79a4d700d552e105@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1055 bytes --]
On Thu, 26 Nov 2009, Sverre Rabbelier wrote:
> Heya,
>
> On Thu, Nov 26, 2009 at 02:03, Junio C Hamano <gitster@pobox.com> wrote:
> > * sr/vcs-helper (2009-11-18) 12 commits
> > - Add Python support library for remote helpers
> > - Basic build infrastructure for Python scripts
> > - Allow helpers to report in "list" command that the ref is unchanged
> > - Fix various memory leaks in transport-helper.c
> > - Allow helper to map private ref names into normal names
> > - Add support for "import" helper command
> > - Allow specifying the remote helper in the url
> > - Add a config option for remotes to specify a foreign vcs
> > - Allow fetch to modify refs
> > - Use a function to determine whether a remote is valid
> > - Allow programs to not depend on remotes having urls
> > - Fix memory leak in helper method for disconnect
> >
> > Replaced again, and looking good. Perhaps Daniel has some comments?
>
> Indeed, Johan, Daniel, is the current version good for next?
Looks good to me.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* gitk: how to display history w/o a certain remote?
From: Dirk Süsserott @ 2009-11-27 19:52 UTC (permalink / raw)
To: Git Mailing List
Hi list,
next to those cute little spherules, gitk shows the labels of the
corresponding tags and branches, e.g. "master", "remotes/XXX/master",
and "remotes/YYY/master". Most of the time, I like that. :-)
"git log [...] --decorate" does it alike.
Sometimes I have many remotes and the actual commit message is far
beyond my screen because of the many labels.
Is there a way to prevent gitk/git-log from displaying certain remotes?
I tried the "--not" switch but that didn't work. At least for my arguments.
AHA,
Dirk
^ permalink raw reply
* Re: [msysGit] [PATCH/RFC 06/11] run-command: add kill_async() and is_async_alive()
From: Johannes Sixt @ 2009-11-27 19:59 UTC (permalink / raw)
To: kusmabite; +Cc: msysgit, git, dotzenlabs
In-Reply-To: <40aa078e0911270804i1a828ea6we1611047d37869f7@mail.gmail.com>
On Freitag, 27. November 2009, Erik Faye-Lund wrote:
> Do you really think it's better to unconditionally take down the
> entire process with an error, instead of having a relatively small
> chance of stuff blowing up without any sensible error? I'm not 100%
> convinced - but let's hope we'll find a proper fix.
"relatively small chance of stuff blowing up"? The docs of
TerminateThread: "... the kernel32 state for the thread's process could be
inconsistent." That's scary if we are talking about a process that should run
for days or weeks without interruption.
The reason why we are killing a thread is to prevent keeping lots of
connections open (to the same IP address). There are two situations to take
care of:
1. We are in a lengthy computation without paying attention to the socket.
2. The client does not send or accept data for a long time.
Case 1 could happen if upload-pack is "counting objects" on a large
repository. We would need some way to kill upload-pack. Since it is a
separate process anyway, we could use TerminateProcess().
Case 2 could be achieved by using setsockopt() with SO_RCVTIMEO and
SO_SNDTIMEO and a tiny timeout. But notice that we would set a timeout in one
thread while another thread is waiting in ReadFile() or WriteFile(). Would
that work?
-- Hannes
^ permalink raw reply
* Re: [PATCH] git-am: don't ignore --keep (-k) option
From: Junio C Hamano @ 2009-11-27 20:03 UTC (permalink / raw)
To: Jim Meyering; +Cc: git list
In-Reply-To: <87638zm38r.fsf_-_@meyering.net>
Jim Meyering <jim@meyering.net> writes:
> I started looking at git-am.sh and spotted what appears to be a typo.
> There is only that one use of $keep_subject, so its value currently
> comes from the environment.
>
> From 02f7e6433b5db8b18a4cccf58c302159c2f54fa5 Mon Sep 17 00:00:00 2001
> From: Jim Meyering <meyering@redhat.com>
> Date: Wed, 25 Nov 2009 09:10:46 +0100
> Subject: [PATCH] git-am: don't ignore --keep (-k) option
>
> Fix typo in variable name: s/keep_subject/keep/.
>
> Signed-off-by: Jim Meyering <meyering@redhat.com>
At the level of "what does each line of the code do", this is a fix, but
as we do a lot more than just stripping "[PATCH] " from the beginning of
the Subject: line these days, I think we are better off declaring defeat
in this particular codepath and not doing anything here.
Adding "[PATCH] " is no longer "keeping the original subject" anyway. It
is "without knowing what we already stripped, adding one random string
that could have been what we removed".
I also have to wonder why $dotest/info does not have the [PATCH] or
whatever prefix that we were told not to strip in this codepath. After
all, we are running "git mailinfo" with $keep option to produce that file,
so if that part is working correctly, we shouldn't even have to have this
"add [PATCH] back" trick to begin with.
What am I missing???
> ---
> git-am.sh | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/git-am.sh b/git-am.sh
> index 151512a..f353e73 100755
> --- a/git-am.sh
> +++ b/git-am.sh
> @@ -578,7 +578,7 @@ do
> sed -e '1,/^$/d' >"$dotest/msg-clean"
> else
> SUBJECT="$(sed -n '/^Subject/ s/Subject: //p' "$dotest/info")"
> - case "$keep_subject" in -k) SUBJECT="[PATCH] $SUBJECT" ;; esac
> + case "$keep" in -k) SUBJECT="[PATCH] $SUBJECT" ;; esac
>
> (printf '%s\n\n' "$SUBJECT"; cat "$dotest/msg") |
> git stripspace > "$dotest/msg-clean"
> --
> 1.6.6.rc0.236.ge0b94
^ 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