Re: 01/03: gnu: wxwidgets: Add libxtst to inputs.

Re: 01/03: gnu: wxwidgets: Add libxtst to inputs.

[Christopher Baines]

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


guix-commits@gnu.org writes:

> apteryx pushed a commit to branch master
> in repository guix.
>
> commit ec9f15b158300da3a77ce02cd2267222f435e80f
> Author: Maxim Cournoyer <maxim.cournoyer@gmail.com>
> AuthorDate: Tue Jun 6 12:12:40 2023 -0400
>
>     gnu: wxwidgets: Add libxtst to inputs.
>
>     WxWidgets was already built with XTest support, but mostly by luck, via
>     propagation of libxtst from GTK's propagated at-spi2-core package.  Make it an
>     explicit input.
>
>     * gnu/packages/wxwidgets.scm (wxwidgets) [inputs]: Add libxtst.
> ---
>  gnu/packages/wxwidgets.scm | 1 +
>  1 file changed, 1 insertion(+)

Did this need to go straight to the master branch?

→ guix refresh -l wxwidgets
Building the following 217 packages would ensure 456 dependent packages are rebuilt: ...

That to me says this should go to staging.

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

Re: 01/03: gnu: wxwidgets: Add libxtst to inputs.

[Maxim Cournoyer]

Hi Christopher,

Christopher Baines <mail@cbaines.net> writes:

> guix-commits@gnu.org writes:
>
>> apteryx pushed a commit to branch master
>> in repository guix.
>>
>> commit ec9f15b158300da3a77ce02cd2267222f435e80f
>> Author: Maxim Cournoyer <maxim.cournoyer@gmail.com>
>> AuthorDate: Tue Jun 6 12:12:40 2023 -0400
>>
>>     gnu: wxwidgets: Add libxtst to inputs.
>>
>>     WxWidgets was already built with XTest support, but mostly by luck, via
>>     propagation of libxtst from GTK's propagated at-spi2-core package.  Make it an
>>     explicit input.
>>
>>     * gnu/packages/wxwidgets.scm (wxwidgets) [inputs]: Add libxtst.
>> ---
>>  gnu/packages/wxwidgets.scm | 1 +
>>  1 file changed, 1 insertion(+)
>
> Did this need to go straight to the master branch?
>
> → guix refresh -l wxwidgets
> Building the following 217 packages would ensure 456 dependent packages are rebuilt: ...
>
> That to me says this should go to staging.

Correct.  Except there's no staging branch anymore.  I guess we should
create one?  :-)

-- 
Thanks,
Maxim

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

[Andreas Enge]

Hello,

Am Sat, Jun 10, 2023 at 11:17:44PM -0400 schrieb Maxim Cournoyer:
> > That to me says this should go to staging.
> Correct.  Except there's no staging branch anymore.  I guess we should
> create one?  :-)

I would say it should go to a team branch; xsystem?

Regardless of name, I think the idea behind the team branch concept is
that a branch should regroup related changes (as much as possible), but
in any case there should be an identified person or group of persons taking
responsibility for shepherding the branch up to its merge; and for repairing
potential breakage. So we could extend the concept to have a
june-2023-disruptive-changes branch, with the aim of regrouping several
maybe unrelated changes leading to bigger rebuilds (and identified
responsibilities). We should not create a random branch where lots of big
changes accumulate for which nobody takes responsibility.

The changes suggested at
   https://issues.guix.gnu.org/63459
remove the staging and core-updates branches from the documentation.
Does it leave open problems behind?

One thing I wonder about is whether we should not rebase all team branches
on master instead of merging master back in. In this way, at least the
commits specific to a branch would be visible since they are on top; with
the former merging concept of staging and core-updates, they would end up
buried deep in the commit history. It could also help keeping changes
focused. What do you think?

Andreas

Re: 01/03: gnu: wxwidgets: Add libxtst to inputs.

[Christopher Baines]

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


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

