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: 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