Shallow clones only contain the ref that was cloned, and so if a
mirror is shallow and the ref is changed in a subsequent invocation of
builder, the new ref is absent and git fails with an error.
This patch avoids bailing out too soon when mirroring a repo if the
requested ref does not exist, to ensure it is fetched.
Fixes#285Closes: #286
Approved by: alexlarsson
This way, if anything fails during the initial pull we can remove it
and not be confused by a partial repo on the next run.
Closes: #98
Approved by: alexlarsson
Rather than dropping the error on the floor entirely.
Coverity CID: #208384
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Closes: #74
Approved by: alexlarsson
If we're bundling sources we really need to fetch from them because
we want to bundle shallow clones. However, this doesn't work for older
git versions, so pre-emptively fetch those deeply.
Closes: #62
Approved by: alexlarsson
Fetching from shallow clones was added in 1.9.0, so we do deep
clones of submodule repos before that to ensure submodule update
works.
Closes: #62
Approved by: alexlarsson
Older versions of git default to only tags when you do --tags instead
of tags + all. So, we force everything with --tags *:*.
Closes: #62
Approved by: alexlarsson
When pulling the commit we need to also pull the tags so we have them
locally, and then we need to peel the ref when we commit it so that we
don't try to create a ref pointing to a non-commit (tag) object.
Closes: #62
Approved by: alexlarsson
The git 1.8.3.2 release notes say:
* Cloning with "git clone --depth N" while fetch.fsckobjects (or
transfer.fsckobjects) is set to true did not tell the cut-off
points of the shallow history to the process that validates the
objects and the history received, causing the validation to fail.
So, on versions prior to this, we always disable fsck when you're
pulling shallowly. If you need fsck validation, use a newer git.
It turns out older versions of git cannot properly check out a commit
if the ref that points to it was not a normal one (branch or tag).
So, we work around this case by detecting it add adding a fake
tag. Also, we change the fake ref we use for commit-only references
to be a regular branch and not a special one for the same reason.
This fixes https://github.com/flatpak/flatpak/issues/1133Closes: #52
Approved by: alexlarsson
Some manifest (cx.ring.RingGnome) had a git commit id that
was only tip of a non-branch ref (refs/changes/51/8051/8), which
was not cloned by a regular clone, so we need to switch to
a clone --mirror.
Closes: #50
Approved by: alexlarsson
When downloading a git repo we try to do a shallow (depth=1) fetch of
only the specified target. This normally works fine for branches and
tags, but if the commit is a raw SHA1 then it fails, because we can
only request refs from the remote.
We handle this by doing an ls-remote and seeing if the specified
target is either a (possilby partial) ref, or a commit id that a
remote ref is pointing at. If it is, we pull that ref only. If not,
then we fall back to a full fetch.
I believe this is the best we can do to fix
https://github.com/flatpak/flatpak-builder/issues/6Closes: #47
Approved by: alexlarsson
When doing a shallow clone when bundling git sources we sometimes need
to create a ref in the source repo. This changes the ref used from
refs/heads/flatpak-builder/ref-$REF to refs/flatpak/ref-$REF.
In other words, it uses a custom ref rather than a branch, which has
less chance of conflicting with some existing branch.
Closes: #47
Approved by: alexlarsson
It seems we have to specify
git fetch --depth 1 origin $ref:$ref
instead of
git fetch --depth 1 origin $ref
because on older versions of git (1.8.3 at least) this otherwise just
sets FETCH_HEAD, rather than $ref in the fetching repo.
There is no need to bundle the entire history in a git repo.
Instead we only bundle shallow versions of all the branches/tags/commit
that we reference.
For directly specified commit ids we can't really shallow-clone those,
so we create fake tags in the mirrored repo.
Michael Gratton