kaihendry
commented
11 years ago I think github can get fussy, when we have something it doesn't have.
root@webconverger:/live/image/live/filesystem.git# git fetch -vvv origin systemd
Server supports multi_ack_detailed
Server supports side-band-64k
Server supports ofs-delta
want 2372a2919bd4fd8057a5cc69761e84377eae240e (refs/heads/systemd)
have 1721229a6fadf2b83c05fa3d1cbe88d8904f033d
have 9d9ee71f1cd9bd765f1b79f78396ff5fe5b9333c
done
fatal: The remote end hung up unexpectedly
When an image is created using revision foo, and you tell the image to downgrade to foo^ (the parent of foo), it will start to download the entire history of the repository, because it does not have any (grand...)parent commit for the commit you're downgrading to.
This means that downgrading to a commit that you never upgraded from (e.g., downgrading past your starting point) will currently always download the entire history.
I'm afraid we can't really detect this case using the git commandline.
What we could do, is pass --depth=x to the git fetch call. This should limit the number of parent commits it will fetch. I think that if there are less than x commits between the current revision and the revision-to-upgrade-to, it will just download those. If there are more commits, or if there is no common ancestor as described above, it will download exactly x commits and create a new shallow root commit as as starting point.
A question is, what value should x have. Some value like "10" make sense, since it will download the history in most cases, but guards against downloading the entire history in the no-common-ancestor case.
At first glance, it looks like there is a risk of doubling the repository size whenever more than 10 commits need to be downloaded, since a completely new history (starting with the shallow root) is created. However, AFAIU, the shallow root commit does not contain a completely separate tree, but can point to the same git objects (using their hash ids) as the commits in separate histories (as long as the files themselves didn't change). So I expect that there will be no (big) performance impact from having multiple shallow root commits.
Having said that, it might make sense to choose a value of 1 (or 0?) for x. This would mean that on every upgrade (except when there is only one or two commits to fetch), a new shallow root will be created and the git repository essentially stores no history (that is, it still keeps all of the revisions it has previously ran and downgrading to them is free, but there is no connection between these previous revisions and the revisions between them are also not stored).