Re[7]: Git wtf?..
От: Evgeny.Panasyuk Россия  
Дата: 31.01.16 06:38
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Однако чаще всего выбирают именно его, в основном как раз из-за популярности гитхаба.


Когда начал использовать Git, о GitHub слышал только краем уха
Думаю тут наоборот — одна из причин популярности GitHub, в том что он именно GitHub.
Re[5]: Git wtf?..
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 31.01.16 06:53
Оценка:
Здравствуйте, Dair, Вы писали:

D>Здравствуйте, netch80, Вы писали:

D>>> path/to/another/source.cpp
D>>> path/to/another/source.h
D>>>Please, commit your changes or stash them before you can merge.
D>>>Aborting

N>>Ага. Вот на этой точке как раз надо было остановиться и разобраться, откуда такое возникло, а что оно не смогло, явно сказало.

N>>Если эти локальные изменения были до rebase pull, то надо было тут выполнить stash и только после этого продолжать. И после всего pull — сделать stash pop и объединять новые изменения.

D>Дело в том, что эти файлы я не трогал. Вообще.


Значит, оно выделило как-то эти файлы именно в результате процесса rebase. Тогда надо было посмотреть, что за изменения, и закоммитить их или отменить.

N>>Вообще тут странно вот что — по умолчанию оно запрещает делать rebase при любых локальных изменениях файлов, то есть оно вообще не вошло бы в такой процесс, потребовав stash до запуска rebase pull. Это какие-то локальные настройки, что оно проигнорировало запрет? Что за версия git?

D>2.6.0

Интересно. Я думаю, что пример воспроизведения этой ситуации будет полезен как problem report.

D>Тут есть предыстория. Я и был в ветке. Закончил, вливаюсь в develop.


D>тут я в ветке my_branch

D>commit
D>checkout develop
D>pull
D>merge my_branch
D>(разрешение конфликтов)
D>add
D>add
D>add
D>commit

Не так важно, если собственно перед pull+rebase было чистое состояние, без локальных правок.

D>Тут в develop другие парни влили ещё два файла из заведомо других каталогов, push не прошёл.

D>Решил, что уже тут надо делать rebase. Ну и вот.

То есть было переключение от попытки merge на попытку rebase, от того, что пришло много других изменений?
Хм... вот это случай, когда методы его слияния могли и поломаться. Само по себе появление файлов, которые вдруг стали локально изменены, является признаком в пользу такой гипотезы.
В таком случае варианты — попробовать другой алгоритм слияния (там несколько на выбор),
наконец, если оно дало изменённые, просто исправить эти изменения и закоммитить.
В любом случае, переключение на rebase вместо предыдущего merge это опасная операция.
(Таки в первой критике я был заметно прав — именно опасная операция, не названная в исходном рассказе, послужила причиной поломки. Лучше было это рассказать с самого начала.)
The God is real, unless declared integer.
Re[2]: Git wtf?..
От: -n1l-  
Дата: 31.01.16 06:59
Оценка:
Или не использовать rebase.
Re[7]: Git wtf?..
От: Sinix  
Дата: 01.02.16 07:08
Оценка: +1
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>С трудом верится, особенно вспоминая жёсткие roundtrip'ы при работе с SVN, даже на мелких репозиториях в пару сотен коммитов. Но хорошо если действительно так.

EP>Я думал там тормоза принципиальные, из-за архитектуры.
Перепроверил, взял папку, которая редко менялась. История за четыре года выгреблась секунд за 10.

EP>Но, это же переход на старую ревизию или ветку может быть очень долгим, так? Например в целях поиска коммита внёсшего баг, а-ля git bisect.

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


Если надо в нескольких ветках одновременно работать, то проще всего сделать пару копий, одна — для основной разработки, вторая — для отрезания релизов/воспроизведения багов и тд и тп.

EP>Например в целях поиска коммита внёсшего баг, а-ля git bisect.

Вот ни разу так не приходилось извращаться. Blame или просмотра истории хватает за глаза.
Re[3]: Git wtf?..
От: Submitter  
Дата: 01.02.16 07:33
Оценка: -3 :)
Здравствуйте, Dair, Вы писали:

