LINUX.ORG.RU

Восстановление коммитов Git

 


0

1

История для меня не так важна, но для красивой визуализации хочу её восстановить.

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

Месяц назад я переключился на какой-то старый коммит, от ноября. При этом, вся промежуточная история по git log перестала показываться. Можно ли восстановить утерянный кусок, проведя по данным gc операцию «склейки»?

Насколько помню, я тогда набрал команду git checkout master, или что-то подобное.

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

git checkout master

Это переключение веток. Ничего при этом не удаляется.

ox55ff ★★★★★
()
Последнее исправление: ox55ff (всего исправлений: 2)
Ответ на: комментарий от grem

Разумеется, нужен же ответственный узел который будет вести этот учёт вне зависимости от проблем клиентов. То что в гите его по умолчанию нет это не плюс а минус, который и приводит к отсутствию стабильной истории. Но по факту все более-менее вменяемые обёртки над гитом концепцию сервера возвращают, правда костыльную а не нативную уже.

firkax ★★★★★
()
Ответ на: комментарий от firkax

Я, кстати, сегодня захотел скачать один старенький проект с сорсфоржа, набрал svn co… и очень удивился, увидев сообщение «bash: svn: команда не найдена». Оказывается, мне за последние 2,5 года (срок жизни Манжары на моём домашнем десктопе) ни разу не потребовался svn, все нужные исходники либо в гите, либо (один или два раза) в меркуриале.

Svn я, конечно, накатил и проект скачал, но задуматься есть над чем. Скоро про него, похоже, забудут. Жаль, система была надёжная, простая и однозначная, как топор — но увы…

hobbit ★★★★★
()
Ответ на: комментарий от hobbit

все нужные исходники либо в гите, либо (один или два раза) в меркуриале.

У меня другая ситуация: нужные мне исходники я пишу сам и лежат они на моём сервере а не где-то в инете. А в инете это всё из-за гитхаба происходит, который раскрутился и навязывает всем гит.

firkax ★★★★★
()

Да там изучать и нечего: при коммите вычисляется хеш от файла и с этим именем записывается объект в котором новое содержимое…

https://matthew-brett.github.io/curious-git/reading_git_objects.html

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

uwuwuu
()
Последнее исправление: uwuwuu (всего исправлений: 1)
Ответ на: комментарий от hobbit

Svn я, конечно, накатил и проект скачал, но задуматься есть над чем. Скоро про него, похоже, забудут. Жаль, система была надёжная, простая и однозначная, как топор — но увы…

ИМХО главная проблема в svn - в том, что он способствует плохим практикам в структурировании коммитов. При работе с git легко разделять локальные изменения: вот этот рефаторинг пойдёт в коммит#1, изменения во вспомогательном модуле пойдут в коммит#2, а решение основной задачи в коммит#3. А люди, использующие svn, обычно работают в стиле «я задачу решил, и все правки, которые сделал в процессе работы над ней, пойдут в одном коммите». Или ещё хуже: «две недели работал без инета, пойду залью всё, что накопилось».

Так что, может svn и надёжная и простая система… но только когда пользуешься ей через git-svn с возможностью создавать локальные коммиты и ветки.

annulen ★★★★★
()
Ответ на: комментарий от hobbit

захотел скачать один старенький проект с сорсфоржа, набрал svn co… и очень удивился, увидев сообщение «bash: svn: команда не найдена»

Всегда в таких случаях делаю git svn clone

А еслм проект ещё жив, то время от времени git svn rebase

akk ★★★★★
()
Ответ на: комментарий от grem

Что такое «стабильная история»?

Это значит что если ты 2023-06-16 09:31:16 закоммитил что-то в репу, то список твоих изменений, их дата и ветка, куда был коммит там гарантированно останутся навсегда, и будут видны, среди отсортированного по датам списка, в svn log. К логу можно применить фильтр по ветке чтобы увидеть историю только ветки.

О каких клиентах вообще идёт речь и почему у них появляются проблемы?

