And finally, if I try using the SVN URL that GitHub provides (since they support basic operations over SVN) the packager still seems to be attempting to use Git, and I get this error:
And finally, if I try using the SVN URL that GitHub provides (since they support basic operations over SVN) the packager still seems to be attempting to use Git
I think the packager should be modified to distinguish the Subversion and Git repositories URLs:
Aye - Git and Mercurial do not provide a mechanism for subdir checkouts, unfortunately. As for the packager; no work is being done on the old platform, at all. The new packager, however, will properly handle the SVN version that GitHub provides...just need to wait for the new platform to roll out.
So... basically I cannot use the CurseForge packager until 2017? So glad I just spent the last week converting all my repos to Git and setting them up for the packager... I'd have been better off sticking with SVN (which is apparently even better than Git than I previously believed) and continuing to use WoWI's packager at this rate. :( >:(
The CurseForge packager doesn't do anything with Git submodules (or SVN externals). I've worked around it for now by making more SVN mirrors for libraries, but I'm still far less than happy with the whole arrangement, especially since the packager has failed more times than it's succeeded at creating packages correctly and promptly....
I'd have been better off sticking with SVN (which is apparently even better than Git than I previously believed)
I'm working on a daily basis with Git, and I also use it for my "private projects" (i.e. WoW addons). Our whole team switched to Git two years ago and none of us would like to go back to Subversion.
The main feature of Git is its branch management system, which is fast and light. This is what allows people to fork your project, contribute back by doing pull requests, and you to easily merge these contributions. It is also very good at handling release/testing/development codes and/or to work in team on the same code base. All this is quite hard to achieve with Subversion.
The subfolder checking out is just a gimmick of Subversion. It just happens to be very handy for addon libraries. Nevertheless you can include the libraries using Git.
How? Let's say Ace3 was in a Git repository. How do I tell the packager to only include AceAddon and AceEvent, but not AceConfig and AceGUI?
I don't care about getting the libs into my local Git repos... I just kept the Libs folders from my previous SVN working copies, and can now just rightclick and "Update" with TortoiseSVN, which is slightly more work than before, but fortunately libraries don't need to be updated that often.
Edit: Also, even a simple "Update" procedure is a pain in the a** with Git if you work on multiple machines. With SVN I could just update the working copy on each machine and it would bring me up to date, painlessly, even if there were uncommitted local changes. With Git I'm apparently supposed to do a pull followed by a rebase with fast forward (I'm still not sure what that means, honestly) which generally results in conflicts if there are any uncommitted local changes, which I then have to manually resolve, and then if I want to push any changes back, I have to use the force option or it dies with complaints about having used fast foward. I've found it slightly easier to just do a fetch followed by a reset to origin/master, which preserves the local changes and just marks them as modified (which is what I want), but I really don't think that's something I'm supposed to be doing on a regular basis.
You cannot because they are all in the same repository. They should be in separate repositories in the first place. If you take a look at two major PHP frameworks hosted on Github, Symfony2 and Zend Framework, their components work together, like the Ace3 ones do, but they are available separately. (Please note this also works with non-PHP as well.)
Edit: Also, even a simple "Update" procedure is a pain in the a** with Git if you work on multiple machines. With SVN I could just update the working copy on each machine and it would bring me up to date, painlessly, even if there were uncommitted local changes. With Git I'm apparently supposed to do a pull followed by a rebase with fast forward (I'm still not sure what that means, honestly) which generally results in conflicts if there are any uncommitted local changes, which I then have to manually resolve, and then if I want to push any changes back, I have to use the force option or it dies with complaints about having used fast foward. I've found it slightly easier to just do a fetch followed by a reset to origin/master, which preserves the local changes and just marks them as modified (which is what I want), but I really don't think that's something I'm supposed to be doing on a regular basis.
Wow. You're doing it wrong. Using "git rebase" recreates your local history, which prevents to do a simple push afterwards, and doing "git push -f" forcefully pushes this new history to the remote, propagating the conflicts to the other clients. This is the subversion commit scheme (where "git rebase" is the equivalent of "git update" and "git push -f" the equivalent of "git commit"), which led to this comic :
With Git, you're supposed to do a simple pull. If it complains about local uncommited changes, just do a "git stash" beforehand and a "git stash pop" afterwards (the latter may cause some conflicts, but you would had to handle the same conflicts with subversion anyway). You should then be able to do simple push after that.
I'm working with Git for several years, alone and in team. I'm also giving some Git beginner courses to researchers with basic programming skills. It's a different mindset than central SCM like SVN, but once you get used to it, you won't go back. However, you might need to find some good documentation about it. There are some concept and abstraction to understand. Take a look at the official documentation. There is also this small interactive tutorial.
With Git, you're supposed to do a simple pull. If it complains about local uncommited changes, just do a "git stash" beforehand and a "git stash pop" afterwards (the latter may cause some conflicts, but you would had to handle the same conflicts with subversion anyway). You should then be able to do simple push after that.
Well, that's slightly better... three operations is still worse than one, though, so I'm still counting SVN as the winner in this regard. :(
So, it turns out that you can checkout a subdirectory of a Git repository using a feature called "sparse checkout" since Git 1.7. Maybe the pkgmeta specification could be extended to allow checking out a subdirectory? For example,
This would be nice for libraries... I'm currently still SVN-mirroring a number of libraries to avoid folder-in-folder syndrome and useless files (eg. TOC files and the "tests" folder contents in LibStub).
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
For SVN this is simple:
This causes the packager to only include the LibSharedMedia-3.0 subfolder, not the entire contents of /trunk.
However, if I attempt to do the same thing for a Git repo:
The packager just totally ignore this line. In the packager status log for my project, there's nothing about this line at all.
If I try using the HTTPS URL instead of the Git URL:
Then the packager log includes the following error:
And finally, if I try using the SVN URL that GitHub provides (since they support basic operations over SVN) the packager still seems to be attempting to use Git, and I get this error:
I can't think of anything else to try. Please help.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumSubfolder checkout is a unique feature of Subversion. Git does not provide it.
I think the packager should be modified to distinguish the Subversion and Git repositories URLs:
-
View User Profile
-
View Posts
-
Send Message
Project AuthorTake a look at how I did it.
https://github.com/moonwitch/oUF_Phanx (yes I forked you just for that)
Just tried giving you something more to work with :(
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI'm working on a daily basis with Git, and I also use it for my "private projects" (i.e. WoW addons). Our whole team switched to Git two years ago and none of us would like to go back to Subversion.
The main feature of Git is its branch management system, which is fast and light. This is what allows people to fork your project, contribute back by doing pull requests, and you to easily merge these contributions. It is also very good at handling release/testing/development codes and/or to work in team on the same code base. All this is quite hard to achieve with Subversion.
The subfolder checking out is just a gimmick of Subversion. It just happens to be very handy for addon libraries. Nevertheless you can include the libraries using Git.
I don't care about getting the libs into my local Git repos... I just kept the Libs folders from my previous SVN working copies, and can now just rightclick and "Update" with TortoiseSVN, which is slightly more work than before, but fortunately libraries don't need to be updated that often.
Edit: Also, even a simple "Update" procedure is a pain in the a** with Git if you work on multiple machines. With SVN I could just update the working copy on each machine and it would bring me up to date, painlessly, even if there were uncommitted local changes. With Git I'm apparently supposed to do a pull followed by a rebase with fast forward (I'm still not sure what that means, honestly) which generally results in conflicts if there are any uncommitted local changes, which I then have to manually resolve, and then if I want to push any changes back, I have to use the force option or it dies with complaints about having used fast foward. I've found it slightly easier to just do a fetch followed by a reset to origin/master, which preserves the local changes and just marks them as modified (which is what I want), but I really don't think that's something I'm supposed to be doing on a regular basis.
I've tried and failed; so Adirelle; do tell :)
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumYou cannot because they are all in the same repository. They should be in separate repositories in the first place. If you take a look at two major PHP frameworks hosted on Github, Symfony2 and Zend Framework, their components work together, like the Ace3 ones do, but they are available separately. (Please note this also works with non-PHP as well.)
Wow. You're doing it wrong. Using "git rebase" recreates your local history, which prevents to do a simple push afterwards, and doing "git push -f" forcefully pushes this new history to the remote, propagating the conflicts to the other clients. This is the subversion commit scheme (where "git rebase" is the equivalent of "git update" and "git push -f" the equivalent of "git commit"), which led to this comic :
http://geekandpoke.typepad.com/.a/6a00d8341d3df553ef0134885909e0970c-pi
With Git, you're supposed to do a simple pull. If it complains about local uncommited changes, just do a "git stash" beforehand and a "git stash pop" afterwards (the latter may cause some conflicts, but you would had to handle the same conflicts with subversion anyway). You should then be able to do simple push after that.
I'm working with Git for several years, alone and in team. I'm also giving some Git beginner courses to researchers with basic programming skills. It's a different mindset than central SCM like SVN, but once you get used to it, you won't go back. However, you might need to find some good documentation about it. There are some concept and abstraction to understand. Take a look at the official documentation. There is also this small interactive tutorial.
Well, that's slightly better... three operations is still worse than one, though, so I'm still counting SVN as the winner in this regard. :(
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumNot entirely relevant but always useful :D
-
View User Profile
-
View Posts
-
Send Message
Curse Premiumexternals: url: git://git.wowace.com/wow/libfoo/mainline.git subdir: libfoobar