Re: Patch committers - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Patch committers
Date
Msg-id 603c8f070911160629y11b807f2x4e2eb790e9b20bdd@mail.gmail.com
Whole thread Raw
In response to Re: Patch committers  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
On Mon, Nov 16, 2009 at 4:30 AM, Magnus Hagander <magnus@hagander.net> wrote:
> On Mon, Nov 16, 2009 at 10:20, Heikki Linnakangas
> <heikki.linnakangas@enterprisedb.com> wrote:
>> Magnus Hagander wrote:
>>> On Mon, Nov 16, 2009 at 02:08, Bruce Momjian <bruce@momjian.us> wrote:
>>>> Magnus Hagander wrote:
>>>>> On Sat, Nov 14, 2009 at 13:35, Robert Haas <robertmhaas@gmail.com> wrote:
>>>>>> On Sat, Nov 14, 2009 at 4:11 AM, Magnus Hagander <magnus@hagander.net> wrote:
>>>>>>> How about we add specific feature(s) about tihs to the commitfest
>>>>>>> management tool? Like the possibility to directly link a git
>>>>>>> repo/branch with the patch?
>>>>>> So two fields, one for the repo URL and one for the branch name?
>>>>> Yeah, I think that's it. It might actually be interesting to pull the
>>>>> latest version date and make a note in the cf management stuff
>>>>> automagically in case there the git repo has a more updated version
>>>>> than the one that was submitted. I think that could be quite useful -
>>>>> shouldn't be too hard to do, I think. Probably just a cron job that
>>>>> updates a third col in the db?
>>>> Can you get git to dynamically generate a tree diff via a URL?  That
>>>> would be nice.  Extra points for a context diff.  ;-)
>>>
>>> yes, easily. Just pass it the commit id. And unlike cvs, there is one
>>> diff for the patch, not one for every file ;)
>>> For example:
>>> http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=d3359020ef7e0fba02ac552d88ede0c3ce5128cc
>>>
>>> turning it into context-diff style will require patching gitweb
>>> though, it doesn't do that by default.
>>
>> Any idea how the get the equivalent of "git diff <branch A> <branch B>"
>> through the web interface?
>
> I don't think you can - but it's probably not a huge thing to implement it.

I think git log <branch A>...<branch B> would also be really useful.
If you update your patches by merging rather than rebasing, the
existing gitweb view is nearly useless.  I'm astonished this hasn't
bothered any of the kernel developers enough for them to fix it.  But
then maybe they use the same workaround I do: the command-line.

...Robert


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: patch - per-tablespace random_page_cost/seq_page_cost
Next
From: Andrew Chernow
Date:
Subject: Re: Listen / Notify - what to do when the queue is full