I should be posting this in dmd-beta but instead I'm posting it here because I am currently locked out of my gmail account, the recovery account for which is yahoo and I'm locked out of that too.

Google doesn't trust me because I moved out of the country and then went on a trip... and Yahoo doesn't trust for the same reasons. Problem is, I created my recovery questions for yahoo back in 2008 and the first time they ever ask me for it was back in April of this year. It's so simple I cannot remember it: "What is your son's name?" and "Where did you meet your wife?". Try as I amy I cannot figure out where I met her or whether we ever had a son together. What a second, do I even have a wife?

End result, my GMail is locked until 17 July, while my Yahoo account is locked for 12 hours. Damn! Grrrr! Ahhhhhhhhhhh!

Sorry about that... That's definitely not the purpose of this post.

I had some issues keeping things straight in my head about which repo I visited, which branch I checkout and which ones I tagged. So I decided to automate the process. Starting with v2.066.0-b3 every repo gets tagged correctly and the tag gets pushed automatically to master. I'm in nirvana. No more forgetting to tag things or tagging them in the wrong places.

The problem? I screwed up the v2.066.0-b1 tags by placing them in master instead of the 2.066 branch. So when I build the binaries from v2.066.0-b3, it's ignoring changes in the branch.

To make matters worse, after visiting both branch and master for all repos, everyone exhibited the same problem with the exception of tools. Tools did not have the v2.066.0-b3 tag and showed the same tag in both master and the branch. I tried removing the tag from master to match the rest of the repos but that did not work, it simply removed all references to the tag.

The only way I know to fix this is to remove all the v2.066 tags and just start over with v2.066.b3.

Some advice would really be appreciated.

Regards,
Andrew

On 7/12/2014 5:27 PM, Andrew Edwards wrote:
> Some advice would really be appreciated.

I share your pain. Others here have rescued my github apocalyptic screwups several times.

Am Sun, 13 Jul 2014 00:27:53 +0000
schrieb "Andrew Edwards" <ridimz@yahoo.com>:


> I had some issues keeping things straight in my head about which repo I visited, which branch I checkout and which ones I tagged. So I decided to automate the process. Starting with v2.066.0-b3 every repo gets tagged correctly and the tag gets pushed automatically to master. I'm in nirvana. No more forgetting to tag things or tagging them in the wrong places.
> 
> The problem? I screwed up the v2.066.0-b1 tags by placing them in master instead of the 2.066 branch. So when I build the binaries from v2.066.0-b3, it's ignoring changes in the branch.

Then delete the v2.066.0-b1 tag and recreate it, as explained below. (You'll have to know the commit sha1 that's actually used to build v2.066.0-b1)

> 
> To make matters worse, after visiting both branch and master for all repos, everyone exhibited the same problem with the exception of tools. Tools did not have the v2.066.0-b3 tag and showed the same tag in both master and the branch. I tried removing the tag from master to match the rest of the repos but that did not work, it simply removed all references to the tag.

?
tags are not _on_ branches. if you tag a commit which is in multiple
branches then it might seem like you have a tag on multiple branches,
but you can only tag commits. That's a crucial point, you never tag
branches, or commits _on_ branches, you can only tag commits!

> 
> The only way I know to fix this is to remove all the v2.066 tags and just start over with v2.066.b3.
> 
> Some advice would really be appreciated.
> 
> Regards,
> Andrew

The correct way to state this: Git tags are placed on commits, not on branches.

I'd explain it like this, but note that it's a little more complicated in reality, commits do not really 'belong' to branches:

If you want to make sure a tag 'is on a certain branch' you
have to tag a commit that 'is only in that branch', usually a merge
commit. http://stackoverflow.com/questions/14613540/git-tag-in-branches

As you guys use cherry-picking cherry picked commits get a different commit hash in different branches anyway and you should be able to tag these sha1 hashes.

(if you just use git tag without further parameters it defaults to the current branch head, which always belongs to one branch. )

If you know the commit sha1s used for the betas you can always delete &
recreate _all_ tags.
http://git-scm.com/book/en/Git-Basics-Tagging
(See 'Tagging later')

More links: http://stackoverflow.com/questions/5480258/how-to-delete-a-remote-git-tag http://stackoverflow.com/a/1457536/471401 http://stackoverflow.com/a/1863224/471401

On Sunday, 13 July 2014 at 00:27:54 UTC, Andrew Edwards wrote:
> Google doesn't trust me because I moved out of the country and then went on a trip... and Yahoo doesn't trust for the same reasons. Problem is, I created my recovery questions for yahoo back in 2008 and the first time they ever ask me for it was back in April of this year. It's so simple I cannot remember it: "What is your son's name?" and "Where did you meet your wife?". Try as I amy I cannot figure out where I met her or whether we ever had a son together. What a second, do I even have a wife?

I believe using real information for this questions is security threat. There's piece of conversation on bash that shows it:
A: Listen, may be we're relatives?
B: You think???
A: May be distant... What was the maiden name of your mother?
B: *encho
A: Oh, you have 8 new emails.

