From: "Randall S. Becker" <rsbecker@nexbridge.com>
To: "'Jeff Hostetler'" <git@jeffhostetler.com>, <git@vger.kernel.org>
Subject: RE: [RFE] Inverted sparseness
Date: Fri, 1 Dec 2017 13:31:23 -0500 [thread overview]
Message-ID: <004701d36ad2$9a7fcea0$cf7f6be0$@nexbridge.com> (raw)
In-Reply-To: <bdd01692-198a-f5ec-3c88-7d99e4adced5@jeffhostetler.com>
On December 1, 2017 1:19 PM, Jeff Hostetler wrote:
>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.
>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---H2
d 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.
next prev parent reply other threads:[~2017-12-01 18:31 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-01 17:21 [RFE] Inverted sparseness Randall S. Becker
2017-12-01 18:19 ` Jeff Hostetler
2017-12-01 18:31 ` Randall S. Becker [this message]
2017-12-03 23:14 ` Philip Oakley
2017-12-03 23:44 ` Randall S. Becker
2017-12-04 11:54 ` Philip Oakley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='004701d36ad2$9a7fcea0$cf7f6be0$@nexbridge.com' \
--to=rsbecker@nexbridge.com \
--cc=git@jeffhostetler.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).