Michael Haggerty <mhag...@alum.mit.edu> writes: > A first weakness of your proposal is that even though the hidden refs > are (optionally) fetchable, there is *no* way to discover them remotely > or to bulk-download them; they would have to be retrieved one by one > using out-of-band information. And if I understand correctly, there > would be no way to push hidden references remotely (whether manually or > from some automated process). Such processes would have to be local to > the machine holding the repository.
I'm the author of git-fat [1], a smudge/clean filter system for managing large files. I currently store files in the file system (.git/fat/objects) and transfer them via rsync because I want to be able to transfer exact subsets requested by the user. I would like to put this data in a git repository so that I can take advantage of packfile compression when applicable and so that I can use existing access control, but I would need to store a separate reference to each blob (so that I can transfer exact subsets). My refs would be named like 'fat-<SHA1_OF_SMUDGED_DATA>' and are known on the client side because they are in the cleaned blob (which contains only this SHA1 and the number of bytes [2]). I believe that my use case would be well supported if git could push and pull unadvertised refs, as long as basic operations were not slowed down by the existence of a very large number of such refs. [1] https://github.com/jedbrown/git-fat [2] We could eliminate the performance problem of needing to buffer the entire file if the smudge filter could be passed the object size as an argument and if we could forward that size in a stream to 'git hash-object --stdin'. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
