Page MenuHomePhabricator

Add git commit date for core and extensions to Special:Version
Closed, ResolvedPublic

Description

Author: dasch

Description:
It would be nice, if the date of the last commit of the extension shown on Special:Version could be displayed.
With SVN I could look at the revision number, to check if I have to look for updates. With git this doesn't work. So it would be helpful to see how long an Extension was not updated.


Version: 1.21.x
Severity: enhancement

Details

Reference
bz38783

Event Timeline

bzimport raised the priority of this task from to Normal.Nov 22 2014, 1:07 AM
bzimport set Reference to bz38783.
bzimport added a subscriber: Unknown Object (MLST).

dasch wrote:

Patch is there
No Review since 7 Weeks
WONTFIX!?

A new patch, Ib66be27a, is still under review. There doesn't seem to be any fundamental reason not to do this, the patch just needs some tweaking (apparently,y the date format isn't localized or something).

I for one would live to see this implemented.

taste1at wrote:

@DaSch:

You write

date("d.m.Y H:i",$rawdate);

This is a german date format.

The localized date format is available using

$wgLang->date( ) and $wgLang->time( )

and others, where $wgLang is a global variable storing an instance of the Language class (can be found in /language/Language.php).

Btw, I suggest not to do the formatting in the GitInfo class. This class should return a MediaWiki-timestamp obtained by

date( 'YmdHis', $lastlinearray[4] );

