Re: Rebasing stgit stacks

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 20/01/07, Jakub Narebski <jnareb@xxxxxxxxx> wrote:
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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]