git rebase question
in [Debian]
|
From: Anand Sivaram on 15 Jun 2010 07:00 I am trying to understand the different aspects of git rebase, especially the "--onto" option. So I was going through "git help rebase". That made me consider a few other scenarios. 1. The first example is "git rebase master" or "git rebase master topic" But if we want to use "--onto" option, this would become git rebase --onto master E topic or git checkout topic git rebase --onto master E Where E is ether the commit hash of E, HEAD~3, master~3 or any other tag/branch attribute of E in case there are any. Is it correct? 2. In the same example, when we do git rebase --onto F E topic Does the output become the following? A'--B'--C' topic / D---E---F---G master 3. In the same example, suppose we do git rebase --onto master B topic The output will become C' topic / D---E---F---G master Is it like cherry picking just C git cherry-pick C Could anyone verify these answers? Thanks and Regards Anand
From: Boyd Stephen Smith Jr. on 15 Jun 2010 12:20 Hrm, this isn't actually on-topic for Debian-user. You might have better luck with the Git user's mailing list. On Tuesday 15 June 2010 05:50:45 Anand Sivaram wrote: > I am trying to understand the different aspects of git rebase, especially > the "--onto" option. So I was going through "git help rebase". > That made me consider a few other scenarios. Git's rebase in a nutshell: Switch to the <branch> argument. Determine where the current branch splits from <upstream>; call that MB. Convert MB..HEAD into a quilt / series of patches; call that Q. Reset <branch> to <newbase>, or <upstream> if --onto was not specified. Replay Q, allowing the user to manually fix up issues or abort the whole process. > 1. The first example is "git rebase master" or "git rebase master topic" > But if we want to use "--onto" option, this would become > git rebase --onto master E topic > or > git checkout topic > git rebase --onto master E > Where E is ether the commit hash of E, HEAD~3, master~3 or any other > tag/branch > attribute of E in case there are any. > Is it correct? The "<upstream>" argument to Git's rebase can be anything that Git can resolve to a commit object. That's true. (git rebase --onto master master topic) does exactly the same thing as (git rebase master topic). In this case, since E is the "branch point" / "merge base" for topic and master, (git rebase --onto master E topic) does the same thing as (git rebase master topic); as does (git rebase --onto master F topic) and (git rebase -- onto master G topic). > 2. In the same example, when we do > git rebase --onto F E topic > Does the output become the following? > A'--B'--C' topic > / > D---E---F---G master Yes. > 3. In the same example, suppose we do > git rebase --onto master B topic > The output will become > > C' topic > / > D---E---F---G master Yes. Commits A and B will still exist; they might be dangling objects, but they won't be immediately deleted. > Is it like cherry picking just C > git cherry-pick C Yes. > Could anyone verify these answers? How would you like me to do that? -- Boyd Stephen Smith Jr. ,= ,-_-. =. bss(a)iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/
From: Anand Sivaram on 16 Jun 2010 07:00 On Tue, Jun 15, 2010 at 21:46, Boyd Stephen Smith Jr. <bss(a)iguanasuicide.net > wrote: > Hrm, this isn't actually on-topic for Debian-user. You might have better > luck > with the Git user's mailing list. > > On Tuesday 15 June 2010 05:50:45 Anand Sivaram wrote: > > I am trying to understand the different aspects of git rebase, especially > > the "--onto" option. So I was going through "git help rebase". > > That made me consider a few other scenarios. > > Git's rebase in a nutshell: > > Switch to the <branch> argument. > Determine where the current branch splits from <upstream>; call that MB. > Convert MB..HEAD into a quilt / series of patches; call that Q. > Reset <branch> to <newbase>, or <upstream> if --onto was not specified. > Replay Q, allowing the user to manually fix up issues or abort the whole > process. > > > 1. The first example is "git rebase master" or "git rebase master topic" > > But if we want to use "--onto" option, this would become > > git rebase --onto master E topic > > or > > git checkout topic > > git rebase --onto master E > > Where E is ether the commit hash of E, HEAD~3, master~3 or any other > > tag/branch > > attribute of E in case there are any. > > Is it correct? > > The "<upstream>" argument to Git's rebase can be anything that Git can > resolve > to a commit object. That's true. > > (git rebase --onto master master topic) does exactly the same thing as (git > rebase master topic). > > In this case, since E is the "branch point" / "merge base" for topic and > master, (git rebase --onto master E topic) does the same thing as (git > rebase > master topic); as does (git rebase --onto master F topic) and (git rebase > -- > onto master G topic). > > > 2. In the same example, when we do > > git rebase --onto F E topic > > Does the output become the following? > > A'--B'--C' topic > > / > > D---E---F---G master > > Yes. > > > 3. In the same example, suppose we do > > git rebase --onto master B topic > > The output will become > > > > C' topic > > / > > D---E---F---G master > > Yes. > > Commits A and B will still exist; they might be dangling objects, but they > won't be immediately deleted. > > > Is it like cherry picking just C > > git cherry-pick C > > Yes. > > > Could anyone verify these answers? > > How would you like me to do that? > -- > Boyd Stephen Smith Jr. ,= ,-_-. =. > bss(a)iguanasuicide.net ((_/)o o(\_)) > ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' > http://iguanasuicide.net/ \_/ > Boyd Stephen, Thanks for the help and clarifications. Thanks and Regards Anand
|
Pages: 1 Prev: Backups - was: Re: LVM Next: new install and 1 MB between partitions |