Detect merge conflict between two git diff without having access to the original repo

Question

Is it possible to detect merge conflicts between two git diff without having access to the repository anymore ?

For instance:

$repo: git diff HEAD > ~/diff1
... do work, move branches etc
$repo: git diff HEAD > ~/diff2

$somewhereElse: git merge-diff ~/diff1 ~/diff2  ??

Edit: Here's an example of two diff that conflict, which we can tell with no knowledge of the repo

diff --git a/schema.graphql b/schema.graphql
index 346rb8i42tg..3f0deee83ad 100644
--- a/schema.graphql
+++ b/schema.graphql
@@ -12,7 +12,6 @@ interface Thing {
 
 interface Being {
   name: String!
-  possessions: [Thing!]!
   lifeExpectancy: Float
   friends: [Being!]!
   optionalFriends: [Character]

diff --git a/schema.graphql b/schema.graphql
index 297fb5e764e..de9fbc233ac 100644
--- a/schema.graphql
+++ b/schema.graphql
@@ -14,6 +14,7 @@ interface Being {
   name: String!
   possessions: [Thing!]!
   lifeExpectancy: Float
+  surname: String
   friends: [Being!]!
   optionalFriends: [Character]
   isRebel: Boolean!

If you have cloned it, you could just attempt to do the merge. If not, check if the diffy modify the same part of the same file. — dan1st, Jan 26 '21 at 21:35
I'm in a situation with a very large repo and every git operation is too slow for what I need, so I can't just stash, checkout, apply etc. I think that the diffs contain all the info required to understand if they would conflict, but I don't know of a command that would analyze them as I need. — Guig, Jan 26 '21 at 22:45
The idea of saying `git diff` without a repo is meaningless. To whom would you be speaking? — matt, Jan 27 '21 at 00:30
Merge doesn't compare HEAD vs work-tree, but rather merge-base (which requires traversing the commit graph) vs HEAD and the other commit in question. There is no `git merge-diff` command, either; I can make no sense of this question. — torek, Jan 27 '21 at 00:56
Well, it's not entirely clear, but you could perhaps use a diff parser and then try to figure out if there's an intersection of the file/line modified in the patches. — plalx, Jan 27 '21 at 02:58

jthill · Answer 1 · 2021-01-28T00:22:53.230

I'm in a situation with a very large repo and every git operation is too slow for what I need

Git has facilities for dealing with this: split indexes and minimum-checkout merges come to mind immediately.

Minimum-checkout merges aren't a separate facility, they're just how Git works: merge doesn't have to see anything but the files that might need automerge, i.e. were changed on both tips, so that's all the files that actually need to be in your work tree, and if you haven't set that up yet it'll do the checkouts for you, just the ones it needs.

If say you're on dev and want to merge trunk:

git clone -ns . `mktemp -d`; cd $_
git reset -q         # load just the index

# note that when I do the above on the full linux history, a 2.8GB repo on my box, 
# the clone and index reload, the result occupies about 6MB total Basically nothing.

git merge trunk

and only the files that might conflict will be checked out.

If your index is so large that any update is painful, do git update-index --split-index after the reset, that will cause unchanging entries to be kept in a sideband/baseline file and only updated entries loaded/rewritten separately.

If you're after pushing the results, you'll need to negotiate the HEAD update with your main repo, easiest is probably git push origin HEAD:refs/heads/somenewbranch and then fastforward your main repo to that. After doing git update-index --split-index there first, natch.

edit: if you want to run a test merge to any other branch, add -b thatbranch to the clone. All branches being ephemeral and local, you can git branch wip somecommit and clone -nsb wip to reflight a merge to that commit.

But how do you square this with the OP’s “without having access to the repository anymore”? — matt, Jan 27 '21 at 04:09
@matt OP's stated reason for not having access to the repo was GIt made the operations too slow. I'm showing how to correct what's producing the limitation that leads to the problem he's facing. Better to make a problem not be a problem at all, right? — jthill, Jan 27 '21 at 04:14

Detect merge conflict between two git diff without having access to the original repo

1 Answers1

Linked