Ну почему, почему нету ни одной готовой платы с годным АЦП? Хотя бы 20бит сигма-дельта :(((
Все 10тибитные медленные, с 2-3 бита уровень шума. Тьфу блин. Так и буду сидеть на ADuCах
Самый главный постулат — видеть два состояния одного рабочего проекта в разные моменты времени — мне просто непонятен. ЗАЧЕМ?!
Если нужно найти разницу между ними — git diff rev1 rev2
Если нужно проверить есть ли баг в таком-то коммите —
git stash && git checkout oldrev && make && make test && git checkout currev && git stash pop
История при копировании/перемещении? Она есть. git log --follow.
Больше что-то ничего не могу придумать.
Так же, используя gitolite легко можно так же ставить ограничения именно на отдельные папки внутри проекта.
Можно просить историю только файлов, трогающих файлы текущй папки и тд — в git это всё вполне себе естественно.
Просто тут надо ставить себе вопрос — а _надо_ ли держать несколько проектов в одном репозитории?
Это уже вопрос идеологический. В Меркуриал ответ один — не пытайтесь, огребёте.
В гит ответ другой — делайте, если это удобно. В текущем проекте у нас было сперва всё в одном репозитории, потом разделили на три — один с одной частью системы, довольно независимой, один с API этой системы (thrift модули), который через submodule включен в оба других проекта, и третий с сервисом, построенным на базе первого.
При этом, несмотря на то, что из одного репозитория было получено три репозитория, вся история сохранена по каждому проекту, и история не трогающая файлы конкретного репозитория в нём не присутствует более.
Было удобно. Стало удобнее, и более логично. Потребовало только одно — попросить всех закоммитить все свои промежуточные изменения, и потом склонировать два новых репозитория и обновить старый, после чего все продолжили свою работу.
Ну в общем-то, описанное мне и не нравится именно у меркуриала.
В git легко ведутся несколько разных связанных проектов в одном репозитории.
Равно же нетрудно ведутся несколько разных связанных проектов в разных репозиториях с подключением одного в другой.
Находясь внутри какой-либо папки внутри, можно попросить дифф только файлов из этой папки, например.
Вредность функции в том, что ребейз можно делать только пока ты полностью контролируешь ветку.
А если есть некая ветка, в которой A=>B=>C=>D, её кто-то слил к себе и сделал E.
После ребейза у тебя стало Q=>B'=>C'=>D'
А E по-прежнему основывается на D а не на D'.
Вот это и есть проблема.
То же самое с --amend.
Но если ты единственный и неповторимый контроллер ветки, то делай с ней всё что угодно — хоть rebase, хоть amend коммитов прошлых — всё будет в порядке.
В мастере _есть_ мержи всех веток, так как они туда мержатся после ребейза с --no-ff.
Поэтому откатывается _весь_ мерж.
Ребейз не уничтожает информацию о связанных коммитах — цепочка как была так и осталась.
Судя по вопросам, вы ни разу не пользовали ребейз?
1. В инструкции я как раз и пишу, чтобы пуш делали минимум раз в день — перед уходом, либо если переключаются надолго на другую ветку.
2. Пуш ветки перед уходом, дома pull эту ветку и продолжил работу.
3. У нас как правило получается так, что сервер делает фичу, тестирует, заливает, после этого ставится задача фронтенду и бэкенду на поддержку. Они делают у себя фичу, тестируют, заливают.
Да, можно в одну ветку по очереди коммитить а-ля svn, тогда перед каждым коммитом делается так:
git stash
git pull origin specialbranch
git stash pop
git add/rm
git commit
git push origin specialbranch
получится как в svn — все изменения по очереди накладываются разными людьми в общую ветку на сервере.
Сумма уплачиваемого налога (6%) может быть уменьшена на сумму фиксированных платежей, но не более чем на 50%.
Иначе говоря, ежеквартально платится суммарно
max(доход*6%, доход*3%+фиксированные платежи)
ну и примерно с 45 в месяц фиксированные платежи становятся меньше 3% от дохода, соответственно затрат остаётся только 6%.
Сам гит может быть, но вот с точки зрения пользователя, это убийство веником и взрыв мозга бедного девеолпера, который еще вчера писал всё в одного для самого себя любимого не используя VCS.
Все 10тибитные медленные, с 2-3 бита уровень шума. Тьфу блин. Так и буду сидеть на ADuCах
Если нужно найти разницу между ними — git diff rev1 rev2
Если нужно проверить есть ли баг в таком-то коммите —
git stash && git checkout oldrev && make && make test && git checkout currev && git stash pop
История при копировании/перемещении? Она есть. git log --follow.
Больше что-то ничего не могу придумать.
Можно просить историю только файлов, трогающих файлы текущй папки и тд — в git это всё вполне себе естественно.
Просто тут надо ставить себе вопрос — а _надо_ ли держать несколько проектов в одном репозитории?
Это уже вопрос идеологический. В Меркуриал ответ один — не пытайтесь, огребёте.
В гит ответ другой — делайте, если это удобно. В текущем проекте у нас было сперва всё в одном репозитории, потом разделили на три — один с одной частью системы, довольно независимой, один с API этой системы (thrift модули), который через submodule включен в оба других проекта, и третий с сервисом, построенным на базе первого.
При этом, несмотря на то, что из одного репозитория было получено три репозитория, вся история сохранена по каждому проекту, и история не трогающая файлы конкретного репозитория в нём не присутствует более.
Было удобно. Стало удобнее, и более логично. Потребовало только одно — попросить всех закоммитить все свои промежуточные изменения, и потом склонировать два новых репозитория и обновить старый, после чего все продолжили свою работу.
В git легко ведутся несколько разных связанных проектов в одном репозитории.
Равно же нетрудно ведутся несколько разных связанных проектов в разных репозиториях с подключением одного в другой.
Находясь внутри какой-либо папки внутри, можно попросить дифф только файлов из этой папки, например.
2Gb DDR2 SO-DIMM 667MHz PC2-5300 non ECC 256M X 64 200 128M X 8 16 Double 1,8V CL5 5-5-5 2Rx8 1,18" (30mm) FBGA TS256MSQ64V6U JM667QSU-2G, JM667QSU-4GK (kit of 2), KVR667D2S5K2/4G(kit of 2) $42
Читаю всю строку, в конце вижу то что я хочу — kit of 2 и рядом цена $42.
Ясно, тогда я лучше возьму тут под боком и дешевле с доставкой на дом ^_^
А вот по цене мне нравится. У вас:
KVR667D2S5K2 = $42
в нашей деревне
opentech.ru/shop/catalog/item/?id=107411 = 1710 = $61
А если есть некая ветка, в которой A=>B=>C=>D, её кто-то слил к себе и сделал E.
После ребейза у тебя стало Q=>B'=>C'=>D'
А E по-прежнему основывается на D а не на D'.
Вот это и есть проблема.
То же самое с --amend.
Но если ты единственный и неповторимый контроллер ветки, то делай с ней всё что угодно — хоть rebase, хоть amend коммитов прошлых — всё будет в порядке.
Советую вкурить оригинальную документацию и мысли Линуса на тему чистой истории
Еще по теме:
www.jarrodspillers.com/2009/08/19/git-merge-vs-git-rebase-avoiding-rebase-hell/
blog.experimentalworks.net/2009/03/merge-vs-rebase-a-deep-dive-into-the-mysteries-of-revision-control/
То есть было: A=>B=>C=>D
Стало: Q=>B'=>C'=>D'
Поэтому откатывается _весь_ мерж.
Ребейз не уничтожает информацию о связанных коммитах — цепочка как была так и осталась.
Судя по вопросам, вы ни разу не пользовали ребейз?
2. Пуш ветки перед уходом, дома pull эту ветку и продолжил работу.
3. У нас как правило получается так, что сервер делает фичу, тестирует, заливает, после этого ставится задача фронтенду и бэкенду на поддержку. Они делают у себя фичу, тестируют, заливают.
Да, можно в одну ветку по очереди коммитить а-ля svn, тогда перед каждым коммитом делается так:
git stash
git pull origin specialbranch
git stash pop
git add/rm
git commit
git push origin specialbranch
получится как в svn — все изменения по очереди накладываются разными людьми в общую ветку на сервере.
То есть выглядит это так:
*------*-----*-----*
_`----' `---' `---'
Где * — это коммиты в мастере, merge'ы, а петельки под ним — непосредственно ветки по каждой фиче-багу
Иначе говоря, ежеквартально платится суммарно
max(доход*6%, доход*3%+фиксированные платежи)
ну и примерно с 45 в месяц фиксированные платежи становятся меньше 3% от дохода, соответственно затрат остаётся только 6%.