Facebook пишет свой Mercurial сервер на Rust

Но зачем?

Когда коту делать нечего... Git ведь уже написан!

Круто-круто. Опенсорс?

It looks like official support forPython 3 support will happen sometime in 2017.

Вот это покруче новость.

react, bower, graphQL, yarn, теперь это.

Тот случай когда открытие исходников вредит сообществу нежели приносит пользу

Но ведь 1) Git говно, и 2) Facebook его не использует.

Интересно, кто primary author.

cast val-amart

Git ведь уже написан!

Обычно самая хреновая технология побеждает, да.

23:20:31

/me посмотрел на часы

08.05

LADNO

Когда гит начнет хоть както уметь ворочать отдельными директориями, тогда от него будет какая то польза... а пока народ сливает гиговые репы ради одного файлика и радостно жрет что ему дают, аргументируя что «сам Линус его использует»

> will support pluggable key-value stores for storage
Но зачем?

Чтобы можно было организовать центральное хранилище без обязательной многоэтажной свалки мелких файлов. Это даст возможность хранить репу внутри облачных БД или на сетевых ФС, например.

google://«sparse checkout»

И что? Это очередной костыль, все равно сливается вся репа... сравни .git размер и объем скаченого на полном clone и на sparse checkout...

как только придет осмысление, как устроет distributed, то сразу отпустит. если уж сильно подгорает, то можно так:

git archive --format=tar --remote=git://git.foo.com/project.git HEAD:path/to/directory filename | tar -O -xf -

как только придет осмысление, как устроет distributed

В данном случае это только обозначает что он ущербный по дизайну и отмазка против всего того, что не укладывается в его структуру и принципы. Так что я только за, если товарищам удастся имплементировать то, о чем написано в топике. тогда и гитокапец может настанет потихоньку

Реализация топика не даст тебе того, что ты хочешь.

В данном случае это только обозначает что он ущербный по дизайну и отмазка против всего того, что не укладывается в его структуру и принципы. Так что я только за, если товарищам удастся имплементировать то, о чем написано в топике. тогда и гитокапец может настанет потихоньку

Мб может проще Git зопатчить, чем опять все ломать? Серьезно, каждый раз начинается «давайте нахрем сломаем все и в этот-то раз сделаем нормально». В итоге как только все более-менее утряслось вылезает новый упырь и поехало.

«enabling sub-directories to be `git clone`d independently of a large repo. This means you could use Mercurial to back your monorepo while still providing the illusion of multiple «sub-repos» to Mercurial or Git clients» както так пишут...

Мб может проще Git зопатчить

Зачем патчить ущербное? к тому же там проблема в дизайне и структуре хранения данных репы...

Зачем патчить ущербное? к тому же там проблема в дизайне и структуре хранения данных репы...

Вот-вот. И так каждый раз.

Мб может проще Git зопатчить, чем опять все ломать? Серьезно, каждый раз начинается «давайте нахрем сломаем все и в этот-то раз сделаем нормально».

Вот-вот. И так каждый раз.

Иногда полезно всё сломать и начать заново.

X.Org, к примеру, так и не могут «запатчить» из-за общей сложности кодовой базы и упоротости X.org-разработчиков, которые сами не понимают как у них там работают отдельные подсистемы. Потому всё ломают, выбрасывают на помойку и делают Wayland, Mir, Freon и прочее.

Git плох, например, тем, что не может в ту же докачку после обрыва. Из-за этого на слабых интернет-соединениях им пользоваться практически невозможно.

Ещё он не поддерживает добавления в себя пустых директорий. Добавлять туда файлики .blank — жуткий костыль. А создать предварительную структуру каталогов на этапе планирования и проектирования проекта бывает очень важным.

Git плох, например, тем, что не может в ту же докачку после обрыва. Из-за этого на слабых интернет-соединениях им пользоваться практически невозможно.

И это, конечно же, очень сложно поправить запатчив Git.

