Давайте поговорим про системы версионирова

“Теряем”, понятное дело, означает не то, что данные исчезли и не достать. - Igor Sereda

Просто после каких-то мержей выясняется - случайно! - что почему-то в основной ветке лежит не последняя версия X, а предыдущая, хотя бранч, в котором шла разработка X, был замержен весь и удален. - Igor Sereda

Обнаруживает это бдительный разработчик X, хотя он мог бы и недобдеть. - Igor Sereda

Ну и к слову, what bothers me about #Git is that with thousands of commands and options, I still need to write elaborate scripts to do simple things. - Igor Sereda

so, how do they do it with kernel? - piikummitus

Только sourcedepot^W perforce, только хардкор. - темноводное

@silpol как летающие крокодильчики из анекдота? - Igor Sereda

При svn практически все мёржи призодилось руками всё равно разгребать, так что было трудно пропустить. С git описанный эффект у меня получался, я потом разобрался, почему так было (достаточно логично), и больше так не получается — но причину уже забыл. - 9000

Расскажи хоть как оно достигается? - зона пингвинов

в принципе же можно восстановить полностью всю историю того, как происходил этот мердж. как именно мерджился бранч Х? если git merge — значит неважно, был ли удален этот бранч. если предварительно с веткой производились какие-то манипуляции — значит, именно в этом процессе потерялась "версия". это же все видно, посмотрите, какое было состояние веток в обоих parents искомого мерджа - псы в рапиде

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

впрочем, проблема может быть в том, что эта ветка уже предварительно мерджилась с транком? точнее, например, транк предварительно мерджился с этой веткой, чтобы потом облегчить настоящий мердж — я иногда так делал, например - псы в рапиде

у меня есть серьезное ощущение, что под этими пафосными словами про "I need to write elaborate scripts to do simple things" — скрывается нечто похожее на одну из причин проблемы. я готов разобраться с вашим юзкейсом, и почему вы вынуждены писать эти самые "развесистые скрипты" и что именно вы называете "простыми вещами". некоторые люди называют "сложными" самые разные вещи. - псы в рапиде

и в чем именно "сложность" этого скрипта. может быть она как в анекдоте про милиционеров которые бывают умные и сильные. - псы в рапиде

@9000 ну вот, так всегда! (это про забытую причину) - ну и я конечно в шутку сетую про svn, там действительно проблемы были на другом уровне - Igor Sereda

@squadette спасибо за внимание к нашей проблеме :) сначала про скрипты - например, я хочу узнать, в каких ветках имеется конкретный коммит (из каких refs он достижим) - чтобы разобраться, что куда было замержено. пишем скрипт №1. или вот, хочу чтобы _все_ локальные неизмененные ветки передвинулись вслед за remote ветками, которые они трекают - это нужно, например, для скрипта №1 - пишем скрипт №2. (перебор всех remote веток, создание их local counterparts, если нет, если есть - fast forward) - Igor Sereda

про сложность скриптов: конечно, они не сложные. сложность тут в том, что а) надо убедиться, что проблема не решается из коробки, б) надо осознать, почему это она не решается из коробки - убедиться, что проблема не надуманная, в) ну и такие мелочи как необходимость писать скрипт два раза - на bash и на powershell. все это вызывает потребительское неудовольствие. - Igor Sereda

про последний случай с потерей изменения - сижу, разбираюсь, напишу апдейт. он не связан со скриптами (которые у нас пока что только читают репозиторий) - Igor Sereda

git branch -r --contains <commit> - зона пингвинов

@bugtracker шайтан! спасибо. а ведь я искал, как это делается - Igor Sereda

Посмотри внимательней только, покажет ли он все ветки - зона пингвинов

With --contains, shows only the branches that contain the named commit (in other words, the branches whose tip commits are descendants of the named commit). With --merged, only branches merged into the named commit (i.e. the branches whose tip commits are reachable from the named commit) will be listed. With --no-merged only branches not merged into the named commit will be listed. If the <commit> argument is missing it defaults to HEAD (i.e. the tip of the current branch). - зона пингвинов

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

(Да, не подводивший меня пока рецепт: работая в своей ветке, периодически делать pull --rebase master, с тем, чтобы всегда работать как бы с текущим состоянием общего мастера, и ловить все потенциальные merge-конфликты быстро и маленькими порциями.) - 9000

^ Ыыыы! Ладно, молчу. - [email protected]

^ Скажи уж! Я так в некоторых случаях делаю и мне кажется это валидной практикой. - оленёнок Роршах

@9000 @blacklion я так понимаю, есть два лагеря - rebase и merge; мы вот не делаем rebase обычно. есть плюсы и минусы в обоих подходах - Igor Sereda

