| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Remove the special case hacks we had and do a proper comparison
between original and new in-memory dict when writing updates to
user morphologies.
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously the code would edit strata that dependended on the stratum
being edited, but would ignore the dependency chain beyond that. In
fact, we need to edit all strata in the dependency chain to avoid
having two different versions of a stratum in the same build.
This splits the modification into two steps: changing the stratum that
points to the chunk, and recursively changing references to any strata
that have been altered.
|
|\ \
| | |
| | |
| | | |
git://git.baserock.org/baserock/baserock/morph
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This adds a new optional field to system morphologies:
"configuration-extensions".
The deployment plugin relies heavily on code from the branch and
merge plugin. This needs to be eventually fixed by refactoring
the codebase so that the shared code is in morphlib and not in
plugins. However, doing that is beyond the scope of adding a
deployment plugin.
|
| |
| |
| |
| |
| |
| | |
Branch from image takes a directory containing metadata, then creates
a branch of what the System was built from and petrifies it to when
the System was built.
|
| | |
|
|/
|
|
|
|
|
|
| |
Pass resolved_refs in with the key as a repo, ref pair to petrify
to the value, rather than petrifying to the current state of the ref.
Set update_working_tree to also change files in the working tree,
instead of just the index.
|
|\ |
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before it would determine which files are changed by comparing your
working tree to
This gets even weirder, since it's effectively comparing your working
tree, the last commit on the temporary build ref, and the last commit
of your HEAD, so committing a change to remove a file isn't noticed,
because it was in the temporary build branch.
It could also cause a strange case of a file being both added and
untracked.
Now the working tree and HEAD are compared, and committed on top of
the temporary build ref.
Better handling of the status output is still required, a deleted
file is treated identically to an added one if it is only removed
in the index.
It would also be nicer to keep the user's index, since they may have
added or removed files from it.
|
|\
| |
| |
| | |
Fixed a copyright year to make ./check happy.
|
|/
|
|
|
|
|
|
| |
glob.glob() can return results in any order. In practice it varies
at least according to the file system being used. This means that test
results may be different. To avoid this, we should always use
sorted(glob.iglob()) instead, so that the code always behaves in the
same way given the same inputs.
|
| |
|
|
|
|
|
|
|
| |
The code took some refactoring. The core functionality is now all inside
one function with make_available() separate, as this is used other places.
The code is still far from perfect, but will hopefully be rewritten to
use the new abstractions of system branches etc. soon
|
|
|
|
|
|
|
|
|
|
|
| |
The committer information in the environment used to run git in morph
tag is not needed. In morph build it makes sense as morph commits without
the user knowing. With morph tag, it's the user that decides to create
the commit and tag.
There is something weird going on, where morph tag may end up generating
commits with different SHA1s on different machines. The full log output
in the morph tag tests might help investigate what happens.
|
|\
| |
| |
| | |
into baserock/merge-queue
|
| |
| |
| |
| |
| | |
This was done to ensure tests.branching/branch-fails-if-branch-exists
always passes, but also seems like the right approach in general.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously some code used `git show-ref`, which is wrong -- given two
refs named 'alpha/master' and 'master', `git show-ref master` will
return both, sorted alphabetically. This can lead to build failures,
etc. due to refs resolving to the wrong SHAs.
We should also use `git rev-parse --verify` to verify SHA1s, which
we previously did with `git rev-list`.
Finally, `git rev-parse --verify` is more than twice as fast as
`git show-ref`.
|
| | |
|
|\ \
| |/
|/| |
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In order to make releases and freeze system branches entirely, we
need to be able to 100% petrify a system branch (that is, resolve
ALL refs into SHA1s) and tag this state to be able to check it out
again later.
This is essentially what "morph tag" does. It takes a tag name
and an arbitrary amount of arguments to "git tag", petrifies all
morphologies of the current system branch behind the scenes, creates
a dangling commit and attaches an annotated tag to it.
Petrifying in this case means that all refs used for chunks are
resolved into commit SHA1s. For stratum and system morphologies,
the refs are replaced by the name of the tag that's being created.
The "tag" command also supports tagging when stratum morphologies
are spread across multiple repositories. In this case, it will
include all statum morphologies from other repos in the tag commi
in the branch root repo. The references to these morphologies are
updated so that they point to the branch root repo and the tag
being created.
This commit also adds a few tests for "morph tag" to verify that
all this works.
|
|\
| |
| |
| | |
git://git.baserock.org/baserock/morph
|
| |
| |
| |
| |
| | |
This is for users who prefer the old behaviour of building from the
remote repos.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This means that Morph no longer requires changes to be pushed in order
to build them.
The repos from the system branch are currently cached in the local
repo cache as part of the build process, which is far from ideal.
Tests for 'morph build' now test build without push. The build
metadata now includes a repo path that is inside the TMPDIR, so the
tests have been rewritten to avoid having any hardcoded cache keys
because the cache keys are no longer static.
|
| | |
|
|/ |
|
|
|
|
|
|
|
|
|
|
|
| |
The test tests.merging/rename-stratum could potentially trigger two
different errors in Morph, based on the order that the systems in the
root repo were processed.
This meant that the test would sometimes spuriously fail if TMPDIR
was manually set, because of differences in the way file systems work.
To fix the root cause requires proper 3-way merging, really.
|
|
|
|
|
|
| |
BranchAndMergePlugin.load_morphology() would crash if a parse error
occurred while reading a morphology from a specific revision in git,
instead of from on disk.
|
|
|
|
|
| |
Make sure all commands have one line of description, and reduce the
size of some which had large amounts of text.
|
|\
| |
| |
| | |
Reviewed-By: Richard Maw <richard.maw@codethink.co.uk>
|
| |
| |
| |
| |
| | |
Output needs to be stable, not least so that the test doesn't fail
sporadically.
|
|\ \
| |/
|/|
| | |
git://git.baserock.org/baserock/morph
|
|/
|
|
|
|
|
|
|
|
|
|
|
| |
This change causes 'morph petrify' to avoid petrifying any chunk whose
ref matches the current system branch, because it makes no sense to
petrify something that is also being edited. It also improves efficiency
slightly and adds warning where different systems point to different
refs of the same stratum.
A non-obvious effect of this is that if you try to petrify 'master',
many of the chunks won't get petrified because they are built from
'master'. However, petrifying master makes no sense so I'm not sure
that we need to worry.
|
|
|
|
|
|
|
|
| |
Previously if the user had renamed the directory holding the root
repository, the commands would break tragically.
Also fix find_repository() to avoid aborting if it encounters a git
repo in the branch checkout that wasn't put there by Morph.
|
| |
|
|
|
|
| |
This provides a user-friendly summary of the workspace or branch status.
|
|
|
|
|
| |
Users do not need these now due to 'morph status' existing. However, they
are still useful for scripts to call.
|
|\
| |
| |
| |
| |
| | |
'origin/samthursfield/S4873-warn-when-merge-causes-petrification'
Renamed petrification test slightly as merge fixup.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The concept of a component path is new. This is simply a concise way
of referring to a component in an error message, and looks like this:
base-system-x86_64-generic.bsp-x86_64-generic.linux
We currently only touch the 'edited chunks' in merge_stratum(), i.e.
those in the FROM branch where 'morph edit' was run. However, the
petrification can affect any chunk so there is a new method added to
obtain all components in a morphology. This function also returns the
differences between the two, which we will make use of at a later date.
|
| | |
|
| | |
|
|/ |
|
|
|
|
|
|
|
|
|
|
| |
This should not normally be used, because we make no attempt to detect
when a full URL and a keyed URL are equivalent, so they cannot be used
interchangably.
However, 'foreach' would previously fail completely if the branch root
happened to be a full URL because it didn't call convert_uri_to_path()
correctly.
|
|
|
|
|
| |
Reviewed-By: Daniel Silverstone (on irc)
Reviewed-By: Richard Maw (on irc)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We often have .gitmodules edited to contain a URI such as
upstream:gnulib, so that we can transparently mirror these in different
locations.
It would be nice to set up git url.insteadOf rules to expand these for
the submodules, but 'git submodule update' uses 'git clone' to fetch
them, which will not take into account the configuration of the
parent repository.
Instead, we set up the submodules automatically and rewrite the URLs
directly in the configuration. The user will need to recreate their
system branch checkouts if their URL configuration changes, or update
the URLs manually, but that should not happen often.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Upsides:
- clearer error messages on conflicts (we no longer dump the git
output)
- merge base is available during morphology merging
- we no longer need to go through the complexity of implementing a
git merge driver
We now manually fetch and then merge, instead of using git pull. This
is not strictly necessary, but it makes it clearer in the code how
FETCH_HEAD is involved in the process.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The origin/ refs in the system branch checkout repos may or may not be
up to date, and may or may not have been tampered with by the user.
Much better to use our central cache for everything other than changes
to the system branch ref itself, where we should indeed be honouring
the user's local changes.
At a later date we could warn if the user modifies refs other than
the system branch ref but does not push, as these changes will have no
effect.
NOTE: this commit breaks 'morph merge'. It is fixed in the next commit.
|
|
|
|
|
|
|
|
|
|
| |
The rationale here is that inside a checkout of a system branch, the
user should only be committing to the refs for that system branch,
because those are the only ones that 'morph merge' will look at.
This removes a problem where we could be confused by a ref with a
name that would be sorted before 'master' in the result of 'git
show-ref'.
|