D>10 минут паники, позорный пост на RSDN — оно того стоило


У тебя полно "позорных" постов.
Re[4]: Git wtf?..
От: Dair Россия  
Дата: 01.02.16 07:57
Оценка:
Здравствуйте, Submitter, Вы писали:

S>У тебя полно "позорных" постов.


Например?
Re[5]: Git wtf?..
От: Mazenrab Россия http://www.electrica.ru
Дата: 01.02.16 08:00
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>А как же скорость? Например log или blame?


Если разработка идет в сети с нормальным каналом, то нет проблем. Я бы даже сказал что переходя на Git с SVN расчитывал увидеть все те сверхзвуковые "чудеса", что обычно описывают в сравнении с SVN. Их не случилось. Да чуть быстрее клонирование (checkout), ну разница порядка в одном 15 сек, в другом 13. Ветки да, шустрее. На Git в основном перешли из за того, что так и не смогли осилить ветки в SVN, а Visual Studio дает встроенную поддержку и не заставляет особо вникать в нюансы.

P.S.
А еще врут что Git репозитории компактнее SVN репозиториев. Они, по крайней мере у нас, больше.

P.P.S.
Возможно конечно что у нас просто не показательные репозитории. Самый сейчас большой порядка 3000 коммитов.
Re[6]: Git wtf?..
От: Evgeny.Panasyuk Россия  
Дата: 01.02.16 08:35
Оценка:
Здравствуйте, Mazenrab, Вы писали:

EP>>А как же скорость? Например log или blame?

M>Если разработка идет в сети с нормальным каналом, то нет проблем.

От меня SVN находился на расстоянии долгих roundtrip'ов.

M>Я бы даже сказал что переходя на Git с SVN расчитывал увидеть все те сверхзвуковые "чудеса", что обычно описывают в сравнении с SVN. Их не случилось.


Я сначала использовал Git локально для удалённого SVN — поэтому могу сравнить напрямую. И как раз были сверхзвуковые чудеса — log -p и blame стали моментальными — это качественный переход, я их стал использовать на порядки чаще чем при непосредственно SVN.
Сейчас попробовал сделать поиск по всем diff'ам в репозитории на десяток тысяч коммитов — всего 2 минуты!

И конечно же работая над фичами локально я мог использовать Git'овские ветки, даже при основном SVN — это удобно.

M>P.S.

M>А еще врут что Git репозитории компактнее SVN репозиториев. Они, по крайней мере у нас, больше.

ЕМНИП, у меня локальный Git репозиторий (со всеми коммитами!), был меньше чем локальный checkout SVN.
Re[7]: Git wtf?..
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 01.02.16 08:45
Оценка: +2
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>И конечно же работая над фичами локально я мог использовать Git'овские ветки, даже при основном SVN — это удобно.


У меня когда-то такой бутерброд был очень выгоден при CVS наверху

EP>ЕМНИП, у меня локальный Git репозиторий (со всеми коммитами!), был меньше чем локальный checkout SVN.


При малой истории и большом объёме рабочей копии это очевидное следствие того, что SVN хранит в pristine/ неизменённую копию каждого файла согласно текущей версии, а Git сжимает их.
The God is real, unless declared integer.
Re[7]: Git wtf?..
От: Mazenrab Россия http://www.electrica.ru
Дата: 01.02.16 09:08
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

А еще я умудрился сломать локальный репозиторий в гите буквально на второй день Причем что с ним до сих пор не понимаю. Гит говорил что вообще все файлы в репозитории модифицированны. При этом при побайтовом сравнении с предыдущим коммитом разницы не было.
Re[8]: Git wtf?..
От: Dziman США http://github.com/Dziman
Дата: 01.02.16 11:43
Оценка: +1
Здравствуйте, Mazenrab, Вы писали:

M> А еще я умудрился сломать локальный репозиторий в гите буквально на второй день Причем что с ним до сих пор не понимаю. Гит говорил что вообще все файлы в репозитории модифицированны. При этом при побайтовом сравнении с предыдущим коммитом разницы не было.


