PSA: Bogus dates in the git log from Gerrit CLs (and how to get familiar dates).

[Trent Apted]

Take, for example, http://crrev.com/477112 .

It landed an hour ago, but the "Date" in git log is May 12 -- nearly a month ago.

Turns out this is "Author-Date".

$ git log --pretty=fuller --date=local 3b76c8f5278fd13afdfa4eef6cb24f7b7ce1a8f1

commit 3b76c8f5278fd13afdfa4eef6cb24f7b7ce1a8f1

Author:     ..

AuthorDate: Fri May 12 09:38:23 2017

Commit:     Commit Bot <commi...@chromium.org>

CommitDate: Tue Jun 6 08:54:13 2017

(aside: looking at the CL I actually have no idea where "May 12" comes from - it is git magic)

CLs from Rietveld would always use the same date, e.g.,

commit 525a0e6f0d79296a4da4f109f7a704ebbcf7f20a

Author:     ..

AuthorDate: Tue Jun 6 08:50:32 2017

Commit:     Commit Bot <commi...@chromium.org>

CommitDate: Tue Jun 6 08:50:32 2017

There is a closed Gerrit Bug - tl;dr is "WAI".

Sadly, `git log` defaults to Author-Date (i.e. --pretty=medium), which I don't think is very useful for Chromium.

If, like me, this confuses you, you can set a custom pretty format, like

git config --global pretty.mine "format:format:%C(yellow)commit %H%n%C(white)Author:     %an <%ae>%nCommitDate: %ad%n%n%w(0,4,4)%B%n"

git config --global alias.lg "log --abbrev-commit --date local --pretty=mine"

Then using `git lg` rather than `git log` gives more useful dates.

E.g., for me, I scan `git log` to see how old my upstream is and whether I should fetch. Author dates are not useful for this.

 - Trent.

[Trent Apted]

On 6 June 2017 at 10:26, Trent Apted <tap...@chromium.org> wrote:

git config --global pretty.mine "format:format:%C(yellow)commit %H%n%C(white)Author:     %an <%ae>%nCommitDate: %ad%n%n%w(0,4,4)%B%n"

git config --global alias.lg "log --abbrev-commit --date local --pretty=mine"

uh, that should be,

git config --global pretty.mine "format:format:%C(yellow)commit %H%n%C(white)Author:     %an <%ae>%nCommitDate: %cd%n%n%w(0,4,4)%B%n"

[Paweł Hajdan, Jr.]

+infra-dev,agable

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAAGrfxdk9E%2B2VGf7kJNTQuE4VUggZLxTQRSyO893sE4GHvLJzQ%40mail.gmail.com.

[Colin Blundell]

Thanks for calling this out, Trent. I had noticed this in the past day or two but hadn't really put my finger on the reason.

Apologies in advance for harping on this, as I know how hard you've been working on this transition overall, Aaron (and overall it's going great). However:

This seems like a serious regression to me. For example, when I was sheriffing yesterday I was investigating a flake that was introduced in the past few days. I initially ignored what turned out to be the culprit CL because its "Date" field was May 19, whereas the flake had started June 2.

It seems like if we stick with this behavior, the "Date" field in "git log" (and by extension the history in cs.chromium.org) becomes actively misleading from a chromium developer's perspective, and the best we could do is teach ourselves to ignore it (and suffer from a lack of information).

Am I missing something that makes this less serious than I'm outlining above?

Thanks,

Colin

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAATLsPYqy5WzF9iEKKPppZOqQofDbidQWxGeJgzygoN7Cw2tRw%40mail.gmail.com.

[Alexei Svitkine]

I share Colin's concern. Perhaps we should hold off using Gerrit until this can be fixed?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAMGE5NGprAV0dJ0QzVngX-%3Du53KfWSNXOCDvh%2B%3DsEzAA70FueQ%40mail.gmail.com.

[Colin Blundell]

Slightly more productively: I'm not suggesting that we necessarily need to go back to the behavior where Author Date and Commit Date were identical, as from the bug it sounds like that's not desired. What I'm saying is that Author Date is uninteresting (and when referenced as "Date", worse than uninteresting) from a chromium dev's perspective. Could we make it (e.g., via depot_tools) such that Commit Date is what is shown as the Date field by default when doing "git log" in a chromium checkout (and on cs.chromium.org and whatever other mainstream tooling chromium devs use)? I don't think it's sufficient to have chromium devs be able to customize their git log output to achieve that effect.

Thanks,

Colin

[Anthony Berent]

You don't need your own git command alias. You can configure whatever you choose as the git log default by doing, for example,

git config --global format.pretty "fuller"

If you don't like any of gits standard format you can also do, for example,

git config --global format.pretty "format:format:%C(yellow)commit %H%n%C(white)Author:     %an <%ae>%nCommitDate: %ad%n%n%w(0,4,4)%B%n"

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAMGE5NGQL1JurqH3m3nrU%3Dk1SvEM%2BhWBpqwsaKYtai03oTPNfA%40mail.gmail.com.

[Colin Blundell]

Thanks! I still don't think that having individual devs be able to customize their "git log" output to have the expected behavior for Date fields is sufficient though, as I outlined below.

[Dirk Pranke]

I don't think there's a way to customize a default setting per-repo, unfortunately.

-- Dirk

--
You received this message because you are subscribed to the Google Groups "infra-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to infra-dev+unsubscribe@chromium.org.
To post to this group, send email to infr...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/CAMGE5NEvEpPXDLqgMEq2VHKreW6poJR8Xk4V3QkiGSFUf9qtHQ%40mail.gmail.com.

[Aaron Gable]

Hey everyone! This thread is actually a fascinating look into the internals of how git works. I'll go over some background (some of which has been covered in other places first), and then cover why it is behaving the way it is.

