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
