Git для пользователей Perforce

86

Я использую Perforce несколько лет. Я хотел бы переключиться на использование git для моего личного кода, но все учебные пособия по git, которые я видел, либо предполагают, что у вас есть полный исходный контроль n00b (что делает их невероятно утомительными), либо что вы привыкли к svn (а я не такой).

Я знаю p4, и я также понимаю идею распределенной системы управления исходным кодом (так что мне не нужна реклама, спасибо). Что мне нужно, так это таблица перевода из команды p4 в эквивалентные команды git, а также команды «не могу жить без», у которых нет эквивалента p4.

Поскольку я подозреваю, что каждый пользователь p4 использует другое подмножество p4, вот некоторые из вещей, которые я регулярно делаю в p4, которые я хотел бы делать в git, которые не сразу очевидны из документов, которые я просмотрел. :

  1. создать несколько ожидающих списков изменений в одном клиенте. ( p4 change)
  2. редактировать ожидающий список изменений. (также p4 change)
  3. просмотреть список всех ожидающих меня списков изменений ( p4 changes -s pending)
  4. список всех измененных файлов в моем клиенте ( p4 opened) или в списке ожидающих изменений ( p4 describe)
  5. увидеть разницу в ожидающем списке изменений (я использую для этого сценарий-оболочку, который использует p4 diffи p4 describe)
  6. для данного файла посмотрите, какие отправленные списки изменений повлияли на какие строки ( p4 annotate)
  7. для данного файла см. список описаний списков изменений, которые повлияли на файл ( p4 log)
  8. отправить ожидающий список изменений ( p4 submit -c)
  9. прервать отложенный список изменений ( p4 revert)

Многие из них вращаются вокруг «списков изменений». "список изменений" - это терминология p4. Что такое термин, эквивалентный git?

Похоже, что ветки могут быть тем, что пользователи git используют вместо того, что p4 вызывает списки изменений. Немного сбивает с толку, поскольку в p4 также есть что-то, называемое ветвью, хотя они, похоже, лишь смутно связаны между собой. (Хотя мне всегда казалось, что концепция ветки в p4 довольно странная, она опять же отличается от классической концепции RCS ветки.)

В любом случае ... Я не уверен, как выполнить то, что я обычно делаю в списках изменений p4 с ветками git. В p4 я могу сделать что-то вроде этого:

$ p4 edit a.txt
$ p4 change a.txt
Change 12345 created.

На данный момент у меня есть список изменений, содержащий a.txt. Я могу отредактировать описание и продолжить работу, не отправляя список изменений. Кроме того, если окажется, что мне нужно внести некоторые изменения в некоторые другие файлы, например, исправить ошибку в каком-то другом слое кода, я могу сделать это в том же клиенте:

$ p4 edit z.txt
$ p4 change z.txt
Change 12346 created.

Теперь у меня есть два отдельных списка изменений в одном клиенте. Я могу работать над ними одновременно, и мне не нужно ничего делать, чтобы «переключаться между ними». Когда приходит время коммитить, я могу отправить их отдельно:

$ p4 submit -c 12346  # this will submit the changes to z.txt
$ p4 submit -c 12345  # this will submit the changes to a.txt

Я не могу понять, как воспроизвести это в git. Судя по моим экспериментам, он не git addсвязан с текущей веткой. Насколько я могу судить, когда я git commitсобираюсь зафиксировать все файлы, которые я git addсоздал, независимо от того, в какой ветке я был в то время:

$ git init
Initialized empty Git repository in /home/laurence/git-playground/.git/
$ ls
a.txt  w.txt  z.txt
$ git add -A .
$ git commit
 Initial commit.
 3 files changed, 3 insertions(+), 0 deletions(-)
 create mode 100644 a.txt
 create mode 100644 w.txt
 create mode 100644 z.txt
