On Tue, Aug 17, 2010 at 11:54, Robert Haas wrote:
> On Tue, Aug 17, 2010 at 11:46 AM, Alex Hunsaker wrote:
>> On Tue, Aug 17, 2010 at 09:21, Robert Haas wrote:
>>> On Tue, Aug 17, 2010 at 10:51 AM, Alex Hunsaker wrote:
On Tue, Aug 17, 2010 at 08:17, Robert Haas wrote:
> /me is very so
On Tue, Aug 17, 2010 at 11:46 AM, Alex Hunsaker wrote:
> On Tue, Aug 17, 2010 at 09:21, Robert Haas wrote:
>> On Tue, Aug 17, 2010 at 10:51 AM, Alex Hunsaker wrote:
>>> On Tue, Aug 17, 2010 at 08:17, Robert Haas wrote:
/me is very sorry master. Please beat your unworthy servant only
Magnus Hagander wrote:
> On Tue, Aug 17, 2010 at 4:34 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> It should get a bit faster if we reduce the number of branches it
> >> examines, which I assume is something we can do once we desupport 7.4
> >> and 8.0. ?We could also add a --since argument w
Tom Lane wrote:
> Robert Haas writes:
> > It should get a bit faster if we reduce the number of branches it
> > examines, which I assume is something we can do once we desupport 7.4
> > and 8.0. We could also add a --since argument which would doubtless
> > speed things up a lot, by truncating th
Robert Haas wrote:
> On Tue, Aug 17, 2010 at 9:55 AM, Alex Hunsaker wrote:
> > On Mon, Aug 16, 2010 at 18:48, Robert Haas wrote:
> >> OK, try this. ?It takes about 14 seconds on my machine on my copy of
> >> Magnus's test repository. ?Output looks like this:
> >
> > 14 seconds! ?That sound much t
On Tue, Aug 17, 2010 at 09:21, Robert Haas wrote:
> On Tue, Aug 17, 2010 at 10:51 AM, Alex Hunsaker wrote:
>> On Tue, Aug 17, 2010 at 08:17, Robert Haas wrote:
>>> /me is very sorry master. Please beat your unworthy servant only
>>> lightly... or alternatively, buy me a faster machine.
>>
>> W
On Tue, Aug 17, 2010 at 10:51 AM, Alex Hunsaker wrote:
> On Tue, Aug 17, 2010 at 08:17, Robert Haas wrote:
>> /me is very sorry master. Please beat your unworthy servant only
>> lightly... or alternatively, buy me a faster machine.
>
> Well, I might be able to afford a beer.
Done!
--
Robert
On Tue, Aug 17, 2010 at 08:17, Robert Haas wrote:
> On Tue, Aug 17, 2010 at 9:55 AM, Alex Hunsaker wrote:
>> On Mon, Aug 16, 2010 at 18:48, Robert Haas wrote:
>>> OK, try this. It takes about 14 seconds on my machine on my copy of
>>> Magnus's test repository. Output looks like this:
>>
>> 14
On Tue, Aug 17, 2010 at 4:34 PM, Tom Lane wrote:
> Robert Haas writes:
>> It should get a bit faster if we reduce the number of branches it
>> examines, which I assume is something we can do once we desupport 7.4
>> and 8.0. We could also add a --since argument which would doubtless
>> speed thi
Robert Haas writes:
> It should get a bit faster if we reduce the number of branches it
> examines, which I assume is something we can do once we desupport 7.4
> and 8.0. We could also add a --since argument which would doubtless
> speed things up a lot, by truncating the history to, say, the las
On Tue, Aug 17, 2010 at 4:17 PM, Robert Haas wrote:
> On Tue, Aug 17, 2010 at 9:55 AM, Alex Hunsaker wrote:
>> On Mon, Aug 16, 2010 at 18:48, Robert Haas wrote:
>>> OK, try this. It takes about 14 seconds on my machine on my copy of
>>> Magnus's test repository. Output looks like this:
>>
>> 1
On Tue, Aug 17, 2010 at 9:55 AM, Alex Hunsaker wrote:
> On Mon, Aug 16, 2010 at 18:48, Robert Haas wrote:
>> OK, try this. It takes about 14 seconds on my machine on my copy of
>> Magnus's test repository. Output looks like this:
>
> 14 seconds! That sound much too slow :-)
/me is very sorry
On Mon, Aug 16, 2010 at 18:48, Robert Haas wrote:
> OK, try this. It takes about 14 seconds on my machine on my copy of
> Magnus's test repository. Output looks like this:
14 seconds! That sound much too slow :-)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make c
Robert Haas wrote:
> > Yeah, it's a bit too slow to do on every sync. ?I run it every week or
> > two and keep the output in a text file. ?Usually what I want the history
> > for is stuff that happened awhile ago, so the fact that it's not 100% up
> > to date is seldom a factor.
>
> OK, try this.
On Mon, Aug 16, 2010 at 7:01 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Aug 16, 2010 at 4:33 PM, Tom Lane wrote:
>>> I'd be satisfied with a tool that merges commit reports if they have the
>>> same log message and occur at approximately the same time, which is the
>>> heuristic that c
Alex Hunsaker writes:
> On Mon, Aug 16, 2010 at 14:33, Tom Lane wrote:
>> I'd be satisfied with a tool that merges commit reports if they have the
>> same log message and occur at approximately the same time, which is the
>> heuristic that cvs2cl uses.
> I dont think it would be to hard to code
Robert Haas writes:
> On Mon, Aug 16, 2010 at 4:33 PM, Tom Lane wrote:
>> I'd be satisfied with a tool that merges commit reports if they have the
>> same log message and occur at approximately the same time, which is the
>> heuristic that cvs2cl uses.
> So how do you run cvs2cl? Do you run it
On Mon, Aug 16, 2010 at 14:33, Tom Lane wrote:
> Alex Hunsaker writes:
>> How exactly patches get applied into back branches?
> There was discussion about that before, but I don't know whether we
> really have a solution that will work comfortably.
I don't either, not being a -commiter I don't
On Mon, Aug 16, 2010 at 4:33 PM, Tom Lane wrote:
> I'd be satisfied with a tool that merges commit reports if they have the
> same log message and occur at approximately the same time, which is the
> heuristic that cvs2cl uses.
So how do you run cvs2cl? Do you run it once in a while and save the
Alex Hunsaker writes:
> How exactly patches get applied into back branches? Has that been
> spelled out somewhere? There are a lot of ways to do it. For
> instance git.git seems to apply the patch to the earliest branch first
> and then merge it on up so that everything can share the same
> com
On Mon, Aug 16, 2010 at 12:45, Tom Lane wrote:
> Magnus Hagander writes:
>> On Mon, Aug 16, 2010 at 20:27, Tom Lane wrote:
>>> Second, does git offer a way to collate matching log entries across
>>> multiple branches?
>
>> But what really is the usecase there?
>
> Generating back-branch update r
On Mon, Aug 16, 2010 at 20:45, Tom Lane wrote:
> Magnus Hagander writes:
>> On Mon, Aug 16, 2010 at 20:27, Tom Lane wrote:
>>> Second, does git offer a way to collate matching log entries across
>>> multiple branches?
>
>> But what really is the usecase there?
>
> Generating back-branch update r
Magnus Hagander writes:
> On Mon, Aug 16, 2010 at 20:27, Tom Lane wrote:
>> Second, does git offer a way to collate matching log entries across
>> multiple branches?
> But what really is the usecase there?
Generating back-branch update release notes, mainly. We usually do that
first for the ne
On Mon, Aug 16, 2010 at 20:27, Tom Lane wrote:
> Magnus Hagander writes:
>> On Mon, Aug 16, 2010 at 20:11, Tom Lane wrote:
>>> The other thing that I'd like to see some data on is the commit log
>>> entries. Can we produce anything comparable to cvs2cl output from
>>> the test repository?
>
>>
Magnus Hagander writes:
> On Mon, Aug 16, 2010 at 20:11, Tom Lane wrote:
>> The other thing that I'd like to see some data on is the commit log
>> entries. Can we produce anything comparable to cvs2cl output from
>> the test repository?
> For a single branch, just do "git log ", e.g. "git log
>
On Mon, Aug 16, 2010 at 20:11, Tom Lane wrote:
> Magnus Hagander writes:
>> Attached is a ZIP file with the diffs generated when converting the
>> cvs repo to git based off a cvs snapshot from this morning. It
>> contains a diff file for every branch and every tag present. (If a
>> file is missin
Magnus Hagander writes:
> Attached is a ZIP file with the diffs generated when converting the
> cvs repo to git based off a cvs snapshot from this morning. It
> contains a diff file for every branch and every tag present. (If a
> file is missing, that means there were no diffs for that branch/tag)
27 matches
Mail list logo
