Thread (218 messages) 218 messages, 10 authors, 2022-06-18

Re: [PATCH 08/12] merge-ort: provide a merge_get_conflicted_files() helper function

From: Elijah Newren <hidden>
Date: 2022-01-29 16:47:56

On Sat, Jan 29, 2022 at 12:23 AM Johannes Sixt [off-list ref] wrote:
Just a heckling from the peanut gallery...

Am 29.01.22 um 07:08 schrieb Elijah Newren:
quoted
On Fri, Jan 28, 2022 at 8:55 AM Johannes Schindelin
[off-list ref] wrote:
quoted
Meaning: Even if stage 3 is missing from the first conflict and stage 1 is
missing from the second conflict, in the output we would see stages 1, 2,
2, 3, i.e. a duplicate stage 2, signifying that we're talking about two
different conflicts.
I don't understand why you're fixating on the stage here.  Why would
you want to group all the stage 2s together, count them up, and then
determine there are N conflicting files because there are N stage 2's?
Looks like you are misunderstanding Dscho's point: When you have two
conflicts, the first with stages 1 and 2, the second with stages 2 and
3, then the 2s occur lumped together when the 4 lines are printed in a
row, and that is the cue to the parser where the new conflict begins.
Dscho did not mean that all N 2s of should be listed together.
Ah, so...I didn't understand his misunderstanding?  Using stages as a
cue to the parser where the new conflict begins is broken; you should
instead check for when the filename listed on a line does not match
the filename on the previous line.  In particular, if one conflict has
stages 1 and 2, and the next conflict has only stage 3, then looking
at stages only might cause you to accidentally lump unrelated
conflicts together.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help