* Re: git hang with corrupted .pack
From: Shawn O. Pearce @ 2009-10-14 14:23 UTC (permalink / raw)
To: Andy Isaacson, Junio C Hamano; +Cc: git, Nicolas Pitre
In-Reply-To: <20091014042249.GA5250@hexapodia.org>
Andy Isaacson <adi@hexapodia.org> wrote:
> We're looping in unpack_compressed_entry, adding a fprintf immediately
> after the call to git_inflate() shows:
Thanks, that was really quite helpful. Junio/Nico, I think we can
just apply this patch to maint and include it in the next release:
--8<--
[PATCH] sha1_file: Fix infinite loop when pack is corrupted
Some types of corruption to a pack may confuse the deflate stream
which stores an object. In Andy's reported case a 36 byte region
of the pack was overwritten, leading to what appeared to be a valid
deflate stream that was trying to produce a result larger than our
allocated output buffer could accept.
Z_BUF_ERROR is returned from inflate() if either the input buffer
needs more input bytes, or the output buffer has run out of space.
Previously we only considered the former case, as it meant we needed
to move the stream's input buffer to the next window in the pack.
We now abort the loop if inflate() returns Z_BUF_ERROR without
consuming the entire input buffer it was given, or has filled
the entire output buffer but has not yet returned Z_STREAM_END.
Either state is a clear indicator that this loop is not working
as expected, and should not continue.
This problem cannot occur with loose objects as we open the entire
loose object as a single buffer and treat Z_BUF_ERROR as an error.
Reported-by: Andy Isaacson <adi@hexapodia.org>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
sha1_file.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index 4ea0b18..4cc8939 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1357,6 +1357,8 @@ unsigned long get_size_from_delta(struct packed_git *p,
in = use_pack(p, w_curs, curpos, &stream.avail_in);
stream.next_in = in;
st = git_inflate(&stream, Z_FINISH);
+ if (st == Z_BUF_ERROR && (stream.avail_in || !stream.avail_out))
+ break;
curpos += stream.next_in - in;
} while ((st == Z_OK || st == Z_BUF_ERROR) &&
stream.total_out < sizeof(delta_head));
@@ -1594,6 +1596,8 @@ static void *unpack_compressed_entry(struct packed_git *p,
in = use_pack(p, w_curs, curpos, &stream.avail_in);
stream.next_in = in;
st = git_inflate(&stream, Z_FINISH);
+ if (st == Z_BUF_ERROR && (stream.avail_in || !stream.avail_out))
+ break;
curpos += stream.next_in - in;
} while (st == Z_OK || st == Z_BUF_ERROR);
git_inflate_end(&stream);
--
1.6.5.52.g0ff2e
--
Shawn.
^ permalink raw reply related
* Re: [PATCH 0/2] user-manual: reorganize the configuration steps
From: Felipe Contreras @ 2009-10-14 14:14 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: git, Junio C Hamano, Jonathan Nieder
In-Reply-To: <20091014024940.GB9700@fieldses.org>
On Wed, Oct 14, 2009 at 5:49 AM, J. Bruce Fields <bfields@citi.umich.edu> wrote:
> On Sun, Oct 11, 2009 at 11:43:04PM +0300, Felipe Contreras wrote:
>> This basically introduces the "getting started" section so users get familiar
>> with the configuration from the get-go, and also, most people prefer to teach
>> 'git config --global' to setup the user name and email. Here are a few
>> examples:
>
> I'm not personally a big fan of starting out with a "how to use
> git-config" section, because it's not that difficult or important:
> questions we get on this list suggest confusion about a lot of things,
> but git configuration is rarely one of them (that I've noticed).
Which means either people understand the configuration perfectly, look
somewhere else for that, or they don't do it at all.
Judging by the fact that most guides cover it at the beginning, and
people still send commits without proper user{.name,.email}, I would
say it is needed.
> I'd rather just point people to the git-config man page the first time
> we mention any git configuration. (And improve the man page if
> necessary to ensure it's up to the job.)
>
> If we have to do this, just keep it short....
That's what I tried to do.
--
Felipe Contreras
^ permalink raw reply
* [msysgit? bug] CRLF in info/grafts causes parse error
From: Yann Dirson @ 2009-10-14 14:07 UTC (permalink / raw)
To: git
When creating an info/grafts under windows, one typically gets a CRLF file.
Then:
* gitk loudly complains about "bad graft data"
* "git log > /dev/null" does not report any problem
* "git log > foo" does report the problem on sdterr, but exit code is still 0
Recreating the graft as a LF file (eg with "echo" or "printf") causes the
graft to be properly interpreted.
^ permalink raw reply
* Re: Bad URL passed to RA lay
From: m.skoric @ 2009-10-14 14:02 UTC (permalink / raw)
To: Eric Wong; +Cc: git
> -----Ursprüngliche Nachricht-----
> Von: "Eric Wong" <normalperson@yhbt.net>
> Gesendet: 14.10.09 09:07:31
> An: m.skoric@web.de
> CC: git@vger.kernel.org
> Betreff: Re: Bad URL passed to RA lay
> m.skoric@web.de wrote:
> > Hi List,
> >
> > i have a problem with git-svn clone / fetch. I get following error
> > while doing one of previous command -> "Bad URL passed to RA lay" This
> > happens because a branch doesn't exists in svn anymore and git wants
> > to retrieve data from it. Here is the complete error message
> >
> > Initializing parent: Abo-Uebernahme (Bug #994)@341
> > Found possible branch point: "quoted"..trunk => "quoted"...Abo-Uebernahme (Bug #994), 203
> > Found branch parent: (Abo-Uebernahme (Bug #994)@341) bb831869748c98bf97d105c5894ae65331c95c08
> > Bad URL passed to RA layer: Malformed URL for repository at /usr/bin/git-svn line 4311
> >
> > git version 1.6.3.3
> >
> > Aynone else has this Problem?
>
> Hi,
>
> Unlikely, not many people use URIs as weird as yours :)
Ye, i know ;) This is really old stuff and we already changed them to more sane ones ;)
> The existing test case (t9118) we have was also inspired by you,
> on the same branch, even.
>
> > Can anyone help me?
>
> What exactly is the "quoted" you refer to? That's not an actual branch
> name, is it?
ah brainfart.
This info is essential!
quoted = branches/dirk/Abo-Uebernahme... => https...branches/Abo-Uebernahme...
> Can you try it with v1.6.5? You might need to edit your $GIT_CONFIG,
> but commit 5268f9edc3c86b07a64fcc2679e5ffe39be28d97 was the last
> fix for URI-escaping problems:
This is not a URI Escaping Problem. As i allready mentioned: I think its a svn
problem and git can't handle that.
svn History:
r203 svn copy /trunk/ /branches/dirk/Abo..
r204 svn mv /branches/dirk/Abo.. /branches/Abo..
r341 svn mv /branches/Abo.. /branches/0944-Abo..
r203 branch was created from trunk.
r204 branch was moved from /branches/dirk/ to /branches
r341 branch was renamed to 0944-Abo
This is what git does.
>Initializing parent: refs/remote/Abo-Uebernahme (Bug #994)@341
>Found possible branch point: branches/Abo => branches/dirk/Abo-Uebernahme (Bug #994), 203
>Found branch parent: (Abo-Uebernahme (Bug #994)@341) bb831869748c98bf97d105c5894ae65331c95c08
>Bad URL passed to RA layer: Malformed URL for repository at /usr/bin/git-svn line 4311
I think the problem is that git doesn't like this kinda action.
branch -> do something with branch -> rename branch.
After some debugging i found something in git-svn
sub find_parent_branch
{
...
} elseif ($self->ra->trees_match($new_url, $r0, $self->full_url, $rev))
....
}
the trees_match sub doesn't do any error handling. if $self->full_url doesn't
exits anymore this will fail, right?
I don't know if the followong piece of code in find_parent_branch works like
you expect it!?
>unless (defined $paths) {
> my $err_handler = $SVN::Error::handler;
> $SVN::Error::handler = \&Git::SVN::Ra::skip_unknown_revs;
> $self->ra->get_log([$self->{path}], $rev, $rev, 0, 1, 1,
> sub { $paths = $_[0] });
> $SVN::Error::handler = $err_handler;
>}
>return undef unless defined $paths;
Maybe its just a problem with renaming branches or something!?
My Perl knowledge is really limited, so its up to you my friend ;)
Majk
______________________________________________________
GRATIS für alle WEB.DE-Nutzer: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://movieflat.web.de
^ permalink raw reply
* Re: [msysgit? bug] crlf double-conversion on win32
From: Johannes Schindelin @ 2009-10-14 14:03 UTC (permalink / raw)
To: Eric Raible; +Cc: git
In-Reply-To: <loom.20091014T001602-378@post.gmane.org>
Hi,
On Tue, 13 Oct 2009, Eric Raible wrote:
> Yann Dirson <y.dirson <at> e-sidor.com> writes:
>
> >
> > With a msysgit 1.6.4 package, I got stuck after someone copied a CRLF file
> > to a Linux box and committed it.
> >
> > In that situation, the win32 client in autocrlf mode keeps telling that
> > the files are locally modified, even after eg "git reset --hard". Without
> > touching the crlf setting (which I believe should not ever be necessary),
> > this can be corrected by committing the faulty files after dos2unix'ing
> > them, and using "git fetch && git reset --hard origin/master" ("git pull
> > --rebase" refuses to do the job since it believes there are local
> > changes).
>
> See http://thread.gmane.org/gmane.comp.version-control.git/122823/focus=122862
>
> In which Junio suggests:
> $ rm .git/index
> $ git reset --hard
>
> in order to "restore sanity to your work tree"
Of course this is insane as a user interface. It is not even plumbing.
So I started some time ago to code a "git checkout --fix-crlf", but I
am not really happy with the user interface. I think that Git should
realize itself that something went wrong with the line endings. If I say
"git reset --hard", it is just a bug in Git when it insists afterwards
that the files are modified.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so
From: Jay Soffian @ 2009-10-14 12:49 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Jeff King, Thomas Rast, Euguess,
Mikael Magnusson, Matthieu Moy, git, Johannes Sixt
In-Reply-To: <7vfx9modqf.fsf@alter.siamese.dyndns.org>
On Tue, Oct 13, 2009 at 11:28 PM, Junio C Hamano <gitster@pobox.com> wrote:
> When you do not have local "frotz" branch, and do have cloned/fetched from
> the origin that has "frotz" branch, I am actually Ok with this
>
> $ git checkout frotz [--]
>
> to do an equivalent of:
>
> $ git checkout -t -b frotz origin/frotz
>
> I do not have problem with this _particular_ DWIMmery. It will not break
> people's expectations, other than "asking to check out non-existing ref
> should fail". That expectation might be logical, but I do not think it is
> useful.
>
> Another reason I won't have problem with this one is that perhaps after
> creating a few more commits, the next day when the user does the same
>
> $ git checkout frotz
>
> what will be shown is the _local_ frotz branch. Nowhere in this sequence
> there is any room to mistake that you somehow checked out a branch owned
> by somebody else (namely, origin). You started by auto-creating your
> local branch, worked on it, and checked it out again the next day. In
> other words, this is really about a shorthand to create a new local branch
> called "frotz" when the commit that the branch should start from is
> clearly unambiguous.
Okay, this is good, and I can work up a patch if no one beats me to the punch.
> I have trouble with yours, on the other hand, which is to make
>
> $ git checkout origin/frotz
> $ git checkout v1.5.5
>
> into
>
> $ git checkout -b frotz-47 origin/frotz
> $ git checkout -b v1.5.5-47 v1.5.5
I suggested no such thing, at least, I don't think I did. What I said was:
---snip---
Modify checkout so that the first commit while detached automatically
creates a branch. Perhaps the name is derived from the branch point,
or the user is prompted for a name.
---snip---
So we'd only automatically create a new branch at commit time. But
never mind that, it was just a suggestion and I don't like it.
What if instead we do something like this:
$ git checkout v1.5.5
Note: moving to 'v1.5.5' which isn't a local branch
If you want to create a new branch from this checkout, you may do so
(now or later) by using -b with the checkout command again. Example:
git checkout -b <new_branch_name>
HEAD is now at 1d2375d... GIT 1.5.5
$ [edit foo.c]
$ git add foo.c
$ git commit -m "edited some file"
Cannot commit to v1.5.5. Please use git commit -b <branch> to specify
the name of a new branch to commit to, or use git commit --detach to
force a detached commit.
So we modify git to, by default, no longer allow creating a commit
while detached or on a branch that cannot be committed to.
j.
^ permalink raw reply
* Re: [PATCH 1/6] Open the pack file and keep a map on it.
From: Sverre Rabbelier @ 2009-10-14 12:48 UTC (permalink / raw)
To: Hervé Cauwelier; +Cc: Git List
In-Reply-To: <1255516669-26745-1-git-send-email-herve@itaapy.com>
Heya,
2009/10/14 Hervé Cauwelier <herve@itaapy.com>:
Please include a cover letter for series as long as these (anything
larger than 4 should have a cover letter IMHO). Doing so makes it
easier for those that follow the series to see what changed (assuming
you write down what changed in the cover letter). Also, it makes it
easier for those that were not following the series to drop in at the
current version (assuming you provide a short summary of what the
series is about in the cover letter).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so
From: Jakub Narebski @ 2009-10-14 10:46 UTC (permalink / raw)
To: Thomas Rast
Cc: Junio C Hamano, Johannes Schindelin, Euguess, Mikael Magnusson,
Matthieu Moy, Jeff King, Jay Soffian, git
In-Reply-To: <200910141156.55536.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> So I think we're now mixing up two different goals in this thread:
> a) Stopping the users from hurting themselves by inadvertent detaching
> b) Helping the users by DWIMming local branches for them
>
> I'm all for (a), but (b) is much harder.
Perhaps (b) should be protected by branch.autocreatelocal (similar to
branch.autosetupmerge and branch.autosetuprebase).
Also we should always print a message if we DWIM creating or checking
out local branch equivalent to remote-tracking branch.
Also, why interactive checkout (checkout --interactive?) idea was
abandoned?
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH 3/6] Allow zlib to read a pack buffer longer than the actual data
From: Hervé Cauwelier @ 2009-10-14 10:37 UTC (permalink / raw)
To: git
In-Reply-To: <1255516669-26745-2-git-send-email-herve@itaapy.com>
As we don't know where the compressed data end, only the size of the
uncompressed data.
Signed-off-by: Hervé Cauwelier <herve@itaapy.com>
---
src/odb.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/odb.c b/src/odb.c
index 2b4b016..349747b 100644
--- a/src/odb.c
+++ b/src/odb.c
@@ -432,7 +432,7 @@ static int inflate_buffer(void *in, size_t inlen, void *out, size_t outlen)
inflateEnd(&zs);
- if ((status != Z_STREAM_END) || (zs.avail_in != 0))
+ if (status != Z_STREAM_END)
return GIT_ERROR;
if (zs.total_out != outlen)
--
1.6.5
^ permalink raw reply related
* [PATCH 6/6] Read an object from a pack file
From: Hervé Cauwelier @ 2009-10-14 10:37 UTC (permalink / raw)
To: git
In-Reply-To: <1255516669-26745-5-git-send-email-herve@itaapy.com>
Signed-off-by: Hervé Cauwelier <herve@itaapy.com>
---
src/odb.c | 11 +++++++----
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/src/odb.c b/src/odb.c
index a612299..65a7993 100644
--- a/src/odb.c
+++ b/src/odb.c
@@ -1263,13 +1263,16 @@ static int read_packed(git_obj *out, git_pack *p, const git_oid *id)
if (pack_openidx(p))
return GIT_ERROR;
+ if (pack_openpack(p)) {
+ pack_decidx(p);
+ return GIT_ERROR;
+ }
res = p->idx_search(&pos, p, id);
pack_decidx(p);
+ assert(pos < p->pack_map.len);
- if (!res) {
- /* TODO unpack object at pos */
- res = GIT_ERROR;
- }
+ if (res == GIT_SUCCESS)
+ return inflate_pack_obj(out, p, pos);
return res;
}
--
1.6.5
^ permalink raw reply related
* [PATCH 4/6] Inflate an object from a pack file
From: Hervé Cauwelier @ 2009-10-14 10:37 UTC (permalink / raw)
To: git
In-Reply-To: <1255516669-26745-3-git-send-email-herve@itaapy.com>
Support delta objects too.
Signed-off-by: Hervé Cauwelier <herve@itaapy.com>
---
src/odb.c | 69 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 68 insertions(+), 1 deletions(-)
diff --git a/src/odb.c b/src/odb.c
index 349747b..c71948b 100644
--- a/src/odb.c
+++ b/src/odb.c
@@ -28,6 +28,7 @@
#include "git/zlib.h"
#include "fileops.h"
#include "hash.h"
+#include "delta-apply.h"
#include "odb.h"
#define GIT_PACK_NAME_MAX (5 + 40 + 1)
@@ -232,7 +233,7 @@ static int is_zlib_compressed_data(unsigned char *data)
unsigned int w;
w = ((unsigned int)(data[0]) << 8) + data[1];
- return data[0] == 0x78 && !(w %31);
+ return data[0] == 0x78 && !(w % 31);
}
static size_t get_binary_object_header(obj_hdr *hdr, gitfo_buf *obj)
@@ -1192,6 +1193,72 @@ int git_odb__read_loose(git_obj *out, git_odb *db, const git_oid *id)
return GIT_SUCCESS;
}
+static int inflate_pack_obj(git_obj *out, git_pack *p, off_t offset)
+{
+ obj_hdr hdr;
+ gitfo_buf buf;
+ size_t used;
+ void *data;
+ git_obj base;
+
+ /* Cast the map to a gitfo_buf */
+ buf.data = (unsigned char *)p->pack_map.data + offset;
+ buf.len = p->pack_map.len - offset;
+
+ /*
+ * Read the object header, which is an (uncompressed)
+ * binary encoding of the object type and size.
+ */
+ if (!(used = get_binary_object_header(&hdr, &buf)))
+ return GIT_ERROR;
+
+ /*
+ * Read the object data as a zlib compressed data
+ */
+ buf.data += used;
+ buf.len -= used;
+ assert(is_zlib_compressed_data(buf.data));
+
+ if (!(data = git__malloc(hdr.size + 1)))
+ return GIT_ERROR;
+ if (inflate_buffer(buf.data, buf.len, data, hdr.size))
+ goto inflate_fail;
+
+ switch (hdr.type) {
+ case GIT_OBJ_COMMIT:
+ case GIT_OBJ_TREE:
+ case GIT_OBJ_BLOB:
+ case GIT_OBJ_TAG:
+ out->data = data;
+ out->len = hdr.size;
+ out->type = hdr.type;
+ return GIT_SUCCESS;
+ case GIT_OBJ_OFS_DELTA:
+ offset -= hdr.base_offset;
+ if (inflate_pack_obj(&base, p, offset))
+ goto inflate_fail;
+ if (git__delta_apply(out, base.data, base.len, data, hdr.size))
+ goto inflate_fail;
+ out->type = base.type;
+ return GIT_SUCCESS;
+ case GIT_OBJ_REF_DELTA:
+ if (p->idx_search(&offset, p, &hdr.base_name))
+ goto inflate_fail;
+ if (inflate_pack_obj(&base, p, offset))
+ goto inflate_fail;
+ if (git__delta_apply(out, base.data, base.len, data, hdr.size))
+ goto inflate_fail;
+ out->type = base.type;
+ return GIT_SUCCESS;
+ default:
+ goto inflate_fail;
+ }
+
+inflate_fail:
+ free(data);
+ return GIT_ERROR;
+}
+
static int read_packed(git_obj *out, git_pack *p, const git_oid *id)
{
off_t pos;
--
1.6.5
^ permalink raw reply related
* [PATCH 1/6] Open the pack file and keep a map on it.
From: Hervé Cauwelier @ 2009-10-14 10:37 UTC (permalink / raw)
To: git
On the same model than the idx file.
Signed-off-by: Hervé Cauwelier <herve@itaapy.com>
---
src/odb.c | 65 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
src/odb.h | 1 +
2 files changed, 65 insertions(+), 1 deletions(-)
diff --git a/src/odb.c b/src/odb.c
index 6d646a4..2319998 100644
--- a/src/odb.c
+++ b/src/odb.c
@@ -64,6 +64,10 @@ struct git_pack {
/** Name of the pack file(s), without extension ("pack-abc"). */
char pack_name[GIT_PACK_NAME_MAX];
+
+ /** The .pack file, mapped into memory. */
+ git_file pack_fd;
+ git_map pack_map;
};
typedef struct git_pack git_pack;
@@ -809,6 +813,59 @@ unlock_fail:
return GIT_ERROR;
}
+static int pack_openpack_map(git_pack *p)
+{
+ char pb[GIT_PATH_MAX];
+ off_t len;
+
+ if (git__fmt(pb, sizeof(pb), "%s/pack/%s.pack",
+ p->db->objects_dir,
+ p->pack_name) < 0)
+ return GIT_ERROR;
+
+ if ((p->pack_fd = gitfo_open(pb, O_RDONLY)) < 0)
+ return GIT_ERROR;
+
+ if ((len = gitfo_size(p->pack_fd)) < 0
+ || !git__is_sizet(len)
+ || gitfo_map_ro(&p->pack_map, p->pack_fd, 0, (size_t)len)) {
+ gitfo_close(p->pack_fd);
+ return GIT_ERROR;
+ }
+
+ return GIT_SUCCESS;
+}
+
+static int pack_openpack(git_pack *p)
+{
+ gitlck_lock(&p->lock);
+ if (p->invalid)
+ goto unlock_fail;
+ if (p->pack_fd < 0) {
+ uint32_t *data;
+
+ if (pack_openpack_map(p))
+ goto invalid_fail;
+ data = p->pack_map.data;
+
+ if (decode32(&data[0]) != PACK_HDR)
+ goto unmap_fail;
+ }
+ gitlck_unlock(&p->lock);
+ return GIT_SUCCESS;
+
+unmap_fail:
+ gitfo_free_map(&p->pack_map);
+
+invalid_fail:
+ p->invalid = 1;
+ p->pack_fd = -1;
+
+unlock_fail:
+ gitlck_unlock(&p->lock);
+ return GIT_ERROR;
+}
+
static void pack_decidx(git_pack *p)
{
gitlck_lock(&p->lock);
@@ -830,6 +887,11 @@ static void pack_dec(git_pack *p)
gitfo_close(p->idx_fd);
free(p->im_fanout);
}
+ if (p->pack_fd >= 0) {
+ gitfo_free_map(&p->pack_map);
+ gitfo_close(p->pack_fd);
+ p->pack_fd = -1;
+ }
gitlck_free(&p->lock);
free(p);
@@ -861,6 +923,7 @@ static git_pack *alloc_pack(const char *pack_name)
gitlck_init(&p->lock);
strcpy(p->pack_name, pack_name);
p->refcnt = 1;
+ p->pack_fd = -1;
return p;
}
@@ -895,7 +958,7 @@ static int scan_one_pack(void *state, char *name)
r->next = *ret;
*ret = r;
- return 0;
+ return GIT_SUCCESS;
}
static git_packlist* scan_packs(git_odb *db)
diff --git a/src/odb.h b/src/odb.h
index 2f205b2..121583f 100644
--- a/src/odb.h
+++ b/src/odb.h
@@ -15,5 +15,6 @@
* cannot be true for an idx v1 file.
*/
#define PACK_TOC 0xff744f63 /* -1tOc */
+#define PACK_HDR 0x5041434b /* PACK */
#endif
--
1.6.5
^ permalink raw reply related
* [PATCH 2/6] Read the base offset or name of delta objects
From: Hervé Cauwelier @ 2009-10-14 10:37 UTC (permalink / raw)
To: git
In-Reply-To: <1255516669-26745-1-git-send-email-herve@itaapy.com>
Signed-off-by: Hervé Cauwelier <herve@itaapy.com>
---
src/cc-compat.h | 3 +++
src/odb.c | 28 ++++++++++++++++++++++++++--
2 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/src/cc-compat.h b/src/cc-compat.h
index 8997caa..8dd6774 100644
--- a/src/cc-compat.h
+++ b/src/cc-compat.h
@@ -30,6 +30,9 @@
# define GIT_TYPEOF(x)
#endif
+#define bitsizeof(x) (CHAR_BIT * sizeof(x))
+#define MSB(x, bits) ((x) & GIT_TYPEOF(x)(~0ULL << (bitsizeof(x) - (bits))))
+
/*
* Does our compiler/platform support the C99 <inttypes.h> and
* <stdint.h> header files. (C99 requires that <inttypes.h>
diff --git a/src/odb.c b/src/odb.c
index 2319998..2b4b016 100644
--- a/src/odb.c
+++ b/src/odb.c
@@ -97,8 +97,10 @@ struct git_odb {
};
typedef struct { /* object header data */
- git_otype type; /* object type */
- size_t size; /* object size */
+ git_otype type; /* object type */
+ size_t size; /* object size */
+ off_t base_offset; /* delta base offset (GIT_OBJ_OFS_DELTA) */
+ git_oid base_name; /* delta base name (GIT_OBJ_REF_DELTA) */
} obj_hdr;
static struct {
@@ -238,6 +240,7 @@ static size_t get_binary_object_header(obj_hdr *hdr, gitfo_buf *obj)
unsigned char c;
unsigned char *data = obj->data;
size_t shift, size, used = 0;
+ off_t base_offset;
if (obj->len == 0)
return 0;
@@ -258,6 +261,27 @@ static size_t get_binary_object_header(obj_hdr *hdr, gitfo_buf *obj)
}
hdr->size = size;
+ hdr->base_offset = 0;
+ hdr->base_name.id[0] = '\0';
+
+ if (hdr->type == GIT_OBJ_OFS_DELTA) {
+ c = data[used++];
+ base_offset = c & 127;
+ while (c & 128) {
+ base_offset++;
+ if (!base_offset || MSB(base_offset, 7))
+ return 0; /* overflow */
+ c = data[used++];
+ base_offset = (base_offset << 7) + (c & 127);
+ }
+ assert(base_offset > 0);
+ hdr->base_offset = base_offset;
+ }
+ else if (hdr->type == GIT_OBJ_REF_DELTA) {
+ git_oid_mkraw(&hdr->base_name, data + used);
+ used += 20;
+ }
+
return used;
}
--
1.6.5
^ permalink raw reply related
* [PATCH 5/6] This assertion is valid for both loose and packed objects
From: Hervé Cauwelier @ 2009-10-14 10:37 UTC (permalink / raw)
To: git
In-Reply-To: <1255516669-26745-4-git-send-email-herve@itaapy.com>
Signed-off-by: Hervé Cauwelier <herve@itaapy.com>
---
src/odb.c | 9 +++------
1 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/src/odb.c b/src/odb.c
index c71948b..a612299 100644
--- a/src/odb.c
+++ b/src/odb.c
@@ -1149,11 +1149,10 @@ void git_odb_close(git_odb *db)
free(db);
}
-int git_odb_read(
- git_obj *out,
- git_odb *db,
- const git_oid *id)
+int git_odb_read(git_obj *out, git_odb *db, const git_oid *id)
{
+ assert(out && db && id);
+
attempt:
if (!git_odb__read_packed(out, db, id))
return GIT_SUCCESS;
@@ -1171,8 +1170,6 @@ int git_odb__read_loose(git_obj *out, git_odb *db, const git_oid *id)
char file[GIT_PATH_MAX];
gitfo_buf obj = GITFO_BUF_INIT;
- assert(out && db && id);
-
out->data = NULL;
out->len = 0;
out->type = GIT_OBJ_BAD;
--
1.6.5
^ permalink raw reply related
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Johannes Schindelin @ 2009-10-14 10:33 UTC (permalink / raw)
To: Jeff King; +Cc: Daniel Barkalow, Junio C Hamano, git
In-Reply-To: <20091014050851.GE31810@coredump.intra.peff.net>
Hi,
On Wed, 14 Oct 2009, Jeff King wrote:
> On Wed, Oct 14, 2009 at 12:44:34AM -0400, Daniel Barkalow wrote:
>
> > +char *get_detached_head_string(void)
> > +{
> > + char *filename = git_path("DETACH_NAME");
> > + struct stat st;
> > + if (stat(filename, &st) || !S_ISREG(st.st_mode))
> > + return NULL;
> > + struct strbuf buf = STRBUF_INIT;
> > + strbuf_read_file(&buf, filename, st.st_size);
> > + strbuf_trim(&buf);
> > + return strbuf_detach(&buf, 0);
> > +}
>
> Would it hurt to tuck this information into HEAD itself, as we already
> put arbitrary text into FETCH_HEAD?
AFAIR we still remember HEAD to be a symlink.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC PATCH 2/5] Introduce new pretty formats %g and %G for reflog information
From: Thomas Rast @ 2009-10-14 9:58 UTC (permalink / raw)
To: Jeff King; +Cc: Jef Driesen, Nanako Shiraishi, git
In-Reply-To: <20091014045918.GA31810@coredump.intra.peff.net>
Jeff King wrote:
> On Mon, Oct 12, 2009 at 11:06:04PM +0200, Thomas Rast wrote:
>
> > Unfortunately, we also need to pass down the reflog_walk_info from
> > show_log(), so this commit touches a lot of (unrelated) callers to
> > pretty_print_commit() and format_commit_message() to accomodate the
> > extra argument.
>
> A while back I wanted to add a feature to pretty-printing, and I ran
> into the same situation (though my feature never made it to the list).
> We really end up passing around the same arguments over and over. Maybe
> it makes sense instead of adding another argument to refactor into a
> "pretty_print_context" struct that contains all of the arguments and
> current state.
>
> It would be an even more invasive patch, but I think it would make
> things more readable, and make future changes much easier to see.
Ok, I'll try for the next round.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so
From: Thomas Rast @ 2009-10-14 9:56 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Euguess, Mikael Magnusson, Matthieu Moy,
Jeff King, Jay Soffian, git
In-Reply-To: <200910131051.47117.trast@student.ethz.ch>
Thomas Rast wrote:
> Junio C Hamano wrote:
> >
> > #1. These used to detach, but will create a local branch
> >
> > $ git checkout origin/next ;# as if with -t
> > $ git checkout xyzzy/frotz ;# as if with -t (origin is not special)
>
> Agreed, though I'm still in favour of a cleaner syntax for explicit
> detaching. (Cleaner in the sense that ^0 is documented as having a
> completely different purpose and only works by accident.)
Not sure if it's too late in the thread, but after sleeping over it
and re-reading (and the other developments in the thread) I'm not
happy with my earlier opinion any more. I think the DWIM part of it
is a bad idea because of this:
> > $ git checkout origin/master ;# detach, or refuse???
>
> This seems to be the trickiest of them. Maybe check out 'master', to
> make the process repeatable. Imagine, in your setting,
>
> git checkout origin/next ;# creates 'next' as with -t
> git checkout - ;# back
> git checkout origin/next ;# should go to 'next' again
>
> Then again, that would trade the confusion of detaching for the
> confusion of not checking out the exact commit that the user
> specified. Worse, 'next' could conceivably be tracking (as per
> branch.next.merge) some entirely different branch, making the "Your
> branch is behind..." message misleading.
So I think we're now mixing up two different goals in this thread:
a) Stopping the users from hurting themselves by inadvertent detaching
b) Helping the users by DWIMming local branches for them
I'm all for (a), but (b) is much harder.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so
From: Thomas Rast @ 2009-10-14 9:33 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Jeff King, Daniel Barkalow, Johannes Sixt,
Euguess, Mikael Magnusson, Matthieu Moy, Jay Soffian, git
In-Reply-To: <alpine.DEB.1.00.0910140108110.4985@pacific.mpi-cbg.de>
Johannes Schindelin wrote:
>
> Let me tell you this from my experience: the least likely answer is "the
> messages are too scary". Invariably, the answer I get is "it is totally
> unintuitive". Often followed by "I tell Git to do something
> straight-forward, and it refuses to do it."
<aside>
Actually I had a rather insightful discussion yesterday (spawned by
this exact thread) with someone here at the institute. He said
something to the effect that git's problem is mostly that it is unlike
everything else. You cannot explain git in simple metaphors like
files, copies and such. Any attempt to do so will just fall short
really soon.
[On the other hand, some users appear unwilling to learn something new
because they "just want to version control this" or "just need to make
a commit to this project".]
</aside>
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH] gitweb: fix esc_param
From: Junio C Hamano @ 2009-10-14 9:13 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Jakub Narebski, Stephen Boyd, Junio C Hamano
In-Reply-To: <1255463496-21617-1-git-send-email-giuseppe.bilotta@gmail.com>
Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
> ...
> Finally, remove an unnecessary escaping of the + sign.
>
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Thanks.
^ permalink raw reply
* Re: [PATCH] clone: Supply the right commit hash to post-checkout when -b is used
From: Junio C Hamano @ 2009-10-14 9:13 UTC (permalink / raw)
To: Jeff King; +Cc: Björn Steinbrink, Junio C Hamano, git, ranguvar
In-Reply-To: <20091014000619.GA20496@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
>> Reported-by: Devin Cofer <ranguvar@archlinux.us>
>> Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
>
> Acked-by: Jeff King <peff@peff.net>
>
> Thanks.
Thanks; will queue on 'maint' for 1.6.5.1.
^ permalink raw reply
* Re: [PATCH v3] bisect reset: Allow resetting to any commit, not just a branch
From: Junio C Hamano @ 2009-10-14 9:13 UTC (permalink / raw)
To: Anders Kaseorg; +Cc: Christian Couder, git
In-Reply-To: <alpine.DEB.2.00.0910131700320.5105@dr-wily.mit.edu>
Thanks; will replace your v2 that was queued in 'pu'.
^ permalink raw reply
* Re: [RFC PATCH 2/5] Introduce new pretty formats %g and %G for reflog information
From: Junio C Hamano @ 2009-10-14 9:13 UTC (permalink / raw)
To: Thomas Rast; +Cc: Jef Driesen, Jeff King, Nanako Shiraishi, git
In-Reply-To: <e0321a8af8d702d24ace33510daff22d02f4e116.1255380039.git.trast@student.ethz.ch>
Squash this patch on top, as
cc1: warnings being treated as errors
reflog-walk.c: In function 'get_reflog_message':
reflog-walk.c:278: error: ISO C90 forbids mixed declarations and code
---
reflog-walk.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/reflog-walk.c b/reflog-walk.c
index 929f025..5cbcb1a 100644
--- a/reflog-walk.c
+++ b/reflog-walk.c
@@ -270,12 +270,13 @@ void get_reflog_message(struct strbuf *sb,
{
struct commit_reflog *commit_reflog = reflog_info->last_commit_reflog;
struct reflog_info *info;
+ size_t len;
if (!commit_reflog)
return;
info = &commit_reflog->reflogs->items[commit_reflog->recno+1];
- size_t len = strlen(info->message);
+ len = strlen(info->message);
if (len > 0)
len--;
strbuf_add(sb, info->message, len);
^ permalink raw reply related
* Re: [PATCH] gitweb: linkify author/committer names with search
From: Junio C Hamano @ 2009-10-14 9:13 UTC (permalink / raw)
To: Stephen Boyd; +Cc: git, Junio C Hamano, Giuseppe Bilotta, Jakub Narebski
In-Reply-To: <1255486344-11891-1-git-send-email-bebarino@gmail.com>
Stephen Boyd <bebarino@gmail.com> writes:
> It's nice to search for an author by merely clicking on their name in
> gitweb. This is usually faster than selecting the name, copying the
> selection, pasting it into the search box, selecting between
> author/committer and then hitting enter.
>
> Linkify the avatar icon in log/shortlog view because the icon is directly
> adjacent to the name and thus more related. The same is not true
> when in commit/tag view where the icon is farther away.
>
> Signed-off-by: Stephen Boyd <bebarino@gmail.com>
> ---
>
> This is on top of Giuseppe's fix esc_param patch.
>
> gitweb/gitweb.css | 1 +
> gitweb/gitweb.perl | 21 ++++++++++++++++-----
> 2 files changed, 17 insertions(+), 5 deletions(-)
>
> diff --git a/gitweb/gitweb.css b/gitweb/gitweb.css
> index 8f68fe3..e2cd9d7 100644
> --- a/gitweb/gitweb.css
> +++ b/gitweb/gitweb.css
> @@ -30,6 +30,7 @@ img.logo {
>
> img.avatar {
> vertical-align: middle;
> + border-width: 0px;
> }
Even though it _might_ be a good thing to do, this looks an unrelated
change,
> div.page_header {
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 4b21ad2..bdf1037 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -1602,8 +1602,12 @@ sub format_author_html {
> my $co = shift;
> my $author = chop_and_escape_str($co->{'author_name'}, @_);
> return "<$tag class=\"author\">" .
> - git_get_avatar($co->{'author_email'}, -pad_after => 1) .
> - $author . "</$tag>";
> + $cgi->a({-href => href(action=>"search", hash=>$hash,
> + searchtext=>$co->{'author_name'},
> + searchtype=>"author"), class=>"list"},
> + git_get_avatar($co->{'author_email'}, -pad_after => 1) .
> + $author) .
> + "</$tag>";
> }
>
> # format git diff header line, i.e. "diff --(git|combined|cc) ..."
> @@ -3372,10 +3376,13 @@ sub git_print_authorship {
> my $co = shift;
> my %opts = @_;
> my $tag = $opts{-tag} || 'div';
> + my $author = $co->{'author_name'};
>
> my %ad = parse_date($co->{'author_epoch'}, $co->{'author_tz'});
> print "<$tag class=\"author_date\">" .
> - esc_html($co->{'author_name'}) .
> + $cgi->a({-href => href(action=>"search", searchtext=>$author,
> + searchtype=>"author"), class=>"list"},
> + esc_html($author)) .
> " [$ad{'rfc2822'}";
> print_local_time(%ad) if ($opts{-localtime});
> print "]" . git_get_avatar($co->{'author_email'}, -pad_before => 1)
> @@ -3394,8 +3401,12 @@ sub git_print_authorship_rows {
> @people = ('author', 'committer') unless @people;
> foreach my $who (@people) {
> my %wd = parse_date($co->{"${who}_epoch"}, $co->{"${who}_tz"});
> - print "<tr><td>$who</td><td>" . esc_html($co->{$who}) . "</td>" .
> - "<td rowspan=\"2\">" .
> + print "<tr><td>$who</td><td>" .
> + $cgi->a({-href => href(action=>"search",
> + searchtext=>$co->{"${who}_name"},
> + searchtype=>$who), class=>"list"},
> + esc_html($co->{$who})) .
> + "</td><td rowspan=\"2\">" .
> git_get_avatar($co->{"${who}_email"}, -size => 'double') .
> "</td></tr>\n" .
> "<tr>" .
> --
> 1.6.5.1.g75846.dirty
^ permalink raw reply
* Re: Efficient cloning from svn (with multiple branches/tags subdirs)
From: Bruno Harbulot @ 2009-10-14 9:07 UTC (permalink / raw)
To: git
In-Reply-To: <20091014060307.GA17178@dcvr.yhbt.net>
Hi Eric,
Eric Wong wrote:
> Hi Bruno,
>
> That looks like there's two levels of tags. You should be able to do
> this with your version of git in $GIT_CONFIG:
>
> [svn-remote "svn"]
> url = http://restlet.tigris.org/svn/restlet
> fetch = trunk:refs/remotes/svn/trunk
> branches = branches/*:refs/remotes/svn/*
> tags = tags/*/*:refs/remotes/svn/tags/*/*
> ; note the */* to glob at multiple levels
Thank you, here is what I had (with the multiple -t/-b):
[svn-remote "svn"]
url = http://restlet.tigris.org/svn/restlet
branches = branches/1.0/*:refs/remotes/svn/*
branches = branches/1.1/*:refs/remotes/svn/*
tags = tags/1.0/*:refs/remotes/svn/tags/*
tags = tags/1.1/*:refs/remotes/svn/tags/*
tags = tags/1.2/*:refs/remotes/svn/tags/*
tags = tags/2.0/*:refs/remotes/svn/tags/*
I think the notation you suggest "*/*" is indeed better, since I don't
have to specify each tag sub-directory. However, they change so rarely
that it was only a minor issue.
>> What surprises me is that it looks like it's looping over and over,
>> since sometimes it starts back from SVN revision 1 when it's trying to
>> import a new tag.
>
> Yeah, that's an unfortunate thing about the flexibility of Subversion,
> basically anything can be a "tag" or a directory and it's extremely
> hard for git svn to support any uncommon cases for tags/branches
> out-of-the box, so the manual config editing is needed.
I must admit I don't fully understand how git-svn does the import, but
even with this manual configuration, it still tries to pull (almost)
every revision from revision 1 for each tag, a bit as if there was:
for each tag:
for revision in 1 to tag.latest revision:
pull the revision
(This isn't even for each tag, but for each modification of each tag,
since tags aren't really tags in SVN).
What I'd like to be able to do (mainly for efficiency and more
importantly not to hammer tigris.org) is to pull each revision at most
once (even if it's for the directory at the top of trunk, branches and
tags).
Best wishes,
Bruno.
^ permalink raw reply
* Re: [PATCH] change throughput display units with fast links
From: Junio C Hamano @ 2009-10-14 9:13 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Nicolas Pitre, git
In-Reply-To: <4AD578BD.7080201@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Nicolas Pitre schrieb:
>> + if (rate > 1 << 10) {
>> + int x = rate + 5; /* for rounding */
>> + snprintf(tp->display + sizeof(tp->display) - l, l,
>> + " | %u.%2.2u MiB/s",
>
> Shouldn't the fractional part be "%02.2u" (leading zeros instead of blanks)?
>
>> + x >> 10, ((x & ((1 << 10) - 1)) * 100) >> 10);
>> + } else if (rate)
>> snprintf(tp->display + sizeof(tp->display) - l, l,
>> " | %u KiB/s", rate);
>> }
>
> -- Hannes
Judging from the surrounding existing code, I do not think so.
$ cat <<\EOF >j.c
#include <stdio.h>
int main(int ac, char **av)
{
printf("%u.%2.2u\n", 4, 5);
return 0;
}
EOF
$ gcc -o j j.c && ./j
4.05
^ 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