Michael Haggerty writes:
> If I understand correctly, you consider the decision of where a
> particular reference should be stored to be a kind of "business logic"
> decision that should live outside of the refs module. I don't think it
> is so important whether this knowledge is inside or outsid
On Sun, Aug 16, 2015 at 12:04 PM, David Turner wrote:
> Duy Nguyen writes:
>> On Thu, Aug 13, 2015 at 4:57 AM, David Turner
> wrote:
>> > Instead of a linear search over common_list to check whether
>> > a path is common, use a trie. The trie search operates on
>> > path prefixes, and handles e
Duy Nguyen writes:
> On Thu, Aug 13, 2015 at 4:57 AM, David Turner
wrote:
> > Instead of a linear search over common_list to check whether
> > a path is common, use a trie. The trie search operates on
> > path prefixes, and handles excludes.
>
> Just be careful that the given key from git_path
On 08/14/2015 10:04 PM, David Turner wrote:
> On Fri, 2015-08-14 at 10:04 -0700, Junio C Hamano wrote:
>> [...]
>> So I think we should have *three* functions:
>>
>> - git_workspace_name(void) returns some name that uniquely
>>identifies the current workspace among the workspaces linked to
>>
On 08/14/2015 07:04 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> Let's take a step back.
>>
>> We have always had a ton of code that uses `git_path()` and friends to
>> convert abstract things into filesystem paths. Let's take the
>> reference-handling code as an example:
>> ...
>> T
On Thu, Aug 13, 2015 at 4:57 AM, David Turner wrote:
> Instead of a linear search over common_list to check whether
> a path is common, use a trie. The trie search operates on
> path prefixes, and handles excludes.
Just be careful that the given key from git_path is not normalized. I
think you a
On Fri, 2015-08-14 at 13:27 -0700, Junio C Hamano wrote:
> David Turner writes:
>
> > Random side note: the present workspace path name component is not
> > acceptable for this if alternate ref backends use a single db for
> > storage across all workspaces. That's because you might create a
> >
David Turner writes:
> Random side note: the present workspace path name component is not
> acceptable for this if alternate ref backends use a single db for
> storage across all workspaces. That's because you might create a
> workspace at foo, then manually rm -r it, and then create a new one a
On Fri, 2015-08-14 at 10:04 -0700, Junio C Hamano wrote:
> Michael Haggerty writes:
>
> > Let's take a step back.
> >
> > We have always had a ton of code that uses `git_path()` and friends to
> > convert abstract things into filesystem paths. Let's take the
> > reference-handling code as an exam
Michael Haggerty writes:
> Let's take a step back.
>
> We have always had a ton of code that uses `git_path()` and friends to
> convert abstract things into filesystem paths. Let's take the
> reference-handling code as an example:
> ...
> This seems crazy to me. It is the *reference* code that sh
On 08/12/2015 11:57 PM, David Turner wrote:
> Instead of a linear search over common_list to check whether
> a path is common, use a trie. The trie search operates on
> path prefixes, and handles excludes.
>
> Signed-off-by: David Turner
> ---
>
> Probably overkill, but maybe we could later use
David Turner writes:
> Instead of a linear search over common_list to check whether
> a path is common, use a trie. The trie search operates on
> path prefixes, and handles excludes.
>
> Signed-off-by: David Turner
> ---
>
> Probably overkill, but maybe we could later use it for making exclude
Instead of a linear search over common_list to check whether
a path is common, use a trie. The trie search operates on
path prefixes, and handles excludes.
Signed-off-by: David Turner
---
Probably overkill, but maybe we could later use it for making exclude
or sparse-checkout matching faster (o
13 matches
Mail list logo
