Hi, Cayetano Santos <csant...@inventati.org> writes:
>>ven. 08 août 2025 at 13:15, Gabriel Wicki <gabr...@erlikon.ch> wrote: > >> Hey! >> >> Maxim Cournoyer <ma...@guixotic.coop> writes: >>> My main objections are: >>> >>> 1) The global tag namespace of the repo would quickly (or at some pace) >>> become messy, as branches are merged often >>> >>> 2) Merge commits would serve that exact purpose without incurring 1), so >>> it seems we should just use that >> >> I understand and agree with you, Maxim! Tagging merges makes little to >> no sense, we should rather just use merge commits, which actually >> already happens (sometimes). For us developers this could help a bunch, >> especially when we try to figure out why problems in the code base were >> introduced. > > I’m late to the party, but I always though that merge commits of team > branches were the obvious way to go to that matter. > > And I always understood that, if Guix took the decision to keep solely a > linear history, was due to a good reason which I ignore, originating > back in time. This reason is still valid ? What has changed since ? I think the main concerns was to keep the history clean (when there are too many merge commits it's hard to follow), and there was also mention by Leo F. of problematic auto-conflict resolution in merge commits, but I'm somewhat doubtful about that (I think Git would be careful by default at least and drop to a conflict resolution session, otherwise that'd be very worrying). -- Thanks, Maxim
