From: Caleb Marchent <cmarchent@aminocom.com>
To: git@vger.kernel.org
Subject: Re: Interpretation of '/' changed sparse-checkout
Date: Wed, 23 May 2012 14:09:24 +0000 (UTC) [thread overview]
Message-ID: <loom.20120523T160215-390@post.gmane.org> (raw)
In-Reply-To: loom.20120521T183651-286@post.gmane.org
Caleb Marchent <cmarchent <at> aminocom.com> writes:
Corrected cut-paste errors on first submission, seems I missed a bunch of
terminating '/' when hand-copying the text in from the sparse-checkout files :-(
Sorry.
I have a system where I checkout by default everything except one directory.
Then the rules in the top-level sources can selectivly reintroduce
subdirectories as required for the build target.
I have deployed, using git 1.7.2.5, a set of git trees which use the following
sparse-checkout rules to achieve this.
/
!exclude/
exclude/reinclude/
I have however discovered that if the reincluded directory is the same as the
first part of any other path then that path will also be checked out.
/
!exlcude/
exclude/wanted/
will checkout both:
exclude/wanted/
exclude/wanted_not/
This appears to have bee fixed in git 1.7.10.2 but from that version of git
onwards using '/' to request everything and then exclude a specific directory
from it no longer works.
While I have been able to contrive the same effect with recent versions of git
using the following updated sparse-checkout rules
/*
!exclude/
exclude/reinclude/
Even with this work-around there are two problems:
1) If I have a path: exclude/reinclude/exclude, this will now be exluded where
I would expect it to be included as it was with 1.7.2.5
2) I have a large number of deployed trees across a number of machines that
have the existing format which will break when git operations are performed
after a upgrade to the latest git.
I believe that the interpretation of '/' should be 'everything in the repo',
from which later rules can exclude. I think this is a bug in recent versions
of git. I have been working on some ideas for a fix to the git code based along
these lines. Can anyone confirm if my analysis is correct or provide an
alternate solution?
Also I would like to know if anyone knows the solution to point 1) above as
this also blocks upgrading to the latest version of git.
next prev parent reply other threads:[~2012-05-23 14:09 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-23 13:40 Interpretation of '/' changed sparse-checkout Caleb Marchent
2012-05-23 14:09 ` Caleb Marchent [this message]
2012-05-24 14:28 ` Nguyen Thai Ngoc Duy
2012-05-25 10:21 ` Caleb Marchent
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=loom.20120523T160215-390@post.gmane.org \
--to=cmarchent@aminocom.com \
--cc=git@vger.kernel.org \
/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).