AW: AW: Parallell Development / Switching to GIT

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]