{"thread":{"id":"20280","subject":"How to push properly a la subversion","startedAt":"2009-07-29T18:32:46Z","lastAt":"2009-08-04T21:15:04Z","messageCount":7,"participants":["Matthieu Stigler","Avery Pennarun","Dmitry Potapov","Nanako Shiraishi"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"119089","messageId":"4A7095CE.8030307@gmail.com","threadId":"20280","inReplyTo":null,"subject":"How to push properly a la subversion","fromName":"Matthieu Stigler","fromEmail":"matthieu.stigler@gmail.com","sentAt":"2009-07-29T18:32:46Z","receivedAt":"2009-07-29T18:32:46Z","isPatch":false,"sender":{"key":"matthieu.stigler@gmail.com","avatar":null},"body":"Hi\n\nI'm discovering git switchig from svn, so I'm still confused... I want \nactually to use git but keeping this idea of one common/public repo that \ndifferent users push/pull from.\n\nI tried just by cloning A to B, changing/commiting B and the pushing to \nA but: then on A the last log is integrated but I have this message with \ngitk \"local changes checked in to index but not commited\", and those \nlocal  changes are actually the version of A before the commit from B \n:-( What I expected with svn mentality is that A is changed and updated...\n\nSo 2 questions:\n-how to remedy?\n-hot to avoid?\n\nI could remedy on A by git reset --hard, but ideally I would not need to \nremedy to that...\n\nShould I enter a specifical push option? Or rather work on section \n\"Setting up a shared repository\"? in \nhttp://www.kernel.org/pub/software/scm/git/docs/gitcvs-migration.html ?\nI tried to do it entering:\n\n$ mkdir /pub/my-repo.git\n$ cd /pub/my-repo.git\n$ git --bare init --shared\n$ git --bare fetch /home/alice/myproject master:master\n\nbut then I get also this message \"local changes checked in to index but \nnot commited\" and especially there are many git files appearing that we \nwould not want to see.... And furthermore it seems there are complicated \npermissions/ssh issues that I don't need (I'm doing for now only locally).\n\nSo can those new files be avoided? What is the best way to set-up git to \nhave kind of central repo?\n\nThanks for your precious help!!\n\nMatthieu Stigler\n"},{"id":"119092","messageId":"32541b130907291212p2c079cn2d7a8b17693577b4@mail.gmail.com","threadId":"20280","inReplyTo":"4A7095CE.8030307@gmail.com","subject":"Re: How to push properly a la subversion","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2009-07-29T19:12:32Z","receivedAt":"2009-07-29T19:12:32Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Wed, Jul 29, 2009 at 6:32 PM, Matthieu\nStigler<matthieu.stigler@gmail.com> wrote:\n> I'm discovering git switchig from svn, so I'm still confused... I want\n> actually to use git but keeping this idea of one common/public repo that\n> different users push/pull from.\n>\n> I tried just by cloning A to B, changing/commiting B and the pushing to A\n> but: then on A the last log is integrated but I have this message with gitk\n> \"local changes checked in to index but not commited\", and those local\n>  changes are actually the version of A before the commit from B :-( What I\n> expected with svn mentality is that A is changed and updated...\n\nYou need to configure A as a \"bare\" repository.  For example:\nhttp://toolmantim.com/articles/setting_up_a_new_remote_git_repository\n\nFuture versions of git will prevent you from accidentally getting A\ninto the inconsistent state that you've managed to produce.\n\nAvery\n"},{"id":"119093","messageId":"20090729195044.GA27178@dpotapov.dyndns.org","threadId":"20280","inReplyTo":"4A7095CE.8030307@gmail.com","subject":"Re: How to push properly a la subversion","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2009-07-29T19:50:44Z","receivedAt":"2009-07-29T19:50:44Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Wed, Jul 29, 2009 at 08:32:46PM +0200, Matthieu Stigler wrote:\n>\n> I tried just by cloning A to B, changing/commiting B and the pushing to  \n> A but: then on A the last log is integrated but I have this message with  \n> gitk \"local changes checked in to index but not commited\", and those  \n> local  changes are actually the version of A before the commit from B  \n> :-( What I expected with svn mentality is that A is changed and \n> updated...\n\nThis is because git-push does not change your working tree. So, your\nnormally should never push to the branch that is currerently checked\nout. (New versions of Git will warn you about that). As to having a\ncommon/shared repo, it should be a \"bare\" repository.\n\n>\n> Should I enter a specifical push option? Or rather work on section  \n> \"Setting up a shared repository\"? in  \n> http://www.kernel.org/pub/software/scm/git/docs/gitcvs-migration.html ?\n> I tried to do it entering:\n>\n> $ mkdir /pub/my-repo.git\n> $ cd /pub/my-repo.git\n> $ git --bare init --shared\n> $ git --bare fetch /home/alice/myproject master:master\n>\n> but then I get also this message \"local changes checked in to index but  \n> not commited\" and especially there are many git files appearing that we  \n> would not want to see....\n\nStrange... The above commands work perfectly for me.... And if you have\na bare repo then it should not have 'index'. So, the error does not make\nmuch sense to me... Is it produced by gitk? Hmm, maybe some old version\nof gitk did not work correctly with a bare repo... I dunno...\n\n> And furthermore it seems there are complicated  \n> permissions/ssh issues that I don't need (I'm doing for now only \n> locally).\n\nI don't understand your troubles with permissions. Basically, there are\ntwo options to setup a shared repo:\n1. where every developer has each own account\n2. a single account (but still each has each own ssh key)\n\nThe 'shared' option during init is necessary only for the first case to\nmake repository group writable. All users who can push to it should be\nmembers of the group.\n\nIf you want to have a single system account for all users, you have two\noptions:\n- gitosis\n- ssh based authentification with forced command and then update hook\n  if extra check is needed (see Documentation/howto/update-hook-example.txt)\n\n\nDmitry\n"},{"id":"119168","messageId":"20090730115448.GB27178@dpotapov.dyndns.org","threadId":"20280","inReplyTo":"111060c20907300111u4345b1f1x784229c066fb3f88@mail.gmail.com","subject":"Re: How to push properly a la subversion","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2009-07-30T11:54:48Z","receivedAt":"2009-07-30T11:54:48Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Thu, Jul 30, 2009 at 10:11:43AM +0200, Matthieu Stigler wrote:\n> \n> Furthermore, there are reluctant to install any new softwares\n> and to use command line software,\n\nActually, gitk and 'git gui' are very nice... Well, I do prefer the\ncommand line, but I still use gitk to see the history. There are\nsome other GUIs out there, but they should be installed separately.\n\n> I used for now portable GIT on windows,\n> which seems to have also ssh.\n\nssh client works fine on Windows, but I have never installed a shared\nrepo on Windows, which would require to install a ssh server. So, I\ndon't think I can help here.\n\n> So I understood that I need to set-up a shared repo, thanks for your\n> advices! Now do I really need all those permissions issues? What is the\n> simplest way to deal with that?\n\nIf you want to have a shared repo then every developer should have the\nwrite access to it and every file created by any developer should be\nwritable by other developers in the same group. To prevent any developer\nfrom removing anything on the server, they should not have the normal\naccess to it but only through git-shell (i.e. git-shell should be\nspecified as the login shell). Now, it is often inconvinient to have\nmany special users accounts. So, you can use gitosis, which requires\nonly one user account and identified users by their SSH key. I heard\nthat some people set up it on Windows, but it was Cygwin version of Git.\n\nAs to the simplest way, it is probably to use a distributed workflow:\neach developer has their own repo, which is writable for him/her and\nreadable for other developers. (You can easily to do with sharable\nfolders by assigning appropriate permissions, and you probably will not\nneed to deal with SSH at all). In this workflow, every group has each\nown team leader or co-ordinator, who is responsible for integration\nother people work. Then the repo of the team leader will becomes the\n\"official\" repo of the project, but it is only social a convention and\nnot a technical one. Any developer can fetch from any repository (see\nalso git-remote). IMHO, the distributed workflow is far superior to\nhaving everyone to push to the same repo.\n\nIn fact, as closer you emulate SVN workflow, more SVN issues, you will\npick up. For instance, 'svn commit' does two things: it creates a new\ncommit and propogate this changes to the server. In general, it is a\nvery bad thing to do, because you end up with a lot of work-in-progress\ncommits, which may be steps in the wrong direction, but they interfere\nwith other people work. With Git even using a central repo, you can do\nbetter -- developers can push their work when they have finished.\nStill, you may want to have some code review process. How are you going\nto organize that? And then when someone works on some feature or have\nsome other work-in-porgress, you still want that this work will be\nproperly backed up (or at least, store more than in one place). So, you\nnaturally want to give every developer repo on that server where he/she\ncan push their work _before_ it is become part of the official history\nof the project. And, finally, it is always good to have someone who\nco-ordinates everyone's efforts, so intergation will be not randomly but\nbased on priorities and quality of one's work...\n\n\nDmitry\n"},{"id":"119472","messageId":"111060c20908040017y753a3cb4mbc4d7654192a5d1a@mail.gmail.com","threadId":"20280","inReplyTo":"20090730115448.GB27178@dpotapov.dyndns.org","subject":"Re: How to push properly a la subversion","fromName":"Matthieu Stigler","fromEmail":"matthieu.stigler@gmail.com","sentAt":"2009-08-04T07:17:45Z","receivedAt":"2009-08-04T07:17:45Z","isPatch":false,"sender":{"key":"matthieu.stigler@gmail.com","avatar":null},"body":"Hi Dmitry and all\n\nThanks for taking time to explain me in details the philosophy of git\nvs svn, it helped me a lot. Two comments/questions:\n\nThe first is that as you say,\n>'svn commit' does two things: it creates a new commit and propogate this changes to the server\n\nThis was a source of confusion for me and I did not get it\nimmediately. Maybe be help page git-svn crash course could be more\ndetailed about that? It just mentions the analogy git commit -a /svn\ncommit (so the first step you mention) but not the second (svn commit\nis similar to git push also)? Personaly, I think this could help a lot\nnewbies like me ;-)\n\nSecond, you said\n> So, your normally should never push to the branch that is currerently checked out. (New versions of Git will warn you about that).\n\nIs there a way to avoid that? Manually, do I just need on post A\n(against which it was pushed from clone B) to use:\ngit-reset --hard HEAD\n\nAnd if yes, can I automate that in hooks/post-update in A? Or post-commit in B?\n\nThanks a lot!\n\nMatthieu\n\n2009/7/30 Dmitry Potapov <dpotapov@gmail.com>:\n> On Thu, Jul 30, 2009 at 10:11:43AM +0200, Matthieu Stigler wrote:\n>>\n>> Furthermore, there are reluctant to install any new softwares\n>> and to use command line software,\n>\n> Actually, gitk and 'git gui' are very nice... Well, I do prefer the\n> command line, but I still use gitk to see the history. There are\n> some other GUIs out there, but they should be installed separately.\n>\n>> I used for now portable GIT on windows,\n>> which seems to have also ssh.\n>\n> ssh client works fine on Windows, but I have never installed a shared\n> repo on Windows, which would require to install a ssh server. So, I\n> don't think I can help here.\n>\n>> So I understood that I need to set-up a shared repo, thanks for your\n>> advices! Now do I really need all those permissions issues? What is the\n>> simplest way to deal with that?\n>\n> If you want to have a shared repo then every developer should have the\n> write access to it and every file created by any developer should be\n> writable by other developers in the same group. To prevent any developer\n> from removing anything on the server, they should not have the normal\n> access to it but only through git-shell (i.e. git-shell should be\n> specified as the login shell). Now, it is often inconvinient to have\n> many special users accounts. So, you can use gitosis, which requires\n> only one user account and identified users by their SSH key. I heard\n> that some people set up it on Windows, but it was Cygwin version of Git.\n>\n> As to the simplest way, it is probably to use a distributed workflow:\n> each developer has their own repo, which is writable for him/her and\n> readable for other developers. (You can easily to do with sharable\n> folders by assigning appropriate permissions, and you probably will not\n> need to deal with SSH at all). In this workflow, every group has each\n> own team leader or co-ordinator, who is responsible for integration\n> other people work. Then the repo of the team leader will becomes the\n> \"official\" repo of the project, but it is only social a convention and\n> not a technical one. Any developer can fetch from any repository (see\n> also git-remote). IMHO, the distributed workflow is far superior to\n> having everyone to push to the same repo.\n>\n> In fact, as closer you emulate SVN workflow, more SVN issues, you will\n> pick up. For instance, 'svn commit' does two things: it creates a new\n> commit and propogate this changes to the server. In general, it is a\n> very bad thing to do, because you end up with a lot of work-in-progress\n> commits, which may be steps in the wrong direction, but they interfere\n> with other people work. With Git even using a central repo, you can do\n> better -- developers can push their work when they have finished.\n> Still, you may want to have some code review process. How are you going\n> to organize that? And then when someone works on some feature or have\n> some other work-in-porgress, you still want that this work will be\n> properly backed up (or at least, store more than in one place). So, you\n> naturally want to give every developer repo on that server where he/she\n> can push their work _before_ it is become part of the official history\n> of the project. And, finally, it is always good to have someone who\n> co-ordinates everyone's efforts, so intergation will be not randomly but\n> based on priorities and quality of one's work...\n>\n>\n> Dmitry\n>\n"},{"id":"119487","messageId":"20090804120446.GD10264@dpotapov.dyndns.org","threadId":"20280","inReplyTo":"111060c20908040017y753a3cb4mbc4d7654192a5d1a@mail.gmail.com","subject":"Re: How to push properly a la subversion","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2009-08-04T12:04:47Z","receivedAt":"2009-08-04T12:04:47Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Tue, Aug 04, 2009 at 09:17:45AM +0200, Matthieu Stigler wrote:\n> \n> This was a source of confusion for me and I did not get it\n> immediately. Maybe be help page git-svn crash course could be more\n> detailed about that? It just mentions the analogy git commit -a /svn\n> commit (so the first step you mention) but not the second (svn commit\n> is similar to git push also)? Personaly, I think this could help a lot\n> newbies like me ;-)\n\nI see that it may be a source for confusion if you look at it from the\nteam workflow POV, you can even say that 'git push' is analogue of 'svn\ncommit'. But it is a general principle of Git that all commands except\nspecifically designed to propagation changes ('fetch', 'push', 'pull'\nand 'remote') to work locally. So, it is not only that all commits are\ncreated locally but also branches, tags, etc. And, though, your repo may\nbe visible to other directly, but it is more commonly that you have to\npush your changes to some bare repository on the server where it can be\nseen by other developers.\n\nSo, I am not sure how better to state that in \"Git - SVN Crash Course\",\nand what is the right place for that. Maybe, a few words should be added\nto the section titled \"Things You Should Know\", but I am not sure about\nwording. Your suggestions are welcome.\n\n> \n> Second, you said\n> > So, your normally should never push to the branch that is currerently checked out. (New versions of Git will warn you about that).\n> \n> Is there a way to avoid that? Manually, do I just need on post A\n> (against which it was pushed from clone B) to use:\n> git-reset --hard HEAD\n\nNormally, you should push to a bare repository, so it not an issue. Yet,\nthere are some situations when it can happen. For instance, you have two\ncomputers on which you work and you want to push your work from one them\nto another directly without using any bare repo. In this case, you can\nuse 'git reset --hard HEAD' after push (and it can be done automatically\nby hooks) but you should be *sure* that uncommitted changes in that\nworking directory, otherwise they will be lost. So, I really don't think\nit is a good idea to do automatically. There are a few alternatives\nthough. Instead of pushing to the checkout branch, you can push to a new\nbranch (See refspec for details). There is also Johannes Schindelin's\npatch called \"Add a few more values for receive.denyCurrentBranch\",\nwhich adds the 'updateInstead' value. It may be want you want, but it is\nnot included to the official Git, because there very few users who want\nto this feature.\n\nDo you really foresee a setup where you will push to a non-bare repo\nquite often?\n\n\nDmitry\n"},{"id":"119523","messageId":"20090805061504.6117@nanako3.lavabit.com","threadId":"20280","inReplyTo":"111060c20908040017y753a3cb4mbc4d7654192a5d1a@mail.gmail.com","subject":"Re: How to push properly a la subversion","fromName":"Nanako Shiraishi","fromEmail":"nanako3@lavabit.com","sentAt":"2009-08-04T21:15:04Z","receivedAt":"2009-08-04T21:15:04Z","isPatch":false,"sender":{"key":"nanako3@lavabit.com","avatar":"https://gravatar.com/avatar/3777b9e201c5883a62b1a6fdf7c53f2d712d1d80989146063ea861e33aad72a8?d=mp&s=160"},"body":"Quoting Matthieu Stigler <matthieu.stigler@gmail.com>\n\n> 2009/7/30 Dmitry Potapov <dpotapov@gmail.com>:\n>\n> Second, you said\n>> So, your normally should never push to the branch that is currerently checked out. (New versions of Git will warn you about that).\n>\n> Is there a way to avoid that? Manually, do I just need on post A\n> (against which it was pushed from clone B) to use:\n> git-reset --hard HEAD\n>\n> And if yes, can I automate that in hooks/post-update in A? Or post-commit in B?\n\nThe standard way to communicate changes to a repository with a working tree A from your repository B is to pretend as if A fetches from B even when you are pushing from B to A..\n\nHere are some recommended readings:\n\n * http://git.or.cz/gitwiki/GitFaq#Whywon.27tIseechangesintheremoterepoafter.22gitpush.22.3F\n * http://git.or.cz/gitwiki/GitFaq#push-is-reverse-of-fetch\n\n * \"Push into another repository\" item in http://www.kernel.org/pub/software/scm/git/docs/everyday.html illustrates this with an example.\n\n * http://article.gmane.org/gmane.comp.version-control.git/123331\n\n-- \nNanako Shiraishi\nhttp://ivory.ap.teacup.com/nanako3/\n"}]}