Re: [git-users] How do I git-push to an FTP server?
On Friday, October 5, 2012 3:40:54 PM UTC+2, Konstantin Khomoutov wrote: I have no idea about why pushing over HTTP calls `git http-push` after uploading the data. I've forwarded your message with the trace to the main Git list to ask the experts. You're on its Cc list so you should automatically get any replies to appear there. Thanks! After reading the replies so far, though, it seems like the problem is unsolvable. /August -- You received this message because you are subscribed to the Google Groups Git for human beings group. To view this discussion on the web visit https://groups.google.com/d/msg/git-users/-/hKKBznfwJNMJ. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
Re: Fw: [git-users] How do I git-push to an FTP server?
Jonathan Nieder jrnie...@gmail.com writes: Ramkumar Ramachandra wrote: Thomas Ferris Nicolaisen tfn...@gmail.com writes: At least according to the documentation[1], Git natively supports [...] ftp. This could need some clarification if pushing over ftp is not supported. [...] -Git natively supports ssh, git, http, https, ftp, ftps, and rsync -protocols. The following syntaxes may be used with them: +Git natively supports ssh, git, http, https, and rsync protocols. The +following syntaxes may be used with them: Perhaps the initial list should not be exhaustive, in which case we could say: Git natively supports ssh, git, http, and https protocols. The following syntaxes may be used with them: ... Git also has (less efficient) support for fetching and pushing over rsync protocol and fetching over ftp or ftps, using the same protocol://host/path/to/repo.git/ syntax. Yeah, that, possibly with These are deprecated; do not use them., would be a better way forward. As we deprecated rsync long time ago, perhaps we should remove it at Git 2.0 or somewhere around that. By the way, that old patch by Ram in question was *not* incorrect per-se back then when dumb http was still more prevalent option between the two http transports. Fetching over dumb http and dumb ftp were both equally bad ;-) It just has become less relevant as more people start equating http with the smart http, where there is no equivalent smart ftp. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
[git-users] Re: Importing Subversion vendor-branches to Git
Hi, It is indeed a large post and hard to read out the question(s) in there. In the middle part, you describe some complications with the live/pristine branches, but you also write that you have already solved this problem? I find the connection with the first and the last part a bit unclear. You might get more replies if you try to isolate a smaller example, and ask simpler questions one at a time. I'm not quite sure how the external libraries are versioned in relation to your core project (with the trunk/branches/tag structure). Before I go on to think about how one could do lots of sub-tree merging and filter-branching to get these external libraries into your repository, I want to ask if you really want to do this. Including the sources of 3rd party libraries is exactly what git-submodules are intended for, and even before I do this I would consider if it is possible to get away with rather some binary dependency declaration in the build-tool instead (this might not be fitting for your project, but it's worth considering). Even if you do your own modifications of lua or the other libraries, it is still worth tracking them in their own repositories, and then load them in using submodules. With this in consideration, what is the first thing you need to solve? You write that you haven't been able to convert with all the merges intact. Is this point crucial to complete the conversion? On Saturday, October 6, 2012 7:33:42 PM UTC+2, Carsten wrote: Hi all, in this blog post the author described a very nice (natural and simple) way to deal with vendor branches in Git: http://happygiraffe.net/blog/2008/02/07/vendor-branches-in-git/ This works very well (in fact, I use this approach for my website, too), but observe how the upstream (vendor) branch file contents (the Wordpress files) is at the same directory level as the project itself. With my main programming project, I'm in a very similar situation, and I'd love to extend this idea to manage the outside, external libraries (e.g. lua, wxWidgets and zlib) in a similar manner. The key difference would be that the upstream branch had the libraries *not* at the top level: lua/ wxWidgets/ zlib/ but have them all in a single shared directory: ExtLibs/ lua/ wxWidgets/ zlib/ This would be important to have it match the main project (master) branch, which had both ExtLibs/ and additionally all the project-specific directories as well. For example: abc/ bin/ ExtLibs/ lua/ wxWidgets/ zlib/ samples/ src/ (Unfortunately, none of the Git books that I've read (Pro Git by Chacon, Version control with Git by Loeliger and McCullough, Git by Haenel and Plenz) mention this technique in their subprojects chapters. In fact, when you search, the answer to vendor branches seems almost always to be submodules or subtrees. I see that the above has limits of its own, but seems to be a very good solution for most cases of vendor branch.) In summary, all like in the blog post above, but with the extra (sub-)directory ExtLibs. In this spirit, I had no problems converting my three websites from Subversion to Git, which were never structured in the Subversion standard layout, but right from the start like this: live/ cafu/ fsv/ rcgj/ pristine/ cafu/ fsv/ rcgj/ This sequence of commands left me with a perfect conversion to Git: git svn init svn://thubi-cfs/Websites --trunk live/fsv fsv cd fsv git config --add svn-remote.svn.fetch pristine/fsv:refs/remotes/pristine git config svn.authorsfile d:/test/authors.txt git svn fetch This also worked for website rcgj, but with cafu, in Subversion days I had made the mistake to merge e.g. from (a) pristine/cafu/forum/ to live/cafu/forum/ (or some other subdirectory below cafu/), rather than at the top from (b) pristine/cafu/ to live/cafu/ In the above sequence, git-svn properly recognized the merges that were made as in (b), but not those made as in (a). As a result, I had to tweak the newly converted cafu Git repository with grafts, baking them with git filter-branch. Back to my source code project, the Subversion repository is today structured like this: cafu/ trunk/ abc/ bin/ ExtLibs/ lua/ wxWidgets/ zlib/ samples/ src/ branches/ tags/ vendor/ lua/ wxWidgets/ zlib/ That is, standard layout, plus one vendor branch. (Sorry that the name cafu appears here again, it's not related to the website example above!)
Re: [git-users] Is Git for me?
I think git is great for backup. Here's why: With svn etc there is a central server. If that fails, then you are screwed. With git, all the clones have exactly the same data, including history etc. There is no master except by convention. If the master server dies, then just repopulate it from a client and you have everything restored. I use git all the time even if the code does not leave one machine. It allows me to track changes and experiment and easily give my clients patches. On Sun, Oct 7, 2012 at 5:38 PM, Max Hodges m...@whiterabbitpress.com wrote: Git is for version tracking--most often for code, but it could also be used to track any files. Its not a backup tool and its not a deployment tool. Tracking changes to your source code is a very useful function. Sometimes during development you realize you're taken a wrong turn, and a tool like Git allows you to backtrack very easily. Also sometimes you may comment out a lot of lines while you're refactoring some code. With Git you no longer need to comment them out. Just delete them, because you can always compare your new code with an older version. So this makes your code a bit more clean. I'd recommend Git any software development project. Source code version tracking is as fundamental as testing. Its the professional way to develop. If you don't care about the benefits of source code tracking, and are only looking for a backup solution, then there are more simple ways to implementing a backup, including a simply copy command to an external hard drive or USB thumb drive. As far as setting up your code for tracking, its extremely easy. You can use a GUI to manage things--I use the SmartGit GUI, but the command-line tutorials like this one are still very useful to get familiar with the concepts and capabilities: http://gitimmersion.com/ airborne IR cameras huh? for spotting the tell-tale footprints of grow light marijuana production by chance? Cheers! -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
