Re: Noob Question

[W T Riker <wtriker.ffe@gmail.com>]

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@gmail.com> 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
>