git clone copying some files from other projects? - macos

I've forked a repository, and after doing so, attempted to clone it
$ git clone https://github.com/dax/newly_cloned_project.git
the clone is successful:
Cloning into '[newly_cloned_project]'...
remote: Counting objects: 180, done.
remote: Compressing objects: 100% (143/143), done.
remote: Total 180 (delta 57), reused 144 (delta 21)
Receiving objects: 100% (180/180), 206.54 KiB | 268 KiB/s, done.
Resolving deltas: 100% (57/57), done.
but when change directories to newly_cloned_project, i'm greeted with this:
You are using '.rvmrc', it requires trusting, it is slower and it is not compatible with other ruby managers,
you can switch to '.ruby-version' using 'rvm rvmrc to [.]ruby-version'
or ignore this warning with 'rvm rvmrc warning ignore /Users/charliekim/programming/developer application tasks/connect_four/.rvmrc',
'.rvmrc' will continue to be the default project file in RVM 1 and RVM 2,
to ignore the warning for all files run 'rvm rvmrc warning ignore all.rvmrcs'.
I'm using an .rvmrc file for other projects - but this is newly created and has no such file - upon closer inspection, it turns out that a fair few files are in my newly_cloned_project directory - including an .rspec file and accompanying spec directory...
I've looked around SO and Google but haven't seen any reference to this - I've triple checked my cloning process, so it's no problem there (that I can tell?) really not sure what's going on!

