Some uses may now require --no-index, but remove a footgun that has bit
users over the years where stash {apply,pop} are not the opposite of
stash push because they drop the (saved) index.
Signed-off-by: D. Ben Knoble <ben.knoble+github@xxxxxxxxx>
---
Notes:
Dscho/Junio suggested it in the original thread [1], but it wasn't
considered for the release I believe [2].
[1]: https://lore.kernel.org/git/Pine.LNX.4.64.0707021213350.4438@xxxxxxxxxx/
[2]: https://lore.kernel.org/git/7vzm20q1l7.fsf_-_@xxxxxxxxxxxxxxxxxxxxxxxx/
Documentation/BreakingChanges.adoc | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/Documentation/BreakingChanges.adoc b/Documentation/BreakingChanges.adoc
index 61bdd586b9..798e742267 100644
--- a/Documentation/BreakingChanges.adoc
+++ b/Documentation/BreakingChanges.adoc
@@ -118,6 +118,17 @@ Cf. <2f5de416-04ba-c23d-1e0b-83bb655829a7@xxxxxxxxxxx>,
<20170223155046.e7nxivfwqqoprsqj@LykOS.localdomain>,
<CA+EOSBncr=4a4d8n9xS4FNehyebpmX8JiUwCsXD47EQDE+DiUQ@xxxxxxxxxxxxxx>.
+* The git-stash(1) command now tries to reinstate the index by default in
+ the "apply" and "pop" modes. Not doing so creates a common trap: "git stash
+ apply" is not the reverse of "git stash push" because carefully staged indices
+ are lost and have to be manually recreated.
++
+Now git-stash(1) will behave like "--index" was given in the "apply" and "pop"
+modes. Use "--no-index" to disable this behavior.
++
+Cf. <CAPx1GvcxyDDQmCssMjEnt6JoV6qPc5ZUpgPLX3mpUC_4PNYA1w@xxxxxxxxxxxxxx>,
+<c5a811ac-8cd3-c389-ac6d-29020a648c87@xxxxxxxxx>.
+
=== Removals
* Support for grafting commits has long been superseded by git-replace(1).
--
2.48.1
