dulwich-users team mailing list archive

[Jelmer Vernooij <jelmer@xxxxxxxxx>]

Whoops, I had forgotten about this email.

On Fri, 2010-06-11 at 20:55 -0400, David Borowitz wrote:
> On Fri, Jun 11, 2010 at 20:28, Jelmer Vernooij <jelmer@xxxxxxxxx>
> 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.

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.

Does that match what you had in mind?

Cheers,

Jelmer

Attachment: signature.asc
Description: This is a digitally signed message part