Re: Rebasing or merging? [was: Re: 01/03: gnu: wxwidgets: Add libxtst to inputs.]

[Giovanni Biscuolo <g@xelera.eu>]

[-- Attachment #1: Type: text/plain, Size: 1676 bytes --]

Hi Maxim,

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

> As discussed previously in this thread, a good policy would be to
> suggest avoid *both* rebases and merges during a feature branch
> development.  This way we avoid both problems,

I read the whole thread and AFAIU the (only?) problem with the "merging
master to feature branch" workflow is the one pointed out by Andreas [1]:

--8<---------------cut here---------------start------------->8---

Well, we used to repeatedly merge the master branch to core-updates,
which if I remember well makes the master commits end up first in "git
log". So the core-updates specific commits gradually disappear below
thousands of master commits. So this is a problem.

--8<---------------cut here---------------end--------------->8---

So, if I don't get wrong, the only problem is with "git log" not clearly
showing the commit that are specific to the feature branch: are we sure
is there no option that can help feature branch reviewers focus on the
specific commits?

Is not "git log --no-merges master..branchname" supposed to do what we
need? Or "git log --first-parent <branch_name>"? (not tested)

> and if the branch is short lived, it should be bearable that is isn't
> synced with master for its short lifetime.

What lifetime is short lived in Guix context?  5 days, 3 weeks?

Anyway, I'm not sure that the branches designed on Guix (i.e. those
listed on https://qa.guix.gnu.org/) will be short lived, I guess some
could be long lived (months instead of weeks)

WDYT?

Ciao, Gio'


[1] id:ZIcZ9tUidrWOfgyN@jurong

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]