When performing an interactive rebase in split-index mode,
the commit message that one should rework when squashing commits
can contain some garbage instead of the usual concatenation of
both of the commit messages.
When bisecting it appears that 94c9b5af70 (Merge branch
'cc/split-index-config', 2017-03-17) is the first bad commit.
But when rebasing cc/split-index-config on top of the commit it
was merged with, the first bad commit is then c3a0082502
(read-cache: use freshen_shared_index() in read_index_from(),
2017-03-06).
This shows that we should be careful not to use git_path() in
freshen_shared_index(). It is using a shared buffer that can
too easily lead to races.
Signed-off-by: Christian Couder <chriscool@xxxxxxxxxxxxx>
---
read-cache.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/read-cache.c b/read-cache.c
index e447751823..2f10242c24 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1682,9 +1682,10 @@ int do_read_index(struct index_state *istate, const char *path, int must_exist)
*/
static void freshen_shared_index(char *base_sha1_hex, int warn)
{
- const char *shared_index = git_path("sharedindex.%s", base_sha1_hex);
+ char *shared_index = git_pathdup("sharedindex.%s", base_sha1_hex);
if (!check_and_freshen_file(shared_index, 1) && warn)
warning("could not freshen shared index '%s'", shared_index);
+ free(shared_index);
}
int read_index_from(struct index_state *istate, const char *path)
--
2.12.0.339.g3df8399f7e.dirty