git mailing list

FromSubjectsort iconDate
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 daytodaynext day
February 7, 2008February 8, 2008February 9, 2008