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

[Maxim Cournoyer]

Hi Giovanni,

Giovanni Biscuolo <g@xelera.eu> writes:

> 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]:
>
>
> 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.
>
> 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)

I'm not a 'git log' expert myself, but intuitively like you, I'd expect
the --no-merges one to be useful to hide merge commits!  The doc seems
to confirm that:

     --no-merges
         Do not print commits with more than one parent. This is
         exactly the same as --max-parents=1.

Thanks for finding that option.

>> 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?

I'd say anything shorter than a month is (relatively) short lived, yes.

> 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)

I'm not sure too, but the idea is that when a branch is merged it should
be deleted to communicate that, and that branches should be short lived
(feature branches).  Perhaps we'll find out that we still need more
longer term integration branches that require synchronization; we'll
see!

-- 
Thanks,
Maxim