On Tue, Jun 22, 2021 at 5:01 PM Alvaro Herrera wrote:
> I have 2.30. It works better. To be clear: some lines still appear as
> originating in some pgindent commit, when they are created by such a
> commit. But as far as I've seen, they're mostly uninteresting ones
> (whitespace, only braces, o
On 2021-Mar-18, Peter Geoghegan wrote:
> On Thu, Mar 18, 2021 at 3:12 PM Bruce Momjian wrote:
> > It would be kind of nice if the file can be generated automatically. I
> > have you checked if 'pgindent' being on the first line of the commit is
> > sufficient?
>
> I generated the file by lookin
On Tue, Jun 22, 2021 at 9:43 AM Tom Lane wrote:
> > Pushed. Thanks.
>
> Um. You probably should have waited for beta2 to be tagged.
> No harm done likely, but it's not per release process.
Sorry about that. I was aware of the policy, but somehow overlooked
that we were in the window between stam
Peter Geoghegan writes:
> On Tue, Jun 22, 2021 at 8:18 AM Tom Lane wrote:
>> OK, no objections then.
> Pushed. Thanks.
Um. You probably should have waited for beta2 to be tagged.
No harm done likely, but it's not per release process.
regards, tom lane
On Tue, Jun 22, 2021 at 8:18 AM Tom Lane wrote:
> OK, no objections then.
Pushed. Thanks.
--
Peter Geoghegan
Peter Geoghegan writes:
> On Tue, Jun 22, 2021 at 8:04 AM Tom Lane wrote:
>> Hmm, is the "git config blame.ignoreRevsFile" setting actually
>> repo-relative? I'm a bit confused as to whether an absolute
>> file path would be needed to ensure correct behavior.
> That seems to be standard practic
On Tue, Jun 22, 2021 at 8:04 AM Tom Lane wrote:
> Hmm, is the "git config blame.ignoreRevsFile" setting actually
> repo-relative? I'm a bit confused as to whether an absolute
> file path would be needed to ensure correct behavior.
That seems to be standard practice, and certainly works for me.
Peter Geoghegan writes:
> Attached is a patch file that puts it all together. I would like to
> commit this in the next couple of days.
Hmm, is the "git config blame.ignoreRevsFile" setting actually
repo-relative? I'm a bit confused as to whether an absolute
file path would be needed to ensure c
On Mon, Jun 21, 2021 at 07:43:59PM -0700, Peter Geoghegan wrote:
> On Mon, Jun 21, 2021 at 5:06 PM Tom Lane wrote:
> > Agreed. I think I'd previously suggested something under src/tools,
> > but we might as well do like others are doing; especially since
> > we have .gitattributes and the like th
On Mon, Jun 21, 2021 at 5:06 PM Tom Lane wrote:
> Agreed. I think I'd previously suggested something under src/tools,
> but we might as well do like others are doing; especially since
> we have .gitattributes and the like there already.
Great.
Attached is a patch file that puts it all together.
Peter Geoghegan writes:
> The convention seems to be that it is located in the top-level
> directory. ISTM that we should follow that convention, since following
> the convention is good, and does not in itself force anybody to ignore
> any of the listed commits. Any thoughts on that?
Agreed. I
On Mon, Jun 21, 2021 at 8:34 AM Tom Lane wrote:
> It's possible that some of these touch few enough lines that they
> are not worth listing; I did not check the commit delta sizes.
Commits that touch very few lines weren't included originally, just
because it didn't seem necessary. Even still, I'
Peter Geoghegan writes:
> What do you think of the attached? I prefer the ISO date style myself,
> so I went with that.
I grepped the git logs for "indent" and found a bunch more commits
that look like they should be included:
db6e2b4c5
d84213909
1e9c85809
f04d4ac91
9ef2dbefc
651902deb
ce5548103
On Thu, Mar 18, 2021 at 4:32 PM Peter Geoghegan wrote:
> On Thu, Mar 18, 2021 at 4:05 PM Tom Lane wrote:
> > b5d69b7c22ee4c44b8bb99cfa0466ffaf3b5fab9 # Sun Jun 7 16:57:08 2020 -0400
> > # pgindent run prior to branching v13.
> >
> > which is easy to make from "git log" or "git show" output. (Be
On Thu, Mar 18, 2021 at 5:07 PM Tom Lane wrote:
> Doubt that it matters. The workflow would have to be "commit and push
> the mechanical updates, then edit the tracking file, commit and push
> that". You don't have the commit hash nailed down till you've pushed.
Okay. I have made a personal TOD
Peter Geoghegan writes:
> On Thu, Mar 18, 2021 at 4:40 PM Tom Lane wrote:
>> Good question. We don't have a standard about that (whether to
>> do those in separate or the same commits), but we could establish one
>> if it seems helpful.
> I don't think that it matters too much, but it will nece
On Thu, Mar 18, 2021 at 4:40 PM Tom Lane wrote:
> Good question. We don't have a standard about that (whether to
> do those in separate or the same commits), but we could establish one
> if it seems helpful.
I don't think that it matters too much, but it will necessitate
updating the file multip
Peter Geoghegan writes:
> What about reformat-dat-files and perltidy runs? It seems that you
> have sometimes used all three reformatting tools to produce one commit
> -- but not always. ISTM that I should get any of those that I missed.
> And that the pgindent README (which already mentions these
On Thu, Mar 18, 2021 at 4:05 PM Tom Lane wrote:
> b5d69b7c22ee4c44b8bb99cfa0466ffaf3b5fab9 # Sun Jun 7 16:57:08 2020 -0400
> # pgindent run prior to branching v13.
>
> which is easy to make from "git log" or "git show" output. (Because
> of the precedent of those tools, I'd rather write the comm
On Thu, Mar 18, 2021 at 07:05:03PM -0400, Tom Lane wrote:
> Other points: the file should be kept in src/tools/pgindent/, and
> it should definitely NOT have a name beginning with ".".
Well, if we want github and others to eventually honor a file, it seems
.git-blame-ignore-revs at the top of the
Peter Geoghegan writes:
> On Thu, Mar 18, 2021 at 3:39 PM Tom Lane wrote:
>> I don't object to maintaining such a file; if it makes "git blame"
>> work better, that's a huge win. However, the file as you have it
>> seems rather unreadable. I'd much rather have something that includes
>> the com
On Thu, Mar 18, 2021 at 4:00 PM Bruce Momjian wrote:
> Probably because later commits might collide with shorter hashes. When
> you are reporting a hash that only looks _backward_, this is not an
> issue.
Right, but it's extremely unlikely to happen by accident. I was
suggesting that there might
On Thu, Mar 18, 2021 at 03:46:10PM -0700, Peter Geoghegan wrote:
> It's worth noting that git insists that you provide the full hash of
> commits here. This is not something I remember it insisting upon in
> any other area. There is probably a very good practical reason for
> that.
Probably becaus
On Thu, Mar 18, 2021 at 3:39 PM Tom Lane wrote:
> I don't object to maintaining such a file; if it makes "git blame"
> work better, that's a huge win. However, the file as you have it
> seems rather unreadable. I'd much rather have something that includes
> the commit date and/or first line of c
Peter Geoghegan writes:
> Attached is my .git-blame-ignore-revs file, which has pgindent commits
> that I'd like to exclude from git blame. The file is helpful on its
> own. But what we really ought to do is commit the file (perhaps with
> some revisions) and require that it be maintained by the o
On Thu, Mar 18, 2021 at 03:20:37PM -0700, Peter Geoghegan wrote:
> On Thu, Mar 18, 2021 at 3:12 PM Bruce Momjian wrote:
> > It would be kind of nice if the file can be generated automatically. I
> > have you checked if 'pgindent' being on the first line of the commit is
> > sufficient?
>
> I gen
On Thu, Mar 18, 2021 at 3:12 PM Bruce Momjian wrote:
> It would be kind of nice if the file can be generated automatically. I
> have you checked if 'pgindent' being on the first line of the commit is
> sufficient?
I generated the file by looking for commits that:
1) Mentioned "pgindent" or "PGI
On Thu, Mar 18, 2021 at 03:03:41PM -0700, Peter Geoghegan wrote:
> Attached is my .git-blame-ignore-revs file, which has pgindent commits
> that I'd like to exclude from git blame. The file is helpful on its
> own. But what we really ought to do is commit the file (perhaps with
> some revisions) an
On Thu, Mar 18, 2021 at 2:10 PM Bruce Momjian wrote:
> Actually, Tom Lane runs pgindent usually now. I do the copyright
> change, but I don't think we would ignore those since the single-line
> change is probably something we would want to blame.
The copyright change commits don't need to be con
On Thu, Mar 18, 2021 at 01:46:49PM -0700, Peter Geoghegan wrote:
> Recent versions of git are capable of maintaining a list of commits
> for "git blame" to ignore:
>
> https://www.moxio.com/blog/43/ignoring-bulk-change-commits-with-git-blame
>
> I tried this out myself, using my own list of pgind
Recent versions of git are capable of maintaining a list of commits
for "git blame" to ignore:
https://www.moxio.com/blog/43/ignoring-bulk-change-commits-with-git-blame
I tried this out myself, using my own list of pgindent commits. It
works very well -- much better than what you get when you ask
31 matches
Mail list logo
