can anybody explain the following to a git noob?

can anybody explain the following to a git noob?

[Tim Uckun]

A transcript...

git init
git add . > /dev/nul
git commit -m 'initial import'

git status
# On branch master
nothing to commit (working directory clean)

***** Create new branch  ********
git checkout -b my_branch
Switched to a new branch "my_branch"

*********Try to rename a directory  WTF?: Git thinks any directory with a
.git folder is empty and refuses to rename the directory.
git mv vendor vendor_new
fatal: source directory is empty, source=vendor/plugins/acts_as_audited,
destination=vendor_new/plugins/acts_as_audited

ls vendor/plugins/acts_as_audited/
CHANGELOG  generators  init.rb  lib  LICENSE  Rakefile  README  spec  tasks
test.txt

******** Initial state of the test directory
ls test
fixtures  functional  integration  mocks  test_helper.rb  unit  watir

****** Rename and commit changes
git mv test test_new
git commit -m 'renamed the test directory'

********Current state of the directory
 ls
app  Capfile  config  db  doc  lib  MyProject.kpf  public  Rakefile  README
script  test_new  tmp  vendor


********Checkout master. WTF?: Both the test and the test_new directories
exist. Why does the test_new exist in this branch?
git checkout master
ls
app  Capfile  config  db  doc  lib  MyProject.kpf  public  Rakefile  README
script  test  test_new  tmp  vendor

******** list  the test directory.  WTF?: Where did the mocks subdir go??
(see above for the initial directory listing)
 ls test
fixtures  functional  integration  test_helper.rb  unit  watir

**** Check the test_new directory:  WTF?: Where are all the other
subdirectories?
ls test_new
functional  mocks

******** Merge  Everything is merged properly.
git merge my_branch

ls
app  Capfile  config  db  doc  lib  MyProject.kpf  public  Rakefile  README
script  test_new  tmp  vendor
ls test_new
fixtures  functional  integration  mocks  test_helper.rb  unit  watir


obviously I am doing something profoundly wrong. Can somebody explain why
this is happening?

Re: can anybody explain the following to a git noob?

[Avery Pennarun]

On Thu, May 21, 2009 at 11:46 PM, Tim Uckun <timuckun@gmail.com> wrote:
> A transcript...
>
> git init
> git add . > /dev/nul
> git commit -m 'initial import'

...okay...

> *********Try to rename a directory  WTF?: Git thinks any directory with a
> .git folder is empty and refuses to rename the directory.

Well, why do other folders contain .git directories?  Are they
*separate* git repositories?  If so, git doesn't know what to do with
them and leaves them alone.  (Well, in fact it treats them as
submodules.)

All your other weird problems seem to come from this, as far as I can
tell.  If not, it would be helpful if you could give *complete*
reproduction steps for your problem.

Have fun,

Avery

Re: can anybody explain the following to a git noob?

[Tim Uckun]

>> *********Try to rename a directory  WTF?: Git thinks any directory with a
>> .git folder is empty and refuses to rename the directory.
>
> Well, why do other folders contain .git directories?

It just worked out that way.  I am experimenting with a rails app and
those plugins were pulled from github.

>  Are they
> *separate* git repositories?  If so, git doesn't know what to do with
> them and leaves them alone.  (Well, in fact it treats them as
> submodules.)


yes they are separate repositories. I would be happy if it left them
alone or treated them as submodules.  I was just puzzled as to why git
thought they were empty when they were clearly not.

> All your other weird problems seem to come from this, as far as I can
> tell.  If not, it would be helpful if you could give *complete*
> reproduction steps for your problem.

Those were the complete steps. I did no other operations on the
directory.  So the fact that the test directory is misbehaving is
because a directory in the vendor hierarchy has a .git folder?

I'll have to clean up all those and see if the problem remains.

Re: can anybody explain the following to a git noob?

[Andreas Ericsson]

Tim Uckun wrote:
>>> *********Try to rename a directory  WTF?: Git thinks any directory with a
>>> .git folder is empty and refuses to rename the directory.
>> Well, why do other folders contain .git directories?
> 
> It just worked out that way.  I am experimenting with a rails app and
> those plugins were pulled from github.
> 

