Noob Question

Noob Question

[awingnut]

I have not used git yet but am planning to. I am trying to get my head
around how it will work and the documentation I found so far is of
modest help. I currently have a Java application developed using Eclipse
on Windows. However, the project is located on a Linux shared drive
which is my Eclipse workspace. I do my builds using ANT on the Linux
host. My main questions center around the git repository and accessing it.

1) Should I install git on Linux or Windows or does it matter?
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?
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.
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?

Thanks for any help understanding how I need to configure all this.

Re: Noob Question

[Andrew Ardill]

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

Re: Noob Question

[W T Riker]

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
>

Re: Noob Question

[Andrew Ardill]

On 22 December 2012 00:27, W T Riker <wtriker.ffe@gmail.com> wrote:
> 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?

You don't need to install it, but there is no harm in it. If you ever
start doing a build from the linux box and decide you have the wrong
version of your code, it would be useful to have git installed so you
can checkout the right version. Installing git is quick and painless,
however, so you can cross that bridge once you get to it.

Regards,

Andrew Ardill

noob question

[Harry Johnson]

I am completely new to git and have only read the tutorial as well as
some git for subversion users documentation. Our company is
considering switching from subversion to git and I have been doing
some experimenting and have run across a potential problem. Our
systems are kubuntu/linux.

I have used git-svn to create a git repo from our subversion repo. I
have done this as user foo which is just an account that is used for
doing central builds. I have then cloned this as repo as myself,
harry. My thought is that the repo owned by foo would be a central
repo that all of the developers, including myself, could clone and to
which  we could then 'git push' our changes. The nightly builds would
then simply build whatever was currently in the foo repo. This of
course completely ignores the complexity of branches at this point but
like I said, I am experimenting. I did a test of this and what I found
when checking the git log is that while the changes I made and checked
into my repo clearly showed me as the author, the same changes after
being pushed to foo's repo showed a different author.

So two things.. First should the author have been preserved? How can I
make sure that it is?

Second, and probably the better question. Am I too focused on the
subversion methodology? Is there a better way of managing a central
build scheme using git?

Thanks!
-Harry

Re: noob question

[Thomas Rast]

Harry Johnson wrote:
> 
> I have used git-svn to create a git repo from our subversion repo. I
> have done this as user foo which is just an account that is used for
> doing central builds. I have then cloned this as repo as myself,
> harry. My thought is that the repo owned by foo would be a central
> repo that all of the developers, including myself, could clone and to
> which  we could then 'git push' our changes.
[...]
> when checking the git log is that while the changes I made and checked
> into my repo clearly showed me as the author, the same changes after
> being pushed to foo's repo showed a different author.
> 
> So two things.. First should the author have been preserved? How can I
> make sure that it is?

Yes, absolutely, and since the author is encoded in the commit objects
it's impossible to change it without also changing the commit sha1s.

Can you spell your experiments in actual commands and output snippets
so we can see what happened?

Did you ever run 'git svn dcommit', 'git rebase', 'git commit --amend'
or similar in foo's repo?  All of these rewrite commits.  As part of
their rewriting they set the *committer* to the identity of the
current user.  'git svn dcommit' sets author&committer to the identity
coming back from SVN.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

Re: noob question

[Harry Johnson]

>> I have used git-svn to create a git repo from our subversion repo. I
>> have done this as user foo which is just an account that is used for
>> doing central builds. I have then cloned this as repo as myself,
>> harry. My thought is that the repo owned by foo would be a central
>> repo that all of the developers, including myself, could clone and to
>> which  we could then 'git push' our changes.
> [...]
>> when checking the git log is that while the changes I made and checked
>> into my repo clearly showed me as the author, the same changes after
>> being pushed to foo's repo showed a different author.
>>
>> So two things.. First should the author have been preserved? How can I
>> make sure that it is?
>
> Yes, absolutely, and since the author is encoded in the commit objects
> it's impossible to change it without also changing the commit sha1s.
>
> Can you spell your experiments in actual commands and output snippets
> so we can see what happened?
>
> Did you ever run 'git svn dcommit', 'git rebase', 'git commit --amend'
> or similar in foo's repo?  All of these rewrite commits.  As part of
> their rewriting they set the *committer* to the identity of the
> current user.  'git svn dcommit' sets author&committer to the identity
> coming back from SVN.

Ah that does sound like the issue then. I did in fact do a git svn
dcommit to commit the changes from the foo repo to our subversion
repo. If dcommit rewrites the commit changing the author then that
would explain it.

So I did a new test. I made a change and committed it to my local
repo. I then did a git pull to bring my repo in sync with the foo
repo, then did a push to the foo repo. Before doing anything else I
checked the author of my changes in the foo repo and sure enough I am
the author! Yay for that.

Now I try to git svn dcommit and I receive the following error:
Merge conflict during commit: File or directory 'bar' is out of date.
Try updating ...

So I do a git svn rebase, followed by git svn dcommit which works. Now
looking at git log I see that my changes are 'authored' by some else.
All that to say that you seem to hit the nail on the head and the git
svn rebase and git svn dcommit are rewriting the commits and changing
the author.

If we do indeed adopt git as our version control system then we would
freeze the subversion repo and not worry about git svn any further so
I think this is ultimately a non-issue and just something we will deal
with during this hybrid testing period.

Thanks!!
-Harry

>
> --
> Thomas Rast
> trast@{inf,student}.ethz.ch
>