git log --name-status HEAD ^ .. HEAD показывает предыдущий коммит на mac, но не на Windows?

Question

git log --name-status HEAD ^ .. HEAD показывает предыдущий коммит на mac, но не на Windows?

1

Я делаю dev на моем mac, но у меня есть виртуальная машина Windows, в которой я запускаю некоторые сборки. Это довольно просто. У меня Дженкинс тянет и строит приложение ежедневно.

В этом скрипте есть некоторые метаданные, которые мне нужно получить. Мне нужно получить список ветвей на сервере git, и если он имеет (поскольку ветка может не совершать), то последние метаданные коммита. В частности, отправители электронной почты.

В общем, на моем mac это было что-то простое:

git branch --all > branches
for b in $(cat branches);
do
  git checkout $b
  git log --name-status HEAD^..HEAD | grep Author | cut -d"<" -f2 | cut -d">" -f1 > email
  echo $b > branch
  python buildScript.py $(cat email) $(cat branch)
  ; done
rm email branch
mv branches old_branches

Я заметил, что проблема:

При новом притяжении ветки git log --name-status показывает фиксации, но HEAD ^.. HEAD не возвращал результатов.
grep не является допустимым cmd в окнах Cmd Prompt.
cut не является допустимым cmd в окнах Cmd Prompt.

Я могу найти grep и сократить альтернативы.

может кто-нибудь объяснить, почему коммиты не появятся в Windows? Есть ли встроенная в Python утилита, которая может обрабатывать все это? У меня нет проблем с запуском прямого bash, но я думаю, что python может быть более чистым, так как я уже запускаю скрипт python для сборки...

Изменить. Мое конечное состояние - это скрипт bash (или скрипт python), который будет делать следующее:

loop over all branches.
if branch is new since the last time the script was run, and has at least 1 commit
   run_a_python_script with the committers email and that branch.
else if there were deleted branches since the last time it was run:
   run_another_python_script with the branch
else
   nothing happens because this script already ran once.

У меня этот набор на 10-минутном интервале cron.

Это легко сделать в Python OR Bash.

Fallenreaper 09 июль 2018, в 21:19

Источник

0

Если вы используете Windows CMD.EXE, обратите внимание , что ^ специальный символа есть (Google поиск предполагает , что это приводит следующий символ путь \ делает в ш / Баше) , так что HEAD^..HEAD результаты в Git видящего HEAD..HEAD , Хотя есть лучший способ сделать все это.
torek 09 июль 2018, в 19:09
0

Я собираюсь добавить быстрое редактирование желаемого конечного состояния
Fallenreaper 09 июль 2018, в 19:10

Теги:

python

windows

git

1 ответ

Ещё вопросы

Если вы используете Windows CMD.EXE, обратите внимание , что ^ специальный символа есть (Google поиск предполагает , что это приводит следующий символ путь \ делает в ш / Баше) , так что HEAD^..HEAD результаты в Git видящего HEAD..HEAD , Хотя есть лучший способ сделать все это.
Я собираюсь добавить быстрое редактирование желаемого конечного состояния

torek · Accepted Answer · 2018-07-09T17-51-00.000Z

Вот общий рецепт, реализуемый в Python через subprocess.Popen или в sh/bash очевидным образом.

loop over all branches

Используйте git for-each-ref. Если вы находитесь на сервере с веткими, это git for-each-ref refs/heads; если вы находитесь на клиенте, который имеет ветки, переименованные в имена удаленных отслеживаний (origin/master и т.д.), это git for-each-ref refs/remotes/origin. Используйте директивы форматирования for-each-ref для получения соответствующего короткого имени, если хотите (но обратите внимание на шестиэтапный процесс поиска в документации gitrevisions и убедитесь, что краткое имя будет искать соответствующий хеш- файл, как правило, более умный в сценариях чтобы сохранить полное имя как можно дольше, передавая его дополнительным скриптам, которые аналогичным образом понимают этот шаблон, чтобы вы не обнаружили хеш фиксации для тега с именем xyz когда есть ветвь с именем xyz).

(Если вы используете библиотеку Python, у нее, вероятно, есть итератор по ссылкам, который работает аналогично git for-each-ref.)

if branch is new since the last time the script was run, and has at least 1 commit

По определению ветвь Git не может существовать, не имея хотя бы одной фиксации на ней. Причина в том, что имя ветки - это просто имя для одного (1) кода хеширования commit.

Конечно, "новый с момента последнего запуска" требует какой-то памяти.

   run_a_python_script with the committers email and that branch.

Учитывая ссылочное имя $ref, чтобы найти электронное письмо для автора (это то, что вы делаете в исходном коде):

git log --no-walk --pretty=format:%ae $ref

