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

user_2054629 0
Viewed 106

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!
git
1 Answers

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.

user_12907310
Related