Короткий ответ: вы не можете, не совсем.В то время как git push выдвигает / загружает различные объекты Git, это заканчивается установкой одного или нескольких имен в другом хранилище Git.Получающий Git затем имеет тенденцию запускать git gc сразу после этого.
В частности, you run:
git push <em>remote</em> <em>refspec1 refspec2 ... refspecN</em>
в командной строкеи ваш Git вызывает другой Git по номеру remote (например, по URL-адресу, взятому из remote.<em>remote</em>.pushurl).Затем ваш Git доставляет в свой Git объекты, идентифицированные исходными частями каждой из ваших refspecs, или, точнее, предлагает им эти объекты по хеш-идентификатору.Вы можете поставить здесь хэш-идентификаторы:
git push origin a123456:name
a123456 - это сокращенный хэш-идентификатор.Какой бы объект ни называл, ваш Git предложит свой полный хэш-идентификатор другому Git.Затем другой Git проверит, есть ли у него объект a123456.Если это так, он говорит вам, что ему не нужно фактическое содержание;если нет, ваш Git упакует содержимое, и теперь должен предлагать любой объект, который также требуется a123456.Например, если a123456 - это коммит, ваш Git должен предложить свое дерево и родительские коммиты;другой Git сообщает вам, есть ли они у них уже или нужны, что вызывает еще большее следование объектам по мере необходимости.(Здесь есть несколько оптимизаций для сокращения обратной и обратной связи, но идея должна быть ясна к этому моменту.)
В конце концов, ваш Git и их Git соглашаются, что если ваш Git отправит некоторый наборобъектов, они будут иметь все объекты, которые им нужны, чтобы принять (или отклонить!) ваш Git установить некоторые имена запрос.Затем ваш Git упаковывает эти объекты, как правило, в thin pack , в котором хранятся эти объекты, но дельта-сжатые по отношению к объектам, которые ваш Git знает или предполагает, что * Git уже имеет их Git на основе более ранних версий.иметь / хотеть диалог объекта-хеш-идентификатора, который привел к этой точке.(Например, если вы предложили a1234356, и они сказали, что им это нужно, то вы предложили его родителю a000000, и они сказали ах, у меня уже есть тот , ваш Git знает, что они не только имеютсам объект a000000, но также и его дерево и все его BLOB-объекты. Более того, если их хранилище не мелкое, они имеют все a000000 ' parent коммитов и все их деревьев и BLOB-объектов! Таким образом, ваш Git может сжимать a123456 BLOB-объектов против всех таких более ранних BLOB-объектов, чтобы создать этот тонкий пакет. Он может полностью исключить любые BLOB-объекты в a123456, которые также находятся в a000000,и так далее.)
После того, как ваш Git отправил тонкую пачку, другая сторона исправит ее (откормит и добавит индекс).Теперь они принимают набор запросов вашего Git в форме: , пожалуйста, установите на (без принудительного нажатия) или то же самое без , пожалуйста, (принудительное нажатие).Если вы запустили git push origin a123456:name, этот запрос говорит , установите name в a123456.
Они либо подчиняются запросу / команде, либо отклоняют ее.Если они отклонят это, то a123456 - который вы только что отправили - вполне вероятно, не достижимо из любой из их других ссылок!(Единственный случай, когда это происходит, - это когда что-то еще в том же наборе или обновило некоторую другую ссылку, чтобы сделать a123456 достижимым.)
Когда разговор заканчивается, после всех ваших установите на операций, они запустят git gc.Если отправленные вами объекты были потерянными объектами, эти объекты были бы защищены по умолчанию 14-дневным льготным периодом.Но вы отправили им файл пакета.Если они упакуют файл пакета, включив в него объекты, которые они собираются сохранить - и они почти всегда так делают - они уронят любой объект, на который нет ссылок.
Это приводит к несколько печальному выводуэто составляет первое предложение этого ответа.