$ vi a.txt z.txt 
2 files to edit
$ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   a.txt
#   modified:   z.txt
#
no changes added to commit (use "git add" and/or "git commit -a")
$ git branch aardvark
$ git checkout aardvark
M   a.txt
M   z.txt
Switched to branch 'aardvark'
$ git add a.txt 
$ git checkout master
M   a.txt
M   z.txt
Switched to branch 'master'
$ git branch zebra
$ git checkout zebra
M   a.txt
M   z.txt
Switched to branch 'zebra'
$ git add z.txt 
$ git status
# On branch zebra
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   modified:   a.txt
#   modified:   z.txt
#
$ git checkout aardvark
M   a.txt
M   z.txt
Switched to branch 'aardvark'
$ git status
# On branch aardvark
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   modified:   a.txt
#   modified:   z.txt

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

git perforce Лоуренс Гонсалвес
источник
2
Вы можете просто использовать perforce для своего личного кода, предполагая, что 5 бесплатных клиентов достаточно.
Логан Капальдо,
3
Я этим и занимался, но хотел бы переключиться на что-то с открытым исходным кодом, которое также используется проектами с открытым исходным кодом. Я рассматривал и git, и Mercurial. Я склонялся к git, потому что он, кажется, более активен.
Лоуренс Гонсалвес,
1
Вам лучше изучить Git с нуля. Рабочий процесс, предписанный Git, сильно отличается от рабочего процесса, предписанного Perforce. Переведенные рабочие процессы будут неудобными, а попытка уравнять функции затруднит ваше понимание. К счастью, сообщество Git предлагает множество документации для начинающих, например. git-scm.com/book
Colonel Panic
1
@ColonelPanic Я понимаю вашу точку зрения, но проблема с такой документацией заключается в том, что она тратит время на объяснение основных вещей, которые каждый пользователь Perforce уже знает. Чтение такой документации так же раздражает, как попытка прочитать учебник по другому языку программирования, в котором глава объясняет, что такое переменные.
Лоуренс Гонсалвес,
@ColonelPanic Тем не менее, я прочитал и другую документацию по git, включая Git From the Bottom Up и Git для компьютерных ученых , которые на самом деле были весьма полезны. Я использую Git уже несколько лет (обратите внимание, когда изначально был задан этот вопрос), и мне кажется, что основные проблемы с изучением git заключаются не в отсутствии документации, а в плохой номенклатуре, внутренней несогласованности, сильно перегруженных командах и некоторых незавершенные детали, которые не готовы к использованию. Мне бы хотелось, чтобы кто-нибудь пошел и убрал весь мусор, но это разозлило бы тех, кто к этому привык.
Лоуренс Гонсалвес,

Ответы:

72

Я не слишком много использовал принудительно, поэтому это может быть не совсем перевод 1: 1. С другой стороны, распределенные системы управления исходным кодом, такие как git и mercurial, в любом случае имеют другой рабочий процесс, поэтому на самом деле нет (и не должно быть) перевода 1: 1. Во всяком случае, вот идет:

  • Создайте несколько ожидающих списков изменений -> Вместо этого используйте ветки. В git ветки легкие и быстрые, на их создание уходит меньше секунды, а на слияние обычно меньше двух секунд. Не бойтесь частого ветвления и перестановки.

    git branch new-branch-name
