Hi, On Sun, Sep 15, 2013 at 8:32 PM, Warren Turkal <wt@xxxxxxxxxxxxxxxx> wrote: > On Tue, Sep 10, 2013 at 6:54 PM, Jehan Pagès <jehan.marmottard@xxxxxxxxx> > wrote: >> >> On Wed, Sep 11, 2013 at 1:10 PM, Michael Henning >> <drawoc@xxxxxxxxxxxxxxxxxx> wrote: >> > As a side note for the future, the fastest way to get a patch reviewed >> > is normally if you post it to a pastebin and bother people on irc. >> >> For my own, I would prefer a git format-patch like this, but on a >> feature request/bug report on bugzilla. That's easy to patch a branch >> and to remove after. And also we keep track of any discussion or >> updated patch about a feature/fix. For instance go find this email >> thread in one year in the mailing history. > > > Even for small refactorings like this one? I would certainly understand that > for a feature add or a major refactor, but it seems like a lot of overhead > for a pretty small refactor like this one. However, I am willing to do > whatever you folks want since I just wanna help the project. However, please > keep in mind that I have very little time to commit to this kind of work. Well there are no strict rules, I guess, likely because the team is small. I guess the real "rule" is to do so that others are not annoyed by the form your patch (so that they will actually check it, and not delay it to forever). Which means that if the other developers are ok with a git bundle for instance (I did not even know what it is, I had to look it up), or by adding your repo as a remote, well that's all good. :-) I am myself flexible and adapt to various team logics. But by experience, I know some others of the core GIMP team want git format-patch. When I made my first patches (I am myself likely the most recent of the core developers), I also set up a public git repo for others to fetch. Well I was told my patches would more likely be reviewed if I provided patch files instead. And now I got used to it, so I work also easily with these. That's not more time-consuming. With a patch formatted with `git format-patch`, you can just "git apply" it, and done! So easy to review (and also to commit if the patch looks good with with git am, nothing to do). I believe that at the opposite, for small patches, it is much easier to provide patch files than maintain a public repo. For huge features which require many commits over weeks, yeah there probably a public branch is worth it. :-) Jehan >> > P.S. I don't see the patch on that last email. Are you sure you attached >> > it? >> >> I see it but I was also a direct recipient. I guess that the list >> cleans emails out from any attached file. >> Could we have conditional filters? Like any text file with a ".patch" >> or ".diff" extension should not be filtered out. > > > You should also allow git bundle files, which are a way to pass around git > commits. I have attached one to this mail that includes the second iteration > of my change. I guess only direct receivers of the email will receive it. > > wt _______________________________________________ gimp-developer-list mailing list List address: gimp-developer-list@xxxxxxxxx List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
