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

.>Здравствуйте, 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, если хочешь понять как тебе вернуть твой файл.
спасибо гляну