Tom Lane wrote:
> > I maintain that if someone else whacked around one of your commits the
> > way you whacked this around, you'd bite their head off.
>
> I apologize if I offended you. I hadn't believed that there was any
> particular consensus on how this script ought to behave; I thought
> it
Dimitri Fontaine writes:
> Tom Lane writes:
>> Author: Tom Lane
>> Branch: master Release: REL8_1 [872c1497f] 2005-05-24 18:02:31 +
>> Branch: REL8_0_STABLE Release: REL8_0_4 [a94ace079] 2005-05-24 18:02:55 +
>> Branch: REL7_4_STABLE Release: REL7_4_9 [0a7b3a364] 2005-05-24 18:03:24 +000
Tom Lane writes:
> Author: Tom Lane
> Branch: master Release: REL8_1 [872c1497f] 2005-05-24 18:02:31 +
> Branch: REL8_0_STABLE Release: REL8_0_4 [a94ace079] 2005-05-24 18:02:55 +
> Branch: REL7_4_STABLE Release: REL7_4_9 [0a7b3a364] 2005-05-24 18:03:24 +
>
> Previous fix for "x FU
David Christensen writes:
> On Sep 26, 2010, at 2:24 PM, Tom Lane wrote:
>> We could perhaps fix that if there were an inexpensive way to get the
>> SHA1 of the master commit that each branch is sprouted from.
> Particularly with PostgreSQL's linear branch history, `git merge-base` will
> show y
On Sep 26, 2010, at 2:24 PM, Tom Lane wrote:
> I wrote:
>> I think we could get that behavior fairly easily by remembering the last
>> tag matching one of the commits on a branch, as we chase the branch
>> backwards.
>
> I find that this works just fine for the branches, but not so well for
> ma
On Mon, Sep 27, 2010 at 3:20 AM, Robert Haas wrote:
> On Sun, Sep 26, 2010 at 9:14 PM, Gurjeet Singh
> wrote:
> > On Mon, Sep 27, 2010 at 3:03 AM, Robert Haas
> wrote:
> >>
> >> On Sun, Sep 26, 2010 at 8:24 PM, Tom Lane wrote:
> >> >
> >>
> >> I maintain that if someone else whacked around one
On Sun, Sep 26, 2010 at 9:14 PM, Gurjeet Singh wrote:
> On Mon, Sep 27, 2010 at 3:03 AM, Robert Haas wrote:
>>
>> On Sun, Sep 26, 2010 at 8:24 PM, Tom Lane wrote:
>> >
>>
>> I maintain that if someone else whacked around one of your commits the
>> way you whacked this around, you'd bite their he
On Mon, Sep 27, 2010 at 3:03 AM, Robert Haas wrote:
> On Sun, Sep 26, 2010 at 8:24 PM, Tom Lane wrote:
> >
>
> I maintain that if someone else whacked around one of your commits the
> way you whacked this around, you'd bite their head off.
>
>
:) Yes, he would. And you are not being any less for
Robert Haas writes:
> On Sun, Sep 26, 2010 at 8:24 PM, Tom Lane wrote:
>> I looked at doing that but it didn't seem like an improvement. Take
>> a look at the new version and see what you think.
> I'm not really sure. I suppose I'll have to play with it for a while
> to really form a clear opi
On Sun, Sep 26, 2010 at 8:24 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Sep 26, 2010 at 4:38 PM, Tom Lane wrote:
>>> Hah, I have a plan. Let's just run git log for "master..RELx_y_STABLE"
>>> for each branch, rather than all the way back.
>
>> This doesn't seem more reliable to me in
Robert Haas writes:
> On Sun, Sep 26, 2010 at 4:38 PM, Tom Lane wrote:
>> Hah, I have a plan. Let's just run git log for "master..RELx_y_STABLE"
>> for each branch, rather than all the way back.
> This doesn't seem more reliable to me in any way. Looking at the
> actual commit history must sur
On Sun, Sep 26, 2010 at 4:38 PM, Tom Lane wrote:
> I wrote:
>> We could perhaps fix that if there were an inexpensive way to get the
>> SHA1 of the master commit that each branch is sprouted from. However,
>> I'm inclined to propose that we instead manually place a tag at each
>> sprout point.
>
I wrote:
> We could perhaps fix that if there were an inexpensive way to get the
> SHA1 of the master commit that each branch is sprouted from. However,
> I'm inclined to propose that we instead manually place a tag at each
> sprout point.
Hah, I have a plan. Let's just run git log for "master..
On Sun, Sep 26, 2010 at 3:24 PM, Tom Lane wrote:
> We could perhaps fix that if there were an inexpensive way to get the
> SHA1 of the master commit that each branch is sprouted from. However,
> I'm inclined to propose that we instead manually place a tag at each
> sprout point. Any thoughts ab
Robert Haas writes:
> On Sun, Sep 26, 2010 at 2:07 PM, Tom Lane wrote:
>> ? It's not hard to offer an option for that, I guess, but I foresee an
>> argument about what the default is going to be.
> If there's no clear consensus, I'm OK with the time-honored tie-break
> of "he who does the work.
I wrote:
> I think we could get that behavior fairly easily by remembering the last
> tag matching one of the commits on a branch, as we chase the branch
> backwards.
I find that this works just fine for the branches, but not so well for
master, because more often than not the initial RELx_y_z tag
On Sun, Sep 26, 2010 at 2:07 PM, Tom Lane wrote:
> [Do you really want the behavior you said you wanted?]
Yes.
> ? It's not hard to offer an option for that, I guess, but I foresee an
> argument about what the default is going to be.
If there's no clear consensus, I'm OK with the time-honored
Robert Haas writes:
> But I still want an option for the original behavior. I have been
> using it extensively and I like it.
You really think this:
Author: Tom Lane
Branch: master [872c1497f] 2005-05-24 18:02:31 +
Branch: REL9_0_STABLE [872c1497f] 2005-05-24 18:02:31 +
Branch: REL8_4_
On Sun, Sep 26, 2010 at 1:25 PM, Tom Lane wrote:
> I wrote:
>> If we could figure out how to show which major release a master-branch
>> commit antedated, and which point release a back-branch commit
>> antedated, I think we would have something that's actually significantly
>> more useful for bot
I wrote:
> If we could figure out how to show which major release a master-branch
> commit antedated, and which point release a back-branch commit
> antedated, I think we would have something that's actually significantly
> more useful for both purposes than either of these behaviors.
I think we c
Robert Haas writes:
> On Sun, Sep 26, 2010 at 12:08 PM, Tom Lane wrote:
>> Hm? As far as I can tell, this fixes that not breaks it. The problem
>> I was seeing was that commits would be attributed to a branch when in
>> fact they were made before the branch ever existed.
> But the commits are
On Sun, Sep 26, 2010 at 12:08 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Sep 26, 2010 at 1:51 AM, Tom Lane wrote:
>>> Still more tweaking of git_changelog.
>
>> Uhm, could you stop massively changing the behavior of this script
>> with no discussion at all?
>
> Uh, there was no discuss
Robert Haas writes:
> On Sun, Sep 26, 2010 at 1:51 AM, Tom Lane wrote:
>> Still more tweaking of git_changelog.
> Uhm, could you stop massively changing the behavior of this script
> with no discussion at all?
Uh, there was no discussion of the original behavior of the script
either.
> I happe
On Sun, Sep 26, 2010 at 1:51 AM, Tom Lane wrote:
> Still more tweaking of git_changelog.
>
> 1. Don't assume there's only one candidate match; check them all and use the
> one with the closest timestamp. Avoids funny output when someone makes
> several successive commits with the same log message
24 matches
Mail list logo
