Hi, On Wed, 1 Apr 2009, Christian Couder wrote: > Le mardi 31 mars 2009, Johannes Schindelin a écrit : > > Hi, > > > > On Tue, 31 Mar 2009, Christian Couder wrote: > > > Le lundi 30 mars 2009, Johannes Schindelin a écrit : > > > > On Mon, 30 Mar 2009, Christian Couder wrote: > > > > > Le jeudi 26 mars 2009, Junio C Hamano a écrit : > > > > > > I've learned to suspect without reading a qsort() callback that > > > > > > does not derefence its arguments. Is this doing the right thing? > > > > > > > > > > I think so. > > > > > > > > I suspect something much worse: you are trying to build a list of > > > > sha1s of commits that need to be skipped, later to look up every > > > > commit via binary search. > > > > > > > > But it has been proven a lot of times that using a hash set is > > > > superior to that approach, and even better: we already have the > > > > framework in place in the form of struct decorate. > > > > > > I had a look, and "struct decorate" can be used to store objects, but I > > > want to store only sha1s. > > > > No, you want to _look up_ sha1s. And struct decorate is not about > > storing objects, but to attach things to objects. > > The problem is that I don't have any object to attach things to when I > read the bisect skip refs. I just need to store the sha1 from the skip > refs in some sha1 container. I see, so you do not want to parse the commits just to register them as skipped. Fair enough. But I still think that a hashmap/set would be better suited. In any case, it should be refactored into something usable in all of libgit.a. You are basically duplicating the grafts code in commit.c, sharing that shortcoming that your code would be static again, not encouraging reusage. Ciao, Dscho
