* Re: collapsing commits with rebase
From: Geoff Russell @ 2009-01-08 1:59 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0901080144270.30769@pacific.mpi-cbg.de>
On Thu, Jan 8, 2009 at 11:15 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Thu, 8 Jan 2009, Geoff Russell wrote:
>
>> Dear gits,
>>
>> I have a series of commits:
>>
>> A---B---C---D---E---F
>>
>> I want to collapse B---C---D into one single commit. git rebase -i B
>> will allow me to do this, but I'm looking for a non-interactive
>> incantation.
>
> You set GIT_EDITOR to a script ;-)
This is plan B.
>
> Alternatively, something like this should work for you:
>
> $ git checkout A
> $ git read-tree -u -m D
> $ git commit -m "My message"
> $ git cherry-pick E
> $ git cherry-pick F
Plan B is looking good, because I'd generally like the commit message to be the
concatenation of the messages for B,C and D.
Many thanks.
Geoff.
^ permalink raw reply
* Re: collapsing commits with rebase
From: Boyd Stephen Smith Jr. @ 2009-01-08 2:11 UTC (permalink / raw)
To: geoffrey.russell; +Cc: git
In-Reply-To: <93c3eada0901071608r190a723bma502b68c4ab81a08@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 846 bytes --]
On Wednesday 2009 January 07 18:08:44 Geoff Russell wrote:
>I have a series of commits:
>
> A---B---C---D---E---F
Assuming you also have a ref (e.g. Foo) that points to F:
git checkout sha(B)
git merge -s sha(D)
git rebase --onto $(cat .git/HEAD) sha(E) Foo
should do what you want.
After the checkout:
A -> B [HEAD] -> C -> D -> E -> F [Foo]
(detached HEAD)
After the merge:
A -> B -> C -> D -> E -> F [Foo]
|
+--> [HEAD]
(detached HEAD)
After the rebase:
A -> B -> E' -> F' [Foo, HEAD]
|
+--> C -> D -> E -> F
(C, D, E, and F will be pruned at some point)
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Public repro case! Re: [PATCH/RFC] Allow writing loose objects that are corrupted in a pack file
From: James Pickens @ 2009-01-08 2:21 UTC (permalink / raw)
To: Git ML
Cc: R. Tyler Ballance, Nicolas Pitre, Jan Krüger, kb,
Linus Torvalds
In-Reply-To: <alpine.LFD.2.00.0901071644330.3283@localhost.localdomain>
On Wed, Jan 7, 2009, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> Can you cnfirm that your "reproducible" case starts working with that
> addition to your ~/.gitconfig? If so, the solution is pretty simple: we
> should just lower the default pack windowsize.
Umm... isn't that more of a workaround than a solution? I.e., if you lower
the default pack windowsize, couldn't the corruption still happen under the
right conditions?
James
^ permalink raw reply
* Re: [PATCH 0/3] Teach Git about the patience diff algorithm
From: Sam Vilain @ 2009-01-08 2:31 UTC (permalink / raw)
To: Linus Torvalds
Cc: Johannes Schindelin, Pierre Habouzit, davidel, Francis Galiegue,
Git ML
In-Reply-To: <alpine.LFD.2.00.0901071222300.3057@localhost.localdomain>
Linus Torvalds wrote:
> On Thu, 8 Jan 2009, Sam Vilain wrote:
>
>> Whatever happens, the current deterministic diff algorithm needs to stay
>> for generating patch-id's... those really can't be allowed to change.
>>
>
> Sure they can.
>
> We never cache patch-id's over a long time. And we _have_ changed xdiff to
> modify the output of the patches before, quite regardless of any patience
> issues: see commit 9b28d55401a529ff08c709f42f66e765c93b0a20, which
> admittedly doesn't affect any _normal_ diffs, but can generate subtly
> different results for some cases.
>
There's at least one person who thinks that they should be deterministic
enough to be able to be placed in commit messages;
http://article.gmane.org/gmane.comp.version-control.git/95671
Now of course the git cherry-pick feature to add the old patch ID to the
commit message isn't written yet; but unless there was a fall-back mode
to produce a "stable" patch ID, these breadcrumbs would become (even
more) worthless.
Sam
^ permalink raw reply
* Re: collapsing commits with rebase
From: Miklos Vajna @ 2009-01-08 2:32 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: geoffrey.russell, git
In-Reply-To: <200901072011.37299.bss@iguanasuicide.net>
[-- Attachment #1: Type: text/plain, Size: 266 bytes --]
On Wed, Jan 07, 2009 at 08:11:32PM -0600, "Boyd Stephen Smith Jr." <bss@iguanasuicide.net> wrote:
> git merge -s sha(D)
You probably mean --squash here, -s stands for --strategy - and I *hope*
you don't have git-sha(D) in your PATH, as a custom merge strategy. ;-)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: collapsing commits with rebase
From: Boyd Stephen Smith Jr. @ 2009-01-08 2:39 UTC (permalink / raw)
To: Miklos Vajna; +Cc: geoffrey.russell, git
In-Reply-To: <20090108023224.GU21154@genesis.frugalware.org>
[-- Attachment #1: Type: text/plain, Size: 598 bytes --]
On Wednesday 2009 January 07 20:32:24 Miklos Vajna wrote:
>On Wed, Jan 07, 2009 at 08:11:32PM -0600, "Boyd Stephen Smith Jr."
<bss@iguanasuicide.net> wrote:
>> git merge -s sha(D)
>
>You probably mean --squash here, -s stands for --strategy - and I *hope*
>you don't have git-sha(D) in your PATH, as a custom merge strategy. ;-)
Oops. Yes. My mistake.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Public repro case! Re: [PATCH/RFC] Allow writing loose objects that are corrupted in a pack file
From: Shawn O. Pearce @ 2009-01-08 2:43 UTC (permalink / raw)
To: James Pickens
Cc: Git ML, R. Tyler Ballance, Nicolas Pitre, Jan Krüger, kb,
Linus Torvalds
In-Reply-To: <885649360901071821t2ea481b5k83ab800f6aeb897@mail.gmail.com>
James Pickens <jepicken@gmail.com> wrote:
> On Wed, Jan 7, 2009, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> > Can you cnfirm that your "reproducible" case starts working with that
> > addition to your ~/.gitconfig? If so, the solution is pretty simple: we
> > should just lower the default pack windowsize.
>
> Umm... isn't that more of a workaround than a solution? I.e., if you lower
> the default pack windowsize, couldn't the corruption still happen under the
> right conditions?
Uhm, yea. So I managed to reproduce it on a Linux system here.
Different object ids than R. Tyler's case, but I'm going to try
to debug it and see why we are getting these.
For those following along at home, Linus' 2.6 tree:
$ ulimit -v `echo '150 * 1024'|bc -l`
$ git co 56d18e9932ebf4e8eca42d2ce509450e6c9c1666
HEAD is now at 56d18e9... Merge branch 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus
$ git merge 9e42d0cf5020aaf217433cad1a224745241d212a
Updating 56d18e9..9e42d0c
error: failed to read delta base object ef135b90084f3c54fccea4e273aeff029db2d873 at offset 48342508 from .git/objects/pack/pack-edb47354be787909e05c15bd1d9eb8b4684d2e4d.pack
error: failed to read delta base object c4e828b71d96622bb258938d69aab9cec53d5cae at offset 128427683 from .git/objects/pack/pack-edb47354be787909e05c15bd1d9eb8b4684d2e4d.pack
error: failed to read object 3cd5a6463cfd9306095bf6312a9b7ab09d4f2f5d at offset 128427777 from .git/objects/pack/pack-edb47354be787909e05c15bd1d9eb8b4684d2e4d.pack
fatal: object 3cd5a6463cfd9306095bf6312a9b7ab09d4f2f5d is corrupted
No, the repository is not corrupt. We f'd up our memory management
somewhere.
--
Shawn.
^ permalink raw reply
* Re: Public repro case! Re: [PATCH/RFC] Allow writing loose objects that are corrupted in a pack file
From: Boyd Stephen Smith Jr. @ 2009-01-08 2:52 UTC (permalink / raw)
To: James Pickens
Cc: Git ML, R. Tyler Ballance, Nicolas Pitre, Jan Krüger, kb,
Linus Torvalds
In-Reply-To: <885649360901071821t2ea481b5k83ab800f6aeb897@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 945 bytes --]
On Wednesday 2009 January 07 20:21:18 James Pickens wrote:
>On Wed, Jan 7, 2009, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>> Can you cnfirm that your "reproducible" case starts working with that
>> addition to your ~/.gitconfig? If so, the solution is pretty simple: we
>> should just lower the default pack windowsize.
>
>Umm... isn't that more of a workaround than a solution? I.e., if you lower
>the default pack windowsize, couldn't the corruption still happen under the
>right conditions?
IMHO:
I agree, somewhat. I'm fine with a "die()" message when there's not enough
memory, but either corruption or just a spurious, but scary "<SHA> is
corrupt" messages should be fixed.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Public repro case! Re: [PATCH/RFC] Allow writing loose objects that are corrupted in a pack file
From: Linus Torvalds @ 2009-01-08 2:52 UTC (permalink / raw)
To: R. Tyler Ballance; +Cc: Nicolas Pitre, Jan Krüger, Git ML, kb
In-Reply-To: <1231374514.8870.621.camel@starfruit>
On Wed, 7 Jan 2009, R. Tyler Ballance wrote:
>
> tyler@grapefruit:~/source/git/linux-2.6> git pull
> error: failed to read object be1b87c70af69acfadb8a27a7a76dfb61de92643 at offset 1850923
> from .git/objects/pack/pack-dbe154052997a05499eb6b4fd90b924da68e799a.pack
> fatal: object be1b87c70af69acfadb8a27a7a76dfb61de92643 is corrupted
Btw, this is an interesting error message, mostly because of what is
_not_ there.
In particular, it doesn't report any reason _why_ it failed to read the
object, which as far as I can tell can happen for only one reason:
unpack_compressed_entry() returns NULL, and that path is the only thing
that can do so without a message.
And it only does it if zlib fails.
Now, zlib can fail because the unpacking fails, but it can fail for other
cases too.
And the thing is, we don't check/report those kinds of failure cases very
well. Which really bit us here, because if we had checked the return value
of inflateInit(), we'd almost certainly would have gotten a nice big "you
ran out of memory" thing, and we wouldn't have been chasing this down as a
corruption issue.
We probably should wrap all the "inflateInit()" calls, and do something
like
static void xinflateInit(z_streamp strm)
{
const char *err;
switch (inflateInit(strm)) {
case Z_OK:
return;
case Z_MEM_ERROR:
err = "out of memory";
break;
case Z_VERSION_ERROR:
err = "wrong version";
break;
default:
err = "error";
}
die("inflateInit: %s (%s)", err,
strm->msg ? strm->msg : "no message");
}
or similar. That way we'd get good error reports when we run out of
memory, rather than consider it to be a corruption issue.
We could also try to make a few of these wrappers actually release some of
the memory (the way xmmap() does), but there are likely diminishing
returns. And the much more important issue is the proper error reporting:
if we had reported "out of memory", we'd not have spent so much time
chasing disk corruption etc.
Linus
^ permalink raw reply
* Re: Public repro case! Re: [PATCH/RFC] Allow writing loose objects that are corrupted in a pack file
From: Shawn O. Pearce @ 2009-01-08 3:01 UTC (permalink / raw)
To: Linus Torvalds
Cc: R. Tyler Ballance, Nicolas Pitre, Jan Krüger, Git ML, kb
In-Reply-To: <alpine.LFD.2.00.0901071836290.3283@localhost.localdomain>
Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Wed, 7 Jan 2009, R. Tyler Ballance wrote:
> >
> > tyler@grapefruit:~/source/git/linux-2.6> git pull
> > error: failed to read object be1b87c70af69acfadb8a27a7a76dfb61de92643 at offset 1850923
> > from .git/objects/pack/pack-dbe154052997a05499eb6b4fd90b924da68e799a.pack
> > fatal: object be1b87c70af69acfadb8a27a7a76dfb61de92643 is corrupted
>
> Btw, this is an interesting error message, mostly because of what is
> _not_ there.
>
> In particular, it doesn't report any reason _why_ it failed to read the
> object, which as far as I can tell can happen for only one reason:
> unpack_compressed_entry() returns NULL, and that path is the only thing
> that can do so without a message.
>
> And it only does it if zlib fails.
Ok, well, in this case I've been able to reproduce a zlib inflate
failure on the base object in a 2 deep delta chain. We got back:
#define Z_STREAM_ERROR (-2)
this causes the buffer to be freed and NULL to come back out of
unpack_compressed_entry(), and then everything is corrupt...
--
Shawn.
^ permalink raw reply
* Re: Error : git svn fetch
From: Eric Wong @ 2009-01-08 2:55 UTC (permalink / raw)
To: chongyc; +Cc: git
In-Reply-To: <E48CF49FF0FE4F96BE206B2689165AF9@VMware>
chongyc <chongyc27@gmail.com> wrote:
> Hi
>
> I found that 'git svn fetch' failed in cloning the hudson svn reposotory.
>
> I want to git-clone the svn repository
>
> svn repository URL : https://svn.dev.java.net/svn/hudson/
> username : guest
> password :
>
>
> So I run followings to git-clone
>
> [root@localhost hudson]# git --version
> git version 1.6.0.6
> [root@localhost hudson]# git svn init -T trunk -t tags -b branches
> https://svn.dev.java.net/svn/hudson/
> [root@localhost hudson]# git svn fetch
> Found possible branch point:
> https://svn.dev.java.net/svn/hudson/tags/hudson-1_230 =>
> https://svn.dev.java.net/svn/hudson/branches/buildnav-1636, 10490
> Initializing parent: buildnav-1636@10490
> Found possible branch point:
> https://svn.dev.java.net/svn/hudson/trunk/hudson/main =>
> https://svn.dev.java.net/svn/hudson/tags/hudson-1_230, 10450
> Initializing parent: buildnav-1636@10450
> Found branch parent: (buildnav-1636@10490) a1c395e5db063ca1ffbbe008e309c5
> 11d56219e0
> Following parent with do_switch
> remoting/pom.xml was not found in commit
> a1c395e5db063ca1ffbbe008e309c511d56219e0 (r10447)
> [root@localhost hudson]#
>
> What shall I do to git-clone it ?
>
> Please help me
Hi, sorry for the late reply, I've been very distracted.
Looking at the hudson repository, the layout is non-standard and very
complex, with subdirectories being branched and tagged all over. The
standard globbing that git-svn uses for most repositories does won't
work. You'll have to map things manually:
[svn-remote "svn"]
url = https://svn.dev.java.net/svn/hudson
fetch = trunk/hudson:refs/remotes/trunk
fetch = branches/tom:refs/remotes/tom
...
Alternately, you could just clone the root and have all the branches all
over the place in one tree (your eventually working copy will be huge).
git svn clone https://svn.dev.java.net/svn/hudson
Basically this is the equivalent of:
svn co https://svn.dev.java.net/svn/hudson
Except you'll have the full history.
--
Eric Wong
^ permalink raw reply
* Re: Public repro case! Re: [PATCH/RFC] Allow writing loose objects that are corrupted in a pack file
From: Linus Torvalds @ 2009-01-08 3:06 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: R. Tyler Ballance, Nicolas Pitre, Jan Krüger, Git ML, kb
In-Reply-To: <20090108030115.GF10790@spearce.org>
On Wed, 7 Jan 2009, Shawn O. Pearce wrote:
>
> Ok, well, in this case I've been able to reproduce a zlib inflate
> failure on the base object in a 2 deep delta chain. We got back:
>
> #define Z_STREAM_ERROR (-2)
>
> this causes the buffer to be freed and NULL to come back out of
> unpack_compressed_entry(), and then everything is corrupt...
I bet you actually got an earlier error already from the inflateInit.
The Z_STREAM_ERROR probably comes from inflate() itself - and could very
easily be due to a allocation error in inflateInit leaving the stream data
incomplete.
Let me try wrapping that dang thing and send a patch.
Linus
^ permalink raw reply
* Re: Public repro case! Re: [PATCH/RFC] Allow writing loose objects that are corrupted in a pack file
From: Shawn O. Pearce @ 2009-01-08 3:13 UTC (permalink / raw)
To: Linus Torvalds
Cc: R. Tyler Ballance, Nicolas Pitre, Jan Krüger, Git ML, kb
In-Reply-To: <alpine.LFD.2.00.0901071904380.3283@localhost.localdomain>
Linus Torvalds <torvalds@linux-foundation.org> wrote:
> The Z_STREAM_ERROR probably comes from inflate() itself - and could very
> easily be due to a allocation error in inflateInit leaving the stream data
> incomplete.
>
> Let me try wrapping that dang thing and send a patch.
Yup. I'm actually doing the same thing...
--
Shawn.
^ permalink raw reply
* [PATCH] Wrap inflateInit to retry allocation after releasing pack memory
From: Shawn O. Pearce @ 2009-01-08 3:16 UTC (permalink / raw)
To: Linus Torvalds, Junio C Hamano
Cc: R. Tyler Ballance, Nicolas Pitre, Jan Krüger, Git ML, kb
In-Reply-To: <20090108031314.GG10790@spearce.org>
If we are running low on virtual memory we should release pack
windows if zlib's inflateInit fails due to an out of memory error.
It may be that we are running under a low ulimit and are getting
tight on address space. Shedding unused windows may get us
sufficient working space to continue.
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
"Shawn O. Pearce" <spearce@spearce.org> wrote:
> Linus Torvalds <torvalds@linux-foundation.org> wrote:
> > The Z_STREAM_ERROR probably comes from inflate() itself - and could very
> > easily be due to a allocation error in inflateInit leaving the stream data
> > incomplete.
> >
> > Let me try wrapping that dang thing and send a patch.
>
> Yup. I'm actually doing the same thing...
builtin-apply.c | 2 +-
builtin-pack-objects.c | 2 +-
builtin-unpack-objects.c | 2 +-
cache.h | 1 +
http-push.c | 4 ++--
http-walker.c | 4 ++--
index-pack.c | 4 ++--
sha1_file.c | 8 ++++----
wrapper.c | 20 ++++++++++++++++++++
9 files changed, 34 insertions(+), 13 deletions(-)
diff --git a/builtin-apply.c b/builtin-apply.c
index af25ee9..cb2663e 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -1258,7 +1258,7 @@ static char *inflate_it(const void *data, unsigned long size,
stream.avail_in = size;
stream.next_out = out = xmalloc(inflated_size);
stream.avail_out = inflated_size;
- inflateInit(&stream);
+ xinflateInit(&stream);
st = inflate(&stream, Z_FINISH);
if ((st != Z_STREAM_END) || stream.total_out != inflated_size) {
free(out);
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index e851534..09576c6 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -195,7 +195,7 @@ static int check_pack_inflate(struct packed_git *p,
int st;
memset(&stream, 0, sizeof(stream));
- inflateInit(&stream);
+ xinflateInit(&stream);
do {
in = use_pack(p, w_curs, offset, &stream.avail_in);
stream.next_in = in;
diff --git a/builtin-unpack-objects.c b/builtin-unpack-objects.c
index 47ed610..cb9edac 100644
--- a/builtin-unpack-objects.c
+++ b/builtin-unpack-objects.c
@@ -99,7 +99,7 @@ static void *get_data(unsigned long size)
stream.avail_out = size;
stream.next_in = fill(1);
stream.avail_in = len;
- inflateInit(&stream);
+ xinflateInit(&stream);
for (;;) {
int ret = inflate(&stream, 0);
diff --git a/cache.h b/cache.h
index 231c06d..7d5c38d 100644
--- a/cache.h
+++ b/cache.h
@@ -17,6 +17,7 @@
#if defined(NO_DEFLATE_BOUND) || ZLIB_VERNUM < 0x1200
#define deflateBound(c,s) ((s) + (((s) + 7) >> 3) + (((s) + 63) >> 6) + 11)
#endif
+extern void xinflateInit(z_stream *stream);
#if defined(DT_UNKNOWN) && !defined(NO_D_TYPE_IN_DIRENT)
#define DTYPE(de) ((de)->d_type)
diff --git a/http-push.c b/http-push.c
index a4b7d08..906ca48 100644
--- a/http-push.c
+++ b/http-push.c
@@ -269,7 +269,7 @@ static void start_fetch_loose(struct transfer_request *request)
memset(&request->stream, 0, sizeof(request->stream));
- inflateInit(&request->stream);
+ xinflateInit(&request->stream);
git_SHA1_Init(&request->c);
@@ -310,7 +310,7 @@ static void start_fetch_loose(struct transfer_request *request)
file; also rewind to the beginning of the local file. */
if (prev_read == -1) {
memset(&request->stream, 0, sizeof(request->stream));
- inflateInit(&request->stream);
+ xinflateInit(&request->stream);
git_SHA1_Init(&request->c);
if (prev_posn>0) {
prev_posn = 0;
diff --git a/http-walker.c b/http-walker.c
index 7271c7d..6aa8486 100644
--- a/http-walker.c
+++ b/http-walker.c
@@ -142,7 +142,7 @@ static void start_object_request(struct walker *walker,
memset(&obj_req->stream, 0, sizeof(obj_req->stream));
- inflateInit(&obj_req->stream);
+ xinflateInit(&obj_req->stream);
git_SHA1_Init(&obj_req->c);
@@ -183,7 +183,7 @@ static void start_object_request(struct walker *walker,
file; also rewind to the beginning of the local file. */
if (prev_read == -1) {
memset(&obj_req->stream, 0, sizeof(obj_req->stream));
- inflateInit(&obj_req->stream);
+ xinflateInit(&obj_req->stream);
git_SHA1_Init(&obj_req->c);
if (prev_posn>0) {
prev_posn = 0;
diff --git a/index-pack.c b/index-pack.c
index 2931511..c6bfc12 100644
--- a/index-pack.c
+++ b/index-pack.c
@@ -275,7 +275,7 @@ static void *unpack_entry_data(unsigned long offset, unsigned long size)
stream.avail_out = size;
stream.next_in = fill(1);
stream.avail_in = input_len;
- inflateInit(&stream);
+ xinflateInit(&stream);
for (;;) {
int ret = inflate(&stream, 0);
@@ -382,7 +382,7 @@ static void *get_data_from_pack(struct object_entry *obj)
stream.avail_out = obj->size;
stream.next_in = src;
stream.avail_in = len;
- inflateInit(&stream);
+ xinflateInit(&stream);
while ((st = inflate(&stream, Z_FINISH)) == Z_OK);
inflateEnd(&stream);
if (st != Z_STREAM_END || stream.total_out != obj->size)
diff --git a/sha1_file.c b/sha1_file.c
index 52d1ead..9aabae2 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1196,7 +1196,7 @@ static int unpack_sha1_header(z_stream *stream, unsigned char *map, unsigned lon
stream->avail_out = bufsiz;
if (legacy_loose_object(map)) {
- inflateInit(stream);
+ xinflateInit(stream);
return inflate(stream, 0);
}
@@ -1217,7 +1217,7 @@ static int unpack_sha1_header(z_stream *stream, unsigned char *map, unsigned lon
/* Set up the stream for the rest.. */
stream->next_in = map;
stream->avail_in = mapsize;
- inflateInit(stream);
+ xinflateInit(stream);
/* And generate the fake traditional header */
stream->total_out = 1 + snprintf(buffer, bufsiz, "%s %lu",
@@ -1348,7 +1348,7 @@ unsigned long get_size_from_delta(struct packed_git *p,
stream.next_out = delta_head;
stream.avail_out = sizeof(delta_head);
- inflateInit(&stream);
+ xinflateInit(&stream);
do {
in = use_pack(p, w_curs, curpos, &stream.avail_in);
stream.next_in = in;
@@ -1585,7 +1585,7 @@ static void *unpack_compressed_entry(struct packed_git *p,
stream.next_out = buffer;
stream.avail_out = size;
- inflateInit(&stream);
+ xinflateInit(&stream);
do {
in = use_pack(p, w_curs, curpos, &stream.avail_in);
stream.next_in = in;
diff --git a/wrapper.c b/wrapper.c
index 93562f0..f255eef 100644
--- a/wrapper.c
+++ b/wrapper.c
@@ -196,3 +196,23 @@ int xmkstemp(char *template)
die("Unable to create temporary file: %s", strerror(errno));
return fd;
}
+
+void xinflateInit(z_stream *stream)
+{
+ switch (inflateInit(stream)) {
+ case Z_OK:
+ return;
+
+ case Z_MEM_ERROR:
+ release_pack_memory(128 * 1024, -1);
+ if (inflateInit(stream) == Z_OK)
+ return;
+ die("Out of memory? inflateInit failed");
+
+ case Z_VERSION_ERROR:
+ die("Wrong zlib version? inflateInit failed");
+
+ default:
+ die("Unknown inflateInit failure");
+ }
+}
--
1.6.1.141.gfe98e
^ permalink raw reply related
* Re: [PATCH (topgit) 1/2] Implement setup_pager just like in git
From: martin f krafft @ 2009-01-08 2:06 UTC (permalink / raw)
To: Kirill Smelkov, Thomas Rast, Bert Wesarg, Pierre Habouzit,
Petr Baudis
In-Reply-To: <20090107220027.GA4946@roro3>
[-- Attachment #1: Type: text/plain, Size: 1133 bytes --]
also sprach Kirill Smelkov <kirr@landau.phys.spbu.ru> [2009.01.08.1100 +1300]:
> > So I suppose you could use
> >
> > ${GIT_PAGER-${PAGER-less}}
> >
> > or similar.
>
> Good eyes, thanks!
>
> I'll rework it.
I am not 100% on this, but I think nested {}'s are a bashism.
> On Wed, Jan 07, 2009 at 03:24:02PM +0100, Bert Wesarg wrote:
> > On Wed, Jan 7, 2009 at 12:27, Kirill Smelkov <kirr@landau.phys.spbu.ru> wrote:
> > > Martin, thanks for your review.
> > > + # atexit(close(1); wait pager)
> > > + trap "exec >&-; rm "$_pager_fifo"; rmdir "$_pager_fifo_dir"; wait" EXIT
> > I think you need to escape the double quotes.
>
> Good eyes -- corrected and thanks!
You could also just use single quotes inside the double quotes.
--
martin | http://madduck.net/ | http://two.sentenc.es/
"he gave me his card
he said, 'call me if they die'
i shook his hand and said goodbye
ran out to the street
when a bowling ball came down the road
and knocked me off my feet"
-- bob dylan
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Wrap inflateInit to retry allocation after releasing pack memory
From: Linus Torvalds @ 2009-01-08 3:54 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Junio C Hamano, R. Tyler Ballance, Nicolas Pitre, Jan Krüger,
Git ML, kb
In-Reply-To: <20090108031655.GH10790@spearce.org>
On Wed, 7 Jan 2009, Shawn O. Pearce wrote:
>
> If we are running low on virtual memory we should release pack
> windows if zlib's inflateInit fails due to an out of memory error.
> It may be that we are running under a low ulimit and are getting
> tight on address space. Shedding unused windows may get us
> sufficient working space to continue.
Let's do this (more complete) wrapping instead, ok?
This one _just_ wraps things, btw - it doesn't do the "retry on low memory
error" part, at least not yet. I think that's an independent issue from
the reporting.
Hmm?
Tyler - does this make the corruption errors go away, and be replaced by
hard failures with "out of memory" reporting?
This patch is potentially pretty noisy, on purpose. I didn't remove the
reporting from places that already do so - some of them have stricter
errors than this.
For example: Z_BUF_ERROR can be valid depending on circumstance, so the
wrapper doesn't complain about it, but the caller may not accept it.
Linus
---
builtin-apply.c | 5 ++-
builtin-pack-objects.c | 6 ++--
builtin-unpack-objects.c | 6 ++--
cache.h | 4 +++
http-push.c | 8 +++---
http-walker.c | 8 +++---
index-pack.c | 12 ++++----
sha1_file.c | 24 +++++++++---------
wrapper.c | 60 ++++++++++++++++++++++++++++++++++++++++++++++
9 files changed, 99 insertions(+), 34 deletions(-)
diff --git a/builtin-apply.c b/builtin-apply.c
index 07244b0..ed02b6d 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -1253,8 +1253,9 @@ static char *inflate_it(const void *data, unsigned long size,
stream.avail_in = size;
stream.next_out = out = xmalloc(inflated_size);
stream.avail_out = inflated_size;
- inflateInit(&stream);
- st = inflate(&stream, Z_FINISH);
+ git_inflate_init(&stream);
+ st = git_inflate(&stream, Z_FINISH);
+ git_inflate_end(&stream);
if ((st != Z_STREAM_END) || stream.total_out != inflated_size) {
free(out);
return NULL;
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index e851534..cb51916 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -195,16 +195,16 @@ static int check_pack_inflate(struct packed_git *p,
int st;
memset(&stream, 0, sizeof(stream));
- inflateInit(&stream);
+ git_inflate_init(&stream);
do {
in = use_pack(p, w_curs, offset, &stream.avail_in);
stream.next_in = in;
stream.next_out = fakebuf;
stream.avail_out = sizeof(fakebuf);
- st = inflate(&stream, Z_FINISH);
+ st = git_inflate(&stream, Z_FINISH);
offset += stream.next_in - in;
} while (st == Z_OK || st == Z_BUF_ERROR);
- inflateEnd(&stream);
+ git_inflate_end(&stream);
return (st == Z_STREAM_END &&
stream.total_out == expect &&
stream.total_in == len) ? 0 : -1;
diff --git a/builtin-unpack-objects.c b/builtin-unpack-objects.c
index 47ed610..9a77323 100644
--- a/builtin-unpack-objects.c
+++ b/builtin-unpack-objects.c
@@ -99,10 +99,10 @@ static void *get_data(unsigned long size)
stream.avail_out = size;
stream.next_in = fill(1);
stream.avail_in = len;
- inflateInit(&stream);
+ git_inflate_init(&stream);
for (;;) {
- int ret = inflate(&stream, 0);
+ int ret = git_inflate(&stream, 0);
use(len - stream.avail_in);
if (stream.total_out == size && ret == Z_STREAM_END)
break;
@@ -118,7 +118,7 @@ static void *get_data(unsigned long size)
stream.next_in = fill(1);
stream.avail_in = len;
}
- inflateEnd(&stream);
+ git_inflate_end(&stream);
return buf;
}
diff --git a/cache.h b/cache.h
index 231c06d..49e54fb 100644
--- a/cache.h
+++ b/cache.h
@@ -18,6 +18,10 @@
#define deflateBound(c,s) ((s) + (((s) + 7) >> 3) + (((s) + 63) >> 6) + 11)
#endif
+void git_inflate_init(z_streamp strm);
+void git_inflate_end(z_streamp strm);
+int git_inflate(z_streamp strm, int flush);
+
#if defined(DT_UNKNOWN) && !defined(NO_D_TYPE_IN_DIRENT)
#define DTYPE(de) ((de)->d_type)
#else
diff --git a/http-push.c b/http-push.c
index 7c64609..809002b 100644
--- a/http-push.c
+++ b/http-push.c
@@ -208,7 +208,7 @@ static size_t fwrite_sha1_file(void *ptr, size_t eltsize, size_t nmemb,
do {
request->stream.next_out = expn;
request->stream.avail_out = sizeof(expn);
- request->zret = inflate(&request->stream, Z_SYNC_FLUSH);
+ request->zret = git_inflate(&request->stream, Z_SYNC_FLUSH);
git_SHA1_Update(&request->c, expn,
sizeof(expn) - request->stream.avail_out);
} while (request->stream.avail_in && request->zret == Z_OK);
@@ -268,7 +268,7 @@ static void start_fetch_loose(struct transfer_request *request)
memset(&request->stream, 0, sizeof(request->stream));
- inflateInit(&request->stream);
+ git_inflate_init(&request->stream);
git_SHA1_Init(&request->c);
@@ -309,7 +309,7 @@ static void start_fetch_loose(struct transfer_request *request)
file; also rewind to the beginning of the local file. */
if (prev_read == -1) {
memset(&request->stream, 0, sizeof(request->stream));
- inflateInit(&request->stream);
+ git_inflate_init(&request->stream);
git_SHA1_Init(&request->c);
if (prev_posn>0) {
prev_posn = 0;
@@ -741,7 +741,7 @@ static void finish_request(struct transfer_request *request)
if (request->http_code == 416)
fprintf(stderr, "Warning: requested range invalid; we may already have all the data.\n");
- inflateEnd(&request->stream);
+ git_inflate_end(&request->stream);
git_SHA1_Final(request->real_sha1, &request->c);
if (request->zret != Z_STREAM_END) {
unlink(request->tmpfile);
diff --git a/http-walker.c b/http-walker.c
index 7271c7d..0dbad3c 100644
--- a/http-walker.c
+++ b/http-walker.c
@@ -82,7 +82,7 @@ static size_t fwrite_sha1_file(void *ptr, size_t eltsize, size_t nmemb,
do {
obj_req->stream.next_out = expn;
obj_req->stream.avail_out = sizeof(expn);
- obj_req->zret = inflate(&obj_req->stream, Z_SYNC_FLUSH);
+ obj_req->zret = git_inflate(&obj_req->stream, Z_SYNC_FLUSH);
git_SHA1_Update(&obj_req->c, expn,
sizeof(expn) - obj_req->stream.avail_out);
} while (obj_req->stream.avail_in && obj_req->zret == Z_OK);
@@ -142,7 +142,7 @@ static void start_object_request(struct walker *walker,
memset(&obj_req->stream, 0, sizeof(obj_req->stream));
- inflateInit(&obj_req->stream);
+ git_inflate_init(&obj_req->stream);
git_SHA1_Init(&obj_req->c);
@@ -183,7 +183,7 @@ static void start_object_request(struct walker *walker,
file; also rewind to the beginning of the local file. */
if (prev_read == -1) {
memset(&obj_req->stream, 0, sizeof(obj_req->stream));
- inflateInit(&obj_req->stream);
+ git_inflate_init(&obj_req->stream);
git_SHA1_Init(&obj_req->c);
if (prev_posn>0) {
prev_posn = 0;
@@ -243,7 +243,7 @@ static void finish_object_request(struct object_request *obj_req)
return;
}
- inflateEnd(&obj_req->stream);
+ git_inflate_end(&obj_req->stream);
git_SHA1_Final(obj_req->real_sha1, &obj_req->c);
if (obj_req->zret != Z_STREAM_END) {
unlink(obj_req->tmpfile);
diff --git a/index-pack.c b/index-pack.c
index 60ed41a..c0a3d97 100644
--- a/index-pack.c
+++ b/index-pack.c
@@ -275,10 +275,10 @@ static void *unpack_entry_data(unsigned long offset, unsigned long size)
stream.avail_out = size;
stream.next_in = fill(1);
stream.avail_in = input_len;
- inflateInit(&stream);
+ git_inflate_init(&stream);
for (;;) {
- int ret = inflate(&stream, 0);
+ int ret = git_inflate(&stream, 0);
use(input_len - stream.avail_in);
if (stream.total_out == size && ret == Z_STREAM_END)
break;
@@ -287,7 +287,7 @@ static void *unpack_entry_data(unsigned long offset, unsigned long size)
stream.next_in = fill(1);
stream.avail_in = input_len;
}
- inflateEnd(&stream);
+ git_inflate_end(&stream);
return buf;
}
@@ -382,9 +382,9 @@ static void *get_data_from_pack(struct object_entry *obj)
stream.avail_out = obj->size;
stream.next_in = src;
stream.avail_in = len;
- inflateInit(&stream);
- while ((st = inflate(&stream, Z_FINISH)) == Z_OK);
- inflateEnd(&stream);
+ git_inflate_init(&stream);
+ while ((st = git_inflate(&stream, Z_FINISH)) == Z_OK);
+ git_inflate_end(&stream);
if (st != Z_STREAM_END || stream.total_out != obj->size)
die("serious inflate inconsistency");
free(src);
diff --git a/sha1_file.c b/sha1_file.c
index 52d1ead..8600b04 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1196,8 +1196,8 @@ static int unpack_sha1_header(z_stream *stream, unsigned char *map, unsigned lon
stream->avail_out = bufsiz;
if (legacy_loose_object(map)) {
- inflateInit(stream);
- return inflate(stream, 0);
+ git_inflate_init(stream);
+ return git_inflate(stream, 0);
}
@@ -1217,7 +1217,7 @@ static int unpack_sha1_header(z_stream *stream, unsigned char *map, unsigned lon
/* Set up the stream for the rest.. */
stream->next_in = map;
stream->avail_in = mapsize;
- inflateInit(stream);
+ git_inflate_init(stream);
/* And generate the fake traditional header */
stream->total_out = 1 + snprintf(buffer, bufsiz, "%s %lu",
@@ -1254,11 +1254,11 @@ static void *unpack_sha1_rest(z_stream *stream, void *buffer, unsigned long size
stream->next_out = buf + bytes;
stream->avail_out = size - bytes;
while (status == Z_OK)
- status = inflate(stream, Z_FINISH);
+ status = git_inflate(stream, Z_FINISH);
}
buf[size] = 0;
if (status == Z_STREAM_END && !stream->avail_in) {
- inflateEnd(stream);
+ git_inflate_end(stream);
return buf;
}
@@ -1348,15 +1348,15 @@ unsigned long get_size_from_delta(struct packed_git *p,
stream.next_out = delta_head;
stream.avail_out = sizeof(delta_head);
- inflateInit(&stream);
+ git_inflate_init(&stream);
do {
in = use_pack(p, w_curs, curpos, &stream.avail_in);
stream.next_in = in;
- st = inflate(&stream, Z_FINISH);
+ st = git_inflate(&stream, Z_FINISH);
curpos += stream.next_in - in;
} while ((st == Z_OK || st == Z_BUF_ERROR) &&
stream.total_out < sizeof(delta_head));
- inflateEnd(&stream);
+ git_inflate_end(&stream);
if ((st != Z_STREAM_END) && stream.total_out != sizeof(delta_head)) {
error("delta data unpack-initial failed");
return 0;
@@ -1585,14 +1585,14 @@ static void *unpack_compressed_entry(struct packed_git *p,
stream.next_out = buffer;
stream.avail_out = size;
- inflateInit(&stream);
+ git_inflate_init(&stream);
do {
in = use_pack(p, w_curs, curpos, &stream.avail_in);
stream.next_in = in;
- st = inflate(&stream, Z_FINISH);
+ st = git_inflate(&stream, Z_FINISH);
curpos += stream.next_in - in;
} while (st == Z_OK || st == Z_BUF_ERROR);
- inflateEnd(&stream);
+ git_inflate_end(&stream);
if ((st != Z_STREAM_END) || stream.total_out != size) {
free(buffer);
return NULL;
@@ -2017,7 +2017,7 @@ static int sha1_loose_object_info(const unsigned char *sha1, unsigned long *size
status = error("unable to parse %s header", sha1_to_hex(sha1));
else if (sizep)
*sizep = size;
- inflateEnd(&stream);
+ git_inflate_end(&stream);
munmap(map, mapsize);
return status;
}
diff --git a/wrapper.c b/wrapper.c
index 93562f0..29afa96 100644
--- a/wrapper.c
+++ b/wrapper.c
@@ -196,3 +196,63 @@ int xmkstemp(char *template)
die("Unable to create temporary file: %s", strerror(errno));
return fd;
}
+
+/*
+ * zlib wrappers to make sure we don't silently miss errors
+ * at init time.
+ */
+void git_inflate_init(z_streamp strm)
+{
+ const char *err;
+
+ switch (inflateInit(strm)) {
+ case Z_OK:
+ return;
+
+ case Z_MEM_ERROR:
+ err = "out of memory";
+ break;
+ case Z_VERSION_ERROR:
+ err = "wrong version";
+ break;
+ default:
+ err = "error";
+ }
+ die("inflateInit: %s (%s)", err, strm->msg ? strm->msg : "no message");
+}
+
+void git_inflate_end(z_streamp strm)
+{
+ if (inflateEnd(strm) != Z_OK)
+ error("inflateEnd: %s", strm->msg ? strm->msg : "failed");
+}
+
+int git_inflate(z_streamp strm, int flush)
+{
+ int ret = inflate(strm, flush);
+ const char *err;
+
+ switch (ret) {
+ /* Out of memory is fatal. */
+ case Z_MEM_ERROR:
+ die("inflate: out of memory");
+
+ /* Data corruption errors: we may want to recover from them (fsck) */
+ case Z_NEED_DICT:
+ err = "needs dictionary"; break;
+ case Z_DATA_ERROR:
+ err = "data stream error"; break;
+ case Z_STREAM_ERROR:
+ err = "stream consistency error"; break;
+ default:
+ err = "unknown error"; break;
+
+ /* Z_BUF_ERROR: normal, needs a buffer output buffer */
+ case Z_BUF_ERROR:
+ case Z_OK:
+ case Z_STREAM_END:
+ return ret;
+ }
+ error("inflate: %s (%s)", err, strm->msg ? strm->msg : "no message");
+ return ret;
+}
^ permalink raw reply related
* Re: collapsing commits with rebase
From: Sitaram Chamarty @ 2009-01-08 4:09 UTC (permalink / raw)
To: git
In-Reply-To: <200901072011.37299.bss@iguanasuicide.net>
On 2009-01-08, Boyd Stephen Smith Jr. <bss@iguanasuicide.net> wrote:
>> A---B---C---D---E---F
> Assuming you also have a ref (e.g. Foo) that points to F:
> git checkout sha(B)
> git merge -s sha(D)
I think you now need to do a commit (assuming you meant
"--squash"). Squash will not commit, and your rebase below
(if it runs at all -- I suspect it will refuse to run) will
hard reset to B, the current HEAD. IOW
> After the merge:
> A -> B -> C -> D -> E -> F [Foo]
> |
> +--> [HEAD]
is not true. You have C+D in the index, not in the tree.
> git rebase --onto $(cat .git/HEAD) sha(E) Foo
Also I think you have an off-by-one error here; you need
sha(D) in that rebase command, not sha(E).
As your rebase command stands, you will lose commit E
completely; neither the merge nor the rebase will pick it
up.
[Haven't tested, but I *think* I understand rebase well
enough now to say so...]
^ permalink raw reply
* Re: collapsing commits with rebase
From: Boyd Stephen Smith Jr. @ 2009-01-08 4:23 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: git
In-Reply-To: <slrngmav3b.20e.sitaramc@sitaramc.homelinux.net>
[-- Attachment #1: Type: text/plain, Size: 585 bytes --]
On Wednesday 2009 January 07 22:09:15 Sitaram Chamarty wrote:
>[Haven't tested, but I *think* I understand rebase well
>enough now to say so...]
Probably understand it better than me. I just haven't needed to use it for
this that much. This also might not be much better than setting GIT_PAGER to
a script, but it seems less fragile to me.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Wrap inflateInit to retry allocation after releasing pack memory
From: Junio C Hamano @ 2009-01-08 5:23 UTC (permalink / raw)
To: Linus Torvalds
Cc: Shawn O. Pearce, R. Tyler Ballance, Nicolas Pitre,
Jan Krüger, Git ML, kb
In-Reply-To: <alpine.LFD.2.00.0901071941210.3283@localhost.localdomain>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> +int git_inflate(z_streamp strm, int flush)
> +{
> +...
> + /* Z_BUF_ERROR: normal, needs a buffer output buffer */
> + case Z_BUF_ERROR:
Thanks, but "needs a buffer output buffer" made me scratch my head
somewhat.
... Z_BUF_ERROR if no progress is possible or if there was not enough
room in the output buffer when Z_FINISH is used. Note that Z_BUF_ERROR
is not fatal, and inflate() can be called again with more input and more
output space to continue decompressing.
^ permalink raw reply
* Re: Public repro case! Re: [PATCH/RFC] Allow writing loose objects that are corrupted in a pack file
From: Junio C Hamano @ 2009-01-08 5:40 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: James Pickens, Git ML, R. Tyler Ballance, Nicolas Pitre,
Jan Krüger, kb, Linus Torvalds
In-Reply-To: <20090108024325.GE10790@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> For those following along at home, Linus' 2.6 tree:
>
> $ ulimit -v `echo '150 * 1024'|bc -l`
> $ git co 56d18e9932ebf4e8eca42d2ce509450e6c9c1666
Hmm, without any "wrap zlib to die on error" patch, this step already
fails with:
$ git checkout 56d18e9932ebf4e8eca42d2ce509450e6c9c1666
fatal: Out of memory? mmap failed: Cannot allocate memory
I guess that is because our test repositories are packed differently.
I'll retry after repacking..
^ permalink raw reply
* Re: Public repro case! Re: [PATCH/RFC] Allow writing loose objects that are corrupted in a pack file
From: Shawn O. Pearce @ 2009-01-08 6:04 UTC (permalink / raw)
To: Junio C Hamano
Cc: James Pickens, Git ML, R. Tyler Ballance, Nicolas Pitre,
Jan Krüger, kb, Linus Torvalds
In-Reply-To: <7v4p0a8if2.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
> > For those following along at home, Linus' 2.6 tree:
> >
> > $ ulimit -v `echo '150 * 1024'|bc -l`
> > $ git co 56d18e9932ebf4e8eca42d2ce509450e6c9c1666
>
> Hmm, without any "wrap zlib to die on error" patch, this step already
> fails with:
>
> $ git checkout 56d18e9932ebf4e8eca42d2ce509450e6c9c1666
> fatal: Out of memory? mmap failed: Cannot allocate memory
>
> I guess that is because our test repositories are packed differently.
> I'll retry after repacking..
Yup. I actually did something more like this to get the test
repository:
git clone git://android.git.kernel.org/kernel/common.git
git fetch git://kernel.org/pub/.../torvalds/linux-2.6.git master
The android kernel repository I had handy on my local system was
quite a bit away from Linus' so I wound up with two different but
sizable packs. I thought android was closer to upstream, but its
apparently not. I started from there because it was local and I
thought it would be a quick way to get a test environment, but
sadly it didn't even have the base 56d18e we were talking about.
--
Shawn.
^ permalink raw reply
* Can I prevent someone clone my git repository?
From: Emily Ren @ 2009-01-08 7:03 UTC (permalink / raw)
To: git
All,
I want some person can clone my git repository, others can't clone my
git repository. Is it realizable ? How to do it?
Thanks,
Emily
^ permalink raw reply
* Re: why still no empty directory support in git
From: Asheesh Laroia @ 2009-01-08 7:12 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <20090101200651.GB6536@coredump.intra.peff.net>
On Thu, 1 Jan 2009, Jeff King wrote:
> On Tue, Dec 30, 2008 at 03:58:46AM -0500, Asheesh Laroia wrote:
>
>> So, let's say I take your suggestion.
>>
>> $ touch ~/Maildir/new/.exists
>> $ git add ~/Maildir/new/.exists && git commit -m "La di da"
>>
>> Now a spec-compliant Maildir user agent will attempt to deliver this new
>> "email message" of zero bytes into the mail spool and assign it a message
>> UID. Doing so will remove it from Maildir/new.
>
> No. The maildir spec says:
>
> A unique name can be anything that doesn't contain a colon (or slash)
> and doesn't start with a dot.
> -- http://cr.yp.to/proto/maildir.html
>
> where a "unique name" is the filename used for a message. In practice,
> every maildir implementation I have seen ignores files starting with a
> dot. Do you have one that doesn't?
My apologies. This works just fine, and I'm a dolt.
Happy new year!
(I'm still academically interested in how to avoid the rmdir(), but as I
said before, that's a topic for someone else to pick up now.)
-- Asheesh.
--
English literature's performing flea.
-- Sean O'Casey on P. G. Wodehouse
^ permalink raw reply
* Re: Problems with large compressed binaries when converting from svn
From: Øyvind Harboe @ 2009-01-08 7:33 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0901071555t62c1da3ar2b2cfd14222b502e@mail.gmail.com>
>> Does git have some capability to store diffs of compressed files efficiently?
>
> No, but you can unpack the tarballs and include the toolchains as submodules
> (aka subprojects) in the projects which need them.
>
> See man page to git submodule, the user-manual.txt on "submodule" and
> gitmodules.txt (submodule configuration formats and conventions).
I'll need the submodule stuff for sure, but in this particular case I was
trying to see if there was a way to keep the svn abuse patterns from
svn under git without a lot of retraining.
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 XScale Cortex
JTAG debugger and flash programmer
^ permalink raw reply
* Re: Google Summer of Code 2009
From: Sam Vilain @ 2009-01-08 7:55 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Shawn O. Pearce, Alex Riesen, git
In-Reply-To: <alpine.DEB.1.00.0901080024170.7496@intel-tinevez-2-302>
On Thu, 2009-01-08 at 00:30 +0100, Johannes Schindelin wrote:
> However, from what Sam said at the GitTogether, it might be a much better
> idea to look at the existing code as a fact-finding experiment, scrap it
> (excluding the experience), and start modifying git-daemon.
>
> AFAICT Sam has a pretty clear idea how to go about it, and staying with C
> should make it much easier for other people to comment.
>
> Note that there has been a flurry of emails on the gittorrent list a few
> weeks back, where somebody challenged the approach Sam wants to take,
> saying that BitTorrent has some very nice features that are absolutely
> necessary, such as its pretty awkward custom encoding.
>
> But AFAICT Sam did a pretty good job at dispelling all of the objections.
Yes, this is accurate as I know it. I've renamed and reworded the
heading under the SoC2009Ideas page to point to the most current design.
It's all in a "just add JFDI" point right now I think ;-).
Sam.
^ 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