* Re: [RFC] Colorize 'commit' lines in log ui
From: Jeff King @ 2006-07-23 22:01 UTC (permalink / raw)
To: Jan-Benedict Glaw; +Cc: git, Junio C Hamano
In-Reply-To: <20060723112422.GB27825@lug-owl.de>
On Sun, Jul 23, 2006 at 01:24:22PM +0200, Jan-Benedict Glaw wrote:
> If people only were used to *always* place a comma behind the last
> array element, the diff would be shorter by one line each time...
I agree that it's much more convenient; I left it off because it wasn't
there before and I thought there were some standardization issues.
As it turns out, the situation is quite ridiculous. C89 allowed trailing
commas in initialization lists but not in enums. Most compilers (gcc,
sun) accepted it anyway, but some (aix xlc) did not.
Do we care? I think probably not, since the color_diff enum already had
a trailing comma. It seems like the primary non-gcc compiler that has
been mentioned is sun cc. I don't know what other compilers are being
used to compile git.
-Peff
^ permalink raw reply
* Re: Git BOF notes
From: Johannes Schindelin @ 2006-07-23 22:53 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060722191652.GR13776@pasky.or.cz>
Hi,
On Sat, 22 Jul 2006, Petr Baudis wrote:
> Dear diary, on Sat, Jul 22, 2006 at 05:55:59AM CEST, I got a letter
> where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> > On Sat, 22 Jul 2006, Petr Baudis wrote:
> > > Dear diary, on Sat, Jul 22, 2006 at 02:17:48AM CEST, I got a letter
> > > where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> > > > And also think "setup a remote repository", especially "setup a remote
> > > > HTTP repository".
> > >
> > > Of course. Currently you need to tinker with environment variables,
> > > then with hooks, possibly with permissions and stuff to make the
> > > repository shared... Think cg-admin-setuprepo. ;-)
> >
> > git-init-db --shared
>
> And the environment variable and the chgrp and g+s. That's my point.
I do not have the itch. But of course, it would be trivial to do that as
command line options.
> > And sometimes, I do "cp -R /some/where/CVS ./; git-cvsimport".
>
> git-cvsimport will create the repository for you, won't it?
It could, if I'd let it ;-)
> > > Of course sometimes you don't want to add everything, and that should
> > > still be possible to do (cg-init has a switch for that).
> >
> > Usually I start small projects as a single .c or .java file. Only after a
> > while, I think it is worth it to init a git database. So, I _always_ have
> > generated files lying around. And I would hate it if they were checked in
> > automatically. (Yeah, I could remove them, _then_ remove them from the
> > index, and then git-commit --amend. Ugly.)
>
> Can't you just do make clean before git init? Or you can prepare
> .gitignore before you check stuff in, so that the autogenerated files
> don't pollute your git status output. ;-)
Yes, I can. I also can type in several sheets of hex data. But I don't
want to. Like Timo, I am very happy to tell the computer what to do, not
to let it take guesses.
Ciao,
Dscho
^ permalink raw reply
* Better Future, wet nurse
From: Erick Daniels @ 2006-07-24 3:35 UTC (permalink / raw)
To: git
Your cre dit doesn't matter to us! If you OWN real est ate
and want IMMEDIATEZ cash to spend ANY way you like, or simply wish
to LOWER your monthly paym ents by a third or more, here are the dea ls
we have TODAY (hurry, these ofers will expre TONIGHT):
$488,000.00 at a 3.67,% fixed-rate0
$372,000.00 at a 3.90,% variable-rateG
$492,000.00 at a 3.21,% interest-onlyZ
$248,000.00 at a 3.36,% fixed-rateZ
$198,000.00 at a 3.55,% variable-rateS
Hurry, when these deals are gone, they are gone Simply fill out this one-min ute form...
Don't worry about approval, your cre dit will not disqualify you!
http://2I2BXYKB.fortessed.com
sip, shut his eyes, and handed the flask to Arthur. That's it, he thought
because of him. Now that my head is clear, I know why. It was right to save
workers showed up here for the moulage. There were two lab assistants, both
gummed his mouth, making it hard to breathe. Gulping for air, Redrick tore
engineer he had drowned in vitriol that day.
hill except the intense sunlight, but on the right slope, in the shade, pale
"Phoo-oo-ey." He shook his head, scattering dirty drops of water.
swamp to the right of the embankment reeked of decay. The fog made it
of the )i. The name was sort of familiar, but who Whip was exactly, and what
but confidence in a miracle --filled him to the brim, and he was amazed at
you lift the bag with rocks and guide it over the ground, it was all clear
^ permalink raw reply
* Re: Makefile checks for DarwinPorts / Fink
From: Shawn Pearce @ 2006-07-24 4:28 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e9vrsf$foc$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> wrote:
> Could you _please_ document this option in commentary part in main
> Makefile?
OK.
I left them out originally as it seemed like other platform specific
items weren't in the main commentary part, but since these are
new defines I guess it makes perfect sense that they should be
documented before they get included into the main Makefile. :-)
Hopefully this is the final version of this patch...
-->8--
Disable linking with Fink or DarwinPorts.
It may be desirable for the compiler to disable linking against Fink
or DarwinPorts, especially if both are installed on the system and
the user wants GIT to be linked specifically to only one of them.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
Makefile | 30 ++++++++++++++++++++++--------
1 files changed, 22 insertions(+), 8 deletions(-)
diff --git a/Makefile b/Makefile
index a1666e2..5432636 100644
--- a/Makefile
+++ b/Makefile
@@ -32,6 +32,18 @@ # Define NO_SVN_TESTS if you want to ski
# tests. These tests take up a significant amount of the total test time
# but are not needed unless you plan to talk to SVN repos.
#
+# Define NO_FINK if you are building on Darwin/Mac OS X, have Fink
+# installed in /sw, but don't want GIT to link against any libraries
+# installed there. If defined you may specify your own (or Fink's)
+# include directories and library directories by defining CFLAGS
+# and LDFLAGS appropriately.
+#
+# Define NO_DARWIN_PORTS if you are building on Darwin/Mac OS X,
+# have DarwinPorts installed in /opt/local, but don't want GIT to
+# link against any libraries installed there. If defined you may
+# specify your own (or DarwinPort's) include directories and
+# library directories by defining CFLAGS and LDFLAGS appropriately.
+#
# Define PPC_SHA1 environment variable when running make to make use of
# a bundled SHA1 routine optimized for PowerPC.
#
@@ -267,15 +279,17 @@ ifeq ($(uname_S),Darwin)
NEEDS_SSL_WITH_CRYPTO = YesPlease
NEEDS_LIBICONV = YesPlease
NO_STRLCPY = YesPlease
- ## fink
- ifeq ($(shell test -d /sw/lib && echo y),y)
- BASIC_CFLAGS += -I/sw/include
- BASIC_LDFLAGS += -L/sw/lib
+ ifndef NO_FINK
+ ifeq ($(shell test -d /sw/lib && echo y),y)
+ BASIC_CFLAGS += -I/sw/include
+ BASIC_LDFLAGS += -L/sw/lib
+ endif
endif
- ## darwinports
- ifeq ($(shell test -d /opt/local/lib && echo y),y)
- BASIC_CFLAGS += -I/opt/local/include
- BASIC_LDFLAGS += -L/opt/local/lib
+ ifndef NO_DARWIN_PORTS
+ ifeq ($(shell test -d /opt/local/lib && echo y),y)
+ BASIC_CFLAGS += -I/opt/local/include
+ BASIC_LDFLAGS += -L/opt/local/lib
+ endif
endif
endif
ifeq ($(uname_S),SunOS)
--
1.4.2.rc1.ge711
^ permalink raw reply related
* Re: [PATCH 1/2] add git-quote: shell and C quoting tool
From: Junio C Hamano @ 2006-07-24 5:49 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20060716222757.GA10135@steel.home>
fork0@t-online.de (Alex Riesen) writes:
> In case anyone asks why isn't it a standalone tool nor is it put into
> git-stripspace: I don't know. Maybe it should be.
This organization is fine by me.
* unquote?
* doc?
> +enum {SHELL_QUOTE, C_QUOTE};
> +static int style = SHELL_QUOTE,
> + use_stdin = 0;
Shouldn't style be of type which is that unnamed enum?
> +static const char *separator = NULL; /* default is space */
> +static unsigned sep_len = 0;
It is not clear if this is separator of input side or output
side (after reading the code it becomes somewhat obvious that
you are talking about output separator), and if the default is
space wouldn't it make more sense to set that here?
> +static const char builtin_quote_usage[] =
> +"git-quote [--c] [--sep=<c-quoted> | -z] ( [--stdin] | [--] ... )";
> +
> +static void print_quoted(const char *text)
> +{
> + switch (style)
> + {
> + case SHELL_QUOTE:
> + sq_quote_print(stdout, text);
> + break;
> + case C_QUOTE:
> + quote_c_style(text, NULL, stdout, 0);
> + break;
> + }
Not a big deal but aren't these going to write out things quoted
when they do not need to? To help scripts, it might be worth
adding "check if this needs quoting" interface perhaps?
> +int cmd_quote(int argc, const char **argv, char **envp)
> +{
> + int i;
> + for (i = 1; i < argc; i++) {
> + const char *arg = argv[i];
> +
> + if (arg[0] != '-')
> + break;
> + if (!strcmp(arg, "--")) {
> + i++;
> + break;
> + }
> + if (!strcmp(arg, "--stdin")) {
> + use_stdin = 1;
> + if ( !separator ) {
> + separator = "\n";
> + sep_len = 1;
> + }
> + break;
> + }
> + if (!strcmp(arg, "--c")) {
Perhaps "--c-style" with "-c" as a shorthand, (and
"--shell-style" with "-s" to complement)?
> + style = C_QUOTE;
> + continue;
> + }
> + if (!strcmp(arg, "-z")) {
> + separator = "";
> + sep_len = 1;
> + continue;
> + }
Is it plausible that somebody might want to feed you NUL
terminated sequence as input (iow you might want to give them
choice of separator on the input side)?
> + if (!strncmp(arg, "--sep=", 6)) {
Perhaps "--separator" (or "--output-separator") with whatever
shorthand is handy?
> + const char *end;
> + char *tmp;
> + arg += 6;
> + if ('"' == *arg)
> + tmp = strdup(arg);
> + else {
> + size_t l = strlen(arg);
> + tmp = malloc(l + 3);
> + sprintf(tmp, "\"%s\"", arg);
> + }
> + separator = unquote_c_style(tmp, &end);
> + sep_len = strlen(separator);
If the parameter is a malformed c-quoted string, you would dump
core here.
> + /* this will leak if multiple --sep= given */
> + continue;
> + }
> + die(builtin_quote_usage);
> + }
> + if (!separator) {
> + sep_len = 1;
> + separator = "\x20";
Any reason you needed to spell it in hex? Is this trying to
be portable to EBCDIC (or trying to prevent the code to be
ported there)? I dunno.
> + }
> + if (use_stdin) {
> + size_t size = BUFSIZ;
> + char *buf = xmalloc(size);
> + int ch, pos = 0;
> + while (EOF != (ch = fgetc(stdin))) {
> + if (pos == size)
> + buf = xrealloc(buf, size <<= 1);
> + buf[pos++] = ch;
> + if ('\n' == ch) {
> + buf[--pos] = '\0';
> + pos = 0;
> + print_quoted(buf);
> + }
> + }
Looks similar to strbuf.c::read_line() loop...
^ permalink raw reply
* Re: print errors from git-update-ref
From: Junio C Hamano @ 2006-07-24 6:06 UTC (permalink / raw)
To: Alex Riesen; +Cc: Git Mailing List
In-Reply-To: <81b0412b0607180613t603551b8t865b407c40ab8aef@mail.gmail.com>
"Alex Riesen" <raa.lkml@gmail.com> writes:
> ...otherwise it not clear what happened when update-ref fails.
>
> E.g., git checkout -b a/b/c HEAD would print nothing if refs/heads/a
> exists and is a directory (it does return 1, so scripts checking for
> return code should be ok).
>
> I'm attaching two patches, because I'm not quite sure where it should
> be done: git-checkout is the least intrusive, but only builtin-update-ref.c
> has enough info to help user to resolve the problem (errno is ENOTDIR,
> which is selfexplanatory). And I happen to use git-update-ref directly
> sometimes.
My gut feeling is that complaining from update-ref is fine, but
I am still tired after a long week and not thinking straight, so
I will not be applying this tonight.
git-applypatch, git-am, and git-branch would be helped by
update-ref complaining.
Porcelains?
BTW, I wonder what happens when .git/logs/refs/a is a directory
(by mistake or malice), .git/refs/a does not exist, and the user
does "git checkout -b a/b/c HEAD". Or when .git/logs/refs/a/b/c
does exist but is not writable. My preference is just warn but
do not interrupt the primary operation, since ref-log is just an
optional part of the system, but that would probably lead to
confusion, so we might be better off erroring the caller out in
such a case. Opinions?
git-resolve does not check exit value from update-ref, which is
*BAD*, but we should be deprecating it anyway.
git-reset has the same problem of not checking the exit status
from update ref. Worse yet, it calls update-ref with wrong
parameter ($@ in its parameter should be $*).
Patches to fix these two and half problems should be trivial but
I won't be doing that myself tonight.
^ permalink raw reply
* Re: [PATCH] upload-pack: fix timeout in create_pack_file
From: Junio C Hamano @ 2006-07-24 6:23 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: git
In-Reply-To: <E1G2t9n-0005PW-72@moooo.ath.cx>
Matthias Lederhofer <matled@gmx.net> writes:
> Signed-off-by: Matthias Lederhofer <matled@gmx.net>
> ---
> <yacc> fatal: packfile '../linux-2.6/.git/objects/pack/tmp-7iPJo5'
> SHA1 mismatch
> <yacc> error: git-fetch-pack: unable to read from git-index-pack
> <yacc> error: git-index-pack died with error code 128
> <yacc> Any idea what this means?
> This happens after ~12 minutes. The problem is that the loop in
> upload-pack.c actually sending the pack does not reset the timeout.
> I'd guess --timeout is 600 or a bit more on git.kernel.org :)
>
> This does not help for low timeouts with slow clients. If a client is
> slow enough so the server is blocked for more time than specified by
> timeout the connection will be closed too (e.g. 15kb/s with a timeout
> of 30 (git adds 10 extra) is not enough).
Where do we add 10 extra?
> We should either add a
> warning to the man page or try to fix this. I don't know if this can
> be fixed not using non-blocking sockets.
I think the intent of "timeout" was to protect us from funny
clients by avoiding talking with the ones that take too much
time doing something that should not take too long. When we are
in create_pack_file(), we are already committed to the heaviest
operation anyway, so one possibility might be to stop doing
timeout at that point. I am not sure if that is acceptable,
though -- it opens up the daemon to even easier DoS than it
currently is.
My gut feeling is that your patch would be fine as is (have you
tried and confirmed that it helps cases other than slow
clients?)
> Perhaps support for resume would be quite useful too but I've no idea
> how hard this is to implement.
That would be _very_ hard.
^ permalink raw reply
* Re: [PATCH] Allow an alias to start with "-p"
From: Junio C Hamano @ 2006-07-24 6:32 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, junkio
In-Reply-To: <Pine.LNX.4.63.0607190125150.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Now, something like
>
> [alias]
> pd = -p diff
>
> works as expected.
I like what it wants to do but I am afraid this leads to an
unmaintainable code (a micronit that already shows what I mean
is that you can say "git --paginate diff", but you cannot say
"pd = --paginate diff" in the configuration file).
Is there a cleaner way to do it without duplicating the argument
loop of git.c::main()?
^ permalink raw reply
* Re: [PATCH] Trivial path optimization test
From: Junio C Hamano @ 2006-07-24 6:41 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Linus Torvalds
In-Reply-To: <20060717223432.GA25522@steel.home>
Clean up the commit log pretty please.
^ permalink raw reply
* Re: [PATCH] cvsexportcommit - add -a (add author line) flag, cleanup warnings
From: Junio C Hamano @ 2006-07-24 6:41 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <11531893692075-git-send-email-martin@catalyst.net.nz>
Thanks.
^ permalink raw reply
* Re: [PATCH] Fix t4114 on cygwin
From: Junio C Hamano @ 2006-07-24 6:41 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0607181946090.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Thanks.
^ permalink raw reply
* Re: [PATCH] tar-tree: add the "tar.applyUmask" config option
From: Junio C Hamano @ 2006-07-24 6:42 UTC (permalink / raw)
To: Willy Tarreau, Rene Scharfe; +Cc: git
In-Reply-To: <44BF3B4A.5040109@lsrfire.ath.cx>
Thanks.
^ permalink raw reply
* Re: [PATCH] git-svn: fix fetching new directories copies when using SVN:: libs
From: Junio C Hamano @ 2006-07-24 6:42 UTC (permalink / raw)
To: Eric Wong; +Cc: Ben Williamson, git
In-Reply-To: <20060720084301.GA29440@localdomain>
Thanks.
^ permalink raw reply
* Re: [PATCH 4/4] git.el: Put the git customize group in the 'tools' parent group.
From: Junio C Hamano @ 2006-07-24 6:42 UTC (permalink / raw)
To: Alexandre Julliard; +Cc: git
In-Reply-To: <87u059g3lu.fsf@wine.dyndns.org>
Thanks for all four patches.
^ permalink raw reply
* Re: Makefile checks for DarwinPorts / Fink
From: Junio C Hamano @ 2006-07-24 6:43 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Jakub Narebski, git
In-Reply-To: <20060724042828.GB9066@spearce.org>
Thanks for the fix and doc.
^ permalink raw reply
* Re: [PATCH] pack-objects: check pack.window for default window size
From: Junio C Hamano @ 2006-07-24 6:43 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20060723055030.GA25790@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> For some repositories, deltas simply don't make sense. One can disable
> them for git-repack by adding --window, but git-push insists on making
> the deltas which can be very CPU-intensive for little benefit.
Makes sense. Will apply but with the above three lines as part
of the commit message.
^ permalink raw reply
* Re: [PATCH] show-branch: Fix another performance problem.
From: Junio C Hamano @ 2006-07-24 6:46 UTC (permalink / raw)
To: Alexandre Julliard; +Cc: git
In-Reply-To: <87mzb0fbw7.fsf@wine.dyndns.org>
Thanks.
^ permalink raw reply
* Re: [PATCH] support cover letter before commit log, using "+++"
From: Junio C Hamano @ 2006-07-24 6:54 UTC (permalink / raw)
To: Martin Waitz; +Cc: git
In-Reply-To: <20060723214524.GC20068@admingilde.org>
Martin Waitz <tali@admingilde.org> writes:
> We already have a "---" separator to end the commit log.
> But writing the cover letter after this separator looks strange.
> Now it is possible to put the cover letter and comments both before
> or after the commit log, as the author sees fit.
>
> Just put the commit log between lines starting with "+++" and "---".
>
> Signed-off-by: Martin Waitz <tali@admingilde.org>
I do not have problem with the implementation itself, but
* I always had an impression that cover letters are tolerated
not encouraged. In other words, as a good practice it would
be nice if necessary information is described in the commit
log messages themselves. Do we want to start encouraging the
cover letter with this patch?
* Has anybody ever used that "+++" as an auxiliary separator?
In other words, is it an established convention? If not,
would it be a good convention that we would want to establish
here?
^ permalink raw reply
* Re: [PATCH] support cover letter before commit log, using "+++"
From: Martin Waitz @ 2006-07-24 7:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wsbfq75.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 1921 bytes --]
hoi :)
On Sun, Jul 23, 2006 at 11:54:22PM -0700, Junio C Hamano wrote:
> Martin Waitz <tali@admingilde.org> writes:
>
> > We already have a "---" separator to end the commit log.
> > But writing the cover letter after this separator looks strange.
> > Now it is possible to put the cover letter and comments both before
> > or after the commit log, as the author sees fit.
> >
> > Just put the commit log between lines starting with "+++" and "---".
> >
> > Signed-off-by: Martin Waitz <tali@admingilde.org>
>
> I do not have problem with the implementation itself, but
>
> * I always had an impression that cover letters are tolerated
> not encouraged. In other words, as a good practice it would
> be nice if necessary information is described in the commit
> log messages themselves. Do we want to start encouraging the
> cover letter with this patch?
that's right, but:
* before using automatic tools to generate mails from patches people
started their mails with "hello" or something similiar.
As these lines are frowned upon in the changelog people just stop
being polite.
* I have often seen patches evolving in an email thread.
With such an separator it is possible to keep the thread history
in one part and a clean change message in another part.
I don't really know if this +++ thing will be used much. It's just
something that I thought might be missing and it was easy to do ;-)
> * Has anybody ever used that "+++" as an auxiliary separator?
> In other words, is it an established convention? If not,
> would it be a good convention that we would want to establish
> here?
I haven't seen the "+++" before here. People have used their own
"cut here" markers somethimes but I don't think their is an
established convention already.
The "+++" just felt good in combination with the "---" end marker.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC] Colorize 'commit' lines in log ui
From: Junio C Hamano @ 2006-07-24 7:06 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20060723092417.GA7547@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I think the visual cue makes the git-whatchanged -p output much easier
> to read.
Although I personally do not do much colors (instead I do
"/^commit [0-9a-f]*" under less), I think this makes sense and I
do not think of any obvious downside.
^ permalink raw reply
* Re: [PATCH] upload-pack: fix timeout in create_pack_file
From: Matthias Lederhofer @ 2006-07-24 7:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd5bvh67p.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> > This does not help for low timeouts with slow clients. If a client is
> > slow enough so the server is blocked for more time than specified by
> > timeout the connection will be closed too (e.g. 15kb/s with a timeout
> > of 30 (git adds 10 extra) is not enough).
>
> Where do we add 10 extra?
Oops, never mind, I misread the source.
> > We should either add a
> > warning to the man page or try to fix this. I don't know if this can
> > be fixed not using non-blocking sockets.
>
> I think the intent of "timeout" was to protect us from funny
> clients by avoiding talking with the ones that take too much
> time doing something that should not take too long. When we are
> in create_pack_file(), we are already committed to the heaviest
> operation anyway, so one possibility might be to stop doing
> timeout at that point. I am not sure if that is acceptable,
> though -- it opens up the daemon to even easier DoS than it
> currently is.
>
> My gut feeling is that your patch would be fine as is (have you
> tried and confirmed that it helps cases other than slow
> clients?)
What else? The problem solved by this patch is the missing
reset_timeout while downloading pack files and this affects all
clients that are too slow (cannot download the packfile within
--timeout seconds). I tried a server with --timeout=600 and a client
that cannot download the whole pack file in 10 minutes. Without the
patch the server closes the connection, with this patch it works.
Additionally I tried it with a client reading so slow that the server
was blocked for more than --timeout seconds, then the server closes
the connection too (this is more or less the DoS case).
> > Perhaps support for resume would be quite useful too but I've no idea
> > how hard this is to implement.
>
> That would be _very_ hard.
I don't know how much demand there is for resuming but there is always rsync
(at least on kernel.org and other repositories that need it can install it too)
to get the new objects with support for resuming.
^ permalink raw reply
* Re: [RFC/PATCH] Per branch properties for pull
From: Junio C Hamano @ 2006-07-24 7:31 UTC (permalink / raw)
To: Santi Béjar; +Cc: git
In-Reply-To: <87hd1b9fjq.fsf@gmail.com>
Santi Béjar <sbejar@gmail.com> writes:
> It extracts all the information for pull from the config file.
>
> If you have a config file as:
>
> [branch "master"]
> remote=origin
> merge=next #the remote name
> octopus=octopus
> twohead=recursive
>
> When doing a "git pull" without extra parameters in the master branch
> it will fetch the origin remote repository and will merge the next
> branch (the remote name).
>
> And you can also put the equivalent of the pull.{octopus,twohead}
> options for each branch.
>
> This only changes the behavour when these keys exist and when
> git-pull is used without extra parameters.
>
> Signed-off-by: Santi Béjar <sbejar@gmail.com>
I am in general in agreement with this line of thought and had
an impression that many on the list wanted to have per-branch
configuration. I am a bit too tired now so I'd just let you
know I am interested but would not apply it tonight.
Opinions? Comments? Anything missing or objectionable on
Santi's patch from the list?
^ permalink raw reply
* Re: Defaulting fetch to origin when set in the repo-config
From: Junio C Hamano @ 2006-07-24 7:31 UTC (permalink / raw)
To: Santi Béjar; +Cc: git
In-Reply-To: <87mzb1s11r.fsf@gmail.com>
Thanks.
^ permalink raw reply
* Re: [PATCH] upload-pack: fix timeout in create_pack_file
From: Junio C Hamano @ 2006-07-24 7:55 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: git
In-Reply-To: <E1G4uZw-0006vZ-VO@moooo.ath.cx>
Matthias Lederhofer <matled@gmx.net> writes:
> Junio C Hamano <junkio@cox.net> wrote:
>
>> My gut feeling is that your patch would be fine as is (have you
>> tried and confirmed that it helps cases other than slow
>> clients?)
> ... I tried a server with --timeout=600 and a client
> that cannot download the whole pack file in 10 minutes. Without the
> patch the server closes the connection, with this patch it works.
> Additionally I tried it with a client reading so slow that the server
> was blocked for more than --timeout seconds, then the server closes
> the connection too (this is more or less the DoS case).
Thanks, that's all I wanted to know. Let's have it.
^ permalink raw reply
* Re: Git BOF notes
From: Catalin Marinas @ 2006-07-24 9:06 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060719230155.GJ13776@pasky.or.cz>
Petr Baudis <pasky@suse.cz> wrote:
> a short summary of the Git BOF on OLS which finished just a short
> while ago. We got to hear how Len Brown is doing things and where Git
> gets in the way for him as well as interesting questions and comments
> from several other people. The main highlights as I feel them (mixed
> randomly with my personal blabbering) are that:
What I forgot to mention at the OLS - it would be useful for a more
wide-spread adoption of GIT to convince some of the source code
hosting sites (like sourceforge.net) to provide GIT support. For StGIT
I currently use an HTTP server but that's not the most efficient way.
--
Catalin
^ 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