I recently encountered a really strange use-case relating to sparse clone/fetch
that is really backwards from the discussion that has been going on, and well,
I'm a bit embarrassed to bring it up, but I have no good solution including
building a separate data store that will end up inconsistent with repositories
(a bad solution). The use-case is as follows:
Given a backbone of multiple git repositories spread across an organization
with a server farm and upstream vendors.
The vendor delivers code by having the client perform git pull into a specific
branch.
The customer may take the code as is or merge in customizations.
The vendor wants to know exactly what commit of theirs is installed on each
server, in near real time.
The customer is willing to push the commit-ish to the vendor's upstream repo
but does not want, by default, to share the actual commit contents for security
reasons.
Realistically, the vendor needs to know that their own commit id was
put somewhere (process exists to track this, so not part of the use-case) and
whether there is a subsequent commit contributed by the customer, but the
content is not relevant initially.
After some time, the vendor may request the commit contents from the customer
in order to satisfy support requirements - a.k.a. a defect was found but has to
be resolved.
The customer would then perform a deeper push that looks a lot like a
"slightly" symmetrical operation of a deep fetch following a prior sparse fetch
to supply the vendor with the specific commit(s).
This is not hard to realize if the sparse commit is HEAD on a branch, but if
its inside a tree, well, I don't even know where to start. To self-deprecate,
this is likely a bad idea, but it has come up a few times.
Thoughts? Nasty Remarks?
Randall
-- Brief whoami: NonStop&UNIX developer since approximately
UNIX(421664400)/NonStop(211288444200000000)
-- In my real life, I talk too much.
