develooper Front page | perl.perl5.porters | Postings from July 2019

Re: Transition from RT to GitHub [FAQ]

Thread Previous | Thread Next
From:
Dan Book
Date:
July 12, 2019 15:08
Subject:
Re: Transition from RT to GitHub [FAQ]
Message ID:
CABMkAVXQp01byVak69iKMr7c0AZ47MOSD14iV=HY2frZxzjCHQ@mail.gmail.com
On Fri, Jul 12, 2019 at 10:52 AM Craig A. Berry <craig.a.berry@gmail.com>
wrote:

> On Thu, Jul 11, 2019 at 6:00 AM Nicholas Clark <nick@ccl4.org> wrote:
> >
> > On Tue, Jul 09, 2019 at 01:45:28AM +0300, Sawyer X wrote:
>
> > > Q: Will this change how we use Git?
> > >
> > > A: There are no plans to do so. We’re just moving the “canonical” git
> > > repository.
> >
> > Please can we take care to stick to "no plans to do so".
> >
> > Specifically in another mail Hugo noted one of my main concerns -
> > historically github has made it easy with pull requests to make a history
> > graph that is complete spaghetti (although unlike spaghetti code, this
> will
> > of course always be acyclic (oh, prove me wrong with an SHA-1
> collision)).
> >
> > git bisect is a very valuable tool - please can we continue to rebase
> > (where possible) before merging in patches and changes.
> >
> > (even if the merge isn't a fast-forward, the trivial merge commit isn't
> > going to mess up bisectability)
>
> +1.  I really loathe the most common GitHub workflow where the commit
> history consists almost entirely of "Merge pull request #1234 from
> somebody/somebranch/about...<cut off>" which is devoid of relevant
> content


As I mentioned previously, the rebase option for merging PRs is available.


> and I believe these merges also show up as affecting every
> file in the repository, making it difficult to track history affecting
> a specific file.


This is inaccurate.

-Dan

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About