2023-02-24 01:09:24 +01:00
|
|
|
#include "git-compat-util.h"
|
2023-03-21 07:25:58 +01:00
|
|
|
#include "abspath.h"
|
2023-02-24 01:09:24 +01:00
|
|
|
#include "alloc.h"
|
2017-06-14 20:07:36 +02:00
|
|
|
#include "config.h"
|
2023-03-21 07:25:54 +01:00
|
|
|
#include "gettext.h"
|
2023-02-24 01:09:27 +01:00
|
|
|
#include "hex.h"
|
2014-10-01 12:28:42 +02:00
|
|
|
#include "lockfile.h"
|
2008-07-21 20:03:49 +02:00
|
|
|
#include "string-list.h"
|
2008-07-09 14:58:57 +02:00
|
|
|
#include "rerere.h"
|
|
|
|
|
#include "xdiff-interface.h"
|
2009-12-26 00:51:32 +01:00
|
|
|
#include "dir.h"
|
|
|
|
|
#include "resolve-undo.h"
|
|
|
|
|
#include "ll-merge.h"
|
2010-01-17 08:28:46 +01:00
|
|
|
#include "attr.h"
|
2013-07-14 10:35:40 +02:00
|
|
|
#include "pathspec.h"
|
2018-05-16 01:42:15 +02:00
|
|
|
#include "object-store.h"
|
2020-12-31 12:56:23 +01:00
|
|
|
#include "hash-lookup.h"
|
rerere: use strmap to store rerere directories
We store a struct for each directory we access under .git/rr-cache. The
structs are kept in an array sorted by the binary hash associated with
their name (and we do lookups with a binary search).
This works OK, but there are a few small downsides:
- the amount of code isn't huge, but it's more than we'd need using one
of our other stock data structures
- the insertion into a sorted array is quadratic (though in practice
it's unlikely anybody has enough conflicts for this to matter)
- it's intimately tied to the representation of an object hash. This
isn't a big deal, as the conflict ids we generate use the same hash,
but it produces a few awkward bits (e.g., we are the only user of
hash_pos() that is not using object_id).
Let's instead just treat the directory names as strings, and store them
in a strmap. This is less code, and removes the use of hash_pos().
Insertion is now non-quadratic, though we probably use a bit more
memory. Besides the hash table overhead, and storing hex bytes instead
of a binary hash, we actually store each name twice. Other code expects
to access the name of a rerere_dir struct from the struct itself, so we
need a copy there. But strmap keeps its own copy of the name, as well.
Using a bare hashmap instead of strmap means we could use the name for
both, but at the cost of extra code (e.g., our own comparison function).
Likewise, strmap has a feature to use a pointer to the in-struct name at
the cost of a little extra code. I didn't do either here, as simple code
seemed more important than squeezing out a few bytes of efficiency.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-01-28 07:34:31 +01:00
|
|
|
#include "strmap.h"
|
2023-03-21 07:26:01 +01:00
|
|
|
#include "wrapper.h"
|
2008-07-09 14:58:57 +02:00
|
|
|
|
2011-02-16 11:47:44 +01:00
|
|
|
#define RESOLVED 0
|
|
|
|
|
#define PUNTED 1
|
|
|
|
|
#define THREE_STAGED 2
|
|
|
|
|
void *RERERE_RESOLVED = &RERERE_RESOLVED;
|
|
|
|
|
|
2008-07-09 14:58:57 +02:00
|
|
|
/* if rerere_enabled == -1, fall back to detection of .git/rr-cache */
|
|
|
|
|
static int rerere_enabled = -1;
|
|
|
|
|
|
|
|
|
|
/* automatically update cleanly resolved paths to the index */
|
|
|
|
|
static int rerere_autoupdate;
|
|
|
|
|
|
2015-07-17 00:47:13 +02:00
|
|
|
#define RR_HAS_POSTIMAGE 1
|
|
|
|
|
#define RR_HAS_PREIMAGE 2
|
rerere: use strmap to store rerere directories
We store a struct for each directory we access under .git/rr-cache. The
structs are kept in an array sorted by the binary hash associated with
their name (and we do lookups with a binary search).
This works OK, but there are a few small downsides:
- the amount of code isn't huge, but it's more than we'd need using one
of our other stock data structures
- the insertion into a sorted array is quadratic (though in practice
it's unlikely anybody has enough conflicts for this to matter)
- it's intimately tied to the representation of an object hash. This
isn't a big deal, as the conflict ids we generate use the same hash,
but it produces a few awkward bits (e.g., we are the only user of
hash_pos() that is not using object_id).
Let's instead just treat the directory names as strings, and store them
in a strmap. This is less code, and removes the use of hash_pos().
Insertion is now non-quadratic, though we probably use a bit more
memory. Besides the hash table overhead, and storing hex bytes instead
of a binary hash, we actually store each name twice. Other code expects
to access the name of a rerere_dir struct from the struct itself, so we
need a copy there. But strmap keeps its own copy of the name, as well.
Using a bare hashmap instead of strmap means we could use the name for
both, but at the cost of extra code (e.g., our own comparison function).
Likewise, strmap has a feature to use a pointer to the in-struct name at
the cost of a little extra code. I didn't do either here, as simple code
seemed more important than squeezing out a few bytes of efficiency.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-01-28 07:34:31 +01:00
|
|
|
struct rerere_dir {
|
2015-07-23 23:23:24 +02:00
|
|
|
int status_alloc, status_nr;
|
|
|
|
|
unsigned char *status;
|
rerere: use strmap to store rerere directories
We store a struct for each directory we access under .git/rr-cache. The
structs are kept in an array sorted by the binary hash associated with
their name (and we do lookups with a binary search).
This works OK, but there are a few small downsides:
- the amount of code isn't huge, but it's more than we'd need using one
of our other stock data structures
- the insertion into a sorted array is quadratic (though in practice
it's unlikely anybody has enough conflicts for this to matter)
- it's intimately tied to the representation of an object hash. This
isn't a big deal, as the conflict ids we generate use the same hash,
but it produces a few awkward bits (e.g., we are the only user of
hash_pos() that is not using object_id).
Let's instead just treat the directory names as strings, and store them
in a strmap. This is less code, and removes the use of hash_pos().
Insertion is now non-quadratic, though we probably use a bit more
memory. Besides the hash table overhead, and storing hex bytes instead
of a binary hash, we actually store each name twice. Other code expects
to access the name of a rerere_dir struct from the struct itself, so we
need a copy there. But strmap keeps its own copy of the name, as well.
Using a bare hashmap instead of strmap means we could use the name for
both, but at the cost of extra code (e.g., our own comparison function).
Likewise, strmap has a feature to use a pointer to the in-struct name at
the cost of a little extra code. I didn't do either here, as simple code
seemed more important than squeezing out a few bytes of efficiency.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-01-28 07:34:31 +01:00
|
|
|
char name[FLEX_ARRAY];
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static struct strmap rerere_dirs = STRMAP_INIT;
|
rerere: split conflict ID further
The plan is to keep assigning the backward compatible conflict ID
based on the hash of the (normalized) text of conflicts, keep using
that conflict ID as the directory name under $GIT_DIR/rr-cache/, but
allow each conflicted path to use a separate "variant" to record
resolutions, i.e. having more than one <preimage,postimage> pairs
under $GIT_DIR/rr-cache/$ID/ directory. As the first step in that
direction, separate the shared "conflict ID" out of the rerere_id
structure.
The plan is to keep information per $ID in rerere_dir, that can be
shared among rerere_id that is per conflicted path.
When we are done with rerere(), which can be directly called from
other programs like "git apply", "git commit" and "git merge", the
shared rerere_dir structures can be freed entirely, so they are not
reference-counted and they are not freed when we release rerere_id's
that reference them.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-16 23:50:05 +02:00
|
|
|
|
|
|
|
|
static void free_rerere_dirs(void)
|
|
|
|
|
{
|
rerere: use strmap to store rerere directories
We store a struct for each directory we access under .git/rr-cache. The
structs are kept in an array sorted by the binary hash associated with
their name (and we do lookups with a binary search).
This works OK, but there are a few small downsides:
- the amount of code isn't huge, but it's more than we'd need using one
of our other stock data structures
- the insertion into a sorted array is quadratic (though in practice
it's unlikely anybody has enough conflicts for this to matter)
- it's intimately tied to the representation of an object hash. This
isn't a big deal, as the conflict ids we generate use the same hash,
but it produces a few awkward bits (e.g., we are the only user of
hash_pos() that is not using object_id).
Let's instead just treat the directory names as strings, and store them
in a strmap. This is less code, and removes the use of hash_pos().
Insertion is now non-quadratic, though we probably use a bit more
memory. Besides the hash table overhead, and storing hex bytes instead
of a binary hash, we actually store each name twice. Other code expects
to access the name of a rerere_dir struct from the struct itself, so we
need a copy there. But strmap keeps its own copy of the name, as well.
Using a bare hashmap instead of strmap means we could use the name for
both, but at the cost of extra code (e.g., our own comparison function).
Likewise, strmap has a feature to use a pointer to the in-struct name at
the cost of a little extra code. I didn't do either here, as simple code
seemed more important than squeezing out a few bytes of efficiency.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-01-28 07:34:31 +01:00
|
|
|
struct hashmap_iter iter;
|
|
|
|
|
struct strmap_entry *ent;
|
|
|
|
|
|
|
|
|
|
strmap_for_each_entry(&rerere_dirs, &iter, ent) {
|
|
|
|
|
struct rerere_dir *rr_dir = ent->value;
|
|
|
|
|
free(rr_dir->status);
|
|
|
|
|
free(rr_dir);
|
2015-07-23 23:23:24 +02:00
|
|
|
}
|
rerere: use strmap to store rerere directories
We store a struct for each directory we access under .git/rr-cache. The
structs are kept in an array sorted by the binary hash associated with
their name (and we do lookups with a binary search).
This works OK, but there are a few small downsides:
- the amount of code isn't huge, but it's more than we'd need using one
of our other stock data structures
- the insertion into a sorted array is quadratic (though in practice
it's unlikely anybody has enough conflicts for this to matter)
- it's intimately tied to the representation of an object hash. This
isn't a big deal, as the conflict ids we generate use the same hash,
but it produces a few awkward bits (e.g., we are the only user of
hash_pos() that is not using object_id).
Let's instead just treat the directory names as strings, and store them
in a strmap. This is less code, and removes the use of hash_pos().
Insertion is now non-quadratic, though we probably use a bit more
memory. Besides the hash table overhead, and storing hex bytes instead
of a binary hash, we actually store each name twice. Other code expects
to access the name of a rerere_dir struct from the struct itself, so we
need a copy there. But strmap keeps its own copy of the name, as well.
Using a bare hashmap instead of strmap means we could use the name for
both, but at the cost of extra code (e.g., our own comparison function).
Likewise, strmap has a feature to use a pointer to the in-struct name at
the cost of a little extra code. I didn't do either here, as simple code
seemed more important than squeezing out a few bytes of efficiency.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-01-28 07:34:31 +01:00
|
|
|
strmap_clear(&rerere_dirs, 0);
|
rerere: split conflict ID further
The plan is to keep assigning the backward compatible conflict ID
based on the hash of the (normalized) text of conflicts, keep using
that conflict ID as the directory name under $GIT_DIR/rr-cache/, but
allow each conflicted path to use a separate "variant" to record
resolutions, i.e. having more than one <preimage,postimage> pairs
under $GIT_DIR/rr-cache/$ID/ directory. As the first step in that
direction, separate the shared "conflict ID" out of the rerere_id
structure.
The plan is to keep information per $ID in rerere_dir, that can be
shared among rerere_id that is per conflicted path.
When we are done with rerere(), which can be directly called from
other programs like "git apply", "git commit" and "git merge", the
shared rerere_dir structures can be freed entirely, so they are not
reference-counted and they are not freed when we release rerere_id's
that reference them.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-16 23:50:05 +02:00
|
|
|
}
|
|
|
|
|
|
2015-07-05 02:38:34 +02:00
|
|
|
static void free_rerere_id(struct string_list_item *item)
|
2008-07-09 14:58:57 +02:00
|
|
|
{
|
2015-07-05 02:38:34 +02:00
|
|
|
free(item->util);
|
2008-07-09 14:58:57 +02:00
|
|
|
}
|
|
|
|
|
|
2015-07-05 02:38:34 +02:00
|
|
|
static const char *rerere_id_hex(const struct rerere_id *id)
|
|
|
|
|
{
|
rerere: use strmap to store rerere directories
We store a struct for each directory we access under .git/rr-cache. The
structs are kept in an array sorted by the binary hash associated with
their name (and we do lookups with a binary search).
This works OK, but there are a few small downsides:
- the amount of code isn't huge, but it's more than we'd need using one
of our other stock data structures
- the insertion into a sorted array is quadratic (though in practice
it's unlikely anybody has enough conflicts for this to matter)
- it's intimately tied to the representation of an object hash. This
isn't a big deal, as the conflict ids we generate use the same hash,
but it produces a few awkward bits (e.g., we are the only user of
hash_pos() that is not using object_id).
Let's instead just treat the directory names as strings, and store them
in a strmap. This is less code, and removes the use of hash_pos().
Insertion is now non-quadratic, though we probably use a bit more
memory. Besides the hash table overhead, and storing hex bytes instead
of a binary hash, we actually store each name twice. Other code expects
to access the name of a rerere_dir struct from the struct itself, so we
need a copy there. But strmap keeps its own copy of the name, as well.
Using a bare hashmap instead of strmap means we could use the name for
both, but at the cost of extra code (e.g., our own comparison function).
Likewise, strmap has a feature to use a pointer to the in-struct name at
the cost of a little extra code. I didn't do either here, as simple code
seemed more important than squeezing out a few bytes of efficiency.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-01-28 07:34:31 +01:00
|
|
|
return id->collection->name;
|
2015-07-05 02:38:34 +02:00
|
|
|
}
|
|
|
|
|
|
2015-07-23 23:23:24 +02:00
|
|
|
static void fit_variant(struct rerere_dir *rr_dir, int variant)
|
|
|
|
|
{
|
|
|
|
|
variant++;
|
|
|
|
|
ALLOC_GROW(rr_dir->status, variant, rr_dir->status_alloc);
|
|
|
|
|
if (rr_dir->status_nr < variant) {
|
|
|
|
|
memset(rr_dir->status + rr_dir->status_nr,
|
|
|
|
|
'\0', variant - rr_dir->status_nr);
|
|
|
|
|
rr_dir->status_nr = variant;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void assign_variant(struct rerere_id *id)
|
|
|
|
|
{
|
|
|
|
|
int variant;
|
|
|
|
|
struct rerere_dir *rr_dir = id->collection;
|
|
|
|
|
|
|
|
|
|
variant = id->variant;
|
|
|
|
|
if (variant < 0) {
|
2015-07-31 00:49:18 +02:00
|
|
|
for (variant = 0; variant < rr_dir->status_nr; variant++)
|
|
|
|
|
if (!rr_dir->status[variant])
|
|
|
|
|
break;
|
2015-07-23 23:23:24 +02:00
|
|
|
}
|
|
|
|
|
fit_variant(rr_dir, variant);
|
|
|
|
|
id->variant = variant;
|
2015-07-05 02:38:34 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
const char *rerere_path(const struct rerere_id *id, const char *file)
|
|
|
|
|
{
|
|
|
|
|
if (!file)
|
|
|
|
|
return git_path("rr-cache/%s", rerere_id_hex(id));
|
|
|
|
|
|
2015-07-23 23:23:24 +02:00
|
|
|
if (id->variant <= 0)
|
|
|
|
|
return git_path("rr-cache/%s/%s", rerere_id_hex(id), file);
|
|
|
|
|
|
|
|
|
|
return git_path("rr-cache/%s/%s.%d",
|
|
|
|
|
rerere_id_hex(id), file, id->variant);
|
2008-07-09 14:58:57 +02:00
|
|
|
}
|
|
|
|
|
|
2015-07-23 23:23:24 +02:00
|
|
|
static int is_rr_file(const char *name, const char *filename, int *variant)
|
2015-07-17 00:47:13 +02:00
|
|
|
{
|
2015-07-23 23:23:24 +02:00
|
|
|
const char *suffix;
|
|
|
|
|
char *ep;
|
|
|
|
|
|
|
|
|
|
if (!strcmp(name, filename)) {
|
|
|
|
|
*variant = 0;
|
|
|
|
|
return 1;
|
|
|
|
|
}
|
|
|
|
|
if (!skip_prefix(name, filename, &suffix) || *suffix != '.')
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
errno = 0;
|
|
|
|
|
*variant = strtol(suffix + 1, &ep, 10);
|
|
|
|
|
if (errno || *ep)
|
|
|
|
|
return 0;
|
|
|
|
|
return 1;
|
2015-07-17 00:47:13 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void scan_rerere_dir(struct rerere_dir *rr_dir)
|
|
|
|
|
{
|
|
|
|
|
struct dirent *de;
|
rerere: use strmap to store rerere directories
We store a struct for each directory we access under .git/rr-cache. The
structs are kept in an array sorted by the binary hash associated with
their name (and we do lookups with a binary search).
This works OK, but there are a few small downsides:
- the amount of code isn't huge, but it's more than we'd need using one
of our other stock data structures
- the insertion into a sorted array is quadratic (though in practice
it's unlikely anybody has enough conflicts for this to matter)
- it's intimately tied to the representation of an object hash. This
isn't a big deal, as the conflict ids we generate use the same hash,
but it produces a few awkward bits (e.g., we are the only user of
hash_pos() that is not using object_id).
Let's instead just treat the directory names as strings, and store them
in a strmap. This is less code, and removes the use of hash_pos().
Insertion is now non-quadratic, though we probably use a bit more
memory. Besides the hash table overhead, and storing hex bytes instead
of a binary hash, we actually store each name twice. Other code expects
to access the name of a rerere_dir struct from the struct itself, so we
need a copy there. But strmap keeps its own copy of the name, as well.
Using a bare hashmap instead of strmap means we could use the name for
both, but at the cost of extra code (e.g., our own comparison function).
Likewise, strmap has a feature to use a pointer to the in-struct name at
the cost of a little extra code. I didn't do either here, as simple code
seemed more important than squeezing out a few bytes of efficiency.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-01-28 07:34:31 +01:00
|
|
|
DIR *dir = opendir(git_path("rr-cache/%s", rr_dir->name));
|
2015-07-17 00:47:13 +02:00
|
|
|
|
|
|
|
|
if (!dir)
|
|
|
|
|
return;
|
|
|
|
|
while ((de = readdir(dir)) != NULL) {
|
2015-07-23 23:23:24 +02:00
|
|
|
int variant;
|
|
|
|
|
|
|
|
|
|
if (is_rr_file(de->d_name, "postimage", &variant)) {
|
|
|
|
|
fit_variant(rr_dir, variant);
|
|
|
|
|
rr_dir->status[variant] |= RR_HAS_POSTIMAGE;
|
|
|
|
|
} else if (is_rr_file(de->d_name, "preimage", &variant)) {
|
|
|
|
|
fit_variant(rr_dir, variant);
|
|
|
|
|
rr_dir->status[variant] |= RR_HAS_PREIMAGE;
|
|
|
|
|
}
|
2015-07-17 00:47:13 +02:00
|
|
|
}
|
|
|
|
|
closedir(dir);
|
|
|
|
|
}
|
|
|
|
|
|
rerere: split conflict ID further
The plan is to keep assigning the backward compatible conflict ID
based on the hash of the (normalized) text of conflicts, keep using
that conflict ID as the directory name under $GIT_DIR/rr-cache/, but
allow each conflicted path to use a separate "variant" to record
resolutions, i.e. having more than one <preimage,postimage> pairs
under $GIT_DIR/rr-cache/$ID/ directory. As the first step in that
direction, separate the shared "conflict ID" out of the rerere_id
structure.
The plan is to keep information per $ID in rerere_dir, that can be
shared among rerere_id that is per conflicted path.
When we are done with rerere(), which can be directly called from
other programs like "git apply", "git commit" and "git merge", the
shared rerere_dir structures can be freed entirely, so they are not
reference-counted and they are not freed when we release rerere_id's
that reference them.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-16 23:50:05 +02:00
|
|
|
static struct rerere_dir *find_rerere_dir(const char *hex)
|
|
|
|
|
{
|
|
|
|
|
struct rerere_dir *rr_dir;
|
rerere: use strmap to store rerere directories
We store a struct for each directory we access under .git/rr-cache. The
structs are kept in an array sorted by the binary hash associated with
their name (and we do lookups with a binary search).
This works OK, but there are a few small downsides:
- the amount of code isn't huge, but it's more than we'd need using one
of our other stock data structures
- the insertion into a sorted array is quadratic (though in practice
it's unlikely anybody has enough conflicts for this to matter)
- it's intimately tied to the representation of an object hash. This
isn't a big deal, as the conflict ids we generate use the same hash,
but it produces a few awkward bits (e.g., we are the only user of
hash_pos() that is not using object_id).
Let's instead just treat the directory names as strings, and store them
in a strmap. This is less code, and removes the use of hash_pos().
Insertion is now non-quadratic, though we probably use a bit more
memory. Besides the hash table overhead, and storing hex bytes instead
of a binary hash, we actually store each name twice. Other code expects
to access the name of a rerere_dir struct from the struct itself, so we
need a copy there. But strmap keeps its own copy of the name, as well.
Using a bare hashmap instead of strmap means we could use the name for
both, but at the cost of extra code (e.g., our own comparison function).
Likewise, strmap has a feature to use a pointer to the in-struct name at
the cost of a little extra code. I didn't do either here, as simple code
seemed more important than squeezing out a few bytes of efficiency.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-01-28 07:34:31 +01:00
|
|
|
|
|
|
|
|
rr_dir = strmap_get(&rerere_dirs, hex);
|
|
|
|
|
if (!rr_dir) {
|
|
|
|
|
FLEX_ALLOC_STR(rr_dir, name, hex);
|
2015-07-23 23:23:24 +02:00
|
|
|
rr_dir->status = NULL;
|
|
|
|
|
rr_dir->status_nr = 0;
|
|
|
|
|
rr_dir->status_alloc = 0;
|
rerere: use strmap to store rerere directories
We store a struct for each directory we access under .git/rr-cache. The
structs are kept in an array sorted by the binary hash associated with
their name (and we do lookups with a binary search).
This works OK, but there are a few small downsides:
- the amount of code isn't huge, but it's more than we'd need using one
of our other stock data structures
- the insertion into a sorted array is quadratic (though in practice
it's unlikely anybody has enough conflicts for this to matter)
- it's intimately tied to the representation of an object hash. This
isn't a big deal, as the conflict ids we generate use the same hash,
but it produces a few awkward bits (e.g., we are the only user of
hash_pos() that is not using object_id).
Let's instead just treat the directory names as strings, and store them
in a strmap. This is less code, and removes the use of hash_pos().
Insertion is now non-quadratic, though we probably use a bit more
memory. Besides the hash table overhead, and storing hex bytes instead
of a binary hash, we actually store each name twice. Other code expects
to access the name of a rerere_dir struct from the struct itself, so we
need a copy there. But strmap keeps its own copy of the name, as well.
Using a bare hashmap instead of strmap means we could use the name for
both, but at the cost of extra code (e.g., our own comparison function).
Likewise, strmap has a feature to use a pointer to the in-struct name at
the cost of a little extra code. I didn't do either here, as simple code
seemed more important than squeezing out a few bytes of efficiency.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-01-28 07:34:31 +01:00
|
|
|
strmap_put(&rerere_dirs, hex, rr_dir);
|
|
|
|
|
|
2015-07-17 00:47:13 +02:00
|
|
|
scan_rerere_dir(rr_dir);
|
rerere: split conflict ID further
The plan is to keep assigning the backward compatible conflict ID
based on the hash of the (normalized) text of conflicts, keep using
that conflict ID as the directory name under $GIT_DIR/rr-cache/, but
allow each conflicted path to use a separate "variant" to record
resolutions, i.e. having more than one <preimage,postimage> pairs
under $GIT_DIR/rr-cache/$ID/ directory. As the first step in that
direction, separate the shared "conflict ID" out of the rerere_id
structure.
The plan is to keep information per $ID in rerere_dir, that can be
shared among rerere_id that is per conflicted path.
When we are done with rerere(), which can be directly called from
other programs like "git apply", "git commit" and "git merge", the
shared rerere_dir structures can be freed entirely, so they are not
reference-counted and they are not freed when we release rerere_id's
that reference them.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-16 23:50:05 +02:00
|
|
|
}
|
rerere: use strmap to store rerere directories
We store a struct for each directory we access under .git/rr-cache. The
structs are kept in an array sorted by the binary hash associated with
their name (and we do lookups with a binary search).
This works OK, but there are a few small downsides:
- the amount of code isn't huge, but it's more than we'd need using one
of our other stock data structures
- the insertion into a sorted array is quadratic (though in practice
it's unlikely anybody has enough conflicts for this to matter)
- it's intimately tied to the representation of an object hash. This
isn't a big deal, as the conflict ids we generate use the same hash,
but it produces a few awkward bits (e.g., we are the only user of
hash_pos() that is not using object_id).
Let's instead just treat the directory names as strings, and store them
in a strmap. This is less code, and removes the use of hash_pos().
Insertion is now non-quadratic, though we probably use a bit more
memory. Besides the hash table overhead, and storing hex bytes instead
of a binary hash, we actually store each name twice. Other code expects
to access the name of a rerere_dir struct from the struct itself, so we
need a copy there. But strmap keeps its own copy of the name, as well.
Using a bare hashmap instead of strmap means we could use the name for
both, but at the cost of extra code (e.g., our own comparison function).
Likewise, strmap has a feature to use a pointer to the in-struct name at
the cost of a little extra code. I didn't do either here, as simple code
seemed more important than squeezing out a few bytes of efficiency.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-01-28 07:34:31 +01:00
|
|
|
return rr_dir;
|
2008-07-09 14:58:57 +02:00
|
|
|
}
|
|
|
|
|
|
2015-07-05 02:38:34 +02:00
|
|
|
static int has_rerere_resolution(const struct rerere_id *id)
|
2008-07-09 14:58:57 +02:00
|
|
|
{
|
2015-07-17 22:28:31 +02:00
|
|
|
const int both = RR_HAS_POSTIMAGE|RR_HAS_PREIMAGE;
|
2015-07-23 23:23:24 +02:00
|
|
|
int variant = id->variant;
|
2015-07-05 02:38:34 +02:00
|
|
|
|
2015-07-23 23:23:24 +02:00
|
|
|
if (variant < 0)
|
|
|
|
|
return 0;
|
|
|
|
|
return ((id->collection->status[variant] & both) == both);
|
2008-07-09 14:58:57 +02:00
|
|
|
}
|
|
|
|
|
|
2015-07-05 02:38:34 +02:00
|
|
|
static struct rerere_id *new_rerere_id_hex(char *hex)
|
|
|
|
|
{
|
|
|
|
|
struct rerere_id *id = xmalloc(sizeof(*id));
|
rerere: split conflict ID further
The plan is to keep assigning the backward compatible conflict ID
based on the hash of the (normalized) text of conflicts, keep using
that conflict ID as the directory name under $GIT_DIR/rr-cache/, but
allow each conflicted path to use a separate "variant" to record
resolutions, i.e. having more than one <preimage,postimage> pairs
under $GIT_DIR/rr-cache/$ID/ directory. As the first step in that
direction, separate the shared "conflict ID" out of the rerere_id
structure.
The plan is to keep information per $ID in rerere_dir, that can be
shared among rerere_id that is per conflicted path.
When we are done with rerere(), which can be directly called from
other programs like "git apply", "git commit" and "git merge", the
shared rerere_dir structures can be freed entirely, so they are not
reference-counted and they are not freed when we release rerere_id's
that reference them.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-16 23:50:05 +02:00
|
|
|
id->collection = find_rerere_dir(hex);
|
2015-07-23 23:23:24 +02:00
|
|
|
id->variant = -1; /* not known yet */
|
2015-07-05 02:38:34 +02:00
|
|
|
return id;
|
|
|
|
|
}
|
|
|
|
|
|
2019-08-18 22:04:25 +02:00
|
|
|
static struct rerere_id *new_rerere_id(unsigned char *hash)
|
2015-07-05 02:38:34 +02:00
|
|
|
{
|
2019-08-18 22:04:25 +02:00
|
|
|
return new_rerere_id_hex(hash_to_hex(hash));
|
2008-07-09 14:58:57 +02:00
|
|
|
}
|
|
|
|
|
|
2015-07-01 07:36:35 +02:00
|
|
|
/*
|
|
|
|
|
* $GIT_DIR/MERGE_RR file is a collection of records, each of which is
|
|
|
|
|
* "conflict ID", a HT and pathname, terminated with a NUL, and is
|
|
|
|
|
* used to keep track of the set of paths that "rerere" may need to
|
|
|
|
|
* work on (i.e. what is left by the previous invocation of "git
|
|
|
|
|
* rerere" during the current conflict resolution session).
|
|
|
|
|
*/
|
2018-11-10 06:49:09 +01:00
|
|
|
static void read_rr(struct repository *r, struct string_list *rr)
|
2008-07-09 14:58:57 +02:00
|
|
|
{
|
2015-06-29 00:51:59 +02:00
|
|
|
struct strbuf buf = STRBUF_INIT;
|
2018-11-10 06:49:09 +01:00
|
|
|
FILE *in = fopen_or_warn(git_path_merge_rr(r), "r");
|
2015-06-29 00:51:59 +02:00
|
|
|
|
2008-07-09 14:58:57 +02:00
|
|
|
if (!in)
|
|
|
|
|
return;
|
2015-06-29 00:51:59 +02:00
|
|
|
while (!strbuf_getwholeline(&buf, in, '\0')) {
|
|
|
|
|
char *path;
|
2018-10-15 02:02:02 +02:00
|
|
|
unsigned char hash[GIT_MAX_RAWSZ];
|
2015-07-05 02:38:34 +02:00
|
|
|
struct rerere_id *id;
|
2015-07-23 23:23:24 +02:00
|
|
|
int variant;
|
2018-10-15 02:02:02 +02:00
|
|
|
const unsigned hexsz = the_hash_algo->hexsz;
|
2015-06-29 00:51:59 +02:00
|
|
|
|
|
|
|
|
/* There has to be the hash, tab, path and then NUL */
|
2018-10-15 02:02:02 +02:00
|
|
|
if (buf.len < hexsz + 2 || get_sha1_hex(buf.buf, hash))
|
2018-08-05 19:20:30 +02:00
|
|
|
die(_("corrupt MERGE_RR"));
|
2015-06-29 00:51:59 +02:00
|
|
|
|
2018-10-15 02:02:02 +02:00
|
|
|
if (buf.buf[hexsz] != '.') {
|
2015-07-23 23:23:24 +02:00
|
|
|
variant = 0;
|
2018-10-15 02:02:02 +02:00
|
|
|
path = buf.buf + hexsz;
|
2015-07-23 23:23:24 +02:00
|
|
|
} else {
|
|
|
|
|
errno = 0;
|
2018-10-15 02:02:02 +02:00
|
|
|
variant = strtol(buf.buf + hexsz + 1, &path, 10);
|
2015-07-23 23:23:24 +02:00
|
|
|
if (errno)
|
2018-08-05 19:20:30 +02:00
|
|
|
die(_("corrupt MERGE_RR"));
|
2015-07-23 23:23:24 +02:00
|
|
|
}
|
|
|
|
|
if (*(path++) != '\t')
|
2018-08-05 19:20:30 +02:00
|
|
|
die(_("corrupt MERGE_RR"));
|
2018-10-15 02:02:02 +02:00
|
|
|
buf.buf[hexsz] = '\0';
|
2015-07-05 02:38:34 +02:00
|
|
|
id = new_rerere_id_hex(buf.buf);
|
2015-07-23 23:23:24 +02:00
|
|
|
id->variant = variant;
|
2015-07-05 02:38:34 +02:00
|
|
|
string_list_insert(rr, path)->util = id;
|
2008-07-09 14:58:57 +02:00
|
|
|
}
|
2015-06-29 00:51:59 +02:00
|
|
|
strbuf_release(&buf);
|
2008-07-09 14:58:57 +02:00
|
|
|
fclose(in);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static struct lock_file write_lock;
|
|
|
|
|
|
2008-07-21 20:03:49 +02:00
|
|
|
static int write_rr(struct string_list *rr, int out_fd)
|
2008-07-09 14:58:57 +02:00
|
|
|
{
|
|
|
|
|
int i;
|
|
|
|
|
for (i = 0; i < rr->nr; i++) {
|
2015-06-29 01:28:00 +02:00
|
|
|
struct strbuf buf = STRBUF_INIT;
|
2015-07-05 02:38:34 +02:00
|
|
|
struct rerere_id *id;
|
2015-06-29 01:28:00 +02:00
|
|
|
|
|
|
|
|
assert(rr->items[i].util != RERERE_RESOLVED);
|
2015-07-05 02:38:34 +02:00
|
|
|
|
|
|
|
|
id = rr->items[i].util;
|
|
|
|
|
if (!id)
|
2008-07-09 14:58:57 +02:00
|
|
|
continue;
|
2015-07-23 23:23:24 +02:00
|
|
|
assert(id->variant >= 0);
|
|
|
|
|
if (0 < id->variant)
|
|
|
|
|
strbuf_addf(&buf, "%s.%d\t%s%c",
|
|
|
|
|
rerere_id_hex(id), id->variant,
|
|
|
|
|
rr->items[i].string, 0);
|
|
|
|
|
else
|
|
|
|
|
strbuf_addf(&buf, "%s\t%s%c",
|
|
|
|
|
rerere_id_hex(id),
|
|
|
|
|
rr->items[i].string, 0);
|
|
|
|
|
|
avoid "write_in_full(fd, buf, len) != len" pattern
The return value of write_in_full() is either "-1", or the
requested number of bytes[1]. If we make a partial write
before seeing an error, we still return -1, not a partial
value. This goes back to f6aa66cb95 (write_in_full: really
write in full or return error on disk full., 2007-01-11).
So checking anything except "was the return value negative"
is pointless. And there are a couple of reasons not to do
so:
1. It can do a funny signed/unsigned comparison. If your
"len" is signed (e.g., a size_t) then the compiler will
promote the "-1" to its unsigned variant.
This works out for "!= len" (unless you really were
trying to write the maximum size_t bytes), but is a
bug if you check "< len" (an example of which was fixed
recently in config.c).
We should avoid promoting the mental model that you
need to check the length at all, so that new sites are
not tempted to copy us.
2. Checking for a negative value is shorter to type,
especially when the length is an expression.
3. Linus says so. In d34cf19b89 (Clean up write_in_full()
users, 2007-01-11), right after the write_in_full()
semantics were changed, he wrote:
I really wish every "write_in_full()" user would just
check against "<0" now, but this fixes the nasty and
stupid ones.
Appeals to authority aside, this makes it clear that
writing it this way does not have an intentional
benefit. It's a historical curiosity that we never
bothered to clean up (and which was undoubtedly
cargo-culted into new sites).
So let's convert these obviously-correct cases (this
includes write_str_in_full(), which is just a wrapper for
write_in_full()).
[1] A careful reader may notice there is one way that
write_in_full() can return a different value. If we ask
write() to write N bytes and get a return value that is
_larger_ than N, we could return a larger total. But
besides the fact that this would imply a totally broken
version of write(), it would already invoke undefined
behavior. Our internal remaining counter is an unsigned
size_t, which means that subtracting too many byte will
wrap it around to a very large number. So we'll instantly
begin reading off the end of the buffer, trying to write
gigabytes (or petabytes) of data.
Signed-off-by: Jeff King <peff@peff.net>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-13 19:16:03 +02:00
|
|
|
if (write_in_full(out_fd, buf.buf, buf.len) < 0)
|
2018-08-05 19:20:30 +02:00
|
|
|
die(_("unable to write rerere record"));
|
2015-06-29 01:28:00 +02:00
|
|
|
|
|
|
|
|
strbuf_release(&buf);
|
2008-07-09 14:58:57 +02:00
|
|
|
}
|
|
|
|
|
if (commit_lock_file(&write_lock) != 0)
|
2018-08-05 19:20:30 +02:00
|
|
|
die(_("unable to write rerere record"));
|
2008-07-09 14:58:57 +02:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2015-07-01 07:33:19 +02:00
|
|
|
/*
|
|
|
|
|
* "rerere" interacts with conflicted file contents using this I/O
|
|
|
|
|
* abstraction. It reads a conflicted contents from one place via
|
|
|
|
|
* "getline()" method, and optionally can write it out after
|
|
|
|
|
* normalizing the conflicted hunks to the "output". Subclasses of
|
|
|
|
|
* rerere_io embed this structure at the beginning of their own
|
|
|
|
|
* rerere_io object.
|
|
|
|
|
*/
|
|
|
|
|
struct rerere_io {
|
|
|
|
|
int (*getline)(struct strbuf *, struct rerere_io *);
|
|
|
|
|
FILE *output;
|
|
|
|
|
int wrerror;
|
|
|
|
|
/* some more stuff */
|
|
|
|
|
};
|
|
|
|
|
|
2008-12-05 01:35:48 +01:00
|
|
|
static void ferr_write(const void *p, size_t count, FILE *fp, int *err)
|
|
|
|
|
{
|
|
|
|
|
if (!count || *err)
|
|
|
|
|
return;
|
|
|
|
|
if (fwrite(p, count, 1, fp) != 1)
|
|
|
|
|
*err = errno;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline void ferr_puts(const char *s, FILE *fp, int *err)
|
|
|
|
|
{
|
|
|
|
|
ferr_write(s, strlen(s), fp, err);
|
|
|
|
|
}
|
|
|
|
|
|
2009-12-25 23:34:53 +01:00
|
|
|
static void rerere_io_putstr(const char *str, struct rerere_io *io)
|
|
|
|
|
{
|
|
|
|
|
if (io->output)
|
|
|
|
|
ferr_puts(str, io->output, &io->wrerror);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void rerere_io_putmem(const char *mem, size_t sz, struct rerere_io *io)
|
|
|
|
|
{
|
|
|
|
|
if (io->output)
|
|
|
|
|
ferr_write(mem, sz, io->output, &io->wrerror);
|
|
|
|
|
}
|
|
|
|
|
|
2015-07-01 07:33:19 +02:00
|
|
|
/*
|
|
|
|
|
* Subclass of rerere_io that reads from an on-disk file
|
|
|
|
|
*/
|
2009-12-25 23:34:53 +01:00
|
|
|
struct rerere_io_file {
|
|
|
|
|
struct rerere_io io;
|
|
|
|
|
FILE *input;
|
|
|
|
|
};
|
|
|
|
|
|
2015-07-01 07:33:19 +02:00
|
|
|
/*
|
|
|
|
|
* ... and its getline() method implementation
|
|
|
|
|
*/
|
2009-12-25 23:34:53 +01:00
|
|
|
static int rerere_file_getline(struct strbuf *sb, struct rerere_io *io_)
|
|
|
|
|
{
|
|
|
|
|
struct rerere_io_file *io = (struct rerere_io_file *)io_;
|
|
|
|
|
return strbuf_getwholeline(sb, io->input, '\n');
|
|
|
|
|
}
|
|
|
|
|
|
2015-06-30 00:05:24 +02:00
|
|
|
/*
|
|
|
|
|
* Require the exact number of conflict marker letters, no more, no
|
|
|
|
|
* less, followed by SP or any whitespace
|
|
|
|
|
* (including LF).
|
|
|
|
|
*/
|
|
|
|
|
static int is_cmarker(char *buf, int marker_char, int marker_size)
|
2010-01-17 08:06:45 +01:00
|
|
|
{
|
2015-06-30 00:05:24 +02:00
|
|
|
int want_sp;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* The beginning of our version and the end of their version
|
|
|
|
|
* always are labeled like "<<<<< ours" or ">>>>> theirs",
|
|
|
|
|
* hence we set want_sp for them. Note that the version from
|
|
|
|
|
* the common ancestor in diff3-style output is not always
|
|
|
|
|
* labelled (e.g. "||||| common" is often seen but "|||||"
|
|
|
|
|
* alone is also valid), so we do not set want_sp.
|
|
|
|
|
*/
|
|
|
|
|
want_sp = (marker_char == '<') || (marker_char == '>');
|
|
|
|
|
|
2010-01-17 08:06:45 +01:00
|
|
|
while (marker_size--)
|
|
|
|
|
if (*buf++ != marker_char)
|
|
|
|
|
return 0;
|
|
|
|
|
if (want_sp && *buf != ' ')
|
|
|
|
|
return 0;
|
|
|
|
|
return isspace(*buf);
|
|
|
|
|
}
|
|
|
|
|
|
2018-08-05 19:20:35 +02:00
|
|
|
static void rerere_strbuf_putconflict(struct strbuf *buf, int ch, size_t size)
|
|
|
|
|
{
|
|
|
|
|
strbuf_addchars(buf, ch, size);
|
|
|
|
|
strbuf_addch(buf, '\n');
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int handle_conflict(struct strbuf *out, struct rerere_io *io,
|
2018-10-15 02:02:02 +02:00
|
|
|
int marker_size, git_hash_ctx *ctx)
|
2008-07-09 14:58:57 +02:00
|
|
|
{
|
2008-08-29 19:12:23 +02:00
|
|
|
enum {
|
2018-08-05 19:20:34 +02:00
|
|
|
RR_SIDE_1 = 0, RR_SIDE_2, RR_ORIGINAL
|
|
|
|
|
} hunk = RR_SIDE_1;
|
2008-10-09 21:12:12 +02:00
|
|
|
struct strbuf one = STRBUF_INIT, two = STRBUF_INIT;
|
2018-08-05 19:20:36 +02:00
|
|
|
struct strbuf buf = STRBUF_INIT, conflict = STRBUF_INIT;
|
2018-08-05 19:20:34 +02:00
|
|
|
int has_conflicts = -1;
|
2008-07-09 14:58:57 +02:00
|
|
|
|
2009-12-25 23:34:53 +01:00
|
|
|
while (!io->getline(&buf, io)) {
|
2015-06-30 00:05:24 +02:00
|
|
|
if (is_cmarker(buf.buf, '<', marker_size)) {
|
2018-08-05 19:20:36 +02:00
|
|
|
if (handle_conflict(&conflict, io, marker_size, NULL) < 0)
|
|
|
|
|
break;
|
|
|
|
|
if (hunk == RR_SIDE_1)
|
|
|
|
|
strbuf_addbuf(&one, &conflict);
|
|
|
|
|
else
|
|
|
|
|
strbuf_addbuf(&two, &conflict);
|
|
|
|
|
strbuf_release(&conflict);
|
2015-06-30 00:05:24 +02:00
|
|
|
} else if (is_cmarker(buf.buf, '|', marker_size)) {
|
2008-08-29 19:12:23 +02:00
|
|
|
if (hunk != RR_SIDE_1)
|
2018-08-05 19:20:34 +02:00
|
|
|
break;
|
2008-08-29 19:24:45 +02:00
|
|
|
hunk = RR_ORIGINAL;
|
2015-06-30 00:05:24 +02:00
|
|
|
} else if (is_cmarker(buf.buf, '=', marker_size)) {
|
2008-08-29 19:24:45 +02:00
|
|
|
if (hunk != RR_SIDE_1 && hunk != RR_ORIGINAL)
|
2018-08-05 19:20:34 +02:00
|
|
|
break;
|
2008-08-29 19:12:23 +02:00
|
|
|
hunk = RR_SIDE_2;
|
2015-06-30 00:05:24 +02:00
|
|
|
} else if (is_cmarker(buf.buf, '>', marker_size)) {
|
2008-08-29 19:12:23 +02:00
|
|
|
if (hunk != RR_SIDE_2)
|
2018-08-05 19:20:34 +02:00
|
|
|
break;
|
2008-07-09 14:58:57 +02:00
|
|
|
if (strbuf_cmp(&one, &two) > 0)
|
|
|
|
|
strbuf_swap(&one, &two);
|
2018-08-05 19:20:33 +02:00
|
|
|
has_conflicts = 1;
|
2018-08-05 19:20:35 +02:00
|
|
|
rerere_strbuf_putconflict(out, '<', marker_size);
|
|
|
|
|
strbuf_addbuf(out, &one);
|
|
|
|
|
rerere_strbuf_putconflict(out, '=', marker_size);
|
|
|
|
|
strbuf_addbuf(out, &two);
|
|
|
|
|
rerere_strbuf_putconflict(out, '>', marker_size);
|
2018-08-05 19:20:34 +02:00
|
|
|
if (ctx) {
|
2018-10-15 02:02:02 +02:00
|
|
|
the_hash_algo->update_fn(ctx, one.buf ?
|
|
|
|
|
one.buf : "",
|
|
|
|
|
one.len + 1);
|
|
|
|
|
the_hash_algo->update_fn(ctx, two.buf ?
|
|
|
|
|
two.buf : "",
|
|
|
|
|
two.len + 1);
|
2008-07-09 14:58:57 +02:00
|
|
|
}
|
2018-08-05 19:20:34 +02:00
|
|
|
break;
|
2008-08-29 19:12:23 +02:00
|
|
|
} else if (hunk == RR_SIDE_1)
|
2014-07-10 10:52:21 +02:00
|
|
|
strbuf_addbuf(&one, &buf);
|
2008-08-29 19:24:45 +02:00
|
|
|
else if (hunk == RR_ORIGINAL)
|
|
|
|
|
; /* discard */
|
2008-08-29 19:12:23 +02:00
|
|
|
else if (hunk == RR_SIDE_2)
|
2014-07-10 10:52:21 +02:00
|
|
|
strbuf_addbuf(&two, &buf);
|
2008-07-09 14:58:57 +02:00
|
|
|
}
|
|
|
|
|
strbuf_release(&one);
|
|
|
|
|
strbuf_release(&two);
|
2009-12-25 22:55:29 +01:00
|
|
|
strbuf_release(&buf);
|
2008-07-09 14:58:57 +02:00
|
|
|
|
2018-08-05 19:20:34 +02:00
|
|
|
return has_conflicts;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Read contents a file with conflicts, normalize the conflicts
|
|
|
|
|
* by (1) discarding the common ancestor version in diff3-style,
|
|
|
|
|
* (2) reordering our side and their side so that whichever sorts
|
|
|
|
|
* alphabetically earlier comes before the other one, while
|
|
|
|
|
* computing the "conflict ID", which is just an SHA-1 hash of
|
|
|
|
|
* one side of the conflict, NUL, the other side of the conflict,
|
|
|
|
|
* and NUL concatenated together.
|
|
|
|
|
*
|
|
|
|
|
* Return 1 if conflict hunks are found, 0 if there are no conflict
|
2019-11-05 18:07:23 +01:00
|
|
|
* hunks and -1 if an error occurred.
|
2018-08-05 19:20:34 +02:00
|
|
|
*/
|
2018-10-15 02:02:02 +02:00
|
|
|
static int handle_path(unsigned char *hash, struct rerere_io *io, int marker_size)
|
2018-08-05 19:20:34 +02:00
|
|
|
{
|
2018-10-15 02:02:02 +02:00
|
|
|
git_hash_ctx ctx;
|
2018-08-05 19:20:35 +02:00
|
|
|
struct strbuf buf = STRBUF_INIT, out = STRBUF_INIT;
|
2018-08-05 19:20:34 +02:00
|
|
|
int has_conflicts = 0;
|
2018-10-15 02:02:02 +02:00
|
|
|
if (hash)
|
|
|
|
|
the_hash_algo->init_fn(&ctx);
|
2018-08-05 19:20:34 +02:00
|
|
|
|
|
|
|
|
while (!io->getline(&buf, io)) {
|
|
|
|
|
if (is_cmarker(buf.buf, '<', marker_size)) {
|
2018-08-05 19:20:35 +02:00
|
|
|
has_conflicts = handle_conflict(&out, io, marker_size,
|
2018-10-15 02:02:02 +02:00
|
|
|
hash ? &ctx : NULL);
|
2018-08-05 19:20:34 +02:00
|
|
|
if (has_conflicts < 0)
|
|
|
|
|
break;
|
2018-08-05 19:20:35 +02:00
|
|
|
rerere_io_putmem(out.buf, out.len, io);
|
|
|
|
|
strbuf_reset(&out);
|
2018-08-05 19:20:34 +02:00
|
|
|
} else
|
|
|
|
|
rerere_io_putstr(buf.buf, io);
|
|
|
|
|
}
|
|
|
|
|
strbuf_release(&buf);
|
2018-08-05 19:20:35 +02:00
|
|
|
strbuf_release(&out);
|
2018-08-05 19:20:34 +02:00
|
|
|
|
2018-10-15 02:02:02 +02:00
|
|
|
if (hash)
|
|
|
|
|
the_hash_algo->final_fn(hash, &ctx);
|
2018-08-05 19:20:34 +02:00
|
|
|
|
2018-08-05 19:20:33 +02:00
|
|
|
return has_conflicts;
|
2009-12-25 23:34:53 +01:00
|
|
|
}
|
|
|
|
|
|
2015-07-01 07:40:35 +02:00
|
|
|
/*
|
|
|
|
|
* Scan the path for conflicts, do the "handle_path()" thing above, and
|
|
|
|
|
* return the number of conflict hunks found.
|
|
|
|
|
*/
|
2018-10-30 07:43:42 +01:00
|
|
|
static int handle_file(struct index_state *istate,
|
|
|
|
|
const char *path, unsigned char *hash, const char *output)
|
2009-12-25 23:34:53 +01:00
|
|
|
{
|
2018-08-05 19:20:33 +02:00
|
|
|
int has_conflicts = 0;
|
2009-12-25 23:34:53 +01:00
|
|
|
struct rerere_io_file io;
|
2018-09-21 17:57:32 +02:00
|
|
|
int marker_size = ll_merge_marker_size(istate, path);
|
2009-12-25 23:34:53 +01:00
|
|
|
|
|
|
|
|
memset(&io, 0, sizeof(io));
|
|
|
|
|
io.io.getline = rerere_file_getline;
|
|
|
|
|
io.input = fopen(path, "r");
|
|
|
|
|
io.io.wrerror = 0;
|
|
|
|
|
if (!io.input)
|
2018-08-05 19:20:30 +02:00
|
|
|
return error_errno(_("could not open '%s'"), path);
|
2009-12-25 23:34:53 +01:00
|
|
|
|
|
|
|
|
if (output) {
|
|
|
|
|
io.io.output = fopen(output, "w");
|
|
|
|
|
if (!io.io.output) {
|
2018-08-05 19:20:30 +02:00
|
|
|
error_errno(_("could not write '%s'"), output);
|
2009-12-25 23:34:53 +01:00
|
|
|
fclose(io.input);
|
2017-05-09 12:11:33 +02:00
|
|
|
return -1;
|
2009-12-25 23:34:53 +01:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2018-10-15 02:02:02 +02:00
|
|
|
has_conflicts = handle_path(hash, (struct rerere_io *)&io, marker_size);
|
2009-12-25 23:34:53 +01:00
|
|
|
|
|
|
|
|
fclose(io.input);
|
|
|
|
|
if (io.io.wrerror)
|
2018-08-05 19:20:30 +02:00
|
|
|
error(_("there were errors while writing '%s' (%s)"),
|
2009-12-25 23:34:53 +01:00
|
|
|
path, strerror(io.io.wrerror));
|
|
|
|
|
if (io.io.output && fclose(io.io.output))
|
2018-08-05 19:20:30 +02:00
|
|
|
io.io.wrerror = error_errno(_("failed to flush '%s'"), path);
|
2009-12-25 23:34:53 +01:00
|
|
|
|
2018-08-05 19:20:33 +02:00
|
|
|
if (has_conflicts < 0) {
|
2008-07-09 14:58:57 +02:00
|
|
|
if (output)
|
2009-04-29 23:22:56 +02:00
|
|
|
unlink_or_warn(output);
|
2018-08-05 19:20:30 +02:00
|
|
|
return error(_("could not parse conflict hunks in '%s'"), path);
|
2008-07-09 14:58:57 +02:00
|
|
|
}
|
2009-12-25 23:34:53 +01:00
|
|
|
if (io.io.wrerror)
|
2008-12-05 01:35:48 +01:00
|
|
|
return -1;
|
2018-08-05 19:20:33 +02:00
|
|
|
return has_conflicts;
|
2008-07-09 14:58:57 +02:00
|
|
|
}
|
|
|
|
|
|
2015-07-01 07:36:35 +02:00
|
|
|
/*
|
|
|
|
|
* Look at a cache entry at "i" and see if it is not conflicting,
|
|
|
|
|
* conflicting and we are willing to handle, or conflicting and
|
|
|
|
|
* we are unable to handle, and return the determination in *type.
|
|
|
|
|
* Return the cache index to be looked at next, by skipping the
|
|
|
|
|
* stages we have already looked at in this invocation of this
|
|
|
|
|
* function.
|
|
|
|
|
*/
|
2018-09-21 17:57:32 +02:00
|
|
|
static int check_one_conflict(struct index_state *istate, int i, int *type)
|
2008-07-09 14:58:57 +02:00
|
|
|
{
|
2018-09-21 17:57:32 +02:00
|
|
|
const struct cache_entry *e = istate->cache[i];
|
2011-02-16 11:47:44 +01:00
|
|
|
|
|
|
|
|
if (!ce_stage(e)) {
|
|
|
|
|
*type = RESOLVED;
|
|
|
|
|
return i + 1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
*type = PUNTED;
|
2018-10-19 06:34:02 +02:00
|
|
|
while (i < istate->cache_nr && ce_stage(istate->cache[i]) == 1)
|
2015-06-28 23:35:13 +02:00
|
|
|
i++;
|
2011-02-16 11:47:44 +01:00
|
|
|
|
|
|
|
|
/* Only handle regular files with both stages #2 and #3 */
|
2018-09-21 17:57:32 +02:00
|
|
|
if (i + 1 < istate->cache_nr) {
|
|
|
|
|
const struct cache_entry *e2 = istate->cache[i];
|
|
|
|
|
const struct cache_entry *e3 = istate->cache[i + 1];
|
2008-07-09 14:58:57 +02:00
|
|
|
if (ce_stage(e2) == 2 &&
|
|
|
|
|
ce_stage(e3) == 3 &&
|
2011-02-16 11:47:44 +01:00
|
|
|
ce_same_name(e, e3) &&
|
2008-07-09 14:58:57 +02:00
|
|
|
S_ISREG(e2->ce_mode) &&
|
2011-02-16 11:47:44 +01:00
|
|
|
S_ISREG(e3->ce_mode))
|
|
|
|
|
*type = THREE_STAGED;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Skip the entries with the same name */
|
2018-09-21 17:57:32 +02:00
|
|
|
while (i < istate->cache_nr && ce_same_name(e, istate->cache[i]))
|
2011-02-16 11:47:44 +01:00
|
|
|
i++;
|
|
|
|
|
return i;
|
|
|
|
|
}
|
|
|
|
|
|
2015-07-01 07:36:35 +02:00
|
|
|
/*
|
|
|
|
|
* Scan the index and find paths that have conflicts that rerere can
|
|
|
|
|
* handle, i.e. the ones that has both stages #2 and #3.
|
|
|
|
|
*
|
|
|
|
|
* NEEDSWORK: we do not record or replay a previous "resolve by
|
|
|
|
|
* deletion" for a delete-modify conflict, as that is inherently risky
|
|
|
|
|
* without knowing what modification is being discarded. The only
|
|
|
|
|
* safe case, i.e. both side doing the deletion and modification that
|
|
|
|
|
* are identical to the previous round, might want to be handled,
|
|
|
|
|
* though.
|
|
|
|
|
*/
|
2018-09-21 17:57:32 +02:00
|
|
|
static int find_conflict(struct repository *r, struct string_list *conflict)
|
2011-02-16 11:47:44 +01:00
|
|
|
{
|
|
|
|
|
int i;
|
2018-09-21 17:57:32 +02:00
|
|
|
|
2019-01-12 03:13:26 +01:00
|
|
|
if (repo_read_index(r) < 0)
|
2018-08-05 19:20:30 +02:00
|
|
|
return error(_("index file corrupt"));
|
2011-02-16 11:47:44 +01:00
|
|
|
|
2018-09-21 17:57:32 +02:00
|
|
|
for (i = 0; i < r->index->cache_nr;) {
|
2011-02-16 11:47:44 +01:00
|
|
|
int conflict_type;
|
2018-09-21 17:57:32 +02:00
|
|
|
const struct cache_entry *e = r->index->cache[i];
|
|
|
|
|
i = check_one_conflict(r->index, i, &conflict_type);
|
2011-02-16 11:47:44 +01:00
|
|
|
if (conflict_type == THREE_STAGED)
|
|
|
|
|
string_list_insert(conflict, (const char *)e->name);
|
|
|
|
|
}
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2015-07-01 07:36:35 +02:00
|
|
|
/*
|
|
|
|
|
* The merge_rr list is meant to hold outstanding conflicted paths
|
|
|
|
|
* that rerere could handle. Abuse the list by adding other types of
|
|
|
|
|
* entries to allow the caller to show "rerere remaining".
|
|
|
|
|
*
|
|
|
|
|
* - Conflicted paths that rerere does not handle are added
|
|
|
|
|
* - Conflicted paths that have been resolved are marked as such
|
|
|
|
|
* by storing RERERE_RESOLVED to .util field (where conflict ID
|
|
|
|
|
* is expected to be stored).
|
|
|
|
|
*
|
|
|
|
|
* Do *not* write MERGE_RR file out after calling this function.
|
|
|
|
|
*
|
|
|
|
|
* NEEDSWORK: we may want to fix the caller that implements "rerere
|
|
|
|
|
* remaining" to do this without abusing merge_rr.
|
|
|
|
|
*/
|
2018-09-21 17:57:32 +02:00
|
|
|
int rerere_remaining(struct repository *r, struct string_list *merge_rr)
|
2011-02-16 11:47:44 +01:00
|
|
|
{
|
|
|
|
|
int i;
|
2018-09-21 17:57:32 +02:00
|
|
|
|
2018-11-10 06:49:09 +01:00
|
|
|
if (setup_rerere(r, merge_rr, RERERE_READONLY))
|
rerere: release lockfile in non-writing functions
There's a bug in builtin/am.c in which we take a lock on
MERGE_RR recursively. But rather than fix am.c, this patch
fixes the confusing interface from rerere.c that caused the
bug. Read on for the gory details.
The setup_rerere() function both reads the existing MERGE_RR
file, and takes MERGE_RR.lock. In the rerere() and
rerere_forget() functions, we end up in write_rr(), which
will then commit the lock file.
But for functions like rerere_clear() that do not write to
MERGE_RR, we expect the caller to have handled
setup_rerere(). That caller would then need to release the
lockfile, but it can't; the lock struct is local to
rerere.c.
For builtin/rerere.c, this is OK. We run a single rerere
operation and then exit immediately, which has the side
effect of rolling back the lockfile.
But in builtin/am.c, this is actively wrong. If we run "git
am -3 --skip", we call setup-rerere twice without releasing
the lock:
1. The "--skip" causes us to call am_rerere_clear(), which
calls setup_rerere(), but never drops the lock.
2. We then proceed to the next patch.
3. The "--3way" may cause us to call rerere() to handle
conflicts in that patch, but we are already holding the
lock. The lockfile code dies with:
BUG: prepare_tempfile_object called for active object
We could fix this by having rerere_clear() call
rollback_lock_file(). But it feels a bit odd for it to roll
back a lockfile that it did not itself take. So let's
simplify the interface further, and handle setup_rerere in
the function itself, taking away the question from the
caller over whether they need to do so.
We can give rerere_gc() the same treatment, as well (even
though it doesn't have any callers besides builtin/rerere.c
at this point). Note that these functions don't take flags
from their callers to pass along to setup_rerere; that's OK,
because the flags would not be meaningful for what they are
doing.
Both of those functions need to hold the lock because even
though they do not write to MERGE_RR, they are still writing
and should be protected from a simultaneous "rerere" run.
But rerere_remaining(), "rerere diff", and "rerere status"
are all read-only operations. They want to setup_rerere(),
but do not care about taking the lock in the first place.
Since our update of MERGE_RR is the usual atomic rename done
by commit_lock_file, they can just do a lockless read. For
that, we teach setup_rerere a READONLY flag to avoid the
lock.
As a bonus, this pushes builtin/rerere.c's setup_rerere call
closer to the functions that use it. Which means that "git
rerere totally-bogus-command" will no longer silently
exit(0) in a repository without rerere enabled.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-02 00:14:09 +02:00
|
|
|
return 0;
|
2019-01-12 03:13:26 +01:00
|
|
|
if (repo_read_index(r) < 0)
|
2018-08-05 19:20:30 +02:00
|
|
|
return error(_("index file corrupt"));
|
2011-02-16 11:47:44 +01:00
|
|
|
|
2018-09-21 17:57:32 +02:00
|
|
|
for (i = 0; i < r->index->cache_nr;) {
|
2011-02-16 11:47:44 +01:00
|
|
|
int conflict_type;
|
2018-09-21 17:57:32 +02:00
|
|
|
const struct cache_entry *e = r->index->cache[i];
|
|
|
|
|
i = check_one_conflict(r->index, i, &conflict_type);
|
2011-02-16 11:47:44 +01:00
|
|
|
if (conflict_type == PUNTED)
|
|
|
|
|
string_list_insert(merge_rr, (const char *)e->name);
|
|
|
|
|
else if (conflict_type == RESOLVED) {
|
|
|
|
|
struct string_list_item *it;
|
|
|
|
|
it = string_list_lookup(merge_rr, (const char *)e->name);
|
2022-05-02 18:50:37 +02:00
|
|
|
if (it) {
|
2015-07-05 02:38:34 +02:00
|
|
|
free_rerere_id(it);
|
2011-02-16 11:47:44 +01:00
|
|
|
it->util = RERERE_RESOLVED;
|
|
|
|
|
}
|
2008-07-09 14:58:57 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2016-03-11 23:53:05 +01:00
|
|
|
/*
|
|
|
|
|
* Try using the given conflict resolution "ID" to see
|
|
|
|
|
* if that recorded conflict resolves cleanly what we
|
|
|
|
|
* got in the "cur".
|
|
|
|
|
*/
|
2018-09-21 17:57:32 +02:00
|
|
|
static int try_merge(struct index_state *istate,
|
|
|
|
|
const struct rerere_id *id, const char *path,
|
2016-03-11 23:53:05 +01:00
|
|
|
mmfile_t *cur, mmbuffer_t *result)
|
|
|
|
|
{
|
2022-02-02 03:37:30 +01:00
|
|
|
enum ll_merge_result ret;
|
2016-03-11 23:53:05 +01:00
|
|
|
mmfile_t base = {NULL, 0}, other = {NULL, 0};
|
|
|
|
|
|
|
|
|
|
if (read_mmfile(&base, rerere_path(id, "preimage")) ||
|
2022-02-02 03:37:30 +01:00
|
|
|
read_mmfile(&other, rerere_path(id, "postimage"))) {
|
|
|
|
|
ret = LL_MERGE_CONFLICT;
|
|
|
|
|
} else {
|
2016-03-11 23:53:05 +01:00
|
|
|
/*
|
|
|
|
|
* A three-way merge. Note that this honors user-customizable
|
|
|
|
|
* low-level merge driver settings.
|
|
|
|
|
*/
|
2018-09-21 17:57:27 +02:00
|
|
|
ret = ll_merge(result, path, &base, NULL, cur, "", &other, "",
|
2018-09-21 17:57:32 +02:00
|
|
|
istate, NULL);
|
2022-02-02 03:37:30 +01:00
|
|
|
}
|
2016-03-11 23:53:05 +01:00
|
|
|
|
|
|
|
|
free(base.ptr);
|
|
|
|
|
free(other.ptr);
|
|
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
2015-07-01 07:40:35 +02:00
|
|
|
/*
|
2015-07-06 23:45:55 +02:00
|
|
|
* Find the conflict identified by "id"; the change between its
|
2015-07-01 07:40:35 +02:00
|
|
|
* "preimage" (i.e. a previous contents with conflict markers) and its
|
|
|
|
|
* "postimage" (i.e. the corresponding contents with conflicts
|
|
|
|
|
* resolved) may apply cleanly to the contents stored in "path", i.e.
|
|
|
|
|
* the conflict this time around.
|
|
|
|
|
*
|
|
|
|
|
* Returns 0 for successful replay of recorded resolution, or non-zero
|
|
|
|
|
* for failure.
|
|
|
|
|
*/
|
2018-09-21 17:57:32 +02:00
|
|
|
static int merge(struct index_state *istate, const struct rerere_id *id, const char *path)
|
2008-07-09 14:58:57 +02:00
|
|
|
{
|
2015-07-07 00:32:53 +02:00
|
|
|
FILE *f;
|
2008-07-09 14:58:57 +02:00
|
|
|
int ret;
|
2016-03-11 23:53:05 +01:00
|
|
|
mmfile_t cur = {NULL, 0};
|
2008-07-09 14:58:57 +02:00
|
|
|
mmbuffer_t result = {NULL, 0};
|
|
|
|
|
|
2015-07-01 07:40:35 +02:00
|
|
|
/*
|
|
|
|
|
* Normalize the conflicts in path and write it out to
|
|
|
|
|
* "thisimage" temporary file.
|
|
|
|
|
*/
|
2018-09-21 17:57:32 +02:00
|
|
|
if ((handle_file(istate, path, NULL, rerere_path(id, "thisimage")) < 0) ||
|
2016-03-11 23:53:05 +01:00
|
|
|
read_mmfile(&cur, rerere_path(id, "thisimage"))) {
|
2010-02-23 21:11:53 +01:00
|
|
|
ret = 1;
|
|
|
|
|
goto out;
|
|
|
|
|
}
|
2015-07-01 07:40:35 +02:00
|
|
|
|
2018-09-21 17:57:32 +02:00
|
|
|
ret = try_merge(istate, id, path, &cur, &result);
|
2015-07-07 00:32:53 +02:00
|
|
|
if (ret)
|
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* A successful replay of recorded resolution.
|
|
|
|
|
* Mark that "postimage" was used to help gc.
|
|
|
|
|
*/
|
|
|
|
|
if (utime(rerere_path(id, "postimage"), NULL) < 0)
|
2018-08-05 19:20:30 +02:00
|
|
|
warning_errno(_("failed utime() on '%s'"),
|
2016-05-08 11:47:52 +02:00
|
|
|
rerere_path(id, "postimage"));
|
2015-07-07 00:32:53 +02:00
|
|
|
|
|
|
|
|
/* Update "path" with the resolution */
|
|
|
|
|
f = fopen(path, "w");
|
|
|
|
|
if (!f)
|
2018-08-05 19:20:30 +02:00
|
|
|
return error_errno(_("could not open '%s'"), path);
|
2015-07-07 00:32:53 +02:00
|
|
|
if (fwrite(result.ptr, result.size, 1, f) != 1)
|
2018-08-05 19:20:30 +02:00
|
|
|
error_errno(_("could not write '%s'"), path);
|
2015-07-07 00:32:53 +02:00
|
|
|
if (fclose(f))
|
2018-08-05 19:20:30 +02:00
|
|
|
return error_errno(_("writing '%s' failed"), path);
|
2008-07-09 14:58:57 +02:00
|
|
|
|
2010-02-23 21:11:53 +01:00
|
|
|
out:
|
2008-07-09 14:58:57 +02:00
|
|
|
free(cur.ptr);
|
|
|
|
|
free(result.ptr);
|
|
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
2018-09-21 17:57:32 +02:00
|
|
|
static void update_paths(struct repository *r, struct string_list *update)
|
2008-07-09 14:58:57 +02:00
|
|
|
{
|
lock_file: move static locks into functions
Placing `struct lock_file`s on the stack used to be a bad idea, because
the temp- and lockfile-machinery would keep a pointer into the struct.
But after 076aa2cbd (tempfile: auto-allocate tempfiles on heap,
2017-09-05), we can safely have lockfiles on the stack. (This applies
even if a user returns early, leaving a locked lock behind.)
Each of these `struct lock_file`s is used from within a single function.
Move them into the respective functions to make the scope clearer and
drop the staticness.
For good measure, I have inspected these sites and come to believe that
they always release the lock, with the possible exception of bailing out
using `die()` or `exit()` or by returning from a `cmd_foo()`.
As pointed out by Jeff King, it would be bad if someone held on to a
`struct lock_file *` for some reason. After some grepping, I agree with
his findings: no-one appears to be doing that.
After this commit, the remaining occurrences of "static struct
lock_file" are locks that are used from within different functions. That
is, they need to remain static. (Short of more intrusive changes like
passing around pointers to non-static locks.)
Signed-off-by: Martin Ågren <martin.agren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-09 22:55:39 +02:00
|
|
|
struct lock_file index_lock = LOCK_INIT;
|
2008-07-09 14:58:57 +02:00
|
|
|
int i;
|
|
|
|
|
|
2019-01-12 03:13:24 +01:00
|
|
|
repo_hold_locked_index(r, &index_lock, LOCK_DIE_ON_ERROR);
|
2008-07-09 14:58:57 +02:00
|
|
|
|
|
|
|
|
for (i = 0; i < update->nr; i++) {
|
2008-07-21 20:03:49 +02:00
|
|
|
struct string_list_item *item = &update->items[i];
|
2018-09-21 17:57:32 +02:00
|
|
|
if (add_file_to_index(r->index, item->string, 0))
|
2014-12-03 05:20:49 +01:00
|
|
|
exit(128);
|
2018-08-05 19:20:30 +02:00
|
|
|
fprintf_ln(stderr, _("Staged '%s' using previous resolution."),
|
2015-06-29 06:13:24 +02:00
|
|
|
item->string);
|
2008-07-09 14:58:57 +02:00
|
|
|
}
|
|
|
|
|
|
2018-09-21 17:57:32 +02:00
|
|
|
if (write_locked_index(r->index, &index_lock,
|
2018-03-01 21:40:20 +01:00
|
|
|
COMMIT_LOCK | SKIP_IF_UNCHANGED))
|
2018-08-05 19:20:30 +02:00
|
|
|
die(_("unable to write new index file"));
|
2008-07-09 14:58:57 +02:00
|
|
|
}
|
|
|
|
|
|
2015-07-31 00:49:18 +02:00
|
|
|
static void remove_variant(struct rerere_id *id)
|
|
|
|
|
{
|
|
|
|
|
unlink_or_warn(rerere_path(id, "postimage"));
|
|
|
|
|
unlink_or_warn(rerere_path(id, "preimage"));
|
|
|
|
|
id->collection->status[id->variant] = 0;
|
|
|
|
|
}
|
|
|
|
|
|
2015-07-01 04:36:24 +02:00
|
|
|
/*
|
|
|
|
|
* The path indicated by rr_item may still have conflict for which we
|
|
|
|
|
* have a recorded resolution, in which case replay it and optionally
|
|
|
|
|
* update it. Or it may have been resolved by the user and we may
|
|
|
|
|
* only have the preimage for that conflict, in which case the result
|
|
|
|
|
* needs to be recorded as a resolution in a postimage file.
|
|
|
|
|
*/
|
2018-09-21 17:57:32 +02:00
|
|
|
static void do_rerere_one_path(struct index_state *istate,
|
|
|
|
|
struct string_list_item *rr_item,
|
2015-07-01 04:36:24 +02:00
|
|
|
struct string_list *update)
|
|
|
|
|
{
|
|
|
|
|
const char *path = rr_item->string;
|
2015-07-23 23:23:24 +02:00
|
|
|
struct rerere_id *id = rr_item->util;
|
2015-07-31 00:49:18 +02:00
|
|
|
struct rerere_dir *rr_dir = id->collection;
|
2015-07-23 23:23:24 +02:00
|
|
|
int variant;
|
|
|
|
|
|
|
|
|
|
variant = id->variant;
|
2015-07-01 04:36:24 +02:00
|
|
|
|
2015-07-31 00:49:18 +02:00
|
|
|
/* Has the user resolved it already? */
|
|
|
|
|
if (variant >= 0) {
|
2018-09-21 17:57:32 +02:00
|
|
|
if (!handle_file(istate, path, NULL, NULL)) {
|
2015-07-31 00:49:18 +02:00
|
|
|
copy_file(rerere_path(id, "postimage"), path, 0666);
|
|
|
|
|
id->collection->status[variant] |= RR_HAS_POSTIMAGE;
|
2018-08-05 19:20:30 +02:00
|
|
|
fprintf_ln(stderr, _("Recorded resolution for '%s'."), path);
|
2015-07-31 00:49:18 +02:00
|
|
|
free_rerere_id(rr_item);
|
|
|
|
|
rr_item->util = NULL;
|
|
|
|
|
return;
|
|
|
|
|
}
|
rerere: delay the recording of preimage
We record the preimage only when there is no directory to record the
conflict we encountered, i.e. when $GIT_DIR/rr-cache/$ID does not
exist. As the plan is to allow multiple <preimage,postimage> pairs
as variants for the same conflict ID eventually, this logic needs to
go.
As the first step in that direction, stop the "did we create the
directory? Then we record the preimage" logic. Instead, we record
if a preimage does not exist when we saw a conflict in a path. Also
make sure that we remove a stale postimage, which most likely is
totally unrelated to the resolution of this new conflict, when we
create a new preimage under $ID when $GIT_DIR/rr-cache/$ID already
exists.
In later patches, we will further update this logic to be "do we
have <preimage,postimage> pair that cleanly resolve the current
conflicts? If not, record a new preimage as a new variant", but
that does not happen at this stage yet.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-21 00:19:44 +02:00
|
|
|
/*
|
2015-07-31 00:49:18 +02:00
|
|
|
* There may be other variants that can cleanly
|
|
|
|
|
* replay. Try them and update the variant number for
|
|
|
|
|
* this one.
|
rerere: delay the recording of preimage
We record the preimage only when there is no directory to record the
conflict we encountered, i.e. when $GIT_DIR/rr-cache/$ID does not
exist. As the plan is to allow multiple <preimage,postimage> pairs
as variants for the same conflict ID eventually, this logic needs to
go.
As the first step in that direction, stop the "did we create the
directory? Then we record the preimage" logic. Instead, we record
if a preimage does not exist when we saw a conflict in a path. Also
make sure that we remove a stale postimage, which most likely is
totally unrelated to the resolution of this new conflict, when we
create a new preimage under $ID when $GIT_DIR/rr-cache/$ID already
exists.
In later patches, we will further update this logic to be "do we
have <preimage,postimage> pair that cleanly resolve the current
conflicts? If not, record a new preimage as a new variant", but
that does not happen at this stage yet.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-21 00:19:44 +02:00
|
|
|
*/
|
2015-07-31 00:49:18 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Does any existing resolution apply cleanly? */
|
|
|
|
|
for (variant = 0; variant < rr_dir->status_nr; variant++) {
|
|
|
|
|
const int both = RR_HAS_PREIMAGE | RR_HAS_POSTIMAGE;
|
|
|
|
|
struct rerere_id vid = *id;
|
|
|
|
|
|
|
|
|
|
if ((rr_dir->status[variant] & both) != both)
|
|
|
|
|
continue;
|
2015-07-01 04:36:24 +02:00
|
|
|
|
2015-07-31 00:49:18 +02:00
|
|
|
vid.variant = variant;
|
2018-09-21 17:57:32 +02:00
|
|
|
if (merge(istate, &vid, path))
|
2015-07-31 00:49:18 +02:00
|
|
|
continue; /* failed to replay */
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* If there already is a different variant that applies
|
|
|
|
|
* cleanly, there is no point maintaining our own variant.
|
|
|
|
|
*/
|
|
|
|
|
if (0 <= id->variant && id->variant != variant)
|
|
|
|
|
remove_variant(id);
|
2015-07-01 04:36:24 +02:00
|
|
|
|
|
|
|
|
if (rerere_autoupdate)
|
|
|
|
|
string_list_insert(update, path);
|
|
|
|
|
else
|
2018-08-05 19:20:30 +02:00
|
|
|
fprintf_ln(stderr,
|
|
|
|
|
_("Resolved '%s' using previous resolution."),
|
|
|
|
|
path);
|
2015-07-31 00:49:18 +02:00
|
|
|
free_rerere_id(rr_item);
|
|
|
|
|
rr_item->util = NULL;
|
2015-07-06 23:18:09 +02:00
|
|
|
return;
|
2015-07-01 04:36:24 +02:00
|
|
|
}
|
2015-07-31 00:49:18 +02:00
|
|
|
|
|
|
|
|
/* None of the existing one applies; we need a new variant */
|
|
|
|
|
assign_variant(id);
|
|
|
|
|
|
|
|
|
|
variant = id->variant;
|
2018-09-21 17:57:32 +02:00
|
|
|
handle_file(istate, path, NULL, rerere_path(id, "preimage"));
|
2015-07-31 00:49:18 +02:00
|
|
|
if (id->collection->status[variant] & RR_HAS_POSTIMAGE) {
|
|
|
|
|
const char *path = rerere_path(id, "postimage");
|
|
|
|
|
if (unlink(path))
|
2018-08-05 19:20:30 +02:00
|
|
|
die_errno(_("cannot unlink stray '%s'"), path);
|
2015-07-31 00:49:18 +02:00
|
|
|
id->collection->status[variant] &= ~RR_HAS_POSTIMAGE;
|
|
|
|
|
}
|
|
|
|
|
id->collection->status[variant] |= RR_HAS_PREIMAGE;
|
2018-08-05 19:20:30 +02:00
|
|
|
fprintf_ln(stderr, _("Recorded preimage for '%s'"), path);
|
2015-07-01 04:36:24 +02:00
|
|
|
}
|
|
|
|
|
|
2018-09-21 17:57:32 +02:00
|
|
|
static int do_plain_rerere(struct repository *r,
|
|
|
|
|
struct string_list *rr, int fd)
|
2008-07-09 14:58:57 +02:00
|
|
|
{
|
2010-07-04 21:46:19 +02:00
|
|
|
struct string_list conflict = STRING_LIST_INIT_DUP;
|
|
|
|
|
struct string_list update = STRING_LIST_INIT_DUP;
|
2008-07-09 14:58:57 +02:00
|
|
|
int i;
|
|
|
|
|
|
2018-09-21 17:57:32 +02:00
|
|
|
find_conflict(r, &conflict);
|
2008-07-09 14:58:57 +02:00
|
|
|
|
|
|
|
|
/*
|
2015-07-01 07:40:35 +02:00
|
|
|
* MERGE_RR records paths with conflicts immediately after
|
|
|
|
|
* merge failed. Some of the conflicted paths might have been
|
|
|
|
|
* hand resolved in the working tree since then, but the
|
|
|
|
|
* initial run would catch all and register their preimages.
|
2008-07-09 14:58:57 +02:00
|
|
|
*/
|
|
|
|
|
for (i = 0; i < conflict.nr; i++) {
|
2015-07-05 02:38:34 +02:00
|
|
|
struct rerere_id *id;
|
2018-10-15 02:02:02 +02:00
|
|
|
unsigned char hash[GIT_MAX_RAWSZ];
|
2008-07-21 20:03:49 +02:00
|
|
|
const char *path = conflict.items[i].string;
|
2015-07-05 02:38:34 +02:00
|
|
|
int ret;
|
2008-07-09 14:58:57 +02:00
|
|
|
|
2015-07-05 02:17:38 +02:00
|
|
|
/*
|
|
|
|
|
* Ask handle_file() to scan and assign a
|
|
|
|
|
* conflict ID. No need to write anything out
|
|
|
|
|
* yet.
|
|
|
|
|
*/
|
2018-10-30 07:43:42 +01:00
|
|
|
ret = handle_file(r->index, path, hash, NULL);
|
rerere: recalculate conflict ID when unresolved conflict is committed
Currently when a user doesn't resolve a conflict, commits the results,
and does an operation which creates another conflict, rerere will use
the ID of the previously unresolved conflict for the new conflict.
This is because the conflict is kept in the MERGE_RR file, which
'rerere' reads every time it is invoked.
After the new conflict is solved, rerere will record the resolution
with the ID of the old conflict. So in order to replay the conflict,
both merges would have to be re-done, instead of just the last one, in
order for rerere to be able to automatically resolve the conflict.
Instead of that, assign a new conflict ID if there are still conflicts
in a file and the file had conflicts at a previous step. This ID
matches the conflict we actually resolved at the corresponding step.
Note that there are no backwards compatibility worries here, as rerere
would have failed to even normalize the conflict before this patch
series.
Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-05 19:20:37 +02:00
|
|
|
if (ret != 0 && string_list_has_string(rr, path)) {
|
rerere: fix crash with files rerere can't handle
Currently when a user does a conflict resolution and ends it (in any
way that calls 'git rerere' again) with a file 'rerere' can't handle,
subsequent rerere operations that are interested in that path, such as
'rerere clear' or 'rerere forget <path>' will fail, or even worse in
the case of 'rerere clear' segfault.
Such states include nested conflicts, or a conflict marker that
doesn't have any match.
This is because 'git rerere' calculates a conflict file and writes it
to the MERGE_RR file. When the user then changes the file in any way
rerere can't handle, and then calls 'git rerere' on it again to record
the conflict resolution, the handle_file function fails, and removes
the 'preimage' file in the rr-cache in the process, while leaving the
ID in the MERGE_RR file.
Now when 'rerere clear' is run, it reads the ID from the MERGE_RR
file, however the 'fit_variant' function for the ID is never called as
the 'preimage' file does not exist anymore. This means
'collection->status' in 'has_rerere_resolution' is NULL, and the
command will crash.
To fix this, remove the rerere ID from the MERGE_RR file in the case
when we can't handle it, just after the 'preimage' file was removed
and remove the corresponding variant from .git/rr-cache/. Removing it
unconditionally is fine here, because if the user would have resolved
the conflict and ran rerere, the entry would no longer be in the
MERGE_RR file, so we wouldn't have this problem in the first place,
while if the conflict was not resolved.
Currently there is nothing left in this folder, as the 'preimage'
was already deleted by the 'handle_file' function, so 'remove_variant'
is a no-op. Still call the function, to make sure we clean everything
up, in case we add some other files corresponding to a variant in the
future.
Note that other variants that have the same conflict ID will not be
touched.
Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-05 19:20:32 +02:00
|
|
|
remove_variant(string_list_lookup(rr, path)->util);
|
|
|
|
|
string_list_remove(rr, path, 1);
|
|
|
|
|
}
|
2015-07-05 02:17:38 +02:00
|
|
|
if (ret < 1)
|
|
|
|
|
continue;
|
2008-07-09 14:58:57 +02:00
|
|
|
|
2018-10-15 02:02:02 +02:00
|
|
|
id = new_rerere_id(hash);
|
2015-07-06 23:45:55 +02:00
|
|
|
string_list_insert(rr, path)->util = id;
|
2015-07-01 07:40:35 +02:00
|
|
|
|
rerere: delay the recording of preimage
We record the preimage only when there is no directory to record the
conflict we encountered, i.e. when $GIT_DIR/rr-cache/$ID does not
exist. As the plan is to allow multiple <preimage,postimage> pairs
as variants for the same conflict ID eventually, this logic needs to
go.
As the first step in that direction, stop the "did we create the
directory? Then we record the preimage" logic. Instead, we record
if a preimage does not exist when we saw a conflict in a path. Also
make sure that we remove a stale postimage, which most likely is
totally unrelated to the resolution of this new conflict, when we
create a new preimage under $ID when $GIT_DIR/rr-cache/$ID already
exists.
In later patches, we will further update this logic to be "do we
have <preimage,postimage> pair that cleanly resolve the current
conflicts? If not, record a new preimage as a new variant", but
that does not happen at this stage yet.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-21 00:19:44 +02:00
|
|
|
/* Ensure that the directory exists. */
|
|
|
|
|
mkdir_in_gitdir(rerere_path(id, NULL));
|
2008-07-09 14:58:57 +02:00
|
|
|
}
|
|
|
|
|
|
2015-07-01 04:36:24 +02:00
|
|
|
for (i = 0; i < rr->nr; i++)
|
2018-09-21 17:57:32 +02:00
|
|
|
do_rerere_one_path(r->index, &rr->items[i], &update);
|
2008-07-09 14:58:57 +02:00
|
|
|
|
|
|
|
|
if (update.nr)
|
2018-09-21 17:57:32 +02:00
|
|
|
update_paths(r, &update);
|
2008-07-09 14:58:57 +02:00
|
|
|
|
|
|
|
|
return write_rr(rr, fd);
|
|
|
|
|
}
|
|
|
|
|
|
2014-08-07 18:21:21 +02:00
|
|
|
static void git_rerere_config(void)
|
2008-07-09 14:58:57 +02:00
|
|
|
{
|
2014-08-07 18:21:21 +02:00
|
|
|
git_config_get_bool("rerere.enabled", &rerere_enabled);
|
|
|
|
|
git_config_get_bool("rerere.autoupdate", &rerere_autoupdate);
|
|
|
|
|
git_config(git_default_config, NULL);
|
2008-07-09 14:58:57 +02:00
|
|
|
}
|
|
|
|
|
|
memoize common git-path "constant" files
One of the most common uses of git_path() is to pass a
constant, like git_path("MERGE_MSG"). This has two
drawbacks:
1. The return value is a static buffer, and the lifetime
is dependent on other calls to git_path, etc.
2. There's no compile-time checking of the pathname. This
is OK for a one-off (after all, we have to spell it
correctly at least once), but many of these constant
strings appear throughout the code.
This patch introduces a series of functions to "memoize"
these strings, which are essentially globals for the
lifetime of the program. We compute the value once, take
ownership of the buffer, and return the cached value for
subsequent calls. cache.h provides a helper macro for
defining these functions as one-liners, and defines a few
common ones for global use.
Using a macro is a little bit gross, but it does nicely
document the purpose of the functions. If we need to touch
them all later (e.g., because we learned how to change the
git_dir variable at runtime, and need to invalidate all of
the stored values), it will be much easier to have the
complete list.
Note that the shared-global functions have separate, manual
declarations. We could do something clever with the macros
(e.g., expand it to a declaration in some places, and a
declaration _and_ a definition in path.c). But there aren't
that many, and it's probably better to stay away from
too-magical macros.
Likewise, if we abandon the C preprocessor in favor of
generating these with a script, we could get much fancier.
E.g., normalizing "FOO/BAR-BAZ" into "git_path_foo_bar_baz".
But the small amount of saved typing is probably not worth
the resulting confusion to readers who want to grep for the
function's definition.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-10 11:38:57 +02:00
|
|
|
static GIT_PATH_FUNC(git_path_rr_cache, "rr-cache")
|
|
|
|
|
|
2008-07-09 14:58:57 +02:00
|
|
|
static int is_rerere_enabled(void)
|
|
|
|
|
{
|
|
|
|
|
int rr_cache_exists;
|
|
|
|
|
|
|
|
|
|
if (!rerere_enabled)
|
|
|
|
|
return 0;
|
|
|
|
|
|
memoize common git-path "constant" files
One of the most common uses of git_path() is to pass a
constant, like git_path("MERGE_MSG"). This has two
drawbacks:
1. The return value is a static buffer, and the lifetime
is dependent on other calls to git_path, etc.
2. There's no compile-time checking of the pathname. This
is OK for a one-off (after all, we have to spell it
correctly at least once), but many of these constant
strings appear throughout the code.
This patch introduces a series of functions to "memoize"
these strings, which are essentially globals for the
lifetime of the program. We compute the value once, take
ownership of the buffer, and return the cached value for
subsequent calls. cache.h provides a helper macro for
defining these functions as one-liners, and defines a few
common ones for global use.
Using a macro is a little bit gross, but it does nicely
document the purpose of the functions. If we need to touch
them all later (e.g., because we learned how to change the
git_dir variable at runtime, and need to invalidate all of
the stored values), it will be much easier to have the
complete list.
Note that the shared-global functions have separate, manual
declarations. We could do something clever with the macros
(e.g., expand it to a declaration in some places, and a
declaration _and_ a definition in path.c). But there aren't
that many, and it's probably better to stay away from
too-magical macros.
Likewise, if we abandon the C preprocessor in favor of
generating these with a script, we could get much fancier.
E.g., normalizing "FOO/BAR-BAZ" into "git_path_foo_bar_baz".
But the small amount of saved typing is probably not worth
the resulting confusion to readers who want to grep for the
function's definition.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-10 11:38:57 +02:00
|
|
|
rr_cache_exists = is_directory(git_path_rr_cache());
|
2008-07-09 14:58:57 +02:00
|
|
|
if (rerere_enabled < 0)
|
|
|
|
|
return rr_cache_exists;
|
|
|
|
|
|
memoize common git-path "constant" files
One of the most common uses of git_path() is to pass a
constant, like git_path("MERGE_MSG"). This has two
drawbacks:
1. The return value is a static buffer, and the lifetime
is dependent on other calls to git_path, etc.
2. There's no compile-time checking of the pathname. This
is OK for a one-off (after all, we have to spell it
correctly at least once), but many of these constant
strings appear throughout the code.
This patch introduces a series of functions to "memoize"
these strings, which are essentially globals for the
lifetime of the program. We compute the value once, take
ownership of the buffer, and return the cached value for
subsequent calls. cache.h provides a helper macro for
defining these functions as one-liners, and defines a few
common ones for global use.
Using a macro is a little bit gross, but it does nicely
document the purpose of the functions. If we need to touch
them all later (e.g., because we learned how to change the
git_dir variable at runtime, and need to invalidate all of
the stored values), it will be much easier to have the
complete list.
Note that the shared-global functions have separate, manual
declarations. We could do something clever with the macros
(e.g., expand it to a declaration in some places, and a
declaration _and_ a definition in path.c). But there aren't
that many, and it's probably better to stay away from
too-magical macros.
Likewise, if we abandon the C preprocessor in favor of
generating these with a script, we could get much fancier.
E.g., normalizing "FOO/BAR-BAZ" into "git_path_foo_bar_baz".
But the small amount of saved typing is probably not worth
the resulting confusion to readers who want to grep for the
function's definition.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-10 11:38:57 +02:00
|
|
|
if (!rr_cache_exists && mkdir_in_gitdir(git_path_rr_cache()))
|
2018-08-05 19:20:30 +02:00
|
|
|
die(_("could not create directory '%s'"), git_path_rr_cache());
|
2008-07-09 14:58:57 +02:00
|
|
|
return 1;
|
|
|
|
|
}
|
|
|
|
|
|
2018-11-10 06:49:09 +01:00
|
|
|
int setup_rerere(struct repository *r, struct string_list *merge_rr, int flags)
|
2008-07-09 14:58:57 +02:00
|
|
|
{
|
|
|
|
|
int fd;
|
|
|
|
|
|
2014-08-07 18:21:21 +02:00
|
|
|
git_rerere_config();
|
2008-07-09 14:58:57 +02:00
|
|
|
if (!is_rerere_enabled())
|
|
|
|
|
return -1;
|
|
|
|
|
|
2009-12-04 09:20:48 +01:00
|
|
|
if (flags & (RERERE_AUTOUPDATE|RERERE_NOAUTOUPDATE))
|
|
|
|
|
rerere_autoupdate = !!(flags & RERERE_AUTOUPDATE);
|
rerere: release lockfile in non-writing functions
There's a bug in builtin/am.c in which we take a lock on
MERGE_RR recursively. But rather than fix am.c, this patch
fixes the confusing interface from rerere.c that caused the
bug. Read on for the gory details.
The setup_rerere() function both reads the existing MERGE_RR
file, and takes MERGE_RR.lock. In the rerere() and
rerere_forget() functions, we end up in write_rr(), which
will then commit the lock file.
But for functions like rerere_clear() that do not write to
MERGE_RR, we expect the caller to have handled
setup_rerere(). That caller would then need to release the
lockfile, but it can't; the lock struct is local to
rerere.c.
For builtin/rerere.c, this is OK. We run a single rerere
operation and then exit immediately, which has the side
effect of rolling back the lockfile.
But in builtin/am.c, this is actively wrong. If we run "git
am -3 --skip", we call setup-rerere twice without releasing
the lock:
1. The "--skip" causes us to call am_rerere_clear(), which
calls setup_rerere(), but never drops the lock.
2. We then proceed to the next patch.
3. The "--3way" may cause us to call rerere() to handle
conflicts in that patch, but we are already holding the
lock. The lockfile code dies with:
BUG: prepare_tempfile_object called for active object
We could fix this by having rerere_clear() call
rollback_lock_file(). But it feels a bit odd for it to roll
back a lockfile that it did not itself take. So let's
simplify the interface further, and handle setup_rerere in
the function itself, taking away the question from the
caller over whether they need to do so.
We can give rerere_gc() the same treatment, as well (even
though it doesn't have any callers besides builtin/rerere.c
at this point). Note that these functions don't take flags
from their callers to pass along to setup_rerere; that's OK,
because the flags would not be meaningful for what they are
doing.
Both of those functions need to hold the lock because even
though they do not write to MERGE_RR, they are still writing
and should be protected from a simultaneous "rerere" run.
But rerere_remaining(), "rerere diff", and "rerere status"
are all read-only operations. They want to setup_rerere(),
but do not care about taking the lock in the first place.
Since our update of MERGE_RR is the usual atomic rename done
by commit_lock_file, they can just do a lockless read. For
that, we teach setup_rerere a READONLY flag to avoid the
lock.
As a bonus, this pushes builtin/rerere.c's setup_rerere call
closer to the functions that use it. Which means that "git
rerere totally-bogus-command" will no longer silently
exit(0) in a repository without rerere enabled.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-02 00:14:09 +02:00
|
|
|
if (flags & RERERE_READONLY)
|
|
|
|
|
fd = 0;
|
|
|
|
|
else
|
2018-05-18 00:51:51 +02:00
|
|
|
fd = hold_lock_file_for_update(&write_lock,
|
2018-11-10 06:49:09 +01:00
|
|
|
git_path_merge_rr(r),
|
rerere: release lockfile in non-writing functions
There's a bug in builtin/am.c in which we take a lock on
MERGE_RR recursively. But rather than fix am.c, this patch
fixes the confusing interface from rerere.c that caused the
bug. Read on for the gory details.
The setup_rerere() function both reads the existing MERGE_RR
file, and takes MERGE_RR.lock. In the rerere() and
rerere_forget() functions, we end up in write_rr(), which
will then commit the lock file.
But for functions like rerere_clear() that do not write to
MERGE_RR, we expect the caller to have handled
setup_rerere(). That caller would then need to release the
lockfile, but it can't; the lock struct is local to
rerere.c.
For builtin/rerere.c, this is OK. We run a single rerere
operation and then exit immediately, which has the side
effect of rolling back the lockfile.
But in builtin/am.c, this is actively wrong. If we run "git
am -3 --skip", we call setup-rerere twice without releasing
the lock:
1. The "--skip" causes us to call am_rerere_clear(), which
calls setup_rerere(), but never drops the lock.
2. We then proceed to the next patch.
3. The "--3way" may cause us to call rerere() to handle
conflicts in that patch, but we are already holding the
lock. The lockfile code dies with:
BUG: prepare_tempfile_object called for active object
We could fix this by having rerere_clear() call
rollback_lock_file(). But it feels a bit odd for it to roll
back a lockfile that it did not itself take. So let's
simplify the interface further, and handle setup_rerere in
the function itself, taking away the question from the
caller over whether they need to do so.
We can give rerere_gc() the same treatment, as well (even
though it doesn't have any callers besides builtin/rerere.c
at this point). Note that these functions don't take flags
from their callers to pass along to setup_rerere; that's OK,
because the flags would not be meaningful for what they are
doing.
Both of those functions need to hold the lock because even
though they do not write to MERGE_RR, they are still writing
and should be protected from a simultaneous "rerere" run.
But rerere_remaining(), "rerere diff", and "rerere status"
are all read-only operations. They want to setup_rerere(),
but do not care about taking the lock in the first place.
Since our update of MERGE_RR is the usual atomic rename done
by commit_lock_file, they can just do a lockless read. For
that, we teach setup_rerere a READONLY flag to avoid the
lock.
As a bonus, this pushes builtin/rerere.c's setup_rerere call
closer to the functions that use it. Which means that "git
rerere totally-bogus-command" will no longer silently
exit(0) in a repository without rerere enabled.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-02 00:14:09 +02:00
|
|
|
LOCK_DIE_ON_ERROR);
|
2018-11-10 06:49:09 +01:00
|
|
|
read_rr(r, merge_rr);
|
2008-07-09 14:58:57 +02:00
|
|
|
return fd;
|
|
|
|
|
}
|
|
|
|
|
|
2015-07-01 07:40:35 +02:00
|
|
|
/*
|
|
|
|
|
* The main entry point that is called internally from codepaths that
|
|
|
|
|
* perform mergy operations, possibly leaving conflicted index entries
|
|
|
|
|
* and working tree files.
|
|
|
|
|
*/
|
2018-09-21 17:57:32 +02:00
|
|
|
int repo_rerere(struct repository *r, int flags)
|
2008-07-09 14:58:57 +02:00
|
|
|
{
|
2010-07-04 21:46:19 +02:00
|
|
|
struct string_list merge_rr = STRING_LIST_INIT_DUP;
|
rerere: split conflict ID further
The plan is to keep assigning the backward compatible conflict ID
based on the hash of the (normalized) text of conflicts, keep using
that conflict ID as the directory name under $GIT_DIR/rr-cache/, but
allow each conflicted path to use a separate "variant" to record
resolutions, i.e. having more than one <preimage,postimage> pairs
under $GIT_DIR/rr-cache/$ID/ directory. As the first step in that
direction, separate the shared "conflict ID" out of the rerere_id
structure.
The plan is to keep information per $ID in rerere_dir, that can be
shared among rerere_id that is per conflicted path.
When we are done with rerere(), which can be directly called from
other programs like "git apply", "git commit" and "git merge", the
shared rerere_dir structures can be freed entirely, so they are not
reference-counted and they are not freed when we release rerere_id's
that reference them.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-16 23:50:05 +02:00
|
|
|
int fd, status;
|
2008-07-09 14:58:57 +02:00
|
|
|
|
2018-11-10 06:49:09 +01:00
|
|
|
fd = setup_rerere(r, &merge_rr, flags);
|
2008-07-09 14:58:57 +02:00
|
|
|
if (fd < 0)
|
|
|
|
|
return 0;
|
2018-09-21 17:57:32 +02:00
|
|
|
status = do_plain_rerere(r, &merge_rr, fd);
|
rerere: split conflict ID further
The plan is to keep assigning the backward compatible conflict ID
based on the hash of the (normalized) text of conflicts, keep using
that conflict ID as the directory name under $GIT_DIR/rr-cache/, but
allow each conflicted path to use a separate "variant" to record
resolutions, i.e. having more than one <preimage,postimage> pairs
under $GIT_DIR/rr-cache/$ID/ directory. As the first step in that
direction, separate the shared "conflict ID" out of the rerere_id
structure.
The plan is to keep information per $ID in rerere_dir, that can be
shared among rerere_id that is per conflicted path.
When we are done with rerere(), which can be directly called from
other programs like "git apply", "git commit" and "git merge", the
shared rerere_dir structures can be freed entirely, so they are not
reference-counted and they are not freed when we release rerere_id's
that reference them.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-16 23:50:05 +02:00
|
|
|
free_rerere_dirs();
|
|
|
|
|
return status;
|
2008-07-09 14:58:57 +02:00
|
|
|
}
|
2009-12-26 00:51:32 +01:00
|
|
|
|
2016-03-14 23:10:39 +01:00
|
|
|
/*
|
|
|
|
|
* Subclass of rerere_io that reads from an in-core buffer that is a
|
|
|
|
|
* strbuf
|
|
|
|
|
*/
|
|
|
|
|
struct rerere_io_mem {
|
|
|
|
|
struct rerere_io io;
|
|
|
|
|
struct strbuf input;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* ... and its getline() method implementation
|
|
|
|
|
*/
|
|
|
|
|
static int rerere_mem_getline(struct strbuf *sb, struct rerere_io *io_)
|
|
|
|
|
{
|
|
|
|
|
struct rerere_io_mem *io = (struct rerere_io_mem *)io_;
|
|
|
|
|
char *ep;
|
|
|
|
|
size_t len;
|
|
|
|
|
|
|
|
|
|
strbuf_release(sb);
|
|
|
|
|
if (!io->input.len)
|
|
|
|
|
return -1;
|
|
|
|
|
ep = memchr(io->input.buf, '\n', io->input.len);
|
|
|
|
|
if (!ep)
|
|
|
|
|
ep = io->input.buf + io->input.len;
|
|
|
|
|
else if (*ep == '\n')
|
|
|
|
|
ep++;
|
|
|
|
|
len = ep - io->input.buf;
|
|
|
|
|
strbuf_add(sb, io->input.buf, len);
|
|
|
|
|
strbuf_remove(&io->input, 0, len);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2018-10-30 07:43:42 +01:00
|
|
|
static int handle_cache(struct index_state *istate,
|
|
|
|
|
const char *path, unsigned char *hash, const char *output)
|
2016-03-14 23:10:39 +01:00
|
|
|
{
|
|
|
|
|
mmfile_t mmfile[3] = {{NULL}};
|
|
|
|
|
mmbuffer_t result = {NULL, 0};
|
|
|
|
|
const struct cache_entry *ce;
|
2018-08-05 19:20:33 +02:00
|
|
|
int pos, len, i, has_conflicts;
|
2016-03-14 23:10:39 +01:00
|
|
|
struct rerere_io_mem io;
|
2018-09-21 17:57:32 +02:00
|
|
|
int marker_size = ll_merge_marker_size(istate, path);
|
2016-03-14 23:10:39 +01:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Reproduce the conflicted merge in-core
|
|
|
|
|
*/
|
|
|
|
|
len = strlen(path);
|
2018-09-21 17:57:32 +02:00
|
|
|
pos = index_name_pos(istate, path, len);
|
2016-03-14 23:10:39 +01:00
|
|
|
if (0 <= pos)
|
|
|
|
|
return -1;
|
|
|
|
|
pos = -pos - 1;
|
|
|
|
|
|
2018-09-21 17:57:32 +02:00
|
|
|
while (pos < istate->cache_nr) {
|
2016-03-14 23:10:39 +01:00
|
|
|
enum object_type type;
|
|
|
|
|
unsigned long size;
|
|
|
|
|
|
2018-09-21 17:57:32 +02:00
|
|
|
ce = istate->cache[pos++];
|
2016-03-14 23:10:39 +01:00
|
|
|
if (ce_namelen(ce) != len || memcmp(ce->name, path, len))
|
|
|
|
|
break;
|
|
|
|
|
i = ce_stage(ce) - 1;
|
|
|
|
|
if (!mmfile[i].ptr) {
|
sha1_file: convert read_sha1_file to struct object_id
Convert read_sha1_file to take a pointer to struct object_id and rename
it read_object_file. Do the same for read_sha1_file_extended.
Convert one use in grep.c to use the new function without any other code
change, since the pointer being passed is a void pointer that is already
initialized with a pointer to struct object_id. Update the declaration
and definitions of the modified functions, and apply the following
semantic patch to convert the remaining callers:
@@
expression E1, E2, E3;
@@
- read_sha1_file(E1.hash, E2, E3)
+ read_object_file(&E1, E2, E3)
@@
expression E1, E2, E3;
@@
- read_sha1_file(E1->hash, E2, E3)
+ read_object_file(E1, E2, E3)
@@
expression E1, E2, E3, E4;
@@
- read_sha1_file_extended(E1.hash, E2, E3, E4)
+ read_object_file_extended(&E1, E2, E3, E4)
@@
expression E1, E2, E3, E4;
@@
- read_sha1_file_extended(E1->hash, E2, E3, E4)
+ read_object_file_extended(E1, E2, E3, E4)
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-12 03:27:53 +01:00
|
|
|
mmfile[i].ptr = read_object_file(&ce->oid, &type,
|
|
|
|
|
&size);
|
2016-03-14 23:10:39 +01:00
|
|
|
mmfile[i].size = size;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
for (i = 0; i < 3; i++)
|
|
|
|
|
if (!mmfile[i].ptr && !mmfile[i].size)
|
|
|
|
|
mmfile[i].ptr = xstrdup("");
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* NEEDSWORK: handle conflicts from merges with
|
|
|
|
|
* merge.renormalize set, too?
|
|
|
|
|
*/
|
|
|
|
|
ll_merge(&result, path, &mmfile[0], NULL,
|
|
|
|
|
&mmfile[1], "ours",
|
2018-09-21 17:57:27 +02:00
|
|
|
&mmfile[2], "theirs",
|
2018-09-21 17:57:32 +02:00
|
|
|
istate, NULL);
|
2016-03-14 23:10:39 +01:00
|
|
|
for (i = 0; i < 3; i++)
|
|
|
|
|
free(mmfile[i].ptr);
|
|
|
|
|
|
|
|
|
|
memset(&io, 0, sizeof(io));
|
|
|
|
|
io.io.getline = rerere_mem_getline;
|
|
|
|
|
if (output)
|
|
|
|
|
io.io.output = fopen(output, "w");
|
|
|
|
|
else
|
|
|
|
|
io.io.output = NULL;
|
|
|
|
|
strbuf_init(&io.input, 0);
|
|
|
|
|
strbuf_attach(&io.input, result.ptr, result.size, result.size);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Grab the conflict ID and optionally write the original
|
|
|
|
|
* contents with conflict markers out.
|
|
|
|
|
*/
|
2018-10-15 02:02:02 +02:00
|
|
|
has_conflicts = handle_path(hash, (struct rerere_io *)&io, marker_size);
|
2016-03-14 23:10:39 +01:00
|
|
|
strbuf_release(&io.input);
|
|
|
|
|
if (io.io.output)
|
|
|
|
|
fclose(io.io.output);
|
2018-08-05 19:20:33 +02:00
|
|
|
return has_conflicts;
|
2008-07-09 14:58:57 +02:00
|
|
|
}
|
2009-12-26 00:51:32 +01:00
|
|
|
|
2018-09-21 17:57:32 +02:00
|
|
|
static int rerere_forget_one_path(struct index_state *istate,
|
|
|
|
|
const char *path,
|
|
|
|
|
struct string_list *rr)
|
2009-12-26 00:51:32 +01:00
|
|
|
{
|
|
|
|
|
const char *filename;
|
2015-07-05 02:38:34 +02:00
|
|
|
struct rerere_id *id;
|
2018-10-15 02:02:02 +02:00
|
|
|
unsigned char hash[GIT_MAX_RAWSZ];
|
2009-12-26 00:51:32 +01:00
|
|
|
int ret;
|
2015-06-30 22:03:36 +02:00
|
|
|
struct string_list_item *item;
|
2009-12-26 00:51:32 +01:00
|
|
|
|
2015-07-01 07:42:34 +02:00
|
|
|
/*
|
|
|
|
|
* Recreate the original conflict from the stages in the
|
|
|
|
|
* index and compute the conflict ID
|
|
|
|
|
*/
|
2018-10-30 07:43:42 +01:00
|
|
|
ret = handle_cache(istate, path, hash, NULL);
|
2009-12-26 00:51:32 +01:00
|
|
|
if (ret < 1)
|
2018-08-05 19:20:30 +02:00
|
|
|
return error(_("could not parse conflict hunks in '%s'"), path);
|
2015-07-01 07:42:34 +02:00
|
|
|
|
|
|
|
|
/* Nuke the recorded resolution for the conflict */
|
2018-10-15 02:02:02 +02:00
|
|
|
id = new_rerere_id(hash);
|
2016-03-28 23:48:13 +02:00
|
|
|
|
|
|
|
|
for (id->variant = 0;
|
|
|
|
|
id->variant < id->collection->status_nr;
|
|
|
|
|
id->variant++) {
|
|
|
|
|
mmfile_t cur = { NULL, 0 };
|
|
|
|
|
mmbuffer_t result = {NULL, 0};
|
|
|
|
|
int cleanly_resolved;
|
|
|
|
|
|
|
|
|
|
if (!has_rerere_resolution(id))
|
|
|
|
|
continue;
|
|
|
|
|
|
2018-10-30 07:43:42 +01:00
|
|
|
handle_cache(istate, path, hash, rerere_path(id, "thisimage"));
|
2016-03-28 23:48:13 +02:00
|
|
|
if (read_mmfile(&cur, rerere_path(id, "thisimage"))) {
|
|
|
|
|
free(cur.ptr);
|
2018-08-05 19:20:30 +02:00
|
|
|
error(_("failed to update conflicted state in '%s'"), path);
|
2016-05-12 01:19:17 +02:00
|
|
|
goto fail_exit;
|
2016-03-28 23:48:13 +02:00
|
|
|
}
|
2018-09-21 17:57:32 +02:00
|
|
|
cleanly_resolved = !try_merge(istate, id, path, &cur, &result);
|
2016-03-28 23:48:13 +02:00
|
|
|
free(result.ptr);
|
|
|
|
|
free(cur.ptr);
|
|
|
|
|
if (cleanly_resolved)
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
2016-05-12 01:19:17 +02:00
|
|
|
if (id->collection->status_nr <= id->variant) {
|
2018-08-05 19:20:30 +02:00
|
|
|
error(_("no remembered resolution for '%s'"), path);
|
2016-05-12 01:19:17 +02:00
|
|
|
goto fail_exit;
|
|
|
|
|
}
|
2016-03-28 23:48:13 +02:00
|
|
|
|
2015-07-06 23:45:55 +02:00
|
|
|
filename = rerere_path(id, "postimage");
|
2016-05-12 01:19:17 +02:00
|
|
|
if (unlink(filename)) {
|
|
|
|
|
if (errno == ENOENT)
|
2018-08-05 19:20:30 +02:00
|
|
|
error(_("no remembered resolution for '%s'"), path);
|
2016-05-12 01:19:17 +02:00
|
|
|
else
|
2018-08-05 19:20:30 +02:00
|
|
|
error_errno(_("cannot unlink '%s'"), filename);
|
2016-05-12 01:19:17 +02:00
|
|
|
goto fail_exit;
|
2016-05-19 21:51:22 +02:00
|
|
|
}
|
2009-12-26 00:51:32 +01:00
|
|
|
|
2015-07-01 07:42:34 +02:00
|
|
|
/*
|
|
|
|
|
* Update the preimage so that the user can resolve the
|
|
|
|
|
* conflict in the working tree, run us again to record
|
|
|
|
|
* the postimage.
|
|
|
|
|
*/
|
2018-10-30 07:43:42 +01:00
|
|
|
handle_cache(istate, path, hash, rerere_path(id, "preimage"));
|
2018-08-05 19:20:30 +02:00
|
|
|
fprintf_ln(stderr, _("Updated preimage for '%s'"), path);
|
2009-12-26 00:51:32 +01:00
|
|
|
|
2015-07-01 07:42:34 +02:00
|
|
|
/*
|
|
|
|
|
* And remember that we can record resolution for this
|
|
|
|
|
* conflict when the user is done.
|
|
|
|
|
*/
|
2015-06-30 22:03:36 +02:00
|
|
|
item = string_list_insert(rr, path);
|
2015-07-05 02:38:34 +02:00
|
|
|
free_rerere_id(item);
|
2015-07-06 23:45:55 +02:00
|
|
|
item->util = id;
|
2018-08-05 19:20:30 +02:00
|
|
|
fprintf(stderr, _("Forgot resolution for '%s'\n"), path);
|
2009-12-26 00:51:32 +01:00
|
|
|
return 0;
|
2016-05-12 01:19:17 +02:00
|
|
|
|
|
|
|
|
fail_exit:
|
|
|
|
|
free(id);
|
|
|
|
|
return -1;
|
2009-12-26 00:51:32 +01:00
|
|
|
}
|
|
|
|
|
|
2018-09-21 17:57:32 +02:00
|
|
|
int rerere_forget(struct repository *r, struct pathspec *pathspec)
|
2009-12-26 00:51:32 +01:00
|
|
|
{
|
|
|
|
|
int i, fd;
|
2010-07-04 21:46:19 +02:00
|
|
|
struct string_list conflict = STRING_LIST_INIT_DUP;
|
|
|
|
|
struct string_list merge_rr = STRING_LIST_INIT_DUP;
|
2009-12-26 00:51:32 +01:00
|
|
|
|
2019-01-12 03:13:26 +01:00
|
|
|
if (repo_read_index(r) < 0)
|
2018-08-05 19:20:30 +02:00
|
|
|
return error(_("index file corrupt"));
|
2009-12-26 00:51:32 +01:00
|
|
|
|
2018-11-10 06:49:09 +01:00
|
|
|
fd = setup_rerere(r, &merge_rr, RERERE_NOAUTOUPDATE);
|
2015-05-14 21:20:52 +02:00
|
|
|
if (fd < 0)
|
|
|
|
|
return 0;
|
2009-12-26 00:51:32 +01:00
|
|
|
|
2015-07-01 07:42:34 +02:00
|
|
|
/*
|
|
|
|
|
* The paths may have been resolved (incorrectly);
|
|
|
|
|
* recover the original conflicted state and then
|
|
|
|
|
* find the conflicted paths.
|
|
|
|
|
*/
|
2018-09-21 17:57:32 +02:00
|
|
|
unmerge_index(r->index, pathspec);
|
|
|
|
|
find_conflict(r, &conflict);
|
2009-12-26 00:51:32 +01:00
|
|
|
for (i = 0; i < conflict.nr; i++) {
|
|
|
|
|
struct string_list_item *it = &conflict.items[i];
|
2018-09-21 17:57:32 +02:00
|
|
|
if (!match_pathspec(r->index, pathspec, it->string,
|
2014-01-24 14:40:33 +01:00
|
|
|
strlen(it->string), 0, NULL, 0))
|
2009-12-26 00:51:32 +01:00
|
|
|
continue;
|
2018-09-21 17:57:32 +02:00
|
|
|
rerere_forget_one_path(r->index, it->string, &merge_rr);
|
2009-12-26 00:51:32 +01:00
|
|
|
}
|
|
|
|
|
return write_rr(&merge_rr, fd);
|
|
|
|
|
}
|
2011-05-08 21:55:34 +02:00
|
|
|
|
2015-07-01 07:43:37 +02:00
|
|
|
/*
|
|
|
|
|
* Garbage collection support
|
|
|
|
|
*/
|
2015-07-05 02:38:34 +02:00
|
|
|
|
2017-08-19 20:16:01 +02:00
|
|
|
static timestamp_t rerere_created_at(struct rerere_id *id)
|
2011-05-08 21:55:34 +02:00
|
|
|
{
|
|
|
|
|
struct stat st;
|
2015-07-05 02:38:34 +02:00
|
|
|
|
2015-07-06 23:45:55 +02:00
|
|
|
return stat(rerere_path(id, "preimage"), &st) ? (time_t) 0 : st.st_mtime;
|
2011-05-08 21:55:34 +02:00
|
|
|
}
|
|
|
|
|
|
2017-08-19 20:16:01 +02:00
|
|
|
static timestamp_t rerere_last_used_at(struct rerere_id *id)
|
2011-05-08 21:55:34 +02:00
|
|
|
{
|
|
|
|
|
struct stat st;
|
2015-07-05 02:38:34 +02:00
|
|
|
|
2015-07-06 23:45:55 +02:00
|
|
|
return stat(rerere_path(id, "postimage"), &st) ? (time_t) 0 : st.st_mtime;
|
2011-05-08 21:55:34 +02:00
|
|
|
}
|
|
|
|
|
|
2015-07-01 07:43:37 +02:00
|
|
|
/*
|
|
|
|
|
* Remove the recorded resolution for a given conflict ID
|
|
|
|
|
*/
|
2015-07-05 02:38:34 +02:00
|
|
|
static void unlink_rr_item(struct rerere_id *id)
|
2011-05-08 21:55:34 +02:00
|
|
|
{
|
2016-03-08 21:11:00 +01:00
|
|
|
unlink_or_warn(rerere_path(id, "thisimage"));
|
|
|
|
|
remove_variant(id);
|
|
|
|
|
id->collection->status[id->variant] = 0;
|
|
|
|
|
}
|
|
|
|
|
|
2017-08-19 20:16:01 +02:00
|
|
|
static void prune_one(struct rerere_id *id,
|
|
|
|
|
timestamp_t cutoff_resolve, timestamp_t cutoff_noresolve)
|
2016-03-08 21:11:00 +01:00
|
|
|
{
|
2017-08-19 20:16:01 +02:00
|
|
|
timestamp_t then;
|
|
|
|
|
timestamp_t cutoff;
|
2016-03-08 21:11:00 +01:00
|
|
|
|
|
|
|
|
then = rerere_last_used_at(id);
|
|
|
|
|
if (then)
|
|
|
|
|
cutoff = cutoff_resolve;
|
|
|
|
|
else {
|
|
|
|
|
then = rerere_created_at(id);
|
|
|
|
|
if (!then)
|
|
|
|
|
return;
|
|
|
|
|
cutoff = cutoff_noresolve;
|
|
|
|
|
}
|
2017-08-19 20:16:01 +02:00
|
|
|
if (then < cutoff)
|
2016-03-08 21:11:00 +01:00
|
|
|
unlink_rr_item(id);
|
2011-05-08 21:55:34 +02:00
|
|
|
}
|
|
|
|
|
|
2021-01-28 07:14:11 +01:00
|
|
|
/* Does the basename in "path" look plausibly like an rr-cache entry? */
|
|
|
|
|
static int is_rr_cache_dirname(const char *path)
|
|
|
|
|
{
|
2021-01-28 07:16:50 +01:00
|
|
|
struct object_id oid;
|
|
|
|
|
const char *end;
|
|
|
|
|
return !parse_oid_hex(path, &oid, &end) && !*end;
|
2021-01-28 07:14:11 +01:00
|
|
|
}
|
|
|
|
|
|
2018-11-10 06:49:09 +01:00
|
|
|
void rerere_gc(struct repository *r, struct string_list *rr)
|
2011-05-08 21:55:34 +02:00
|
|
|
{
|
|
|
|
|
struct string_list to_remove = STRING_LIST_INIT_DUP;
|
|
|
|
|
DIR *dir;
|
|
|
|
|
struct dirent *e;
|
2016-03-08 21:11:00 +01:00
|
|
|
int i;
|
2017-08-19 20:16:01 +02:00
|
|
|
timestamp_t now = time(NULL);
|
|
|
|
|
timestamp_t cutoff_noresolve = now - 15 * 86400;
|
|
|
|
|
timestamp_t cutoff_resolve = now - 60 * 86400;
|
2011-05-08 21:55:34 +02:00
|
|
|
|
2018-11-10 06:49:09 +01:00
|
|
|
if (setup_rerere(r, rr, 0) < 0)
|
rerere: release lockfile in non-writing functions
There's a bug in builtin/am.c in which we take a lock on
MERGE_RR recursively. But rather than fix am.c, this patch
fixes the confusing interface from rerere.c that caused the
bug. Read on for the gory details.
The setup_rerere() function both reads the existing MERGE_RR
file, and takes MERGE_RR.lock. In the rerere() and
rerere_forget() functions, we end up in write_rr(), which
will then commit the lock file.
But for functions like rerere_clear() that do not write to
MERGE_RR, we expect the caller to have handled
setup_rerere(). That caller would then need to release the
lockfile, but it can't; the lock struct is local to
rerere.c.
For builtin/rerere.c, this is OK. We run a single rerere
operation and then exit immediately, which has the side
effect of rolling back the lockfile.
But in builtin/am.c, this is actively wrong. If we run "git
am -3 --skip", we call setup-rerere twice without releasing
the lock:
1. The "--skip" causes us to call am_rerere_clear(), which
calls setup_rerere(), but never drops the lock.
2. We then proceed to the next patch.
3. The "--3way" may cause us to call rerere() to handle
conflicts in that patch, but we are already holding the
lock. The lockfile code dies with:
BUG: prepare_tempfile_object called for active object
We could fix this by having rerere_clear() call
rollback_lock_file(). But it feels a bit odd for it to roll
back a lockfile that it did not itself take. So let's
simplify the interface further, and handle setup_rerere in
the function itself, taking away the question from the
caller over whether they need to do so.
We can give rerere_gc() the same treatment, as well (even
though it doesn't have any callers besides builtin/rerere.c
at this point). Note that these functions don't take flags
from their callers to pass along to setup_rerere; that's OK,
because the flags would not be meaningful for what they are
doing.
Both of those functions need to hold the lock because even
though they do not write to MERGE_RR, they are still writing
and should be protected from a simultaneous "rerere" run.
But rerere_remaining(), "rerere diff", and "rerere status"
are all read-only operations. They want to setup_rerere(),
but do not care about taking the lock in the first place.
Since our update of MERGE_RR is the usual atomic rename done
by commit_lock_file, they can just do a lockless read. For
that, we teach setup_rerere a READONLY flag to avoid the
lock.
As a bonus, this pushes builtin/rerere.c's setup_rerere call
closer to the functions that use it. Which means that "git
rerere totally-bogus-command" will no longer silently
exit(0) in a repository without rerere enabled.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-02 00:14:09 +02:00
|
|
|
return;
|
|
|
|
|
|
2017-08-19 20:43:39 +02:00
|
|
|
git_config_get_expiry_in_days("gc.rerereresolved", &cutoff_resolve, now);
|
|
|
|
|
git_config_get_expiry_in_days("gc.rerereunresolved", &cutoff_noresolve, now);
|
2014-08-07 18:21:21 +02:00
|
|
|
git_config(git_default_config, NULL);
|
2011-05-08 21:55:34 +02:00
|
|
|
dir = opendir(git_path("rr-cache"));
|
|
|
|
|
if (!dir)
|
2018-08-05 19:20:30 +02:00
|
|
|
die_errno(_("unable to open rr-cache directory"));
|
2015-07-01 07:43:37 +02:00
|
|
|
/* Collect stale conflict IDs ... */
|
2021-05-12 19:28:22 +02:00
|
|
|
while ((e = readdir_skip_dot_and_dotdot(dir))) {
|
2016-03-08 21:11:00 +01:00
|
|
|
struct rerere_dir *rr_dir;
|
|
|
|
|
struct rerere_id id;
|
|
|
|
|
int now_empty;
|
|
|
|
|
|
2021-01-28 07:14:11 +01:00
|
|
|
if (!is_rr_cache_dirname(e->d_name))
|
2016-03-08 21:11:00 +01:00
|
|
|
continue; /* or should we remove e->d_name? */
|
|
|
|
|
|
2021-01-28 07:14:11 +01:00
|
|
|
rr_dir = find_rerere_dir(e->d_name);
|
|
|
|
|
|
2016-03-08 21:11:00 +01:00
|
|
|
now_empty = 1;
|
|
|
|
|
for (id.variant = 0, id.collection = rr_dir;
|
|
|
|
|
id.variant < id.collection->status_nr;
|
|
|
|
|
id.variant++) {
|
2017-08-19 20:16:01 +02:00
|
|
|
prune_one(&id, cutoff_resolve, cutoff_noresolve);
|
2016-03-08 21:11:00 +01:00
|
|
|
if (id.collection->status[id.variant])
|
|
|
|
|
now_empty = 0;
|
2011-05-08 21:55:34 +02:00
|
|
|
}
|
2016-03-08 21:11:00 +01:00
|
|
|
if (now_empty)
|
2011-05-08 21:55:34 +02:00
|
|
|
string_list_append(&to_remove, e->d_name);
|
|
|
|
|
}
|
2011-05-26 15:55:50 +02:00
|
|
|
closedir(dir);
|
2016-03-08 21:11:00 +01:00
|
|
|
|
|
|
|
|
/* ... and then remove the empty directories */
|
2011-05-08 21:55:34 +02:00
|
|
|
for (i = 0; i < to_remove.nr; i++)
|
2016-03-08 21:11:00 +01:00
|
|
|
rmdir(git_path("rr-cache/%s", to_remove.items[i].string));
|
2011-05-08 21:55:34 +02:00
|
|
|
string_list_clear(&to_remove, 0);
|
rerere: release lockfile in non-writing functions
There's a bug in builtin/am.c in which we take a lock on
MERGE_RR recursively. But rather than fix am.c, this patch
fixes the confusing interface from rerere.c that caused the
bug. Read on for the gory details.
The setup_rerere() function both reads the existing MERGE_RR
file, and takes MERGE_RR.lock. In the rerere() and
rerere_forget() functions, we end up in write_rr(), which
will then commit the lock file.
But for functions like rerere_clear() that do not write to
MERGE_RR, we expect the caller to have handled
setup_rerere(). That caller would then need to release the
lockfile, but it can't; the lock struct is local to
rerere.c.
For builtin/rerere.c, this is OK. We run a single rerere
operation and then exit immediately, which has the side
effect of rolling back the lockfile.
But in builtin/am.c, this is actively wrong. If we run "git
am -3 --skip", we call setup-rerere twice without releasing
the lock:
1. The "--skip" causes us to call am_rerere_clear(), which
calls setup_rerere(), but never drops the lock.
2. We then proceed to the next patch.
3. The "--3way" may cause us to call rerere() to handle
conflicts in that patch, but we are already holding the
lock. The lockfile code dies with:
BUG: prepare_tempfile_object called for active object
We could fix this by having rerere_clear() call
rollback_lock_file(). But it feels a bit odd for it to roll
back a lockfile that it did not itself take. So let's
simplify the interface further, and handle setup_rerere in
the function itself, taking away the question from the
caller over whether they need to do so.
We can give rerere_gc() the same treatment, as well (even
though it doesn't have any callers besides builtin/rerere.c
at this point). Note that these functions don't take flags
from their callers to pass along to setup_rerere; that's OK,
because the flags would not be meaningful for what they are
doing.
Both of those functions need to hold the lock because even
though they do not write to MERGE_RR, they are still writing
and should be protected from a simultaneous "rerere" run.
But rerere_remaining(), "rerere diff", and "rerere status"
are all read-only operations. They want to setup_rerere(),
but do not care about taking the lock in the first place.
Since our update of MERGE_RR is the usual atomic rename done
by commit_lock_file, they can just do a lockless read. For
that, we teach setup_rerere a READONLY flag to avoid the
lock.
As a bonus, this pushes builtin/rerere.c's setup_rerere call
closer to the functions that use it. Which means that "git
rerere totally-bogus-command" will no longer silently
exit(0) in a repository without rerere enabled.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-02 00:14:09 +02:00
|
|
|
rollback_lock_file(&write_lock);
|
2011-05-08 21:55:34 +02:00
|
|
|
}
|
|
|
|
|
|
2015-07-01 07:43:37 +02:00
|
|
|
/*
|
|
|
|
|
* During a conflict resolution, after "rerere" recorded the
|
|
|
|
|
* preimages, abandon them if the user did not resolve them or
|
|
|
|
|
* record their resolutions. And drop $GIT_DIR/MERGE_RR.
|
|
|
|
|
*
|
|
|
|
|
* NEEDSWORK: shouldn't we be calling this from "reset --hard"?
|
|
|
|
|
*/
|
2018-11-10 06:49:09 +01:00
|
|
|
void rerere_clear(struct repository *r, struct string_list *merge_rr)
|
2011-05-08 21:55:34 +02:00
|
|
|
{
|
|
|
|
|
int i;
|
|
|
|
|
|
2018-11-10 06:49:09 +01:00
|
|
|
if (setup_rerere(r, merge_rr, 0) < 0)
|
rerere: release lockfile in non-writing functions
There's a bug in builtin/am.c in which we take a lock on
MERGE_RR recursively. But rather than fix am.c, this patch
fixes the confusing interface from rerere.c that caused the
bug. Read on for the gory details.
The setup_rerere() function both reads the existing MERGE_RR
file, and takes MERGE_RR.lock. In the rerere() and
rerere_forget() functions, we end up in write_rr(), which
will then commit the lock file.
But for functions like rerere_clear() that do not write to
MERGE_RR, we expect the caller to have handled
setup_rerere(). That caller would then need to release the
lockfile, but it can't; the lock struct is local to
rerere.c.
For builtin/rerere.c, this is OK. We run a single rerere
operation and then exit immediately, which has the side
effect of rolling back the lockfile.
But in builtin/am.c, this is actively wrong. If we run "git
am -3 --skip", we call setup-rerere twice without releasing
the lock:
1. The "--skip" causes us to call am_rerere_clear(), which
calls setup_rerere(), but never drops the lock.
2. We then proceed to the next patch.
3. The "--3way" may cause us to call rerere() to handle
conflicts in that patch, but we are already holding the
lock. The lockfile code dies with:
BUG: prepare_tempfile_object called for active object
We could fix this by having rerere_clear() call
rollback_lock_file(). But it feels a bit odd for it to roll
back a lockfile that it did not itself take. So let's
simplify the interface further, and handle setup_rerere in
the function itself, taking away the question from the
caller over whether they need to do so.
We can give rerere_gc() the same treatment, as well (even
though it doesn't have any callers besides builtin/rerere.c
at this point). Note that these functions don't take flags
from their callers to pass along to setup_rerere; that's OK,
because the flags would not be meaningful for what they are
doing.
Both of those functions need to hold the lock because even
though they do not write to MERGE_RR, they are still writing
and should be protected from a simultaneous "rerere" run.
But rerere_remaining(), "rerere diff", and "rerere status"
are all read-only operations. They want to setup_rerere(),
but do not care about taking the lock in the first place.
Since our update of MERGE_RR is the usual atomic rename done
by commit_lock_file, they can just do a lockless read. For
that, we teach setup_rerere a READONLY flag to avoid the
lock.
As a bonus, this pushes builtin/rerere.c's setup_rerere call
closer to the functions that use it. Which means that "git
rerere totally-bogus-command" will no longer silently
exit(0) in a repository without rerere enabled.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-02 00:14:09 +02:00
|
|
|
return;
|
|
|
|
|
|
2011-05-08 21:55:34 +02:00
|
|
|
for (i = 0; i < merge_rr->nr; i++) {
|
2015-07-05 02:38:34 +02:00
|
|
|
struct rerere_id *id = merge_rr->items[i].util;
|
2016-03-08 21:11:00 +01:00
|
|
|
if (!has_rerere_resolution(id)) {
|
2015-07-06 23:45:55 +02:00
|
|
|
unlink_rr_item(id);
|
2016-03-08 21:11:00 +01:00
|
|
|
rmdir(rerere_path(id, NULL));
|
|
|
|
|
}
|
2011-05-08 21:55:34 +02:00
|
|
|
}
|
2018-11-10 06:49:09 +01:00
|
|
|
unlink_or_warn(git_path_merge_rr(r));
|
rerere: release lockfile in non-writing functions
There's a bug in builtin/am.c in which we take a lock on
MERGE_RR recursively. But rather than fix am.c, this patch
fixes the confusing interface from rerere.c that caused the
bug. Read on for the gory details.
The setup_rerere() function both reads the existing MERGE_RR
file, and takes MERGE_RR.lock. In the rerere() and
rerere_forget() functions, we end up in write_rr(), which
will then commit the lock file.
But for functions like rerere_clear() that do not write to
MERGE_RR, we expect the caller to have handled
setup_rerere(). That caller would then need to release the
lockfile, but it can't; the lock struct is local to
rerere.c.
For builtin/rerere.c, this is OK. We run a single rerere
operation and then exit immediately, which has the side
effect of rolling back the lockfile.
But in builtin/am.c, this is actively wrong. If we run "git
am -3 --skip", we call setup-rerere twice without releasing
the lock:
1. The "--skip" causes us to call am_rerere_clear(), which
calls setup_rerere(), but never drops the lock.
2. We then proceed to the next patch.
3. The "--3way" may cause us to call rerere() to handle
conflicts in that patch, but we are already holding the
lock. The lockfile code dies with:
BUG: prepare_tempfile_object called for active object
We could fix this by having rerere_clear() call
rollback_lock_file(). But it feels a bit odd for it to roll
back a lockfile that it did not itself take. So let's
simplify the interface further, and handle setup_rerere in
the function itself, taking away the question from the
caller over whether they need to do so.
We can give rerere_gc() the same treatment, as well (even
though it doesn't have any callers besides builtin/rerere.c
at this point). Note that these functions don't take flags
from their callers to pass along to setup_rerere; that's OK,
because the flags would not be meaningful for what they are
doing.
Both of those functions need to hold the lock because even
though they do not write to MERGE_RR, they are still writing
and should be protected from a simultaneous "rerere" run.
But rerere_remaining(), "rerere diff", and "rerere status"
are all read-only operations. They want to setup_rerere(),
but do not care about taking the lock in the first place.
Since our update of MERGE_RR is the usual atomic rename done
by commit_lock_file, they can just do a lockless read. For
that, we teach setup_rerere a READONLY flag to avoid the
lock.
As a bonus, this pushes builtin/rerere.c's setup_rerere call
closer to the functions that use it. Which means that "git
rerere totally-bogus-command" will no longer silently
exit(0) in a repository without rerere enabled.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-02 00:14:09 +02:00
|
|
|
rollback_lock_file(&write_lock);
|
2011-05-08 21:55:34 +02:00
|
|
|
}
|