Right now, if cache/clone/PROJECT/ already exists,
the logic for pulling new changes doesn't execute,
and neither does the logic for updating remotes.
This is bad when updating revisions, because then
manual updating is required, defeating the purpose
of xbmk's own automation in this regard.
Fix it by only checking the cached download on files,
not Git repositories; the try_git function itself will
already perform this check, before updating remotes
and pulling in new commits from upstream.
The updating only happens when a given target directory
doesn't exist, e.g. src/flashprog/ or src/grub/default/,
so this won't slow down release builds for example.
Signed-off-by: Leah Rowe <leah@libreboot.org>
don't skip if the URL is empty. throw an error instead.
i decree that all links must be properly initialised, because
that is the design of lbmk. where only one link is provided,
such as in a local copy operation, the second would succeed no
better than the first so two identical paths are given.
Signed-off-by: Leah Rowe <leah@libreboot.org>
the intent once again is that this for loop shall
return, with zero status, if success is observed.
otherwise, the loop breaks and an error is thrown.
Signed-off-by: Leah Rowe <leah@libreboot.org>
The idea in this function is that if a file or repo is
successfully handled, a return will be performed from the
loop.
If the loop exits for any reason, an error is thrown. The
current code is probably fine, but I can forsee future
modifications possibly causing bugs here.
Make it unambiguous, by always throwing an error if execution
reaches the end of the function.
Signed-off-by: Leah Rowe <leah@libreboot.org>
the user doesn't care where the temporary git repo is
git shows that information anyway, in the git clone command
Signed-off-by: Leah Rowe <leah@libreboot.org>
we really only need it there, because the context is
for release archives. normal use of the git repository
doesn't matter in the context of deletions, because that
will not be distributed. only the result of ./mk release
will be distributed.
the builds produced will not change as a result of this,
for people using the normal git repository, because the
files in question are never used anyway, in our configs.
this is being done to make working on local repos easier.
Signed-off-by: Leah Rowe <leah@libreboot.org>
this is the mkdir call that createsn the directory where
a cached git repository is moved to, during creation.
Signed-off-by: Leah Rowe <leah@libreboot.org>
more specifically, re-write it so that it can be called with fx_
this means that the single-tree check for nuke.list can be made
much simpler
Signed-off-by: Leah Rowe <leah@libreboot.org>
This way, we can use x_ which will then print the command
that failed, if we need to debug future errors.
Signed-off-by: Leah Rowe <leah@libreboot.org>
I overlooked this in a previous patch. It doesn't really
matter, since we're operating on a file anyway, but it's
not correct.
Files should have rm -f on them, not rm -Rf, for deletion.
Signed-off-by: Leah Rowe <leah@libreboot.org>
We already do what the old code does in setcfg, by
virtue of the fact that the st variable is later
checked, after loading this config conditionally,
where the st variable is otherwise blank.
We can avoid the unnecessary work after loading
the config, by returning if the config is absent.
Signed-off-by: Leah Rowe <leah@libreboot.org>
We are calling xbmkget in the same way, whether it's
a subfile or subrepo.
Rename these variables to subcurl and subgit, so that we
can call xbmkget unconditionally.
Signed-off-by: Leah Rowe <leah@libreboot.org>
they were always re-downloading every time.
i've basically re-written most of xbmkget.
there was some erroneous conditions under which
it wrongly deleted the cached file, resulting in
it being downloaded again.
Signed-off-by: Leah Rowe <leah@libreboot.org>
it now handles more than just git, and i forsee
it handling even more in the future, e.g. rsync,
ftp, bittorrent.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Leah Rowe