Відмінності між віддаленим оновленням git та завантаженням?

Є git remote updateеквівалент git fetch?

ОНОВЛЕННЯ: додаткова інформація!

Я мав би це зробити з самого початку: я переглянув ноти до випуску Git у репортажі Git Git (так мета!)

grep --color=always -R -C30 fetch Documentation/RelNotes/* | less

Потім я здійснив lessпошук --all, і ось що я знайшов під нотами до випуску для Git версії 1.6.6 :

git fetchвивчені --allта --multipleваріанти, запустити отримання з багатьох сховищ та --pruneможливість видалити гілки віддаленого відстеження, які застаріли. Вони роблять git remote updateі git remote pruneменш необхідним (немає ніякого плану , щоб видалити remote updateні remote prune, хоча).

Версія 1.6.6 була випущена до 23 грудня 2009 року , а Оригінальний афіша поставив своє запитання 6 грудня 2009 року.

Отже, як видно з приміток до випуску, авторам Git було відомо про те, що git remote updateфункціональність команди дещо дублюється git fetch, але вони вирішили не видаляти її, можливо, для зворотної сумісності з існуючими сценаріями та програмами, а може тому, що це просто занадто багато роботи і є пункти з вищим пріоритетом.

Оригінальна відповідь з більш детальною інформацією

Відповіді ксенотеррациду зараз 3,5 роки, і Git пройшов через кілька версій з тих пір (він перейшов від v1.6.5.5 до v.8.8.2 станом на цей текст), і переглянувши поточну документацію для, git remote updateі git fetch, схоже як вони обидва можуть виконувати однакову функцію отримання нових комітетів з декількох віддалених , враховуючи правильні параметри та аргументи.

Отримання всіх видалень

Один із способів отримати кілька віддалених пристроїв - це --allпрапор:

git fetch --all

Це буде отримано з усіх налаштованих вами віддалених програм, якщо ви не remote.<name>.skipFetchAllвстановили для них:

Якщо це правда, цей пульт буде пропущено за замовчуванням під час оновлення за допомогою git-fetch (1) або оновленої підкоманди git-remote (1) . - документація на git-config

Це було б рівнозначно використанню

git remote update

не вказуючи жодної віддаленої групи для отримання, а також не remotes.defaultвстановивши в конфігурації репо, а також, що жодне з ваших віддалених не remote.<name>.skipDefaultUpdateвстановило значення true.

У поточній документації 1.8.3.2 для конфігурації Git не вказаноremotes.default налаштування, але я порадився з Всемогутнім Google щодо цього і знайшов це корисне пояснення від Міслава Мароніча :

$ git config remotes.default 'origin mislav staging'
$ git remote update

# fetches remotes "origin", "mislav", and "staging"

Ви можете визначити список за замовчуванням віддалених даних, які потрібно отримати remote updateкомандою. Це можуть бути віддалені від ваших колег, довірених членів спільноти проекту з відкритим джерелом тощо.

Отже, імовірно, якщо ви remotes.defaultвстановили, і не всі ваші віддалені файли перераховані в ньому, то git remote updateне вдасться отримати всі віддалені, про які ваше репо "знає".

Щодо remote.<name>.skipDefaultUpdateналаштування, документи Git пояснюють це так:

Якщо це правда, цей пульт буде пропущено за замовчуванням під час оновлення за допомогою git-fetch (1) або оновленої підкоманди git-remote (1) .

Отримання визначеної групи пульта

Замість того, щоб отримати всі віддалені, обидва, fetchі remote updateви можете вказати кілька віддалених та груп віддалених для отримання:

git fetch [<options>] <group>
git fetch --multiple [<options>] [(<repository> | <group>)…]

git fetch [<options>] <group>дозволяє отримати декілька віддалених пристроїв, які входять до групи (запозичити ще один приклад у Міслава ):

$ git config remotes.mygroup 'remote1 remote2 ...'
$ git fetch mygroup

git fetch --multipleдозволяє вказати кілька сховищ і груп сховищ, щоб отримати одразу (з документів ):

Дозволити кілька <repository>і <group>аргументи повинні бути вказані. Не <refspec>sможе бути вказано жодне .

Неоднозначність у git remote updateдокументації

Синопсис дляgit remote update специфицирует , що синтаксис команди виглядає наступним чином :

git remote [-v | --verbose] update [-p | --prune] [(<group> | <remote>)…]

Помітьте останню частину [(<group> | <remote>)…],? Дослідні точки ...означають, що за допомогою команди можна вказати кілька груп та віддалених команд, а це означає, що вона поводиться так само, як і git fetch --multiple... бачите, наскільки синтаксис між ними такий подібний?

Однак у цьому ж документі пояснення для updateкоманди нічого не говорить про вказівку декількох групових та віддалених аргументів, лише про те, що це

Вилучити [і] оновлення для названого набору віддалених даних у сховищі, як визначено remotes.<group>.

Тож незрозуміло, чи git remote updateпрацює однаково git fetch --multipleщодо визначення кількох окремих віддалених та декількох віддалених груп.

Отримання єдиного пульта

Нарешті, всі знають простий випадок отримання єдиного пульта:

git fetch <remote>

Можливо, ви також можете використовувати

git remote update <remote>

зробити те ж саме, але, як я вже згадував у попередньому розділі, в документації для git remote updateнезрозуміло, чи можна отримати команду, крім однієї групи віддалених команд.

Обгортка

Як я пояснив, git fetchі git remote updateповодяться аналогічно щодо отримання даних з декількох дистанційних. Вони поділяють подібний синтаксис і аргументи, хоча git fetchвони коротші, тому людям, напевно, легше набирати та користуватися.

Можливо, це git remote updateне може бути використане для отримання лише одного віддаленого пристрою, як git fetch, однак, як я вже зазначив, документація цього не дає зрозуміти.

Убік

Дублювання функціональних можливостей між порцеляновими командами Git, як показано вище git fetchта git remote updateвище, не є унікальним. Я помітив , що подібна ситуація з git rebase --ontoі git cherry-pickв тому , що обидва можуть прийняти ряд фіксацій на патч на нову базу фіксації.

Я здогадуюсь, що в міру того, як Git розвивався протягом багатьох років, деяка функціональність (неминуче?) Дублювалася, можливо, іноді як зручність для кінцевих споживачів (наприклад, простіше пройти діапазон cherry-pick, ніж передавати одну комісію знову і знову вибрати діапазон). Мабуть cherry-pick, не завжди приймався діапазон комітетів , як пояснено в примітках до випуску v1.7.2 :

git cherry-pickнавчився вибирати коло комітетів (наприклад, cherry-pick A..Bта cherry-pick --stdin), так і робив git revert; вони не підтримують приємніший контроль послідовності rebase [-i], хоча.

Так і ні. git remote updateотримує з усіх віддалених, не лише одного.

Не дивлячись на код, щоб побачити, чи remote updateпросто скрипт оболонки (можливий), він, в основному, запускає отримання для кожного віддаленого пристрою. git fetchможе бути набагато більш зернистим.