# Joining a fixed archive with its continuation 3 messages from 2006-09-01 to 2006-09-01. Participants: Sergio Callegari, Jakub Narebski, Johannes Schindelin. Thread: https://gitlist.dev/t/5450 ## Sergio Callegari, 2006-09-01 11:56 Subject: Joining a fixed archive with its continuation Message-ID: <44F81FE5.1040509@arces.unibo.it> URL: https://gitlist.dev/e/44F81FE5.1040509%40arces.unibo.it ``` Hi, I am trying to follow Johannes (Dscho) suggestions to join a fixed archive with a new archive, that is its continuation from the latest working tree. I am having some trouble with rebase, and any help would be appreciated. > > You can "graft" the new onto the old branch: > Yes, grafts are fine... however, if I am to use push/pull for transferring data between two computers I am working on, I'd like better a "history rewriting" approach, so that I do not need to manually copy the grafts. > NOTE! This is the quickest way if you want to have the history _locally_. > > If you want to be able to distribute it (or synchronize it between your > laptop and PC _with git!_), you can rewrite the history by either > git-rebase, or by using cg-admin-rewritehist if you are using cogito. > > I have tried using git-rebase (I do not have cg, at least not yet). However I am encountering some problems... Everything is fine with the master branch of my continuation archive doing git rebase fixed-master master (where fixed-master is the master head of the recovered archive) This does the trick nicely. I.e. I start with A---B---C---D E---F---G---H---I where D is fixed-master and I is master, and I end up with A---B---C---D---E'---F'---G'---H'---I' plus the older tree E---...---I However I am then in trouble with the other branches of the continuation archive, which I simply cannot get right... In fact, E...I has actually a branch, say at G, like in E---F---G---H---I \ --M---N And I cannot make an M'---N' based at G'... the best that I am succeeding in is building an E''--F''--G''--M'--N' based on D. > Ciao, > Dscho > > P.S.: Of course, if you do not insist on a super clean history, you can > fake a merge. Just put <40-hex-chars-old> into .git/MERGE_HEAD and commit. > This will pretend that your new head and your old head were merged, and > the result is the new head. This _should_ even work with git-bisect, but > it is slightly ugly. Before I try, can you better explain me what shall go on in this case? The man page of commit actually does not say much about commit behavior during a merge (i.e. with MERGE_HEAD set). Thanks, Sergio ``` ## Jakub Narebski, 2006-09-01 14:12 Subject: Re: Joining a fixed archive with its continuation Message-ID: URL: https://gitlist.dev/e/ed9f3e%24cvm%241%40sea.gmane.org In-Reply-To: <44F81FE5.1040509@arces.unibo.it> ``` Sergio Callegari wrote: >> If you want to be able to distribute it (or synchronize it between your >> laptop and PC _with git!_), you can rewrite the history by either >> git-rebase, or by using cg-admin-rewritehist if you are using cogito. >> >>   > I have tried using git-rebase (I do not have cg, at least not yet). > However I am encountering some problems... > > Everything is fine with the master branch of my continuation archive doing > > git rebase fixed-master master > > (where fixed-master is the master head of the recovered archive) > This does the trick nicely. I.e. I start with > > A---B---C---D    E---F---G---H---I > > > where D is fixed-master and I is master, and I end up with > > A---B---C---D---E'---F'---G'---H'---I' > > plus the older tree E---...---I > > However I am then in trouble with the other branches of the continuation > archive, which I simply cannot get right... > In fact, E...I has actually a branch, say at G, like in > > E---F---G---H---I >          \ >           --M---N > > > And I cannot make an M'---N' based at G'... the best that I am > succeeding in is building an > > E''--F''--G''--M'--N' > > based on D. It is where --onto parameter of git-rebase is used. It means you use parameter to identify main branch in the continuation archive, parameter being the branch you want to transplant into main archive (i.e. .. being the part you want to transplant/rebase), and '--onto ' with being the new fork point. So in the abovementioned case, try git rebase --onto G' I N and tell us if it works. -- Jakub Narebski Warsaw, Poland ShadeHawk on #git ``` ## Johannes Schindelin, 2006-09-01 14:37 Subject: Re: Joining a fixed archive with its continuation Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.63.0609011634370.28360%40wbgn013.biozentrum.uni-wuerzburg.de In-Reply-To: <44F81FE5.1040509@arces.unibo.it> ``` Hi, On Fri, 1 Sep 2006, Sergio Callegari wrote: > > P.S.: Of course, if you do not insist on a super clean history, you can fake > > a merge. Just put <40-hex-chars-old> into .git/MERGE_HEAD and commit. This > > will pretend that your new head and your old head were merged, and the > > result is the new head. This _should_ even work with git-bisect, but it is > > slightly ugly. > > Before I try, can you better explain me what shall go on in this case? > The man page of commit actually does not say much about commit behavior > during a merge (i.e. with MERGE_HEAD set). A merge commit is almost the same as a regulaar commit; the only difference is that you provide multiple parents to a merge commit. The first parent is always the current head. And the other parents are in .git/MERGE_HEAD (one commit SHA1 per line). So, putting the fixed-master SHA1 into .git/MERGE_HEAD pretends that the fixed-master merged with the current master is the current master. >From a view point of correctness, this is _wrong_. _But_ it would work correctly with pull/push/bisect. Ciao, Dscho ```