I created an internal library which can be use for frequent and common use case, then use git submodule for better modularization.
After that you will see Ref's hashes something like this in the IntelliJ IDE.
Looks like it needs to be push as well for the CI CD to work properly and be able to build the project. Pushing those changes will result to the submodule being added and visible to the main module repository.
Now when you change or update the submodule code, another ref hashes like the first photo above will show. My question is do I still need to push those changes or ignore it since the submodule is already added to the main module and during project building a git clone is being perform in the pipeline by default.
Related
We are two developer and we want to work on a same project at the same time. So, we use GitHub. However, we couldn't do this.
This is our problem;
I am pushing new xcode project to our master, then, my friend are pulling this xcode project. Every thing is ok since here. Then, I am changing some codes, then, I am pushing (commit and push) it again. When my friend change some codes (he didn't pull) and push it, there is an error like this: "The local repository is out of date. Make sure all changes have been pulled from the remote repository and try again."
Actually, we want that, we change some come codes, then, I and my friend push it, then these two file will be merged. How can we do this?
he will need to do git pull --rebase which will pull the branch and put his changes on top of yours
you should really branch each feature though and work on the conflicts during merge
I just installed the new OS X Server with Xcode CI (http://www.apple.com/osx/server/features/#xcode-server).
I have successfully setup CI for my project, but a submodule of the main git repo is very big (it contains version-controlled images, not code).
For performance and space-related reasons I'd like the CI to use a shallow clone instead of a full clone when getting the submodule. Is there a way to configure the CI to do that?
Or is there an alternative way to speed up the process?
Shallow submodules are possible with git, the problem is with Xcode CI.
Using git to store large binary images is anti-pattern, so it might never be an optimal fit behaviorally. For Xcode's sake, ideally you would not use git at all for this purpose, and just script into CI that the build process retrieves a single image (for example, via a rake or gradle task, wget, curl, scp, etc.). If it is really an image target, you probably have the ability to reference it, like this jar file:
https://github.com/projecthydra/hydra-jetty/blob/master/solr/lib/solr-analysis-extras-4.9.0.jar
The CI is not interested in the availability of other possible states for the target, or the revision history. It just wants to fulfill the dependency.
If you must use submodule, you could set up your own slimmed internal repo target called [that_submodule]_current that just has the single state you want. Blow it away and replace it as needed.
Note that Xcode apparently has a detached submodule head bug, so that suggests it will be some time before they handle other slightly more exotic submodule options like --depth.
Sometimes I have problems with my Laravel project after running composer update. I believe this is caused by changes in the Laravel application skeleton (https://github.com/laravel/laravel). How do I update my local project to reflect those changes?
From the awesome forum post on the Laravel forums by Kindari (http://forums.laravel.io/viewtopic.php?id=5367):
If you originally cloned this repository and still share a git history
with it, you can usually merge in changes easily. Assuming your remote
is 'upstream' pointed at this repository, you can do the following:
git fetch upstream
git merge upstream/develop
Alternatively you could cherry pick in individual commits
from the develop branch, but I won't cover that here.
If you downloaded the zip distribution originally or
removed the upstream history, you can still resolve your problem
manually. Look at the commits on this branch and make any changes not
present in your application. Usually the breaking changes are simple
configuration changes.
Since most of the changes are likely to be simple configuration changes,
another option is to do a diff on the root folder and the /app folder. You'll mostly see your own configuration, but you'll also see any new configuration items that you should add.
I usually use git pull request. A git pull request does a git fetch followed by a git merge. It works for me nicely. In other words, A git pull is what you would do to bring your repository up to date with a remote repository.
my Hg repo now needs to include a Git submodule (Restkit) as per the advised method in the site wiki.
However, I am not updating the git contents and should only be potentially reading/pulling in changes from the host.
It appears that when I came to make my first push of my main Hg repo it baulked at the Git one asking for a password. I think this may be because its attempting to authenticate against the Git site as well.
My questions are can I arrange this so that the Git repo is read-only(pull) or even static and/or get round the log in issue. Obviously the two different repos have different credentials.
Thanks.
P.S. using Atlassian SourceTree 1.5.3 on OS X 10.8.2, Xcode 4.5.1
I've just re-read this;
2.6. Synchronizing in subrepositories
Subrepos don't automatically track the latest changeset of their sources. Instead, they are updated to the changeset that corresponds with the changeset checked out in the top-level changeset. This is so developers always get a consistent set of compatible code and libraries when they update.
Thus, updating subrepos is a manual process. Simply run 'hg pull' and 'hg up' in the target subrepo, test in the top-level repo, then commit in the top-level repo to record the new combination. The onsub extension can be used to automate that.
Assume this means its not pulling the sub? but I still have the above issue of the password request.
You moved in the right direction, but not finished all required steps.
You have to have subrepository, create it by hand... and don't mix real subrepository with a) independent b) nested repository
When you'll convert nested to subrepo push into master repo will not perform push to subrepo (except it requested)
I am really frustrated about using git's submodule feature. Either I still don't get it right or it just don't work as I am expecting this. Following project situation is given:
Project
| .git
| projsrc
| source (submodule)
| proj.sln
In this scenario source is pointing to another repository containing the common source data across all our projects. There is a lot of development happening under source as also under projsrc. Unfortunately Project points to some commit of the source submodule and not to the actual HEAD of it. This is the usual git behaviour, as far as I got it know.
I already found out that
git submodule update
just get the version of submodule which was commited together with the main Project. However, I would really like to be always up-to date with the submodules development, but do not have any real clue how to do this right. Hence my question is:
Is it possible to attach the Project to the HEAD of the submodule,
reagardless of the fact if this will break the compilation of Project or not.
I just don't want to go always into the submodule
directory and do git pull there. Since I think I could loose my changes done
in the submodule directory, because this is simple attached to a
commit and not really to any branch or so.
Please consider following constraints:
Developers in our group are not that familiar with all VCS around. We are used to use really huge svn repository before, without any external repo features at all.
We are working on Windows
A click'n'forget solution would be best, since most of project members are rather scared by using a command line interface :)
The reason why a submodule points to a particular revision is important. If you point to a HEAD, builds will be unreproducible. I.e. if you checkout yesterday's a version of the Project, you would never know which exact version of source#HEAD was yesterday.
That's why it always stores particular revision sha.
To pull all submodules you could use Easy way pull latest of all submodules
I am not good at Git and submodule. But I think some simple rules would be very helpful.
Commit and push from sub-directory.
Go back to root of your project, check the status if you need to commit and push again.
when Pull. can try to use script to bundle the "pull/submodule update" together. And only do it at the root of your project.
Consider this:
source is pointing to HEAD (as you would want).
you make changes to source inside you Project (you commit but not push them)
now you have two HEADs : one in your Project's source, another in your common source.
Which one you would want to be present in your Project when you make submodule update?
The problem (and the main feature) of git in your case is that you consider commit and push as atomic operation. It isn't. Git is decentralized. There is no common HEAD. You might have multiple repositories with different HEADs.
Consider this:
you have 3 developers (A, B and C) with a git project.
they all pull a project's HEAD.
each developer has made changes to project
now each of them has 3 HEADS: A HEAD, B HEAD and C HEAD.
Which HEAD you consider "true" HEAD?
So, to answer your question: If you want common source submodule always be synchronized with central repository, git isn't your choice. And probably none of VCSs would help you with that.
You should treat git submodule as a thirdparty library which should be updated manually with these two steps:
Pull your submodule ("download thirdparty library")
Commit your project with updated submodule ("place the new version of thirdparty library to your project")
If you want to make changes to submodule you should do the same in reverse order:
Commit your submodule ("make your changes to the thirdparty library")
Push your submodule ("send your changes to the thirdparty library maintainer")
Commit your project with updated submodule ("place the new version of thirdparty library to your project")