Вопросы по созданию git-репозитория своего проекта

черрипикают

что это значит?

Урожай собирают) https://git-scm.com/docs/git-cherry-pick

kaldeon, mord0d, vbr, что делать в такой ситуации?:

▶ git push -u origin main
To https://git.org.ru/kosmos/KOSMOS.git
 ! [rejected]        main -> main (fetch first)
error: failed to push some refs to 'https://git.org.ru/kosmos/KOSMOS.git'
hint: Updates were rejected because the remote contains work that you do not
hint: have locally. This is usually caused by another repository pushing to
hint: the same ref. If you want to integrate the remote changes, use
hint: 'git pull' before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
▶ git pull
hint: You have divergent branches and need to specify how to reconcile them.
hint: You can do so by running one of the following commands sometime before
hint: your next pull:
hint:
hint:   git config pull.rebase false  # merge
hint:   git config pull.rebase true   # rebase
hint:   git config pull.ff only       # fast-forward only
hint:
hint: You can replace "git config" with "git config --global" to set a default
hint: preference for all repositories. You can also pass --rebase, --no-rebase,
hint: or --ff-only on the command line to override the configured default per
hint: invocation.
fatal: Need to specify how to reconcile divergent branches.

git pull --rebase

И не пользоваться уеб-интерфейсами

спасибо.
а почему по git push -u origin main не все файлы заливаются в репу? в корне проекта есть файлы: NEW_ROOT OLD_ROOT dist packages sources w. это директории. они почему то не появляются в репе https://git.org.ru/kosmos/KOSMOS

push заливает только то, что было закоммичено локально. В отличие от svn, git это полностью локальная система, а push/pull и т.п. только синхронизируют состояние между локальным репозиторием и его репликой на сервере.

так я делал

git add *
git commit -m '...'
потом
git push -u origin main

git add *

Во-первых, правильнее git add . (или даже git add -A, если нужно удалить файлы, которые есть в репе, но нет в рабочей копии)

Во-вторых, особенно на первых порах, я бы не рекомендовал такие огульные действия, лучше запустить git gui и увидеть своими глазами, какие изменения попадают в индекс. Да и в дальнейшем это позволяет делать самостоятельно review своих изменений, а также выбирать отдельные чанки или даже строки изменений для включения в коммит.

Если директории пустые, то они не зальются. Нужно добавить в них какой-то файл, например, .keep, если не предвидится чего-то более существенного, а директория там нужна.

История твоих коммитов разошлась. У них был один общий предок A. Потом в веб-интерфейсе ты сделал коммит B, а локально коммит C. Автоматически этот конфликт разрешить невозможно, поэтому тебе нужно делать rebase. Вроде тебе с этим помогли.

На будущее - если работаешь один - если делал изменения через веб-интерфейс, локально сразу делай pull и коммить уже после этого. Тогда твоя история коммитов будет строго линейная и проблем с push не будет.

Нужно добавить в них какой-то файл, например, .keep

Встроенная фича – добавлять в них .gitkeep.

Вот: https://devops-daily.com/posts/how-do-i-add-an-empty-directory-to-a-git-repository.

dataman,

Если директории пустые, то они не зальются.

можно как-то это обойти без добавления файлов? нафейхоа мне эти пустые файлы?

Не охота читать тред. Сколько раз рекомендовали forgejo?

Быстрый, как молния. Лёгкий, как пёрышко. Открытый, как GPL.

Ссылочка

Если западло самостоятельный хостинг, вот немцы создали гитхабокапец: codeberg

А вообще, всё, что вы пишите, можно успешно разруливать локальным гитом: контроль версий, ветки. Если хостинг в Сеть необязателен, потратьте время на освоение важного инструмента — git. А уж гайдов в Рунете полным-полно.

Нет, нельзя. Гит отслеживает файлы, а не директории. Это основа его архитектуры.

Создание файлов-заглушек .nodelete — стандарт.

Один хрен это в UNIX’ах скрытые файлы :)

а если хочу на нескольких зеркалах, как сделать 1 основное, чтобы синхронизировало автоматически?

Гит отслеживает файлы, а не директории.

директории это тоже файлы.

Один хрен это в UNIX’ах скрытые файлы :)

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

В гит есть хуки: ссылка.

Можно сделать так, чтобы при каждом совершении git commit зеркала выполняли git pull. Или в лоб переносить через rsync/cp -r.

директории это тоже файлы.

К чему эта духота? Ну да, тоже. Но ты не понял, что он сказал? Гит отслеживает обычные файлы, директории не отслеживает.

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

Предложи решение лучше.

$ git remote set-url --add origin <url>

тогда по командам типа git push origin master у тебя будут пушиться изменения в зеркала по всем урлам, указанным для ремота origin

Предложи решение лучше.

решение чего? для гита можно было бы отдельный конфиг файл со списком исключений.

решение чего?

Решение проблемы, очевидно. Чтобы и git юзать и директория в нужном месте была.

для гита можно было бы отдельный конфиг файл со списком исключений.

Каких исключений? Из чего? У него есть список файлов, которые он отслеживает. С путями. Директории создаются при необходимости. Из чего здесь можно сделать исключение?

Можно, наверное (я не пробовал), хук сделать, который по списку .emptydirs или типа того вызывает mkdir… Но это не список исключений, а как раз наоборот, список пустых директорий для создания.

вообще, начинать надо не с заучивания команд а с понимания базы, что такое git-репозиторий.

Это хранилище объектов, где каждый объект - это файл с именем, равным хэшу содержимого. Объекты бывают нескольких типов: блоб (файл), дерево (папка. Содержит ссылки на другие папки, блобы и коммиты субмодулей), коммит (содержит ссылку на родительские коммиты, на дерево корневой папки репозитория, и еще всякие метаданные), аннотированный тег (ссылка на коммит плюс еще больше метаданных).

Далее изучаем трехстороннее слияние, черрипик, ребейз и мерж.

Изучаем рабочие деревья и файл индекса. И т.д. Гит в своей базе - отлично продуманная и легкая для понимания система.

с github не было прецедентов

Ну до определённого времени нигде не было никаких прецедентов. На то они и прецеденты. (%

Каких исключений? Из чего?

witelist пустых директорий, которые нужно включать.

Но с github не было прецедентов требования денег/удаления репозиториев просто так

Ни с чем никогда не бывает официально «просто так», всегда есть какое-то объяснение. Но прецеденты удаления того, что до покупки мелкомягкими никого бы не потревожило, были.

От того, что кому-то репозиторий снесут не «просто так», а «потому что такие-то важные законотворцы в такой-то важной стране придумали такой-то важный акт, а такая-то важная корпорация пожаловалась», сильно легче не станет.

Ты опять бубнишь какие-то мантры, не имеющие отношения к ответу на мой вопрос.

Но пофиг, я тебя понял, можешь дальше не объяснять. Просто это не whitelist. И никаких исключений в твоей идее нет, а ровно наоборот. А так всё понятно (ещё до твоего вот этого комментария было, что я и написал в абзаце про потенциально возможный хук).

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

я тебя понял, можешь дальше не объяснять. Просто это не whitelist. И никаких исключений в твоей идее нет, а ровно наоборот. А так всё понятно (ещё до твоего вот этого комментария было, что я и написал в абзаце про потенциально возможный хук).