Оформить заказ подкаталоги в Git?

Можно ли проверить подкаталоги репозитория в Git?

Представьте, что я устанавливаю новую установку WordPress. Я создам две новые директории для моего плагина и настройки темы:

• wordpress/wp-content/plugins/myplugins/
• wordpress/wp-content/themes/mytheme/

Я хочу поддерживать эти каталоги через Git. В Subversion я достиг бы этого, имея trunk/myplugins/и trunk/mytheme/каталоги, и проверяя подкаталоги. Есть ли у Git способ выполнить ту же задачу, используя один репозиторий?

Я мог просто пропустить лодку по какой-то парадигме Git, как давний пользователь SVN с небольшим воздействием Git.

Редактировать: несколько ветвей, хранящих различное содержимое, является интересным способом справиться с этим.

Редкие проверки в настоящее время в Git 1.7 .

Также смотрите вопрос « Можно ли сделать редкую проверку без предварительной проверки всего хранилища? ».

Обратите внимание, что для редких проверок по-прежнему требуется загрузить весь репозиторий, даже если некоторые файлы, загружаемые Git, не окажутся в вашем рабочем дереве.

Нет реального способа сделать это в git. И если вы не будете вносить изменения, которые влияют на оба дерева одновременно, как на единую рабочую единицу, нет веской причины использовать один репозиторий для обоих. Я думал, что пропущу эту функцию Subversion, но обнаружил, что создание репозиториев требует очень мало административных умственных затрат (просто из-за того, что репозитории хранятся прямо рядом с их рабочей копией, вместо того, чтобы требовать от меня явного выбора какого-либо места вне рабочая копия), к которой я привык просто делать множество небольших одноцелевых репозиториев.

Однако, если вы настаиваете (или действительно нуждаетесь в этом), вы можете создать git-репозиторий с директориями just mythemeи, mypluginsи ссылками на них из установки WordPress.

MDCore написал:

сделав коммит, например, mytheme увеличит номер ревизии для myplugin

Обратите внимание, что это не имеет значения для git, если вы решите поместить оба каталога в один репозиторий, потому что git полностью устраняет концепцию монотонно увеличивающегося номера ревизии любой формы.

Единственный критерий того, что нужно собрать в один репозиторий в git - это то, является ли он единым целым, т.е. в вашем случае, есть ли изменения, когда нет смысла смотреть на изменения в каждом каталоге изолированно. Если у вас есть изменения, в которых вам нужно отредактировать файлы в обоих каталогах одновременно, и правки принадлежат друг другу, это должен быть один репозиторий. Если нет, то не обманывайте их вместе.

Git действительно хочет, чтобы вы использовали отдельные репозитории для отдельных сущностей.

подмодули

Подмодули не учитывают желание хранить оба каталога в одном репозитории, потому что они фактически навязывают наличие отдельного репозитория для каждого каталога, которые затем объединяются в другом репозитории с использованием подмодулей. Хуже того, поскольку каталоги внутри установки WordPress не являются прямыми подкаталогами одного и того же каталога и также являются частью иерархии со многими другими файлами, использование репозиториев для каждого каталога в качестве подмодулей в объединенном репозитории не принесет никакой пользы, потому что унифицированный репозиторий хранилище не будет отражать какой-либо вариант использования / необходимость.

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

Чтобы обойти эту проблему, нужно клонировать репо в месте, не являющемся моим рабочим пространством, а затем создать символическую ссылку в моем каталоге рабочего пространства на подкаталог в репозитории. Git работает очень хорошо, потому что такие вещи, как git status, будут отображать файлы изменений относительно вашего текущего рабочего каталога.

На самом деле, «узкие», «частичные» или «редкие» извлечения находятся в настоящее время в тяжелой разработке для Git. Обратите внимание, у вас все еще будет полный репозиторий .git. Итак, две другие записи являются текущими для текущего состояния Git, но похоже , что в конечном итоге мы сможем делать редкие проверки. Проверьте списки рассылки, если вы заинтересованы в более подробной информации - они быстро меняются.

git clone --filter из Git 2.19

Эта опция фактически пропускает выборку ненужных объектов с сервера:

git clone --depth 1 --no-checkout --filter=blob:none \
  "file://$(pwd)/server_repo" local_repo
cd local_repo
git checkout master -- mdir/

Сервер должен быть настроен с:

git config --local uploadpack.allowfilter 1
git config --local uploadpack.allowanysha1inwant 1

Начиная с версии v2.19.0 сервер не поддерживается, но его уже можно локально протестировать.

file://$(path)Требуется преодолеть git cloneпротокол shenanigans: Как мелко клонировать локальный репозиторий git с относительным путем?

