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

From: Shawn Pearce <spearce@spearce.org>
Date: Nov 8, 2006, 06:10 UTC
Message-ID: <20061108061020.GF28498@spearce.org>
In-Reply-To: <eiqi3f$ouq$1@sea.gmane.org>

Salikh Zakirov <Salikh.Zakirov@Intel.com> wrote:

Show 7 quoted lines

> 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...

Show 8 quoted lines

> - 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.