From: Petr Baudis <pasky@suse.cz>
To: Matthieu Moy <Matthieu.Moy@imag.fr>
Cc: David Jeske <jeske@willowmail.com>, git@vger.kernel.org
Subject: Re: is rebase the same as merging every commit?
Date: Fri, 27 Jun 2008 10:34:19 +0200 [thread overview]
Message-ID: <20080627083419.GD12567@machine.or.cz> (raw)
In-Reply-To: <vpqfxqz5qzj.fsf@bauges.imag.fr>
On Fri, Jun 27, 2008 at 08:30:56AM +0200, Matthieu Moy wrote:
> "David Jeske" <jeske@willowmail.com> writes:
>
> > Rebasing is described in the docs I've read as turning this: (sorry for the
> > dots)
> >
> > ..........A---B---C topic
> > ........./
> > ....D---E---F---G master
> >
> > Into this:
> >
> > ...................A'--B'--C' topic
> > ................../
> > .....D---E---F---G master
> >
> > If I understand it right (and that's a BIG if), it's the same as doing a merge
> > of C into G where every individual commit in the C-line is individually
> > committed into the new C' line.
> >
> > ...........-------------A---B---C
> > ........../ / / /
> > ........./ /---A'--B'--C' topic
> > ......../ /
> > ....D---E---F---G - master
>
> I'd draw that the other way:
>
> ...........---------A---B---C
> ........../ \ \ \
> ........./ /---A'--B'--C' topic
> ......../ /
> ....D---E---F---G - master
>
> > (1) Is the above model a valid explanation?
>
> Sounds correct to me.
I don't think you can call it correct since it assumes !(2) while (2)
holds. Drawing the diagram this way is misleading; merging commits
one-by-one implies preserving the merge information in the history
graph; nothing like that is done by rebase.
Rebase is more like _cherry-picking_ all the patches on your branch on
top of the upstream branch. You just essentially take each patch (commit
message + diff to parent) growing on top of upstream's E and recommit it
on top of G.
> > (2) From the documentation diagrams, it looks like the rebased A' has only (G)
> > as a parent, not (A,G). If this is the case, why?
..snip..
> > (i.e. not connecting those nodes throws away useful information)
>
> For the use-cases where this information is useful, "rebase" is not
> for you. Indeed, in these cases, a plain "merge" is usually what you
> want.
Indeed, noone forces you into the rebase workflow for your own projects.
I personally never ever rebase (I do use StGIT though, but it records
per-patch history and makes sure I'm always in some consistent state).
--
Petr "Pasky" Baudis
The last good thing written in C++ was the Pachelbel Canon. -- J. Olson
next prev parent reply other threads:[~2008-06-27 8:35 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-26 23:04 is rebase the same as merging every commit? David Jeske
2008-06-27 6:30 ` Matthieu Moy
2008-06-27 6:46 ` David Jeske
2008-06-27 6:46 ` David Jeske
2008-06-27 8:34 ` Petr Baudis [this message]
-- strict thread matches above, loose matches on Subject: below --
2008-06-26 23:04 David Jeske
2008-06-27 0:51 ` Junio C Hamano
2008-06-27 1:08 ` Junio C Hamano
2008-06-27 6:24 ` David Jeske
2008-06-27 7:34 ` Matthieu Moy
2008-06-27 15:39 ` David Jeske
2008-06-27 15:39 ` David Jeske
2008-06-27 6:24 ` David Jeske
2008-06-27 6:31 ` Pascal Obry
2008-06-27 10:33 ` しらいしななこ
2008-06-27 21:51 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080627083419.GD12567@machine.or.cz \
--to=pasky@suse.cz \
--cc=Matthieu.Moy@imag.fr \
--cc=git@vger.kernel.org \
--cc=jeske@willowmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.