Using 2 of the above answers (How to clone git repository with specific revision/changeset? and How to clone git repository with specific revision/changeset?)
Helped me to come up with a definative. If you want to clone up to a point, then that point has to be a tag/branch not simply an SHA or the FETCH_HEAD gets confused. Following the git fetch set, if you use a branch or tag name, you get a response, if you simply use an SHA-1 you get not response.
Here's what I did:-
create a full working clone of the full repo, from the actual origin
cd <path to create repo>
git clone git@<our gitlab server>:ui-developers/ui.git
Then create a local branch, at the point that's interesting
git checkout 2050c8829c67f04b0db81e6247bb589c950afb14
git checkout -b origin_point
Then create my new blank repo, with my local copy as its origin
cd <path to create repo>
mkdir reduced-repo
cd reduced-repo
git init
git remote add local_copy <path to create repo>/ui
git fetch local_copy origin_point
At that point I got this response. I note it because if you use a SHA-1 in place of the branch above, nothing happens, so the response, means it worked
/var/www/html/ui-hacking$ git fetch local_copy origin_point remote: Counting objects: 45493, done. remote: Compressing objects: 100% (15928/15928), done. remote: Total 45493 (delta 27508), reused 45387 (delta 27463) Receiving objects: 100% (45493/45493), 53.64 MiB | 50.59 MiB/s, done. Resolving deltas: 100% (27508/27508), done. From /var/www/html/ui * branch origin_point -> FETCH_HEAD * [new branch] origin_point -> origin/origin_point
Now in my case, I then needed to put that back onto gitlab, as a fresh repo so I did
git remote add origin git@<our gitlab server>:ui-developers/new-ui.git
Which meant I could rebuild my repo from the origin_point by using git --git-dir=../ui/.git format-patch -k -1 --stdout <sha1> | git am -3 -k
to cherry pick remotely then use git push origin
to upload the whole lot back to its new home.
Hope that helps someone