Best-Practice "Merge vs. Rebase" searched...

[Stephen Rasku]

On Tue, Oct 20, 2009 at 06:04, Alexander Schatten
<ml_alexanderschatten at gmx.at> wrote:
>
> I am working in different projects, where I favour Mercurial, but one colleage pushes GIT (so some internal nerd-discussions running, ok).
>
> Now, yesterday we had a discussion about Rebasing. I have to say, that I once read the
>  documentation on Mercurial rebase extension, but did not really understand the concept. Or to put
> it differently, I understood more or less what it does, but I did not really get *why* I would want to
> do that.
>
> Now my colleague is apparently a big rebase fan and the history in his project is pretty flat. In this
> project a lot of (students) are working in parallel, so there is a lot merging to be done, and he does
> most of it via rebasing as I understand it. One of his arguments is, that a complex branched
> history makes problems, when you want to extract certain parts of a repository into a new project
> later (but there were other arguments as well).

We use rebasing for our in-house developer team in order to keep the
history as flat as possible.  Before we were rebasing this we had a
lot of low-value merges.  They added lines to the changelog for no
real purpose.

Our in-house developers rebase their work before pushing to the
central server. This is a fairly easy process that's easy to manage.

On the other hand we have off-shore developers which use a repository
that they don't rebase.  They don't have direct access to our
repository so rebasing is basically out of the question.  They are
also 15 time zones away so supporting them if they have problems
rebasing is going to be difficult and unpleasant.

I am going to read the linked pages that others have posted but I
thought you might be interested in our experience.

...Stephen



We also have a