git checkout new-branch-name

    Или сделайте все в одной строке:

    git checkout -b new-branch-name

  • См. Список всех ожидающих списков изменений -> Поскольку эквивалентом нескольких ожидающих списков изменений является несколько веток, просто просмотрите ветки:

    git branch

    Если вы хотите также просмотреть удаленные ветки:

    git branch -a

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

  • Список всех измененных файлов -> Для одного ожидающего «списка изменений» в определенной ветке git имеет понятие индекса или кеша. Чтобы зафиксировать изменение, вы должны сначала добавить файлы в этот индекс. Это позволяет вам вручную выбрать, какая группа файлов представляет собой одно изменение, или игнорировать нерелевантные файлы. Чтобы узнать, какие файлы добавлены или нет в этот индекс, просто выполните:

    git status

  • См. Различие ожидающего списка изменений -> Это состоит из двух частей. Сначала, чтобы увидеть разницу между рабочим каталогом и индексом:

    git diff

    Но если вы хотите знать разницу между тем, что вы вводите сейчас, и последней фиксацией, тогда вы действительно запрашиваете разницу между рабочим каталогом + index и HEAD:

    git diff HEAD

  • Для данного файла посмотрите, какие отправленные списки изменений повлияли на какие строки -> Это просто:

    git blame filename

    или даже лучше, если вы находитесь в оконной среде:

    git gui blame filename

    Git gui занимает больше времени для синтаксического анализа файла (он был написан на tcl вместо C), но у него есть множество полезных функций, включая возможность «путешествовать во времени» назад в прошлое, щелкнув идентификатор фиксации. Я только хотел бы, чтобы они реализовали функцию "путешествия во времени" в будущее, чтобы я мог узнать, как в конечном итоге будет решена данная ошибка ;-)

  • Для данного файла просмотрите список описаний списков изменений, которые повлияли на этот файл -> также просто:

    git log filename

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

  • Отправить ожидающий список изменений -> Также просто:

    git commit

См. Мой ответ на предыдущий вопрос, чтобы увидеть мой типичный рабочий процесс с git: изучение Git. Нужно знать, на правильном ли я пути

Если вы будете следовать описанному мною рабочему процессу, то вы обнаружите, что такие инструменты, как gitk, будут гораздо более ценными, поскольку он позволяет четко видеть группы изменений.

Дополнительный ответ:

Git очень гибкий, и есть несколько способов делать то, что вы описываете. Следует помнить, что всегда нужно начинать новую ветку для каждой функции, над которой вы работаете. Это означает, что основная ветка не затрагивается, поэтому вы всегда можете вернуться к ней, чтобы исправить ошибки. Работу в git почти всегда следует начинать с:

git checkout -b new-feature-a

Теперь вы можете редактировать файл a.txt. Чтобы одновременно работать над другой функцией, выполните:

git checkout master
git checkout -b new-feature-z

Теперь вы можете редактировать файл z.txt. Чтобы вернуться к a.txt:

git checkout new-feature-a

Но подождите, есть изменения в new-feature-z, и git не позволит вам переключать ветки. На данный момент у вас есть два варианта. Первый самый простой, зафиксируйте все изменения в текущей ветке:

git add .
git commit
git checkout new-feature-a

Это то, что я рекомендую. Но если вы действительно не готовы зафиксировать код, вы можете временно спрятать его:

git stash

Теперь вы можете переключиться на ветку new-feature-a. Чтобы вернуться к коду, над которым вы работали, просто откройте тайник:

git checkout new-feature-z
git stash pop

Когда все будет готово, объедините все изменения в master:

git merge --no-ff new-feature-a
git merge --no-ff new-feature-z

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

Вот еще один пример общего использования веток в git, который вы не видите в других инструментах управления версиями (кроме, возможно, Mercurial):

Необходимо постоянно изменять файлы конфигурации, чтобы они отражали среду разработки? Затем используйте ветку:

git checkout -b dev-config

Теперь отредактируйте свои файлы конфигурации в любимом редакторе, а затем зафиксируйте изменения:

git add .
git commit

Теперь каждая новая ветка может начинаться с ветки dev-config вместо master:

git checkout dev-config
git checkout -b new-feature-branch

Как только вы закончите, удалите правки в dev-config из new-feature-branch с помощью интерактивной перебазировки:

git rebase -i master

Удалите ненужные коммиты и сохраните. Теперь у вас есть чистая ветка без пользовательских правок конфигурации. Время слиться с мастером:

git checkout master
git merge --no-ff new-feature-branch
# because master have changed, it's a good idea to rebase dev-config:
git checkout dev-config
git rebase master