* As everyone here is aware (but other folks on this list might not be, so I'll say it anyway), the Commiter Date and the Author Date are semantically different things in git. The Author Date represents when someone wrote some code; the Committer Date represents when the commit representing that code was generated -- for example, by a coworker applying your patch.

* The git command line tool updates the Committer Date every time you modify a commit object. Every time you make a new one, the new commit has the Committer Date set to "now". Every time you run "git commit --amend", the Committer Date on the old object is updated to "now" (and this is why the hash changes even if you didn't change any code).

* The git command line tool never updates the Author Date on its own. The Author Date is set the first time a commit is created with "git commit", and never updated by "git commit --amend". You can force it to update the Author Date with "git commit --amend --reset-author".

Ok, enough background on git, how does this relate to Gerrit and Chromium?

Gerrit doesn't modify your commits. Whatever commit object gets pushed from your local machine with "git cl push" is exactly the commit object which gets reviewed. And the commit object which gets landed is just a rebase of what you upload, so the Author Date remains the same as it was on the commit you uploaded.

This leads to the conclusion that, in the commit referenced in the first email in this thread, the Author Date was a month old because the commit which was pushed from ckuiper@'s local machine itself had an Author Date which was a month old. So how did that happen?

Well, git-cl tries to prevent this. If you have a local branch with many commits on it, and you use "git cl upload" to upload that branch for review, we generate a brand new commit object -- whose Committer Date and Author Date are both set to "now" -- and push that to Gerrit. We generate this new commit object so that we can push a single commit which contains all of the changes in your multiple-commit branch.

But when your branch only contains a single commit, git-cl doesn't bother taking that extra step. There's no need for it to generate a new "squashed" commit object to push when it would only be pushing a single commit anyway, so it just pushes the single commit which you have sitting on your branch. And when it does that, it pushes whatever Committer Date and Author Date are set on your local commit.

So why was the Author Date a month old? Because ckuiper@ used "git commit --amend", constantly updating a single commit object while leaving its Author Date untouched, and then uploading that single commit object to Gerrit.

If you look at some other changes (for example, this one), you can see that the Author Date was updated when I pushed the second patchset because the branch I uploaded had multiple commits on it which needed to be squashed.

At the end of the day, everything here was working correctly. Because ckuiper was using "git commit --amend" (which git assumes is explicitly intended to preserve the Author Date), all the other tools in the chain did so as well.

So the final question is: is this enough of a problem that git-cl should generate a new "squashed" commit object with updated Author Date on every upload, even uploads of just a single commit? Or should git-cl respect the author's choice to maintain their Author Date by using --amend, and push the single commit object that author is maintaing?

[Christian Biesinger]

So I don't really have an opinion on whether anything should be done
here but I feel that resetting the author date on upload does not
solve anything -- the date people seem to be interested in is when the
change lands, so gerrit's rebase is the time when we should consider
that reset.

Christian

> https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAH58R2d3fTmBGRN5wfe_9n7kpQjreb-2hsTH7ict_t6Y5e3VGA%40mail.gmail.com.

[Aaron Gable]

That is not a change we are going to make. The Author Date and Committer Date should and do represent semantically different things. As the bug linked to earlier points out, the Rietveld CQ is supposed to rewrite the Author Date to the time of last patchset upload, not the time of submission. It used to, and the fact that it doesn't anymore is a bug. The time at which the change landed is already stored in the Commit Date; we're don't plan to purposefully replace unique information with redundant information.

So the question remains -- should git-cl make an effort to reset the Author Date on every upload, even for single-commit branches; or should git-cl respect the author's intent when the author uses "git commit --amend"?

[Steve Kobes]

On Tue, Jun 6, 2017 at 1:23 PM, Aaron Gable <aga...@chromium.org> wrote:

So the question remains -- should git-cl make an effort to reset the Author Date on every upload, even for single-commit branches; or should git-cl respect the author's intent when the author uses "git commit --amend"?

I think most people who use git commit --amend don't know about these effects.  So it's not really their intent.

[Nodir Turakulov]

I think what we have now is inconsistency: whether author date of uploaded CLs is `now` or not depends on an semi-unrelated personal choice. I think we should make it consistent so it does not depend on the user personal choice. Both options seems to be possible. git-cl-upload can use --date to set author date.

I don't have a strong opinion on whether git-cl-land should always squash, or it should set --date when squashing.

--

You received this message because you are subscribed to the Google Groups "infra-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to infra-dev+unsubscribe@chromium.org.
To post to this group, send email to infr...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/CAAjAU%3DY1ywPqwiM07Y9XkjRABgM6tOCm_0QY1KpKZGNnfbDENA%40mail.gmail.com.

[Colin Blundell]

Hi Aaron,

Thanks for your informative replies!

As Christian mentioned, I think whether we special-case single-commit branches or not is a bit of a side issue here. The fundamental issue is that the date displayed in "git log", codesearch, etc. will be the date that the patch was last uploaded, which could be an arbitrary amount of time before the patch landed.

If there's no way of changing this on a community-wide level, then I'll change my git log defaults to display the commit date instead and try to keep this issue in mind when using codesearch. I still think this change is a big and unfortunate regression from a user POV (users being chromium devs), even if it's strictly speaking more correct.

Best,

Colin

[Christian Biesinger]

For what it's worth, I think codesearch/gittiles ought to show commit
date, not author date...

Christian

[Colin Blundell]

Do you mean "ought to" as in "you think they do" or as in "you think they should"?

At least codesearch currently does not AFAICT: click on the second commit from the top in the "Recent Changes" list here for an easy example.

[Christian Biesinger]

I meant: I think they should be changed so that they do :)

Christian

[Colin Blundell]

Then we'd have the issue that codesearch git history would look different than a vanilla local "git log", which is also kind of strange (but a smaller issue for sure)... I see the problem as being the same for history presented through codesearch or displayed locally.

[Daniel Cheng]

I don't think most devs care about when a patch was first created: it's generally much more useful to know when the patch landed in the tree. If that means forcing git cl to reset the author date on upload/commit so that the other tools work as expected, then we should just do that.

Daniel

--

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAMGE5NGvDJ4FKdbvDgOJUzrUXFFxGogDyzZ%2Bk7VPhjB-qd%2BE1Q%40mail.gmail.com.

[Mike Frysinger]

i'm not sure if gittiles allows per-repo customization, but this isn't a change that should be made everywhere.  as Aaron outlined, this is standard git behavior and for people who use git daily, trying to shift these defaults would break them.  like all CrOS projects.

it's also unlikely you'll get the behavior changed in Github, cgit, gitweb, and every other git web viewer out there.

so, unless you're operating in a complete silo (only ever look at Chromium projects and never any other project), this is behavior people need to get used to.

-mike

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
    http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAPTJ0XENaxC7NOEUhfmowNbXMyMWOdgD5YiUeU_aj2v4Ez-rWw%40mail.gmail.com.

[Hans Wennborg]

I think "git-cl land" should set all the dates to "now". Anything else
is super confusing.

If for some reason I'd want to know when a patch was authored, I'd
look up the codereview. When browsing history, blame, etc. locally or
in code search, I want to see when the commit landed in the tree, not
some other random date.

> --
> --
> Chromium Developers mailing list: chromi...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-dev
> ---
> You received this message because you are subscribed to the Google Groups
> "Chromium-dev" group.
> To view this discussion on the web visit

> https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAMGE5NGvDJ4FKdbvDgOJUzrUXFFxGogDyzZ%2Bk7VPhjB-qd%2BE1Q%40mail.gmail.com.

[Brett Wilson]

Right, we do not use Git as a distributed version control system. We use it like a traditional centrally managed system. This is a reason we added the commit sequence in spite of git purists' arguments to the contrary.

I don't understand why Gerrit can't just set the date to be the current time when it lands the patch in the repo like Reitveld does?

Brett

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAB8jPhfF%2BsCYzDuouY537u5J83dcN0mh3WAiyvgDRXrPWraGWw%40mail.gmail.com.

[Hans Wennborg]

Is it even Gerrit that lands the patch?

I thought the commit queue we use for Gerrit and Rietveld is the same,
and that it uses "git cl land" which pushes to some magic branch which
some other thing merges to the upstream master and adds the commit
sequence number. (I'm sad this is so complicated.) Could the thing
that adds the commit sequence number also set the date?

[Aaron Gable]

So from the feedback here, it seems clear that git-cl should always set the Author Date to "now" when it uploads a new patchset, no matter whether the user has been using "git commit --amend" locally or not. That makes total sense to me, and I'll file a change to have it do that soon.

Some people in this thread are also expressing the opinion that the time-of-last-upload is insufficient, and that the Author Date should be set to the time of submission, the same as the Commit Date. That will not happen. As Mike Frysinger said, changing the internals of Gerrit to set the Author Date when submitting a commit is a non-starter for the rest of the git-using community.

Since we control cs.chromium.org, we may be able to have it display the Commit Date instead of the Author Date. Since Gitiles is used primarily by googlesource (not other open-source gerrit installations, although some do use it), and we have a large stake in that, we may be able to change Gitiles to do the same.

[Brett Wilson]

On Tue, Jun 6, 2017 at 3:07 PM, Aaron Gable <aga...@chromium.org> wrote:

So from the feedback here, it seems clear that git-cl should always set the Author Date to "now" when it uploads a new patchset, no matter whether the user has been using "git commit --amend" locally or not. That makes total sense to me, and I'll file a change to have it do that soon.

Some people in this thread are also expressing the opinion that the time-of-last-upload is insufficient, and that the Author Date should be set to the time of submission, the same as the Commit Date. That will not happen. As Mike Frysinger said, changing the internals of Gerrit to set the Author Date when submitting a commit is a non-starter for the rest of the git-using community.

Can you go into more details? Why is this a non-starter? I understand why this is inappropriate for our project, but why not have a setting for our project?

 Brett

[Brett Wilson]

I meant inappropriate for "some" projects.

Brett

[Primiano Tucci]

My 2 cents: my personal reading of this thread is that folks here are essentially saying "the way git works by default doesn't match my expectations, I don't like this"

1) Welcome to Git, a nicely designed and architecturally simple DVCS with one of the ugliest and most inconsistent command line interfaces the humanity has ever seen *

2) If you feel the default choice of showing the author date is wrong and what you want to see is the committer date (FWIW I personally fully agree with this sentiment) just change the default behavior of git log in your ~/.gitconfig. As aberent@ pointed out above in this thread it's just a one liner, really.

This issue is not unique to chromium. You will get the same exact behavior if you git log the linux kernel sources, Android sources or generally any other git repo. Unless I am missing something here, we are not special in this sense.

I don't think it really helps in the long term asking depot_tools / infra folks to help us to live in a bubble where git is special in different ways we like more and doesn't behave like it does for the rest of the world. Just develop the right mix of git aliases and Stockholm syndrome like the rest of the world that is using git did ;-)

*Fun trivia: http://stevelosh.com/blog/2013/04/git-koans/

[agable]

Aside, popping off the stack a bit: My initial analysis of the change uploaded/landed by ckuiper@ wasn't quite correct. I've just confirmed that "git cl upload" always sets the Author Date to "now", no matter whether the branch being uploaded has multiple commits or just a single commit on it. So "git cl upload" was being bypassed entirely on that CL; it appears the author was using "git commit --amend && git push origin HEAD:refs/changes/12/477112". If our tools are bypassed, they can't help you do the right thing :)

As for why we don't want to clobber the Author Date and replace it with a copy of the Committer Date:

1) As Primiano said, the Author Date is used by git projects worldwide. The less special-sauce we have, the easier it is for our project and practices to be compatible with other systems and tools that interact with Git.

2) The Author Date encodes useful information! For example: a) It can tell you the Author's timezone, so you know when that Author is active; or b) It can tell you if there was a lag between when the change was written and submitted -- if the lag was large, and the change broke something upon submission, the conflict is likely in that lag time period

3) Preserving information is good; when there are perfectly reasonable workaround (such as changing your log config, using git log --fuller, or using git log --since), I believe that the preservation of information outweighs the slight confusion that shows up in the default log.

All of that said, I'm happy to be outvoted/overruled. I believe there is one way this could be implemented that would only be mostly filled with haxx, instead of entirely built out of cardboard and duct tape. If chromium eng leads or the community as a whole (truly a majority/plurality, please, not a loud minority) tell me that the desired state is to have the Committer Date and Author Date be redundant, it can be done. I just wanted to make sure that people know the reasons behind the current state first :)

Aaron

[Michael Giuffrida]

