On Wed, 2010-06-23 at 08:55 -0700, David Borowitz wrote: > On Wed, Jun 23, 2010 at 08:42, Jelmer Vernooij <[email protected]> > wrote:
> On Fri, 2010-06-11 at 20:55 -0400, David Borowitz wrote: > > On Fri, Jun 11, 2010 at 20:28, Jelmer Vernooij > <[email protected]> > > wrote: > > On Fri, Jun 11, 2010 at 07:26:31PM -0400, David > Borowitz > > wrote: > > > I'm a bit torn on this issue. On the one hand, I > agree that > > there are some > > > things like excludes that we can provide > well-defined APIs > > for rather than > > > depending on specific filenames. On the other > hand, there > > are two cases that > > > I think merit keeping get_named_file around: > > > 1. Allow users to read and parse files on their > own that > > Dulwich does not > > > (yet) have support for. (Presumably we would > encourage such > > users to > > > contribute their parsing code back to Dulwich > and/or > > transition to the > > > official API once one exists.) > > > > I don't have any objections against making it > possible for > > people to do > > this but I'd rather keep it optional, not a > requirement for > > the correct > > or full functioning. > > > What do you mean by the correct or full functioning? I was > referring > > to the fact that there are a lot of miscellaneous files that > can > > already live under .git (*_HEAD, RENAMED-REF, branches/*, > hooks/*, > > logs/*). If users of dulwich want to use these files before > we've > > developed APIs for them, I think we should let them. Yes, it > wouldn't > > work for non-disk-based Repos, but at least it would work in > the most > > common case. This is just about the transitional period, > until we > > provide first-class support for those features. > > I think we agree. Summarizing: These functions should be there > so people > can get at these files while we complete the functionality in > Dulwich > but only for that reason - not as the intended way of working > with these > files. Ideally these functions should not be used at all and > perhaps > eventually be removed. > Just to clarify, by "these functions" you mean get_named_file and > put_named_file, correct? Yep. > I agree that "ideally" we'd get rid of those, but I wouldn't rule out > the possibility that new repo files will get added to C git at a fast > enough pace that they're always a few steps ahead of dulwich, so > get_named_file may always be necessary. I hope we can catch up at some point. Once we do, keeping up with the pace with which new features in C Git are being added is doable I think. > It should be possible for implementations of the Repo > interface to not > provide these functions. If they need direct access to the > disk > representation perhaps they should bypass the Repo interface > altogether > or use an explicit wrapper on top of Repo to generate those > files on the > fly. > I'm not sure I follow this last point. IIUC, you're talking about what > I suggested earlier for web.py--use the (future) high-level Repo > functions to generate any necessary files on the fly according to the > URL requested. Right? What I meant was having a separate class that lives on top of Repo and can provide the required files. I.e. something that perhaps implements just get_named_file() and put_named_file() but rather than by talking to disk it would call out to methods on Repo. Cheers, Jelmer
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Mailing list: https://launchpad.net/~dulwich-users Post to : [email protected] Unsubscribe : https://launchpad.net/~dulwich-users More help : https://help.launchpad.net/ListHelp
