Да, но здесь‐то модификатор всего один! Впрочем, в терминале <ModX-ModY-x> не заработает практически никогда, поэтому если вам (хотя бы иногда) нужен именно терминал с Vim, то ничего назначать на «сложные» сочетания вы не будете, потому что не можете, а не потому что неудобно (я, к примеру, не вижу ничего сложного в <C-S-, нужно просто мизинец чуть больше (Ctrl на CapsLock) согнуть). Поэтому же в стандартных сочетаниях есть <C-буква(лат.)>, верхний регистр, все печатные ASCII символы и немного оставшихся <C-неБуква> из того, что есть в ASCII (вроде U+001D, <C-]>) и вроде даже <F1>, но больше ничего: Брам не любит добавлять возможности, завязанные на GUI, вплоть до того, что сочетание <C-S-x> внезапно означает то же самое, что и <C-x>, потому что именно так поступают все эмуляторы терминалов без настройки (а многие и настроить различать эти два случая нельзя). (В последнем предложении под x понимаются печатные символы из ASCII, <C-S-F1> в GUI нормально работает, иногда даже и в терминале.)
Кроме того автор из первой цитаты намекал на нормальный режим, а я написал, что я использую в режиме вставки. Впрочем, там тоже есть полезные сочетания с <C- и <S-, особенно с shift’ом.
Именно так: из режима «вставки» в «нормальный» режим. Хотя у меня для таких мелких передвижений в режиме набора используются сочетания вроде <C-b>/<C-f> (назад/вперёд на символ), ,b/,w (назад/вперёд на слово), ,B/,W (назад/вперёд на СЛОВО (ограниченное пробелами: первый вариант переносит на f в (foo|, второй — на ()). (Я имею ввиду, не выходя из режима вставки.)
И стрелки с <C- вроде тоже поддерживаются, но до них далеко тянуться и с высокой вероятностью в терминале что‐то из стрелок с модификаторами работать не будет.
У вас с этой проблемой нет особого выбора. Просто запретите метаклассом создавать метод meow(), лучше вы даже на уровне ниже¹ не напишете: не будет этой проблемы, будет проблема двойной инициализации, либо проблема её отсутствия, либо проблема гонки (кстати, ваш оригинальный код должен был удерживать блокировку в new и освобождать её в _fake_init (и не должен был использовать двойные подчёркивания где не надо)), либо проблема нарушения контракта «один id ссылается всегда на один и тот же объект».
¹ «На уровне ниже» можно существующему объекту и тип изменить, в т.ч. временно; при достаточном знании внутренностей CPython можно даже в процессе ничего не поломать до следующего релиза.
Верно, но это на самом деле вопрос того, как классы используются на самом деле. Стилем кодирования (и метаклассом чтобы наверняка) в принципе можно запретить определение новых методов, как и переопределение старых с несовместимыми сигнатурами. Хотя я лично всё же нахожу задачу несколько странной, и просто написал бы функцию получения животного по id, возможно даже вида def get_animal(cls, id, *args, **kwargs) (дополнительные аргументы — для конструктора).
Я как‐то не вижу проблемы вообще. Зачем запрещать __init__, вызывая неочевидное поведение, просто напишите в аргументах __new__*args, **kwargs и спокойно игнорируйте эти аргументы? А проблема с __init__ легко решается метаклассом:
class MetaAnimal(type):
def __new__(cls, name, bases, namespace, **kwargs):
old_init = namespace.get('__init__')
if old_init:
def __init__(self, id, *args, **kwargs):
if not self._called_init:
old_init(self, id, *args, **kwargs)
self._called_init = True
namespace['__init__'] = __init__
return type.__new__(cls, name, bases, namespace)
class Animal(metaclass=MetaAnimal):
_cache = dict()
_called_init = False
def __new__(cls, id, *args, **kwargs):
if not id in Animal._cache:
Animal._cache[id] = super().__new__(cls)
return Animal._cache[id]
def __init__(self, id):
self.id=id
print('THERE')
class Cat(Animal):
data="data"
def __init__(self, id, b):
super(Cat, self).__init__(id)
print('HERE')
print(id(Animal(1)))
print(id(Animal(1)))
print(id(Cat(1)))
print(id(Cat(2, 1)))
print(id(Cat(2)))
Печатает
THERE
139883603787504
139883603787504
139883603787504
THERE
HERE
139883603787672
139883603787672
Для администрирования компьютеров и локальной сети в целом есть отдельные «программисты». Правда, они не только наши компьютеры администрируют, но, вроде бы, всех в здании. К ним же идут за лицензиями.
Линуксовый таб сильно настраивается, особенно если вы используете zsh, которая через zstyle позволяет сделать с автодополнением практически всё, что вам может придти в голову, включая, к примеру, проигрывание музыки при каждом нажатии tab без ущерба для собственно автодополнения. Аналог TAB: menu-complete у zsh, кстати, по‐умолчанию стоит. Хотя как просто сделать автоподстановку первого же соответствия (аналог Vim с set wildmode=full) по первому же нажатию tab я не нашёл (что не значит, что такого нет), но непросто (т.е. не через zstyle) это всегда можно сделать разными способами. (С set wildmode=full Vim как раз будет имитировать автоподстановку как в cmd.exe.)
А почему «цветов не хватает»? Во многих терминалах есть поддержка 24‐битного цвета, что больше либо равно числу цветов, поддерживаемых большинством мониторов.
PS: не думали попробовать написать что‐то сложное под POSIX shell? Я как‐то аналог getopt --longoptions писал, использовал много eval для «массивов», но вопрос о скорости, к счастью, не стоял.
В этом примере всё зависит от версии Python: PyPy, PyPy3 и CPython начиная с какой‐то из третьих версий (но точно больше 3.4.5: у меня именно она и a is not b в данном случае) применяют какую‐то оптимизацию, из‐за чего a is b в вашем случае, тогда как другие версии её не применяют. В общем, просто учитывайте, что 257 is 257 не гарантируется.
Насколько я понял, имеется ввиду, что «in array вызовет iter(array) и сохранит итератор ещё при создании генератора, а условия будут проверяться только во время собственно итерации, которая ленивая».
Никто как‐то ещё не может похвастаться идеальной, да ещё и универсальной программой, поэтому скорость взаимодействия максимальной быть не может. На этапе проектирования интерфейса ускорены могут быть и консольные, и GUI программы, но GUI намного сложнее подпилить самому под свою задачу, тренировками того же слепого набора можно ускориться ровно настолько, насколько автор покрыл всё клавиатурными сочетаниями. Т.е. если вас не устраивает скорость взаимодействия с GUI приложением или его интерфейс, то вы не сможете сделать ничего, не будучи самому разработчиком GUI приложений.
Универсальности никакой никогда не было, есть некоторые общие соглашения насчёт ограниченного набора действий, но и они часто нарушаются. В тех же полях ввода <S-Left> почти наверняка что‐то выделит, а уже <C-S-Home> может и переход сделать. <Tab> может увести вас куда‐то не туда, вставить что‐то в поле ввода или просто ничего не сделать. До сих пор не могу привыкнуть к тому, что делает <S-перетаскивание> и <C-перетаскивание> в Altium: почти везде второе копирует объект, в Altium — перетаскивает с сохранением соединений, а копирует первое. Если автор GUI заранее не предположил, что данные с некоего элемента интерфейса понадобится куда‐то скопировать, то единственным доступным обычному пользователю способом это всё же сделать будет скриншот (и последующее распознавание текста, скорее всего, ручное, — если нужен именно текст) — в GUI я такое вижу постоянно, особенно в сообщениях об ошибках (их очень не любят тестировать). В консоли я такого не видел никогда, технология не позволяет запретить мне скопировать текст.
Конечно, я не жду, что что‐то вроде Altium вдруг окажется консольным приложением — даже если такое существует, под терминал такие приложения не подходят никак. Но универсальности в GUI меньше, чем в консоли: нарушаемые соглашения есть и там, и там, но в консоли часть ожиданий пользователя нарушить нельзя в принципе из‐за ограничений технологии.
Я к тому, что это настолько сложно, что нужно стремиться вместо этого писать кастомные скрипты в консоли?
Нет, именно это — не настолько. Я к консоли «стремлюсь», потому что их там можно писать, и потому что часть вещей там универсальна: к примеру, когда вы не знаете точного вида регулярного выражения проще и быстрее искать что‐то в git log --patch | less или hg log -v --patch | less (Про автоматически используемый git’ом pager не говорите, я их всегда отключаю.), чем, во‐первых, вспоминать что поиск по патчам в одном месте git log -G, в другом hg grep, во‐вторых, учитывать, что регулярные выражения в одном месте вроде POSIX ERE, а в другом, кажется, Python re, в‐третьих, тратить время на перезапуск — поиск в less быстрее, чем повторный запуск с необходимостью повторно сформировать diff’ы.
Мне вот неохота прогонять 10 коммитов с начала ветки, если надо поменять только 2 последних.
Зависит от редактора: переместить курсор в конец списка изменений в Vim требует нажатия всего одной клавиши.
Не говоря уже о том, что у вас гораздо больше времени уйдет на редактирование файла для ребейза. Это экономия на спичках.
На редактирование файла для rebase у меня зачастую уходит столько же времени, сколько потребуется, чтобы пройти по списку действий из 1, исключая последнее («дальше что‐то ещё»).
Ну и да. "Переключиться на терминал, нажать G, нажать I, нажать T, нажать Space, нажать R, нажать I, проверить, что нет опечаток, нажать Enter". Обнаружить опечатку "get", переместить туда курсор, убрать символ, добавить символ, или нажать Ctrl+C и набрать все заново. А потом в "git log" проверить, все ли правильно получилось, не забыл ли чего.
Слишком долго печатаете для программиста: за следующей клавишей можно и нужно тянуться одновременно с набором предыдущей (даже без слепого набора, но с двумя руками), поэтому делить на отдельные нажатия смысла не имеет. Опечатки тоже проверяются по мере набора (если смотреть не на клавиатуру). А мышка так не параллелится: «найти нужное изменение» и «навести мышку» вы, скорее всего, будете делать одновременно, а с остальным из моего списка так не получится. И ускорить сложнее: про методы ускорения набора я слышал, про методы ускорения взаимодействия с GUI я слышал только «выучите клавиатурные сочетания и используйте методы ускорения набора» (возможно, что‐то иное знают «профессиональные» игроки в некоторые RTS).
(Кстати, такой вопрос: а в tortoisegit часом не получится всё делать с клавиатуры?)
В терминале можно пускать компиляцию, тесты, посмотреть результаты с travis, … А в tortoisegit только git. Впрочем, это только альтернативный workflow: терминал с tmux и Vim плюс браузер в принципе заменяются на браузер+IDE+tortoisegit, особенно учитывая, что в IDE терминал часто есть.
А сложное: сравните
Переключиться на черепашку, посмотреть на лог, найти там нужное изменение, навести мышку, нажать ПКМ, навести мышку и нажать ЛКМ, дальше что‐то ещё.
Переключиться на терминал, напечатать git ri<CR>, дальше что‐то ещё.
И что, что заканчивается? У git полно универсальных команд: тот же checkout берёт на себя и создание ветки, и переключение на ветку с обновлением рабочего каталога, и обновление каталога без переключения, и частичное применение изменений из другой ветки. У mercurial это всё разные команды (правда, последнего в таком виде как у git нет, или требуется plugin). Изменение истории — это у меня было
A-D'-E-D'' (feature)
|
s-+-B-C (master)
Я хочу объединить D' и D'':
A-D-E (feature)
|
s-+-B-C (master)
. Но по‐умолчанию git rebase -i master сделает
s-B-C (master)-A-D-E (feature)
Взамен вы получили постоянно висящее окно (или лог будет настолько же «под рукой» как у меня в терминале), специализированное практически под одну задачу. А вопрос был не в том, как бы искать попроще, а в том как бы не искать вообще.
Т.е. всё же надо искать, где начиналась ваша ветка, или хотя бы предка первого изменяемого изменения. Журнал не в тему: искать удобнее и несколько быстрее, но с git ri ничего искать не нужно.
git rebase -i abcdef, внезапно, сделает rebase, если изменения не основаны на abcdef. А нужно изменение истории без rebase.
git ri не требует знания количества коммитов в той части истории, которую нужно изменить, а git rebase -i HEAD~3 требует. Когда их число достигает хотя бы пяти (а я легко могу сделать такую серию только из fixup! изменений) считать становится уже неудобно; если PR большой, то опечатки приходится исправлять и за десяток полноценных коммитов.
А каким именно образом указывается основание для rebase в tortoisegit я не знаю, пока что он мне был нужен исключительно чтобы сделать git clone, в случаях, когда мне неохота ставить babun (сборка на основе cygwin), в котором git также есть (для новых проектов, за редким исключением, всегда использую mercurial). В консоли приходится искать, или отряжать скрипт, чтобы он искал. Если в tortoisegit такой скрипт написали за вас, то это отлично.
Привязок у библиотеки ну очень много, вроде все популярные языки с поддержкой вызова C’шных функций есть (не знаю, насколько полные и поддерживаемые). А замены консольному git почему‐то нет, а UI основаны на нём. TortoiseGit вроде имеет настройку «UseLibgit2» (если не ошибаюсь, включена по‐умолчанию), но я как‐то недавно установил tortoisegit, забыв git и он всё равно потребовал git, а не просто заблокировал часть операций, которые libgit2 пока не умеет, вместо этого.
В консоли по‐умолчанию rebase идёт на master (точнее, на что‐то настраиваемое, но это «что‐то» — ветка, см. второй абзац раздела «DESCRIPTION» git help rebase). А alias делает именно это: rebase на начало ветки (пока нет слияний, rebase на последнее слияние, если есть). В tortoisegit есть простой способ найти эту точку?
А про «сложные вещи»: если консоль непривычна, то сложные вещи будет сделать очень сложно. А как она будет привычна, если используется в основном GUI?
Да, но здесь‐то модификатор всего один! Впрочем, в терминале
<ModX-ModY-x>не заработает практически никогда, поэтому если вам (хотя бы иногда) нужен именно терминал с Vim, то ничего назначать на «сложные» сочетания вы не будете, потому что не можете, а не потому что неудобно (я, к примеру, не вижу ничего сложного в<C-S-, нужно просто мизинец чуть больше (Ctrl на CapsLock) согнуть). Поэтому же в стандартных сочетаниях есть<C-буква(лат.)>, верхний регистр, все печатные ASCII символы и немного оставшихся<C-неБуква>из того, что есть в ASCII (вроде U+001D,<C-]>) и вроде даже<F1>, но больше ничего: Брам не любит добавлять возможности, завязанные на GUI, вплоть до того, что сочетание<C-S-x>внезапно означает то же самое, что и<C-x>, потому что именно так поступают все эмуляторы терминалов без настройки (а многие и настроить различать эти два случая нельзя). (В последнем предложении подxпонимаются печатные символы из ASCII,<C-S-F1>в GUI нормально работает, иногда даже и в терминале.)Кроме того автор из первой цитаты намекал на нормальный режим, а я написал, что я использую в режиме вставки. Впрочем, там тоже есть полезные сочетания с
<C-и<S-, особенно с shift’ом.Именно так: из режима «вставки» в «нормальный» режим. Хотя у меня для таких мелких передвижений в режиме набора используются сочетания вроде
<C-b>/<C-f>(назад/вперёд на символ),,b/,w(назад/вперёд на слово),,B/,W(назад/вперёд на СЛОВО (ограниченное пробелами: первый вариант переносит наfв(foo|, второй — на()). (Я имею ввиду, не выходя из режима вставки.)И стрелки с
<C-вроде тоже поддерживаются, но до них далеко тянуться и с высокой вероятностью в терминале что‐то из стрелок с модификаторами работать не будет.У вас с этой проблемой нет особого выбора. Просто запретите метаклассом создавать метод
meow(), лучше вы даже на уровне ниже¹ не напишете: не будет этой проблемы, будет проблема двойной инициализации, либо проблема её отсутствия, либо проблема гонки (кстати, ваш оригинальный код должен был удерживать блокировку в new и освобождать её в _fake_init (и не должен был использовать двойные подчёркивания где не надо)), либо проблема нарушения контракта «один id ссылается всегда на один и тот же объект».¹ «На уровне ниже» можно существующему объекту и тип изменить, в т.ч. временно; при достаточном знании внутренностей CPython можно даже в процессе ничего не поломать до следующего релиза.
Верно, но это на самом деле вопрос того, как классы используются на самом деле. Стилем кодирования (и метаклассом чтобы наверняка) в принципе можно запретить определение новых методов, как и переопределение старых с несовместимыми сигнатурами. Хотя я лично всё же нахожу задачу несколько странной, и просто написал бы функцию получения животного по id, возможно даже вида
def get_animal(cls, id, *args, **kwargs)(дополнительные аргументы — для конструктора).Я как‐то не вижу проблемы вообще. Зачем запрещать
__init__, вызывая неочевидное поведение, просто напишите в аргументах__new__*args, **kwargsи спокойно игнорируйте эти аргументы? А проблема с__init__легко решается метаклассом:Печатает
, что и нужно.
Для администрирования компьютеров и локальной сети в целом есть отдельные «программисты». Правда, они не только наши компьютеры администрируют, но, вроде бы, всех в здании. К ним же идут за лицензиями.
Frontend+backend — это ни о чём вообще. Настоящие разработчики должны уметь
С 1989 так существуем и ничего.
Гм, так просто… Только со второй командой получилось что нужно. Только с первой нет (проверял под
zsh -f). Обе одновременно не проверял.Ещё убрать меню и получится копия автодополнения cmd.exe, но зачем такое нужно? Заявленное затруднение вы разрешили.
Линуксовый таб сильно настраивается, особенно если вы используете zsh, которая через zstyle позволяет сделать с автодополнением практически всё, что вам может придти в голову, включая, к примеру, проигрывание музыки при каждом нажатии tab без ущерба для собственно автодополнения. Аналог
TAB: menu-completeу zsh, кстати, по‐умолчанию стоит. Хотя как просто сделать автоподстановку первого же соответствия (аналог Vim сset wildmode=full) по первому же нажатию tab я не нашёл (что не значит, что такого нет), но непросто (т.е. не через zstyle) это всегда можно сделать разными способами. (Сset wildmode=fullVim как раз будет имитировать автоподстановку как в cmd.exe.)А почему «цветов не хватает»? Во многих терминалах есть поддержка 24‐битного цвета, что больше либо равно числу цветов, поддерживаемых большинством мониторов.
PS: не думали попробовать написать что‐то сложное под POSIX shell? Я как‐то аналог getopt --longoptions писал, использовал много
evalдля «массивов», но вопрос о скорости, к счастью, не стоял.В этом примере всё зависит от версии Python: PyPy, PyPy3 и CPython начиная с какой‐то из третьих версий (но точно больше 3.4.5: у меня именно она и
a is not bв данном случае) применяют какую‐то оптимизацию, из‐за чегоa is bв вашем случае, тогда как другие версии её не применяют. В общем, просто учитывайте, что257 is 257не гарантируется.Насколько я понял, имеется ввиду, что «
in arrayвызоветiter(array)и сохранит итератор ещё при создании генератора, а условия будут проверяться только во время собственно итерации, которая ленивая».Никто как‐то ещё не может похвастаться идеальной, да ещё и универсальной программой, поэтому скорость взаимодействия максимальной быть не может. На этапе проектирования интерфейса ускорены могут быть и консольные, и GUI программы, но GUI намного сложнее подпилить самому под свою задачу, тренировками того же слепого набора можно ускориться ровно настолько, насколько автор покрыл всё клавиатурными сочетаниями. Т.е. если вас не устраивает скорость взаимодействия с GUI приложением или его интерфейс, то вы не сможете сделать ничего, не будучи самому разработчиком GUI приложений.
Универсальности никакой никогда не было, есть некоторые общие соглашения насчёт ограниченного набора действий, но и они часто нарушаются. В тех же полях ввода
<S-Left>почти наверняка что‐то выделит, а уже<C-S-Home>может и переход сделать.<Tab>может увести вас куда‐то не туда, вставить что‐то в поле ввода или просто ничего не сделать. До сих пор не могу привыкнуть к тому, что делает<S-перетаскивание>и<C-перетаскивание>в Altium: почти везде второе копирует объект, в Altium — перетаскивает с сохранением соединений, а копирует первое. Если автор GUI заранее не предположил, что данные с некоего элемента интерфейса понадобится куда‐то скопировать, то единственным доступным обычному пользователю способом это всё же сделать будет скриншот (и последующее распознавание текста, скорее всего, ручное, — если нужен именно текст) — в GUI я такое вижу постоянно, особенно в сообщениях об ошибках (их очень не любят тестировать). В консоли я такого не видел никогда, технология не позволяет запретить мне скопировать текст.Конечно, я не жду, что что‐то вроде Altium вдруг окажется консольным приложением — даже если такое существует, под терминал такие приложения не подходят никак. Но универсальности в GUI меньше, чем в консоли: нарушаемые соглашения есть и там, и там, но в консоли часть ожиданий пользователя нарушить нельзя в принципе из‐за ограничений технологии.
Нет, именно это — не настолько. Я к консоли «стремлюсь», потому что их там можно писать, и потому что часть вещей там универсальна: к примеру, когда вы не знаете точного вида регулярного выражения проще и быстрее искать что‐то в
git log --patch | lessилиhg log -v --patch | less(Про автоматически используемый git’ом pager не говорите, я их всегда отключаю.), чем, во‐первых, вспоминать что поиск по патчам в одном местеgit log -G, в другомhg grep, во‐вторых, учитывать, что регулярные выражения в одном месте вроде POSIX ERE, а в другом, кажется, Python re, в‐третьих, тратить время на перезапуск — поиск в less быстрее, чем повторный запуск с необходимостью повторно сформировать diff’ы.Зависит от редактора: переместить курсор в конец списка изменений в Vim требует нажатия всего одной клавиши.
На редактирование файла для rebase у меня зачастую уходит столько же времени, сколько потребуется, чтобы пройти по списку действий из 1, исключая последнее («дальше что‐то ещё»).
Слишком долго печатаете для программиста: за следующей клавишей можно и нужно тянуться одновременно с набором предыдущей (даже без слепого набора, но с двумя руками), поэтому делить на отдельные нажатия смысла не имеет. Опечатки тоже проверяются по мере набора (если смотреть не на клавиатуру). А мышка так не параллелится: «найти нужное изменение» и «навести мышку» вы, скорее всего, будете делать одновременно, а с остальным из моего списка так не получится. И ускорить сложнее: про методы ускорения набора я слышал, про методы ускорения взаимодействия с GUI я слышал только «выучите клавиатурные сочетания и используйте методы ускорения набора» (возможно, что‐то иное знают «профессиональные» игроки в некоторые RTS).
(Кстати, такой вопрос: а в tortoisegit часом не получится всё делать с клавиатуры?)
В терминале можно пускать компиляцию, тесты, посмотреть результаты с travis, … А в tortoisegit только git. Впрочем, это только альтернативный workflow: терминал с tmux и Vim плюс браузер в принципе заменяются на браузер+IDE+tortoisegit, особенно учитывая, что в IDE терминал часто есть.
А сложное: сравните
git ri<CR>, дальше что‐то ещё.И что, что заканчивается? У git полно универсальных команд: тот же checkout берёт на себя и создание ветки, и переключение на ветку с обновлением рабочего каталога, и обновление каталога без переключения, и частичное применение изменений из другой ветки. У mercurial это всё разные команды (правда, последнего в таком виде как у git нет, или требуется plugin). Изменение истории — это у меня было
Я хочу объединить
D'иD'':. Но по‐умолчанию
git rebase -i masterсделаетВзамен вы получили постоянно висящее окно (или лог будет настолько же «под рукой» как у меня в терминале), специализированное практически под одну задачу. А вопрос был не в том, как бы искать попроще, а в том как бы не искать вообще.
Т.е. всё же надо искать, где начиналась ваша ветка, или хотя бы предка первого изменяемого изменения. Журнал не в тему: искать удобнее и несколько быстрее, но с
git riничего искать не нужно.git rebase -i abcdef, внезапно, сделает rebase, если изменения не основаны на abcdef. А нужно изменение истории без rebase.git riне требует знания количества коммитов в той части истории, которую нужно изменить, аgit rebase -i HEAD~3требует. Когда их число достигает хотя бы пяти (а я легко могу сделать такую серию только изfixup!изменений) считать становится уже неудобно; если PR большой, то опечатки приходится исправлять и за десяток полноценных коммитов.А каким именно образом указывается основание для rebase в tortoisegit я не знаю, пока что он мне был нужен исключительно чтобы сделать
git clone, в случаях, когда мне неохота ставить babun (сборка на основе cygwin), в котором git также есть (для новых проектов, за редким исключением, всегда использую mercurial). В консоли приходится искать, или отряжать скрипт, чтобы он искал. Если в tortoisegit такой скрипт написали за вас, то это отлично.Привязок у библиотеки ну очень много, вроде все популярные языки с поддержкой вызова C’шных функций есть (не знаю, насколько полные и поддерживаемые). А замены консольному git почему‐то нет, а UI основаны на нём. TortoiseGit вроде имеет настройку «UseLibgit2» (если не ошибаюсь, включена по‐умолчанию), но я как‐то недавно установил tortoisegit, забыв git и он всё равно потребовал git, а не просто заблокировал часть операций, которые libgit2 пока не умеет, вместо этого.
В консоли по‐умолчанию
rebaseидёт на master (точнее, на что‐то настраиваемое, но это «что‐то» — ветка, см. второй абзац раздела «DESCRIPTION»git help rebase). А alias делает именно это: rebase на начало ветки (пока нет слияний, rebase на последнее слияние, если есть). В tortoisegit есть простой способ найти эту точку?А про «сложные вещи»: если консоль непривычна, то сложные вещи будет сделать очень сложно. А как она будет привычна, если используется в основном GUI?