Клиенты это те кто подключаются к серверу. А проблемы у клиента могут быть в виде сломавшегося диска с лежащими коммитами, которые он хоть и приготовил, но решил слать на сервер «потом», ведь у него распределённая vcs и все узлы равны.

firkax ★★★★★
()
Ответ на: комментарий от t184256

У меня коллега думал,что в mercurial нельзя изменять историю, пока я ему на показал, что очень даже можно посредством расширений histedit и mq. На сервере сложнее, но при желании и наличии прав тоже можно.

grem ★★★★★
()
Ответ на: комментарий от grem

Моим первым VCS был bzr с его мягким и шелковистым bzr uncommit и человеческой нумерацией коммитов несмотря на распределенность. Из-за этого я очень непонимающими детскими глазами смотрел годы спустя на перелеты какашек из стана SVN в толпу Git и обратно. Но в 2023 стенания ТСа о том, как хорошо было при тоталитаризме — это уже в чистом виде маркер возраста.

t184256 ★★★★★
()
Ответ на: комментарий от grem

histedit

Там вроде было два режима: сохранять вечно все старые версии коммитов, либо не сохранять вообще ничего. Или я с чем-то путаю? Оба варианта, естественно, никуда не годны.

annulen ★★★★★
()
Ответ на: комментарий от annulen

hg histedit - это скорее аналог git rebase -i, когда он вываливает список коммитов в текстовом редакторе, где для них можно указать, что с ними делать: удалить, переместить, объединить, подправить или поменять описание.

grem ★★★★★
()
Последнее исправление: grem (всего исправлений: 1)
Ответ на: комментарий от annulen

При работе с git легко разделять локальные изменения: вот этот рефаторинг пойдёт в коммит#1, изменения во вспомогательном модуле пойдут в коммит#2, а решение основной задачи в коммит#3.

В svn же тоже можно указывать, какие файлы и даже целые подкаталоги явно включать в коммит. Я этим по работе регулярно пользовался. Тот, кто не пользуется — ССЗБ.

А люди, использующие svn, обычно работают в стиле…

Ну это аргумент из серии «Delphi позволяет быдлокодить, поэтому люди, использующие Delphi, обычно быдлокодеры». Git тоже позволяет накосячить, и очень серьёзно. К примеру, сделал человек 10 коммитов и после них один пуш. И после пуша выясняется, что конфликт с наработками другого разработчика возник где-то в начале, на втором или третьем коммите из серии… В svn так не получится, проблема выявится при первом же коммите. Да, это плата за распределённость со всеми её плюшками.

Или ещё хуже: «две недели работал без инета, пойду залью всё, что накопилось».

Ну вот это да, проблема, здесь svn объективно проигрывает гиту. Я в такой ситуации обычно работал как сам-себе-VCS: после каждой логической порции изменений складывал изменившиеся файлы в отдельный номерной каталог, внутрь него помещал файлик README с комментариями к «коммиту». По возвращении к доступному серверу коммитил все эти каталоги по очереди. Да, с гитом это намного удобнее.

hobbit ★★★★★
()
Ответ на: комментарий от t184256

Но в 2023 стенания ТСа о том, как хорошо было при тоталитаризме — это уже в чистом виде маркер возраста.

В моё время не парились по поводу версий. И часто хранили сорцы в одной копии, скидывая бэкап раз в месяц (к примеру) на 5.25" дискету. Сейчас - да, каждой секундой дорожат. Человек обесценился. Технократия.

i_am_not_ai
() автор топика
Ответ на: комментарий от hobbit

В svn же тоже можно указывать, какие файлы и даже целые подкаталоги явно включать в коммит

А в гите это делается с точностью до строчки в файле. Плюс можно отредактировать, если что-то лишнее включил по ошибке.

Ну это аргумент из серии «Delphi позволяет быдлокодить, поэтому люди, использующие Delphi, обычно быдлокодеры».