Чтобы найти электронную почту для примечания коммиттера, каждая фиксация имеет отдельный "автор" и "коммиттер", хотя в большинстве случаев они обычно одинаковы - используйте %ce вместо %ae.

Если ссылка имеет форму refs/heads/name, ветвь имеет имя name; если он имеет форму refs/remotes/origin/name, ветка имеет имя name. Формат %(refname:short) в git for-each-ref будет %(refname:short) git for-each-ref refs/heads/ или refs/remotes/ part, но, как отмечалось ранее, это может быть неразумно делать слишком рано. Если скрипт Python может обрабатывать полное имя ссылки, это было бы лучше.

else if there were deleted branches since the last time it was run:

Это также требует памяти и некоторого способа выполнения вычитания (сохраненный набор ссылок минус текущий набор ссылок равен удаленной установке). Память в сценариях оболочки означает внешний файл; памяти в коде Python также может быть внешний файл, используя pickle или JSon форматирования или любой другой.

  run_another_python_script with the branch
else
   nothing happens because this script already ran once.

Согласитесь, я думал сохранить со временем 1 файл для сохранения предыдущей информации в течение итераций. Единственное, о чем я могу думать, это то, что при использовании BitBucket, например, для создания новой ветви, я смотрел на ветку и предыдущую коммит на самом деле будет из ствола, из которого вышла ветка. Есть ли способ сказать, заставить человека, который создал эту ветку в Bitbucket, ИЛИ подождать, пока не будет хотя бы 1 выделенного коммита? В идеале код, с которым я работаю, запускает скрипты, основанные на ветке, но присылает письмо авторам. (У каждого филиала есть 1 владелец для моей команды).
Сам Git не придает никакого значения именам ветвей (они просто идентифицируют тот единственный коммит, который они идентифицируют), поэтому все, что вы здесь делаете, будет чисто вашей собственной конструкцией. Поэтому вы можете делать все, что захотите, но заставить ваших пользователей соответствовать вашим ограничениям может оказаться затруднительным. :-) Обратите внимание, что если вы обновляете свой собственный клон на основе какой-либо версии, которую вы рассматриваете как источник правды (например, версию на Bitbucket), вы всегда можете обнаружить добавленные коммиты и удаленные коммиты, но вы не можете точно сказать, кто добавил и удалил их, вы можете только смотреть на содержание.
Любой может подтолкнуть чьи-либо коммиты или сделать коммит, утверждая, что он является кем-то другим, поэтому сам контент не является чем-то, чем вы можете доверять. Это возвращает вас к тому, чтобы «заставить ваших пользователей соответствовать вашим ограничениям». Если вы управляете сервером , который обеспечивает этот источник истины, однако, вы можете контролировать , кто может нажать на сервер, и делать все проверки вам нравится в то время.
ААА, хорошо. Я думаю, что поскольку все мы настроили git с нашими именами и адресами электронной почты, соответствующая машина добавит его в коммит, можно подумать. Вот как мы определяем собственность. В то время как кто-либо МОЖЕТ взять на себя обязательства в этой ветке, мы в значительной степени используем их в качестве самостоятельной разработки для задачи. Задача просто имеет отношения 1-1 с разработчиком. Таким образом, до тех пор, пока создается ветка, первый созданный в ней коммит будет владельцем. Кажется, однако, что при создании ветки скажем, от master, до коммита, который он сделал для этой ветки, он все еще указывает на этот коммит
Да, я понимаю, что предыдущий коммит в этом отношении все еще принадлежит этой ветви, но я думал о том, как: точка, в которой ветвь становится как +1 впереди мастера. Имеет ли это смысл? Это возможно?
Хорошо, учтите, что я могу сделать: git push origin <hash>:branch чтобы создать branch имени на сервере в origin , указывая на любой произвольный существующий коммит по его хеш-идентификатору. Если имя уже существует, я могу сделать git push -f origin <hash>:branch чтобы произвольно изменить его, чтобы указать на любой существующий коммит по идентификатору хэша. Таким образом, ваше предположение, что имена ветвей появляются, указывая на некоторую существующую фиксацию, достижимую из кончика master , и затем продвигаются вперед, не обязательно так!
Что вы можете сделать, это определить, доступен ли коммит, на который в данный момент указывают некоторые имена, от master - и, сохраняя память о том, какие имена ветвей существовали до этого, и какие коммиты были доступны из этих коммитов с ветвлением до того, вы может наблюдать, перемещалось ли имя ветви «вперед» или «назад» (принудительное нажатие, чтобы удалить фиксации), или оба одновременно. То, что вы не знаете, это то, что произошло между вашими двумя наблюдениями, если что-то на самом деле произошло между ними.