What is GIT Staging and Difference between Add To Index and Add To GIT Index? - egit

I am using GibHub private repository. I don't have enough knowledge about it.
What is Git Staging ? what is the purpose of Git Staging ?
When to use Git Staging ?
I found two different options to add file in Git Staging.
Project Explorer --> Team --> Add to index
Team Synchronize --> Add to Git Index
Both of them send files to Git Staging. Then What is the difference between these two ?
Which is better to user ? Both of them send files to Git Staging.
Thanks.

They do the same thing. It's just an inconsistency in the labeling.
I pushed a change for EGit to make this consistent, it will be in the next release (3.5).

"Staging" is the process that one performs when selecting which modified files (or portion of files) will be part of the next commit.
The "Index" is the file into which Git stores the files that have been staged. It's also called the "Staging area".
Adding a file to the index is merely saying "Git, this version of this file in my working directory should be part of the next commit I'm about to create".
References:
Egit - User guide
ProGit - Recording changes to the repository

Related

TFVC and consequences of converting branches to folders

Setup:
I have a client with a TFVC source control repository. The root is a folder, not a branch. Scattered throughout the hiearchy are branches, sometimes 2, sometimes 3 levels deep. For using git-tfs to migrate the repository, I need the root to be a branch. However, when I try to convert the root folder to a branch, I get this error:
You cannot create a branch at $/myProject because a branch already exists at $/myProject/Releases/7.3/Metadata.
If $/myProject/Releases/7.3/Metadata is not a branch convert it back to a folder and retry the operation.
Question:
Is there any impact to me "de-branching" some of those branches, turning them into regular folders, so that I can make the root a branch and then use git-tfs to migrate it? Could I possibly lose some of the history? Would I be risking corrupting the source control repository or losing any data? I'm trying to be very careful with the client's source code and not risk losing any data.
Thanks!
Update:
My justification for thinking I need to convert the root to a branch:
* When created a simple test repository to try out the migration, and ran this command
git tfs list-remote-branches https://mysite.visualstudio.com/
I got this message
"No TFS branches were found!"
And on this github issue, it said I should switch to a branch, then I would see it and that worked. So I assumed the clone wouldn't work since it didn't show up in the list. Also, with the similarly structured test repo, when I ran git tfs list-remote-branches, I got:
TFS branches that could be cloned:
$/myproject1/Releases/7.1/Metadata [*]
$/myproject1/Releases/7.2/Metadata [*]
$/myproject1/Releases/7.3/Metadata [*]
$/myproject1/Trunk/Main [*]
Cloning root branches (marked by [*]) is recommended!
PS:if your branch is not listed here, perhaps you should convert its
containing folder into a branch in TFS: -> Open 'Source Control
Explorer' and for each folder corresponding to a branch, right click
on the folder and select 'Branching and Merging' > 'Convert to
branch'.
Based on that, I thought I had to convert it to a branch.
The next command I ran was
git-tfs clone https://mysite.visualstudio.com/ $/myproject1
I thought this gave me an error when the root was a folder, but it just gave me a warning when I reran it just now. The folder structure was something like
folder/folder/branch
folder/folder/folder/branch/folder
etc
warning: you are going to clone the whole repository or too high in
the repository path ! => If you want to manage branches with
git-tfs, clone one of this branch instead :
- $/myproject1/Releases/7.1/Metadata
- $/myproject1/Releases/7.2/Metadata
So it looks like the reponses are right. You can clone off the root without a problem. Thanks!
Don't convert your branch to a folder.
What does the following command tell you to clone?
git tfs list-remote-branches http://tfs:8080/tfs
A doc on the subject :
https://github.com/git-tfs/git-tfs/blob/master/doc/usecases/manage_tfs_branches.md#find-the-tfs-branch-to-clone-optional
Edit: git-tfs is able to clone every folders in a TFVC Collection but if you want to clone the history with the branches, each folder should be converted as a branch.

what Git Ignore field means in github desktop while creating a new repository

see the Git Ignore option in the below image.What I have to choose, I am creating an ionic-framework repository.
https://i.stack.imgur.com/pBvkd.png
.gitignore is a file which, Git uses to determine which files and directories to ignore, before you make a commit. These files/directories will not be pushed into the repository.
If you have any files or directories that don't need to be pushed into the repository, then you can include them. (a simple example : log files)
If there is no ionic option, you can ignore it, and create it locally on your repo, then push it back to your GitHub repo.
To create it, see https://www.gitignore.io/api/ionic3
It does generate an Ionic .gitignore for you.

