* 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
* 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: 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
* 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: 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
* 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
* 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
* [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
* 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
* 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: 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
* [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: [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
* [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: 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
* 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: [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: [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
* What's cooking in git.git (Nov 2011, #01; Thu, 3)
From: Junio C Hamano @ 2011-11-03 22:16 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'.
--------------------------------------------------
[New Topics]
* jc/stream-to-pack (2011-11-03) 4 commits
- Bulk check-in
- finish_tmp_packfile(): a helper function
- create_tmp_packfile(): a helper function
- write_pack_header(): a helper function
Teaches "git add" to send large-ish blob data straight to a packfile.
This is a continuation to the "large file support" topic. I think this
codepath to move data from worktree to repository needs to become aware of
streaming, just like the checkout codepath that goes the other way, which
was done in the previous "large file support" topic in the 1.7.7 cycle.
* jn/gitweb-side-by-side-diff (2011-10-31) 8 commits
- gitweb: Add navigation to select side-by-side diff
- gitweb: Use href(-replay=>1,...) for formats links in "commitdiff"
- t9500: Add basic sanity tests for side-by-side diff in gitweb
- t9500: Add test for handling incomplete lines in diff by gitweb
- gitweb: Give side-by-side diff extra CSS styling
- gitweb: Add a feature to show side-by-side diff
- gitweb: Extract formatting of diff chunk header
- gitweb: Refactor diff body line classification
Replaces a series from Kato Kazuyoshi on the same topic.
* vr/msvc (2011-10-31) 3 commits
- MSVC: Remove unneeded header stubs
- Compile fix for MSVC: Include <io.h>
- Compile fix for MSVC: Do not include sys/resources.h
It seems this needs to be rehashed with msysgit folks.
* mf/curl-select-fdset (2011-11-02) 2 commits
- http.c: Use timeout suggested by curl instead of fixed 50ms timeout
- http.c: Use curl_multi_fdset to select on curl fds instead of just sleeping
* na/strtoimax (2011-11-02) 2 commits
- Support sizes >=2G in various config options accepting 'g' sizes.
- Add strtoimax() compatibility function.
--------------------------------------------------
[Graduated to "master"]
* dm/pack-objects-update (2011-10-20) 4 commits
(merged to 'next' on 2011-10-27 at fa52898)
+ pack-objects: don't traverse objects unnecessarily
+ pack-objects: rewrite add_descendants_to_write_order() iteratively
+ pack-objects: use unsigned int for counter and offset values
+ pack-objects: mark add_to_write_order() as inline
* ef/mingw-upload-archive (2011-10-30) 3 commits
(merged to 'next' on 2011-10-30 at 5267fa3)
+ upload-archive: use start_command instead of fork
+ compat/win32/poll.c: upgrade from upstream
+ mingw: move poll out of sys-folder
* jk/git-tricks (2011-10-21) 3 commits
(merged to 'next' on 2011-10-23 at 7c9bf71)
+ completion: match ctags symbol names in grep patterns
+ contrib: add git-jump script
+ contrib: add diff highlight script
* nd/pretty-commit-log-message (2011-10-23) 2 commits
(merged to 'next' on 2011-10-27 at 4b61df7)
+ pretty.c: use original commit message if reencoding fails
+ pretty.c: free get_header() return value
* ss/blame-textconv-fake-working-tree (2011-10-28) 2 commits
(merged to 'next' on 2011-10-30 at 9588bc1)
+ (squash) test for previous
+ blame.c: Properly initialize strbuf after calling, textconv_object()
--------------------------------------------------
[Stalled]
* hv/submodule-merge-search (2011-10-13) 4 commits
- submodule.c: make two functions static
- allow multiple calls to submodule merge search for the same path
- push: Don't push a repository with unpushed submodules
- push: teach --recurse-submodules the on-demand option
What the topic aims to achieve may make sense, but the implementation
looked somewhat suboptimal.
* sr/transport-helper-fix-rfc (2011-07-19) 2 commits
- t5800: point out that deleting branches does not work
- t5800: document inability to push new branch with old content
Perhaps 281eee4 (revision: keep track of the end-user input from the
command line, 2011-08-25) would help.
* jc/lookup-object-hash (2011-08-11) 6 commits
- object hash: replace linear probing with 4-way cuckoo hashing
- object hash: we know the table size is a power of two
- object hash: next_size() helper for readability
- pack-objects --count-only
- object.c: remove duplicated code for object hashing
- object.c: code movement for readability
I do not think there is anything fundamentally wrong with this series, but
the risk of breakage far outweighs observed performance gain in one
particular workload.
* jc/verbose-checkout (2011-10-16) 2 commits
- checkout -v: give full status output after switching branches
- checkout: move the local changes report to the end
This is just to leave a record that the reason why we do not do this not
because we are incapable of coding this, but because it is not a good idea
to do this. I suspect people who are new to git that might think they need
it would soon realize the don't.
Will keep in 'pu' as a showcase for a while and then will drop.
--------------------------------------------------
[Cooking]
* nd/misc-cleanups (2011-10-27) 6 commits
(merged to 'next' on 2011-10-28 at 2527a49)
+ unpack_object_header_buffer(): clear the size field upon error
+ tree_entry_interesting: make use of local pointer "item"
+ tree_entry_interesting(): give meaningful names to return values
+ read_directory_recursive: reduce one indentation level
+ get_tree_entry(): do not call find_tree_entry() on an empty tree
+ tree-walk.c: do not leak internal structure in tree_entry_len()
These are unquestionably good parts taken out of a larger series, so that
we can focus more on the other changes in later rounds of review.
Will keep in 'next' during this cycle.
* rs/allocate-cache-entry-individually (2011-10-26) 2 commits
(merged to 'next' on 2011-10-27 at 2e4acd6)
+ cache.h: put single NUL at end of struct cache_entry
+ read-cache.c: allocate index entries individually
Will keep in 'next' during this cycle.
* mh/ref-api-3 (2011-10-19) 11 commits
(merged to 'next' on 2011-10-23 at 92e2d35)
+ is_refname_available(): reimplement using do_for_each_ref_in_array()
+ names_conflict(): simplify implementation
+ names_conflict(): new function, extracted from is_refname_available()
+ repack_without_ref(): reimplement using do_for_each_ref_in_array()
+ do_for_each_ref_in_array(): new function
+ do_for_each_ref(): correctly terminate while processesing extra_refs
+ add_ref(): take a (struct ref_entry *) parameter
+ create_ref_entry(): extract function from add_ref()
+ parse_ref_line(): add a check that the refname is properly formatted
+ repack_without_ref(): remove temporary
+ Rename another local variable name -> refname
(this branch uses mh/ref-api-2.)
Will keep in 'next' during this cycle.
* rr/revert-cherry-pick (2011-10-23) 5 commits
(merged to 'next' on 2011-10-26 at 27b7496)
+ revert: simplify communicating command-line arguments
+ revert: allow mixed pick and revert instructions
+ revert: make commit subjects in insn sheet optional
+ revert: simplify getting commit subject in format_todo()
+ revert: free msg in format_todo()
The internals of "git revert/cherry-pick" has been further refactored to
serve as the basis for the sequencer.
Will keep in 'next' during this cycle.
* jc/check-ref-format-fixup (2011-10-19) 2 commits
(merged to 'next' on 2011-10-19 at 98981be)
+ Revert "Restrict ref-like names immediately below $GIT_DIR"
(merged to 'next' on 2011-10-15 at 8e89bc5)
+ Restrict ref-like names immediately below $GIT_DIR
This became a no-op except for the bottom one which is part of the other
topic now.
Will discard once the other topic graduates to 'master'.
* cb/daemon-permission-errors (2011-10-17) 2 commits
- daemon: report permission denied error to clients
- daemon: add tests
The tip commit might be loosening things a bit too much.
Will keep in 'pu' until hearing a convincing argument for the patch.
* mh/ref-api-2 (2011-10-17) 14 commits
(merged to 'next' on 2011-10-19 at cc89f0e)
+ resolve_gitlink_ref_recursive(): change to work with struct ref_cache
+ Pass a (ref_cache *) to the resolve_gitlink_*() helper functions
+ resolve_gitlink_ref(): improve docstring
+ get_ref_dir(): change signature
+ refs: change signatures of get_packed_refs() and get_loose_refs()
+ is_dup_ref(): extract function from sort_ref_array()
+ add_ref(): add docstring
+ parse_ref_line(): add docstring
+ is_refname_available(): remove the "quiet" argument
+ clear_ref_array(): rename from free_ref_array()
+ refs: rename parameters result -> sha1
+ refs: rename "refname" variables
+ struct ref_entry: document name member
+ cache.h: add comments for git_path() and git_path_submodule()
(this branch is used by mh/ref-api-3.)
Will keep in 'next' during this cycle.
* jc/signed-commit (2011-10-21) 7 commits
(merged to 'next' on 2011-10-23 at 03eec25)
+ pretty: %G[?GS] placeholders
+ parse_signed_commit: really use the entire commit log message
+ test "commit -S" and "log --show-signature"
+ t7004: extract generic "GPG testing" bits
+ log: --show-signature
+ commit: teach --gpg-sign option
+ Split GPG interface into its own helper library
This is to replace the earlier "signed push" experiments.
Will keep in 'next' during this cycle.
* sg/complete-refs (2011-10-21) 9 commits
(merged to 'next' on 2011-10-26 at d65e2b4)
+ completion: remove broken dead code from __git_heads() and __git_tags()
+ completion: fast initial completion for config 'remote.*.fetch' value
+ completion: improve ls-remote output filtering in __git_refs_remotes()
+ completion: query only refs/heads/ in __git_refs_remotes()
+ completion: support full refs from remote repositories
+ completion: improve ls-remote output filtering in __git_refs()
+ completion: make refs completion consistent for local and remote repos
+ completion: optimize refs completion
+ completion: document __gitcomp()
Will keep in 'next' until an Ack or two from completion folks.
* jc/request-pull-show-head-4 (2011-10-15) 11 commits
(merged to 'next' on 2011-10-15 at 7e340ff)
+ fmt-merge-msg.c: Fix an "dubious one-bit signed bitfield" sparse error
(merged to 'next' on 2011-10-10 at 092175e)
+ environment.c: Fix an sparse "symbol not declared" warning
+ builtin/log.c: Fix an "Using plain integer as NULL pointer" warning
(merged to 'next' on 2011-10-07 at fcaeca0)
+ fmt-merge-msg: use branch.$name.description
(merged to 'next' on 2011-10-06 at fa5e0fe)
+ request-pull: use the branch description
+ request-pull: state what commit to expect
+ request-pull: modernize style
+ branch: teach --edit-description option
+ format-patch: use branch description in cover letter
+ branch: add read_branch_desc() helper function
+ Merge branch 'bk/ancestry-path' into jc/branch-desc
Allow setting "description" for branches and use it to help communications
between humans in various workflow elements.
Will keep in 'next' during this cycle.
--------------------------------------------------
[Discarded]
* kk/gitweb-side-by-side-diff (2011-10-17) 2 commits
. gitweb: add a feature to show side-by-side diff
. gitweb: change format_diff_line() to remove leading SP from $diff_class
jn/gitweb-side-by-side-diff replaces this.
^ permalink raw reply
* Re: [PATCH] fsck: print progress
From: Jeff King @ 2011-11-03 21:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nguyễn Thái Ngọc Duy, git
In-Reply-To: <7vwrbhdixe.fsf@alter.siamese.dyndns.org>
On Thu, Nov 03, 2011 at 01:56:13PM -0700, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > So you would agree that we are better summing the objects for all packs
> > and showing one big progress bar?
>
> If it can be done without sacrificing the clarity of the code, compared to
> the "we will do new and smaller ones first so in practice it does not
> matter" approach taken by the patch in question, I would not mind it, but
> to be honest, I do not deeply care either way.
I looked briefly at doing this. It's a little annoying with the
verify_packs code, because you have to pass around the "how far are we
into the progress" counter separately. But I confess I don't care that
much either way, either. With the two minor fixups I sent in my original
review, I think Duy's patch would be OK by me.
-Peff
^ permalink raw reply
* Re: [PATCH] fsck: print progress
From: Junio C Hamano @ 2011-11-03 20:56 UTC (permalink / raw)
To: Jeff King; +Cc: Nguyễn Thái Ngọc Duy, git
In-Reply-To: <20111103202954.GC19483@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> So you would agree that we are better summing the objects for all packs
> and showing one big progress bar?
If it can be done without sacrificing the clarity of the code, compared to
the "we will do new and smaller ones first so in practice it does not
matter" approach taken by the patch in question, I would not mind it, but
to be honest, I do not deeply care either way.
^ permalink raw reply
* Re: [PATCH] fsck: print progress
From: Jeff King @ 2011-11-03 20:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nguyễn Thái Ngọc Duy, git
In-Reply-To: <7v8vnxeyrp.fsf@alter.siamese.dyndns.org>
On Thu, Nov 03, 2011 at 01:28:42PM -0700, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> >> Hmm, once you do this kind of thing I would expect two (or more) progress
> >> bars to be shown, something like:
> >>
> >> $ git fsck --progress
> >> checking packs: 3 of 7 (42% done)
> >> checking objects in pack: 12405 of 332340 (4% done)
> >
> > I don't think we can do multiple lines portably, though, because the
> > progress code just uses "\r" to return to the beginning of the line.
>
> It was meant to be a tongue-in-cheek comment. I personally hate those
> "Installing n of N packages / Installation of package n p% done" progress
> meters when we know the weight of each of these N packages varies.
OK, I missed your sarcasm. You're too understated. ;)
So you would agree that we are better summing the objects for all packs
and showing one big progress bar?
-Peff
^ permalink raw reply
* Re: [PATCH] fsck: print progress
From: Junio C Hamano @ 2011-11-03 20:28 UTC (permalink / raw)
To: Jeff King; +Cc: Nguyễn Thái Ngọc Duy, git
In-Reply-To: <20111103195147.GA21318@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
>> Hmm, once you do this kind of thing I would expect two (or more) progress
>> bars to be shown, something like:
>>
>> $ git fsck --progress
>> checking packs: 3 of 7 (42% done)
>> checking objects in pack: 12405 of 332340 (4% done)
>
> I don't think we can do multiple lines portably, though, because the
> progress code just uses "\r" to return to the beginning of the line.
It was meant to be a tongue-in-cheek comment. I personally hate those
"Installing n of N packages / Installation of package n p% done" progress
meters when we know the weight of each of these N packages varies.
I also agree with your "how would you know which one is throughput and
which one is counts" comment, which would mean the particular abstraction
you mentioned is too premature even though it looks nice on the surface.
^ permalink raw reply
* Re: [PATCH] fsck: print progress
From: Jeff King @ 2011-11-03 19:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nguyễn Thái Ngọc Duy, git
In-Reply-To: <7vd3d9f0u8.fsf@alter.siamese.dyndns.org>
On Thu, Nov 03, 2011 at 12:43:59PM -0700, Junio C Hamano wrote:
> > But I almost wonder if it is worth factoring out the concept of a
> > "progress group", where you would call it like:
> >
> > progress = progress_group_start("Checking objects in pack", nr_packs);
> > for (p = packed_git; p; p = p->next) {
> > progress_group_next(progress, p->num_objects);
> > for (j = 0; j < num; j++) {
> > fsck_sha1(p, j);
> > display_progress(progress, j+1);
> > }
> > }
> > stop_progress(&progress);
>
> Hmm, once you do this kind of thing I would expect two (or more) progress
> bars to be shown, something like:
>
> $ git fsck --progress
> checking packs: 3 of 7 (42% done)
> checking objects in pack: 12405 of 332340 (4% done)
I don't think we can do multiple lines portably, though, because the
progress code just uses "\r" to return to the beginning of the line.
However, I do think it's a nice design even if the output is the same
right now, because the calling code is specifying more clearly to the
progress code what it actually means. Which means it is easier to
tweak the progress code later to make a prettier representation of that
meaning.
One downside (as with all abstractions :) ), is that it's hard to
deviate from the defaults. With the above, how would you specify if it
was a group of throughput measurements, not counts? Or that you wanted
to use start_progress_delay instead of start_progress on each one?
Or hey, if you really want to get crazy, why can't we check each pack in
parallel on a different CPU, and have all of the progress meters
displayed and moving simultaneously? :)
The last one is obviously a bit tongue in cheek. But it does raise an
interesting point: is seeing the per-pack meter actually useful (whether
parallel or not)? The user just wants to know that progress is being
made, and when it is done. And maybe that argues for just summing the
size of each pack and showing a single progress meter per task.
-Peff
^ permalink raw reply
* Re: [PATCH] fsck: print progress
From: Junio C Hamano @ 2011-11-03 19:43 UTC (permalink / raw)
To: Jeff King; +Cc: Nguyễn Thái Ngọc Duy, git
In-Reply-To: <20111103193826.GB19483@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> a little more readable, or even:
>
> stop_progress_msg(&progress, p->next ? NULL : "done\n");
Yeah, this one looks neat.
> But I almost wonder if it is worth factoring out the concept of a
> "progress group", where you would call it like:
>
> progress = progress_group_start("Checking objects in pack", nr_packs);
> for (p = packed_git; p; p = p->next) {
> progress_group_next(progress, p->num_objects);
> for (j = 0; j < num; j++) {
> fsck_sha1(p, j);
> display_progress(progress, j+1);
> }
> }
> stop_progress(&progress);
Hmm, once you do this kind of thing I would expect two (or more) progress
bars to be shown, something like:
$ git fsck --progress
checking packs: 3 of 7 (42% done)
checking objects in pack: 12405 of 332340 (4% done)
^ 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