> To make matters worse, after visiting both branch and master for all repos, everyone exhibited the same problem with the exception of tools. Tools did not have the v2.066.0-b3 tag and showed the same tag in both master and the branch. I tried removing the tag from master to match the rest of the repos but that did not work, it simply removed all references to the tag.

Actually, branches and tags are simple references. As I see in tools `master` and `2.066` points at single commit. So, new tag was pointing at that same commit.

> Some advice would really be appreciated.

Read Pro Git book: http://www.git-scm.com/book

On 13/07/14 12:24, sigod via Digitalmars-d wrote:
> I believe using real information for this questions is security threat. There's
> piece of conversation on bash that shows it:
> A: Listen, may be we're relatives?
> B: You think???
> A: May be distant... What was the maiden name of your mother?
> B: *encho
> A: Oh, you have 8 new emails.

I think that what worries me more is that people should try and build security techniques on the assumption of such outdated social/gender norms .... :-)

On Sun, Jul 13, 2014 at 10:24:10AM +0000, sigod via Digitalmars-d wrote:
> On Sunday, 13 July 2014 at 00:27:54 UTC, Andrew Edwards wrote:
> >Google doesn't trust me because I moved out of the country and then went on a trip... and Yahoo doesn't trust for the same reasons. Problem is, I created my recovery questions for yahoo back in 2008 and the first time they ever ask me for it was back in April of this year. It's so simple I cannot remember it: "What is your son's name?" and "Where did you meet your wife?". Try as I amy I cannot figure out where I met her or whether we ever had a son together. What a second, do I even have a wife?
> 
> I believe using real information for this questions is security
> threat.  There's piece of conversation on bash that shows it:
> A: Listen, may be we're relatives?
> B: You think???
> A: May be distant... What was the maiden name of your mother?
> B: *encho
> A: Oh, you have 8 new emails.
[...]

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.


T

-- 
Recently, our IT department hired a bug-fix engineer. He used to work for Volkswagen.

On Sunday, 13 July 2014 at 10:06:37 UTC, Johannes Pfau wrote:
> Am Sun, 13 Jul 2014 00:27:53 +0000
> schrieb "Andrew Edwards" <ridimz@yahoo.com>:
>
>
>> I had some issues keeping things straight in my head about which repo I visited, which branch I checkout and which ones I tagged. So I decided to automate the process. Starting with v2.066.0-b3 every repo gets tagged correctly and the tag gets pushed automatically to master. I'm in nirvana. No more forgetting to tag things or tagging them in the wrong places.
>> 
>> The problem? I screwed up the v2.066.0-b1 tags by placing them in master instead of the 2.066 branch. So when I build the binaries from v2.066.0-b3, it's ignoring changes in the branch.
>
> Then delete the v2.066.0-b1 tag and recreate it, as explained below.
> (You'll have to know the commit sha1 that's actually used to build
> v2.066.0-b1)
>
>> 
>> To make matters worse, after visiting both branch and master for all repos, everyone exhibited the same problem with the exception of tools. Tools did not have the v2.066.0-b3 tag and showed the same tag in both master and the branch. I tried removing the tag from master to match the rest of the repos but that did not work, it simply removed all references to the tag.
>
> ?
> tags are not _on_ branches. if you tag a commit which is in multiple
> branches then it might seem like you have a tag on multiple branches,
> but you can only tag commits. That's a crucial point, you never tag
> branches, or commits _on_ branches, you can only tag commits!

Completely, understand. Since I do not provide a commit hash, and since I'm tagging from the branch, whatever is at the head of the branch is the commit that gets tagged. Here is my problem, after removing v2.066.0-b3 and v2.066.0-b2, if I run "git describe --tag", I get the following:

     dmd
     Switched to branch 'master'
     Your branch is up-to-date with 'origin/master'.
     v2.066.0-b1-74-g8f3af62
     Switched to branch '2.066'
     Your branch is up-to-date with 'origin/2.066'.
     v2.066.0-b1-29-g2b79556

     druntime
     Switched to branch 'master'
     Your branch is up-to-date with 'origin/master'.
     v2.066.0-b1-31-gb0920b6
     Switched to branch '2.066'
     Your branch is up-to-date with 'origin/2.066'.
     v2.066.0-b1-14-gd8fc4a0

     phobos
     Switched to branch 'master'
     Your branch is up-to-date with 'origin/master'.
     v2.066.0-b1-71-g1e9c457
     Switched to branch '2.066'
     Your branch is up-to-date with 'origin/2.066'.
     v2.066.0-b1-15-g02c8b31

     installer
     Switched to branch 'master'
     Your branch is up-to-date with 'origin/master'.
     v2.066.0-b1-34-g9f411e2
     Switched to branch '2.066'
     Your branch is up-to-date with 'origin/2.066'.
     v2.066.0-b1-11-gb8aa5c0

     dlang.org
     Switched to branch 'master'
     Your branch is up-to-date with 'origin/master'.
     v2.066.0-b1-15-gd31f436
     Switched to branch '2.066'
     Your branch is up-to-date with 'origin/2.066'.
     v2.066.0-b1

     tools
     Switched to branch 'master'
     Your branch is up-to-date with 'origin/master'.
     v2.066.0-b1
     Switched to branch '2.066'
     Your branch is up-to-date with 'origin/2.066'.
     v2.066.0-b1

