RE: [RFE] Inverted sparseness
- From
Randall S. Becker <rsbecker@nexbridge.com>
- Date
- Dec 1, 2017, 18:31 UTC
- Message-ID
- <004701d36ad2$9a7fcea0$cf7f6be0$@nexbridge.com>
- In-Reply-To
- <bdd01692-198a-f5ec-3c88-7d99e4adced5@jeffhostetler.com>
On December 1, 2017 1:19 PM, Jeff Hostetler wrote:
Show 12 quoted lines
>On 12/1/2017 12:21 PM, Randall S. Becker wrote: >> 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).
>Perhaps I'm not understanding the subtleties of what you're describing, but could you do this with stock git functionality.
>Let the vendor publish a "well known branch" for the client. >Let the client pull that and build. >Let the client create a branch set to the same commit that they fetched. >Let the client push that branch as a client-specific branch to the vendor to indicate that that is the official release they are based on.
>Then the vendor would know the official commit that the client was using.
This is the easy part, and it doesn't require anything sparse to exist.
Show 5 quoted lines
>If the client makes local changes, does the vendor really need the SHA of those -- without the actual content? >I mean any SHA would do right? Perhaps let the client create a second client-specific branch (set to > the same commit as the first) to indicate they had mods. >Later, when the vendor needs the actual client changes, the client does a normal push to this 2nd client-specific branch at the vendor. >This would send everything that the client has done to the code since the official release.
What I should have added to the use-case was that there is a strong audit requirement (regulatory, actually) involved that the SHA is exact, immutable, and cannot be substitute or forged (one of the reasons git is in such high regard). So, no I can't arrange a fake SHA to represent a SHA to be named later. It SHA of the installed commit is part of the official record of what happened on the specific server, so I'm stuck with it.
>I'm not sure what you mean about "it is inside a tree".
m---a---b---c---H1
`---d---H2d would be at a head. b would be inside. Determining content of c is problematic if b is sparse, so I'm really unsure that any of this is possible.
Cheers, Randall
-- Brief whoami: NonStop&UNIX developer since approximately UNIX(421664400)/NonStop(211288444200000000) -- In my real life, I talk too much.