But not, I take it, as submodules?

>>  Are they
>> *separate* git repositories?  If so, git doesn't know what to do with
>> them and leaves them alone.  (Well, in fact it treats them as
>> submodules.)
> 
> 
> yes they are separate repositories. I would be happy if it left them
> alone or treated them as submodules.  I was just puzzled as to why git
> thought they were empty when they were clearly not.
> 

Because from git's point of view, they were already managed in a
separate repository as a submodule. When you have submodules in a
repository, the parent repository can't (well, won't anyways) track
files inside the submodule directory, so git ignores everything under
a worktree subdirectory that contains a .git folder.

>> All your other weird problems seem to come from this, as far as I can
>> tell.  If not, it would be helpful if you could give *complete*
>> reproduction steps for your problem.
> 
> Those were the complete steps. I did no other operations on the
> directory.  So the fact that the test directory is misbehaving is
> because a directory in the vendor hierarchy has a .git folder?
> 
> I'll have to clean up all those and see if the problem remains.

A better way is probably to import those projects as proper
submodules so you can update them without hassle later. "git help
submodule" should get you a long way, but be prepared to study the
docs a little so you understand the caveats with submodules before
you use them. For instance, you *will* run into problems if you
later replace a worktree subdirectory belonging to the parent git
repository with a submodule, so it's really better to have them as
submodules from the start.

HTH

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Register now for Nordic Meet on Nagios, June 3-4 in Stockholm
 http://nordicmeetonnagios.op5.org/

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

Re: can anybody explain the following to a git noob?

[Tim Uckun]

>> It just worked out that way.  I am experimenting with a rails app and
>> those plugins were pulled from github.
>>
>
> But not, I take it, as submodules?
>

That's right.


>
> Because from git's point of view, they were already managed in a
> separate repository as a submodule. When you have submodules in a
> repository, the parent repository can't (well, won't anyways) track
> files inside the submodule directory, so git ignores everything under
> a worktree subdirectory that contains a .git folder.

I deleted the .git directory in that subfolder but I got the exact
same message. There was a .gitignore file in there so I deleted that
too and still got the same message.    I think since the initial
checkin has the .git folder in it git has already decided it's not
going to track it.

Anyway as you can see from my original post I decided to mv the 'test'
directory instead because it has no .git directory in it.

>

>>
>> I'll have to clean up all those and see if the problem remains.
>
> A better way is probably to import those projects as proper
> submodules so you can update them without hassle later. "git help
> submodule" should get you a long way, but be prepared to study the
> docs a little so you understand the caveats with submodules before
> you use them. For instance, you *will* run into problems if you
> later replace a worktree subdirectory belonging to the parent git
> repository with a submodule, so it's really better to have them as
> submodules from the start.
>

To be honest I am just trying to learn the basics now and would rather
get comfortable with those before I mess around with submodules.

I still don't have an answer as to why the renamed test_new directory
exists master branch and why both the original 'test' directory and
the renamed 'test_new' directory are missing subdirectories.

Until I understand that I won't feel comfortable using git.

Re: can anybody explain the following to a git noob?

[Johannes Sixt]

Tim Uckun schrieb:
> I still don't have an answer as to why the renamed test_new directory
> exists master branch and why both the original 'test' directory and
> the renamed 'test_new' directory are missing subdirectories.

Did test_new contain ignored files? In this case, when you checkout the
branch that does not have test_new, only the tracked files are removed;
the ignored (i.e untracked) files remain. Therefore, after the checkout
you still have a test_new directory.

-- Hannes

Re: can anybody explain the following to a git noob?

[Tim Uckun]

>
> Did test_new contain ignored files?

No.  I put the entire transcript in the first email. I did not tell
git to ignore anything and there were no .git directories in the test
folder.

> In this case, when you checkout the
> branch that does not have test_new, only the tracked files are removed;
> the ignored (i.e untracked) files remain. Therefore, after the checkout
> you still have a test_new directory.
>