> Hi Christopher,
>
> Christopher Baines <mail@cbaines.net> writes:
>
>> guix-commits@gnu.org writes:
>>
>>> apteryx pushed a commit to branch master
>>> in repository guix.
>>>
>>> commit ec9f15b158300da3a77ce02cd2267222f435e80f
>>> Author: Maxim Cournoyer <maxim.cournoyer@gmail.com>
>>> AuthorDate: Tue Jun 6 12:12:40 2023 -0400
>>>
>>>     gnu: wxwidgets: Add libxtst to inputs.
>>>
>>>     WxWidgets was already built with XTest support, but mostly by luck, via
>>>     propagation of libxtst from GTK's propagated at-spi2-core package.  Make it an
>>>     explicit input.
>>>
>>>     * gnu/packages/wxwidgets.scm (wxwidgets) [inputs]: Add libxtst.
>>> ---
>>>  gnu/packages/wxwidgets.scm | 1 +
>>>  1 file changed, 1 insertion(+)
>>
>> Did this need to go straight to the master branch?
>>
>> → guix refresh -l wxwidgets
>> Building the following 217 packages would ensure 456 dependent packages are rebuilt: ...
>>
>> That to me says this should go to staging.
>
> Correct.  Except there's no staging branch anymore.  I guess we should
> create one?  :-)

You're the second person to mention this. I guess I view the branch not
existing as a minor technical detail that doesn't really change what
you'd do.

Maybe we need to do more in the guidance to reassure people though, you
should still push to a branch if that's what you should do, even if that
branch doesn't currently exist on the remote. This situation will
probably come up more often in the case of team branches.

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

Re: 01/03: gnu: wxwidgets: Add libxtst to inputs.

[Maxim Cournoyer]

Hi,

Christopher Baines <mail@cbaines.net> writes:

> Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
>
>> Hi Christopher,
>>
>> Christopher Baines <mail@cbaines.net> writes:
>>
>>> guix-commits@gnu.org writes:
>>>
>>>> apteryx pushed a commit to branch master
>>>> in repository guix.
>>>>
>>>> commit ec9f15b158300da3a77ce02cd2267222f435e80f
>>>> Author: Maxim Cournoyer <maxim.cournoyer@gmail.com>
>>>> AuthorDate: Tue Jun 6 12:12:40 2023 -0400
>>>>
>>>>     gnu: wxwidgets: Add libxtst to inputs.
>>>>
>>>>     WxWidgets was already built with XTest support, but mostly by luck, via
>>>>     propagation of libxtst from GTK's propagated at-spi2-core package.  Make it an
>>>>     explicit input.
>>>>
>>>>     * gnu/packages/wxwidgets.scm (wxwidgets) [inputs]: Add libxtst.
>>>> ---
>>>>  gnu/packages/wxwidgets.scm | 1 +
>>>>  1 file changed, 1 insertion(+)
>>>
>>> Did this need to go straight to the master branch?
>>>
>>> → guix refresh -l wxwidgets
>>> Building the following 217 packages would ensure 456 dependent packages are rebuilt: ...
>>>
>>> That to me says this should go to staging.
>>
>> Correct.  Except there's no staging branch anymore.  I guess we should
>> create one?  :-)
>
> You're the second person to mention this. I guess I view the branch not
> existing as a minor technical detail that doesn't really change what
> you'd do.

I remember we were very happy to get rid of the staging branch last time
we managed to merge it -- I was naively hoping we'd have ironed out the
new team-based branching processes soon enough to not have to recreate
staging/core-updates anew; I guess I'm not alone :-).

Which reminds me, I need to take a look at
https://issues.guix.gnu.org/63459, which I'll try to do soon.

-- 
Thanks,
Maxim

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

[Maxim Cournoyer]

Hi Andreas,

Andreas Enge <andreas@enge.fr> writes:

> Hello,
>
> Am Sat, Jun 10, 2023 at 11:17:44PM -0400 schrieb Maxim Cournoyer:
>> > That to me says this should go to staging.
>> Correct.  Except there's no staging branch anymore.  I guess we should
>> create one?  :-)
>
> I would say it should go to a team branch; xsystem?
>
> Regardless of name, I think the idea behind the team branch concept is
> that a branch should regroup related changes (as much as possible), but
> in any case there should be an identified person or group of persons taking
> responsibility for shepherding the branch up to its merge; and for repairing
> potential breakage. So we could extend the concept to have a
> june-2023-disruptive-changes branch, with the aim of regrouping several
> maybe unrelated changes leading to bigger rebuilds (and identified
> responsibilities). We should not create a random branch where lots of big
> changes accumulate for which nobody takes responsibility.
>
> The changes suggested at
>    https://issues.guix.gnu.org/63459
> remove the staging and core-updates branches from the documentation.
> Does it leave open problems behind?
>
> One thing I wonder about is whether we should not rebase all team branches
> on master instead of merging master back in. In this way, at least the
> commits specific to a branch would be visible since they are on top; with
> the former merging concept of staging and core-updates, they would end up
> buried deep in the commit history. It could also help keeping changes
> focused. What do you think?

