On Tue, 26 Sep 2017 17:26:33 +0200 Michael Haggerty <mhag...@alum.mit.edu> wrote:
> Maybe naming has been discussed at length before, and I am jumping into > a long-settled topic. And admittedly this is bikeshedding. > > But I find these names obscure, even as a developer. And terms like this > will undoubtedly bleed into the UI and documentation, so it would be > good to put some effort into choosing the best names possible. Names are definitely not a long-settled topic. :-) I agree that naming is important, and thanks for your efforts. > I suppose that the term "promisor" comes from the computer science term > "promise" [1]. In that sense it is apt, because, say, a promisor object > is something that is known to be obtainable, but we don't have it yet. > > But from the user's point of view, I think this isn't a very > illuminating term. I think the user's mental model will be that there is > a distinguished remote repository that holds the project's entire > published history, and she has to remain connected to it for certain Git > operations to work [2]. Another interesting aspect of this remote is > that it has to be trusted never (well, almost never) to discard any > objects [3]. Yes, that is the mental model I have too. I think the ordinary meaning of the word "promise" works, though - you're not working completely on things you have, but you're working partly based on the guarantees (or promises) that this distinguished remote repository gives. > Personally I think "lazy remote" and "backing remote" are not too bad. I think these terms are imprecise. "Lazy remote" seems to me to imply that it is the remote that is lazy, not us. "Backing remote" does evoke the concept of a "backing store". For me, the ability to transfer objects to the backing store to be stored permanently (so that you don't have to store it yourself) is an essential part of a backing store, and that is definitely something we don't do here (although, admittedly, such a feature might be useful), so I don't agree with that term. But if transferring objects is not essential to a backing store, or if adding such a feature is a natural fit to the partial clone feature, maybe we could use that. > [2] I haven't checked whether the current proposal allows for > multiple "promisor remotes". It's certainly thinkable, if not > now then in the future. But I suppose that even then, 99% of > users will configure a single "promisor remote" for each > repository. It does not allow for multiple "promisor remotes". Support for that would require upgrades in the design (including knowing which remote to fetch a missing object from), but otherwise I agree with your statements.
