GNU bug report logs -
#78813
feature/igc: [PATCH] Make the array face_attr_sym readonly
Previous Next
Full log
Message #44 received at 78813 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 22 Jun 2025 06:34:11 +0000
> From: Pip Cet <pipcet <at> protonmail.com>
> Cc: eller.helmut <at> gmail.com, 78813 <at> debbugs.gnu.org
>
> "Eli Zaretskii" <eliz <at> gnu.org> writes:
>
> >> Date: Sat, 21 Jun 2025 10:07:43 +0000
> >> From: Pip Cet <pipcet <at> protonmail.com>
> >> Cc: eller.helmut <at> gmail.com, 78813 <at> debbugs.gnu.org
> >>
> >> "Eli Zaretskii" <eliz <at> gnu.org> writes:
> >>
> >> >> Sorry I'm asking for clarification, but my impression was the igc branch
> >> >> was to change very little in the !HAVE_MPS case, because general GC
> >> >> cleanups such as this one make more sense on the main branch: fewer
> >> >> merge conflicts, we'll see the benefits before merging the branch (or
> >> >> even if for some reason we never do), a better git history, better test
> >> >> coverage for pre-push testing.
> >> >
> >> > That's true in general, but if some change in the non-MPS case makes
> >> > the overall code cleaner, there should be no reason not to make it on
> >> > the branch.
>
> This is what you said: a "change in the non-MPS case" (so presumably one
> not touching the MPS code) should be made "on the branch".
No, you presume wrong. I just mean changes in parts of code that are
not compiled in the MPS build. But see below.
> >> I can't parse that statement. If a change affects only the non-MPS
> >> case, which branch should we make it on? The master branch would make
> >> sense to me, and the feature/igc branch doesn't make sense.
> >
> > That's not the situation I alluded to. Your question was about more
> > general situations: you never said that you are talking about changes
> > that affect _only_ the non-MPS parts of the code. I replied with the
> > situation in mind where some change affects _both_ MPS and non-MPS
> > parts.
>
> How is it a "change in the non-MPS case" if it affects both?
A change could affect both MPS and non-MPS code, couldn't it? Why is
it so hard to understand?
> >> This single change isn't critical, of course, but feature/igc already
> >> contains too many changes which should be merged to master before we
> >> ever consider merging the branch as a whole. If the strategy is to
> >> increase that number further, that makes a sensible merge of feature/igc
> >> much less likely.
> >
> > Like I said: merge conflicts are a non-issue with modern dVCSes.
>
> That's not my experience.
We will have to agree to disagree, then.
This bug report was last modified 25 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.