Rebasing only really works if a single person works on the branch, since
it rewrites history.  So it doesn't seem very team friendly.  Also,
rebasing causes the PGP-signed commits to be resigned with the key of
the people of does the rebase, which obfuscates the origin seal
somewhat.

I think we should continue to prefer merging, but minimizing this to
only when it's truly required, as Linus suggests for branches
maintainers (where it's suggested to not sync with the main branch to
avoid getting unrelated/untested changes).  If the branches are
short-lived that shouldn't be (common) problem anyway.

What do you think?

-- 
Thanks,
Maxim

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

[Felix Lechner via Development of GNU Guix and the GNU System distribution.]

Hi Maxim,

On Sun, Jun 11, 2023 at 2:26 PM Maxim Cournoyer
<maxim.cournoyer@gmail.com> wrote:
>
> rebasing causes the PGP-signed commits to be resigned with the key of
> the people of does the rebase, which obfuscates the origin seal
> somewhat.
>
> I think we should continue to prefer merging

Let's take your argument all the way for a moment, please. What if the
signed merge commits were to serve as the mutual approvals Ludo' has
been asking for?

Non-forward merges could also be used for changes involving just a
single commit, although that would create more overhead and result in
a more complicated project history.

Kind regards
Felix

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

[Maxim Cournoyer]

Hi Felix,

Felix Lechner <felix.lechner@lease-up.com> writes:

> Hi Maxim,
>
> On Sun, Jun 11, 2023 at 2:26 PM Maxim Cournoyer
> <maxim.cournoyer@gmail.com> wrote:
>>
>> rebasing causes the PGP-signed commits to be resigned with the key of
>> the people of does the rebase, which obfuscates the origin seal
>> somewhat.
>>
>> I think we should continue to prefer merging
>
> Let's take your argument all the way for a moment, please. What if the
> signed merge commits were to serve as the mutual approvals Ludo' has
> been asking for?

I'm not sure how that'd work, since Git only allows a single PGP
signature per commit, as far as I can tell.  When you rewrite the
history (by using rebase, say), the existing signatures of the rewritten
(rebased) commits are replaced with new ones generated from your key.

-- 
Thanks,
Maxim

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

[Felix Lechner via Development of GNU Guix and the GNU System distribution.]

Hi Maxim,

On Sun, Jun 11, 2023 at 5:48 PM Maxim Cournoyer
<maxim.cournoyer@gmail.com> wrote:
>
> When you rewrite the
> history (by using rebase, say), the existing signatures of the rewritten
> (rebased) commits are replaced with new ones generated from your key.

That was probably a misunderstanding. I meant to suggest with some
trepidation that 'master' is merged into the feature branch, and then
the feature branch is merged back into 'master'. I thought the two
merge commits would be signed by the person performing the merges
while the "origin seal" of the accepted change is also preserved.

Please forgive me. I merely hoped to find common ground but apparently
added confusion rather than clarity.

Kind regards
Felix

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

[Maxim Cournoyer]

Hi Felix,

Felix Lechner <felix.lechner@lease-up.com> writes:

> Hi Maxim,
>
> On Sun, Jun 11, 2023 at 5:48 PM Maxim Cournoyer
> <maxim.cournoyer@gmail.com> wrote:
>>
>> When you rewrite the
>> history (by using rebase, say), the existing signatures of the rewritten
>> (rebased) commits are replaced with new ones generated from your key.
>
> That was probably a misunderstanding. I meant to suggest with some
> trepidation that 'master' is merged into the feature branch, and then
> the feature branch is merged back into 'master'. I thought the two
> merge commits would be signed by the person performing the merges
> while the "origin seal" of the accepted change is also preserved.
>
> Please forgive me. I merely hoped to find common ground but apparently
> added confusion rather than clarity.

