On 6 September 2016 at 10:21, Marc Dequènes (Duck) <duck@redhat.com> wrote:

So cleanup done. In fact the commit hook added them when doing the git am :-/.

So, when working on a topic branch, people usually intend to work on the same feature, so to stakup improvements and fixes on the same "patchset". I fail to see how to do that with git review and the current commit hook, as it does not seem to care about handling a branch as a series of patches in the same patchset. Are we supposed to handle the Change-ID manually?

Please help on this matter, the conflicting docs on Internet did not really help.

In Gerrit every commit becomes a patch, there is no way to put multiple commits in the same patch (this is probably the most notable difference between Gerrit and pull-request based systems). The idea in Gerrit is that once you are done developing, you squash your commits together to generate patches that will be easy for reviewers to understand. -- Barak Korren bkorren@redhat.com RHEV-CI Team

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qrvTdkFVqxoDSTTIlIQ1bDuqXsrN3nHBo Content-Type: multipart/mixed; boundary="OPPV6aM0cSSt5RXQEfdPITKMrR70Sp0Wg" From: =?UTF-8?B?TWFyYyBEZXF1w6huZXMgKER1Y2sp?= <duck@redhat.com> To: infra@ovirt.org Message-ID: <d0068dde-3d37-f85e-f9b9-fddfbfeeaca8@redhat.com> Subject: Re: [JIRA] (OVIRT-696) create an 'infra-ansible' repo References: <JIRA.18604.1471435113000@Atlassian.JIRA> <JIRA.18604.1471435113707@ovirt-jira.atlassian.net> <JIRA.18604.1471435113000.26.1471435200131@Atlassian.JIRA> <1cdb68d9-ad05-a192-0f7a-5a418e37bfca@redhat.com> <b39c9ab0-91f2-6726-eece-543a26efec26@redhat.com> <CAGJrMmqCA=ok+GC8Z0h79PmDoUWBH0xpW5fOLay2xe2=TndFsw@mail.gmail.com> <798d9530-ad0d-797f-8a36-7c2a1b5a86d5@redhat.com> In-Reply-To: <798d9530-ad0d-797f-8a36-7c2a1b5a86d5@redhat.com> --OPPV6aM0cSSt5RXQEfdPITKMrR70Sp0Wg Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 09/06/2016 09:15 PM, Marc Dequ=E8nes (Duck) wrote:

That is not very practical in this case. I'd like to preserve the work history, as said in the meeting.

I mean in most cases squashing is perfectly fine, unless it is very big, so I agree with this method. I'm just looking for a way to get the previous work history, so this is a one-shot situation. As the previous way of pushing changes was different, there is no other way to also push the logic motivating the changes. After, reviews would take over. --OPPV6aM0cSSt5RXQEfdPITKMrR70Sp0Wg-- --qrvTdkFVqxoDSTTIlIQ1bDuqXsrN3nHBo Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJXzrTcAAoJEFXp+fesHEQ/pUcQAM41iVhi5ogG6bvDnZqlfGVP iEX4A8XEC35ezSWQXDwo5spLRQumRjQVPeei/4vlliNSiky7/srF0eK3BmYrIwVd OB14gNkzlRmJZ0DZBYJtoglGHKtMz5n3/cQ68ewavYMGU5WeS9hUdFRfiSv4tdvh pUN+RRZBn9IK0TtOvqTj6iGcpqlBIn58eq8CbKuo/4B/ay7FhbJNEQAWdu5M/Vai rwR5nU9cRoMRZplFOzCyxwXsD7HOrpK13q6HB3t2IVlAWpkgen2lBkEKGV+jDpHZ FFiH/7MfWZjq27cqsWU2dOrVcVXhZHtWR0/A50+2Yz35+ZsjPIszBq0V4UQ/Iioj BwQw5sLGtyykH6Tk8QAoxEbfn8H7cKr5ssnGUdPkwGtL+68dxgWp7bLatJI3+UMT tIkiTqZFHqIk+9C/4hMGzhXROg0QLkqoRLloNiAZ2DzDAlEPJ54yuL98UlVtYfRc HSh5vXe4ppIF4BWPgv+ow0vPj/+fIVteRA/1A5kZ81d+oFWy9L1aUMf+KWrD48/q DYGv0wXMTZwQOFS2Px1KCPlAcy2QmW0SruxjSFQyv/db6cwSemy1scq5Xx0M2gPm R8crbnNGOUskk200KFI8+fWQWQkShQl8zxhaUC8S45ZBKEZnx0a4vwuki36xztU2 Pf5iQgWFyHwgtObchd+/ =jgsT -----END PGP SIGNATURE----- --qrvTdkFVqxoDSTTIlIQ1bDuqXsrN3nHBo--

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --btdKXJCU5DOrmGrkEUmwTKnIjl4rtQR5Q Content-Type: multipart/mixed; boundary="9tPRhpbiexEshuhgQXhwT4OgJJ6UDi7nS" From: =?UTF-8?B?TWFyYyBEZXF1w6huZXMgKER1Y2sp?= <duck@redhat.com> To: Barak Korren <bkorren@redhat.com> Cc: infra <infra@ovirt.org> Message-ID: <2b6c9b48-59dc-444e-18a8-cfec21c41666@redhat.com> Subject: Re: [JIRA] (OVIRT-696) create an 'infra-ansible' repo References: <JIRA.18604.1471435113000@Atlassian.JIRA> <JIRA.18604.1471435113707@ovirt-jira.atlassian.net> <JIRA.18604.1471435113000.26.1471435200131@Atlassian.JIRA> <1cdb68d9-ad05-a192-0f7a-5a418e37bfca@redhat.com> <b39c9ab0-91f2-6726-eece-543a26efec26@redhat.com> <CAGJrMmqCA=ok+GC8Z0h79PmDoUWBH0xpW5fOLay2xe2=TndFsw@mail.gmail.com> <798d9530-ad0d-797f-8a36-7c2a1b5a86d5@redhat.com> <d0068dde-3d37-f85e-f9b9-fddfbfeeaca8@redhat.com> <CAGJrMmpbbOs+bpsi1kSztesMqOgXHGMNbp6emaWNZ2tn81DizA@mail.gmail.com> In-Reply-To: <CAGJrMmpbbOs+bpsi1kSztesMqOgXHGMNbp6emaWNZ2tn81DizA@mail.gmail.com> --9tPRhpbiexEshuhgQXhwT4OgJJ6UDi7nS Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 09/06/2016 10:10 PM, Barak Korren wrote:

