summaryrefslogtreecommitdiff
path: root/t/t3429-rebase-edit-todo.sh
AgeCommit message (Collapse)AuthorFilesLines
2019-11-10Merge branch 'bc/hash-independent-tests-part-6'Libravatar Junio C Hamano1-1/+1
Test updates to prepare for SHA-2 transition continues. * bc/hash-independent-tests-part-6: t4048: abstract away SHA-1-specific constants t4045: make hash-size independent t4044: update test to work with SHA-256 t4039: abstract away SHA-1-specific constants t4038: abstract away SHA-1 specific constants t4034: abstract away SHA-1-specific constants t4027: make hash-size independent t4015: abstract away SHA-1-specific constants t4011: abstract away SHA-1-specific constants t4010: abstract away SHA-1-specific constants t3429: remove SHA1 annotation t1305: avoid comparing extensions rev-parse: add a --show-object-format option t/oid-info: add empty tree and empty blob values t/oid-info: allow looking up hash algorithm name
2019-10-28t3429: remove SHA1 annotationLibravatar brian m. carlson1-1/+1
This test passes successfully with SHA-256, so remove the annotation which limits it to SHA-1. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-19rebase -i: check for updated todo after squash and rewordLibravatar Phillip Wood1-1/+20
While a rebase is stopped for the user to edit a commit message it can be convenient for them to also edit the todo list. The scripted version of rebase supported this but the C version does not. We already check to see if the todo list has been updated by an exec command so extend this to rewords and squashes. It only costs a single stat call to do this so it should not affect the speed of the rebase (especially as it has just stopped for the user to edit a message) Note that for squashes the editor may be opened on a different pick to the squash itself as we edit the message at the end of a chain fixups and squashes. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-03-14get_oid(): when an object was not found, try harderLibravatar Johannes Schindelin1-1/+1
It is quite possible that the loose object cache gets stale when new objects are written. In that case, get_oid() would potentially say that it cannot find a given object, even if it should find it. Let's blow away the loose object cache as well as the read packs and try again in that case. Note: this does *not* affect the code path that was introduced to help avoid looking for the same non-existing objects (which made some operations really expensive via NFS): that code path is handled by the `OBJECT_INFO_QUICK` flag (which does not even apply to `get_oid()`, which has no equivalent flag, at least at the time this patch was written). This incidentally fixes the problem identified earlier where an interactive rebase wanted to re-read (and validate) the todo list after an `exec` command modified it. Helped-by: Jeff King <peff@peff.net> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-03-14rebase -i: demonstrate obscure loose object cache bugLibravatar Johannes Schindelin1-0/+22
We specifically support `exec` commands in `git rebase -i`'s todo lists to rewrite the very same todo list. Of course, we need to validate that todo list when re-reading it. It is also totally legitimate to extend the todo list by `pick` lines using short names of commits that were created only after the rebase started. And this is where the loose object cache interferes with this feature: if *some* loose object was read whose hash shares the same first two digits with a commit that was not yet created when that loose object was created, then we fail to find that new commit by its short name in `get_oid()`, and the interactive rebase fails with an obscure error message like: error: invalid line 1: pick 6568fef error: please fix this using 'git rebase --edit-todo'. Let's first demonstrate that this is actually a bug in a new regression test, in a separate commit so that other developers who do not believe me can cherry-pick it to confirm the problem. This new regression test generates two commits whose hashes share the first two hex digits (so that their corresponding loose objects live in the same subdirectory of .git/objects/, and are therefore supposed to be in the same loose object cache bin). It then picks the first, to make sure that the loose object cache is initialized and cached that object directory, then generates the second commit and picks it, too. Since the commit was generated in a different process than the sequencer that wants to pick it, the loose object cache had no chance of being updated in the meantime. Technically, we would need only one `exec` command in this regression test case, but for ease of implementation, it uses a pseudo-recursive call to the same script. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-04-27rebase -i: reread the todo list if `exec` touched itLibravatar Stephen Hicks1-0/+14
In the scripted version of the interactive rebase, there was no internal representation of the todo list; it was re-read before every command. That allowed the hack that an `exec` command could append (or even completely rewrite) the todo list. This hack was broken by the partial conversion of the interactive rebase to C, and this patch reinstates it. We also add a small test to verify that this fix does not regress in the future. Signed-off-by: Stephen Hicks <sdh@google.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>