AuthorDate questions aside, does the CommiterDate always reflect the time the change landed in trunk (or whichever branch I'm pulling from)? Or will it sometimes reflect when the author uploaded the patch to gerrit, or when the author originally committed the patch locally?

Just want to know if we can blindly trust at least one of these dates.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/50e565a9-4a0a-48b2-bfaa-57529a7fd5ed%40chromium.org.

[Aaron Gable]

With Chromium's submit strategy, Rebase Always, the Committer Date will always be when the change was committed to the target branch (usually master).

(This is not true in all ChromeOS repos, which use different submit strategies (such as Merge If Necessary, which sometimes produces a merge commit, and sometimes produces a fast-forward merge).)

--

You received this message because you are subscribed to the Google Groups "infra-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to infra-dev+...@chromium.org.

To post to this group, send email to infr...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/CACi5S_2tT%3D6J%2B16bQLrXEY8PXJeC9MOtZ%3Dj5k6NkJ4-xvfZV%3Dg%40mail.gmail.com.

[John Abd-El-Malek]

Personally I care less about what git command line tools show.

I'm mostly curious what code search and gittiles show. I strongly believe these should be the date that the commit made it to the branch, otherwise it's confusing when one is using these tools.

To unsubscribe from this group and stop receiving emails from it, send an email to infra-dev+unsubscribe@chromium.org.

To post to this group, send email to infr...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/CACi5S_2tT%3D6J%2B16bQLrXEY8PXJeC9MOtZ%3Dj5k6NkJ4-xvfZV%3Dg%40mail.gmail.com.

--

You received this message because you are subscribed to the Google Groups "infra-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to infra-dev+unsubscribe@chromium.org.

To post to this group, send email to infr...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/CAH58R2d9EHV-QB0kCCRo6NT8eYYKKOj40%2Ba6H-xFNpPWz8O4LA%40mail.gmail.com.

[Peter Kasting]

On Tue, Jun 6, 2017 at 5:09 PM, John Abd-El-Malek <j...@chromium.org> wrote:

Personally I care less about what git command line tools show.

I'm mostly curious what code search and gittiles show. I strongly believe these should be the date that the commit made it to the branch, otherwise it's confusing when one is using these tools.

This.

I would be happy for us to cater to git log folks by adding some kind of alias (like "git cl log", but that feels a little weird) that shows commit rather than author dates.  But I don't think we should change the underlying "author date" more than we currently do; if git cl upload sets it at upload time, that seems correct.  Having "git log" display author dates rather than commit dates definitely doesn't make sense for how we manage our project, but to me the right way to fix is to try and change the tools displaying the dates to do the right thing, rather than corrupt the underlying metadata.

PK

[Dirk Pranke]

I definitely think it's reasonable to look into changing what gitiles and code search display, and we'll follow up on that.

-- Dirk

--

You received this message because you are subscribed to the Google Groups "infra-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to infra-dev+unsubscribe@chromium.org.
To post to this group, send email to infr...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/CAAHOzFC6H79yQnk9cXtjt8Zi2L5wfhFZUBrY2Lb%3DwXo%2BpDa5-Q%40mail.gmail.com.

[Michael Giuffrida]

On Mon, Jun 5, 2017 at 5:27 PM Trent Apted <tap...@chromium.org> wrote:

Take, for example, http://crrev.com/477112 .

It landed an hour ago, but the "Date" in git log is May 12 -- nearly a month ago.

Turns out this is "Author-Date".

$ git log --pretty=fuller --date=local 3b76c8f5278fd13afdfa4eef6cb24f7b7ce1a8f1

commit 3b76c8f5278fd13afdfa4eef6cb24f7b7ce1a8f1

Author:     ..

AuthorDate: Fri May 12 09:38:23 2017

Commit:     Commit Bot <commi...@chromium.org>

CommitDate: Tue Jun 6 08:54:13 2017

(aside: looking at the CL I actually have no idea where "May 12" comes from - it is git magic)

CLs from Rietveld would always use the same date, e.g.,

commit 525a0e6f0d79296a4da4f109f7a704ebbcf7f20a

Author:     ..

AuthorDate: Tue Jun 6 08:50:32 2017

Commit:     Commit Bot <commi...@chromium.org>

CommitDate: Tue Jun 6 08:50:32 2017

There is a closed Gerrit Bug - tl;dr is "WAI".

Sadly, `git log` defaults to Author-Date (i.e. --pretty=medium), which I don't think is very useful for Chromium.

If, like me, this confuses you, you can set a custom pretty format, like

git config --global pretty.mine "format:format:%C(yellow)commit %H%n%C(white)Author:     %an <%ae>%nCommitDate: %ad%n%n%w(0,4,4)%B%n"

git config --global alias.lg "log --abbrev-commit --date local --pretty=mine"

This is minor, but using this format (which is supposed to be similar to git's default "medium" format) gives me an extra line break after most CLs, so that most CL has two blank lines (three \n's) after it instead of just 1.

Without the "%n" at the end of the format string, that goes away, but then the minority of CLs have no blank lines after them, so the next commit ID follows the last line of the previous commit message.

Any idea what's causing this? I would suspect something wrong with the minority commit messages, but `git log --pretty=medium` works fine with one blank line between every CL.

Then using `git lg` rather than `git log` gives more useful dates. 

E.g., for me, I scan `git log` to see how old my upstream is and whether I should fetch. Author dates are not useful for this.

 - Trent.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---

You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAAGrfxfnzfFMhJ99xZa9ez42oTpnKjr4zC85jMJ4EWSHFEDKwA%40mail.gmail.com.

[Mike Frysinger]

to reiterate, i don't think changing gitiles for all repos is appropriate.  there are a number of projects (like all the CrOS repos) who are used to standard git behavior here, and having repos change behavior depending on the viewer is bad.

-mike

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---

You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAEoffTAxLt%2Br7auVfn8fHjYfJu6G%3D95w1ip%2B2ETRjPKWAfNrWw%40mail.gmail.com.

[Trent Apted]

On 7 June 2017 at 12:25, Michael Giuffrida <mich...@chromium.org> wrote:

If, like me, this confuses you, you can set a custom pretty format, like

git config --global pretty.mine "format:format:%C(yellow)commit %H%n%C(white)Author:     %an <%ae>%nCommitDate: %ad%n%n%w(0,4,4)%B%n"

git config --global alias.lg "log --abbrev-commit --date local --pretty=mine"

This is minor, but using this format (which is supposed to be similar to git's default "medium" format) gives me an extra line break after most CLs, so that most CL has two blank lines (three \n's) after it instead of just 1.

Without the "%n" at the end of the format string, that goes away, but then the minority of CLs have no blank lines after them, so the next commit ID follows the last line of the previous commit message.

Any idea what's causing this? I would suspect something wrong with the minority commit messages, but `git log --pretty=medium` works fine with one blank line between every CL.

Git is magic :). Implementing --pretty=medium as a lookup into a table of format strings would be far too sensible. Instead it's a CMIT_FMT_MEDIUM enum that has a bunch of bespoke stuff :/

I'd also really like to get back the branch annotations that appear in the logs in really recent versions of git.. but I haven't figured that one out yet.

[Dirk Pranke]

I'm sorry, I should've been clearer. Yes, I would only want to change gitiles for the Chromium projects, so we'd want to look for some way for this to be a per-project setting.

-- Dirk

[Aaron Gable]

For folks looking for nicer log formats, depot tools already provides "git map", which prints a colorized and nicely formatted log showing all your local branches, their relationships, and (as of today) the committer date instead of the author date.

It turns out all the discussion of Gitiles is moot -- on chromium.googlesource.com, the relative timestamp which it displays is already calculated relative to the committer timestamp, not the author timestamp. And when you click through to a commit, both timestamps are displayed side-by-side.

So we have log covered, and we have gitiles covered. It's worthwhile to look into changing codesearch (which does display the Author Date). Given the current state of the tooling, I see no reason to clobber the Author Date with a redundant Committer Date.

Aaron

On Wed, Jun 7, 2017 at 9:09 AM Dirk Pranke <dpr...@chromium.org> wrote:

I'm sorry, I should've been clearer. Yes, I would only want to change gitiles for the Chromium projects, so we'd want to look for some way for this to be a per-project setting.

-- Dirk

On Tue, Jun 6, 2017 at 11:18 PM, Mike Frysinger <vap...@chromium.org> wrote:

to reiterate, i don't think changing gitiles for all repos is appropriate.  there are a number of projects (like all the CrOS repos) who are used to standard git behavior here, and having repos change behavior depending on the viewer is bad.

-mike

On Tue, Jun 6, 2017 at 7:19 PM, Dirk Pranke <dpr...@chromium.org> wrote:

I definitely think it's reasonable to look into changing what gitiles and code search display, and we'll follow up on that.

-- Dirk

On Tue, Jun 6, 2017 at 6:20 PM, Peter Kasting <pkas...@chromium.org> wrote:

On Tue, Jun 6, 2017 at 5:09 PM, John Abd-El-Malek <j...@chromium.org> wrote:

Personally I care less about what git command line tools show.

I'm mostly curious what code search and gittiles show. I strongly believe these should be the date that the commit made it to the branch, otherwise it's confusing when one is using these tools.

This.

I would be happy for us to cater to git log folks by adding some kind of alias (like "git cl log", but that feels a little weird) that shows commit rather than author dates.  But I don't think we should change the underlying "author date" more than we currently do; if git cl upload sets it at upload time, that seems correct.  Having "git log" display author dates rather than commit dates definitely doesn't make sense for how we manage our project, but to me the right way to fix is to try and change the tools displaying the dates to do the right thing, rather than corrupt the underlying metadata.

PK

--

You received this message because you are subscribed to the Google Groups "infra-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to infra-dev+...@chromium.org.

To post to this group, send email to infr...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/CAAHOzFC6H79yQnk9cXtjt8Zi2L5wfhFZUBrY2Lb%3DwXo%2BpDa5-Q%40mail.gmail.com.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAEoffTAxLt%2Br7auVfn8fHjYfJu6G%3D95w1ip%2B2ETRjPKWAfNrWw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "infra-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to infra-dev+...@chromium.org.

To post to this group, send email to infr...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/CAEoffTA2gG46HJsOZ7ubf50Wi8eX1RAGwKyuTfG%2BDh9VOa2hCQ%40mail.gmail.com.

[Michael Moss]

On Wed, Jun 7, 2017 at 10:09 AM, Aaron Gable <aga...@chromium.org> wrote:

For folks looking for nicer log formats, depot tools already provides "git map", which prints a colorized and nicely formatted log showing all your local branches, their relationships, and (as of today) the committer date instead of the author date.

It turns out all the discussion of Gitiles is moot -- on chromium.googlesource.com, the relative timestamp which it displays is already calculated relative to the committer timestamp, not the author timestamp. And when you click through to a commit, both timestamps are displayed side-by-side.

For the curious (and in case it needs any future tweaking), this was originally enabled by cl/65010145 (sorry, internal CL) way back in 2014. IIRC, it was one of the "compatibility" prerequisites for the svn->git migration

 

So we have log covered, and we have gitiles covered. It's worthwhile to look into changing codesearch (which does display the Author Date). Given the current state of the tooling, I see no reason to clobber the Author Date with a redundant Committer Date.

Aaron

On Wed, Jun 7, 2017 at 9:09 AM Dirk Pranke <dpr...@chromium.org> wrote:

