On Thu, Jun 6, 2013 at 6:39 PM, robe070 <goodridge....@gmail.com> wrote: > One of the issues with our source code is that there is one file that is > critical to our development. If its changed in our working directory then > the entire solution needs to be re-built. We currently avoid this and > usually end up needing to do it every couple of days or so, unless we are > the developer making the changes to the critical file. We can avoid it in > Vault by simply not updating the working directory with the new version. > > We would use a Central Repository workflow as described here: > http://www.atlassian.com/git/workflows. We would probably end up using the > Gitflow Workflow model. Gitflow is very similar to how we work with Vault. > > With git, it seems that if we want to commit to the Central Repository we > need to pull any changes from the branch we are pushing too. If the critical > file has been changed in that branch then we must receive it in order to > push our changes to that branch. We can of course push the changes then, but > our local working directory will need to be re-compiled. > > Does anyone have experience with handling a critical file like this? > > Does it require that our commits to the central repository only take place > when we are prepared to re-compile? This is a negative for Developer > adoption of git.
A couple suggestions, maybe one will be helpful: - fix your build process, get faster machines, better build too, something...? - put the single critical file in a submodule, this has some pain, but allows it to develop semi-independently - you didn't say _why_ the critical file is changing. If I change file A, and CRIT, and then push those, you seem to be saying some other developer can pull A, and NOT pull CRIT (with Vault). Uhm, that means the change to CRIT is not necessary to use the change to A... so, why on earth was CRIT changed and pushed at the same time? Very strange. I'm having trouble imagining what kind of build env would cause this to happen. - push the change to A and the change to CRIT on _different_ branches, they are semi (see above) unrelated. Then also push a branch that merges the two. People who only want the change to A would pull the feature branch, and changes to CRIT would only be made on the critical branch... this may or may not make sense, depending on why CRIT is changing, and what it is. > If a developer must receive the critical file change, what would you say to > a developer that makes him think its worth adopting git even though it has > this major drawback? Use Vault? Promise to buy the developer a faster machine, or implement a build farm? :-) Sorry, git does not rule over all, for all use cases. Sam -- 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.