Помните, что это --depth 1уже подразумевает --single-branch, см. Также: Как мне клонировать одну ветку в Git?

TODO: --filter=blob:noneпропускает все BLOB-объекты, но по-прежнему выбирает все объекты дерева. Но в обычном репо это должно быть крошечным по сравнению с самими файлами, так что это уже достаточно хорошо. На вопрос: https://www.spinics.net/lists/git/msg342006.html Разработчики ответили--filter=tree:0 находится в разработке.

Формат --filterзадокументирован наman git-rev-list .

Для поддержки этой функции было сделано расширение для протокола Git remote.

Документы по дереву Git:

• https://github.com/git/git/blob/v2.19.0/Documentation/technical/partial-clone.txt
• https://github.com/git/git/blob/v2.19.0/Documentation/rev-list-options.txt#L720
• https://github.com/git/git/blob/v2.19.0/t/t5616-partial-clone.sh

Проверьте это

#!/usr/bin/env bash
set -eu

list-objects() (
  git rev-list --all --objects
  echo "master commit SHA: $(git log -1 --format="%H")"
  echo "mybranch commit SHA: $(git log -1 --format="%H")"
  git ls-tree master
  git ls-tree mybranch | grep mybranch
  git ls-tree master~ | grep root
)

# Reproducibility.
export GIT_COMMITTER_NAME='a'
export GIT_COMMITTER_EMAIL='a'
export GIT_AUTHOR_NAME='a'
export GIT_AUTHOR_EMAIL='a'
export GIT_COMMITTER_DATE='2000-01-01T00:00:00+0000'
export GIT_AUTHOR_DATE='2000-01-01T00:00:00+0000'

rm -rf server_repo local_repo
mkdir server_repo
cd server_repo

# Create repo.
git init --quiet
git config --local uploadpack.allowfilter 1
git config --local uploadpack.allowanysha1inwant 1

# First commit.
# Directories present in all branches.
mkdir d1 d2
printf 'd1/a' > ./d1/a
printf 'd1/b' > ./d1/b
printf 'd2/a' > ./d2/a
printf 'd2/b' > ./d2/b
# Present only in root.
mkdir 'root'
printf 'root' > ./root/root
git add .
git commit -m 'root' --quiet

# Second commit only on master.
git rm --quiet -r ./root
mkdir 'master'
printf 'master' > ./master/master
git add .
git commit -m 'master commit' --quiet

# Second commit only on mybranch.
git checkout -b mybranch --quiet master~
git rm --quiet -r ./root
mkdir 'mybranch'
printf 'mybranch' > ./mybranch/mybranch
git add .
git commit -m 'mybranch commit' --quiet

echo "# List and identify all objects"
list-objects
echo

# Restore master.
git checkout --quiet master
cd ..

# Clone. Don't checkout for now, only .git/ dir.
git clone --depth 1 --quiet --no-checkout --filter=blob:none "file://$(pwd)/server_repo" local_repo
cd local_repo

# List missing objects from master.
echo "# Missing objects after --no-checkout"
git rev-list --all --quiet --objects --missing=print
echo

echo "# Git checkout fails without internet"
mv ../server_repo ../server_repo.off
! git checkout master
echo

echo "# Git checkout fetches the missing directory from internet"
mv ../server_repo.off ../server_repo
git checkout master -- d1/
echo

echo "# Missing objects after checking out d1"
git rev-list --all --quiet --objects --missing=print

GitHub upstream .

Выход в Git v2.19:

# List and identify all objects
c6fcdfaf2b1462f809aecdad83a186eeec00f9c1
fc5e97944480982cfc180a6d6634699921ee63ec
7251a83be9a03161acde7b71a8fda9be19f47128
62d67bce3c672fe2b9065f372726a11e57bade7e
b64bf435a3e54c5208a1b70b7bcb0fc627463a75 d1
308150e8fddde043f3dbbb8573abb6af1df96e63 d1/a
f70a17f51b7b30fec48a32e4f19ac15e261fd1a4 d1/b
84de03c312dc741d0f2a66df7b2f168d823e122a d2
0975df9b39e23c15f63db194df7f45c76528bccb d2/a
41484c13520fcbb6e7243a26fdb1fc9405c08520 d2/b
7d5230379e4652f1b1da7ed1e78e0b8253e03ba3 master
8b25206ff90e9432f6f1a8600f87a7bd695a24af master/master
ef29f15c9a7c5417944cc09711b6a9ee51b01d89
19f7a4ca4a038aff89d803f017f76d2b66063043 mybranch
1b671b190e293aa091239b8b5e8c149411d00523 mybranch/mybranch
c3760bb1a0ece87cdbaf9a563c77a45e30a4e30e
a0234da53ec608b54813b4271fbf00ba5318b99f root
93ca1422a8da0a9effc465eccbcb17e23015542d root/root
master commit SHA: fc5e97944480982cfc180a6d6634699921ee63ec
mybranch commit SHA: fc5e97944480982cfc180a6d6634699921ee63ec
040000 tree b64bf435a3e54c5208a1b70b7bcb0fc627463a75    d1
040000 tree 84de03c312dc741d0f2a66df7b2f168d823e122a    d2
040000 tree 7d5230379e4652f1b1da7ed1e78e0b8253e03ba3    master
040000 tree 19f7a4ca4a038aff89d803f017f76d2b66063043    mybranch
040000 tree a0234da53ec608b54813b4271fbf00ba5318b99f    root

