Hi Andrew, Thank you for a great explanation. It clears up a number of things but also creates some new questions. However, armed with this I am going to run through the documentation again and perhaps it will make more sense to me. One basic question, since I don't make changes from the Linux side, only builds, do I need to install anything git related on that machine? On 12/20/2012 8:43 PM, Andrew Ardill wrote: > Hi! > > On 21 December 2012 12:07, awingnut <wtriker.ffe@xxxxxxxxx> wrote: >> My main questions center around the git repository and accessing it. > The main thing you need to know is that you can work on your code base > in the *exact* same way while using git. You don't *have* to change > anything about how you work, as git's primary purpose is to store > snapshots of your work so that you have a history of what has changed. > > That being said, you can (and maybe should) change how you work to > take into account the power of git. Most of what you do will stay the > same, however. > >> 1) Should I install git on Linux or Windows or does it matter? > Install git wherever you need to access the code. From the sounds of > it you will want git on both machines, as you are working on windows > and but keeping the code on the linux shared drive. When working on > the windows machine you will use a windows copy of git to manipulate > the workspace, though I'm not sure if there are any gotchas with the > interaction with a linux shared drive. > > If you want to manipulate the repository from the linux machine you > will need git on it as well. > > Unless you're using a git server, manipulating the repository is a > local action and so is performed by the client. That is, when working > on windows use the windows client, if you also work on the linux > machine then you will need a client there as well. > >> 2) How will my build scripts access the source? Will it be the same as >> now (my scripts 'cd' to the Eclipse project directory and run there) or >> do I need to add a wrapper to my script to check out the entire source >> for the builds? > It's the same as now. Git uses the concept of a 'work tree' to talk > about the actual files you are working on now. The work tree > corresponds exactly to your current project files. When you create a > git repository you gain the ability to store snapshots of this working > tree into the 'object store', as well as metadata about the snapshots, > so that you can restore that snapshot later. > > Your actual files keep their current layout and format, until you change them. > >> 3) How do I move my current Eclipse project into git after I create the >> empty repository? I can only find info on how to import git into Eclipse >> not the other way around. > You have two options. Create the git repository in the same location > as your Eclipse project. Navigate to the project folder using git bash > and do a 'git init' inside it; voila! you now have a git repository. > You can choose to create a 'remote' repository somewhere to store a > backup of your code as well, but this _still_ requires you to init a > local repository to backup. > > The other option is to create a blank repository somewhere (anywhere) > and then tell that repository to use your Eclipse project as its > working tree. The benefit to doing this is being able to keep your > snapshots and metadata in a different location to your working > directory (say keep the snapshots on a local windows drive while your > working directory is on the linux share). Unless you shouldn't or > aren't able to create the repository within the Eclipse project, I > would recommend against this. > >> 4) Do I need to checkout the entire project from Eclipse to modify and >> test it or only the classes I want to change? Does the plugin get the >> others as needed when I run the app within Eclipse for testing? > Not sure exactly what you are asking here, but in general people will > 'clone' an entire repository including all its history. If you want to > update only certain files that is fine, but the commit object stores > the state of the entire tree of files. Note that a commit object does > _not_ store the difference between two snapshots, but stores the > entire state of the files. You can grab a file from a given snapshot > and test that along side files from a second snapshot, but if you > wanted to commit the resulting tree to the repository it would store a > third snapshot containing the exact state of all files. > > Hopefully that clears it up for you? > > Regards, > > Andrew Ardill > -- 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