Hi Maxim, Maxim Cournoyer <maxim.courno...@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
signature.asc
Description: PGP signature
