Модератор, мда, прочитал. Это исключительно имхо, но за тегом 'git' наблюдает гораздо больше людей, пользующихся sourcetree, чем за самим тегом 'sourcetree'. Тем более я не увидел его в списке предлагаемых тегов при создании этого вопроса.
Итог - люди, которые могут знать ответ, его не прочтут.
Но ок, правила есть правила, буду учитывать.
Сергей: у вас файл на 1000 строк. Вы поменяли пару кусков в 200 строк местами. Просто местами.
Чем не атомарный коммит? Фактически это 2 операции копипаста. Поможет это при просмотре? Кусок, помеченный удалённым, будет помечен добавленным в другом месте. А теперь, допустим, в этих 200 строках вы случайно добавите точку? Поможет вам Diff её найти? Нет.
aol-nnov: увы, ПО, с которым я вынужден работать - не кроссплатформенное.
А насчёт гита не соглашусь, т.к. вопрос был как раз как решать такие проблемы не каждый день, а один раз. Впрочем, ларчик открывался просто, оказывается.
Так и есть! Спасибо что не предложили сменить ОСь! =)
P. S. согласен, что проще, файл в любом случае переименуем. Но, вдруг кто-то сталкивался с подобной проблемой и знает как её решать средствами Git'а?
Sayonji: то есть "var new_array = array;" - это не копирование массива, а ссылка на него? Это особенность работы цикла forEach?
Почему такое происходит только в случае двумерного массива? Если я делаю:
var new_array=[];
var row = ['a','b1;b2'];
row[j].split(char).forEach(function(el) {
var new_row = row;
new_row[j] = el;
new_array.push(new_row);
});
aol-nnov: не репозитория, а коммита. у репозитория есть ветка master и много тегов.
скажем так, я нормально отношусь ко множеству веток))) по-сути, тот же git flow именно это и предлагает. но некоторых людей это почему-то порой пугает.
т.к. в NTFS структура каталогов храниться в основном в начале раздела, а он был перезаписан, то testdisk восстановить нихрена не смог. Пришлось восстанавливать отдельные файлы и тут уже гораздо удобнее был rstudio.
А, когда я попытался восстановить сам раздел, то testdisk меня послал использовать утилиту chkdsk из под Windows о_О
aol-nnov: к тегу. разве gc не удаляет только коммиты которым присвоена ветка? по идее коммиты с присвоенным тегом не должны быть удалены.
Например в примере ниже коммиты A* и A** не будут удалены gc ведь?
__A____B___C___D_______
\__A*__A**(tag:r1.0)
Зачем:
в git есть генерируемый файл .docx, который периодически кто-то берёт на review и пишет в нём комментарии. Пока этот кто-то будет его смотреть сам файл уже не раз обновится. Поэтому не очень хорошо файл с комментариями к старой версии коммитить в основную ветку и надо делать ответвление от того коммита, который человек взял на review. А плодить ветки не хочется, поэтому и спрашиваю про теги.
Только не спрашивайте зачем .docx скрещивать с git'ом, умоляю. =)
aol-nnov: само собой, коммиты тоже будут запушены вместе с тегами. Но с коммитами проблем не будет при выполнении git pull, т.к. никакого rebase не происходит.
В документации нашёл, что git fetch осуществляет удаление и перенос тегов. А git pull?
Edgars: Мне вот не помогло. так и не разобрался и забил на Nautilus. Но подозреваю, что проблема в двухфакторной аутентификации, в каком-то месте она возможно не поддерживается.
а восстановление разделов через testdisk перезатрёт всё на диске, да? то есть, при попытке восстановления через testdisk имеется риск потерять данные совсем? или я не так понимаю что-то?
В общем-то сам пришёл к такому же выводу. По функционалу лучше SmartGit'а не нашёл.
Ещё тестирую Gitkraken сейчас дома, он довольно интуитивно-понятный.
SourceTree - неплох, но зато он абсолютно бесплатный.