No worries, cheers!

-- 
Thanks,
Maxim

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

[Andreas Enge]

Hello,

Am Sun, Jun 11, 2023 at 06:10:37PM -0700 schrieb Felix Lechner:
> That was probably a misunderstanding. I meant to suggest with some
> trepidation that 'master' is merged into the feature branch, and then
> the feature branch is merged back into 'master'. I thought the two
> merge commits would be signed by the person performing the merges
> while the "origin seal" of the accepted change is also preserved.

indeed, that is what we had been doing with the very long lived staging
and core-updates branches in the past. 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.

But Maxim is right about signatures, sorry for forgetting them time and
again!

One policy would be to *not* merge master back to the feature branch
(or maybe just before merging the feature branch to master). This would
work well for short-lived branches.

Andreas

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

[Maxim Cournoyer]

Hi Andreas,

Andreas Enge <andreas@enge.fr> writes:

> Hello,
>
> Am Sun, Jun 11, 2023 at 06:10:37PM -0700 schrieb Felix Lechner:
>> That was probably a misunderstanding. I meant to suggest with some
>> trepidation that 'master' is merged into the feature branch, and then
>> the feature branch is merged back into 'master'. I thought the two
>> merge commits would be signed by the person performing the merges
>> while the "origin seal" of the accepted change is also preserved.
>
> indeed, that is what we had been doing with the very long lived staging
> and core-updates branches in the past. 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.
>
> But Maxim is right about signatures, sorry for forgetting them time and
> again!
>
> One policy would be to *not* merge master back to the feature branch
> (or maybe just before merging the feature branch to master). This would
> work well for short-lived branches.

Yes, I think we should document as policy that there should be no merge
to the feature branches unless really necessary.  This will remove a lot
of noise from the commit history and keep things in the feature branch
focused.

-- 
Thanks,
Maxim

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

[Leo Famulari]

On Sun, Jun 11, 2023 at 08:47:54PM -0400, Maxim Cournoyer wrote:
> I'm not sure how that'd work, since Git only allows a single PGP
> signature per commit, as far as I can tell.  When you rewrite the
> history (by using rebase, say), the existing signatures of the rewritten
> (rebased) commits are replaced with new ones generated from your key.

Is it so bad to re-sign commits on feature branches that we should lose
the easy-to-read history of rebased branches?

To me, it's much easier to understand and review a branch that has been
updated by rebasing rather than merging. I think that counts for a lot.
Do many people feel the same way?

Re-signing the commits is messy but I don't think there's even been a
consensus that it's very bad.

I think that re-signing commits while rebasing is consistent with our
security model which (as I understand it) considers committers' and their
machines to be trusted. And that the meaning of the signature is merely
that the committed changeset was definitively made by someone with the
key.

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

[Maxim Cournoyer]

Hi Leo,

Leo Famulari <leo@famulari.name> writes:

> On Sun, Jun 11, 2023 at 08:47:54PM -0400, Maxim Cournoyer wrote:
>> I'm not sure how that'd work, since Git only allows a single PGP
>> signature per commit, as far as I can tell.  When you rewrite the
>> history (by using rebase, say), the existing signatures of the rewritten
>> (rebased) commits are replaced with new ones generated from your key.
>
> Is it so bad to re-sign commits on feature branches that we should lose
> the easy-to-read history of rebased branches?

It's no the end of the world, but if it's avoidable, it should be, in my
opinion.  A bigger problem with rebasing is that it means a single
person can push changes to the rebased branch.  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, and if the branch is short lived, it should be bearable that
is isn't synced with master for its short lifetime.

-- 
Thanks,
Maxim

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

[Giovanni Biscuolo]

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

Hello,

please consider I am (was?) a /great/ fan of rebase, but I have to admit
that "the golden rule" [1] of rebasing makes sense: «never rebase on a
public branch.»

Leo Famulari <leo@famulari.name> writes:

