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.
