[almighty] github merge option for almighty-core

Andrew Lee Rubinger alr at redhat.com
Thu Sep 22 12:14:37 UTC 2016


We'd discussed this on yesterday's "JBoss Asylum" podcast recording. :)

Overall I think this is about balance; often I prioritize clarity and
maintenance of the codebase through a clean commit history over a
fully-detailed commit log that chronicles the fine-grained construction of
a feature or bugfix.  I aim for these to be able to be undone atomically,
without interleaving among other issues.

But you don't want to be overzealous and remove authorship; credit has to
be given where its due -- especially in the case of a signed commit.

So I don't believe in a particular policy or one-size-fits-all approach;
generally I like to rebase and squash so that a commit or several fit
neatly atop master, then test and merge.

S,
ALR

On Thu, Sep 22, 2016 at 7:46 AM, Thomas Mäder <tmader at redhat.com> wrote:

> Frankly, I think the detailed creation history of a PR does not add a lot
> of useful information. PR's should contain consistent sets of changes
> addressing a particular to-do. We are doing Scrum with a 3 week cycle, so
> no change should be really huge.
>
> Often, the genesis of a particular PR is messy...you do some stuff, then
> realize you have to fix something over there...and you end up with a mess
> of commits that doesn't make any chronological sense.
>
> That said, if we ARE interested in a detailed history of all commits, we
> should keep the real history, not some kind of fake history made to look
> good or logical when it isn't. Chances are that we are going to get the
> history wrong if we make it up after the fact.
>
> My 0.02€
>
> /Thomas
>
> On 09/22/2016 01:08 PM, Konrad Kleine wrote:
>
> Hi Max,
>
> what KB said is correct: A squash "destroys" the history.
>
> I can only guess but the reason why we have squash at the moment is
> probably best explained when you look at master from a different angle.
>
> Suppose you merge a PR with many commits into master and due to some
> reasons it doesn't work: Then you have to revert a whole bunch of commits.
> To be precise: All the commits until the next "merge" commit.
>
> With a squash commit you have just one commit to revert in master.
>
> ... While writing this, I've changed my mind ;) ....
>
> I think a good compromise is to keep an eye on your own commits in your
> PR. If you think that some commits don't add any value, you can refine your
> commit history as long as you want to get it in "a good shape". The
> required force push only works if nobody forked from your branch of course.
>
> As a reviewer we should check that the history is in good shape before we
> approve a PR.
>
> Sound good?
>
> Regards
> Konrad
>
>
>
> On Thu, Sep 22, 2016 at 12:27 PM, Karanbir Singh <kbsingh at redhat.com>
> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Rebase to master, from the PR  would - but then a merge back to master
>> would still squash all the commits into 1 change at point of merge
>> back into master. Thats how the git repo is setup at the moment, and
>> seems wrong to me.
>>
>> If a feature is worked on for a few days, across the team, and then
>> pushed into a single PR to merge into master, we are destroying the
>> entire history of that code.
>>
>> regards,
>>
>> On 21/09/16 19:18, Max Andersen wrote:
>> > Rebase keeps history does it not ?
>> >
>> > Sent from my iPhone
>> >
>> > On 21 Sep 2016, at 18:28, Karanbir Singh <kbsingh at redhat.com
>> > <mailto:kbsingh at redhat.com>> wrote:
>> >
>> > hi,
>> >
>> > I just noticed that the only merge option for almighty-core is now
>> > squash-and-merge, ie. we cant retain commit history for the PR's.
>> > Is this by design ?
>> >
>>
>> - --
>> Karanbir Singh, Project Lead, The CentOS Project, London, UK
>> Red Hat Ext. 8274455 | DID: 0044 207 009 4455
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v2.0.22 (GNU/Linux)
>>
>> iQEcBAEBAgAGBQJX47H4AAoJEI3Oi2Mx7xbtF6oIAKxV1r7aPkBDySUQVqj+5khd
>> 3i+psJ5SCXqLJFEC827K+VMEV37pveWtNghRv5MgUKSCGYGX9KPkIiasLkW4RNdK
>> IHtoyp5UvxcvuDGh63doSf0m6vGNitBlvtJ9oG9t3DIS+bFrAugJ9LKl69cRyQuC
>> wlPv0Kq+goEkZK/CuvPhpM7PWkdLgpKQiJXPreVDohWeZfF6aECA87Mf9elQuDta
>> Qt77+Z3Jj3mjLD1lSDXqrAD58n6HbZQwkKm12UUkJpULQA/AO64A1sN1XdYTVxx5
>> Ka15IQdpY4fbQX2rO/qNvcpkQkiIvX7cRSxOLpYmGHxTREPWM8O2kPTcrEmnPsE=
>> =/x5C
>> -----END PGP SIGNATURE-----
>>
>> _______________________________________________
>> almighty-public mailing list
>> almighty-public at redhat.com
>> https://www.redhat.com/mailman/listinfo/almighty-public
>>
>
>
>
> _______________________________________________
> almighty-public mailing listalmighty-public at redhat.comhttps://www.redhat.com/mailman/listinfo/almighty-public
>
>
>
> _______________________________________________
> almighty-public mailing list
> almighty-public at redhat.com
> https://www.redhat.com/mailman/listinfo/almighty-public
>
>


-- 
Red Hat Developer Programs Architecture
@ALRubinger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/almighty-public/attachments/20160922/5e171b87/attachment.htm>


More information about the almighty-public mailing list