Re: Darcs-git: a few notes for Git hackers

> Date: Sun, 15 May 2005 13:48:47 +0200
> From: Petr Baudis <pasky@ucw.cz>
> To: Brad Roberts <braddr@puremagic.com>
> Cc: Juliusz Chroboczek <Juliusz.Chroboczek@pps.jussieu.fr>,
>      git@vger.kernel.org
> Subject: Re: Darcs-git: a few notes for Git hackers
>
> Dear diary, on Sun, May 15, 2005 at 04:04:25AM CEST, I got a letter
> where Brad Roberts <braddr@puremagic.com> told me that...
> > > I wasn't able to finish redoing these against linus tip, but I got most of
> > > it done (patches 1-14 of the original 19):
> > >
> > >   http://gameboy2.puremagic.com:8090/
> > >   rsync://gameboy2.puremagic.com/git/
> > >
> > > The second, third, and forth to last changes need a careful review,
> > > they're direct applications of the original patches which were lightly
> > > tested during the first round and nothing other than compile tested in
> > > this round.
> > >
> > > I suspect the remaining parts of the original patch series will go in
> > > fairly smoothly.  If no one gets to them before tonight I'll finish
> > > it up after work.
> > >
> > > Later,
> > > Brad
> >
> > I've completed the re-merge, and moved to tip of git-pb.git rather than
> > tip of git.git.  Unfortunatly that merge was also somewhat intrusive and
> > my individual diffs along the way are somewhat useless now.  The entire
> > history is available about the above locations still.  Attached is the
> > full diff vs git-pb @ 902b92e00e491a60d55c4b2bce122903b8347f34.
>
> I've merged some of the minor stuff for now.

Cool, though there appears to have been some objections. :)

> > 2) Should the index changing areas be constructing a new index instead of
> > shuffling bits within the current index?
>
> When I have a big cache (the only time it matters), I do usually only
> relatively small changes to it, so...

The entire index is bit shuffled around even if nothing changed.  At least
today, size and amount changed doesn't matter.

> > 3) The vocabulary and code is inconsistent between cache and index.
>
> Yes...
>
> > 4) read-cache.c does much more than reading.
>
> and yes. And cache.h is full of crap. Perhaps we could move read-cache.c
> to cache.c?

At least parts of it, probably yes.

> I'd imagine the plan of attack to continue by changing active_cache to
> be struct cache, then making it local.

Which is what the rest of that patch does.

Thanks for looking at this.

Later,
Brad

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html