Let's say that DeveloperA works on git repository (locally on his computer) and also that there are some files staged in index for the next commit. If DeveloperB then clones this repository via "git clone" command, will he also receive the content of the staging area from developerA's repository?
Asked
Active
Viewed 443 times
3 Answers
5
No, only committed files and changes will be included when another developer clones a repository.
If DeveloperB clones from a remote repository rather than DeveloperA's repository, DeveloperA will have to commit and push any changes to that remote repository for DeveloperB to be able to clone or pull them.
You can read more information about how git clone works in the documentation.
Brian
- 14,610
- 7
- 35
- 43
0
Easy, short answer: no. Stackoverflow requires at least 30 characters in an answer, hence this sentence.
torek
- 448,244
- 59
- 642
- 775
-
There's a reason for that requirement, to prevent non-useful answers like this. – Justin Howard Mar 30 '15 at 22:07
-
1@JustinHoward 'No' Seems a perfectly acceptable and useful answer to a yes/no question like this one. – Andrew C Mar 31 '15 at 00:35
0
Nope. The index is for keeping track of what's going on in a particular worktree. It's a pathname-indexed list of sha's, showing which content in the object db goes where. It's also where git stores its notes about inflight operations, but it's all very straightforward stuff: the index is just a manifest, an indexed list. Cloning duplicates the object db and a selection of references (branches and tags), that's it.
To add content to the repository, you git add it, and git adds it, and then writes the added content's sha to the index entry for its path.
I avoid the phrase "staging area" as if it were toxic waste. If you look at it just right there's a reasonable sense in which it's accurate, but for people who don't already know what the index is it's horribly misleading.
jthill
- 55,082
- 5
- 77
- 137
-
I find the opposite. People new to git seem to get a much better idea if I use staging area as opposed to index. – Andrew C Mar 31 '15 at 01:15
-
@AndrewC I've found people more _comfortable_ with it that way, but it leads for instance to questions like OP's here, prompted by the idea that a staging area should hold content. Start from "nope, just a list" territory and while some or many may struggle to accommodate the notion that git could be that simple, they at least don't get lost in the weeds. – jthill Mar 31 '15 at 01:51
-
@AndrewC It may just be that I've held this view long enough any other is hard for me, but for instance I don't see how to explain [this](http://stackoverflow.com/a/29396902/1290731) to anybody who thinks the index is a staging area without first explaining that it isn't a staging area, and it's a fairly constant theme with questions I see here, people not even examining options or rejecting ideas involving simple index work because they mistakenly perceive it as heavyweight or never felt they clearly understood it before. – jthill Apr 01 '15 at 18:20
-
Hmm. I've always viewed it as a place where you construct the contents of your next commit, and staging area has always worked as a theoretical concept of that for all situations for me. – Andrew C Apr 01 '15 at 18:46
-
@AndrewC but you already know what the index is, and what a commit contains. The mistake I run across repeatedly is people who conceive of the index as actually containing the blob content -- a misconception that doesn't cause trouble until later on, since it doesn't actually make any real difference in the usual day-to-day work. Interesting conversation, thanks. – jthill Apr 01 '15 at 19:09