Следует отметить, что удаление правок git rebase -iработает даже тогда, когда все изменения происходят в одном файле. Git запоминает изменения, а не содержимое файла *.

* примечание: на самом деле технически не совсем верно, но как пользователь это чувствует

Дополнительный ответ:

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

Во-первых, несколько слов о влиянии дешевых ветвлений и изменяемой истории на ваш рабочий процесс. Когда я использовал CVS и SVN, я всегда немного сопротивлялся фиксации. Это потому, что коммит нестабильного кода неизбежно испортит рабочий код других людей. Но с git я избавился от этого страха. Это потому, что в git другие люди не получат мои изменения, пока я не объединю их в master. Итак, теперь я фиксирую код каждые 5 строк, которые пишу. Чтобы совершить что-то, вам не нужно совершенное предвидение. Вам просто нужно изменить свое мышление: commit-to-branch == add-to-changeset, merge-to-master == commit-changeset.

Итак, вернемся к примерам. Вот как бы я это сделал. Скажем, у вас есть ветка, new-feature-zи вы хотите ее протестировать new-feature-a. Я бы просто создал новую ветку для проверки:

# assume we are currently in branch new-feature-z
# branch off this branch for testing
git checkout -b feature-z-and-feature-a
# now temporarily merge new-feature-a
git merge --no-ff new-feature-a

Теперь можно протестировать. Если вам нужно что-то изменить, чтобы функция feature-z работала с feature-a, сделайте это. В таком случае вы можете объединить изменения в соответствующую ветку. Используйте git rebase -iдля удаления несущественных изменений из слияния.

В качестве альтернативы вы также можете использовать git rebase, чтобы временно изменить базу new-feature-z, чтобы указать на new-feature-a:

# assume we are currently in branch new-feature-z
git rebase new-feature-a

Теперь история веток изменена так, что new-feature-z будет основываться на new-feature-a, а не на master. Теперь можно протестировать. Любые изменения, внесенные в эту ветку, будут принадлежать ветке new-feature-z. Если вам нужно изменить new-feature-a, просто вернитесь к нему и переустановите, чтобы получить новые изменения:

git checkout new-feature-a
# edit code, add, commit etc..
git checkout new-feature-z
git rebase new-feature-a
# now new-feature-z will contain new changes from new-feature-a

Когда вы закончите, просто вернитесь к master, чтобы удалить изменения из new-feature-a:

# assume we are currently in branch new-feature-z
git rebase master

Не бойтесь начинать новую ветку. Не бойтесь открывать одноразовую ветку. Не бойтесь выбрасывать ветки. И поскольку merge == submit и commit == add-to-changeset, не бойтесь часто коммитить. Помните, что коммит - это лучший инструмент для отмены действий разработчика.

Да, и еще одна вещь, в git удаленные ветки все еще существуют в вашем репозитории. Так что, если вы случайно удалили что-то, что, как вы позже понимаете, полезно, вы всегда можете вернуть это, выполнив поиск в истории. Так что не бойтесь выбрасывать ветки.

слебетман
источник
1
Имеет ли каждая ветвь свой собственный «индекс» или существует ли общий индекс между ветвями? Мой эксперимент, кажется, предлагает последнее, но вы говорите, что «конкретная ветка git имеет концепцию индекса или кеша», что предполагает первое.
Лоуренс Гонсалвес,
4
Это другой инструмент. Вам нужен другой рабочий процесс, и при этом другой образ мышления и другие привычки. Никакой мерзавец не работает так, как вы описываете. Это ветки и ничего больше. Но есть очень мощные инструменты для работы с ветвями. Я предлагаю вам считать себя новичком, который ничего не знает о системе управления версиями, и прочитать базовые руководства. Считайте свое нынешнее мышление "дурной привычкой", против которой вас нужно перевоспитывать в git-land. Извините ..
slebetman
1
Итак, что вы делаете в git, когда у вас есть две вещи, над которыми вы хотите работать одновременно (и в одном и том же месте, чтобы вы могли тестировать незафиксированные изменения друг против друга), но вы хотите зафиксировать их отдельно? Кроме того, как вы можете отредактировать сообщение фиксации перед выполнением фиксации? Я могу согласиться с тем, что рабочий процесс отличается, но вы не сказали, что такое рабочий процесс, эквивалентный git. Сказать, что это вредные привычки, ужасно похоже на попытку выдать ошибку за функцию.
Лоуренс Гонсалвес,
2
Прочтите мой обновленный ответ. Вы все еще думаете о незафиксированных изменениях, тогда как вам следует думать о несвязанных ветвях.
slebetman
2
Очень обширный ответ. В какой момент это нужно викифицировать?
Тим Клемонс
1

