[PATCH 0/3] Using a bit more decoration

2013-04-08 Thread Junio C Hamano
This comes on top of the two "decorate" patches that introduced the clear_decoration() function. I am not sure if pre-parsing and sharing the encoding values in-core would affect performance very much, but now we have 2 bytes (or 6 bytes, if you are on 64-bit archs) free to use in "struct commit"

Re: [PATCH 0/3] Using a bit more decoration

2013-04-08 Thread Jeff King
On Mon, Apr 08, 2013 at 04:01:51PM -0700, Junio C Hamano wrote: > This comes on top of the two "decorate" patches that introduced the > clear_decoration() function. > [...] > Junio C Hamano (3): > commit: shrink "indegree" field > commit: rename parse_commit_date() > commit: add get_commit_e

Re: [PATCH 0/3] Using a bit more decoration

2013-04-08 Thread Junio C Hamano
Jeff King writes: > [1] The thing that made me think about this was making a version of > paint_down_to_common that could keep a separate color for each > source, rather than only PARENT1 and PARENT2. That would let us do > the "--contains" traversal in a breadth-first way, but calcul

Re: [PATCH 0/3] Using a bit more decoration

2013-04-08 Thread Junio C Hamano
Jeff King writes: > Neat. Reading through, I didn't notice anything obviously wrong with any > of the patches (though there is one gcc warning, which I'll respond to > separately). > > It does make me a little nervous to have code that almost never gets > exercised (i.e., when indegree is really

Re: [PATCH 0/3] Using a bit more decoration

2013-04-08 Thread Jeff King
On Mon, Apr 08, 2013 at 09:17:42PM -0700, Junio C Hamano wrote: > Jeff King writes: > > > [1] The thing that made me think about this was making a version of > > paint_down_to_common that could keep a separate color for each > > source, rather than only PARENT1 and PARENT2. That would le

Re: [PATCH 0/3] Using a bit more decoration

2013-04-08 Thread Junio C Hamano
Jeff King writes: > The tricky part is how to store the index for each commit (or object). I > don't see a way around adding a new field to "struct commit" to do so. We could reuse the space "indegree" used to live at; that is a one-word space already, and I really do not need "encoding". It wa

Re: [PATCH 0/3] Using a bit more decoration

2013-04-08 Thread Jeff King
On Mon, Apr 08, 2013 at 09:54:50PM -0700, Junio C Hamano wrote: > Jeff King writes: > > > The tricky part is how to store the index for each commit (or object). I > > don't see a way around adding a new field to "struct commit" to do so. > > We could reuse the space "indegree" used to live at;

Re: [PATCH 0/3] Using a bit more decoration

2013-04-09 Thread Junio C Hamano
Jeff King writes: > +static inline int *slab_at(struct commit_slab *s, const struct commit *c) > +{ > + if (s->alloc <= c->index) { > + int new_alloc = alloc_nr(s->alloc); > + if (new_alloc <= c->index) > + new_alloc = c->index + 1; > + > +