unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Björn Bidar" <bjorn.bidar@thaodan.de>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Ship Mints <shipmints@gmail.com>,
	 yantar92@posteo.net, emacs-devel@gnu.org
Subject: Re: On committing significant and/or controversial changes
Date: Sun, 24 Nov 2024 04:35:49 +0200	[thread overview]
Message-ID: <3972.40662002645$1732415815@news.gmane.org> (raw)
In-Reply-To: <86y11bm6oq.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 22 Nov 2024 21:04:05 +0200")

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Ship Mints <shipmints@gmail.com>
>> Date: Fri, 22 Nov 2024 12:47:22 -0500
>> Cc: Alan Mackenzie <acm@muc.de>, emacs-devel@gnu.org
>> 
>> Considering how cheap git branches are, I would add that contributors could create a branch with their
>> potentially controversial changes committed in the branch for people to better appreciate vs. users
>> speculatively applying patches in their own private branches.
>
> Branches are "cheap" to create, but are "expensive" because too many
> active branches tend to increase the probability of mistakes when
> people push changes to the wrong branch or merge from/to the wrong
> branch.

Rules on such branches should help for example for Glibc there are rules
for namespace specifically to avoid this kind of issue.[1]

These test branches exist to experiment, create commits such as fixup
commits that won't reflect the actual commits that would be merged after
the changes in said branch would be in a working state.


> Branches also make it a bit harder to track changes people install.

It depends on how they are organized. E.g. if topic branches are merged
into master which only contain extra commits related to that topic they
are easy to track. However if a topic branch contains merge commits
where they should have been rebased first before merging instead of
merging mater back then these can cause unnecessary noise in the commit
history.

> So I don't think I like this proposal for changing our procedures.

Change is hard but without change issues will potentially keep existing.
Making use of features that different systems offer can help to relieve
some of the friction and make communication of changes easier.

It would be best to take the things learned by people outside of the
personal bubble into account. Often they can show use things that we
have become blind to or would have never thought of in the first place.


[1] https://sourceware.org/glibc/wiki/GlibcGit#Branch_Name_Space_Conventions



  reply	other threads:[~2024-11-24  2:35 UTC|newest]

Thread overview: 81+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-20 15:13 My resignation from Emacs development Alan Mackenzie
2024-11-20 15:34 ` Eli Zaretskii
2024-11-20 16:23 ` Christopher Dimech
2024-11-21  6:22   ` Gerd Möllmann
2024-11-21 10:05     ` Christopher Dimech
2024-11-21 11:23       ` Gerd Möllmann
2024-11-21 11:40         ` Eli Zaretskii
2024-11-21 10:29   ` Alan Mackenzie
2024-11-21 12:26     ` Christopher Dimech
2024-11-20 16:42 ` Alfred M. Szmidt
2024-11-20 17:04 ` tomas
2024-11-20 21:56 ` Dmitry Gutov
2024-11-21  2:28 ` Stefan Kangas
2024-11-21 12:34   ` Tree-sitter maturity (was: My resignation from Emacs development) Peter Oliver
2024-11-23 13:41     ` Stefan Kangas
2024-11-24  2:10     ` Tree-sitter maturity Björn Bidar
2024-11-21 13:01   ` My resignation from Emacs development Alan Mackenzie
2024-11-21 13:48     ` Eli Zaretskii
2024-11-21 14:29       ` Alfred M. Szmidt
2024-11-22  0:01         ` Po Lu
2024-11-22  7:03           ` Eli Zaretskii
2024-11-22  8:14             ` Robert Pluim
2024-11-22  8:32               ` Eli Zaretskii
2024-11-22 23:59               ` Po Lu
2024-11-23  6:39                 ` Eli Zaretskii
2024-11-21 16:29       ` Alan Mackenzie
2024-11-22  5:35     ` Adam Porter
2024-11-22  7:24       ` Madhu
2024-11-22  8:11         ` Eli Zaretskii
2024-11-22  9:26           ` Madhu
2024-11-22 12:07             ` Eli Zaretskii
2024-11-22 12:40           ` Stefan Kangas
2024-11-22 13:06           ` Alan Mackenzie
2024-11-22 13:39             ` Stefan Kangas
2024-11-22 14:25             ` Eli Zaretskii
2024-11-25  4:28             ` Richard Stallman
2024-11-26 17:37               ` Alan Mackenzie
2024-11-23 22:18           ` Andrea Corallo
2024-11-22 10:57       ` Alan Mackenzie
2024-11-22 23:19         ` Adam Porter
2024-11-26 19:01       ` Daniel Radetsky
2024-11-26 19:51         ` Christopher Dimech
2024-11-27  2:18           ` Adam Porter
2024-11-27  9:36             ` Daniel Radetsky
2024-11-27  9:59             ` Christopher Dimech
2024-11-27  2:06         ` Adam Porter
2024-11-27  9:17           ` Daniel Radetsky
2024-11-22 15:36     ` Stefan Kangas
2024-11-22 17:48       ` Alan Mackenzie
2024-11-23 23:43     ` Stefan Monnier via Emacs development discussions.
2024-11-23  6:10   ` Richard Stallman
2024-11-23  7:48     ` Eli Zaretskii
2024-11-23 11:06       ` Christopher Dimech
2024-11-23 11:54         ` Eli Zaretskii
2024-11-23 12:48           ` Christopher Dimech
2024-11-23 23:59       ` Adam Porter
2024-11-24 18:12     ` Suhail Singh
2024-11-26  4:56       ` Richard Stallman
2024-11-26  7:38         ` Suhail Singh
2024-11-21  5:59 ` Gerd Möllmann
2024-11-22 11:36   ` Alan Mackenzie
2024-11-22 11:52     ` Eli Zaretskii
2024-11-23 10:36       ` Alan Mackenzie
2024-11-23 11:31         ` Eli Zaretskii
2024-11-21 13:39 ` Andrea Corallo
2024-11-21 19:01   ` Alfred M. Szmidt
2024-11-21 19:19     ` Christopher Dimech
2024-11-21 19:47     ` Eli Zaretskii
2024-11-21 19:40 ` Jim Porter
2024-11-24  4:35   ` Richard Stallman
2024-11-21 23:57 ` Po Lu
2024-11-22 17:26 ` On committing significant and/or controversial changes (was: My resignation from Emacs development) Ihor Radchenko
2024-11-22 17:47   ` Ship Mints
2024-11-22 19:04     ` Eli Zaretskii
2024-11-24  2:35       ` Björn Bidar [this message]
2024-11-24  4:41         ` On committing significant and/or controversial changes Adam Porter
     [not found]       ` <87ttbx73zu.fsf@>
2024-11-24  8:26         ` Eli Zaretskii
2024-11-22 19:01   ` Eli Zaretskii
2024-11-23  6:10 ` My resignation from Emacs development Richard Stallman
2024-11-23  8:50   ` Eli Zaretskii
2024-11-23  6:10 ` Richard Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='3972.40662002645$1732415815@news.gmane.org' \
    --to=bjorn.bidar@thaodan.de \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=shipmints@gmail.com \
    --cc=yantar92@posteo.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).