Bugzilla – Full Text Bug Listing
| Summary: | best way tag git repos after a release | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Kim Moir <kim.moir> |
| Component: | Releng | Assignee: | Platform-Releng-Inbox <platform-releng-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | curtis.windatt.public, daniel_megert, david_williams, dj.houghton, pwebster, remy.suen, tjwatson |
| Version: | 3.7.1 | ||
| Target Milestone: | 4.2.2 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
Kim Moir
Dani's suggestion is the closest we can get with our current workflow, but it is not guaranteed to be correct. If someone committed a change to the branch, but did not contribute it to the build, then it will appear to be in the release when it isn't. See bug 351818 and bug 351819 comment #2 I'd hope to separate the qualifier for the plugin from the tag on the commit used to create the build, to help with EGit + large repos + eclipse source references. But if it is useful would depend on us adopting a process similar to Orion. PW On the advice of the wise PMC, I have been advised to delegate the tagging of the git repos for 3.7.1 to the components who own them. The following Git repositories need to be tagged with R3_7_1 to match the tags that were submitted to the final build. You can see these tags in the R3_7_1 tag of org.eclipse.releng in /cvsroot/eclipse. equinox.framework equinox.bundles platform.runtime platform.resources equinox.p2 pde.ui platform.swt platform.swt.binaries platform.ui platform.ua (In reply to comment #3) > platform.ui I'll take care of this tomorrow. I've pushed the R3_7_1 tag for eclipse.platform.ui to git.eclipse.org. (In reply to comment #1) > Dani's suggestion is the closest we can get with our current workflow, but it > is not guaranteed to be correct. If someone committed a change to the branch, > but did not contribute it to the build, then it will appear to be in the > release when it isn't. This was not an issue for the equinox.bundles and equinox.framework repositories but I am wondering what we would actually do if something like that happened. I don't see any useful way to do this. Isn't it enough to simply tag the map files used for input to the R3_7_1 build? > Isn't it enough to simply tag the map files used for input to the R3_7_1 build?
Yes, for the build(er) but if you want to compare stuff against a release, e.g. to track down a bug, then it is very helpful to have the tag on the repo.
The tag has been added to pde.ui and pde.build (thanks DJ) repositories. I have also done platform debug and jdt debug. I had two minor issues. I couldn't see the tags on platform debug's git.eclipse.org page (but the tags do exist). In jdt debug there have been several changes since the 3.7.1 release including one bug that was marked for 3.7.1 and committed, but never tagged. Since this case was the last commit before 3.7.1, I tagged the prior commit as R3_7_1. (In reply to comment #9) > I had two minor issues. I couldn't see the tags on platform debug's > git.eclipse.org page (but the tags do exist). The gitweb cache just needs to catch up. It does not always immediately reflect the tags you push upstream. (In reply to comment #10) > (In reply to comment #9) > > I had two minor issues. I couldn't see the tags on platform debug's > > git.eclipse.org page (but the tags do exist). > > The gitweb cache just needs to catch up. It does not always immediately > reflect the tags you push upstream. Yes, Tom is right, the web UI is not "instant". When I need to link to a commit or tag that I've just pushed and don't see it after refreshing, I usually click on an existing commit or tag and then replace the link with the SHA-1 hash or tag that I've just pushed. That should load up in the browser even if the table view doesn't seem to show the commit or tag in question. (In reply to comment #9) > I had two minor issues. I couldn't see the tags on platform debug's > git.eclipse.org page (but the tags do exist). Tags aren't pushed by default. You need to do "git push --tags" or whatever the EGit equivalent is. (In reply to comment #12) > Tags aren't pushed by default. You need to do "git push --tags" or whatever the > EGit equivalent is. The equivalent step in eGit is to do a Push... and on the specifications page press the button to add all tag specs. I had added this to the git workflows wiki page, but Dani has since reverted the change as that command will push all local tags, replacing any that have been deleted on the remote. Does anyone have a suggestion on how to push a specific set of tags from eGit? You can push a single tag from the command line using 'git push origin mynewtag'. For me I don't see any problems with pushing all tags as I don't have any other local ones and the dry run tells you what tags will be updated/changed. (In reply to comment #13) > Does anyone have a suggestion on how to push a specific set of tags from eGit? So on the specifications page of the push wizard you can add 'refs/tags/<tagname>' to the source ref box and hit add spec. Only that tag will be pushed. There is content assist for that box to help you find a tag. I have updated the wiki page accordingly. It really depends on how you use Git. If you keep work with local branches and tags then you should make sure that those don't end up in the shared repositories. If not, then feel free to always push all tags. Out of curiosity, what actually happens if you try to push a tag upstream for a commit that does not exist upstream? Would that automatically push your branch containing the commit upstream? (In reply to comment #16) > Out of curiosity, what actually happens if you try to push a tag upstream for a > commit that does not exist upstream? Would that automatically push your branch > containing the commit upstream? Nice homework for the weekend :-) (In reply to comment #16) > Out of curiosity, what actually happens if you try to push a tag upstream for a > commit that does not exist upstream? Would that automatically push your branch > containing the commit upstream? It looks like it pushes the tag only i.e. it will be unusable without pushing the other stuff. (In reply to comment #18) > (In reply to comment #16) > > Out of curiosity, what actually happens if you try to push a tag upstream for a > > commit that does not exist upstream? Would that automatically push your branch > > containing the commit upstream? > It looks like it pushes the tag only i.e. it will be unusable without pushing > the other stuff. Thanks Dani, you did your weekend homework! ;-) I would not have guessed tagging worked that way. I had always thought that a tag in git required some commit to be associated with it. The tag is worthless without the commit it is associated with. I guess the commit could be pushed later. > I would not have guessed tagging worked that way. I had always thought that a
> tag in git required some commit to be associated with it. The tag is worthless
> without the commit it is associated with. I guess the commit could be pushed
> later.
Yes. It looks like Git just creates the tag file pointing to the commit hash. Once the commit is pushed, the tag becomes usable.
I think this was settled a long time ago. |