# Missing objects after --no-checkout
?f70a17f51b7b30fec48a32e4f19ac15e261fd1a4
?8b25206ff90e9432f6f1a8600f87a7bd695a24af
?41484c13520fcbb6e7243a26fdb1fc9405c08520
?0975df9b39e23c15f63db194df7f45c76528bccb
?308150e8fddde043f3dbbb8573abb6af1df96e63

# Git checkout fails without internet
fatal: '/home/ciro/bak/git/test-git-web-interface/other-test-repos/partial-clone.tmp/server_repo' does not appear to be a git repository
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

# Git checkout fetches the missing directory from internet
remote: Enumerating objects: 1, done.
remote: Counting objects: 100% (1/1), done.
remote: Total 1 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (1/1), 45 bytes | 45.00 KiB/s, done.
remote: Enumerating objects: 1, done.
remote: Counting objects: 100% (1/1), done.
remote: Total 1 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (1/1), 45 bytes | 45.00 KiB/s, done.

# Missing objects after checking out d1
?8b25206ff90e9432f6f1a8600f87a7bd695a24af
?41484c13520fcbb6e7243a26fdb1fc9405c08520
?0975df9b39e23c15f63db194df7f45c76528bccb

Выводы: все капли снаружи d1/ отсутствуют.

Обратите внимание, что root/rootи mybranch/mybranchтакже отсутствуют, но --depth 1скрывает это из списка отсутствующих файлов. Если удалить --depth 1, то они отобразятся в списке отсутствующих файлов.

Как указывает ваше редактирование, вы можете использовать две отдельные ветви для хранения двух отдельных каталогов. Это удерживает их обоих в одном репозитории, но вы по-прежнему не можете иметь коммиты, охватывающие оба дерева каталогов. Если у вас есть изменение в одном, которое требует изменения в другом, вам придется сделать это как две отдельные фиксации, и вы открываете возможность того, что пара проверок двух каталогов может быть не синхронизирована.

Если вы хотите рассматривать пару каталогов как один блок, вы можете использовать «wordpress / wp-content» в качестве корня вашего репозитория и использовать файл .gitignore на верхнем уровне, чтобы игнорировать все, кроме двух подкаталогов, представляющих интерес. Это, наверное, самое разумное решение на данный момент.

Редкие проверки, как утверждается, идут уже два года, но в репозитории git для разработки все еще нет ни признаков, ни каких-либо признаков того, что необходимые изменения когда-либо появятся там. Я бы на них не рассчитывал.

Вы не можете извлечь один каталог из репозитория, потому что весь репозиторий обрабатывается единственной папкой .git в корне проекта вместо множества каталогов .svn в Subversion.

Проблема с работой над плагинами в одном репозитории заключается в том, что при фиксации, например, mytheme, будет увеличиваться номер редакции для myplugin. , поэтому даже в subversion лучше использовать отдельные репозитории.

Парадигма subversion для подпроектов - это svn: externals, что несколько переводит на подмодули в git (но не совсем, если вы уже использовали svn: externals.)

Здесь есть вдохновение. Просто используйте shell regexили git regex.

git checkout commit_id */*.bat  # *.bat in 1-depth subdir exclude current dir, shell regex  
git checkout commit_id '*.bat'  # *.bat in all subdir include current dir, git regex

Используйте кавычки, чтобы избежать интерпретации регулярных выражений оболочки и передать подстановочные знаки в git.

Первый не рекурсивный, только файлы в 1 глубину subdir. Но второй рекурсивен.

Что касается вашей ситуации, следующего может быть достаточно.

git checkout master */*/wp-content/*/*
git checkout master '*/wp-content/*'

Просто взломайте строки как требуется.

Вы можете отменить незафиксированные изменения только для определенного файла или каталога:

git checkout [some_dir|file.txt]