У меня недостаточно опыта работы с p4, чтобы создать настоящую шпаргалку, но есть по крайней мере некоторые сходства, к которым можно вернуться. «Набор изменений» p4 - это git «commit».

Изменения в вашем локальном рабочем пространстве добавляются в «индекс» с помощью git add, а затем индекс фиксируется с помощью git commit. Таким образом, индекс - это ваш ожидающий список изменений для всех намерений и целей.

Вы смотрите на изменения с помощью git diffи git status, где git diffобычно отображаются изменения между рабочей областью и индексом, но git diff --cachedотображаются изменения между индексом и репозиторием (= ваш ожидающий список изменений).

Для получения более подробной информации я рекомендую http://progit.org/book/ . Поскольку вы в целом разбираетесь в управлении версиями, вы, вероятно, можете просмотреть большую его часть и извлечь информацию, специфичную для git ...

Якоб Борг
источник
1
Я бы не согласился с тем, что «набор изменений p4 - это git commit»; это самые близкие эквиваленты, правда, но набор изменений p4 намного ближе к набору коммитов git. Набор изменений p4 представляет функцию, тогда как ветка git представляет функцию.
RJFalconer
@RJFalconer Erm. "Ветка" - это тоже ветка в Perforce, не так ли? А «набор изменений» - это атомарный набор изменений в одном или нескольких файлах, очень похожий на коммит? Если нет, что бы вы сказали, что это эквивалент фиксации p4?
Якоб Борг
Я бы сказал, что p4 не имеет эквивалента просто потому, что степень атомарности не одинакова; в git я могу внести несколько изменений в данный файл, а затем зафиксировать их в разных коммитах (git add -p), тем самым отделяя рефакторинг / очистку в истории от исправления функции / ошибки. Если бы я сделал это в p4, мне пришлось бы разрабатывать их по отдельности. Даже в этом случае мои коммиты могут не быть непрерывными, поскольку другие разработчики могут отправлять их между ними (если я не являюсь частной веткой, которая включает в себя зачастую непрактичное дублирование на диске).
RJFalconer
Отказ от ответственности: я использовал p4 всего несколько месяцев, и вполне возможно, что в нем есть какая-то функция, которая выполняет это, я просто еще не встречал.
RJFalconer
Списки изменений p4 и ветки p4 логически такие же, как коммиты git и ветки git. p4 shelve - это эквивалент git stash. Разница между ними заключается в реализации (т.е. распределенная или клиент-серверная), и это различие приводит к p4-эквиваленту git checkout, включающему несколько шагов и значительное время. Накладные расходы таковы, что несколько ветвей обычно сохраняются локально на диске вместо выполнения эквивалента git checkout. полки p4 хранятся на сервере, а не в локальном репо.
Джош Хайцман
1

Я страдаю, как и вы, из-за отсутствия концепции «списка изменений», которая не совсем такая же, как ветки git.

Я бы написал небольшой скрипт, который создаст файл списка изменений со списком файлов в этом списке.

Другая команда для отправки только определенного списка изменений путем простого вызова git commit -a @ change_list_contents.txt, а затем "git commit"

Надеюсь, это поможет, Элиас

