If I am working with a bare repo, can any number of people be pushing changes to the same master branch? or do they all need to make a new branch and eventually merge them? .... my understanding is that with a bare repo, multiple developers can commit and push to the same master branch
On Sat, Jun 29, 2013 at 1:06 AM, Ed Pataky <ed.pat...@gmail.com> wrote: > 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 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=incron&page=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. >>>> >>>> >>>> >>> >>> >>> >>> -- >>> 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.
