Проверьте, является ли коммит записью в тайнике

Записи в Stash — это обычные коммиты. Вы можете проверить их с помощью git cat-file -p stash@{<number>}, это коммиты слияния между 1) фиксацией, на которую указывал ваш HEAD, когда вы спрятали, и 2) каким-то коммитом, автоматически созданным git, когда вы спрятали, ссылаясь на состояние индекса в момент спрятания.

Это похоже на проблему XY. Что именно вы пытаетесь достичь, что заставляет вас думать, что вам нужно это сделать? Проверка наличия удаленных, но не собранных мусора тайников в любом случае кажется грязной операцией.

Сделайте себе и всем остальным одолжение и перестаньте использовать stash и вместо этого просто проверяйте временные данные как временные коммиты.

@MarcoBonelli Я пишу специальную команду для тайника, и прежде чем она внесет какие-либо изменения, я хочу, чтобы она проверила, действительно ли ref / sha, предоставленный пользователем, является тайником. Есть ли в этом вопросе какое-либо фактическое указание на проблему XY? Я чувствую, что в последнее время люди здесь называют проблему XY каждый раз, когда видят что-то, что им раньше не нужно.

@hlovdal Нет. Stash слишком полезен и удобен, чтобы игнорировать его существование.

@PiotrSiupa Что делает тайник, чего нельзя было достичь с помощью временных коммитов?

@RomainValeri Я могу сохранить свой индекс, изменения в отслеживаемых файлах и все неотслеживаемые файлы с помощью одной простой команды, а затем восстановить их с помощью одной простой команды.

@PiotrSiupa Ничто из этого не является эксклюзивным для git stash, этого можно добиться с помощью тривиальных псевдонимов. Но извините за примечание не по теме, и, конечно, у каждого есть предпочтения относительно того, как работать. Заботиться!

У Stash есть опасные , сложные особенности, которых нет у обычных коммитов.

@hlovdal 1) Это проблема навыков, а не причуды. Stash работает так, как должен, и интуитивно понятен. Если вы предполагаете, что числа не изменятся при удалении записей, это ваша вина. Если вы не уверены, вы всегда можете обратиться к записям тайника по именам. 2) Это даже не настоящая проблема. Простой git reset --hard отменяет это. 3) Это не причуда, просто неудобно, и если вы хотите хранить индексные и непроиндексированные изменения отдельно, использовать rebase еще сложнее. Если у вас возникла эта проблема, значит, вы используете stash не так, как предполагалось. Мне трудно представить ситуацию, когда вам понадобится изменить существующую запись в тайнике.

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

@RomainValeri Я запустил поиск [git] stash is:question и оказалось, что их вообще не так много. Однако, если вы предполагаете, что популярность stash является причиной избавиться от него, может быть, нам также следует перестать использовать rebase, потому что, похоже, к нему гораздо больше вопросов, чем к stash?

@PiotrSiupa По личному опыту я очень часто помогал коллегам с неправильным обращением с тайниками, но опять же, я не сторонник того, чтобы «никогда не использовать тайник», делайте, как хотите.

Может быть три родителя с -u или --untracked, и сообщение основного тайника настраивается, но да. Это примерно столько хорошего, сколько вы можете получить, единственное, что имеет значение, можно ли его использовать в качестве тайника, все остальное - это упомянутая проблема XY.

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

@PiotrSiupa Я думаю, что сообщение index on: ref shorthash у второго родителя, где короткий хеш является первым родителем, должно быть достаточно надежным.