top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

Git: How to handle a frequently changed file that requires a compile that takes 20 mins

+1 vote
282 views

We are considering adopting git. We are currently using Vault from SourceGear.

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.

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?

posted Jun 7, 2013 by anonymous

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button

2 Answers

+1 vote
 
Best answer

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.

answer Jun 9, 2013 by anonymous
0 votes

Its not about splitting the push that another developer has submitted. Its not about splitting file A and CRIT. Its about not needing any part of that commit in order to work in our current environment. With Git you are forced to pull both A and CRIT before pushing your changes. I don't want either A nor CRIT. The only time I would need them is when I have changed either A or CRIT.

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. Believe it or not I do realise that we do not need to get Git!

So it looks like the only way is reduce the criticality of CRIT. Obviously nothing to do with Git. But anyway, 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?

answer Jun 10, 2013 by anonymous
Similar Questions
+2 votes

Suppose I create a new local branch and name it "mybranch" and made some changes in some files. I commit the changes, checked out to master branch, merged "mybranch" with master branch and pushed the changes to master.

I checked out back to "mybranch", now is there anyway to get the list of files in which I made the changes?

+1 vote

I tried to compile git 2.4.3 on Solaris 10. I used the following configuration:

$ ./configure --without-iconv

$ grep -i iconv config.status
ac_cs_config="'--without-iconv'"
 set X /bin/bash './configure' '--without-iconv'
$ac_configure_extra_args --no-create --no-recursion
OLD_ICONV=UnfortunatelyYes

But when I try to compile it, I get an error that libiconv is missing:

 LINK git-credential-store
Undefined first referenced
 symbol in file
libintl_gettext libgit.a(lockfile.o)
libiconv_close libgit.a(utf8.o)
libiconv_open libgit.a(utf8.o)
libintl_ngettext libgit.a(date.o)
libiconv libgit.a(utf8.o)
ld: fatal: symbol referencing errors. No output written to git-credential-store
collect2: ld returned 1 exit status
gmake: *** [git-credential-store] Error 1

How can I work around this?

0 votes

We are using git-1.8.2 version for version control. It is an centralized server and git status takes too long

How to improve the performance of git status

Git repo details:
Size of the .git folder is 8.9MB
Number of commits approx 53838 (git rev-list HEAD --count)
Number of branches - 330
Number of files - 63883
Working tree clone size is 4.3GB

time git status shows
real 0m23.673s
user 0m9.432s
sys 0m3.793s

then after 5 mins
real 0m4.864s
user 0m1.417s
sys 0m4.710s

And I have experimented the following ways
- - Setting core.ignorestat to true
- - Git gc &git clean
- - Shallow clone €“ Reducing number of commits
- - Clone only one branch
- Git repacking - git repack -ad && git prune
- - Cold/warm cache

Could you please let me know, what are the ways to improve the git performance ?

0 votes

Is there any reason why 'git clone -b' only takes a branch (from refs/heads/) or a tag (from refs/tags/) ?

Background: At $dayjob we're using some kind of 'hidden' refs (in refs/releases/) to communicate between the 'branch integrator' (who creates the ref in refs/releases/) and the 'build master' who wants to build that ref.

It would be a little easier if the build master could simply say

git clone -b refs/releases/the-release-for-today URL
instead of: git clone... ; cd ... ; git fetch... ; git checkout....

Any answer or even a better idea to solve that is appreciated.

...