On Mon, 23 Sept 2024 at 19:00, Eric Gallager via Gcc wrote:
>
> On Mon, Sep 23, 2024 at 8:09 AM Thomas Koenig via Gcc
> wrote:
> >
> > [For the fortran people: Discussion on gcc@]
> >
> > Just a general remark.
> >
> > There are people, such as myself, who regularly mess up
> > their git reposit
Thomas Koenig writes:
> [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 mana
On Mon, Sep 23, 2024 at 8:09 AM Thomas Koenig via Gcc 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
> On 23 Sep 2024, at 15:33, Jonathan Wakely wrote:
>
> On Mon, 23 Sept 2024 at 14:36, enh wrote:
>>
>> it doesn't make the patch _management_ problem better ("now i have two
>> problems"), but https://github.com/landley/toybox takes the "why not both?"
>> approach --- you can use pull reque
On Mon, 23 Sept 2024 at 16:20, Florian Weimer wrote:
>
> * Jonathan Wakely:
>
> > The discussion is about how we do patch submission and patch review.
> > The GitHub pull request workflow is widely seen as simpler than our
> > current email-based workflow (not everybody agrees, of course). The
> >
* Jonathan Wakely:
> The discussion is about how we do patch submission and patch review.
> The GitHub pull request workflow is widely seen as simpler than our
> current email-based workflow (not everybody agrees, of course). The
> idea is to *lower* the barrier of entry for contributors, not rais
On Mon, 23 Sep 2024, enh via Gcc wrote:
> it doesn't make the patch _management_ problem better ("now i have two
> problems"), but https://github.com/landley/toybox takes the "why not both?"
> approach --- you can use pull requests if you grew up with/adapted to
> git/github, or you can use the ma
On Mon, 23 Sept 2024 at 14:36, enh wrote:
>
> it doesn't make the patch _management_ problem better ("now i have two
> problems"), but https://github.com/landley/toybox takes the "why not both?"
> approach --- you can use pull requests if you grew up with/adapted to
> git/github, or you can use
it doesn't make the patch _management_ problem better ("now i have two
problems"), but https://github.com/landley/toybox takes the "why not both?"
approach --- you can use pull requests if you grew up with/adapted to
git/github, or you can use the mailing list otherwise ... taking into
account that
On Mon, 23 Sept 2024 at 13:09, Thomas Koenig via Gcc 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
I highly recommend
On Mon, Sep 23, 2024 at 8:08 AM Thomas Koenig via Gdb
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
[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
12 matches
Mail list logo
