| From | Subject | Date |
|---|---|---|
| Jakub Narebski | Re: [PATCH] RFC: git lazy clone proof-of-concept
Why not in info/alternates?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
-
| Feb 8, 5:35 pm 2008 |
| Johannes Schindelin | Re: [PATCH] RFC: git lazy clone proof-of-concept
Hi,
[I'll just Cc you, out of the goodness of my heart.]
> >> +
| Feb 8, 5:52 pm 2008 |
| Mike Hommey | Re: [PATCH] RFC: git lazy clone proof-of-concept
Also note that the http transport uses info/http-alternates for http://
urls. By the way, it doesn't make much sense that only http-fetch uses
it.
Mike
-
| Feb 8, 6:03 pm 2008 |
| Johannes Schindelin | Re: [PATCH] RFC: git lazy clone proof-of-concept
Hi,
I think it does make sense: nobody else needs http-alternates.
Ciao,
Dscho
-
| Feb 8, 6:34 pm 2008 |
| Mike Hommey | Re: [PATCH] RFC: git lazy clone proof-of-concept
If you're setting an http-alternate, it means objects are missing in the
repo. If they are missing in the repo and are not in alternates, how can
any other command needing objects out there work on the repo ?
Mike
-
| Feb 8, 6:50 pm 2008 |
| Johannes Schindelin | Re: [PATCH] RFC: git lazy clone proof-of-concept
Hi,
The point is: if you have a bare repository on a server that uses
alternates, that path stored in info/alternates is usable by git-daemon.
But it is not usable by git-http-fetch, since that does not have a
git-aware server side. So if you want to reuse the _same_ bare repository
_with_ alternates for both git:// transport and http:// transport, you
_need_ to _different_ alternates: one being a path on the server, and
another being an http:// url for http-fetch.
Hth,
Dscho
-
| Feb 8, 7:14 pm 2008 |
| Mike Hommey | Re: [PATCH] RFC: git lazy clone proof-of-concept
But nothing prevents you from only setting an http-alternate. Also not
http-fetch can deal fine with info/alternates if it contains relative
paths.
Mike
-
| Feb 8, 7:38 pm 2008 |
| jaysoffian+git | [PATCH] Improve git-help--browse browser support under OS X
/usr/bin/open <document> is used under OS X to open a document just as if the
user had double-clicked on the file's icon. In other words, this will open HTML
files with the user's default browser. Note however that whether the document
opens in a new window, or in a new tab depends upon the browser configuration.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
---
git-web--browse.sh | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/git-web--browse.sh b/...
| Feb 8, 5:23 pm 2008 |
| Ville | [PATCH] Abort early if not being sourced under bash.
Subject: [PATCH] Abort early if not being sourced under bash.
This way, the file can be safely sourced from profile files shared with
non-bash shells, eg. dropped into /etc/profile.d like directories.
Signed-off-by: Ville Skyttä <ville.skytta@iki.fi>
---
contrib/completion/git-completion.bash | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 4ea727b..3cde9f4 100755
--- a/contri...
| Feb 8, 5:10 pm 2008 |
| Junio C Hamano | Re: [PATCH] Abort early if not being sourced under bash.
I do not particularly sympathize with the /etc/profile.d/
argument. Ditros can and should put a small script in there
that checks what /bin/sh it really is running and source the
real thing from elsewhere, perhaps /usr/share/git-core/,
appropriately.
However, even if you did so, there is another issue. One of my
hosts have a bash that does not know the "complete" command, and
logging into the host I get twenty-or-so "bash: complete:
command not found".
So
if bash "complete" would not wo...
| Feb 8, 5:31 pm 2008 |
| Johannes Schindelin | Re: [PATCH] Abort early if not being sourced under bash.
Hi,
On Fri, 8 Feb 2008, Ville Skytt
| Feb 8, 5:14 pm 2008 |
| Jari Aalto | [PATCH] Documentation/gitattributes.txt: Add an example box ...
Demonstrate the meaning of set, unset, set to value, unspecied in a
asciidoc 'listing block'.
---
Documentation/gitattributes.txt | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index 35a29fd..cd99a8e 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -52,6 +52,12 @@ Unspecified::
the path has or does not have the attribute, the
attribute for the path is said to...
| Feb 8, 2:28 pm 2008 |
| Jan Holesovsky | [PATCH] RFC: git lazy clone proof-of-concept
Hi,
This is my attempt to implement the 'lazy clone' I've read about a bit in the
git mailing list archive, but did not see implemented anywhere - the clone
that fetches a minimal amount of data with the possibility to download the
rest later (transparently!) when necessary. I am sorry to send it as a huge
patch, not as a series of patches, but as I don't know if I chose a way that is
acceptable for you [I'm new to the git code ;-)], I'd like to hear some
feedback first, and then I'll split it int...
| Feb 8, 1:28 pm 2008 |
| Johannes Schindelin | Re: [PATCH] RFC: git lazy clone proof-of-concept
Hi,
2nd part of my review:
I thought about this function again. It seems we have something similar
in builtin-pack-objects.c, which is easier to read. The equivalent would
be:
static void read_from_stdin(int *num, char ***records)
{
char line[4096];
int alloc = 0;
*num = 0;
*records = NULL;
for (;;) {
if (!fgets(line, sizeof(line), stdin)) {
if (feof(stdin))
break;
if (!ferror(stdin))
die("fgets returned NULL, not EOF, nor error!");
if (errno != EINTR)
...
| Feb 8, 4:16 pm 2008 |
| Jakub Narebski | Re: [PATCH] RFC: git lazy clone proof-of-concept
It was not implemented because it was thought to be hard; git assumes
in many places that if it has an object, it has all objects referenced
by it.
But it is very nice of you to [try to] implement 'lazy clone'/'remote
alternates'.
Could you provide some benchmarks (time, network throughtput, latency)
One of the reasons why 'lazy clone' was not implemented was the fact
that by using large enough window, and larger than default delta
length you can repack "archive pack" (and keep it from tryin...
| Feb 8, 3:00 pm 2008 |
| Jon Smirl | Re: [PATCH] RFC: git lazy clone proof-of-concept
A lot of memory is 2-4GB. Without this much memory you will trigger
swapping and the pack process will finish in about a month. Note that
only one machine needs to have this kind of memory. It can be used to
make the optimized pack of the project history and mark it with .keep
files. It doesn't take a lot of memory to use the optimized packs,
only to make them.
There are some patches for making repack work multi-core. Not sure if
they made it into the main git tree yet. These patches work almost
...
| Feb 8, 3:26 pm 2008 |
| Harvey Harrison | Re: [PATCH] RFC: git lazy clone proof-of-concept
Well, my modest little Celeron M laptop w/ 1GB of ram did the full
repack overnight on the gcc repo, so a month is a bit of an
exaggeration.
Cheers,
Harvey
-
| Feb 8, 4:19 pm 2008 |
| Jon Smirl | Re: [PATCH] RFC: git lazy clone proof-of-concept
Try it again with window=250 and depth=250. That's how you get the
--
Jon Smirl
jonsmirl@gmail.com
-
| Feb 8, 4:24 pm 2008 |
| Harvey Harrison | Re: [PATCH] RFC: git lazy clone proof-of-concept
Yes, I know, and I did if you remember back to the gcc discussion.
Harvey
-
| Feb 8, 4:25 pm 2008 |
| Jon Smirl | Re: [PATCH] RFC: git lazy clone proof-of-concept
Now that you mention it I seem to recall some changes were made to git
during that discussion that reduced the memory footprint and made the
optimized gcc repack fit into 1GB. I've forgotten the exact timings
and git is a moving target. When I was working on Mozilla it needed
2.4GB to avoid swapping but that was with a much older git.
The rule is: if it starts swapping it is going to take way longer that
you are probably willing to wait. Buying more RAM is a cheap and easy
fix.
If people are h...
| Feb 8, 4:41 pm 2008 |
| Nicolas Pitre | Re: [PATCH] RFC: git lazy clone proof-of-concept
Yes, they are. You need to compile with"make THREADED_DELTA_SEARCH=yes"
or add THREADED_DELTA_SEARCH=yes into config.mak for it to be enabled
though. Then you have to set the pack.threads configuration variable
appropriately to use it.
Nicolas
-
| Feb 8, 4:09 pm 2008 |
| Mike Hommey | Re: [PATCH] RFC: git lazy clone proof-of-concept
<snip>
There are 2 things, here:
- Probably, you can make your pack smaller with proper window sizing.
Try taking a look at the "Git and GCC" that crossed borders between
the gcc and the git mailing lists.
- There are tricks to do roughly what you want without modifying git.
For example, you can prepare several "shared" clones of your repo (git
clone -s) and leave in each only a few branches. Cloning from these will
only pull the needed data.
Mike
-
| Feb 8, 2:49 pm 2008 |
| Johannes Schindelin | Re: [PATCH] RFC: git lazy clone proof-of-concept
Hi,
The problem is, of course, that the shared clones are not updated
automatically, whenever the big repository is updated.
Ciao,
Dscho
-
| Feb 8, 3:04 pm 2008 |
| Johannes Schindelin | Re: [PATCH] RFC: git lazy clone proof-of-concept
Hi,
You might want to make the full_info static, and only send the options the
This chunk could use ALLOC_GROW() quite nicely (would make it more
readable, and avoid errors). Also, I'd use alloc_nr() instead of the
You can initialise it to 0 right away...
Unfortunately, I have to go now... so I will review the rest
(from builtin-fetch.c on) later.
It's great seeing that you work on this!
Thanks,
Dscho
-
| Feb 8, 2:20 pm 2008 |
| Harvey Harrison | Re: [PATCH] RFC: git lazy clone proof-of-concept
For comparison, how big was the svn repo you're testing? My experience
has been about 15-20 times smaller than SVN once a tuned repack has
been done.
Cheers,
Harvey
-
| Feb 8, 2:14 pm 2008 |
| Nicolas Pitre | Re: [PATCH] RFC: git lazy clone proof-of-concept
How did you repack your repository?
We know that current defaults are not suitable for large projects. For
example, the gcc git repository shrinked from 1.5GB pack down to 230MB
after some tuning.
Nicolas
-
| Feb 8, 2:03 pm 2008 |
| H.Merijn Brand | [PATCH] opening files in remote.c should ensure it is openin...
HP-UX allows directories to be opened with fopen (path, "r"), which
will cause some translations that expect to read files, read dirs
instead. This patch makes sure the two fopen () calls in remote.c
only open the file if it is a file.
Signed-off-by: H.Merijn Brand <h.m.brand@xs4all.nl>
---
diff -pur git-1.5.4a/remote.c git-1.5.4b/remote.c
--- git-1.5.4a/remote.c 2008-01-27 09:04:18 +0100
+++ git-1.5.4/remote.c 2008-02-08 17:38:43 +0100
@@ -121,9 +121,18 @@ static struct branch *ma...
| Feb 8, 12:46 pm 2008 |
| Morten Welinder | Re: [PATCH] opening files in remote.c should ensure it is op...
That looks wrong. stat+fopen has a pointless race condition that
open+fstat+fdopen would not have.
Morten
-
| Feb 8, 4:15 pm 2008 |
| Junio C Hamano | Re: [PATCH] opening files in remote.c should ensure it is op...
That's true. How about doing something like this?
(1) in a new file "compat/gitfopen.c" have this:
#include "../git-compat-util.h"
#undef fopen
FILE *gitfopen(const char *path, const char *mode)
{
int fd, flags;
struct stat st;
if (mode[0] == 'w')
return fopen(path, mode);
switch (mode[0]) {
case 'r': flags = O_RDONLY; break;
case 'a': flags = O_APPEND; break;
default:
errno = EINVAL;
...
| Feb 8, 4:33 pm 2008 |
| Brandon Casey | Re: [PATCH] opening files in remote.c should ensure it is op...
Which ones _don't_ open directories?
Shouldn't fopen("path_to_some_directory", "r") work?
-brandon
#include <stdio.h>
int main(int argc, char* argv[])
{
if (!fopen(argv[1], "r")) {
perror("File open failed");
return 1;
}
puts("File open succeeded.");
return 0;
}
-
| Feb 8, 4:58 pm 2008 |
| Brandon Casey | Re: [PATCH] opening files in remote.c should ensure it is op...
Ok. It's the FOPEN_OPENS_DIRECTORIES term that confused me.
fopen is expected to succeed, even on directories. It's the read
that should fail but is not on HPUX. Obviously we don't want to
change the read.
-brandon
-
| Feb 8, 5:14 pm 2008 |
| Johannes Schindelin | Re: [PATCH] opening files in remote.c should ensure it is op...
Hi,
Funny... our emails crossed, and you picked the same name ;-)
Ciao,
Dscho
-
| Feb 8, 4:40 pm 2008 |
| Junio C Hamano | Re: [PATCH] opening files in remote.c should ensure it is op...
Bad Dscho.
It has been a very well kept secret that Dscho and Junio are one
and the same person, but you just spilled the beans.
;-)
-
| Feb 8, 5:19 pm 2008 |
| Johannes Schindelin | Re: [PATCH] opening files in remote.c should ensure it is op...
Hi,
Shush... left-hemisphere: shut up.
Ciao,
Dscho
P.S.: double ;-)
-
| Feb 8, 5:47 pm 2008 |
| Junio C Hamano | Re: [PATCH] opening files in remote.c should ensure it is op...
Can we make this a platform specific "compat" hack?
It is not fair to force stat() overhead to ports on platforms
that fails fopen() on directories, as I doubt we would ever want
from directory using fopen() anyway.
-
| Feb 8, 4:09 pm 2008 |
| Johannes Schindelin | Re: [PATCH] opening files in remote.c should ensure it is op...
Hi,
You mean something like
#ifdef FOPEN_OPENS_DIRECTORIES
inline static FILE *fopen_compat(const char *path, const char *mode)
{
struct stat st_buf;
if (stat(path, &st_buf) || !S_ISREG(st_buf.st_mode))
return NULL;
return (fopen(path, mode));
}
#define fopen fopen_compat
#endif
in git-compat-util.h, right?
Yeah, I can see that, even if I think the overhead would not be _that_
crucial. But it is a nice way of fixing _all_ fopen() calls at the...
| Feb 8, 4:38 pm 2008 |
| Mike Ralphson | Re: [PATCH] opening files in remote.c should ensure it is op...
Many thanks, this is also required for AIX. I had got some way to
tracking it down, but I thought it was an issue with strbuf. So...
Tested-by: Mike Ralphson <mike.ralphson@gmail.com>
Your other fix there [- if (!strbuf_avail(sb)) / + if
(strbuf_avail(sb) < 64) ] is, guess what, also required on AIX.
Thanks again.
-
| Feb 8, 1:25 pm 2008 |
| Daniel Barkalow | Re: [PATCH] opening files in remote.c should ensure it is op...
Does the following help? We really ought to know that ".." must be a path
literal (and there obviously should be more limitations on nicknames for
remotes, but I haven't figured out what they should be yet).
-Daniel
*This .sig left intentionally blank*
diff --git a/remote.c b/remote.c
index 0e00680..83a3d9d 100644
--- a/remote.c
+++ b/remote.c
@@ -348,7 +348,7 @@ struct remote *remote_get(const char *name)
if (!name)
name = default_remote_name;
ret = make...
| Feb 8, 4:36 pm 2008 |
| Johannes Schindelin | Re: [PATCH] opening files in remote.c should ensure it is op...
Hi,
You'll need to check for ".", too: "git pull . <branch>" was originally
the only way to merge a local branch, and it is still valid.
Ciao,
Dscho
-
| Feb 8, 4:44 pm 2008 |
| H.Merijn Brand | Re: [PATCH] opening files in remote.c should ensure it is op...
On Fri, 8 Feb 2008 17:25:52 +0000, "Mike Ralphson" <mike.ralphson@gmail.com>
Not there yet ...
$ cat do-tests
#!/bin/sh
export TAR=ntar
rm -f *.err
for t in t[0-9]*.sh ; do
echo $t
sh $t > test.err 2>&1 || mv test.err $t.err
rm -f test.err
done
$
197509 -rw-rw-rw- 1 merijn softwr 1633 Feb 8 18:03 t5302-pack-index.sh.err
196846 -rw-rw-rw- 1 merijn softwr 943 Feb 8 18:04 t5500-fetch-pack.sh.err
203431 -rw-rw-rw- 1 merijn softwr 344 Feb 8 18:05 t5600-c...
| Feb 8, 4:04 pm 2008 |
| Bruno Ribas | git.owner, hope everything is fine
Made final adjustments and hope it is OK now.
-
| Feb 8, 12:38 pm 2008 |
| Bruno Ribas | [PATCH] gitweb: Use the config file to set repository owner'...
Now gitweb checks if gitweb.owner exists before trying to get filesystem's
owner.
Allow to use configuration variable gitweb.owner set the repository owner,
it checks the gitweb.owner, if not set it uses filesystem directory's owner.
Useful when we don't want to maintain project list file, and all
repository directories have to have the same owner (for example when the
same SSH account is shared for all projects, using ssh_acl to control
access instead).
Signed-off-by: Bruno Ribas <ribas@c3...
| Feb 8, 12:38 pm 2008 |
| Bruno Ribas | [PATCH] gitweb: Update gitweb/README to include the new per-...
Signed-off-by: Bruno Ribas <ribas@c3sl.ufpr.br>
---
gitweb/README | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/gitweb/README b/gitweb/README
index 4c8bedf..2163071 100644
--- a/gitweb/README
+++ b/gitweb/README
@@ -233,6 +233,10 @@ You can use the following files in repository:
Displayed in the project summary page. You can use multiple-valued
gitweb.url repository configuration variable for that, but the file
takes precendence.
+ * gitweb.own...
| Feb 8, 12:38 pm 2008 |
| H.Merijn Brand | read_branches_file ()
I'm (again) trying to port git-1.5.4 to HP-UX, and I've already got rather
far, but I'm hitting some stuff I cannot explain.
t5405-send-pack-rewind.sh fails the 'git fetch .. master:master' part in
the setup, as deep down, read_branches_file () is called with in remote
the name "..".
The file that it tries to open using git_path () is ".git/branches/.."
That is weird. That is not a file, but a dir. "../.git/branches" would
be more logical, but whatever. HP-UX 11.00 will gladly return a valid
FIL...
| Feb 8, 11:50 am 2008 |
| Daniel Barkalow | Re: read_branches_file ()
It's doing this because it thinks you might have a remote configured with
the name "..", which should probably be blocked at a higher level, if only
for general sanity.
-Daniel
*This .sig left intentionally blank*
-
| Feb 8, 1:18 pm 2008 |
| H.Merijn Brand | Re: read_branches_file ()
On Fri, 8 Feb 2008 16:50:08 +0100, "H.Merijn Brand" <h.m.brand@xs4all.nl>
Something like this seems so `fix' this specific problem.
Feel free to take another approach, t5405 now passes
--8<--- remote.c.diff
--- remote.c.org 2008-01-27 09:04:18 +0100
+++ remote.c 2008-02-08 17:01:09 +0100
@@ -1,6 +1,7 @@
#include "cache.h"
#include "remote.h"
#include "refs.h"
+#include <sys/stat.h>
static struct remote **remotes;
static int allocated_remotes;
@@ -173,11 +174,...
| Feb 8, 12:03 pm 2008 |
| Johannes Schindelin | Re: read_branches_file ()
Hi,
Please use a more descriptive variable name, such as "branches_file" or
"branches_path".
Also, we only leave a space after operators like "for", "while", but not
Again, please remove the spaces after "stat" and "S_ISDIR".
Other than that, the patch looks obviously correct: please resubmit with a
nice commit message and a sign-off.
Thanks,
Dscho
-
| Feb 8, 12:22 pm 2008 |
| H.Merijn Brand | Re: read_branches_file ()
On Fri, 8 Feb 2008 16:22:45 +0000 (GMT), Johannes Schindelin
This patch was not sent to be applied as-is, only as a proof-of-concept
Not that I agree to the layout/indentation, the new patch is sent trying
Done
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using & porting perl 5.6.2, 5.8.x, 5.10.x on HP-UX 10.20, 11.00, 11.11,
& 11.23, SuSE 10.1 & 10.2, AIX 5.2, and Cygwin. http://qa.perl.org
http://mirrors.develooper.com/hpux/ ...
| Feb 8, 12:49 pm 2008 |
| Johannes Schindelin | [PATCH] Adjust .gitignore for 5884f1(Rename 'git-help--brows...
Since git-help--browse was renamed, we should ignore git-web--browse
instead.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
.gitignore | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/.gitignore b/.gitignore
index 1a73de0..a85d2e7 100644
--- a/.gitignore
+++ b/.gitignore
@@ -51,7 +51,6 @@ git-gc
git-get-tar-commit-id
git-grep
git-hash-object
-git-help--browse
git-http-fetch
git-http-push
git-imap-send
@@ -137,6 +136,7 @@ git-...
| Feb 8, 9:33 am 2008 |
| Jonathan del Strother | git log -S doesn't search stash WIPs
"git log --all -Sfoo" doesn't find strings introduced in stash WIP
commits, only the stash index. That is, if I do :
$ echo foo >> file
$ git add file
$ echo bar >> file
$ git stash
Saved working directory and index state "WIP on master: 00495fc... initial"
(To restore them type "git stash apply")
HEAD is now at 00495fc... initial
$ git log --all -Sfoo
commit a8834ce80ebdf84e6579280c1fc75cdb7b4ac7c9
Author: Jonathan del Strother <me@here.com>
Date: Fri Feb 8 10:43:44 2008 ...
| Feb 8, 6:46 am 2008 |
| previous day | today | next day |
|---|---|---|
| February 7, 2008 | February 8, 2008 | February 9, 2008 |
| Dave Hansen | [RFC][PATCH 0/4] kernel-based checkpoint restart |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| Bart Van Assche | Integration of SCST in the mainstream Linux kernel |
| Eric Paris | [RFC 0/5] [TALPA] Intro to a linux interface for on access scanning |
git: | |
| David Miller | Re: [GIT]: Networking |
| Natalie Protasevich | [BUG] New Kernel Bugs |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Jarek Poplawski | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
