Это копия, сохраненная 4 августа 2022 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
8 Кб, 383x383> понял, что моя работа стала бы производительней, подруби я какой либо граф интерфейс
На самом деле, нет, не стала бы. Обычно надо делать коммит, пуш, пулл, мерж, иногда ребейз, и для всего есть кнопки в IDE. Очень редко надо сделать что-то сложное типа поиска и черри-пиков кучи коммитов, и тогда эти тулзы что-то могут облегчить.
джун-макака
Magit очень удобный. Использую даже когда пишу код не в эмаксе.
/thread
10 Кб, 240x206>Можно в гит десктоп пушить без коммитов? На пике например кнопка неактивна пока не напишешь что-то в заголовок
Чел иди лучше на завод.
Работаю в консоли, давно уже есть конвейер
"git add . && git commit -m "comment" && git push", вызываемый с 6 кнопок ([g][t][ ][a][↑]). Там же всякие более мудрёные rebase, fetch, checkout и пр., с oh-my-zsh и его автодополнением работать крайне удобно.
Для просмотра (в том числе контроль перед коммитом, git add -p и git add -i мне не зашли) или когда нужно разнести изменения по нескольким коммитам - Sublime Merge, иногда (когда очень лень) могу и пушнуть прямо оттуда.
Ситуация такая: в рамках одного проекта и репа писал подсистемку, сейчас самое время вытащить её и использовать отдельно. Это 1 файл. И я бы хотел вытащить его в новый реп со всей историей коммитов. Это возможно?
Интернет пишет про связки типа remote-fetch-merge и всём таком, но они тянут весь реп со всей историей, а мне нужен один файл.
Nyet. В гите ID каждого коммита создается в том числе на основе предыдущего ID, поэтому надо тащить всю историю коммитов целиком. Но теоретически можешь попробовать создать новый реп с начальной версией этого файла и последовательно накатить на него все диффы из оригинальной репы.
Сделай форк и в нём ещё один коммит с удалением всех файлов, кроме твоей "подсистемки".
Пичаль. Я уже думал выковырять её откуда-то из .git/, но слишком замороченный шаг.
>>164239
Так и сделал. Спасибо. Я, кстати, с этими фетчами и импортами забыл о том, что прямо в интерфейсе GL есть метод для дублирования всего в пару кликов.
Сори, с работы благодарственные сиськи постить неудобноа потом это же объективация женского тела и вообще вдруг ты не любишь сиськи (например, кроме своих).
109 Кб, 1280x710На гитхабе и так всё визуализируется, чего именно тебе не хватает?
>кто как пользуется git'ом
Консоль - практически все.
TortoiseGit - оверлеи, удобный диф, реверты.
SourceTree - удобный поиск по истории
Гитхаб - говно, гитлаб - няша.
Git - говно, Mercurial - няша, но к сожалению рыночек порешал, приходится пользоваться говном.
>всё визуализируется
Хуй там. За столько лет в ебучем гитхабе не смогли запилить нормальный граф коммитов, который есть даже в сраной консоли.
Github Desktop или просмотр в VS Code. Гораздо безопаснее чем вслепую коммитить из консоли. Кстати до десктопа я гит не понимал абсолютно, хотя много раз пытался, консольке-пердольке не хватает наглядности.
Ковыряю GitLab CI, возник вопрос: можно ли когда в репе произошло некое событие инициировать CI в другом репе?
Тема такая: есть N групп, пилящих один проект, каждая в своём репозитории (фронт отдельно, бэк отдельно, ansible-плэйбуки для деплоя — отдельно).
Хочу чтобы когда команды фронта или бэка повесили на коммит в мастере тег — запускался бы CI, который соберёт всё вместе, скомпилирует, протестирует и отправит заказчику дистрибутив (при чём, очевидно, делать одинаковые CI в каждом дистре — явно неправильный вариант). Сборку, тестирование и отправку реализовал, но лень нажимать кнопочку билда вручную по звонку "мы родили версию", хочу, чтобы они сами, тегированием, дёргали ручку.
Не тот анон, но отвечу от себя:
Можно случайно закоммитить полупереписанный метод, например. В итоге код в репе будет нефункционален.
Вообще для этого есть ключи -p и -i для git add, но мне, например, проще посмотреть в smerge все изменения и при необходимости застейджить и закоммитить их поотдельности.
В общем-то я как правило коммичу из консоли прямо кодом
>git add . && git commit -m "comment" && git push
, но перед коммитом стараюсь всегда заглянуть в смердж на предмет мусора.
>>168626
Анон все правильно сказал. Я ещё тревожный, всегда глазами изменения перед коммитом проглядываю. Можно насрать в метод, можно забыть убрать матерный комментарий, можно проебать секретный токен доступа, можно забыть заигнорить гигабайтный файл тестовой базы или сраные node_modules, можно просто что-то вспомнить пока код пролистываешь. Короче полезная привычка на самом деле.
Если нет коммитов, то и пушить нечего.
Может ты хотел спросить можно ли сделать коммит без комментария?
мимо гит вкатывальщик
@
НА СОБЕСЕ ПРОСЯТ ПРОДЕМОНСТРИРОВАТЬ
@
И ДОБАВИТЬ ПУСТУЮ ПАПКУ В РЕПОЗИТОРИЙ
8 Кб, 235x68Сука, нашёл.
Одна строка в скрипте:
> - curl --request POST --form "token=$CI_JOB_TOKEN" ${CI_API_V4_URL}/projects/${PROJECT_CI_ID}/trigger/pipeline
В переменную PROJECT_CI_ID нужно положить ID проекта, в котором CI должен стартовать. Увидеть его можно под именем проекта, например, на пике это будет 11936575.
Можно дополнительно указать, например, ветку:
> --form ref=master
или переменные, скажем, можно передать текущий тег, чтобы вызываемая CI положила результат сборки в определённое место:
> --form "variables[TAG]=$CI_COMMIT_TAG"
Фишка, на которую надо обратить внимание в CI_JOB_TOKEN: права текущей джобы зависят от того, чьи действия инициировали CI, если у него нет прав инициировать CI в вызываемом проекте, то ничего и не произойдёт. Что работает неоднозначно: на сборочный CI нужно давать дополнительные права. Впрочем, если придерживаться, скажем, GitLab Flow, то такое действие можно привязать к тегированию, а тегированием будет заниматься ответственный тимлид.
Перебежал в соседнюю через улицу контору на плюстриста
На самом деле не то чтобы совсем ненужная вещь.
Например, у меня есть реп, в котором в CI создаются и заполняются папки. Создать их один раз и не морочиться потом с созданием-владельцем-правами отдельно -- вполне себе выход.
Другое дело, что даже имея такую задачу я не морочился тем, чтобы именно сохранить папочку.
На самом деле не то чтобы совсем ненужная вещь.
Например, у меня есть реп, в котором в CI создаются и заполняются папки. Создать их один раз и не морочиться потом с созданием-владельцем-правами отдельно -- вполне себе выход.
Другое дело, что даже имея такую задачу я не морочился тем, чтобы именно сохранить папочку.
К чему это? Он тоже используется в проекте. И даже частично заполняет эти вновьсозданные папки.
Типичный способ сохранить папку -- создать в ней пустой файл .gitkeep или что-то такое. Но добавить в CI "mkdir -p" или в установщик --
"- file: path=/path/to/folder/ state=directory owner=user group=users mode='777'" не сложнее.
947 Кб, 1441x878Пользуюсь встроенным в VS Code.
Для чего-то более сложного иду в консоль.
Можешь попробовать GitKraken
https://www.gitkraken.com/
git status
32 Кб, 471x356Ну объясните уже, как удалить ёбаные комиты, ну бесит уже, сука! Ну пиздец же, блядь! Я нихуя не понимат! Вот есть макароны из комитов. Как мне ПРОСТО блядь взять и удалить на хуй комит к такой-то матери? Ну блядь?!!
Ну вот я нахерачил пикрил. Как удалить всё, кроме основной ветки мастер. Не скрыть! А удалить!
Ну блядь сука БЕСИТ!!!
Почему нельзя просто блядь нажать ёбаный Del и забыть про ненужные версии как про страшный сон? Какого блядь хуя, блядь?!! Это локальный репозиторий, он никуда не аплоадится, какого блядь хуя, блядь?!!
Кто, какой долбоёб, блядь, придумал, что комиты не должны удаляться, сука, ебало бы ему разбить!
Я уже заебался гуглить и читать охуительные истории про то, что коммиты удаляются из истории через reset! Нет, блядь, ОНИ НЕ УДАЛЯЮТСЯ!!! Более того, в итоге создаётся ещё один комит! И rebase тоже создаёт новые комиты! Но мне не нужны новые комиты, я хочу удалить всё, удалить К ХУЯМ, сука блядь! Ну как это так?!! Они не нужны мне, эти комиты, и не понадобятся ни при каких условиях, ибо их можно считать ошибочными, не код ошибочен, а сами комиты закомитили НЕ ТО, неужели ради удаления подобного говна всегда нужно будет удалять к хуям весь репозиторий? Сирьёна?!! Да вы ёбнулись? И все этим пользуются?!! Пиздец!!!
Да я бля лучше сука в таксисты пойду, чем в программирование, я сука не согласен пользоваться таким говном, в котором не работает ебучий Del.
>Эта команда делает совсем другое: стирает всю историю до commitId и возвращает рабочую область к его состоянию. При этом вы потеряете данные более поздних коммитов.
>git reset --hard commitId #УДАЛЯЕТ ИСТОРИЮ GIT
Это типичный ответ в гугле. Ну какого хуя они все пишут такую херню?!! Во-первых, мне не надо откатывать последний комит, мне нужно удалить комиты из побочных ветвей, которые ведут в никуда. Во-вторых, НЕ УДАЛЯЕТ ЭТА КОМАНДА НИХЕРА, НЕ УДАЛЯЕТ, СУКА, ТУПИЦЫ, ДОЛБОЁБЫ, САМ ПРОВЕРЬ, НЕ УДАЛЯЕТ ОНО БЛЯДЬ!!! Она просто указатель HEAD передвигает, блядь!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Вся история остаётся!!! СУКА, ПИДОРЫ ТУПЫЕ!!! Хули вы весь гугл засрали своим враньём?!! ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА!!!!!!!!!!!!!!!!!!!!!!!
Ну ответь по существу, а потом я пойду в таксисты.
Мань, ты не видишь пикрилы? Это и есть графический клиент, долбоёбина! Ты даже этого не понял? Кому ещё из нас в таксисты идти, тупица! Давай, объясняй, как удалять ссылки на комиты из графических клиентов. Из каких? Вот у меня gitg, gitk, git-gui, ни в одном из них нет подобного функционала, чтобы выделить произвольный комит и удалить его
сжалюсь над таксистом.
давай сначала .
Это твой репозитарий или ты собираешься наебать товарищей?
У себя ты можешь что угодно перебазировать, сделать push определенных веток и все пропадет.
Ты не можешь ничего нагуглить потому что так никто не делает.
или, если все действительно так как ты описываешь, нужно просто почистить коммиты без ссылок.
вот такой вариант должен работать : git gc --prune=now --aggressive
Опять же, подразумевается, что ты все делаешь локально и никто эти коммиты к себе не скачивал. Иначе коллегам придется мержить вручную и они тебя отпиздят.
Тебе просто нужно пройти парочку туториалов и разобраться в терминологии. Ты хочешь удалить коммиты, а бугуртишь на ветки. Ветки можно удалить без последствий для главной ветки - мастера. Это, конечно, если ты уже всё смерджил.
Также можно просто не отображать все бранчи в графическом интерфейсе, а выбрать только нужные.
Тепере про коммиты в основной ветки. Если у тебя есть много коммитов, а хочешь подсократить их количество, то ты можешь
делать git reset на определенном коммите, который тебя устраивает, а потом перезаписать все изменения в основной коммит.
Например, допустим вот твоя история. Используй git log format=oneline -5, чтобы отобразить коммиты примерно в нижеследующем формате.
63362df1fd678ad96 Do some work
ad5dd2beebe85b474 Lick shit
1806f3b61eb81498e Lick pussy
8de4ec1366a46c01d Lick cock
ab36113c2f3be2870 Fix bug
Очевидно, что тебе не нужны коммиты в середине. Как от них избавиться. Существует несколько способов, однако самый простой - резет на определенном коммите и добавление изменений в новый коммит.
git reset ab36113c2f3be2870
Полсе этого у тебя остаётся только первый коммит Fix bug. При этом все изменения в файлах никуда не делись, они просто не закомичены, как если бы ты их сделал прямо сейчас. Можешь проверить с помощью git status.
Дальше, добавляешь эти и другие изменения (если делал их).
git add .
И коммитишь в нужный коммит.
git commit "Do some work"
Получаешь следующую историю.
1233lqw343wej2116 Do some work
ab36113c2f3be2870 Fix bug
Все изменения сохранены. Обрати внимание, у последнего коммита новый hash. Это потому что ты перезаписал коммит.
Вот и всё.
Конечно, это необязательно проделывать в мастере, любая ветка может считаться твой основной, в зависимости от того, работаешь ты в ней или нет. Вообще бранчинг в гите - это легковесная операция, не надо с неё бугуртить, у тебя будут сотни бранчей, и это круто. Просто нужно их удалять или фильтровать. Многие системы типа Гитлаба удаляют бранчи автоматически при мердже.
Еще штуки, чтоб погуглить, как разберешься: interactive rebase, git reflog.
Тебе просто нужно пройти парочку туториалов и разобраться в терминологии. Ты хочешь удалить коммиты, а бугуртишь на ветки. Ветки можно удалить без последствий для главной ветки - мастера. Это, конечно, если ты уже всё смерджил.
Также можно просто не отображать все бранчи в графическом интерфейсе, а выбрать только нужные.
Тепере про коммиты в основной ветки. Если у тебя есть много коммитов, а хочешь подсократить их количество, то ты можешь
делать git reset на определенном коммите, который тебя устраивает, а потом перезаписать все изменения в основной коммит.
Например, допустим вот твоя история. Используй git log format=oneline -5, чтобы отобразить коммиты примерно в нижеследующем формате.
63362df1fd678ad96 Do some work
ad5dd2beebe85b474 Lick shit
1806f3b61eb81498e Lick pussy
8de4ec1366a46c01d Lick cock
ab36113c2f3be2870 Fix bug
Очевидно, что тебе не нужны коммиты в середине. Как от них избавиться. Существует несколько способов, однако самый простой - резет на определенном коммите и добавление изменений в новый коммит.
git reset ab36113c2f3be2870
Полсе этого у тебя остаётся только первый коммит Fix bug. При этом все изменения в файлах никуда не делись, они просто не закомичены, как если бы ты их сделал прямо сейчас. Можешь проверить с помощью git status.
Дальше, добавляешь эти и другие изменения (если делал их).
git add .
И коммитишь в нужный коммит.
git commit "Do some work"
Получаешь следующую историю.
1233lqw343wej2116 Do some work
ab36113c2f3be2870 Fix bug
Все изменения сохранены. Обрати внимание, у последнего коммита новый hash. Это потому что ты перезаписал коммит.
Вот и всё.
Конечно, это необязательно проделывать в мастере, любая ветка может считаться твой основной, в зависимости от того, работаешь ты в ней или нет. Вообще бранчинг в гите - это легковесная операция, не надо с неё бугуртить, у тебя будут сотни бранчей, и это круто. Просто нужно их удалять или фильтровать. Многие системы типа Гитлаба удаляют бранчи автоматически при мердже.
Еще штуки, чтоб погуглить, как разберешься: interactive rebase, git reflog.
Все то же самое можно сделать в любом графическом клиенте. Ты просто не понимаешь, что жделать, потому что не разобрался как работает гит. Если ты разберешься с консолью, для тебе любой графический клиент будет открытой книгой.
Использую гит в консоли, часто консоль прямо в IDE. Если нужно решить конфликты, использую функцтонал IDE, так как она показывает сразу компилируется ли финальный файл.
>Все изменения сохранены. Обрати внимание, у последнего коммита новый hash. Это потому что ты перезаписал коммит.
Ах да, чтобы записать их в репозиторий, нужно сделать git push --force. Не делай так в мастере (пока), посколько это переписывает всю историю и за это тебе спасибо не скажут. Если ты работаешь пока один, то пох, или если это ветка с исключительно твой фичей.
Можешь использовать git push --force-with-lease, чтобы не перезаписать, если кто-то уже спулил твою ветку.
536 Кб, 1838x985из консольки обычно только пуши, сташ и интерактивный ребейз запускаю или если нужно указать другого автора коммита, ну и свои скрепты вроде удоления старых замерженных бранчей, игнора файлов и т.п.
Но т.к. он слишком сырой пока что и несколько не хватает функционала - все равно иногда прийдется переходить на другие гит-клиенты или на консоль. Лично я пользуюсь таоГитом практически постоянно + Tower если не хватает возможностей таогита.
Если же ты под виндой.... То с грустью сообщаю что все графические гит-клиенты ущербны... как-то так.
Но чуть менее ущербным является Tower.
создай бранч на нулевом коммите.
А потом вручную на каждом коммите где менялся этот файл делай черри пик.
Что бы вы понимали на сколько прекрасен ТаоГит - посмотрите на окно клонирования. А потом сравните с любым другим гит-клиентом. Это просто небо и земля -- ничего лишнего при той же функциональности. И так всюду, йопта!
никак невозможно удалить коммит. Это особенность работы репозитория. Потому что каждый последующий коммит является патчем на предыдущее состояние репозитория. Удалив коммит физически ты получаешь нерабочий репозиторий. Теоретически это возможно, конечно. Например обьединив несколько коммитов в один - но на практике гит не дает такой возможности.
Так что расслабь булки и успокойся и просто оставь как есть.
91 Кб, 457x327git add .
git commit -m "..."
git merge branch_name
git rebase main
git pull origin main
git checkout -b ...
git checkout commit_hash
Отдельно еще нужно понимать как сабмодули работают.
За 6 лет опыта пришлось несколько раз черри пик делать, там уже подгуглил доку быстро.
GUI полезен и нужен когда надо посмотреть быстро изменения файлов перед коммитом, ну и конечно же для решения мердж конфликтов. В VS Code встроенные отличные тулзы для этого.
Ты забыл упомянуть о проблеме гита в работе с сабмодулями в целом.
Что в консольном гите что во всех гит клиентах (за исключением таогита) при работе с репозиториями с сабмодулями ПОСТОЯННО детачатся хеады. И это ущербство.
Таогит же это фиксит сам практически всегда без этой всякой постоянной возни на пустом месте.
Черри пик тот же через гуишные клиенты делается на раз-два и ничего гуглить не нужно. Чисто файл из коммита перетягиваешь на нужный бранч или коммит на нужный бранч и все чики-пики.
а еще забыл упомянуть об "удобстве" решения конфликтов через консоль))))
Ничего не детачится если ты сам не задетачишь. GUI всего лишь исполняет консольные комманды под капотом.
36 Кб, 471x356Без прочтения доки и не поигравшись в консоли ты не поймешь никогда. Гит очень простой, но он не очевидный, из-за этого у новичков проблемки часто.
скачай fork и играйся. мне помог. в основном юзаю pull, fetch, cherry-peak и мерж (из за дурачков в команде, которые не умеют в ребейз)
Больше команд не надо. Ну и ветки создавать.
/thread
>мерж (из за дурачков в команде, которые не умеют в ребейз)
Только не говори, что ты rebase на remote ветки делаешь.
еще как детачиться) и у консольной версии ровно так же детачится. Это связано с архитектурой гита, долго обьяснять.
https://codingkilledthecat.wordpress.com/2012/04/28/why-your-company-shouldnt-use-git-submodules/
в блоке статьи "Oh, were you using that?" описано пример)
А ты сказки рассказываешь
Если ты говоришь что гит очено простой - то ты не знаешь гита))) А знаешь лишь его базовый функционал в стиле фетч, пул, пуш, коммит, реверт да мердж.
Внутри гит очень сложная штука да и функционал у него чуть по-шире перечисленных функций.
>>217617
При чем обрати внимание, если проэкт состоит из 1 репозитория и 1 сабмодуля - эт еще терпимо Но бывает и не так. Бывает что дерево сабмодулей состоит из десятка и более репозиториев. И не все твои еще. И эта вся структура на постоянке у тебя детачится и ты как дебил должен это фиксить вручную на каждом репозитории(сабмодуле) отдельно.
А еще ты не прав что гуи исполняет консольные команды под капотом. Потому что это зависит от того что за гуи используется. Некоторые используют под капотом гуи - напримет тот же тавер. А вот ТаоГит и Кракен под капотом используют библиотеку LibGit2.
Но это не играет роли потому что хеады детачатся всюду. Ни одного гит клиента или консольной версии гита не существовало которые бы не детачили хеады. Повторюсь - все из-за архитектуры гита как такового.
Единственное исключение из этого всего- таогит. Если кто знает еще кто фиксит - милости прошу меня поправить.
Ты имеешь в виду, что вся команда должна делать ребейз одновременно с тобой, а они не умеют, поэтому они дурачки?
Да уж. Я в итоге разбираюсь помаленьку. Только всё-таки я настаиваю, что одной консоли тут мало. Надо именно гуйню. А потом уже консоль. В консоли видно не то что бы меньше, но другое. В gitk сразу видно структуру. А в консоли можно увидеть, например, git reflog. А ещё лучше просто зайти в каталог .git и пооткрывать там файлики, чтобы понять, что там вообще содержится.
>>217579
Ну и нафиг, когда есть gitk/git-gui?
>>217597
Да-да. В gitk выделяешь коммит в ветке и в контекстном меню выбираешь "скопировать коммит в текущую ветку", и всё. Вот ребейза в гуйне не нашёл.
316 Кб, 554x808вот просто схожу в тавере рибейз в контекстном меню на любом коммите.
>настаиваю, что одной консоли тут мало
^ консоли не то что бы мало.... она наоборот функциональнее почти любого гуя (в плане гита а не внешних фишек как в случае с кракеном). Просто там те же будничные вещи делаются сложнее зачастую чем в гуе. Есть смысл пользоваться гуем и переходить на консоль по мере необходимости.
>А в консоли можно увидеть, например, git reflog
^ уверен что некоторые гуи и его имеют у себя в запасе.
> А ещё лучше просто зайти в каталог .git и пооткрывать там файлики, чтобы понять, что там вообще содержится
^ Эт плохой совет. Потому что файлики которые там лежат - постоянно меняются. Например если идет мердж но он еще не закомичен - там + 3 файлика. И так на куче-куче-куче действий. Вобщем, это даст очень поверхностное представление о гите. Есть же книги по гиту, для чего так извращатся?)
Даже на русском есть вполне годная бесплатная литература. https://git-scm.com/book/ru/v2
>Например если идет мердж но он еще не закомичен - там + 3 файлика.
Ты имеешь в виду каталог, в котором твои исходники? Я имею в виду каталог .git. Там, конечно, не всё можно понять, но по крайней мере многое видно. Например, метки в виде простых текстовых файлов. Ветки тоже. И логи.
именно что имею ввиду каталог .git
потому что во время начатого мерджа там генерятся файлы: MERGE_HEAD, MERGE_MODE, MERGE_MSG. И подобные этим файлы появляются и исчезают на постоянке во время работы с гитом в зависимости от того какое действие ты сейчас делаешь. Вобщем как я и сказал -- это очень плохой способ для понимания гита))
Ты это подтвердил своим переуточнением)
>Fossil наше все
Так.
Был бы еще файловый оверлей для него какой-нибудь по типу черепахи, было бы вообще заебись.
>Ты имеешь в виду каталог, в котором твои исходники?
^ каталог с исходниками называется "воркдиром" в гите :)
>>Там, конечно, не всё можно понять, но по крайней мере многое видно. Например, метки в виде простых текстовых файлов.
^ Чесно - я не знаю что тебе там может быть многое понятно, но я тебе гарантирую что ты и 5% не понимаешь от того что там творится.
Я гит знаю весьма неплохо потому что у меня работа с ним связана очень-очень тесно. Но даже я не берусь утверждать что я понимаю хотя бы 50% от того что творится в категории .git.
Вот например ты знаешь как хранятся коммиты? Там хранятся исключительно изменения (как патчи) или же файлы целиком?
Ты знаешь что такое патч вообще? То есть ты понял прошлый вопрос полностью?
Может ли находится .git в нестандартном месте? В каких случаях?
Как взаимодействуют .git папки между собой если у тебя твой проэкт состоит не из одного репозитория, а из кучи репозиториев (сабмодулей)?
гитигнор файлы в проэктах с сабмодулями общие или на каждый репозиторий свой?
По какой логике размещаются файлы в папке objects ты понимаешь? А что там вообще хранится? Там хранятся только коммиты или что-то еще?
Что такое хуки в гите?
И так можно продолжать очень-очень-очень долго.
Или почему в репозиториях с сабмодулями на постоянке детачатся хеады по каждому чиху?
Или как найти потерявшийся коммит или ветку коммитов? Как вообще коммит может потеряться?
Что такое bare repo ? Чем отличается от empty repo ?
Почему ты не можешь патч применить на любую версию файла?) Почему если у патч отображает изменения файла на начале файла, а в файле менялся конец, то ты не можешь применить этот патч? Он же не конфликтует изменения.
Как гит работает с бинарными файлами? Он отслеживает изменения в бинарных файлах частями так же как он работает с текстовыми файлами? Или же он с ними работает иначе?
83 Кб, 686x697Как это я подтвердил? Просто я ещё пока не видел этих файлов, но если я в них посмотрю, то пойму немного больше, чем если просто сделаю merge. А непонятка была в том, что при merge и в рабочем каталоге создаются три файла, koko.base, koko.local и koko.remote.
>>226981
>Там хранятся исключительно изменения (как патчи) или же файлы целиком?
This. И упаковываются в пакеты. Но я не предлагал пакеты читать как текст. А ветки и тэги это же просто текст.
>Ты знаешь что такое патч вообще? То есть ты понял прошлый вопрос полностью?
Знаю, понял. "dif koko kokokoko > koko.diff", вот и получился патч. Потом "patch koko.diff", вот патч и применился. Что тут непонятного?
>Может ли находится .git в нестандартном месте? В каких случаях?
Может, раз ты спросил. В каких случаях хз.
>Как взаимодействуют .git папки между собой если у тебя твой проэкт состоит не из одного репозитория, а из кучи репозиториев (сабмодулей)?
Не знаю, не пользовался сабмодулями. Как я понял, сабмодули это отдельные репозитории, которые сами по себе коммитятся в главный репозиторий, но нафига это всё я пока не в курсе. А что, если только по мануалам учиться, то ты это поймёшь лучше, чем заглядывая и в мануалы, и в файлы?
>гитигнор файлы в проэктах с сабмодулями общие или на каждый репозиторий свой?
Не пользовался сабмодулями. Без понятия.
>По какой логике размещаются файлы в папке objects ты понимаешь?
От sha коммита отделяются первые два символа и создаётся папка с этим именем, остальное используется как имя файла. Это как раз элементарно проверяется в простом текстовом редакторе, где у тебя открыт .git/logs/refs/heads/master и простым ctrl-F по имени файла. А ты подразумеваешь, что это какое-то тайное знание, недоступное простому наблюдателю?
>А что там вообще хранится? Там хранятся только коммиты или что-то еще?
В основном коммиты, как я понял. По отдельности и объединённые в пакеты. Но не только.
>Что такое хуки в гите?
Скрипты такие специальные, лежащие в папке ./git/hooks. Там лежат сэмплы, которые делают всякое, например, проверяют, можно ли ребейзить ветку, или лучше не стоит. Между прочим, весьма познавательно, там на 70 строк кода 90 строк комментариев с картинками. А в коде этом команды всякие к git, с объяснениями. Потому-то я и говорю, что полезно почитать, что там изначально положено.
>И так можно продолжать очень-очень-очень долго.
Ну и что? Какой ты сделал вывод? Я сделал вывод, что заглянув в этот каталог можно многое узнать. В том числе и ответы на вопросы, которые ты почему-то задал. Мне вот непонятно, с какой целью ты спросил про хуки? Ну их сэмплы лежат прямо на виду. Они специально туда положены, чтобы кто-то их прочитал. Специально с комментариями с картинками. Значит очевидно, что их читать подразумевается. Что только подтверждает то, что я выше написал. А ты почему-то пишешь прямо противоположное.
83 Кб, 686x697Как это я подтвердил? Просто я ещё пока не видел этих файлов, но если я в них посмотрю, то пойму немного больше, чем если просто сделаю merge. А непонятка была в том, что при merge и в рабочем каталоге создаются три файла, koko.base, koko.local и koko.remote.
>>226981
>Там хранятся исключительно изменения (как патчи) или же файлы целиком?
This. И упаковываются в пакеты. Но я не предлагал пакеты читать как текст. А ветки и тэги это же просто текст.
>Ты знаешь что такое патч вообще? То есть ты понял прошлый вопрос полностью?
Знаю, понял. "dif koko kokokoko > koko.diff", вот и получился патч. Потом "patch koko.diff", вот патч и применился. Что тут непонятного?
>Может ли находится .git в нестандартном месте? В каких случаях?
Может, раз ты спросил. В каких случаях хз.
>Как взаимодействуют .git папки между собой если у тебя твой проэкт состоит не из одного репозитория, а из кучи репозиториев (сабмодулей)?
Не знаю, не пользовался сабмодулями. Как я понял, сабмодули это отдельные репозитории, которые сами по себе коммитятся в главный репозиторий, но нафига это всё я пока не в курсе. А что, если только по мануалам учиться, то ты это поймёшь лучше, чем заглядывая и в мануалы, и в файлы?
>гитигнор файлы в проэктах с сабмодулями общие или на каждый репозиторий свой?
Не пользовался сабмодулями. Без понятия.
>По какой логике размещаются файлы в папке objects ты понимаешь?
От sha коммита отделяются первые два символа и создаётся папка с этим именем, остальное используется как имя файла. Это как раз элементарно проверяется в простом текстовом редакторе, где у тебя открыт .git/logs/refs/heads/master и простым ctrl-F по имени файла. А ты подразумеваешь, что это какое-то тайное знание, недоступное простому наблюдателю?
>А что там вообще хранится? Там хранятся только коммиты или что-то еще?
В основном коммиты, как я понял. По отдельности и объединённые в пакеты. Но не только.
>Что такое хуки в гите?
Скрипты такие специальные, лежащие в папке ./git/hooks. Там лежат сэмплы, которые делают всякое, например, проверяют, можно ли ребейзить ветку, или лучше не стоит. Между прочим, весьма познавательно, там на 70 строк кода 90 строк комментариев с картинками. А в коде этом команды всякие к git, с объяснениями. Потому-то я и говорю, что полезно почитать, что там изначально положено.
>И так можно продолжать очень-очень-очень долго.
Ну и что? Какой ты сделал вывод? Я сделал вывод, что заглянув в этот каталог можно многое узнать. В том числе и ответы на вопросы, которые ты почему-то задал. Мне вот непонятно, с какой целью ты спросил про хуки? Ну их сэмплы лежат прямо на виду. Они специально туда положены, чтобы кто-то их прочитал. Специально с комментариями с картинками. Значит очевидно, что их читать подразумевается. Что только подтверждает то, что я выше написал. А ты почему-то пишешь прямо противоположное.
>>This. И упаковываются в пакеты. Но я не предлагал пакеты читать как текст.
^ Я спросил про 2 варианта. А ты мне "зис")
> А ветки и тэги это же просто текст.
^ Понятие веток и тэгов вообще виртуальное. В гите внутри нету ни веток ни тегов. Там есть коммиты. Тэги и ветки это буквально именованные коммиты. Это как лейбочка на веревочке.
А когда ты ветку или тэг удаляешь - ничего из репозитория не удаляется. Из гит-репозитория в принципе никогда ничего не удаляется. Все что ты туда внес там и остается навсегда.
А на один и тот же коммит может быть созданно бесконечное число бранчей.
Именно поэтому постоянно детачатся хеады. Потому что при любом чихе и малейшем изменении оно все равно ссылается на определенный коммит. Но гит не уверен - он ссылается на этот созданный бранч (на эту лейбочку), или же он ссылается на этот коммит как на отдельный неименованный бранч (детачед хеад)
>Знаю, понял. "dif koko kokokoko > koko.diff", вот и получился патч.
^ неа, патч и дифф это разные вещи. Потому что патч включает себя как дифф, так и дополнительную информацию о файле на который он должен применятся. Ты не можешь применить дифф как патч.
> Как я понял, сабмодули это отдельные репозитории, которые сами по себе коммитятся в главный репозиторий, но нафига это всё я пока не в курсе.
^ очень полезная штука. Покопай.
>Но не только.
Именно что не только. Там может быть много-много-много всего. Там хранится почти все. Стеши, индексы, коммиты, вообще все-все-все возможные обьекты гита которые относятся к сохранению данных из воркдира в том или ином виде. Все индексы там же. А индекс - это не только информация о текущем чекауте или конфликтах. Там может быть паралельно использовано овердохрена индексов под капотом каждый из которых по-своему использует гит.
> .....А в коде этом команды всякие к git, с объяснениями. Потому-то я и говорю, что полезно почитать, что там изначально положено.
^ а здесь уже наступает вопрос чем именно репозиторий был создан. Потому что разные клиенты или терминал могут эту папку создавать или не создавать. Заполнять примерами или не заполнять. Кидать туда картинки с обьяснениями или не кидать. И вот посоветуешь ты человеку туда залезть... а у него там пусто)
>Я сделал вывод, что заглянув в этот каталог можно многое узнать. В том числе и ответы на вопросы, которые ты почему-то задал.
^ мои исправления показывают что многие из твоих выводов ошибочны потому что ты поленился почитать книги)
>>This. И упаковываются в пакеты. Но я не предлагал пакеты читать как текст.
^ Я спросил про 2 варианта. А ты мне "зис")
> А ветки и тэги это же просто текст.
^ Понятие веток и тэгов вообще виртуальное. В гите внутри нету ни веток ни тегов. Там есть коммиты. Тэги и ветки это буквально именованные коммиты. Это как лейбочка на веревочке.
А когда ты ветку или тэг удаляешь - ничего из репозитория не удаляется. Из гит-репозитория в принципе никогда ничего не удаляется. Все что ты туда внес там и остается навсегда.
А на один и тот же коммит может быть созданно бесконечное число бранчей.
Именно поэтому постоянно детачатся хеады. Потому что при любом чихе и малейшем изменении оно все равно ссылается на определенный коммит. Но гит не уверен - он ссылается на этот созданный бранч (на эту лейбочку), или же он ссылается на этот коммит как на отдельный неименованный бранч (детачед хеад)
>Знаю, понял. "dif koko kokokoko > koko.diff", вот и получился патч.
^ неа, патч и дифф это разные вещи. Потому что патч включает себя как дифф, так и дополнительную информацию о файле на который он должен применятся. Ты не можешь применить дифф как патч.
> Как я понял, сабмодули это отдельные репозитории, которые сами по себе коммитятся в главный репозиторий, но нафига это всё я пока не в курсе.
^ очень полезная штука. Покопай.
>Но не только.
Именно что не только. Там может быть много-много-много всего. Там хранится почти все. Стеши, индексы, коммиты, вообще все-все-все возможные обьекты гита которые относятся к сохранению данных из воркдира в том или ином виде. Все индексы там же. А индекс - это не только информация о текущем чекауте или конфликтах. Там может быть паралельно использовано овердохрена индексов под капотом каждый из которых по-своему использует гит.
> .....А в коде этом команды всякие к git, с объяснениями. Потому-то я и говорю, что полезно почитать, что там изначально положено.
^ а здесь уже наступает вопрос чем именно репозиторий был создан. Потому что разные клиенты или терминал могут эту папку создавать или не создавать. Заполнять примерами или не заполнять. Кидать туда картинки с обьяснениями или не кидать. И вот посоветуешь ты человеку туда залезть... а у него там пусто)
>Я сделал вывод, что заглянув в этот каталог можно многое узнать. В том числе и ответы на вопросы, которые ты почему-то задал.
^ мои исправления показывают что многие из твоих выводов ошибочны потому что ты поленился почитать книги)
>Или почему в репозиториях с сабмодулями на постоянке детачатся хеады по каждому чиху?
Да хрен знает. Я вообще не понял, с какой целью их нужно использовать. А может даже не понял, что это вообще такое.
>Или как найти потерявшийся коммит или ветку коммитов? Как вообще коммит может потеряться?
Да просто потеряться. Перестали на него ссылаться - он и потерялся. А найти - просто reset на него, пока не потерялся окончательно.
>Что такое bare repo ? Чем отличается от empty repo ?
Видимо, один почти пустой, а другой совсем пустой. Не знаю. А это какое-то принципиальное знание? Оно мне зачем?
>Почему ты не можешь патч применить на любую версию файла?)
Потому что конфликты. Потому что контекст не находится. Потому что он уже изменён.
>Почему если у патч отображает изменения файла на начале файла, а в файле менялся конец, то ты не можешь применить этот патч? Он же не конфликтует изменения.
Я не знаю, что это за патч, который нельзя применить в начале файла, изменив его конец. В тех патчах, которые я делаю, всё прекрасно изменяется. Возможно, речь о том, что в патчах, которые создаёт git, контролируется время создания файла, например. Не пробовал. Но если попробую, то почему бы не заглянуть в патч для того, чтобы понять, как он работает? Разве это не логично?
Вот попробовал. Увидел то же самое, что видно и в gitk. С первого взгляда вижу, что там помимо самого патча есть некий index. В конце у него явные атрибуты файла. А перед ним два числа. Вероятно, контрольные суммы содержимого файла, так как у вновь создаваемых файлов число 0, а у двух последовательных патчей одно из чисел совпадает с числом из соседнего патча.
А вот зачем мне это? Что мешает просто взять и удалить эту строку и применить патч, если мне прям надо? inb4 Ничего не мешает. Тогда в чём вопрос?
>Как гит работает с бинарными файлами? Он отслеживает изменения в бинарных файлах частями так же как он работает с текстовыми файлами? Или же он с ними работает иначе?
Очевидно, что иначе. Пока я только добавлял бинарные файлы. Но в принципе если в бинарных файлах изменяется только несколько байт, то и для них можно сделать патч, меняющий лишь эти несколько байт. И как из этого следует, что информация в каталоге .git не заслуживает внимания? Не понимаю. Столько много вопросов, но они, по-моему, ничего не доказывают.
>Или почему в репозиториях с сабмодулями на постоянке детачатся хеады по каждому чиху?
Да хрен знает. Я вообще не понял, с какой целью их нужно использовать. А может даже не понял, что это вообще такое.
>Или как найти потерявшийся коммит или ветку коммитов? Как вообще коммит может потеряться?
Да просто потеряться. Перестали на него ссылаться - он и потерялся. А найти - просто reset на него, пока не потерялся окончательно.
>Что такое bare repo ? Чем отличается от empty repo ?
Видимо, один почти пустой, а другой совсем пустой. Не знаю. А это какое-то принципиальное знание? Оно мне зачем?
>Почему ты не можешь патч применить на любую версию файла?)
Потому что конфликты. Потому что контекст не находится. Потому что он уже изменён.
>Почему если у патч отображает изменения файла на начале файла, а в файле менялся конец, то ты не можешь применить этот патч? Он же не конфликтует изменения.
Я не знаю, что это за патч, который нельзя применить в начале файла, изменив его конец. В тех патчах, которые я делаю, всё прекрасно изменяется. Возможно, речь о том, что в патчах, которые создаёт git, контролируется время создания файла, например. Не пробовал. Но если попробую, то почему бы не заглянуть в патч для того, чтобы понять, как он работает? Разве это не логично?
Вот попробовал. Увидел то же самое, что видно и в gitk. С первого взгляда вижу, что там помимо самого патча есть некий index. В конце у него явные атрибуты файла. А перед ним два числа. Вероятно, контрольные суммы содержимого файла, так как у вновь создаваемых файлов число 0, а у двух последовательных патчей одно из чисел совпадает с числом из соседнего патча.
А вот зачем мне это? Что мешает просто взять и удалить эту строку и применить патч, если мне прям надо? inb4 Ничего не мешает. Тогда в чём вопрос?
>Как гит работает с бинарными файлами? Он отслеживает изменения в бинарных файлах частями так же как он работает с текстовыми файлами? Или же он с ними работает иначе?
Очевидно, что иначе. Пока я только добавлял бинарные файлы. Но в принципе если в бинарных файлах изменяется только несколько байт, то и для них можно сделать патч, меняющий лишь эти несколько байт. И как из этого следует, что информация в каталоге .git не заслуживает внимания? Не понимаю. Столько много вопросов, но они, по-моему, ничего не доказывают.
33 Кб, 753x491>>>This. И упаковываются в пакеты. Но я не предлагал пакеты читать как текст.
>^ Я спросил про 2 варианта. А ты мне "зис")
Я имел в виду, что изменения, но получается, что и файлы целиком, если git не умеет в патчи бинарных файлов, или если новый файл добавлен целиком.
>> А ветки и тэги это же просто текст.
>^ Понятие веток и тэгов вообще виртуальное. В гите внутри нету ни веток ни тегов. Там есть коммиты. Тэги и ветки это буквально именованные коммиты. Это как лейбочка на веревочке.
Это просто текстовые файлы, содержащие sha коммитов. Почему я и говорю, что достаточно зайти в каталог .git и просто увидеть их там, чтобы это понять.
>А когда ты ветку или тэг удаляешь - ничего из репозитория не удаляется. Из гит-репозитория в принципе никогда ничего не удаляется. Все что ты туда внес там и остается навсегда.
Сдаётся мне, что это неправда. Не далее как сегодня сделал
git reflog expire --expire=now --all
git gc --prune=now
и очень сомневаюсь, что там после этого осталось хоть что-то из не помеченного тегами или бранчами.
До этого reset на потерянный коммит работал, а после этого нет. Почему, если там по твоим словам ничего не удаляется?
>А на один и тот же коммит может быть созданно бесконечное число бранчей.
Это очевидно.
>Именно поэтому постоянно детачатся хеады. Потому что при любом чихе и малейшем изменении оно все равно ссылается на определенный коммит. Но гит не уверен - он ссылается на этот созданный бранч (на эту лейбочку), или же он ссылается на этот коммит как на отдельный неименованный бранч (детачед хеад)
Ну без сабмодулей же ничего не детачится. В каталоге .git/refs/heads лежит по одному файлу на каждую ветвь, и в каждом находится sha коммита, который на этой ветви head. А почему с сабмодулями это не работает и зачем они вообще нужны?
>>Знаю, понял. "dif koko kokokoko > koko.diff", вот и получился патч.
>^ неа, патч и дифф это разные вещи. Потому что патч включает себя как дифф, так и дополнительную информацию о файле на который он должен применятся. Ты не можешь применить дифф как патч.
Ещё как могу:
echo qwe >1
echo rty >2
diff -u ./1 ./2 >patch.diff
cat patch.diff | patch
У меня всё работает. Прилагаю пикрил. Что я делаю не так?
Может быть это гит не может применить патч без дополнительной информации о файле, но это не мешает патчу быть патчем. И его можно отдельно применить и потом закоммитить.
Вот даже цитата из мана:
patch takes a patch file patchfile containing a difference listing produced by the diff program
То есть одно и то же в зависимости от контекста называют и difference listing, и patch file.
>> Как я понял, сабмодули это отдельные репозитории, которые сами по себе коммитятся в главный репозиторий, но нафига это всё я пока не в курсе.
>^ очень полезная штука. Покопай.
Зачем? Чтобы детачились хеады? И что это даст?
>>Но не только.
>Именно что не только. Там может быть много-много-много всего. Там хранится почти все. Стеши,
Ну, стешами я не пользуюсь. Непонятно, зачем мне один стеш на все бранчи, когда в каждом можно сделать по коммиту, который в любой момент можно переделать.
>индексы, коммиты, вообще все-все-все возможные обьекты гита которые относятся к сохранению данных из воркдира в том или ином виде. Все индексы там же. А индекс - это не только информация о текущем чекауте или конфликтах. Там может быть паралельно использовано овердохрена индексов под капотом каждый из которых по-своему использует гит.
Например? На что именно ссылаются эти индексы? И зачем указание на эти (?) индексы пихать в патч?
>> .....А в коде этом команды всякие к git, с объяснениями. Потому-то я и говорю, что полезно почитать, что там изначально положено.
>^ а здесь уже наступает вопрос чем именно репозиторий был создан. Потому что разные клиенты или терминал могут эту папку создавать или не создавать. Заполнять примерами или не заполнять. Кидать туда картинки с обьяснениями или не кидать. И вот посоветуешь ты человеку туда залезть... а у него там пусто)
Я самим git и создавал. Самым дефолтным образом.
>>Я сделал вывод, что заглянув в этот каталог можно многое узнать. В том числе и ответы на вопросы, которые ты почему-то задал.
>^ мои исправления показывают что многие из твоих выводов ошибочны потому что ты поленился почитать книги)
Да, мне лень читать <i>книги</i> по гиту. Не понимаю, зачем это может быть нужно. Чтобы узнать про сабмодули, которые постоянно детачатся? Ну что мне вот это всё может дать, чего не дал мой, пусть поверхностный взгляд? Как я это смогу применять?
33 Кб, 753x491>>>This. И упаковываются в пакеты. Но я не предлагал пакеты читать как текст.
>^ Я спросил про 2 варианта. А ты мне "зис")
Я имел в виду, что изменения, но получается, что и файлы целиком, если git не умеет в патчи бинарных файлов, или если новый файл добавлен целиком.
>> А ветки и тэги это же просто текст.
>^ Понятие веток и тэгов вообще виртуальное. В гите внутри нету ни веток ни тегов. Там есть коммиты. Тэги и ветки это буквально именованные коммиты. Это как лейбочка на веревочке.
Это просто текстовые файлы, содержащие sha коммитов. Почему я и говорю, что достаточно зайти в каталог .git и просто увидеть их там, чтобы это понять.
>А когда ты ветку или тэг удаляешь - ничего из репозитория не удаляется. Из гит-репозитория в принципе никогда ничего не удаляется. Все что ты туда внес там и остается навсегда.
Сдаётся мне, что это неправда. Не далее как сегодня сделал
git reflog expire --expire=now --all
git gc --prune=now
и очень сомневаюсь, что там после этого осталось хоть что-то из не помеченного тегами или бранчами.
До этого reset на потерянный коммит работал, а после этого нет. Почему, если там по твоим словам ничего не удаляется?
>А на один и тот же коммит может быть созданно бесконечное число бранчей.
Это очевидно.
>Именно поэтому постоянно детачатся хеады. Потому что при любом чихе и малейшем изменении оно все равно ссылается на определенный коммит. Но гит не уверен - он ссылается на этот созданный бранч (на эту лейбочку), или же он ссылается на этот коммит как на отдельный неименованный бранч (детачед хеад)
Ну без сабмодулей же ничего не детачится. В каталоге .git/refs/heads лежит по одному файлу на каждую ветвь, и в каждом находится sha коммита, который на этой ветви head. А почему с сабмодулями это не работает и зачем они вообще нужны?
>>Знаю, понял. "dif koko kokokoko > koko.diff", вот и получился патч.
>^ неа, патч и дифф это разные вещи. Потому что патч включает себя как дифф, так и дополнительную информацию о файле на который он должен применятся. Ты не можешь применить дифф как патч.
Ещё как могу:
echo qwe >1
echo rty >2
diff -u ./1 ./2 >patch.diff
cat patch.diff | patch
У меня всё работает. Прилагаю пикрил. Что я делаю не так?
Может быть это гит не может применить патч без дополнительной информации о файле, но это не мешает патчу быть патчем. И его можно отдельно применить и потом закоммитить.
Вот даже цитата из мана:
patch takes a patch file patchfile containing a difference listing produced by the diff program
То есть одно и то же в зависимости от контекста называют и difference listing, и patch file.
>> Как я понял, сабмодули это отдельные репозитории, которые сами по себе коммитятся в главный репозиторий, но нафига это всё я пока не в курсе.
>^ очень полезная штука. Покопай.
Зачем? Чтобы детачились хеады? И что это даст?
>>Но не только.
>Именно что не только. Там может быть много-много-много всего. Там хранится почти все. Стеши,
Ну, стешами я не пользуюсь. Непонятно, зачем мне один стеш на все бранчи, когда в каждом можно сделать по коммиту, который в любой момент можно переделать.
>индексы, коммиты, вообще все-все-все возможные обьекты гита которые относятся к сохранению данных из воркдира в том или ином виде. Все индексы там же. А индекс - это не только информация о текущем чекауте или конфликтах. Там может быть паралельно использовано овердохрена индексов под капотом каждый из которых по-своему использует гит.
Например? На что именно ссылаются эти индексы? И зачем указание на эти (?) индексы пихать в патч?
>> .....А в коде этом команды всякие к git, с объяснениями. Потому-то я и говорю, что полезно почитать, что там изначально положено.
>^ а здесь уже наступает вопрос чем именно репозиторий был создан. Потому что разные клиенты или терминал могут эту папку создавать или не создавать. Заполнять примерами или не заполнять. Кидать туда картинки с обьяснениями или не кидать. И вот посоветуешь ты человеку туда залезть... а у него там пусто)
Я самим git и создавал. Самым дефолтным образом.
>>Я сделал вывод, что заглянув в этот каталог можно многое узнать. В том числе и ответы на вопросы, которые ты почему-то задал.
>^ мои исправления показывают что многие из твоих выводов ошибочны потому что ты поленился почитать книги)
Да, мне лень читать <i>книги</i> по гиту. Не понимаю, зачем это может быть нужно. Чтобы узнать про сабмодули, которые постоянно детачатся? Ну что мне вот это всё может дать, чего не дал мой, пусть поверхностный взгляд? Как я это смогу применять?
Вопрос очень косвенно связанный с гитом. Пишу тут программку, которую автор уже пару лет не обновляет. Пул-реквест я ему тогда отправлял, так и висел не закрытым, пока не потерял актуальность. В общем, я теперь ту программку сам ощутимо доделал. Точнее, уже два человека по всякому её доделали, а я объединил всё и тоже чуть доделал и сделал всё совсем красиво. Так вот, там в readme указана ссылка на гитхаб первоначального автора. Но там старая версия лежит, без тех фич, который он планировал, а мы сделали.
Так вот, уместно ли в его readme ссылку на его гитхаб заменить ссылкой на мой гитхаб, учитывая, что я не первоначальный автор?
И как при этом сделать так, чтобы не получилось так, что я предлагаю автору забрать мои изменения вместе с изменением его readme? Ведь если он всё-таки запулит их себе, то ссылку уместно оставить на первоначальный гит.
Как принято вообще в этом вашем опенсорсе, я не понимаю.
И вот, допустим, в программе одной опенсорсной иконки используются. Я часть из них забрал не воровства ради, а чтобы в другой программе, которая одновременно с той используется, всё выглядело однообразно, красоты ради. Об этом по-хорошему надо где-то упоминать, или просто тихо спиздил и пошёл, называется нашёл? Ну понятно, что они оттуда же. Я на авторство конкретно этих картинок не претендую, не в них дело, а чтобы красиво было и удобно. А то когда одно и то же в разных окнах обозначается разными картинками - это лишний напряг для мозгов.
И ещё вопрос до кучи сразу, если я вырезал где-то в опенсорсе кусок кода, допустим, пять строк. Мелочь, ну все же копипастят. Ну вот, и использовал у себя, это как считается, красиво или некрасиво? Ну не указывать же источник каждой отдельной строки, где я сделал Ctrl-C?
>по-хорошему надо где-то упоминать
Если делаешь проект для себя и пары друзяшек, то забей. Если на какую-то аудиторию рассчитываешь, то лучше упоминать. За каждую строчку кода и иконку пояснять необязательно, но просто приложить список вида "вдохновлялся тем-то и там-то" - стоит.
Если же планируешь хоть какой-то доход поиметь, то следить за лицензионной чистотой кода и ресурсов крайне рекомендуется.
А еще есть вещи которые в принципе не стоит трогать, даже если ты хочешь это в полный опенсорц отпустить и совершенно бесплатно выкладывать - отымеют.
>А еще есть вещи которые в принципе не стоит трогать, даже если ты хочешь это в полный опенсорц отпустить и совершенно бесплатно выкладывать - отымеют.
Например?
ты сейчас про модули что-ли?
git clone и так дергает все. не могу даже вспомнить времен когда не дергал.
возможно, ты где-то затупил в консольке.
TortoiseGit
Не. Вот смотри. Делаю я git clone, получаю реп. Залезаю в реп там куча веток. Делаю checkout на открытую ветку и каждый мне приходится после этого делать pull, потому как ее содержимое не подтягивается сразу при клонировании. И так с каждой. Git fetch --all и git pull -all не помогают. Т.е. если я хочу допустим полный клон репа сделать, то мне каждую ветку нужно по отдельности вытягивать. В меркуриале например, делая клон репа, по умолчанию ты скачиваешь его локально со всем говном, что мне и нужно, а в гите не так.
ты наверное неправильно переключаешься и забываешь что ветки называются origin/remote-branch-name
В консольке работай. Там все ок.
Что-то ты неправильно делаешь. clone вытаскивает все. Ты случайно на другую ветку с флагом -b переключаешься?)
Вот пример, который точно работает:
git clone
git checkout branch-name
На сколько я понял твой вопрос -- клонируя репозиторий ты получаешь все.
Ты просто не трекаешь ветки которые удаленно лежат. Но информация по тех ветках лежит у тебя в репозитории локальном. И фетч алл да пулл алл делают именно то что должны делать - они обновляют исключительно затреканные бранчи.
Вобщем - просто трекни необходимые бранчи и только потом делай пулл алл и не будет проблем.
На сколько я понял твой вопрос -- клонируя репозиторий ты получаешь все.
Ты просто не трекаешь ветки которые удаленно лежат. Но информация по тех ветках лежит у тебя в репозитории локальном. И фетч алл да пулл алл делают именно то что должны делать - они обновляют исключительно затреканные бранчи.
Вобщем - просто трекни необходимые бранчи и только потом делай пулл алл и не будет проблем.
т.к. не уверен что ты правильно понял предыдущее сообщение
Перефразирую:
1. У тебя все склонировано и все лежит локально. Абсолютно все.
2. Просто нет информации о бранчах. Вот эту информацию и затрекай.
>Я имел в виду, что изменения, но получается, что и файлы целиком, если git не умеет в патчи бинарных файлов, или если новый файл добавлен целиком.
^ В случае текстовых файлов - только файлы целиком.
А вот по поводу бинарников не уверен - вероятее всего они как раз измененными кусками и сохраняются.
> Сдаётся мне, что это неправда. Не далее как сегодня сделал
^ окей, про это забыл. Ты прав. Иногда удалить можно, но только начиная с последних коммитов ветки дерева и вниз(что ты и сделал).
Но с середины ты ничего удалить не можешь.
>Ну без сабмодулей же ничего не детачится. В каталоге .git/refs/heads лежит по одному файлу на каждую ветвь, и в каждом находится sha коммита, который на этой ветви head. А почему с сабмодулями это не работает и зачем они вообще нужны?
^ Сабмодули нужны если есть части кода которые ты используешь в разных проэктах. Допустим у тебя есть некий фреймворк который ты используешь еще в 2х проэктах кроме этого. И тогда это должно быть отдельным репозиторием который приаттачен к этим 3м проэктам которые должны использовать этот же фреймворк. Это дает возможность изменять этот "сабмодуль" в одном месте, а получать обновления во всех 3х использующих этот код репозиториях. Или, например, если ты используешь чужой репозиторий который автор периодически обновляет. Тогда ты не застрянешь на той стадии когда ты склонировал себе ссорцы а будешь без проблем обновлятся по мере необходимости.
Почему не работает - да потому что при чекауте какого-то коммита родительского репозитория он как дебил умышленно детачит хеады дочерних репозиториев чисто на перебдеть. Ты собираешься вносить изменения в родительский репозиторий, значит типа ты собираешься вносить изменения и в дочерние. Других предположений у меня нет. Но факт остается фактом - детачатся хеады при каждом чихе. И это не только про чекауты.
> У меня всё работает. Прилагаю пикрил. Что я делаю не так?
^ вероятно применяешь изменения на весь файл, а не на кусок
>Вот даже цитата из мана:
patch takes a patch file patchfile containing a difference listing produced by the diff program
То есть одно и то же в зависимости от контекста называют и difference listing, и patch file.
^ Влом искать пруф из документации, но патч должен содержать заголовок в котором прописывается относительный путь(вообще 2 - до и после), тип файла (текстовый или бинарный), а так же его хеши до изменений и после изменений. Это сделано для того, что бы ты мог применить патч исключительно на тот файл, с которого он был взят. В том состоянии, с которого он был сгенерирован. Но после малейшего изменения в файле в любом месте уже не мог бы применить этот патч. Потому что это потенциально опасная ситуация, в которой ты поломаешь себе проэкт, от чего гит тебя уберегает.
Вот приблизительный заголовок патча:
diff --git a/file.swift b/file.swift
index 5bbee42..f9b3d72 100644
--- a/file.swift
+++ b/file.swift
где 100644 - указывает что это текстовый файл, а 5bbee42..f9b3d72 - это чексуммы которые должны быть у файла до и после применения пата. А количество плюсиков и минусиков в нижних строках косвенно указывает на количество изменений в файле. (количество изменений в ханках).
Я эту инфу когда-то брал из документации, а не придумал сам, уж поверь)
И кстате патч сохраняется с расширением .patch :) А ты применяешь дифф имеющий расширение .diff . Я вот не знал что можно применять дифы вместо патчей :) Хотя возможно это от библиотеки и от версии гита зависит.
>Я имел в виду, что изменения, но получается, что и файлы целиком, если git не умеет в патчи бинарных файлов, или если новый файл добавлен целиком.
^ В случае текстовых файлов - только файлы целиком.
А вот по поводу бинарников не уверен - вероятее всего они как раз измененными кусками и сохраняются.
> Сдаётся мне, что это неправда. Не далее как сегодня сделал
^ окей, про это забыл. Ты прав. Иногда удалить можно, но только начиная с последних коммитов ветки дерева и вниз(что ты и сделал).
Но с середины ты ничего удалить не можешь.
>Ну без сабмодулей же ничего не детачится. В каталоге .git/refs/heads лежит по одному файлу на каждую ветвь, и в каждом находится sha коммита, который на этой ветви head. А почему с сабмодулями это не работает и зачем они вообще нужны?
^ Сабмодули нужны если есть части кода которые ты используешь в разных проэктах. Допустим у тебя есть некий фреймворк который ты используешь еще в 2х проэктах кроме этого. И тогда это должно быть отдельным репозиторием который приаттачен к этим 3м проэктам которые должны использовать этот же фреймворк. Это дает возможность изменять этот "сабмодуль" в одном месте, а получать обновления во всех 3х использующих этот код репозиториях. Или, например, если ты используешь чужой репозиторий который автор периодически обновляет. Тогда ты не застрянешь на той стадии когда ты склонировал себе ссорцы а будешь без проблем обновлятся по мере необходимости.
Почему не работает - да потому что при чекауте какого-то коммита родительского репозитория он как дебил умышленно детачит хеады дочерних репозиториев чисто на перебдеть. Ты собираешься вносить изменения в родительский репозиторий, значит типа ты собираешься вносить изменения и в дочерние. Других предположений у меня нет. Но факт остается фактом - детачатся хеады при каждом чихе. И это не только про чекауты.
> У меня всё работает. Прилагаю пикрил. Что я делаю не так?
^ вероятно применяешь изменения на весь файл, а не на кусок
>Вот даже цитата из мана:
patch takes a patch file patchfile containing a difference listing produced by the diff program
То есть одно и то же в зависимости от контекста называют и difference listing, и patch file.
^ Влом искать пруф из документации, но патч должен содержать заголовок в котором прописывается относительный путь(вообще 2 - до и после), тип файла (текстовый или бинарный), а так же его хеши до изменений и после изменений. Это сделано для того, что бы ты мог применить патч исключительно на тот файл, с которого он был взят. В том состоянии, с которого он был сгенерирован. Но после малейшего изменения в файле в любом месте уже не мог бы применить этот патч. Потому что это потенциально опасная ситуация, в которой ты поломаешь себе проэкт, от чего гит тебя уберегает.
Вот приблизительный заголовок патча:
diff --git a/file.swift b/file.swift
index 5bbee42..f9b3d72 100644
--- a/file.swift
+++ b/file.swift
где 100644 - указывает что это текстовый файл, а 5bbee42..f9b3d72 - это чексуммы которые должны быть у файла до и после применения пата. А количество плюсиков и минусиков в нижних строках косвенно указывает на количество изменений в файле. (количество изменений в ханках).
Я эту инфу когда-то брал из документации, а не придумал сам, уж поверь)
И кстате патч сохраняется с расширением .patch :) А ты применяешь дифф имеющий расширение .diff . Я вот не знал что можно применять дифы вместо патчей :) Хотя возможно это от библиотеки и от версии гита зависит.
>>227135
>Я имел в виду, что изменения, но получается, что и файлы целиком, если git не умеет в патчи бинарных файлов, или если новый файл добавлен целиком.
^ В случае текстовых файлов - только файлы целиком.
А вот по поводу бинарников не уверен - вероятее всего они как раз измененными кусками и сохраняются.
> Сдаётся мне, что это неправда. Не далее как сегодня сделал
^ окей, про это забыл. Ты прав. Иногда удалить можно, но только начиная с последних коммитов ветки дерева и вниз(что ты и сделал).
Но с середины ты ничего удалить не можешь.
>Ну без сабмодулей же ничего не детачится. В каталоге .git/refs/heads лежит по одному файлу на каждую ветвь, и в каждом находится sha коммита, который на этой ветви head. А почему с сабмодулями это не работает и зачем они вообще нужны?
^ Сабмодули нужны если есть части кода которые ты используешь в разных проэктах. Допустим у тебя есть некий фреймворк который ты используешь еще в 2х проэктах кроме этого. И тогда это должно быть отдельным репозиторием который приаттачен к этим 3м проэктам которые должны использовать этот же фреймворк. Это дает возможность изменять этот "сабмодуль" в одном месте, а получать обновления во всех 3х использующих этот код репозиториях. Или, например, если ты используешь чужой репозиторий который автор периодически обновляет. Тогда ты не застрянешь на той стадии когда ты склонировал себе ссорцы а будешь без проблем обновлятся по мере необходимости.
Почему не работает - да потому что при чекауте какого-то коммита родительского репозитория он как дебил умышленно детачит хеады дочерних репозиториев чисто на перебдеть. Ты собираешься вносить изменения в родительский репозиторий, значит типа ты собираешься вносить изменения и в дочерние. Других предположений у меня нет. Но факт остается фактом - детачатся хеады при каждом чихе. И это не только про чекауты.
> У меня всё работает. Прилагаю пикрил. Что я делаю не так?
^ вероятно применяешь изменения на весь файл, а не на кусок
>Вот даже цитата из мана:
patch takes a patch file patchfile containing a difference listing produced by the diff program
То есть одно и то же в зависимости от контекста называют и difference listing, и patch file.
^ Влом искать пруф из документации, но патч должен содержать заголовок в котором прописывается относительный путь(вообще 2 - до и после), тип файла (текстовый или бинарный), а так же его хеши до изменений и после изменений. Это сделано для того, что бы ты мог применить патч исключительно на тот файл, с которого он был взят. В том состоянии, с которого он был сгенерирован. Но после малейшего изменения в файле в любом месте уже не мог бы применить этот патч. Потому что это потенциально опасная ситуация, в которой ты поломаешь себе проэкт, от чего гит тебя уберегает.
Вот приблизительный заголовок патча:
diff --git a/file.swift b/file.swift
index 5bbee42..f9b3d72 100644
--- a/file.swift
+++ b/file.swift
где 100644 - указывает что это текстовый файл, а 5bbee42..f9b3d72 - это чексуммы которые должны быть у файла до и после применения пата. А количество плюсиков и минусиков в нижних строках косвенно указывает на количество изменений в файле. (количество изменений в ханках).
Я эту инфу когда-то брал из документации, а не придумал сам, уж поверь)
И кстате патч сохраняется с расширением .patch :) А ты применяешь дифф имеющий расширение .diff . Я вот не знал что можно применять дифы вместо патчей :) Хотя возможно это от библиотеки и от версии гита зависит.
>>227135
>Я имел в виду, что изменения, но получается, что и файлы целиком, если git не умеет в патчи бинарных файлов, или если новый файл добавлен целиком.
^ В случае текстовых файлов - только файлы целиком.
А вот по поводу бинарников не уверен - вероятее всего они как раз измененными кусками и сохраняются.
> Сдаётся мне, что это неправда. Не далее как сегодня сделал
^ окей, про это забыл. Ты прав. Иногда удалить можно, но только начиная с последних коммитов ветки дерева и вниз(что ты и сделал).
Но с середины ты ничего удалить не можешь.
>Ну без сабмодулей же ничего не детачится. В каталоге .git/refs/heads лежит по одному файлу на каждую ветвь, и в каждом находится sha коммита, который на этой ветви head. А почему с сабмодулями это не работает и зачем они вообще нужны?
^ Сабмодули нужны если есть части кода которые ты используешь в разных проэктах. Допустим у тебя есть некий фреймворк который ты используешь еще в 2х проэктах кроме этого. И тогда это должно быть отдельным репозиторием который приаттачен к этим 3м проэктам которые должны использовать этот же фреймворк. Это дает возможность изменять этот "сабмодуль" в одном месте, а получать обновления во всех 3х использующих этот код репозиториях. Или, например, если ты используешь чужой репозиторий который автор периодически обновляет. Тогда ты не застрянешь на той стадии когда ты склонировал себе ссорцы а будешь без проблем обновлятся по мере необходимости.
Почему не работает - да потому что при чекауте какого-то коммита родительского репозитория он как дебил умышленно детачит хеады дочерних репозиториев чисто на перебдеть. Ты собираешься вносить изменения в родительский репозиторий, значит типа ты собираешься вносить изменения и в дочерние. Других предположений у меня нет. Но факт остается фактом - детачатся хеады при каждом чихе. И это не только про чекауты.
> У меня всё работает. Прилагаю пикрил. Что я делаю не так?
^ вероятно применяешь изменения на весь файл, а не на кусок
>Вот даже цитата из мана:
patch takes a patch file patchfile containing a difference listing produced by the diff program
То есть одно и то же в зависимости от контекста называют и difference listing, и patch file.
^ Влом искать пруф из документации, но патч должен содержать заголовок в котором прописывается относительный путь(вообще 2 - до и после), тип файла (текстовый или бинарный), а так же его хеши до изменений и после изменений. Это сделано для того, что бы ты мог применить патч исключительно на тот файл, с которого он был взят. В том состоянии, с которого он был сгенерирован. Но после малейшего изменения в файле в любом месте уже не мог бы применить этот патч. Потому что это потенциально опасная ситуация, в которой ты поломаешь себе проэкт, от чего гит тебя уберегает.
Вот приблизительный заголовок патча:
diff --git a/file.swift b/file.swift
index 5bbee42..f9b3d72 100644
--- a/file.swift
+++ b/file.swift
где 100644 - указывает что это текстовый файл, а 5bbee42..f9b3d72 - это чексуммы которые должны быть у файла до и после применения пата. А количество плюсиков и минусиков в нижних строках косвенно указывает на количество изменений в файле. (количество изменений в ханках).
Я эту инфу когда-то брал из документации, а не придумал сам, уж поверь)
И кстате патч сохраняется с расширением .patch :) А ты применяешь дифф имеющий расширение .diff . Я вот не знал что можно применять дифы вместо патчей :) Хотя возможно это от библиотеки и от версии гита зависит.
Дифы же в чистом виде не должны иметь заголовка патча. Хз что у тебя в том файле ".diff" но вероятнее всего там заголовка патча нет. Именно заголовком патч от дифа и отличается ибо дифф показывает исключительно дифф
51 Кб, 869x608>>Я имел в виду, что изменения, но получается, что и файлы целиком, если git не умеет в патчи бинарных файлов, или если новый файл добавлен целиком.
>^ В случае текстовых файлов - только файлы целиком.
Я загуглил, и это действительно так. Хм, я был уверен в обратном.
>> Сдаётся мне, что это неправда. Не далее как сегодня сделал
>^ окей, про это забыл. Ты прав. Иногда удалить можно, но только начиная с последних коммитов ветки дерева и вниз(что ты и сделал).
>Но с середины ты ничего удалить не можешь.
Я так понимаю, что дело не в последовательности добавления коммитов, а в том, что у коммита нет помеченных (бранчами и тегами) потомков, которые на него ссылаются. Соответственно, если из середины вырастает ветка, которую мы удаляем, и если эта ветка не имеет помеченных потомков, то она может быть полностью удалена.
При этом, я так понимаю, что если из середины потребовалось выкинуть коммит, то можно сделать рибейз, и более новые коммиты приделать к более старым, минуя данный, или, например, просто удалить строчку с pick <sha> <descr> из списка для ребейза, либо сделать ей fixup, то некоторые исходные коммиты выкидывается из цепочки. Да вообще все они выкидываются из цепочки при ребейзе, начиная с первого изменённого коммита. А потом уже все они могут быть выкинуты и из reflog-а, а значит и могут быть стёрты окончательно.
>^ Сабмодули нужны если есть части кода которые ты используешь в разных проэктах. Допустим у тебя есть некий фреймворк который ты используешь еще в 2х проэктах кроме этого. И тогда это должно быть отдельным репозиторием который приаттачен к этим 3м проэктам которые должны использовать этот же фреймворк. Это дает возможность изменять этот "сабмодуль" в одном месте, а получать обновления во всех 3х использующих этот код репозиториях.
Да, это нужная вещь.
>Почему не работает - да потому что при чекауте какого-то коммита родительского репозитория он как дебил умышленно детачит хеады дочерних репозиториев чисто на перебдеть. Ты собираешься вносить изменения в родительский репозиторий, значит типа ты собираешься вносить изменения и в дочерние. Других предположений у меня нет. Но факт остается фактом - детачатся хеады при каждом чихе. И это не только про чекауты.
И при обратном переходе на ветку в родительском репозитарии в дочерних хеады обратно не приаттачиваются? Это, наверное, логично, ведь там свои собственные ветки. Но тогда зачем гит их детачит? Странно.
>> У меня всё работает. Прилагаю пикрил. Что я делаю не так?
>^ вероятно применяешь изменения на весь файл, а не на кусок
Пожалуйста, другой пикрил.
>>Вот даже цитата из мана:
>patch takes a patch file patchfile containing a difference listing produced by the diff program
>>То есть одно и то же в зависимости от контекста называют и difference listing, и patch file.
>^ Влом искать пруф из документации, но патч должен содержать заголовок в котором прописывается относительный путь(вообще 2 - до и после), тип файла (текстовый или бинарный), а так же его хеши до изменений и после изменений.
В документации чего? Гита? Но ведь патчи существовали и до гита. Путь я указываю, при чём путь "после" командой patch игнорируется. Там ещё автоматически и время создания файла указывается для каждой из версий, но и его можно просто удалить из патча, и строку с +++ можно удалить целиком.
И можно вообще вручную написать патч. Например, если тебе нужно пропатчить единственную строку в системном конфиге, то можно это сделать так:
sudo patch -p0 -d/ << EOF
--- /config.file
@@ -100,1 +100,1 @@
-lang=en
+lang=ru
EOF
При чём, если lang=en вдруг окажется не в сотой строке, а, скажем, в девяносто девятой, патч всё равно прекрасно отработает. А если его попытаться применить повторно, то патчилка предложит сделать реверс.
> Это сделано для того, что бы ты мог применить патч исключительно на тот файл, с которого он был взят. В том состоянии, с которого он был сгенерирован.
Но ведь это может излишне ограничивать функционал. Например, как я выше описал, можно изменить единственную строку lang=en на lang=ru. Почему бы не сделать это патчем?
>Но после малейшего изменения в файле в любом месте уже не мог бы применить этот патч. Потому что это потенциально опасная ситуация, в которой ты поломаешь себе проэкт, от чего гит тебя уберегает.
Не в случае, когда надо лишь разово поменять одну строчку в конфиге с простой линейной структурой, где каждое значение встречается и задаётся только один раз. Я понимаю, почему в гите сделано иначе. Ибо это система контроля версий, а не средство для создания патчей. А патчи это в моём представлении нечто другое, отдельное понятие, мало связанное с гитом.
>Вот приблизительный заголовок патча:
>diff --git a/file.swift b/file.swift
>--git
У diff вообще нет такого параметра. То есть у гита какой-то свой собственный diff, отличный от того, что лежит в /usr/bin/diff
>index 5bbee42..f9b3d72 100644
>--- a/file.swift
>+++ b/file.swift
>где 100644 - указывает что это текстовый файл, а 5bbee42..f9b3d72 - это чексуммы которые должны быть у файла до и после применения пата.
Точно чексуммы? Почему они тогда называются индексом? Они используются в качестве такового? А коллизий с ними, случайно, произойти не может? Ведь если использовать их исключительно как чексуммы, то коллизии фактически ни на что не повлияют, а вот если использовать как ключи для поиска каких-то дополнительных данных о состоянии, то коллизия гипотетически может плохо кончиться.
>А количество плюсиков и минусиков в нижних строках косвенно указывает на количество изменений в файле. (количество изменений в ханках).
Не знаю, как в документации, но на практике я видел исключительно группы из трёх минусиков и плюсиков.
Три минуса и три плюса указывают на то, что дальше написаны имена исходного и конечного файла. Дальше идут ханки (?), начинающиеся со строчки @@, в них пишется номер начальной строки контекста, количество строк в нём, затем те же числа, но после изменения. Далее идут строки контекста, начинающиеся с пробела, они не изменяются, а служат исключительно для поиска правильного фрагмента в большом тексте. Те строки, которые должны быть удалены, начинаются с минуса, добавляемые с плюса. При этом контекст, как сказано выше, может и отсутствовать, то есть можно просто удалить строку и вставить на то же место другую, не заботясь о том, какое будет окружение у этой строки.
>Я эту инфу когда-то брал из документации, а не придумал сам, уж поверь)
Допустим. Но тогда получается, что практика немного отличается от документации?
>И кстате патч сохраняется с расширением .patch :) А ты применяешь дифф имеющий расширение .diff .
Это же линукс. Тут нет такого понятия "расширение". Тут есть понятие "тип mime". Я могу патч хоть джипегом обозвать, а расширение указал просто для указания на то, что он создан программой diff.
>Я вот не знал что можно применять дифы вместо патчей :) Хотя возможно это от библиотеки и от версии гита зависит.
Ну гит-то тут ни при чём. diff и patch это стандартные команды в линуксе, существующие ещё с незапамятных времён (ещё при Брежневе diff уже была). Насколько я помню, они даже в досе были. Ну который ms dos.
https://ru.wikipedia.org/wiki/Diff
Кстати, вот и тут указание на то, что диффом и патчем называют одно и то же:
Вывод утилиты называется «diff», или, что более распространено, патч, так как он может быть применён с программой patch.
51 Кб, 869x608>>Я имел в виду, что изменения, но получается, что и файлы целиком, если git не умеет в патчи бинарных файлов, или если новый файл добавлен целиком.
>^ В случае текстовых файлов - только файлы целиком.
Я загуглил, и это действительно так. Хм, я был уверен в обратном.
>> Сдаётся мне, что это неправда. Не далее как сегодня сделал
>^ окей, про это забыл. Ты прав. Иногда удалить можно, но только начиная с последних коммитов ветки дерева и вниз(что ты и сделал).
>Но с середины ты ничего удалить не можешь.
Я так понимаю, что дело не в последовательности добавления коммитов, а в том, что у коммита нет помеченных (бранчами и тегами) потомков, которые на него ссылаются. Соответственно, если из середины вырастает ветка, которую мы удаляем, и если эта ветка не имеет помеченных потомков, то она может быть полностью удалена.
При этом, я так понимаю, что если из середины потребовалось выкинуть коммит, то можно сделать рибейз, и более новые коммиты приделать к более старым, минуя данный, или, например, просто удалить строчку с pick <sha> <descr> из списка для ребейза, либо сделать ей fixup, то некоторые исходные коммиты выкидывается из цепочки. Да вообще все они выкидываются из цепочки при ребейзе, начиная с первого изменённого коммита. А потом уже все они могут быть выкинуты и из reflog-а, а значит и могут быть стёрты окончательно.
>^ Сабмодули нужны если есть части кода которые ты используешь в разных проэктах. Допустим у тебя есть некий фреймворк который ты используешь еще в 2х проэктах кроме этого. И тогда это должно быть отдельным репозиторием который приаттачен к этим 3м проэктам которые должны использовать этот же фреймворк. Это дает возможность изменять этот "сабмодуль" в одном месте, а получать обновления во всех 3х использующих этот код репозиториях.
Да, это нужная вещь.
>Почему не работает - да потому что при чекауте какого-то коммита родительского репозитория он как дебил умышленно детачит хеады дочерних репозиториев чисто на перебдеть. Ты собираешься вносить изменения в родительский репозиторий, значит типа ты собираешься вносить изменения и в дочерние. Других предположений у меня нет. Но факт остается фактом - детачатся хеады при каждом чихе. И это не только про чекауты.
И при обратном переходе на ветку в родительском репозитарии в дочерних хеады обратно не приаттачиваются? Это, наверное, логично, ведь там свои собственные ветки. Но тогда зачем гит их детачит? Странно.
>> У меня всё работает. Прилагаю пикрил. Что я делаю не так?
>^ вероятно применяешь изменения на весь файл, а не на кусок
Пожалуйста, другой пикрил.
>>Вот даже цитата из мана:
>patch takes a patch file patchfile containing a difference listing produced by the diff program
>>То есть одно и то же в зависимости от контекста называют и difference listing, и patch file.
>^ Влом искать пруф из документации, но патч должен содержать заголовок в котором прописывается относительный путь(вообще 2 - до и после), тип файла (текстовый или бинарный), а так же его хеши до изменений и после изменений.
В документации чего? Гита? Но ведь патчи существовали и до гита. Путь я указываю, при чём путь "после" командой patch игнорируется. Там ещё автоматически и время создания файла указывается для каждой из версий, но и его можно просто удалить из патча, и строку с +++ можно удалить целиком.
И можно вообще вручную написать патч. Например, если тебе нужно пропатчить единственную строку в системном конфиге, то можно это сделать так:
sudo patch -p0 -d/ << EOF
--- /config.file
@@ -100,1 +100,1 @@
-lang=en
+lang=ru
EOF
При чём, если lang=en вдруг окажется не в сотой строке, а, скажем, в девяносто девятой, патч всё равно прекрасно отработает. А если его попытаться применить повторно, то патчилка предложит сделать реверс.
> Это сделано для того, что бы ты мог применить патч исключительно на тот файл, с которого он был взят. В том состоянии, с которого он был сгенерирован.
Но ведь это может излишне ограничивать функционал. Например, как я выше описал, можно изменить единственную строку lang=en на lang=ru. Почему бы не сделать это патчем?
>Но после малейшего изменения в файле в любом месте уже не мог бы применить этот патч. Потому что это потенциально опасная ситуация, в которой ты поломаешь себе проэкт, от чего гит тебя уберегает.
Не в случае, когда надо лишь разово поменять одну строчку в конфиге с простой линейной структурой, где каждое значение встречается и задаётся только один раз. Я понимаю, почему в гите сделано иначе. Ибо это система контроля версий, а не средство для создания патчей. А патчи это в моём представлении нечто другое, отдельное понятие, мало связанное с гитом.
>Вот приблизительный заголовок патча:
>diff --git a/file.swift b/file.swift
>--git
У diff вообще нет такого параметра. То есть у гита какой-то свой собственный diff, отличный от того, что лежит в /usr/bin/diff
>index 5bbee42..f9b3d72 100644
>--- a/file.swift
>+++ b/file.swift
>где 100644 - указывает что это текстовый файл, а 5bbee42..f9b3d72 - это чексуммы которые должны быть у файла до и после применения пата.
Точно чексуммы? Почему они тогда называются индексом? Они используются в качестве такового? А коллизий с ними, случайно, произойти не может? Ведь если использовать их исключительно как чексуммы, то коллизии фактически ни на что не повлияют, а вот если использовать как ключи для поиска каких-то дополнительных данных о состоянии, то коллизия гипотетически может плохо кончиться.
>А количество плюсиков и минусиков в нижних строках косвенно указывает на количество изменений в файле. (количество изменений в ханках).
Не знаю, как в документации, но на практике я видел исключительно группы из трёх минусиков и плюсиков.
Три минуса и три плюса указывают на то, что дальше написаны имена исходного и конечного файла. Дальше идут ханки (?), начинающиеся со строчки @@, в них пишется номер начальной строки контекста, количество строк в нём, затем те же числа, но после изменения. Далее идут строки контекста, начинающиеся с пробела, они не изменяются, а служат исключительно для поиска правильного фрагмента в большом тексте. Те строки, которые должны быть удалены, начинаются с минуса, добавляемые с плюса. При этом контекст, как сказано выше, может и отсутствовать, то есть можно просто удалить строку и вставить на то же место другую, не заботясь о том, какое будет окружение у этой строки.
>Я эту инфу когда-то брал из документации, а не придумал сам, уж поверь)
Допустим. Но тогда получается, что практика немного отличается от документации?
>И кстате патч сохраняется с расширением .patch :) А ты применяешь дифф имеющий расширение .diff .
Это же линукс. Тут нет такого понятия "расширение". Тут есть понятие "тип mime". Я могу патч хоть джипегом обозвать, а расширение указал просто для указания на то, что он создан программой diff.
>Я вот не знал что можно применять дифы вместо патчей :) Хотя возможно это от библиотеки и от версии гита зависит.
Ну гит-то тут ни при чём. diff и patch это стандартные команды в линуксе, существующие ещё с незапамятных времён (ещё при Брежневе diff уже была). Насколько я помню, они даже в досе были. Ну который ms dos.
https://ru.wikipedia.org/wiki/Diff
Кстати, вот и тут указание на то, что диффом и патчем называют одно и то же:
Вывод утилиты называется «diff», или, что более распространено, патч, так как он может быть применён с программой patch.
93 Кб, 867x604Ну, в man diff, в man patch и в википедии сказано, что диффом и патчем называют одно и то же. А вы утверждаете иное. Конечно же, man diff ошибается, man patch ошибается, википедия ну уж само собой ясное дело тоже ничего не понимает, а вы точно знаете, что diff и patch это совершенно разные понятия, потому что в документации гита, который был создан в 2005 году так якобы сказано про diff, который был опубликован в 1974.
Ну не убедительно...
Выделил на скриншоте. Не вижу, чтобы из этого мана следовало, что дифф и патч надо считать принципиально разными понятиями. Когда патч автоматически создаётся утилитой diff - это "difference listing". Когда он применяется в качестве патча - это патч. При этом никаких дополнительных заголовков (по крайней мере в универсальном формате) команде patch не требуется. Более того, строку с +++ можно просто удалить, и патч прекрасно продолжит работать. Ну, или если вам угодно - дифф в качестве патча прекрасно продолжит работать.
А на счёт того, есть ли у меня в diff заголовок патча, во-первых, я привёл команды, которые использовал перед скриншотом, чтобы можно было просто повторить их и посмотреть, что получится в результате. Во-вторых, вот тут я уже специально сделал cat patch.diff, чтобы было ясно, что там внутри получается. Всё там есть, и что надо, и что не надо. Это называется "универсальный формат diff", который появился в 1990 году. За 15 лет до появления git. Торвальдс просто взял за основу классический формат, когда создавал git.
Есть ещё специальный вывод diff для бинарных файлов, который отдельные байтики меняет. И он тоже применяется той же командой patch. И тоже без каких-либо дополнительных правок заголовков, насколько я помню.
670 Кб, 1206x1534это после клона ты указываешь за каким бранчами тебе нужно следить локально. Эта процедура отдельная так как большинству пользователей гита нет необходимости клонировать информацию о всех бранчах.
Как трекать? Ну вот например через юай тавера вот так как на картинке. Как в случае консоли хз - гугли
потому что она не нужна всем пользователям. Каждый пользователь гит-репозитория сам решает какие бранчи ему нужны. Но бранчи - это "виртуальное понятие". Это лишь именованные ссылки на коммиты. Сами же коммиты все до единого у тебя копируются при клонировании.
>Почему не работает - да потому что при чекауте какого-то коммита родительского репозитория он как дебил умышленно детачит хеады дочерних репозиториев чисто на перебдеть. Ты собираешься вносить изменения в родительский репозиторий, значит типа ты собираешься вносить изменения и в дочерние. Других предположений у меня нет. Но факт остается фактом - детачатся хеады при каждом чихе. И это не только про чекауты.
Я вот обнаружил, что и не пользуюсь чекаутами. Только reset (через гуй). И вообще мне не очень понятно, зачем может быть именно детачед head. С него же всё равно не стоит куда-то переходить, не оставив пометки на хвост, хоть её и нетрудно будет снова отыскать. Так почему бы не сделать сразу новую ветку и не сбросить её на нужный коммит вместо чекаута?
При резете-то хеады в сабмодулях не детачатся?
152 Кб, 1066x356>И при обратном переходе на ветку в родительском репозитарии в дочерних хеады обратно не приаттачиваются?
^ А вот не скажу. Вероятнее всего не приатачивается потому что до конца не уверен. Вобщем, единственный гит клиент который я встречал что бы это фиксил - таогит. У всех остальных хеады детачатся на постоянке.
>Например, как я выше описал, можно изменить единственную строку lang=en на lang=ru. Почему бы не сделать это патчем?
^ Могу лишь догадываться: Приблизительно потому, почему в шарпе отказались от прямых ссылок на переменные - это не безопасно) Хотя в шарпе это ограничение можно обойти включив небезопасный код) Только это вряд ли хорошая идея
>Точно чексуммы? Почему они тогда называются индексом?
^ мне влом искать документацию. Но по моей памяти именно что чексуммы. В любом случае если любое из этих значений не сойдется - патч не будет применен.
> Допустим. Но тогда получается, что практика немного отличается от документации?
^ вероятно зависит от версии гита и от использованной библиотеки. Или от их настроек. Например тавер патчи без заголовка применять не будет. Выдаст тебе ошибку о том что патчи без заголовков применять нельзя. Картинка прилагается.
> Конечно же, man diff ошибается, man patch ошибается, википедия ну уж само собой ясное дело тоже ничего не понимает, а вы точно знаете, что diff и patch это совершенно разные понятия, потому что в документации гита, который был создан в 2005 году
^ 1. Потому что патч может состоять из множества дифов. А дифф - это один дифф.
2. Потому что патч должен иметь заголовок для применения. По спецификации.
3. Потому что я говорю исключительно за патч и дифф конкретно гита. За все остальные сферы я ничего не говорю и не утверждаю.
именно для применения как патча.
Но внутри гита (в самой-самой нутрянке невидимой юзеру) - заголовок не есть частью патча. Можешь попробовать достать дифф, например, из библиотеки libgit2 и убедится в этом сам :)
> При резете-то хеады в сабмодулях не детачатся?
^ могут детачится и при ресете, думаю.
Там вообще при каждом левом чихе что-то детачится, мне сложно сказать наверняка в каких ситуациях это происходит. Знаю только что за этим нужно следить постоянно. Но таогит спасает от большинства этих ситуаций.
У ресета вообще иное предназначение чем у чекаута. Лично я вообще не понимаю как можно обойтись ресетом вместо чекаута потому что они должны быть использованы для разных нужд. https://stackoverflow.com/a/3639387/4423545
Точно чексуммы? Почему они тогда называются индексом?
Индексы это данные которые лежат в папочке .git. А воркдир - это твоя рабочая директория с твоим проэктом.
в даном случае вероятнее всего это можно прочесть как "применять патч на файл в индексе со ShortOID 5bbee42 что бы получился файл с ShortOID f9b3d72". А оид является чексуммой файла длинной в 40 символов. Шорт оид же - это первые 7-8 символов этой чексуммы. (от чего зависит 7 или 8 я тебе не подскажу)
>но глаза вытекают как только напишу git log и ляпну по enter
Попробуй вот так:
git log --graph --pretty=oneline --abbrev-commit --all --decorate --date-order
Вопрос по гиту. Нужно написать клиент гитлаба, с достаточно ограниченным функционалом. Работает он через gitlab http api.
Вопрос вот в чем. Как вообще работает gitignore? Полностью на стороне клиента, как и скрытая папка .git?
Это копия, сохраненная 4 августа 2022 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.