On Thu, 3 Oct 2013 03:56:03 -0700 (PDT)
ruud <r.grosm...@gmail.com> wrote:

> > I think yes, this is the only way because you need to squash A-C
> > into a new commit, C', and then reapply E-G on top of it, and
> > that's what `git rebase` is goot at. 
> thank you for your reply. I was a bit afraid this was the way to go.
> If I focus on first pushing the whole of the branch A-G to a new
> repository: when I squash A-C into commit C', it still leaves me with
> a commit isn't it? Although I need no single file in that commit. I
> can empty it, but it still leaves me with that node. 
> No possibility to make E the root node of the repository?

Sure it's possible: just squash A-E into E' not A-C into C' -- there's
really no difference, I've just failed to discern from your message
that you did not want C as well.

If you'are worried by the fact D references C as well as E, and that
squashing A-E would affect D, then fear not: parental relation between
commits is implemented "in reverse" -- children refernce their parents
while parents do not know anything about their childen, -- and
`git rebase` creates new commits not *replaces* those which were
created when rebasing so your

A-B-C-D <- foo
     \ E-F-G <- bar

(with "foo" and "bar" being refs (tags or branches) pointing to their
respective commits) after squashing A-E into E' and rebasing F-G onto E'
would look like

A-B-C-D <- foo
E'-F'-G' <- bar

That is, D will reference the same chain of commits as before while
"bar" will reference a new chain with all new commits; E' will be
synthetic and F' and G' will be mostly the same as their original
commits F and G but with their commit dates changed.

Let's recap: when `git rebase` creates new commits, old ones are left
intact and they either persist (if they're still referenced by a ref)
or become dangling and are eventually garbage-collected.  They're not
*replaced* in the sense of being modified in-place; they're replaced
only from the point-of-view of a reference which has been rebased and
now points to a new chain of commits.

Note though that there's no such thing as a "root node of a
repository": a Git repository might contain arbitrary number of branches
which share no commits (and even no other kinds objects such as trees
and blobs).  So the correct spelling would be "a root commit of the new
branch".  That's nitpicking, but I thought it won't hurt clarifying to
possibly prevent future confusion.

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to