On 2024-03-15 at 13:22:52, Kai wrote:
> Ok, I was assuming that having the whole files may be better to
> reproduce the problem, but if just the relevant parts are enough, let
> me do that.
>
> Here is an example from all three files:
>
> ### BASE FILE (I used git merge-base master hook-form to show the
> ancestor commit)
> export const AddListingForm = (active: number) => {
>
>
> const form = useForm({
>
> defaultValues: {
> city: { name: '', lat: 0, lon: 0 },
> neighborhood: { name: '', lat: 0, lon: 0, neighborhood: '' },
>
>
>
> ### MASTER BRANCH (THEIR VERSION):
> export const AddListingForm = (active: number) => {
> const form = useForm({
> name: "add-listing-form",
> initialValues: {
> city: { name: "", lat: 0, lon: 0 },
> neighborhood: { name: "", lat: 0, lon: 0, neighborhood: "" },
>
>
>
> ### HOOK-FORM BRANCH (OUR VERSION):
> export const AddListingForm = (active: number) => {
>
>
> const form = useForm({
>
> defaultValues: {
> city: { name: '', lat: 0, lon: 0 },
> neighborhood: { name: '', lat: 0, lon: 0, neighborhood: '' },
>
>
> ### GIT DIFF MASTER TO BASE FILE (git diff
> 12545fa846fb0d042a4ed29ee0699d89f1621bc2 master --
> components/add-listing/forms/AddListingForm.ts)
> const form = useForm({
> -
> - defaultValues: {
> - city: { name: '', lat: 0, lon: 0 },
> - neighborhood: { name: '', lat: 0, lon: 0, neighborhood: '' },
> + name: "add-listing-form",
> + initialValues: {
>
> ### GIT DIFF BASE FILE TO HOOK-FORM (git diff
> 12545fa846fb0d042a4ed29ee0699d89f1621bc2 hook-form --
> components/add-listing/forms/AddListingForm.ts)
> No diff in relevant part
>
>
> So as you can see, in this case Master has changes to the base file at
> the relevant part, while in the hook form branch we continued to use
> the base file version of that part. Now maybe I misunderstand how
> merge conflicts are supposed to work, but shouldn't I expect git
> marking the changes master made as a conflict? Because in master parts
> of the file were changed that I did not change in the new branch? When
> I now merge, the code is not working, because masters code is applied
> and it breaks other parts of the code in the same file.
I think you may misunderstand how a three-way merge works. Git
considers exactly three points: the merge base and the two heads. If,
in a particular region of code, there is a difference between the merge
base and one of the heads, and no difference between the merge base and
the other head, then Git adopts the difference. This is the fundamental
idea of a three-way merge: to include the changes made from both sides.
This is true even if the side that has no changes between the merge base
and one of the heads has had multiple changes and reverts in between.
The intermediate states of the two branches are not considered.
It is also irrelevant what happens to other parts of the file as long as
they are not directly adjacent to the parts that the merge is working
on.
So in this case, it looks like Git is functioning as expected.
> If this is expected behavior, this is a big issue in this case, as I
> cannot trust that after sorting all conflicts that my code will work.
> In that case I would need to manually review every diff. Or is there
> maybe a stricter mode for merge conflicts, to also highlight these
> types of differences?
This is called a semantic conflict, and it can occur. Git typically
operates on lines for diffs and merges, and that doesn't intrinsically
line up with functional units of code, as you've seen. It's possible
that a three-way merge produces broken or even syntactically invalid
code.
This is why you need tests, so that people can run the tests on the
merged value and verify that the result is functional. Usually this can
be done via a CI system.
--
brian m. carlson (they/them or he/him)
Toronto, Ontario, CA
Attachment:
signature.asc
Description: PGP signature
