Michael Haggerty mhag...@alum.mit.edu 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
On Sun, Aug 16, 2015 at 12:04 PM, David Turner dtur...@twopensource.com wrote:
Duy Nguyen pclo...@gmail.com writes:
On Thu, Aug 13, 2015 at 4:57 AM, David Turner dtur...@twopensource.com
wrote:
Instead of a linear search over common_list to check whether
a path is common, use a trie. The
Duy Nguyen pclo...@gmail.com writes:
On Thu, Aug 13, 2015 at 4:57 AM, David Turner dtur...@twopensource.com
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
On Thu, Aug 13, 2015 at 4:57 AM, David Turner dtur...@twopensource.com 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
On 08/14/2015 07:04 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu 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:
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
the same
David Turner dtur...@twopensource.com 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
On Fri, 2015-08-14 at 10:04 -0700, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu 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
Michael Haggerty mhag...@alum.mit.edu 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
On Fri, 2015-08-14 at 13:27 -0700, Junio C Hamano wrote:
David Turner dtur...@twopensource.com 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
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 dtur...@twopensource.com
---
Probably overkill, but maybe
David Turner dtur...@twopensource.com 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 dtur...@twopensource.com
---
Probably overkill, but maybe
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 dtur...@twopensource.com
---
Probably overkill, but maybe we could later use it for making exclude
or
13 matches
Mail list logo