I'm sorry, I should've been clearer. Yes, I would only want to change gitiles for the Chromium projects, so we'd want to look for some way for this to be a per-project setting.

-- Dirk

On Tue, Jun 6, 2017 at 11:18 PM, Mike Frysinger <vap...@chromium.org> wrote:

to reiterate, i don't think changing gitiles for all repos is appropriate.  there are a number of projects (like all the CrOS repos) who are used to standard git behavior here, and having repos change behavior depending on the viewer is bad.

-mike

On Tue, Jun 6, 2017 at 7:19 PM, Dirk Pranke <dpr...@chromium.org> wrote:

I definitely think it's reasonable to look into changing what gitiles and code search display, and we'll follow up on that.

-- Dirk

On Tue, Jun 6, 2017 at 6:20 PM, Peter Kasting <pkas...@chromium.org> wrote:

On Tue, Jun 6, 2017 at 5:09 PM, John Abd-El-Malek <j...@chromium.org> wrote:

Personally I care less about what git command line tools show.

I'm mostly curious what code search and gittiles show. I strongly believe these should be the date that the commit made it to the branch, otherwise it's confusing when one is using these tools.

This.

I would be happy for us to cater to git log folks by adding some kind of alias (like "git cl log", but that feels a little weird) that shows commit rather than author dates.  But I don't think we should change the underlying "author date" more than we currently do; if git cl upload sets it at upload time, that seems correct.  Having "git log" display author dates rather than commit dates definitely doesn't make sense for how we manage our project, but to me the right way to fix is to try and change the tools displaying the dates to do the right thing, rather than corrupt the underlying metadata.

PK

--

You received this message because you are subscribed to the Google Groups "infra-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to infra-dev+unsubscribe@chromium.org.

To post to this group, send email to infr...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/CAAHOzFC6H79yQnk9cXtjt8Zi2L5wfhFZUBrY2Lb%3DwXo%2BpDa5-Q%40mail.gmail.com.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAEoffTAxLt%2Br7auVfn8fHjYfJu6G%3D95w1ip%2B2ETRjPKWAfNrWw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "infra-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to infra-dev+unsubscribe@chromium.org.

To post to this group, send email to infr...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/CAEoffTA2gG46HJsOZ7ubf50Wi8eX1RAGwKyuTfG%2BDh9VOa2hCQ%40mail.gmail.com.

--

You received this message because you are subscribed to the Google Groups "infra-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to infra-dev+unsubscribe@chromium.org.

To post to this group, send email to infr...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/CAH58R2darEEyj6_aH3_Dd3Vgtb2nqQk5aQ%2B0sC01jX%3DM0DEH4g%40mail.gmail.com.

[Michael Giuffrida]

:-(

Your git repo has too many branches (123/40) for this tool to work well.

You may adjust this limit by running:

git config depot-tools.branch-limit <new_limit>

I only want a nice looking log from HEAD.

[Aaron Gable]

@mgiuffrida: Try "git cl archive". It automatically removes all of the branches which are tracking CLs that have been submitted, on the assumption that you don't really need to be maintaining them anymore. In addition, if you're a fan of the rebase workflow, "git rebase-update" will rebase all of your currently-open branches on top of origin/master, and remove any which end up with no diff (i.e. have been submitted).

[Michael Giuffrida]

On Wed, Jun 7, 2017 at 11:35 AM Aaron Gable <aga...@chromium.org> wrote:

@mgiuffrida: Try "git cl archive". It automatically removes all of the branches which are tracking CLs that have been submitted, on the assumption that you don't really need to be maintaining them anymore.

I don't use `git cl archive` because it makes it a pain to rebase CLs depending on archived stuff, especially when the archived stuff needs to be squashed to prevent a rebase onto origin/master from throwing a zillion merge conflicts.

 

In addition, if you're a fan of the rebase workflow, "git rebase-update" will rebase all of your currently-open branches on top of origin/master, and remove any which end up with no diff (i.e. have been submitted).

Yeah, I should use that more. It leaves my other working directories (besides the one I run it in) in a weird state though since the branches they've checked out change from underneath them.

[Colin Blundell]

Thanks for all the responses here. It is very difficult for me personally to imagine a use case for knowing the date of when a committed CL was last uploaded before the commit landed; in ~6 years of working on Chromium, I have never once needed to ask that question. So it's hard for me to buy into the argument of preserving that information over having git log default to showing what is the actual useful information for Chromium for all Chromium devs. In addition Chromium already uses git in such a different way to a vanilla git repo that I also can't buy arguments of "let's not make ourselves more different from a vanilla git repo."

Getting started as (and being) a Chromium dev is already hard. If we make it so that the date shown by "git log" is misleading unless you do special local configuration, that seems to me like it significantly increases the cost for very little concrete benefit that I can see. I understand that other repos behave differently and that we don't want to affect the behavior of those other repos, but I don't see that "other repos behave differently" has ever really been a strong argument for how we do a given thing in Chromium. We can and should of course limit the scope of any changes so that they only impact Chromium.

That said, if I'm the only one or near the only one who feels this strongly about it, I will let it drop, change my git log default, and wait for cs.chromium.org to change.

Best,

Colin

[Michael Giuffrida]

On Wed, Jun 7, 2017 at 2:14 AM Trent Apted <tap...@chromium.org> wrote:

On 7 June 2017 at 12:25, Michael Giuffrida <mich...@chromium.org> wrote:

If, like me, this confuses you, you can set a custom pretty format, like

git config --global pretty.mine "format:format:%C(yellow)commit %H%n%C(white)Author:     %an <%ae>%nCommitDate: %ad%n%n%w(0,4,4)%B%n"

git config --global alias.lg "log --abbrev-commit --date local --pretty=mine"

This is minor, but using this format (which is supposed to be similar to git's default "medium" format) gives me an extra line break after most CLs, so that most CL has two blank lines (three \n's) after it instead of just 1.

Without the "%n" at the end of the format string, that goes away, but then the minority of CLs have no blank lines after them, so the next commit ID follows the last line of the previous commit message.

Any idea what's causing this? I would suspect something wrong with the minority commit messages, but `git log --pretty=medium` works fine with one blank line between every CL.

Git is magic :). Implementing --pretty=medium as a lookup into a table of format strings would be far too sensible. Instead it's a CMIT_FMT_MEDIUM enum that has a bunch of bespoke stuff :/

ThanksS! I found a handy fix: '%B%-%n' replaces all trailing newlines from the body with a single newline.

git log --pretty="format:%C(yellow)commit %H%n%C(white)Author:     %an <%ae>%nCommitDate: %ad%n%n%w(0,4,4)%B%-%n"

Though the last % shouldn't be necessary. I believe there's a bug, and adding it triggers another bug that cancels out the first bug to make everything work. So it goes.

[Adam Rice]

For the record, I am also not in favour of making every Chromium developer have baroque local git configuration just so that we can avoid throwing away a piece of metadata that we never needed.

I also don't think that replacing git log with a tool that prints

Your git repo has too many branches (74/20) for this tool to work well.

is a viable alternative.

I thought we were told that the migration to Gerrit would not disrupt our workflow. Did that happen or did I just dream it?

Colin

--

To unsubscribe from this group and stop receiving emails from it, send an email to infra-dev+unsubscribe@chromium.org.

To post to this group, send email to infr...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/CAAHOzFC6H79yQnk9cXtjt8Zi2L5wfhFZUBrY2Lb%3DwXo%2BpDa5-Q%40mail.gmail.com.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAEoffTAxLt%2Br7auVfn8fHjYfJu6G%3D95w1ip%2B2ETRjPKWAfNrWw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "infra-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to infra-dev+unsubscribe@chromium.org.

To post to this group, send email to infr...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/CAEoffTA2gG46HJsOZ7ubf50Wi8eX1RAGwKyuTfG%2BDh9VOa2hCQ%40mail.gmail.com.

--

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAMGE5NFqHUe_QGx96FzpLPFUqoDPo0Urq2XypQdLUm_Bqgsvqw%40mail.gmail.com.

[Colin Blundell]

On Tue, Jun 6, 2017 at 5:06 PM Anthony Berent <abe...@chromium.org> wrote:

You don't need your own git command alias. You can configure whatever you choose as the git log default by doing, for example,

git config --global format.pretty "fuller"

If you don't like any of gits standard format you can also do, for example,

git config --global format.pretty "format:format:%C(yellow)commit %H%n%C(white)Author:     %an <%ae>%nCommitDate: %ad%n%n%w(0,4,4)%B%n"

Just to close the loop here, the above preserves Trent's original error of using the author date instead of commit date :). Here's the command I used to get something that looks basically identical to the default of "pretty=medium" but with "Date: <author-date>" replaced by "Committed: <commit-date>":

 git config --global format.pretty "format:%C(yellow)commit %H%nAuthor:    %an <%ae>%nCommitted: %cd%n%n%w(0,4,4)%B%n"

 

On Tue, 6 Jun 2017 at 15:38 Colin Blundell <blun...@chromium.org> wrote:

Slightly more productively: I'm not suggesting that we necessarily need to go back to the behavior where Author Date and Commit Date were identical, as from the bug it sounds like that's not desired. What I'm saying is that Author Date is uninteresting (and when referenced as "Date", worse than uninteresting) from a chromium dev's perspective. Could we make it (e.g., via depot_tools) such that Commit Date is what is shown as the Date field by default when doing "git log" in a chromium checkout (and on cs.chromium.org and whatever other mainstream tooling chromium devs use)? I don't think it's sufficient to have chromium devs be able to customize their git log output to achieve that effect.

Thanks,

Colin

On Tue, Jun 6, 2017 at 4:31 PM Colin Blundell <blun...@chromium.org> wrote:

Thanks for calling this out, Trent. I had noticed this in the past day or two but hadn't really put my finger on the reason.

Apologies in advance for harping on this, as I know how hard you've been working on this transition overall, Aaron (and overall it's going great). However:

