* 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: 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: 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: [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: 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: [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: [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: 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] 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
* 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 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
* 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: 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: 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: Junio C Hamano @ 2013-01-30 16:46 UTC (permalink / raw)
To: Max Horn; +Cc: git, Scott Chacon
In-Reply-To: <D6EAC791-63E2-4B0E-92AA-676112039BD9@quendi.de>
Max Horn <max@quendi.de> writes:
> 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).
Preformatted ones for the tip of 'master' are reachable from
http://git-htmldocs.googlecode.com/git/git.html
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2013, #10; Sun, 27)
From: Junio C Hamano @ 2013-01-30 16:47 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: git
In-Reply-To: <20130130123420.GA3793@padd.com>
Pete Wyckoff <pw@padd.com> writes:
> gitster@pobox.com wrote on Sun, 27 Jan 2013 22:45 -0800:
>> * pw/git-p4-on-cygwin (2013-01-26) 21 commits
>> ...
>> 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.
OK, so let's treat that as a completely separate topic that comes on
top after this series is done.
Thanks; will start merging down.
^ permalink raw reply
* Re: Anybody know a website with up-to-date git documentation?
From: Max Horn @ 2013-01-30 17:05 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: John Keeping, git, Scott Chacon
In-Reply-To: <CAMK1S_i+ML+HuTRuox5rU4bsV0+xoFLWpK63WrdXuzhgyHJbrA@mail.gmail.com>
On 30.01.2013, at 16:59, Sitaram Chamarty wrote:
> I'm curious... what's wrong with 'git checkout html' from the git repo
> and just browsing them using a web browser?
Hm, do you mean "make html", perhaps? At least I couldn't figure out what "git checkout html" should do, but out of curiosity gave it a try and got an error...
But supposing that you meant "make html": There is nothing "wrong" with it. This is mostly a matter of convenience:
* Many people just use git and don't have the git.git repos (or any git sources) at hand. And while for many things, older versions of the reference pages may suffice, this is not always the case.
* When I want to point somebody at something specific in the git docs while, say, while discussing on IRC or a mailing list, it is very convenient to point them at a website, like this:
http://git-htmldocs.googlecode.com/git/git-fast-import.html#_code_notemodify_code
* Similarly if I am standing physically next to somebody sitting at their computer and they ask me something about git, it is nice to be able to send them to a current version of the docs online
* I can access the web version from my tablet -- and I actually do that (use my tablet as "secondary screen" showing some git refs and other docs while coding on my laptop).
* a website can be update by one person (or ideally: one script) and serve many people with the same need Seems more efficient than each of those people setting up an appropriate clone & a cron job to keep it up-to-date on each machine where they need it.
But of course, the "make html" has its own clear advantages, e.g. I can use it online, I have full control over which exact version of the docs I get, including most recent changes, etc. To me, the two complement each other.
Anyway, I'll stop spamming the list, I got my answers from John and Junio:
http://git-htmldocs.googlecode.com/git/git.html
and in addition
http://manned.org/git.1
Thanks again,
Max
^ permalink raw reply
* Re: Anybody know a website with up-to-date git documentation?
From: Junio C Hamano @ 2013-01-30 17:18 UTC (permalink / raw)
To: Max Horn; +Cc: Sitaram Chamarty, John Keeping, git, Scott Chacon
In-Reply-To: <6BE76AE4-254E-43DD-A3FF-88B5486029A5@quendi.de>
Max Horn <max@quendi.de> writes:
[administrivia: please wrap lines to a reasonable width]
> On 30.01.2013, at 16:59, Sitaram Chamarty wrote:
>
>> I'm curious... what's wrong with 'git checkout html' from the git repo
>> and just browsing them using a web browser?
>
> Hm, do you mean "make html", perhaps? At least I couldn't figure
> out what "git checkout html" should do, but out of curiosity gave
> it a try and got an error...
Perhaps some information from "A note from the maintainer" (posted
to this list from time to time) is lacking. Some excerpts:
You can browse the HTML manual pages at:
http://git-htmldocs.googlecode.com/git/git.html
Preformatted documentation from the tip of the "master" branch can be
found in:
git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
git://repo.or.cz/git-{htmldocs,manpages}.git/
...
Armed with that knowledge, I think Sitaram may have something like
this:
[remote "htmldocs"]
url = git://git.kernel.org/pub/scm/git/git-htmldocs.git/
fetch = +refs/heads/master:refs/heads/html
and does
git fetch htmldocs
git checkout html
You can, too, of course ;-)
^ permalink raw reply
* [PATCH 0/7] perl/Git.pm: a bunch of fixes for Windows
From: Gustavo L. de M. Chaves @ 2013-01-30 17:22 UTC (permalink / raw)
To: git; +Cc: Gustavo L. de M. Chaves
From: "Gustavo L. de M. Chaves" <gnustavo@cpan.org>
I'm working on Git::Hooks, a Perl module to facilitate the
implementation of git hooks. (http://search.cpan.org/dist/Git-Hooks/)
Git::Hooks uses the Git module implemented in perl/Git.pm and
distributed with git.
While working on porting Git::Hooks to Windows I stumbled upon a few
problems in the Git module, problems specific to the Windows
environment. In the following sequence of patches I try to fix them.
For the record, I'm using Strawberry Perl on Windows.
This is my first patch submission to git. I tried to follow all the
project conventions but I may have done it wrong. If so, please, help
me learn it.
Thanks!
Gustavo L. de M. Chaves (7):
perl/Git.pm: test portably if a path is absolute
perl/Git.pm: set up command environment on Windows
perl/Git.pm: fix _cmd_close on Windows
perl/Git.pm: escape external command's arguments on Windows
perl/Git.pm: simplify Git::activestate_pipe
perl/Git.pm: make command pipe work in slurp-mode on Windows
perl/Git.pm: rename 'ActiveState' to 'Windows'
perl/Git.pm | 63 +++++++++++++++++++++++++++++++++++--------------------------
1 file changed, 36 insertions(+), 27 deletions(-)
--
1.7.12.464.g83379df.dirty
^ permalink raw reply
* [PATCH 2/7] perl/Git.pm: set up command environment on Windows
From: Gustavo L. de M. Chaves @ 2013-01-30 17:22 UTC (permalink / raw)
To: git; +Cc: Gustavo L. de M. Chaves
In-Reply-To: <1359566583-19654-1-git-send-email-gnustavo@cpan.org>
From: "Gustavo L. de M. Chaves" <gnustavo@cpan.org>
Routine _cmd_exec invokes _setup_git_cmd_env inside the child process
before invoking an external git command to set up the environment
variables GIT_DIR and GIT_WORK_TREE and, also, to chdir to the
repository. But _cmd_exec is only used on Unix. On Windows, it's not
used and the main code path is in _command_common_pipe, which didn't
prepare the environment like _cmd_exec.
Without this environment preparation some git commands, such as "git
clone", don't work.
We can't use _setup_git_cmd_env in this case because we don't use a
forking open like _cmd_exec does and don't get a chance to make such
preparations on the child process.
So, the preparation is done on _command_common_pipe by setting up
localized environment variables and by chdir temporarily just before
invoking the external command.
Signed-off-by: Gustavo L. de M. Chaves <gnustavo@cpan.org>
---
perl/Git.pm | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/perl/Git.pm b/perl/Git.pm
index 658b602..e14b41a 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -1302,6 +1302,19 @@ sub _command_common_pipe {
# warn 'ignoring STDERR option - running w/ ActiveState';
$direction eq '-|' or
die 'input pipe for ActiveState not implemented';
+
+ # Set up repo environment
+ local $ENV{GIT_DIR} = $self->repo_path() if defined $self && $self->repo_path();
+ local $ENV{GIT_WORK_TREE} = $self->wc_path() if defined $self && $self->repo_path() && $self->wc_path();
+
+ my $cwd = cwd;
+
+ if (defined $self) {
+ chdir $self->repo_path() if $self->repo_path();
+ chdir $self->wc_path() if $self->wc_path();
+ chdir $self->wc_subdir() if $self->wc_subdir();
+ }
+
# the strange construction with *ACPIPE is just to
# explain the tie below that we want to bind to
# a handle class, not scalar. It is not known if
@@ -1310,6 +1323,7 @@ sub _command_common_pipe {
tie (*ACPIPE, 'Git::activestate_pipe', $cmd, @args);
$fh = *ACPIPE;
+ chdir $cwd;
} else {
my $pid = open($fh, $direction);
if (not defined $pid) {
--
1.7.12.464.g83379df.dirty
^ permalink raw reply related
* [PATCH 5/7] perl/Git.pm: simplify Git::activestate_pipe
From: Gustavo L. de M. Chaves @ 2013-01-30 17:23 UTC (permalink / raw)
To: git; +Cc: Gustavo L. de M. Chaves
In-Reply-To: <1359566583-19654-1-git-send-email-gnustavo@cpan.org>
From: "Gustavo L. de M. Chaves" <gnustavo@cpan.org>
Git::activestate_pipe::TIEHANDLE creates an object to keep the
external command's output as an array of lines. The object also kept
an index into the array to know up to which line had already been read
via Git::activestate_pipe::READLINE.
We don't really need that index because lines already read don't need
to be kept. So, we simply unshift lines as they're being read and use
the array's size to know when we have read all lines.
This implementation uses more idiomatic Perl, which makes it more
readable and probably a little bit faster.
Signed-off-by: Gustavo L. de M. Chaves <gnustavo@cpan.org>
---
perl/Git.pm | 17 ++++++-----------
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/perl/Git.pm b/perl/Git.pm
index 42c3971..2d88b89 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -1402,33 +1402,28 @@ sub TIEHANDLE {
# should take care of the most common cases.
my @escaped_params = map { "\"$_\"" } map { s/"/""/g; $_ } @params;
my @data = qx{git @escaped_params};
- bless { i => 0, data => \@data, exit => $? }, $class;
+ bless { data => \@data, exit => $? }, $class;
}
sub READLINE {
my $self = shift;
- if ($self->{i} >= scalar @{$self->{data}}) {
- return undef;
- }
- my $i = $self->{i};
+ return unless @{$self->{data}};
if (wantarray) {
- $self->{i} = $#{$self->{'data'}} + 1;
- return splice(@{$self->{'data'}}, $i);
+ return splice @{$self->{data}};
+ } else {
+ return shift @{$self->{data}};
}
- $self->{i} = $i + 1;
- return $self->{'data'}->[ $i ];
}
sub CLOSE {
my $self = shift;
delete $self->{data};
- delete $self->{i};
return $self->{exit} == 0;
}
sub EOF {
my $self = shift;
- return ($self->{i} >= scalar @{$self->{data}});
+ return @{$self->{data}} == 0;
}
--
1.7.12.464.g83379df.dirty
^ permalink raw reply related
* [PATCH 4/7] perl/Git.pm: escape external command's arguments on Windows
From: Gustavo L. de M. Chaves @ 2013-01-30 17:23 UTC (permalink / raw)
To: git; +Cc: Gustavo L. de M. Chaves
In-Reply-To: <1359566583-19654-1-git-send-email-gnustavo@cpan.org>
From: "Gustavo L. de M. Chaves" <gnustavo@cpan.org>
On Windows, the external git commands are invoked using backticks by
Git::activestate_pipe::TIEHANDLE, but there was no attempt to properly
quote their arguments. This caused problems with all but the simplest
command invokations.
The arguments are now surrounded by quotes and internal quotes are
doubled. This is not a complete quoting solution but takes care of
some of the most common problems on Windows.
Signed-off-by: Gustavo L. de M. Chaves <gnustavo@cpan.org>
---
perl/Git.pm | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/perl/Git.pm b/perl/Git.pm
index ef3134b..42c3971 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -1398,12 +1398,10 @@ use strict;
sub TIEHANDLE {
my ($class, @params) = @_;
- # FIXME: This is probably horrible idea and the thing will explode
- # at the moment you give it arguments that require some quoting,
- # but I have no ActiveState clue... --pasky
- # Let's just hope ActiveState Perl does at least the quoting
- # correctly.
- my @data = qx{git @params};
+ # FIXME: The quoting done below is not completely right but it
+ # should take care of the most common cases.
+ my @escaped_params = map { "\"$_\"" } map { s/"/""/g; $_ } @params;
+ my @data = qx{git @escaped_params};
bless { i => 0, data => \@data, exit => $? }, $class;
}
--
1.7.12.464.g83379df.dirty
^ permalink raw reply related
* [PATCH 6/7] perl/Git.pm: make command pipe work in slurp-mode on Windows
From: Gustavo L. de M. Chaves @ 2013-01-30 17:23 UTC (permalink / raw)
To: git; +Cc: Gustavo L. de M. Chaves
In-Reply-To: <1359566583-19654-1-git-send-email-gnustavo@cpan.org>
From: "Gustavo L. de M. Chaves" <gnustavo@cpan.org>
Git::activestate_pipe::READLINE implementation wasn't working when the
pipe was read in slurp-mode (i.e., with $/ undefined).
Now, when in slurp-mode it correctly returns the remaining lines
joined together.
Signed-off-by: Gustavo L. de M. Chaves <gnustavo@cpan.org>
---
perl/Git.pm | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/perl/Git.pm b/perl/Git.pm
index 2d88b89..fdef024 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -1410,8 +1410,10 @@ sub READLINE {
return unless @{$self->{data}};
if (wantarray) {
return splice @{$self->{data}};
- } else {
+ } elsif (defined $/) {
return shift @{$self->{data}};
+ } else {
+ return join('', splice @{$self->{data}});
}
}
--
1.7.12.464.g83379df.dirty
^ permalink raw reply related
* [PATCH 3/7] perl/Git.pm: fix _cmd_close on Windows
From: Gustavo L. de M. Chaves @ 2013-01-30 17:22 UTC (permalink / raw)
To: git; +Cc: Gustavo L. de M. Chaves
In-Reply-To: <1359566583-19654-1-git-send-email-gnustavo@cpan.org>
From: "Gustavo L. de M. Chaves" <gnustavo@cpan.org>
The Git::activestate_pipe::CLOSE routine wasn't explicitly returning
anything. This means that on Windows the routine _cmd_close wasn't
checking correctly the external command's exit code.
Now we store the command's exit code on the object created by
Git::activestate_pipe::TIEHANDLE and return a sensible value on
Git::activestate_pipe::CLOSE to _cmd_close.
Signed-off-by: Gustavo L. de M. Chaves <gnustavo@cpan.org>
---
perl/Git.pm | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/perl/Git.pm b/perl/Git.pm
index e14b41a..ef3134b 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -1404,7 +1404,7 @@ sub TIEHANDLE {
# Let's just hope ActiveState Perl does at least the quoting
# correctly.
my @data = qx{git @params};
- bless { i => 0, data => \@data }, $class;
+ bless { i => 0, data => \@data, exit => $? }, $class;
}
sub READLINE {
@@ -1425,6 +1425,7 @@ sub CLOSE {
my $self = shift;
delete $self->{data};
delete $self->{i};
+ return $self->{exit} == 0;
}
sub EOF {
--
1.7.12.464.g83379df.dirty
^ permalink raw reply related
* [PATCH 1/7] perl/Git.pm: test portably if a path is absolute
From: Gustavo L. de M. Chaves @ 2013-01-30 17:22 UTC (permalink / raw)
To: git; +Cc: Gustavo L. de M. Chaves
In-Reply-To: <1359566583-19654-1-git-send-email-gnustavo@cpan.org>
From: "Gustavo L. de M. Chaves" <gnustavo@cpan.org>
The code was testing if a path was absolute by checking if its first
character was a '/'. This does not work on Windows.
The portable way to do it is to use File::Spec::file_name_is_absolute.
Signed-off-by: Gustavo L. de M. Chaves <gnustavo@cpan.org>
---
perl/Git.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/perl/Git.pm b/perl/Git.pm
index 931047c..658b602 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -185,7 +185,7 @@ sub repository {
};
if ($dir) {
- $dir =~ m#^/# or $dir = $opts{Directory} . '/' . $dir;
+ $dir = $opts{Directory} . '/' . $dir unless File::Spec->file_name_is_absolute($dir);
$opts{Repository} = abs_path($dir);
# If --git-dir went ok, this shouldn't die either.
--
1.7.12.464.g83379df.dirty
^ permalink raw reply related
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