As far as I can tell all the files are tracked after I do a commit.

I can understand why it put the original test directory back when I
changed to the master branch but I don't understand why it's missing a
subdirectory.  I don't think the test_new directory should be in the
master branch at all but I guess I can kind of sort of see why git
might not remove it. What I can't understand at all is why it's
missing subdirectories.

I hate to say this but I tried the exact same thing with mercurial in
the last half hour and it did exactly what I thought it should do. The
master had the test directory but not the test_new and the branch had
the test_new directory but not the test. No subdirectories were
missing out of either one.

Re: can anybody explain the following to a git noob?

[Julian Phillips]

On Fri, 22 May 2009, Tim Uckun wrote:

>>
>> Did test_new contain ignored files?
>
> No.  I put the entire transcript in the first email. I did not tell
> git to ignore anything and there were no .git directories in the test
> folder.
>
>> In this case, when you checkout the
>> branch that does not have test_new, only the tracked files are removed;
>> the ignored (i.e untracked) files remain. Therefore, after the checkout
>> you still have a test_new directory.
>>
>
> As far as I can tell all the files are tracked after I do a commit.
>
> I can understand why it put the original test directory back when I
> changed to the master branch but I don't understand why it's missing a
> subdirectory.  I don't think the test_new directory should be in the
> master branch at all but I guess I can kind of sort of see why git
> might not remove it. What I can't understand at all is why it's
> missing subdirectories.

What's in the subdirectory?  Is it empty?  If so, that would explain what 
you are seeing.  Git doesn't track directories - so an empty directory is 
always treated as an untracked file.

> I hate to say this but I tried the exact same thing with mercurial in
> the last half hour and it did exactly what I thought it should do. The
> master had the test directory but not the test_new and the branch had
> the test_new directory but not the test. No subdirectories were
> missing out of either one.

I don't know if mercurial tracks directories, if it does, then this would 
explain why it behaves diffently to git.

-- 
Julian

  ---
Even a cabbage may look at a king.

Re: can anybody explain the following to a git noob?

[Tim Uckun]

> What's in the subdirectory?  Is it empty?  If so, that would explain what
> you are seeing.  Git doesn't track directories - so an empty directory is
> always treated as an untracked file.

The directories are not empty. They contain various tests (unit tests,
integration tests etc).

>
> I don't know if mercurial tracks directories, if it does, then this would
> explain why it behaves diffently to git.
>

That might be the reason.

I am just baffled. I have run that script many times and it always
turns out the same. For example on one run I removed all the .git
directories in all the subdirectories to see if I would get different
results but it didn't help (git mv worked but the messed up
directories remained).

I also tried renaming other directories and similar things happen.

Re: can anybody explain the following to a git noob?

[Andreas Ericsson]

Tim Uckun wrote:
>> Did test_new contain ignored files?
> 
> No.  I put the entire transcript in the first email.

No you did not. You used 'ls' where you should have used 'ls -a' to also
show the "hidden" directory entries (.gitignore and .git)

> I did not tell
> git to ignore anything and there were no .git directories in the test
> folder.
> 

But the upstream project could well have told git to ignore stuff, and
since .gitignore files are transmitted on clone they would have been
sent along to you.

>> In this case, when you checkout the
>> branch that does not have test_new, only the tracked files are removed;
>> the ignored (i.e untracked) files remain. Therefore, after the checkout
>> you still have a test_new directory.
>>
> 
> As far as I can tell all the files are tracked after I do a commit.
> 

"git ls-tree -r --name-only HEAD" will show you all the tracked files.
You'll almost certainly want to pipe it through less or some such.

Try "git ls-tree -r --name-only | grep gitignore" to see all the
.gitignore files.

> I can understand why it put the original test directory back when I
> changed to the master branch but I don't understand why it's missing a
> subdirectory.

Because that subdirectory was never tracked by git. If it had been, it
would have been there when you switched branches.

