What's [scanned]? "Conor Rafferty" <conor.rafferty@xxxxxxxxxxxxx> writes: > (1a) Do I need to install windows git on the same machine I want to > store the files on ? Or can I install git on my workstation PC and > create the repo on the server ? The model employed by git is not "client working with centralized server". On whichever machine you want to be recording your changes (aka "running 'git commit'"), you would need to have git installed. > (1b) if i create a repo on my office PC, can it easily be moved > (including all history) to another PC (e.g. LAN server) if we decide to > implement git across the team (If not, or its inconvenient, I need to > create the repo on the server) git is a distributed source code management system. People often deploy one (or more, in hierarchical fashion in an advanced set-up) bare server repository for everybody to meet and synchronize. Each developer has one repository (or more) on his or her own on his or her machines. Most notably, if you work on your notebook and on your desktop (i.e. two machines), you will have (at least) one repository on each of them [*1*]. > (2) if i create a repo on my work PC, can it easily be migrated > (including all history) to a repo on github (etc.) ? I do not know about github in particular (that's #github question) but in principle, yes. Easy exchange of development histories across repositories is the whole point of distributedness. > (3) if I create a repo and commit the first baseline, can I later create > an ancestor commit to that baseline, if I subsequently find an older > version of the project lying around on the file system (or, same concept > i guess, if i find a project version that sits between say version v1.0 > and v1.1 (where v1.0 is the parent tag of v1.1) can i interleave the > project files as say v1.01. You can graft the older ones behind the root commit and filter-branch the result to cast the graft in stone. You are strongly recommended to do that in one repository first, and have reasonable level of confidence in the result before you publish it to other repositories, as running filter-branch to rewrite the history after people (or yourself) cloned the history to multiple places would cause trouble to thoese . For more details, see the user-manual. Don't dive into manual pages for individual commands, which are for people who already understood the basic concepts in the user manual. [Footnote] *1* Maybe we should change our pricing structure to be based on the number of repositories, not on the number of users. Currently we charge $0 per user, but we should change $0 per repository ;-) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
