* [PATCH] t3411: Fix test 1 for case-insensitive file systems
From: Brian Gernhardt @ 2009-01-29 16:00 UTC (permalink / raw)
To: Git List; +Cc: Junio C Hamano
The call to "git reset --hard B1" failed on case-insensitive file
systems (such as the default settings for HFS+) because there was both
a tag "B1" and a file "b1". Adding "--" to the command makes it
clear that we mean commit B1.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
---
t/t3411-rebase-preserve-around-merges.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/t3411-rebase-preserve-around-merges.sh b/t/t3411-rebase-preserve-around-merges.sh
index 6533505..e544451 100755
--- a/t/t3411-rebase-preserve-around-merges.sh
+++ b/t/t3411-rebase-preserve-around-merges.sh
@@ -24,7 +24,7 @@ test_expect_success 'setup' '
test_commit A1 &&
test_commit B1 &&
test_commit C1 &&
- git reset --hard B1 &&
+ git reset --hard B1 -- &&
test_commit D1 &&
test_merge E1 C1 &&
test_commit F1
--
1.6.1.2.418.gd79e6.dirty
^ permalink raw reply related
* Re: Appropriateness of git for digital video production versioning
From: Pau Garcia i Quiles @ 2009-01-29 15:48 UTC (permalink / raw)
To: Charles Earl; +Cc: git
In-Reply-To: <8c4a72800901290736p4952e53byddca243f300dd8af@mail.gmail.com>
Hello,
Git is not the appropriate tool. What about using a filesystem with
versioning support? tux3, btrfs, ZFS and NILFS may work for you.
On Thu, Jan 29, 2009 at 4:36 PM, Charles Earl <charles.cearl@gmail.com> wrote:
> Hi,
> Are there past instances of git having been adapted to support version
> control of digital media production workflow?
> I'm evaluating CMS and versioning systems for the backend of a SaaS
> for digital media production workflow.
> The bulk of content stored is binary data -- there have been posts on
> this about integration of various binary diff implemetations with git.
> The versioning of metadata, scripts, project structure seems to argue
> for applicability of system such as git -- these fit the paradigm of
> traditional scm.
> Example content is from media production suites such as Adobe After
> Effects/Premier: video, compositions, etc.
> I'd also like the object storage to be in S3/Amazon BlockStore or
> similar remote stores.
> Charles
> --
> 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
>
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
^ permalink raw reply
* Re: Appropriateness of git for digital video production versioning
From: Shawn O. Pearce @ 2009-01-29 15:45 UTC (permalink / raw)
To: Charles Earl; +Cc: git
In-Reply-To: <8c4a72800901290736p4952e53byddca243f300dd8af@mail.gmail.com>
Charles Earl <charles.cearl@gmail.com> wrote:
> Are there past instances of git having been adapted to support version
> control of digital media production workflow?
You are going to run into scaling problems. Git works under the
assumption that it can malloc() at least 2 complete copies of a
file at once, in the same process.
Last time I mucked around with digital media production, the volume
of data in a video file was *huge*. Its workable on modern systems
with terabyte disk arrays and so forth, but modern systems still
can't afford the 100 GB of RAM necessary to allow Git to malloc()
up two blocks of a single 40 GB video file.
Also, since clients pretty much grab the entire repository when they
clone it for working access, its going to suck down the entire media
archive, *all* versions. That could be well into the hundreds of
TB range and may never complete.
> The bulk of content stored is binary data -- there have been posts on
> this about integration of various binary diff implemetations with git.
You mention later about using S3 or BlockStore to hold the binary
content. Maybe the large binary data should be stored in S3, and
the Git repository just holds the metadata and scripts, including
scripts to perform downloads/uploads through S3.
> The versioning of metadata, scripts, project structure seems to argue
> for applicability of system such as git -- these fit the paradigm of
> traditional scm.
Yea, that's more typical of what Git was designed and built to store.
> Example content is from media production suites such as Adobe After
> Effects/Premier: video, compositions, etc.
> I'd also like the object storage to be in S3/Amazon BlockStore or
> similar remote stores.
My suggestion?
Use Git for your metadata and scripts. Include a few scripts that
can download the large media files from S3 when they are needed,
and upload new versions when they are modified.
If you want to store versions over time of the files, sha1sum
the media file and use that as the key name in the S3 bucket,
and store the output of sha1sum into a file within Git. E.g. a
".media" text file just listing out sha1sum and path names:
ceba7222551c722836564535697947e8a9b3e7ce big_file.mpg
75c8f5ecb97ec67c1ec949b16c72e6ba1361a528 other_file.mpg
and use a simple script to edit/read that file, accessing S3 as
necessary for the operations.
--
Shawn.
^ permalink raw reply
* how to clean up remote/ref
From: bill lam @ 2009-01-29 15:42 UTC (permalink / raw)
To: git
When I migrated from svn to git, I keep updating svn repo and also
added a dummy git repo, Now the GIT_DIR/config look likes
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[svn-remote "svn"]
url = http://localhost/svn/project2/
fetch = :refs/remotes/trunk
[remote "origin"]
url = http://bl@localhost/git-repo/project/
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
Now I feel I don't need update the svn repo (actually it was inactive
for more than 1 year after a few updates). Also I no longer want to
use http protocol to remote git repo.
It said the HEAD is different that orgin/master
$ git checkout master
Switched to branch "master"
Your branch and 'origin/master' have diverged,
and have 71 and 24 different commit(s) each, respectively.
How do it
1. remove any reference to the svn repo [svn-remote "svn"]
2. remove reference to the http [remote "origin"]
3. setup a new empty git as the new remote repos
thanks
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
唐詩277 柳中庸 征人怨
歲歲金河復玉關 朝朝馬策與刀環 三春白雪歸青塚 萬里黃河繞黑山
^ permalink raw reply
* Appropriateness of git for digital video production versioning
From: Charles Earl @ 2009-01-29 15:36 UTC (permalink / raw)
To: git
Hi,
Are there past instances of git having been adapted to support version
control of digital media production workflow?
I'm evaluating CMS and versioning systems for the backend of a SaaS
for digital media production workflow.
The bulk of content stored is binary data -- there have been posts on
this about integration of various binary diff implemetations with git.
The versioning of metadata, scripts, project structure seems to argue
for applicability of system such as git -- these fit the paradigm of
traditional scm.
Example content is from media production suites such as Adobe After
Effects/Premier: video, compositions, etc.
I'd also like the object storage to be in S3/Amazon BlockStore or
similar remote stores.
Charles
^ permalink raw reply
* [PATCH,v2] git-bundle(1): add no references required simplest case
From: jidanni @ 2009-01-29 15:32 UTC (permalink / raw)
To: gitster; +Cc: mdl123, spearce, git
In-Reply-To: <7vljsx6dzi.fsf@gitster.siamese.dyndns.org>
Signed-off-by: jidanni <jidanni@jidanni.org>
---
Words totally by Junio C Hamano.
Documentation/git-bundle.txt | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-bundle.txt b/Documentation/git-bundle.txt
index 1b66ab7..42c2abc 100644
--- a/Documentation/git-bundle.txt
+++ b/Documentation/git-bundle.txt
@@ -164,6 +164,22 @@ $ git pull bundle
would treat it as if it is talking with a remote side over the
network.
+A complete bundle is one that does not require you to have any
+prerequisite object for you to extract its contents. Not only you
+can fetch/pull from a bundle, you can clone from a complete bundle
+as if it was a remote repository, like this:
+
+----------------
+$ git clone /home/me/tmp/file.bdl mine.git
+----------------
+
+This will define a remote called "origin" in the resulting
+repository that lets you fetch and pull from the bundle, just
+like the previous example lets you do with the remote called
+"bundle", and from then on you can fetch/pull to update the
+resulting mine.git repository after replacing the bundle you store
+at /home/me/tmp/file.bdl with incremental updates.
+
Author
------
Written by Mark Levedahl <mdl123@verizon.net>
--
1.6.0.6
^ permalink raw reply related
* Re: [PATCH v2] http-push: refactor request url creation
From: Johannes Schindelin @ 2009-01-29 15:10 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: git, Junio C Hamano
In-Reply-To: <4981C43B.9030409@gmail.com>
Hi,
On Thu, 29 Jan 2009, Tay Ray Chuan wrote:
> Currently, functions that deal with objects on the remote repository have to
> allocate and
> do strcpys to generate the URL.
That is a funny way to wrap the commit message :-)
> +static void append_remote_object_url(struct strbuf *buf, const char *url,
> const char *hex, int only_two_digit_prefix)
Here, you still have a corrupt patch. Which might be helped by wrapping
the overly long line in the first place?
Ciao,
Dscho
^ permalink raw reply
* [PATCH v2] http-push: refactor request url creation
From: Tay Ray Chuan @ 2009-01-29 14:59 UTC (permalink / raw)
To: git, Junio C Hamano
Currently, functions that deal with objects on the remote repository have to allocate and
do strcpys to generate the URL.
This patch saves them this trouble, by providing two functions, "append_remote_object_url"
and "get_remote_object_url".
Both generate a URL, with either the object's 2-digit hex directory (eg. /objects/a1/), or
the complete object location (eg. /objects/a1/b2).
However, they differ in that "append_remote_object_url" appends this URL to a strbuf, while
"get_remote_object_url" wraps around the former and returns the URL directly in char*.
Users usually would use "get_remote_object_url", but may find "append_remote_object_url"
useful if they require further string operations on the URL.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Acked-by: Junio C Hamano <gitster@pobox.com>
---
* renamed only_two_digit_postfix in original patch to only_two_digit_prefix
* rebased and generated on master (5dc1308)
* updated with Junio's changes (if (...) and fix memory leak)
* updated with Junio's double interface
* added back use of temporary string "url" in "start_fetch_loose"
* rebased and generated on master (a34a9db)
http-push.c | 62 +++++++++++++++++++++++-----------------------------------
1 files changed, 25 insertions(+), 37 deletions(-)
diff --git a/http-push.c b/http-push.c
index 59037df..816e658 100644
--- a/http-push.c
+++ b/http-push.c
@@ -209,6 +209,20 @@ static struct curl_slist *get_dav_token_headers(struct remote_lock *lock, enum d
return dav_headers;
}
+static void append_remote_object_url(struct strbuf *buf, const char *url, const char *hex, int only_two_digit_prefix)
+{
+ strbuf_addf(buf, "%sobjects/%.*s/", url, 2, hex);
+ if (!only_two_digit_prefix)
+ strbuf_addf(buf, "%s", hex+2);
+}
+
+static char *get_remote_object_url(const char *url, const char *hex, int only_two_digit_prefix)
+{
+ struct strbuf buf = STRBUF_INIT;
+ append_remote_object_url(&buf, url, hex, only_two_digit_prefix);
+ return strbuf_detach(&buf, NULL);
+}
+
static void finish_request(struct transfer_request *request);
static void release_request(struct transfer_request *request);
@@ -255,7 +269,6 @@ static void start_fetch_loose(struct transfer_request *request)
char *filename;
char prevfile[PATH_MAX];
char *url;
- char *posn;
int prevlocal;
unsigned char prev_buf[PREV_BUF_SIZE];
ssize_t prev_read = 0;
@@ -305,17 +318,8 @@ static void start_fetch_loose(struct transfer_request *request)
git_SHA1_Init(&request->c);
- url = xmalloc(strlen(remote->url) + 50);
- request->url = xmalloc(strlen(remote->url) + 50);
- strcpy(url, remote->url);
- posn = url + strlen(remote->url);
- strcpy(posn, "objects/");
- posn += 8;
- memcpy(posn, hex, 2);
- posn += 2;
- *(posn++) = '/';
- strcpy(posn, hex + 2);
- strcpy(request->url, url);
+ url = get_remote_object_url(remote->url, hex, 0);
+ request->url = xstrdup(url);
/* If a previous temp file is present, process what was already
fetched. */
@@ -388,16 +392,8 @@ static void start_mkcol(struct transfer_request *request)
{
char *hex = sha1_to_hex(request->obj->sha1);
struct active_request_slot *slot;
- char *posn;
- request->url = xmalloc(strlen(remote->url) + 13);
- strcpy(request->url, remote->url);
- posn = request->url + strlen(remote->url);
- strcpy(posn, "objects/");
- posn += 8;
- memcpy(posn, hex, 2);
- posn += 2;
- strcpy(posn, "/");
+ request->url = get_remote_object_url(remote->url, hex, 1);
slot = get_active_slot();
slot->callback_func = process_response;
@@ -512,7 +508,7 @@ static void start_put(struct transfer_request *request)
{
char *hex = sha1_to_hex(request->obj->sha1);
struct active_request_slot *slot;
- char *posn;
+ struct strbuf buf = STRBUF_INIT;
enum object_type type;
char hdr[50];
void *unpacked;
@@ -551,21 +547,13 @@ static void start_put(struct transfer_request *request)
request->buffer.buf.len = stream.total_out;
- request->url = xmalloc(strlen(remote->url) +
- strlen(request->lock->token) + 51);
- strcpy(request->url, remote->url);
- posn = request->url + strlen(remote->url);
- strcpy(posn, "objects/");
- posn += 8;
- memcpy(posn, hex, 2);
- posn += 2;
- *(posn++) = '/';
- strcpy(posn, hex + 2);
- request->dest = xmalloc(strlen(request->url) + 14);
- sprintf(request->dest, "Destination: %s", request->url);
- posn += 38;
- *(posn++) = '_';
- strcpy(posn, request->lock->token);
+ strbuf_addstr(&buf, "Destination: ");
+ append_remote_object_url(&buf, remote->url, hex, 0);
+ request->dest = strbuf_detach(&buf, NULL);
+
+ append_remote_object_url(&buf, remote->url, hex, 0);
+ strbuf_addstr(&buf, request->lock->token);
+ request->url = strbuf_detach(&buf, NULL);
slot = get_active_slot();
slot->callback_func = process_response;
--
1.6.1.1.241.gc53a6.dirty
^ permalink raw reply related
* Re: Valgrind updates
From: Johannes Schindelin @ 2009-01-29 14:54 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: <alpine.DEB.1.00.0901291510520.3586@pacific.mpi-cbg.de>
Hi,
On Thu, 29 Jan 2009, Johannes Schindelin wrote:
> 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).
Now, things get interesting.
Of course, I made sure that I had the newest zlib installed before
mentioning publically that I found a strange valgrind issue.
But I did not build it from source myself; I installed what Ubuntu Gutsy
Gibbon had to offer me.
Now that I tried to investigate further by compiling zlib from source,
instrumenting it with various valgrind-specific code to find out what is
actually happening, I cannot reproduce anymore!
So I searched for the sources that Ubuntu provides, and I _still_ cannot
reproduce.
So I'll just go for the easy solution, install plain straightforward
zlib-1.2.3 (as opposed to zlib_1.2.3.3.dfsg-12ubuntu1), and apologise to
y'all for all the bruhaha.
Ciao,
Dscho
P.S.: Note that there is still something fishy going on, as Ubuntu's zlib
generates the deflated stream correctly. But that will have to be
investigated by someone with substantially more time on her hands than me.
^ permalink raw reply
* Re: git clone --bare doesn't create refs/heads/*?
From: Tay Ray Chuan @ 2009-01-29 14:48 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20090129144036.GH21473@genesis.frugalware.org>
On Thu, Jan 29, 2009 at 10:40 PM, Miklos Vajna <vmiklos@frugalware.org> wrote:
> [ Please don't top-post. ]
Oops.
> Ah, packed refs. :)
>
> See man git-pack-refs, git clone uses it to pack refs after a clone.
> They are still in the 'packed-refs' file.
Thanks, that does clears things up.
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: Sporadic BSOD with msys git?
From: Mark Burton @ 2009-01-29 14:41 UTC (permalink / raw)
To: git
In-Reply-To: <20090129115442.6ce311f8@crow>
Hi,
Thanks for the responses.
The crash is in the XP guest, not the host (the host is a Linux box).
The XP image is quite old and has had quite a lot of stuff
installed/un-installed over time so I will try again using a fresh XP VM
updated with all the latest M$ fixes.
Cheers,
Mark
^ permalink raw reply
* Re: git clone --bare doesn't create refs/heads/*?
From: Miklos Vajna @ 2009-01-29 14:40 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: git
In-Reply-To: <be6fef0d0901290636m5b472499mdf614841a06ec978@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 563 bytes --]
[ Please don't top-post. ]
On Thu, Jan 29, 2009 at 10:36:26PM +0800, Tay Ray Chuan <rctay89@gmail.com> wrote:
> Hmm, no, --mirror adds extra remote tracking information.
>
> Quoting the git-clone man page:
>
> "...the branch heads at the remote are copied directly..."
>
> which is to say, git clone --bare isn't doing what it's supposed to do.
>
> that said, i'm not too sure about this, hence this thread.
Ah, packed refs. :)
See man git-pack-refs, git clone uses it to pack refs after a clone.
They are still in the 'packed-refs' file.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: git clone --bare doesn't create refs/heads/*?
From: Tay Ray Chuan @ 2009-01-29 14:36 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20090129142657.GG21473@genesis.frugalware.org>
Hmm, no, --mirror adds extra remote tracking information.
Quoting the git-clone man page:
"...the branch heads at the remote are copied directly..."
which is to say, git clone --bare isn't doing what it's supposed to do.
that said, i'm not too sure about this, hence this thread.
On Thu, Jan 29, 2009 at 10:26 PM, Miklos Vajna <vmiklos@frugalware.org> wrote:
> 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?
>
--
Cheers,
Ray Chuan
^ permalink raw reply
* 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
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