Изменение Отмены в мерзавце (не переписывающий историю)
Лучше всего реализовать метод расширения, такой как
public static T DeepClone(this T originalObject)
{ /* the cloning code */ }
, а затем использовать его в любом месте решения с помощью
var copy = anyObject.DeepClone();
. Мы можем иметь следующие три реализации:
- Сериализация (самый короткий код)
- По рефлексии - быстрее на 5 раз
- По деревьям выражений - 20 раз быстрее
Все связанные методы хорошо работают и были глубоко протестированы.
3 ответа
Да, можно использовать , мерзавец возвращается для этого. Посмотрите раздел руководства мерзавца по этому для получения дополнительной информации.
суть - то, что можно сказать:
git revert 4f4k2a
, Где 4f4k2a идентификатор фиксации, требуется отменить, и это попытается отменить его.
Просто комментарий:
git revert aCommit
действительно возвращается весь фиксация (как в" все файлы часть фиксации"):
это вычисляет обратный патч, применяет его на ГОЛОВУ и фиксацию.
Так две проблемы здесь (первый легко решен):
- это действительно всегда фиксирует, таким образом, можно хотеть добавить
-no-commitопция: "git revert --no-commit aCommit": это полезно при возвращении эффекта больше чем одной фиксации к индексу подряд. - это не запрашивает определенный файл (что, если Вы a.py были частью фиксации с 1 000 других изменений, что Вы не можете хотеть возвращаться)?
Для этого, если Вы хотите извлечь определенные файлы, как они были в другой фиксации, необходимо видетьgit-checkout, конкретноgit checkout <commit> <filename>синтаксис (который не является точно, в чем Вы нуждаетесь в этом случае, хотя)
Легкий Мерзавец (Elijah Newren) пытался принести, больше "завершенное возвращается" к Список рассылки Мерзавца ; но без большого успеха:
Люди иногда хотят "вернуться изменения".
Теперь, это может быть:
- изменения между 32 и 29 изменений назад,
- это могли бы быть все изменения начиная с последней фиксации,
- это могли быть изменения с тех пор 3 фиксации назад, или
- это могла быть всего одна определенная фиксация.
- пользователь может хотеть к подмножеству такие возвращения только к определенным файлам ,
(eg revert, зарегистрированы здесь , но я не уверен, что это - часть текущего распределения, например, хотя)
, но все это сводится к "возвращающимся изменениям" в конце.
eg revert --since HEAD~3 # Undo all changes since HEAD~3
eg revert --in HEAD~8 # much like git revert HEAD~8, but nocommit by default
eg revert --since HEAD foo.py # Undo changes to foo.py since last commit
eg revert foo.py # Same as above
eg revert --in trial~7 bar.c baz. # Undo changes made in trial~7 to bar.[ch]
<час>эти виды "возвращающихся данных", действительно столь отличающихся, что должны должны быть быть различные команды, или что некоторые из этих операций не должны поддерживаться простым, возвращаются команда?
Несомненно, большинство пользователей большую часть времени будет, вероятно, использовать"eg revert FILE1 FILE2..." форма, но я не видел вреда в поддержке дополнительных возможностей.Также... там что-либо фундаментальное, которое помешало бы базовому мерзавцу принимать такое поведение?
Примечание Elijah
: фиксации по умолчанию не имеют смысла для обобщенного
revert, команда, и"git revert REVISION" была бы ошибка с инструкциями (говорящий пользователю добавить - во флаге).
Позволяет, говорят, что Вы имеете из 50 фиксировавших, 20 файлов, Вы понимаете, что старая фиксация X представленных изменений, которые не должны были происходить.
Немного инфраструктуры в порядке.
то, В чем Вы нуждаетесь, является способом перечислить все определенные файлы, в которых Вы нуждаетесь к [1 173], возвращаются
(как в [1 174], "для отмены изменений, внесенных в фиксации X при хранении всех последующих изменений" ),
и затем, для каждого из них:
git-merge-file -p a.py X X^
проблема здесь должна восстановить потерянную функцию, не стирая все последующие изменения в a.py, который Вы могли бы хотеть сохранить.
, Что технику когда-то называют "отрицательным слиянием".
С тех пор git merge-file <current-file> <base-file> <other-file> средства :
включает все изменения, которые ведут от <base-file> к [1 114] в [1 115], Вы можете восстановление удаленная функция путем высказывания, что Вы хотите включить все изменения.)
- от: X (где функция была удалена)
- к: X^ (предыдущая фиксация прежде X, где функция была все еще там)
Примечание: ' -p' аргумент, который позволяет Вам рассматривать сначала изменения, ничего не делая на текущем файле. Когда Вы уверены, удаляете ту опцию.
Примечание : git merge-file не что прост : Вы не можете сослаться на предыдущие версии файла точно так же, как это.
(у Вас было бы много раз расстраивающее сообщение: error: Could not stat X )
Вы имеете к:
git cat-file blob a.py > tmp/ori # current file before any modification
git cat-file blob HEAD~2:a.py > tmp/X # file with the function deleted
git cat-file blob HEAD~3:a.py > tmp/F # file with the function which was still there
git merge-file a.py tmp/X tmp/F # basically a RCS-style merge
# note the inversed commit order: X as based, then F
# that is why is is a "negative merge"
diff -u a.py tmp/ori # eyeball the merge result
git add a.py
git commit -m "function restored" # and any other changes made from X are preserved!
, Если это должно быть сделано для большого количества файлов в предыдущей фиксации..., некоторые сценарии в порядке;)
Для возвращения изменений только в одном файле в фиксации, как VonC, на который указывают, я был бы checkout ответвление (ведущее устройство или соединительная линия или безотносительно) и затем checkout версия файла, я хотел вернуться и рассматривать его как новую фиксацию:
$ git checkout trunk
$ git checkout 4f4k2a^ a.py
$ git add a.py
$ git diff #verify I'm only changing what I want; edit as needed
$ git commit -m 'recover function deleted from a.py in 4f4k2a'
существует, вероятно, команда инфраструктуры, которая сделала бы это непосредственно, но я не использовал бы ее, если бы я знал это. Не то, чтобы я не доверяю Мерзавцу, но я не доверяю мне - я не положил бы, что знал, не смотря, что было изменено в том файле в той фиксации и с тех пор. И как только я смотрю, легче просто создать новую фиксацию путем редактирования diff. Возможно, это - просто персональный workstyle.