Re: Officially start moving to the term 'staging area'

From: "Felipe Contreras" Sent: Sunday, September 08, 2013 2:33 AM [snip...] The snapshot concept is totally orthogonal from the staging area concept. Git works in snapshots, which are frozen images of how the content tree was at a certain point in time; IOW; a commit. (I feel that) In most peo

Re: [PATCH 1/3] upload-pack: send the HEAD information

On Sun, Sep 08, 2013 at 03:13:59AM -0400, Jeff King wrote: > What do you think about teaching git to read extra data after "\0" for > _every_ ref line? And then ref advertisement might look something like: > >HEAD\0multi_ack thin-pack ... symref=refs/heads/master\n >refs/heads/master\n >

[PATCH v2 11/14] index-pack: move delta base queuing code to unpack_raw_entry

For v2, ofs-delta and ref-delta can only have queue one delta base at a time. A v4 tree can have more than one delta base. Move the queuing code up to unpack_raw_entry() and give unpack_tree_v4() more flexibility to add its bases. --- builtin/index-pack.c | 46 ++---

[PATCH v2 09/14] index-pack: parse v4 commit format

--- builtin/index-pack.c | 94 ++-- 1 file changed, 91 insertions(+), 3 deletions(-) diff --git a/builtin/index-pack.c b/builtin/index-pack.c index efb969a..473514a 100644 --- a/builtin/index-pack.c +++ b/builtin/index-pack.c @@ -319,6 +319,30 @@ st

[PATCH v2 12/14] index-pack: record all delta bases in v4 (tree and ref-delta)

--- builtin/index-pack.c | 33 ++--- 1 file changed, 30 insertions(+), 3 deletions(-) diff --git a/builtin/index-pack.c b/builtin/index-pack.c index 8f2d929..e903a49 100644 --- a/builtin/index-pack.c +++ b/builtin/index-pack.c @@ -24,6 +24,7 @@ struct object_entry {

[PATCH v2 14/14] index-pack: resolve v4 one-base trees

This is the most common case for delta trees. In fact it's the only kind that's produced by packv4-create. It fits well in the way index-pack resolves deltas and benefits from threading (the set of objects depending on this base does not overlap with the set of objects depending on another base) M

[PATCH v2 10/14] index-pack: parse v4 tree format

--- builtin/index-pack.c | 105 +-- 1 file changed, 101 insertions(+), 4 deletions(-) diff --git a/builtin/index-pack.c b/builtin/index-pack.c index 473514a..dcb6409 100644 --- a/builtin/index-pack.c +++ b/builtin/index-pack.c @@ -334,6 +334,14 @@ s

[PATCH v2 08/14] index-pack: make sure all objects are registered in v4's SHA-1 table

--- builtin/index-pack.c | 22 -- 1 file changed, 20 insertions(+), 2 deletions(-) diff --git a/builtin/index-pack.c b/builtin/index-pack.c index 83e6e79..efb969a 100644 --- a/builtin/index-pack.c +++ b/builtin/index-pack.c @@ -288,6 +288,19 @@ static inline void *fill_and_use

[PATCH v2 13/14] index-pack: skip looking for ofs-deltas in v4 as they are not allowed

--- builtin/index-pack.c | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/builtin/index-pack.c b/builtin/index-pack.c index e903a49..ce06473 100644 --- a/builtin/index-pack.c +++ b/builtin/index-pack.c @@ -1173,10 +1173,13 @@ static struct base_data *find_unresolved

[PATCH v2 03/14] index-pack: add more comments on some big functions

--- builtin/index-pack.c | 30 ++ 1 file changed, 26 insertions(+), 4 deletions(-) diff --git a/builtin/index-pack.c b/builtin/index-pack.c index 9c1cfac..1dbabe0 100644 --- a/builtin/index-pack.c +++ b/builtin/index-pack.c @@ -19,8 +19,8 @@ struct object_entry {

[PATCH v2 06/14] index-pack: split inflate/digest code out of unpack_entry_data

--- builtin/index-pack.c | 62 +++- 1 file changed, 37 insertions(+), 25 deletions(-) diff --git a/builtin/index-pack.c b/builtin/index-pack.c index 78554d0..3389262 100644 --- a/builtin/index-pack.c +++ b/builtin/index-pack.c @@ -431,6 +431,40 @@ s

[PATCH v2 05/14] index-pack: do not allocate buffer for unpacking deltas in the first pass

We do need deltas until the second pass. Allocating a buffer for it then freeing later is wasteful is unnecessary. Make it use fixed_buf (aka large blob code path). --- builtin/index-pack.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/builtin/index-pack.c b/builtin/index-p

[PATCH v2 04/14] index-pack: split out varint decoding code

--- builtin/index-pack.c | 82 1 file changed, 45 insertions(+), 37 deletions(-) diff --git a/builtin/index-pack.c b/builtin/index-pack.c index 1dbabe0..5fbd517 100644 --- a/builtin/index-pack.c +++ b/builtin/index-pack.c @@ -277,6 +277,31 @@ s

[PATCH v2 02/14] pack v4: add pv4_free_dict()

--- packv4-parse.c | 8 packv4-parse.h | 1 + sha1_file.c| 2 ++ 3 files changed, 11 insertions(+) diff --git a/packv4-parse.c b/packv4-parse.c index 82661ba..d515bb9 100644 --- a/packv4-parse.c +++ b/packv4-parse.c @@ -63,6 +63,14 @@ struct packv4_dict *pv4_create_dict(const unsigne

[PATCH v2 07/14] index-pack: parse v4 header and dictionaries

--- builtin/index-pack.c | 49 - 1 file changed, 48 insertions(+), 1 deletion(-) diff --git a/builtin/index-pack.c b/builtin/index-pack.c index 3389262..83e6e79 100644 --- a/builtin/index-pack.c +++ b/builtin/index-pack.c @@ -11,6 +11,7 @@ #include

[PATCH v2 01/14] pack v4: split pv4_create_dict() out of load_dict()

--- packv4-parse.c | 63 -- packv4-parse.h | 8 2 files changed, 43 insertions(+), 28 deletions(-) diff --git a/packv4-parse.c b/packv4-parse.c index 63bba03..82661ba 100644 --- a/packv4-parse.c +++ b/packv4-parse.c @@ -30,11 +30,3

[PATCH v2 00/14] pack v4 support in index-pack

Mostly cleanups after Nico's comments. The diff against v2 is diff --git a/builtin/index-pack.c b/builtin/index-pack.c index 4a24bc3..88340b5 100644 --- a/builtin/index-pack.c +++ b/builtin/index-pack.c @@ -22,8 +22,8 @@ struct object_entry { struct pack_idx_entry idx; unsigned lon

Re: [PATCH 0/3] Reject non-ff pulls by default

On Sun, Sep 8, 2013 at 1:54 AM, Jeff King wrote: > On Sun, Sep 08, 2013 at 01:17:42AM -0500, Felipe Contreras wrote: > >> > I think it's fine to tell them to do "git pull --merge". What I'd worry >> > more about is somebody who is suddenly presented with the choice between >> > "--rebase" and "--m

Re: [PATCH 1/3] upload-pack: send the HEAD information

On Fri, Sep 06, 2013 at 10:46:24AM -0700, Junio C Hamano wrote: > I think it is perfectly fine to expose _only_ HEAD now, and wait > until we find a good reason that we should send this information for > other symbolic refs in the repository. Yeah, I agree with that. > However, because we alread

<    1   2