On Thu, Nov 19, 2015 at 5:28 PM, Christophe Fergeau <cfergeau@xxxxxxxxxx> 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@xxxxxxxxxx> 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 _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel