| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We assumed that the sha1 of the tree of the commit of the ref we care
about was sufficient to cache, but `git replace` means that you need to
know the state of other branches too, since anything in refs/replace can
completely change what the tree you check-out is.
This behaviour can be disabled globally by setting
GIT_NO_REPLACE_OBJECTS, so we're going to do that.
If we need to integrate a project that uses git-replace to change the
contents of their git trees then we could support that by:
if any(refs/replace/*):
potentially_replacable_objects = [
`git rev-parse HEAD`,
`git rev-parse HEAD^{commit}`,
`git rev-parse HEAD^{tree}`]
potentially_replacable_objects.extend(
`git ls-tree -r HEAD | awk '{print $3}'`)
# NOTE: doesn't handle submodules, and you'd need to expand this
# set whenever you process a replacement
for object in refs/replace/*:
if basename(object) not in potentially_replacable_objects: continue
cache_key['replacements'][basename(object)] = `git rev-parse $object`
If we were to support this would need to traverse the tree anyway, doing
replacements, so we may as well use libgit to do the checkout anyway,
and list which replacements were used.
However, since the expected use-case of `git replace` is as a better way
to do history grafting, we're unlikely to need it, as it would only have
any effect if it replaced the commit we were using with a different one.
Rubber-stamped-by: Daniel Silverstone
|
| |
|
|
|
|
|
|
|
| |
The help for the show-branch-root command said it returns a path, but
the command and the yarns just showed the aliased url it was cloned
from.
Given I found myself needing the path in some scripts, not the repo url,
I think it's more useful to reconcile the difference this way.
|
| |
|
|
|
|
|
|
|
|
|
| |
This was noticed because our definitions.git had a dangling symlink,
so it failed to construct the temporary build branch.
We shouldn't process symlinks as morphologies either, since either we
make symlinked morphologies a first-class behaviour, and validate that
the link points inside the repository, which is a lot of work for
something we don't and probably won't need; or we can just assume that
we deal with the morphology this is linked to correctly anyway.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We want to use file paths to locate morphologies now, so the old model
of get a list of names and hand it those back to get the contents
doesn't really make sense any more.
This abstraction initially came about as one idea I had for moving
morphologies out of the source tree was to put them in something like
git notes, where it's possible to look up information for one commit in
another ref in the repository, at which point this abstraction would
have been flexible enough to handle that as well as in the
However, moving the chunk morphologies into the definitions repository
has other benefits too, so it makes more sense to be honest about using
filenames in the API.
It remains as a single point where we can put the logic for knowing which
files in a repository look like morphologies, but if we need to remove
any further functionality, it should be replaced by a single function.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was previously a private method of the branch and merge
plugin, but it's useful to other plugins, so has been moved to the
SystemBranchDirectory class, where everything else can get to it.
It has an unpleasant amount of coupling to other classes, but in a *good*
object oriented design it would either be a tiny module on its own,
or not exist and leave all its users to re-implement the same logic
multiple ways, so we've opted for a less clean, but more useful design.
It is left un-covered by the unit tests, since it requires a great deal
of instrumentation to test, at which point it may be best to leave it
to integration tests.
|
| |
|
|
| |
Operations on remotes are now accessed through this proxy object.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The workspace needs to be able to list all its system branches, and the
system branches need to be able to list all their git repositories.
This is broadly the same thing, just with a different directory to look
out for, so provide that utility in morphlib.util.
find_leaf() is rewritten to use find_leaves(), this is less efficient
since it waits until every leaf is found.
I felt it was better to reduce the code than maintain a slightly more
optimal algorithm.
The find_leaf() algorithm could become more optimal if it could lazily
check for at least one result in a generator.
|
| |
|
|
| |
There's a built-in function to do this.
|
| |
|
|
|
|
|
| |
This is necessary because a relative pathname may become invalid,
if the current working directory changes, either in Morph itself,
of when Morph invokes a subprocess and gives the pathname to the
system branch root directory to it.
|
| | |
|
| |
|
|
|
| |
For some reason, there was an unused argument in the method. Remove it
from the definition and all call sites.
|
| |
|
