Re: [git-users] newbie questions
From: Ed Pataky ed.pat...@gmail.com Can you have multiple access points within a repo? What I mean is, suppose i have a repo accessing: ./DIR/ And I want some people to access ./DIR/FOLDER1/ and other to access ./DIR/FOLDER2/ But I want access to the whole thing .. can I make each folder including the parent folder DIR a git repo, so they can connect to the subfolders but not the main folder? My understanding is that is not possible; repositories are indivisible. (As opposed to Subversion, where you can check out a subtree of the controlled directory structure.) Dale -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] newbie questions
Can you have multiple access points within a repo? What I mean is, suppose i have a repo accessing: ./DIR/ And I want some people to access ./DIR/FOLDER1/ and other to access ./DIR/FOLDER2/ But I want access to the whole thing .. can I make each folder including the parent folder DIR a git repo, so they can connect to the subfolders but not the main folder? On Sat, Jun 29, 2013 at 9:38 PM, Ed Pataky ed.pat...@gmail.com wrote: If I setup a bare repo, and all developers track their changes, all is good .. but then one developer makes a bunch of changes that were not tracked and files are out of sync .. how do i tell GIT to revert back to the old file versions when everything was ok? On Sat, Jun 29, 2013 at 8:15 AM, Ed Pataky ed.pat...@gmail.com wrote: thank you very helpful i am seeing everywhere that a bare repo is the way to go for distributed developers .. it seems to me we should essentially make a rule that you make your changes and test locally if possible, then ftp them to the server when ok ... once all done the next step is (i am choosing SourceTree Gui) stage changes, commit and push .. My only question now is can developers have different set of files in thier local repos? for example i use python and other developers use php, and we all edit html as well...so in my repo i added only html and python and in thiers i would tell them to add thier php ad the same html .. is there any issue with this? i just do not want to download the entire website directory contents because it is huge On Saturday, June 29, 2013, aft wrote: You have some fundamental misconception about how git works. 1. Its not a deploying tool. Your git server is only meant for providing a neat way to synchronize everyone's work. Not for deployment. Best idea is to make your release tarballs from your local dev machine and ftp it into the server. Don't use the files inside server's repo as production use. 2. Git does not recognize a file by its file_name. It considers files as blob object, which resides in tree object. A particular tree snapshot makes a commit object, some pointer to a commit object is branch object etc. All these objects has unique ID , identified by a SHA1 checksum. Now if you edit a file, its SHA1 hash changes, so from git's perspective its no longer the same blob object, its a different object. That's why you have to git add every time you make modification on a file. you have to do git status to see what have changed since last commit. And decide which changes should go into a particular commit, git add them, then do git commit. There is a shortcut git commit -a which adds all the changes. But i prefer adding them by hand because that way i can organize my commit. If two edits are functionally separate, they should reside in different commits. A commit should not be larger then one screen full of edits. If its a huge, then you're doing something wrong. Because the idea of VCS gets killed if your diffs are huge to comprehend. 3) My advice is git is for managing source code versions and its useful for the developers. Your deployment strategy should not be based on git. It should be different. Tag your releases. Use git archive to make release tarballs. Then push them in the production server for deployment. You can write scripts which can automate the whole process. On Sat, Jun 29, 2013 at 2:21 PM, Ed Pataky ed.pat...@gmail.com wrote: Gergely you said Again, you can only do this if you don't need the source files to be present on the server, or you can clone it to a separate directory to access, test or serve them. ... I do not understand this .. why cant the files be on the server? I have a std web server with web files ... scripts, html, etc .. can I not use this bare repo idea for this? Why not? ed On Fri, Jun 28, 2013 at 11:22 AM, Gergely Polonkai gerg...@polonkai.eu wrote: Hello, if I was you, I would use a bare repository on the server side. This will render the server's repository unreadable for the human eye, but the server-side merging would become unnecessary. To do this, create a new directory on the server, and issue the command git init --bare in it. After that, simply `git push` into it from your local machine, and tell your developers to use that repo from then on (or overwrite the old plain text repository with the new, bare one). Again, you can only do this if you don't need the source files to be present on the server, or you can clone it to a separate directory to access, test or serve them. Best, Gergely On 28 Jun 2013 20:14, HWSWMAN ed.pat...@gmail.com wrote: Ok, I want to start over after having spent a few hours trying things ... Here is my situation ... I need to use GIT for some source control .. i have never used any source control before and I want to use it in the simplest possible way first, to get running, and have
Re: [git-users] newbie questions
Question: lets say i want to go with the bare repo idea ... i set one up, i cloned it to my pc .. ok cool Now what if i typically work on files ABC and my developers work on DEF ... do i need to add all the files A-F to my machine, or can i just add the ones i need to work on ? ... in other words, does every developer have to have an entire copy of the server, or can we all just have the copies we work on and GIT still track the whole thing as one thing? On Fri, Jun 28, 2013 at 7:07 PM, Ed Pataky ed.pat...@gmail.com wrote: So suppose i have a git repo setup, and someone adds a file that should not be there, or deletes a file they should not have, through ssh or ftp ... how do i go about reversing their change back to the last commit point? On Fri, Jun 28, 2013 at 1:58 PM, John McKown john.archie.mck...@gmail.com wrote: You can roll back to any commit point. You can roll back all changes to that point. Or one or more files. Or just look at the contents of a file as of that commit point. Perhaps I misunderstood, but I got the impression you thought that git would automatically keep every change made to a file without any action on the part of the user. As to ftp, you are correct. git does not control _how_ the file is changed. You can use any method that you have available to you. You can ftp the file somewhere else, modify it, then ftp it back. You can use an editor to edit it in place. You can run a program which modifies it somehow (like maybe using Perl to do something, or have a tidy program reformat it). If you have permission, you can even delete it and git won't stop you. But however you modify it, so long as nobody destroys the contents of the .git subdirectory, you can recover any file to any commit point (generally, there are obscene ways to modify the git repository which can royally mess it up). What I often do is edit one or more files in a project. I test the changes until I like the results. When I like the results, I do a git add -A . and git commit to put the changes in the local git repository. If I decide that I have royally messed up before I do any comit, I do a git reset --hard HEAD to revert all the files. Now, suppose I did the commit and then decided that I was wrong to do so. I can go back to the previous version with git revert --hard HEAD~1 to revert the files to the commit point before the bad commit point. But, instead, if I like most of the changes, but maybe there is one which I decide is a mess. I don't revert all the files. I can do git checkout HEAD~1 -- some.file. This restores the some.file to the point it was before I did the current commit. I can then fix that one file, eventually doing a git add -A . and git commit again. Note that the bad version of the file still exists in the git history. There are ways to eliminate the bad commit, but I never use them because I've never felt comfortable doing so. It is, to me, quite complicated. I guess I'm still confused as to what you really want git to do. In my way of thinking, git gives me a way to take a snapshot of a set of files at a point in time (via the git add and git commit). And a way to revert any or all of those files back to that point in time if I need to. git does say whether I can modify a file or not. Nor _how_ I can modify that file. It just allows me to take a point in time snapshot, more or less. It can do more, but that is the big part of it, to me. It can tell you what change between snapshots and by whom (if you set it up that way) and other things. On Fri, Jun 28, 2013 at 3:27 PM, Ed Pataky ed.pat...@gmail.com wrote: So you are saying that there is no way to rollback to an old version using git? what is the point then, just to store a bunch of comments? On Fri, Jun 28, 2013 at 12:59 PM, John McKown john.archie.mck...@gmail.com wrote: I will have to note that you seem to have a non-standard definition of version control. git, and other version control software such as Subversion, Mercurial, CVS, Visual Source Safe (or whatever MS calls it), don't track all changes to every file every time the file is modified. They only supply commands so that, at the direction of a user, a snapshot of the file(s) can be taken and tracked. With git, this is the git add and git commit commands. The git commit is what takes the actual snapshot. The git add puts the contents of the files to be updated/added in the snapshot into the index. The git commit actually snapshots the index information into the local git data base (kept in the .git subdirectory) . Perhaps, you eventually update the bare repository using a git push command. Assuming you even keep a bare directory. On some of my personal stuff, I don't because I don't share it with others. Neither is git a security system. If you have been granted write access to a file, it is done using the host operating system's security mechanisms; whatever they may be. In Linux, that is with
Re: [git-users] newbie questions
Gergely you said Again, you can only do this if you don't need the source files to be present on the server, or you can clone it to a separate directory to access, test or serve them. ... I do not understand this .. why cant the files be on the server? I have a std web server with web files ... scripts, html, etc .. can I not use this bare repo idea for this? Why not? ed On Fri, Jun 28, 2013 at 11:22 AM, Gergely Polonkai gerg...@polonkai.euwrote: Hello, if I was you, I would use a bare repository on the server side. This will render the server's repository unreadable for the human eye, but the server-side merging would become unnecessary. To do this, create a new directory on the server, and issue the command git init --bare in it. After that, simply `git push` into it from your local machine, and tell your developers to use that repo from then on (or overwrite the old plain text repository with the new, bare one). Again, you can only do this if you don't need the source files to be present on the server, or you can clone it to a separate directory to access, test or serve them. Best, Gergely On 28 Jun 2013 20:14, HWSWMAN ed.pat...@gmail.com wrote: Ok, I want to start over after having spent a few hours trying things ... Here is my situation ... I need to use GIT for some source control .. i have never used any source control before and I want to use it in the simplest possible way first, to get running, and have some version control going on ... i have a very small team of only a few people, but in different locations. I read some stuff and this is what I am planning on doing, please tell me if this makes sense: - I went on the server and used git init to create a new repo - added some files and directories, and commited them from the server - i installed and opened GIT GUI, simple and free, this is what i want ... i cloned the repo to my local machine ... all good - now my understanding is that on the server is the master branch, so all the developers who develop locally on their machines, should create a branch so that they can push ... i created a branch on my machine called company-name-desc, I will recommend all the developers to do this - I made some changes to files in the repo, staged, and commited ... all good ... i also pushed and no issues ... - Now I notice i have to go to the server to merge the changes so the files actually show up on the web server ... worked fine .. - So the idea is, since this all worked, that i would tell the developers to (1) clone the repo (2) create a branch to work out of (3) do their development and stage and commit changes locally, then push to the server ... (4) then they should tell me they need me to merge the branch, and I would ask for the branch name ... i would then go to the server and merge the changes - Does this all sound good so far? Will it work fine? ... - Now if yes, if there is an issue, how do i roll back a change? .. can i simply issue a command on the server, and have the files roll back to the state before the last merge? How do i do this? Otherwise please let me know if this is not right in some way how i am thinking ... note i do not care if i do not have the 110% most optimal way of doing things, i just need a simple method to have some control, and some tracking for now .. this seems to work and i just want some verification .. i am sure more experienced users have suggestions as to how to make this better/smoother/more efficient, and I welcome that too, but please do not just say i am wrong because you know more than i do and you know a fancier way .. what i want to know is if this above is reasonable, and if it will work for basic tracking and control of source files ... Thank you -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to a topic in the Google Groups Git for human beings group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/git-users/uZ15XbPK8zk/unsubscribe. To unsubscribe from this group and all its topics, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] newbie questions
You have some fundamental misconception about how git works. 1. Its not a deploying tool. Your git server is only meant for providing a neat way to synchronize everyone's work. Not for deployment. Best idea is to make your release tarballs from your local dev machine and ftp it into the server. Don't use the files inside server's repo as production use. 2. Git does not recognize a file by its file_name. It considers files as blob object, which resides in tree object. A particular tree snapshot makes a commit object, some pointer to a commit object is branch object etc. All these objects has unique ID , identified by a SHA1 checksum. Now if you edit a file, its SHA1 hash changes, so from git's perspective its no longer the same blob object, its a different object. That's why you have to git add every time you make modification on a file. you have to do git status to see what have changed since last commit. And decide which changes should go into a particular commit, git add them, then do git commit. There is a shortcut git commit -a which adds all the changes. But i prefer adding them by hand because that way i can organize my commit. If two edits are functionally separate, they should reside in different commits. A commit should not be larger then one screen full of edits. If its a huge, then you're doing something wrong. Because the idea of VCS gets killed if your diffs are huge to comprehend. 3) My advice is git is for managing source code versions and its useful for the developers. Your deployment strategy should not be based on git. It should be different. Tag your releases. Use git archive to make release tarballs. Then push them in the production server for deployment. You can write scripts which can automate the whole process. On Sat, Jun 29, 2013 at 2:21 PM, Ed Pataky ed.pat...@gmail.com wrote: Gergely you said Again, you can only do this if you don't need the source files to be present on the server, or you can clone it to a separate directory to access, test or serve them. ... I do not understand this .. why cant the files be on the server? I have a std web server with web files ... scripts, html, etc .. can I not use this bare repo idea for this? Why not? ed On Fri, Jun 28, 2013 at 11:22 AM, Gergely Polonkai gerg...@polonkai.eu wrote: Hello, if I was you, I would use a bare repository on the server side. This will render the server's repository unreadable for the human eye, but the server-side merging would become unnecessary. To do this, create a new directory on the server, and issue the command git init --bare in it. After that, simply `git push` into it from your local machine, and tell your developers to use that repo from then on (or overwrite the old plain text repository with the new, bare one). Again, you can only do this if you don't need the source files to be present on the server, or you can clone it to a separate directory to access, test or serve them. Best, Gergely On 28 Jun 2013 20:14, HWSWMAN ed.pat...@gmail.com wrote: Ok, I want to start over after having spent a few hours trying things ... Here is my situation ... I need to use GIT for some source control .. i have never used any source control before and I want to use it in the simplest possible way first, to get running, and have some version control going on ... i have a very small team of only a few people, but in different locations. I read some stuff and this is what I am planning on doing, please tell me if this makes sense: I went on the server and used git init to create a new repo added some files and directories, and commited them from the server i installed and opened GIT GUI, simple and free, this is what i want ... i cloned the repo to my local machine ... all good now my understanding is that on the server is the master branch, so all the developers who develop locally on their machines, should create a branch so that they can push ... i created a branch on my machine called company-name-desc, I will recommend all the developers to do this I made some changes to files in the repo, staged, and commited ... all good ... i also pushed and no issues ... Now I notice i have to go to the server to merge the changes so the files actually show up on the web server ... worked fine .. So the idea is, since this all worked, that i would tell the developers to (1) clone the repo (2) create a branch to work out of (3) do their development and stage and commit changes locally, then push to the server ... (4) then they should tell me they need me to merge the branch, and I would ask for the branch name ... i would then go to the server and merge the changes Does this all sound good so far? Will it work fine? ... Now if yes, if there is an issue, how do i roll back a change? .. can i simply issue a command on the server, and have the files roll back to the state before the last merge? How do i do this? Otherwise please let me know if this is not
Re: [git-users] newbie questions
thank you very helpful i am seeing everywhere that a bare repo is the way to go for distributed developers .. it seems to me we should essentially make a rule that you make your changes and test locally if possible, then ftp them to the server when ok ... once all done the next step is (i am choosing SourceTree Gui) stage changes, commit and push .. My only question now is can developers have different set of files in thier local repos? for example i use python and other developers use php, and we all edit html as well...so in my repo i added only html and python and in thiers i would tell them to add thier php ad the same html .. is there any issue with this? i just do not want to download the entire website directory contents because it is huge On Saturday, June 29, 2013, aft wrote: You have some fundamental misconception about how git works. 1. Its not a deploying tool. Your git server is only meant for providing a neat way to synchronize everyone's work. Not for deployment. Best idea is to make your release tarballs from your local dev machine and ftp it into the server. Don't use the files inside server's repo as production use. 2. Git does not recognize a file by its file_name. It considers files as blob object, which resides in tree object. A particular tree snapshot makes a commit object, some pointer to a commit object is branch object etc. All these objects has unique ID , identified by a SHA1 checksum. Now if you edit a file, its SHA1 hash changes, so from git's perspective its no longer the same blob object, its a different object. That's why you have to git add every time you make modification on a file. you have to do git status to see what have changed since last commit. And decide which changes should go into a particular commit, git add them, then do git commit. There is a shortcut git commit -a which adds all the changes. But i prefer adding them by hand because that way i can organize my commit. If two edits are functionally separate, they should reside in different commits. A commit should not be larger then one screen full of edits. If its a huge, then you're doing something wrong. Because the idea of VCS gets killed if your diffs are huge to comprehend. 3) My advice is git is for managing source code versions and its useful for the developers. Your deployment strategy should not be based on git. It should be different. Tag your releases. Use git archive to make release tarballs. Then push them in the production server for deployment. You can write scripts which can automate the whole process. On Sat, Jun 29, 2013 at 2:21 PM, Ed Pataky ed.pat...@gmail.com wrote: Gergely you said Again, you can only do this if you don't need the source files to be present on the server, or you can clone it to a separate directory to access, test or serve them. ... I do not understand this .. why cant the files be on the server? I have a std web server with web files ... scripts, html, etc .. can I not use this bare repo idea for this? Why not? ed On Fri, Jun 28, 2013 at 11:22 AM, Gergely Polonkai gerg...@polonkai.eu wrote: Hello, if I was you, I would use a bare repository on the server side. This will render the server's repository unreadable for the human eye, but the server-side merging would become unnecessary. To do this, create a new directory on the server, and issue the command git init --bare in it. After that, simply `git push` into it from your local machine, and tell your developers to use that repo from then on (or overwrite the old plain text repository with the new, bare one). Again, you can only do this if you don't need the source files to be present on the server, or you can clone it to a separate directory to access, test or serve them. Best, Gergely On 28 Jun 2013 20:14, HWSWMAN ed.pat...@gmail.com wrote: Ok, I want to start over after having spent a few hours trying things ... Here is my situation ... I need to use GIT for some source control .. i have never used any source control before and I want to use it in the simplest possible way first, to get running, and have some version control going on ... i have a very small team of only a few people, but in different locations. I read some stuff and this is what I am planning on doing, please tell me if this makes sense: I went on the server and used git init to create a new repo added some files and directories, and commited them from the server i installed and opened GIT GUI, simple and free, this is what i want ... i cloned the repo to my local machine ... all good now my understanding is that on the server is the master branch, so all the developers who develop locally on their machines, should create a branch so that they can push ... i created a branch on my machine called company-name-desc, I will recommend all the developers to do this I made some changes to
Re: [git-users] newbie questions
If I setup a bare repo, and all developers track their changes, all is good .. but then one developer makes a bunch of changes that were not tracked and files are out of sync .. how do i tell GIT to revert back to the old file versions when everything was ok? On Sat, Jun 29, 2013 at 8:15 AM, Ed Pataky ed.pat...@gmail.com wrote: thank you very helpful i am seeing everywhere that a bare repo is the way to go for distributed developers .. it seems to me we should essentially make a rule that you make your changes and test locally if possible, then ftp them to the server when ok ... once all done the next step is (i am choosing SourceTree Gui) stage changes, commit and push .. My only question now is can developers have different set of files in thier local repos? for example i use python and other developers use php, and we all edit html as well...so in my repo i added only html and python and in thiers i would tell them to add thier php ad the same html .. is there any issue with this? i just do not want to download the entire website directory contents because it is huge On Saturday, June 29, 2013, aft wrote: You have some fundamental misconception about how git works. 1. Its not a deploying tool. Your git server is only meant for providing a neat way to synchronize everyone's work. Not for deployment. Best idea is to make your release tarballs from your local dev machine and ftp it into the server. Don't use the files inside server's repo as production use. 2. Git does not recognize a file by its file_name. It considers files as blob object, which resides in tree object. A particular tree snapshot makes a commit object, some pointer to a commit object is branch object etc. All these objects has unique ID , identified by a SHA1 checksum. Now if you edit a file, its SHA1 hash changes, so from git's perspective its no longer the same blob object, its a different object. That's why you have to git add every time you make modification on a file. you have to do git status to see what have changed since last commit. And decide which changes should go into a particular commit, git add them, then do git commit. There is a shortcut git commit -a which adds all the changes. But i prefer adding them by hand because that way i can organize my commit. If two edits are functionally separate, they should reside in different commits. A commit should not be larger then one screen full of edits. If its a huge, then you're doing something wrong. Because the idea of VCS gets killed if your diffs are huge to comprehend. 3) My advice is git is for managing source code versions and its useful for the developers. Your deployment strategy should not be based on git. It should be different. Tag your releases. Use git archive to make release tarballs. Then push them in the production server for deployment. You can write scripts which can automate the whole process. On Sat, Jun 29, 2013 at 2:21 PM, Ed Pataky ed.pat...@gmail.com wrote: Gergely you said Again, you can only do this if you don't need the source files to be present on the server, or you can clone it to a separate directory to access, test or serve them. ... I do not understand this .. why cant the files be on the server? I have a std web server with web files ... scripts, html, etc .. can I not use this bare repo idea for this? Why not? ed On Fri, Jun 28, 2013 at 11:22 AM, Gergely Polonkai gerg...@polonkai.eu wrote: Hello, if I was you, I would use a bare repository on the server side. This will render the server's repository unreadable for the human eye, but the server-side merging would become unnecessary. To do this, create a new directory on the server, and issue the command git init --bare in it. After that, simply `git push` into it from your local machine, and tell your developers to use that repo from then on (or overwrite the old plain text repository with the new, bare one). Again, you can only do this if you don't need the source files to be present on the server, or you can clone it to a separate directory to access, test or serve them. Best, Gergely On 28 Jun 2013 20:14, HWSWMAN ed.pat...@gmail.com wrote: Ok, I want to start over after having spent a few hours trying things ... Here is my situation ... I need to use GIT for some source control .. i have never used any source control before and I want to use it in the simplest possible way first, to get running, and have some version control going on ... i have a very small team of only a few people, but in different locations. I read some stuff and this is what I am planning on doing, please tell me if this makes sense: I went on the server and used git init to create a new repo added some files and directories, and commited them from the server i installed and opened GIT GUI, simple and free, this is what i want ... i cloned the repo
Re: [git-users] newbie questions
On Fri, Jun 28, 2013 at 4:30 AM, HWSWMAN ed.pat...@gmail.com wrote: ok i am new to GIT .. i need a source control system and i want to use it in the simplest possible way ... i have a linux server with our website files, and i have me, plus a few developers in another country ... myself and the developers share the same SSH access username i got started and created a git repo in a particular directory .. cool i installed the basic git gui, and was able to clone down to my machine using ssh ... cool I have to say the GIT docs are pretty cryptic .. i just want to use the thing, I could not care less how it works ... is there a better documentation that focuses on how to USE git and not how git internals work? otherwise, questions below: The internet is full of articles on how to use Git. I mainly turn to http://gitready.com/ when I get confused by a man page. It's slightly more of a reference site though, but maybe one of the sites on this page can get you started: http://sixrevisions.com/resources/git-tutorials-beginners/ I already tested and it seems like you can ftp a file from then to the server with changes, and totally go around git ... what does git do to stop this? i thought changes had to go through GIT? Also why can I not see the changes? In other words, I cloned the repo to my machine .. then i opened FTP, downloaded a file, changed it and ftp'd it back ... then i went in GIT to see if I could see that change .. i could not .. how do i see if there are any changes that happenned outside of GIT? I don't understand your question at all. Did you 1. Clone a repo into $WE 2. Download a file into the repo from an unrelated location into $WE 3. Modify the downloaded file 4. Upload the file again to the unrelated location If so I'm not sure what you expected would happen, since 1. The local Git clone hasn't been told to track the file you downloaded (run `git status` and you should see the file listed as untracked) 2. The remote Git repo does of course not know anything about the file either Also, keep in mind that Git is *not* a deployment tool per se, it's a version control tool! If I want the simplest possible implementation, how should it work? what i mean is, i was thinking there is one central repo on the server, and all the developers, including me, clone to our machines, then do our work, and stage, then commit the changes ... does this make sense? I plan to use this workflow concept: Centralized-Workflow Install a web server capable of FastCGI (e.g. lighttpd) and configure it to run git-http-backend. Do I have to clone the whole thing everytime, or can i just download any file changes before i begin work? How do i do it? I would suggest you read an introductory text on Git, but here's a very short explanation: You have to create a local clone before commencing work, you *always* need a local clone: % git clone http://myrepo.git Then you make changes locally and commit those: % vim my-file % git add my-file % git commit And finally you push back changes to the central repo: % git push /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] newbie questions
Thank you .. question: I created a git repo on the server ... than on my machine i cloned the repo i made some changes, stage, commit, then push ... it says master is checked out? Should I have made a branch first? Why can I not push these changes? How should I push them, or what is the process I should have followed? ed On Fri, Jun 28, 2013 at 3:54 AM, Magnus Therning mag...@therning.orgwrote: On Fri, Jun 28, 2013 at 4:30 AM, HWSWMAN ed.pat...@gmail.com wrote: ok i am new to GIT .. i need a source control system and i want to use it in the simplest possible way ... i have a linux server with our website files, and i have me, plus a few developers in another country ... myself and the developers share the same SSH access username i got started and created a git repo in a particular directory .. cool i installed the basic git gui, and was able to clone down to my machine using ssh ... cool I have to say the GIT docs are pretty cryptic .. i just want to use the thing, I could not care less how it works ... is there a better documentation that focuses on how to USE git and not how git internals work? otherwise, questions below: The internet is full of articles on how to use Git. I mainly turn to http://gitready.com/ when I get confused by a man page. It's slightly more of a reference site though, but maybe one of the sites on this page can get you started: http://sixrevisions.com/resources/git-tutorials-beginners/ I already tested and it seems like you can ftp a file from then to the server with changes, and totally go around git ... what does git do to stop this? i thought changes had to go through GIT? Also why can I not see the changes? In other words, I cloned the repo to my machine .. then i opened FTP, downloaded a file, changed it and ftp'd it back ... then i went in GIT to see if I could see that change .. i could not .. how do i see if there are any changes that happenned outside of GIT? I don't understand your question at all. Did you 1. Clone a repo into $WE 2. Download a file into the repo from an unrelated location into $WE 3. Modify the downloaded file 4. Upload the file again to the unrelated location If so I'm not sure what you expected would happen, since 1. The local Git clone hasn't been told to track the file you downloaded (run `git status` and you should see the file listed as untracked) 2. The remote Git repo does of course not know anything about the file either Also, keep in mind that Git is *not* a deployment tool per se, it's a version control tool! If I want the simplest possible implementation, how should it work? what i mean is, i was thinking there is one central repo on the server, and all the developers, including me, clone to our machines, then do our work, and stage, then commit the changes ... does this make sense? I plan to use this workflow concept: Centralized-Workflow Install a web server capable of FastCGI (e.g. lighttpd) and configure it to run git-http-backend. Do I have to clone the whole thing everytime, or can i just download any file changes before i begin work? How do i do it? I would suggest you read an introductory text on Git, but here's a very short explanation: You have to create a local clone before commencing work, you *always* need a local clone: % git clone http://myrepo.git Then you make changes locally and commit those: % vim my-file % git add my-file % git commit And finally you push back changes to the central repo: % git push /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus -- You received this message because you are subscribed to a topic in the Google Groups Git for human beings group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/git-users/uZ15XbPK8zk/unsubscribe. To unsubscribe from this group and all its topics, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] newbie questions
I made a new branch, made changes, commited, pushed .. all good .. why did the file not ftp to the server? On Fri, Jun 28, 2013 at 9:33 AM, Ed Pataky ed.pat...@gmail.com wrote: Thank you .. question: I created a git repo on the server ... than on my machine i cloned the repo i made some changes, stage, commit, then push ... it says master is checked out? Should I have made a branch first? Why can I not push these changes? How should I push them, or what is the process I should have followed? ed On Fri, Jun 28, 2013 at 3:54 AM, Magnus Therning mag...@therning.orgwrote: On Fri, Jun 28, 2013 at 4:30 AM, HWSWMAN ed.pat...@gmail.com wrote: ok i am new to GIT .. i need a source control system and i want to use it in the simplest possible way ... i have a linux server with our website files, and i have me, plus a few developers in another country ... myself and the developers share the same SSH access username i got started and created a git repo in a particular directory .. cool i installed the basic git gui, and was able to clone down to my machine using ssh ... cool I have to say the GIT docs are pretty cryptic .. i just want to use the thing, I could not care less how it works ... is there a better documentation that focuses on how to USE git and not how git internals work? otherwise, questions below: The internet is full of articles on how to use Git. I mainly turn to http://gitready.com/ when I get confused by a man page. It's slightly more of a reference site though, but maybe one of the sites on this page can get you started: http://sixrevisions.com/resources/git-tutorials-beginners/ I already tested and it seems like you can ftp a file from then to the server with changes, and totally go around git ... what does git do to stop this? i thought changes had to go through GIT? Also why can I not see the changes? In other words, I cloned the repo to my machine .. then i opened FTP, downloaded a file, changed it and ftp'd it back ... then i went in GIT to see if I could see that change .. i could not .. how do i see if there are any changes that happenned outside of GIT? I don't understand your question at all. Did you 1. Clone a repo into $WE 2. Download a file into the repo from an unrelated location into $WE 3. Modify the downloaded file 4. Upload the file again to the unrelated location If so I'm not sure what you expected would happen, since 1. The local Git clone hasn't been told to track the file you downloaded (run `git status` and you should see the file listed as untracked) 2. The remote Git repo does of course not know anything about the file either Also, keep in mind that Git is *not* a deployment tool per se, it's a version control tool! If I want the simplest possible implementation, how should it work? what i mean is, i was thinking there is one central repo on the server, and all the developers, including me, clone to our machines, then do our work, and stage, then commit the changes ... does this make sense? I plan to use this workflow concept: Centralized-Workflow Install a web server capable of FastCGI (e.g. lighttpd) and configure it to run git-http-backend. Do I have to clone the whole thing everytime, or can i just download any file changes before i begin work? How do i do it? I would suggest you read an introductory text on Git, but here's a very short explanation: You have to create a local clone before commencing work, you *always* need a local clone: % git clone http://myrepo.git Then you make changes locally and commit those: % vim my-file % git add my-file % git commit And finally you push back changes to the central repo: % git push /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus -- You received this message because you are subscribed to a topic in the Google Groups Git for human beings group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/git-users/uZ15XbPK8zk/unsubscribe. To unsubscribe from this group and all its topics, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] newbie questions
ok i get it ... the file did ftp, i had to go on the server and merge it -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] newbie questions
question: going to the server and trying to do a merge with VIM is very terrible ... can't i see the merge and do it locally from my PC using the GIT GUI? I need a GUI basically, i hate command line stuff ... how i can i do the merge on the server, but from my PC in a (free) GUI -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] newbie questions
Ok, I want to start over after having spent a few hours trying things ... Here is my situation ... I need to use GIT for some source control .. i have never used any source control before and I want to use it in the simplest possible way first, to get running, and have some version control going on ... i have a very small team of only a few people, but in different locations. I read some stuff and this is what I am planning on doing, please tell me if this makes sense: - I went on the server and used git init to create a new repo - added some files and directories, and commited them from the server - i installed and opened GIT GUI, simple and free, this is what i want ... i cloned the repo to my local machine ... all good - now my understanding is that on the server is the master branch, so all the developers who develop locally on their machines, should create a branch so that they can push ... i created a branch on my machine called company-name-desc, I will recommend all the developers to do this - I made some changes to files in the repo, staged, and commited ... all good ... i also pushed and no issues ... - Now I notice i have to go to the server to merge the changes so the files actually show up on the web server ... worked fine .. - So the idea is, since this all worked, that i would tell the developers to (1) clone the repo (2) create a branch to work out of (3) do their development and stage and commit changes locally, then push to the server ... (4) then they should tell me they need me to merge the branch, and I would ask for the branch name ... i would then go to the server and merge the changes - Does this all sound good so far? Will it work fine? ... - Now if yes, if there is an issue, how do i roll back a change? .. can i simply issue a command on the server, and have the files roll back to the state before the last merge? How do i do this? Otherwise please let me know if this is not right in some way how i am thinking ... note i do not care if i do not have the 110% most optimal way of doing things, i just need a simple method to have some control, and some tracking for now .. this seems to work and i just want some verification .. i am sure more experienced users have suggestions as to how to make this better/smoother/more efficient, and I welcome that too, but please do not just say i am wrong because you know more than i do and you know a fancier way .. what i want to know is if this above is reasonable, and if it will work for basic tracking and control of source files ... Thank you -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] newbie questions
Hello, if I was you, I would use a bare repository on the server side. This will render the server's repository unreadable for the human eye, but the server-side merging would become unnecessary. To do this, create a new directory on the server, and issue the command git init --bare in it. After that, simply `git push` into it from your local machine, and tell your developers to use that repo from then on (or overwrite the old plain text repository with the new, bare one). Again, you can only do this if you don't need the source files to be present on the server, or you can clone it to a separate directory to access, test or serve them. Best, Gergely On 28 Jun 2013 20:14, HWSWMAN ed.pat...@gmail.com wrote: Ok, I want to start over after having spent a few hours trying things ... Here is my situation ... I need to use GIT for some source control .. i have never used any source control before and I want to use it in the simplest possible way first, to get running, and have some version control going on ... i have a very small team of only a few people, but in different locations. I read some stuff and this is what I am planning on doing, please tell me if this makes sense: - I went on the server and used git init to create a new repo - added some files and directories, and commited them from the server - i installed and opened GIT GUI, simple and free, this is what i want ... i cloned the repo to my local machine ... all good - now my understanding is that on the server is the master branch, so all the developers who develop locally on their machines, should create a branch so that they can push ... i created a branch on my machine called company-name-desc, I will recommend all the developers to do this - I made some changes to files in the repo, staged, and commited ... all good ... i also pushed and no issues ... - Now I notice i have to go to the server to merge the changes so the files actually show up on the web server ... worked fine .. - So the idea is, since this all worked, that i would tell the developers to (1) clone the repo (2) create a branch to work out of (3) do their development and stage and commit changes locally, then push to the server ... (4) then they should tell me they need me to merge the branch, and I would ask for the branch name ... i would then go to the server and merge the changes - Does this all sound good so far? Will it work fine? ... - Now if yes, if there is an issue, how do i roll back a change? .. can i simply issue a command on the server, and have the files roll back to the state before the last merge? How do i do this? Otherwise please let me know if this is not right in some way how i am thinking ... note i do not care if i do not have the 110% most optimal way of doing things, i just need a simple method to have some control, and some tracking for now .. this seems to work and i just want some verification .. i am sure more experienced users have suggestions as to how to make this better/smoother/more efficient, and I welcome that too, but please do not just say i am wrong because you know more than i do and you know a fancier way .. what i want to know is if this above is reasonable, and if it will work for basic tracking and control of source files ... Thank you -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] newbie questions
From: HWSWMAN ed.pat...@gmail.com i have a linux server with our website files, and i have me, plus a few developers in another country ... myself and the developers share the same SSH access username That is generally a bad idea, because then the access of a single developer cannot be revoked without revoking the access of all the developers. Better is to assign each developer a different username (which can have a distinct password). Put all the usernames into one group. All of the things that the developers should have read or write access to on the server can then be made readable or writable for the entire group. Also, the various Linux system management tools can see and record which developer logged in when. Dale -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] newbie questions
Thank you, I did try this but I was confused ... The files are on the server, these are the production files .. they have to be there or there is no website ... so can i still use a bare repo? My understanding of this is that a bare repo simply has the history info (branches, commits, etc) .. but it does not store the files .. is this correct? Then is the idea that the developers make changes locally, commit and push, but then simply FTP the files? Is that how it works with a bare repo? How do the files get there and what would push do for a bare repo? ed On Fri, Jun 28, 2013 at 11:22 AM, Gergely Polonkai gerg...@polonkai.euwrote: Hello, if I was you, I would use a bare repository on the server side. This will render the server's repository unreadable for the human eye, but the server-side merging would become unnecessary. To do this, create a new directory on the server, and issue the command git init --bare in it. After that, simply `git push` into it from your local machine, and tell your developers to use that repo from then on (or overwrite the old plain text repository with the new, bare one). Again, you can only do this if you don't need the source files to be present on the server, or you can clone it to a separate directory to access, test or serve them. Best, Gergely On 28 Jun 2013 20:14, HWSWMAN ed.pat...@gmail.com wrote: Ok, I want to start over after having spent a few hours trying things ... Here is my situation ... I need to use GIT for some source control .. i have never used any source control before and I want to use it in the simplest possible way first, to get running, and have some version control going on ... i have a very small team of only a few people, but in different locations. I read some stuff and this is what I am planning on doing, please tell me if this makes sense: - I went on the server and used git init to create a new repo - added some files and directories, and commited them from the server - i installed and opened GIT GUI, simple and free, this is what i want ... i cloned the repo to my local machine ... all good - now my understanding is that on the server is the master branch, so all the developers who develop locally on their machines, should create a branch so that they can push ... i created a branch on my machine called company-name-desc, I will recommend all the developers to do this - I made some changes to files in the repo, staged, and commited ... all good ... i also pushed and no issues ... - Now I notice i have to go to the server to merge the changes so the files actually show up on the web server ... worked fine .. - So the idea is, since this all worked, that i would tell the developers to (1) clone the repo (2) create a branch to work out of (3) do their development and stage and commit changes locally, then push to the server ... (4) then they should tell me they need me to merge the branch, and I would ask for the branch name ... i would then go to the server and merge the changes - Does this all sound good so far? Will it work fine? ... - Now if yes, if there is an issue, how do i roll back a change? .. can i simply issue a command on the server, and have the files roll back to the state before the last merge? How do i do this? Otherwise please let me know if this is not right in some way how i am thinking ... note i do not care if i do not have the 110% most optimal way of doing things, i just need a simple method to have some control, and some tracking for now .. this seems to work and i just want some verification .. i am sure more experienced users have suggestions as to how to make this better/smoother/more efficient, and I welcome that too, but please do not just say i am wrong because you know more than i do and you know a fancier way .. what i want to know is if this above is reasonable, and if it will work for basic tracking and control of source files ... Thank you -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to a topic in the Google Groups Git for human beings group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/git-users/uZ15XbPK8zk/unsubscribe. To unsubscribe from this group and all its topics, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com.
Re: [git-users] newbie questions
ok about the usernames, in general yes i know this is not ideal .. it just happened this way because the developers needed SSH access to everything essentially so they could mess with things that needed full control ... i think because the ssh password on the server is locked to one single ftp account, so for the developers to have ssh access they needed the root account .. not much i can do about it .. but besides that issue, i need to understand git On Fri, Jun 28, 2013 at 11:32 AM, Dale R. Worley wor...@alum.mit.eduwrote: From: HWSWMAN ed.pat...@gmail.com i have a linux server with our website files, and i have me, plus a few developers in another country ... myself and the developers share the same SSH access username That is generally a bad idea, because then the access of a single developer cannot be revoked without revoking the access of all the developers. Better is to assign each developer a different username (which can have a distinct password). Put all the usernames into one group. All of the things that the developers should have read or write access to on the server can then be made readable or writable for the entire group. Also, the various Linux system management tools can see and record which developer logged in when. Dale -- You received this message because you are subscribed to a topic in the Google Groups Git for human beings group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/git-users/uZ15XbPK8zk/unsubscribe. To unsubscribe from this group and all its topics, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] newbie questions
Generally, for simple projects with multiple developers, the pattern is to have one central bare repository that is the official copy of all the commits. Each developer then has their own repository with an attached working directory. Each repository is created as a clone of the central repository, which means that it contains a more-or-less complete set of commits as well, and contains a pointer back to the contral repository. If the files need to be used on the server, then create another clone on the server whose working directory is the place where the files are used. Each developer works in their own working directory. When they want to check something in, they commit their changes to their repo. This creates a new commit in their repo. They then push changes to the central repo, which causes the new commit(s) to be copied from their repo to the central repo. When a developer wants to obtain updates from the central repo, they do a pull, which causes any new commits from the central repo to be copied to their repo. When the developer changes his checked-out commit to be the newest downloaded commit, then his working directory is updated accordingly. This is the point at which conflicts will show up, and merging may be needed to fix them. Dale -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] newbie questions
ok i have to try this thank you ed On Fri, Jun 28, 2013 at 11:38 AM, Dale R. Worley wor...@alum.mit.eduwrote: Generally, for simple projects with multiple developers, the pattern is to have one central bare repository that is the official copy of all the commits. Each developer then has their own repository with an attached working directory. Each repository is created as a clone of the central repository, which means that it contains a more-or-less complete set of commits as well, and contains a pointer back to the contral repository. If the files need to be used on the server, then create another clone on the server whose working directory is the place where the files are used. Each developer works in their own working directory. When they want to check something in, they commit their changes to their repo. This creates a new commit in their repo. They then push changes to the central repo, which causes the new commit(s) to be copied from their repo to the central repo. When a developer wants to obtain updates from the central repo, they do a pull, which causes any new commits from the central repo to be copied to their repo. When the developer changes his checked-out commit to be the newest downloaded commit, then his working directory is updated accordingly. This is the point at which conflicts will show up, and merging may be needed to fix them. Dale -- You received this message because you are subscribed to a topic in the Google Groups Git for human beings group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/git-users/uZ15XbPK8zk/unsubscribe. To unsubscribe from this group and all its topics, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] newbie questions
the downside of this seems to be that all the developers/contributors have to know how to merge correctly On Fri, Jun 28, 2013 at 11:45 AM, Ed Pataky ed.pat...@gmail.com wrote: ok i have to try this thank you ed On Fri, Jun 28, 2013 at 11:38 AM, Dale R. Worley wor...@alum.mit.eduwrote: Generally, for simple projects with multiple developers, the pattern is to have one central bare repository that is the official copy of all the commits. Each developer then has their own repository with an attached working directory. Each repository is created as a clone of the central repository, which means that it contains a more-or-less complete set of commits as well, and contains a pointer back to the contral repository. If the files need to be used on the server, then create another clone on the server whose working directory is the place where the files are used. Each developer works in their own working directory. When they want to check something in, they commit their changes to their repo. This creates a new commit in their repo. They then push changes to the central repo, which causes the new commit(s) to be copied from their repo to the central repo. When a developer wants to obtain updates from the central repo, they do a pull, which causes any new commits from the central repo to be copied to their repo. When the developer changes his checked-out commit to be the newest downloaded commit, then his working directory is updated accordingly. This is the point at which conflicts will show up, and merging may be needed to fix them. Dale -- You received this message because you are subscribed to a topic in the Google Groups Git for human beings group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/git-users/uZ15XbPK8zk/unsubscribe. To unsubscribe from this group and all its topics, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] newbie questions
One thing I am concerned about is that it seems like there is no protection from someone in via ftp and changing files .. i assumed that version control meant that the files are protected .. why doesn't git protect the files? What i mean is, this seems to only work if everyone does it correctly .. but if someone simply goes in by ftp and modifies files, then git has no control over that .. is this correct? On Fri, Jun 28, 2013 at 11:57 AM, Ed Pataky ed.pat...@gmail.com wrote: the downside of this seems to be that all the developers/contributors have to know how to merge correctly On Fri, Jun 28, 2013 at 11:45 AM, Ed Pataky ed.pat...@gmail.com wrote: ok i have to try this thank you ed On Fri, Jun 28, 2013 at 11:38 AM, Dale R. Worley wor...@alum.mit.eduwrote: Generally, for simple projects with multiple developers, the pattern is to have one central bare repository that is the official copy of all the commits. Each developer then has their own repository with an attached working directory. Each repository is created as a clone of the central repository, which means that it contains a more-or-less complete set of commits as well, and contains a pointer back to the contral repository. If the files need to be used on the server, then create another clone on the server whose working directory is the place where the files are used. Each developer works in their own working directory. When they want to check something in, they commit their changes to their repo. This creates a new commit in their repo. They then push changes to the central repo, which causes the new commit(s) to be copied from their repo to the central repo. When a developer wants to obtain updates from the central repo, they do a pull, which causes any new commits from the central repo to be copied to their repo. When the developer changes his checked-out commit to be the newest downloaded commit, then his working directory is updated accordingly. This is the point at which conflicts will show up, and merging may be needed to fix them. Dale -- You received this message because you are subscribed to a topic in the Google Groups Git for human beings group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/git-users/uZ15XbPK8zk/unsubscribe. To unsubscribe from this group and all its topics, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] newbie questions
I will have to note that you seem to have a non-standard definition of version control. git, and other version control software such as Subversion, Mercurial, CVS, Visual Source Safe (or whatever MS calls it), don't track all changes to every file every time the file is modified. They only supply commands so that, at the direction of a user, a snapshot of the file(s) can be taken and tracked. With git, this is the git add and git commit commands. The git commit is what takes the actual snapshot. The git add puts the contents of the files to be updated/added in the snapshot into the index. The git commit actually snapshots the index information into the local git data base (kept in the .git subdirectory) . Perhaps, you eventually update the bare repository using a git push command. Assuming you even keep a bare directory. On some of my personal stuff, I don't because I don't share it with others. Neither is git a security system. If you have been granted write access to a file, it is done using the host operating system's security mechanisms; whatever they may be. In Linux, that is with attributes, ACLS and maybe SELinux profiles. I don't know Windows. But the git software itself is not designed to stop you. That is the OS's responsibility. What it sounds like you want is a versioning file system. That is a file system which keeps old versions of a file each time you modify it, and usually has commands to revert to a previous version. ref: http://en.wikipedia.org/wiki/Versioning_file_system The only system which I have ever used which had this was long ago. It was called TOPS-20 and ran on a DEC System-20 machine. Every time you changed a file, the old version got a version number attached to it and the new version got the old name. So you could go back to previous versions using various commands. Now, if for some reason I wanted such a thing, I could likely implement something in Linux using incrond. This software allows you to specify a command to be run every time a monitored file or file in a subdirectory is changed. So if you wanted to use it, you would monitor the subdirectory so that when a file was changed a git add -A . and and git commit -m 'some comment' would automatically be issued. ref: http://inotify.aiken.cz/?section=incronpage=doc But this is not a standard part of git. It is simply not part of the design. And I don't even know if something like this could be implemented in Windows. On Fri, Jun 28, 2013 at 2:07 PM, Ed Pataky ed.pat...@gmail.com wrote: One thing I am concerned about is that it seems like there is no protection from someone in via ftp and changing files .. i assumed that version control meant that the files are protected .. why doesn't git protect the files? What i mean is, this seems to only work if everyone does it correctly .. but if someone simply goes in by ftp and modifies files, then git has no control over that .. is this correct? -- This is a test of the Emergency Broadcast System. If this had been an actual emergency, do you really think we'd stick around to tell you? Maranatha! John McKown -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] newbie questions
So you are saying that there is no way to rollback to an old version using git? what is the point then, just to store a bunch of comments? On Fri, Jun 28, 2013 at 12:59 PM, John McKown john.archie.mck...@gmail.comwrote: I will have to note that you seem to have a non-standard definition of version control. git, and other version control software such as Subversion, Mercurial, CVS, Visual Source Safe (or whatever MS calls it), don't track all changes to every file every time the file is modified. They only supply commands so that, at the direction of a user, a snapshot of the file(s) can be taken and tracked. With git, this is the git add and git commit commands. The git commit is what takes the actual snapshot. The git add puts the contents of the files to be updated/added in the snapshot into the index. The git commit actually snapshots the index information into the local git data base (kept in the .git subdirectory) . Perhaps, you eventually update the bare repository using a git push command. Assuming you even keep a bare directory. On some of my personal stuff, I don't because I don't share it with others. Neither is git a security system. If you have been granted write access to a file, it is done using the host operating system's security mechanisms; whatever they may be. In Linux, that is with attributes, ACLS and maybe SELinux profiles. I don't know Windows. But the git software itself is not designed to stop you. That is the OS's responsibility. What it sounds like you want is a versioning file system. That is a file system which keeps old versions of a file each time you modify it, and usually has commands to revert to a previous version. ref: http://en.wikipedia.org/wiki/Versioning_file_system The only system which I have ever used which had this was long ago. It was called TOPS-20 and ran on a DEC System-20 machine. Every time you changed a file, the old version got a version number attached to it and the new version got the old name. So you could go back to previous versions using various commands. Now, if for some reason I wanted such a thing, I could likely implement something in Linux using incrond. This software allows you to specify a command to be run every time a monitored file or file in a subdirectory is changed. So if you wanted to use it, you would monitor the subdirectory so that when a file was changed a git add -A . and and git commit -m 'some comment' would automatically be issued. ref: http://inotify.aiken.cz/?section=incronpage=doc But this is not a standard part of git. It is simply not part of the design. And I don't even know if something like this could be implemented in Windows. On Fri, Jun 28, 2013 at 2:07 PM, Ed Pataky ed.pat...@gmail.com wrote: One thing I am concerned about is that it seems like there is no protection from someone in via ftp and changing files .. i assumed that version control meant that the files are protected .. why doesn't git protect the files? What i mean is, this seems to only work if everyone does it correctly .. but if someone simply goes in by ftp and modifies files, then git has no control over that .. is this correct? -- This is a test of the Emergency Broadcast System. If this had been an actual emergency, do you really think we'd stick around to tell you? Maranatha! John McKown -- You received this message because you are subscribed to a topic in the Google Groups Git for human beings group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/git-users/uZ15XbPK8zk/unsubscribe. To unsubscribe from this group and all its topics, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] newbie questions
From: Ed Pataky ed.pat...@gmail.com One thing I am concerned about is that it seems like there is no protection from someone in via ftp and changing files .. i assumed that version control meant that the files are protected .. why doesn't git protect the files? What i mean is, this seems to only work if everyone does it correctly .. but if someone simply goes in by ftp and modifies files, then git has no control over that .. is this correct? If you want that sort of protection, the usual technique is: - Adjust how the developers access the server so that the *only* thing they can do is insert new commits into the master repository. - Have a process that the developers can trigger when they put a newest commit into the master repository that: (1) pulls the new commits from the master repository into the subordinate repository on the server; (2) checks out the newest commit from the subordinate repository into the working directory; (3) restarts the web server in whatever way is necessary for the new files to take effect. Caution: When you do this, you will discover that your developers have been going in via FTP and changing files... and that there are some practical tasks which this is the *only* way they know how to accomplish. Probably testing and debugging tasks. So suddenly your existing workflow will break, and you will need to be prepared to figure out better ways to do these things, possibly in a hurry. Dale -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] newbie questions
question: i have installed now 4 different GIT GUIs and all of them break with an error that says CLR error ... blah blah ... i saw online this meant .NET was not installed, i installed 10 times ... nothing works .. the only gui that works is the GIT GUI but it is not very good ... any help on this ??? i have never seen this in 5 years of using this computer On Fri, Jun 28, 2013 at 1:43 PM, Dale R. Worley wor...@alum.mit.edu wrote: From: Ed Pataky ed.pat...@gmail.com One thing I am concerned about is that it seems like there is no protection from someone in via ftp and changing files .. i assumed that version control meant that the files are protected .. why doesn't git protect the files? What i mean is, this seems to only work if everyone does it correctly .. but if someone simply goes in by ftp and modifies files, then git has no control over that .. is this correct? If you want that sort of protection, the usual technique is: - Adjust how the developers access the server so that the *only* thing they can do is insert new commits into the master repository. - Have a process that the developers can trigger when they put a newest commit into the master repository that: (1) pulls the new commits from the master repository into the subordinate repository on the server; (2) checks out the newest commit from the subordinate repository into the working directory; (3) restarts the web server in whatever way is necessary for the new files to take effect. Caution: When you do this, you will discover that your developers have been going in via FTP and changing files... and that there are some practical tasks which this is the *only* way they know how to accomplish. Probably testing and debugging tasks. So suddenly your existing workflow will break, and you will need to be prepared to figure out better ways to do these things, possibly in a hurry. Dale -- You received this message because you are subscribed to a topic in the Google Groups Git for human beings group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/git-users/uZ15XbPK8zk/unsubscribe. To unsubscribe from this group and all its topics, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] newbie questions
From: Ed Pataky ed.pat...@gmail.com the downside of this seems to be that all the developers/contributors have to know how to merge correctly Yeah, but that's true of any version control system that does not have a centralized locking system to prevent two developers from changing a single file simultaneously. Or at least, *somebody* must be available to do necessary merging. With Git, it's possible to have a developer create a new commit and send it to the master repo but *not* have it become the newest commit of the main line of development. Then another developer can download that commit and merge it into the main line. With Git there are always multiple ways of doing something. Dale -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] newbie questions
You can roll back to any commit point. You can roll back all changes to that point. Or one or more files. Or just look at the contents of a file as of that commit point. Perhaps I misunderstood, but I got the impression you thought that git would automatically keep every change made to a file without any action on the part of the user. As to ftp, you are correct. git does not control _how_ the file is changed. You can use any method that you have available to you. You can ftp the file somewhere else, modify it, then ftp it back. You can use an editor to edit it in place. You can run a program which modifies it somehow (like maybe using Perl to do something, or have a tidy program reformat it). If you have permission, you can even delete it and git won't stop you. But however you modify it, so long as nobody destroys the contents of the .git subdirectory, you can recover any file to any commit point (generally, there are obscene ways to modify the git repository which can royally mess it up). What I often do is edit one or more files in a project. I test the changes until I like the results. When I like the results, I do a git add -A . and git commit to put the changes in the local git repository. If I decide that I have royally messed up before I do any comit, I do a git reset --hard HEAD to revert all the files. Now, suppose I did the commit and then decided that I was wrong to do so. I can go back to the previous version with git revert --hard HEAD~1 to revert the files to the commit point before the bad commit point. But, instead, if I like most of the changes, but maybe there is one which I decide is a mess. I don't revert all the files. I can do git checkout HEAD~1 -- some.file. This restores the some.file to the point it was before I did the current commit. I can then fix that one file, eventually doing a git add -A . and git commit again. Note that the bad version of the file still exists in the git history. There are ways to eliminate the bad commit, but I never use them because I've never felt comfortable doing so. It is, to me, quite complicated. I guess I'm still confused as to what you really want git to do. In my way of thinking, git gives me a way to take a snapshot of a set of files at a point in time (via the git add and git commit). And a way to revert any or all of those files back to that point in time if I need to. git does say whether I can modify a file or not. Nor _how_ I can modify that file. It just allows me to take a point in time snapshot, more or less. It can do more, but that is the big part of it, to me. It can tell you what change between snapshots and by whom (if you set it up that way) and other things. On Fri, Jun 28, 2013 at 3:27 PM, Ed Pataky ed.pat...@gmail.com wrote: So you are saying that there is no way to rollback to an old version using git? what is the point then, just to store a bunch of comments? On Fri, Jun 28, 2013 at 12:59 PM, John McKown john.archie.mck...@gmail.com wrote: I will have to note that you seem to have a non-standard definition of version control. git, and other version control software such as Subversion, Mercurial, CVS, Visual Source Safe (or whatever MS calls it), don't track all changes to every file every time the file is modified. They only supply commands so that, at the direction of a user, a snapshot of the file(s) can be taken and tracked. With git, this is the git add and git commit commands. The git commit is what takes the actual snapshot. The git add puts the contents of the files to be updated/added in the snapshot into the index. The git commit actually snapshots the index information into the local git data base (kept in the .git subdirectory) . Perhaps, you eventually update the bare repository using a git push command. Assuming you even keep a bare directory. On some of my personal stuff, I don't because I don't share it with others. Neither is git a security system. If you have been granted write access to a file, it is done using the host operating system's security mechanisms; whatever they may be. In Linux, that is with attributes, ACLS and maybe SELinux profiles. I don't know Windows. But the git software itself is not designed to stop you. That is the OS's responsibility. What it sounds like you want is a versioning file system. That is a file system which keeps old versions of a file each time you modify it, and usually has commands to revert to a previous version. ref: http://en.wikipedia.org/wiki/Versioning_file_system The only system which I have ever used which had this was long ago. It was called TOPS-20 and ran on a DEC System-20 machine. Every time you changed a file, the old version got a version number attached to it and the new version got the old name. So you could go back to previous versions using various commands. Now, if for some reason I wanted such a thing, I could likely implement something in Linux using incrond. This software allows you to specify a
Re: [git-users] newbie questions
Ah. Sounds like you are running MS-Windows? Sorry, but I don't _do_ windows! (as I used to say as a maintenance worker in college grin/). I am a Linux bigot. On Fri, Jun 28, 2013 at 3:53 PM, Ed Pataky ed.pat...@gmail.com wrote: question: i have installed now 4 different GIT GUIs and all of them break with an error that says CLR error ... blah blah ... i saw online this meant .NET was not installed, i installed 10 times ... nothing works .. the only gui that works is the GIT GUI but it is not very good ... any help on this ??? i have never seen this in 5 years of using this computer -- This is a test of the Emergency Broadcast System. If this had been an actual emergency, do you really think we'd stick around to tell you? Maranatha! John McKown -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] newbie questions
Thank you ... about git add i thought once you add the file you never have to do that again? ... doesn't add tell git to track the file? and if so, why do you have to do it again? ed On Fri, Jun 28, 2013 at 1:58 PM, John McKown john.archie.mck...@gmail.comwrote: You can roll back to any commit point. You can roll back all changes to that point. Or one or more files. Or just look at the contents of a file as of that commit point. Perhaps I misunderstood, but I got the impression you thought that git would automatically keep every change made to a file without any action on the part of the user. As to ftp, you are correct. git does not control _how_ the file is changed. You can use any method that you have available to you. You can ftp the file somewhere else, modify it, then ftp it back. You can use an editor to edit it in place. You can run a program which modifies it somehow (like maybe using Perl to do something, or have a tidy program reformat it). If you have permission, you can even delete it and git won't stop you. But however you modify it, so long as nobody destroys the contents of the .git subdirectory, you can recover any file to any commit point (generally, there are obscene ways to modify the git repository which can royally mess it up). What I often do is edit one or more files in a project. I test the changes until I like the results. When I like the results, I do a git add -A . and git commit to put the changes in the local git repository. If I decide that I have royally messed up before I do any comit, I do a git reset --hard HEAD to revert all the files. Now, suppose I did the commit and then decided that I was wrong to do so. I can go back to the previous version with git revert --hard HEAD~1 to revert the files to the commit point before the bad commit point. But, instead, if I like most of the changes, but maybe there is one which I decide is a mess. I don't revert all the files. I can do git checkout HEAD~1 -- some.file. This restores the some.file to the point it was before I did the current commit. I can then fix that one file, eventually doing a git add -A . and git commit again. Note that the bad version of the file still exists in the git history. There are ways to eliminate the bad commit, but I never use them because I've never felt comfortable doing so. It is, to me, quite complicated. I guess I'm still confused as to what you really want git to do. In my way of thinking, git gives me a way to take a snapshot of a set of files at a point in time (via the git add and git commit). And a way to revert any or all of those files back to that point in time if I need to. git does say whether I can modify a file or not. Nor _how_ I can modify that file. It just allows me to take a point in time snapshot, more or less. It can do more, but that is the big part of it, to me. It can tell you what change between snapshots and by whom (if you set it up that way) and other things. On Fri, Jun 28, 2013 at 3:27 PM, Ed Pataky ed.pat...@gmail.com wrote: So you are saying that there is no way to rollback to an old version using git? what is the point then, just to store a bunch of comments? On Fri, Jun 28, 2013 at 12:59 PM, John McKown john.archie.mck...@gmail.com wrote: I will have to note that you seem to have a non-standard definition of version control. git, and other version control software such as Subversion, Mercurial, CVS, Visual Source Safe (or whatever MS calls it), don't track all changes to every file every time the file is modified. They only supply commands so that, at the direction of a user, a snapshot of the file(s) can be taken and tracked. With git, this is the git add and git commit commands. The git commit is what takes the actual snapshot. The git add puts the contents of the files to be updated/added in the snapshot into the index. The git commit actually snapshots the index information into the local git data base (kept in the .git subdirectory) . Perhaps, you eventually update the bare repository using a git push command. Assuming you even keep a bare directory. On some of my personal stuff, I don't because I don't share it with others. Neither is git a security system. If you have been granted write access to a file, it is done using the host operating system's security mechanisms; whatever they may be. In Linux, that is with attributes, ACLS and maybe SELinux profiles. I don't know Windows. But the git software itself is not designed to stop you. That is the OS's responsibility. What it sounds like you want is a versioning file system. That is a file system which keeps old versions of a file each time you modify it, and usually has commands to revert to a previous version. ref: http://en.wikipedia.org/wiki/Versioning_file_system The only system which I have ever used which had this was long ago. It was called TOPS-20 and ran on a DEC System-20 machine. Every time you changed a file,
Re: [git-users] newbie questions
finally got the CLR error fixed, here is the fix: https://github.com/Windower/Issues/issues/170 On Fri, Jun 28, 2013 at 2:06 PM, Ed Pataky ed.pat...@gmail.com wrote: Thank you ... about git add i thought once you add the file you never have to do that again? ... doesn't add tell git to track the file? and if so, why do you have to do it again? ed On Fri, Jun 28, 2013 at 1:58 PM, John McKown john.archie.mck...@gmail.com wrote: You can roll back to any commit point. You can roll back all changes to that point. Or one or more files. Or just look at the contents of a file as of that commit point. Perhaps I misunderstood, but I got the impression you thought that git would automatically keep every change made to a file without any action on the part of the user. As to ftp, you are correct. git does not control _how_ the file is changed. You can use any method that you have available to you. You can ftp the file somewhere else, modify it, then ftp it back. You can use an editor to edit it in place. You can run a program which modifies it somehow (like maybe using Perl to do something, or have a tidy program reformat it). If you have permission, you can even delete it and git won't stop you. But however you modify it, so long as nobody destroys the contents of the .git subdirectory, you can recover any file to any commit point (generally, there are obscene ways to modify the git repository which can royally mess it up). What I often do is edit one or more files in a project. I test the changes until I like the results. When I like the results, I do a git add -A . and git commit to put the changes in the local git repository. If I decide that I have royally messed up before I do any comit, I do a git reset --hard HEAD to revert all the files. Now, suppose I did the commit and then decided that I was wrong to do so. I can go back to the previous version with git revert --hard HEAD~1 to revert the files to the commit point before the bad commit point. But, instead, if I like most of the changes, but maybe there is one which I decide is a mess. I don't revert all the files. I can do git checkout HEAD~1 -- some.file. This restores the some.file to the point it was before I did the current commit. I can then fix that one file, eventually doing a git add -A . and git commit again. Note that the bad version of the file still exists in the git history. There are ways to eliminate the bad commit, but I never use them because I've never felt comfortable doing so. It is, to me, quite complicated. I guess I'm still confused as to what you really want git to do. In my way of thinking, git gives me a way to take a snapshot of a set of files at a point in time (via the git add and git commit). And a way to revert any or all of those files back to that point in time if I need to. git does say whether I can modify a file or not. Nor _how_ I can modify that file. It just allows me to take a point in time snapshot, more or less. It can do more, but that is the big part of it, to me. It can tell you what change between snapshots and by whom (if you set it up that way) and other things. On Fri, Jun 28, 2013 at 3:27 PM, Ed Pataky ed.pat...@gmail.com wrote: So you are saying that there is no way to rollback to an old version using git? what is the point then, just to store a bunch of comments? On Fri, Jun 28, 2013 at 12:59 PM, John McKown john.archie.mck...@gmail.com wrote: I will have to note that you seem to have a non-standard definition of version control. git, and other version control software such as Subversion, Mercurial, CVS, Visual Source Safe (or whatever MS calls it), don't track all changes to every file every time the file is modified. They only supply commands so that, at the direction of a user, a snapshot of the file(s) can be taken and tracked. With git, this is the git add and git commit commands. The git commit is what takes the actual snapshot. The git add puts the contents of the files to be updated/added in the snapshot into the index. The git commit actually snapshots the index information into the local git data base (kept in the .git subdirectory) . Perhaps, you eventually update the bare repository using a git push command. Assuming you even keep a bare directory. On some of my personal stuff, I don't because I don't share it with others. Neither is git a security system. If you have been granted write access to a file, it is done using the host operating system's security mechanisms; whatever they may be. In Linux, that is with attributes, ACLS and maybe SELinux profiles. I don't know Windows. But the git software itself is not designed to stop you. That is the OS's responsibility. What it sounds like you want is a versioning file system. That is a file system which keeps old versions of a file each time you modify it, and usually has commands to revert to a previous version. ref:
Re: [git-users] newbie questions
On Fri, Jun 28, 2013 at 11:14:06AM -0700, HWSWMAN wrote: Ok, I want to start over after having spent a few hours trying things ... Here is my situation ... I need to use GIT for some source control .. i have never used any source control before and I want to use it in the simplest possible way first, to get running, and have some version control going on ... i have a very small team of only a few people, but in different locations. I read some stuff and this is what I am planning on doing, please tell me if this makes sense: - I went on the server and used git init to create a new repo As others have suggested it's better to use `git init --bare` when creating the repo on the server. - added some files and directories, and commited them from the server This step is rather unnecessary, once the repo exists on the server it can be checked out and you can do all the work on your development machine. - i installed and opened GIT GUI, simple and free, this is what i want ... i cloned the repo to my local machine ... all good - now my understanding is that on the server is the master branch, so all the developers who develop locally on their machines, should create a branch so that they can push ... i created a branch on my machine called company-name-desc, I will recommend all the developers to do this No! The master branch is in *every* clone, not only on the server. You may decide to use the server repo as the *master repo*, or blessed repo, or whatever you want to call it, simply it's the one central point where you always can turn to get the current, up-to-date source. - I made some changes to files in the repo, staged, and commited ... all good ... i also pushed and no issues ... - Now I notice i have to go to the server to merge the changes so the files actually show up on the web server ... worked fine .. This is where my comment about Git not being a deployment tool comes in, and where the point about using a bare repo clarifies things: Pushing to a non-bare repo *will not* modify the checked out file in that repo! By using a bare repo on the server you avoid falling into the trap of thinking about the server repo in the wrong way. - So the idea is, since this all worked, that i would tell the developers to (1) clone the repo (2) create a branch to work out of (3) do their development and stage and commit changes locally, then push to the server ... (4) then they should tell me they need me to merge the branch, and I would ask for the branch name ... i would then go to the server and merge the changes - Does this all sound good so far? Will it work fine? ... No, I would organise it as such (for the sake of argument I'm assuming you are developing a web application): - bare repo on the Git server - each developer clones the bare repo from the Git server, do their development, and push back to the Git server - you clone the bare repo from the Git server onto the web application server, and pull in changes when they are ready for deployment (the Git server and web application server can of course be the same physical machine, even served by the same httpd server, but the central Git repo and the web application should not live in the same folder on the file system) This is the basic flow, you then need to add details regarding branching on top of this. - Now if yes, if there is an issue, how do i roll back a change? .. can i simply issue a command on the server, and have the files roll back to the state before the last merge? How do i do this? In the repo on the web server you can simply roll back to a specific point using `git reset --hard ref`. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay pgpX5ZFboSSDE.pgp Description: PGP signature
Re: [git-users] newbie questions
On Fri, Jun 28, 2013 at 02:06:38PM -0700, Ed Pataky wrote: Thank you ... about git add i thought once you add the file you never have to do that again? ... doesn't add tell git to track the file? and if so, why do you have to do it again? Many VCSs work the way you mention above, you add once, then just committing is enough - e.g. SVN. Git has a staging area where you put changes before committing them: http://gitready.com/beginner/2009/01/18/the-staging-area.html Look for instance at `git add -p` to see what kind of power Git's way offers you when committing changes. It's actually a great thing, and I'm sure that once you get used to it you'll miss it whenever you are forced to work with a VCS that doesn't work like Git. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus I invented the term Object-Oriented, and I can tell you I did not have C++ in mind. -- Alan Kay pgpGRwEnoPMvs.pgp Description: PGP signature
Re: [git-users] newbie questions
So suppose i have a git repo setup, and someone adds a file that should not be there, or deletes a file they should not have, through ssh or ftp ... how do i go about reversing their change back to the last commit point? On Fri, Jun 28, 2013 at 1:58 PM, John McKown john.archie.mck...@gmail.comwrote: You can roll back to any commit point. You can roll back all changes to that point. Or one or more files. Or just look at the contents of a file as of that commit point. Perhaps I misunderstood, but I got the impression you thought that git would automatically keep every change made to a file without any action on the part of the user. As to ftp, you are correct. git does not control _how_ the file is changed. You can use any method that you have available to you. You can ftp the file somewhere else, modify it, then ftp it back. You can use an editor to edit it in place. You can run a program which modifies it somehow (like maybe using Perl to do something, or have a tidy program reformat it). If you have permission, you can even delete it and git won't stop you. But however you modify it, so long as nobody destroys the contents of the .git subdirectory, you can recover any file to any commit point (generally, there are obscene ways to modify the git repository which can royally mess it up). What I often do is edit one or more files in a project. I test the changes until I like the results. When I like the results, I do a git add -A . and git commit to put the changes in the local git repository. If I decide that I have royally messed up before I do any comit, I do a git reset --hard HEAD to revert all the files. Now, suppose I did the commit and then decided that I was wrong to do so. I can go back to the previous version with git revert --hard HEAD~1 to revert the files to the commit point before the bad commit point. But, instead, if I like most of the changes, but maybe there is one which I decide is a mess. I don't revert all the files. I can do git checkout HEAD~1 -- some.file. This restores the some.file to the point it was before I did the current commit. I can then fix that one file, eventually doing a git add -A . and git commit again. Note that the bad version of the file still exists in the git history. There are ways to eliminate the bad commit, but I never use them because I've never felt comfortable doing so. It is, to me, quite complicated. I guess I'm still confused as to what you really want git to do. In my way of thinking, git gives me a way to take a snapshot of a set of files at a point in time (via the git add and git commit). And a way to revert any or all of those files back to that point in time if I need to. git does say whether I can modify a file or not. Nor _how_ I can modify that file. It just allows me to take a point in time snapshot, more or less. It can do more, but that is the big part of it, to me. It can tell you what change between snapshots and by whom (if you set it up that way) and other things. On Fri, Jun 28, 2013 at 3:27 PM, Ed Pataky ed.pat...@gmail.com wrote: So you are saying that there is no way to rollback to an old version using git? what is the point then, just to store a bunch of comments? On Fri, Jun 28, 2013 at 12:59 PM, John McKown john.archie.mck...@gmail.com wrote: I will have to note that you seem to have a non-standard definition of version control. git, and other version control software such as Subversion, Mercurial, CVS, Visual Source Safe (or whatever MS calls it), don't track all changes to every file every time the file is modified. They only supply commands so that, at the direction of a user, a snapshot of the file(s) can be taken and tracked. With git, this is the git add and git commit commands. The git commit is what takes the actual snapshot. The git add puts the contents of the files to be updated/added in the snapshot into the index. The git commit actually snapshots the index information into the local git data base (kept in the .git subdirectory) . Perhaps, you eventually update the bare repository using a git push command. Assuming you even keep a bare directory. On some of my personal stuff, I don't because I don't share it with others. Neither is git a security system. If you have been granted write access to a file, it is done using the host operating system's security mechanisms; whatever they may be. In Linux, that is with attributes, ACLS and maybe SELinux profiles. I don't know Windows. But the git software itself is not designed to stop you. That is the OS's responsibility. What it sounds like you want is a versioning file system. That is a file system which keeps old versions of a file each time you modify it, and usually has commands to revert to a previous version. ref: http://en.wikipedia.org/wiki/Versioning_file_system The only system which I have ever used which had this was long ago. It was called TOPS-20 and ran on a DEC System-20
