Fix dev release time

I've got a workaround for the former and a solution for the latter problem. It works quiet nicely so far on my website.

The code is here: http://git.pfeifer.ch/git_deploy.git/log/refs/heads/1254200-fix

The 2 commits are based on 6.x-1.x (176ccec) and can be applied with git like that:
git pull http://git.pfeifer.ch/git_deploy.git 1254200-fix

Applying the commits on master and 7.x-1.x works as well, with cherry-pick - just 1 minor conflict each.

As mentioned in the commit message, the proper solution to the former problem, IMHO, would be to include
the commit sha1 in the release history xml output (e.g. introduce a project/releases/scm/commit/sha1 node in http://updates.drupal.org/release-history/git_deploy/6.x)

EDIT (Fri Aug 26 11:09:29 UTC 2011):
fixed the function _git_deploy_find_remote():
- init $remote_refs outside loop
- adjust coding style

The repository for the fix no longer exists. To bad it wasn’t provided as a patch. Does anyone have a copy?

Decided not to wait.

Updated patch to pick the dev branch with the fewest differences when the local branch does not have a Drupal-formatted name and there is more than one possible matching dev branch.

Improved detection of whether we are on a dev release.

The existing logic was so prone to bugs that I did a complete rewrite.

@Darren Oh

The existing logic was so prone to bugs that I did a complete rewrite.

Will the same approach work in D7 ?

complete rewrite

Does this warrant a new major version of the module?

When I said complete rewrite, I meant to explain why I did not provide an interdiff for the patch. The patch is a bug cleanup, so I don’t think it warrants a new major version. It can be ported to Drupal 7.

Cleaned up the patch.

1. Removed unneeded lines.
2. Suppressed Git errors on the command line.
3. Select correct version when last common commit has multiple tags.
4. Improved performance by only overriding status of dev projects if original status is not current or not secure.

Removed unreliable code for detecting .git folder.

Modified last patch so it is not necessary to change directories to run Git.

Made patch slightly more efficient.

I was directed to this issue from #3104890: Undefined index: version in git_deploy_system_info_alter() line 103 because apparently this problem will be fixed here. This issue was started in 2011 and Darren Oh has done a great job in picking it up after an 8 year delay. Patches #3, #4 and #5 no longer apply. Patch #6 and onwards can be applied. Using patch #13 this is actually a complete re-write of the module, as there is not a single executable line in .module which is not altered. As this was started so long ago, just wanted to check that the issue title is still appropriate? I think the patch is doing a lot more than just "Fix the dev release time"?

I have manually tested this with a variety of Cores and contrib modules:

Core tagged release 8.7.11 - shows core correctly

Core 8.8.x git clone - shows as 8.8.x-dev (2020-Jan-01) which is correct according to git log. Still shows as this date when on a checked-out local branch with a later commit.

Core 8.9.x git clone - shows as 8.9.x-dev (2020-Jan-04) which is also correct.

Contrib modules
e.g. Scheduler 8.x-1.x-dev (2020-Jan-02)
On branch 8.x-1.1 with latest dev commits. This date is correct for the latest commit. Check out local branch, make newer commit, and the date remains as above (which is the intention, as per the issue summary).

So all appears OK so far. However, as there are no 'steps to reproduce' from the original posting I have not been able to prove that this re-write makes exactly the changes it was designed to do. Without the patch, we still get the correct dates showing for the Core dev versions and Contrib local branches.

Hopefully that helps. It would be nice to get rid of the current problem "Undefined index: version in git_deploy_system_info_alter() line 103".

Jonathan

I have added steps to reproduce the issue.

Thanks. I will follow that through.

Also I was wrong in my comment in #14 where I said that without the patch the dates and times still show correctly. Without the patch, on a core local branch it totally fails to recognise any core version, and we get Not supported! Error. Drupal core Unknown. So this patch is definitely an improvement over that.

Looking up the core version number is unnecessary and causes errors now that info files only include the core key if they are compatible with Drupal versions before 8.7.7.

Repeating my tests on patch #17 and all seems good.

Core

8.7.6 and 8.7.10 both show Recommended version: 8.8.1 (2019-Dec-18) Security update: 8.7.11
8.7.11 shows 8.7.11 ok
8.7.x shows 8.7.x-dev (2019-Dec-19) This matches my git log latest date.
8.8.x shows 8.8.x-dev (2020-Jan-20) Up to date.
8.9.x shows 8.9.x-dev (2020-Jan-04) Development version: 8.9.x-dev (2020-Jan-17)
This is correct as 4 Jan is where my 8.9 branch is at.

Contrib

Rules on 8.x-3.x branch gives 8.x-3.x-dev (2020-Jan-20) Recommended version: 8.x-3.0-alpha5 (2019-Aug-19)
This matches the latest commit on the git log.

Rules on an old out-of-date local branch gives 8.x-3.x-dev (2020-Jan-15)
Recommended version: 8.x-3.0-alpha5 (2019-Aug-19) Development version: 8.x-3.x-dev (2020-Jan-20)
15 Jan is the latest commit in this branch common with 8.x-3.x, even though there are newer local ones.

Scheduler on main branch has 8.x-1.x-dev (2020-Jan-10) which is correct
On local branch that is behind, 8.x-1.x-dev (2020-Jan-02) Recommended version:8.x-1.1 (2019-Aug-23) Development version: 8.x-1.x-dev (2020-Jan-10)
After merge with 8.x-1.x, local branch shows as green with 'Up to date'

Both of the other recent issues I have raised #3104890: Undefined index: version in git_deploy_system_info_alter() line 103 and #3105132: Cater for core_version_requirement are fixed by this, so I am tempted to mark this RTBC.

However there is one slight regression in functionality which I want to check that Darren-Oh is aware of. On the existing Git Deploy, for dev branches we had an indication of which was the latest tag and how many commits have been done since

But with the new patch, we only see that it is on the -dev branch with no other info

This may be acceptable, but I want to make sure it is noted here.

Other than that, this is working and RTBC. So I'd be happy for this to be committed now, then that final item can be discussed on a separate issue.

I am aware that the dev branch format is different. The latest tag with number of commits since was inaccurate for users who had local commits. The format produced by the patch matches what you would get if you downloaded and installed the dev package from Drupal. I believe the intended behavior of Git Deploy is to provide the information that is added to the downloads by the Drupal packaging scripts.