Re: On pull request workflows for the GNU toolchain

Jonathan Wakely <[email protected]>
Newsgroups gmane.comp.lib.glibc.alpha,gmane.comp.gcc.devel,gmane.comp.gnu.binutils,gmane.comp.gdb.devel,gmane.comp.gcc.fortran
Message-ID <CAH6eHdSi3-h-y2yRh_XS9uzJBaovBVvc2JdL0kZA5Q0AFDeghw@mail.gmail.com>
On Mon, 23 Sept 2024 at 19:00, Eric Gallager via Gcc <[email protected]> wrote:
>
> On Mon, Sep 23, 2024 at 8:09 AM Thomas Koenig via Gcc <[email protected]> wrote:
> >
> > [For the fortran people: Discussion on gcc@]
> >
> > Just a general remark.
> >
> > There are people, such as myself, who regularly mess up
> > their git repositories because they have no mental model
> > of what git is doing (case in point: The Fortran unsigned
> > branch, which I managed to put into an unrepairable state
> > despite considerable help from people who tried to help me
> > fix it).
>
> As one such person who has messed up his fork of GCC, I'd just like to
> note that in my particular case at least, I messed it up because I was
> trying to apply GitHub's model for git usage, while the GCC project
> has a very different model for git usage, and the two don't exactly
> play very well with one another.

Only in the sense that the GCC project wants a linear history without
merge requests, and GitHub will happily let you create whatever mess
of merges and jumbled commits you choose to. Using pull requests won't
change that - you will need to sort your branch out before it will get
merged.


> I see switching to a pull request
> model as reducing the chances of people getting their forks into
> unusable states, rather than increasing it.

I don't think it will change it at all, you'll still be able to do
anything to your fork, it just won't get approved for merging if it's
a mess.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.