Commits using tortoisegit not showing up in sourceforge repository - tortoisegit

I set up tortoise git to commit to my sourceforge repository. It does commit -> master, shows everything as fine, but nothing is showing up on sourceforge. It was set up using the recommended command line procedure using git as sourceforge listed (although it shows up as "author unknown", another problem). Where the heck is it commiting to?
Scott Moore

Commits are all local until you "Push" to the remote. The local repo is on your computer in whatever folder you cloned into.
The unknown author thing is probably because you haven't told TortisGit who you are (check settings for the name and email values).

Related

GitHub won't let me push to remote folder (in Xcode)

I'm trying to set up a GitHub Repo for an existing Project (in Xcode). I'm already logged in with my GitHub Account. But as soon as I try to Push a commit to the Remote Repo, this Window Pops Up
I can't select anything. How can I fix that?
You can't push a local repo that is not associated with a remote repo (known, for short, as a "remote"). Give this repo a remote. You can either make one at GitHub now, or associate this repo with a repo at GitHub that you have created already. Here's how to do that using Xcode's interface:
Personally, though, I never use Xcode's Git interface for much of anything; it's atrocious. Learn to use the command line; you'll be much happier (in my opinion).

How to use GitHub in VS 2015 so a moron can understand?

Downvote if you want... but I need a set of simple basic steps that we can follow. We have VS Enterprise, no GitHub add-ons installed. We have a an empty repo created on GitHub. What do each of the developers do after that? There's a local repo, right? Should there be another project on the local machine that commits to the local repo or do we open the project in the repo? If yes, how do we create that other project? What about the .sln file that VS lovingly puts in a separate folder? We have been at this for hours and believe me we have tried every combination of commit/push/sync/goat sacrifice except the right ones. We cannot reproduce consistent results such that two developers can work against the same remote repo. Sometimes one developer can push and he doesn't see the files pushed by the other developer. Sometimes the Commit Message text box lights up but the Commit button is disabled. I thought I was reasonably intelligent until I started working with GitHub.
I'll give you the broad steps you need to do. You may need to fill in a bit of the detail. THis is how I would work it. I am sure you could get many other opinions.
Create the repo on GitHub (which You already have done.)
Each developer should then go to the GitHub repo and fork the repo under their own GitHub account.
Each developer then needs to clone their repo to their local machine. (That's the beauty of Git. Every developer has the entire repo locally.) You can do this in VS2015 by choosing: File -> New -> Repository -> Clone.
Go to your on-line repo and get the URL of the repo that you will be cloning. Enter it into the New Repo dialog box in VS.
When working on the project, each developer should create a temporary feature branch, which they push to their own GitHub repo. They can then push their work as often as they want without it conflicting with other developers.
When a developer thinks that their work should be merged into master, they should go to GitHub and issue a "Pull Request" for their feature branch.
Their PR can then be discussed among the team before it is accepted.
Once it is accepted and merged into master, the developer can delete their feature branch locally and on GitHub, if he likes.
Since "master" on the team repo has now been updated, each developer will need to pull down master from the team repo to update their own local and remote repos.
It sounds more like an how-to-use git issue. You probably first need to see how two collaborators work on same project with git. I donot think either VS or GitHub has anything to do here, as both only provides you git gui tool regarding this issue.

Add Github remote to GitKraken

I'm using GitKraken (v. 1.4.1) as my Git managing tool. And now I want to use Github as a remote to back up my repos. But when I click on add remote and try to add a Github repo, it just says 'no match'
Does anybody know why this happens? (BTW: I'm using Windows 10, just in case that's relevant)
Here's how it seems to work. If you have a local repo and want to connect it to github, you would use the "URL" option and put in the github address to set that as the remote repo for your local repo. The first time you do a pull or push on a local branch, it will ask which remote branch you want to use and that becomes the remote location to which you will pushing and pulling changes.
The GitHub.com option only comes into play after you have set the remote repo using the "URL" option. If there are multiple collaborators on a project and someone has created one or more forks of the project, then instead of "No Match" under the GitHub.com, you would see a list of all the forks of the project on which you are a collaborator.
You could then add the forked repos as the 2nd, 3rd, etc. remotes, and any activity on those forks would be displayed to you on the commit graph. This allows people to see what's going on in the forks, and you can drag and drop from the forked parts of the graph to create pull requests to the repo you first set up using "URL".
It's a nice feature, but the remote dialog could be labelled more clearly so that people would know the GitHub.com option was for adding forked repos to the commit graph display.
You must always use the "URL" option to add the 1st remote, and then the GitHub.com option only becomes available after that if there are forks to which you have access.
If GitHub is set with your account in GitKraken, you might need to create first an empty repo with the same name as your local repo.
That way, GitKraken can find a matching repo name in your GitHub account.
Or you could select "URL", and enter the right GitHub repo url directly there. Which is what Jim Meyer's answer confirms above.
Note that GitKraken 6.5 (January 2020) will create, then add a GitHub fork repo automatically!
Forking GitHub Repositories in GitKraken
Formerly, users were required to leave GitKraken, go to their hosting service, fork the desired repository, come back to GitKraken, find the related remote, and then find the forked repo. 😅
Now, GitHub users can fork repositories directly through the GitKraken GUI, no more time wasted context switching.
v6.5 allows users the ability to fork GitHub repositories in GitKraken through the GitHub integration.
Simply navigate to the remotes pane in the left panel and click the + button to add a remote.
If you don’t already have a fork on the selected GitHub repository, GitKraken will automatically present you with the fork option.
You will see the message “You have not yet forked microsoft/vscode on GitHub.”
Click the Fork and Add Remote button, and it will fork the repo and add it as a remote to the left panel.
Gitkraken (V3.3.4 64bits on windows) behaviour is strange at this feature level. Same name or URL input doesn't work for me.
So the best and quick way to attach the remote repo to your local is to use the simple Git command line in local repo directory (git#... is your remote URL Github, GitLab...):
> git remote add origin git#...
Gitkraken recognise dynamically it after less than 5 second . Then you can push your existing local files.
Not to add to an old posting but I had the same issue and found this article first so wanted to help anyone else having this issue.
You can get to it by doing the following.
Click the folder icon in the top left corner
Click Clone
Go to the GitHub tab and you will see all your GitHub repos. Clone the one you want and then open it and you are set.

How do I allow 2 people to work on the same local copy of a git repository? Or can I?

This might be verbose, but I'm just starting out with git, so I'm still learning here.
Before now, I've had a team of developers all working off of the same hard drive with a local copy of all of our dev files. So we have 1 hard disk and 4 developers. All of us use sublime text and work on the projects together. We all work in the same room, so it's never been an issue to work on the same project at the same time. We just don't work on the same file at the same time. Not the greatest system, but it worked at the time.
Now we want to introduce git to the team for all of the reasons a VCS is important. The problem we're running into is files being locked by one user and no one else can use git on that repository.
Here's an example. I log into my mac in the morning and make some changes to files in Project X located at /Volumes/dev/projectx/. I open terminal and commit those changes to the local repository (stored also at /Volumes/dev/projectx/). My coworker gets in and logs into his mac. He opens up his terminal to check the status on the repo he's working on. So he moves into /Volumes/dev/projectx/ and runs git status. He gets an error message that says the index is locked. In order to allow him to run any git commands on the repo, I have to completely log out (maybe just kill some processes, but I don't know which ones). After I log out, he can work as though there's no problem.
Is there any way that we can both work on the same local repository at the same time?
I've also discovered that, if I'm working in a project that has a git repository in it and anyone else even opens the project folder in a finder window, it completely locks me out from using that git repo (same index lock error).
We're willing to change the way we work on files, but since there are literally thousands of projects on the drive, it isn't really practical for each of us to have our own local copies of all of the files. Also, since many of the changes are a very simple text change of some kind, it seems tedious to host all of these repositories remotely and have to pull down all the files anytime we only want to update a single file.
I'm really looking for workflow suggestions here, but the question I asked is kind of the starting point here.
The whole point of using git is that you don't have to do this kind of crazy stuff.
I know what you've said about why you don't think you should all have complete copies. Here's the hard truth. You're wrong. Mostly. But that's ok, you said your willing to rethink how you work and that's good. Ill try to explain why its not that big a deal to have everyone use their own clones.
A assume all code is already in a remote repository - if its not, sign up on http://github.com or http://bitbucket.com and get a free repository, add it as a remote to your git repo, and push it up. Its really very simple.
Each of your developers should then make their own directory locally on their machines where they can clone the whole repository.
git clone http://github.com/yuoraccount/yourrepo ~/clones/localproject
The first time they clone, it will take a little time to download everything, but from then on, only each minor diff will need to be downloaded uploaded. Git is made to be efficient that way.
When you make a change, commit it, and push it up.
git commit -am "i made a small change"
git push origin master
Then everyone can pull it down.
git pull origin master
You can even all work on different branches, so your not just pushing to the same branch. This should all be really simple, and very easy to do.
You can also split your project into multiple repositories, but you don't really need to. Thousands of files is not a big deal, git can handle it without a problem. That's not to say that you won't have some challenges. Git is easy to use, but you'll eventually run into merge conflicts. They will be a little bit frustrating at first, but stack overflow has a thousand answers explaining how to deal with them - you should be fine.
This is what git is for.
Git is a decentralized version control system. The way you want to use git could be described as the opposite of decentralized.
There are a number of perfectly reasonable workflows possible with git, but all of them are going to involve each developer working in a local clone of some repo.
i guess that your "single harddisk" is really a single "network storage" that can be accessed concurrently. otherwise i don't see the problem (the harddisk can only be attached to a single computer at any time; whenever you unplug the disk, any locks should be released!)
anyhow, though you currently consider it impractical, you still might consider using per-user clones of the repositories.
the normal workflow of a multi-user repository would consist of a local clone of each repository on each developer machine (that is: a clone on your personal mac).
then the trouble with concurrently accessing the locked central repository doesn't exist!
it's exactly the use-case for which git was designed.
this would allow your users to work on the repository even without having access to your central network storage.
if you are concerned about disk-space, you might be happy to hear that git does a pretty decent job of compressing the data (just run git gc every once in a while in your repository).
if (for whatever reasons) you cannot have local copies (on the dev-machine) of the repositories, you might consider having per-user clones on the central storage.
git can use hardlinks for local clones, so disk-space should not be an issue here.
Section 4 of the Pro Git book (version 2) is about "Git on the Server" and gives some information about what the OP is trying to achieve.
The OP's situation calls for the "Local Protocol".
Here is how this works:
1. Create a local remote from your project
cd into your project and create the remote in your preferred location (in your example /Volumes/dev/projectx):
git remote add origin /Volumes/dev/projectx.git
2. Set the permissions for the remote
git init --bare --shared /Volumes/dev/projectx.git
This will set the permissions properly so that different users can push and pull to/from the remote. This command does not affect your Git history and is safe to run.
The --bare flag is used because all that is needed for a remote is a bare repository, that is, a repository without a working directory (a repository with only the .git directory and nothing else).
Note: this step is not described in the Git Book for the Local Remote protocol and is only suggested when setting up a Git server, but in the experience of a colleague, without using this step, the permissions were not set properly.
3. Push the data to your new remote
Assuming you have a branch called main (do this for any branch you want your collaborators to have access to):
git push --set-upstream origin main
4. Have your collaborators clone the remote
This works as with any remote:
git clone /Volumes/dev/projectx.git
From here on, everybody can push and pull to/from the local remote.

How to pull files from github branch to xcode directly?

I have a project created for me by teacher and I have to improve it. He created a repo on Git Hub with branch for me. I'm trying to pull the project files from that branch directly to Xcode and Xcode refers to the branches that I have created which are empty, not the master one. Can't find any adequate manual for that as well... Please help...
so github uses git to manage repositories, so this question has more to do with git than with github.
Git is a distributed-repository source-control system, which means that every machine has a full copy of the repository, with all of its history and branches. This means that your local repository that you cloned from GitHub has all of the branches on it.
So, your problem is actually just that you need to switch branches locally to the branch your professor created.
In a terminal you can execute
git checkout <the-name-of-the-branch-your-teacher-created>
and that should do it. :)
Xcode is simply looking at the files in your working directory, so switching branches will update the files in Xcode as well.
For more git information check out the git book or any of the other countless git resources online!
Well using Git is fairly simple and as specified above can pull the project (either complete of specific brach and then import it.
OR
While running Xcode you can follow below steps -
Click on Check out an existing project.
Enter Repo link as shown below and hit Next.
Select the branch that you want to pull and hit Next.
Note As shown in Image Xcode version 8.2.1 is used.

Resources