threads / discuss / 5450

Joining a fixed archive with its continuation

Subject: Joining a fixed archive with its continuation

## tl;dr

3 messages between Sep 1, 2006 and Sep 1, 2006.

replies: 2people: 3as markdown or json

Sergio Callegari· Sep 1, 2006, 11:56 UTC · lore

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.

Show 7 quoted lines

> 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.

Show 8 quoted lines

> 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· Sep 1, 2006, 14:12 UTC · re: Sergio Callegari · lore

Re: Joining a fixed archive with its continuation

Sergio Callegari wrote:

Show 39 quoted lines

>> 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 <upstream> parameter to identify main branch in the continuation archive, <branch> parameter being the branch you want to transplant into main archive (i.e. <upstream>..<branch> being the part you want to transplant/rebase), and '--onto <newbase>' with <newbase> 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· Sep 1, 2006, 14:37 UTC · re: Sergio Callegari · lore

Re: Joining a fixed archive with its continuation

Hi,

On Fri, 1 Sep 2006, Sergio Callegari wrote:

Show 9 quoted lines

> > 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