Ah I see. Your tag references "merged commit" but not "merge commit", former being implicit part of the latter when it comes to "git describe".

Printing HEAD for 2.066 shows this:

commit 2b795569cd892801050faec80054d91c1fb54d3c
Merge: d84aadd 601d478

As you may notice it mentions d84aadd (your v2.066-b3 tag commit) as on of merged parents.


May I ask what command sequence have you used to create the tag? Doing this locally result in proper HEAD tag for me:

git fetch upstream
git checkout 2.066
git tag testtag HEAD

On Mon, Jul 14, 2014 at 11:12:41AM +0200, Jacob Carlborg via Digitalmars-d wrote:
> On 13/07/14 17:00, H. S. Teoh via Digitalmars-d wrote:
> 
> >Yeah I always get annoyed by these security screening questions, especially when they don't let you write your own!!! They mostly involve trivia like relatives' names, dates and places, etc., that are far too easy to guess by a social engineering attacker. *My* favorite systems allow wording my own questions, which are along the lines of:
> >
> >	Q: Blue cheese?
> >	A: I got diarrhea.
> >
> >I.e., the question is completely nonsensical to anyone except me, and the answer has no obvious connection to the question without context that only I have.
> 
> They have at least some connection. Perhaps you get diarrhea from eating blue cheese ;)
[...]

Of course there is a connection. But not one that's obvious from the question, and not something you can guess without knowing exactly what the implied context is.

(And btw, the example I gave above is completely made up.)


T

-- 
Meat: euphemism for dead animal. -- Flora

On 7/14/14, 6:47 PM, Dicebot wrote:
> Ah I see. Your tag references "merged commit" but not "merge commit",
> former being implicit part of the latter when it comes to "git describe".
>
> Printing HEAD for 2.066 shows this:
>
> commit 2b795569cd892801050faec80054d91c1fb54d3c
> Merge: d84aadd 601d478
>
> As you may notice it mentions d84aadd (your v2.066-b3 tag commit) as on
> of merged parents.
>
>
> May I ask what command sequence have you used to create the tag? Doing
> this locally result in proper HEAD tag for me:
>
> git fetch upstream
> git checkout 2.066
> git tag testtag HEAD

cd dmd
git checkout 2.066
git tag -m git tag -m v2.066.0-b3 2.066
git push upstream v2.066.0-b3

http://wiki.dlang.org/Simplified_Release_Process_Proposal#Releases

On 7/14/14, 11:12 PM, Andrew Edwards wrote:
> On 7/14/14, 6:47 PM, Dicebot wrote:
>> Ah I see. Your tag references "merged commit" but not "merge commit",
>> former being implicit part of the latter when it comes to "git describe".
>>
>> Printing HEAD for 2.066 shows this:
>>
>> commit 2b795569cd892801050faec80054d91c1fb54d3c
>> Merge: d84aadd 601d478
>>
>> As you may notice it mentions d84aadd (your v2.066-b3 tag commit) as on
>> of merged parents.
>>
>>
>> May I ask what command sequence have you used to create the tag? Doing
>> this locally result in proper HEAD tag for me:
>>
>> git fetch upstream
>> git checkout 2.066
>> git tag testtag HEAD
>

This process used is described here:

> http://wiki.dlang.org/Simplified_Release_Process_Proposal#Releases

cd dmd
git checkout 2.066
git tag -m v2.066.0-b3 v2.066.0-b3 2.066
git push upstream v2.066.0-b3

On Monday, 14 July 2014 at 14:12:37 UTC, Andrew Edwards wrote:
> cd dmd
> git checkout 2.066
> git tag -m git tag -m v2.066.0-b3 2.066
> git push upstream v2.066.0-b3
>
> http://wiki.dlang.org/Simplified_Release_Process_Proposal#Releases

It has worked correctly for me (resulted in 2b795569 tagged). Can it be a bug in your git version? I have 2.0.1 installed.

On 7/15/14, 12:50 AM, Dicebot wrote:
> On Monday, 14 July 2014 at 14:12:37 UTC, Andrew Edwards wrote:
>> cd dmd
>> git checkout 2.066
>> git tag -m git tag -m v2.066.0-b3 2.066
>> git push upstream v2.066.0-b3
>>
>> http://wiki.dlang.org/Simplified_Release_Process_Proposal#Releases
>
> It has worked correctly for me (resulted in 2b795569 tagged). Can it be
> a bug in your git version? I have 2.0.1 installed.


This is what I see:

---------------------------------------
Andrews-Mac-mini:dmd ace$ git show HEAD
commit 2b795569cd892801050faec80054d91c1fb54d3c
Merge: d84aadd 601d478
Author: AndrewEdwards <edwards.ac@gmail.com>
Date:   Sat Jul 12 00:15:06 2014 +0900

    Merge pull request #3744 from 9rnsr/2.066
    Cherry-picking commits from master to 2.066 branch (for beta3)

----------------------------------------------
Andrews-Mac-mini:dmd ace$ git show v2.066.0-b3
tag v2.066.0-b3
Tagger: AndrewEdwards <edwards.ac@gmail.com>
Date:   Sun Jul 13 23:36:14 2014 +0900

v2.066.0-b3

commit 2b795569cd892801050faec80054d91c1fb54d3c
Merge: d84aadd 601d478
Author: AndrewEdwards <edwards.ac@gmail.com>
Date:   Sat Jul 12 00:15:06 2014 +0900

    Merge pull request #3744 from 9rnsr/2.066
    Cherry-picking commits from master to 2.066 branch (for beta3)
----------------------------------------------

Is this not saying that both the tag and HEAD are pointing to the same commit?

Yes, currently tags are OK in dmd repo:
https://github.com/D-Programming-Language/dmd/commits/2.066
https://github.com/D-Programming-Language/dmd/commits/v2.066.0-b3

..it was different at point Kenji had written his message. Have you pushed new ones recently?

On 7/15/14, 7:11 AM, Dicebot wrote:
> Yes, currently tags are OK in dmd repo:
> https://github.com/D-Programming-Language/dmd/commits/2.066
> https://github.com/D-Programming-Language/dmd/commits/v2.066.0-b3
>
> ..it was different at point Kenji had written his message. Have you
> pushed new ones recently?

After posting my original message, I removed all references to v2.066.0-b3 and v2.066.0-b2 and re-added...

I just realized the cause of this problem. In efforts to avoid pollution of master, I created the tags on my local clones of my own forks at github.com/AndrewEdwards. I then pushed those tags to to the forks and attempted to create pull requests for them... It could not be done. After clarifying with David Nadlinger, I went ahead and push the tags from local to master and that caused the problem.

My later recreated tags were done on a direct clone from master.

Since that seems to have solved corrected the issue, I'll forgo the RC and continue producing betas. Either way, we have a number of regressions outstanding, which by the current defined measures calls for extension of the review period.

B4 is forthcoming.

On 7/15/14, 8:50 AM, Andrew Edwards wrote:
>
> After clarifying with David Nadlinger, I went ahead and push the tags
> from local to master and that caused the problem.
>

Not in any way suggesting that this was David's fault, just that I didn't create the tags in a direct clone, instead I created them on a fork and then generated a pull request for the changes to be included in the release. This ended up being two different commits back in master.