www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - git <tag> --fubar

reply "Andrew Edwards" <ridimz yahoo.com> writes:
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
Jul 12 2014
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Jul 12 2014
prev sibling next sibling parent reply Johannes Pfau <nospam example.com> writes:
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
Jul 13 2014
parent reply "Andrew Edwards" <ridimz yahoo.com> writes:
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.
Jul 13 2014
parent reply "Dicebot" <public dicebot.lv> writes:
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.
Jul 13 2014
parent reply Andrew Edwards <ridimz yahoo.com> writes:
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
Jul 13 2014
parent reply "Dicebot" <public dicebot.lv> writes:
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
Jul 14 2014
parent reply Andrew Edwards <ridimz yahoo.com> writes:
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
Jul 14 2014
next sibling parent Andrew Edwards <ridimz yahoo.com> writes:
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
Jul 14 2014
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
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.
Jul 14 2014
parent reply Andrew Edwards <ridimz yahoo.com> writes:
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


     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


     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?
Jul 14 2014
parent reply "Dicebot" <public dicebot.lv> writes:
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?
Jul 14 2014
parent reply Andrew Edwards <ridimz yahoo.com> writes:
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.
Jul 14 2014
parent Andrew Edwards <ridimz yahoo.com> writes:
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.
Jul 14 2014
prev sibling parent reply "sigod" <sigod.mail gmail.com> writes:
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
Jul 13 2014
next sibling parent Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d puremagic.com> writes:
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 .... :-)
Jul 13 2014
prev sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
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.
Jul 13 2014
parent reply Jacob Carlborg <doob me.com> writes:
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
Jul 14 2014
parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
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
Jul 14 2014