1

Following Trunk Based Development, shown below:

enter image description here

Assume there are two short-lived feature branches(f1 and f2) created from master(trunk). For implementation, source code files used for these branches overlap, in this scenario.

Assume, there is one CI/CD pipeline for master(trunk) that gets triggered on code change.

One code conflict that can be possible is functional, f1 could remove or modify existing source code that f2 uses.... This is not a VCS conflict.

Developer1 has perform git commit on f1(in laptop) at time t and yet to push

Developer2 has perform git commit on f2(in laptop) at time t+24 and yet to push

As per my understanding, below is the scenario in commit History file of laptop, before push:

enter image description here Given above sccenario, f1 can get merge with master, which is a simple fast-forward merge. So, master and f1 will point to 156b4bf commit snapshot, after this merge, as shown below:

enter image description here CI/CD pipeline gets triggered, as merge is successful, with no conflicts

But when f2 commit happens after 24 hours, Git will perform 3-way merge using 3 snapshots(156b4bf, 96f5b29 and c435356), as shown below:

enter image description here CI/CD pipeline gets triggered again, if merge is successful. My understanding is, Git should block 3-way merge due to functional conflict.

1) Using Git, Does fast-forward/3-way merge detect functional conflict?

2) If yes, are there any other non-VCS conflict scenarios that ApartCI address? that Git cannot... if yes, how?

Note: No plan to use Gitflow workflow

overexchange
  • 15,768
  • 30
  • 152
  • 347

1 Answers1

1

A purely functional conflict is one in which the 2 conflicting changes don't touch the same files:

  • f1 modifies a function prototype (let's say in file S1) and all its usages (let's say in files S2 and S3)
  • f2 adds a new function usage in a different file in which the function wasn't used before (let's say in file S4), using the original prototype since it doesn't yet see the f1 change

Each change takes in isolation could pass verifications, but when integrated together in the same branch the code won't work as the invocation added in S4 won't match the updated prototype from S1.

In such case both merges are fast-forward and the conflict can not be detected by git - there will be no actual file merges in the 3-way merge since the changesets don't touch the same files. Thus neither will the conflict be detected by git-based tools analyzing the merge, for example by gerrit.

Only the verifications performed by the CI/CD tool can detect such purely functional conflict by finding the mismatch. Depending on the language used it'd be either a build/compilation error or a test/runtime/execution error.

If the 2 changes cause a merge conflict (3-way or not) it means the conflict is a VCS one, not a purely functional one and yes, it would be detected by git and/or git-based tools, so it would need to be addressed before the merge is allowed (a CI/CD tool execution would not be necessary for detecting it)

To your 2nd question ApartCI would detect either kind of conflict:

  • if it's a VCS conflict the 2 changes are overlapping (i.e. they both touch at least one common source file) so they won't be bundled together for simultaneous verification. Which means that they will never end up in a primary bundle together. One of them will be committed and end up in the project's baseline first. As soon as that happens the other change will fail patching in its next verification attempt and will be rejected.
  • if it's a purely functional conflict the 2 changes are not overlapping, so they may or may not end up in the same bundle.
    • if they are not in the same bundle the flow of events will be pretty much the same as that for a VCS conflict
    • if they are in the same bundle the bundle verification will fail and following the bundle splitting actions they will eventually end up in different bundle and again the same flow of events as that for a VCS conflict will follow
Dan Cornilescu
  • 39,470
  • 12
  • 57
  • 97
  • 1
    Dan is taking C language as example here... when he says... function prototype and definition... – overexchange Jan 20 '19 at 19:16
  • For your point... "there will be no 3-way merge", am bit skeptic on this... 3-way merge happens after f2 commit. 3-way merge is not invoked based on same/different file strategy.. 3-way merge is invoked based on the path(direct/indirect) between master and f2(any branch that needs to be merged). – overexchange Jan 20 '19 at 19:19
  • Sorry, by `there will be no 3-way merge` I mean that no files will be technically merged in such case, simply a different version of the files will be selected. – Dan Cornilescu Jan 20 '19 at 19:27
  • yes.... the criteria is... to **just detect** the conflict... I would not need a tool to resolve the conflict... Isn't it? Human intervention is better.... – overexchange Jan 20 '19 at 19:31
  • [Here](https://stackoverflow.com/a/54223312/3317808) it says...Merge conflicts are very risky to automate, which would preclude the possibility of automating it at all..... is ApartCI trying to detect the conflict or detect&resolve the conflict? – overexchange Jan 20 '19 at 19:33
  • Human intervention is better to **resolve** conflicts, yes, but to just **detect** them automation is IMHO preferable. Why waste developer time with something that the machine can typically do faster and better? – Dan Cornilescu Jan 20 '19 at 19:36
  • No, apartCI makes no attempt to resolve conflicts, its only goal is to isolate them as efficiently as possible and pass them to humans for resolution, while automatically driving the integration of the other, non-conflicting changes. – Dan Cornilescu Jan 20 '19 at 19:41