After adding back the v2.066.0-b3 tag, I get this:

     dmd
     Switched to branch 'master'
     Your branch is up-to-date with 'origin/master'.
     v2.066.0-b1-80-ga721850
     Switched to branch '2.066'
     Your branch is up-to-date with 'origin/2.066'.
     v2.066.0-b3

     druntime
     Switched to branch 'master'
     Your branch is up-to-date with 'origin/master'.
     v2.066.0-b1-34-gc679110
     Switched to branch '2.066'
     Your branch is up-to-date with 'origin/2.066'.
     v2.066.0-b3

     phobos
     Switched to branch 'master'
     Your branch is up-to-date with 'origin/master'.
     v2.066.0-b1-78-g5a021a7
     Switched to branch '2.066'
     Your branch is up-to-date with 'origin/2.066'.
     v2.066.0-b3

     installer
     Switched to branch 'master'
     Your branch is up-to-date with 'origin/master'.
     v2.066.0-b1-34-g9f411e2
     Switched to branch '2.066'
     Your branch is up-to-date with 'origin/2.066'.
     v2.066.0-b3

     dlang.org
     Switched to branch 'master'
     Your branch is up-to-date with 'origin/master'.
     v2.066.0-b3-15-gd31f436
     Switched to branch '2.066'
     Your branch is up-to-date with 'origin/2.066'.
     v2.066.0-b3

     tools
     Switched to branch 'master'
     Your branch is up-to-date with 'origin/master'.
     v2.066.0-b3
     Switched to branch '2.066'
     Your branch is up-to-date with 'origin/2.066'.
     v2.066.0-b3

This was exactly how things looked to me when I created the B3 binaries (with the exception of tools which only had tags for B2), however Kenji Hara reports that there are changes in the branch that do not exist in the binaries. I do not understand why since I created all the tags using the same process. The only difference is that instead of typing them one by one, I put the commands in a script so I don't forget anything.

I guess my problem is not a lack of resources (books/links) or basic understanding of them, but rather not being able to understand how commits in the branch do not make it into the binaries.

On Sunday, 13 July 2014 at 16:12:02 UTC, Andrew Edwards wrote:
> After adding back the v2.066.0-b3 tag, I get this:
>
>      dmd
>      Switched to branch 'master'
>      Your branch is up-to-date with 'origin/master'.
>      v2.066.0-b1-80-ga721850
>      Switched to branch '2.066'
>      Your branch is up-to-date with 'origin/2.066'.
>      v2.066.0-b3

This looks correct to me - because of cherry-picking commits in master and 2.066 branch have different hashes and you only tag the latter. It just happened that for v2.066.0-b1 tag commit hash in master was the same.

v2.066.0-b1-80-ga721850 means : "commit ga721850 which is 80 commits ahead of v2.066.0-b1 tag"

> This was exactly how things looked to me when I created the B3 binaries (with the exception of tools which only had tags for B2), however Kenji Hara reports that there are changes in the branch that do not exist in the binaries.

Can you link the Kenji report? It feels like some cherry-picking issue for me but I need tiny bit more info what to look for in repos.

On 7/14/14, 1:36 AM, Dicebot wrote:
> On Sunday, 13 July 2014 at 16:12:02 UTC, Andrew Edwards wrote:
>> After adding back the v2.066.0-b3 tag, I get this:
>>
>>      dmd
>>      Switched to branch 'master'
>>      Your branch is up-to-date with 'origin/master'.
>>      v2.066.0-b1-80-ga721850
>>      Switched to branch '2.066'
>>      Your branch is up-to-date with 'origin/2.066'.
>>      v2.066.0-b3
>
> This looks correct to me - because of cherry-picking commits in master
> and 2.066 branch have different hashes and you only tag the latter. It
> just happened that for v2.066.0-b1 tag commit hash in master was the same.
>
> v2.066.0-b1-80-ga721850 means : "commit ga721850 which is 80 commits
> ahead of v2.066.0-b1 tag"
>
>> This was exactly how things looked to me when I created the B3
>> binaries (with the exception of tools which only had tags for B2),
>> however Kenji Hara reports that there are changes in the branch that
>> do not exist in the binaries.
>
> Can you link the Kenji report? It feels like some cherry-picking issue
> for me but I need tiny bit more info what to look for in repos.

http://forum.dlang.org/post/CAFDvkcv+e4_skTXduXNHHHRzUgK7eUq6okniR1eakuvhqFv87w@mail.gmail.com

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 ;)

-- 
/Jacob Carlborg