LINUX.ORG.RU

Помогите разобраться с git


0

1

Доброго времени суток!

Первый раз работаю с git-ом и не могу понять кое что. Смотрю сейчас исходники ядра на git-хабе, историю коммитов в tag-е 2.6.37-rc7 (https://github.com/torvalds/linux/commits/v2.6.37-rc7). Не могу понять логику commit-ов, которые merge.

Почему при попытке посмотреть исходники я вижу какое-то не такое содержание файлов? Например, в commit-е v2.6.37-rc6 в Makefile было прописано обновление EXTRAVERSION=rc6 с EXTRAVERSION=rc5, в commit-е v2.6.37-rc7 там же обновлено EXTRAVERSION=rc7 вместо EXTRAVERSION=rc6. Но если я смотрю исходник какого-либо commit-а (например https://github.com/torvalds/linux/tree/050c6c9b896625d9fa498265be17b82c5fc65257) между ними или делаю checkout на локальном репозитории, то вижу rc6, rc5, rc1 и тому подобное, хотя если посмотреть лог изменений этого файла, то подобных изменений в нем между этими commit-ами не было. То же самое происходит и с другими файлами.

Это так и должно быть? Как загрузить состояние нужной ветки, чтобы увидеть то, что храниться именно в ней? Например, чтобы в Makefile было EXTRAVERSION=rc6 при загрузке любой ревизии между v2.6.37-rc6 и v2.6.37-rc7

Спасибо

> Как загрузить состояние нужной ветки, чтобы увидеть то, что храниться именно в ней?

В гите веток нету, есть updatable heads. То бишь ветка - это реально просто ссылка на какой-то коммит.

anonymous
()

на git-хабе прочитал как на git-хабре :) Уже испугался.

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

Попробую по другому спросить.

Как мне получить состояние head не некоторый произвольный коммит по его хешу. Если я делаю чекаут по какому-то промежуточному коммиту (между коммитами где поставили rc6 и rc7) то получаю следующую коллизию:

с одной стороны судя по логу файла Makefile в нем должно быть rc6, а с другой стороны я получаю в нем другое содержание (rc5, rc1 и т.п.). Я так подозреваю, что это относится к коммитам в которых делается merge с другим бранчем и содержание Makefile я получаю оттуда, из другого бранча, но все такие коммиты проверить не могу. Поэтому меня очень удивил bissect, когда начав работать между rc6 и rc7, выдывал rc5 и rc1.

Пока вижу такое решение - checkout на rc6, затем получение содержания каждого коммита в виде diff до интерессующей меня точки и накатывание их, но что-то мне подсказывает, что это не нормально, должен быть какой-нибудь более адекватный способ

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

тогда почему после git checkout в Makefile (например, но и не только в нем) оказывается не ожидаемое содержание? Может надо по другому commit указывать или флаги какие? Фокус в том, что и bissect делает так-же, после него я получаю не ожидаемые значения

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

bisect на нелинейной истории то еще приключение.

Скажи хеши коммитов, и что ты собирался увидеть, в каких файлах.

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

Например вот это: https://github.com/torvalds/linux/commits/master/Makefile?page=3 - история изменения Makefile, хеши b0c3844d8a (стало rc6, 16.12.2010) и 90a8a73c06 (стало rc7, 21.12.2010), между ними других изменений в Makefile нет.

Потом я захожу в историю 90a8a73c06 (он имеет тег v2.6.37-rc7) https://github.com/torvalds/linux/commits/v2.6.37-rc7 и выбираю коммит 050c6c9b89 (20.12.2010), затем перехожу в просмотр кода https://github.com/torvalds/linux/blob/050c6c9b896625d9fa498265be17b82c5fc652... и вижу там EXTRAVERSION = -rc5.

Если я делаю checkout этого коммита, то аналогично, я вижу rc5. Подозреваю, что также меняются и остальные файлы, просто изменения Makefile сразу бросаются в глаза при сборке пакета.

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

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

> И история линейная, ага.

История, конечно, нелинейная. Но не отменяет того факта, что веток нет, а есть граф коммитов связынных отношением parent-child.

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

В общем так открываешь gitk или qgit - он нормально развернет мержи в отдельные комиты и нарисует что куда мержилось.

Потом делашь git reset --hard commitid

Но есть ньюансы так как мердж это почти паралельная ветка. Так что смотри по qgit как она была смержена.

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

> Пользователь clearcase?

Пользователь гита. Если что, бранч в гите - это просто файлик в .git/refs/heads, в котором хранится хэш коммита, не более.

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

Да, почитал про git, посмотрел графы, разобрался почему так происходит, все в принципе логично.

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

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

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

Видимо, да. Мне еще не приходилось делать bisect по сложной истории, но другого способа на ум не приходит.

Посмотри еще следующие ссылки:

http://stackoverflow.com/questions/5638211/how-do-you-get-git-bisect-to-ignor...

http://stackoverflow.com/questions/3673377/why-isnt-git-bisect-branch-aware

Там есть рецепт, как выбрать промежуточные мержи, что позволит автоматизировать процесс.

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

> Как, по-твоему, должны быть сделаны православные бранчи? И почему?

В гите они вполне православны.

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

В гите они вполне православны.

Если ты тот же самый анон, то как понимать:

В гите веток нету

Но не отменяет того факта, что веток нет

это просто файлик в котором хранится хэш коммита, не более.

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

Все, разобрался как это работает, интересно конечно задумано. Очень помогает «визуальный» просмотр на ветки коммитов, пришлось конечно регрессию искать ручками, но нашел :)

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