Re: [git-users] can't have a directory named bundle?
On Tue, Jan 08, 2013 at 06:34:24PM -0800, msoulier wrote: I happened to create a subdirectory in my working set called bundle, and I noticed that git ignored it. Why is that? And what if I need such a directory? I suppose essentially what you're seeing is Git not showing you an *empty* directory, and this has nothing to do with its name: % git status # On branch master nothing to commit (working directory clean) % mkdir bundle % git status # On branch master nothing to commit (working directory clean) % touch bundle/whatever % git status # On branch master # Untracked files: # (use git add file... to include in what will be committed) # # bundle/ nothing added to commit but untracked files present (use git add to track) % I think this behaviour is due to the fact Git does not explicitly track directories and they ever exist in the commits it manages because those commits contain files in those directories. I mean, the only way to make a directory get added to a commit, is to add a file in it. This also means Git does not support managing empty directories (a topic provoked heated discussions on the main Git list several times). Hence looks like tools like `git status` only ever pay attention to those filesystem objects which are regular files or contain them. --
[git-users] Re: git push
Hello, I am seeing TRUNK- branches... are you using git with git svn? In this case, you should not try to sync with a svn repo and a git remote at the same time. When you git svn dcommit to your svn repo, the commits being sent are locally rewritten to include some svn information. This is basically equivalent to rewriting your history, which is considered a bad thing when dealing with git remotes. The only safe (and very constraintful) way to deal with the two types of repos is to set the rule to only push to git commits which have already been dcommitted to svn. Hope this helps. Le mardi 8 janvier 2013 08:47:10 UTC+1, k-joseph a écrit : Hi every one, am kindly requesting for your assistance, i successfully push to a remote branch on my account for the first time( first push where i use git push origin name of the branch) but when am pushing the second or any other time except the first i normally get an error $ git push Enter passphrase for key '/c/Users/kaweesi joseph/.ssh/id_rsa': error: src refspec refs/heads/trunk-3...@github.com javascript: does not match any. error: failed to push some refs to 'g...@github.com:k-joseph/openmrs-core.git' i have also tried using git push --all and i get $ git push --all Enter passphrase for key '/c/Users/kaweesi joseph/.ssh/id_rsa': Counting objects: 249, done. Delta compression using up to 4 threads. Compressing objects: 100% (79/79), done. Writing objects: 100% (139/139), 24.36 KiB, done. Total 139 (delta 72), reused 99 (delta 45) To g...@github.com:k-joseph/openmrs-core.git 9b76cd3..9e4ba80 TRUNK-3814 - TRUNK-3814 * [new branch] TRUNK-2449 - TRUNK-2449 * [new branch] testing - testing ! [rejected]master - master (non-fast-forward) error: failed to push some refs to 'g...@github.com:k-joseph/openmrs-core.git' hint: Updates were rejected because a pushed branch tip is behind its remote hint: counterpart. Check out this branch and merge the remote changes hint: (e.g. 'git pull') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details. So i have always been deleting the remote branch in order to succeed in pushing my changes to a remote branch, i fill this is not the best way to do this Please help me with a git command that i can use to push to a remote branch the second, third or even more time without first deleting the remote branch, thanks all --
[git-users] Re: Management of a puppet tree and multiple developers
Thanks for your replies. I agree that we'd like to use multiple branches, but we're running into problems doing that with our setup. The issue here is that often, there isn't a way to know something isn't working until the changes are committed and the development puppet server has pulled them down, because only then can we see how the puppet client systems react. There are a few potential ways to go about this: - Have a bunch of test clients (most of them would have to be VMs), two for each developer's workstation, and run puppet masters on each developer's workstation for test clients to point to. I'm thinking there has to be an easier way than this. - Have multiple development branches, each one being pulled down to the puppet development server in separate directories, then have those directories rsync'd into the main puppet tree (this avoids the problems that happen when you have unmanaged files in locations to which you're doing a git pull, which are magnified greatly when implementing multiple trees, as I discovered yesterday). - A better version of the above is something like this, but it would require a lot of restructuring, and unfortunately we're understaffed and have several large projects that take priority: http://puppetlabs.com/blog/git-workflow-and-puppet-environments/ I think option 3 is the best long-term, but I'm looking for something we can implement quickly until we get a bit of breathing space. I realize the way we're using Git is kind of weird, so maybe I'm thinking in the wrong direction altogether. --
[git-users] Position of Development and Operations for Gerrit in Ericsson
Ericsson is looking for DevOps candidates with very good experience to develop and support global services for Gerrit, Jenkins and other tools in the continuous integration domain. You can access the full description on LinkedIn at http://www.linkedin.com/jobs?viewJob=jobId=4528066 or read it below. Note that each tool will be handled in it's own service so experience in all of them is not required however if you do have larger experience you'll be potentially able to get involved in multiple areas. If interested please contact *christian.la...@ericsson.com*. *Job description* Ericsson is putting in place global services to support few main applications in the area of version control and continuous integration, more specifically Gerrit, Jenkins, Maven and Repository Management solutions. The services scope is to deliver a common platform: enterprise grade application infrastructure, user support, best practices, and communities. The RD projects then use that platform to define and perform own processes. The responsibilities can cover any of the following aspects: development, deployment, administration, operations, troubleshooting and support. The candidate will be part of a team and may also coordinate technical activities, using Agile methods (Scrum, Kanban). The team is responsible of the *application* layer, the underlying IT infrastructure (e.g. OS, hardware, storage, network …) been supported by other IT services. The team will provide requirements to those services and be actively involved in reviewing their solutions. As such we need candidates that have solid experience in deploying, administering and supporting on a large scale the tools in scope or similar applications, have good experience with those tools are power users, solid knowledge of IT, good communication, coordination and planning skills. Java programming and debugging is also a strong asset. *This position is located in Ericsson Montreal (Canada)*. *Main responsibilities* · Investigation, analysis, definition and implementation · System administration (installations, upgrades, expansions, multi-siting e.g. Gerrit mirrors, virtualisation, etc) · Development (live Java application debugging, scripts, plugins) · Interfacing with solution providers, including Ericsson IT , or relevant open source communities · Internal customer support (technical, usage) · Participation to internal communities, drive and consolidate best practices · Planning and coordination of team activities *Qualifications*** Education: Bachelor's degree in Engineering, or Computer Science. Pertinent Experience: Minimum 5 years in development and operations of the tools in scope or similar. *Competencies (not all required, the more the beter)* · Very good knowledge of Git, Gerrit, Jenkins, Maven · Very good experience in system / application administration · Good knowledge of software CM (version control tools and build management in general) · Good general IT knowledge. · Good software development experience, preferably with Java and with at least one of: Python, Groovy, Shell scripting. · Good database administration knowledge (MySQL, PostgreSQL). · Good customer handling skills. · Ability to solve problems quickly and completely, and document solutions. · Ability to identify recurring tasks which require automation and automate them. · Strong inter-personal and communication skills. Must enjoy being part of a team, and be a team player. · Good leadership, planning and coordination skills · Fluent in english (written/spoken) The following skills are considered assets: · Experience with managing multi-user applications on Linux. · Good Linux system administration skills. · Good virtualization knowledge · Knowledge of Agile methods (SCRUM, Kanban), capable to manage team planning (e.g. Scrum master) *Company Description* A connected world is just the beginning. *Ericsson* is the world’s leading provider of technology and services to telecom operators. Ericsson is advancing its vision of being the “prime driver in an all-communicating world” through innovation, technology, and sustainable business solutions. We now stand on the brink of fundamental innovation opportunities across industries, public services and in private life. We are moving from the information society to the Networked Society, where the primary concern is not having access to information, but what benefit you get out of it. It took 100 years to connect 1 billion places and 25 years to connect 5 billion people. The next step is connecting things. Ericsson envisions 50 billion connected devices as a starting point for new ways of innovating, collaborating, and socializing. The result will be simplified processes,
Re: [git-users] Can Git do all of this?
On Tue, 8 Jan 2013 15:51:18 -0800 (PST) Greg i.am...@comcast.net wrote: [...] 1. A general architecture as follows: a. Distributed repository model where local branches are pemitted and all repositories are kept in sync with reasonable latency (I believe Git does this; please correct me if I'm wrong) This sounds like some kind of marketing speak so it's not quite clear what's being asked here. If you ask about some sort of *automated* synchronizing of developers' repos to a central (master, blessed, reference or whatever else you'd like to call it) repo then no, Git can't do it by itself. If what's hidden behind this phrase is whether developers are able to periodically push their work somewhere then the answer is yes (obviously). But such pushes are only done voluntarily unless you deploy some sort of crazy scheme which would use a scheduler and some custom code to automate such a task. In general, when working with Git, a policy regarding code organisation and workflow is developed and agreed upon, then everyone follows it. b. Capable of synchronization with a secure repository in the cloud as redundant off-site storage (either free or subscription) Another case of marketing speak: the word cloud is so tired everyone has its own set of meanings for it. To provide an off-site emergency storage for your Git repo(s), you have several possibilities: * Buy private hosting from a Git hosting provider (such as bitbucket, github etc) -- this is really a no-brainer setup. * Buy a VPS or a dedicated server (running a Linux-based OS) and host your backup repos on it -- this is slighty harder to set up, but only slightly. These two possibilities suffer from the same syndrome: they won't protect your code from a prying eye and are unable to keep your trade secret, if any, so there's another one: * Buy/rent some storage (be it a server or a dropbox-like service) and periodically upload there encrypted backups of your repos made by the `git bundle` tool (which is an integral part of Git). This is not bandwidth-effective but should in exchange be reasonably safe security-wise. 2. Provide a seamless developer SCM experience from within the following development environments: a. Microsoft Visual Studio (HTML/JavaScript/C# development for PC/Windows and Windows Phone) No native (i.e. made by Microsoft) tool, but Git Extensions [1] claims to have support for the whole range of contemporary MS IDEs. I have only used Git Extensions in the standalone mode, and it rocks. b. Eclipse (HTML/JavaScript/Java development for Android devices) Yes, via its EGIT plugin [2]. I, again, have no personal experience with it, but it's reported to work OK. c. Apple Xcode (HTML/JavaScript/Objective-C development for Mac/OS X, iPad, iPod, and iPhone) XCode has built-in support for Git -- at least version 4.2 running on Mac OS X 10.6.8 (I've had a chance to tinker with it just today). 3. Provide full-featured user interfaces for the following platforms (particularly where IDE integration in #1 above is not available): Not sure what does full-featured really means here. On all platforms Git is ported to (namely, everything POSIX, including Mac OS X, and Windows), it comes with its full set of command-line utilities and its two standard GUI tools (`git gui` for arranging commits and working with remote repos and `gitk` which is a graphical history browser). Git's command line tools are able to work with a wide set of diffing GUI software (such as vimdiff, meld, KDiff etc) and could be set up for custom front-ends as well. a. PC with Microsoft Windows 7 (GUI and command shell, preferrably PowerShell) Works OK in cmd.exe. Works almost OK in the port of the GNU bash shell (which is packaged with Git for Windows) -- no support for non-ASCII characters. Don't know for PowerShell but heard it works there OK as well. Several technical issues exist: * There's no 64-bit binaries of Git for Windows so you won't be able to handle files larger than some 2GiB. * Pathnames longer than 260 or so characters are not supported (i.e. Git does not internally uses those hacks with \\.\ pathname prefixes and relies on more standard APIs). * Certain obscure bugs persist (though you're unlikely to encounter them). b. Mac with OS X It's just a POSIX system, so nothing special about it. There were certain issues with funky approach to handling Unicode in HFS but they've been fixed in 1.8 or even earlier. c. Browser-based web interface for the secure repository in the cloud (for use on machines/devices where Git is not installed) I hear this stupid word again... There are three sorts of web front-ends to browse Git's history: * Proprietary web front-ends provided by the Git hosting providers. * A de-facto standard free tool called gitweb -- it usually comes packaged with any sensible OS which has Git packaged, so if you're about to deploy/rent a server, you
Re: [git-users] Can Git do all of this?
Thank you very, very much Konstantin for the detailed reply... you answered all of my questions and also included lots of great supplemental information. I concur with your comments about the marketing speak and the cloud, and I apologize for not phrasing my questions in a more clear and concise way. WRT 1.a: Voluntary pushes by devs to synchronize repos based upon agreed policy is the model I was attempting to describe (obviously poorly, sorry). WRT 1.b: I am surprised by your comment that private Git repos purchased from Github are not secure... they purport to be authenticated and use SSL connections. Other than the employees at Github, who's prying eyes would be able to peruse the code? WRT 3.c: By secure I meant a user/password protected, SSL connection to a web-based UI over a private and (hopefully :-) secure Git repo hosted by a Git hosting provider. So, based upon your thorough reply, it appears that Git will do everything we need it to do (and more). And we will review the options for off-site secure repository backup to determine where the best cost/benefit will be for our organization. Thank you again for your counsel, Greg On Wednesday, January 9, 2013 9:09:28 AM UTC-8, Konstantin Khomoutov wrote: On Tue, 8 Jan 2013 15:51:18 -0800 (PST) Greg i.a...@comcast.net javascript: wrote: [...] 1. A general architecture as follows: a. Distributed repository model where local branches are permitted and all repositories are kept in sync with reasonable latency (I believe Git does this; please correct me if I'm wrong) This sounds like some kind of marketing speak so it's not quite clear what's being asked here. If you ask about some sort of *automated* synchronizing of developers' repos to a central (master, blessed, reference or whatever else you'd like to call it) repo then no, Git can't do it by itself. If what's hidden behind this phrase is whether developers are able to periodically push their work somewhere then the answer is yes (obviously). But such pushes are only done voluntarily unless you deploy some sort of crazy scheme which would use a scheduler and some custom code to automate such a task. In general, when working with Git, a policy regarding code organisation and workflow is developed and agreed upon, then everyone follows it. b. Capable of synchronization with a secure repository in the cloud as redundant off-site storage (either free or subscription) Another case of marketing speak: the word cloud is so tired everyone has its own set of meanings for it. To provide an off-site emergency storage for your Git repo(s), you have several possibilities: * Buy private hosting from a Git hosting provider (such as bitbucket, github etc) -- this is really a no-brainer setup. * Buy a VPS or a dedicated server (running a Linux-based OS) and host your backup repos on it -- this is slighty harder to set up, but only slightly. These two possibilities suffer from the same syndrome: they won't protect your code from a prying eye and are unable to keep your trade secret, if any, so there's another one: * Buy/rent some storage (be it a server or a dropbox-like service) and periodically upload there encrypted backups of your repos made by the `git bundle` tool (which is an integral part of Git). This is not bandwidth-effective but should in exchange be reasonably safe security-wise. 2. Provide a seamless developer SCM experience from within the following development environments: a. Microsoft Visual Studio (HTML/JavaScript/C# development for PC/Windows and Windows Phone) No native (i.e. made by Microsoft) tool, but Git Extensions [1] claims to have support for the whole range of contemporary MS IDEs. I have only used Git Extensions in the standalone mode, and it rocks. b. Eclipse (HTML/JavaScript/Java development for Android devices) Yes, via its EGIT plugin [2]. I, again, have no personal experience with it, but it's reported to work OK. c. Apple Xcode (HTML/JavaScript/Objective-C development for Mac/OS X, iPad, iPod, and iPhone) XCode has built-in support for Git -- at least version 4.2 running on Mac OS X 10.6.8 (I've had a chance to tinker with it just today). 3. Provide full-featured user interfaces for the following platforms (particularly where IDE integration in #2 above is not available): Not sure what does full-featured really means here. On all platforms Git is ported to (namely, everything POSIX, including Mac OS X, and Windows), it comes with its full set of command-line utilities and its two standard GUI tools (`git gui` for arranging commits and working with remote repos and `gitk` which is a graphical history browser). Git's command line tools are able to work with a wide set of diffing GUI software (such as vimdiff, meld, KDiff etc) and could be set up for custom
[git-users] Git off-site security
This may be a rather ignorant question. It is based on the thread: Can Git do all of this?. Konstantin indicated that Web suppliers such as GitHub are not secure. Why is this? Well, I guess maybe they could be hacked from the outside, or perhaps an employee could be subverted. I am wondering why there is not an git _option_ to mark a repository as insecure. When something is pushed to this insecure repository, the files being pushed would be encrypted as they are being transferred (read data, encrypt, then send). The reverse on a fetch or pull (receive, decrypt, write). This would leave the files unencrypted on the user's machine. I don't know git internals, but is there some reason why the remote repository cannot have its files be encrypted on the user's machine before transferring to the insecure machine? I don't think anybody _in this case_ would directly use the files on the server. I am aware that encryption will increase their size. I don't know, but I guess this would inhibit some operations such as gc and maybe fsck. But are those operations truly necessary on a storage-only git repository? Again, my ignorance is showing. I would think that the encryption used would require a properly signed digital certificate. How to distribute this cert to the appropriate people is left as an exercise for the reader. Thanks for your thoughts. --
[git-users] git-archive against a smart-http repo?
A user reported that they can't git-archive against our smart-http based repos. According to documentation, it should work. I can reproduce it not working against my repos, as well as a random open git repo using smart-http on the internet. Has anyone gotten this to work? Example: $ git archive --verbose --format=zip --remote=http://code.toofishes.net/git/dan/initscripts.git fatal: Operation not supported by protocol. Unexpected end of command stream --
Re: [git-users] Git off-site security
From: John McKown john.archie.mck...@gmail.com This may be a rather ignorant question. It is based on the thread: Can Git do all of this?. Konstantin indicated that Web suppliers such as GitHub are not secure. Why is this? Well, I guess maybe they could be hacked from the outside, or perhaps an employee could be subverted. I am wondering why there is not an git _option_ to mark a repository as insecure. When something is pushed to this insecure repository, the files being pushed would be encrypted as they are being transferred (read data, encrypt, then send). The reverse on a fetch or pull (receive, decrypt, write). This would leave the files unencrypted on the user's machine. To implement this, you couldn't just encrypt the block of data sent to the remote repository, because then the remote repository couldn't organize proper shared data structures to represent all the commits. You'd have to encrypt the contents of each file individually. That would require the operations of sending/receiving from the repository to regenerate the directory-tree and commit objects based on the different file contents in the two repositories. That is a lot of code to put into a system which is not strongly worried about security. And if you want the remote Git to be able to see blocks of lines moved from one file to another, you have to arrange that any given line is encrypted the same way, regardless of where it appears in any file. That's possible, I think, with a degree of security, but makes the data cryptographically soft. (Hash the line concatenated to the secret key, use the hash to generate a keystream, XOR the keystream with the contents of the line, ciphertext is the hash concatenated with the XORed line contents.) If you want to implement it simply, I'd suggest having a program that synchronizes an unencrypted working copy directory with an encrypted Git working copy directory: make a change in the code, sync to the encrypted file tree, Git check in, push to remote repository. Otherwise, you have to change the plumbing deep down in Git. Dale --
Re: [git-users] Git off-site security
Thanks for explaining. I guess the way to do a cloud backup would be to do a git archive and then encrypt and scp the archive to the cloud. On Wed, Jan 9, 2013 at 2:30 PM, Dale R. Worley wor...@alum.mit.edu wrote: From: John McKown john.archie.mck...@gmail.com This may be a rather ignorant question. It is based on the thread: Can Git do all of this?. Konstantin indicated that Web suppliers such as GitHub are not secure. Why is this? Well, I guess maybe they could be hacked from the outside, or perhaps an employee could be subverted. I am wondering why there is not an git _option_ to mark a repository as insecure. When something is pushed to this insecure repository, the files being pushed would be encrypted as they are being transferred (read data, encrypt, then send). The reverse on a fetch or pull (receive, decrypt, write). This would leave the files unencrypted on the user's machine. To implement this, you couldn't just encrypt the block of data sent to the remote repository, because then the remote repository couldn't organize proper shared data structures to represent all the commits. You'd have to encrypt the contents of each file individually. That would require the operations of sending/receiving from the repository to regenerate the directory-tree and commit objects based on the different file contents in the two repositories. That is a lot of code to put into a system which is not strongly worried about security. And if you want the remote Git to be able to see blocks of lines moved from one file to another, you have to arrange that any given line is encrypted the same way, regardless of where it appears in any file. That's possible, I think, with a degree of security, but makes the data cryptographically soft. (Hash the line concatenated to the secret key, use the hash to generate a keystream, XOR the keystream with the contents of the line, ciphertext is the hash concatenated with the XORed line contents.) If you want to implement it simply, I'd suggest having a program that synchronizes an unencrypted working copy directory with an encrypted Git working copy directory: make a change in the code, sync to the encrypted file tree, Git check in, push to remote repository. Otherwise, you have to change the plumbing deep down in Git. Dale -- -- Maranatha! John McKown --
Re: [git-users] Can Git do all of this?
On Wed, Jan 09, 2013 at 10:00:07AM -0800, Greg wrote: [...] WRT 1.b: I am surprised by your comment that private Git repos purchased from Github are not secure... they purport to be authenticated and use SSL connections. Other than the employees at Github, who's prying eyes would be able to peruse the code? I did not say they are not secure, I told about different levels of security of various methods to keep your data offsite. I stated that the security of a private repository hosted by a third-party is questionable. This is because being private only keeps your repository from being freely accessed by casual public. But that's all what it means. The repository is physically maintained by that third party (your hosting provider) whose staff has full access to it. It's the same situation as with your webmail account: it's not only you who has access to it but also the organisation who hosts its data. So of course there's the question of which level of security you need. It might be that the level of security just discussed is perfectly acceptable for your needs. But it might be not. As you asked a rather comprehensive question I decided to try to show the full picture so you could make an educated decision. As to the level of security for accessing your github private repos from the outside, it's only as strong as your account's password -- this has to be understood very well. Even if you do use SSH auth which requires using public keys (it's beleived to be quite a strong authentication), to upload these keys on the server, you use regular login to the github web interface, hence whoever succeeded at guessing your password (or happened to just obtain it [1]) could upload their own key. Well, and since github also provides HTTPS transport they wouldn't even need to do that as they could use your password right away to clone your repo. WRT 3.c: By secure I meant a user/password protected, SSL connection to a web-based UI over a private and (hopefully :-) secure Git repo hosted by a Git hosting provider. Ah, that's doable of course: any Git hosting provider offering private repos does provide password-protected and SSL-encrypted access to the web interface, and in the case of deploying your own hosting (say, on a rented server or a VPS) you usually put gitweb behind a web server which is set up to perform whichever sort of authentification/encryption is desired. So, based upon your thorough reply, it appears that Git will do everything we need it to do (and more). And we will review the options for off-site secure repository backup to determine where the best cost/benefit will be for our organization. Well, Subversion would also fulfill all your requirements. It's just... uh... well, okay ;-) 1. https://lwn.net/Articles/531726/ --
Re: [git-users] Git off-site security
On Wed, Jan 09, 2013 at 02:51:57PM -0600, John McKown wrote: Thanks for explaining. I guess the way to do a cloud backup would be to do a git archive and then encrypt and scp the archive to the cloud. That wouldn't preserve the history as `git archive` just extracts the tree from the specified commit and makes a tarball out of it. Hence `git bundle` is a more sensible soultion to the problem as it basically creates a portable blob containing all the history it has been told to process (or all). As a possible bonus, `git bundle` is able to wrap only what's changed since the specified commit so it could in principle be used to set up incremental backups if bandwidth is an issue. --
[git-users] Free Git Book
Hey Git Users! I wrote a Git book awhile ago, and I've recently released the entire thing for free at http://rypress.com/tutorials/git/index.html. It covers a lot of the basic concepts that beginners ask about on this list, so I thought it would be a helpful future reference for everyone. If Thomas, Konstantin, Dale, John, or any of the other regular posters had some time to look at it, feedback would be greatly appreciated (topics you would like to see added, custom configurations that you use everyday, etc). Hope you're all having a happy new year! Ryan --
Re: [git-users] Can Git do all of this?
Thank you again Konstantin for the detailed clarifications! We will carefully consider how secure our code needs to be and then review your recommendations. Greg On Wednesday, January 9, 2013 3:45:59 PM UTC-8, Konstantin Khomoutov wrote: On Wed, Jan 09, 2013 at 10:00:07AM -0800, Greg wrote: [...] WRT 1.b: I am surprised by your comment that private Git repos purchased from Github are not secure... they purport to be authenticated and use SSL connections. Other than the employees at Github, who's prying eyes would be able to peruse the code? I did not say they are not secure, I told about different levels of security of various methods to keep your data offsite. I stated that the security of a private repository hosted by a third-party is questionable. This is because being private only keeps your repository from being freely accessed by casual public. But that's all what it means. The repository is physically maintained by that third party (your hosting provider) whose staff has full access to it. It's the same situation as with your webmail account: it's not only you who has access to it but also the organisation who hosts its data. So of course there's the question of which level of security you need. It might be that the level of security just discussed is perfectly acceptable for your needs. But it might be not. As you asked a rather comprehensive question I decided to try to show the full picture so you could make an educated decision. As to the level of security for accessing your github private repos from the outside, it's only as strong as your account's password -- this has to be understood very well. Even if you do use SSH auth which requires using public keys (it's beleived to be quite a strong authentication), to upload these keys on the server, you use regular login to the github web interface, hence whoever succeeded at guessing your password (or happened to just obtain it [1]) could upload their own key. Well, and since github also provides HTTPS transport they wouldn't even need to do that as they could use your password right away to clone your repo. WRT 3.c: By secure I meant a user/password protected, SSL connection to a web-based UI over a private and (hopefully :-) secure Git repo hosted by a Git hosting provider. Ah, that's doable of course: any Git hosting provider offering private repos does provide password-protected and SSL-encrypted access to the web interface, and in the case of deploying your own hosting (say, on a rented server or a VPS) you usually put gitweb behind a web server which is set up to perform whichever sort of authentification/encryption is desired. So, based upon your thorough reply, it appears that Git will do everything we need it to do (and more). And we will review the options for off-site secure repository backup to determine where the best cost/benefit will be for our organization. Well, Subversion would also fulfill all your requirements. It's just... uh... well, okay ;-) 1. https://lwn.net/Articles/531726/ --
[git-users] Re: Free Git Book
There is a mention of a ebook now being free of charge. Admitting total laziness, it would be great to have a link to the amazon store now free ebook... unless I misunderstood. Thanks. --
Re: [git-users] Free Git Book
On Wed, Jan 09, 2013 at 06:03:40PM -0600, Ryan Hodson wrote: I wrote a Git book awhile ago, and I've recently released the entire thing for free at http://rypress.com/tutorials/git/index.html. It covers a lot of the basic concepts that beginners ask about on this list, so I thought it would be a helpful future reference for everyone. Thanks Ryan. The book is worth reading. :) Iñigo If Thomas, Konstantin, Dale, John, or any of the other regular posters had some time to look at it, feedback would be greatly appreciated (topics you would like to see added, custom configurations that you use everyday, etc). Hope you're all having a happy new year! Ryan -- --
Re: [git-users] Free Git Book
There is a mention of a ebook now being free of charge. Admitting total laziness, it would be great to have a link to the amazon store now free ebook... unless I misunderstood. Sorry, I'm no longer maintaining the Kindle version, but the entire book is available via the link in the original email. Thanks Ryan. The book is worth reading. :) Thanks Iñigo, I appreciate that :) Ryan --
[git-users] Re: Free Git Book
On Thursday, January 10, 2013 1:03:40 AM UTC+1, Ryan Hodson wrote: Hey Git Users! I wrote a Git book awhile ago, and I've recently released the entire thing for free at http://rypress.com/tutorials/git/index.html. It covers a lot of the basic concepts that beginners ask about on this list, so I thought it would be a helpful future reference for everyone. If Thomas, Konstantin, Dale, John, or any of the other regular posters had some time to look at it, feedback would be greatly appreciated (topics you would like to see added, custom configurations that you use everyday, etc). Wow, that looks amazing. Great layout, design, illustrations.. I haven't got the time right now to dig through the content, but it looks really great. I like the webdesign examples. Nice detail that you can download the example repo for each module. Well done! I'll share it on twitter and google+. I hope you get some sponsors on the tutorial, cause it definitely deserves it. --
[git-users] Re: Free Git Book
Oh, and an eBook format would be cool, as Huu Da Tran said. --
[git-users] Re: Free Git Book
I've also suggested they add the book to the external resources list on git-scm.com http://git-scm.com/documentation/external-links : https://github.com/github/gitscm-next/pull/235 --
Re: [git-users] Re: Free Git Book
Thanks Thomas. I actually already did that :). I'll see what I can do about an ebook version. On Jan 10, 2013 1:43 AM, Thomas Ferris Nicolaisen tfn...@gmail.com wrote: I've also suggested they add the book to the external resources list on git-scm.com http://git-scm.com/documentation/external-links: https://github.com/github/gitscm-next/pull/235 -- --
Re: [git-users] Re: Free Git Book
Lol. Thanks for the thought though. On Jan 10, 2013 1:45 AM, Thomas Ferris Nicolaisen tfn...@gmail.com wrote: Uh, never mind, I saw you beat me to it :) On Thursday, January 10, 2013 8:43:57 AM UTC+1, Thomas Ferris Nicolaisen wrote: I've also suggested they add the book to the external resources list on git-scm.com http://git-scm.com/documentation/external-links: https://github.**com/github/gitscm-next/pull/**235https://github.com/github/gitscm-next/pull/235 -- --
