Posted by Damien Tournoud on December 10, 2010 at 3:13am
9 followers
| Project: | The Great Git Migration |
| Component: | Migration scripts |
| Category: | task |
| Priority: | normal |
| Assigned: | sdboyer |
| Status: | closed (won't fix) |
| Issue tags: | git phase 2, git sprint 10, tggm repo changers |
Issue Summary
Now that we rename the old CVS tags, all our tags and branches properly map the version numbers of the corresponding releases. All, but "master", which is the renamed HEAD branch.
It would be very very useful (even if not strictly necessary) to rename the master branch to its corresponding development release, if available. It would avoid special cases needed to be added to Drush and all the other tools that need to pull branches from Git and would promote a saner naming convention we want to provide anyway.
All the needed information is available in the release XML feed, so no deep integration with Drupal.org database would be necessary. See for example http://updates.drupal.org/release-history/drupal/7.x
Comments
#1
Mental note: we also need to set the default branch of the repository to this new branch.
Also, because Git provides no facility to do that via the protocol, we might have to provide a UI for that at one point.
#2
Noticed this drush with RC3. We can't checkout stuff from HEAD right now. Subscribe.
Thanks all.
#3
A corresponding decision was made over at #953916: Proposal: Ditch the ability to have release nodes pointing to HEAD/master where I believe a few queries were run to find the number of projects this would affect.
#4
Yeah, I'm down with that. In cases where there's a release node pointing to HEAD with useful version information, we could rename HEAD to the right branch version (e.g '7.x-1.x') instead of just renaming it to 'master'. I'm definitely in favor of that. Two points:
A) There are going to be some HEAD release nodes that still don't have useful version info, so we're still going to have to deal with those in some way. Granted, these are incredibly old and probably totally obsolete. But, we can't assume every HEAD release has a real version yet.
B) This isn't a bug -- WTF? ;)
But yes, this would be a Good Thing(tm) for a lot of reasons. +1. ;)
Cheers,
-Derek
#5
Adding a tag so we can better track these repo-altering issues
#6
sub
#7
Quick php to parse the branch name from the update XML.
This script requires a shortname so... #1009326: rename repos to their project shortname is a requirement for this to truly work correctly atm.
#8
Suggestion: If there is a release pointing to master, rename it to that release. Otherwise, point default branch to the latest dev release branch and remove master.
#9
Probably a bad idea remove masters we can't tie to a release. That isn't clear enough to rule the history isn't important. For example, all new modules that don't want a dev release yet loose their repo.
#10
Yikes! I guess if there is history in master to just leave it, maybe ask the maintainers what to call it.
#11
I think in cases where we don't know, we just leave it called 'master' and let people branch to well-known branch names whenever they want to make a release out of it.
#12
Tagging for consideration in Git Sprint 8.
#13
Assigning to Sam per the sprint planning spreadsheet.
#14
This isn't critical for initial public testing, we can always add it in later. And since there are some potential headaches and careful data sifting that needs to be done to ensure we don't make any oopsies, moving this to sprint 9.
#15
Sprint 10 for this.
#16
We seem to have just decided in IRC that the risk is too high to do this at this point, so this one will not happen.
#17
Opened #1059072: Migrate away from the use of master branch: Document and promote project moves as a more gentle, lower-risk way of making this move.