Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Missing git tags for v0.10.1 and v0.10.2 #1606

Closed
ljharb opened this issue Dec 27, 2014 · 14 comments

Comments

Projects
None yet
4 participants
@ljharb
Copy link
Contributor

commented Dec 27, 2014

Please push git tags for the released v0.10.1 and v0.10.2 versions :-) thanks!

(Looks like 8ca82d8 is v0.10.2 and ab2a8ff is v0.10.1?

@nzakas

This comment has been minimized.

Copy link
Member

commented Dec 27, 2014

These appear to already be pushed:
https://github.com/eslint/eslint/tags

Tags are pushed with every release as part of our script so as to avoid such problems.

Where are you looking?

@nzakas nzakas added the triage label Dec 27, 2014

@ljharb

This comment has been minimized.

Copy link
Contributor Author

commented Dec 27, 2014

Huh - they're totally there on github, but my local repo seems to refuse to fetch them, even on a fresh clone.

@ljharb

This comment has been minimized.

Copy link
Contributor Author

commented Dec 27, 2014

Can you reproduce this problem on a fresh clone? If not, I'll close it, and if so, maybe we could try force-deleting and repushing the tags?

@michaelficarra

This comment has been minimized.

Copy link
Member

commented Dec 27, 2014

I just fetched the tags myself. Are you fetching from the correct remote? Try git fetch --tags --all.

@ljharb

This comment has been minimized.

Copy link
Contributor Author

commented Dec 27, 2014

Snap, I'd done git fetch --tags and git fetch --all but never the two combined - that seems to have done it. Odd that a fresh clone would grab every tag but those two. Thanks!

@ljharb ljharb closed this Dec 27, 2014

@ljharb

This comment has been minimized.

Copy link
Contributor Author

commented Dec 27, 2014

I figured it out - nothing else is pointing at them, since the tagged commits aren't actually in the master branch. Should be fine, but it's a bit odd imo that the tagged commit wouldn't be on something in master?

@michaelficarra

This comment has been minimized.

Copy link
Member

commented Dec 27, 2014

Yeah, it looks like the tagged commits are not on master. Here's the ones that are on master, untagged: 0.10.1 and 0.10.2. I say we tag these ones properly and force-push them.

@nzakas nzakas reopened this Dec 27, 2014

@nzakas

This comment has been minimized.

Copy link
Member

commented Dec 27, 2014

Sorry, I'm having trouble following this thread. Are you saying the tags are on the wrong commits? If yes, how can that be fixed?

@michaelficarra

This comment has been minimized.

Copy link
Member

commented Dec 27, 2014

Yes. Delete the tags, add the tags to the commits I linked above, then git push --tags --force.

@ljharb

This comment has been minimized.

Copy link
Contributor Author

commented Dec 27, 2014

It looks like your automated process is creating two commits - one with the changelog and package.json changes with the message "vA.B.C" on master, and then a separate loose commit not on master, on top of the commit before the one that's on master, with only the version number bump and not the changelog.

@lo1tuma

This comment has been minimized.

Copy link
Member

commented Dec 27, 2014

The following is going on in Makefile.js

  1. Executing npm version <type> which updates the package.json and creates a commit and a tag
  2. Updating CHANGELOG.md
  3. Executing git commit --amend --no-edit

git commit --amend creates a new commit with a new SHA and replaces the old commit on the master branch but the tag is still pointing to the old commit.

@ljharb I wonder why you only have problems with the two latest commits. It seems like almost every tag points to a commit which is not on master. Compare v0.8.0 (not on master) with v0.0.2 (on master).

See also: What happens in Git to a tag when you amend the commit that was tagged?

@nzakas

This comment has been minimized.

Copy link
Member

commented Dec 27, 2014

@lo1tuma nice analysis. Seems like this has been going on for a while.

So we should fix the build step to make sure the tag is pointing to the correct commit. I'm not sure it's worth the time to go back and fix ask the existing tags unless there's a way to automate it.

@nzakas nzakas added accepted bug build and removed triage labels Dec 27, 2014

lo1tuma added a commit that referenced this issue Dec 28, 2014

lo1tuma added a commit that referenced this issue Dec 28, 2014

lo1tuma added a commit that referenced this issue Dec 28, 2014

nzakas added a commit that referenced this issue Dec 28, 2014

Merge pull request #1608 from eslint/issue-1606
Build: tag correct commit (refs #1606)
@nzakas

This comment has been minimized.

Copy link
Member

commented Dec 29, 2014

Okay, I updated the tags for 0.10.1 and 0.10.2. With @lo1tuma's fix to the build script, we should be good going forward.

@nzakas nzakas closed this Dec 29, 2014

@ljharb

This comment has been minimized.

Copy link
Contributor Author

commented Dec 29, 2014

Thanks!

Holixus pushed a commit to Holixus/eslint that referenced this issue Feb 12, 2015

@eslint eslint bot locked and limited conversation to collaborators Feb 7, 2018

@eslint eslint bot added the archived due to age label Feb 7, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.