This seems like a serious regression to me. For example, when I was sheriffing yesterday I was investigating a flake that was introduced in the past few days. I initially ignored what turned out to be the culprit CL because its "Date" field was May 19, whereas the flake had started June 2.

It seems like if we stick with this behavior, the "Date" field in "git log" (and by extension the history in cs.chromium.org) becomes actively misleading from a chromium developer's perspective, and the best we could do is teach ourselves to ignore it (and suffer from a lack of information).

Am I missing something that makes this less serious than I'm outlining above?

Thanks,

Colin

On Tue, Jun 6, 2017 at 11:50 AM Paweł Hajdan, Jr. <phajd...@chromium.org> wrote:

+infra-dev,agable

On Tue, Jun 6, 2017 at 2:36 AM, Trent Apted <tap...@chromium.org> wrote:

On 6 June 2017 at 10:26, Trent Apted <tap...@chromium.org> wrote:

git config --global pretty.mine "format:format:%C(yellow)commit %H%n%C(white)Author:     %an <%ae>%nCommitDate: %ad%n%n%w(0,4,4)%B%n"

git config --global alias.lg "log --abbrev-commit --date local --pretty=mine"

uh, that should be,

git config --global pretty.mine "format:format:%C(yellow)commit %H%n%C(white)Author:     %an <%ae>%nCommitDate: %cd%n%n%w(0,4,4)%B%n"

git config --global alias.lg "log --abbrev-commit --date local --pretty=mine"

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAAGrfxdk9E%2B2VGf7kJNTQuE4VUggZLxTQRSyO893sE4GHvLJzQ%40mail.gmail.com.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAATLsPYqy5WzF9iEKKPppZOqQofDbidQWxGeJgzygoN7Cw2tRw%40mail.gmail.com.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAMGE5NGQL1JurqH3m3nrU%3Dk1SvEM%2BhWBpqwsaKYtai03oTPNfA%40mail.gmail.com.

[Colin Blundell]

On Mon, Jun 12, 2017 at 3:37 PM Colin Blundell <blun...@chromium.org> wrote:

On Tue, Jun 6, 2017 at 5:06 PM Anthony Berent <abe...@chromium.org> wrote:

You don't need your own git command alias. You can configure whatever you choose as the git log default by doing, for example,

git config --global format.pretty "fuller"

If you don't like any of gits standard format you can also do, for example,

git config --global format.pretty "format:format:%C(yellow)commit %H%n%C(white)Author:     %an <%ae>%nCommitDate: %ad%n%n%w(0,4,4)%B%n"

Just to close the loop here, the above preserves Trent's original error of using the author date instead of commit date :). Here's the command I used to get something that looks basically identical to the default of "pretty=medium" but with "Date: <author-date>" replaced by "Committed: <commit-date>":

 git config --global format.pretty "format:%C(yellow)commit %H%nAuthor:    %an <%ae>%nCommitted: %cd%n%n%w(0,4,4)%B%n"

Also just uploaded this documentation CL.

[Dirk Pranke]

We could probably a hook to DEPS that would set `git config --local` if it wasn't already. 

Thoughts?

-- Dirk

--

You received this message because you are subscribed to the Google Groups "infra-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to infra-dev+unsubscribe@chromium.org.
To post to this group, send email to infr...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/CAMGE5NGP-Wq-gx9b6S7Msa%3DtOCDHXJRU8Tj6aOzY%3Dz5KSRj2HQ%40mail.gmail.com.

[Michael Giuffrida]

OK, here's my latest attempt which matches --pretty=medium almost exactly, but substitutes the commited date:

git config --global format.pretty 'format:%C(auto,yellow)commit %H%C(auto)%d%nAuthor:    %an <%ae>%nCommitted: %cd%n%n%w(0,4,4)%B%-%n'

Like --pretty=medium, this: 

• Shows short ref names for commits, e.g. HEAD or my-branch
• Prints color codes ONLY when outputting to a terminal
• Has exactly one blank line after each commit's message

The only problem I've found is that when NOT outputting to a terminal (e.g., redirecting to a file), the short ref names are still included. The default format would exclude the short ref names, only showing the commit hash. There should be a workaround with --decorate but it doesn't seem to work.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAMGE5NGP-Wq-gx9b6S7Msa%3DtOCDHXJRU8Tj6aOzY%3Dz5KSRj2HQ%40mail.gmail.com.

[Colin Blundell]

On Mon, Jun 12, 2017 at 5:44 PM Dirk Pranke <dpr...@chromium.org> wrote:

We could probably a hook to DEPS that would set `git config --local` if it wasn't already. 

Thoughts?

-- Dirk

Does anyone think this is a bad idea? I'm supportive, but that's obvious.

 

To unsubscribe from this group and stop receiving emails from it, send an email to infra-dev+...@chromium.org.

To post to this group, send email to infr...@chromium.org.

[Colin Blundell]

On Mon, Jun 12, 2017 at 10:35 PM Michael Giuffrida <mich...@chromium.org> wrote:

OK, here's my latest attempt which matches --pretty=medium almost exactly, but substitutes the commited date:

git config --global format.pretty 'format:%C(auto,yellow)commit %H%C(auto)%d%nAuthor:    %an <%ae>%nCommitted: %cd%n%n%w(0,4,4)%B%-%n'

Like --pretty=medium, this: 

• Shows short ref names for commits, e.g. HEAD or my-branch
• Prints color codes ONLY when outputting to a terminal
• Has exactly one blank line after each commit's message

The only problem I've found is that when NOT outputting to a terminal (e.g., redirecting to a file), the short ref names are still included. The default format would exclude the short ref names, only showing the commit hash. There should be a workaround with --decorate but it doesn't seem to work.

Thanks, Michael! This looks good to me.

[Nico Weber]

On Tue, Jun 6, 2017 at 6:38 PM, Brett Wilson <bre...@chromium.org> wrote:

On Tue, Jun 6, 2017 at 3:38 PM, Brett Wilson <bre...@chromium.org> wrote:

On Tue, Jun 6, 2017 at 3:07 PM, Aaron Gable <aga...@chromium.org> wrote:

So from the feedback here, it seems clear that git-cl should always set the Author Date to "now" when it uploads a new patchset, no matter whether the user has been using "git commit --amend" locally or not. That makes total sense to me, and I'll file a change to have it do that soon.

Some people in this thread are also expressing the opinion that the time-of-last-upload is insufficient, and that the Author Date should be set to the time of submission, the same as the Commit Date. That will not happen. As Mike Frysinger said, changing the internals of Gerrit to set the Author Date when submitting a commit is a non-starter for the rest of the git-using community.

Can you go into more details? Why is this a non-starter? I understand why this is inappropriate for our project, but why not have a setting for our project?

I meant inappropriate for "some" projects.

Was this question ever answered?

I attempted to do a summary of this thread, and it sounds like several people (tapted blundell asvitkine brettw dcheng hwennborg) all feel that not having the commit date by default in `git log` is an issue. Nobody said they found this useful.Why can't we fix this? (It could be some gerrit setting or something that's off by default but on for us. That seems far preferable over a complicated thing that tries to configure git's log command to fix up the displayed data after the fact.

 

Brett

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CABiGVV_9z1DVN8yBC4RecMdR6Q8i%2BLB967Qqn_gWGJAe%2BCcAyg%40mail.gmail.com.

[Anthony Berent]

Is even the commit date what you want? If you look at a log of master with commit dates even these are not in order. I believe the commit dates are the dates at which the commits were uploaded to Gerrit, not when they landed.

[Primiano Tucci]

On Tue, Jun 13, 2017 at 5:23 PM, Anthony Berent <abe...@chromium.org> wrote:

Is even the commit date what you want? If you look at a log of master with commit dates even these are not in order. I believe the commit dates are the dates at which the commits were uploaded to Gerrit, not when they landed.

By default git log shows commits in: std::tie(topological order, commit date). For a project which has a strict linear history like us it just degenerates into topological order (% crossing the blink merge point, but I seriously doubt anybody git-logs that deep).

That means that no matter how you touch either the commit or the author date, the order of git log won't change.

 

You received this message because you are subscribed to the Google Groups "infra-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to infra-dev+unsubscribe@chromium.org.

To post to this group, send email to infr...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/CABdZ6yC-toQmwN2S-p4tujP6DsSGVaxu%3Dj5Vf7gLcOBTYwJKCQ%40mail.gmail.com.

[Anthony Berent]

On Tue, 13 Jun 2017 at 17:39 Primiano Tucci <prim...@chromium.org> wrote:

On Tue, Jun 13, 2017 at 5:23 PM, Anthony Berent <abe...@chromium.org> wrote:

Is even the commit date what you want? If you look at a log of master with commit dates even these are not in order. I believe the commit dates are the dates at which the commits were uploaded to Gerrit, not when they landed.

By default git log shows commits in: std::tie(topological order, commit date). For a project which has a strict linear history like us it just degenerates into topological order (% crossing the blink merge point, but I seriously doubt anybody git-logs that deep).

That means that no matter how you touch either the commit or the author date, the order of git log won't change.

I don't think anybody wants the order in the log to change. What I think people want to see in git log is the dates when the commits landed on master. This is something this is not, as far as I know, recorded at within the commits, and, I believe, hasn't been available since we stopped using SVN. To add this so we would, I think, have to change how the commit queue lands commits (although I am not sure of the details). 

Having said this, the only thing I ever use commit dates for is to get a general idea of how old things are and I am not sure how I would use a precise landing date if I had it.

 

On Tue, 13 Jun 2017 at 16:05 Nico Weber <tha...@chromium.org> wrote:

On Tue, Jun 6, 2017 at 6:38 PM, Brett Wilson <bre...@chromium.org> wrote:

On Tue, Jun 6, 2017 at 3:38 PM, Brett Wilson <bre...@chromium.org> wrote:

On Tue, Jun 6, 2017 at 3:07 PM, Aaron Gable <aga...@chromium.org> wrote:

