AW: Parallell Development / Switching to GIT

Hi,

I have been installing and trying out GIT by now and like it. 

I am not sure if I understood everything correctly though. Let me point out 2 parts I just couldn't find a solution for so far:

We are still having the scenario of 2 branches. Master Development.

1) What if I only want to merge a specific file/directly, but not the whole branch, is there a way?

I found that I can git checkout development directory/ but this only works for new added files, it would overwrite changes within the same file of master, if it exists. So it's pretty similar to just copiing files over and commit.

The reason is, that external developers will only commit to development branch. They are working on new features, and sometimes some small bugfixes, or design templates. Those need to be merged separately, and we try to not have more branches. As developers can access our testserver and then see what they have done and test functionality.

If we do different branches, testing on the testserver would always involve merging the branch into development branch, and especially for templates, this isn't a one time update, but might be there are quite some commits, until everything fits.

Is there a way?
  
2) We are using gitosis to give external developers access to the branches and have some kind of access restriction. 
But we are only able to limit push rights, not pull rights. In most cases, that's not a problem, if they see master
And development, but sometimes (like for external designers), we might want them to only be able to checkout some directories. 

Important here is, that merging will still work (like later into the master), and that files go directly into development branch. Same as above, they need to test functionality, so switching branches on the testserver wouldn't work.

As I am coming from an svn background, where both things were possible, I wonder if I just didn't hit the right trail to get this accomplished with git?

Thanks

Patrick

-----Ursprüngliche Nachricht-----
Von: Andreas Ericsson [mailto:ae@op5.se] 
Gesendet: Donnerstag, 25. Juni 2009 12:12
An: Patrick Neuner - Futureweb.at
Cc: git@vger.kernel.org
Betreff: Re: Parallell Development / Switching to GIT

Patrick Neuner wrote:

Conflicts will still happen with git, but "merge horror" no longer applies,
for a couple of reasons (I come from a similar background, but switched to
git in late 2005).
1. In SVN (and CVS), you're merging *unknown changes* into *unsaved state*.
   You haven't committed your changes to the repository before you merge,
   and you haven't (usually) looked at the upstream changes before you
   try to merge. Git doesn't have this problem (and neither does any other
   distributed version control system), since you first fetch changes from
   someone else and then merge them into an already saved state. When a
   merge conflict resolution goes wahoonie-shaped, you can easily restore
   either of the previously saved states with zero hassle.
2. Git has "rerere", which records and reuses previously resolved merge
   conflicts, so you won't get the same merge-conflict more than once, if
   you enable rerere.
3. SVN (and CVS) won't remember which changes are already merged in, so
   they will fail horribly at repeated same-branch merges. Git (and other
   DAG-based scm's) can and do calculate the merge-base for you so you'll
   never have to think about that yourself.

Git doesn't take away merge conflicts, but it does make it (a LOT) easier to handle them when they appear, for the reasons stated above. What you want to do sounds pretty reasonable, although I'd personally use feature-branches for both internal and external developers, since they make it possible to pick which features and fixes you want to release while allowing developers to make as many commits as they feel is necessary for each feature.

We're quite fond of ascii-art here on git@vger. Since I don't know what the different colors mean in the picture, ascii would probably have made more sense (since I then could have commented on it).