Re: AW: Parallell Development / Switching to GIT

[Andreas Ericsson <ae@op5.se>]

Patrick Neuner - Futureweb.at wrote:
> Hi,
> 
> thanks for your answers, I appreciate that. I read about
> cherry-picking, but I am not quite sure if that's really what we
> need. Lets assume, you do a new feature:
> 
> /featureX
> 
> You will commit it, check it out on the testserver and probably see a
> bug, fix it, commit and push it again. (and probably more commits
> after the testing person ran over other issues).
> 
> With cherry-picking, I would need to know all commits I have to pick.
>  But as there have been serveral commits, so wouldn't it be a pain to
> check all commits to that file or directory to have the same version?
> 
> 
> Just trying to find the right way to handle that.
> 

I can't help but think you're going about this the entirely wrong way.
It sounds as if every developer has to be able to log in to the test
server to try out their stuff, which sounds just plain insane to me
(unless you're developing supercomputer applications, but a company
named "futureweb" probably doesn't do that).

Anyways, the way you *merge* specific features in git is to develop
them on a topic-branch. If you absolutely do not want that (though I
can't think why, since branching is both cheap and easy in git), you
have to resort to cherry-picking. You cannot merge and say "I want
only changes to these and those files" because you'd end up with 
either a disconnected DAG (meaning git wouldn't know where to merge
from when you want to merge next), or with a connected DAG that
*still* doesn't have all the changes.

In short; Your workflow seems built around the capabilities and
shortcomings of SVN. Git has a different set of capabilities and
shortcomings, so it's natural that some things will feel awkward.
It's like bringing a skateboard to a formula 1 race, really.

With SVN, noone uses feature branches, because merging is a serious
pain. With SVN, every active contributor has commit access to the
central repository, because without it they'd have to juggle patches,
which is boring, and that would hinder them in their work.

With git, a lot of people use feature-branches, because merging is
really easy. With git, there's no real need to let every developer
have write access to the "officially blessed" repository. Instead
it's often useful to have each developer set up his/her own public
repository and then issue "please pull" requests, allowing the
maintainer(s) to fetch their changes, inspect them and then decide
which of the changes to make public. A lot of active git contributors
have their own repositories, and nearly all of the linux subsystem
maintainers have them too. Git also makes it really easy to send
patches by email (and apply such emailed patches). Since git is a
distributed version control system, each developer still gains the
full benefit of using an SCM, while the trusted people act as gate-
keepers for patches that get sent in. But I digress...

> 
> About the 2nd point - I am not sure if I get the different
> repositories thing. Do you talk about to different clones of the rep,
> and give different directory permissions on it,

I'm sure he is, yes.

> or is there a way to
> have like to completly different git rep's running and still merge
> things over (both ways)?

Yes, there is. That's what happens as soon as you have a public repo
and a local repo, and it's how all distributed version control systems
work. They're both separate repositories, but you can merge til your
heart's content between them, ofcourse.

> I just thought this approach would break
> correct mergin, as it doesn't know where it's comming from.
> 

bzzt! wrong. You're thinking SVN. Git has a DAG, with each revision
having a unique name, based on its content and all its history, so
separate copies of the same repository can be merged without problem
at all. This is how Linux development happens; The subsystem maintainers
all have their own repositories, and Linus merges from them during each
merge-window. I think there are about 30 "official" Linux repositories
if you count all the subsystem ones. Git was *designed* for scenarios
like that, so it does it very, very well.

> The only thing I ran over so far is probably doing a hook for that
> (like a pre-pull hook if that exists). didn't get to read too much
> about hooks yet, just did the update hook that checks if the user
> with specific ssh key is allowed to push to a specific branch. That
> works pretty good and is more important in fact.
> 
> But having 2 completly different repos would be another solution, but
> I kinda wonder that mergin would work correctly this way (if both
> sides have changes).
> 

git help merge-base

In SVN, you need to know exactly which revision you've merged before
in order to once again merge the same branch. Git holds that knowledge
already. Spend some time with gitk after following the git tutorial
and you'll probably get a much better grasp of how the DAG works and
how git uses it.

I'd advise you to clone the linux kernel and inspecting its history
using gitk. Every merge-commit you see which has a line saying something
like "merge foo bar frotz of git://example.com/path/to/repo.git" is a
merge with branches from different repositories. I wouldn't be the least
surprised if you find more than 5000 such merges in the linux kernel
history.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.