Элиас Бачаалани
источник
Да, я действительно думал о том, чтобы сделать что-то подобное, хотя в то время, когда я задавал этот вопрос, я был новичком в git и поэтому хотел знать «родное» решение. Теперь я обнаружил, что главное, чего мне не хватает, - это возможность работать над сообщением о фиксации, фактически не выполняя фиксации. Таким образом, можно решить, имея файл для хранения «ожидающего сообщения фиксации» и, возможно, некоторую магию для его автоматического чтения при написании сообщения фиксации.
Лоуренс Гонсалвес,
@LaurenceGonsalves, рабочий процесс, который я использую, состоит в том, чтобы фиксировать несовершенные сообщения фиксации (или даже просто "WIP"), пока я сосредоточен на работе, а затем вносить поправки во время моей перебазировки. Поскольку коммиты являются чисто локальными, они не обязательно должны быть окончательными, пока вы не сделаете свою ветку доступной (нажав ее на свой удаленный компьютер или что-то подобное).
RJFalconer
1

В git есть более легкая альтернатива, которая может стать частью вашего рабочего процесса; используя промежуточную область git.

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

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

git commit a.txt
git commit z.txt

Или сначала явно разместить файлы:

git add a.txt
git commit
git add z.txt
git commit

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

При этом рабочем процессе следует иметь в виду небольшую оговорку. Если вы вносите изменения A и B в файл, проверяете файл, затем фиксируете A, значит, вы не тестировали эту фиксацию (независимо от B).

Рассел Галлоп
источник
Безусловно, git позволяет выполнять даже более мелкие коммиты, чем perforce (например, строки и фрагменты). То, что мне (до сих пор) не хватает из-за воли, - это возможность отслеживать описание изменения (также известное как сообщение о фиксации) того, над чем я сейчас работаю. Например, когда я собираюсь исправить ошибку № 12345, я бы создал список изменений, в котором говорилось, что я это делаю (но не отправляю, то есть коммит). Затем, работая над этим, я обновлял описание изменения, чтобы указать, что я сделал. Наконец, когда я закончу, я зафиксирую список изменений.
Лоуренс Гонсалвес,
В git кажется, что грубым эквивалентом является фиксация этих крошечных (часто нерабочих) битов в ветке разработки, а затем, когда все в порядке, объединить изменения. Мне это все еще кажется более утомительным и неуклюжим. Кроме того, я до сих пор не привык к идее коммитить код, который даже не компилируется.
Лоуренс Гонсалвес,
@LaurenceGonsalves Любопытно, не привыкли ли вы к этому. Я перехожу к Perforce из Git, и мне не хватает возможности фиксировать каждые 15 минут, а затем нажимать, когда я буду готов.
Дамиан
0

Это не отвечает конкретно на ваш вопрос, но я не знаю, знаете ли вы, что версию perforce для 2 пользователей и 5 рабочих областей можно бесплатно загрузить и использовать с веб-сайта perforce .

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

Тоби Аллен
источник
2
Я этим и занимался, но хотел бы переключиться на что-то с открытым исходным кодом, которое также используется проектами с открытым исходным кодом.
Лоуренс Гонсалвес,
0

Я достаточно широко использовал как Perforce, так и git, поэтому я вижу только один способ приблизиться к спискам изменений Perforce с помощью git.

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

Списки изменений Perforce разрешают рабочий процесс, которому просто нет эквивалента в git. Рассмотрим следующий рабочий процесс:

Check out a branch
Modify file A and add it to changelist 1
Modify file B and add it to changelist 2

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

Ближайшее приближение я могу видеть это использовать , git add . -pа затем использовать 'a'и 'd'суб-команды , чтобы выбрать или отклонить файлы целиком. Однако это не совсем одно и то же, и разница здесь проистекает из фундаментального различия в общих способах работы двух систем.