>  I don't think the test_new directory should be in the
> master branch at all but I guess I can kind of sort of see why git
> might not remove it. What I can't understand at all is why it's
> missing subdirectories.
> 
> I hate to say this but I tried the exact same thing with mercurial in
> the last half hour and it did exactly what I thought it should do. The
> master had the test directory but not the test_new and the branch had
> the test_new directory but not the test. No subdirectories were
> missing out of either one.

Naturally, since mercurial (rightly) ignores .gitignore files and the
.git/ directory. With mercurial though, you're not only tracking the
history of the files, but also the history of the object databases of
all the git repositories you've cloned and that live in subdirectories
of your master-project. Whether or not that's an actual problem for you
is something you'll have to decide for yourself. If you want to keep
that exceptionally odd configuration, please remember to never run
"git repack -a" in the subdirectories originating from github clones,
or mercurial will think files have gone missing.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Register now for Nordic Meet on Nagios, June 3-4 in Stockholm
 http://nordicmeetonnagios.op5.org/

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

Re: can anybody explain the following to a git noob?

[Daniel Barkalow]

On Fri, 22 May 2009, Tim Uckun wrote:

> >
> > Did test_new contain ignored files?
> 
> No.  I put the entire transcript in the first email. I did not tell
> git to ignore anything and there were no .git directories in the test
> folder.

Obviously, there's more before the transcript started; otherwise, there 
would be nothing to import in the initial commit, and there certainly 
wouldn't be .git directories that came from nowhere. I don't think any 
version control system I know of likes having your initial import be of a 
directory with other working directories for the same system as 
subdirectories. (That is, Mercurial will be fine having git working 
directories in the import, but git won't, and Mercurial wouldn't be happy 
about having Mercurial working directories as subdirectories).

> 
> > In this case, when you checkout the
> > branch that does not have test_new, only the tracked files are removed;
> > the ignored (i.e untracked) files remain. Therefore, after the checkout
> > you still have a test_new directory.
> >
> 
> As far as I can tell all the files are tracked after I do a commit.
> 
> I can understand why it put the original test directory back when I
> changed to the master branch but I don't understand why it's missing a
> subdirectory.  I don't think the test_new directory should be in the
> master branch at all but I guess I can kind of sort of see why git
> might not remove it. What I can't understand at all is why it's
> missing subdirectories.

This tends to happen if, while on a different branch, you editted some 
files and left editor backups or compiled (maybe just-in-time) files in 
that directory. Then there are files in the directory that don't belong to 
any branch, since they're not source files.

It's also highly likely that what's missing is stuff you thought you 
imported initially, but did not actually import due to the confusion with 
it already being a git working directory.

	-Daniel
*This .sig left intentionally blank*

Re: can anybody explain the following to a git noob?

[Tim Uckun]

>
> Obviously, there's more before the transcript started; otherwise, there
> would be nothing to import in the initial commit, and there certainly
> wouldn't be .git directories that came from nowhere.

Sorry. The command before git init is svn export  blah/blah/blah/

I am taking a rails project and putting it under git.  The .git files
are there in the pluging because the plugins are hosted on github and
they ware installed via git clone.

I know people keep mentioning those directories so I want to repeat
myself.  I renamed the test directory which had no .git folders
anywhere in them.  It contains the tests for the rails project and
nothing else.



> I don't think any
> version control system I know of likes having your initial import be of a
> directory with other working directories for the same system as
> subdirectories. (That is, Mercurial will be fine having git working
> directories in the import, but git won't, and Mercurial wouldn't be happy
> about having Mercurial working directories as subdirectories).
>

I now realize that.  I did however did the same thing again but first
deleted all the .git directories before doing a git init.  The end
result didn't change.


>> > In this case, when you checkout the
>> > branch that does not have test_new, only the tracked files are removed;
>> > the ignored (i.e untracked) files remain. Therefore, after the checkout
>> > you still have a test_new directory.

I now understand that this is the way git works. I wasn't expecting
this though. I was exptecting the master branch to look like it was
before I switched to another branch and mucked around.

As I said in a previous email mercurial worked as I was expecting.
Subversion also works the way I expected. Coming from subversion I
never expected git to carry the new directory name into the original
branch.

