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.
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
> >> 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
> >> 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
> 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
> 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
For more options, visit https://groups.google.com/groups/opt_out.