Hi, Vagrant Cascadian <vagr...@debian.org> writes:
[...] >> Do you mean git trailers rather than git tags? > > No. git tags. > > For examples: > > git tag --sign team-reproduciblebuilds-12345 > > git tag --sign core-packages-567890 > > >> In any case, I'd rather not have to do that. We're trying to simplify >> things, and any manual annotation to be added to the git commit >> message is a small but added annoyance. > > Tags are independent of the git commit message entirely, and can even be > done after the fact when you know for sure it actually landed in the > master branch at a specific commit. OK. I don't like the idea of using git tags as metadata for anything but releases (including RCs). [...] > Either that or revisit a safer way to actually use "git merge" which > would just make it obvious in the merge commit, although we stopped > using "git merge" in that way for reasons: > > https://lists.gnu.org/archive/html/guix-devel/2022-01/msg00306.html I'm not sure the reason exposed there was valid. The conflict resolution mechanisms should be the same whether you use 'git merge' or 'git rebase', I don't see how using 'git merge' can be worse here. Presumably the mistake was made by a human (e.g. me) while manually resolving the conflicts, and could have happened the same in a git merge or git rebase. I like a linear history, and I think it usually makes sense to keep topic branches rebased onto master if there's a need to sync them, but for merging large branches such as python-team or gnome-team to master, I can see value in using a 'git merge' operation to record a merge commit that tells us exactly when the branch was merged and can be easily reverted easily if the branch introduced unforeseen breakages en masse, so perhaps we could revisit this. I'm not feeling strongly enough about the status quo to do that myself. It could be done by sending a patch that adjust the documentation to mention that 'git merge' is preferred for large branches (more than ~15 commits?) when merging to master, and publicising it to guix-devel to see if everyone can be made to agree to it. If you are motivated to do that, please go ahead :-). Happy to review. -- Thanks, Maxim
