Currently a call to check_stages is using bit-shift values to define what will be used
as the first argument. If the reader doesn't know what the values are from heart, they
have to go dig in cache.h what each value is.
This patch is replacing those values for the macros from cache.h so that it's
clear at first sight what they are (CE_ENTRY_REMOVED, CE_ENTRY_ADDED)
Signed-off-by: Edmundo Carmona Antoranz <redacted>
---
builtin/checkout.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/checkout.c b/builtin/checkout.c
index ffa776c6e1..3a644b31f6 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -397,7 +397,7 @@ static int checkout_paths(const struct checkout_opts *opts,
} else if (opts->writeout_stage) {
errs |= check_stage(opts->writeout_stage, ce, pos, opts->overlay_mode);
} else if (opts->merge) {
- errs |= check_stages((1<<2) | (1<<3), ce, pos);
+ errs |= check_stages(CE_ENTRY_REMOVED | CE_ENTRY_ADDED, ce, pos);
} else {
errs = 1;
error(_("path '%s' is unmerged"), ce->name);--
2.26.2
On Sat, Jun 6, 2020 at 11:49 PM Edmundo Carmona Antoranz
[off-list ref] wrote:
Currently a call to check_stages is using bit-shift values to define what will be used
as the first argument. If the reader doesn't know what the values are from heart, they
have to go dig in cache.h what each value is.
This patch is replacing those values for the macros from cache.h so that it's
clear at first sight what they are (CE_ENTRY_REMOVED, CE_ENTRY_ADDED)
The macros are defined since at least v2.1.0 and I am able to apply
the patch on top of it. Should
I send the patch from that version? I am sending on top of v2.22.4
cause it's the oldest version I
was able to compile successfully.
Edmundo Carmona Antoranz [off-list ref] writes:
Currently a call to check_stages is using bit-shift values to
define what will be used as the first argument. If the reader
doesn't know what the values are from heart, they have to go dig
in cache.h what each value is.
This patch is replacing those values for the macros from cache.h so that it's
clear at first sight what they are (CE_ENTRY_REMOVED, CE_ENTRY_ADDED)
The patch does not make sense. The hardcoded numbers you touched
have nothing to do with these macros.
The first argument to check_stages() is a bitmask for the stage
numbers in the index (which can span from 1 to 3), where 1 means
"common ancestor", 2 means "ours" and 3 means "theirs". The caller
gives a position 'pos' in the in-core index and asks the function
this question: "starting at position 'pos', there must be cache
entries with the same path as 'ce'---are these enries cover all the
stages specified by this mask?" This particular caller wants to
make sure that there are both "ours" and "theirs" entries for the
path.
The thing is, CE_ENTRY_REMOVED may also happen to have the value of
4, but that has nothing to do with (1<<2) used in the argument of
this. It was not chosen to be the value of 1 shifted by the stage
number for "ours". Same thing for CE_ENTRY_ADDED and (1<<3). Even
when these macros are renumbered, the argument to check_stages()
must stay the values they are written in the original code
(i.e. (1<<2)|(1<<3) == 12).
quoted hunk
Signed-off-by: Edmundo Carmona Antoranz <redacted>
---
builtin/checkout.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/checkout.c b/builtin/checkout.c
index ffa776c6e1..3a644b31f6 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -397,7 +397,7 @@ static int checkout_paths(const struct checkout_opts *opts,
} else if (opts->writeout_stage) {
errs |= check_stage(opts->writeout_stage, ce, pos, opts->overlay_mode);
} else if (opts->merge) {
- errs |= check_stages((1<<2) | (1<<3), ce, pos);
+ errs |= check_stages(CE_ENTRY_REMOVED | CE_ENTRY_ADDED, ce, pos);
} else {
errs = 1;
error(_("path '%s' is unmerged"), ce->name);
On Tue, Jun 9, 2020 at 2:22 PM Junio C Hamano [off-list ref] wrote:
The patch does not make sense. The hardcoded numbers you touched
have nothing to do with these macros.
Totally misguided myself. Sorry for the confusion.