So from the feedback here, it seems clear that git-cl should always set the Author Date to "now" when it uploads a new patchset, no matter whether the user has been using "git commit --amend" locally or not. That makes total sense to me, and I'll file a change to have it do that soon.

Some people in this thread are also expressing the opinion that the time-of-last-upload is insufficient, and that the Author Date should be set to the time of submission, the same as the Commit Date. That will not happen. As Mike Frysinger said, changing the internals of Gerrit to set the Author Date when submitting a commit is a non-starter for the rest of the git-using community.

Can you go into more details? Why is this a non-starter? I understand why this is inappropriate for our project, but why not have a setting for our project?

I meant inappropriate for "some" projects.

Was this question ever answered?

I attempted to do a summary of this thread, and it sounds like several people (tapted blundell asvitkine brettw dcheng hwennborg) all feel that not having the commit date by default in `git log` is an issue. Nobody said they found this useful.Why can't we fix this? (It could be some gerrit setting or something that's off by default but on for us. That seems far preferable over a complicated thing that tries to configure git's log command to fix up the displayed data after the fact.

 

Brett

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CABiGVV_9z1DVN8yBC4RecMdR6Q8i%2BLB967Qqn_gWGJAe%2BCcAyg%40mail.gmail.com.

--

You received this message because you are subscribed to the Google Groups "infra-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to infra-dev+...@chromium.org.

To post to this group, send email to infr...@chromium.org.

[Colin Blundell]

On Tue, Jun 13, 2017 at 6:23 PM Anthony Berent <abe...@chromium.org> wrote:

Is even the commit date what you want? If you look at a log of master with commit dates even these are not in order. I believe the commit dates are the dates at which the commits were uploaded to Gerrit, not when they landed.

 Do you have an example? I haven't seen this.

[Aaron Gable]

Ok, summary of this thread:

* git log (and other things which want to act like git log, such as gitiles and codesearch) shows the Author Date by default

* Chromium developers are accustomed to having their git log be in chronological order, because of an old bug in Rietveld meant that it didn't forge the Author Date to be the time of last patchset upload when it was forging the Author Name

* Now that we're using Gerrit, some Chromium developers don't like the fact that their git log sometimes shows dates which are not in chronological order

* There are many "git config" commands (provided in this thread) which will make your git log show the committer date instead of the author date

* depot_tools provides "git map", which shows the committer date along with other useful information

* Gitiles already shows the committer date instead of the author date

* A change (internal, sorry) is in flight to make codesearch show the committer date instead of the author date as well

* A proposal has been floated to make Gerrit forge the author date to match the committer date.

  - I am opposed to this proposal because it would lose useful information, make the chromium project even less of a canonical git project, and take large amounts of developer effort that could be better spent elsewhere

* A propsal has been floated to add a "git config --local" command to set up the appropriate log alias as a chromium DEPS hook

  - I don't have any strong opinion on this

Some more details to address recent emails:

aberent@: yes, the commit date is what people want. This information is still available; it didn't go away with the switch away from SVN. Because chromium modifes every commit when it lands (to add the cr-commit-position and other footers), the commit date is always exactly when it was submitted. This is not necessarily true for other gerrit projects that don't modify commit messages like we do.

thakis@: Gerrit offers a selection of six submission strategies. None of these are configurable -- the configuration is in choosing which strategy you want, not in configuring that strategy. So it would be a large amount of developer effort, as well as convincing the gerrit community that they should accept such additional complexity, in order to make them configurable to forge the author date. Gerrit also offers an API to intercept changes during submission, but the API only lets you modify the commit message, not other commit metadata. So again, changing that would take a large amount of developer effort.

Aaron

To unsubscribe from this group and stop receiving emails from it, send an email to infra-dev+...@chromium.org.

To post to this group, send email to infr...@chromium.org.

[Torne (Richard Coles)]

On Tue, 13 Jun 2017 at 13:03 Anthony Berent <abe...@chromium.org> wrote:

On Tue, 13 Jun 2017 at 17:39 Primiano Tucci <prim...@chromium.org> wrote:

On Tue, Jun 13, 2017 at 5:23 PM, Anthony Berent <abe...@chromium.org> wrote:

Is even the commit date what you want? If you look at a log of master with commit dates even these are not in order. I believe the commit dates are the dates at which the commits were uploaded to Gerrit, not when they landed.

By default git log shows commits in: std::tie(topological order, commit date). For a project which has a strict linear history like us it just degenerates into topological order (% crossing the blink merge point, but I seriously doubt anybody git-logs that deep).

That means that no matter how you touch either the commit or the author date, the order of git log won't change.

 

I don't think anybody wants the order in the log to change. What I think people want to see in git log is the dates when the commits landed on master. This is something this is not, as far as I know, recorded at within the commits, and, I believe, hasn't been available since we stopped using SVN. To add this so we would, I think, have to change how the commit queue lands commits (although I am not sure of the details). 

I think that the commit queue and git cl land already cherrypick onto master in almost all cases to land stuff, which means that the commit date actually is the point the commit landed on master. The one possible exception would be if your commit is already based on the tip of master, at which point it would be *possible* for it to land it without cherrypicking and for the commit date to be a different point than when it actually landed. I don't know if our tools are configured to cherrypick anyway even in this circumstance.

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CABdZ6yB7-vWVgByDhhxrvYuqbJEWgQ4nKBowcT_TX5Oym5Lk5A%40mail.gmail.com.

[Anthony Berent]

I take it back, there was a mistake in my git log format string. The commit dates do appear to be in order.

[Nico Weber]

On Tue, Jun 13, 2017 at 1:05 PM, Aaron Gable <aga...@chromium.org> wrote:

Ok, summary of this thread:

* git log (and other things which want to act like git log, such as gitiles and codesearch) shows the Author Date by default

* Chromium developers are accustomed to having their git log be in chronological order, because of an old bug in Rietveld meant that it didn't forge the Author Date to be the time of last patchset upload when it was forging the Author Name

* Now that we're using Gerrit, some Chromium developers don't like the fact that their git log sometimes shows dates which are not in chronological order

I think it's more "shows a meaningless data". The date when the CL landed means something (imho, not terribly much since we have the commit numbers, but more than nothing), all the other dates don't.

 

* There are many "git config" commands (provided in this thread) which will make your git log show the committer date instead of the author date

* depot_tools provides "git map", which shows the committer date along with other useful information

* Gitiles already shows the committer date instead of the author date

* A change (internal, sorry) is in flight to make codesearch show the committer date instead of the author date as well

* A proposal has been floated to make Gerrit forge the author date to match the committer date.

  - I am opposed to this proposal because it would lose useful information,

What's useful about the current date? My reading of the thread is that several people think this is a regression, and I've seen nobody say that the date that's there is useful (until I read your reply here).

 

make the chromium project even less of a canonical git project

Chrome has hundreds of people with close to a decade of experience with a linear dev model. I think most large git deployments use a linear history. So I don't think this rhetoric is particularly productive.

