From: Junio C Hamano <gitster@pobox.com>
To: git@vger.kernel.org
Subject: [PATCH v3 04/11] rerere: delay the recording of preimage
Date: Wed, 6 Apr 2016 16:05:28 -0700 [thread overview]
Message-ID: <1459983935-25267-5-git-send-email-gitster@pobox.com> (raw)
In-Reply-To: <1459983935-25267-1-git-send-email-gitster@pobox.com>
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>
---
rerere.c | 52 +++++++++++++++++++++++++---------------------------
1 file changed, 25 insertions(+), 27 deletions(-)
diff --git a/rerere.c b/rerere.c
index a1e2963..33b1348 100644
--- a/rerere.c
+++ b/rerere.c
@@ -122,6 +122,11 @@ static int has_rerere_resolution(const struct rerere_id *id)
return ((id->collection->status & both) == both);
}
+static int has_rerere_preimage(const struct rerere_id *id)
+{
+ return (id->collection->status & RR_HAS_PREIMAGE);
+}
+
static struct rerere_id *new_rerere_id_hex(char *hex)
{
struct rerere_id *id = xmalloc(sizeof(*id));
@@ -749,8 +754,24 @@ static void do_rerere_one_path(struct string_list_item *rr_item,
const char *path = rr_item->string;
const struct rerere_id *id = rr_item->util;
- /* Is there a recorded resolution we could attempt to apply? */
- if (has_rerere_resolution(id)) {
+ if (!has_rerere_preimage(id)) {
+ /*
+ * We are the first to encounter this conflict. Ask
+ * handle_file() to write the normalized contents to
+ * the "preimage" file.
+ */
+ handle_file(path, NULL, rerere_path(id, "preimage"));
+ if (id->collection->status & RR_HAS_POSTIMAGE) {
+ const char *path = rerere_path(id, "postimage");
+ if (unlink(path))
+ die_errno("cannot unlink stray '%s'", path);
+ id->collection->status &= ~RR_HAS_POSTIMAGE;
+ }
+ id->collection->status |= RR_HAS_PREIMAGE;
+ fprintf(stderr, "Recorded preimage for '%s'\n", path);
+ return;
+ } else if (has_rerere_resolution(id)) {
+ /* Is there a recorded resolution we could attempt to apply? */
if (merge(id, path))
return; /* failed to replay */
@@ -807,31 +828,8 @@ static int do_plain_rerere(struct string_list *rr, int fd)
id = new_rerere_id(sha1);
string_list_insert(rr, path)->util = id;
- /*
- * Ensure that the directory exists.
- * mkdir_in_gitdir() will fail with EEXIST if there
- * already is one.
- */
- if (mkdir_in_gitdir(rerere_path(id, NULL)) &&
- errno != EEXIST)
- continue; /* NEEDSWORK: perhaps we should die? */
-
- if (id->collection->status & RR_HAS_PREIMAGE) {
- ;
- } else {
- /*
- * We are the first to encounter this
- * conflict. Ask handle_file() to write the
- * normalized contents to the "preimage" file.
- *
- * NEEDSWORK: what should happen if we had a
- * leftover postimage that is totally
- * unrelated? Perhaps we should unlink it?
- */
- handle_file(path, NULL, rerere_path(id, "preimage"));
- id->collection->status |= RR_HAS_PREIMAGE;
- fprintf(stderr, "Recorded preimage for '%s'\n", path);
- }
+ /* Ensure that the directory exists. */
+ mkdir_in_gitdir(rerere_path(id, NULL));
}
for (i = 0; i < rr->nr; i++)
--
2.8.1-273-ga2cd0f9
next prev parent reply other threads:[~2016-04-06 23:06 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-14 23:57 [PATCH 0/7] saving and replaying multiple variants with rerere Junio C Hamano
2015-09-14 23:57 ` [PATCH 1/7] rerere: split conflict ID further Junio C Hamano
2015-09-14 23:57 ` [PATCH 2/7] rerere: scan $GIT_DIR/rr-cache/$ID when instantiating a rerere_id Junio C Hamano
2015-09-14 23:57 ` [PATCH 3/7] rerere: handle leftover rr-cache/$ID directory and postimage files Junio C Hamano
2015-09-14 23:57 ` [PATCH 4/7] rerere: delay the recording of preimage Junio C Hamano
2015-09-14 23:57 ` [PATCH 5/7] rerere: allow multiple variants to exist Junio C Hamano
2015-09-14 23:57 ` [PATCH 6/7] t4200: rerere a merge with two identical conflicts Junio C Hamano
2015-09-14 23:57 ` [PATCH 7/7] rerere: do use multiple variants Junio C Hamano
2016-03-28 22:42 ` [PATCH v2 00/11] saving and replaying multiple variants with rerere Junio C Hamano
2016-03-28 22:42 ` [PATCH v2 01/11] rerere: split conflict ID further Junio C Hamano
2016-03-28 22:42 ` [PATCH v2 02/11] rerere: scan $GIT_DIR/rr-cache/$ID when instantiating a rerere_id Junio C Hamano
2016-03-28 22:42 ` [PATCH v2 03/11] rerere: handle leftover rr-cache/$ID directory and postimage files Junio C Hamano
2016-03-28 22:42 ` [PATCH v2 04/11] rerere: delay the recording of preimage Junio C Hamano
2016-03-28 22:42 ` [PATCH v2 05/11] rerere: allow multiple variants to exist Junio C Hamano
2016-03-28 22:42 ` [PATCH v2 06/11] t4200: rerere a merge with two identical conflicts Junio C Hamano
2016-03-28 22:42 ` [PATCH v2 07/11] rerere: do use multiple variants Junio C Hamano
2016-03-28 22:42 ` [PATCH v2 08/11] rerere: gc and clear Junio C Hamano
2016-03-28 22:42 ` [PATCH v2 09/11] rerere: move code related to "forget" together Junio C Hamano
2016-03-28 22:42 ` [PATCH v2 10/11] rerere: split code to call ll_merge() further Junio C Hamano
2016-03-28 22:42 ` [PATCH v2 11/11] rerere: adjust 'forget' to multi-variant world order Junio C Hamano
2016-04-06 23:05 ` [PATCH v3 00/11] saving and replaying multiple variants with rerere Junio C Hamano
2016-04-06 23:05 ` [PATCH v3 01/11] rerere: split conflict ID further Junio C Hamano
2016-04-06 23:05 ` [PATCH v3 02/11] rerere: scan $GIT_DIR/rr-cache/$ID when instantiating a rerere_id Junio C Hamano
2016-04-06 23:05 ` [PATCH v3 03/11] rerere: handle leftover rr-cache/$ID directory and postimage files Junio C Hamano
2016-04-06 23:05 ` Junio C Hamano [this message]
2016-04-06 23:05 ` [PATCH v3 05/11] rerere: allow multiple variants to exist Junio C Hamano
2016-04-06 23:05 ` [PATCH v3 06/11] t4200: rerere a merge with two identical conflicts Junio C Hamano
2016-04-06 23:05 ` [PATCH v3 07/11] rerere: do use multiple variants Junio C Hamano
2016-04-06 23:05 ` [PATCH v3 08/11] rerere: gc and clear Junio C Hamano
2016-04-06 23:05 ` [PATCH v3 09/11] rerere: move code related to "forget" together Junio C Hamano
2016-04-06 23:05 ` [PATCH v3 10/11] rerere: split code to call ll_merge() further Junio C Hamano
2016-04-06 23:05 ` [PATCH v3 11/11] rerere: adjust 'forget' to multi-variant world order Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1459983935-25267-5-git-send-email-gitster@pobox.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).