Re: [PLUG] Git: net time gain or loss?

[Rich Freeman <r-plug@thefreemanclan.net>]

On Sat, Dec 22, 2018 at 1:50 AM Fred Stluka <fred@bristle.com> wrote:
>
> Hmmm...  OK.  I've never gotten in the habit of rebasing.  The parallel
> branches of the merge commits have always made perfect sense to
> me.  Seems to fit the reality of what happened better.  The rebased
> history DOES seem to me like re-writing history.  I remember now
> that someone on a project a few years back was encouraging rebases.
> But he was solving a problem that I felt we didn't have, so I could
> never understand why we would bother.

I think the appropriate approach depends on workflow.

Keep in mind that Gentoo is not a release-based distro.  If you look
at that history you see a series of commits to mostly-unrelated
packages.  Most of those commits are probably one-line changes to
isolated files.  If developer A stabilizes a new version of xeyes and
developer B adds a new testing version of less a minute later there is
no real relationship between those commits that needs to be preserved.
Plus, we already have a ton of commits and since they all go to master
merge commits basically double the count.

However, release-based workflows are far more common and in these
cases branching makes more sense.  You could be working on a new
feature and integrating it into a main development branch.  You could
be integrating a development branch into a new stable release.  You
could be backporting some fixes into a previous stable release.  In
all of these cases it is much better to start a branch, add commits,
test/integrate, and then merge that entire branch.  A merge commit
would preserve the history as it actually happened.

There is no one right workflow with git - there are pros and cons, and
you need to pick the workflow in git that fits the appropriate
development methodology.  If you work mainly in a release-based world
then it wouldn't surprise me that you haven't had much exposure to
rebasing, and you certainly wouldn't want to use it.  I'd also say
that using merge commits when you could have used rebasing will
probably cause fewer problems than using rebased commits when you
should have been using merge commits.

-- 
Rich
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug