* [PATCH] Support various HTTP authentication methods
From: Moriyoshi Koizumi @ 2009-01-29 9:32 UTC (permalink / raw)
To: git
Currently there is no way to specify the preferred authentication
method for the HTTP backend and it always ends up with the CURL's
default
settings.
This patch enables it if supported by CURL, adding a couple of new
settings
and config environment variables listed below (the names within the
parentheses indicate the latter.)
- http.auth (GIT_HTTP_AUTH)
Specifies the preferred authentication method for HTTP. This can
be a method name or the combination of those separated by comma. Valid
values are "basic", "digest", "gss" and "ntlm". You can also specify
"any" (all of the above), "anysafe" (all of the above except "basic").
Note that the strings are treated case-insensitive.
- http.proxy_auth (GIT_HTTP_PROXY_AUTH)
Specifies the preferred authentication method method for HTTP proxy.
The same thing as above applies to this setting.
Signed-off-by: Moriyoshi Koizumi <mozo@mozo.jp>
---
http.c | 105
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 105 insertions(+), 0 deletions(-)
diff --git a/http.c b/http.c
index ee58799..889135f 100644
--- a/http.c
+++ b/http.c
@@ -25,6 +25,12 @@ static long curl_low_speed_limit = -1;
static long curl_low_speed_time = -1;
static int curl_ftp_no_epsv = 0;
static const char *curl_http_proxy = NULL;
+#if LIBCURL_VERSION_NUM >= 0x070a06
+static const char *curl_http_auth = NULL;
+#endif
+#if LIBCURL_VERSION_NUM >= 0x070a07
+static const char *curl_http_proxy_auth = NULL;
+#endif
static struct curl_slist *pragma_header;
@@ -153,11 +159,67 @@ static int http_options(const char *var, const
char *value, void *cb)
return git_config_string(&curl_http_proxy, var, value);
return 0;
}
+#if LIBCURL_VERSION_NUM >= 0x070a06
+ if (!strcmp("http.auth", var)) {
+ if (curl_http_auth == NULL)
+ return git_config_string(&curl_http_auth, var, value);
+ return 0;
+ }
+#endif
+#if LIBCURL_VERSION_NUM >= 0x070a07
+ if (!strcmp("http.proxy_auth", var)) {
+ if (curl_http_proxy_auth == NULL)
+ return git_config_string(&curl_http_proxy_auth, var, value);
+ return 0;
+ }
+#endif
/* Fall back on the default ones */
return git_default_config(var, value, cb);
}
+#if LIBCURL_VERSION_NUM >= 0x070a06
+static long get_curl_auth_bitmask(const char* auth_method)
+{
+ char *buf = xmalloc(strlen(auth_method) + 1);
+ const unsigned char *p = (const unsigned char *)auth_method;
+ long mask = CURLAUTH_NONE;
+
+ 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)
+ 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;
+ }
+
+ return mask;
+}
+#endif
+
static CURL* get_curl_handle(void)
{
CURL* result = curl_easy_init();
@@ -210,6 +272,20 @@ static CURL* get_curl_handle(void)
if (curl_http_proxy)
curl_easy_setopt(result, CURLOPT_PROXY, curl_http_proxy);
+ 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);
+
+ if (curl_http_proxy_auth) {
+ long n = get_curl_auth_bitmask(curl_http_proxy_auth);
+ curl_easy_setopt(result, CURLOPT_PROXYAUTH, n);
+ }
+ }
+
return result;
}
@@ -258,6 +334,21 @@ void http_init(struct remote *remote)
if (low_speed_time != NULL)
curl_low_speed_time = strtol(low_speed_time, NULL, 10);
+#if LIBCURL_VERSION_NUM >= 0x070a06
+ {
+ char *http_auth = getenv("GIT_HTTP_AUTH");
+ if (http_auth)
+ curl_http_auth = xstrdup(http_auth);
+ }
+#endif
+#if LIBCURL_VERSION_NUM >= 0x070a07
+ {
+ char *http_proxy_auth = getenv("GIT_HTTP_PROXY_AUTH");
+ if (http_proxy_auth)
+ curl_http_proxy_auth = xstrdup(http_proxy_auth);
+ }
+#endif
+
git_config(http_options, NULL);
if (curl_ssl_verify == -1)
@@ -309,6 +400,20 @@ void http_cleanup(void)
free((void *)curl_http_proxy);
curl_http_proxy = NULL;
}
+
+#if LIBCURL_VERSION_NUM >= 0x070a06
+ if (curl_http_auth) {
+ free((void *)curl_http_auth);
+ curl_http_auth = NULL;
+ }
+#endif
+
+#if LIBCURL_VERSION_NUM >= 0x070a07
+ if (curl_http_proxy_auth) {
+ free((void *)curl_http_proxy_auth);
+ curl_http_proxy_auth = NULL;
+ }
+#endif
}
struct active_request_slot *get_active_slot(void)
--
1.5.6.3
^ permalink raw reply related
* Re: [PATCH] Support various HTTP authentication methods
From: Junio C Hamano @ 2009-01-29 10:08 UTC (permalink / raw)
To: Moriyoshi Koizumi; +Cc: git
In-Reply-To: <1233221532.21518.1.camel@lena.gsc.riken.jp>
Moriyoshi Koizumi <mozo@mozo.jp> writes:
> Currently there is no way to specify the preferred authentication
> method for the HTTP backend and it always ends up with the CURL's
> default
> settings.
>
> This patch enables it if supported by CURL, adding a couple of new
"it" in "enables it" is a bit unclear...
> Signed-off-by: Moriyoshi Koizumi <mozo@mozo.jp>
> ---
> http.c | 105
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 105 insertions(+), 0 deletions(-)
Linewrapped and whitespace damaged patch that would not apply.
> diff --git a/http.c b/http.c
> index ee58799..889135f 100644
> --- a/http.c
> +++ b/http.c
> @@ -25,6 +25,12 @@ static long curl_low_speed_limit = -1;
> static long curl_low_speed_time = -1;
> static int curl_ftp_no_epsv = 0;
> static const char *curl_http_proxy = NULL;
> +#if LIBCURL_VERSION_NUM >= 0x070a06
> +static const char *curl_http_auth = NULL;
> +#endif
> +#if LIBCURL_VERSION_NUM >= 0x070a07
> +static const char *curl_http_proxy_auth = NULL;
> +#endif
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.
> static struct curl_slist *pragma_header;
>
> @@ -153,11 +159,67 @@ static int http_options(const char *var, const
> char *value, void *cb)
> return git_config_string(&curl_http_proxy, var, value);
> return 0;
> }
> +#if LIBCURL_VERSION_NUM >= 0x070a06
> + if (!strcmp("http.auth", var)) {
> + if (curl_http_auth == NULL)
We tend to say "if (!pointer)".
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.
> + return git_config_string(&curl_http_auth, var, value);
> + return 0;
> + }
> +#endif
> +#if LIBCURL_VERSION_NUM >= 0x070a07
> + if (!strcmp("http.proxy_auth", var)) {
> + if (curl_http_proxy_auth == NULL)
> + return git_config_string(&curl_http_proxy_auth, var, value);
> + return 0;
> + }
> +#endif
>
> /* Fall back on the default ones */
> return git_default_config(var, value, cb);
> }
>
> +#if LIBCURL_VERSION_NUM >= 0x070a06
> +static long get_curl_auth_bitmask(const char* auth_method)
> +{
> + char *buf = xmalloc(strlen(auth_method) + 1);
> + const unsigned char *p = (const unsigned char *)auth_method;
> + long mask = CURLAUTH_NONE;
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.
> + 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?
> + return mask;
> +}
> +#endif
> +
> static CURL* get_curl_handle(void)
> {
> CURL* result = curl_easy_init();
> @@ -210,6 +272,20 @@ static CURL* get_curl_handle(void)
> if (curl_http_proxy)
> curl_easy_setopt(result, CURLOPT_PROXY, curl_http_proxy);
>
> + 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);
> +
> + 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...
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 way you can free the two strings much early without waiting for
http_cleanup(), too, right?
^ permalink raw reply
* [ANNOUNCE] GIT 1.6.1.2
From: Junio C Hamano @ 2009-01-29 10:16 UTC (permalink / raw)
To: git; +Cc: linux-kernel
The latest maintenance release GIT 1.6.1.2 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.6.1.2.tar.{gz,bz2} (source tarball)
git-htmldocs-1.6.1.2.tar.{gz,bz2} (preformatted docs)
git-manpages-1.6.1.2.tar.{gz,bz2} (preformatted docs)
The RPM binary packages for a few architectures are also provided
as courtesy.
RPMS/$arch/git-*-1.6.1.2-1.fc9.$arch.rpm (RPM)
People with 1.6.1 or 1.6.1.1, who push into a repository that borrows
objects from other repositories via "alternates" mechanism (most of the
linux kernel subsystems hosted on k.org, and "forks" on various public
hosting site such as repo.or.cz and github fall into this category), may
want to upgrade to this version, as these two versions have a buggy "git
push" that does not like such a repository served by git 1.6.1 or newer.
GIT v1.6.1.2 Release Notes
==========================
Fixes since v1.6.1.1
--------------------
* The logic for rename detectin in internal diff used by commands like
"git diff" and "git blame" have been optimized to avoid loading the same
blob repeatedly.
* We did not allow writing out a blob that is larger than 2GB for no good
reason.
* "git format-patch -o $dir", when $dir is a relative directory, used it
as relative to the root of the work tree, not relative to the current
directory.
* v1.6.1 introduced an optimization for "git push" into a repository (A)
that borrows its objects from another repository (B) to avoid sending
objects that are available in repository B, when they are not yet used
by repository A. However the code on the "git push" sender side was
buggy and did not work when repository B had new objects that are not
known by the sender. This caused pushing into a "forked" repository
served by v1.6.1 software using "git push" from v1.6.1 sometimes did not
work. The bug was purely on the "git push" sender side, and has been
corrected.
* "git status -v" did not paint its diff output in colour even when
color.ui configuration was set.
* "git ls-tree" learned --full-tree option to help Porcelain scripts that
want to always see the full path regardless of the current working
directory.
* "git grep" incorrectly searched in work tree paths even when they are
marked as assume-unchanged. It now searches in the index entries.
* "git gc" with no grace period needlessly ejected packed but unreachable
objects in their loose form, only to delete them right away.
----------------------------------------------------------------
Changes since v1.6.1.1 are as follows:
Björn Steinbrink (1):
Rename detection: Avoid repeated filespec population
Jeff King (1):
avoid 31-bit truncation in write_loose_object
Johannes Schindelin (2):
get_sha1_basic(): fix invalid memory access, found by valgrind
test-path-utils: Fix off by one, found by valgrind
Junio C Hamano (4):
ls-tree: add --full-tree option
Teach format-patch to handle output directory relative to cwd
send-pack: do not send unknown object name from ".have" to pack-objects
GIT 1.6.1.2
Marcel M. Cary (1):
git-sh-setup: Fix scripts whose PWD is a symlink to a work-dir on OS X
Markus Heidelberg (2):
git-commit: color status output when color.ui is set
git-status -v: color diff output when color.ui is set
Nanako Shiraishi (1):
Document git-ls-tree --full-tree
Nguyễn Thái Ngọc Duy (2):
grep: support --no-ext-grep to test builtin grep
grep: grep cache entries if they are "assume unchanged"
Nicolas Pitre (1):
objects to be pruned immediately don't have to be loosened
^ permalink raw reply
* Re: [PATCH] Support various HTTP authentication methods
From: Johannes Sixt @ 2009-01-29 10:18 UTC (permalink / raw)
To: Moriyoshi Koizumi; +Cc: git
In-Reply-To: <1233221532.21518.1.camel@lena.gsc.riken.jp>
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...
>
> + 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);
... and here again. Is that necessary?
-- Hannes
^ permalink raw reply
* Re: Emacs git-mode feature request: support fill-paragraph correctly
From: Alexandre Julliard @ 2009-01-29 10:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Peter Simons
In-Reply-To: <7vk58fktfy.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Peter Simons <simons@cryp.to> writes:
>
>> that patch has the desired effect (tested with GNU Emacs 22.3.1 and
>> GIT 1.6.1). Thank you very much.
>>
>> Now, I'd be hugely in favor of applying that change to the repository
>> so that future versions of GIT have it.
>
> Alexandre?
Sure, I'll include it in my next pull request.
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply
* Re: Something weird is happening...
From: Ingo Molnar @ 2009-01-29 10:50 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Git Mailing List
In-Reply-To: <49814BA4.6030705@zytor.com>
* H. Peter Anvin <hpa@zytor.com> wrote:
> I was investigating a problem that Ingo Molnar reported on the
> linux-2.6-tip.git repository on kernel.org. Unfortunately I was not
> able to reproduce his problem (which is a problem in itself) but I did
> run into another oddity:
>
> : hera 4 ; git fsck
>
> [lots of dangling commits deleted]
> missing blob af0e01d4c663a101f48614e40d006ed6272d5c36
This problem went away as i downgraded my version of Git from the 'maint'
branch to a distro 1.6.0 version.
Ingo
^ permalink raw reply
* Re: Something weird is happening...
From: Ingo Molnar @ 2009-01-29 10:52 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Git Mailing List
In-Reply-To: <20090129105003.GB10987@elte.hu>
* Ingo Molnar <mingo@elte.hu> wrote:
>
> * H. Peter Anvin <hpa@zytor.com> wrote:
>
> > I was investigating a problem that Ingo Molnar reported on the
> > linux-2.6-tip.git repository on kernel.org. Unfortunately I was not
> > able to reproduce his problem (which is a problem in itself) but I did
> > run into another oddity:
> >
> > : hera 4 ; git fsck
> >
> > [lots of dangling commits deleted]
> > missing blob af0e01d4c663a101f48614e40d006ed6272d5c36
>
> This problem went away as i downgraded my version of Git from the
> 'maint' branch to a distro 1.6.0 version.
the last 'bad' version of git that i tried was:
v1.6.1.1-259-g8712b3c
the 'good' version is:
git version 1.6.0.6
but i had a previous version as well, about 2 weeks older than
v1.6.1.1-259-g8712b3c - and it only started triggering these problems once
the kernel.org upgrade happened. I have no clean reproducer so you can
ignore this - my use of versions was a bit messy.
Ingo
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)
From: Sverre Rabbelier @ 2009-01-29 11:27 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20090129035138.GC11836@coredump.intra.peff.net>
On Thu, Jan 29, 2009 at 04:51, Jeff King <peff@peff.net> wrote:
> $ mkdir parent && (cd parent && git init)
> Initialized empty Git repository in /home/peff/parent/.git/
>
> $ git clone parent child
> Initialized empty Git repository in /home/peff/child/.git/
> warning: You appear to have cloned an empty repository.
>
> So far so good...
>
> $ (cd parent && echo content >file && git add file && git commit -m one)
> [normal commit output]
> $ (cd child && git fetch)
> [normal fetch output]
I thought instead we wanted to support the following workflow:
$ (cd child && echo content >file && git add file && git commit -m one)
[normal commit output]
Which is what the testcase tests. E.g., we want to support cloning an
empty repo so that the user can then _push_ to that repository to make
it non-empty, no?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)
From: Jeff King @ 2009-01-29 11:37 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Junio C Hamano, git
In-Reply-To: <bd6139dc0901290327u572cc30ci9dc719c912fbf875@mail.gmail.com>
On Thu, Jan 29, 2009 at 12:27:23PM +0100, Sverre Rabbelier wrote:
> I thought instead we wanted to support the following workflow:
>
> $ (cd child && echo content >file && git add file && git commit -m one)
> [normal commit output]
>
> Which is what the testcase tests. E.g., we want to support cloning an
> empty repo so that the user can then _push_ to that repository to make
> it non-empty, no?
True, that is probably going to be more common (otherwise, why would the
person who is going to push into the empty repo advertise it to you
before they have put any content in it).
But it will probably still be surprising not to have the branch merging
setup:
mkdir parent && (cd parent && git init) &&
git clone parent child && cd child &&
echo content >file && git add file && git commit -m one &&
git push origin master ;# note we have to explicitly mention the branch
... time passes ...
git pull
produces the "you haven't asked me which branch to merge" message.
Which does make some sense, given how tracking configuration is set up.
It's just that it's a little sad that cloning an empty repository and
then later getting commits out of it (whether commits you put in or
somebody else) does not behave the same as cloning a repository with
commits.
Which I thought was sort of the point, that this would work seamlessly.
Otherwise, there is not much advantage over:
mkdir parent && (cd parent && git init) &&
mkdir child && cd child && git init &&
echo content >file && git add file && git commit -m one &&
git push origin master ;# note we have to explicitly mention the branch
With the empty clone, you get your "origin" remote set up, but in both
cases you are missing the branch tracking.
I don't know if there is a good solution, though. Perhaps it's best to
just let what's there get released and see if people complain.
-Peff
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)
From: Pieter de Bie @ 2009-01-29 11:40 UTC (permalink / raw)
To: Jeff King; +Cc: Sverre Rabbelier, Junio C Hamano, git
In-Reply-To: <20090129113735.GA6505@coredump.intra.peff.net>
On 29 jan 2009, at 11:37, Jeff King wrote:
> git push origin master ;# note we have to explicitly mention the
> branch
>
> ... time passes ...
>
> git pull
>
> produces the "you haven't asked me which branch to merge" message.
>
> Which does make some sense, given how tracking configuration is set
> up.
> It's just that it's a little sad that cloning an empty repository and
> then later getting commits out of it (whether commits you put in or
> somebody else) does not behave the same as cloning a repository with
> commits.
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.
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)
From: Sverre Rabbelier @ 2009-01-29 11:45 UTC (permalink / raw)
To: Pieter de Bie; +Cc: Jeff King, Junio C Hamano, git
In-Reply-To: <351A6988-32EB-473F-B6E5-8FBB38D91F88@ai.rug.nl>
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.
--
Cheers,
Sverre Rabbelier
^ 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
* 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: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
* 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: 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
* 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: 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: 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: 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: "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
* [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: 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
* 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: [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
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