Hello, thanks for your really helpful and detailled information I got, it helped us a lot to get started. And I got the point of using branches and thinking different about the workflow. I stumbled over something I just can't figure out, I kinda feel stupid as it must be something really simple, but going up and down docs, just can't figure it out. We use the update-hook to check into which branches pushes are allowed per different ssh keys. Now, I wonder how I am able to create branches that are below another branch. Like Refs/heads/master Refs/heads/dev Refs/heads/dev/featureA Refs/heads/dev/featureB Instead of Refs/heads/featureA Anything I tried either results in an error or creates the branch under /refs/heads/. For the update hook this would be helpful as we won't always be able to pull from a developer, so they would need to push their feature branches up to our public one. (as we prefer it this way instead of receiving patches). I found on following page what we need, so I bet there is a way I just couldn't figure out how? Basically the refs/heads/bw/.* example is what I am seeking, so each developer can push feature branches up under development. I do understand it's nothing different if the branch is under /refs/heads, but first it would be cleaner, 2nd access control is better handled. ++ http://www.kernel.org/pub/software/scm/git/docs/howto/update-hook-example.txt refs/heads/master junio +refs/heads/pu junio refs/heads/cogito$ pasky refs/heads/bw/.* linus refs/heads/tmp/.* .* refs/tags/v[0-9].* junio With this, *Linus can push or create "bw/penguin" or "bw/zebra" or "bw/panda" branches*, Pasky can do only "cogito", and JC can do master and pu branches and make versioned tags. And anybody can do tmp/blah branches. The '+' sign at the pu record means that JC can make non-fast-forward pushes on it. ++ Thanks Patrick -----Ursprüngliche Nachricht----- Von: Andreas Ericsson [mailto:ae@xxxxxx] Gesendet: Montag, 29. Juni 2009 10:35 An: Patrick Neuner - Futureweb.at Cc: Jeff King; git@xxxxxxxxxxxxxxx Betreff: Re: AW: Parallell Development / Switching to GIT 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@xxxxxx 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html