Почти наверняка косяк с переводами строк https://help.github.com/articles/dealing-with-line-endings/
avalon 1.0rc3 build 430, zlib 1.2.5
Re[3]: Git wtf?..
От: alexzz  
Дата: 02.02.16 07:45
Оценка:
Здравствуйте, Нахлобуч, Вы писали:

S>>Или использовать ui-инструменты, они хоть предупреждают о возможных косяках, или страдать.

Н>...или взять Mercurial

Не помогает

В нём тоже есть инструменты редактирования истории. Если штатных мало, можно других доставить. Я так пару раз терял коммиты, причём из GUI. Виноват я конечно, а не Mercurial.
Re[6]: Git wtf?..
От: · Великобритания  
Дата: 02.02.16 18:29
Оценка:
Здравствуйте, alex_public, Вы писали:

_>>>Mercurial лучше — абсолютно те же самые технические возможности, но при этом более удобно.

N>>Нет, в разы менее удобно, идиотская логика на каждом углу. И не надо возражать, этот холивар давно надоел и я всё равно не соглашусь, ничего лучшего за последние лет 5 в меркуриале не случилось.
_>Ну естественно если речь не о технических аргументах, а о вере, то попытки убедить бесполезны) Хотя это всё как раз по профилю данного форума. )))
Технические аргументы уже были. http://rsdn.ru/forum/tools/5821081.flat#5821081
Автор: .
Дата: 17.10.14

Интересно изменилось ли что с тех пор?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[7]: Git wtf?..
От: alex_public  
Дата: 02.02.16 20:55
Оценка:
Здравствуйте, ·, Вы писали:

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

·>Технические аргументы уже были. http://rsdn.ru/forum/tools/5821081.flat#5821081
Автор: .
Дата: 17.10.14

·>Интересно изменилось ли что с тех пор?

Со временем уровень технологических возможностей этих конкурирующих систем (да и не только этих двух, просто они самые известные, а там на самом деле ещё несколько полноценный аналогов есть) только выравнивается (у mercurial же в прошлом был свой аналогичный список). А вот уровень заложенного удобства сохраняется... Разве что GUI для git чуть подрос до уровня аналогичного в mercurial. Но GUI — это не всем интересно.
Re[8]: Git wtf?..
От: · Великобритания  
Дата: 02.02.16 22:26
Оценка: +2
Здравствуйте, alex_public, Вы писали:

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

_>·>Технические аргументы уже были. http://rsdn.ru/forum/tools/5821081.flat#5821081
Автор: .
Дата: 17.10.14

_>·>Интересно изменилось ли что с тех пор?

_>Со временем уровень технологических возможностей этих конкурирующих систем (да и не только этих двух, просто они самые известные, а там на самом деле ещё несколько полноценный аналогов есть) только выравнивается (у mercurial же в прошлом был свой аналогичный список).

Можно увидеть этот список? Единственное, что могу припомнить, git плоховато работал на win, ибо изначально разрабатывался unix-only, когда как hg изначально задумывался кроссплатформенным.

_>А вот уровень заложенного удобства сохраняется... Разве что GUI для git чуть подрос до уровня аналогичного в mercurial. Но GUI — это не всем интересно.

Фундамент git — лучше. Вместо традиционного (тянущееся начиная с rcs?) append-only лога, да ещё и per-file используется принципиально другой подход, ассоциативное object-хранилище.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[9]: Git wtf?..
От: alex_public  
Дата: 03.02.16 00:46
Оценка:
Здравствуйте, ·, Вы писали:

_>>Со временем уровень технологических возможностей этих конкурирующих систем (да и не только этих двух, просто они самые известные, а там на самом деле ещё несколько полноценный аналогов есть) только выравнивается (у mercurial же в прошлом был свой аналогичный список).

·>Можно увидеть этот список? Единственное, что могу припомнить, git плоховато работал на win, ибо изначально разрабатывался unix-only, когда как hg изначально задумывался кроссплатформенным.

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

