Простими словами git pull спочатку робить git fetch а потім git merge.

git pull

Виконується дві операції в одній команді. Спочатку завантажуються всі зміни які є на сервері, після чого ці зміни об'єднуються з локальною гілкою.

git fetch

Ця команда лише завантажує зміни, але не об'єднує їх з локальними гілками.

Скасувати останній коміт можна командою

git reset HEAD~

Ця команда видалить останній коміт, але залише всі зміни які були в цьому коміті.

Якщо також треба видалити всі зміни, що були зроблені в цьому коміті, тоді використовуйте прапор --hard

git reset HEAD~ --hard

git reset - ця команда відповідає за скасування коміту. За допомогою параметру HEAD вказується які саме коміти необхідно скасувати

• HEAD - посилання на поточний коміт
• HEAD~1 - посилання на 1 попередній коміт
• HEAD~ те саме що і HEAD~1
• HEAD~87 посилання на 87 попередніх комітів

Виправити помилку можна наступним чином

1. Необхідно встановити пакет guzzlehttp/psr7

composer require guzzlehttp/psr7

2. Далі в composer.json міняємо версію з "guzzlehttp/psr7": "^2.0", на "guzzlehttp/psr7": "^1.5"
3. Оновлюємо пакети командою

composer update

4. Після чого зможемо успішно встановити пакет paquettg/php-html-parser командою

composer require paquettg/php-html-parser

В perl6 це можна зробити ось так

perl6 -e 'print(%*ENV<SHELL>,"\n")'

Це можна обійти якщо виконати команду:

$ sudo apparmor_parser -r /etc/apparmor.d/*snap-confine*

Це зробить запуск snap-confine "обмеженим" і snap програми будуть запускатися. Якщо помилка виникне знову, цю команду необхідно буде виконати повторно.

Функція описується так:

тип_що_повертається им'я_функції([тип1 аргумент1 [, тип2 аргумент2] ...)

Так що

const double * f2(const double * ar, int n);

const double * - тип який повертається, f2 - ім'я функції, const double * - тип першого аргументу ar, int- тип другого аргументу n.

Так зрозуміліше?

На друге питання - "прототип" і визначення повинні збігатися (крім, хіба що, імен аргументів), так що * потрібна точно так же, щоб вказувати тип який повертається.

Покажчик на функцію даного типу буде мати вигляд

const double * (* func_ptr)(const double *, int);

Виконайте наступне:

grep -rnw '/path/to/somewhere/' -e 'pattern'

• -r або -R - рекурсивний пошук,
• -n - вивести номер рядка
• -w пошук цілого слова.
• -l (нижній регістр L) можна додати, щоб просто вказати ім'я відповідного файлу.

Також можна використовувати, --exclude, --include, --exclude-dir. Ці прапори можуть бути використані для ефективного пошуку:

Ця команда буде здійснювати пошук лише у тих файлах з розширенням .c або .h:

grep --include=\*.{c,h} -rnw '/path/to/somewhere/' -e "pattern"

Ця команда виконає пошук у всіх файлах, за виключенням тих що закінчуються розширенням .o:

grep --exclude=\*.o -rnw '/path/to/somewhere/' -e "pattern"

Для каталогів можна виключити один або кілька каталогів за допомогою параметра --exclude-dir. Наприклад, ця команда виключить директорії dir1/, dir2/ а також ті що відповідають *.dst/:

grep --exclude-dir={dir1,dir2,*.dst} -rnw '/path/to/somewhere/' -e "pattern"

Для отримання додаткових опцій перевірте man grep.

Нехай ви хочете склеїти останні три коміти (для 13-ти комітів процес виглядає аналогічно). Для цього є відмінний метод з використанням git rebase. Ця команда дозволяє змінювати історію комітів. Алгоритм роботи виглядає наступним чином:

1. Зробіть резервну копію. Це зовсім не обов'язково, але допоможе зберегти нервові клітини, якщо щось піде не так. варіанти:

• Копія каталогу з файлами в якому розгорнуто git репозиторій.
• git branch backup або git tag backup в останньому коміті.
• Прочитати довідку по командам reflog і reset і перевірити, що бекапи вже є.

2. Позбавтеся від незакомічених змін ( git add + git commit або git stash або щось ще).
3. Виконайте git rebase -i HEAD~3. У відповідь на це ви отримаєте "діалог" (вікно редагування файлу) виду:

pick bcdca61 Second commit
pick 4643a5f The third commit with cool stuff
pick e0ca8b9 The last commit

 #  Rebase 48411de..e0ca8b9 onto 48411de
 #
 #  Commands:
 #  p, pick = use commit
 #  r, reword = use commit, but edit the commit message
 #  e, edit = use commit, but stop for amending
 #  s, squash = use commit, but meld into previous commit
 #  f, fixup = like "squash", but discard this commit's log message
 #  x, exec = run command (the rest of the line) using shell

при цьому, коміти вказані в порядку зростання часу створення (найнижчий - найсвіжіший).

4. В "діалозі" з вам потрібно замінити pick на squash для двох найсвіжіших комітів (два нижні рядки). В наведеному вище прикладі, це повинно виглядати ось так:

pick bcdca61 Second commit
squash 4643a5f The third commit with cool stuff
squash e0ca8b9 The last commit

 #  Rebase 48411de..e0ca8b9 onto 48411de
 #
 #...

Після цього ви повинні закрити цей "діалог" (зберегти редагований файл). Якщо для роботи з git використовується vi (за замовчуванням), то це робиться послідовним натисканням ESC, введенням :wq і натисненням Enter.

5. У наступному "діалозі" вам запропонують вказати заголовок для отриманого коміту.

У PHP починаючи з версії 5.4.0 з'явився прапор JSON_UNESCAPED_UNICODEі все стало набагато простіше:

json_encode($array, JSON_UNESCAPED_UNICODE);

Проблема лежить в області забезпечення зворотної сумісності.

Подивіться, будь-яку новий мову програмування - наприклад Паскаль, не кажучи вже про Java або C # - не потребують заголовних файлах. Без сумніву, C++ теж міг би обійтися без них. У чому ж справа?

Перенесемося на півстоліття назад, в 1972 рік. Уявімо собі компілятор мови C.

Припустимо, ми хочемо написати дизайн компілятора. Ми не можемо скомпілювати всю програму за раз, у нас на це просто не вистачить пам'яті. Комп'ютери тоді були маленькими і повільними. Ми хочемо компілювати програму по шматочках, по кілька функцій за раз.

У нас відразу ж виникає проблема: як скомпілювати функцію f, яка посилається на іншу функцію g? Нам потрібно окремий опис інших функцій. Ми могли б, звичайно, прочитати всі вихідні файли, для початку з'ясувати, які функції у нас є, і потім прочитати їх вдруге і скомпілювати один за одним. Але це було занадто складно і повільно, потрібно було парсити визначення функцій двічі, і один раз викидати результат! Це неприпустима витрата процесорного часу! Плюс, якщо тримати в пам'яті визначення всіх функцій, може знову-таки не вистачити пам'яті.

На кого Денніс вирішив покласти складну проблему відділення опису функції від її реалізації, і підключення тільки потрібних описів при компіляції даної функції? На нас, програмістів. Він вирішив, що ми повинні самі допомогти компілятору і скопіювати визначення функцій в окремий файл, і самі вказати компілятору, які файли з визначеннями потрібні. (Тобто перший крок компіляції покладається на нас.)

Це радикально спростило компілятор, але привело в свою чергу до проблем. Що буде, якщо ми забули підключити потрібні заголовки? Відповідь: помилка компіляції. Що буде, якщо зміст тексту заголовки змінюється в залежності від якого-небудь макросу? Відповідь: компілятор «тупий», і не намагається детектувати цю проблему, він перекладає відповідальність на нас.

На момент розробки мови це було правильне рішення. Компілятор виявився практичним, швидким, і програмісти були не проти допомогти компіляції. Ну і якщо хто припускався помилки, сам був винен.

Перемотати стрілки годинника в 1983 рік. Бьярн створює C++. Він вирішив злетіти на хвилі популярності мови C, і перейняв модель компіляції C з окремими translation unit'ами та пов'язаними з цим проблемами прямо з C. Втім, перші версії C++ були просто препроцесором мови C! Тому проблеми роздільної компіляції перекочували з C в C++. Більше того, додалися нові проблеми. Наприклад, шаблони класів виглядають як класи, але не генерують об'єктного коду самі по собі, тому для них доводиться йти на хитрощі і обходити недоліки системи роздільної компіляції (наприклад, включенням реалізації в header і трюками компоновщика).

А далі вступила в гру зворотна сумісність. Зараз, в 2017 році, ми маємо так багато коду, написаного в стилі «з заголовками», і так багато коду виходить з різних тонкощів, пов'язаних з цим, що міняти парадигму вже пізно, поїзд практично поїхав.

Втім, існує проект модульної системи в C++, який повинен допомогти програмістам позбутися спадщини півстолітньої давності. Він ще не реалізований, і в ньому є складнощі рівня дизайну (наприклад, в header'і був визначений макрос, чи буде його видно, якщо ми перейдемо від header'ів до модулів?) Сподіваюся, в майбутньому розробники мови таки зможуть побороти проблему зворотної сумісності.

import itertools

x, y, z = 2, 4, 12

for num in itertools.permutations([x, y, z]):
    print(num)
		```

Поки що так. Відвідувачів на сайті ще не дуже багато, треба з чогось починати :)