Thats definitely food for thought. I could imagine a branch thats for 
maintaining CRIT, which may be the main Development branch or you merge to 
Development as and when you are complete, with CRIT. Otherwise changes are 
made to Feature branches. Those Feature branches could be merged as desired 
from the Development branch. Kind of work independently until you need to 
get other changes. Its just the cost of the merge that I wonder about. I'll 
have to work through a practical scenario and try to estimate what that 
cost will be. But for the developer who is not getting CRIT until they want 
it, it may be sufficient incentive if the merge is easy enough. 

I'll have to see how independent the changes usually are to CRIT. My gut 
feel is that though the file is frequently hit, changes rarely conflict 
with each other. If thats the case, having developers changing CRIT as they 
need to in their Feature branch means they can be as independent as they 
like. No more needing to rebuild every 2 days. And, after merging with 
Development, the integration build can be left to build it and leave the 
developer to work on the next feature. The merge would be done into 
Development in a separate local repo where the developer could rebuild and 
test. Or just go to feature local repo. Or both build Development and go 
and work in feature repo whilst its building.

Actually that doesn't work. The feature branch is now merged with 
Development. They would need to build the local feature repo anyway. Then 
branch again for new work. A separate Development branch local repo would 
not have any particular purpose in managing the CRIT file.

thanks

Whats an 'fs clone'?

On Monday, June 10, 2013 12:06:42 PM UTC+10, Sam Roberts wrote:
>
> On Sun, Jun 9, 2013 at 6:39 PM, benoît person 
> <benoit...@gmail.com<javascript:>> 
> wrote: 
> > On 10 June 2013 03:09, robe070 <goodri...@gmail.com <javascript:>> 
> wrote: 
> >> Different branches or submodule won't work. The change to A and CRIT 
> will be 
> >> required soon - but at the request of the receiver, not forced upon you 
> by 
> >> Git. 
> > 
> > You are not forced to pull / push to all branches you know ? You could 
> > always pull / push in the A-branch and when the receiver wants it : he 
> > merges that A-branch and the CRIT-branch into the merge-branch. 
>
> It becomes more clear. As Benoit says, you could change your work flow. 
>
> Joe and Mary are pushing to the same branch, so yeah, they need to 
> pull before pushing, and if one of the changes they pull touched CRIT, 
> they hate git (or their build system, or both). 
>
> Start using feature branches, git-flow, as you mentioned you were 
> interested in, would solve this, they would be the only pusher to 
> their feature branch. No merging required. Someone, sometime, needs to 
> merge that branch with a master, but it doesn't have to be them. It 
> could be done by a push-button (on github, or with gerritt), or by the 
> code-reviewer. 
>
> Or, if the CI or merge-master-person won't do the merges, have two 
> local repositories/"working copies". Push from one to the feature 
> branch, then in your integration repo, pull, merge or rebase, and 
> push. 
>
> For most people, its easy to have only a single local git clone, and 
> move quickly between branches, using stash, or just comitting and 
> rebasing branches later. But, if you have expensive to re-create build 
> products, then this isn't true. Consider multiple local clones, each 
> for different purposes or branches. I do this with kernels, you do not 
> want to rebuild from scratch each time you checkout a different 
> branch, you keep different repos around for each branch you are 
> looking at, and do local fs clones, which are really, really fast. 
>

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to