उपनिर्देशिका में गेट रिपोजिटरी मर्ज करें

Question

मैं अपने काम करने वाले गिट रिपॉजिटरी में एक रिमोट गैट रिपॉजिटरी को इसके एक उपनिर्देशिका के रूप में मर्ज करना चाहता हूं। मैं परिणामी रिपॉजिटरी को दो रिपॉजिटरी के मर्ज किए गए इतिहास को सम्‍मिलित करना चाहूंगा और यह भी कि मर्ज किए गए रिपॉजिटरी की प्रत्‍येक फाइल अपने इतिहास को बनाए रखती है क्‍योंकि यह रिमोट रिपॉजिटरी में थी। मैंने सबट्री रणनीति का उपयोग करने की कोशिश की जैसा कि उप-मर्ज की रणनीति का उपयोग करने के तरीके में उल्लेख किया गया है , लेकिन उस प्रक्रिया का पालन करने के बाद, हालांकि परिणामी रिपॉजिटरी में वास्तव में दो रिपॉजिटरी के मर्ज किए गए इतिहास शामिल हैं, रिमोट से आने वाली व्यक्तिगत फाइलें उनके इतिहास को बरकरार नहीं रखती हैं। (उनमें से किसी पर `गिट लॉग 'सिर्फ एक संदेश" मर्ज की गई शाखा ... ") दिखाता है।

इसके अलावा, मैं सबमॉड्यूल का उपयोग नहीं करना चाहता क्योंकि मैं नहीं चाहता कि दो संयुक्त गिट रिपॉजिटरी अब अलग हो जाएं।

क्या दूरस्थ रिपॉजिटरी से अपने इतिहास को बनाए रखने वाली व्यक्तिगत फ़ाइलों के साथ एक उपनिर्देशिका के रूप में एक दूसरे में एक दूरस्थ गिट रिपॉजिटरी को मर्ज करना संभव है?

किसी भी मदद के लिए बहुत बहुत धन्यवाद।

संपादित करें: मैं वर्तमान में एक समाधान की कोशिश कर रहा हूं जो मर्ज किए गए भंडार इतिहास को फिर से लिखने के लिए गिट फिल्टर-शाखा का उपयोग करता है। यह काम करने लगता है, लेकिन मुझे इसे कुछ और परखने की जरूरत है। मैं अपने निष्कर्षों पर रिपोर्ट करने के लिए लौटूंगा।

संपादित 2: आशा है कि मैं अपने आप को और अधिक स्पष्ट करता हूं मैं सटीक कमांड देता हूं जिसका उपयोग मैंने गिट की उप-रणनीति रणनीति के साथ किया है, जिसके परिणामस्वरूप दूरस्थ रिपॉजिटरी की फ़ाइलों के इतिहास का स्पष्ट नुकसान होता है। आज्ञा देना एक git प्रतिनिधि मैं वर्तमान में काम कर रहा हूँ और B git प्रतिनिधि मैं इसे एक उपनिर्देशिका के रूप में ए में शामिल करना चाहूंगा। इसने निम्नलिखित कार्य किया:

git remote add -f B <url-of-B>
git merge -s ours --no-commit B/master
git read-tree --prefix=subdir/Iwant/to/put/B/in/ -u B/master
git commit -m "Merge B as subdirectory in subdir/Iwant/to/put/B/in."

इन कमांड्स के बाद और डायरेक्टर सबडिर / Iwant / in / put / B / in में जाने पर, मुझे B की सभी फाइलें दिखाई देती हैं, लेकिन git logउनमें से किसी एक पर बस कमिट मैसेज दिखाता है "subgeir / Iwant / put / में subdirectory के रूप में Merge B / बी / में। " उनका फ़ाइल इतिहास जैसा कि B में है खो गया है।

काम करने के लिए क्या लगता है (जब से मैं शुरुआत में गलत हूं मैं गलत हो सकता हूं) निम्नलिखित है:

git remote add -f B <url-of-B>
git checkout -b B_branch B/master  # make a local branch following B's master
git filter-branch --index-filter \ 
   'git ls-files -s | sed "s-\t\"*-&subdir/Iwant/to/put/B/in/-" |
        GIT_INDEX_FILE=$GIT_INDEX_FILE.new \
                git update-index --index-info &&
        mv "$GIT_INDEX_FILE.new" "$GIT_INDEX_FILE"' HEAD 
git checkout master
git merge B_branch

फ़िल्टर-शाखा के लिए ऊपर की कमान से ली गई है git help filter-branch, जिसमें मैंने केवल उप-पथ को बदल दिया है।

Comments

gitkइतिहास के बारे में क्या कहता है? मैंने अतीत में git सबट्री मर्ज का सफलतापूर्वक उपयोग किया है। शायद आप अपने सटीक आदेशों को प्रकट कर सकते हैं? मुझे यकीन नहीं है कि गिट-फ़िल्टर-शाखा सही दृष्टिकोण है। मैं एक नए इतिहास को संश्लेषित करने के लिए गिट-फास्ट-एक्सपोर्ट और गिट-फास्ट-इम्पोर्ट की कोशिश कर सकता हूं।

— सेठ रॉबर्टसन

सबट्री प्रक्रिया को करने के बाद gitkउनके सुझावों पर मर्ज किए गए दो रेपो को दर्शाता है और उनके प्रारंभिक कमानों में असंबंधित है। (अगर मैं gitk के इतिहास दृश्य के स्क्रीनशॉट पोस्ट करूं तो क्या यह मदद करेगा? क्या मैं?) दुर्भाग्य से दूरस्थ रिपॉजिटरी की अलग-अलग फाइलों ने अगर मैं टर्मिनल में काम करता हूं, तो अपने इतिहास को बरकरार नहीं रखा है git log <file-from-remote-repo>। में देखता हूँ git-fast-exportऔर git-fast-import; मैं बहुत नया हूँ। मैं अपने प्रश्न को यह दिखाने के लिए संपादित करूंगा कि मैंने git सबट्री के साथ कौन सी कमांड का उपयोग किया है। आपके उत्तर के लिए बहुत बहुत धन्यवाद।

— क्रिसमस

@christosc: अपनी दूसरी विधि खूबसूरती से और बहुत ही सरलता से काम किया, बहुत बहुत धन्यवाद! मुझे बस सबडिर / Iwant / को / put / B / in में बदलना था और इसे एक oneliner बनाना था (क्योंकि Windows पर msysgit कमांड में लाइन रिटर्न का समर्थन नहीं करता प्रतीत होता है): git फ़िल्टर-शाखा --index- फ़िल्टर git ls-files -s | sed "s- \ t \" * - & subdir / Iwant / to / put / B / in / - "। GIT_INDEX_FILE "'हेड

— गैबरियस

@ user1121352 खुशी है कि आपकी मदद की।

— क्रिस्मस

मैं आम तौर पर इस जवाब का पालन करता हूं: stackoverflow.com/a/1684694/207791

— विक्टर सर्जियनको

Answer 1

क्या चल रहा है, इसका पूरा विवरण प्राप्त करने के बाद, मुझे लगता है कि मैं इसे समझता हूं और नीचे किसी भी मामले में मुझे एक समाधान है। विशेष रूप से, मेरा मानना ​​है कि जो कुछ भी हो रहा है उसका नाम बदलना पता लगाया जा रहा है - उपसर्ग के साथ सबट्री मर्ज से मूर्ख बनाया गया है। यहाँ मेरा परीक्षण मामला है:

mkdir -p z/a z/b
cd z/a
git init
echo A>A
git add A
git commit -m A
echo AA>>A
git commit -a -m AA
cd ../b
git init
echo B>B
git add B
git commit -m B
echo BB>>B
git commit -a -m BB
cd ../a
git remote add -f B ../b
git merge -s ours --no-commit B/master
git read-tree --prefix=bdir -u B/master
git commit -m "subtree merge B into bdir"
cd bdir
echo BBB>>B
git commit -a -m BBB

हम प्रत्येक के लिए कई हिट के साथ git डाइरेक्टरीज़ a और b बनाते हैं। हम एक सबट्री मर्ज करते हैं, और फिर हम नए सबट्री में एक अंतिम प्रतिबद्ध करते हैं।

रनिंग gitk(z / a में) दिखाता है कि इतिहास दिखाई देता है, हम इसे देख सकते हैं। रनिंग से git logपता चलता है कि इतिहास दिखाई देता है। हालाँकि, किसी विशिष्ट फ़ाइल को देखने में समस्या है: git log bdir/B

खैर, एक चाल है जिसे हम खेल सकते हैं। हम --follow का उपयोग करके किसी विशिष्ट फ़ाइल के पूर्व-पुनर्नामित इतिहास को देख सकते हैं। git log --follow -- B। यह अच्छा है, लेकिन महान नहीं है क्योंकि यह पूर्व-मर्ज के इतिहास को पोस्ट-मर्ज के साथ जोड़ने में विफल रहता है।

मैंने -M और -C के साथ खेलने की कोशिश की, लेकिन मैं इसे एक विशिष्ट फ़ाइल का पालन करने में सक्षम नहीं था।

इसलिए, मुझे लगता है कि समाधान, नाम बदलने के बारे में गिट को बताने के लिए है जो सबट्री मर्ज के हिस्से के रूप में हो रहा है। दुर्भाग्य से गिट-रीड-ट्री, सबट्री मर्ज के बारे में बहुत उधम मचाता है इसलिए हमें एक अस्थायी निर्देशिका के माध्यम से काम करना होगा, लेकिन इससे पहले कि हम कमिट करें। बाद में, हम पूरा इतिहास देख सकते हैं।

सबसे पहले, "ए" रिपॉजिटरी बनाएं और कुछ कमिट करें:

mkdir -p z/a z/b
cd z/a
git init
echo A>A
git add A
git commit -m A
echo AA>>A
git commit -a -m AA

दूसरा, "बी" रिपॉजिटरी बनाएं और कुछ कमिट करें:

cd ../b
git init
echo B>B
git add B
git commit -m B
echo BB>>B
git commit -a -m BB

और इस काम को बनाने की चाल : Git को उपनिर्देशिका बनाकर और उसमें सामग्री को स्थानांतरित करके नाम बदलने के लिए बाध्य करें।

mkdir bdir
git mv B bdir
git commit -a -m bdir-rename

रिपॉजिटरी "ए" पर लौटें और "बी" की सामग्री प्राप्त करें और मर्ज करें:

cd ../a
git remote add -f B ../b
git merge -s ours --no-commit B/master
# According to Alex Brown and pjvandehaar, newer versions of git need --allow-unrelated-histories
# git merge -s ours --allow-unrelated-histories --no-commit B/master
git read-tree --prefix= -u B/master
git commit -m "subtree merge B into bdir"

यह दिखाने के लिए कि वे अब विलीन हो गए हैं:

cd bdir
echo BBB>>B
git commit -a -m BBB

पूरा इतिहास साबित करने के लिए एक जुड़ी श्रृंखला में संरक्षित किया गया है:

git log --follow B

ऐसा करने के बाद हमें इतिहास मिलता है, लेकिन समस्या यह है कि यदि आप वास्तव में पुराने "बी" रेपो को इधर-उधर रख रहे हैं और कभी-कभार उसमें से विलय कर रहे हैं (कहते हैं कि यह वास्तव में एक तीसरी पार्टी है जो रेपो को बनाए रखती है) तो आप उस तीसरे पक्ष के लिए परेशानी में हैं नाम नहीं बदला होगा। आपको अपने नए संस्करण में b के नाम के साथ नए बदलाव मिलाने की कोशिश करनी चाहिए और मुझे डर है कि यह आसानी से नहीं जाएगा। लेकिन अगर बी दूर जा रहा है, तो आप जीत जाते हैं।

Comments

वास्तव में वह काम करता है @ सेठ! और मुझे फिल्टर-ब्रांच के साथ इतिहास के पुनर्लेखन का सहारा नहीं लेना पड़ा, जो कुछ हद तक भ्रामक इतिहास (जैसे देखने के दौरान git log --stat) बनाता है । इसके अलावा मैंने --followगिट लॉग के दस्तावेज में स्विच को नहीं देखा था ; नाम बदलने के साथ बहुत आसान लगता है। आपके इतने विस्तृत और जानकारीपूर्ण उत्तर के लिए बहुत बहुत धन्यवाद!

— क्रिसमस

यह प्रतिक्रिया बहुत अधिक सहायक होगी यदि उदाहरण कोड एक एकल-कोलोन-पृथक एक-लाइनर के बजाय पठनीय लाइनों में टूट गया था। ;)

— जुवाडैक

मैं इसके पूर्ण इतिहास को ध्यान में रखते हुए "b" को "a" में मिलाना चाहता हूं। ऐसा कैसे किया जा सकता था?

— पन्नाधाय

देखिए stackoverflow.com/questions/37937984/… बगफिक्स के लिए

— एलेक्स ब्राउन

जैसा कि @AlexBrown ने उल्लेख किया है, gitइस के नए संस्करणों पर उत्पादन होता है fatal: refusing to merge unrelated historiesऔर इसलिए आपको git merge -s ours --allow-unrelated-histories --no-commit B/masterइसके बजाय चलना चाहिए।

— pjvandehaar

Answer 2

git-subtreeइतिहास को संरक्षित करते हुए (और / या उपशीर्षकों के इतिहास को विभाजित करते हुए, एकाधिक रिपोजिटरी को एक में विलय करने के इस उपयोग के मामले के लिए डिज़ाइन की गई एक स्क्रिप्ट है, हालांकि यह इस प्रश्न के लिए अप्रासंगिक लगता है)। यह 1.7.11 रिलीज के बाद से गिट के पेड़ के हिस्से के रूप में वितरित किया जाता है ।

उपनिर्देशिका के रूप <repo>में संशोधन पर एक रिपॉजिटरी विलय करने के लिए , निम्नानुसार उपयोग करें :<rev><prefix>git subtree add

git subtree add -P <prefix> <repo> <rev>

git-subtree एक अधिक उपयोगकर्ता के अनुकूल तरीके से उप-मर्ज रणनीति को लागू करता है।

नकारात्मक पक्ष यह है कि मर्ज किए गए इतिहास में फ़ाइलों को बिना उपसर्ग वाले हैं (एक उपनिर्देशिका में नहीं) है। कहते हैं कि आप भंडार aको मर्ज करते हैं b। परिणामस्वरूप git log a/f1आपको मर्ज किए गए इतिहास के अलावा सभी परिवर्तन (यदि कोई हो) दिखाएंगे। तुम कर सकते हो:

git log --follow -- f1

लेकिन यह मर्ज किए गए इतिहास में अन्य परिवर्तन नहीं दिखाएगा।

दूसरे शब्दों में, यदि आप aरिपॉजिटरी की फाइलों को नहीं बदलते हैं b, तो आपको निर्दिष्ट --followऔर एक उपसर्ग पथ की आवश्यकता है। यदि आप उन्हें दोनों रिपॉजिटरी में बदलते हैं, तो आपके पास 2 कमांड हैं, जिनमें से कोई भी सभी बदलाव नहीं दिखाता है।

यहाँ पर अधिक है ।

Comments

अच्छा! यह वही है जो मुझे एक पंक्ति में चाहिए था। धन्यवाद, भविष्य!

— इमली

यह एक अन्य भंडार में एक उप-दिशा में मेरी भंडार में विलय करने का सही समाधान है।

— 18:17 पर eitch

ध्यान दें कि यह मौजूदा उपनिर्देशिकाओं के साथ काम नहीं करेगा <prefix>। उदाहरण के लिए, एक उपनिर्देशिका को मर्ज करने के लिए जिसे स्वयं रिपॉजिटरी मैथेन में मैन्युअल रूप से स्थानांतरित किया गया है, और आप इसे वापस मर्ज करना चाहते हैं।

— रिचर्ड कीफर

Answer 3

मैं चाहता था

1. स्पष्ट मर्ज के बिना एक रैखिक इतिहास रखें, और
2. ऐसा लगता है कि मर्ज किए गए भंडार की फाइलें हमेशा उपनिर्देशिका में मौजूद थीं, और साइड इफेक्ट के git log -- fileबिना काम करते हैं --follow।

चरण 1 : स्रोत रिपॉजिटरी में इतिहास को फिर से लिखें, यह देखने के लिए कि सभी फाइलें हमेशा उपनिर्देशिका के नीचे मौजूद थीं।

लिखित इतिहास के लिए एक अस्थायी शाखा बनाएँ।

git checkout -b tmp_subdir

फिर git filter-branchवर्णित के रूप में उपयोग करें कि मैं इतिहास को फिर से कैसे लिख सकता हूं ताकि सभी फाइलें, जिन्हें मैं पहले ही स्थानांतरित कर चुका हूं, एक उपनिर्देशिका में हो? :

git filter-branch --prune-empty --tree-filter '
if [ ! -e foo/bar ]; then
    mkdir -p foo/bar
    git ls-tree --name-only $GIT_COMMIT | xargs -I files mv files foo/bar
fi'

चरण 2 : लक्ष्य भंडार पर स्विच करें। स्रोत रिपॉजिटरी को लक्ष्य रिपॉजिटरी में रिमोट के रूप में जोड़ें और इसकी सामग्री प्राप्त करें।

git remote add sourcerepo .../path/to/sourcerepo
git fetch sourcerepo

चरण 3 : merge --ontoलक्ष्य रिपॉजिटरी के शीर्ष पर फिर से लिखे गए स्रोत भंडार के कमेंट्स को जोड़ने के लिए उपयोग करें ।

git rebase --preserve-merges --onto master --root sourcerepo/tmp_subdir

आप यह देखने के लिए लॉग की जांच कर सकते हैं कि यह वास्तव में आपको मिला है जो आप चाहते थे।

git log --stat

चरण 4 : छूट के बाद आप "अलग" स्थिति में हैं। आप नए सिर के लिए मास्टर-फास्ट कर सकते हैं।

git checkout -b tmp_merged
git checkout master
git merge tmp_merged
git branch -d tmp_merged

चरण 5 : अंत में कुछ सफाई: अस्थायी रिमोट निकालें।

git remote rm sourcerepo

Comments

git rebaseनिर्दिष्ट विकल्पों को एक साथ अनुमति देने के लिए प्रतीत नहीं होता है: "त्रुटि: इंटरएक्टिव विकल्प (--interactive, --exec, --rebase-merges, --preserve- मर्ज, -की-खाली, --root +) को संयोजित नहीं कर सकता है (-आंतो) am के विकल्पों के साथ (--committer-date-is-author-date) "

— सैम

दिलचस्प! छोड़ने की कोशिश करो --committer-date-is-author-date। असंगत विकल्पों के लिए चेक को हाल ही में git v2.19.0 ( github.com/git/git/commit/… ) में जोड़ा गया था । विवरण से ऐसा लगता है जैसे --committer-date-is-author-dateचुपचाप वैसे भी पहले नजरअंदाज कर दिया गया था।

— hfs

पुराने filter-branchआदेश का उपयोग करने के बजाय git filter-repo --to-subdirectory-filter <dir>, इसका उपयोग करें , यह तेज़ और आसान है।

— विलेम

Answer 4

यदि आप वास्तव में चीजों को एक साथ सिलाई करना चाहते हैं, तो ग्राफ्टिंग देखें। आपको भी उपयोग करना चाहिए git rebase --preserve-merges --onto। कमेंट की जानकारी के लिए लेखक की तारीख रखने का विकल्प भी है।

Comments

@adymitruk धन्यवाद, आपके उत्तर के लिए। मैं वास्तव में नया हूँ, इसलिए मैं आपके द्वारा प्रस्तावित प्रस्ताव को देखूंगा। मैंने कोशिश की git filter-branchऔर यह काम करने लगता है, लेकिन शायद आपका बेहतर है। मैं इसे आज़माऊँगा।

— क्रिसमस

@adymitruk क्या मैं दो रिपॉजिटरी के साथ रिबेस का उपयोग कर सकता हूं जो शाखाओं के रूप में अंतर-संबंधित नहीं हैं? मेरा मतलब है कि जिन दो रिपोजिटरीज़ को मैं मर्ज करना चाहता हूं, वे शुरुआती शुरुआती नहीं हैं ...

— क्रिसमस

धन्यवाद @adymitruk मुझे यकीन नहीं था कि रिबासिंग दो असंबंधित रिपॉजिटरी के साथ किया जा सकता है। यह निश्चित रूप से उपयोगी होगा ...

— क्रिसमस

लेकिन फिल्टर-शाखा से डरो मत। यह हमें कई बार बचाया है। बस पहले एक और शाखा बनाएं और आप हमेशा वापस जा सकते हैं। कि, या रिफ्लग का उपयोग करें।

— एडम डाइमिट्रुक

मैं देखता हूं ... किसी भी मामले में मैं इन git अवधारणाओं और आदेशों पर डॉक्स के कुछ पढ़ने को बेहतर बनाता हूं। केवल VCSs में थोड़ा अनुभव है, अर्थात् svn, मैं तरह से अभिभूत हूँ। इसकी शक्ति हालांकि इसके लायक प्रतीत होती है।

— क्रिसमस

Answer 5

मुझे निम्नलिखित समाधान मेरे लिए व्यावहारिक लगे। पहले मैं प्रोजेक्ट बी में जाता हूं, एक नई शाखा बनाता हूं जिसमें पहले से ही सभी फाइलें नई उप निर्देशिका में स्थानांतरित हो जाएंगी। मैं फिर इस नई शाखा को उत्पत्ति की ओर धकेलता हूं। आगे मैं A प्रोजेक्ट में जाता हूं, B का रिमोट जोड़ता हूं और लाता हूं, फिर मैं स्थानांतरित शाखा की जांच करता हूं, मैं मास्टर में वापस जाता हूं और विलय करता हूं:

# in local copy of project B
git checkout -b prepare_move
mkdir subdir
git mv <files_to_move> subdir/
git commit -m 'move files to subdir'
git push origin prepare_move

# in local copy of project A
git remote add -f B_origin <remote-url>
git checkout -b from_B B_origin/prepare_move
git checkout master
git merge from_B

यदि मैं उप निर्देशिका पर जाता subdirहूं, तो मैं उपयोग कर सकता हूं git log --followऔर अभी भी इतिहास है।

मैं एक गिट विशेषज्ञ नहीं हूं, इसलिए मैं यह टिप्पणी नहीं कर सकता कि क्या यह एक विशेष रूप से अच्छा समाधान है या अगर इसमें कैवेट है, लेकिन अभी तक यह सब ठीक है।

Comments

लोग यहां इस दृष्टिकोण को

— बढ़ा

Answer 6

क्या आपने git सबमॉड्यूल के रूप में अतिरिक्त रिपॉजिटरी को जोड़ने की कोशिश की है? यह युक्त भंडार के साथ इतिहास का विलय नहीं करेगा, वास्तव में, यह एक स्वतंत्र भंडार होगा।

मैं इसका उल्लेख करता हूं, क्योंकि आपने नहीं किया है।

Comments

उत्तर Abizern के लिए धन्यवाद। वास्तव में मैं चाहता हूं कि दो रिपॉजिटरी इतिहास को एक में मिला दिया जाए; मैं उन्हें अलग नहीं करना चाहता, इसीलिए मैंने सबमॉडल्स का उल्लेख नहीं किया।

— क्रिसमस

Answer 7

आप भंडार मर्ज करना चाहते हैं कहो aमें b(मैं यह सोचते कर रहा हूँ कि वे एक दूसरे के बगल में स्थित हैं):

cd a
git filter-repo --to-subdirectory-filter a
cd ..
cd b
git remote add a ../a
git fetch a
git merge --allow-unrelated-histories a/master
git remote remove a

यह आप की जरूरत के लिए git-filter-repoस्थापित ( filter-branchहै हतोत्साहित )।

2 बड़े रिपोजिटरी को विलय करने का एक उदाहरण, उनमें से एक को एक उपनिर्देशिका में रखा गया है: https://gist.github.com/x-yuri/9890ab1079cf4357d6f269d073fd9731

यहाँ पर अधिक है ।

Answer 8

Hfs के उत्तर के समान मैं चाहता था

• स्पष्ट मर्ज के बिना एक रैखिक इतिहास रखें और
• ऐसा लगता है कि मर्ज किए गए भंडार की फाइलें हमेशा उपनिर्देशिका में मौजूद थीं, और साइड इफेक्ट के git log -- fileबिना काम करते हैं --follow।

हालाँकि, मैंने अधिक आधुनिक चुना filter-repo(यह मानते हुए कि newरेपो मौजूद है और इसकी जाँच की गई है):

git clone git@host/repo/old.git
cd old
git checkout -b tmp_subdir
git filter-repo --to-subdirectory-filter old

cd ../new
git remote add old ../old
git fetch old
git rebase --rebase-merges --onto main --root old/tmp_subdir --committer-date-is-author-date

--merge -s recursive -X theirsयदि आप theirsसंस्करण के साथ इसे हल करने का प्रयास करना चाहते हैं, तो आपको संघर्ष (मैन्युअल रूप से) को ठीक करने या रीबेस कमांड को बदलने की आवश्यकता हो सकती है :

git rebase --rebase-merges --onto main --root old/tmp_subdir --committer-
date-is-author-date --merge -s recursive -X theirs

आप एक अलग हेड पर समाप्त होते हैं, इसलिए एक नई शाखा बनाएं और इसे मुख्य नोट में मर्ज करें कि आधुनिक रिपॉजिटरी को "मास्टर" शाखा का उपयोग नहीं करना चाहिए लेकिन "मुख्य"

branch for a more inclusive language.
git checkout -b old_merge
git checkout main
git merge old_merge

साफ - सफाई

git branch -d old_merge
git remote rm old