Нет, описаный пример оносится в том числе к серьёзным дядям из Apple, работающим на WebKit. Когда был svn, было довольно легко отличить тех, то пользуется на своей стороне гитом, от свнщиков - по содержимому коммитов.

Я в такой ситуации обычно работал как сам-себе-VCS: после каждой логической порции изменений складывал изменившиеся файлы в отдельный номерной каталог, внутрь него помещал файлик README с комментариями к «коммиту».

Блин, зачем так жить :(

annulen ★★★★★
()
Ответ на: комментарий от i_am_not_ai

И часто хранили сорцы в одной копии, скидывая бэкап раз в месяц (к примеру) на 5.25" дискету.

Ну это первая ступень постижения VCS.

Вторая — это когда до программиста доходит, что неплохо бы иметь возможность знать, когда что-то поломалось. Он начинает зиповать исходники в архивы с датами и хранить всю серию архивов.

Третья — когда до программиста доходит, что надо бы знать не только «когда», но и «почему», и он в эти архивы начинает класть ридмишки с описаниями, что менялось. Всё, если программист (или ведущий программист проекта) до этой стадии дошёл, он уже морально готов к введению VCS, поскольку она делает всё то же самое, но автоматом, да ещё и поиск по истории упрощает радикально.

Хотя до второй или третьей стадии доходят не все, да. Я прошёл все три, поэтому у меня ломки от VCS не было.

Человек обесценился.

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

hobbit ★★★★★
()
Ответ на: комментарий от hobbit

Я пользуюсь той системой контроля, которой пользуется проект. Только в случае svn получается, что его я использую для скачивания репозитория и создания единственного! патча, доступа то на запись в репу у меня нет. По крайней мере, как сделать в нём несколько дополняющих и наслаивающихся друг на друга патчей я не знаю.

grem ★★★★★
()
Ответ на: комментарий от grem

По крайней мере, как сделать в нём несколько дополняющих и наслаивающихся друг на друга патчей я не знаю.

Никак. Без доступа на запись лучший (для меня - минимально приемлемый) способ работы с svn - это git-svn

annulen ★★★★★
()
Ответ на: комментарий от hobbit

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

Просто стали бояться смерти и энтропии. Слишком большое внимание придают своей личности. И меньше - заботе о следующих поколениях. Некогда. Всё внимание к «я». Бок о бок эгоизм идёт с экономическим строем, когда социальному придаётся меньше, но больше - личному. Не сказал бы, что люди сейчас стали жить счастливее. В любую эпоху есть вещи, которым можно радоваться.

Ну а все эти «истории изменения файлов» по-большому счёту нужны, пока ты зависишь от компьютера. Для жизни они не являются необходимым. В силу привычки пользуешься этим. Можно зависеть (физиологически) и от других возбудителей, когда прёт от техники, или от ботаники.

Сейчас нагрузка (информационная) выросла на порядки, человеческий мозг уже не справляется с этим потоком энтропии. Компьютер, типа, и причина бедствий, и помощник, 2:1 )

i_am_not_ai
() автор топика
Последнее исправление: i_am_not_ai (всего исправлений: 2)
Ответ на: комментарий от hobbit

Брали main-ветку да нумеровали, очень удобно. Feature-бранчи то ли по имени+номеру, то-ли по имени + номеру parent коммита + номеру коммита в ветке, типа из 3 растет feature 3.1

ИМХО если бы в гит была похожая встроенная схема типа 3.0.3+23.feature.2, отламывающаяся при попытке делать из истории guitar hero, всей этой дуроты с нелинейной историей на пустом месте резко стало бы меньше.

t184256 ★★★★★
()
Последнее исправление: t184256 (всего исправлений: 2)
Ответ на: комментарий от hobbit

и он в эти архивы начинает класть ридмишки с описаниями, что менялось

VCS, поскольку она делает всё то же самое, но автоматом

А у меня vcs есть а вот «ридмишки» далеко не всегда. Зато есть команда svn-diff.

firkax ★★★★★
()