RE: Question re. git remote repository
From: git-ow...@vger.kernel.org [git-ow...@vger.kernel.org] on behalf of Lang, David [david.l...@uhn.ca] I thought the idea was that each developer installed git locally on their machines Yes. and (as needed) committed their changes to the master repository which resides externally to any of the local machines, such as on a network server Yes, but committing their changes to the master repository is a two step process: 1. Each developer first commits their changes to their personal repository using the git commit command. 2. Each developer pushes their changes from their personal repository to the master repository with the git push command (and which I'm assuming has git installed locally as well). Maybe. If the machine with the master repository has git installed locally, then each developer can push their changes to the master repository using either the git protocol or the ssh protocol. If the machine with the master repository does not have git installed locally, then each developer can push their changes to the master repository using NFS or CIFS/SMB. The git documentation refers to this method as the file protocol. The other David Lang (da...@lang.hm) believes that using git push using NFS or CIFS/SMB may not be safe and reliable. Based on the following article by the creator of git, I believe using git push over NFS or CIFS/SMB is safe and reliable: http://permalink.gmane.org/gmane.comp.version-control.git/122670 The GitFaq wiki also says that using git push over NFS or CIFS/SMB is safe and reliable: https://git.wiki.kernel.org/index.php/GitFaq#What_can_I_use_to_set_up_a_public_repository.3F -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question re. git remote repository
Konstantin Khomoutov kostix+...@007spb.ru wrote in message news:20130116233744.7d0775eaec98ce154a9de...@domain007.com... On Wed, 16 Jan 2013 10:21:56 -0800 Jeff King p...@peff.net wrote: I agree that performance is not ideal (although if you are on a fast LAN, it probably would not matter much), but I do not recall any specific bugs in that area. Can you elaborate? Of course, if there are happy users of such setups, I would be glad to hear as my precautions might well be unfounded for the recent versions of Git. I'm a happy user of git on network file systems (NFS and CIFS/SMB), although not a heavy user. 1. http://code.google.com/p/msysgit/issues/detail?id=130 I wouldn't be surprised if there are some subtle POSIX-Win32 compatibility issues here between msysgit and Samba (POSIX GIT, ported to use Win32 file system functions, sending those Win32 requests to a Samba server, and the Samba server translating those Win32 requests back into POSIX functions). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question re. git remote repository
David Lang da...@lang.hm wrote in message news:alpine.deb.2.02.1301161459060.21...@nftneq.ynat.uz... But if you try to have one filesystem, with multiple people running git on their machines against that shared filesystem, I would expect you to have all sorts of problems. What leads you to think you will have problems? Why would there be more of a problem on a network file system as opposed to local file system that can be accessed by multiple users? Linus seemed to think it should work: http://permalink.gmane.org/gmane.comp.version-control.git/122670 And git init specifically has a shared option: --shared[=(false|true|umask|group|all|world|everybody|0xxx)] Specify that the git repository is to be shared amongst several users. This allows users belonging to the same group to push into that repository. When specified, the config variable core.sharedRepository is set so that files and directories under $GIT_DIR are created with the requested permissions. When not specified, git will use permissions reported by umask(2). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Question re. git remote repository
From: David Lang [mailto:da...@lang.hm] On Wed, 16 Jan 2013, Matt Seitz (matseitz) wrote: Linus seemed to think it should work: http://permalink.gmane.org/gmane.comp.version-control.git/122670 In the link you point at, he says that you can have problems with some types of actions. He points out things like git prune, Linus wrote: You do need to be a bit careful if you do maintenance operations concurrently (I would suggest avoiding doing concurrent git gc --prune, for example), but any normal git workflow should be fine. but I would also say that there are probably race conditions if you have two git processes that try to change the HEAD to different things at the same time. What makes you think there are race conditions? Linus wrote: And git doesn't have proper locking, because it doesn't need it for database ops: git objects are stable. For refs, git should be using the proper NFS-safe create and atomic rename ops. And git init specifically has a shared option: --shared[=(false|true|umask|group|all|world|everybody|0xxx)] I think this is dealing with multiple users _reading_ a repository, not making updates to it at the same time. The description of shared says This allows users belonging to the same group to push into that repository. The push command is about making updates. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Question re. git remote repository
From: David Lang [mailto:da...@lang.hm] Linus says that git does not have proper locking, so think about it, what do you think will happen if person A does git add a/b; git commit and person B does git add c/d; git commit? Sorry, I wasn't clear. My assumption is that a shared repository on a network file system will either be: 1. a bare repository that is normally accessed only by git push and git pull (or git fetch), the central repository model. 2. a repository where only one user does git add and git commit, while other users will do git pull, the peer-to-peer model (you pull changes from me, I pull changes from you). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Question re. git remote repository
From: David Lang [mailto:da...@lang.hm] On Thu, 17 Jan 2013, Matt Seitz (matseitz) wrote: 1. a bare repository that is normally accessed only by git push and git pull (or git fetch), the central repository model. pulling from it would not be a problem, I could see issues with multiple pushes taking place (the underlying repository would not get corrupted, but you will very quickly hit conflicts where the push is not a fast forward and you need to merge, not just push) How is that different on a network file system, as opposed to using http, ssh, or git-daemon? Don't you get a not a fast-forward error, regardless of the protocol? 2. a repository where only one user does git add and git commit, while other users will do git pull, the peer-to-peer model (you pull changes from me, I pull changes from you). pulling from a shared repository is probably safe, but I wouldn't bet against there being any conditions where a pull at the same time someone is doing an update being able to cause problems. Why do you think there would be a problem? The normal thing is to do the pulls through git-daemon, and that does make sure that what you are pulling is consistant. What does git pull via git-daemon do to ensure consistency that is different from git pull on a network file system? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question re. git remote repository
David Lang da...@lang.hm wrote in message news:alpine.deb.2.02.1301161843390.21...@nftneq.ynat.uz... On Thu, 17 Jan 2013, Matt Seitz (matseitz) wrote: 2. a repository where only one user does git add and git commit, while other users will do git pull, the peer-to-peer model (you pull changes from me, I pull changes from you). you may _be_ safe, and if others who really know the internals speak up, take their word on it. Well, we already have Linus's article. I guess the question is whether the use case I describe above falls under: A. maintenance operations B. normal git workflow Personally, I would consider this use case to be a normal git workflow. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git send-email should not allow 'y' for in-reply-to
Jeff King p...@peff.net wrote in message news:2013085417.ga12...@sigill.intra.peff.net... On Fri, Jan 11, 2013 at 10:43:39AM -0800, Hilco Wijbenga wrote: How about What Message-ID to use as In-Reply-To for the first email? or Provide the Message-ID to use as In-Reply-To for the first email:. seem fine to me. Maybe somebody who has been confused by it can offer more. At any rate, patches welcome. Suggestion: Message-ID to use as In-Reply-To for the first email:. Simple and unlikely to generate a y or n response. Putting Message-ID first makes it more obvious what data is being asked for by this prompt. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
