Manoj Babu04/17/2023, 3:59 PM
Oz Katz04/17/2023, 7:03 PM
Manoj Babu04/17/2023, 7:58 PM
Ariel Shaqed (Scolnicov)04/17/2023, 8:10 PM
) is just porcelain. As a result, Git doesn't care about what kind of conflict I had. GitHub and GitLab, in this comparison, do care about conflict resolution. The interactive workflow that they offer for conflict resolution in PRs is actually quite limited, and I don't know anyone who uses it. Perhaps I don't know enough people. So on lakeFS-as-Git, I see 2 options -- and each will allow us to get a conflict resolution flow. Option A: I think we could start by being Git here. It's a bit harder because lakeFS has only a staging area and cannot have a working tree. But we could still offer this partial merge result as a commit (and do whatever with the conflicts, just mark them)! A Git staging are is just a commit that is not linked to any other commit. We could do the same: a failed merge could still generate a result into an unlinked commit (or just metarange, but commits are supported by the lakeFS API), and then return the digest of that commit. We could even give that commit a staging area if we wanted to work there! This commit would magically mark conflicts, say as metadata. Resolving a merge is a process on top of lakeFS that somehow re-merges the objects from the merge source and destination, and writes to the staging area. Eventually, all conflicts are resolved, and we can "complete" the merge. It's actually just a re-merge, using the staging area as the source. Option B: Don't bother 🙂 . Say my merge from S to D has a conflict. I branch out of S to S2, merge D into S2 with a strategy that makes D win. Now I look at S versus S2, and wherever there's a conflict I do "something". I commit the result into S2, and merge S2 into D. I am not sure how option A is more powerful than option B. Perhaps we need to automate option B as part of lakeFS-as-GitLab...?
git merge --continue
Manoj Babu04/17/2023, 9:11 PM
Ariel Shaqed (Scolnicov)04/18/2023, 6:54 AM