> On Sun, Jun 11, 2023 at 08:47:54PM -0400, Maxim Cournoyer wrote:
>> I'm not sure how that'd work, since Git only allows a single PGP
>> signature per commit, as far as I can tell.  When you rewrite the
>> history (by using rebase, say), the existing signatures of the rewritten
>> (rebased) commits are replaced with new ones generated from your key.
>
> Is it so bad to re-sign commits on feature branches that we should lose
> the easy-to-read history of rebased branches?

IMHO this is not a problem, at all.

> To me, it's much easier to understand and review a branch that has been
> updated by rebasing rather than merging. I think that counts for a lot.
> Do many people feel the same way?

Me! ...if you mean "it's much easier to understand the history" I agree,
but all in all this is "just" a "view" problem that should be solved (if
not already solved) by a proper git log "filter"

conversely, when rebasing the review process might be (sometimes very)
problematic, this is an excerpt from
«Why you should stop using Git rebase»
https://medium.com/@fredrikmorken/why-you-should-stop-using-git-rebase-5552bee4fed1

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

Why do we use Git at all? Because it is our most important tool for
tracking down the source of bugs in our code. Git is our safety net. By
rebasing, we give this less priority, in favour of the desire to achieve
a linear history.

A while back, I had to bisect through several hundred commits to track
down a bug in our system. The faulty commit was located in the middle of
a long chain of commits that didn’t compile, due to a faulty rebase a
colleague had performed. This unneccessary and totally avoidable error
resulted in me spending nearly a day extra in tracking down the commit.

[...] Git merge. It’s a simple, one-step process, where all conflicts
are resolved in a single commit. The resulting merge commit clearly
marks the integration point between our branches, and our history
depicts what actually happened, and when it happened.

The importance of keeping your history true should not be
underestimated. By rebasing, you are lying to yourself and to your
team. You pretend that the commits were written today, when they were in
fact written yesterday, based on another commit. You’ve taken the
commits out of their original context, disguising what actually
happened. Can you be sure that the code builds? Can you be sure that the
commit messages still make sense? You may believe that you are cleaning
up and clarifying your history, but the result may very well be the
opposite.

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

Also, when I read the below mentioned article I have many doubts that
rebase should ever be used in Guix public feature branches:

«Rebase Considered Harmful»
https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md

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

2.1 A rebase is just a merge with historical references omitted

[...] So, another way of thinking about rebase is that it is a kind of merge
that intentionally forgets some details in order to not overwhelm the
weak history display mechanisms available in Git. Wouldn't it be better,
less error-prone, and easier on users to enhance the history display
mechanisms in Git so that rebasing for a clean, linear history became
unnecessary? [...]

2.2 Rebase does not actually provide better feature-branch diffs

[...] The argument from rebase advocates is that with merge it is
difficult to see only the changes associated with the feature branch
without the commingled mainline changes. In other words, diff(C2,C7)
shows changes from both the feature branch and from the mainline,
whereas in the rebase case diff(C6,C5') shows only the feature branch
changes.

But that argument is comparing apples to oranges, since the two diffs do
not have the same baseline. The correct way to see only the feature
branch changes in the merge case is not diff(C2,C7) but rather
diff(C6,C7). [...]

(n.d.r. see graphs on original page for clearness)

--8<---------------cut here---------------end--------------->8---
(IMHO the whole article deserves to be read)

[...]

WDYT?

Happy hacking! Gio'


[1] https://www.atlassian.com/git/tutorials/merging-vs-rebasing#the-golden-rule-of-rebasing


P.S.: and yes, maybe Fossil is better designed than Git, but I'm not
proposing switching to it, not at all :-)

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

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

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

[Giovanni Biscuolo]

[-- 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 --]

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

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

[Josselin Poiret]

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

Hi everyone,

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

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

I used these kinds of options for the last core-updates merge, and this
one only hides the merge commits themselves, not the merged commits.
For that, you need to use --first-parent.

Best,
-- 
Josselin Poiret

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

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

[Maxim Cournoyer]

Hi Josselin,

Josselin Poiret <dev@jpoiret.xyz> writes:

> Hi everyone,
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
>
>> 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.
>
> I used these kinds of options for the last core-updates merge, and this
> one only hides the merge commits themselves, not the merged commits.
> For that, you need to use --first-parent.

Good to know, thanks for sharing!

-- 
Thanks,
Maxim