In the class SpecialVersion, you can use $wgLang for formatting. (I'm not sure if the global variable is still to be used but in SpecialVersion lots of them are still around...)

dasch wrote:

Okay, I'm out. That's to complicated for me. Gerrit also does not move. I close this, seams I have to live without this.

Somebody else could still give this a try - reopening.

Could you use YYYY-MM-DD ISO 8601 format instead?

This will help a lot to avoid misunderstanding with a unique date format during debug.

  • Bug 43354 has been marked as a duplicate of this bug. ***

In the bug 43354, we wanted the Special:Version format:

Method | Git revision and date | Description | Authors


Example of the 4 columns content:

ParserFunctions (Version 1.4.1)

(8d2534b)
2012-12-22

Enhance parser with logical functions

Tim Starling, Robert Rohde, Ross McClure and Juraj Simlovic


As explained in comment 7, I strongly insist for a ISO 8601 date. This is a vital debug information, not something to localize, especially with a risk of day/month confusion.

Is someone working on that? I really wish to see the ISO-8601 commit _dates_ close to the version hashes.

It seems this should be done in two ways:

(1) ExtensionDistributor. Add a an information file with hash and date.

To get the date:
git show --format="%ci" HEAD | head -n1 | cut -f1 -d ' '

To get the hash (if this is needed, I think the case is well covered by our current class):
git rev-parse HEAD


(2) If this file is absent and a .git folder is present. The extension has probabably been fetched by a git clone repository. Test we can execute git on the system and get the date.

[Please don't reset the version field to "unspecified".]

Tom: Do you plan to work on this, or why did you set the Target Milestone?

dasch wrote:

There was a patch
There was a gerrit commit
But nobody took care of approving
So I think nobody really is interested in this

Ah thanks! Adding "patch-in-gerrit" keyword...

https://gerrit.wikimedia.org/r/#/c/17333/ is the latest version of the patch which was abandoned.

(In reply to comment #13)

There was a patch
There was a gerrit commit
But nobody took care of approving
So I think nobody really is interested in this

As I said to you end December, T. Gries and me are interested in this.


As I indicated in the Ib66be27a review in December, I've tested your patch and it doesn't work as intended.

First, the logs/HEAD file contains other operations than commits. There would have been a need to filter to only process "commit" lines.

But there is a bigger issue: the patch currently reads the .git/logs/HEAD file. This won't always contain the information we want.

It contains the operation you did to the git repository (e.g. clone, checkout).

It will only contain the date of the last commit when committed locally.

dasch wrote:

4 month after the commit and some days after I said that I'm out of this
by the way I'm not going to ever commit anything to gerrit because this is way to complicated to me and I have no idea of how it works

(In reply to comment #18)

4 month after the commit and some days after I said that I'm out of this
by the way I'm not going to ever commit anything to gerrit because this is
way to complicated to me and I have no idea of how it works

DaSch:
When was the last time you took a look at Gerrit and its documentation at http://www.mediawiki.org/wiki/Gerrit ? Could you elaborate on what's complicated? Your feedback is very welcome to make things easier for you to contribute. Thank you in advance!

dasch wrote:

The documentation is for working with command line and I'm working with Eclipse, Aptana and Egit. So the Documentation is worthless and the functions and workflows described there are not available there!

Qgil added a comment.Jan 28 2013, 4:20 PM

(pressed Save Changes too soon, sorry)

PS: learning how to deal properly with git and code review from your IDE is useful not only for MediaWiki development but also for many other software projects. The first time might be annoying but after that going through the process is trivial.

If you still want to give it a go there is always people happy to help at MediaWiki-General IRC or wikitech-l mailing list.
https://www.mediawiki.org/wiki/Communication

Thank you for your interest in improving MediaWiki software!

dasch wrote:

I make my extensions simple and my own way at github and mediawiki is the only project I contribute a little bit and that's only a bit hacking and Copy Paste Programming because I don't have any experience with PHP only because I have to do it in PHP for mediawiki because I hate PHP.

Note: As this has the 1.21.0 target milestone set (by Nemo), somebody would have to pick up the patch and rework it. If this does not happen in the next weeks, the Target Milestone will get removed.

dasch wrote:

I bet on nobody picking it up!

I am working on that now, rebased and made it working (with core / master ).

see screenshot http://i.imgur.com/d9VC08W.png

https://gerrit.wikimedia.org/r/#/c/54902/

A screenshot of Special:Version page with this patch is available http://i.imgur.com/d9VC08W.png

and is deployed to
http://openid-wiki.instance-proxy.wmflabs.org/wiki/Special:Version

where it can be seen in action.

Related URL: https://gerrit.wikimedia.org/r/54902 (Gerrit Patch-Set: Ia31a747c0d79f460503f66c369a0d1f2b971b692/5)

https://gerrit.wikimedia.org/r/54902 (Gerrit Change Ia31a747c0d79f460503f66c369a0d1f2b971b692) | Code-Review: Reviewed:+1 Patch Set 5: Code-Review+1 [by Wikinaut]

https://gerrit.wikimedia.org/r/54902 (Gerrit Change Ia31a747c0d79f460503f66c369a0d1f2b971b692) | Patch Set 5:

A screenshot of Special:Version page with this patch is available http://i.imgur.com/d9VC08W.png

and is deployed to http://openid-wiki.instance-proxy.wmflabs.org/wiki/Special:Version

where it can be seen in action. [by Wikinaut]

https://gerrit.wikimedia.org/r/54902 (Gerrit Change Ia31a747c0d79f460503f66c369a0d1f2b971b692) | Code-Review: Reviewed:-1 Patch Set 5: Code-Review-1

(1 comment) [by Catrope]

https://gerrit.wikimedia.org/r/54902 (Gerrit Change Ia31a747c0d79f460503f66c369a0d1f2b971b692) | Patch Set 5:

(1 comment)

@DaSch: Catrope asked, why you removed return self::getwgVersionLinked() . " $shortSHA1";

Can you explain ?

I also set to -1 because I want again to check the dates. [by Wikinaut]

https://gerrit.wikimedia.org/r/54902 (Gerrit Change Ia31a747c0d79f460503f66c369a0d1f2b971b692) | Code-Review: Reviewed:-1 Patch Set 5: Code-Review-1 [by Wikinaut]

https://gerrit.wikimedia.org/r/54902 (Gerrit Change Ia31a747c0d79f460503f66c369a0d1f2b971b692) | Patch Set 5:

(1 comment) [by Wikinaut]

Related URL: https://gerrit.wikimedia.org/r/54902 (Gerrit Patch-Set: Ia31a747c0d79f460503f66c369a0d1f2b971b692/6)

Related URL: https://gerrit.wikimedia.org/r/54902 (Gerrit Patch-Set: Ia31a747c0d79f460503f66c369a0d1f2b971b692/7)

dasch wrote:

(In reply to comment #33)

https://gerrit.wikimedia.org/r/54902 (Gerrit Change
Ia31a747c0d79f460503f66c369a0d1f2b971b692) | Patch Set 5:
(1 comment)
@DaSch: Catrope asked, why you removed return self::getwgVersionLinked() . "
$shortSHA1";
Can you explain ?
I also set to -1 because I want again to check the dates. [by Wikinaut]

That's not from my patch!

It can't be found here
https://gerrit.wikimedia.org/r/#/c/16904/
nor here
https://gerrit.wikimedia.org/r/#/c/17333/

https://gerrit.wikimedia.org/r/54902 (Gerrit Change Ia31a747c0d79f460503f66c369a0d1f2b971b692) | Code-Review: Reviewed:-1 Patch Set 7: Code-Review-1

The following comment by Dereckson is important:
https://bugzilla.wikimedia.org/show_bug.cgi?id=38783#c17

  • I hereby withdraw (abandon) that patch set, because it indeed does not work as intended, Well, it shows a date, but not necessarily the commit date, or edit date. ***

Dereckson wrote:

As I indicated in the Ib66be27a review in December, I've tested your patch and
it doesn't work as intended.

First, the logs/HEAD file contains other operations than commits. There would
have been a need to filter to only process "commit" lines.

But there is a bigger issue: the patch currently reads the .git/logs/HEAD file.
This won't always contain the information we want.

It contains the operation you did to the git repository (e.g. clone, checkout).

It will only contain the date of the last commit when committed locally. [by Wikinaut]

https://gerrit.wikimedia.org/r/54902 (Gerrit Change Ia31a747c0d79f460503f66c369a0d1f2b971b692) | change ABANDONED [by Wikinaut]

Related URL: https://gerrit.wikimedia.org/r/54986 (Gerrit Patch-Set: I0931400ecacf91ed2ab4fc7aa46dceac17661768/1)

Related URL: https://gerrit.wikimedia.org/r/54986 (Gerrit Patch-Set: I0931400ecacf91ed2ab4fc7aa46dceac17661768/2)

Related URL: https://gerrit.wikimedia.org/r/54986 (Gerrit Patch-Set: I0931400ecacf91ed2ab4fc7aa46dceac17661768/3)

dasch wrote:

what Dereckson want's is only possible by connecting to remote within the PHP Skript

git information in .git only have local changes.

The information from logs/HEAD contains the last git operation. And that is exactly what is needed. But only there I see how long I didn't check for an update. Because when I take the date from the commit I always think that I have to pull for new updates just because there where no changes for a long time!

(In reply to comment #46)

what Dereckson want's is only possible by connecting to remote within the PHP
Skript
git information in .git only have local changes.

I think, you are right -- this is, what I also think is needed (fetching the dates from the remote).

So in summary, the present solution is the best possible local solution.

Url will be added, when the (draft) patch is published.

The information from logs/HEAD contains the last git operation. And that is
exactly what is needed. But only there I see how long I didn't check for an
update. Because when I take the date from the commit I always think that I
have
to pull for new updates just because there where no changes for a long time!

Related URL: https://gerrit.wikimedia.org/r/54986 (Gerrit Patch-Set: I0931400ecacf91ed2ab4fc7aa46dceac17661768/4)

Related URL: https://gerrit.wikimedia.org/r/54986 (Gerrit Patch-Set: I0931400ecacf91ed2ab4fc7aa46dceac17661768/5)

Related URL: https://gerrit.wikimedia.org/r/54986 (Gerrit Patch-Set: I0931400ecacf91ed2ab4fc7aa46dceac17661768/6)

Related URL: https://gerrit.wikimedia.org/r/54986 (Gerrit Patch-Set: I0931400ecacf91ed2ab4fc7aa46dceac17661768/7)

Related URL: https://gerrit.wikimedia.org/r/54986 (Gerrit Patch-Set: I0931400ecacf91ed2ab4fc7aa46dceac17661768/8)

Related URL: https://gerrit.wikimedia.org/r/54986 (Gerrit Patch-Set: I0931400ecacf91ed2ab4fc7aa46dceac17661768/9)

(In reply to comment #46)

what Dereckson want's is only possible by connecting to remote within the PHP
Skript
git information in .git only have local changes.

Commit dates are stored as part of the commit objects, so they are available locally. However, commit objects can be (and often are) part of packfiles, so reading them is not easy (unless of course you shell out to git).

A working version is now available in
https://gerrit.wikimedia.org/r/#/c/54986/

Screenshot http://i.imgur.com/z3RvMiB.png shows, how the Special:Version page looks when the patch is applied.

It has to * shell out * and makes use of the "git show" command to let git do the work to fetch and format author and commit dates. Any other solution is PITA, I investigated different alternatives and all of them are even worse.

(In reply to comment #7)

Could you use YYYY-MM-DD ISO 8601 format instead?
This will help a lot to avoid misunderstanding with a unique date format
during
debug.

(In reply to comment #9)

As explained in comment 7, I strongly insist for a ISO 8601 date. This is a
vital debug information, not something to localize, especially with a risk of
day/month confusion.

We localize dates everywhere by the user's preference. RC, contribs, histories, etc... even our old code review system uses localized dates.

Dates are localized according to the user's choice, they should know how to read it. In fact none of the date preference options we give are ambiguous. And if YOU don't like seeing localized dates you can set your preferences to show ISO dates.

Is there any real reason not to localize the date as our standard is?

(In reply to comment #56)

(In reply to comment #7)

Dates are localized according to the user's choice, they should know how to

read it. In fact none of the date preference options we give are ambiguous.
And
if YOU don't like seeing localized dates you can set your preferences to show
ISO dates.
Is there any real reason not to localize the date as our standard is?

Daniel, please simply change the two lines in SpecialVersion.php as you like to have it --- I want to finish this story, successfully and soon. Pls.

patch available https://gerrit.wikimedia.org/r/#/c/54986/ . pls. can someone review and commit?

T. Gries: Why did you bomp the Target Milestone from 1.21 to 1.22?

(In reply to comment #59)

T. Gries: Why did you bomp the Target Milestone from 1.21 to 1.22?

André: because I thought that the 1.21 train was already gone... (reset to 1.21 milestone). Perhaps you can help to get this in, thanks.

(In reply to comment #59)

T. Gries: Why did you bomp the Target Milestone from 1.21 to 1.22?

@André:

because this bug is - apparently currently - not part of https://www.mediawiki.org/wiki/Release_notes/1.21 !

Of course - 1.21 is not even released, so release notes are work in progress. :)

(In reply to comment #62)

Of course - 1.21 is not even released, so release notes are work in progress.
:)

ok,. did not know, and added it now https://www.mediawiki.org/w/index.php?title=Release_notes%2F1.21&diff=671485&oldid=667144

T. Gries: Errm, but the patch is not merged, so it's NOT part of 1.21 yet, and IMO it should not be part of the release notes yet either.

(In reply to comment #64)

T. Gries: Errm, but the patch is not merged, so it's NOT part of 1.21 yet,
and
IMO it should not be part of the release notes yet either.

merge it

current code is live on http://openid-wiki.instance-proxy.wmflabs.org/wiki/Special:Version

@PleaseStand: See your comment to patch set 31 https://gerrit.wikimedia.org/r/#/c/54986/31/includes/GitInfo.php in Line 131

The present commit implements your proposal to have $wgGitBin as DefaultSetting parameter, which prevents multiple exec failures in Special:Versions when this command is not available. Thanks for pointing me to this.

I realize this commit has already been merged in, but it would be really nice if this information were also exposed in the API call for extensions

api.php?action=query&meta=siteinfo&siprop=extensions

This is indeed a good idea.

I opened a new feature request on bug 48418.