Re: Rebasing stgit stacks

From: Catalin Marinas <catalin.marinas@gmail.com>
Date: Jan 22, 2007, 23:12 UTC
Message-ID: <b0943d9e0701221512g377b26b9rf6eabdcdd24853ff@mail.gmail.com>
In-Reply-To: <200701202016.16333.jnareb@gmail.com>

On 20/01/07, Jakub Narebski <jnareb@gmail.com> wrote:

Show 21 quoted lines

> Well, I haven't thought this through. I was thinking about situation
> where there are no applied patches, and some commits were done without
> StGIT (pure git), i.e. we had
>
>                   ..1...2...3  <-- unapplied (deck) [ branch ]
>                  /
>     a---b---c---d   <-- HEAD [ branch ]
>
> There were some git commits (for example fetch, or cherry-pick, or ...)
>
>
>                   ..1...2...3  <-- unapplied (deck) [ branch ]
>                  /
>     a---b---c---d---e---f   <-- HEAD [ branch ]
>
> And after "stg rebase" I want to have:
>
>
>                           ..1...2...3  <-- unapplied (deck) [ branch ]
>                          /
>     a---b---c---d---e---f   <-- HEAD [ branch ]

StGIT currently doesn't care whether the base of an empty stack has changed. To get to the above graph, just use "stg push 1..3" and "stg pop 1..3".

The unapplied patches may be disconnected from the current graph and StGIT doesn't care about them until pushed (applied) on top of the stack when they become part of the linear history graph. I'm not good at ASCII graphics to show an example but, for example, as long as they are unapplied, 1 above can have b as a parent and 2 can have e as a parent (it all depends on when they were last pushed).

-- 
Catalin