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>Ну ты — джедай. Тут уж ничего не поделаешь, привыкай
Ты не поверишь, но даже те кнопки, которые есть в студии мной практически не используются. Нет необходимости. Одтельный тул гораздо удобнее, чем всякие интеграционные штучки. Единственное исключение — история, ей и в гите не сложно пользоваться, но навигация по проекту в студии всё же поудобнее.
Если нам не помогут, то мы тоже никого не пощадим.
Иногда надо дать права только на часть.
Если нам не помогут, то мы тоже никого не пощадим.
