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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxx
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.
--
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]