git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andreas Ericsson <ae@op5.se>
To: Tim Uckun <timuckun@gmail.com>
Cc: Johannes Sixt <j.sixt@viscovery.net>,
	Avery Pennarun <apenwarr@gmail.com>,
	git@vger.kernel.org
Subject: Re: can anybody explain the following to a git noob?
Date: Fri, 22 May 2009 14:22:26 +0200	[thread overview]
Message-ID: <4A169902.4070902@op5.se> (raw)
In-Reply-To: <855e4dcf0905220436h1b6fa632q7804c98bf09b324c@mail.gmail.com>

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.

  parent reply	other threads:[~2009-05-22 12:30 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-22  3:46 can anybody explain the following to a git noob? Tim Uckun
2009-05-22  5:02 ` Avery Pennarun
2009-05-22  5:44   ` Tim Uckun
2009-05-22  9:35     ` Andreas Ericsson
2009-05-22 10:35       ` Tim Uckun
2009-05-22 10:44         ` Johannes Sixt
2009-05-22 11:36           ` Tim Uckun
2009-05-22 12:04             ` Julian Phillips
2009-05-23  8:03               ` Tim Uckun
2009-05-22 12:22             ` Andreas Ericsson [this message]
2009-05-22 17:33             ` Daniel Barkalow
2009-05-23  8:21               ` Tim Uckun
2009-05-25 11:10                 ` Heiko Voigt
2009-05-25 12:52                   ` Tim Uckun
2009-05-22 11:03     ` Sitaram Chamarty
2009-05-22 13:36 ` Dan Loewenherz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4A169902.4070902@op5.se \
    --to=ae@op5.se \
    --cc=apenwarr@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=j.sixt@viscovery.net \
    --cc=timuckun@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).