Peter Eisentraut wrote:
> On 7/14/15 3:44 AM, Alvaro Herrera wrote:
> > I have been using a slightly tweaked version of this and I have found
> > that the %w(80,4,4)%B thingy results in mangled formatting;
>
> I have since refined this to
>
> ... %n%n%w(0,4,4)%s%n%+b
>
> You might find that tha
On 7/14/15 3:44 AM, Alvaro Herrera wrote:
> Peter Eisentraut wrote:
>> On 6/25/15 8:08 PM, Robert Haas wrote:
>>> Because I don't want to have to do git log --format=fuller to see when
>>> the thing was committed, basically.
>>
>> Then I suggest to you the following configuration settings:
>>
>> [f
Peter Eisentraut wrote:
> On 6/25/15 8:08 PM, Robert Haas wrote:
> > Because I don't want to have to do git log --format=fuller to see when
> > the thing was committed, basically.
>
> Then I suggest to you the following configuration settings:
>
> [format]
> pretty=cmedium
> [pretty]
>
On Fri, Jun 26, 2015 at 4:11 PM, Peter Eisentraut wrote:
> On 6/25/15 8:08 PM, Robert Haas wrote:
>> Because I don't want to have to do git log --format=fuller to see when
>> the thing was committed, basically.
>
> Then I suggest to you the following configuration settings:
>
> [format]
>
On 6/25/15 8:08 PM, Robert Haas wrote:
> Because I don't want to have to do git log --format=fuller to see when
> the thing was committed, basically.
Then I suggest to you the following configuration settings:
[format]
pretty=cmedium
[pretty]
cmedium="format:%C(auto,yellow)commit
On Wed, Jun 24, 2015 at 3:50 PM, Peter Eisentraut wrote:
> On 6/24/15 12:55 PM, Robert Haas wrote:
>>> FWIW, I have been doing that, and I have not considered it a problem.
>>> If the patch was submitted three months ago, reviewed, and then
>>> committed unchanged, the date is what it is. Also, w
On Wed, Jun 24, 2015 at 10:03:50AM -0400, Robert Haas wrote:
> On Tue, Jun 23, 2015 at 10:15 PM, Noah Misch wrote:
> >> That brings it back to the enforcing - would we want to enforce both those?
> >
> > May as well. AuthorDate is the main source of trouble. You would need to
> > go
> > out of
On 6/24/15 12:55 PM, Robert Haas wrote:
>> FWIW, I have been doing that, and I have not considered it a problem.
>> If the patch was submitted three months ago, reviewed, and then
>> committed unchanged, the date is what it is. Also, when I cherry-pick a
>> commit from master to a back branch, I k
On Wed, Jun 24, 2015 at 11:37 AM, Peter Eisentraut wrote:
> On 6/12/15 9:31 AM, Robert Haas wrote:
>> Could we update our git hook to refuse a push of a new commit whose
>> timestamp is more than, say, 24 hours in the past? Our commit history
>> has some timestamps in it now that are over a month
On 6/12/15 9:31 AM, Robert Haas wrote:
> Could we update our git hook to refuse a push of a new commit whose
> timestamp is more than, say, 24 hours in the past? Our commit history
> has some timestamps in it now that are over a month off, and it's
> really easy to do, because when you rebase a co
On Tue, Jun 23, 2015 at 10:15 PM, Noah Misch wrote:
>> That brings it back to the enforcing - would we want to enforce both those?
>
> May as well. AuthorDate is the main source of trouble. You would need to go
> out of your way (e.g. git filter-branch) to push an old CommitDate, but let's
> che
Noah Misch wrote:
> On Sun, Jun 14, 2015 at 12:37:00PM +0200, Magnus Hagander wrote:
> > Would we in that case want to enforce linearity *and* recent-ness, or just
> > linearity? as in, do we care about the commit time even if it doesn't
> > change the order?
>
> If a recency check is essentially
On Sun, Jun 14, 2015 at 12:37:00PM +0200, Magnus Hagander wrote:
> On Fri, Jun 12, 2015 at 4:33 PM, Tom Lane wrote:
> > Andrew Dunstan writes:
> > > On 06/12/2015 09:31 AM, Robert Haas wrote:
> > >> Could we update our git hook to refuse a push of a new commit whose
> > >> timestamp is more than,
On Fri, Jun 12, 2015 at 4:33 PM, Tom Lane wrote:
> Andrew Dunstan writes:
> > On 06/12/2015 09:31 AM, Robert Haas wrote:
> >> Could we update our git hook to refuse a push of a new commit whose
> >> timestamp is more than, say, 24 hours in the past? Our commit history
> >> has some timestamps i
Andrew Dunstan writes:
> On 06/12/2015 09:31 AM, Robert Haas wrote:
>> Could we update our git hook to refuse a push of a new commit whose
>> timestamp is more than, say, 24 hours in the past? Our commit history
>> has some timestamps in it now that are over a month off, and it's
>> really easy t
On 06/12/2015 09:31 AM, Robert Haas wrote:
Could we update our git hook to refuse a push of a new commit whose
timestamp is more than, say, 24 hours in the past? Our commit history
has some timestamps in it now that are over a month off, and it's
really easy to do, because when you rebase a com
Could we update our git hook to refuse a push of a new commit whose
timestamp is more than, say, 24 hours in the past? Our commit history
has some timestamps in it now that are over a month off, and it's
really easy to do, because when you rebase a commit, it keeps the old
timestamp. If you then
17 matches
Mail list logo