— проблема с сохранением истории в git. В mercurial всегда можно найти источник проблемы, а в git'е далеко не всегда.
— возможность получить гигабайтный патч при слияние веток в git.
— проблема с кодировками в путях. Надеюсь хоть это уже исправили? )
— слабая работа с хуками и другими расширениями в git
— заковыристая система команд (субъективно конечно, дело вкуса, но такое мнение можно частенько услышать) в сравнение с другими dcvs.

·>Фундамент git — лучше. Вместо традиционного (тянущееся начиная с rcs?) append-only лога, да ещё и per-file используется принципиально другой подход, ассоциативное object-хранилище.


Это смотря на каком уровне смотреть. Формально да, одно хранит дифы, а другое вроде как сами файлы. Но фокус в том, что если бы оно реально хранило сами файлы, то размер хранилища был бы нереальным. Так что в итоге и второе хранит дифы, просто они там для сжатия, а не для идеологии.
Re[10]: Git wtf?..
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 03.02.16 05:46
Оценка:
Здравствуйте, alex_public, Вы писали:

_>- проблема с сохранением истории в git. В mercurial всегда можно найти источник проблемы, а в git'е далеко не всегда.


Совершенно непонятно. Что есть "проблема" в данном случае? Источник конкретного изменения? Ищется по истории без проблем, на каждую версию строчки или бинаря есть id коммита, из которого она возникла. Развилки? Они существуют во всех DVCS.

_>- возможность получить гигабайтный патч при слияние веток в git.


Любое слияние отражает дифф с исходными версиями. "Гигабайтный патч" означает сведение существенно несовместимых вариантов. Проблема общая для всех DVCS, но в случае Git имеем один из лучших, испытанный на практике, мержер.

_>- проблема с кодировками в путях. Надеюсь хоть это уже исправили? )


Этой проблемы никогда не было у Git. Имя объекта это NUL-terminated строка байт, даже понимание этого имени как пути уже является свойством внешнего слоя, а не ядра.
Если она есть у Windows, то это проблема кодировок Windows и конкретных реализаций Git клиента. Бардак с кодировками (ANSI/OEM/Unicode) в Windows такой, что я всегда забывал, что в них где, через 5 минут после того, как разобрался.

_>- слабая работа с хуками и другими расширениями в git


Мне не с чем сравнивать, но вопрос в том, насколько реально нужна "сильная" в твоём понимании, и насколько она логична.

_>- заковыристая система команд (субъективно конечно, дело вкуса, но такое мнение можно частенько услышать) в сравнение с другими dcvs.


Система команд очень удобна из логики "если действие с базовой концепцией X, команда будет называться X".
The God is real, unless declared integer.
Re: Git wtf?..
От: D.Lans Россия  
Дата: 03.02.16 06:20
Оценка: +1 -1
Вот поэтому я и пользуюсь Mercurial. Есть свои проблемы, в частности уже пару раз ломал репозиторий, что приходилось пересоздавать с нуля (хотя может можно было и починить, нз), но в целом ощущения от использования этой VCS очень приятные. Всё чисто, понятно и логично.

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

Хайпа вокруг гита не понимаю. Ладно самое красноглазное подмножество линуксоидов-ядерщиков в своём мирке юзают что им удобнее (белоглазые же линуксоиды, я слышал, почётно восседают на bazaar), но гит с хрустом начинают жевать маководы и виндузятники (к коим отношусь и я), с улыбкой гарольда-скрывающего-боль нахваливая и зазывая всех присоединиться к их клёвым проектам, худо-бедно выложенным на модный нынче гитхаб (но которые почему-то так и не получают должной популярности), я в недоумении развожу руками.
Re: Git wtf?..
От: Yoriсk  
Дата: 03.02.16 09:10
Оценка: :))) :)
Здравствуйте, Dair, Вы писали:

D>Консольный Git, 2.6.0


Re[2]: Git wtf?..
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 03.02.16 09:12
Оценка:
Здравствуйте, Yoriсk, Вы писали:

Y> http://imgs.xkcd.com/comics/git.png


Успешно выбирались и из-под ошибок, и без каких-то суперпремудростей — всего лишь надо было спешить не торопясь
The God is real, unless declared integer.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.