[Spice-devel] ovirt-wgt - another attempt

[Yedidyah Bar David]

On Thu, Nov 19, 2015 at 5:28 PM, Christophe Fergeau <cfergeau at redhat.com> wrote:
> On Thu, Nov 19, 2015 at 05:05:10PM +0200, Yedidyah Bar David wrote:
>> On Thu, Nov 19, 2015 at 4:03 PM, Christophe Fergeau <cfergeau at redhat.com> wrote:
>> > Hey,
>> >
>> > On Thu, Nov 19, 2015 at 03:13:35PM +0200, Yedidyah Bar David wrote:
>> >> I find more comfortable this semi-pull-requests mode of operation
>> >> instead of posting patches to the list. Please notify if you prefer me
>> >> to also post, but please use git fetch as it's easier to keep commit
>> >> hashes unchanged if no real change was intended.
>> >
>> > Sending just a pull request means that:
>> > - it's not possible to easily send reviews for the individual patches to
>> >   the mailing list. Here I have a minor change I'd like to squash in the
>> >   commit adding the .spec patch, but I cannot easily check with you if
>> >   it's fine. Authorship information is also wrong on 3 other patches (my
>> >   fault), I can fix that before pushing, but cannot easily mention it in
>> >   relation with the patches.
>
> (for the record, I was wrong actually, and the change I wanted to
> suggest on the .spec file was not correct)
>
>> >
>> > - you are potentially cutting off comments from 'passer-bys' (ie someone
>> >   who is just reading the mailing list but has some insights on one
>> >   particular patch
>> >
>> > In short, an easy way to directly fetch the changes to a repository can
>> > be useful, but this cannot really replace sending the individual
>> > patches.
>>
>> Very well. I agree with you. I am just asking that while the review is
>> done on the list, the actual patches are merged from a git repo and not
>> from email. Just so that we know well what we agreed to merge, meta-data
>> is kept, etc. Thanks.
>
> Thanks for sending the individual patches!
>
> No promises that I'll always pull from the links you provide though, I
> may forget. I think the only metadata which is going to change with git
> am VS git fetch is the commit hashes because the committer/commit date
> changed. git rebase seems to cope well with this though.

Indeed. At least I never had problems with that.

> Is that going to cause concrete issues with your workflow if patches get
> applied with git am rather than fetched from your repo?

The concrete issue I already had is that gerrit refuses a push if the patch
didn't change. I handled this in the past by artificially pushing another
version of the change changing the patch and then pushing again the patch I
wanted to push. Didn't try using force, not sure about other ways.

Thanks,
-- 
Didi