I find that typically work history can be lease then ideal for presenting work to other developers. For me I typically find that I can narrow down commits by a factor of 3-5 when going from actual work history to a commit series that describes gradual accumulation of major features.

In ideal way I would have done topic branches from the start. Already moving out the Vagrant work was a pain in the ass, so it would mean hours or rebasing to aggregate fixes, which I'm clearly not willing to do= =2E So I agree on presenting the history, except in this case (without gerrit) all the discussions about why something was setup one way and then changed is not in reviews and associated comments. So if I squash commits, messages explaining the reasons are lost.

Please not that I did not mean that you should squash all commits to a single big one, just narrow them down and reorder to make it easier for us to understand your major themes and ideas.

That would probably be nice, but I'm not gonna redo all my work again, with things months behind I do not recall perfectly. So unless a decent proposition is done, well, we're stuck. With the current limitations of Gerrit (acknowledging your other reply) I see only two possibilities, none of them satisfying: - reviewing (well, accepting in fact) all the commits one by one. this is boring but history is preserved - cleaning all reviews I sent by mistake, and have just 2 commits: base layout with MM3 full, and Vagrant work I would have preferred my work being used as it is as the base repository of gerrit, or even better that this gerrit repository was created from the start (but with noone to really be able to review except myself). Now this is the hard way. --9tPRhpbiexEshuhgQXhwT4OgJJ6UDi7nS-- --btdKXJCU5DOrmGrkEUmwTKnIjl4rtQR5Q Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJXzsYwAAoJEFXp+fesHEQ/SHkQAMCh8jHX0lDvDAxecQ/kTG9S R3aJKMMBDi/usl56RN6t7hMf3RR4a4s8v0J1zvw2tqkN7t6QZ4fxbu483gWRVN+c vHIVlHjZ2sZ/UH/T6gJEgUidy5itwZqJp1KiMGiiHKOKBiTmFjMwCd6PGB8AMWM1 a/mtPacAxeRb+TLnRctKFdtrVRiu2rVjxLJRTsLrfFp6E67STcaP+kirkPldg7mI UZcb5/0nNEseL5bg4SRy6mkFiGuwkR2YoyxzapPcJbD8AeJ8IYlWjvdLXqKOokY7 8hnltobk3W3wUKozS6Uv3eUr820gyTgKRE0nubFit1ZOcy0nMYCRQ0oF3rzIkqqu nZsU/X8MegJtRveQPI8ljsqsi0gDwCvgnGQaA/sikCAPZKJvB4XgRZKfS9aM8pVB MIEEXw6JbFyCTTSS3AfVo2qblr+vHpkgO8/6QTncRy+Kdhuo9ZJlwt9nswWfCMV7 0F79rWPEPWZS0U5qE17j2lApthY67s2guWM29K62vj8d0KrvF0fP4JnROI7LS/SM SbqmYNTcxkIfIBajM6U6pI7w8QuoSj818E5EKAId0iQTGHgyElgjMdLeWglylfGd JI9VUv7EBeOVVRuhLPBMRyDfWNsRksZCayvNwTAMMA0UxWDyFmjI0cS4kNdDHyiR ZIXM9iwFIGXjBJZo7vbP =OHvw -----END PGP SIGNATURE----- --btdKXJCU5DOrmGrkEUmwTKnIjl4rtQR5Q--

I'm not really sure to understand what would happen if I push to review several commit with the same Change-Id; would it create a patchset or replace the former commits?

Patch sets within the same change ID replace each other with the most recent one is the one being reviewed and potentially merged.

Also, even if I would probably not send as big changes as now again, I see kernel devs sending features is a series of patches for more readability, so Gerrit is unable to do that?

It is. You just give each commit a different change id and push it as a different patch. Gerrit knows how to track dependencies between patches and present then in the UI. git-review helps here - Given branch 'foo' with N commits on top of 'maser', checking out on 'foo' and running 'git review' would create a gerrit patch and a change-id for each commit and would send them to Gerrit while also setting the topic in gerrit to 'foo' to allow looking at the patches as a group. Please note that each commit is reviewed separately, a change requested by a reviewer for an earlier commit may necessitate adaptations for later patches. When submitting sets of patches one must be ready to perform the occasional 'rebase -i'... -- Barak Korren bkorren@redhat.com RHEV-CI Team