How to ignore eclipse metadata but preserve the template?

I've got an ARM project in Eclipse...Actually, I'm using the STM Workbench packaging of Base-CDT-Eclipse.
I'm working with a few other guys and we're using a git server to push and pull from.
However, everyone has a little bit different setup as far as where their toolchains are, OS's, etc.
This is causing trouble, because we're git dummies, and when we push changes after working locally, we do
git add .
git commit -m "some message"
git push origin master
And when we pull changes, we just do
git pull origin master
And pray that there no one else did anything in the meantime, because we're afraid of merging differences, but that's a different story.
Anyway, this whole project has a few sub directories that include things like datasheets, Word documents, and what-not...but, it also includes the metadata for the Eclipse project. So, the last person to commit also pushes their unique settings for things like tool-chain path, preferred builder, etc. This breaks the other guys' setup and after each pull, everyone else has to manually update their project settings to fix this.
So, what files are special to Eclipse for project settings and how can I tell git to ignore these files if they already exist? They need to be available for, say, a git clone but they need to be ignored for subsequent git push's and git pull's.
If you need the setting file and not rename it and it's ok forsetting file need not to do version control, so there is a way by .gitignore with below steps:
Create a .gitignore file. touch .gitignore
Edit and save the .gitignore file
.gitignore
filename
Remove the caches from version control. git rm --cached filename
Commit and push
You can ignore those files changes locally with:
git update-index --skip-worktree -- .project
git update-index --skip-worktree -- .classpath
See: "Difference Between 'assume-unchanged' and 'skip-worktree'", it should better resist to git pull.
Another option would be to a content filter driver which generates (automatically on git checkout) a .classpath if it does not yet exist.
That allows you to version a .classpath.tpl template, and you can keep your actual .classpath completely private (and in your .gitignore)
See this answer for more.

push specific files using egit

I thought this would be a no pbrainer, but for some reason can't find anything on the issue - is there a way to push only specific files from egit? Our repository contains a lrage number of files which are mainly of no interest to me, and every time I try to push I get many DIRTY_TREE errors in files I don't care about. Right-clicking on a file and then attempting push, just tryes to push the entire repository
I'm using Eclipse Juno from mac, and BitBucket repository
Thanks!
Git push deals with commit objects, not with files. If you want to push specific files, you have to make a commit that contains only those files. In your case, you might want to look at the git update-index --assume-unchanged <files> command, or at the .git/info/exclude file, which is like .gitignore except it's for your local repository only (doesn't get shared with the upstream repo).

How to check out a project from a server with Git

You may classify my question to the layman's level, but I am using Git for the first time (til now I used TortoiseSVN) and I am not sure how I can check out an existing project from a server, so as to have it available on my local machine in a folder. I have installed Git Bash. Should I run it (Gui), select New Archiv and then specify the path of the project in the server? Is there a better Git framework to install, which is appropriate to make the same task more easily?
I would appreciate also some screenshots if needed in the answers.
Update: I have installed also TortoiseGit. I want to create a new clone by a right click in a directory, but the new Clone is not available after the right click. Does it need additional configuration? If no, what should I do from TortoiseGit to checkout an existing project?
I'd usually recommend learning git from command line. But if you are already familiar with TortoiseSVN then TortoiseGIT is a good tool for you.
Also, I think you should learn git very well. I can recommend the book Pro Git.
To "check out" a git repository is called clone in the git world (you will get a whole copy of the server repository). This can be done either from command line or TortoiseGIT.
git bash:
$ cd /path/to/my/projects
$ git clone url-to-server-repo
Update:
Since you get the "normal" TortoiseGit menu (without clone option), it seems you already have a local git repository. You probably created an empty git repository by mistake. Look for a hidden directory .git in the project directory or any parent directory.
right click on the folder (not right click on nothing in the folder, the icon of the folder you want to clone INTO from the parent directory) and select clone from the menu.
FYI:
clone = create a copy of a repository.
checkout = change the current state of an existing repo to a saved state.
so if you have a repo w/ 3 commits (A,B,C) when you clone the repo you will be at the most current state (C). if you want to see the previous state of the repo you would git checkout B. if you want to see the repo's initial state you would git checkout A
hope that helps.