* Re: Sporadic BSOD with msys git?
From: Peter Harris @ 2009-01-29 14:36 UTC (permalink / raw)
To: Mark Burton; +Cc: git
In-Reply-To: <20090129115442.6ce311f8@crow>
On Thu, Jan 29, 2009 at 6:54 AM, Mark Burton wrote:
>
> I occasionally have to use Windows (XP under VMWare) and thought I would try
> out msysgit so I installed the recent version (1.6.1). For what I was
> wanting to use it for, it worked OK.
>
> However, I then started getting crashes when using the Windows explorer. I would
> click on a folder to look at its contents and, whammo, Windows would crash. It
> just happened every now and again, not all the time.
msysgit does not install any drivers, so it cannot possibly be the
cause of any BSOD.
> Has anyone else seen this?
It's usually bad hardware or a bad driver. (VMWare is virtual
hardware, so buggy versions count as "bad hardware")
Either of the above can cause problems that appear and disappear based
on unrelated factors, which makes them hard to track down. But if it's
a BSOD, the root cause is not msysgit.
Peter Harris
^ permalink raw reply
* Re: git clone --bare doesn't create refs/heads/*?
From: Miklos Vajna @ 2009-01-29 14:26 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: git
In-Reply-To: <be6fef0d0901290606q25ad7c82ob250a5f89d4db0cf@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 287 bytes --]
On Thu, Jan 29, 2009 at 10:06:39PM +0800, Tay Ray Chuan <rctay89@gmail.com> wrote:
> afaik, a bare repository is just a copy of the .git folder of the
> cloned repository. why isn't any of its branches copied too?
Maybe you're searching for git clone --mirror and not git clone --bare?
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Valgrind updates
From: Johannes Schindelin @ 2009-01-29 14:22 UTC (permalink / raw)
To: Linus Torvalds
Cc: zlib, Mark Brown, Jeff King, Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0901281751580.3123@localhost.localdomain>
Hi,
On Wed, 28 Jan 2009, Linus Torvalds wrote:
> On Tue, 27 Jan 2009, Johannes Schindelin wrote:
> >
> > To help ye Gods, I put together this almost minimal C program:
>
> This one is buggy.
Not exactly buggy. Underexplained.
> > out = fopen("/dev/null", "w");
> > fwrite(compressed + 51, 51, 1, out);
> > fwrite(compressed + 51, 1, 1, stderr);
> > fflush(out);
> > fclose(out);
>
> The problem is that the first argument to that first "fwrite()" is simply
> wrong. It shouldn't be "compressed + 51", it should be just "compressed".
Nope. It should be "compressed + 51" to narrow down the issue, as
valgrind does not complain about _any other_ offset.
Not even when that is _well_ after the 58 bytes deflate() says are
available.
> As it is, you're writing 51 bytes, starting at 51 bytes in, and that's
> obviously not correct (you only got 58 bytes from deflate()).
It is not, granted. But I left it in for a purpose: to show that valgrind
does not even bother to mention bytes we think should be invalid.
I thought that there might be a shortcut for /dev/null, so I changed the
outfile to a real file, and it _still_ does not complain.
> So valgrind does complain about it, but for a perfectly valid reason.
Only it does not. It complains about the write of 1 byte, not the write
of 51.
But I know why: "out" is opened buffered, so it shows the error (well
delayed, I might add, and not in a helpful manner) when fflush() is
called.
The real issue, namely that an access of offset 51 triggers a valgrind
error, is demonstrated by my small test case.
Ciao,
Dscho
^ permalink raw reply
* Re: ??? Re: [PATCH/RFC v1 1/6] symlinks.c: small cleanup and optimisation
From: Kjetil Barvik @ 2009-01-29 14:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vskn3np6u.fsf@gitster.siamese.dyndns.org>
* Kjetil Barvik <barvik@broadpark.no> writes:
> + /*
> + * Is the cached path string a substring of 'name', is 'name'
> + * a substring of the cached path string, or is 'name' and the
> + * cached path string the exact same string?
> + */
> + if (i >= max_len && ((i < len && name[i] == '/') ||
> + (i < cache.len && cache.path[i] == '/') ||
> + (len == cache.len))) {
* Junio C Hamano <gitster@pobox.com> writes:
> As you described in your commit log message, what this really wants to
> check is (i == max_len). By saying (i >= max_len) you are losing
> readability, optimizing for compilers (that do not notice this)
When the compiler see the source line:
'while (i < max_len && name[i] == cache.path[i])'
it will, from what I know about compilers and machine instructions for
intel cpu's, generate the following pseudo instructions for this line
(before more compiler optimisation is done):
1 test !(i < max_len) /* which is (i >= max_len) */
2 jump-if-not-zero first_instruction_address_outside_the_loop
3 "some instructions to retrieve some memory locations and test
name[i] == cache.path[i]"
4 jump-if-not-zero instruction-address-to-continue-to-loop
So, I thought that if I could use the exact same test as the compiler
have to generate for line 1, then I would maybe saved a test, and
maybe also a jump instruction.
Compiling with 'gcc -Os' (optimise for text segment size) I was able to
save 4 bytes for this file, which I think shows that gcc is able to
take advantage of this trick.
> and pessimizing for human readers (like me, who had to spend a few
> dozens of seconds to realize what you are doing, to speculate why you
> might have thought this would be a good idea, and writing this
> paragraph). I do not know if it is a good trade-off.
But, it was not easy to come up with a real test which shows a
noticeable time difference from this trick, so, I guess this is only a
trick for the kernel people (at most), so I revert it and will use
'==' for version 2, such that we keep a little better readability.
-- kjetil
ps! Compiling with '-march=core2 -O2 -g0 -s -fomit-frame-pointer', the
difference in text segment was 64 bytes when using this trick.
^ permalink raw reply
* Re: Valgrind updates
From: Johannes Schindelin @ 2009-01-29 14:14 UTC (permalink / raw)
To: Mark Adler
Cc: Linus Torvalds, Jean-loup Gailly, Mark Brown, Jeff King,
Junio C Hamano, Git Mailing List
In-Reply-To: <4D595705-7935-4AC2-91F4-1DAB3C6C7D27@alumni.caltech.edu>
Hi,
On Wed, 28 Jan 2009, Mark Adler wrote:
> On Jan 28, 2009, at 3:27 PM, Johannes Schindelin wrote:
> >On Wed, 28 Jan 2009, Mark Adler wrote:
> > >2. Can someone send me the input and the 58 bytes of output from this
> > > case?
> >
> >I did better than that already...
> >http://article.gmane.org/gmane.comp.version-control.git/107391
>
> Johannes,
>
> Thanks for the input and code. When I run it, the byte in question at
> offset 51 is 0x2c. The output decompresses fine and the result matches
> the input. If I change the 0x2c to anything else, decompression fails.
> The 58 bytes are below.
>
> Can you also send me the 58 bytes of output that you get when you run it?
I get exactly the same 58 bytes. Together with the fact that the 52nd
byte is actually required to be 0x2c, I think that maybe valgrind is
having problems to track that this byte was correctly initialized.
BTW did you have any chance to test the code with valgrind on your
machine? It might be related to this here platform (x86_64).
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Support various HTTP authentication methods
From: Johannes Sixt @ 2009-01-29 14:08 UTC (permalink / raw)
To: Moriyoshi Koizumi; +Cc: git
In-Reply-To: <4981B6E6.6020502@mozo.jp>
Moriyoshi Koizumi schrieb:
> Johannes Sixt wrote:
>> Moriyoshi Koizumi schrieb:
>>> @@ -210,6 +272,20 @@ static CURL* get_curl_handle(void)
>>> if (curl_http_proxy)
>>> curl_easy_setopt(result, CURLOPT_PROXY, curl_http_proxy);
>> CURLOPT_PROXY is set here...
>
> As I wrote in the previous post, this part was from the original.
>
>>>
>>> + if (curl_http_auth) {
>>> + long n = get_curl_auth_bitmask(curl_http_auth);
>>> + curl_easy_setopt(result, CURLOPT_HTTPAUTH, n);
>>> + }
>
>> ... and here again. Is that necessary?
>
> What part do you mean by that?
Oops, sorry, I cut too much from your patch:
> + if (curl_http_auth) {
> + long n = get_curl_auth_bitmask(curl_http_auth);
> + curl_easy_setopt(result, CURLOPT_HTTPAUTH, n);
> + }
> +
> + if (curl_http_proxy) {
> + curl_easy_setopt(result, CURLOPT_PROXY, curl_http_proxy);
Here you set CURLOPT_PROXY again.
-- Hannes
^ permalink raw reply
* git clone --bare doesn't create refs/heads/*?
From: Tay Ray Chuan @ 2009-01-29 14:06 UTC (permalink / raw)
To: git
Hi,
just like to clarify a doubt of mine.
afaik, a bare repository is just a copy of the .git folder of the
cloned repository. why isn't any of its branches copied too?
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: [PATCH] push: Learn to set up branch tracking with '--track'
From: Johannes Schindelin @ 2009-01-29 14:05 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: git, gitster
In-Reply-To: <bd6139dc0901290551g42ac7cb6m40194f75b8863be0@mail.gmail.com>
Hi,
On Thu, 29 Jan 2009, Sverre Rabbelier wrote:
> On Thu, Jan 29, 2009 at 12:45, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> > Mhhh, so maybe we want a way to set up tracking branches when pushing,
> > yes? From what I've seen a patch to do that shouldn't be too hard, so
> > if there's interest in that I could look into that.
>
> On Thu, Jan 29, 2009 at 14:38, Johannes Schindelin
> <johannes.schindelin@gmx.de> wrote:
> > $ git checkout xyz
> > $ git push --track origin xyz:abc
> > $ git pull
>
> Am I reading this correctly in that you beat me to the patch I
> mentioned earlier in reply to Junio and Peff?
I have to admit that due to time constraints, I did not follow your
discussion closely.
I just just remembered that 'jast' mentioned something like this on IRC,
and it seemed that it was easy to do. Now you go and point out all those
mistakes in my code, okay?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] push: Learn to set up branch tracking with '--track'
From: Johannes Schindelin @ 2009-01-29 14:02 UTC (permalink / raw)
To: git; +Cc: gitster
In-Reply-To: <alpine.DEB.1.00.0901291438030.3586@pacific.mpi-cbg.de>
Hi,
On Thu, 29 Jan 2009, Johannes Schindelin wrote:
> This is a companion patch to the one I sent earlier:
>
> http://article.gmane.org/gmane.comp.version-control.git/13735
Hmm, maybe I should explain a little better.
That patch tried to make 'git pull' more convenient, that you could set up
tracking information with a single flag to an explicit pull.
This patch does the same for 'git push', although I agree that the 'pull'
patch should be done rather differently.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Support various HTTP authentication methods
From: Moriyoshi Koizumi @ 2009-01-29 14:02 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <4981826D.507@viscovery.net>
Johannes Sixt wrote:
> Moriyoshi Koizumi schrieb:
>> @@ -210,6 +272,20 @@ static CURL* get_curl_handle(void)
>> if (curl_http_proxy)
>> curl_easy_setopt(result, CURLOPT_PROXY, curl_http_proxy);
>
> CURLOPT_PROXY is set here...
As I wrote in the previous post, this part was from the original.
>
>>
>> + if (curl_http_auth) {
>> + long n = get_curl_auth_bitmask(curl_http_auth);
>> + curl_easy_setopt(result, CURLOPT_HTTPAUTH, n);
>> + }
> ... and here again. Is that necessary?
What part do you mean by that?
Regards,
Moriyoshi
^ permalink raw reply
* Re: [PATCH] Support various HTTP authentication methods
From: Moriyoshi Koizumi @ 2009-01-29 13:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3af2h1b0.fsf@gitster.siamese.dyndns.org>
First thank you for the advice. I am not familiar to the code base and
definitely doing something wrong.
Junio C Hamano wrote:
> Moriyoshi Koizumi <mozo@mozo.jp> writes:
>> This patch enables it if supported by CURL, adding a couple of new
>
> "it" in "enables it" is a bit unclear...
I was a bit in a rush and I thought I got to get this done before I went
home. This patch dnables various HTTP authentication methods namely
basic, digest, GSS and NTLM that are supported by cURL. cURL tries to
use basic authentication if the option is not explicitly provided.
> Linewrapped and whitespace damaged patch that would not apply.
Sorry for the crap. I'll try to send the correct one next week.
> I am not a cURL expert, so I'd take your word for these version
> dependencies.
>
> We do not initialize static scope pointers to "= NULL" nor variables to 0,
> instead we let BSS take care of that for us. ftp_no_epsv we can see in
> the context is doing unnecessary initialization that should be fixed.
Right.
>> +#if LIBCURL_VERSION_NUM >= 0x070a06
>> + if (!strcmp("http.auth", var)) {
>> + if (curl_http_auth == NULL)
>
> We tend to say "if (!pointer)".
I'll fix this too.
> I see you implemented "the first one wins" rule with this test, but I do
> not think you want that. We first read $HOME/.gitconfig and then
> repository specific $GIT_DIR/config, so it is often more useful to use
> "the last one wins" rule.
The environment variables win over gitconfigs. I thought that's what I
implemented and what we want.
> Our isspace() is a sane_isspace(), so you do not have to play casting
> games between signed vs unsigned char.
>
>> + for (;;) {
>> + char *q = buf;
>> + while (*p && isspace(*p))
>> + ++p;
>> +
>> + while (*p && *p != ',')
>> + *q++ = tolower(*p++);
>> +
>> + while (--q >= buf && isspace(*(unsigned char *)q));
>> + ++q;
>> +
>> + *q = '\0';
>> +
>> + if (strcmp(buf, "basic") == 0)
>
> Say !strcmp(buf, "literal") like you did in the configuration parsing part
> earlier.
I tend to like this way, and the reason for the inconsistency between
them is that the earlier one is pasted from the nearby code. I'm
willing to fix this as well if I should.
>
>> + mask |= CURLAUTH_BASIC;
>> + else if (strcmp(buf, "digest") == 0)
>> + mask |= CURLAUTH_DIGEST;
>> + else if (strcmp(buf, "gss") == 0)
>> + mask |= CURLAUTH_GSSNEGOTIATE;
>> + else if (strcmp(buf, "ntlm") == 0)
>> + mask |= CURLAUTH_NTLM;
>> + else if (strcmp(buf, "any") == 0)
>> + mask |= CURLAUTH_ANY;
>> + else if (strcmp(buf, "anysafe") == 0)
>> + mask |= CURLAUTH_ANYSAFE;
>> +
>> + if (!*p)
>> + break;
>> + ++p;
>> + }
>
> You leak "buf" here you forgot to free. The string you can possibly
> accept is a known set with some maximum length, so you can use a on-stack
> buf[] and reject any token longer than that maximum, right?
That one is really silly and shameful :-( I first thought I could go
with the on-stack buffer, but I eventually did this because the input
might contain an indefinite set of tokens, and thought safer to alloc it.
>> + if (curl_http_proxy) {
>> + curl_easy_setopt(result, CURLOPT_PROXY, curl_http_proxy);
>> +
>> + if (curl_http_proxy_auth) {
>> + long n = get_curl_auth_bitmask(curl_http_proxy_auth);
>> + curl_easy_setopt(result, CURLOPT_PROXYAUTH, n);
>> + }
>> + }
>> +
>
> This part does not have to be protected with the LIBCURL_VERSION_NUM
> conditional? I somehow find it unlikely...
The block that starts with if (curl_http_proxy_auth) {} should've been
enclosed by the conditinals. The leading part had been there in the
first place.
> Instead of parsing the string every time a curl handle is asked for, how
> about parsing them once and store the masks in two file scope static longs
> in http_init() and use that value to easy_setopt() call here?
That has to be the way to go, but the question is where I am supposed to
parse the strings and store them to the globals?
>
> That way you can free the two strings much early without waiting for
> http_cleanup(), too, right?
Regards,
Moriyoshi
^ permalink raw reply
* Re: [PATCH] push: Learn to set up branch tracking with '--track'
From: Sverre Rabbelier @ 2009-01-29 13:51 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <alpine.DEB.1.00.0901291438030.3586@pacific.mpi-cbg.de>
On Thu, Jan 29, 2009 at 12:45, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> Mhhh, so maybe we want a way to set up tracking branches when pushing,
> yes? From what I've seen a patch to do that shouldn't be too hard, so
> if there's interest in that I could look into that.
On Thu, Jan 29, 2009 at 14:38, Johannes Schindelin
<johannes.schindelin@gmx.de> wrote:
> $ git checkout xyz
> $ git push --track origin xyz:abc
> $ git pull
Am I reading this correctly in that you beat me to the patch I
mentioned earlier in reply to Junio and Peff?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Something weird is happening...
From: Sverre Rabbelier @ 2009-01-29 13:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: H. Peter Anvin, Git Mailing List, Ingo Molnar
In-Reply-To: <7vr62mha7a.fsf@gitster.siamese.dyndns.org>
On Thu, Jan 29, 2009 at 07:56, Junio C Hamano <gitster@pobox.com> wrote:
>> Okay, what is going on here?
Is this perhaps related to the problem the github guys were having,
its sounds similar, problem not showing up until after upgrade,
missing objects, no?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: "malloc failed"
From: Andreas Ericsson @ 2009-01-29 13:41 UTC (permalink / raw)
To: David Abrahams; +Cc: Jeff King, Junio C Hamano, git
In-Reply-To: <87pri6qmvm.fsf@mcbain.luannocracy.com>
David Abrahams wrote:
> on Thu Jan 29 2009, Jeff King <peff-AT-peff.net> wrote:
>
>> On Thu, Jan 29, 2009 at 12:20:41AM -0500, Jeff King wrote:
>>
>>> Ok, that _is_ big. ;) I wouldn't be surprised if there is some corner of
>>> the code that barfs on a single object that doesn't fit in a signed
>>> 32-bit integer; I don't think we have any test coverage for stuff that
>>> big.
>> Sure enough, that is the problem. With the patch below I was able to
>> "git add" and commit a 3 gigabyte file of random bytes (so even the
>> deflated object was 3G).
>>
>> I think it might be worth applying as a general cleanup, but I have no
>> idea if other parts of the system might barf on such an object.
>>
>> -- >8 --
>> Subject: [PATCH] avoid 31-bit truncation in write_loose_object
>>
>> The size of the content we are adding may be larger than
>> 2.1G (i.e., "git add gigantic-file"). Most of the code-path
>> to do so uses size_t or unsigned long to record the size,
>> but write_loose_object uses a signed int.
>>
>> On platforms where "int" is 32-bits (which includes x86_64
>> Linux platforms), we end up passing malloc a negative size.
>
>
> Good work. I don't know if this matters to you, but I think on a 32-bit
> platform you'll find that size_t, which is supposed to be able to hold
> the size of the largest representable *memory block*, is only 4 bytes
> large:
>
> #include <limits.h>
> #include <stdio.h>
>
> int main()
> {
> printf("sizeof(size_t) = %d", sizeof(size_t));
> }
>
> Prints "sizeof(size_t) = 4" on my core duo.
>
It has nothing to do with typesize, and everything to do with
signedness. A size_t cannot be negative, while an int can.
Making sure we use the correct signedness everywhere means
we double the capacity where negative values are clearly bogus,
such as in this case. On 32-bit platforms, the upper limit for
what git can handle is now 4GB, which is expected. To go beyond
that, we'd need to rework the algorithm so we handle chunks of
the data instead of the whole. Some day, that might turn out to
be necessary but today is not that day.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* [PATCH] push: Learn to set up branch tracking with '--track'
From: Johannes Schindelin @ 2009-01-29 13:38 UTC (permalink / raw)
To: git; +Cc: gitster
In-Reply-To: <cover.1233236267u.git.johannes.schindelin@gmx.de>
When pushing a branch to a remote repository that the remote side did
not know beforehand, it is often handy to set up the branch tracking
such that
$ git checkout xyz
$ git push --track origin xyz:abc
$ git pull
will pull the branch 'abc' from the remote 'origin' into the branch
'xyz'.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
This is a companion patch to the one I sent earlier:
http://article.gmane.org/gmane.comp.version-control.git/13735
Documentation/git-push.txt | 7 ++++++-
builtin-push.c | 42 ++++++++++++++++++++++++++++++++++++++++++
t/t5516-fetch-push.sh | 11 +++++++++++
3 files changed, 59 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 7d1eced..fa1d54c 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -10,7 +10,7 @@ SYNOPSIS
--------
[verse]
'git push' [--all | --mirror] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>]
- [--repo=<repository>] [-f | --force] [-v | --verbose]
+ [--repo=<repository>] [-f | --force] [-v | --verbose] [-t | --track]
[<repository> <refspec>...]
DESCRIPTION
@@ -126,6 +126,11 @@ useful if you write an alias or script around 'git-push'.
transfer spends extra cycles to minimize the number of
objects to be sent and meant to be used on slower connection.
+-t::
+--track::
+ Set up tracking information for the pushed branches, so that
+ 'git pull' will remember the indicated mapping.
+
-v::
--verbose::
Run verbosely.
diff --git a/builtin-push.c b/builtin-push.c
index 122fdcf..9fd445d 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -16,6 +16,7 @@ static const char * const push_usage[] = {
static int thin;
static const char *receivepack;
+static int track;
static const char **refspec;
static int refspec_nr;
@@ -48,6 +49,41 @@ static void set_refspecs(const char **refs, int nr)
}
}
+static void setup_tracking(const char *url)
+{
+ struct strbuf buf = STRBUF_INIT, buf2 = STRBUF_INIT;
+ int i;
+
+ for (i = 0; i < refspec_nr; i++) {
+ const char *branch = refspec[i], *colon;
+
+ /* skip non-branches */
+ if (!prefixcmp("refs/", branch)) {
+ if (prefixcmp("refs/heads/", branch))
+ continue;
+ branch += strlen("refs/heads/");
+ }
+ colon = strchrnul(branch, ':');
+
+ strbuf_reset(&buf);
+ strbuf_addf(&buf, "branch.%.*s.remote",
+ (int)(colon - branch), branch);
+ git_config_set(buf.buf, url);
+
+ strbuf_reset(&buf);
+ strbuf_addf(&buf, "branch.%.*s.merge",
+ (int)(colon - branch), branch);
+ strbuf_reset(&buf2);
+ strbuf_addf(&buf2, "%s%s",
+ *colon && !prefixcmp("refs/heads/", colon + 1) ?
+ "" : "refs/heads/",
+ *colon ? colon + 1 : branch);
+ git_config_set(buf.buf, buf2.buf);
+ }
+ strbuf_release(&buf);
+ strbuf_release(&buf2);
+}
+
static int do_push(const char *repo, int flags)
{
int i, errs;
@@ -96,6 +132,8 @@ static int do_push(const char *repo, int flags)
if (flags & TRANSPORT_PUSH_VERBOSE)
fprintf(stderr, "Pushing to %s\n", remote->url[i]);
err = transport_push(transport, refspec_nr, refspec, flags);
+ if (!err && track)
+ setup_tracking(transport->url);
err |= transport_disconnect(transport);
if (!err)
@@ -126,11 +164,15 @@ int cmd_push(int argc, const char **argv, const char *prefix)
OPT_BOOLEAN( 0 , "thin", &thin, "use thin pack"),
OPT_STRING( 0 , "receive-pack", &receivepack, "receive-pack", "receive pack program"),
OPT_STRING( 0 , "exec", &receivepack, "receive-pack", "receive pack program"),
+ OPT_BOOLEAN('t', "track", &track, "set up branch tracking information"),
OPT_END()
};
argc = parse_options(argc, argv, options, push_usage, 0);
+ if (track && !tags && !argc)
+ die ("Need explicit arguments for branch tracking");
+
if (tags)
add_refspec("refs/tags/*");
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index 4426df9..e18b2f6 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -573,4 +573,15 @@ test_expect_success 'push with branches containing #' '
git checkout master
'
+test_expect_success 'push --track' '
+
+ git push --track testrepo master &&
+ test ! -z "$(git ls-remote testrepo master)" &&
+ test "testrepo" = $(git config branch.master.remote) &&
+ test "refs/heads/master" = $(git config branch.master.merge) &&
+ git push --track testrepo master:test &&
+ test "refs/heads/test" = $(git config branch.master.merge)
+
+'
+
test_done
--
1.6.1.1.506.gdbe181
^ permalink raw reply related
* Re: "malloc failed"
From: David Abrahams @ 2009-01-29 13:10 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20090129055633.GA32609@coredump.intra.peff.net>
on Thu Jan 29 2009, Jeff King <peff-AT-peff.net> wrote:
> On Thu, Jan 29, 2009 at 12:20:41AM -0500, Jeff King wrote:
>
>> Ok, that _is_ big. ;) I wouldn't be surprised if there is some corner of
>> the code that barfs on a single object that doesn't fit in a signed
>> 32-bit integer; I don't think we have any test coverage for stuff that
>> big.
>
> Sure enough, that is the problem. With the patch below I was able to
> "git add" and commit a 3 gigabyte file of random bytes (so even the
> deflated object was 3G).
>
> I think it might be worth applying as a general cleanup, but I have no
> idea if other parts of the system might barf on such an object.
>
> -- >8 --
> Subject: [PATCH] avoid 31-bit truncation in write_loose_object
>
> The size of the content we are adding may be larger than
> 2.1G (i.e., "git add gigantic-file"). Most of the code-path
> to do so uses size_t or unsigned long to record the size,
> but write_loose_object uses a signed int.
>
> On platforms where "int" is 32-bits (which includes x86_64
> Linux platforms), we end up passing malloc a negative size.
Good work. I don't know if this matters to you, but I think on a 32-bit
platform you'll find that size_t, which is supposed to be able to hold
the size of the largest representable *memory block*, is only 4 bytes
large:
#include <limits.h>
#include <stdio.h>
int main()
{
printf("sizeof(size_t) = %d", sizeof(size_t));
}
Prints "sizeof(size_t) = 4" on my core duo.
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> sha1_file.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/sha1_file.c b/sha1_file.c
> index 360f7e5..8868b80 100644
> --- a/sha1_file.c
> +++ b/sha1_file.c
> @@ -2340,7 +2340,8 @@ static int create_tmpfile(char *buffer, size_t bufsiz, const
> char *filename)
> static int write_loose_object(const unsigned char *sha1, char *hdr, int hdrlen,
> void *buf, unsigned long len, time_t mtime)
> {
> - int fd, size, ret;
> + int fd, ret;
> + size_t size;
> unsigned char *compressed;
> z_stream stream;
> char *filename;
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
^ permalink raw reply
* Re: Sporadic BSOD with msys git?
From: John Chapman @ 2009-01-29 12:27 UTC (permalink / raw)
To: Mark Burton; +Cc: git
In-Reply-To: <20090129115442.6ce311f8@crow>
Is that a clean windows XP system in VMware - with how much RAM?
- I just find it strange, because I've had a similar setup, but never
once got a crash like that.
Additionally, the BSOD is in the guest, and not the host?
- if it is the host that is BSOD'ing, then go check your memory,
something's wierd there.
On Thu, 2009-01-29 at 11:54 +0000, Mark Burton wrote:
> Hi,
>
> I occasionally have to use Windows (XP under VMWare) and thought I would try
> out msysgit so I installed the recent version (1.6.1). For what I was
> wanting to use it for, it worked OK.
>
> However, I then started getting crashes when using the Windows explorer. I would
> click on a folder to look at its contents and, whammo, Windows would crash. It
> just happened every now and again, not all the time.
>
> I uninstalled msysgit and now the crashes are not happening any more. Not
> exactly conclusive evidence but, perhaps, there's an issue there?
>
> Has anyone else seen this?
>
> Cheers,
>
> Mark
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)
From: Sverre Rabbelier @ 2009-01-29 12:20 UTC (permalink / raw)
To: Jeff King; +Cc: Pieter de Bie, Junio C Hamano, git
In-Reply-To: <20090129115026.GB10792@coredump.intra.peff.net>
On Thu, Jan 29, 2009 at 12:50, Jeff King <peff@peff.net> wrote:
> I think that would be reasonable.
Yay :).
> It wouldn't help the case of "somebody
> else pushed some content that you want to pull", but like you said, I
> think the primary workflow is that you immediately push after cloning
> the empty repo.
Also, the only way to support the "somebody else pushed already"
workflow would be to assume the user wants to name the branch
'master', which might not be the case at all.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Sporadic BSOD with msys git?
From: Christian MICHON @ 2009-01-29 12:18 UTC (permalink / raw)
To: Mark Burton; +Cc: git
In-Reply-To: <20090129115442.6ce311f8@crow>
On Thu, Jan 29, 2009 at 12:54 PM, Mark Burton <markb@ordern.com> wrote:
>
> Hi,
>
> I occasionally have to use Windows (XP under VMWare) and thought I would try
> out msysgit so I installed the recent version (1.6.1). For what I was
> wanting to use it for, it worked OK.
>
> However, I then started getting crashes when using the Windows explorer. I would
> click on a folder to look at its contents and, whammo, Windows would crash. It
> just happened every now and again, not all the time.
>
> I uninstalled msysgit and now the crashes are not happening any more. Not
> exactly conclusive evidence but, perhaps, there's an issue there?
>
> Has anyone else seen this?
>
> Cheers,
>
> Mark
> --
no, never on virtual machines, nor on real systems (xp+vista).
could you try on a freshly installed version of xp inside a vm ? maybe
also provide please the release details (os, msysgit, etc...)
a test case allowing to reproduce with predictability would be also welcome...
--
Christian
--
http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
^ permalink raw reply
* Re: Something weird is happening...
From: Ingo Molnar @ 2009-01-29 12:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: H. Peter Anvin, Git Mailing List
In-Reply-To: <20090129113846.GA10645@elte.hu>
* Ingo Molnar <mingo@elte.hu> wrote:
> a simple 'git fsck' still reports a ton of dangling and missing objects.
> (see it below)
>
> amongst them is the object above:
>
> missing blob af0e01d4c663a101f48614e40d006ed6272d5c36
>
> but this does not seem to cause problems with git version 1.6.0.6 that
> i'm using now.
hm - maybe it's unrelated, but yesterday, a few hours before the incident
i did a higher-order Octopus merge with 1.6.1, that segfaulted.
I didnt think much of it - git often crashes with our crazy -tip tree when
i get above the magic 20 branches limit. The crash left a .git/index.lock
file around which i removed - and then forgot about the incident. I wanted
to report those crashes before but procrastinated it.
I used git/maint snapshots because new versions of Git are much better at
doing Octopus merges.
I've written a reproducer for git-1.6.1.1-1.fc11.i386. See the crash log
below.
To reproduce, pick up the -tip tree as a remote:
http://people.redhat.com/mingo/tip.git/README
(you can run the README file as a script)
Then do this:
git checkout -b tmp.crash v2.6.29-rc3
git merge tip/x86/asm tip/x86/cleanups tip/x86/cpudetect \
tip/x86/debug tip/x86/doc tip/x86/header-fixes \
tip/x86/mm tip/x86/paravirt tip/x86/pat \
tip/x86/setup-v2 tip/x86/subarch tip/x86/uaccess \
tip/x86/urgent tip/core/percpu
and you should see the segfault.
interestingly i did not reproduce with the sha1's hardcoded:
git checkout -b tmp.crash 18e352e4a73465349711a9324767e1b2453383e2
git merge 2d4d57db692ea790e185656516e6ebe8791f1788 a448720ca3248e8a7a426336885549d6e923fd8e b38b0665905538e76e26f2a4c686179abb1f69f6 d5e397cb49b53381e4c99a064ca733c665646de8 e56d0cfe7790fd3218ae4f6aae1335547fea8763 dbca1df48e89d8aa59254fdc10ef16c16e73d94e fb746d0e1365b7472ccc4c3d5b0672b34a092d0b 6522869c34664dd5f05a0a327e93915b1281c90d d639bab8da86d330493487e8c0fea8ca31f53427 042cbaf88ab48e11afb725541e3c2cbf5b483680 5662a2f8e7313f78d6b17ab383f3e4f04971c335 3b4b75700a245d0d48fc52a4d2f67d3155812aba bf3647c44bc76c43c4b2ebb4c37a559e899ac70e 4369f1fb7cd4cf777312f43e1cb9aa5504fc4125
Ingo
-------------------->
earth4:~/tip> git merge x86/asm x86/cleanups x86/cpudetect x86/debug
x86/doc x86/header-fixes x86/mm x86/paravirt x86/pat x86/setup-v2
x86/subarch x86/uaccess x86/urgent core/percpu
Trying simple merge with 2d4d57db692ea790e185656516e6ebe8791f1788
Trying simple merge with a448720ca3248e8a7a426336885549d6e923fd8e
Simple merge did not work, trying automatic merge.
Auto-merging arch/x86/include/asm/io.h
Auto-merging arch/x86/include/asm/spinlock.h
Auto-merging arch/x86/kernel/mpparse.c
Auto-merging arch/x86/kernel/setup_percpu.c
Auto-merging arch/x86/mm/init_32.c
Trying simple merge with b38b0665905538e76e26f2a4c686179abb1f69f6
Simple merge did not work, trying automatic merge.
Auto-merging arch/x86/kernel/cpu/common.c
Auto-merging arch/x86/kernel/cpu/intel.c
Auto-merging arch/x86/mm/pat.c
Trying simple merge with d5e397cb49b53381e4c99a064ca733c665646de8
Trying simple merge with e56d0cfe7790fd3218ae4f6aae1335547fea8763
Trying simple merge with dbca1df48e89d8aa59254fdc10ef16c16e73d94e
Trying simple merge with fb746d0e1365b7472ccc4c3d5b0672b34a092d0b
Trying simple merge with 6522869c34664dd5f05a0a327e93915b1281c90d
Simple merge did not work, trying automatic merge.
Auto-merging arch/x86/include/asm/paravirt.h
Trying simple merge with d639bab8da86d330493487e8c0fea8ca31f53427
Simple merge did not work, trying automatic merge.
Auto-merging arch/x86/include/asm/io.h
Auto-merging arch/x86/mm/ioremap.c
Trying simple merge with 042cbaf88ab48e11afb725541e3c2cbf5b483680
Trying simple merge with 5662a2f8e7313f78d6b17ab383f3e4f04971c335
Trying simple merge with 3b4b75700a245d0d48fc52a4d2f67d3155812aba
Simple merge did not work, trying automatic merge.
Auto-merging arch/x86/kernel/signal.c
Trying simple merge with bf3647c44bc76c43c4b2ebb4c37a559e899ac70e
Simple merge did not work, trying automatic merge.
Auto-merging arch/x86/kernel/cpu/intel.c
Trying simple merge with 4369f1fb7cd4cf777312f43e1cb9aa5504fc4125
/usr/libexec/git-core/git-merge-octopus: line 52: 26758 Segmentation fault
git read-tree -u -m --aggressive $common $MRT $SHA1
Merge with strategy octopus failed.
earth4:~/tip>
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)
From: Nico -telmich- Schottelius @ 2009-01-29 12:04 UTC (permalink / raw)
To: Jeff King; +Cc: Pieter de Bie, Sverre Rabbelier, Junio C Hamano, git
In-Reply-To: <20090129114834.GA10792@coredump.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 1502 bytes --]
Jeff King [Thu, Jan 29, 2009 at 06:48:34AM -0500]:
> [...] I think that is what people who ask for empty cloning really want:
>
> 1. make a bare upstream
>
> 2. clone empty repo
>
> 3. create commits
>
> 4. git push / git pull, as if we had cloned non-empty repo
I must confess, as a user I would like to do
1. create local repo
2. create a remote
3. push it
I don't care about creating empty repos somewhere:
My aim is to publish my work, that's it.
Comments on the steps:
1.1. I don't care whether I push a empty repo or not. But pushing an empty
one does not make much sense, so refusing this would be reasonable
1.2. When creating a new repo, it would be helpful if I can directly add a
description: git init [description] would be nice to have
2.1. I (as a user) understand that I need to create a remote where I have to
push to. It would be helpful to specify --track-this/--merge-this to
have it automatically connected to the current branch
3.1. I would really like to see something like git push
--create[-if-not-exists]. This makes sense for me, but could also
be a global configuration option (push.autocreate = true|false).
Just a comment from a user's point of view ;-)
Sincerly,
Nico
--
Think about Free and Open Source Software (FOSS).
http://nico.schottelius.org/documentations/foss/the-term-foss/
PGP: BFE4 C736 ABE5 406F 8F42 F7CF B8BE F92A 9885 188C
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Sporadic BSOD with msys git?
From: Mark Burton @ 2009-01-29 11:54 UTC (permalink / raw)
To: git
Hi,
I occasionally have to use Windows (XP under VMWare) and thought I would try
out msysgit so I installed the recent version (1.6.1). For what I was
wanting to use it for, it worked OK.
However, I then started getting crashes when using the Windows explorer. I would
click on a folder to look at its contents and, whammo, Windows would crash. It
just happened every now and again, not all the time.
I uninstalled msysgit and now the crashes are not happening any more. Not
exactly conclusive evidence but, perhaps, there's an issue there?
Has anyone else seen this?
Cheers,
Mark
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)
From: Jeff King @ 2009-01-29 11:50 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Pieter de Bie, Junio C Hamano, git
In-Reply-To: <bd6139dc0901290345u4962f747gbe93c945ab35c9cb@mail.gmail.com>
On Thu, Jan 29, 2009 at 12:45:23PM +0100, Sverre Rabbelier wrote:
> On Thu, Jan 29, 2009 at 12:40, Pieter de Bie <pdebie@ai.rug.nl> wrote:
> > This is true in all cases. If you create a new branch in any repository,
> > push that, and later do a 'git pull', you get that message. I agree it's
> > not the nicest way to handle things, but this is not an issue with the
> > clone, it's an issue of pushing new branches in general.
>
> Mhhh, so maybe we want a way to set up tracking branches when pushing,
> yes? From what I've seen a patch to do that shouldn't be too hard, so
> if there's interest in that I could look into that.
I think that would be reasonable. It wouldn't help the case of "somebody
else pushed some content that you want to pull", but like you said, I
think the primary workflow is that you immediately push after cloning
the empty repo.
-Peff
^ permalink raw reply
* Re: [PATCH] http-push: refactor request url creation
From: Tay Ray Chuan @ 2009-01-29 11:49 UTC (permalink / raw)
To: git, Johannes Schindelin, Junio C Hamano
In-Reply-To: <4980D9FF.7020307@gmail.com>
Hi,
On Thu, Jan 29, 2009 at 6:51 AM, Junio C Hamano <gitster@pobox.com> wrote:
> What's with these loooooooooooooooooooooooooooooong lines?
>
> I thought at least you did not have these overlong lines in your earlier
> attempts, and Dscho may have acked one of those, but I doubt he would give
> his Ack to this one. I certainly wouldn't Ack it myself.
>
> By the way, aren't you sending format="flowed"? Please don't. It damages
> whitespaces.
I used Thunderbird since Gmail kept wrapping lines in the patch, guess
i"ll have to manually wrap the commit lines.
> Daniel Stenberg did a research on the safety of your "since curl stdrup's
> it" claim, and found that it unsafe for earlier versions of the library
> before 7.17.0.
>
> It seems that we earlier found out that anything older than 7.16 were not
> usable for git-http-push (see Release Notes for 1.5.4), but 7.16 is still
> older than 7.17, so either we declare you _must_ have 7.17 or newer to use
> http-push, or keep an extra copy around and free it later like the
> original code does.
>
> Even Debian is at 7.18.2 these days, so requiring 7.17 or newer may not be
> an issue in practice, but there are people who keep running things on
> older distros with proven stability (and known features limitation).
>
> The refactoring looked sane otherwise, but I think we would want to opt
> for safety by keeping an extra string around.
Hmm, since that string won't be released in start_fetch_loose, or
anywhere else, would this be considered a memory leak?
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)
From: Jeff King @ 2009-01-29 11:48 UTC (permalink / raw)
To: Pieter de Bie; +Cc: Sverre Rabbelier, Junio C Hamano, git
In-Reply-To: <351A6988-32EB-473F-B6E5-8FBB38D91F88@ai.rug.nl>
On Thu, Jan 29, 2009 at 11:40:42AM +0000, Pieter de Bie wrote:
> This is true in all cases. If you create a new branch in any
> repository, push that, and later do a 'git pull', you get that
> message. I agree it's not the nicest way to handle things, but this is
> not an issue with the clone, it's an issue of pushing new branches in
> general.
Right. I guess I was hoping by cloning an existing repository, even one
with no commits on the branch, that we could somehow remember that we
are "on" the master branch. I think that is what people who ask for
empty cloning really want:
1. make a bare upstream
2. clone empty repo
3. create commits
4. git push / git pull, as if we had cloned non-empty repo
And I know that it is not very "git" to talk about empty branches, since
branches are pointers into the DAG. But we already do similar trickery
with "yet to be born" branches by putting a dangling symref into HEAD.
But I don't think there's any way currently to send those dangling
symrefs across the git protocol, which is what would be required to do
the above accurately.
-Peff
^ 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