Git (и subversion, но это не имеет значения для этого обсуждения) позволяют изменять файл, не сообщая об этом заранее. Вы просто меняете файл, а затем позволяете git разбираться со всем этим, когда вы фиксируете изменения. Perforce требует, чтобы вы активно извлекали файл, прежде чем изменения будут разрешены, и именно по этой причине должны существовать списки изменений. По сути, Perforce требует, чтобы вы добавили файл в индекс перед его изменением. Отсюда необходимость в нескольких списках изменений в Perforce, а также причина, по которой у git нет эквивалента. Они ему просто не нужны.

dgnuff
источник
0

В Git 2.27 (второй квартал 2020 г.) " git p4" изучил четыре новых хука, а также " --no-verify" возможность их обхода (и существующий " p4-pre-submit" крючок).

См. Фиксацию 1ec4a0a , фиксацию 38ecf75 , фиксацию cd1e0dc (14 февраля 2020 г.) и фиксацию 4935c45 , фиксацию aa8b766 , фиксацию 9f59ca4 , фиксацию 6b602a2 (11 февраля 2020 г.) Бен Кин ( seraphire) .
(Объединено Junio ​​C Hamano - gitster- в коммите 5f2ec21 , 22 апреля 2020 г.)

git-p4: добавить хуки отправки p4

Подписано: Бен Кин

Команда git " commit" поддерживает ряд перехватчиков, которые поддерживают изменение поведения команды фиксации.

У git-p4.pyпрограммы есть только один существующий хук " p4-pre-submit".

Эта команда появляется на ранней стадии процесса.

В потоке процесса нет ловушек для программного изменения текста списка изменений P4.

Добавляет 3 новых крючка git-p4.pyк опции отправки.

Новые крючки:

  • p4-prepare-changelist- Выполните эту ловушку после создания файла списка изменений.
    Хук будет выполнен, даже если --prepare-p4-onlyопция установлена.
    Этот хук игнорирует --no-verifyпараметр в соответствии с существующим поведением git commit.

  • p4-changelist- Выполните эту ловушку после того, как пользователь отредактировал список изменений.
    Не выполняйте эту ловушку, если пользователь выбрал эту --prepare-p4-onlyопцию.
    Этот хук будет учитывать --no-verify, следуя соглашениям git commit.

  • p4-post-changelist- Выполните эту ловушку после успешного завершения процесса отправки P4.
    Этот хук не принимает параметров и выполняется независимо от --no-verifyопции.

Его возвращаемое значение проверяться не будет.

Призывы к новым крючками: p4-prepare-changelist, p4-changelistи p4-post-changelistвсе должны называться внутри примерки , наконец , блок.

До Git 2.28 (3 квартал 2020 г.) --prepare-p4-onlyопция " " должна была останавливаться после воспроизведения одного набора изменений, но продолжала работать (по ошибке?)

См. Commit 2dfdd70 (12 мая 2020 г.) Бена Кина ( seraphire) .
(Объединено Junio ​​C Hamano - gitster- в коммите 7a8fec9 , 02 июня 2020 г.)

git-p4.py: исправить --prepare-p4-onlyошибку с несколькими коммитами

Подписано: Бен Кин

При использовании git p4 submitс этой --prepare-p4-onlyопцией программа должна подготовить один список изменений p4 и уведомить пользователя о том, что ожидаются другие фиксации, а затем прекратить обработку.

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

Функция applyCommit возвращается, Trueкогда применение фиксации было успешным, и программа должна продолжаться.
Однако, если установлен необязательный флаг --prepare-p4-only, программа должна остановиться после первого приложения.

Измените логику в методе выполнения для P4Submit, чтобы проверять флаг --prepare-p4-onlyпосле успешного завершения applyCommitметода.

Если более 1 фиксации ожидает отправки в P4, метод правильно подготовит список изменений P4, однако он все равно выйдет из приложения с кодом выхода 1.

Текущая документация не определяет , что код выхода должен быть в этом состоянии.

VonC
источник