* Re: Files excluded but not ignored
From: Junio C Hamano @ 2013-01-30 16:17 UTC (permalink / raw)
To: Jason Wenger; +Cc: git
In-Reply-To: <loom.20130130T161911-66@post.gmane.org>
Jason Wenger <jcwenger@gmail.com> writes:
> I prefer to not add core.* files to my ignore listings because I find it helpful
> to see them in git status -- It helps me notice and clean them up periodically.
> Not having them ignored is also good ,because it allows git clean to care of
> core.* files.
>
> The problem is that git add -A, git stash -u, etc, remain interested in the core
> files.
>
> Trying to start up discussion of whether there would be merit to a "half-
> ignored" state -- Files which are excluded from tracking, but which still
> show in git status, and which are removed by git clean.
>
> Not trying to propose yet how .git/exclude or .gitignore would be formatted
> or anything like that. Just looking for opinions on whether such a state
> would be considered by the community as a good thing and merit the added
> complexity in the code.
I see no merit for "ignored and never to be tracked, but are still
shown loudly in the untracked list" myself. Use cases for "ignored
and never to be tracked, but not expendable" class were mentioned
often in the past, though.
^ permalink raw reply
* Re: Anybody know a website with up-to-date git documentation?
From: Sitaram Chamarty @ 2013-01-30 15:59 UTC (permalink / raw)
To: Max Horn; +Cc: John Keeping, git, Scott Chacon
In-Reply-To: <71A3AA8C-DBA2-44F7-9B69-AEDB81BB0906@quendi.de>
On Wed, Jan 30, 2013 at 7:28 PM, Max Horn <max@quendi.de> wrote:
>
> On 30.01.2013, at 12:54, John Keeping wrote:
>
>> On Wed, Jan 30, 2013 at 12:46:47PM +0100, Max Horn wrote:
>>> does anybody know a website where one can view that latest git
>>> documentation? Here, "latest" means "latest release" (though being
>>> also able to access it for "next" would of course be a nice bonus,
>>> likewise for older versions). While I do have those docs on my local
>>> machine, I would like to access them online, too (e.g. easier to
>>> pointer people at this, I can access it from other machines, etc.).
>>
>> How about http://git-htmldocs.googlecode.com/git/ ?
>>
>> It's just a directory listing of the git-htmldocs repository that Junio
>> maintains - the latest update was yesterday: Autogenerated HTML docs for
>> v1.8.1.2-422-g08c0e.
>>
>> [I didn't know Google Code let you view the repository like that, but I
>> got there by clicking the "raw" link against one of the files so I
>> assume it's not likely to go away.]
>>
>
> Thanks John, that looks pretty good!
>
> In addition, I just discovered
>
> http://manned.org/git-remote-helpers/2b9e4c86
>
> which contains git docs from Arch Linux, Debian, FreeBSD and Ubuntu packages. And since Arch tends to have the latest, so does manned.org. And best, it even lets me browser to older versions of a file.
>
> So, taken together, I guess that solves my problem -- with John's link, I can see the bleeding edge versions, with manned.org the latest released version (as soon as Arch Linux catches up, which seems to be pretty quick :-).
I'm curious... what's wrong with 'git checkout html' from the git repo
and just browsing them using a web browser?
^ permalink raw reply
* Re: [PATCH] git-send-email: add ~/.authinfo parsing
From: Junio C Hamano @ 2013-01-30 15:57 UTC (permalink / raw)
To: Jeff King; +Cc: Michal Nazarewicz, git, Krzysztof Mazur, Michal Nazarewicz
In-Reply-To: <20130130074306.GA17868@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> But it would probably make sense for send-email to support the existing
> git-credential subsystem, so that it can take advantage of secure
> system-specific storage. And that is where we should be pointing new
> users. I think contrib/mw-to-git even has credential support written in
> perl, so it would just need to be factored out to Git.pm.
Yeah, that sounds like a neat idea.
^ permalink raw reply
* Re: [PATCH 4/6] introduce a commit metapack
From: Junio C Hamano @ 2013-01-30 15:56 UTC (permalink / raw)
To: Jeff King; +Cc: git, Duy Nguyen, Shawn O. Pearce
In-Reply-To: <20130130071209.GD11147@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
>>From this:
>
>> Then it will be very natural for the extension data that store the
>> commit metainfo to name objects in the pack the .idx file describes
>> by the offset in the SHA-1 table.
>
> I guess your argument is that putting it all in the same file makes it
> more natural for there to be a data dependency.
It is more about the "I am torn on this one" I mentioned earlier.
It would be more "logical" if this weren't tied to a particular
pack, as the properties of a commit you record in this series do not
depend on which pack the commit is in, and such a repository-global
file by definition cannot be inside anybody's .idx.
But if we split the information into separate pieces and store one
piece per .idx for implementation reasons, it is crazy not to at
least consider it a longer term goal to put it inside .idx file.
Of course, it is more convenient to store this kind of things in a
separate file while experimenting and improving the mechanism, but I
do not think we want to see each packfile in a repository comes with
47 auxiliary files with different suffixes 5 years down the road.
^ permalink raw reply
* Files excluded but not ignored
From: Jason Wenger @ 2013-01-30 15:34 UTC (permalink / raw)
To: git
I prefer to not add core.* files to my ignore listings because I find it helpful
to see them in git status -- It helps me notice and clean them up periodically.
Not having them ignored is also good ,because it allows git clean to care of
core.* files.
The problem is that git add -A, git stash -u, etc, remain interested in the core
files.
Trying to start up discussion of whether there would be merit to a "half-
ignored" state -- Files which are excluded from tracking, but which still
show in git status, and which are removed by git clean.
Not trying to propose yet how .git/exclude or .gitignore would be formatted
or anything like that. Just looking for opinions on whether such a state
would be considered by the community as a good thing and merit the added
complexity in the code.
^ permalink raw reply
* Re: [PATCH] git-send-email: add ~/.authinfo parsing
From: Ted Zlatanov @ 2013-01-30 15:03 UTC (permalink / raw)
To: git
In-Reply-To: <7vvcafojf4.fsf@alter.siamese.dyndns.org>
On Tue, 29 Jan 2013 11:53:19 -0800 Junio C Hamano <gitster@pobox.com> wrote:
JCH> Makes one wonder why .authinfo and not .netrc;
JCH> http://www.gnu.org/software/emacs/manual/html_node/auth/Help-for-users.html
JCH> phrases it amusingly:
JCH> “Netrc” files are usually called .authinfo or .netr
JCH> nowadays .authinfo seems to be more popular and the
JCH> auth-source library encourages this confusion by accepting
JCH> both
I wrote this and the auth-source.el library in Emacs (I'm glad it was
amusing :). The confusion is further perpetuated by our (in Emacs)
encouragement to use a .authinfo.gpg file, which is then decrypted on
the fly by Emacs through GPG. The format is the same; by the time
auth-source.el sees the contents, they are plain text since the decoding
happens at the file handler level.
I think it makes sense to write the code to support both
`git-send-email' and credentials. I have had it in my TODO list for
almost 2 years now to work on credential support, and to support the
~/.authinfo.gpg decoding specifically. Ideally this would also support
the other formats... Michal, would you be interested in that feature? I
promise to get off my rear and help out.
>> +The '~/.authinfo' file is read if Text::CSV Perl module is installed
>> +on the system; if it's missing, a notification message will be printed
>> +and the file ignored altogether. The file should contain a line with
>> +the following format:
>> ++
>> + machine <domain> port <port> login <user> password <pass>
JCH> It is rather strange to require a comma-separated-values parser to
JCH> read a file format this simple, isn't it?
I'd recommend a hand-crafted parser. Among other things, you should
accept both "strings" and 'strings' if possible (I've seen both formats
in the wild), and the format is simple enough to avoid the module
dependency.
>> ++
>> +Contrary to other tools, 'git-send-email' does not support symbolic
>> +port names like 'imap' thus `<port>` must be a number.
JCH> Perhaps you can convert at least some popular ones yourself? After
JCH> all, the user may be using an _existing_ .authinfo/.netrc that she
JCH> has been using with other programs that do understand symbolic port
JCH> names. Rather than forcing all such users to update their files,
JCH> the patch can work a bit harder for them and the world will be a
JCH> better place, no?
I agree, "port imap" is a nice self-documenting token. Maybe it can be
interpreted by the program that requests the token with a services
lookup, where supported.
Ted
^ permalink raw reply
* Re: Bug, feature, or pilot error: format-patch
From: Gene Czarcinski @ 2013-01-30 14:41 UTC (permalink / raw)
Cc: Git
In-Reply-To: <5106AF7C.1010502@czarc.net>
Ping
It would be useful to get some comment on this
On 01/28/2013 12:03 PM, Gene Czarcinski wrote:
> I am not on the mailing list so please CC me. I am running git 1.8.1 on
> Fedora 18.
>
> I aam having what appears to be a problem. Here is the sequence which
> generally describes what I did and what happened:
>
> git checkout -b test1 master
> git am 0001-simple-1.patch
> git checkout -b test2 master
> git am 0001-simple-2.patch ### this is known to conflict
> with 0001-simple-1.patch
> git checkout test1
> git merge test2
> [here git-merge detects a conflict]
> git mergetool ###to resolve the
> conflict
> [conflict resolved]
> git commit -a -s
> git log
> [shows two commits -- one for simple-2 and one for the merge]
> git format-patch master..HEAD
> [two patch files created: 0001-simple-1.patch and 0002-simple-2.patch]
> [0002-simple-2.patch and 0001-simple-2.patch are exactly equal and do
> not reflect the resolved conflict]
>
> If you do git-diff between <commit-patch-1> and HEAD, you get something
> different that you got from format-patch.
>
> 1. Bug ... format-patch is broken
>
> 2. Feature ... that is the way it works
>
> 3. Pilot error ... ??
>
> I can create a good version of patch-2 manually but should I have to?
>
> Color me foolish but I assumed I could do git-format-patch in one branch
> and then use git-am to recreate that branch elsewhere.
>
> Gene
^ permalink raw reply
* Re: [PATCH 4/6] introduce a commit metapack
From: Duy Nguyen @ 2013-01-30 14:16 UTC (permalink / raw)
To: Jeff King; +Cc: git, Shawn O. Pearce
In-Reply-To: <20130130135607.GA23154@lanh>
On Wed, Jan 30, 2013 at 8:56 PM, Duy Nguyen <pclouds@gmail.com> wrote:
> However, performance seems to suffer too. Maybe I do more lookups than
> necessary, I don't know.
Yes, I should have stored the position in the sha-1 <-> offset map
instead of the position of the object in .pack file. Even so,
performance does not improve.
> I should probably measure the cost of revindex separately.
And the cost of create_pack_revindex() is 0.6 sec :-(
Perhaps we could store abbrev sha-1 instead of full sha-1. Nice
space/time trade-off.
--
Duy
^ permalink raw reply
* RE: [feature request] git add completion should exclude staged content
From: Marc Khouzam @ 2013-01-30 14:06 UTC (permalink / raw)
To: 'Manlio Perillo', 'Junio C Hamano'
Cc: 'Michael J Gruber', 'wookietreiber',
'git@vger.kernel.org'
In-Reply-To: <5106DC87.7090607@gmail.com>
> -----Original Message-----
> From: git-owner@vger.kernel.org
> [mailto:git-owner@vger.kernel.org] On Behalf Of Manlio Perillo
> Sent: Monday, January 28, 2013 3:16 PM
> To: Junio C Hamano
> Cc: Michael J Gruber; wookietreiber; git@vger.kernel.org
> Subject: Re: [feature request] git add completion should
> exclude staged content
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Il 28/01/2013 18:52, Junio C Hamano ha scritto:
> > [...]
> >
> > Thanks both for commenting. I'll find time to read it over again
> > and perhaps we can merge it to 'next' and advertise it in the next
> > issue of "What's cooking" report to ask for wider testing to move it
> > forward.
>
> Thanks.
>
> I will try to update the patch, with your latest suggestions (avoid
> tricky POSIX shell syntax, and CDPATH issue - if I remember
> correctly),
> and with an update for the t/t9902-completion.sh test (that I
> completely
> missed).
Hi Manlio,
I'm trying to update git-completion.tcsh to work properly with
your nice new completion feature. But I'm having trouble with
the missing '/' at the end of directories.
The new logic in git-completion.bash tells bash that 'filenames'
completion is ongoing so bash will add a '/' after directories.
Sadly, tcsh won't do that, so it would be simpler if
git-completion.bash added the '/' itself. I looked at the
git-completion.bash script changes and I noticed that for
bash version < 4, you have to add the '/' yourself.
I also noticed the following comment:
# XXX if we append a slash to directory names when using
# `compopt -o filenames`, Bash will append another slash.
# This is pretty stupid, and this the reason why we have to
# define a compatible version for this function.
So I gather you would rather add a '/' all the time to deal
with older bash version transparently. This would be great
for tcsh also. I'm trying to figure out
when bash mis-behaves when you add the '/' all the time?
When I try it (I have bash 4.1.5(1)-release) I didn't run
into the double slash problem you mention in the comment.
I'm hoping we can straighten this out and have
git-completion.bash add the '/' all the time.
Could you explain when the problem happens?
Thanks
Marc
^ permalink raw reply
* Re: Anybody know a website with up-to-date git documentation?
From: Max Horn @ 2013-01-30 13:58 UTC (permalink / raw)
To: John Keeping; +Cc: git, Scott Chacon
In-Reply-To: <20130130115439.GH1342@serenity.lan>
On 30.01.2013, at 12:54, John Keeping wrote:
> On Wed, Jan 30, 2013 at 12:46:47PM +0100, Max Horn wrote:
>> does anybody know a website where one can view that latest git
>> documentation? Here, "latest" means "latest release" (though being
>> also able to access it for "next" would of course be a nice bonus,
>> likewise for older versions). While I do have those docs on my local
>> machine, I would like to access them online, too (e.g. easier to
>> pointer people at this, I can access it from other machines, etc.).
>
> How about http://git-htmldocs.googlecode.com/git/ ?
>
> It's just a directory listing of the git-htmldocs repository that Junio
> maintains - the latest update was yesterday: Autogenerated HTML docs for
> v1.8.1.2-422-g08c0e.
>
> [I didn't know Google Code let you view the repository like that, but I
> got there by clicking the "raw" link against one of the files so I
> assume it's not likely to go away.]
>
Thanks John, that looks pretty good!
In addition, I just discovered
http://manned.org/git-remote-helpers/2b9e4c86
which contains git docs from Arch Linux, Debian, FreeBSD and Ubuntu packages. And since Arch tends to have the latest, so does manned.org. And best, it even lets me browser to older versions of a file.
So, taken together, I guess that solves my problem -- with John's link, I can see the bleeding edge versions, with manned.org the latest released version (as soon as Arch Linux catches up, which seems to be pretty quick :-).
Thanks!
Max
^ permalink raw reply
* Re: [PATCH 4/6] introduce a commit metapack
From: Duy Nguyen @ 2013-01-30 13:56 UTC (permalink / raw)
To: Jeff King; +Cc: git, Shawn O. Pearce
In-Reply-To: <20130129091610.GD9999@sigill.intra.peff.net>
On Tue, Jan 29, 2013 at 04:16:11AM -0500, Jeff King wrote:
> When we are doing a commit traversal that does not need to
> look at the commit messages themselves (e.g., rev-list,
> merge-base, etc), we spend a lot of time accessing,
> decompressing, and parsing the commit objects just to find
> the parent and timestamp information. We can make a
> space-time tradeoff by caching that information on disk in a
> compact, uncompressed format.
And this is a (messy) patch on top that avoids storing SHA-1
directly. On my linux-2.6.git (575 MB pack, 73 MB index), .commits
file is 5.2 MB and 27 MB with and without my patch respectively. Nice
shrinkage.
However, performance seems to suffer too. Maybe I do more lookups than
necessary, I don't know. I should probably measure the cost of
revindex separately.
git rev-list --all --quiet on vanilla git:
real 0m3.645s
user 0m3.556s
sys 0m0.080s
commit cache without my patch:
real 0m0.723s
user 0m0.677s
sys 0m0.045s
and with my patch:
real 0m1.338s
user 0m1.259s
sys 0m0.075s
Another point, but not really important at this stage, I think we have
memory leak somewhere (lookup_commit??). It used up to 800 MB RES on
linux-2.6.git while generating the cache.
-- 8< --
diff --git a/cache.h b/cache.h
index 1f96f65..8048d5b 100644
--- a/cache.h
+++ b/cache.h
@@ -1069,6 +1069,7 @@ extern struct packed_git *add_packed_git(const char *, int, int);
extern const unsigned char *nth_packed_object_sha1(struct packed_git *, uint32_t);
extern off_t nth_packed_object_offset(const struct packed_git *, uint32_t);
extern off_t find_pack_entry_one(const unsigned char *, struct packed_git *);
+extern int find_pack_entry_pos(const unsigned char *, struct packed_git *);
extern int is_pack_valid(struct packed_git *);
extern void *unpack_entry(struct packed_git *, off_t, enum object_type *, unsigned long *);
extern unsigned long unpack_object_header_buffer(const unsigned char *buf, unsigned long len, enum object_type *type, unsigned long *sizep);
diff --git a/commit-metapack.c b/commit-metapack.c
index 2c19f48..55f7ea9 100644
--- a/commit-metapack.c
+++ b/commit-metapack.c
@@ -3,11 +3,12 @@
#include "metapack.h"
#include "commit.h"
#include "sha1-lookup.h"
+#include "pack-revindex.h"
struct commit_metapack {
struct metapack mp;
- uint32_t nr;
- unsigned char *index;
+ struct packed_git *pack;
+ uint32_t first, last;
unsigned char *data;
struct commit_metapack *next;
};
@@ -16,7 +17,7 @@ static struct commit_metapack *commit_metapacks;
static struct commit_metapack *alloc_commit_metapack(struct packed_git *pack)
{
struct commit_metapack *it = xcalloc(1, sizeof(*it));
- uint32_t version;
+ uint32_t version, nr;
if (metapack_init(&it->mp, pack, "commits", &version) < 0) {
free(it);
@@ -39,22 +40,25 @@ static struct commit_metapack *alloc_commit_metapack(struct packed_git *pack)
free(it);
return NULL;
}
- memcpy(&it->nr, it->mp.data, 4);
- it->nr = ntohl(it->nr);
+ memcpy(&it->first, it->mp.data, 4);
+ it->first = ntohl(it->first);
+ memcpy(&it->last, it->mp.data + 4, 4);
+ it->last = ntohl(it->last);
+ nr = it->last - it->first + 1;
+ it->pack = pack;
/*
- * We need 84 bytes for each entry: sha1(20), date(4), tree(20),
- * parents(40).
+ * We need 16 bytes for each entry: date(4), tree index(4),
+ * parent indexes(8).
*/
- if (it->mp.len < (84 * it->nr + 4)) {
+ if (it->mp.len < (16 * nr + 8)) {
warning("commit metapack for '%s' is truncated", pack->pack_name);
metapack_close(&it->mp);
free(it);
return NULL;
}
- it->index = it->mp.data + 4;
- it->data = it->index + 20 * it->nr;
+ it->data = it->mp.data + 8;
return it;
}
@@ -81,31 +85,61 @@ static void prepare_commit_metapacks(void)
initialized = 1;
}
+static const unsigned char *idx_to_sha1(struct packed_git *p,
+ uint32_t nth)
+{
+ struct revindex_entry *revindex = get_revindex(p);
+ if (!revindex)
+ return NULL;
+ return nth_packed_object_sha1(p, revindex[nth].nr);
+}
+
int commit_metapack(unsigned char *sha1,
uint32_t *timestamp,
- unsigned char **tree,
- unsigned char **parent1,
- unsigned char **parent2)
+ const unsigned char **tree,
+ const unsigned char **parent1,
+ const unsigned char **parent2)
{
struct commit_metapack *p;
prepare_commit_metapacks();
for (p = commit_metapacks; p; p = p->next) {
unsigned char *data;
- int pos = sha1_entry_pos(p->index, 20, 0, 0, p->nr, p->nr, sha1);
- if (pos < 0)
+ uint32_t p1, p2;
+ struct revindex_entry *re, *base;
+ off_t off;
+ uint32_t pos;
+
+ base = get_revindex(p->pack);
+ off = find_pack_entry_one(sha1, p->pack);
+ if (!off)
+ continue;
+ re = find_pack_revindex(p->pack, off);
+ if (!re)
+ continue;
+ pos = re - base;
+ if (pos < p->first || pos > p->last)
continue;
/* timestamp(4) + tree(20) + parents(40) */
- data = p->data + 64 * pos;
+ data = p->data + 16 * (pos - p->first);
*timestamp = *(uint32_t *)data;
*timestamp = ntohl(*timestamp);
+ if (!*timestamp)
+ return -1;
data += 4;
- *tree = data;
- data += 20;
- *parent1 = data;
- data += 20;
- *parent2 = data;
+ *tree = idx_to_sha1(p->pack, ntohl(*(uint32_t*)data));
+ data += 4;
+ p1 = ntohl(*(uint32_t*)data);
+ *parent1 = idx_to_sha1(p->pack, p1);
+ data += 4;
+ p2 = ntohl(*(uint32_t*)data);
+ if (p1 == p2)
+ *parent2 = null_sha1;
+ else
+ *parent2 = idx_to_sha1(p->pack, p2);
+ if (!*tree || !*parent1 || !*parent2)
+ return -1;
return 0;
}
@@ -113,63 +147,114 @@ int commit_metapack(unsigned char *sha1,
return -1;
}
-static void get_commits(struct metapack_writer *mw,
- const unsigned char *sha1,
- void *data)
+static int get_commits(struct metapack_writer *mw,
+ uint32_t nth,
+ int dry_run)
{
- struct commit_list ***tail = data;
+ const unsigned char *sha1 = nth_packed_object_sha1(mw->pack, nth);
enum object_type type = sha1_object_info(sha1, NULL);
struct commit *c;
+ struct revindex_entry *revindex, *ridx;
+ int pt, p1, p2 = -1;
- if (type != OBJ_COMMIT)
- return;
+ if (type != OBJ_COMMIT) {
+ if (dry_run)
+ return -1;
+ metapack_writer_add_uint32(mw, 0); /* date */
+ metapack_writer_add_uint32(mw, 0); /* tree */
+ metapack_writer_add_uint32(mw, 0); /* 1st parent */
+ metapack_writer_add_uint32(mw, 0); /* 2nd tree */
+ return 0;
+ }
c = lookup_commit(sha1);
if (!c || parse_commit(c))
die("unable to read commit %s", sha1_to_hex(sha1));
+ if (c->buffer) {
+ free(c->buffer);
+ c->buffer = NULL;
+ }
+
/*
* Our fixed-size parent list cannot represent root commits, nor
* octopus merges. Just skip those commits, as we can fallback
* in those rare cases to reading the actual commit object.
*/
if (!c->parents ||
- (c->parents && c->parents->next && c->parents->next->next))
- return;
+ (c->parents && c->parents->next && c->parents->next->next) ||
+ /* edge commits are out too */
+ (pt = find_pack_entry_pos(c->tree->object.sha1, mw->pack)) == -1 ||
+ (p1 = find_pack_entry_pos(c->parents->item->object.sha1, mw->pack)) == -1 ||
+ (c->parents->next &&
+ (p2 = find_pack_entry_pos(c->parents->next->item->object.sha1, mw->pack)) == -1) ||
+ /*
+ * we set the 2nd parent the same as 1st parent as an
+ * indication that 2nd parent does not exist. Normal
+ * commits should never have two same parents, but just in
+ * case..
+ */
+ p1 == p2 ||
+ /* zero date is reserved to say this is not a valid entry */
+ c->date == 0) {
+ if (dry_run)
+ return -1;
+ metapack_writer_add_uint32(mw, 0); /* date */
+ metapack_writer_add_uint32(mw, 0); /* tree */
+ metapack_writer_add_uint32(mw, 0); /* 1st parent */
+ metapack_writer_add_uint32(mw, 0); /* 2nd tree */
+ return 0;
+ }
+
+ if (dry_run)
+ return 0;
+
+ revindex = get_revindex(mw->pack);
- *tail = &commit_list_insert(c, *tail)->next;
+ metapack_writer_add_uint32(mw, c->date);
+ ridx = find_pack_revindex(mw->pack,
+ nth_packed_object_offset(mw->pack, pt));
+ metapack_writer_add_uint32(mw, ridx - revindex);
+ ridx = find_pack_revindex(mw->pack,
+ nth_packed_object_offset(mw->pack, p1));
+ metapack_writer_add_uint32(mw, ridx - revindex);
+ if (p2 != -1)
+ ridx = find_pack_revindex(mw->pack,
+ nth_packed_object_offset(mw->pack, p2));
+ metapack_writer_add_uint32(mw, ridx - revindex);
+ return 0;
}
void commit_metapack_write(const char *idx)
{
struct metapack_writer mw;
- struct commit_list *commits = NULL, *p;
- struct commit_list **tail = &commits;
- uint32_t nr = 0;
+ uint32_t i, first = 0xffffffff, last = 0;
+ struct revindex_entry *revidx;
metapack_writer_init(&mw, idx, "commits", 1);
- /* Figure out how many eligible commits we've got in this pack. */
- metapack_writer_foreach(&mw, get_commits, &tail);
- for (p = commits; p; p = p->next)
- nr++;
- metapack_writer_add_uint32(&mw, nr);
+ packed_git = mw.pack;
+ revidx = get_revindex(mw.pack);
- /* Then write an index of commit sha1s */
- for (p = commits; p; p = p->next)
- metapack_writer_add(&mw, p->item->object.sha1, 20);
+ /*
+ * Figure out how many eligible commits we've got in this pack.
+ */
+ for (i = 0; i < mw.pack->num_objects; i++) {
+ int ret = get_commits(&mw, revidx[i].nr, 1);
+ if (ret == -1) /* not cached */
+ continue;
+ if (i < first)
+ first = i;
+ if (i > last)
+ last = i;
+ }
+
+ metapack_writer_add_uint32(&mw, first);
+ metapack_writer_add_uint32(&mw, last);
/* Followed by the actual date/tree/parents data */
- for (p = commits; p; p = p->next) {
- struct commit *c = p->item;
- metapack_writer_add_uint32(&mw, c->date);
- metapack_writer_add(&mw, c->tree->object.sha1, 20);
- metapack_writer_add(&mw, c->parents->item->object.sha1, 20);
- metapack_writer_add(&mw,
- c->parents->next ?
- c->parents->next->item->object.sha1 :
- null_sha1, 20);
- }
+ for (i = first; i <= last; i++)
+ get_commits(&mw, revidx[i].nr, 0);
metapack_writer_finish(&mw);
}
diff --git a/commit-metapack.h b/commit-metapack.h
index 4684573..caf85be 100644
--- a/commit-metapack.h
+++ b/commit-metapack.h
@@ -3,9 +3,9 @@
int commit_metapack(unsigned char *sha1,
uint32_t *timestamp,
- unsigned char **tree,
- unsigned char **parent1,
- unsigned char **parent2);
+ const unsigned char **tree,
+ const unsigned char **parent1,
+ const unsigned char **parent2);
void commit_metapack_write(const char *idx_file);
diff --git a/pack-revindex.c b/pack-revindex.c
index 77a0465..d58dd02 100644
--- a/pack-revindex.c
+++ b/pack-revindex.c
@@ -111,12 +111,10 @@ static void create_pack_revindex(struct pack_revindex *rix)
qsort(rix->revindex, num_ent, sizeof(*rix->revindex), cmp_offset);
}
-struct revindex_entry *find_pack_revindex(struct packed_git *p, off_t ofs)
+struct revindex_entry *get_revindex(struct packed_git *p)
{
int num;
- int lo, hi;
struct pack_revindex *rix;
- struct revindex_entry *revindex;
if (!pack_revindex_hashsz)
init_pack_revindex();
@@ -127,7 +125,13 @@ struct revindex_entry *find_pack_revindex(struct packed_git *p, off_t ofs)
rix = &pack_revindex[num];
if (!rix->revindex)
create_pack_revindex(rix);
- revindex = rix->revindex;
+ return rix->revindex;
+}
+
+struct revindex_entry *find_pack_revindex(struct packed_git *p, off_t ofs)
+{
+ int lo, hi;
+ struct revindex_entry *revindex = get_revindex(p);
lo = 0;
hi = p->num_objects + 1;
diff --git a/pack-revindex.h b/pack-revindex.h
index 8d5027a..cea85db 100644
--- a/pack-revindex.h
+++ b/pack-revindex.h
@@ -6,6 +6,7 @@ struct revindex_entry {
unsigned int nr;
};
+struct revindex_entry *get_revindex(struct packed_git *p);
struct revindex_entry *find_pack_revindex(struct packed_git *p, off_t ofs);
void discard_revindex(void);
diff --git a/sha1_file.c b/sha1_file.c
index 40b2329..1acab8c 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1978,8 +1978,8 @@ off_t nth_packed_object_offset(const struct packed_git *p, uint32_t n)
}
}
-off_t find_pack_entry_one(const unsigned char *sha1,
- struct packed_git *p)
+int find_pack_entry_pos(const unsigned char *sha1,
+ struct packed_git *p)
{
const uint32_t *level1_ofs = p->index_data;
const unsigned char *index = p->index_data;
@@ -1992,7 +1992,7 @@ off_t find_pack_entry_one(const unsigned char *sha1,
if (!index) {
if (open_pack_index(p))
- return 0;
+ return -1;
level1_ofs = p->index_data;
index = p->index_data;
}
@@ -2019,9 +2019,7 @@ off_t find_pack_entry_one(const unsigned char *sha1,
if (use_lookup) {
int pos = sha1_entry_pos(index, stride, 0,
lo, hi, p->num_objects, sha1);
- if (pos < 0)
- return 0;
- return nth_packed_object_offset(p, pos);
+ return pos;
}
do {
@@ -2032,15 +2030,24 @@ off_t find_pack_entry_one(const unsigned char *sha1,
printf("lo %u hi %u rg %u mi %u\n",
lo, hi, hi - lo, mi);
if (!cmp)
- return nth_packed_object_offset(p, mi);
+ return mi;
if (cmp > 0)
hi = mi;
else
lo = mi+1;
} while (lo < hi);
- return 0;
+ return -1;
}
+off_t find_pack_entry_one(const unsigned char *sha1,
+ struct packed_git *p)
+{
+ int pos = find_pack_entry_pos(sha1, p);
+ if (pos < 0)
+ return 0;
+ else
+ return nth_packed_object_offset(p, pos);
+}
int is_pack_valid(struct packed_git *p)
{
/* An already open pack is known to be valid. */
--
1.8.1.1.459.g5970e58
-- 8< --
^ permalink raw reply related
* Re: Anybody know a website with up-to-date git documentation?
From: Sebastian Staudt @ 2013-01-30 13:48 UTC (permalink / raw)
To: Max Horn; +Cc: git
In-Reply-To: <72077344-E4EF-43E1-A9E0-A907C423616F@quendi.de>
Hi Max,
it seems that this is some sort of caching problem on git-scm.com.
I saw you've already opened an issue at
https://github.com/github/gitscm-next/issues/232.
So there's probably not much you can do right now.
And I don't know any better source for documentation right now, apart
from the locally installed HTML version.
Best regards,
Sebastian
2013/1/30 Max Horn <max@quendi.de>:
> Hi Sebastian,
>
> On 30.01.2013, at 12:56, Sebastian Staudt wrote:
>
>> Hello Max,
>>
>> git-scm.com is the best source and it's not outdated.
>
> Then it seems you are using the word "outdated" in a different way than me which I don't understand :-). Sure, it strives to be up-to-date, but fact is that it fails to do that, due to a bug (I guess). The end result (failure to update at all, vs. failure in an attempted update) sadly amount to the same.
>
>> It gets an
>> update after every single release of Git.
>> See e.g. http://git-scm.com/docs/git-config which was updated in the
>> current stable version.
>> It seems that git-remote-helper's documentation was just not updated
>> since version 1.7.12.3.
>
> Yes, and it is not alone in that, which makes the site somewhat unreliable, sadly. Some more examples of pages tuck at version 1.7.12.3 and showing outdated content:
>
> http://git-scm.com/docs/git-log
> http://git-scm.com/docs/git-merge
> http://git-scm.com/docs/git-merge-base
> http://git-scm.com/docs/git-mergetool
> http://git-scm.com/docs/git-reset
> http://git-scm.com/docs/git-rm
> http://git-scm.com/docs/git-status
> http://git-scm.com/docs/git-symbolic-ref
>
> I did not bother to check every single page, though, and I am pretty sure there are plenty more. Because there definitely is a plethora of other pages that are stuck at 1.7.12.3. Several of them still show the latest version due to not having had updates since the 1.7.12.3, but that is not always easy to tell due to included files (e.g. git-log.txt was not changed v1.7.12.2, but it includes rev-list-options.txt which was last changed in 1.8.1).
>
>
> So, yeah, I do think git-scm.com is outdated -- in the sense that for many pages, it does not show the latest officially released version of the page.
>
>
> Best regards,
> Max
^ permalink raw reply
* Re: Anybody know a website with up-to-date git documentation?
From: Max Horn @ 2013-01-30 13:27 UTC (permalink / raw)
To: Sebastian Staudt; +Cc: git
In-Reply-To: <CA+xP2SbWKucCCPq3sS8Y2DQQM129urrM7-QzeDYju4+wA_-aUg@mail.gmail.com>
Hi Sebastian,
On 30.01.2013, at 12:56, Sebastian Staudt wrote:
> Hello Max,
>
> git-scm.com is the best source and it's not outdated.
Then it seems you are using the word "outdated" in a different way than me which I don't understand :-). Sure, it strives to be up-to-date, but fact is that it fails to do that, due to a bug (I guess). The end result (failure to update at all, vs. failure in an attempted update) sadly amount to the same.
> It gets an
> update after every single release of Git.
> See e.g. http://git-scm.com/docs/git-config which was updated in the
> current stable version.
> It seems that git-remote-helper's documentation was just not updated
> since version 1.7.12.3.
Yes, and it is not alone in that, which makes the site somewhat unreliable, sadly. Some more examples of pages tuck at version 1.7.12.3 and showing outdated content:
http://git-scm.com/docs/git-log
http://git-scm.com/docs/git-merge
http://git-scm.com/docs/git-merge-base
http://git-scm.com/docs/git-mergetool
http://git-scm.com/docs/git-reset
http://git-scm.com/docs/git-rm
http://git-scm.com/docs/git-status
http://git-scm.com/docs/git-symbolic-ref
I did not bother to check every single page, though, and I am pretty sure there are plenty more. Because there definitely is a plethora of other pages that are stuck at 1.7.12.3. Several of them still show the latest version due to not having had updates since the 1.7.12.3, but that is not always easy to tell due to included files (e.g. git-log.txt was not changed v1.7.12.2, but it includes rev-list-options.txt which was last changed in 1.8.1).
So, yeah, I do think git-scm.com is outdated -- in the sense that for many pages, it does not show the latest officially released version of the page.
Best regards,
Max
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2013, #10; Sun, 27)
From: Pete Wyckoff @ 2013-01-30 12:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlibdyfdt.fsf@alter.siamese.dyndns.org>
gitster@pobox.com wrote on Sun, 27 Jan 2013 22:45 -0800:
> * pw/git-p4-on-cygwin (2013-01-26) 21 commits
> - git p4: introduce gitConfigBool
> - git p4: avoid shell when calling git config
> - git p4: avoid shell when invoking git config --get-all
> - git p4: avoid shell when invoking git rev-list
> - git p4: avoid shell when mapping users
> - git p4: disable read-only attribute before deleting
> - git p4 test: use test_chmod for cygwin
> - git p4: cygwin p4 client does not mark read-only
> - git p4 test: avoid wildcard * in windows
> - git p4 test: use LineEnd unix in windows tests too
> - git p4 test: newline handling
> - git p4: scrub crlf for utf16 files on windows
> - git p4: remove unreachable windows \r\n conversion code
> - git p4 test: translate windows paths for cygwin
> - git p4 test: start p4d inside its db dir
> - git p4 test: use client_view in t9806
> - git p4 test: avoid loop in client_view
> - git p4 test: use client_view to build the initial client
> - git p4: generate better error message for bad depot path
> - git p4: remove unused imports
> - git p4: temp branch name should use / even on windows
>
> Improve "git p4" on Cygwin. The cover letter said it is not yet
> ready for full Windows support so I won't move this to 'next' until
> told by the author (the area maintainer) otherwise.
The series is ready as is to support Cygwin platforms, and
thus useful to people who would use git on windows via cygwin.
Future work will be to add support for Msysgit. That work
will need much of the changes in this Cygwin series as well.
It is more complicated since there's no native python for
Msysgit (yet).
I think the Cygwin changes should go in now.
-- Pete
^ permalink raw reply
* Re: Anybody know a website with up-to-date git documentation?
From: Sebastian Staudt @ 2013-01-30 11:56 UTC (permalink / raw)
To: Max Horn; +Cc: git
In-Reply-To: <20130130115439.GH1342@serenity.lan>
Hello Max,
git-scm.com is the best source and it's not outdated. It gets an
update after every single release of Git.
See e.g. http://git-scm.com/docs/git-config which was updated in the
current stable version.
It seems that git-remote-helper's documentation was just not updated
since version 1.7.12.3.
Best regards,
Sebastian
2013/1/30 John Keeping <john@keeping.me.uk>:
> On Wed, Jan 30, 2013 at 12:46:47PM +0100, Max Horn wrote:
>> does anybody know a website where one can view that latest git
>> documentation? Here, "latest" means "latest release" (though being
>> also able to access it for "next" would of course be a nice bonus,
>> likewise for older versions). While I do have those docs on my local
>> machine, I would like to access them online, too (e.g. easier to
>> pointer people at this, I can access it from other machines, etc.).
>
> How about http://git-htmldocs.googlecode.com/git/ ?
>
> It's just a directory listing of the git-htmldocs repository that Junio
> maintains - the latest update was yesterday: Autogenerated HTML docs for
> v1.8.1.2-422-g08c0e.
>
> [I didn't know Google Code let you view the repository like that, but I
> got there by clicking the "raw" link against one of the files so I
> assume it's not likely to go away.]
>
>
> John
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Anybody know a website with up-to-date git documentation?
From: John Keeping @ 2013-01-30 11:54 UTC (permalink / raw)
To: Max Horn; +Cc: git, Scott Chacon
In-Reply-To: <D6EAC791-63E2-4B0E-92AA-676112039BD9@quendi.de>
On Wed, Jan 30, 2013 at 12:46:47PM +0100, Max Horn wrote:
> does anybody know a website where one can view that latest git
> documentation? Here, "latest" means "latest release" (though being
> also able to access it for "next" would of course be a nice bonus,
> likewise for older versions). While I do have those docs on my local
> machine, I would like to access them online, too (e.g. easier to
> pointer people at this, I can access it from other machines, etc.).
How about http://git-htmldocs.googlecode.com/git/ ?
It's just a directory listing of the git-htmldocs repository that Junio
maintains - the latest update was yesterday: Autogenerated HTML docs for
v1.8.1.2-422-g08c0e.
[I didn't know Google Code let you view the repository like that, but I
got there by clicking the "raw" link against one of the files so I
assume it's not likely to go away.]
John
^ permalink raw reply
* Anybody know a website with up-to-date git documentation?
From: Max Horn @ 2013-01-30 11:46 UTC (permalink / raw)
To: git; +Cc: Scott Chacon
Hi,
does anybody know a website where one can view that latest git documentation? Here, "latest" means "latest release" (though being also able to access it for "next" would of course be a nice bonus, likewise for older versions). While I do have those docs on my local machine, I would like to access them online, too (e.g. easier to pointer people at this, I can access it from other machines, etc.).
My problem is that all sites I know of are outdated, and thus don't show recent improvements. Also, for many it is hard to determine for which version of git they carry documentation. Here are the contenders I know, and the problems they have:
* The closest I know is http://git-scm.com/ -- they fit the bill almost perfectly. Except that sadly, some pages that are crucial for me are permanently stuck at outdated versions, like http://git-scm.com/docs/git-remote-helpers which is stuck at 1.7.12.3. I tried contacting them about this for two months now, but to no avail (multiple bug reports, direct emails, etc. all went w/o reaction). Of course time and resources are limited, so I fully understand and respect that the people behind it (Scott Chacon in particular, who did an awesome job creating that site in the first place) have other priorities.
* http://www.kernel.org/pub/software/scm/git/docs/ was last updated in May 2012. No hints on who maintains this and how to contact them. Attempts to contact kernel.org webadmins to find out more were not answered either :-(. Anybody know more?
* http://schacon.github.com/git/git-remote-helpers.html was lasted updated in May 2011. I assume git-scm.com is supposed to replace it, though, as Scott Chacon made git-scm.com. (In that case, a redirect to git-scm.com might be nice *g* but of course is extra work)
* http://www.manpagez.com/man/1/git/ and http://man.he.net/man1/git at least document on each page from which git version it is taken. Unfortunately, both are stuck at the 1.7.x series.
* http://linux.die.net/man/1/git does not indicate the git version, but it seems to be a 1.7.x, too
Anybody know an up-to-date alternative? Or do I have to setup my own? :-(.
Cheers,
Max
^ permalink raw reply
* [BUG] incorrect search result returned when using git log with a future date parameter
From: Caspar Zhang @ 2013-01-30 11:30 UTC (permalink / raw)
To: git; +Cc: Gris Ge, Junio C Hamano
Hi there,
when I'm using the commit limit option `--before/--until` when doing
`git log` search, I meet a bug when the upper-bound date is 10days later
in the future. Here is an example:
$ date +%F
2013-01-30
$ git log --oneline --since=2013-01-01 --until=2013-02-01
<several git log entry from 2013-01-01 to 2013-01-30 printed>
$ git log --oneline --since=2013-01-01 --until=2013-02-13
<null>
I debugged into the problem with ./test-date program in git source tree,
got:
$ ./test-date approxidate 2013-02-01
2013-02-01 -> 2013-02-01 10:47:13 +0000 // correctly parsed
$ ./test-date approxidate 2013-02-13
2013-02-13 -> 2013-01-02 10:47:20 +0000 // incorrectly parsed
When looking into the codes of date.c, in is_date() function, I found:
382 /* Be it commit time or author time, it does not make
383 * sense to specify timestamp way into the future. Make
384 * sure it is not later than ten days from now...
385 */
386 if (now + 10*24*3600 < specified)
387 return 0;
388 tm->tm_mon = r->tm_mon;
389 tm->tm_mday = r->tm_mday;
390 if (year != -1)
391 tm->tm_year = r->tm_year;
392 return 1;
If I comment Line 386 & 387 out, the parsing works correctly. So I guess
here is the cause of the problem.
Then I checked the git history, the change was introduced in commit
38035cf4 by Junio C Hamano (cc-ed):
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
commit 38035cf4a51c48cccf6c5e3977130261bc0c03a7
Author: Junio C Hamano <junkio@cox.net>
Date: Wed Apr 5 15:31:12 2006 -0700
date parsing: be friendlier to our European friends.
This does three things, only applies to cases where the user
manually tries to override the author/commit time by environment
variables, with non-ISO, non-2822 format date-string:
- Refuses to use the interpretation to put the date in the
future; recent kernel history has a commit made with
10/03/2006 which is recorded as October 3rd.
- Adds '.' as the possible year-month-date separator. We
learned from our European friends on the #git channel that
dd.mm.yyyy is the norm there.
- When the separator is '.', we prefer dd.mm.yyyy over
mm.dd.yyyy; otherwise mm/dd/yy[yy] takes precedence over
dd/mm/yy[yy].
Signed-off-by: Junio C Hamano <junkio@cox.net>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It seems like the original commit was going to fix European date style,
but it fixed(?) the future date problem as well. However, this part of
fix is not perfect:
1) it makes date parsing not working correctly. (see my test examples
above).
IMO, it should be in another place (maybe in commit.c or somewhere
else?) we check if commit date is valid or not, instead of in the date
parsing function. A date parsing function should parse _all dates with
correctly format_, despite if it's an old date, or the date in the future.
2) from the test example I gave above, in fact the codes don't really
prevent git from accepting the changes with illegal date, e.g., if there
is a commit recorded as "2013-02-13", it will be parsed to "2013-01-02",
which is a legal (old) date, thus, this commit will be accepted, but
this is wrong.
My suggestion is we might need to revert the first part of commit
38035cf4 since this part of code doesn't work correctly and causes
problems; then we should create a new checking mechanism to prevent
those "future date commits" to be accepted in other functions. I'm not
able to do the second part since I'm not familiar with git codes yet.. :-(
Thoughts?
Caspar
^ permalink raw reply
* [BUG] incorrect search result returned when using git log with a future date parameter
From: Caspar Zhang @ 2013-01-30 11:28 UTC (permalink / raw)
To: git; +Cc: Gris Ge, Junio C Hamano
Hi there,
when I'm using the commit limit option `--before/--until` when doing
`git log` search, I meet a bug when the upper-bound date is 10days later
in the future. Here is an example:
$ date +%F
2013-01-30
$ git log --oneline --since=2013-01-01 --until=2013-02-01
<several git log entry from 2013-01-01 to 2013-01-30 printed>
$ git log --oneline --since=2013-01-01 --until=2013-02-13
<null>
I debugged into the problem with ./test-date program in git source tree,
got:
$ ./test-date approxidate 2013-02-01
2013-02-01 -> 2013-02-01 10:47:13 +0000 // correctly parsed
$ ./test-date approxidate 2013-02-13
2013-02-13 -> 2013-01-02 10:47:20 +0000 // incorrectly parsed
When looking into the codes of date.c, in is_date() function, I found:
382 /* Be it commit time or author time, it does not make
383 * sense to specify timestamp way into the future. Make
384 * sure it is not later than ten days from now...
385 */
386 if (now + 10*24*3600 < specified)
387 return 0;
388 tm->tm_mon = r->tm_mon;
389 tm->tm_mday = r->tm_mday;
390 if (year != -1)
391 tm->tm_year = r->tm_year;
392 return 1;
If I comment Line 386 & 387 out, the parsing works correctly. So I guess
here is the cause of the problem.
Then I checked the git history, the change was introduced in commit
38035cf4 by Junio C Hamano (cc-ed):
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
commit 38035cf4a51c48cccf6c5e3977130261bc0c03a7
Author: Junio C Hamano <junkio@cox.net>
Date: Wed Apr 5 15:31:12 2006 -0700
date parsing: be friendlier to our European friends.
This does three things, only applies to cases where the user
manually tries to override the author/commit time by environment
variables, with non-ISO, non-2822 format date-string:
- Refuses to use the interpretation to put the date in the
future; recent kernel history has a commit made with
10/03/2006 which is recorded as October 3rd.
- Adds '.' as the possible year-month-date separator. We
learned from our European friends on the #git channel that
dd.mm.yyyy is the norm there.
- When the separator is '.', we prefer dd.mm.yyyy over
mm.dd.yyyy; otherwise mm/dd/yy[yy] takes precedence over
dd/mm/yy[yy].
Signed-off-by: Junio C Hamano <junkio@cox.net>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It seems like the original commit was going to fix European date style,
but it fixed(?) the future date problem as well. However, this part of
fix is not perfect:
1) it makes date parsing not working correctly. (see my test examples
above).
IMO, it should be in another place (maybe in commit.c or somewhere
else?) we check if commit date is valid or not, instead of in the date
parsing function. A date parsing function should parse _all dates with
correctly format_, despite if it's an old date, or the date in the future.
2) from the test example I gave above, in fact the codes don't really
prevent git from accepting the changes with illegal date, e.g., if there
is a commit recorded as "2013-02-13", it will be parsed to "2013-01-02",
which is a legal (old) date, thus, this commit will be accepted, but
this is wrong.
My suggestion is we might need to revert the first part of commit
38035cf4 since this part of code doesn't work correctly and causes
problems; then we should create a new checking mechanism to prevent
those "future date commits" to be accepted in other functions. I'm not
able to do the second part since I'm not familiar with git codes yet.. :-(
Thoughts?
Caspar
^ permalink raw reply
* Re: [RFC/PATCH v2] CodingGuidelines: add Python coding guidelines
From: Michael Haggerty @ 2013-01-30 10:05 UTC (permalink / raw)
To: John Keeping; +Cc: git
In-Reply-To: <20130129190844.GB1342@serenity.lan>
On 01/29/2013 08:08 PM, John Keeping wrote:
> These are kept short by simply deferring to PEP-8. Most of the Python
> code in Git is already very close to this style (some things in contrib/
> are not).
>
> Rationale for version suggestions:
>
> - Amongst the noise in [1], there isn't any disagreement about using
> 2.6 as a base (see also [2]), although Brandon Casey recently added
> support for 2.4 and 2.5 to git-p4 [3].
>
> - Restricting ourselves to 2.6+ makes aiming for Python 3 compatibility
> significantly easier [4].
>
> - Advocating Python 3 support in all scripts is currently unrealistic
> because:
>
> - 'p4 -G' provides output in a format that is very hard to use with
> Python 3 (and its documentation claims Python 3 is unsupported).
>
> - Mercurial does not support Python 3.
>
> - Bazaar does not support Python 3.
>
> - But we should try to make new scripts compatible with Python 3
> because all new Python development is happening on version 3 and the
> Python community will eventually stop supporting Python 2 [5].
>
> - Python 3.1 is required to support the 'surrogateescape' error handler
> for encoding/decodng filenames to/from Unicode strings and Python 3.0
> is not longer supported.
>
> [1] http://thread.gmane.org/gmane.comp.version-control.git/210329
> [2] http://article.gmane.org/gmane.comp.version-control.git/210429
> [3] http://thread.gmane.org/gmane.comp.version-control.git/214579
> [4] http://docs.python.org/3.3/howto/pyporting.html#try-to-support-python-2-6-and-newer-only
> [5] http://www.python.org/dev/peps/pep-0404/
>
> ---
> Changes since v1:
>
> - Set 3.1 as the minimum Python 3 version
>
> - Remove the section on Unicode literals - it just adds confusion and
> doesn't apply to the current code; we can deal with any issues if they
> ever arise.
>
> Documentation/CodingGuidelines | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
> index 69f7e9b..db7a416 100644
> --- a/Documentation/CodingGuidelines
> +++ b/Documentation/CodingGuidelines
> @@ -179,6 +179,19 @@ For C programs:
> - Use Git's gettext wrappers to make the user interface
> translatable. See "Marking strings for translation" in po/README.
>
> +For Python scripts:
> +
> + - We follow PEP-8 (http://www.python.org/dev/peps/pep-0008/).
> +
> + - As a minimum, we aim to be compatible with Python 2.6 and 2.7.
> +
> + - Where required libraries do not restrict us to Python 2, we try to
> + also be compatible with Python 3.1 and later.
> +
> + - We use the 'b' prefix for bytes literals. Note that even though
> + the Python documentation for version 2.6 does not mention this
> + prefix it is supported since version 2.6.0.
> +
> Writing Documentation:
>
> Every user-visible change should be reflected in the documentation.
>
Nit: s/it is supported/it has been supported/
I think this would be a good Python policy.
I would hate to junk up all Python code with things like
' '.encode('ascii')
though, so maybe we should establish a small Python library of
compatibility utilities (like a small "six"). It could contain b().
Another handy utility function could be
def check_python_version(minimum_v2=0x02060000,
minimum_v3=0x03010000)
which checks our default Python requirements by default, but is
overrideable by specific scripts if they know that they can deal with
older Python versions.
But I haven't had time to think of where to put such a library, how to
install it, etc.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [PATCH/RFC 0/6] commit caching
From: Duy Nguyen @ 2013-01-30 8:32 UTC (permalink / raw)
To: Jeff King; +Cc: git, Shawn O. Pearce
In-Reply-To: <20130130071839.GF11147@sigill.intra.peff.net>
On Wed, Jan 30, 2013 at 2:18 PM, Jeff King <peff@peff.net> wrote:
> On Wed, Jan 30, 2013 at 10:31:43AM +0700, Nguyen Thai Ngoc Duy wrote:
>
>> On Tue, Jan 29, 2013 at 4:14 PM, Jeff King <peff@peff.net> wrote:
>> > The timings from this one are roughly similar to what I posted earlier.
>> > Unlike the earlier version, this one keeps the data for a single commit
>> > together for better cache locality (though I don't think it made a big
>> > difference in my tests, since my cold-cache timing test ends up touching
>> > every commit anyway). The short of it is that for an extra 31M of disk
>> > space (~4%), I get a warm-cache speedup for "git rev-list --all" of
>> > ~4.2s to ~0.66s.
>>
>> Some data point on caching 1-parent vs 2-parent commits on webkit
>> repo, 26k commits. With your changes (caching 2-parent commits), the
>> .commits file takes 2241600 bytes. "rev-list --all --quiet":
>
> Hmm. My webkit repo has zero merges in it (though it is the older
> svn-based one). What percentage of the one you have are merges? How does
> your 1-parent cache perform on something like git.git, where about 25%
> of all commits are merges?
git.git performs worse with 1-parent cache. But the point is it should
be customizable.
>> The performance loss in 1-parent case is not significant while disk
>> saving is (although it'll be less impressive after you do Shawn's
>> suggestion not storing SHA-1 directly)
>
> Yeah, I think moving to offsets instead of sha1s is going to be a big
> enough win that it won't matter anymore.
Yeah, if we use uint32_t instead of sha-1, the cache is just about
400k 2 parents for webkit, 312k for 1 parent. The total size is so
small that reduction does not really matter anymore.
--
Duy
^ permalink raw reply
* Re: Updating shared ref from remote helper, or fetch hook
From: Jed Brown @ 2013-01-30 8:06 UTC (permalink / raw)
To: git; +Cc: Max Horn
In-Reply-To: <87ehh5lw9j.fsf@59A2.org>
Jed Brown <jed@59A2.org> writes:
> I'm working on an hg remote helper that uses git notes for the sha1
> revision, so that git users can more easily refer to specific commits
> when communicating with hg users. Since there may be multiple
> concurrent fast-import streams, I write the notes to a private ref
> (refs/notes/hg-REMOTE), to be merged eventually using
>
> git notes --ref hg merge hg-REMOTE*
A related issue is that when a remote helper replies to an 'import' with
_only_ a commit in refs/notes/, git (fetch or pull) produces an error
message like
error: refs/notes/hg-84b3865b750a567acb16929c21e14c4a45a5639b does not point to a valid object
but successfully updates the ref (which is indeed valid) and returns
0. I have not been able to determine what exactly git thinks is
invalid. As long as there is at least one non-notes commit in the
stream, no such error message is produced.
Is this behavior intended?
^ permalink raw reply
* Re: [PATCH] git-send-email: add ~/.authinfo parsing
From: Jeff King @ 2013-01-30 7:43 UTC (permalink / raw)
To: Michal Nazarewicz; +Cc: Junio C Hamano, git, Krzysztof Mazur, Michal Nazarewicz
In-Reply-To: <7vvcafojf4.fsf@alter.siamese.dyndns.org>
On Tue, Jan 29, 2013 at 11:53:19AM -0800, Junio C Hamano wrote:
> Either way it still encourages a plaintext password to be on disk,
> which may not be what we want, even though it may be slight if not
> really much of an improvement. Again the Help-for-users has this
> amusing bit:
I do not mind a .netrc or .authinfo parser, because while those formats
do have security problems, they are standard files that may already be
in use. So as long as we are not encouraging their use, I do not see a
problem in supporting them (and we already do the same with curl's netrc
support).
But it would probably make sense for send-email to support the existing
git-credential subsystem, so that it can take advantage of secure
system-specific storage. And that is where we should be pointing new
users. I think contrib/mw-to-git even has credential support written in
perl, so it would just need to be factored out to Git.pm.
-Peff
^ permalink raw reply
* Re: [PATCH v2 0/3] transfer.hiderefs
From: Junio C Hamano @ 2013-01-30 7:19 UTC (permalink / raw)
To: git
In-Reply-To: <7vham0tvus.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Please take this as just a preview of early WIP. I think I may end
> up doing moderate amount of refactoring as a preparatory step before
> these patches, so nitpick-reviews are likely to become waste of
> reviewer's time at this point.
I've pushed out a mostly-done reroll on 'pu'; I'll send them out as
patches for review tomorrow. I think I am making a good progress.
^ permalink raw reply
* Re: [PATCH/RFC 0/6] commit caching
From: Jeff King @ 2013-01-30 7:18 UTC (permalink / raw)
To: Duy Nguyen; +Cc: git, Shawn O. Pearce
In-Reply-To: <CACsJy8BE3LdxbZzdQXuvEJop23KnnLbCTgPos9CywKV7EY2q9g@mail.gmail.com>
On Wed, Jan 30, 2013 at 10:31:43AM +0700, Nguyen Thai Ngoc Duy wrote:
> On Tue, Jan 29, 2013 at 4:14 PM, Jeff King <peff@peff.net> wrote:
> > The timings from this one are roughly similar to what I posted earlier.
> > Unlike the earlier version, this one keeps the data for a single commit
> > together for better cache locality (though I don't think it made a big
> > difference in my tests, since my cold-cache timing test ends up touching
> > every commit anyway). The short of it is that for an extra 31M of disk
> > space (~4%), I get a warm-cache speedup for "git rev-list --all" of
> > ~4.2s to ~0.66s.
>
> Some data point on caching 1-parent vs 2-parent commits on webkit
> repo, 26k commits. With your changes (caching 2-parent commits), the
> .commits file takes 2241600 bytes. "rev-list --all --quiet":
Hmm. My webkit repo has zero merges in it (though it is the older
svn-based one). What percentage of the one you have are merges? How does
your 1-parent cache perform on something like git.git, where about 25%
of all commits are merges?
> The performance loss in 1-parent case is not significant while disk
> saving is (although it'll be less impressive after you do Shawn's
> suggestion not storing SHA-1 directly)
Yeah, I think moving to offsets instead of sha1s is going to be a big
enough win that it won't matter anymore.
-Peff
^ 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