Здравствуйте, IT, Вы писали:
IT>Здравствуйте, alvas, Вы писали:
A>>У Mercurial вроде как есть интергация с Visual Studio.
IT>У GitExtensions тоже есть. Вполне достаточная для работы с ним.
В статье утверждалось
Из существующих GUI для обеих систем можно выделить, пожалуй, Git Extensions для Git и TortoiseHg соответственно для Mercurial. Первый инструмент представляет собой отдельное приложение с очень лёгкой интеграцией с Visual Studio, второй сделан по образу и подобию TortoiseSVN в виде расширения оболочки Windows. Не вдаваясь в подробности, скажу лишь, что то, что русскому хорошо, немцу – смерть. На мой взгляд, работа с репозиторием как со структурой файлов вполне оправдана в случае с Subversion, но совершенно не подходит для репозиториев Git или Mercurial, по той причине, что в Subversion мы работаем с деревом каталогов, а в Git или Mercurial – с деревом коммитов. К тому же разработчики TortoiseHg находятся в состоянии затяжного творческого поиска и когда они из него выйдут совершенно не ясно.
Git — это хорошо, но я было подумал, что картинки будут вроде этих: http://nvie.com/posts/a-successful-git-branching-model/. Скриншоты? Мне кажется намного более актуальным разъяснение того, чего можно добиться с помощью Git или аналогов, и какие подходы при этом рекомендуются, а не картинки, где какие открыть окна и какие жать кнопочки.
В Git нет команды переименования/перемещения файлов. Тем не менее, Git пытается выполнять эту работу автоматически. Чтобы гарантированно сохранить историю переименований, сделайте коммит, потом выполните переименования/перемещения файлов и сделайте ещё один коммит. Точное совпадение содержимого файлов даст гарантию сохранения истории. Если же вы одновременно переименуете и измените файл, то такой гарантии не будет.
Не совсем так. Во-первых, команда-таки есть: git mv. Во-вторых, если одновременно попытаться переименовать и изменить файл, то в этом случае не просто "не будет гарантии", а, наоборот, будет гарантия, что связь между старым и новым файлом уничтожится (старый файл удалён, новый добавлен). Сохранить в коммите запись о том, что файл был одновременно и переименован, и изменён, невозможно.
Здравствуйте, Roman Odaisky, Вы писали:
RO>Git — это хорошо, но я было подумал, что картинки будут вроде этих: http://nvie.com/posts/a-successful-git-branching-model/. Скриншоты? Мне кажется намного более актуальным разъяснение того, чего можно добиться с помощью Git или аналогов, и какие подходы при этом рекомендуются, а не картинки, где какие открыть окна и какие жать кнопочки.
Можно подумать ты учился читать не по букварю с картинками, а сразу по Войне и Миру.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Roman Odaisky, Вы писали:
RO>>Git — это хорошо, но я было подумал, что картинки будут вроде этих: http://nvie.com/posts/a-successful-git-branching-model/. Скриншоты? Мне кажется намного более актуальным разъяснение того, чего можно добиться с помощью Git или аналогов, и какие подходы при этом рекомендуются, а не картинки, где какие открыть окна и какие жать кнопочки.
IT>Можно подумать ты учился читать не по букварю с картинками, а сразу по Войне и Миру.
Я наоборот формат статьи считаю действительно здоровским. В отличие от Hg в картинках от Джоела Спольски, например. Почистить только небольшие огрехи (в этой ветке предложенные, например) + убрать рекламный глянец (на аудиторию он не действует — скорее наоборот)
ИТ>Авторы: ИТ> Игорь Ткачев
ИТ>Аннотация: ИТ>Краткое введение в Git и Git Extensions.
Я уже более десятка лет использую самые разные системы контроля версий, но за всё это время мною было создано веток меньше, чем при написании этой статьи.
RO>Git — это хорошо, но я было подумал, что картинки будут вроде этих: http://nvie.com/posts/a-successful-git-branching-model/. Скриншоты? Мне кажется намного более актуальным разъяснение того, чего можно добиться с помощью Git или аналогов, и какие подходы при этом рекомендуются, а не картинки, где какие открыть окна и какие жать кнопочки.
Вы не поверите, но большинство людей ждут именно картинок с указаниями куда смотреть и что жать в какой момент, т.е. чтобы вообще всё было разжовано и показано без особых пробелов.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, alvas, Вы писали:
A>>У Mercurial вроде как есть интергация с Visual Studio.
IT>У GitExtensions тоже есть. Вполне достаточная для работы с ним.
А картинки к интеграции есть? Что -то в статье не заметил.
Здравствуйте, Аноним, Вы писали:
А>Вы не поверите, но большинство людей ждут именно картинок с указаниями куда смотреть и что жать в какой момент, т.е. чтобы вообще всё было разжовано и показано без особых пробелов.
Так RSDN (я тешу себя надеждой) отнюдь не представляет собой средоточие таких людей.
Мессия — только человек, причём в контексте религии. Долго пытался понять смысл предложения, прежде чем осознал неуместное использования слова.
Любой коммит (от англ. commit) в Git производится в локальный репозиторий, а затем эти изменения при необходимости проталкиваются на сервер. Т.е. чтобы сделать коммит на сервер, нужно нажать не одну кнопку, а две. В некоторых случаях это даже удобно. Например, можно лететь в самолёте, при этом писать код и периодически сохранять свои изменения в локальный репозиторий, не соединяясь с центральным сервером. Прикольно, конечно, но в целом удобство такой возможности весьма сомнительно. Как часто вы летаете в самолётах, а как часто при этом пишете код? Стоит ли менять систему контроля версий только из-за такой возможности? Скорее всего, вряд ли.
Вообще нет, это очень важно. DVCS подкупили меня не распределённостью, которой я пользуюсь крайне редко, а именно локальными комитами, видимыми только мне контрольными точками к которым можно откатиться. Возможность безболезненно эксперементировать, рефакторить не боясь ошибиться бесценна. Лично для меня именно локальные комиты были решающим аргументом.
Из существующих GUI для обеих систем можно выделить, пожалуй, Git Extensions для Git и TortoiseHg соответственно для Mercurial.
Для меркуриала есть аж две интеграции с Visual Studio. Я пользуюсь VisualHG. Её не заметно, просто работает.
Не увидел аналога Preview incoming changes from remote repository. Это как pull, но локальный репозиторий не изменяется.
Не раскрыт вопрос аутентификации и авторизации.
Не раскрыт вопрос работы с большими файлами. Mercurial, например, выделяет оперативную память под файл непрырывным куском,поэтому с файлами больше 200-300Мб работать сложновато.
Не раскрыт вопрос работы с двоичными файлами. Mercurial, например, считает двоичным любой файл в котором есть нулевой байт, в том числе текстовые файлы в кодировке UTF-16.
Здравствуйте, CaptainFlint, Вы писали:
CF>Не совсем так. Во-первых, команда-таки есть: git mv. Во-вторых, если одновременно попытаться переименовать и изменить файл, то в этом случае не просто "не будет гарантии", а, наоборот, будет гарантия, что связь между старым и новым файлом уничтожится (старый файл удалён, новый добавлен). Сохранить в коммите запись о том, что файл был одновременно и переименован, и изменён, невозможно.
Это что правда так? Нельзя одновременно менять и переименовывать файлы с сохранением истории? Какое убожество, как я люблю меркуриал.
Здравствуйте, adontz, Вы писали:
CF>>Не совсем так. Во-первых, команда-таки есть: git mv. Во-вторых, если одновременно попытаться переименовать и изменить файл, то в этом случае не просто "не будет гарантии", а, наоборот, будет гарантия, что связь между старым и новым файлом уничтожится (старый файл удалён, новый добавлен). Сохранить в коммите запись о том, что файл был одновременно и переименован, и изменён, невозможно.
A>Это что правда так? Нельзя одновременно менять и переименовывать файлы с сохранением истории?
Когда мне это потребовалось, я довольно долго рылся в поисках решения, и всё, что нашёл, — это утверждения о невозможности такого действия одинарным коммитом. Не исключаю, что в последних версиях что-то такое добавили. Вообще, насколько я слышал, Git и Hg по функциональности практически идентичны и различаются лишь подходом к выполняемым операциям, а если в одном из них появляется что-то новое, другой то же самое быстренько реализует и у себя.
CF> Не совсем так. Во-первых, команда-таки есть: git mv. Во-вторых, если одновременно попытаться переименовать и изменить файл, то в этом случае не просто "не будет гарантии", а, наоборот, будет гарантия, что связь между старым и новым файлом уничтожится (старый файл удалён, новый добавлен). Сохранить в коммите запись о том, что файл был одновременно и переименован, и изменён, невозможно.
Не совсем так. Точнее говоря, совсем не так.
Renames are handled implicitly rather than explicitly. A common complaint with CVS is that it uses the name of a file to identify its revision history, so moving or renaming a file is not possible without either interrupting its history, or renaming the history and thereby making the history inaccurate. Most post-CVS revision control systems solve this by giving a file a unique long-lived name (a sort of inode number) that survives renaming. Git does not record such an identifier, and this is claimed as an advantage.[32][33] Source code files are sometimes split or merged as well as simply renamed,[34] and recording this as a simple rename would freeze an inaccurate description of what happened in the (immutable) history. Git addresses the issue by detecting renames while browsing the history of snapshots rather than recording it when making the snapshot.[35] (Briefly, given a file in revision N, a file of the same name in revision N−1 is its default ancestor. However, when there is no like-named file in revision N−1, Git searches for a file that existed only in revision N−1 and is very similar to the new file.) However, it does require more CPU-intensive work every time history is reviewed, and a number of options to adjust the heuristics.
Здравствуйте, ., Вы писали:
CF>> Не совсем так. Во-первых, команда-таки есть: git mv. Во-вторых, если одновременно попытаться переименовать и изменить файл, то в этом случае не просто "не будет гарантии", а, наоборот, будет гарантия, что связь между старым и новым файлом уничтожится (старый файл удалён, новый добавлен). Сохранить в коммите запись о том, что файл был одновременно и переименован, и изменён, невозможно. .>Не совсем так. Точнее говоря, совсем не так. .>
Renames are handled implicitly rather than explicitly. A common complaint with CVS is that it uses the name of a file to identify its revision history, so moving or renaming a file is not possible without either interrupting its history, or renaming the history and thereby making the history inaccurate. Most post-CVS revision control systems solve this by giving a file a unique long-lived name (a sort of inode number) that survives renaming. Git does not record such an identifier, and this is claimed as an advantage.[32][33] Source code files are sometimes split or merged as well as simply renamed,[34] and recording this as a simple rename would freeze an inaccurate description of what happened in the (immutable) history. Git addresses the issue by detecting renames while browsing the history of snapshots rather than recording it when making the snapshot.[35] (Briefly, given a file in revision N, a file of the same name in revision N−1 is its default ancestor. However, when there is no like-named file in revision N−1, Git searches for a file that existed only in revision N−1 and is very similar to the new file.) However, it does require more CPU-intensive work every time history is reviewed, and a number of options to adjust the heuristics.
В контексте .Net это плохо. В одном файле всего один класс. Содержимое файла по нескольким другим распредляется довольно редко. А вот куча похожих файлов (EventArgs какие-нибудь) в одном каталоге, напротив, обычное дело. Если git сглючит будет неприятно.
Здравствуйте, adontz, Вы писали:
a> Не увидел аналога Preview incoming changes from remote repository. Это как pull, но локальный репозиторий не изменяется.
pull это просто 2 команды подряд — fetch (забрать изменения из remote) и merge (слить удалённую ветку с локальной). Это кстати, вроде упомянуто в статье. Но явно не сказано, что если хочешь preview, сделай только fetch, потом сравни ветки diff, хотя в общем-то можно догадаться.
a> Не раскрыт вопрос аутентификации и авторизации.
В самом гите нет аутентикации. Там только идентификация.
Аутентификацию нужно устраивать на транспортном уровне: ssh, unc, http, https.
С авторизацией тоже всё "просто" — т.к. система распределённая, репозиторий нужен весь. А значит только две опции — rw, ro.
Коммиты можно подписывать для защиты целостности — pgp подписывание коммитов.
Если нужно разделять права, то нужно разделять репозитории. Множество репозиториев можно компоновать в submodules, что-то типа аналога svn:externals, если я правильно понимаю.
a> Не раскрыт вопрос работы с большими файлами. Mercurial, например, выделяет оперативную память под файл непрырывным куском,поэтому с файлами больше 200-300Мб работать сложновато.
примерно то же самое.
a> Не раскрыт вопрос работы с двоичными файлами. Mercurial, например, считает двоичным любой файл в котором есть нулевой байт, в том числе текстовые файлы в кодировке UTF-16.
Примерно то же самое, но можно докрутить.
Здравствуйте, adontz, Вы писали:
a> В контексте .Net это плохо. В одном файле всего один класс. Содержимое файла по нескольким другим распредляется довольно редко. А вот куча похожих файлов (EventArgs какие-нибудь) в одном каталоге, напротив, обычное дело. Если git сглючит будет неприятно.
The thing is, it does better than anything that _tries_ to be "reliable". I can pretty much _guarantee_ that you can't do it better.
(c) Linus Torvalds
The thing is, it does better than anything that _tries_ to be "reliable". I can pretty much _guarantee_ that you can't do it better.
.>(c) Linus Torvalds
Здравствуйте, ., Вы писали:
a>> Не увидел аналога Preview incoming changes from remote repository. Это как pull, но локальный репозиторий не изменяется. .>pull это просто 2 команды подряд — fetch (забрать изменения из remote) и merge (слить удалённую ветку с локальной). Это кстати, вроде упомянуто в статье. Но явно не сказано, что если хочешь preview, сделай только fetch, потом сравни ветки diff, хотя в общем-то можно догадаться.
Да нет, preview вообще ничего не меняет. fetch, как я понял, добавляет историю в локальный репозиторий, а после preview я просто получаю список changeset'ов с комментариями.
.>В самом гите нет аутентикации. Там только идентификация. .>Аутентификацию нужно устраивать на транспортном уровне: ssh, unc, http, https. .>С авторизацией тоже всё "просто" — т.к. система распределённая, репозиторий нужен весь. А значит только две опции — rw, ro. .>Коммиты можно подписывать для защиты целостности — pgp подписывание коммитов. .>Если нужно разделять права, то нужно разделять репозитории. Множество репозиториев можно компоновать в submodules, что-то типа аналога svn:externals, если я правильно понимаю.
Хм. В меркуриале за апачем можно давать права доступа на отдельные папки, не только на репозиторий целиком. Но с другой строны, сам меркуриал поддерживает аутентицикацию.
Здравствуйте, adontz, Вы писали:
a> .>pull это просто 2 команды подряд — fetch (забрать изменения из remote) и merge (слить удалённую ветку с локальной). Это кстати, вроде упомянуто в статье. Но явно не сказано, что если хочешь preview, сделай только fetch, потом сравни ветки diff, хотя в общем-то можно догадаться. a> Да нет, preview вообще ничего не меняет. fetch, как я понял, добавляет историю в локальный репозиторий, а после preview я просто получаю список changeset'ов с комментариями.
У тебя в репозитории будет ветка твоя с именем "master", с твоими изменениями и "remotes/origin/master" с изменениями из "центрального" репозитория. Эти ветки независимы. Любые ветки можно мержить. но ведь можно и не мержить! Т.е. fetch просто скачивает изменения удалённых веток к себе. Дальше делай что хочешь.
Что такое список changeset'ов?
a> Хм. В меркуриале за апачем можно давать права доступа на отдельные папки, не только на репозиторий целиком.
Да, афаик нельзя.
А можно привести пример полезного юскейса для этого? Раньше в svn таким пользовался, но там папки по сути были независимые проекты для разных команд, и делалось это лишь потому, что так удобнее администрировать, чем плодить кучу репозиториев.
a> Но с другой строны, сам меркуриал поддерживает аутентицикацию.
А что там аутентифицировать, если репозиторий лежит локально?
Здравствуйте, ., Вы писали:
.>Что такое список changeset'ов?
хеш, список файлов, коментарий.
.>А можно привести пример полезного юскейса для этого? Раньше в svn таким пользовался, но там папки по сути были независимые проекты для разных команд, и делалось это лишь потому, что так удобнее администрировать, чем плодить кучу репозиториев.
Ну у меня большие проекты Иногда надо дать права только на часть.
a>> Но с другой строны, сам меркуриал поддерживает аутентицикацию. .>А что там аутентифицировать, если репозиторий лежит локально?
Здравствуйте, AlexNek, Вы писали:
IT>>У GitExtensions тоже есть. Вполне достаточная для работы с ним. AN>А картинки к интеграции есть? Что -то в статье не заметил.
Там три кнопки: Commit, Pull и Push. А какая другая функциональность нужна от интеграции?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Там три кнопки: Commit, Pull и Push. А какая другая функциональность нужна от интеграции?
diff для выбранного файла или папки, история (аналогично), revert (аналогично). Если там только Commit, Push и Pull, то считай что интеграции никакой нет.
Здравствуйте, adontz, Вы писали:
IT>>Там три кнопки: Commit, Pull и Push. А какая другая функциональность нужна от интеграции?
A>diff для выбранного файла или папки,
diff с чем?
A>история (аналогично),
Кстати, вот это не помешало бы.
A>revert (аналогично).
Reset file changes и Reset chunk of file делаются из окна коммита. Это вообще гораздо более функциональное окно, чем в том же svn.
A>Если там только Commit, Push и Pull, то считай что интеграции никакой нет.
Она и не нужна. Я и этими то кнопками не пользуюсь.
Кстати, есть ещё одна кнопка — открыть Git Extensions. Ну а дальше решение сводится к описанному в статье.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
A>>diff для выбранного файла или папки, IT>diff с чем?
С базовой версией. То есть дифф текущего состояния (причём лучше даже чтоб не требовало сохранять файл) и последнего закомиченного состояния.
IT>Reset file changes и Reset chunk of file делаются из окна коммита. Это вообще гораздо более функциональное окно, чем в том же svn.
Я хотел бы это видеть в контекстном меню файла прямо в студии.
IT>Кстати, есть ещё одна кнопка — открыть Git Extensions. Ну а дальше решение сводится к описанному в статье.
Ну ты — джедай. Тут уж ничего не поделаешь, привыкай
Здравствуйте, adontz, Вы писали:
a> .>Что такое список changeset'ов? a> хеш, список файлов, коментарий.
и чем оно принципиально от коммита отличается? А пачка коммитов от списка changeset'ов? Короче, в git то же самое, но проще, т.к. не вносит лишних сущностей.
a> Ну у меня большие проекты Иногда надо дать права только на часть.
Тогда от проекта отпочковывается часть (притом вовсе не обязательно делить по каталогам) и это будет независимый репоризторий, с которым можно потом мержиться как обычно.
Правда я сам так не пробовал...
a> Локально ничего. Удалённо.
Так удалённо в гите этим занимается транспортный протокол, ssh какой-нибудь — что удобнее. Вроде есть gitosis, родной протокол какой-то, правда накой нужно — непонятно, и так всё работает.
Здравствуйте, ., Вы писали:
a>> хеш, список файлов, коментарий. .>и чем оно принципиально от коммита отличается? А пачка коммитов от списка changeset'ов? Короче, в git то же самое, но проще, т.к. не вносит лишних сущностей.
Нет, ничем. Я про другое. Ты можешь просмотреть краткую информацию о changeset'ах (сотня байт) прежде чем решать скачивать ли их в локальный репозиторий вообще.
a>> Ну у меня большие проекты Иногда надо дать права только на часть. .>Тогда от проекта отпочковывается часть (притом вовсе не обязательно делить по каталогам) и это будет независимый репоризторий, с которым можно потом мержиться как обычно. .>Правда я сам так не пробовал...
Ну это вариант, конечно, но не удобно в администрировании.
a>> Локально ничего. Удалённо. .>Так удалённо в гите этим занимается транспортный протокол, ssh какой-нибудь — что удобнее. Вроде есть gitosis, родной протокол какой-то, правда накой нужно — непонятно, и так всё работает.
Здравствуйте, adontz, Вы писали:
a> Нет, ничем. Я про другое. Ты можешь просмотреть краткую информацию о changeset'ах (сотня байт) прежде чем решать скачивать ли их в локальный репозиторий вообще.
А, понятно. Не, нельзя вроде (если, конечно, нет больше никаких способов доступа типа ssh или gitweb). Как я понимаю, это нужно только для защиты от кривых рук, коммитящих фотографии любимой кошечки.bmp. А обычно типичный fetch и так сотни байт.
a> Ну это вариант, конечно, но не удобно в администрировании.
Да, согласен.
Здравствуйте, ., Вы писали:
a>> Нет, ничем. Я про другое. Ты можешь просмотреть краткую информацию о changeset'ах (сотня байт) прежде чем решать скачивать ли их в локальный репозиторий вообще. .>А, понятно. Не, нельзя вроде (если, конечно, нет больше никаких способов доступа типа ssh или gitweb). Как я понимаю, это нужно только для защиты от кривых рук, коммитящих фотографии любимой кошечки.bmp. А обычно типичный fetch и так сотни байт.
Ну бывает на воздухе через GPRS сидишь, да и кафешечках интернет не всегда быстрее.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, AlexNek, Вы писали:
IT>>>У GitExtensions тоже есть. Вполне достаточная для работы с ним. AN>>А картинки к интеграции есть? Что -то в статье не заметил.
IT>Там три кнопки: Commit, Pull и Push. А какая другая функциональность нужна от интеграции?Так хочется просто глянуть на фото может будущего друга
типа тут, глянул и уже не хочется http://gitscc.codeplex.com/
Или здесь между 6 и 7 минутой How to setup Git Extensions with VS.NET 2008
Оказывается как установить эту штуку нужно 13 минут объяснять
Здравствуйте, adontz, Вы писали:
A>Не раскрыт вопрос работы с большими файлами. Mercurial, например, выделяет оперативную память под файл непрырывным куском,поэтому с файлами больше 200-300Мб работать сложновато.
Для mercurial есть решения в виде:
1) Bigfiles Extension
2) The Kiln Big Files extension которое сделали для Kiln (по поводу можно ли его использовать отдельно от Kiln читать здесь)
Здравствуйте, adontz, Вы писали:
A>>>diff для выбранного файла или папки, IT>>diff с чем?
A>С базовой версией. То есть дифф текущего состояния (причём лучше даже чтоб не требовало сохранять файл) и последнего закомиченного состояния.
Жмёшь Commit и там всё это смотришь.
IT>>Reset file changes и Reset chunk of file делаются из окна коммита. Это вообще гораздо более функциональное окно, чем в том же svn.
A>Я хотел бы это видеть в контекстном меню файла прямо в студии.
Я тоже хотел бы. Можно фич реквест авторам написать.
IT>>Кстати, есть ещё одна кнопка — открыть Git Extensions. Ну а дальше решение сводится к описанному в статье.
A>Ну ты — джедай. Тут уж ничего не поделаешь, привыкай
Ты не поверишь, но даже те кнопки, которые есть в студии мной практически не используются. Нет необходимости. Одтельный тул гораздо удобнее, чем всякие интеграционные штучки. Единственное исключение — история, ей и в гите не сложно пользоваться, но навигация по проекту в студии всё же поудобнее.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
A>>С базовой версией. То есть дифф текущего состояния (причём лучше даже чтоб не требовало сохранять файл) и последнего закомиченного состояния. IT>Жмёшь Commit и там всё это смотришь.
Не, ну там все файлы. Иди ищи нужный...
IT>>>Кстати, есть ещё одна кнопка — открыть Git Extensions. Ну а дальше решение сводится к описанному в статье. A>>Ну ты — джедай. Тут уж ничего не поделаешь, привыкай IT>Ты не поверишь, но даже те кнопки, которые есть в студии мной практически не используются. Нет необходимости. Одтельный тул гораздо удобнее, чем всякие интеграционные штучки. Единственное исключение — история, ей и в гите не сложно пользоваться, но навигация по проекту в студии всё же поудобнее.
Верю, я сам люблю отдельные тулы. Но контекстное меню я тоже люблю.
Здравствуйте, IT, Вы писали:
IT>Ты не поверишь, но даже те кнопки, которые есть в студии мной практически не используются. Нет необходимости. Одтельный тул гораздо удобнее, чем всякие интеграционные штучки. Единственное исключение — история, ей и в гите не сложно пользоваться, но навигация по проекту в студии всё же поудобнее.
Внимание, опасность!
Следующий шаг — это переход к работе в командной строке. А дальше и до Линукса недалеко.
Здравствуйте, adontz, Вы писали:
IT>>В коммите не все файлы, а только те, которые ты изменил.
A>Ну какая разница, их может быть несколько десятков. Переименовал класс и куча файлов поменялась. Нет, как раз diff удобнее в контекстном меню.
А если файл не менялся, то что ты должен увидеть в контекстном меню? Нет, как раз diff удобнее в сабмите, видно не только один единственный файл, а сразу полный набор изменений.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Пока, кроме истории, больше ничего полезного для контекстного меню не приходит в голову.
Еще blame/annotate. Они могут понадобиться и для неизмененого файла. Я частенько пользуюсь этими инструментами, когда пытаюсь выяснить причины предыдущих изменений, сделанных предшественниками.
Здравствуйте, IT, Вы писали:
IT>>>В коммите не все файлы, а только те, которые ты изменил. A>>Ну какая разница, их может быть несколько десятков. Переименовал класс и куча файлов поменялась. Нет, как раз diff удобнее в контекстном меню. IT>А если файл не менялся, то что ты должен увидеть в контекстном меню?
Diff. А вот когда я на него нажму, он мне в обеих панельках покажет одинаковые файлы и диалоговое окно: files are binary identical.
IT>Нет, как раз diff удобнее в сабмите, видно не только один единственный файл, а сразу полный набор изменений.
Это другой use case. А мне не надо просто вспомнить что я поменял.
Здравствуйте, adontz, Вы писали:
A>Это другой use case. А мне не надо просто вспомнить что я поменял.
А если ты что-то удалил или переименовал, то как ты это вспомнишь?
В общем, всё это вкусовщина. А если есть непреодолимое желание такое получить, то всё это можно и самому воплотить. Благо с этим теперь на гитхабе вообще никаких проблем.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, IT, Вы писали:
IT>>Там три кнопки: Commit, Pull и Push. А какая другая функциональность нужна от интеграции?
A>diff для выбранного файла или папки, история (аналогично), revert (аналогично). Если там только Commit, Push и Pull, то считай что интеграции никакой нет.
История там тоже есть, через контекстное меню. Там же реверт. Другое дело, что и диф и блейм из контекстного меню работают только для закоммиченных файлов.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, AlexNek, Вы писали:
AN>>Оказывается как установить эту штуку нужно 13 минут объяснять
IT>Да ладно. Это требует времени меньше, чем написание твоего сообщения.
После просмотра, я почти уверен, что установка займет минимум вечер.
Я бы с удовольствием перешел бы с SVN на что то другое, но при этом не хочется вместо одних проблем иметь другие.
Ну например, изменение и переименование файла происходит почти автоматом при переименовании имени класса. Как я понял, Гит этого не любит.
С историей по файлам похоже также есть проблемы.
Похоже нет и отметок состояния файла в визуал студио в GitExtension.
Также не совсем понятно как Гиту удается минимизировать конфликты.
Вот например работа, с SVN небольшой команды в пятницу перед сдачей этапа в понедельник.
С утра все забрали актуальную копию репозитория, до обеда неспешная работа по исправлению ошибок, кто то успел закммитить исправления, кто то еще правит. После обеда тестеры вдруг находят еще пару багов кторые нужно непременно исправить сегодня.
Кто не успел доделать нужно бросить и править срочно найденные баги (можно либо текущее состояние куда скопировать, либо поверх править) Ну вот вроде все сделал, через час домой, пора коммитить. А фиг вам низзя, надо вначале забрать актуальную версию.
При взятии выясняется что в паре файлов конфликты, причем довольно много. Разбираться некогда оставляем свою версию. Идем в историю каждого конфликтного файла имена которых записали на бумажке и переносим изменения сделанные другим разработчиком. Сделали, но прога не стартует. Провидение рекомендует глянуть журнал изменений за сегодня и похоже кто то изменил сопуствующий проект, но забыл закомиттить ДЛЛ-ку. Вроде все. Пробуем опять сохранить все, и опять непонятно почему облом. Брать изменения сейчас нельзя иначе не удастся просто потестить свои исправления, я знаю, что изменения сделал сосед и теперь мне будут приходит только "правильные" данные. Ищем изменный файл "вручную", по счастью мержится на автомате. Ок все работает, теперь берем все и проверяем еще раз. Все ок, но вечер пятницы безвозвратно утерян. (Может и немного присочинил, но для сравнения пойдет)
Подозреваю что с Гитом будет по другому, но интересно как?
Здравствуйте, AlexNek, Вы писали:
AN> После просмотра, я почти уверен, что установка займет минимум вечер. AN> Я бы с удовольствием перешел бы с SVN на что то другое, но при этом не хочется вместо одних проблем иметь другие.
Ты можешь воспользоваться git svn для начала, поиграться самому, есть несколько подводных камней (надо бы это мне как-то рассказать на досуге), но почувствовать вкус вполне можно.
AN> Ну например, изменение и переименование файла происходит почти автоматом при переименовании имени класса. Как я понял, Гит этого не любит.
Почему не любит? Ему пофиг — переименовывай как хочешь, чем хочешь. Он сам всё что надо подхватит.
AN> С историей по файлам похоже также есть проблемы. AN> Похоже нет и отметок состояния файла в визуал студио в GitExtension.
В Идее есть суперская интеграция, есть tortoisegit, есть gitk, git gui, gitextensions... но я почему-то использую коммандную строку в большинстве случаев.
AN> Также не совсем понятно как Гиту удается минимизировать конфликты.
Тем, что коммиты маленькие.
AN> Вот например работа, с SVN небольшой команды в пятницу перед сдачей этапа в понедельник. AN> С утра все забрали актуальную копию репозитория, до обеда неспешная работа по исправлению ошибок, кто то успел закммитить исправления, кто то еще правит. После обеда тестеры вдруг находят еще пару багов кторые нужно непременно исправить сегодня. AN> Кто не успел доделать нужно бросить и править срочно найденные баги (можно либо текущее состояние куда скопировать, либо поверх править)
git stash
[делаем хотфикс обнаруженных багов]
git commit
git push
[пусть тестеры тестят]
git stash pop
[вернулись к своим изменениям, продолжаем добавлять новые баги]
AN> Ну вот вроде все сделал, через час домой, пора коммитить. А фиг вам низзя, надо вначале забрать актуальную версию. AN> При взятии выясняется что в паре файлов конфликты, причем довольно много. Разбираться некогда оставляем свою версию. Идем в историю каждого конфликтного файла имена которых записали на бумажке и переносим изменения сделанные другим разработчиком. Сделали, но прога не стартует. Провидение рекомендует глянуть журнал изменений за сегодня и похоже кто то изменил сопуствующий проект, но забыл закомиттить ДЛЛ-ку. Вроде все. Пробуем опять сохранить все, и опять непонятно почему облом. Брать изменения сейчас нельзя иначе не удастся просто потестить свои исправления, я знаю, что изменения сделал сосед и теперь мне будут приходит только "правильные" данные. Ищем изменный файл "вручную", по счастью мержится на автомате. Ок все работает, теперь берем все и проверяем еще раз. Все ок, но вечер пятницы безвозвратно утерян. (Может и немного присочинил, но для сравнения пойдет)
AN> Подозреваю что с Гитом будет по другому, но интересно как?
Да, там можно делать бранчи. Притом легко. Можно тупо внести исправление в утренний trunk, создав бранч с этим хотфиксом. Или тупо всё коммитить, создать бранч от последней стабильной версии и в неё сделать cherry-pick хотфикса.
Изменения брать можно в любой момент времени — с твоими исправлениями оно пересечётся только при мерже, который не обязателен. В svn же ты обязан замержить текущие модифицированные файлы при update. Притом, если что-то пошло не так... вешайся. В гите же обычный мерж веток — не понравилось — отменил, оставил на потом.
А ещё есть магический rebase...
Слияние в Git выполняется не сильно сложнее создания новых веток. Единственная вещь, которую нужно понимать – это то, что любые манипуляции делаются над текущей веткой. То есть, если вы ходить слить две ветки...
Здравствуйте, ., Вы писали:
.>Здравствуйте, AlexNek, Вы писали:
AN>> После просмотра, я почти уверен, что установка займет минимум вечер. AN>> Я бы с удовольствием перешел бы с SVN на что то другое, но при этом не хочется вместо одних проблем иметь другие. .>Ты можешь воспользоваться git svn для начала, поиграться самому, есть несколько подводных камней (надо бы это мне как-то рассказать на досуге), но почувствовать вкус вполне можно.
Но как я понял из описания — это просто синхронизатор двух репозиториев, да и еще с командной строкой
Вот нашел еще один огромный минус
Основными достоинствами git (в сравнении с другими распределёнными системами контроля версий) в настоящее время принято считать:
* Unix-ориентированность и глубокий unixway во всём;
и еще
Ревизии обозначаются с помощью SHA1-хэшей, с одной стороны они уникальны, с другой — возникает необходимость оперировать большими строками хэшей вместо маленьких номеров.
AN>> Ну например, изменение и переименование файла происходит почти автоматом при переименовании имени класса. Как я понял, Гит этого не любит. .>Почему не любит? Ему пофиг — переименовывай как хочешь, чем хочешь. Он сам всё что надо подхватит.
Не знаю, здесь где то было написано.
AN>> С историей по файлам похоже также есть проблемы. AN>> Похоже нет и отметок состояния файла в визуал студио в GitExtension. .>В Идее есть суперская интеграция, есть tortoisegit, есть gitk, git gui, gitextensions... но я почему-то использую коммандную строку в большинстве случаев.
А что такое "Идея"? И что же лучше для студии исходя из того, что я ненавижу командные строки.
AN>> Также не совсем понятно как Гиту удается минимизировать конфликты. .>Тем, что коммиты маленькие.
Так размер коммита зависит от программиста. Если для правки ошибки нужно исправить Х строк, так эти Х будут всегда.
AN>> Вот например работа, с SVN небольшой команды в пятницу перед сдачей этапа в понедельник. AN>> С утра все забрали актуальную копию репозитория, до обеда неспешная работа по исправлению ошибок, кто то успел закммитить исправления, кто то еще правит. После обеда тестеры вдруг находят еще пару багов кторые нужно непременно исправить сегодня. AN>> Кто не успел доделать нужно бросить и править срочно найденные баги (можно либо текущее состояние куда скопировать, либо поверх править)
.>git stash
добавить текущие незакоммиченные изменения в стек изменений и сбросить текущую рабочую копию до HEAD'а репозитория;
непонятно почему это начало работы. Что все мои изменения затрутся? Хочу просто взять текущее состояние и смержить с моим. .>[делаем хотфикс обнаруженных багов] .>git commit .>git push
вносим изменения в удаленный репозитарий (удаленную ветку)
А тут обломов не бывает? .>[пусть тестеры тестят] .>git stash pop
применить последнее изменение из стека к текущей рабочей копии и удалить его из стека;
То есть имеется еще какой то локальный стек изменений? .>[вернулись к своим изменениям, продолжаем добавлять новые баги]
AN>> Ну вот вроде все сделал, через час домой, пора коммитить. А фиг вам низзя, надо вначале забрать актуальную версию. AN>> При взятии выясняется что в паре файлов конфликты, причем довольно много. Разбираться некогда оставляем свою версию. Идем в историю каждого конфликтного файла имена которых записали на бумажке и переносим изменения сделанные другим разработчиком. Сделали, но прога не стартует. Провидение рекомендует глянуть журнал изменений за сегодня и похоже кто то изменил сопуствующий проект, но забыл закомиттить ДЛЛ-ку. Вроде все. Пробуем опять сохранить все, и опять непонятно почему облом. Брать изменения сейчас нельзя иначе не удастся просто потестить свои исправления, я знаю, что изменения сделал сосед и теперь мне будут приходит только "правильные" данные. Ищем изменный файл "вручную", по счастью мержится на автомате. Ок все работает, теперь берем все и проверяем еще раз. Все ок, но вечер пятницы безвозвратно утерян. (Может и немного присочинил, но для сравнения пойдет)
AN>> Подозреваю что с Гитом будет по другому, но интересно как? .>Да, там можно делать бранчи. Притом легко. Можно тупо внести исправление в утренний trunk, создав бранч с этим хотфиксом. Или тупо всё коммитить, создать бранч от последней стабильной версии и в неё сделать cherry-pick хотфикса. .>Изменения брать можно в любой момент времени — с твоими исправлениями оно пересечётся только при мерже, который не обязателен.
Это совсем не понятно куда денутся мои изменения? .>В svn же ты обязан замержить текущие модифицированные файлы при update. Притом, если что-то пошло не так... вешайся. В гите же обычный мерж веток — не понравилось — отменил, оставил на потом. .>А ещё есть магический rebase...
Пока искал описание комманд попалось несколько интересных ссылок http://githowto.com/ http://www.proft.com.ua/2010/10/17/spravochnik-po-git-i-mercurial/ http://www.freesource.info/wiki/RuslanHihin/gitusermanual http://www.altlinux.org/Справочник_по_git.alt http://evasive.ru/articles/git_kung-fu.html http://habrahabr.ru/blogs/Git/60347/ http://git.or.cz/course/svn.html http://habrahabr.ru/blogs/Git/118924/
Здравствуйте, AlexNek, Вы писали:
AN> .>Ты можешь воспользоваться git svn для начала, поиграться самому, есть несколько подводных камней (надо бы это мне как-то рассказать на досуге), но почувствовать вкус вполне можно. AN> Но как я понял из описания — это просто синхронизатор двух репозиториев, да и еще с командной строкой
Да. В общем-то в любой совместной работе в гите ты синхронизируешь два репозитория. Если используешь git svn, то просто второй репозиторий — svn. Правда так как он довольно примитивный, приходится шаманить слегка.
Насчёт командной строки... там в общем-то всего 2 команды надо. По-мему в tortoisegit есть, но я ни разу не использовал.
AN> Вот нашел еще один огромный минус AN>
AN> Основными достоинствами git (в сравнении с другими распределёнными системами контроля версий) в настоящее время принято считать:
AN> * Unix-ориентированность и глубокий unixway во всём;
Эээ... оно не сильно отлчиается от svn.
AN> и еще AN>
AN> Ревизии обозначаются с помощью SHA1-хэшей, с одной стороны они уникальны, с другой — возникает необходимость оперировать большими строками хэшей вместо маленьких номеров.
Оперировать с идентификаторами ревизий практически не приходится. Трудностей не вызывает. Тем более достаточно обычно первых 5-6 символов хеша. А запоминать ревизию 23723 и bd94f особой разницы нет.
AN> .>В Идее есть суперская интеграция, есть tortoisegit, есть gitk, git gui, gitextensions... но я почему-то использую коммандную строку в большинстве случаев. AN> А что такое "Идея"? И что же лучше для студии исходя из того, что я ненавижу командные строки.
Jetbrains IDEA. Хз... дело вкуса. Надо пробовать самому.
AN> AN>> Также не совсем понятно как Гиту удается минимизировать конфликты. AN> .>Тем, что коммиты маленькие. AN> Так размер коммита зависит от программиста. Если для правки ошибки нужно исправить Х строк, так эти Х будут всегда.
Нет. Если используешь svn, то перед тем как коммитить — надо точно знать, что коммитишь и не поломается ли чего у других.
При использовании git коммитишь когда завершаешь какую-то мысль. Т.е. например делаешь какую-то фичу. Чтобы её сделать — надо: что-то порефакторить, написать новый код, написать тест, добавить кнопки для новой фичи, поправить баги, дописать заглушки и т.п. Так вот коммитить можешь после каждого этапа.
AN>
AN> добавить текущие незакоммиченные изменения в стек изменений и сбросить текущую рабочую копию до HEAD'а репозитория;
AN> непонятно почему это начало работы. Что все мои изменения затрутся? Хочу просто взять текущее состояние и смержить с моим.
Я имел в виду, сиутацию, когда ты делаешь что-то новое, поломал кучу кода, ничего пока не работает и ВНЕЗАПНО надо сделать какой-то хотфикс.
AN> .>[делаем хотфикс обнаруженных багов] AN> .>git commit AN> .>git push
AN>
AN> вносим изменения в удаленный репозитарий (удаленную ветку)
AN> А тут обломов не бывает?
Если кто-то что-то до тебя закоммитил, то при наличии конфликтов ругнётся, конечно. Будешь должен смержить или оставить мерж на потом.
Или что ты имеешь в виду под обломом?
AN>
AN> применить последнее изменение из стека к текущей рабочей копии и удалить его из стека;
AN> То есть имеется еще какой то локальный стек изменений?
Тупо для удобства сделано — ветки автоматом создаются и в стек складываются, потом достаются. Автоматизация частого юзкейса.
AN> .>Да, там можно делать бранчи. Притом легко. Можно тупо внести исправление в утренний trunk, создав бранч с этим хотфиксом. Или тупо всё коммитить, создать бранч от последней стабильной версии и в неё сделать cherry-pick хотфикса. AN> .>Изменения брать можно в любой момент времени — с твоими исправлениями оно пересечётся только при мерже, который не обязателен. AN> Это совсем не понятно куда денутся мои изменения?
В локальной ветке останутся, продолжишь работу в понедельник.
Хотя полезно ветку куда-нибудь на другой сервер запушить, чисто ради бекапа, если за выходные твой комп сломается или потеряется.
Отличная статья, спасибо! Наконец-то осилил переход на Git. Кстати, совсем немного времени заняло...
У меня остался вопрос по кодировке. В проекте оказался файлик, названный по-русски (из документации). По-умолчанию в Git установилась кодировка UTF-8. С этой кодировкой он отказывается работать с файлом в Windows 7 (видит файл так: ��������.txt), при установке Unicode отказывается работать со всеми файлами, Windows 1251 — работает нормально. Переименовать проблемный файл — не проблема, однако, хотелось бы разобраться с кодировками. По идее, если проект не кросс-платформенный, то можно оставить Win1251, однако интересно почему UTF-8 и UNICODE не работают?
Здравствуйте, М.Р., Вы писали:
МР>Отличная статья, спасибо! Наконец-то осилил переход на Git. Кстати, совсем немного времени заняло...
МР>У меня остался вопрос по кодировке. В проекте оказался файлик, названный по-русски (из документации). По-умолчанию в Git установилась кодировка UTF-8. С этой кодировкой он отказывается работать с файлом в Windows 7 (видит файл так: ��������.txt), при установке Unicode отказывается работать со всеми файлами, Windows 1251 — работает нормально. Переименовать проблемный файл — не проблема, однако, хотелось бы разобраться с кодировками. По идее, если проект не кросс-платформенный, то можно оставить Win1251, однако интересно почему UTF-8 и UNICODE не работают?
С кодировками имён файлов в git’е Всё Плохо. То есть всё хорошо под *nix’ами, а под Windows плохо. Это потому, что по юниксовой идеологии имена файлов священны и транскодировать их никак нельзя — пришла по протоколу байтовая строка, изволь передать её в функции работы с файлами как есть. А в Windows эти функции как раз работают в 866 или 1251.
Какие-то работы по этой проблеме ведутся, но не факт, что скоро будет готово. А пока стоит принять правило, что имена файлов должны вписываться в us-ascii. И путь к локальному репозиторию, кстати, тоже.
Здравствуйте, Centaur, Вы писали:
МР>>У меня остался вопрос по кодировке. В проекте оказался файлик, названный по-русски (из документации). По-умолчанию в Git установилась кодировка UTF-8. С этой кодировкой он отказывается работать с файлом в Windows 7 (видит файл так: ��������.txt)
C>С кодировками имён файлов в git’е Всё Плохо. То есть всё хорошо под *nix’ами, а под Windows плохо.
не знаю как под win7, а под win2003 я специально создавал msysgit-ом с нуля репозиторий с русскими именами файлов, менял их и т.д. — никаких проблем ни с файлами на диске, ни с историей. Проблема с нелатинскими именами есть при импорте хранилища из svn, это как оказалось уж сто лет как зарегистрированная бага msysgit
За курс молодого бойца — спасибо. Но почему вы считаете, что создание веток в Subversion — гемор? Очень даже удобная фича. Никто в твои изменения не лезет, а ты можешь постепенно ваять новую функцию хоть два дня, хоть неделю, хоть месяц. И как раз не нужно на локальном компе держать. К примеру, я сейчас в SVN каждый день прыгаю, как минимум, по 2 веткам в своем репозитарии еще иногда еще по одной в чужом. И еще по 1-2 своим собственным, отведенным на вялотекущие задачи сроком от нескольких дней до неопределенного.
Я и сам периодически страдаю от того, что в моей прежней команде — с которой до сих пор сотрудничаем — 10 человек всё по мере работы выкладывают — в работающем или неработающем виде — в транк, превращая этот самый транк в помойку и затрудняя слитие (когда переданные им же изменения приходят тебе обратно, да еще и в искаженном виде вперемежку с их собственными изменениями). Да, и можно неделю держать код на своем компе и не коммитить, а потом говорить, как это круто — stash в git. А можно опять же ветки использовать. Но вы ведь не будете спорить, что возможности git можно точно так же НЕ использовать, как возможности subversion, ссылаясь на сложность и гемморойность этого Ваше ощущение свободы при использовании git, как мне кажется, связано с тем, что вас вынудили сменить парадигму работы с репозитарием, и новая оказалась удобнее прежней, хотя следовать ей вы могли и раньше — по доброй воле
Из реальных недостатков ветвлений в SVN я по опыту интенсивной работы назвал бы такие: 1) в SVN нельзя завести временную ветку, похимичить в ней пару дней, а потом бесследно прибить, не выпуская из "локального репозитария", 2) выгрузка дампа репозитария с ветками несколько избыточная, 3) просматривая историю ветки, мы не видим историю коммитов внутри слитых в нее веток (а видимо только единственный коммит, которым коммитили саму операцию слития). То есть ветки там функциональны, но попросту менее удобны, чем в git. И во многом, кстати, это вина утилит, а не самой системы управления версиями: скажем, показать дерево веток вполне можно было бы и в TortoiseSVN, пусть даже за счет дополнительных запросов к серверу. Но вот не сделали же.
Спору нет, у git есть преимущества. Но и конкурентам предыдущего поколения не стоит придумывать новые недостатки сверх тех, которыми они и так страдают...
Slicer
Специалист — это варвар, невежество которого не всесторонне :)
Здравствуйте, Centaur, Вы писали:
C>С кодировками имён файлов в git’е Всё Плохо. То есть всё хорошо под *nix’ами, а под Windows плохо. Это потому, что по юниксовой идеологии имена файлов священны и транскодировать их никак нельзя — пришла по протоколу байтовая строка, изволь передать её в функции работы с файлами как есть. А в Windows эти функции как раз работают в 866 или 1251.
Значит, плохо не только в git. В svn у нас, например, умельцы создавали такие имена файлов, которые не удавалось без потерь протолкнуть через дамп репозитария =) Хотя обычные русские имена — проходят. Баги, куда ж без них.
Slicer
Специалист — это варвар, невежество которого не всесторонне :)
SM>Но почему вы считаете, что создание веток в Subversion — гемор? Очень даже удобная фича.
Фича удобная, никто и не спорит, но создание ветки в SVN все-таки гемор .
Здравствуйте, Dym On, Вы писали:
SM>>Но почему вы считаете, что создание веток в Subversion — гемор? Очень даже удобная фича. DO>Фича удобная, никто и не спорит, но создание ветки в SVN все-таки гемор .
Да ну бросьте же. Branch/Tag, ввели номер ревизии откуда гнуть, ввели название, поставили галочко внизу — и все. А как вам хотелось — чтоб за вас название придумали? =)
Slicer
Специалист — это варвар, невежество которого не всесторонне :)
Здравствуйте, Slicer [Mirkwood], Вы писали:
SM>За курс молодого бойца — спасибо. Но почему вы считаете, что создание веток в Subversion — гемор? Очень даже удобная фича. Никто в твои изменения не лезет, а ты можешь постепенно ваять новую функцию хоть два дня, хоть неделю, хоть месяц. И как раз не нужно на локальном компе держать. К примеру, я сейчас в SVN каждый день прыгаю, как минимум, по 2 веткам в своем репозитарии еще иногда еще по одной в чужом. И еще по 1-2 своим собственным, отведенным на вялотекущие задачи сроком от нескольких дней до неопределенного.
SM>Спору нет, у git есть преимущества. Но и конкурентам предыдущего поколения не стоит придумывать новые недостатки сверх тех, которыми они и так страдают...
У SVN наконец заработал мердж с ветками? Раньше, насколько помню, беспроблемно влить изменения из мастера в свою ветку можно было ровно один раз — потом SVN начинал считать, что это я все сам придумал и предлагал разрешать конфликты для каждого из уже влитых изменений.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Тот кто сидит в пруду, Вы писали:
ТКС>У SVN наконец заработал мердж с ветками? Раньше, насколько помню, беспроблемно влить изменения из мастера в свою ветку можно было ровно один раз — потом SVN начинал считать, что это я все сам придумал и предлагал разрешать конфликты для каждого из уже влитых изменений.
Ну как... если честно вливать одни и те же изменения по несколько раз, мержилка может и не распознать дублирование. С другой стороны — а для чего несколько раз мержить одно и то же? Сначала залили коммиты до M-ного, в другой раз — c M+1-го по N-ный... Я обычно прям в коммите и пишу — слил такую-то ветку до такой-то ревизии.
Ну и потом, с какой-то версии они — чтобы не высматривать по логам, докуда мы уже успели слить — ввели запоминание истории сливов, чтобы можно было и на глаз видеть, что уже слито, а что нет, и автоматически тоже пропускать уже слитое. Хранится история в проперте svn:mergeinfo у конкретного сливаемого элемента (напр., сливаем "папочку" trunk — ей и пишется).
Slicer
Специалист — это варвар, невежество которого не всесторонне :)
Здравствуйте, Slicer [Mirkwood], Вы писали:
ТКС>>У SVN наконец заработал мердж с ветками? Раньше, насколько помню, беспроблемно влить изменения из мастера в свою ветку можно было ровно один раз — потом SVN начинал считать, что это я все сам придумал и предлагал разрешать конфликты для каждого из уже влитых изменений. SM>Ну как... если честно вливать одни и те же изменения по несколько раз, мержилка может и не распознать дублирование. С другой стороны — а для чего несколько раз мержить одно и то же? Сначала залили коммиты до M-ного, в другой раз — c M+1-го по N-ный... Я обычно прям в коммите и пишу — слил такую-то ветку до такой-то ревизии. SM>Ну и потом, с какой-то версии они — чтобы не высматривать по логам, докуда мы уже успели слить — ввели запоминание истории сливов, чтобы можно было и на глаз видеть, что уже слито, а что нет, и автоматически тоже пропускать уже слитое. Хранится история в проперте svn:mergeinfo у конкретного сливаемого элемента (напр., сливаем "папочку" trunk — ей и пишется).
Ну вот в этом и отличие — в гите просто переключаешься в свою ветку и забираешь изменения из последнего мастера (trunk), или любой другой ветки, хоть каждый день. Не забивая голову ненужными подробностями, и никаких левых конфликтов при этом не возникает. Собственно, насколько я понимаю, именно об этом речь и идет, когда говорят о легкой работе с ветками.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
A>Я уже более десятка лет использую самые разные системы контроля версий, но за всё это время мною было создано веток меньше, чем при написании этой статьи.
A>А с этого места поподробней, пожалуйста
Что тут может быть подробнее? В svn бранчинг — это наказание и желательно его избегать. В git — развлечение. Такие вот побробности
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, alvas, Вы писали:
A>>
A>>Я уже более десятка лет использую самые разные системы контроля версий, но за всё это время мною было создано веток меньше, чем при написании этой статьи.
A>>А с этого места поподробней, пожалуйста
IT>Что тут может быть подробнее? В svn бранчинг — это наказание и желательно его избегать. В git — развлечение. Такие вот побробности
А я думал что ответ будет что-то типа: Когда я сел за написание этой статьи, то ... и давай расписывать как вы использовали git для написание этой статьи ...
Здравствуйте, Centaur, Вы писали:
C>... А пока стоит принять правило, что имена файлов должны вписываться в us-ascii. И путь к локальному репозиторию, кстати, тоже.
Да я обычно придерживаюсь этого правила, да тут невесть откуда завалялся файлик... А вообще, после переключения кодировки на windows-1251 проблема ушла. Я просто задумался — либо оставить кодировку, либо файлик переименовать...
A>Хм. В меркуриале за апачем можно давать права доступа на отдельные папки, не только на репозиторий целиком. Но с другой строны, сам меркуриал поддерживает аутентицикацию.
С git-ом идёт скрипт update-paranoid. Так вот он при наличии нормальной аутентификации позволяет задавать права вплоть до веток. Причём как за апачем, так и за ssh.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, ., Вы писали:
.>Да, афаик нельзя.
update-paranoid, gitosys, gitolite .>А можно привести пример полезного юскейса для этого? Раньше в svn таким пользовался, но там папки по сути были независимые проекты для разных команд, и делалось это лишь потому, что так удобнее администрировать, чем плодить кучу репозиториев.
Ну например, так делается запрещение на удаление tag-ов, в master могут сливать только интеграторы, в topic-ветки может писать только програмер/его менеджер и т.п. Т.е. для поддержания целостности.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, Roman Odaisky, Вы писали:
А>>Вы не поверите, но большинство людей ждут именно картинок с указаниями куда смотреть и что жать в какой момент, т.е. чтобы вообще всё было разжовано и показано без особых пробелов. RO>Так RSDN (я тешу себя надеждой) отнюдь не представляет собой средоточие таких людей.
С чего бы это?
Здравствуйте, Roman Odaisky, Вы писали:
А>>Вы не поверите, но большинство людей ждут именно картинок с указаниями куда смотреть и что жать в какой момент, т.е. чтобы вообще всё было разжовано и показано без особых пробелов. RO>Так RSDN (я тешу себя надеждой) отнюдь не представляет собой средоточие таких людей.
Мне тоже кажется, что нет ничего плохого в том, чтобы снизить порог вхождения в технологию пусть даже теми же картинками.
Если нам не помогут, то мы тоже никого не пощадим.
Re[4]: Git в картинках
От:
Аноним
Дата:
26.05.11 19:09
Оценка:
Здравствуйте, Slicer [Mirkwood], Вы писали:
SM>>>Но почему вы считаете, что создание веток в Subversion — гемор? Очень даже удобная фича. DO>>Фича удобная, никто и не спорит, но создание ветки в SVN все-таки гемор . SM>Да ну бросьте же. Branch/Tag, ввели номер ревизии откуда гнуть, ввели название, поставили галочко внизу — и все. А как вам хотелось — чтоб за вас название придумали? =)
Не всегда имеется возможность создать бранч самому, а здесь это "прошито" в дезайне.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Roman Odaisky, Вы писали:
А>>>Вы не поверите, но большинство людей ждут именно картинок с указаниями куда смотреть и что жать в какой момент, т.е. чтобы вообще всё было разжовано и показано без особых пробелов. RO>>Так RSDN (я тешу себя надеждой) отнюдь не представляет собой средоточие таких людей.
IT>Мне тоже кажется, что нет ничего плохого в том, чтобы снизить порог вхождения в технологию пусть даже теми же картинками.
Вообще, честь тебе и хвала в деле популяризации git-а. Ибо его считают каким-то шаманским сборником заклятий чОрной командной строки. А тут всё гламурненько. Помниться правда год назад GitExtention неилюзорно глючил, как, впрочем, и tortoriseHG . Базар в плане ГУИ хорошь из коробки и, кстати, может выступать просто удобным интерфейсом к svn-овскому репозиторию.
Романа я, правда, тоже понимаю ибо чОрной магии обучен хочется заклинаний левелом повыше.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, dr.Chaos, Вы писали:
DC>Романа я, правда, тоже понимаю ибо чОрной магии обучен хочется заклинаний левелом повыше.
Да я и сам бывает заклинаниями балуюсь. Но всё по дилетантски — с вопросом в гугль, команду git в слипборд, Git bash прямо из тулбара Git Extensions, paste, edit, enter. Но такое бывает надо не часто
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, ., Вы писали:
.>Здравствуйте, AlexNek, Вы писали:
AN>> .>Ты можешь воспользоваться git svn для начала, поиграться самому, есть несколько подводных камней (надо бы это мне как-то рассказать на досуге), но почувствовать вкус вполне можно. AN>> Но как я понял из описания — это просто синхронизатор двух репозиториев, да и еще с командной строкой .>Да. В общем-то в любой совместной работе в гите ты синхронизируешь два репозитория. Если используешь git svn, то просто второй репозиторий — svn. Правда так как он довольно примитивный, приходится шаманить слегка. .>Насчёт командной строки... там в общем-то всего 2 команды надо. По-мему в tortoisegit есть, но я ни разу не использовал.
AN>> Основными достоинствами git (в сравнении с другими распределёнными системами контроля версий) в настоящее время принято считать:
AN>> * Unix-ориентированность и глубокий unixway во всём;
.>Эээ... оно не сильно отлчиается от svn.
Они вроде и есть но как то еще ни разу не попадались
AN>> .>В Идее есть суперская интеграция, есть tortoisegit, есть gitk, git gui, gitextensions... но я почему-то использую коммандную строку в большинстве случаев. AN>> А что такое "Идея"? И что же лучше для студии исходя из того, что я ненавижу командные строки. .>Jetbrains IDEA. Хз... дело вкуса. Надо пробовать самому.
Java IDE. Не... такое вообще не пробуем.
AN>> AN>> Также не совсем понятно как Гиту удается минимизировать конфликты. AN>> .>Тем, что коммиты маленькие. AN>> Так размер коммита зависит от программиста. Если для правки ошибки нужно исправить Х строк, так эти Х будут всегда. .>Нет. Если используешь svn, то перед тем как коммитить — надо точно знать, что коммитишь и не поломается ли чего у других. .>При использовании git коммитишь когда завершаешь какую-то мысль. Т.е. например делаешь какую-то фичу. Чтобы её сделать — надо: что-то порефакторить, написать новый код, написать тест, добавить кнопки для новой фичи, поправить баги, дописать заглушки и т.п. Так вот коммитить можешь после каждого этапа.
Но получается только локально, а когда все закончил надо то в основную ветку забросить.
AN>> .>[делаем хотфикс обнаруженных багов] AN>> .>git commit AN>> .>git push
AN>>
AN>> вносим изменения в удаленный репозитарий (удаленную ветку)
AN>> А тут обломов не бывает? .>Если кто-то что-то до тебя закоммитил, то при наличии конфликтов ругнётся, конечно. Будешь должен смержить или оставить мерж на потом. .>Или что ты имеешь в виду под обломом?
Да конфиликты прежде всего. А если оставлю мерж на потом как же дальше работать?
Здравствуйте, AlexNek, Вы писали:
AN> Сколько нужно пока не знаю, но списки команд довольно приличные. AN> Кстати, решил сегодня попробовать git svn. Пока ничего отрицательного, но комп пришлось оставить включенным, оказывается в хеаде почти 79 тыс. файлов.
Да, есть такой момент... У меня один репозиторий с десятком тысяч ревизий и кучей бинарников (кто придумал скомпиленное коммитить?!) скачивался несколько дней...
AN> .>Эээ... оно не сильно отлчиается от svn. AN> Они вроде и есть но как то еще ни разу не попадались
? Не понял.
AN> .>Нет. Если используешь svn, то перед тем как коммитить — надо точно знать, что коммитишь и не поломается ли чего у других. AN> .>При использовании git коммитишь когда завершаешь какую-то мысль. Т.е. например делаешь какую-то фичу. Чтобы её сделать — надо: что-то порефакторить, написать новый код, написать тест, добавить кнопки для новой фичи, поправить баги, дописать заглушки и т.п. Так вот коммитить можешь после каждого этапа. AN> Но получается только локально, а когда все закончил надо то в основную ветку забросить.
Ну да, мержишь потом, сразу все коммиты. Притом история сохраняется (или не сохраняется, если решишь её поредактировать).
AN> Да конфиликты прежде всего. А если оставлю мерж на потом как же дальше работать?
В другой ветке. Ещё можно историю как-то поредактировать, чтобы количество конфликтов уменьшить.
Здравствуйте, ., Вы писали:
.>Здравствуйте, AlexNek, Вы писали:
.>(кто придумал скомпиленное коммитить?!)
Ээ.. у нас даже большая дискуссия была по этому поводу, прекратилась после первого неопознанного вылета
AN>> .>Эээ... оно не сильно отлчиается от svn. AN>> Они вроде и есть но как то еще ни разу не попадались .>? Не понял.
Ну команды для svn вроде есть, но как то в практике еще ни разу не попадались.
AN>> .>Нет. Если используешь svn, то перед тем как коммитить — надо точно знать, что коммитишь и не поломается ли чего у других. AN>> .>При использовании git коммитишь когда завершаешь какую-то мысль. Т.е. например делаешь какую-то фичу. Чтобы её сделать — надо: что-то порефакторить, написать новый код, написать тест, добавить кнопки для новой фичи, поправить баги, дописать заглушки и т.п. Так вот коммитить можешь после каждого этапа. AN>> Но получается только локально, а когда все закончил надо то в основную ветку забросить. .>Ну да, мержишь потом, сразу все коммиты. Притом история сохраняется (или не сохраняется, если решишь её поредактировать).
Ну так когда сразу все коммиты, это равносильно svn коммит, в чем "качество" конфликтов будет отличаться?
AN>> Да конфиликты прежде всего. А если оставлю мерж на потом как же дальше работать? .>В другой ветке. Ещё можно историю как-то поредактировать, чтобы количество конфликтов уменьшить.
Это как? Обнаружили конфликт, прерываем, берем все в новую ветку?
Кстати сегодня поигрался немного. Что выяснилось?
— Локальная копия взятая Гитом из svn и есть рабочий репозиторий гита.
— каталоги с пробелами или не ASCII символами гит не любит, хотя в Гит экстеншион показываются нормально.
— репозиторий гита весьма хорошо упакован
— обновления из svn ищутся быстрее черепахи.
— визуал Гит от Гит экстеншион не захотел грузится в мою 2008 студию
— ни в проводнике ни в Гит экстеншион нифига не видно состояний файла/папки (под контролем/модифицирован/не изменен)
— без коммандной строки нмфига не сделать. Добавил пару файлов в подконтрольный гиту каталог, еле нашел их в сташе. при попытке добавить в репозиторий получаю ошибку
C:\msysgit\cmd\git.cmd stash apply Current working dir changes
fatal: ambiguous argument 'Current': unknown revision or path not in the working tree.
use '--' to separate paths from revisions
Done
После получаса брожения по менюшкам и поиску ответа в сети Current заменился на какую то странную комбинацию и что то вроде пошло, но файлы упрямо не появлялись в Гит экстеншион пока не сделал все по описанным командам. При этом с проводника вообще ничего не получалось хотя и есть команда добавить файлы.
Так что пока отрицательных состояний больше чем положительных, но бум продолжать.
Здравствуйте, adontz, Вы писали:
A>Ну у меня большие проекты Иногда надо дать права только на часть.
Это как? Ну, то есть, если это один проект, то получив часть репозитория программист даже не сможет собрать приложение, чтобы протестировать свои изменения.
Если это части, собираемые независимо, то наверное стоит подумать о разделении на подпроекты (submodules)
Здравствуйте, DemAS, Вы писали:
DAS>Здравствуйте, adontz, Вы писали:
A>>Ну у меня большие проекты Иногда надо дать права только на часть.
DAS> Это как? Ну, то есть, если это один проект, то получив часть репозитория программист даже не сможет собрать приложение, чтобы протестировать свои изменения. DAS> Если это части, собираемые независимо, то наверное стоит подумать о разделении на подпроекты (submodules)
Я даю права на запись на часть проекта. Права на чтение имеют все.
Здравствуйте, adontz, Вы писали:
A>Я даю права на запись на часть проекта. Права на чтение имеют все.
Если на запись, то может использовать технологию, которая используется на GitHub?
Разработчик делает fork проекта, коммитит в него, а потом делает pull request в твой репозиторий.
А ты уже просмотривая эти pull request'ы решаешь — принимать их или нет.
В общем то, я понимаю, что если ты обычно не просматриваешь все коммиты, то это может быть излишней нагрузкой на тебя.
Здравствуйте, adontz, Вы писали:
DAS>> Это как? Ну, то есть, если это один проект, то получив часть репозитория программист даже не сможет собрать приложение, чтобы протестировать свои изменения. DAS>> Если это части, собираемые независимо, то наверное стоит подумать о разделении на подпроекты (submodules) A>Я даю права на запись на часть проекта. Права на чтение имеют все.
В git делается с помощью commit hooks.
Здравствуйте, DemAS, Вы писали:
DAS>В общем то, я понимаю, что если ты обычно не просматриваешь все коммиты, то это может быть излишней нагрузкой на тебя.
У меня постмодерация, так что такая модель не подходит. В сущности всё достаточно просто. вот давай на примере. Есть трёхзвенка. Сервер, клиент, БД. Её пишут три программиста, каждый свою часть. Тот кто знает WPF, плавает в SQL. Тот кто знает SQL, не разбирается в WCF. Можно премодерировать изменения, но тогда нужен отдельный человек, который будет разбираться во всех трёх технологиях и с утра до вечера премодерировать. Этон е эффективно. Мне проще дать каждому права на запись только в его часть. Тогда в случае больших изменений, затрагивающих несколько слоёв они будут вынуждены общаться и согласовывать свои действия. Эффективность при этом существенно не падает.
Здравствуйте, AlexNek, Вы писали:
AN> Ээ.. у нас даже большая дискуссия была по этому поводу, прекратилась после первого неопознанного вылета
В Ява-мире есть maven repository. А у вас?
AN> Ну так когда сразу все коммиты, это равносильно svn коммит, в чем "качество" конфликтов будет отличаться?
Тем что у тебя не один огромный коммит, который делает всё, а много маленьких, легко обозримых.
AN> .>В другой ветке. Ещё можно историю как-то поредактировать, чтобы количество конфликтов уменьшить. AN> Это как? Обнаружили конфликт, прерываем, берем все в новую ветку?
Конфликт может возникнуть только при мерже. Берётся (в смысле fetch) всегда в отдельную ветку.
AN> — каталоги с пробелами или не ASCII символами гит не любит, хотя в Гит экстеншион показываются нормально.
Кодировка да, возможно проблемы с msys, может быть, но решаемо. А на счёт пробелов — что-то ты видимо не то делаешь, вроде всё ок.
AN> — обновления из svn ищутся быстрее черепахи.
А история, а мержи... всё быстрее.
AN> — визуал Гит от Гит экстеншион не захотел грузится в мою 2008 студию
Хвалёный .net.
AN> — ни в проводнике ни в Гит экстеншион нифига не видно состояний файла/папки (под контролем/модифицирован/не изменен)
А он разве должен отображать? Вроде tortoisegit такое делает, знаю.
AN> — без коммандной строки нмфига не сделать. Добавил пару файлов в подконтрольный гиту каталог, еле нашел их в сташе. при попытке добавить в репозиторий получаю ошибку AN>
AN> C:\msysgit\cmd\git.cmd stash apply Current working dir changes
AN> fatal: ambiguous argument 'Current': unknown revision or path not in the working tree.
AN> use '--' to separate paths from revisions
AN> Done
"C:\msysgit\cmd\git.cmd stash apply Current working dir changes" это коммандная строка такая? Ты разве знаешь что аргументы, содержащие пробелы, нужно заключать в кавычки?
Что-то я не понял что ты со stash делал такое... Ты случайно его со stage не попутал?
AN> После получаса брожения по менюшкам и поиску ответа в сети Current заменился на какую то странную комбинацию и что то вроде пошло, но файлы упрямо не появлялись в Гит экстеншион пока не сделал все по описанным командам. При этом с проводника вообще ничего не получалось хотя и есть команда добавить файлы.
AN> Так что пока отрицательных состояний больше чем положительных, но бум продолжать.
Learning curve у гита очень steep...
Здравствуйте, ., Вы писали:
.>Здравствуйте, AlexNek, Вы писали:
AN>> Ээ.. у нас даже большая дискуссия была по этому поводу, прекратилась после первого неопознанного вылета .>В Ява-мире есть maven repository. А у вас?
Если бы еще знал что это
Пока только это нашел Byldan
AN>> Ну так когда сразу все коммиты, это равносильно svn коммит, в чем "качество" конфликтов будет отличаться? .>Тем что у тебя не один огромный коммит, который делает всё, а много маленьких, легко обозримых.
То есть для начала меняется стратегия работы? Коммитим после каждого пука.
AN>> .>В другой ветке. Ещё можно историю как-то поредактировать, чтобы количество конфликтов уменьшить. AN>> Это как? Обнаружили конфликт, прерываем, берем все в новую ветку? .>Конфликт может возникнуть только при мерже. Берётся (в смысле fetch) всегда в отдельную ветку.
А потом ветка мержится с моей локальной копией?
AN>> — каталоги с пробелами или не ASCII символами гит не любит, хотя в Гит экстеншион показываются нормально. .>Кодировка да, возможно проблемы с msys, может быть, но решаемо. А на счёт пробелов — что-то ты видимо не то делаешь, вроде всё ок.
Ну да, когда "" автоматом ставишь
Но если решаемо через несколько лет, то как говорится, нам не по пути
AN>> — обновления из svn ищутся быстрее черепахи. .>А история, а мержи... всё быстрее.
Остального пока не видел, но поиск новых файлов точно медленней. (в SVN вроде и не нужен)
AN>> — визуал Гит от Гит экстеншион не захотел грузится в мою 2008 студию .>Хвалёный .net.
Скорее хваленный Гит экстеншион
AN>> — ни в проводнике ни в Гит экстеншион нифига не видно состояний файла/папки (под контролем/модифицирован/не изменен) .>А он разве должен отображать?
Про должен не знаю, но как без этого работать пока не знаю. .>Вроде tortoisegit такое делает, знаю.
Было такое подозрение. Прийдется еще ждать AnkhGit. AN>> — без коммандной строки нмфига не сделать. Добавил пару файлов в подконтрольный гиту каталог, еле нашел их в сташе. при попытке добавить в репозиторий получаю ошибку AN>>
AN>> C:\msysgit\cmd\git.cmd stash apply Current working dir changes
AN>> fatal: ambiguous argument 'Current': unknown revision or path not in the working tree.
AN>> use '--' to separate paths from revisions
AN>> Done
.>"C:\msysgit\cmd\git.cmd stash apply Current working dir changes" это коммандная строка такая? Ты разве знаешь что аргументы, содержащие пробелы, нужно заключать в кавычки?
Это не моя команда, это прога все делает.
.>Что-то я не понял что ты со stash делал такое... Ты случайно его со stage не попутал?
А фиг его знает там какая то желтая иконка и первые три буквы вроде "sta". Там диалог открывается, где видны новые файлы, вверху комбобох который дает "Current", внизу от комбо бокса список файлов с большими плюсиками и внизу три кнопки. Справа текстовые файлы показывает.
AN>> После получаса брожения по менюшкам и поиску ответа в сети Current заменился на какую то странную комбинацию и что то вроде пошло, но файлы упрямо не появлялись в Гит экстеншион пока не сделал все по описанным командам. При этом с проводника вообще ничего не получалось хотя и есть команда добавить файлы.
AN>> Так что пока отрицательных состояний больше чем положительных, но бум продолжать. .>Learning curve у гита очень steep...
Тогда я выучил git. Git — это такой нелогичный набор утилит командной строки, в котором ежедневные операции выполняются последовательностью из двух–четырех команд. Первую неделю я тыкался в каждый угол, как слепой щенок. Я рисовал себе схему четырех хранилищ (working copy, staging area, local repo, remote repo), и подписывал стрелочками, какая команда и с какими опциями переносит информацию откуда куда. К концу этого периода адаптации я нащупал те заветные комбинации, которые мне нужны были в повседневной работе, и обрел некоторую смелость в перетасовке набора команд с листочка, заставляя их выдавать более-менее то, что мне нужно. Силу интерактивного коммита из коммандной строки, или, допустим, какие делать запросы, чтобы понять текущее состояние, я не освоил до сих пор. Порадовало, что репозиторий можно вертеть как угодно, пересвязывать что угодно с чем угодно, правда, магия для этого нужна соответствующая.
Здравствуйте, AlexNek, Вы писали:
AN> Если бы еще знал что это AN> Пока только это нашел Byldan
Главная фича — репозиторий бинарных артефактов.
AN> То есть для начала меняется стратегия работы? Коммитим после каждого пука.
Типа того.
AN> А потом ветка мержится с моей локальной копией?
Да.
AN> Ну да, когда "" автоматом ставишь
Например, Far Manager автоматом ставит. bash тоже.
AN> Но если решаемо через несколько лет, то как говорится, нам не по пути
Нет, уже вроде решаемо. Правда никогда не приходилось решать, не знаю точно.
AN> Остального пока не видел, но поиск новых файлов точно медленней. (в SVN вроде и не нужен)
Что значит "поиск новых файлов"? git status показывает всё.
AN> Скорее хваленный Гит экстеншион
Хз, ни разу не пользовался. Я в мире java живу.
AN> .>А он разве должен отображать? AN> Про должен не знаю, но как без этого работать пока не знаю.
Это по идее должен делать софт, который ставит расширения в Проводнике. svn же тоже просто так ничего не показывает.
AN> Было такое подозрение. Прийдется еще ждать AnkhGit.
А чем tortoisegit не устраивает?
AN> Это не моя команда, это прога все делает.
Мда.. хз, непонятно.
AN> .>Что-то я не понял что ты со stash делал такое... Ты случайно его со stage не попутал?
AN> А фиг его знает там какая то желтая иконка и первые три буквы вроде "sta". Там диалог открывается, где видны новые файлы, вверху комбобох который дает "Current", внизу от комбо бокса список файлов с большими плюсиками и внизу три кнопки. Справа текстовые файлы показывает.
Брр... вот за это не люблю gui в данном случае — ничего без скриншотов непонятно.
AN>
AN> Тогда я выучил git. Git — это такой нелогичный набор утилит командной строки, в котором ежедневные операции выполняются последовательностью из двух–четырех команд. Первую неделю я тыкался в каждый угол, как слепой щенок. Я рисовал себе схему четырех хранилищ (working copy, staging area, local repo, remote repo), и подписывал стрелочками, какая команда и с какими опциями переносит информацию откуда куда. К концу этого периода адаптации я нащупал те заветные комбинации, которые мне нужны были в повседневной работе, и обрел некоторую смелость в перетасовке набора команд с листочка, заставляя их выдавать более-менее то, что мне нужно. Силу интерактивного коммита из коммандной строки, или, допустим, какие делать запросы, чтобы понять текущее состояние, я не освоил до сих пор. Порадовало, что репозиторий можно вертеть как угодно, пересвязывать что угодно с чем угодно, правда, магия для этого нужна соответствующая.
AN> Пугает
staging area — всё просто. Представь себе svn, диалог коммита. Ты там галочками отмечаешь что хочешь закоммитить. Так вот staging area это замена этому диалогу, с учётом того, что ты эти галочки можешь отмечать через командную строку (git add) и оно не теряется при закрытии/обновлении диалога. И ещё ты можешь отметить для коммита не весь файл целиком, а только некоторые ломтики (hunks).
Здравствуйте, ., Вы писали:
.>Здравствуйте, AlexNek, Вы писали:
AN>> Если бы еще знал что это AN>> Пока только это нашел Byldan .>Главная фича — репозиторий бинарных артефактов.
То есть не может быть бинарников "несовместимых" с исходниками?
AN>> А потом ветка мержится с моей локальной копией? .>Да.
Пожалуй пора искать алгоритм пользования гитом
AN>> Ну да, когда "" автоматом ставишь .>Например, Far Manager автоматом ставит. bash тоже.
Я в окно Баша даже ничего вставить из клипбоарда не могу, призодится все пути руками вводить
AN>> Но если решаемо через несколько лет, то как говорится, нам не по пути .>Нет, уже вроде решаемо. Правда никогда не приходилось решать, не знаю точно.
Ну если понравится поищу, а то SVN репозиторий никто не будет менять.
AN>> Остального пока не видел, но поиск новых файлов точно медленней. (в SVN вроде и не нужен) .>Что значит "поиск новых файлов"? git status показывает всё.
Как я теперь понял это окно stag-ей, после каждой операции оно перечитывается.
AN>> Скорее хваленный Гит экстеншион .>Хз, ни разу не пользовался. Я в мире java живу.
А я в НЕТе — прювет
AN>> .>А он разве должен отображать? AN>> Про должен не знаю, но как без этого работать пока не знаю. .>Это по идее должен делать софт, который ставит расширения в Проводнике. svn же тоже просто так ничего не показывает.
Ну так данный софт и хочется.
А что в яве разве не нужно знать что под контролем версий, а что еще нет
AN>> Было такое подозрение. Прийдется еще ждать AnkhGit. .>А чем tortoisegit не устраивает?
Он для студии не должен годится, по идее. (В смысле провайдера контроля версий)
AN>> Это не моя команда, это прога все делает. .>Мда.. хз, непонятно.
Я открываю окно stag-ей, там список файлов которые я добавил проводником, потом жму кнопу добавить в рабочую область (или что то подопбное) и потом приведенная ошибка и вылазит.
AN>> .>Что-то я не понял что ты со stash делал такое... Ты случайно его со stage не попутал?
AN>> А фиг его знает там какая то желтая иконка и первые три буквы вроде "sta". Там диалог открывается, где видны новые файлы, вверху комбобох который дает "Current", внизу от комбо бокса список файлов с большими плюсиками и внизу три кнопки. Справа текстовые файлы показывает. .>Брр... вот за это не люблю gui в данном случае — ничего без скриншотов непонятно.
Скрины можно сделать только на работе, но с работы я не хожу на форум. Придется обходным путем идти...
AN>>
AN>> Тогда я выучил git. Git — это такой нелогичный набор утилит командной строки, в котором ежедневные операции выполняются последовательностью из двух–четырех команд. Первую неделю я тыкался в каждый угол, как слепой щенок. Я рисовал себе схему четырех хранилищ (working copy, staging area, local repo, remote repo), и подписывал стрелочками, какая команда и с какими опциями переносит информацию откуда куда. К концу этого периода адаптации я нащупал те заветные комбинации, которые мне нужны были в повседневной работе, и обрел некоторую смелость в перетасовке набора команд с листочка, заставляя их выдавать более-менее то, что мне нужно. Силу интерактивного коммита из коммандной строки, или, допустим, какие делать запросы, чтобы понять текущее состояние, я не освоил до сих пор. Порадовало, что репозиторий можно вертеть как угодно, пересвязывать что угодно с чем угодно, правда, магия для этого нужна соответствующая.
AN>> Пугает .>staging area — всё просто. Представь себе svn, диалог коммита. Ты там галочками отмечаешь что хочешь закоммитить. Так вот staging area это замена этому диалогу, с учётом того, что ты эти галочки можешь отмечать через командную строку (git add) и оно не теряется при закрытии/обновлении диалога. И ещё ты можешь отметить для коммита не весь файл целиком, а только некоторые ломтики (hunks)
Тое это как бы виртуальный репозиторий которого просто не существует физически?
Здравствуйте, AlexNek, Вы писали:
AN>Здравствуйте, IT, Вы писали:
IT>>Здравствуйте, AlexNek, Вы писали:
IT>>>>У GitExtensions тоже есть. Вполне достаточная для работы с ним. AN>>>А картинки к интеграции есть? Что -то в статье не заметил.
Сорри, случайно отправил тестовое сообщение из черновиков.
Здравствуйте, AlexNek, Вы писали:
AN> .>Главная фича — репозиторий бинарных артефактов. AN> То есть не может быть бинарников "несовместимых" с исходниками?
Управление версиями. Типа сделал какой-то модуль, скомпилил, протестил, выложил в репозиторий под новой версией. Другие указывают в исходниках какую версию использовать и качают готовый бинарник.
AN> Пожалуй пора искать алгоритм пользования гитом
Да всё просто:
1. правим код
2. git status — смотрим что наменяли.
3. git add/rm — отмечаем что хотим закоммитить.
4. git commit
5. git push
Шаги 3+4 в простых случаях делаются проще: "git commit -a" — коммит всех изменений сразу.
AN> Я в окно Баша даже ничего вставить из клипбоарда не могу, призодится все пути руками вводить
Эээ.. вроде shift-ins работает. (или мышой — одновременно left+right click).
AN> Ну если понравится поищу, а то SVN репозиторий никто не будет менять.
Это тебе повезло, что только под виндой работаешь. А так бы ты ещё намучился с русскими именами везде.
AN> .>Что значит "поиск новых файлов"? git status показывает всё. AN> Как я теперь понял это окно stag-ей, после каждой операции оно перечитывается.
Непонятно. Десятки тысяч файлов перечитывается в пределах 2-3 секунд. И, кстати, быстрее чем svn окно коммита на том же проекте.
AN> .>Хз, ни разу не пользовался. Я в мире java живу. AN> А я в НЕТе — прювет
Ява — рулезъ, .НЕТ — мастдай!
AN> Ну так данный софт и хочется.
Так можешь и то, и то поставить.
AN> А что в яве разве не нужно знать что под контролем версий, а что еще нет
Проводником не пользуюсь.
AN> Я открываю окно stag-ей, там список файлов которые я добавил проводником, потом жму кнопу добавить в рабочую область (или что то подопбное) и потом приведенная ошибка и вылазит.
Оно ещё и по-русски? Вообще непонятно.
AN> AN>> .>Что-то я не понял что ты со stash делал такое... Ты случайно его со stage не попутал?
AN> .>staging area — всё просто. Представь себе svn, диалог коммита. Ты там галочками отмечаешь что хочешь закоммитить. Так вот staging area это замена этому диалогу, с учётом того, что ты эти галочки можешь отмечать через командную строку (git add) и оно не теряется при закрытии/обновлении диалога. И ещё ты можешь отметить для коммита не весь файл целиком, а только некоторые ломтики (hunks) AN> Тое это как бы виртуальный репозиторий которого просто не существует физически?
Нет, просто редактируемый список того что ты собираешься закоммитить.
Для GUI он обычно не нужен, там чекбоксами работаешь. Для коммандной строки — удобно. В svn чтобы закоммитить некоторые файлы ты должен писать огромную страшную команду:
svn commit path1/file1 path2/file2 path2/file3 ...
в git можно например так:
git add path1/file1
cd path2
git add file2 file3
...
git commit
(но не обязательно, можно и как в svn).
Здравствуйте, ., Вы писали:
AN>> Пожалуй пора искать алгоритм пользования гитом .>Да всё просто: .>1. правим код .>2. git status — смотрим что наменяли. .>3. git add/rm — отмечаем что хотим закоммитить. .>4. git commit .>5. git push
.>Шаги 3+4 в простых случаях делаются проще: "git commit -a" — коммит всех изменений сразу.
Назовите меня мышевозилой гуёвым, но я для 2…4 использую git gui. Удобно просматривать изменения и выбирать, в какой последовательности какие из них коммитить.
Push из него тоже можно сделать, но у меня в большинстве случаев «сверху» svn и вместо git push надо git svn dcommit, а для этого в git gui кнопочка не предусмотрена. Да и нефиг вообще-то: отправка своих коммитов в другой репозиторий — это должен быть осознанный и обдуманный шаг.
Здравствуйте, ., Вы писали:
.>Здравствуйте, AlexNek, Вы писали:
AN>> .>Главная фича — репозиторий бинарных артефактов. AN>> То есть не может быть бинарников "несовместимых" с исходниками? .>Управление версиями. Типа сделал какой-то модуль, скомпилил, протестил, выложил в репозиторий под новой версией.
в НЕТе это встроено производителем .>Другие указывают в исходниках какую версию использовать и качают готовый бинарник.
Это работает до тех пор пока кто то, что то не забудет сделать.
AN>> Пожалуй пора искать алгоритм пользования гитом .>Да всё просто: .>1. правим код .>2. git status — смотрим что наменяли. .>3. git add/rm — отмечаем что хотим закоммитить. .>4. git commit .>5. git push
А где же "взять изменения в ветку", "смержить с моими"?
.>Шаги 3+4 в простых случаях делаются проще: "git commit -a" — коммит всех изменений сразу.
AN>> Я в окно Баша даже ничего вставить из клипбоарда не могу, призодится все пути руками вводить .>Эээ.. вроде shift-ins работает. (или мышой — одновременно left+right click).
shift-ins вроде пробовал какую то фигню вставляет, а вот мышу не насиловал. А что мешает Ctl/V сделать?
AN>> .>Что значит "поиск новых файлов"? git status показывает всё. AN>> Как я теперь понял это окно stag-ей, после каждой операции оно перечитывается. .>Непонятно. Десятки тысяч файлов перечитывается в пределах 2-3 секунд. И, кстати, быстрее чем svn окно коммита на том же проекте.
До git status я еше не дошел, я только в GitExtension UI смотрел.
AN>> .>Хз, ни разу не пользовался. Я в мире java живу. AN>> А я в НЕТе — прювет .>Ява — рулезъ, .НЕТ — мастдай!
Я лучше промолчу
AN>> Ну так данный софт и хочется. .>Так можешь и то, и то поставить.
Да комп и так 10 минут грузится, спасибо McAfee
AN>> А что в яве разве не нужно знать что под контролем версий, а что еще нет .>Проводником не пользуюсь.
А... знаю... ls
AN>> Я открываю окно stag-ей, там список файлов которые я добавил проводником, потом жму кнопу добавить в рабочую область (или что то подопбное) и потом приведенная ошибка и вылазит. .>Оно ещё и по-русски? Вообще непонятно.
Не, по англицки, где то близко к "Add to working copy"
AN>> AN>> .>Что-то я не понял что ты со stash делал такое... Ты случайно его со stage не попутал?
AN>> .>staging area — всё просто. Представь себе svn, диалог коммита. Ты там галочками отмечаешь что хочешь закоммитить. Так вот staging area это замена этому диалогу, с учётом того, что ты эти галочки можешь отмечать через командную строку (git add) и оно не теряется при закрытии/обновлении диалога. И ещё ты можешь отметить для коммита не весь файл целиком, а только некоторые ломтики (hunks) AN>> Тое это как бы виртуальный репозиторий которого просто не существует физически? .>Нет, просто редактируемый список того что ты собираешься закоммитить. .>Для GUI он обычно не нужен, там чекбоксами работаешь.
где? В GitExtension не заметил пока.
.>Для коммандной строки — удобно. В svn чтобы закоммитить некоторые файлы ты должен писать огромную страшную команду: .>svn commit path1/file1 path2/file2 path2/file3 ...
Ни разу не видел . Черепаха это наш нижний уровень.
Здравствуйте, AlexNek, Вы писали:
AN> .>Управление версиями. Типа сделал какой-то модуль, скомпилил, протестил, выложил в репозиторий под новой версией. AN> в НЕТе это встроено производителем
И тоже само все эти шаги делает? Выкачивает все зависимости, все исходники/документацию?
AN> .>Другие указывают в исходниках какую версию использовать и качают готовый бинарник. AN> Это работает до тех пор пока кто то, что то не забудет сделать.
А репозиторий-то где?
AN> .>Да всё просто: AN> .>1. правим код AN> .>2. git status — смотрим что наменяли. AN> .>3. git add/rm — отмечаем что хотим закоммитить. AN> .>4. git commit AN> .>5. git push AN> А где же "взять изменения в ветку", "смержить с моими"?
Если push отказался работать (кто-то другой что-то успел наменять), то делаешь pull, правишь конфликты если есть, тестишь, делаешь push. В общем аналогично svn, только в svn когда делаешь update, он будет сливать твои незакоммиченные изменения с чужими. Если что-то не так пойдёт, вешайся... git же не позволяет сливать незакоммиченное, что гарантирует тебе возможность отката любых действий.
AN> shift-ins вроде пробовал какую то фигню вставляет, а вот мышу не насиловал. А что мешает Ctl/V сделать?
Да вроде работало... Не помню, у меня в убунте — работает. На работе винда — проверю на неделе.
А ctrl-<letter> это управляющая последовательнось в терминале.
Кстати, можно настроить оказывается.
AN> .>Ява — рулезъ, .НЕТ — мастдай! AN> Я лучше промолчу
Эх жаль... а можно было бы пофлеймить.
AN> Да комп и так 10 минут грузится, спасибо McAfee
Снеси. Я антивирусами не пользовался. А последнее время на убунте сижу..
AN> А... знаю... ls
Far manager.
А под убунтой, да.
AN> .>Оно ещё и по-русски? Вообще непонятно. AN> Не, по англицки, где то близко к "Add to working copy"
Слушай, ты вроде с tortoisesvn работаешь. Попробуй tortoisegit, он очень похож.
AN> .>Нет, просто редактируемый список того что ты собираешься закоммитить. AN> .>Для GUI он обычно не нужен, там чекбоксами работаешь. AN> где? В GitExtension не заметил пока.
Ээ.. не пользовался. В tortise — точно можно.
Здравствуйте, ., Вы писали:
.>Здравствуйте, AlexNek, Вы писали:
AN>> .>Управление версиями. Типа сделал какой-то модуль, скомпилил, протестил, выложил в репозиторий под новой версией. AN>> в НЕТе это встроено производителем .>И тоже само все эти шаги делает? Выкачивает все зависимости, все исходники/документацию?
Это было к этому "Другие указывают в исходниках какую версию использовать и качают готовый бинарник."
AN>> .>Другие указывают в исходниках какую версию использовать и качают готовый бинарник. AN>> Это работает до тех пор пока кто то, что то не забудет сделать. .>А репозиторий-то где?
В смысле? Нормальный SVN
AN>> .>Да всё просто: AN>> .>1. правим код AN>> .>2. git status — смотрим что наменяли. AN>> .>3. git add/rm — отмечаем что хотим закоммитить. AN>> .>4. git commit AN>> .>5. git push AN>> А где же "взять изменения в ветку", "смержить с моими"? .>Если push отказался работать (кто-то другой что-то успел наменять), .>то делаешь pull,
Так пулл это похоже взять изменения в рабочую копию, разговор ведь был про ветку. .>правишь конфликты если есть, тестишь, делаешь push. В общем аналогично svn, только в svn когда делаешь update, он будет сливать твои незакоммиченные изменения с чужими. Если что-то не так пойдёт, вешайся... git же не позволяет сливать незакоммиченное, что гарантирует тебе возможность отката любых действий.
AN>> shift-ins вроде пробовал какую то фигню вставляет, а вот мышу не насиловал. А что мешает Ctl/V сделать? .>Да вроде работало... Не помню, у меня в убунте — работает. На работе винда — проверю на неделе. .>А ctrl-<letter> это управляющая последовательнось в терминале.
.>Кстати, можно настроить оказывается.
Спасибки, попробую
AN>> .>Ява — рулезъ, .НЕТ — мастдай! AN>> Я лучше промолчу .>Эх жаль... а можно было бы пофлеймить.
Жалко эту ветку, надо в спецфоруме открывать. Да и результата то все равно никакого не будет.
AN>> Да комп и так 10 минут грузится, спасибо McAfee .>Снеси. Я антивирусами не пользовался. А последнее время на убунте сижу..
Низзя, прописан в сетевой загрузке (это на работе)
AN>> А... знаю... ls .>Far manager.
Он у меня тоже всегда с собой
AN>> .>Оно ещё и по-русски? Вообще непонятно. AN>> Не, по англицки, где то близко к "Add to working copy" .>Слушай, ты вроде с tortoisesvn работаешь. Попробуй tortoisegit, он очень похож.
Да, для проводника, а для студии?
Здравствуйте, AlexNek, Вы писали:
AN> Это было к этому "Другие указывают в исходниках какую версию использовать и качают готовый бинарник."
maven сам готовый бинарник качает.
AN> .>А репозиторий-то где? AN> В смысле? Нормальный SVN
Для бинарников?
AN> .>Если push отказался работать (кто-то другой что-то успел наменять), AN> .>то делаешь pull, AN> Так пулл это похоже взять изменения в рабочую копию, разговор ведь был про ветку.
Я видимо вопрос не понял.
pull == fetch + merge.
fetch == "взять изменения", притом всегда в отдельную ветку "origin/master". Потом "замержить" твой "master" с "origin/master". А рабочую копию можно только checkout или commit, притом только в локальный "master". Потом можно мержить твой "master" в "origin/master" с помощью push.
AN> .>правишь конфликты если есть, тестишь, делаешь push. В общем аналогично svn, только в svn когда делаешь update, он будет сливать твои незакоммиченные изменения с чужими. Если что-то не так пойдёт, вешайся... git же не позволяет сливать незакоммиченное, что гарантирует тебе возможность отката любых действий.
AN> .>Эх жаль... а можно было бы пофлеймить. AN> Жалко эту ветку, надо в спецфоруме открывать. Да и результата то все равно никакого не будет.
Да ладно, флеймить везде можно, пока модераторы не придут. А результат будет — сотни сообщений.
AN> .>Слушай, ты вроде с tortoisesvn работаешь. Попробуй tortoisegit, он очень похож. AN> Да, для проводника, а для студии?
А tortoisesvn разве в Студию встраивается?
Здравствуйте, ., Вы писали:
.>Здравствуйте, AlexNek, Вы писали:
AN>> Это было к этому "Другие указывают в исходниках какую версию использовать и качают готовый бинарник." .>maven сам готовый бинарник качает.
А где он его берет?
AN>> .>А репозиторий-то где? AN>> В смысле? Нормальный SVN .>Для бинарников?
Так люди и с фотошопом в нем работают.
А где-же их еще хранить?
AN>> .>Если push отказался работать (кто-то другой что-то успел наменять), AN>> .>то делаешь pull, AN>> Так пулл это похоже взять изменения в рабочую копию, разговор ведь был про ветку. .>Я видимо вопрос не понял. .>pull == fetch + merge. .>fetch == "взять изменения", притом всегда в отдельную ветку "origin/master". Потом "замержить" твой "master" с "origin/master". А рабочую копию можно только checkout или commit, притом только в локальный "master". Потом можно мержить твой "master" в "origin/master" с помощью push.
Я видимо этот ответ не понял
отдельную ветку "origin/master" — это разве не главная ветка?
Потом "замержить" твой "master" с "origin/master" — как?
AN>> .>Эх жаль... а можно было бы пофлеймить. AN>> Жалко эту ветку, надо в спецфоруме открывать. Да и результата то все равно никакого не будет. .>Да ладно, флеймить везде можно, пока модераторы не придут. А результат будет — сотни сообщений.
Да вроде ветка полезная, не хочется ее замусоривать. У меня уже скоро месяц пару сообщений ждут ответа, пока был в отпуске развил "большую полемику", а потом уже времени не стало. (перед авторами сообщений неудобно). Так что лучше не начинать.
AN>> .>Слушай, ты вроде с tortoisesvn работаешь. Попробуй tortoisegit, он очень похож. AN>> Да, для проводника, а для студии? .>А tortoisesvn разве в Студию встраивается?
Не а, для этого ankhSVN пользуется. Да тут пока бы просто так поиграться, а если понравиться можно и дальше искать.
Здравствуйте, AlexNek, Вы писали:
AN> .>maven сам готовый бинарник качает. AN> А где он его берет?
Из maven repository. Например, тут куча опен-сорсных библиотек. Можно создавать свои репозитории.
AN> .>Для бинарников? AN> Так люди и с фотошопом в нем работают. AN> А где-же их еще хранить?
Фотошоп ещё ладно, от безысходности, а вот всякие dll это жуть.
AN> .>Я видимо вопрос не понял. AN> .>pull == fetch + merge. AN> .>fetch == "взять изменения", притом всегда в отдельную ветку "origin/master". Потом "замержить" твой "master" с "origin/master". А рабочую копию можно только checkout или commit, притом только в локальный "master". Потом можно мержить твой "master" в "origin/master" с помощью push. AN> Я видимо этот ответ не понял AN> отдельную ветку "origin/master" — это разве не главная ветка?
Есть "master" — твоя личная главная ветка, а есть "origin/master" главная ветка репозитория с которого ты первый раз взял копию (потому и названо origin).
AN> .>Да ладно, флеймить везде можно, пока модераторы не придут. А результат будет — сотни сообщений. AN> Да вроде ветка полезная, не хочется ее замусоривать. У меня уже скоро месяц пару сообщений ждут ответа, пока был в отпуске развил "большую полемику", а потом уже времени не стало. (перед авторами сообщений неудобно). Так что лучше не начинать.
Истинно интересующиеся должны не брезговать ища инфу среди мусора. Это есть путь познания.
AN> .>А tortoisesvn разве в Студию встраивается? AN> Не а, для этого ankhSVN пользуется. Да тут пока бы просто так поиграться, а если понравиться можно и дальше искать.
Так ты значит и tortisesvn + ankhsvn юзаешь? Так используй tortoisegit+gitextensions.
Здравствуйте, ., Вы писали:
.>Здравствуйте, AlexNek, Вы писали:
AN>> .>maven сам готовый бинарник качает. AN>> А где он его берет? .>Из maven repository. Например, тут куча опен-сорсных библиотек. Можно создавать свои репозитории.
Это мне все равно не грозит, так что хоть до конца не понятно, замнем.
AN>> .>Для бинарников? AN>> Так люди и с фотошопом в нем работают. AN>> А где-же их еще хранить? .>Фотошоп ещё ладно, от безысходности, а вот всякие dll это жуть.
А куда кидать сторонние либы?
AN>> .>Я видимо вопрос не понял. AN>> .>pull == fetch + merge. AN>> .>fetch == "взять изменения", притом всегда в отдельную ветку "origin/master". Потом "замержить" твой "master" с "origin/master". А рабочую копию можно только checkout или commit, притом только в локальный "master". Потом можно мержить твой "master" в "origin/master" с помощью push. AN>> Я видимо этот ответ не понял AN>> отдельную ветку "origin/master" — это разве не главная ветка? .>Есть "master" — твоя личная главная ветка, а есть "origin/master" главная ветка репозитория с которого ты первый раз взял копию (потому и названо origin).
но если "origin/master" главная ветка репозитория с которого ты первый раз взял копию как в нее можно брать изменения?
AN>> .>Да ладно, флеймить везде можно, пока модераторы не придут. А результат будет — сотни сообщений. AN>> Да вроде ветка полезная, не хочется ее замусоривать. У меня уже скоро месяц пару сообщений ждут ответа, пока был в отпуске развил "большую полемику", а потом уже времени не стало. (перед авторами сообщений неудобно). Так что лучше не начинать. .>Истинно интересующиеся должны не брезговать ища инфу среди мусора. Это есть путь познания.
Вообще то это путь спецслужб. Хотя как постигнем вселенную — поймем микрософт
AN>> .>А tortoisesvn разве в Студию встраивается? AN>> Не а, для этого ankhSVN пользуется. Да тут пока бы просто так поиграться, а если понравиться можно и дальше искать. .>Так ты значит и tortisesvn + ankhsvn юзаешь? Так используй tortoisegit+gitextensions.
так я почему и говорю, что gitextensions не хочет в студии работать.
Здравствуйте, AlexNek, Вы писали:
AN> А куда кидать сторонние либы?
В яве всё просто. Пишем в файле проекта dependency hibernate:3.5.2 и оно само вытягивает из инета либы, исходники, документацию. Притом со всеми зависимостями.
AN> .>Есть "master" — твоя личная главная ветка, а есть "origin/master" главная ветка репозитория с которого ты первый раз взял копию (потому и названо origin). AN> но если "origin/master" главная ветка репозитория с которого ты первый раз взял копию как в нее можно брать изменения?
git fetch
AN> .>Истинно интересующиеся должны не брезговать ища инфу среди мусора. Это есть путь познания. AN> Вообще то это путь спецслужб. Хотя как постигнем вселенную — поймем микрософт
AN> .>Так ты значит и tortisesvn + ankhsvn юзаешь? Так используй tortoisegit+gitextensions. AN> так я почему и говорю, что gitextensions не хочет в студии работать.
Хз в общем. В смысле нет плугинов к Студии вообще?
Я в Студии работал последний раз года 3 назад... и тогда юзал tortoisesvn.
Здравствуйте, ., Вы писали:
.>Здравствуйте, AlexNek, Вы писали:
AN>> А куда кидать сторонние либы? .>В яве всё просто. Пишем в файле проекта dependency hibernate:3.5.2 и оно само вытягивает из инета либы, исходники, документацию. Притом со всеми зависимостями.
А если либа купленная и стянуть нечего?
AN>> .>Есть "master" — твоя личная главная ветка, а есть "origin/master" главная ветка репозитория с которого ты первый раз взял копию (потому и названо origin). AN>> но если "origin/master" главная ветка репозитория с которого ты первый раз взял копию как в нее можно брать изменения? .>git fetch
Вообще то интересовала не коамнда а принцип. Если я откуда-то взял копию, то как это может быть моей личной веткой.
Да и как нашел "git fetch — забрать изменения удаленной ветки из репозитария", то есть это просто аналог чекаут
AN>> .>Так ты значит и tortisesvn + ankhsvn юзаешь? Так используй tortoisegit+gitextensions. AN>> так я почему и говорю, что gitextensions не хочет в студии работать. .>Хз в общем. В смысле нет плугинов к Студии вообще? .>Я в Студии работал последний раз года 3 назад... и тогда юзал tortoisesvn.
В студии никак ее нельзя юзать, по крайней мере мне это неизвестно.
Кстати, относительно диалога, это был все же Stash
И вот так получается ошибка.
А Гит черепах ведет себя весьма нагло, что подразумевает полный отказ от дальнеших экспериментов.
Скопировал новый файл в мой рабочий каталог, сказал Гиту коммит через GitExtension, все отработало нормально, файл на месте.
Делаем синхронизацию с SVN через черепаху Гита. Она показывает мне добавленный файл, я ей говорю игнорируй его (то бишь, нехрен в SVN писать). Что делает эта скотина? Она берет и нагло удаляет файл с диска. Ладно я его просто скопировал для теста, а если бы в поту пару ней набирал.
Здравствуйте, AlexNek, Вы писали:
AN> А если либа купленная и стянуть нечего?
Будет без исходников...
AN> AN>> но если "origin/master" главная ветка репозитория с которого ты первый раз взял копию как в нее можно брать изменения? AN> .>git fetch AN> Вообще то интересовала не коамнда а принцип. Если я откуда-то взял копию, то как это может быть моей личной веткой.
Она "твоя" в том смысле, что ты именно в неё вносишь изменения. Т.е. после clone у тебя есть 2 ветки — master и origin/master, которые указывают на один и тот же коммит. Когда ты что-то редактируешь, коммитишь в master. Когда ты делаешь fetch — изменения появляются в origin/master. Т.е. ветки расходятся. Потом ты можешь их мержить, совмещая ветки обратно.
AN> .>Хз в общем. В смысле нет плугинов к Студии вообще? AN> .>Я в Студии работал последний раз года 3 назад... и тогда юзал tortoisesvn. AN> В студии никак ее нельзя юзать, по крайней мере мне это неизвестно.
Да и не надо. В Студии редактируешь, потом в Проводнике коммитишь/апдейтишь.
AN> Кстати, относительно диалога, это был все же Stash AN> И вот так получается ошибка.
Да диалог пустой же. Смысла в нём нет. По идее кнопки должны не нажиматься.
AN> А Гит черепах ведет себя весьма нагло, что подразумевает полный отказ от дальнеших экспериментов.
AN> Скопировал новый файл в мой рабочий каталог, сказал Гиту коммит через GitExtension, все отработало нормально, файл на месте. AN> Делаем синхронизацию с SVN через черепаху Гита. Она показывает мне добавленный файл, я ей говорю игнорируй его (то бишь, нехрен в SVN писать). Что делает эта скотина? Она берет и нагло удаляет файл с диска. Ладно я его просто скопировал для теста, а если бы в поту пару ней набирал.
Честно говоря, слабо понял.. Как он после коммита решил опять что-то добавить — мне непонятно.
что-то на это тоже хотел ответить, но куда-то потерял.
AN> Да и как нашел "git fetch — забрать изменения удаленной ветки из репозитария", то есть это просто аналог чекаут
Нет, совсем нет. checkout забирает данные из локального в рабочую копию. fetch — забирает данные из удалённого репозитория в локальный.
Здравствуйте, ., Вы писали:
.>Здравствуйте, AlexNek, Вы писали:
AN>> А если либа купленная и стянуть нечего? .>Будет без исходников...
Исходники тоже куплены, только откуда тянуть?
AN>> AN>> но если "origin/master" главная ветка репозитория с которого ты первый раз взял копию как в нее можно брать изменения? AN>> .>git fetch AN>> Вообще то интересовала не коамнда а принцип. Если я откуда-то взял копию, то как это может быть моей личной веткой. .>Она "твоя" в том смысле, что ты именно в неё вносишь изменения. Т.е. после clone у тебя есть 2 ветки — master и origin/master, которые указывают на один и тот же коммит. Когда ты что-то редактируешь, коммитишь в master. Когда ты делаешь fetch — изменения появляются в origin/master. Т.е. ветки расходятся. Потом ты можешь их мержить, совмещая ветки обратно.
То есть на самом деле 3 места.
— центральный репозиторий
— оригинальный мастер
— личный мастер
AN>> .>Хз в общем. В смысле нет плугинов к Студии вообще? AN>> .>Я в Студии работал последний раз года 3 назад... и тогда юзал tortoisesvn. AN>> В студии никак ее нельзя юзать, по крайней мере мне это неизвестно. .>Да и не надо. В Студии редактируешь, потом в Проводнике коммитишь/апдейтишь.
А откуда знать что именно нужно коммитить/добавлять? А так все что в солушине автоматом коммитится. А если валом проектов?
AN>> Кстати, относительно диалога, это был все же Stash AN>> И вот так получается ошибка. .>Да диалог пустой же. Смысла в нём нет. По идее кнопки должны не нажиматься.
Тоже самое происходит и с не пустым. Кнопки нажимаются в любом случае.
AN>> А Гит черепах ведет себя весьма нагло, что подразумевает полный отказ от дальнеших экспериментов.
AN>> Скопировал новый файл в мой рабочий каталог, сказал Гиту коммит через GitExtension, все отработало нормально, файл на месте. AN>> Делаем синхронизацию с SVN через черепаху Гита. Она показывает мне добавленный файл, я ей говорю игнорируй его (то бишь, нехрен в SVN писать). Что делает эта скотина? Она берет и нагло удаляет файл с диска. Ладно я его просто скопировал для теста, а если бы в поту пару ней набирал. .>Честно говоря, слабо понял.. Как он после коммита решил опять что-то добавить — мне непонятно.
Стащил я SVN проект в каталог под гитом.
Добавляюю руками в каталог файл, делаю ему коммит в гите.
Затем синхронизируюсь с SVN, но прошу не передавать новый файл.
После этого файл бесследно исчезает.
Здравствуйте, ., Вы писали:
.>Здравствуйте, AlexNek, Вы писали:
.>что-то на это тоже хотел ответить, но куда-то потерял.
AN>> Да и как нашел "git fetch — забрать изменения удаленной ветки из репозитария", то есть это просто аналог чекаут .>Нет, совсем нет. checkout забирает данные из локального в рабочую копию. fetch — забирает данные из удалённого репозитория в локальный.
Я имел в виду SVN checkout. А сколько же в гите репозиториев?
В SVN я знаю только один.
Здравствуйте, AlexNek, Вы писали:
AN> .>Будет без исходников... AN> Исходники тоже куплены, только откуда тянуть?
Обычно делают так:
Один раз один из девелоперов берёт бинарники, доки, исходники, формирует так называемый "артефакт", кладёт (deploy) в в приватный maven repository, доступный только вашей компании.
Потом в проекте(ах) просто прописывается зависимость от этой либы и она сама будет подтягиваться всем остальным.
AN> .>Она "твоя" в том смысле, что ты именно в неё вносишь изменения. Т.е. после clone у тебя есть 2 ветки — master и origin/master, которые указывают на один и тот же коммит. Когда ты что-то редактируешь, коммитишь в master. Когда ты делаешь fetch — изменения появляются в origin/master. Т.е. ветки расходятся. Потом ты можешь их мержить, совмещая ветки обратно. AN> То есть на самом деле 3 места. AN> — центральный репозиторий AN> — оригинальный мастер AN> — личный мастер
Не совсем. Мастер — это ветка (метка на некий коммит). А репозиторий это свалка коммитов.
Репозиторий есть локальный (находится в каталоге .git). И есть удалённые (все остальные существующие в мире — в другом каталоге, на другом сервере, етс). И есть условное соглашение, что когда ты делаешь git clone <the url>, автоматически добавляется удалённый репозиторий, называемый "origin" == <the url>. Т.е. как такового "центрального репозитория" в принципе нет. Так что в лучшем случае он не центральный, а "изначальный".
AN> .>Да и не надо. В Студии редактируешь, потом в Проводнике коммитишь/апдейтишь. AN> А откуда знать что именно нужно коммитить/добавлять? А так все что в солушине автоматом коммитится. А если валом проектов?
Коммитишь весь каталок с солюшеном.
AN> .>Да диалог пустой же. Смысла в нём нет. По идее кнопки должны не нажиматься. AN> Тоже самое происходит и с не пустым. Кнопки нажимаются в любом случае.
Вообще накой тебе этот диалог? Чтобы делать "apply" нужно чтобы в stash что-то было. У тебя там пусто.
В сабжевой статье такой картинки вроде не было.
AN> Стащил я SVN проект в каталог под гитом. AN> Добавляюю руками в каталог файл, делаю ему коммит в гите. AN> Затем синхронизируюсь с SVN, но прошу не передавать новый файл. AN> После этого файл бесследно исчезает.
А как ты синхронизируешься? dcommit? или что?
Попробую угадать... Когда ты синхронизируешься ты говоришь чтобы git был приведён в соотвествие с svn. Если ты в svn файл отказался не положить, то и в git его не станет, т.к. git отображает состояние svn. Логично в общем-то.
AN> Я имел в виду SVN checkout. А сколько же в гите репозиториев? AN> В SVN я знаю только один
Много. На то оно и distributed.
Здравствуйте, ., Вы писали:
.>Здравствуйте, AlexNek, Вы писали:
AN>> .>Она "твоя" в том смысле, что ты именно в неё вносишь изменения. Т.е. после clone у тебя есть 2 ветки — master и origin/master, которые указывают на один и тот же коммит. Когда ты что-то редактируешь, коммитишь в master. Когда ты делаешь fetch — изменения появляются в origin/master. Т.е. ветки расходятся. Потом ты можешь их мержить, совмещая ветки обратно. AN>> То есть на самом деле 3 места. AN>> — центральный репозиторий AN>> — оригинальный мастер AN>> — личный мастер .>Не совсем. Мастер — это ветка (метка на некий коммит). А репозиторий это свалка коммитов. .>Репозиторий есть локальный (находится в каталоге .git). И есть удалённые (все остальные существующие в мире — в другом каталоге, на другом сервере, етс). И есть условное соглашение, что когда ты делаешь git clone <the url>, автоматически добавляется удалённый репозиторий, называемый "origin" == <the url>. Т.е. как такового "центрального репозитория" в принципе нет. Так что в лучшем случае он не центральный, а "изначальный".
А что можно сразу с несколькими удаленными работать.
Тогда получатся следующее:
— удаленный репозиторий
— локальный репозиторий (находится в каталоге .git)
— каталог в котором находится локальный репозиторий
AN>> .>Да и не надо. В Студии редактируешь, потом в Проводнике коммитишь/апдейтишь. AN>> А откуда знать что именно нужно коммитить/добавлять? А так все что в солушине автоматом коммитится. А если валом проектов? .>Коммитишь весь каталок с солюшеном.
Так я же говорю,валом различных проектов не все в одном каталоге, а солюшин вообще в каталоге приложения расположена, там наверное не более сотни строк.
AN>> .>Да диалог пустой же. Смысла в нём нет. По идее кнопки должны не нажиматься. AN>> Тоже самое происходит и с не пустым. Кнопки нажимаются в любом случае. .>Вообще накой тебе этот диалог? Чтобы делать "apply" нужно чтобы в stash что-то было. У тебя там пусто.
Просто на момент получения картинки ломало добавлять новые файлы.
ошибка все равно точно такая же. .>В сабжевой статье такой картинки вроде не было.
Я ее не рисовал
AN>> Стащил я SVN проект в каталог под гитом. AN>> Добавляюю руками в каталог файл, делаю ему коммит в гите. AN>> Затем синхронизируюсь с SVN, но прошу не передавать новый файл. AN>> После этого файл бесследно исчезает. .>А как ты синхронизируешься? dcommit? или что?
Rebase — больше ничего нет в меню.
.>Попробую угадать... Когда ты синхронизируешься ты говоришь чтобы git был приведён в соотвествие с svn. Если ты в svn файл отказался не положить, то и в git его не станет, т.к. git отображает состояние svn. Логично в общем-то.
Ладно, пусть себе делает, что хочет в своем локальном репозитории. Но без всяких следов удалять файлы из моей папки только из-за того что их нет в SVN SVN себе такого никогда не позволяет.
AN>> Я имел в виду SVN checkout. А сколько же в гите репозиториев? AN>> В SVN я знаю только один .>Много. На то оно и distributed.
И их сразу всехможно пользовать?
Очень интересная статья, то что нужно для ознакомления!
Я пробовал перевести, ради интереса, наш проект в Гит. Размер проекта около 300 мб.
Теперь когда я создал ветку с изменениями, то переключение между главной и созданной веткой занимает около 5-7 секунд.
Хотя реально изменен был только один файл.
Собственно вопрос. А можно как-то сделать ветку не от всего дерева, а поместить туда только какую-то поддиректорию?
Здравствуйте, Bear Hunter, Вы писали:
BH>Я пробовал перевести, ради интереса, наш проект в Гит. Размер проекта около 300 мб.
Это размер проекта или размер репозитория?
BH>Теперь когда я создал ветку с изменениями, то переключение между главной и созданной веткой занимает около 5-7 секунд. BH>Хотя реально изменен был только один файл.
Такое поведение наблюдается постоянно или только при первом переключении?
BH>Собственно вопрос. А можно как-то сделать ветку не от всего дерева, а поместить туда только какую-то поддиректорию?
Нельзя.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, AlexNek, Вы писали:
AN> — удаленный репозиторий AN> — локальный репозиторий (находится в каталоге .git)
да. AN> — каталог в котором находится локальный репозиторий
"Рабочая копия" называется.
AN> Так я же говорю,валом различных проектов не все в одном каталоге, а солюшин вообще в каталоге приложения расположена, там наверное не более сотни строк.
Непонятно... А как svn по разным каталогам коммитит? Это разные репозитории что-ли?
AN> .>Вообще накой тебе этот диалог? Чтобы делать "apply" нужно чтобы в stash что-то было. У тебя там пусто. AN> Просто на момент получения картинки ломало добавлять новые файлы. AN> ошибка все равно точно такая же.
Да я понял. Не понял с какой ты целью этим диалогом пользуешься.
AN> .>А как ты синхронизируешься? dcommit? или что? AN> Rebase — больше ничего нет в меню.
rebase выкачивает изменения из svn в git. В каком-то смысле аналог svn update.
AN> Ладно, пусть себе делает, что хочет в своем локальном репозитории. Но без всяких следов удалять файлы из моей папки только из-за того что их нет в SVN SVN себе такого никогда не позволяет.
Если ты ветки в svn переключаешь — может же файл исчезнуть. Так и тут.
AN> И их сразу всехможно пользовать?
Да. В этом и кайф.
Здравствуйте, IT, Вы писали:
IT>Это размер проекта или размер репозитория?
Проекта, репозиторий занимает около 60 мб.
IT>Такое поведение наблюдается постоянно или только при первом переключении?
Постоянно.
IT>Нельзя.
Здравствуйте, ., Вы писали:
AN>> Rebase — больше ничего нет в меню. .>rebase выкачивает изменения из svn в git. В каком-то смысле аналог svn update.
Это не совсем так. Если в локальном репозитории есть локальная ветка, не закоммиченная в svn, то git svn rebase сначала подтянет изменения из svn, а потом пересадит локальную ветку с точки ответвления на конец свежеподтянутого.
Здравствуйте, ., Вы писали:
.>Здравствуйте, AlexNek, Вы писали:
AN>> Так я же говорю,валом различных проектов не все в одном каталоге, а солюшин вообще в каталоге приложения расположена, там наверное не более сотни строк. .>Непонятно... А как svn по разным каталогам коммитит? Это разные репозитории что-ли?
Если работать только с root каталогом то можно хорошо выспаться за время обмена.
AN>> .>Вообще накой тебе этот диалог? Чтобы делать "apply" нужно чтобы в stash что-то было. У тебя там пусто. AN>> Просто на момент получения картинки ломало добавлять новые файлы. AN>> ошибка все равно точно такая же. .>Да я понял. Не понял с какой ты целью этим диалогом пользуешься.
Да я просто искал где мои новые файлы (которые я скопировать вручную в "Рабочая копия") и нашел их в этом диалоге.
AN>> .>А как ты синхронизируешься? dcommit? или что? AN>> Rebase — больше ничего нет в меню. .>rebase выкачивает изменения из svn в git. В каком-то смысле аналог svn update.
Пусть себе делает что хочет в локальном репозитории но нефиг лезть в "Рабочая копия", а если полез то хоть скажи где-то.
AN>> Ладно, пусть себе делает, что хочет в своем локальном репозитории. Но без всяких следов удалять файлы из моей папки только из-за того что их нет в SVN SVN себе такого никогда не позволяет. .>Если ты ветки в svn переключаешь — может же файл исчезнуть. Так и тут.
А что их можно переключать? не знал. У нас каждая ветка качается в свой отдельный каталог.
AN>> И их сразу всехможно пользовать? .>Да. В этом и кайф.
Икак же к ним можно одновременно обращаться, я пока заметил только один адрес репозитория для соединения.
Здравствуйте, AlexNek, Вы писали:
AN> .>Непонятно... А как svn по разным каталогам коммитит? Это разные репозитории что-ли? AN> Если работать только с root каталогом то можно хорошо выспаться за время обмена.
Вообще говоря, стоит попробовать как есть — git может работать быстрее на порядок.
AN> Да я просто искал где мои новые файлы (которые я скопировать вручную в "Рабочая копия") и нашел их в этом диалоге.
Да блин.. Вон же в статье
всё разжевывается, с картинками.
AN> .>rebase выкачивает изменения из svn в git. В каком-то смысле аналог svn update. AN> Пусть себе делает что хочет в локальном репозитории но нефиг лезть в "Рабочая копия", а если полез то хоть скажи где-то.
Пока удаление не деструктивное — пусть делает, можно откатиться.
AN> .>Если ты ветки в svn переключаешь — может же файл исчезнуть. Так и тут.
AN> А что их можно переключать? не знал. У нас каждая ветка качается в свой отдельный каталог. Счастливчик.
Конечно можно: svn switch
У меня рабочая копия с после компиляции, со всякими Debug/Release занимала около 5гб. Не особо с отдельными каталогами размахнёшься. А ещё окружение перенастраивать, со всякими IIS путями...
AN> Икак же к ним можно одновременно обращаться, я пока заметил только один адрес репозитория для соединения.
remotes прописывать. Или можно тупо писать git pull/push <repo url>
Здравствуйте, ., Вы писали:
.>Здравствуйте, AlexNek, Вы писали:
AN>> .>Непонятно... А как svn по разным каталогам коммитит? Это разные репозитории что-ли? AN>> Если работать только с root каталогом то можно хорошо выспаться за время обмена. .>Вообще говоря, стоит попробовать как есть — git может работать быстрее на порядок.
Все равно не удобно коммитить все, могу править документацию и проект, а коммитить хочу только проект.
AN>> .>rebase выкачивает изменения из svn в git. В каком-то смысле аналог svn update. AN>> Пусть себе делает что хочет в локальном репозитории но нефиг лезть в "Рабочая копия", а если полез то хоть скажи где-то. .>Пока удаление не деструктивное — пусть делает, можно откатиться.
В том и дело что деструктивное без всякой возможности отката
AN>> .>Если ты ветки в svn переключаешь — может же файл исчезнуть. Так и тут.
AN>> А что их можно переключать? не знал. У нас каждая ветка качается в свой отдельный каталог. .> Счастливчик. .>Конечно можно: svn switch .>У меня рабочая копия с после компиляции, со всякими Debug/Release занимала около 5гб. Не особо с отдельными каталогами размахнёшься. А ещё окружение перенастраивать, со всякими IIS путями...
Здравствуйте, AlexNek, Вы писали:
AN> .>Вообще говоря, стоит попробовать как есть — git может работать быстрее на порядок. AN> Все равно не удобно коммитить все, могу править документацию и проект, а коммитить хочу только проект.
Так не коммить, выбирай что хочешь в tsvn, gitexts. Хоть с точностью до части файла. Накой нужна Студия для этого — неясно, в ней это менее удобно будет всё равно.
AN> .>Пока удаление не деструктивное — пусть делает, можно откатиться. AN> В том и дело что деструктивное без всякой возможности отката
В общем я не понял что ты там такое делал, почему нет возможности отката — загадка.
AN> А сколько же тогда только исходники занимают?
Исходники не помню... там ещё месиво из разных файлов, html,js,c++,java было... Несколько десятков мб вроде.
Здравствуйте, ., Вы писали:
.>Здравствуйте, AlexNek, Вы писали:
AN>> .>Вообще говоря, стоит попробовать как есть — git может работать быстрее на порядок. AN>> Все равно не удобно коммитить все, могу править документацию и проект, а коммитить хочу только проект. .>Так не коммить, выбирай что хочешь в tsvn, gitexts. Хоть с точностью до части файла. Накой нужна Студия для этого — неясно, в ней это менее удобно будет всё равно.
Менее удобно еще куда то переключаться.
— я всегда вижу визульно какой файл модифицирован
— нажав commit на solution сразу видно все изменения только в файлах включенных в проект. Могу тут же глянуть отличия.
Если делать в проводнике нужно минимум еще туда перейти, при этом нужно переходить в корень всех проектов.
AN>> .>Пока удаление не деструктивное — пусть делает, можно откатиться. AN>> В том и дело что деструктивное без всякой возможности отката .>В общем я не понял что ты там такое делал, почему нет возможности отката — загадка.
Может просто не знаю где искать откат?
А делал вот что
Копирую через проводник файл в локальную папку под гитом.
Через git extension делаю ему коммит.
Через гит черепаху даю команду ребасе.
Появляется диалог, вверху виден мой файл.
Не помню уже точно как, может через контектное меню, может слева где кликнул, ставлю ему признак ignore.
Нажимаю кнопочку ОК
Файл бесследно исчезает.
AN>> А сколько же тогда только исходники занимают? .>Исходники не помню... там ещё месиво из разных файлов, html,js,c++,java было... Несколько десятков мб вроде.
А откуда берутся гигибайты?
Здравствуйте, AlexNek, Вы писали:
AN> Менее удобно еще куда то переключаться. AN> — я всегда вижу визульно какой файл модифицирован AN> — нажав commit на solution сразу видно все изменения только в файлах включенных в проект. Могу тут же глянуть отличия.
Т.е. "включённых в проект"? Те, которые не в проекте вообще в игноре должны быть.
AN> Если делать в проводнике нужно минимум еще туда перейти, при этом нужно переходить в корень всех проектов.
В git не надо вроде. Он коммитит рабочую копию целиком (как минимум из командной строки).
AN> Может просто не знаю где искать откат?
AN> А делал вот что
AN> Копирую через проводник файл в локальную папку под гитом. AN> Через git extension делаю ему коммит. AN> Через гит черепаху даю команду ребасе. AN> Появляется диалог, вверху виден мой файл. AN> Не помню уже точно как, может через контектное меню, может слева где кликнул, ставлю ему признак ignore. AN> Нажимаю кнопочку ОК AN> Файл бесследно исчезает.
В общем понял теперь. Короче, рассказываю. Ты делал rebase, т.е. перебазирование. Что это значит. У тебя есть история svn, c коммитами s1, s2, s3. Ты делаешь изменение в гите и коммитишь, получается коммит g1. История теперь такая: s1->s2->s3->g1. Допустим за это время кто-то другой что-то в svn закоммитил s4, получается теперь есть 2 истории: s1->s2->s3->s4 в svn и s1->s2->s3->g1. Тебе их надо слить. В случае git всё просто, а с svn надо сделать линейную историю. Т.е. должно получиться s1->s2->s3->s4->g1. Т.е. твой коммит g1 должен быть применён не к s3 а к s4. Когда ты делаешь git svn rebase он скачивает историю из svn и переносит твой коммит в её конец. При этом tgit предлагает эту историю тут же подредактировать (например, возможно s4 уже фиксит проблему которую ты пофиксил в g1 или там что-то пересекается). Ты же поставил признак "skip" (а не ignore как ты написал). Т.е. ты отказался применять твоё изменение g1. Логично, что файла в итоге не стало.
Да, кстати это не важно что не было никакого s4, перебазирование позволяет редактировать историю в любом случае, чтобы при отправке в удалённый репозиторий было всё красиво в истории.
Если тебе интересно, поразбирайся с git reflog, если хочешь понять как тебе вернуть твой файл.
AN> .>Исходники не помню... там ещё месиво из разных файлов, html,js,c++,java было... Несколько десятков мб вроде. AN> А откуда берутся гигибайты?
C++ он такой. Всякие obj, куча отладочных pdb, кодогенерация использовалась — своя и COM-импорты, в общем распухает оно резво.
Здравствуйте, ., Вы писали:
.>Здравствуйте, AlexNek, Вы писали:
AN>> Менее удобно еще куда то переключаться. AN>> — я всегда вижу визульно какой файл модифицирован AN>> — нажав commit на solution сразу видно все изменения только в файлах включенных в проект. Могу тут же глянуть отличия. .>Т.е. "включённых в проект"? Те, которые не в проекте вообще в игноре должны быть.
Для чего нужно делать лишнюю работу? Сделал допустим новую диаграмму, закинул в проект и она уже будет закоммичена, старую просто убрал с проекта и она больше не будет обновлятся, зато смогу эксперименты наней делать. Мне лично удобнее следить за одним чем то.
AN>> Если делать в проводнике нужно минимум еще туда перейти, при этом нужно переходить в корень всех проектов. .>В git не надо вроде. Он коммитит рабочую копию целиком (как минимум из командной строки).
Ну тогда к коммандную строку нужно хотя бы перейти, а как там отличия смотреть, вначале записать список изменений а после по нему идти?
AN>> А делал вот что
AN>> Копирую через проводник файл в локальную папку под гитом. AN>> Через git extension делаю ему коммит. AN>> Через гит черепаху даю команду ребасе. AN>> Появляется диалог, вверху виден мой файл. AN>> Не помню уже точно как, может через контектное меню, может слева где кликнул, ставлю ему признак ignore. AN>> Нажимаю кнопочку ОК AN>> Файл бесследно исчезает. .>В общем понял теперь. Короче, рассказываю. Ты делал rebase, т.е. перебазирование. Что это значит. У тебя есть история svn, c коммитами s1, s2, s3.
Я брал просто Head .>Ты делаешь изменение в гите и коммитишь, получается коммит g1. История теперь такая: s1->s2->s3->g1. Допустим за это время кто-то другой что-то в svn закоммитил s4, получается теперь есть 2 истории: s1->s2->s3->s4 в svn и s1->s2->s3->g1. Тебе их надо слить. В случае git всё просто, а с svn надо сделать линейную историю. Т.е. должно получиться s1->s2->s3->s4->g1. Т.е. твой коммит g1 должен быть применён не к s3 а к s4. Когда ты делаешь git svn rebase он скачивает историю из svn и переносит твой коммит в её конец. При этом tgit предлагает эту историю тут же подредактировать (например, возможно s4 уже фиксит проблему которую ты пофиксил в g1 или там что-то пересекается). Ты же поставил признак "skip" .>(а не ignore как ты написал).
Возможно, для меня, в данном случае это были синонимы. .>Т.е. ты отказался применять твоё изменение g1. Логично, что файла в итоге не стало.
А что нужно было тогда делать, если я хочу сохранить файл в гите но не хочу его тправлять в svn .>Да, кстати это не важно что не было никакого s4, перебазирование позволяет редактировать историю в любом случае, чтобы при отправке в удалённый репозиторий было всё красиво в истории.
.>Если тебе интересно, поразбирайся с git reflog, если хочешь понять как тебе вернуть твой файл.
спасибо гляну
Здравствуйте, Bear Hunter, Вы писали:
BH> Я пробовал перевести, ради интереса, наш проект в Гит. Размер проекта около 300 мб. BH> Теперь когда я создал ветку с изменениями, то переключение между главной и созданной веткой занимает около 5-7 секунд. BH> Хотя реально изменен был только один файл.
А сейчас под какой системой проект? Такого размера проект в том же svn по-моему будет на порядок дольше работать.
Здравствуйте, AlexNek, Вы писали:
AN> Для чего нужно делать лишнюю работу? Сделал допустим новую диаграмму, закинул в проект и она уже будет закоммичена, старую просто убрал с проекта и она больше не будет обновлятся, зато смогу эксперименты наней делать. Мне лично удобнее следить за одним чем то.
Хз, не очень представляю что ты там такое делаешь и за чем следишь.
AN> Ну тогда к коммандную строку нужно хотя бы перейти, а как там отличия смотреть, вначале записать список изменений а после по нему идти?
В статье с картинками вроде всё просто и без командной строки. Что куда записывать ты собираешься?
AN> .>В общем понял теперь. Короче, рассказываю. Ты делал rebase, т.е. перебазирование. Что это значит. У тебя есть история svn, c коммитами s1, s2, s3. AN> Я брал просто Head
Ты не понял что-ли? git выкачивает весь svn репозиторий, целиком.
AN> А что нужно было тогда делать, если я хочу сохранить файл в гите но не хочу его тправлять в svn
Попробуй сохранить файл в гите и не отправлять его в svn.
hint: rebase в svn ничего не отправляет.
Здравствуйте, ., Вы писали:
.>Здравствуйте, AlexNek, Вы писали:
AN>> Для чего нужно делать лишнюю работу? Сделал допустим новую диаграмму, закинул в проект и она уже будет закоммичена, старую просто убрал с проекта и она больше не будет обновлятся, зато смогу эксперименты наней делать. Мне лично удобнее следить за одним чем то. .>Хз, не очень представляю что ты там такое делаешь и за чем следишь.
Я могу менять файлы как в проекте так и вне его, но в корневом каталоге, например документацию. Да и со студии гораздо удобнее, без проблем могу файл, проект или солюшин закоммитить. (Конечно можно тожесамое и на уровен файловой системы сделать, но это все лишнии движения)
AN>> Ну тогда к коммандную строку нужно хотя бы перейти, а как там отличия смотреть, вначале записать список изменений а после по нему идти? .>В статье с картинками вроде всё просто и без командной строки. Что куда записывать ты собираешься?
Там не в студии.
AN>> .>В общем понял теперь. Короче, рассказываю. Ты делал rebase, т.е. перебазирование. Что это значит. У тебя есть история svn, c коммитами s1, s2, s3. AN>> Я брал просто Head .>Ты не понял что-ли? git выкачивает весь svn репозиторий, целиком.
Точно уверен? http://www.haypocalc.com/blog/index.php/2008/11/05/172-git-svn
Потверждено практикой, можно выкачать исключительно последнюю ревизию
AN>> А что нужно было тогда делать, если я хочу сохранить файл в гите но не хочу его тправлять в svn .>Попробуй сохранить файл в гите и не отправлять его в svn. .>hint: rebase в svn ничего не отправляет.
Может мы говорим о разных командах?
Здравствуйте, AlexNek, Вы писали:
AN> Я могу менять файлы как в проекте так и вне его, но в корневом каталоге, например документацию. Да и со студии гораздо удобнее, без проблем могу файл, проект или солюшин закоммитить. (Конечно можно тожесамое и на уровен файловой системы сделать, но это все лишнии движения)
Вот и не понятно. Как коммитить что-то из студии, если ты можешь менять что-то не в проекте/солюшне?
В общем непонятно что именно такого в Студии. Но наверное дело привычки/вкуса.
AN> .>В статье с картинками вроде всё просто и без командной строки. Что куда записывать ты собираешься? AN> Там не в студии.
И слава богу!
AN> .>Ты не понял что-ли? git выкачивает весь svn репозиторий, целиком.
AN> Точно уверен?
Если не делать лишних телодвижений, то да. git svn clone выкачивает всё. Естественно можно частями, но редко когда нужно.
AN> .>Попробуй сохранить файл в гите и не отправлять его в svn. AN> .>hint: rebase в svn ничего не отправляет.
AN> Может мы говорим о разных командах?
rtfm хоть что-ли. Отправить что-то в svn можно командой git svn dcommit, на картинке предыдущий пункт меню.
Здравствуйте, ., Вы писали:
.>Здравствуйте, AlexNek, Вы писали:
AN>> Я могу менять файлы как в проекте так и вне его, но в корневом каталоге, например документацию. Да и со студии гораздо удобнее, без проблем могу файл, проект или солюшин закоммитить. (Конечно можно тожесамое и на уровен файловой системы сделать, но это все лишнии движения) .>Вот и не понятно. Как коммитить что-то из студии, если ты можешь менять что-то не в проекте/солюшне?
В студии у меня все исходники и прочее что нужно для компиляции проекта. Вне проекта, но в каталоге есть еще различные документы которые не хочется коммитить вместе с исходниками.
.>В общем непонятно что именно такого в Студии. Но наверное дело привычки/вкуса.
нам намного удобнее делать все со студии.
AN>> Точно уверен? .>Если не делать лишних телодвижений, то да. git svn clone выкачивает всё. Естественно можно частями, но редко когда нужно.
А про клоне я не видел (git-svn fetch -rREVISION) А нафига мне весь репозиторий?
AN>> .>Попробуй сохранить файл в гите и не отправлять его в svn. AN>> .>hint: rebase в svn ничего не отправляет.
AN>> Может мы говорим о разных командах? .>rtfm хоть что-ли. Отправить что-то в svn можно командой git svn dcommit, на картинке предыдущий пункт меню.
Отчего то мне казалось, что это синхронизация
Я теперь просто ветку сделал с изменениями, а перед svn переключаюсь на мастер.
Здравствуйте, ., Вы писали:
.>А сейчас под какой системой проект? Такого размера проект в том же svn по-моему будет на порядок дольше работать.
Сейчас проект под Perforce. Но у нас немного подход не такой. Мы делаем отдельные ветки только для релизов.
Но после прочтения статьи Игоря и еще этой то очень понравилась идея ветвления проекта для каждого фикса/фичи отдельно. Очень удобно!
Вот и решил попробовать как оно будет выглядеть на большом проекте.
Здравствуйте, Bear Hunter, Вы писали:
BH> Сейчас проект под Perforce. Но у нас немного подход не такой. Мы делаем отдельные ветки только для релизов. BH> Но после прочтения статьи Игоря и еще этой то очень понравилась идея ветвления проекта для каждого фикса/фичи отдельно. Очень удобно! BH> Вот и решил попробовать как оно будет выглядеть на большом проекте.
Если я не ошибаюсь, то это преимущество p4 над git — оно умеет ворочить огромные репозитории, в том числе с бинарниками, ценой удобства работы.
Уже не первый раз встречаю мнение, что ветки в свн — это что-то очень сложное и неудобное.
Постоянно ими пользуюсь, активно создаю, сливаю, удаляю. Часто работаю параллельно над разными ветками.
Единственный минус — инфа о слияниях хранится не совсем удобно (точнее ее неудобно смотреть в тортиле). Однако я использовал ветки еще до появления в свн этой инфы и завел привычку при мердже писать что именно было слито.
В последнее время часто использую меркуриал. Каких-то мегапреимуществ именно для веток я в нем не увидел. Более того, свн — это что-то типа версионной файловой системы, там можно создать иерархическую организацию веток и тагов, чем активно пользуюсь на работе.
Здравствуйте, enji, Вы писали:
E>Уже не первый раз встречаю мнение, что ветки в свн — это что-то очень сложное и неудобное.
E>Постоянно ими пользуюсь, активно создаю, сливаю, удаляю. Часто работаю параллельно над разными ветками.
E>Единственный минус — инфа о слияниях хранится не совсем удобно (точнее ее неудобно смотреть в тортиле). Однако я использовал ветки еще до появления в свн этой инфы и завел привычку при мердже писать что именно было слито.
E>В последнее время часто использую меркуриал. Каких-то мегапреимуществ именно для веток я в нем не увидел. Более того, свн — это что-то типа версионной файловой системы, там можно создать иерархическую организацию веток и тагов, чем активно пользуюсь на работе.
Может личный процесс опишите более подробно?
Вот как у нас делают:
— создание ветки. Говорю админу он делает ветку. (Копия всего проекта)
— взятие ветки. Делаю checkout и "иду на прогулку"
— играемся с кодом.
— Часто после "игрушек" нужно не более 50% исправлений, которые нужно абсолютно все контроллировать. Поэтому нужные части кода просто переносятся вручную при необходимости в основную ветку.
Ветки делаются только тогда когда нужна какая то особая версия продукта или есть большой шанс все "поломать"
Здравствуйте, AlexNek, Вы писали:
AN>Может личный процесс опишите более подробно? AN>Вот как у нас делают: AN>- создание ветки. Говорю админу он делает ветку. (Копия всего проекта)
у нас админ не занимается свн. Настраивал его в свое время лично я. Потратил наверное часа 2. Особых проблем не припомню. С тех пор просто добавляю новых пользователей по мере надобности.
У программеров есть права на запись в brunches. Программеров человека 4, все люди вменяемые и саботажем никто не занимается — поэтому права особо не ограничиваются.
Когда мне нужна ветка — просто ее создаю. В свн копирование "легкое", создание ветки в репозитории — практически мгновенно. Мои личные ветки живут в brunches/fio. С личными ветками других не пересекаются. AN>- взятие ветки. Делаю checkout и "иду на прогулку"
У меня чекаут- минут 10. Часто можно сделать не чекаут, а переключение имеющей раб копии. У меня их в работе штук 5. Обычно просто переключаю, это пара минут. Работаю на С++, разные раб копии используют общий кэш объектников. Сборка довольно быстрая. Билд-скрипт сделан так, чтобы не зависеть от местоположения раб копии. AN>- играемся с кодом.
При "играх" делаю частые коммиты в ветку, стараюсь чтобы 1 коммит = 1 логическое изменение. Если возникает необходимость попробовать неск альтернатив — создаю новые ветки. При необходимости мержу их друг с другом. Но необходимость в ветках от ветки бывает не сильно часто. AN>- Часто после "игрушек" нужно не более 50% исправлений, которые нужно абсолютно все контроллировать. Поэтому нужные части кода просто переносятся вручную при необходимости в основную ветку.
Так как 1 коммит = 1 изменение, можно выбрать нужные коммиты. Мерж автоматический. После мержа просматриваю изменения в файлах. Если мерж значительный — компилирую, прогоняю тесты, иногда проверяю работу. AN>Ветки делаются только тогда когда нужна какая то особая версия продукта или есть большой шанс все "поломать"
Ветки делаются практически на каждый чих — на каждую версию продукта, на каждое нововведение. Иногда если нововведение заведомо маленькое, ветку не делаем, коммитим в транк.
После мерже в сообщении коммита пишу, какая ветка и какие ревизии были влиты. Содержимое комментария формализовано и может быть разобрано программно — собственно так и строится плоский журнал изменений.
Пользуясь фильтром по комментарию в тортилле можно легко понять что с чем было слито. Иногда смотрю граф ревизий, но редко
Я только начал работать с git и хотел бы получить подробную пошаговую инструкцию (в картинках), как настраивать сервер. Сервер, где предполагается хранить репозиторий, находится в защищенной сети за маршрутизатором и файрволом. Клиентские компьютеры частично находятся в этой же сети, частично за ее пределами. Администратор сети может открыть доступ компьютерам с определенными IP-адресами, но он требует название протокола и номер порта, по которому будет выполняться взаимодействие с сервером. Сервер работает на машине под управлением Windows 7, клиенты используют GitExtension с PuTTY (интеграция с Visual Studio). Что нужно сделать для настройки маршрутизатора (и файрвола) сети и настройки сервера. Очень хотелось бы получить максимально подробную инструкцию или ссылку на нее, если таковая уже имеется.
Здравствуйте, rsdn_gurin, Вы писали:
_>Администратор сети может открыть доступ компьютерам с определенными IP-адресами, но он требует название протокола и номер порта, по которому будет выполняться взаимодействие с сервером.
$ grep ^git /etc/services
git 9418/tcp # git pack transfer service
git 9418/udp # git pack transfer service
Либо ssh, тогда стандартный порт 22. Либо любой, специально назначенный для. Например, 2222.
Здравствуйте, enji, Вы писали:
AN>>- взятие ветки. Делаю checkout и "иду на прогулку" E>У меня чекаут- минут 10. Часто можно сделать не чекаут, а переключение имеющей раб копии. У меня их в работе штук 5. Обычно просто переключаю, это пара минут. Работаю на С++, разные раб копии используют общий кэш объектников.
Вот тут проблема. В git создание (или переключение) ветки это секунд 5-10 независимо от размера репозитория. Если бы это занимало пару минут, то ветки были бы малополезны. А так на любой чих (баг, фичу, эксперимент) создаётся короткоживущая ветка, которая видна только мне, и не мешает остальным.
Re: про лицензию
От:
Аноним
Дата:
28.07.11 13:02
Оценка:
Здравствуйте, Игорь Ткачев, Вы писали:
ИТ>Статья: ИТ>Git в картинках
ИТ>Авторы: ИТ> Игорь Ткачев
ИТ>Аннотация: ИТ>Краткое введение в Git и Git Extensions.
а про лицензию вопрос есть.
GIT идет под GNU лицензией.
Что это обязывает?
Т.е. разработанный мною продукт, для которого я использовал в качестве GIT должен быть под GNU лицензией => open source?
Здравствуйте, <Аноним>, Вы писали:
А>а про лицензию вопрос есть. А>GIT идет под GNU лицензией. А>Что это обязывает? А>Т.е. разработанный мною продукт, для которого я использовал в качестве GIT должен быть под GNU лицензией => open source?
Если ваш продукт является производным от Git (ну например линкуется с ним каким-то образом) — то продукт должен быть выпущен под GPL. Но врядли это ваш случай.
Спасибо большое за статью.
Жаль что только сейчас увидел.
Хотелось бы в нее добавить 2 вещи.
1) ссылку на http://hginit.com/ (Ну ведь много сравнений с Hg)
2) описание недостатков Git
для нас основным был — невозможно ограничить доступ к части репозитория (например к коду защиты)
P_Y>1) ссылку на http://hginit.com/ (Ну ведь много сравнений с Hg)
Это действительно стоит почитать! Написано кратко, доходчиво, и с юмором. Рассказано не только что система делает, но и зачем это все надо. К сожалению такое очень редко сейчас можно увидеть. Обычно или толмуд на тему "Введение в CM", где на 90% вода вокруг да около или тупое подробное описание всех команд.
Re[3]: про лицензию
От:
Аноним
Дата:
28.07.11 17:34
Оценка:
Здравствуйте, Peregrin, Вы писали:
P>Здравствуйте, <Аноним>, Вы писали:
А>>а про лицензию вопрос есть. А>>GIT идет под GNU лицензией. А>>Что это обязывает? А>>Т.е. разработанный мною продукт, для которого я использовал в качестве GIT должен быть под GNU лицензией => open source?
P>Если ваш продукт является производным от Git (ну например линкуется с ним каким-то образом) — то продукт должен быть выпущен под GPL. Но врядли это ваш случай.
можно точно разъяснить:
если я его использую только для контроля версий при разработке проекта, то мой проект должен быть под GNU?
также не совсем понял, что значит линкуется? т.е. взял за основу GIT т.к. исходники открыты — допилил?
Здравствуйте, -VaS-, Вы писали:
P_Y>> для нас основным был — невозможно ограничить доступ к части репозитория (например к коду защиты)
VS>А в HG это возможно?
Насколько мне кажется, в любой распределенной СКВ это невозможно. Нам ведь нужно хранить весь репозиторий у каждого участника.
Здравствуйте, <Аноним>, Вы писали:
P>>Если ваш продукт является производным от Git (ну например линкуется с ним каким-то образом) — то продукт должен быть выпущен под GPL. Но врядли это ваш случай.
А>можно точно разъяснить:
А>если я его использую только для контроля версий при разработке проекта, то мой проект должен быть под GNU?
Нет.
А>также не совсем понял, что значит линкуется? т.е. взял за основу GIT т.к. исходники открыты — допилил?
Да.
Здравствуйте, P_YegreS_P, Вы писали:
P_Y>2) описание недостатков Git P_Y> для нас основным был — невозможно ограничить доступ к части репозитория (например к коду защиты)
Здравствуйте, Peregrin, Вы писали:
P>Здравствуйте, <Аноним>, Вы писали:
P>>>Если ваш продукт является производным от Git (ну например линкуется с ним каким-то образом) — то продукт должен быть выпущен под GPL. Но врядли это ваш случай.
А>>можно точно разъяснить:
А>>если я его использую только для контроля версий при разработке проекта, то мой проект должен быть под GNU? P>Нет.
А>>также не совсем понял, что значит линкуется? т.е. взял за основу GIT т.к. исходники открыты — допилил? P>Да.
Здравствуйте, adontz, Вы писали:
a> .>А как это для части репо работает? a> Это уже фронт-эндом надо делать. Я предпочитаю апач, он гибче.
Просто мне непонятно как можно часть репо клонировать и как потом мержиться, как перемещения файлов между частями работает.
Здравствуйте, ., Вы писали:
a>> Это уже фронт-эндом надо делать. Я предпочитаю апач, он гибче. .>Просто мне непонятно как можно часть репо клонировать и как потом мержиться, как перемещения файлов между частями работает.
Копируется весь, ограничения только на запись. Закрыть часть репозитория от чтения не получится.
Здравствуйте, ., Вы писали:
.>Здравствуйте, adontz, Вы писали:
a>> .>А как это для части репо работает? a>> Это уже фронт-эндом надо делать. Я предпочитаю апач, он гибче. .>Просто мне непонятно как можно часть репо клонировать и как потом мержиться, как перемещения файлов между частями работает.
никак. частично ограничить можно только запись. чтение — бинарно. либо ты можешь читать весь репо, либо не можешь.
Здравствуйте, adontz, Вы писали:
a> Копируется весь, ограничения только на запись. Закрыть часть репозитория от чтения не получится.
А. Так не интересно, так и гит умеет.
Здравствуйте, P_YegreS_P, Вы писали:
P_Y>Насколько я понял, можно запретить только коммитить, читать всё равно можно. P_Y>А код защиты, именно хочется спрятать от чтения.
DVCS требуют наличия всего репо локально у каждого юзера. Так что один путь — вынести секретный код в отдельный репо. Его можно подключать к основному через git submodule, или вообще просто завести отдельный проект, к тому же, как я полагаю, код защиты вполне независимая вещь и можно девелопить её отдельно.
В hg так же, но я не знаю что там является аналогом submodule.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, CaptainFlint, Вы писали:
CF>>Не совсем так. Во-первых, команда-таки есть: git mv. Во-вторых, если одновременно попытаться переименовать и изменить файл, то в этом случае не просто "не будет гарантии", а, наоборот, будет гарантия, что связь между старым и новым файлом уничтожится (старый файл удалён, новый добавлен). Сохранить в коммите запись о том, что файл был одновременно и переименован, и изменён, невозможно.
A>Это что правда так? Нельзя одновременно менять и переименовывать файлы с сохранением истории?
Можно, только что переименовал класс вместе с файлом, в котором класс описан. Всё подхватилось. Git оценил похожесть файлов. Насколько это всегда будет работать — не знаю.
Сообщение заговорено потомственным колдуном, целителем и магом в девятом поколении!
Модерирование или минусование сообщения ведет к половому бессилию, венерическим заболеваниям, венцу безбрачия и диарее!
В SVN копировать репозитории не рекомендуется (есть даже спец. команда для этого), в Mercurial я могу копировать весь каталог и со мной ничего плохого не случится (точнее, случится, но не по этой причине). Было бы неплохо, если бы где-то в статье было бы всё-таки кратко отражено, можно ли копировать репозитории: всё-таки вопрос хранения репозиториев не зря рассматривается (а читать инглиш ради одного абзаца очень не хочется).
FDS>В SVN копировать репозитории не рекомендуется (есть даже спец. команда для этого), в Mercurial я могу копировать весь каталог и со мной ничего плохого не случится (точнее, случится, но не по этой причине). Было бы неплохо, если бы где-то в статье было бы всё-таки кратко отражено, можно ли копировать репозитории: всё-таки вопрос хранения репозиториев не зря рассматривается (а читать инглиш ради одного абзаца очень не хочется).
Можно. Ничего плохого не случится. В git (как и в Mercurial) вне самого репозитория ничего не хранится. Если после этого захочется наладить связь с оригиральным репозиторием (pull-push), то придется сделать это руками (git remote). Поэтому лучше делать нормальный клон — он создаст все нужные связи и использует hard links вместо копирования (в случае локальной копии).
Есть проект P.
Есть часть проекта P\A, которая живёт отдельно (имеет независимые версии, которые могут использоваться с разными версиями P), но в то же время для удобства лежит в папке с файлами P и может изменяться под конкретные версии P. Мне уже объяснили, что git контролирует всё дерево файлов целиком, и задача решается используя submodule, но логика его работы в TortoiseGit от меня ускользает. Сейчас просто создал отдельный репозиторий A и переместил его в директорию P\. Покажите пожалуйста пример использования submodule (без cmd) в TortoiseGit или GitExtensions.
Здравствуйте, kr12, Вы писали:
K> Покажите пожалуйста пример использования submodule (без cmd) в TortoiseGit или GitExtensions.
Начинать работать с гуёвыми обёртками можно только после того, как освоишь командную строку и будешь понимать, какие команды за какими пунктами менюшек стоят.
Я бы, наверно, такую важную вещь, как первичная настройка submodule, делал полностью с командной строки. Хотя, возможно, в дальнейшем работал бы с уже настроенной структурой репозиториев с использованием гуя.
Здравствуйте, Centaur, Вы писали: C>Начинать работать с гуёвыми обёртками можно только после того, как освоишь командную строку и будешь понимать, какие команды за какими пунктами менюшек стоят. C>Я бы, наверно, такую важную вещь, как первичная настройка submodule, делал полностью с командной строки. Хотя, возможно, в дальнейшем работал бы с уже настроенной структурой репозиториев с использованием гуя.
Просьба ответить по существу, хотя бы на пальцах, что есть эти submodule откуда и куда их подключать, а не подстрекать холивар cmd vs gui. В конце концов тема "Git в картинках" и аудитория соответствующая.
Здравствуйте, Pzz, Вы писали:
Pzz>Обычно статьи со столь безаппеляционной и поверхностной аргументацией на хабре вываливают, а не здесь
Это ты про картинку 8 или 10?
Если нам не помогут, то мы тоже никого не пощадим.
Re: Git в картинках
От:
Аноним
Дата:
08.11.11 12:02
Оценка:
а ежели у меня 1)есть папка с проектом на винте и 2) создан репо на githab
то как как первоночально заслать на гит хаб файлы?
в SVN это делалось командой импорт
Подскажите может ли git следовать по символьным ссылкам (linux/ubuntu) расположенным в рабочем каталоге репозитария?
Поскольку в Linux все храниться в файлах конфигов, есть наивная идея создать каталог, к которому будут прилинкованы каталоги с интересующими конфигами системы. Цель — смотреть что менялось, восстанавливать, вспоминать как настраивал.. и т.п.
Самостоятельно сделать или найти инфу не получилось.
Здравствуйте, cruse, Вы писали:
C>Подскажите может ли git следовать по символьным ссылкам (linux/ubuntu) расположенным в рабочем каталоге репозитария? C>Поскольку в Linux все храниться в файлах конфигов, есть наивная идея создать каталог, к которому будут прилинкованы каталоги с интересующими конфигами системы. Цель — смотреть что менялось, восстанавливать, вспоминать как настраивал.. и т.п. C>Самостоятельно сделать или найти инфу не получилось. http://stackoverflow.com/questions/1500772/getting-git-to-follow-symlinks-again
Как я понимаю проблема в том, что оно непонятно как должно работать, куча "what if" остаётся. Поэтому, git не следует по ссылкам, такое поведение вполне чётко определено и работает однозначно.
Ты можешь добавить "/" в репозиторий, а всё что не нужно — выпилить через .gitignore, главное потом не запускать "git clean -xdf".
Ещё можно создавать hard link, но это будет коряво работать с удалениями/добавлениями.
Ещё можно разные каталоги поместить в разные репозитории. Можно дополнительно их объединить как submodule
Ещё можно поменять направление ссылок — реально каталоги класть в репозиторий, и ссылаться на его содержимое из мест использования.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
В рекламе очень популярны НЛП технологии основанные на картинках. Целью является получение обратной связи от клиента, но прежде чем мысль трансформируется в мышечный нервный импульс, она должны быть осознана. Воздействие идет на сознание и подсознание сразу т.е. импульс рано или поздно все таки будет сформирован, зависит от впечатлительности человека. Хотелось бы видеть статью в таком виде.
Здравствуйте, AlexNek, Вы писали:
AN>Здравствуйте, IT, Вы писали:
IT>>Здравствуйте, alvas, Вы писали:
A>>>У Mercurial вроде как есть интергация с Visual Studio.
IT>>У GitExtensions тоже есть. Вполне достаточная для работы с ним. AN>А картинки к интеграции есть? Что -то в статье не заметил.
Re[4]: Git в картинках
От:
Аноним
Дата:
02.06.13 14:04
Оценка:
Здравствуйте, CaptainFlint, Вы писали:
... CF>Когда мне это потребовалось, я довольно долго рылся в поисках решения, и всё, что нашёл, — это утверждения о невозможности такого действия одинарным коммитом.
Да, переименовывать можно только в два коммита, но такая необходимость возникает только в случае синтаксических ошибок в имени файла т.е. достаточно редко. Хм, учите правописание.
Re[10]: Git в картинках
От:
Аноним
Дата:
02.06.13 14:17
Оценка:
Здравствуйте, adontz, Вы писали:
A>У меня постмодерация, так что такая модель не подходит. В сущности всё достаточно просто. вот давай на примере. Есть трёхзвенка. Сервер, клиент, БД. Её пишут три программиста, каждый свою часть. Тот кто знает WPF, плавает в SQL. Тот кто знает SQL, не разбирается в WCF. Можно премодерировать изменения, но тогда нужен отдельный человек, который будет разбираться во всех трёх технологиях и с утра до вечера премодерировать. Этон е эффективно. Мне проще дать каждому права на запись только в его часть. Тогда в случае больших изменений, затрагивающих несколько слоёв они будут вынуждены общаться и согласовывать свои действия. Эффективность при этом существенно не падает.
В таком случае необходим арбитр, для того что бы разнимать программерова, шило на мыло получается. В чем плюс?
Здравствуйте, Аноним, Вы писали:
А>Да, переименовывать можно только в два коммита, но такая необходимость возникает только в случае синтаксических ошибок в имени файла т.е. достаточно редко. Хм, учите правописание.
Здравствуйте, Игорь Ткачев, Вы писали:
ИТ>Аннотация: ИТ>Краткое введение в Git и Git Extensions.
Попытался прочитать второй раз. Сначала было интересно, но потом упёрся в КУЧУ окон, окошек, кнопочек, иконочек, разноцветных надписей и прочих рюшечек. Расстроился, читать бросил. Шлю минус в карму, ибо гит в первую очередь это коммандная строка. Впрочем, минус когда получишь — можешь его себе не записывать, все таки виндузятник ты, вы все такие...
Здравствуйте, Sheridan, Вы писали:
S>Попытался прочитать второй раз. Сначала было интересно, но потом упёрся в КУЧУ окон, окошек, кнопочек, иконочек, разноцветных надписей и прочих рюшечек. Расстроился, читать бросил. Шлю минус в карму, ибо гит в первую очередь это коммандная строка. Впрочем, минус когда получишь — можешь его себе не записывать, все таки виндузятник ты, вы все такие...
Надо Линусу ссылку подкинуть, или он тоже под видной кодит?
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Sheridan, Вы писали:
S>>Шлю минус в карму...
IT>Злой ты.
По мне так Меркуриал и Гит — это как Руби и Питон. Различий меньше чем похожести. Я лично предпочитаю Меркуриал, но я просто офигеваю от того как Гит тянет код из инета. Насколько я понял он его упакованным тянет. Это только он так может или ...?
Здравствуйте, мыщъх, Вы писали:
м> статью прочитал. интересно. жаль, что не раскрыта тема подключения через SSL.
А что там раскрывать-то? Это к git не относится. Обычно просто поверх ssh работает.
Или ты имеешь в виду https?
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, Игорь Ткачев, Вы писали:
ИТ>>Аннотация: ИТ>>Краткое введение в Git и Git Extensions.
S>Попытался прочитать второй раз. Сначала было интересно, но потом упёрся в КУЧУ окон, окошек, кнопочек, иконочек, разноцветных надписей и прочих рюшечек. Расстроился, читать бросил. Шлю минус в карму, ибо гит в первую очередь это коммандная строка. Впрочем, минус когда получишь — можешь его себе не записывать, все таки виндузятник ты, вы все такие...
А название темы "Git в картинках" тебя не смутило? Слать минус за 100% соответствие темы содержанию, это минус в карму.
Здравствуйте, ., Вы писали:
.>Ты можешь добавить "/" в репозиторий, а всё что не нужно — выпилить через .gitignore, главное потом не запускать "git clean -xdf".
Совсем нуль в git, однако все еще не оставляю надежды использовать его для управления версиями файлов конфигураций программ (т.е. не по назначению). И есть одна проблема, которая ставим меня в тупик.
Предположим, что мы создали репозиторий в "/" и у нас есть два файла, которые мы хотим "засунуть в git": /php.ini и /apache.conf
Я не могу понять, как можно _раздельно_ управлять версиями этих файлов. Т.е. меня интересует отдельно история изменения php.ini — ее я могу посмотреть, а вот как восстановить его до определенного коммита, не затрагивая при этом apache.conf не понятно.
Подскажите ключевые слова, для поиска.
Здравствуйте, Ash-2, Вы писали:
A> Я не могу понять, как можно _раздельно_ управлять версиями этих файлов. Т.е. меня интересует отдельно история изменения php.ini — ее я могу посмотреть,
git log php.ini
A> а вот как восстановить его до определенного коммита, не затрагивая при этом apache.conf не понятно. A> Подскажите ключевые слова, для поиска.
git checkout <commitid> php.ini
загрузится версия php.ini в твой рабочий каталог. Зафиксировать изменение:
git commit php.ini -m "решил откатить т.к. всё заглючило"
Если нам не помогут, то мы тоже никого не пощадим.
.
Счастливчик.
