Re: [0/5] Parsers for git objects, porting some programs
On Mon, 18 Apr 2005, Junio C Hamano wrote: > > "DB" == Daniel Barkalow <[EMAIL PROTECTED]> writes: > > DB> On Mon, 18 Apr 2005, Linus Torvalds wrote: > >> On Sun, 17 Apr 2005, Daniel Barkalow wrote: > >> > > >> > This series introduces common parsers for objects, and ports the programs > >> > that currently use revision.h to them. > >> > > >> > 1: the header files > >> > 2: the implementations > >> > 3: port rev-tree > >> > 4: port fsck-cache > >> > 5: port merge-base > >> > >> Ok, having now looked at the code, I don't have any objections at all. > > I was looking at the tree part and am thinking that it would > make it much nicer if your tree object records path for each > entry. As it turns out, the code I just doesn't actually record the path; it does everything else, and it should be easy to add the path to those entries. I mainly wanted object type (i.e., do I have to recurse into the object), so I skipped that one. But it should now be clear what you need to add. -Daniel *This .sig left intentionally blank* - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [0/5] Parsers for git objects, porting some programs
On Mon, 18 Apr 2005, Junio C Hamano wrote: > I was looking at the tree part and am thinking that it would > make it much nicer if your tree object records path for each > entry. You're entirely right, and I've actually now written the code that does it. I'm planning to send out a patch for that shortly. > Currently it just borrows from object.refs to represent > its children Note that object.refs needs to get filled out for those applications, even if the information is also included in the parse; object.refs is for finding what you can reach without worrying about how you do it. -Daniel *This .sig left intentionally blank* - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [0/5] Parsers for git objects, porting some programs
> "DB" == Daniel Barkalow <[EMAIL PROTECTED]> writes: DB> On Mon, 18 Apr 2005, Linus Torvalds wrote: >> On Sun, 17 Apr 2005, Daniel Barkalow wrote: >> > >> > This series introduces common parsers for objects, and ports the programs >> > that currently use revision.h to them. >> > >> > 1: the header files >> > 2: the implementations >> > 3: port rev-tree >> > 4: port fsck-cache >> > 5: port merge-base >> >> Ok, having now looked at the code, I don't have any objections at all. I was looking at the tree part and am thinking that it would make it much nicer if your tree object records path for each entry. Currently it just borrows from object.refs to represent its children, which is good enough for the applications listed above (none of them would care where in the tree the object belongs to), but I was thinking about an incremental dumper I talked about in another thread and noticed that I cannot use the current struct tree as is to compare two trees to find related sha1 files (then I would inflate both, run diff and record the output as a recipe to create one sha1 object from the other). Or am I misreading the code that parses tree objects? - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [0/5] Parsers for git objects, porting some programs
On Mon, 18 Apr 2005, Linus Torvalds wrote: > On Sun, 17 Apr 2005, Daniel Barkalow wrote: > > > > This series introduces common parsers for objects, and ports the programs > > that currently use revision.h to them. > > > > 1: the header files > > 2: the implementations > > 3: port rev-tree > > 4: port fsck-cache > > 5: port merge-base > > Ok, having now looked at the code, I don't have any objections at all. > Could you clarify the "fsck" issue about reading the same object twice? > When does that happen? Currently, the fsck-cache code is unpacking the objects to find out what type they are, and the old code would pass the unpacked objects to the parsing code. The new code doesn't take the unpacked objects, so it unpacks them again. (I.e., fsck-cache will look at each object exactly twice). The right solution is to have the internals reorganized slightly such that a "parse_object" method, which does what fsck-cache wants (i.e., parse this object regardless of what type it is, and tell me the type), could be fit in efficiently. But it doesn't affect the header file interface, and it's only relevant to fsck-cache, which wants to look at random junk that it doesn't have a reference to. -Daniel *This .sig left intentionally blank* - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [0/5] Parsers for git objects, porting some programs
On Sun, 17 Apr 2005, Daniel Barkalow wrote: > > This series introduces common parsers for objects, and ports the programs > that currently use revision.h to them. > > 1: the header files > 2: the implementations > 3: port rev-tree > 4: port fsck-cache > 5: port merge-base Ok, having now looked at the code, I don't have any objections at all. Could you clarify the "fsck" issue about reading the same object twice? When does that happen? Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
