* Re: [ANNOUNCE] Git 1.7.8.rc0
From: Junio C Hamano @ 2011-11-03 23:02 UTC (permalink / raw)
To: Stefan Naewe, Jeff King; +Cc: Michael J Gruber, git
In-Reply-To: <20111102200947.GA5628@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Normally I would say to implement in favor of the no-netrc case, as it
> is probably more common (and will hopefully be more so after the auth
> helpers are finished). But the problem is that the penalties are
> different. On the one hand, we have the extra http round-trip. Which is
> annoying, but mostly invisible to the user. But on the other, we have
> git prompting the user unnecessarily, which is just awful.
Ok, so are we in agreement that Stefan's patch $gmane/184617 is the right
fix at least for the time being?
This will be a minor regression if left unfixed, so I'd like to have a
minimum fix in before I tag -rc1 over the weekend.
Could any one of you guys please care to package it up with a readable
commit log message with a sign-off?
^ permalink raw reply
* Re: [PATCHv2] Improve use of select in http backend
From: Junio C Hamano @ 2011-11-03 23:14 UTC (permalink / raw)
To: Mika Fischer; +Cc: git, Jeff King, daniel
In-Reply-To: <1320265288-12647-1-git-send-email-mika.fischer@zoopnet.de>
I re-read this thread once again, and my understanding of the current
situation on these two patch series is the following. Please correct me if
I am wrong.
* This is not a regression fix, this is not a correctness fix, but it is
a performance improvement;
* Jeff gave an idea for improvement around the use of (rather, not having
to use) data_received; and
* Mika understood Jeff's suggestion, but was hesitant due to one
potential issue around curl_multi_fdset() and asked Daniel's opinion,
to which Daniel responded that the worrysome situation would not
happen.
It appears to me that the next step is for Mika to decide either (1) we go
ahead with the original patch and leave the improvement for later, or (2)
update the patch as Jeff suggested and we review it again.
I can go either way, but whichever way you choose, I would want to see the
patches properly signed-off.
Thanks.
^ permalink raw reply
* Re: git rev-parse --since=1970-01-01 does not work reliably
From: Nguyen Thai Ngoc Duy @ 2011-11-03 23:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Dmitry V. Levin
In-Reply-To: <20111031231320.GA3857@do>
2011/11/1 Nguyen Thai Ngoc Duy <pclouds@gmail.com>:
> Subject: [PATCH] Do not accept negative time_t
>
> We use unsigned long internally to present time, negative value just
> breaks thing.
Junio, what do you think about this patch?
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
> date.c | 8 +++++++-
> 1 files changed, 7 insertions(+), 1 deletions(-)
>
> diff --git a/date.c b/date.c
> index 353e0a5..9cbd521 100644
> --- a/date.c
> +++ b/date.c
> @@ -653,8 +653,12 @@ int parse_date_basic(const char *date, unsigned long *timestamp, int *offset)
> if (*timestamp == -1)
> return -1;
>
> - if (!tm_gmt)
> + if (!tm_gmt) {
> + if ((time_t)*timestamp < (time_t)*offset * 60)
> + die("unsupported time before Epoch");
> *timestamp -= *offset * 60;
> + }
> +
> return 0; /* success */
> }
>
> @@ -722,6 +726,8 @@ static unsigned long update_tm(struct tm *tm, struct tm *now, unsigned long sec)
>
> n = mktime(tm) - sec;
> localtime_r(&n, tm);
> + if (n < 0)
> + die("unsupported time before Epoch");
> return n;
> }
>
> --
> 1.7.4.74.g639db
> -- 8< --
>
--
Duy
^ permalink raw reply
* Re: git rev-parse --since=1970-01-01 does not work reliably
From: Junio C Hamano @ 2011-11-04 0:36 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git, Dmitry V. Levin
In-Reply-To: <CACsJy8AewxbocqQ3gvgcrbSuNyKa0BCqDn6OV31m_6-P1AxJCA@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> 2011/11/1 Nguyen Thai Ngoc Duy <pclouds@gmail.com>:
>> Subject: [PATCH] Do not accept negative time_t
>>
>> We use unsigned long internally to present time, negative value just
>> breaks thing.
>
> Junio, what do you think about this patch?
At this late point in the release cycle, the topic itself is a Meh for me,
especially when other discussions for next cycle occupies my attention.
^ permalink raw reply
* [PATCHv2] Add options to specify snapshot file name, prefix
From: Thomas Guyot-Sionnest @ 2011-11-04 0:53 UTC (permalink / raw)
To: git; +Cc: Thomas Guyot-Sionnest
In-Reply-To: <1320302318-28315-1-git-send-email-dermoth@aei.ca>
commit b629275 implemented "smart" snapshot names and prefixes. I have
scripts that used to rely on the old behaviour which allowed in some
cases to have fixed prefix, and would require modifications to work with
newer Gitweb.
This patch adds two parameters for overriding the snapshot name and
prefix, sn and sp respectively. For example, to get a snapshot
named "myproject.[suffix]" with no prefix one can add this query string:
?sn=myproject;sp=
Signed-off-by: Thomas Guyot-Sionnest <dermoth@aei.ca>
---
gitweb/gitweb.perl | 12 +++++++++++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 4f0c3bd..9c91f01 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -756,6 +756,8 @@ our @cgi_param_mapping = (
searchtext => "s",
searchtype => "st",
snapshot_format => "sf",
+ snapshot_name => "sn",
+ snapshot_prefix => "sp",
extra_options => "opt",
search_use_regexp => "sr",
ctag => "by_tag",
@@ -6684,11 +6686,19 @@ sub git_snapshot {
}
my ($name, $prefix) = snapshot_name($project, $hash);
+ if (defined($input_params{'snapshot_name'})) {
+ $name = $input_params{'snapshot_name'};
+ }
+ if (defined($input_params{'snapshot_prefix'})) {
+ $prefix = $input_params{'snapshot_prefix'};
+ } else {
+ $prefix .= '/';
+ }
my $filename = "$name$known_snapshot_formats{$format}{'suffix'}";
my $cmd = quote_command(
git_cmd(), 'archive',
"--format=$known_snapshot_formats{$format}{'format'}",
- "--prefix=$prefix/", $hash);
+ "--prefix=$prefix", $hash);
if (exists $known_snapshot_formats{$format}{'compressor'}) {
$cmd .= ' | ' . quote_command(@{$known_snapshot_formats{$format}{'compressor'}});
}
--
1.7.7.1
^ permalink raw reply related
* Re: [PATCH] Escape file:// URL's to meet subversion SVN::Ra requirements
From: Ben Walton @ 2011-11-04 2:11 UTC (permalink / raw)
To: Eric Wong; +Cc: Jonathan Nieder, git
In-Reply-To: <20111102220941.GA3925@dcvr.yhbt.net>
Excerpts from Eric Wong's message of Wed Nov 02 18:09:41 -0400 2011:
Hi Eric,
> I don't have much time to help you fix it, but I got numerous errors
> on SVN 1.6.x (svn 1.6.12). Can you make sure things continue to
> work on 1.6 and earlier, also?
Yes, it's a bit of a mess, I think. It looks as though the
modification required within Git::SVN::Ra is going to negatively
impact other code paths that interact with that package from the
outside.
For example, when doing git svn init --minimize-url ..., the minimized
url is not escaped while the url is. The minimized url is used to
strip off the head from the full url using a regex. This now breaks
because of the escaping.
Fixing this locally to the use of the minimized url let me move on
farther but I then got another core dump.
> Maybe just enable the escaping for file:// on >= SVN 1.7
I think that it would be best if this change was only effective for
1.7.
I wonder if all URL-ish objects should be (conditionally iff svn >=
1.7) subjected to escaping?
This would require some restructuring and will take me a bit of time
to work out as I need to familiarize myself with the code to a deeper
level.
Pointers welcomed. :)
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
^ permalink raw reply
* [PATCH] fsck: print progress
From: Nguyễn Thái Ngọc Duy @ 2011-11-04 3:10 UTC (permalink / raw)
To: git, Junio C Hamano, Jeff King; +Cc: Nguyễn Thái Ngọc Duy
In-Reply-To: <20111103211819.GA17341@sigill.intra.peff.net>
fsck is usually a long process and it would be nice if it prints
progress from time to time.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
OK let's go with total object count for more accurate progress. One
thing I did not realize that the title is not copied to struct
progress and we can update title (e.g. current pack) while displaying
progress.
Updating once every 1024 objects may feel sluggish on large blobs,
but we have more important things to worry about when it comes to
large blobs than this progress bar.
multithread fsck sounds interesting, I'll look into it.
Documentation/git-fsck.txt | 12 +++++++++-
builtin/fsck.c | 49 ++++++++++++++++++++++++++++++++++++++++---
pack-check.c | 11 +++++++--
pack.h | 4 ++-
4 files changed, 67 insertions(+), 9 deletions(-)
diff --git a/Documentation/git-fsck.txt b/Documentation/git-fsck.txt
index a2a508d..5245101 100644
--- a/Documentation/git-fsck.txt
+++ b/Documentation/git-fsck.txt
@@ -10,7 +10,8 @@ SYNOPSIS
--------
[verse]
'git fsck' [--tags] [--root] [--unreachable] [--cache] [--no-reflogs]
- [--[no-]full] [--strict] [--verbose] [--lost-found] [<object>*]
+ [--[no-]full] [--strict] [--verbose] [--lost-found]
+ [--[no-]progress] [<object>*]
DESCRIPTION
-----------
@@ -72,6 +73,15 @@ index file, all SHA1 references in .git/refs/*, and all reflogs (unless
a blob, the contents are written into the file, rather than
its object name.
+--progress::
+--no-progress::
+ When fsck is run in a terminal, it will show the progress.
+ These options can force progress to be shown or not
+ regardless terminal check.
++
+Progress is not shown when --verbose is used. --progress is ignored
+in this case.
+
It tests SHA1 and general object sanity, and it does full tracking of
the resulting reachability and everything else. It prints out any
corruption it finds (missing or bad objects), and if you use the
diff --git a/builtin/fsck.c b/builtin/fsck.c
index df1a88b..e0cc4de 100644
--- a/builtin/fsck.c
+++ b/builtin/fsck.c
@@ -11,6 +11,7 @@
#include "fsck.h"
#include "parse-options.h"
#include "dir.h"
+#include "progress.h"
#define REACHABLE 0x0001
#define SEEN 0x0002
@@ -27,6 +28,8 @@ static const char *head_points_at;
static int errors_found;
static int write_lost_and_found;
static int verbose;
+static int show_progress = -1;
+
#define ERROR_OBJECT 01
#define ERROR_REACHABLE 02
@@ -512,15 +515,20 @@ static void get_default_heads(void)
static void fsck_object_dir(const char *path)
{
int i;
+ struct progress *progress = NULL;
if (verbose)
fprintf(stderr, "Checking object directory\n");
+ if (show_progress)
+ progress = start_progress("Checking object directories", 256);
for (i = 0; i < 256; i++) {
static char dir[4096];
sprintf(dir, "%s/%02x", path, i);
fsck_dir(i, dir);
+ display_progress(progress, i+1);
}
+ stop_progress(&progress);
fsck_sha1_list();
}
@@ -591,6 +599,7 @@ static struct option fsck_opts[] = {
OPT_BOOLEAN(0, "strict", &check_strict, "enable more strict checking"),
OPT_BOOLEAN(0, "lost-found", &write_lost_and_found,
"write dangling objects in .git/lost-found"),
+ OPT_BOOL (0, "progress", &show_progress, "show progress"),
OPT_END(),
};
@@ -603,6 +612,12 @@ int cmd_fsck(int argc, const char **argv, const char *prefix)
read_replace_refs = 0;
argc = parse_options(argc, argv, prefix, fsck_opts, fsck_usage, 0);
+
+ if (show_progress == -1)
+ show_progress = isatty(2);
+ if (verbose)
+ show_progress = 0;
+
if (write_lost_and_found) {
check_full = 1;
include_reflogs = 0;
@@ -622,20 +637,46 @@ int cmd_fsck(int argc, const char **argv, const char *prefix)
if (check_full) {
struct packed_git *p;
+ int i, nr_objects = 0, object_count;
+ struct progress *progress = NULL;
prepare_packed_git();
- for (p = packed_git; p; p = p->next)
+
+ if (show_progress) {
+ for (p = packed_git; p; p = p->next) {
+ if (open_pack_index(p))
+ continue;
+ nr_objects += p->num_objects;
+ }
+
+ object_count = 0;
+ progress = start_progress("Verifying packs", nr_objects);
+ }
+
+ for (i = 1, p = packed_git; p; p = p->next, i++) {
/* verify gives error messages itself */
- verify_pack(p);
+ verify_pack(p, progress, object_count);
+ object_count += p->num_objects;
+ }
+ stop_progress(&progress);
- for (p = packed_git; p; p = p->next) {
+ if (show_progress) {
+ object_count = 0;
+ progress = start_progress("Checking objects", nr_objects);
+ }
+
+ for (i = 1, p = packed_git; p; p = p->next, i++) {
uint32_t j, num;
if (open_pack_index(p))
continue;
num = p->num_objects;
- for (j = 0; j < num; j++)
+ for (j = 0; j < num; j++) {
fsck_sha1(nth_packed_object_sha1(p, j));
+ display_progress(progress, object_count + j+1);
+ }
+ object_count += p->num_objects;
}
+ stop_progress(&progress);
}
heads = 0;
diff --git a/pack-check.c b/pack-check.c
index 0c19b6e..80de302 100644
--- a/pack-check.c
+++ b/pack-check.c
@@ -1,6 +1,7 @@
#include "cache.h"
#include "pack.h"
#include "pack-revindex.h"
+#include "progress.h"
struct idx_entry {
off_t offset;
@@ -42,7 +43,8 @@ int check_pack_crc(struct packed_git *p, struct pack_window **w_curs,
}
static int verify_packfile(struct packed_git *p,
- struct pack_window **w_curs)
+ struct pack_window **w_curs,
+ struct progress *progress, uint32_t base_count)
{
off_t index_size = p->index_size;
const unsigned char *index_base = p->index_data;
@@ -126,7 +128,10 @@ static int verify_packfile(struct packed_git *p,
break;
}
free(data);
+ if (((base_count + i) & 1023) == 0)
+ display_progress(progress, base_count + i);
}
+ display_progress(progress, base_count + i);
free(entries);
return err;
@@ -155,7 +160,7 @@ int verify_pack_index(struct packed_git *p)
return err;
}
-int verify_pack(struct packed_git *p)
+int verify_pack(struct packed_git *p, struct progress *progress, uint32_t base_count)
{
int err = 0;
struct pack_window *w_curs = NULL;
@@ -164,7 +169,7 @@ int verify_pack(struct packed_git *p)
if (!p->index_data)
return -1;
- err |= verify_packfile(p, &w_curs);
+ err |= verify_packfile(p, &w_curs, progress, base_count);
unuse_pack(&w_curs);
return err;
diff --git a/pack.h b/pack.h
index 722a54e..3a63bf6 100644
--- a/pack.h
+++ b/pack.h
@@ -70,10 +70,12 @@ struct pack_idx_entry {
off_t offset;
};
+struct progress;
+
extern const char *write_idx_file(const char *index_name, struct pack_idx_entry **objects, int nr_objects, const struct pack_idx_option *, unsigned char *sha1);
extern int check_pack_crc(struct packed_git *p, struct pack_window **w_curs, off_t offset, off_t len, unsigned int nr);
extern int verify_pack_index(struct packed_git *);
-extern int verify_pack(struct packed_git *);
+extern int verify_pack(struct packed_git *, struct progress *, uint32_t);
extern void fixup_pack_header_footer(int, unsigned char *, const char *, uint32_t, unsigned char *, off_t);
extern char *index_pack_lockfile(int fd);
extern int encode_in_pack_object_header(enum object_type, uintmax_t, unsigned char *);
--
1.7.3.1.256.g2539c.dirty
^ permalink raw reply related
* Re: How to make "git push/pull" work in non-clone repo?
From: Hong-Ming Su @ 2011-11-04 3:33 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Kirill Likhodedov, git
In-Reply-To: <m2fwi5nnt8.fsf@igel.home>
git push -u can set upstream too.
Thanks all!
On Fri, Nov 4, 2011 at 1:00 AM, Andreas Schwab <schwab@linux-m68k.org> wrote:
> Hong-Ming Su <halleyinvent@gmail.com> writes:
>
>> /d/workspace/git/work1 (master)
>> $ git remote add origin ../depot
>
> $ git branch --set-upstream master origin/master
>
> Andreas.
>
> --
> Andreas Schwab, schwab@linux-m68k.org
> GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
> "And now for something completely different."
>
^ permalink raw reply
* Re: Folder level Acces in git
From: Joshua Jensen @ 2011-11-04 4:21 UTC (permalink / raw)
To: Eugene Sajine; +Cc: redhat1981, git
In-Reply-To: <CAPZPVFY15AqCpWcRbv0tjXBz4G2kQTm+nMGpsYzCKe0niHV_dA@mail.gmail.com>
----- Original Message -----
From: Eugene Sajine
Date: 11/3/2011 1:28 PM
> Are you sure that the way your have organized the repository is
> actually correct? If you need to manage the access on folder level why
> don't you simply split up the project into several
> repositories/projects which each team is going to work with
> independently?
>
> This seems to me to be much simpler and cleaner solution then any
> other alternative.
>
Submodules are _not_ simple at all. Our organization of nearly 100
developers using Git pretty much let out a collective cheer when we
finally removed the submodules. Submodules are an absolute pain to
develop within; there are a number of Git mailing list exchanges about
that, but I'd be happy to go into great detail if anybody cares. Even
submodules that are read-only are a pain as it takes two steps (git pull
+ git submodule update) to actually get them up to date.
Ick.
In short, if it is an absolute requirement to manage access to a
repository on a folder level, get Subversion or Perforce. DVCS is not
for you...
Josh
^ permalink raw reply
* Re: [PATCH] Escape file:// URL's to meet subversion SVN::Ra requirements
From: Jonathan Nieder @ 2011-11-04 6:38 UTC (permalink / raw)
To: Ben Walton; +Cc: Eric Wong, git
In-Reply-To: <1320372215-sup-8341@pinkfloyd.chass.utoronto.ca>
Ben Walton wrote:
> Fixing this locally to the use of the minimized url let me move on
> farther but I then got another core dump.
If it continues like this, it might be possible to get help from svn
developers.
E.g., I would love to see a nice summary of the relevant API changes,
like so (except with more truth):
Previously the svn_frob() function would accept a filename with
spaces in it in its "path" argument. Only the svn_plugh() function
and its relatives required escaped paths. And all functions
returning paths would unescape them.
With Subversion 1.7, passing a filename with a space in it to
svn_frob() trips an assertion, so we have to escape the "path"
argument. This requires ... changes in application code.
Unfortunately, back in Subversion 1.6, svn_frob() escapes its
argument, so an application modified as above will find its "path"
argument to be double-escaped. There does not seem to be any
way for applications to target both Subversion 1.6 and 1.7 without
doing ...
Subversion 1.8 should follow the following simple, consistent
semantics when requested with a flag, which would allow me to easily
target my code against both SVN >= 1.8 and <= 1.6 with a few "if"
statements (forgetting 1.7 as if it were a bad dream).
Or to put it another way: if getting git-svn to cooperate starts to
prove difficult, maybe abstracting away from git and understanding
what changed for libsvn callers in general could help. On one hand,
it could help in making sure the guarantees that libsvn offers are
well documented, stable in the future, and clear. On the other hand,
it might make the appropriate changes to git more obvious.
Sorry for the ramble. I wish I could offer a fix instead.
Jonathan
^ permalink raw reply
* [PATCH] http-push: don't always prompt for password
From: Stefan Naewe @ 2011-11-04 7:03 UTC (permalink / raw)
To: gitster, git, peff; +Cc: Stefan Naewe
In-Reply-To: <7vfwi6jucg.fsf@alter.siamese.dyndns.org>
http-push prompts for a password when the URL is set as
'https://user@host/repo' even though there is one set
in ~/.netrc. Pressing ENTER at the password prompt succeeds
then, but is a annoying and makes it almost useless
in a shell script, e.g.
Signed-off-by: Stefan Naewe <stefan.naewe@gmail.com>
---
http.c | 7 +++----
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/http.c b/http.c
index a4bc770..008ad72 100644
--- a/http.c
+++ b/http.c
@@ -279,8 +279,6 @@ static CURL *get_curl_handle(void)
curl_easy_setopt(result, CURLOPT_HTTPAUTH, CURLAUTH_ANY);
#endif
- init_curl_http_auth(result);
-
if (ssl_cert != NULL)
curl_easy_setopt(result, CURLOPT_SSLCERT, ssl_cert);
if (has_cert_password())
@@ -846,7 +844,7 @@ static int http_request(const char *url, void *result, int target, int options)
else if (missing_target(&results))
ret = HTTP_MISSING_TARGET;
else if (results.http_code == 401) {
- if (user_name) {
+ if (user_name && user_pass) {
ret = HTTP_NOAUTH;
} else {
/*
@@ -855,7 +853,8 @@ static int http_request(const char *url, void *result, int target, int options)
* but that is non-portable. Using git_getpass() can at least be stubbed
* on other platforms with a different implementation if/when necessary.
*/
- user_name = xstrdup(git_getpass_with_description("Username", description));
+ if (!user_name)
+ user_name = xstrdup(git_getpass_with_description("Username", description));
init_curl_http_auth(slot->curl);
ret = HTTP_REAUTH;
}
--
1.7.8.rc0.1.gb345ae
^ permalink raw reply related
* aliases causing “Permission denied” error in git v1.7
From: Алексей Данченков @ 2011-11-04 8:09 UTC (permalink / raw)
To: git
Hi!
$ git co -b newbranch
$ git co oldbranch
results in "fatal: cannot exec 'git-co': Permission denied" error.
In the same time, things like
$ git checkout -b newbranch
$ git checkout oldbranch
and
$ sudo git co -b newbranch
$ sudo git co oldbranch
work as expected. Ownership rights for the .git die are set for the user
and 0755/0644 are the mode for .git dir/subdir/files. There are no git-co
script anywhere in the system (as it is an alias to git-checkout, which
resides in /usr/libexec/git-core).
Aliases are defined in .gitconfig of the home dir:
[alias]
co = checkout
There is no difference in git config for root or normal user.
Things work well as expected when I install git v1.6. Going back to 1.7
gives me the same error.
What am I missing?
---
Gentoo / kernel v3.0.6 / git v1.7.3.4
^ permalink raw reply
* Re: Folder level Acces in git
From: Jens Lehmann @ 2011-11-04 8:42 UTC (permalink / raw)
To: Joshua Jensen; +Cc: Eugene Sajine, redhat1981, git
In-Reply-To: <4EB36855.8000802@workspacewhiz.com>
Am 04.11.2011 05:21, schrieb Joshua Jensen:
> ----- Original Message -----
> From: Eugene Sajine
> Date: 11/3/2011 1:28 PM
>> Are you sure that the way your have organized the repository is
>> actually correct? If you need to manage the access on folder level why
>> don't you simply split up the project into several
>> repositories/projects which each team is going to work with
>> independently?
>>
>> This seems to me to be much simpler and cleaner solution then any
>> other alternative.
>>
> Submodules are _not_ simple at all. Our organization of nearly 100 developers using Git pretty much let out a collective cheer when we finally removed the submodules. Submodules are an absolute pain to develop within; there are a number of Git mailing list exchanges about that, but I'd be happy to go into great detail if anybody cares.
I do care and would appreciate if you could share your problems.
> Even submodules that are read-only are a pain as it takes two steps (git pull + git submodule update) to actually get them up to date.
Full Ack. I'm working on teaching git to update update the whole
work tree - including the submodules - after each checkout, merge,
pull, bisect, etc. (which also includes proper support for deletion
and re-creation of submodules).
What else made using submodules hard for you?
^ permalink raw reply
* Re: New Feature wanted: Is it possible to let git clone continue last break point?
From: Clemens Buchacher @ 2011-11-04 8:56 UTC (permalink / raw)
To: Shawn Pearce
Cc: Jeff King, Junio C Hamano, Jonathan Nieder, netroby,
Git Mail List, Tomas Carnecky
In-Reply-To: <CAJo=hJt2kU10r5rq23qgimtW8dmzu-N92vjO_hNBbVVsKSpDmg@mail.gmail.com>
On Wed, Nov 02, 2011 at 09:19:03PM -0700, Shawn Pearce wrote:
>
> [...] But they can use sendfile() on the server they have and get
> a lot of improvement in clone speed due to lower system load,
> plus resumable clone for the relatively stable history part.
Setting aside the system load issue for now, couldn't we simply do
the following?
1. Figure out HAVE's and WANT's [1], based on which an ad-hoc pack
will be made and sent to the client.
2. Cache the information on disk (not the pack but the information
to re-create it), and give the client a 'ticket number' which
corresponds to that ad-hoc pack.
3. Start downloading the packfile
When the connection drops, we can resume like this:
1. Send the previously received 'ticket number', and the amount of
previously received data.
2. Re-generate the pack from the HAVE's and WANT's cached under
'ticket number'. (This may fail if the repo state has changed
such that previously accessible refs are now inaccessible.)
3. Resume download of that pack.
The upside of this approach is that it would work automatically,
without any manual setup by the server admin. All the previously
discussed ideas skip the step where we figure out the HAVE's and
WANT's. And to me that implies that we manually prepare a packfile
somewhere on disk, which contains what the user usually WANT's and
is allowed to have (think per-branch access control). Even if we
disregard access control, wouldn't that at least require the server
to create a "clean" pack which does not contain any objects from
the reflog?
The whole mirror thing could be pursued independently of the resume
capability, and if each git repo is capable of resuming the mirrors
can be plain git clones as well.
Just my 2 cents,
Clemens
^ permalink raw reply
* Find the size of git push in pre-receive hook
From: manigandans @ 2011-11-04 9:20 UTC (permalink / raw)
To: git
Hi,
I want to restrict the size of the push on the git remote repository. How
can I find the size of the push in pre-receive hook?
Thanks a lot in advance.
Best regards,
Manigandan S.
--
View this message in context: http://git.661346.n2.nabble.com/Find-the-size-of-git-push-in-pre-receive-hook-tp6962141p6962141.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: New Feature wanted: Is it possible to let git clone continue last break point?
From: Johannes Sixt @ 2011-11-04 9:35 UTC (permalink / raw)
To: Clemens Buchacher
Cc: Shawn Pearce, Jeff King, Junio C Hamano, Jonathan Nieder, netroby,
Git Mail List, Tomas Carnecky
In-Reply-To: <20111104085633.GA13924@ecki>
Am 11/4/2011 9:56, schrieb Clemens Buchacher:
> Cache ... not the pack but the information
> to re-create it...
It has been discussed. It doesn't work. Because with threaded pack
generation, the resulting pack is not deterministic.
-- Hannes
^ permalink raw reply
* Re: Find the size of git push in pre-receive hook
From: Magnus Bäck @ 2011-11-04 9:46 UTC (permalink / raw)
To: manigandans; +Cc: git
In-Reply-To: <1320398420796-6962141.post@n2.nabble.com>
On Friday, November 04, 2011 at 10:20 CET,
manigandans <etc.mani@gmail.com> wrote:
> I want to restrict the size of the push on the git remote repository.
> How can I find the size of the push in pre-receive hook?
What does "size of the push" mean to you? Number of bytes transmitted
over the wire? Number of commits pushed? Number of refs updated? Number
of files modified? Number of lines modified? Something else?
--
Magnus Bäck Opinions are my own and do not necessarily
SW Configuration Manager represent the ones of my employer, etc.
Sony Ericsson
^ permalink raw reply
* Re: How to find a commit that introduces (not removes) a string?
From: Sebastian Schuberth @ 2011-11-04 10:59 UTC (permalink / raw)
Cc: git, nkreitzinger, laksvij
In-Reply-To: <j8to8h$vqd$1@dough.gmane.org>
On 03.11.2011 10:50, Sebastian Schuberth wrote:
> I know about git log's -S / -G, but I'm unable to make these search through *introduced* strings only. Is there a way to do so?
Thanks for your suggestions. However, I ended up simply doing
$ git diff --no-color FROM..TO | grep ^+[^+] | grep WORD
which works well for my case.
--
Sebastian Schuberth
^ permalink raw reply
* important upgrade info for Fedora/EPEL RPM of gitolite
From: Sitaram Chamarty @ 2011-11-04 13:57 UTC (permalink / raw)
To: gitolite, git; +Cc: limb
[-- Attachment #1: Type: text/plain, Size: 843 bytes --]
Hello,
If you're using a Fedora/EPEL RPM of gitolite, and
upgraded/upgrading from 1.5.* to 2.*, then please do this as
soon as possible after the upgrade.
(1) look in ~/.gitolite.rc on the server for these variables:
$GL_PACKAGE_CONF
$GL_PACKAGE_HOOKS
If they are both defined, (and uncommented), you should be ok.
(2) if they are not defined, please add these lines at or near
the top of the file:
$GL_PACKAGE_CONF="/usr/share/gitolite/conf";
$GL_PACKAGE_HOOKS="/usr/share/gitolite/hooks";
Save the file, then run gl-setup (without any arguments).
This will fix up some issues related to the upgrade that
required variables in the rc which the RPM would not
automatically insert (per policy and for sanity in general!)
----
Thanks, and sorry for the trouble. If you have any questions
please feel free to ask.
Sitaram
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH v3 1/3] http.c: Use curl_multi_fdset to select on curl fds instead of just sleeping
From: Mika Fischer @ 2011-11-04 14:19 UTC (permalink / raw)
To: git; +Cc: gitster, daniel, peff, Mika Fischer
In-Reply-To: <1320416367-28843-1-git-send-email-mika.fischer@zoopnet.de>
Instead of sleeping unconditionally for a 50ms, when no data can be read
from the http connection(s), use curl_multi_fdset to obtain the actual
file descriptors of the open connections and use them in the select call.
This way, the 50ms sleep is interrupted when new data arrives.
Signed-off-by: Mika Fischer <mika.fischer@zoopnet.de>
---
http.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/http.c b/http.c
index a4bc770..ae92318 100644
--- a/http.c
+++ b/http.c
@@ -664,14 +664,14 @@ void run_active_slot(struct active_request_slot *slot)
}
if (slot->in_use && !data_received) {
- max_fd = 0;
+ max_fd = -1;
FD_ZERO(&readfds);
FD_ZERO(&writefds);
FD_ZERO(&excfds);
+ curl_multi_fdset(curlm, &readfds, &writefds, &excfds, &max_fd);
select_timeout.tv_sec = 0;
select_timeout.tv_usec = 50000;
- select(max_fd, &readfds, &writefds,
- &excfds, &select_timeout);
+ select(max_fd+1, &readfds, &writefds, &excfds, &select_timeout);
}
}
#else
--
1.7.8.rc0.35.gd9f16.dirty
^ permalink raw reply related
* [PATCH v3 0/3] Improve use of select in http backend
From: Mika Fischer @ 2011-11-04 14:19 UTC (permalink / raw)
To: git; +Cc: gitster, daniel, peff, Mika Fischer
In-Reply-To: <1320265288-12647-1-git-send-email-mika.fischer@zoopnet.de>
Changes since v2:
- Properly signed off
- Incorporated Jeff's suggestion of getting rid of data_received
altogether
And yes, this is just a performance improvement, not a bugfix.
Mika Fischer (3):
http.c: Use curl_multi_fdset to select on curl fds instead of just
sleeping
http.c: Use timeout suggested by curl instead of fixed 50ms timeout
http.c: Rely on select instead of tracking whether data was received
http.c | 42 +++++++++++++++++++++++-------------------
http.h | 1 -
2 files changed, 23 insertions(+), 20 deletions(-)
--
1.7.8.rc0.35.gd9f16.dirty
^ permalink raw reply
* [PATCH v3 2/3] http.c: Use timeout suggested by curl instead of fixed 50ms timeout
From: Mika Fischer @ 2011-11-04 14:19 UTC (permalink / raw)
To: git; +Cc: gitster, daniel, peff, Mika Fischer
In-Reply-To: <1320416367-28843-1-git-send-email-mika.fischer@zoopnet.de>
Recent versions of curl can suggest a period of time the library user
should sleep and try again, when curl is blocked on reading or writing
(or connecting). Use this timeout instead of always sleeping for 50ms.
Signed-off-by: Mika Fischer <mika.fischer@zoopnet.de>
---
http.c | 22 ++++++++++++++++++++--
1 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/http.c b/http.c
index ae92318..e91a2ab 100644
--- a/http.c
+++ b/http.c
@@ -649,6 +649,9 @@ void run_active_slot(struct active_request_slot *slot)
fd_set excfds;
int max_fd;
struct timeval select_timeout;
+#if LIBCURL_VERSION_NUM >= 0x070f04
+ long curl_timeout;
+#endif
int finished = 0;
slot->finished = &finished;
@@ -664,13 +667,28 @@ void run_active_slot(struct active_request_slot *slot)
}
if (slot->in_use && !data_received) {
+#if LIBCURL_VERSION_NUM >= 0x070f04
+ curl_multi_timeout(curlm, &curl_timeout);
+ if (curl_timeout == 0) {
+ continue;
+ } else if (curl_timeout == -1) {
+ select_timeout.tv_sec = 0;
+ select_timeout.tv_usec = 50000;
+ } else {
+ select_timeout.tv_sec = curl_timeout / 1000;
+ select_timeout.tv_usec = (curl_timeout % 1000) * 1000;
+ }
+#else
+ select_timeout.tv_sec = 0;
+ select_timeout.tv_usec = 50000;
+#endif
+
max_fd = -1;
FD_ZERO(&readfds);
FD_ZERO(&writefds);
FD_ZERO(&excfds);
curl_multi_fdset(curlm, &readfds, &writefds, &excfds, &max_fd);
- select_timeout.tv_sec = 0;
- select_timeout.tv_usec = 50000;
+
select(max_fd+1, &readfds, &writefds, &excfds, &select_timeout);
}
}
--
1.7.8.rc0.35.gd9f16.dirty
^ permalink raw reply related
* [PATCH v3 3/3] http.c: Rely on select instead of tracking whether data was received
From: Mika Fischer @ 2011-11-04 14:19 UTC (permalink / raw)
To: git; +Cc: gitster, daniel, peff, Mika Fischer
In-Reply-To: <1320416367-28843-1-git-send-email-mika.fischer@zoopnet.de>
Since now select is used with the file descriptors of the http connections,
tracking whether data was received recently (and trying to read more in
that case) is no longer necessary. Instead, always call select and rely on
it to return as soon as new data can be read.
Signed-off-by: Mika Fischer <mika.fischer@zoopnet.de>
---
http.c | 16 +---------------
http.h | 1 -
2 files changed, 1 insertions(+), 16 deletions(-)
diff --git a/http.c b/http.c
index e91a2ab..3c6a00b 100644
--- a/http.c
+++ b/http.c
@@ -4,7 +4,6 @@
#include "run-command.h"
#include "url.h"
-int data_received;
int active_requests;
int http_is_verbose;
size_t http_post_buffer = 16 * LARGE_PACKET_MAX;
@@ -99,13 +98,11 @@ size_t fwrite_buffer(char *ptr, size_t eltsize, size_t nmemb, void *buffer_)
struct strbuf *buffer = buffer_;
strbuf_add(buffer, ptr, size);
- data_received++;
return size;
}
size_t fwrite_null(char *ptr, size_t eltsize, size_t nmemb, void *strbuf)
{
- data_received++;
return eltsize * nmemb;
}
@@ -642,8 +639,6 @@ void step_active_slots(void)
void run_active_slot(struct active_request_slot *slot)
{
#ifdef USE_CURL_MULTI
- long last_pos = 0;
- long current_pos;
fd_set readfds;
fd_set writefds;
fd_set excfds;
@@ -656,17 +651,9 @@ void run_active_slot(struct active_request_slot *slot)
slot->finished = &finished;
while (!finished) {
- data_received = 0;
step_active_slots();
- if (!data_received && slot->local != NULL) {
- current_pos = ftell(slot->local);
- if (current_pos > last_pos)
- data_received++;
- last_pos = current_pos;
- }
-
- if (slot->in_use && !data_received) {
+ if (slot->in_use) {
#if LIBCURL_VERSION_NUM >= 0x070f04
curl_multi_timeout(curlm, &curl_timeout);
if (curl_timeout == 0) {
@@ -1232,7 +1219,6 @@ static size_t fwrite_sha1_file(char *ptr, size_t eltsize, size_t nmemb,
git_SHA1_Update(&freq->c, expn,
sizeof(expn) - freq->stream.avail_out);
} while (freq->stream.avail_in && freq->zret == Z_OK);
- data_received++;
return size;
}
diff --git a/http.h b/http.h
index 3c332a9..71bdf58 100644
--- a/http.h
+++ b/http.h
@@ -89,7 +89,6 @@ extern void step_active_slots(void);
extern void http_init(struct remote *remote, const char *url);
extern void http_cleanup(void);
-extern int data_received;
extern int active_requests;
extern int http_is_verbose;
extern size_t http_post_buffer;
--
1.7.8.rc0.35.gd9f16.dirty
^ permalink raw reply related
* Re: New Feature wanted: Is it possible to let git clone continue last break point?
From: Shawn Pearce @ 2011-11-04 14:22 UTC (permalink / raw)
To: Johannes Sixt
Cc: Clemens Buchacher, Jeff King, Junio C Hamano, Jonathan Nieder,
netroby, Git Mail List, Tomas Carnecky
In-Reply-To: <4EB3B1E7.7080507@viscovery.net>
On Fri, Nov 4, 2011 at 02:35, Johannes Sixt <j.sixt@viscovery.net> wrote:
> Am 11/4/2011 9:56, schrieb Clemens Buchacher:
>> Cache ... not the pack but the information
>> to re-create it...
>
> It has been discussed. It doesn't work. Because with threaded pack
> generation, the resulting pack is not deterministic.
The information to create a pack for a repository with 2M objects
(e.g. Linux kernel tree) is *at least* 152M of data. This is just a
first order approximation of what it takes to write out the 2M SHA-1s,
along with say a 4 byte length so you can find given an offset
provided by the client roughly where to resumse in the object stream.
This is like 25% of the pack size itself. Ouch.
This data is still insufficient to resume from. A correct solution
would allow you to resume in the middle of an object, which means we
also need to store some sort of indicator of which representation was
chosen from an existing pack file for object reuse. Which adds more
data to the stream. And then there is the not so simple problem of how
to resume in the middle of an object that was being recompressed on
the fly, such as a large loose object.
By the time you get done with all of that, your "ticket" might as well
be the name of a pack file. And your "resume information" is just a
pack file itself. Which would be very expensive to recreate.
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Ted Ts'o @ 2011-11-04 14:59 UTC (permalink / raw)
To: Linus Torvalds
Cc: Junio C Hamano, Shawn Pearce, git, James Bottomley, Jeff Garzik,
Andrew Morton, linux-ide, LKML
In-Reply-To: <CA+55aFyRawm9CoJMiEXDFCX4YTidPOiV4oqSS2d7nNv7Ecw8BQ@mail.gmail.com>
On Thu, Nov 03, 2011 at 12:09:55PM -0700, Linus Torvalds wrote:
> I personally dislike it, and don't really think it's a wonderful thing
> at all. I really does have real downsides:
>
> - internal signatures really *are* a disaster for maintenance. You
> can never fix them if they need fixing (and "need fixing" may well be
> "you want to re-sign things after a repository format change")
Note that a repository format change will break a bunch of other
things as well, including references in commit descriptions ("This
fixes a regression introduced in commit 42DEADBEEF") So if SHA-1 is in
danger of failing in way that would threaten git's use of it (highly
unlikely), we'd probably be well advised to find a way to add a new
crypto checksum (i.e., SHA-256) in parallel, but keep the original
SHA-1 checksum for UI purposes.
> - they are ugly as heck, and you really don't want to see them in
> 99.999% of all cases.
So we can make them be hidden from "git log" and "gik" by default.
That bit is a bit gross, I agree, but 3rd party verification really is
a good thing, which I'm hoping can be added in a relatively clean
fashion.
- Ted
^ 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