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:
[format]
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 that works
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 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 Fri, Jun 26, 2015 at 4:11 PM, Peter Eisentraut pete...@gmx.net 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 Wed, Jun 24, 2015 at 3:50 PM, Peter Eisentraut pete...@gmx.net 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.
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 free,
On Tue, Jun 23, 2015 at 10:15 PM, Noah Misch n...@leadboat.com 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,
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
On Wed, Jun 24, 2015 at 10:03:50AM -0400, Robert Haas wrote:
On Tue, Jun 23, 2015 at 10:15 PM, Noah Misch n...@leadboat.com 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
On Wed, Jun 24, 2015 at 11:37 AM, Peter Eisentraut pete...@gmx.net 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
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 keep the
On Sun, Jun 14, 2015 at 12:37:00PM +0200, Magnus Hagander wrote:
On Fri, Jun 12, 2015 at 4:33 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net 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
On Fri, Jun 12, 2015 at 4:33 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net 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
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
Andrew Dunstan and...@dunslane.net 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
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