(I don't have an opinion on this issue.)

 

, and take large amounts of developer effort that could be better spent elsewhere

* A propsal has been floated to add a "git config --local" command to set up the appropriate log alias as a chromium DEPS hook

  - I don't have any strong opinion on this

Some more details to address recent emails:

aberent@: yes, the commit date is what people want. This information is still available; it didn't go away with the switch away from SVN. Because chromium modifes every commit when it lands (to add the cr-commit-position and other footers), the commit date is always exactly when it was submitted. This is not necessarily true for other gerrit projects that don't modify commit messages like we do.

thakis@: Gerrit offers a selection of six submission strategies. None of these are configurable -- the configuration is in choosing which strategy you want, not in configuring that strategy. So it would be a large amount of developer effort, as well as convincing the gerrit community

We're probably a noticeable part of the gerrit community now (?) I don't have an opinion on this issue, but having an upstream who's not sympathetic towards our needs seems like a drawback compared to unmaintained rietveld where we can do what we want :-P

 

To unsubscribe from this group and stop receiving emails from it, send an email to infra-dev+unsubscribe@chromium.org.

To post to this group, send email to infr...@chromium.org.

[Torne (Richard Coles)]

I think having a linear history is extremely rare. Virtually no standard git tooling or workflows even make this something you can easily do - gerrit's support for server-side cherrypicking of completed code reviews is the only mechanism I know that even makes this realistic and even most gerrit based projects I'm aware of don't use this option or don't enforce this being the sole way to commit (and still permit pushing normally, or merging by other mechanisms).

To unsubscribe from this group and stop receiving emails from it, send an email to infra-dev+...@chromium.org.

To post to this group, send email to infr...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/CABdZ6yC-toQmwN2S-p4tujP6DsSGVaxu%3Dj5Vf7gLcOBTYwJKCQ%40mail.gmail.com.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAMGbLiFc4sAHwZ7FHzZNY8k6RrnimsMczArE%2Bk4NmUc5Jy0JXw%40mail.gmail.com.

[Brett Wilson]

On Tue, Jun 13, 2017 at 11:14 AM, Torne (Richard Coles) <to...@chromium.org> wrote:

I think having a linear history is extremely rare. Virtually no standard git tooling or workflows even make this something you can easily do - gerrit's support for server-side cherrypicking of completed code reviews is the only mechanism I know that even makes this realistic and even most gerrit based projects I'm aware of don't use this option or don't enforce this being the sole way to commit (and still permit pushing normally, or merging by other mechanisms).

What I would expect to happen is that commit-bit / gerrit / "git cl land" set the date to "now" when it lands things. If I merge a change to a release branch, I don't have this expectation.

All I'm hearing on this thread is "this isn't how it's done", "this isn't how it works", "this would lose information", "this would be confusing to other people." I don't find these helpful.

What would be helpful is hearing why it would be very difficult to implement, exactly what information it loses, exactly how it's confusing to other people. Because I don't understand any of these.

Brett

[Steve Kobes]

On Tue, Jun 13, 2017 at 10:05 AM, Aaron Gable <aga...@chromium.org> wrote:

thakis@: Gerrit offers a selection of six submission strategies. None of these are configurable -- the configuration is in choosing which strategy you want, not in configuring that strategy. So it would be a large amount of developer effort, as well as convincing the gerrit community that they should accept such additional complexity, in order to make them configurable to forge the author date. Gerrit also offers an API to intercept changes during submission, but the API only lets you modify the commit message, not other commit metadata. So again, changing that would take a large amount of developer effort.

I won't make any claims about effort, but I notice that submission strategy is just one of many existing project-specific configuration options.  One could imagine a new, orthogonal option like submit.forgeAuthorDate (perhaps ignored for strategies other than "Rebase Always").  It's not as though configurability is an entirely new concept for Gerrit, or a deep rethinking of submission strategies.

[Aaron Gable]

skobes@: A top-level submit.forgeAuthorDate would not be compatible with 4 out of the 6 submit strategies (Fast Forward Only, Merge Always, Merge if Necessary, and Rebase if Necessary in the case that rebase isn't necessary) which do not produce new commit objects representing your code review. They submit exactly with commit which was reviewed, with no modifications, and therefore submit the same hash -- adding an option to forge the Author Date in those strategies would break their guarantees. That's why it would have to be a per-strategy configuration, which simply hasn't existed previously.

brettw@: These are what I've attempted to address above:

why it is difficult to implement:

"""

Gerrit offers a selection of six submission strategies. None of these are configurable -- the configuration is in choosing which strategy you want, not in configuring that strategy. So it would be a large amount of developer effort, as well as convincing the gerrit community that they should accept such additional complexity, in order to make them configurable to forge the author date. Gerrit also offers an API to intercept changes during submission, but the API only lets you modify the commit message, not other commit metadata. So again, changing that would take a large amount of developer effort.

"""

what information it loses:

"""

The Author Date encodes useful information! For example: a) It can tell you the Author's timezone, so you know when that Author is active; or b) It can tell you if there was a lag between when the change was written and submitted -- if the lag was large, and the change broke something upon submission, the conflict is likely in that lag time period

"""

how it's confusing to other people:

The git book clearly lays out the difference between Author and Committer, and the guarantee that the author date is not updated by operations which only modify the Committer (such as rebase, cherry-pick, and commit --amend). Having a different author and committer, but the same author date and committer date, is something which simply doesn't exist in other git workflows. The first assumption could easily be "this system forges the Author field", which would be both worrisome as an experienced git contributor coming in from another community, and would be incorrect.

Aaron

[Michael Giuffrida]

On Tue, Jun 13, 2017 at 10:05 AM Aaron Gable <aga...@chromium.org> wrote:

Ok, summary of this thread:

* git log (and other things which want to act like git log, such as gitiles and codesearch) shows the Author Date by default

 

* Chromium developers are accustomed to having their git log be in chronological order, because of an old bug in Rietveld meant that it didn't forge the Author Date to be the time of last patchset upload when it was forging the Author Name 

* Now that we're using Gerrit, some Chromium developers don't like the fact that their git log sometimes shows dates which are not in chronological order

I don't think this accurately summarizes the issues presented on this thread. The main concern isn't that log no longer appears to be in chronological order. We all know we have a linear history and `git log` will always be in chronological order of when the changes landed on trunk.

The concern I see here is that the dates shown are not useful, regardless of relative ordering. Here's an example of the distinction:

"When did this file last change?"

$ git log foo.cc

"Oh, 3 weeks ago? Guess that wasn't the regression I'm looking for."

The concern isn't about "chronological ordering" so much as understanding the exact date a thing landed, and it's an important distinction. Another example that goes beyond `git log`:

"Looks like something broke this code recently. When did that land?"

$ git blame foo.cc

"Ah, change d34db33f looks suspicious. Oh, that's dated 3 weeks ago? Guess it's not the regression I'm looking for."

* There are many "git config" commands (provided in this thread) which will make your git log show the committer date instead of the author date 

These apply to log, show and whatchanged, but not other commands like blame.

 

* depot_tools provides "git map", which shows the committer date along with other useful information

A summary should include: "`git map` does not work for devs with many branches."

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAH58R2dqQLBKv%2BsdiYgfDCRrD8yYUZiMQ4w7m9tNEU-66YBzPQ%40mail.gmail.com.

[Dirk Pranke]

It seems like there are three obvious paths going forward.

The first is to get used to how Gerrit does things by default and get used to surfacing the author date instead of the commit date.

The second is to try and make our tools use the commit date by default where possible and to try and make things configurable so users can switch to seeing the author date if necessary.

The third is to figure out how to do what Rietveld did, set the author date to match the commit date, and rely on the codereview history for additional information.

I believe there is general consensus in Chromium-land that we don't want to do the first option. It's less clear whether the second or third option is better, but I think at this point the request is clear.

As of now, the plan of record is the second option: to change the tools to do what we want, but leave the underlying system alone.

I've filed crbug.com/732968 to track the idea that we should match dates in the underlying system instead.  On that bug, we'll scope out the potential impact, priority, whether we can get the Gerrit folks to agree, etc. If you want to follow along, please star that issue, and if you have comments, do feel free to add them there as well. In particular, if you find other cases where we can't easily show the commit date (like in git blame), please mention them there and/or file linked bugs.

Otherwise, let's bring this thread to a close. 

Thanks,

-- Dirk

To unsubscribe from this group and stop receiving emails from it, send an email to infra-dev+unsubscribe@chromium.org.

To post to this group, send email to infr...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/CABdZ6yC-toQmwN2S-p4tujP6DsSGVaxu%3Dj5Vf7gLcOBTYwJKCQ%40mail.gmail.com.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAH58R2dqQLBKv%2BsdiYgfDCRrD8yYUZiMQ4w7m9tNEU-66YBzPQ%40mail.gmail.com.

--

You received this message because you are subscribed to the Google Groups "infra-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to infra-dev+unsubscribe@chromium.org.

To post to this group, send email to infr...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/CACi5S_1zOoEo6Ld11v2mXwHJX9a7%2BvuqDfqMq8WqNFWcybsB8w%40mail.gmail.com.

[Adam Rice]

Counterexample: the WHATWG streams standard repository has a linear history. Github supports this by allowing repositories to disable merge commits from the UI.

To unsubscribe from this group and stop receiving emails from it, send an email to infra-dev+unsubscribe@chromium.org.

To post to this group, send email to infr...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/CABdZ6yC-toQmwN2S-p4tujP6DsSGVaxu%3Dj5Vf7gLcOBTYwJKCQ%40mail.gmail.com.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAMGbLiFc4sAHwZ7FHzZNY8k6RrnimsMczArE%2Bk4NmUc5Jy0JXw%40mail.gmail.com.

--

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAEV-rjeaD%3D264e9-%3D8N720pqkmGqvbv8zvjQdmdv%2B3mSh5Jx%3DA%40mail.gmail.com.

[Colin Blundell]

Thanks, Dirk. This seems like a useful path forward. Thanks as well Aaron for the discussion so far.

For the record, my concerns are precisely what Michael presented below.

To unsubscribe from this group and stop receiving emails from it, send an email to infra-dev+...@chromium.org.

To post to this group, send email to infr...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/CABdZ6yC-toQmwN2S-p4tujP6DsSGVaxu%3Dj5Vf7gLcOBTYwJKCQ%40mail.gmail.com.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAH58R2dqQLBKv%2BsdiYgfDCRrD8yYUZiMQ4w7m9tNEU-66YBzPQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "infra-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to infra-dev+...@chromium.org.

To post to this group, send email to infr...@chromium.org.

[Julie Parent]

Thank you all.

For the sake of respecting the desire to end this thread, I'll keep the majority of my comments on the bug filed, but, I did want to make one thing clear: we, chrome ops team, hear you.  We will not be changing the default to use Gerrit until this issue is resolved.  Chromium behavior *is* different from most git users, but, there are thousands of you, and it is our jobs to make you productive and efficient at your jobs.  We'll address this in the best way possible (either hacking our tools around the dates, forging the dates, or working with Gerrit team to enable it deeper in the stack), even if it means sticking with Rietveld a while longer.

So, thank you for dealing with us as we rip your code review tool out from under you.  We really value all the feedback and patient dogfooding.

To unsubscribe from this group and stop receiving emails from it, send an email to infra-dev+unsubscribe@chromium.org.

To post to this group, send email to infr...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/CABdZ6yC-toQmwN2S-p4tujP6DsSGVaxu%3Dj5Vf7gLcOBTYwJKCQ%40mail.gmail.com.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAH58R2dqQLBKv%2BsdiYgfDCRrD8yYUZiMQ4w7m9tNEU-66YBzPQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "infra-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to infra-dev+unsubscribe@chromium.org.

To post to this group, send email to infr...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/CACi5S_1zOoEo6Ld11v2mXwHJX9a7%2BvuqDfqMq8WqNFWcybsB8w%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "infra-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to infra-dev+unsubscribe@chromium.org.

To post to this group, send email to infr...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/CAMGE5NHeo5xWa1MRJP58TFUdEU0ugwbWCM1i2WkY03r9Ha59bg%40mail.gmail.com.

[Aaron Gable]

As you may have seen, I just sent the PSA announcing that we'll be making Gerrit the default in just under two weeks. Since that announcement didn't address this issue specifically, I figured I'd drop in an update here too:

We're tracking the work to make the Author Dates match the Committer Dates here and here (sorry, internal link). A series of changes to make this possible are in flight here: one, two, three. The first two have already landed and will be deployed early next week. Once they're deployed, we can flip the config variable introduced in the first of those changes, and this issue should be resolved from then forward.

Thanks again,

Aaron

To unsubscribe from this group and stop receiving emails from it, send an email to infra-dev+...@chromium.org.

To post to this group, send email to infr...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/CABdZ6yC-toQmwN2S-p4tujP6DsSGVaxu%3Dj5Vf7gLcOBTYwJKCQ%40mail.gmail.com.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAH58R2dqQLBKv%2BsdiYgfDCRrD8yYUZiMQ4w7m9tNEU-66YBzPQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "infra-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to infra-dev+...@chromium.org.

To post to this group, send email to infr...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/CACi5S_1zOoEo6Ld11v2mXwHJX9a7%2BvuqDfqMq8WqNFWcybsB8w%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "infra-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to infra-dev+...@chromium.org.

To post to this group, send email to infr...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/CAMGE5NHeo5xWa1MRJP58TFUdEU0ugwbWCM1i2WkY03r9Ha59bg%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "infra-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to infra-dev+...@chromium.org.

To post to this group, send email to infr...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/CAPSmAAQuBC6kGwp%2BoDEhaS2LnvtxBzPN2RE64LBtXj7h1yr2RA%40mail.gmail.com.

[Colin Blundell]

Thanks for the update, and thanks for the work! Thanks to the Gerrit folks as well for how responsive they were to the needs of Chrome here given that this is pretty clearly a special-case ask from their POV.

[Aaron Gable]

One last update: the first commit with matching committer and author dates has landed.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/CAMGE5NHOoNTwU_apAoC%3Dr6ZvjB8hdvgegCY2TL84xEG_KY5cNw%40mail.gmail.com.

[Julie Parent]

A big thank you to Aaron and the team for getting this out the door a full week ahead of the migration date!  And of course, to our Dogfooders for voicing this concern and helping guide us to the best solution for everyone :)

To unsubscribe from this group and stop receiving emails from it, send an email to infra-dev+unsubscribe@chromium.org.

To post to this group, send email to infr...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/CABdZ6yC-toQmwN2S-p4tujP6DsSGVaxu%3Dj5Vf7gLcOBTYwJKCQ%40mail.gmail.com.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAH58R2dqQLBKv%2BsdiYgfDCRrD8yYUZiMQ4w7m9tNEU-66YBzPQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "infra-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to infra-dev+unsubscribe@chromium.org.

To post to this group, send email to infr...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/CACi5S_1zOoEo6Ld11v2mXwHJX9a7%2BvuqDfqMq8WqNFWcybsB8w%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "infra-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to infra-dev+unsubscribe@chromium.org.

To post to this group, send email to infr...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/CAMGE5NHeo5xWa1MRJP58TFUdEU0ugwbWCM1i2WkY03r9Ha59bg%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "infra-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to infra-dev+unsubscribe@chromium.org.

To post to this group, send email to infr...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/CAPSmAAQuBC6kGwp%2BoDEhaS2LnvtxBzPN2RE64LBtXj7h1yr2RA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "infra-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to infra-dev+unsubscribe@chromium.org.

To post to this group, send email to infr...@chromium.org.

[Lei Zhang]

Belated thanks for doing this.

I would like to do this for PDFium as well, but I haven't figured out
how. Looking at [1], I can't figure out where project.config is. If
you can mention how, then projects using Gerrit can turn this on for
themselves.

[1] https://chromium.googlesource.com/chromium/src/+/c414cefc

> https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAH58R2eqiAT4Zt-16A3Em3mJQKFqt8Wd3ovXKL3yLdb%2B%2BwPdow%40mail.gmail.com.

[Aaron Gable]

project.config is on the "refs/meta/config" ref, which only git administrators can modify. Please file a ticket to get the current git admin to enable the plugin for your repo.

[Marijn Kruisselbrink]

This does no longer seem to be working? For example https://chromium.googlesource.com/chromium/src/+/5af715b5e1ddba56932bfbdf59ccd42c692ec656 has an author date several weeks older than the commiter date.

On Thu, Jun 29, 2017 at 10:15 AM, Aaron Gable <aga...@chromium.org> wrote:

To unsubscribe from this group and stop receiving emails from it, send an email to infra-dev+unsubscribe@chromium.org.

To post to this group, send email to infr...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/CABdZ6yC-toQmwN2S-p4tujP6DsSGVaxu%3Dj5Vf7gLcOBTYwJKCQ%40mail.gmail.com.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAH58R2dqQLBKv%2BsdiYgfDCRrD8yYUZiMQ4w7m9tNEU-66YBzPQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "infra-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to infra-dev+unsubscribe@chromium.org.

To post to this group, send email to infr...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/CACi5S_1zOoEo6Ld11v2mXwHJX9a7%2BvuqDfqMq8WqNFWcybsB8w%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "infra-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to infra-dev+unsubscribe@chromium.org.

To post to this group, send email to infr...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/CAMGE5NHeo5xWa1MRJP58TFUdEU0ugwbWCM1i2WkY03r9Ha59bg%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "infra-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to infra-dev+unsubscribe@chromium.org.

To post to this group, send email to infr...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/CAPSmAAQuBC6kGwp%2BoDEhaS2LnvtxBzPN2RE64LBtXj7h1yr2RA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "infra-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to infra-dev+unsubscribe@chromium.org.

To post to this group, send email to infr...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/CAMGE5NHOoNTwU_apAoC%3Dr6ZvjB8hdvgegCY2TL84xEG_KY5cNw%40mail.gmail.com.

--

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAH58R2eqiAT4Zt-16A3Em3mJQKFqt8Wd3ovXKL3yLdb%2B%2BwPdow%40mail.gmail.com.

[Dirk Pranke]

Interesting. Can you please file a bug so we can track this there? It's possible something has regressed in Gerrit.

-- Dirk

[Lei Zhang]

PDFium Gerrit had the same problem. I filed https://crbug.com/800239
and it was quickly fixed.

>>>>>>>>>>>> it, send an email to infra-dev+...@chromium.org.

>>>>>>>>>>>> To post to this group, send email to infr...@chromium.org.
>>>>>>>>>>>>
>>>>>>>>>>>> To view this discussion on the web visit
>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/infra-dev/CABdZ6yC-toQmwN2S-p4tujP6DsSGVaxu%3Dj5Vf7gLcOBTYwJKCQ%40mail.gmail.com.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> --
>>>>>>>>>> Chromium Developers mailing list: chromi...@chromium.org
>>>>>>>>>> View archives, change email options, or unsubscribe:
>>>>>>>>>> http://groups.google.com/a/chromium.org/group/chromium-dev
>>>>>>>>>> ---
>>>>>>>>>> You received this message because you are subscribed to the Google
>>>>>>>>>> Groups "Chromium-dev" group.
>>>>>>>>>> To view this discussion on the web visit
>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAH58R2dqQLBKv%2BsdiYgfDCRrD8yYUZiMQ4w7m9tNEU-66YBzPQ%40mail.gmail.com.
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> You received this message because you are subscribed to the Google
>>>>>>>>> Groups "infra-dev" group.
>>>>>>>>> To unsubscribe from this group and stop receiving emails from it,

>>>>>>>>> send an email to infra-dev+...@chromium.org.

>>>>>>>>> To post to this group, send email to infr...@chromium.org.
>>>>>>>>>
>>>>>>>>> To view this discussion on the web visit
>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/infra-dev/CACi5S_1zOoEo6Ld11v2mXwHJX9a7%2BvuqDfqMq8WqNFWcybsB8w%40mail.gmail.com.
>>>>>>>>
>>>>>>>>
>>>>>>> --
>>>>>>> You received this message because you are subscribed to the Google
>>>>>>> Groups "infra-dev" group.
>>>>>>> To unsubscribe from this group and stop receiving emails from it,

>>>>>>> send an email to infra-dev+...@chromium.org.

>>>>>>> To post to this group, send email to infr...@chromium.org.
>>>>>>>
>>>>>>> To view this discussion on the web visit
>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/infra-dev/CAMGE5NHeo5xWa1MRJP58TFUdEU0ugwbWCM1i2WkY03r9Ha59bg%40mail.gmail.com.
>>>>>>
>>>>>>
>>>>>> --
>>>>>> You received this message because you are subscribed to the Google
>>>>>> Groups "infra-dev" group.
>>>>>> To unsubscribe from this group and stop receiving emails from it, send

>>>>>> an email to infra-dev+...@chromium.org.

>>>>>> To post to this group, send email to infr...@chromium.org.
>>>>>>
>>>>>> To view this discussion on the web visit
>>>>>> https://groups.google.com/a/chromium.org/d/msgid/infra-dev/CAPSmAAQuBC6kGwp%2BoDEhaS2LnvtxBzPN2RE64LBtXj7h1yr2RA%40mail.gmail.com.
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "infra-dev" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send

>>>> an email to infra-dev+...@chromium.org.

>>>> To post to this group, send email to infr...@chromium.org.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/a/chromium.org/d/msgid/infra-dev/CAMGE5NHOoNTwU_apAoC%3Dr6ZvjB8hdvgegCY2TL84xEG_KY5cNw%40mail.gmail.com.
>>>
>>> --
>>> --
>>> Chromium Developers mailing list: chromi...@chromium.org
>>> View archives, change email options, or unsubscribe:
>>> http://groups.google.com/a/chromium.org/group/chromium-dev
>>> ---
>>> You received this message because you are subscribed to the Google Groups
>>> "Chromium-dev" group.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAH58R2eqiAT4Zt-16A3Em3mJQKFqt8Wd3ovXKL3yLdb%2B%2BwPdow%40mail.gmail.com.
>>
>>
>

> --
> --
> Chromium Developers mailing list: chromi...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-dev
> ---
> You received this message because you are subscribed to the Google Groups
> "Chromium-dev" group.
> To view this discussion on the web visit

> https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAEoffTDbN2hNFiYjiAs36VWp-6J8BHYE3%2BkcAo_WTNPrKSnb5g%40mail.gmail.com.

[Colin Blundell]

Following the trail of Lei's bug, it looks like there was a regression in Gerrit that was fixed in https://gerrit-review.googlesource.com/c/gerrit/+/151435.