Stupid mistake - if anyone else is having trouble like this, be sure to check that you've not made unnecessary changes to your user level gitconfig file (found at ~/.gitconfig on unix systems).
I had added a remote for a specific repository in this file and that was causing the issue.
~/.gitconfig
[remote "origin"]
url = [email_address]:dax/other_repo.git
fetch = +refs/heads/*:refs/remotes/origin/*
should be in .../other_repo/.git/config

Related

How do I get around "Filename too long" error when running `chef install` on Windows 10?

I'm transitioning from berkshelf to the Policyfile workflow, and everything was running fine until I attempted to resolve all the dependencies. Two of my dependencies are from git, so when I run chef install in the cookbook directory, I get the following error:
Error: Failed to generate Policyfile.lock
Reason: (CookbookOmnifetch::GitCommandError) Git error: command `git reset --hard 7e5e4bccf57718cacc246f1b4d501ff7de8ac13d` failed. If this error persists,
try removing the cache directory at 'C:/Users/pcummuskey/AppData/Local/chefdk/cache/.cache/git/780b7dbee933c3a9efbfd3898d54cdf72784fa7e'.Output from the command:
error: unable to create file test/kitchen/.kitchen/tmp/librarian/cache/source/chef/site/877777683730772c36b1e6a3fc3aa2c3/windows/version-uri/a3432e93fb3c21cb7111fde71e435661/package/files/default/handlers/windows_reboot_handler.rb: Filename too long
Checking out files: 100% (389/389), done.
fatal: Could not reset index file to revision '7e5e4bccf57718cacc246f1b4d501ff7de8ac13d'.
Predictably, removing the cache folder had zero effect on the problem. I'm in the middle of checking whether I can get it working in the ubuntu subsystem and/or docker atm, but it'd be nice to be able to run it natively on Windows.
I don't get this problem using "git bash" (MINGW64) packaged in Git for windows installer.
As an example:
$ pwd
/c/Users/foobar/AppData/Local/chefdk/cache/.cache/git/13036489648c6f8811262c6a50ff6b03da2395b7/4416ca3886d025b3ead519f1ee53af03ecb630f64416ca3886d025b3ead519f1ee53af03ecb630f64416ca3886d025b3ead519f1ee53af03ecb630f64416ca3886d025b3ead519f1ee53af03ecb630f6/4416ca3886d025b3ead519f1ee53af03ecb630f64416ca3886d025b3ead519f1ee53af03ecb630f64416ca3886d025b3ead519f1ee53af03ecb630f61
Managed to work around the issue by making a local cookbooks folder and checking out the dependencies to there and referencing them by path. It's not pretty, but it does the trick.

GIT bash not recognizing changes to ".classpath" file via "git diff"

I was using command line GIT GNU bash as GIT client, to check in my Java project that I worked on in Eclipse.
As part of the work, I changed some project build settings, which in Eclipse are recorded in a hidden (.dot) file called ".classpath" in the project's root directory.
For some reason git diff refused to recognize the change:
user#HOST MINGW64 /c/_GIT/myserver (BRANCH1)
$ git diff .classpath
<==== crickets. Empty output!!!!
However, I could see that the file changed, with a recent timestamp (and could prove that it changed by explicitly doing git commit and pushing the change):
user#HOST MINGW64 /c/_GIT/myserver (BRANCH1)
$ git commit -m "remove test" .classpath
[BRANCH1 bd4c1c5] remove test
1 file changed, 28 insertions(+)
create mode 100644 .classpath
user#HOST MINGW64 /c/_GIT/myserver (BRANCH1)
$ git push
Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 610 bytes | 0 bytes/s, done.
Total 3 (delta 1), reused 0 (delta 0)
remote: Simple Bitbucket Commit Checker
remote: Create pull request for BRANCH1:
remote: http://GIT_URL....
remote:
To http://GIT_URL....
77981fe..bd4c1c5 BRANCH1 -> BRANCH1
GNU bash, version 4.3.46(2)-release (x86_64-pc-msys)
git diff without any options or arguments shows the change between your working tree and the index. Most probably your changes were staged for commit (via git add). You could run git status to verify that. To see such changes (i.e. the diff between the index and HEAD) you should have run git diff --staged.

Heroku error message no Cedar-supported app detected

So, I am running into more problems with heroku and this rails tutorial. The rails tutorial I am making had me develop a super basic app. They then had me create a bit bucket account. After this they had me create a Heroku account. Now they are asking me to push my origin master to my heroku host. When I do this, I am getting this error message and I cannot figure it out. Anyone have any hints as to how I could solve this? Thanks so much in advance!
alopex#alopex-TH55-HD:~/work-space$ git push heroku master
Counting objects: 66, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (55/55), done.
Writing objects: 100% (66/66), 16.39 KiB | 0 bytes/s, done.
Total 66 (delta 2), reused 0 (delta 0)
remote: Compressing source files... done.
remote: Building source:
remote: ! Push rejected, no Cedar-supported app detected
remote: HINT: This occurs when Heroku cannot detect the buildpack
remote: to use for this application automatically.
remote: See https://devcenter.heroku.com/articles/buildpacks
remote: Building source:
remote:
remote:
remote: ! Push rejected, no Cedar-supported app detected
remote: HINT: This occurs when Heroku cannot detect the buildpack
remote: to use for this application automatically.
remote: See https://devcenter.heroku.com/articles/buildpacks
remote:
remote: Verifying deploy....
remote:
remote: ! Push rejected to safe-badlands-5004.
remote:
To https://git.heroku.com/safe-badlands-5004.git
! [remote rejected] master -> master (pre-receive hook declined)
You need to cd in to your project directory, as I'm assuming ~/work-space isn't the name of your app.
Do the following: cd path/to/root/of/your/project and try the command again.
UPDATE
Historically, the more major fix for this has been one of two things:
Correctly naming your .buildpacks file (make sure it's not .buildpack)
or
Reinitializing your .git files:
rm -rf .git
git init
git add .
git commit -am "Reinitialize"
heroku create --stack cedar
git push heroku master
I GOT IT! OH LORD I GOT IT!
Ahem...
So, Steve and Collin were correct. I did in fact need to be in my project directory so Heroku could sense my Ruby files and proceed accordingly. I goofed up when I pushed my initial app to Bit Bucket. I pushed my app onto Bit Bucket inside of a main directory. This made my app the a subfolder, which in turn made it impossible for Heroku to detect its presence.
The solution was selecting all of my app, click and dragging it to the desktop and deleting the phony main folder. I the proceeded to put my files back into the Bit Bucket repository and add, committed, and pushed it to Bit Bucket.
If this happens to you, make sure that you also drag the hidden folders in your app into your new folder as well, as that could really mess you up.
Thanks everyone!

Why does gitlab freeze when I clone/pull my repo?

i've created a private repo on gitlab.
from my office's macbook i can clone, pull, push and whatever, but here at home (with a little older macbook), when i try to clone the repo, it stuck on "compressing objects" with a different percentage each time...
no matter how big the repo is (i'm trying to clone a 5KB project..)
eg:
git clone git#gitlab.com:username/myproject.git
Cloning into 'myproject'...
remote: Counting objects: 24, done.
remote: Compressing objects: 26% (6/23)
i can leave it here for hours (actually i tried for about 30 minutes..)
but the only thing i can do is hit "ctrl+c" and kill the process, then it says
Killed by signal 2.
fatal: index-pack failed
i'm using:
OSX 10.9.4
git version 1.9.3 (Apple Git-50)
i tried also to create the folder, then
git init
git remote add origin git#gitlab.com:username/myproject.git
git pull
but the result still the same as cloning the whole project
btw.. searching online i found this answer ( https://stackoverflow.com/a/22798706/1294988 ) so i tried to execute:
git clone https://gitlab.com/0X1A/dotfiles.git
and it did it quick and easy! so what's wrong with mine?
any help?

Can git and subversion play nice together?

I have recently decided to take the git plunge, and am really enjoying using git, even on Windows.
My current open source project lives on subversion, all devs are familiar with subversion so I would like to keep subversion as the "source of truth" for now.
Nonetheless, I want to use git, so I went ahead and created a copy of the source on github using git svn. All my work is done against the source in github and I push my changes to github. Once every few days I also push my changes to svn and rebase.
The initial import seemed to go ok, but now every time I do a "git svn rebase" I keep on getting conflicts, even on files I have not changed in my get repository. This is causing me much pain.
Eg.
$ git svn rebase
First, rewinding head to replay your work on top of it...
Applying: Added git ignore file
c:/Users/sam/Desktop/MediaBrowserGit/trunk/.git/rebase-apply/patch:12: trailing
whitespace.
*/obj/*
error: .gitignore: already exists in index
Using index info to reconstruct a base tree...
:12: trailing whitespace.
*/obj/*
warning: 1 line adds whitespace errors.
Falling back to patching base and 3-way merge...
Auto-merging .gitignore
CONFLICT (add/add): Merge conflict in .gitignore
Failed to merge in the changes.
Patch failed at 0001 Added git ignore file
When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To restore the original branch and stop rebasing run "git rebase --abort".
rebase refs/remotes/git-svn: command returned error: 1
My questions:
Is there any way I can tell git to sync itself up with svn using svn as the source, so I can start with a clean slate. (export latest, check in changes and reset the svn refs somewhere)
Are there any tips and tricks to getting this scenario to work consistently?
Should I have the core.safecrlf and core.autocrlf options set to true? It seems I will need a bit of hoop jumping.
Related:
http://kerneltrap.org/index.php?q=mailarchive/git/2008/4/16/1450834/thread
http://markmail.org/message/vaois4kkr5ggugqs#query:git%20crlf+page:1+mid:i4flex6vmt5tdala+state:results
http://code.google.com/p/msysgit/issues/detail?id=271
It seems getting line endings right is a bit of a black art.
(I realize that this question probably needs to be expanded, please comment on the places that need expanding)
Are you getting line-ending conflicts? Git has a few configuration properties you can set that change how it handles the end of line characters. I have the following set:
# this makes git NOT attempt to convert line endings on commit and checkout
core.autocrlf=false
# this makes git check if the conversion done by autocrlf would be reversible
# this is probably not required because I do not have autocrlf turned on
core.safecrlf=true
Note that I am on windows, all my coworkers are on windows and I am interfacing with SVN through git-svn. These settings seem to do the trick for me.
(source: codinghorror.com)

Resources