1.1, Resonance (ok), 09:02, 29/09/2015 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
> Реализации "git pull" и "git am" переписаны на языке Си;
а на чем было? О_О
| |
|
|
|
4.19, Аноним (-), 14:20, 29/09/2015 [^] [^^] [^^^] [ответить]
| +3 +/– |
Там sh а не баш. Просто выросло поколение неучей которые из не различают. Это ещё ладно, а ведь иногда их допускают до писания скриптов, и тогда несовместимое ни с чем bash-онлу гoвнo начинает дрызгать рекой.
| |
|
5.34, Аноним (-), 22:16, 29/09/2015 [^] [^^] [^^^] [ответить]
| –2 +/– |
О ученый выискался, а ну как как рекомендовано писать $() или '' ?
| |
|
6.42, anonymous (??), 13:20, 30/09/2015 [^] [^^] [^^^] [ответить]
| +1 +/– |
Неужели трудно набрать
man bash, man ksh, man sh, man <ваш_любимый_шелл>?
| |
|
|
6.38, llolik (ok), 09:00, 30/09/2015 [^] [^^] [^^^] [ответить]
| +2 +/– |
Тем, что у того, кто будет пользоваться, не обязательно будет bash, у которого есть свои специфические особенности ("bash-измы"). А синтаксис Bourne shell (он же sh) стандарт да-факто и поддерживается в *.nix везде и всем.
Или для вас сюрприз, что шеллы ограничиваются не только bash-ем и их в общем-то хватает разных?
| |
|
7.43, Crazy Alex (ok), 03:02, 01/10/2015 [^] [^^] [^^^] [ответить]
| –1 +/– |
Не помню линукса, где не было бы баша по дефолту. А если БСДМшники страдают - это by design.
| |
|
6.40, Andrey Mitrofanov (?), 10:30, 30/09/2015 [^] [^^] [^^^] [ответить]
| +/– |
> поддерживаю, чем плохо написание скриптом на баше, а не сш?
Друзья проприертарщиков страдают же. И виноваты в этом те, кто пишет на #!/bin/bash-е.
Очевидно же!
| |
|
|
|
|
2.25, h31 (ok), 15:25, 29/09/2015 [^] [^^] [^^^] [ответить]
| –3 +/– |
Git написан на смеси сишечки, шелла и перла.
// Комментарий специально для противников Mercurial.
| |
2.32, Аноним (-), 18:30, 29/09/2015 [^] [^^] [^^^] [ответить]
| +/– |
> а на чем было? О_О
git am - на шеле и перле. Без последнего - не работал
| |
|
1.9, Аноним (-), 10:06, 29/09/2015 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
> Проведена работа по увеличению удобства работы в интерфейсе gitk
QGIT умер окончательно? :(
| |
|
|
|
4.37, funny.falcon (?), 07:57, 30/09/2015 [^] [^^] [^^^] [ответить]
| +/– |
И чем это плохо? для разрешения мерж-конфликтов meld очень удобен. А что кроме него она запускает? И чем это плохо?
По-моему, это хорошо, когда велосипед не изобретается, а берётся и катается. Вы со мною не согласны?
| |
|
|
|
1.10, Штунц (?), 11:42, 29/09/2015 [ответить] [﹢﹢﹢] [ · · · ]
| –10 +/– |
Git прекрасен, но действительно конфеткой его делают 2 программы для Windows:
- окно истории коммитов (Log Messages) в TortoiseGit
- и из того же набора TortoiseGitMerge
| |
|
2.23, Пользователь Debian (?), 14:37, 29/09/2015 [^] [^^] [^^^] [ответить]
| +/– |
Попробуйте Git Extensions: он такой же красивый и понятный, но в отличие от TortoiseGit, не пытается сделать вид, что Вы работаете с Subversion.
И даже умеет добавлять в индекс патчи кусками (почти уровень штатной 'git gui').
| |
|
|
4.41, Пользователь Debian (?), 10:32, 30/09/2015 [^] [^^] [^^^] [ответить]
| +/– |
Да, именно это.
Правда, когда я смотрел на него задний раз, он не умел добавлять выбранные строки из куска (как 'git gui'), а возможности *редактировать* куски перед добавлением по-моему нет вообще ни в одном GUI фронт-енде.
Но хоть что-то...
| |
|
|
|
1.18, Аноним (-), 13:54, 29/09/2015 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Они бы лучше git status ускорили а то на реально больших проектах тормозит. Можно иногда минуту ждать пока прочухает. Основное время конечно сканирование файловой системы у него занимает, но может что-то и можно ускорить там.
| |
|
|
3.21, Аноним (-), 14:28, 29/09/2015 [^] [^^] [^^^] [ответить]
| –1 +/– |
круто если так, я как раз года два ничего настолько большого и не смотрел
| |
|
2.22, Аноним (-), 14:34, 29/09/2015 [^] [^^] [^^^] [ответить]
| +/– |
> Они бы лучше git status ускорили а то на реально больших проектах
> тормозит. Можно иногда минуту ждать пока прочухает. Основное время конечно сканирование
> файловой системы у него занимает, но может что-то и можно ускорить
> там.
Ничего там нельзя ускорить, как ни крути нужно обойти всё поддерево ФС и проверить не изменилось/добавилось ли что. Есть -u no, но не заметил чтобы оно что-то заметно ускоряло, хотя и не замерял. Со стороны git тут ничего не сделать, поэтому это вопрос уже к файловой системе. Я проблему решил (у меня ZFS) добавив SSD для L2ARC. ZFS в этом плане очень рулит, потому что не нужно никуда руками переносить данные или думать куда монтировать диск - подключил, после первого git status репозиторий свалился в кэш, второй статус и далее обрабатываются мгновенно потому что читают с ssd. 128G мне лично хватает, после месяца работы используется только 70G кэша.
| |
|
3.39, _smit_ (?), 09:14, 30/09/2015 [^] [^^] [^^^] [ответить]
| –1 +/– |
>> Они бы лучше git status ускорили
> Ничего там нельзя ускорить, как ни крути нужно обойти всё поддерево ФС
- при записи время модификации каталогов разве не распространяется вверх по дереву ?
| |
|
|
3.44, й (?), 14:38, 01/10/2015 [^] [^^] [^^^] [ответить]
| –1 +/– |
git 2.6.0 на win 8.1 по-прежнему безбожно тормозит с 'git status'. с включенным кэшированием, ага.
| |
|
4.45, Led (ok), 22:30, 01/10/2015 [^] [^^] [^^^] [ответить]
| +/– |
> git 2.6.0 на win 8.1 по-прежнему безбожно тормозит
Всё правильно - так и должно быть.
| |
|
|
|
1.26, Аноним (-), 15:35, 29/09/2015 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
не распределённая, а децентрализованная.
распределённая, - это когда так: gitchain.org
| |
1.31, Аноним (-), 17:14, 29/09/2015 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
Много изменений в сравнении с прошлым релизом, где не было ничего интересного. Это радует.
| |
|