LINUX.ORG.RU

[Git] Слетают изменения в файлах. В чем может быть проблема?


0

1

Здравствуйте!


Веду разработку из нескольких мест (с работы, из дома) и уже несколько раз натыкаюсь на одну и ту же проблему.

В какой-то момент после очередной синхронизации с github, изменения, сделанные в файлах исходников, слетают. И файл становится таким же, каким был до правки. Причем нигде в истории не отмечается момента исчезновения из изменённого файла новых строк. Они просто бесследно удаляются, и файл становится таким же каким был до правки. Причем это происходит не всегда, и я никак не могу выяснить закономерность этого глюка.

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

Я уже начинаю думать, что нужно в глобальных настройках Git на рабочем компе и на домашнем указать разные e-mail и разные имена пользователей. Поведение git похоже на то, что он считает оба компьютера за один, и по каким-то причинам не применяет поверх изменения, взятые с сервера.

Команда синхронизации следующая:

git add . & git commit -a -m "Commit" & git pull -s recursive -X theirs & git push

Стратегия синхронизации должна быть следующей: то, что было последнее изменено, то и должно закачиваться на сервер. При получении изменений, последние изменения должны применяться к коду на локальной машине.

Кто встечался с таким глюком? Как исправить? В чем может быть проблема?

★★★★★

Ответ на: комментарий от baverman

Поддерживаю... до такого додуматься надо было :)

Jetty ★★★★★ ()

Ты что-то делаешь не так

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

Многими скорбями надлежит нам войти в Царствие Божие.

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

Это не проблема git

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

baverman ★★★ ()

Кто встечался с таким глюком?

Это не глюк, theirs заставляет git применять изменения из remote-репозитория независимо от времени изменения.

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

Это не глюк, theirs заставляет git применять изменения из remote-репозитория независимо от времени изменения.

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

Вопрос: какой режим следует применять, чтобы выполнялось правило: самые последние изменения, залитые в репозитарий, самые правильные?

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

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

Возвращается не весь файл, а только то место, где пересеклись изменения.

stack_protector ()
Ответ на: комментарий от Xintrea

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

Думай не в терминах измененных файлов, а в терминах измененных строчек. theirs действует при разрешении конфликтов.

baverman ★★★ ()

Как исправить?

Вырвать руки и вставить в нужное место. Нормальные люди пользуются гитом совсем не так.

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

Ну так, мы увидим строку с командами синхрониации по приниципу «самые последние изменения, залитые в репозитарий, самые правильные»? Или будем налюдать как гуру гита исходят на гуано?

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

git stash && git pull имяремоута имябранчи && git stash pop

Этой командой можно просто пользоваться для постоянной синхронизации? Или она преднаначена для единичного случай синхронизации, а остальные разы надо синхриться как-то по-другому? Нужна команда, которой пользоваться постоянно, без плясок «сейчас сохранимся так», «а сейчас вотэдак».

Я это спрашиваю из-а того, что:

Stash the changes in a dirty working directory away
Прячет изменения в грязной рабочей директории подальше

Use git stash when you want to record the current state of the working directory and the index, but want to go back to a clean working directory. The command saves your local modifications away and reverts the working directory to match the HEAD commit.
Используйте Git тайник, когда вы хотите записать текущее состояние рабочего каталога и индекса, но хотите вернуться к чистому рабочему каталогу.Команда сохраняет ваши локальные изменения в сторону и возвращается рабочий каталог, чтобы соответствовать HEAD коммита.

Что сие значит не совсем понятно.

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

Стэщ нужен только потому что гит не даст тебе смержиться в грязную (т.е. с незакомиченными изменениями) ветку.

Я всегда делаю синхронизацию merge-ом (pull из моего примера - это, грубо говоря, алиас для последовательных fetch и merge).

Почитай лучше какую нибудь книжку по гиту, а? Прогит например.

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

Поставлю вопрос по-другому. Я гит использую не по назначению, а, так сказать, для синхронизации текстовых данных. Вот статья, в ней есть моя вышеприведенная команда:

http://webhamster.ru/site/page/index/articles/projectcode/170

На практике оказалось, что вылезают вышеописанные глюки синхронизации.

Какую команду можешь посоветовать в этом случае?

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

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

Ты сначала определись, что тебе надо.

Если тебе нужна самая последняя версия с сервера, то это git stash && git pull (или git reset --hard && git pull).

Но при этом ты жалуешься на потерю локальных изменений, ведь так?

yoghurt ★★★★★ ()

В чем может быть проблема?

Проблемы в DNA.

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

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

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

На практике оказалось, что вылезают вышеописанные глюки синхронизации.

Ты очень странно читаешь:

Грубо говоря, если вы в первой копии данных удалите ветку с записями и засинхронизируетесь, а во второй копии, не синхронизируясь начнете редактировать записи в этой ветке, то после синхронизации второй копии всё ваше редактирование будет забыто и ветка удалена. Это произойдет потому, что вначале произошло событие удаления ветки (и оно было зафиксировано!), а все последующие действия внутри этой ветки не имеют смысла.
baverman ★★★ ()
Ответ на: комментарий от yoghurt

Ты сначала определись, что тебе надо.
Если тебе нужна самая последняя версия с сервера, то это git stash && git pull (или git reset --hard && git pull).
Но при этом ты жалуешься на потерю локальных изменений, ведь так?

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


1.

Есть два пользователя. Синхронизировались оба в 10:00.

1User. 10:30. В файле a.txt дописал «abc»

2User. 10:45. В файле a.txt на том же месте дописал «123»

1User. 11:00. Синхронизируется с сервером. На сервере в файле a.txt появляется строка «abc».

2User. 11:10. Синхронизируется с сервером. На сервере в файле a.txt появляется строка «123».

1User. 11:20. Синхронизируется с сервером. В локальном файле a.txt появляется строка «123».


2.

Есть два пользователя. Синхронизировались оба в 10:00.

1User. 10:30. В файле a.txt дописал «abc»

2User. 10:45. В файле a.txt на том же месте дописал «123»

2User. 11:00. Синхронизируется с сервером. На сервере в файле a.txt появляется строка «123».

1User. 11:10. Синхронизируется с сервером. В локальном файле a.txt строка «abc» замняется на «123», так как «123» появилась пожже чем «abc» («123» - актуальнее).


И 1 и 2 должны отрабатываться так, как описано. Посему и вопрос, какой универсальной командной строкой подобную синхронизацию можно сделать.

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

В локальном файле a.txt строка «abc» замняется на «123», так как «123» появилась пожже чем «abc» («123» - актуальнее)

«123» - актуальнее

Только как гит должен об этом догадаться? Без внешних, по отношению к ниму скриптов, этого не сделаешь.

То есть процедура будет примерно такой:

1) git fetch
2) сравнение таймстампов локальных файлов и remotes/origin/master
3) формирование коммита соответственно твоей логике
4) git commit
5) git push

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

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

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

Есть два пользователя. Синхронизировались оба в 10:00.

И оба коммитят параллельно в одну ветку? Ну некошерно же

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

Только как гит должен об этом догадаться?

По времени модификации файла вестимо.

Я нигде не могу найти в документации объяснения следующего важного момента.

В Git изменения фиксируются просто по факту синхронизации с репозитарием? Кто первый закоммитил изменения, так они и будут считаться первыми, независимо от того, сделаны ли они позже другого пользователя в мировом времени?

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

Кто первый закоммитил изменения, так они и будут считаться первыми

Вообще-то, AFAIK, так работают все нормальные VCS. И это хорошо и правильно.

baverman ★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.