Howard Miller wrote:
> > > I created a branch in a project and did a series of commits. I now
> > > discover that I really wanted to make all those changes against a
> > > completely different branch of the same project. There shouldn't be
> > > any issues as the branch introduces entirely new files (no changes to
> > > existing code).
> > >
> > > I'm struggling to see a way to do this without loosing the history.
> > > Some Google'ing suggests 'rebase --onto' but I'm struggling to see how
> > > this works or if it is appropriate. Any pointers much appreciated :)
> > > Thanks.
> >
> > This is decidely work for git rebase:
> >
> > $ git rebase --onto <where it should be based> <where it is based> <branch>
>
> Thanks.... I've re-read the rebase help and spotted the appropriate
> example. This makes sense.
>
> The only thing that I'm a little bit unsure of is what does 'upstream'
> actually mean (used in the help quite liberally)? Does it just mean an
> older ancestor of the current HEAD? I was struggling to find a definition.
gitglossary(7) has the following definition:
upstream branch::
The default branch that is merged into the branch in question
(or the branch in question is rebased onto). It is configured
via `branch.<name>.remote` and `branch.<name>.merge`. If the
upstream branch of 'A' is 'origin/B' sometimes we say
"'A' is tracking 'origin/B'"
But in the case of rebase "upstream" means branch you forked from (you
created branch from).
N.B. if the branch in question is not too old, you can examine its
reflog ('git log -g <branch>' or 'git reflog show <branch>') for a creation
event, e.g.:
2de58b3 gitweb/doc@{24}: branch: Created from origin
--
Jakub Narebski
Poland
--
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