Re: Did anyone have trouble learning the idea of local vs. remote branches?

[Shawn Pearce <spearce@spearce.org>]

Salikh Zakirov <Salikh.Zakirov@Intel.com> wrote:
> I think that the particular issue with the workflow in my organization
> could have been solved by the git-checkout and git-clone hybrid
> 
>     git-checkout ssh://path.to/repo.git#branch [work_dir]
> 
> which would clone repository with just one branch and setup the remotes
> file accordingly (The syntax is completely made up, of course)

Right; that would help us to but developers really want two mainline
branches locally (stable and slightly less stable) as they access
them frequently.

Hence the "git clone --only a,b" syntax that was floating around
on the mailing list the past few days.  Of course no implementation
exists yet...
 
> - there is a "mainline" branch of development, kept as ssh-shared git repository
> - mainline commits require some pre-commit testing, which takes ~1.5 hours,
>   so people tend not to commit to mainline too often. On average, a given
>   person commits to mainline once or twice a week.
> - mainlines commits also require a fellow developer review, that's where
>   topic branches come in handy. Topic branches are also useful for testing,
>   as pre-commit testing should be run on several different platforms, thus
>   on a different machines. Topic branches are kept on the same shared server.

Pretty much the same workflow here; except that instead of a 1.5
hour testing requirement to move code into the mainline we have a
several day manual process where humans redo the changes that were
already made in git in the "real" SCM.

Usually humans screw up redoing those changes and it takes a few more
days to figure out why a topic branch it Git that works correctly
fails to even compile in the mainline.  So we don't push to the
mainline often.

--