Could be better, could be worse, it's workable.

So linear history then?

On Mon, Nov 7, 2022 at 3:58 PM Matthew Benedict de Detrich
<[email protected]> wrote:

> > I guess the one remaining thing that bugs me about the rebase option is
> that I think you loose the link with the PR, which you would get in the
> merge (or squash) commit otherwise.
>
> Github PR search actually works with rebased commits. i.e. if you copy the
> hash from git log you can then just search PR's with that hash. As an
> example, the latest commit hash right now for a PR merged with rebase
> is 373e87edaae027acf4869540daa8467007f89aac (which is the git log). You can
> then just go to the pull requests tab in github and place that in the
> search field and the PR will come up (make sure to remove the is:open
> query), i.e.
>
> https://github.com/apache/incubator-pekko/pulls?q=is%3Apr+373e87edaae027acf4869540daa8467007f89aac
> .
> The github website also tells you what the new commit hash for the rebase
> will be on the PR.
>
> On Mon, Nov 7, 2022 at 3:49 PM Jean-Luc Deprez <[email protected]>
> wrote:
>
> > >
> > > Not sure what the point is? That git requires signatures for
> > > authentication (like many decentralized protocols) while svn was based
> > > on client-server-based authentication?
> > >
> >
> > Indeed
> >
> > This was not related to git at all, is it? It is more about some kind
> > > of social engineering to get changes accepted (which are hard to
> > > counter for projects on the scale of Linux).
> > >
> >
> > Correct. TBH you don't need the size of the Linux kernel to be
> susceptible
> > to this.
> >
> > Precise traceability of who wrote which exact portions code isn't of any
> > > critical importance in open source projects, authorship is. You have
> > > ...
> > > whole point of the CLA/Apache Foundation, one of its main goals is to
> > > actually to protect individuals.
> > >
> >
> > I guess that's what I aimed to say with "enterprise thinking".
> >
> > If commit signing is deemed irrelevant, the importance of merge commits
> > drops indeed.
> >
> > Which reduces the "discussion" to, should merge commits still be allowed
> in
> > certain cases or should that always be a rebase no matter the size of the
> > incoming work? (aka. linear history)
> >
> > I guess the one remaining thing that bugs me about the rebase option is
> > that I think you loose the link with the PR, which you would get in the
> > merge (or squash) commit otherwise.
> >
>
>
> --
>
> Matthew de Detrich
>
> *Aiven Deutschland GmbH*
>
> Immanuelkirchstraße 26, 10405 Berlin
>
> Amtsgericht Charlottenburg, HRB 209739 B
>
> Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
>
> *m:* +491603708037
>
> *w:* aiven.io *e:* [email protected]
>

Reply via email to