Ещё он не поддерживает добавления в себя пустых директорий. Добавлять туда файлики .blank — жуткий костыль. А создать предварительную структуру каталогов на этапе планирования и проектирования проекта бывает очень важным.

Пфф.

Не видел таких патчей на Git. Не подскажешь где взять?

Не видел таких патчей на Git. Не подскажешь где взять?

Я тоже не видел. Потому что их никто не написал.

И это, конечно же, очень сложно поправить запатчив Git.

с учетом того как он передает данные - не слишком просто.. если только сваливать на сервере предварительно сохраненные архивы.. которые весят больше чем вся репа в разы

с учетом того как он передает данные - не слишком просто.. если только сваливать на сервере предварительно сохраненные архивы.. которые весят больше чем вся репа в разы

Или поменять метод передачи данных :)

Git плох, например, тем, что не может в ту же докачку после обрыва. Из-за этого на слабых интернет-соединениях им пользоваться практически невозможно.

И это, конечно же, очень сложно поправить запатчив Git.

Это не запатчили за 11 лет. Вероятно, это не так уж просто (а если подумать над моделью хранения Git - в общем случае тупо невозможно).

enabling sub-directories to be `git clone`d independently of a large repo. This means you could use Mercurial to back your monorepo while still providing the illusion of multiple «sub-repos» to Mercurial or Git clients

Это возможность объединять несколько репозиториев в один. А тебе, насколько я понял, нужно чекаутить подкаталоги большого репа, SVN-стайл.

Это не запатчили за 11 лет. Вероятно, это не так уж просто (а если подумать над моделью хранения Git - в общем случае тупо невозможно).

Там был GSoC на тему, я не особо вчитывался. Но я отказываюсь верить в то, что если буферизировать данные в буфере TCP — то все ок, а если буферизировать где-нибудь на диске — то нет.

Во, нашел: https://git.wiki.kernel.org/index.php/SoC2009Ideas

The difficulty of this task is under a dispute: it should be fairly easy to make clone restartable for (deprecated) rsync:// protocol and for «dumb» protocols using commit walker, like http://. It shouldn't be too difficult to design user interface for this feature. Adding resume support to git-clone over «smart» protocols using packfile generation like git:// and ssh:// would require (most probably) good knowledge of pack protocol and packfiles. It would require most probably new extension to git protocol.

Я вот сегодня на 2 машинах пытался слить код с гитхаба, чтоб он сразу стал нетбинс проектом. У меня ушло где-то час. В итоге все равно все руками копировал. Потом это гогно мне не хотело пушить нормально. Говорило, что изменений нет. Я смотрю в измененный и закоммиченый файл, а оно мне говорит «no changes». Потом гордо заявило, что я вне бранча состою, а мне показывается original/master...

Я так-то особо пряморукостью не отличаюсь, но это какая-то жопь, извините.

документацию читать надо :)

Я вот когда смотрю в гитхуб, делаю pull и оно говорит «already latest», а в гитхубе другой код в том же файле, мне какую документацию читать именно? При том, что бранч тот же.

нужны подробности

с того ли ты гитхаба тянешь, точно ли бранчи те же и т.д.

The primary author also has aspirations for...

Жениться тебе надо, барин.

кул стори, бро.

Я смотрю фейспук слепо верит, что всё, что он делает - есть благо в высшей степени. Кому нужен mercurial, когда есть божественный git, дарованный человечеству солнцеликим Линусом?

Добавлять туда файлики .blank — жуткий костыль.

Ни разу такого не видел. Видел, что люди добавляют файл PLACEHOLDER, в котором желательно объяснить зачем эта пустая директория нужна. И это не только проблема Git многим тулзам иногда нужно объяснять, что пустая директория тоже нужна.

.blank, PLACEHOLDER или DeleteMe — это не так важно.

Плохо то, что нельзя добавить директории в процессе проектирования проекта.