Думаю, дело в том, что некоторым vcs представляются средством хранения истории, типа летописи. Возможно, это кому-то нужно, но не мне. Мне vсs нужны как средство *логического упорядочения изменений*. Поэтому rebase — хоршее, годное средство сказать *в моей рабочей ветке*, кто на ком стоит (а именно, мои изменения всегда стоят на текущем состоянии мастера). Вот мастер — да, он append-only, fast-forward-only, и сколько угодно (в моем случае 90%+) промежуточных коммитов из рабочей ветки в него не попадает. - 9000

@sereda Ну да. Но вопрос даже не в хранении истории (хотя и это тоже), а в том, что я работаю на нескольких WS и для меня система контроля версий -- это синхронизатор рабочих копий, в том числе и WIP. И как только я сделаю первый ребейз я взорву остальные репозитрии. Т.е. у меня ЛЮБАЯ работа, которая занимает больше 1 дня -- формально паблик (живёт более чем в 1 репозитории, пуш-пулл, вот это вот всё). Я это, впрочем, уже не раз писал. Теоретически ребейз можно было сделать нормально публикуемым, но не сделали. Кстати, в Mercurial то ли сделали то ли вот-вот доделают. - [email protected]

^^^ I see. Я исповедую merge-only во всём публичном и rebase-only во всём личном (которое у меня в отличие от Льва живёт как правило в одном месте). Так и сюрпризов мало и история чище (очень неприятно продираться через историю где на каждый значимый коммит три мерджа). Я ещё и перед тем как вмерджиться во что-то публичное часто историю редактирую, какие-то коммиты сливаю, мессаджи редактирую, чтобы люди видели не поток моей фантазии, а осмысленные этапы какие-то. - оленёнок Роршах

^ same, как и многие другие. Но видел парней, которые коллективно ребейзили долгоживующую публичную ветку. Видимо, пингуя и reset --hard всех коллабораторов, не знаю. Воркфлоу у них такой. Извращенцы, конечно. - ʕノ•ᴥ•ʔノ︵ StandardError

Частая причина проблем и пропаданий кода - "содержимое мержа" в git log -p обычно не показывается. Можно, но мало кто умеет это нормально читать. А есть товарищи, которые при conflict resolution дописывают или удаляют код и коммитят это. Найти такой фокус - целое дело. - ʕノ•ᴥ•ʔノ︵ StandardError

да, с постоянно ребейзящимися локальными бранчами есть маленькая проблема - они локальные! Я однажды так потерял бранч с 20 коммитами за пару месяцев - стер папку с сорцами нечаянно. Восстанавливал по памяти. С тех пор мало мальски значимое все-таки публикую и не стесняюсь это push -f после ребейза, и всем рекомендую. - ʕノ•ᴥ•ʔノ︵ StandardError

у меня домашний каталог бекапится раз в час, смысл бекапить средствами git теряется. до этого тоже пушил -f во что-нибудь ремотное личное. - оленёнок Роршах

А, еще вспомнил пушнутое коллегами, и не раз: сначала мержнуть мастер в свою ветку, потом ее ребейзнуть на мастер же, потом еще накоммитить и снова смержить. Гит при этом явно что-то логичное делает, но эту логику при том, что девелопер логикой не пользовался, выяснять незачем. С тех пор правило: не умеешь - не ребейзь. - ʕノ•ᴥ•ʔノ︵ StandardError

Годика полтора назад я плотно использовал Gerrit как code review tool. Там все изменения идут через рабочие ветки, которые видны при review, а руками мёржит в мастер нельзя. Рабочие ветки все всегда жили в режиме pull --rebase, притом чужую такую ветку можно было клонировать, поредактировать и запушить обратно, и такой пинг-понг несколько раз. Вполне было работоспособно. По такой модели живёт вроде source.android.com. - 9000

+1 к code review, — как только в компании запретили разработчикам мёржить в мастер без ревью, проблемы с пропаданием и перетиранием кода куда-то исчезли - Denis

Gerrit годная вещь, да, очень упрощает жизнь - Evelynne

Это я к тому, что герритовские review branches есть те самые WIP-репозитории, их у меня получалось более-менее независимо иметь и апдейтить на двух машинах. С другой стороны, изменения там вносились небольшие и постоянно пушились в центральный (герритовский) репозиторий, так что случай Льва это может и не покрывать. - 9000

Ну вот у нас как-бы 100% code review перед мержем в общую ветку (сидим на Stash), и тем не менее. Разобрались с данной конкретной потерей - был параллельный rename и edit, при мерже почему-то не смержились, а девелопер почему-то не смержил руками, а выбрал "ours". То есть в итоге ошибка девелопера, но, видимо, помогло ошибиться то, что он мержил с помощью IDEA, и там как-то очень легко было что-то нажать безвозвратно. - Igor Sereda

А вообще, похоже, корень проблемы - это мерж из чужой feature ветки в свою без задних мыслей про то, как потом это будет сливаться. - Igor Sereda

о да! мердж между ветками с нечетко контролируемым провенансом — это отличная тема. - псы в рапиде

Friends

Login

Service