The way I have always thought about branches was that they are
isolated from other branches and it surprised me greatly when git
"leaked" the new directory from the "my_branch" branch into master.

I still kind of think I did something wrong.  This behavior seems
extremely odd to me.

> This tends to happen if, while on a different branch, you editted some
> files and left editor backups or compiled (maybe just-in-time) files in
> that directory. Then there are files in the directory that don't belong to
> any branch, since they're not source files.

I didn't edit any files. I didn't compile anything. There should have
been on artifacts of any sort.  I did a commit before switching
branches.


> It's also highly likely that what's missing is stuff you thought you
> imported initially, but did not actually import due to the confusion with
> it already being a git working directory.
>

As I said the test directories did not have any .git directories in
them. If they had  git mv would not have worked.

Re: can anybody explain the following to a git noob?

[Heiko Voigt]

On Sat, May 23, 2009 at 08:21:09PM +1200, Tim Uckun wrote:
> > I don't think any
> > version control system I know of likes having your initial import be of a
> > directory with other working directories for the same system as
> > subdirectories. (That is, Mercurial will be fine having git working
> > directories in the import, but git won't, and Mercurial wouldn't be happy
> > about having Mercurial working directories as subdirectories).
> >
> 
> I now realize that.  I did however did the same thing again but first
> deleted all the .git directories before doing a git init.  The end
> result didn't change.

Note that a second git init does not delete the previous database. So if
you want to start from scratch you need to delete the main .git folder.

As already mentioned a script recreating your setup from public sources
would really be a big help to find out were git does not do what you are
expecting.

cheers Heiko

Re: can anybody explain the following to a git noob?

[Tim Uckun]

>
> Note that a second git init does not delete the previous database. So if
> you want to start from scratch you need to delete the main .git folder.

Yes of course.


> As already mentioned a script recreating your setup from public sources
> would really be a big help to find out were git does not do what you are
> expecting.
>

OK. I'll give that a shot.

I would still like to know what went wrong with my own sources though.
 After all I am going to be using it with my own sources.

Re: can anybody explain the following to a git noob?

[Sitaram Chamarty]

On 2009-05-22, Tim Uckun <timuckun@gmail.com> wrote:

> directory.  So the fact that the test directory is misbehaving is
> because a directory in the vendor hierarchy has a .git folder?
>
> I'll have to clean up all those and see if the problem remains.

I believe those look like submodule directories to git,
which are handled quite differently.

man git-submodule maybe a good starting point

Re: can anybody explain the following to a git noob?

[Dan Loewenherz]

It would be nice if instead of a transcript, you provided us with a script
that duplicated your problem instead of having everyone on the git-list play
20 questions.

In any case, I'm going to try and explain what's going on.

On 22/05/09 15:46 +1200, Tim Uckun wrote:
>git mv vendor vendor_new
>fatal: source directory is empty, source=vendor/plugins/acts_as_audited,
>destination=vendor_new/plugins/acts_as_audited

Try reading `man git-mv`. "...it renames <source>, which must exist...".

>ls vendor/plugins/acts_as_audited/
>CHANGELOG  generators  init.rb  lib  LICENSE  Rakefile  README  spec  tasks
>test.txt

What was this `ls` for? Also, next time try doing `ls -a` so people know
what hidden files exist.

>ls test
>fixtures  functional  integration  mocks  test_helper.rb  unit  watir

Again, `ls -a`.

>git mv test test_new
>git commit -m 'renamed the test directory'

Where is `git add .`?? Additionally, you must specific the `-a` flag on `git
commit` to apply the commit to files you removed.

>********Checkout master. WTF?: Both the test and the test_new directories
>exist. Why does the test_new exist in this branch?
>git checkout master
>ls
>app  Capfile  config  db  doc  lib  MyProject.kpf  public  Rakefile  README
>script  test  test_new  tmp  vendor

This is because you didn't commit the deletion of test. I can't speak to
anything else. It's like telling you to change your tires when the engine
has disintegrated.

Best,
Dan