Re: [PATCH v2 2/2] git-cvsimport: allow local timezone for commits
Chris Rorvick ch...@rorvick.com writes:
CVS patches are imported with the timezone offset of + (UTC).
Allow timezone offsets to be calculated from the the local timezone by
adding -l to the command line or specifying cvsimport.l in the config.
A single I do not like everybody's timestamp is in GMT, so instead
use the local timezone I the importer happen to be in sounds more
like an uninteresting hack with limited application than a useful
new feature. Even back in CVS days, many projects and repositories
worth converting to Git were multi-people projects that span across
timezones.
I am wondering if it is sufficient to enhance existing cvs-authors
file to tie a person to a timezone to add a feature like this in a
more sensible manner. I'd assume that in many multi-person project,
one person, even when travelling, tend to record commits in a single
timezone (i.e. his or her home timezone). Even for a single-person
project, adding a single entry ot the file is not too much to ask to
the user. Being able to view his human-readable name and timezone
would be good value for the amount of trouble.
This could be made the default behavior, as setting TZ=UTC in the
environment before doing the import is equivalent to the current
behavior. But since a new default may be an unwelcome surprise to
some, make this new behavior available as an option.
This, just like use of cvs-authors, will never be the default.
When you and somebody else import the same history recorded in the
same CVS repository, you would want to see the same resulting
history, and that is even more true when these two people may
perform their import incrementally. If you switch the default
in one version of Git, their histories will diverge at a different
place depending on when their sysadmins updated Git.
The repeatability is why the script does not use the local timezone
the importer happens to be in.
Signed-off-by: Chris Rorvick ch...@rorvick.com
---
Documentation/git-cvsimport.txt | 13 ++---
git-cvsimport.perl |9 +
2 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-cvsimport.txt b/Documentation/git-cvsimport.txt
index 6695ab3..9059ad1 100644
--- a/Documentation/git-cvsimport.txt
+++ b/Documentation/git-cvsimport.txt
@@ -11,9 +11,9 @@ SYNOPSIS
[verse]
'git cvsimport' [-o branch-for-HEAD] [-h] [-v] [-d CVSROOT]
[-A author-conv-file] [-p options-for-cvsps] [-P file]
- [-C git_repository] [-z fuzz] [-i] [-k] [-u] [-s subst]
- [-a] [-m] [-M regex] [-S regex] [-L commitlimit]
- [-r remote] [-R] [CVS_module]
+ [-C git_repository] [-z fuzz] [-i] [-k] [-l] [-u]
+ [-s subst] [-a] [-m] [-M regex] [-S regex]
+ [-L commitlimit] [-r remote] [-R] [CVS_module]
DESCRIPTION
@@ -89,6 +89,13 @@ the old cvs2git tool.
to avoid noisy changesets. Highly recommended, but off by default
to preserve compatibility with early imported trees.
+-l::
+ Use the local timezone for computing the timezone offset of commit
+ timestamps instead of the default of + (UTC). The `TZ`
+ environment variable can be used to override the default local
+ timezone, possibly useful if you are importing from a non-local
+ repository.
+
-u::
Convert underscores in tag and branch names to dots.
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index 2f5da9e..927d75c 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -28,9 +28,8 @@ use POSIX qw(strftime dup2 ENOENT);
use IPC::Open2;
$SIG{'PIPE'}=IGNORE;
-$ENV{'TZ'}=UTC;
-our
($opt_h,$opt_o,$opt_v,$opt_k,$opt_u,$opt_d,$opt_p,$opt_C,$opt_z,$opt_i,$opt_P,
$opt_s,$opt_m,@opt_M,$opt_A,$opt_S,$opt_L, $opt_a, $opt_r, $opt_R);
+our
($opt_h,$opt_o,$opt_v,$opt_k,$opt_u,$opt_l,$opt_d,$opt_p,$opt_C,$opt_z,$opt_i,$opt_P,
$opt_s,$opt_m,@opt_M,$opt_A,$opt_S,$opt_L, $opt_a, $opt_r, $opt_R);
my (%conv_author_name, %conv_author_email);
sub usage(;$) {
@@ -40,7 +39,7 @@ sub usage(;$) {
Usage: git cvsimport # fetch/update GIT from CVS
[-o branch-for-HEAD] [-h] [-v] [-d CVSROOT] [-A author-conv-file]
[-p opts-for-cvsps] [-P file] [-C GIT_repository] [-z fuzz] [-i] [-k]
- [-u] [-s subst] [-a] [-m] [-M regex] [-S regex] [-L commitlimit]
+ [-l] [-u] [-s subst] [-a] [-m] [-M regex] [-S regex] [-L commitlimit]
[-r remote] [-R] [CVS_module]
END
exit(1);
@@ -128,7 +127,7 @@ sub read_repo_config {
}
}
-my $opts = haivmkuo:d:p:r:C:z:s:M:P:A:S:L:R;
+my $opts = haivmkulo:d:p:r:C:z:s:M:P:A:S:L:R;
read_repo_config($opts);
Getopt::Long::Configure( 'no_ignore_case', 'bundling' );
@@ -138,6 +137,8 @@ GetOptions( map { s/:/=s/; /M/ ? $_\@ : $_ } split(
/(?!:)/, $opts ) )
or usage();
usage if $opt_h;
+$ENV{'TZ'}=UTC unless $opt_l;
+
if (@ARGV == 0) {
chomp(my $module = `git
[PATCH 09/20] cvsserver: cvs add: do not expand directory arguments
Standard cvs add never does any recursion. With standard
cvs, cvs add dir will either add just the dir to
the repository, or error out. Prior to this change, git-cvsserver
would try to recurse (perhaps re-adding sandbox-removed files?) into
the existing directory instead.
Signed-off-by: Matthew Ogilvie mmogilvi_...@miniinfo.net
---
git-cvsserver.perl | 2 --
1 file changed, 2 deletions(-)
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index 8a7106d..4d514b4 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -543,8 +543,6 @@ sub req_add
my $updater = GITCVS::updater-new($state-{CVSROOT}, $state-{module},
$log);
$updater-update();
-argsfromdir($updater);
-
my $addcount = 0;
foreach my $filename ( @{$state-{args}} )
--
1.7.10.2.484.gcd07cc5
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 18/20] cvsserver: support -r and sticky tags for most operations
- Split off prepDirForOutput for update and commit.
Some low level protocol details were changed to more closely
resemble CVS even in non-tagged cases. Hopefully it still works
with finicky clients like Eclipse.
- Substantial changes to diff. The output is now closer to
standard CVS (including exit status), and can be used as
a patch, but there are still a number of differences compared
to CVS.
- Tweaks to add, remove, status, and commit.
- FUTURE: CVS revision numbers for branches simply encode git
commit IDs in a way that resembles CVS revision numbers,
dropping all normal CVS structural relations between different
revision numbers.
- FUTURE: log doesn't try to work properly at all with branches
and tags.
- FUTURE: annotate probably doesn't work with branches or
tags either (untested)?
Signed-off-by: Matthew Ogilvie mmogilvi_...@miniinfo.net
---
git-cvsserver.perl | 713 ++---
1 file changed, 510 insertions(+), 203 deletions(-)
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index 5e558d1..3679074 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -611,7 +611,10 @@ sub req_add
{
$filename = filecleanup($filename);
-my $meta = $updater-getmeta($filename);
+# no -r, -A, or -D with add
+my $stickyInfo = resolveStickyInfo($filename);
+
+my $meta = $updater-getmeta($filename,$stickyInfo);
my $wrev = revparse($filename);
if ($wrev $meta ($wrev=~/^-/))
@@ -634,8 +637,10 @@ sub req_add
# this is an entries line
my $kopts =
kopts_from_path($filename,sha1,$meta-{filehash});
-$log-debug(/$filepart/$meta-{revision}//$kopts/);
-print /$filepart/$meta-{revision}//$kopts/\n;
+my $entryLine = /$filepart/$meta-{revision}//$kopts/;
+$entryLine .= getStickyTagOrDate($stickyInfo);
+$log-debug($entryLine);
+print $entryLine\n;
# permissions
$log-debug(SEND :
u=$meta-{mode},g=$meta-{mode},o=$meta-{mode});
print u=$meta-{mode},g=$meta-{mode},o=$meta-{mode}\n;
@@ -666,7 +671,8 @@ sub req_add
print $filename\n;
my $kopts = kopts_from_path($filename,file,
$state-{entries}{$filename}{modified_filename});
-print /$filepart/0//$kopts/\n;
+print /$filepart/0//$kopts/ .
+ getStickyTagOrDate($stickyInfo) . \n;
my $requestedKopts = $state-{opt}{k};
if(defined($requestedKopts))
@@ -734,7 +740,10 @@ sub req_remove
next;
}
-my $meta = $updater-getmeta($filename);
+# only from entries
+my $stickyInfo = resolveStickyInfo($filename);
+
+my $meta = $updater-getmeta($filename,$stickyInfo);
my $wrev = revparse($filename);
unless ( defined ( $wrev ) )
@@ -764,7 +773,7 @@ sub req_remove
print Checked-in $dirpart\n;
print $filename\n;
my $kopts = kopts_from_path($filename,sha1,$meta-{filehash});
-print /$filepart/-$wrev//$kopts/\n;
+print /$filepart/-$wrev//$kopts/ . getStickyTagOrDate($stickyInfo) .
\n;
$rmcount++;
}
@@ -944,6 +953,9 @@ sub req_co
return 1;
}
+my $stickyInfo = { 'tag' = $state-{opt}{r},
+ 'date' = $state-{opt}{D} };
+
my $module = $state-{args}[0];
$state-{module} = $module;
my $checkout_path = $module;
@@ -961,64 +973,32 @@ sub req_co
my $updater = GITCVS::updater-new($state-{CVSROOT}, $module, $log);
$updater-update();
-$checkout_path =~ s|/$||; # get rid of trailing slashes
+my $headHash;
+if( defined($stickyInfo) defined($stickyInfo-{tag}) )
+{
+$headHash = $updater-lookupCommitRef($stickyInfo-{tag});
+if( !defined($headHash) )
+{
+print error 1 no such tag `$stickyInfo-{tag}'\n;
+cleanupWorkTree();
+exit;
+}
+}
-# Eclipse seems to need the Clear-sticky command
-# to prepare the 'Entries' file for the new directory.
-print Clear-sticky $checkout_path/\n;
-print $state-{CVSROOT} . /$module/\n;
-print Clear-static-directory $checkout_path/\n;
-print $state-{CVSROOT} . /$module/\n;
-print Clear-sticky $checkout_path/\n; # yes, twice
-print $state-{CVSROOT} . /$module/\n;
-print Template $checkout_path/\n;
-print $state-{CVSROOT} . /$module/\n;
-print 0\n;
-
-# instruct the client that we're checking out to $checkout_path
-print E cvs checkout: Updating $checkout_path\n;
+$checkout_path =~ s|/$||; # get rid of trailing slashes
my %seendirs = ();
my $lastdir ='';
-# recursive
-sub prepdir {
- my ($dir, $repodir, $remotedir, $seendirs) = @_;
- my $parent = dirname($dir);
- $dir =~
Re: [RFC/PATCH 0/2] Re: [PATCH] config: warn on inaccessible files
On Sat, Oct 13, 2012 at 05:02:10PM -0700, Jonathan Nieder wrote: Before reading a config file, we check !access(path, R_OK) to make sure that the file exists and is readable. If it's not, then we silently ignore it. git became noisy: $ git fetch --all warning: unable to access '/home/jrn/.config/git/config': Not a directory [...] I somehow thought that we had dealt with this ENOTDIR already, but I see that 8e950da only dealt with .gitattributes, which may look for arbitrary path names that are not reflected in the current working tree. We didn't ignore ENOTDIR for config files at the same time, because it is not obvious that such a bogus config path is not something the user would want to know about. On this machine, ~/.config/git has been a regular file for a while, with ~/.gitconfig a symlink to it. Probably ENOTDIR should be ignored just like ENOENT is. Except for the noise, the behavior is fine, but something still feels wrong. Hmm. Your use of ~/.config/git is interesting. Recent versions of git will look in ~/.config (or $XDG_CONFIG_HOME), but they want to find git/config there, and your single file is in conflict with that. So this has nothing to do with ~/.gitconfig, or the fact that it is symlinked. This is the XDG lookup code kicking in, because you happened to put your file in the same place, and then afterwards git learned to look there (albeit with a slightly different format). So on the one hand, this ENOTDIR is uninteresting, because it is not really about an error with the file we are trying to open at all, but simply another way of saying the file does not exist. And therefore it should be ignored. On the other hand, it is actually alerting you to an unusual situation that you might want to fix (you are putting stuff in the XDG config directory, but it is not in the format git wants). I don't have a strong preference about what should happen, but I would lean towards your first patch. ENOTDIR really is just another way of saying ENOENT (it just gives more information about the leading paths). It did find a configuration oddity you might want to fix, but that oddity was not actually hurting anything. When ~/.gitconfig is unreadable (EPERM), the messages are a symptom of an older issue: the config file is being ignored. Shouldn't git error out instead so the permissions can be fixed? E.g., if the sysadmin has set [branch] autoSetupRebase to true in /etc/gitconfig and I have set it to false in my own ~/.gitconfig, I'd rather see git error out because ~/.gitconfig has become unreadable in a chmod gone wrong than have a branch set up with the wrong settings and have to learn to fix it up myself. This is a separate issue from above. I tend to agree that dying would be better in most cases, because an operation may not do what you want if opening the config fails (for an even worse example, considering something like receive-pack trying to figure out if receive.denyDeletes is set). I considered doing this when I wrote the original patch, but was mainly worried about regressions in weird situations. The two I can think of are: 1. You are inspecting somebody else's repo, but you do not have access to their .git/config file. But then, I think that is probably a sane time to die anyway, since we cannot read core.repositoryFormatVersion. 2. You have used sudo or some other tool to switch uid, but your environment still points git at your original user's global config, which may not be readable. Those are unusual situations, though. It probably makes more sense for us to be conservative in the common case and die. Case 1 is pretty insane and should probably involve dying anyway. Case 2 people may be inconvenienced (they would rather see the harmless warning and continue the operation), but they can work around it by setting up their environment properly after switching uids. In other words, how about something like this? Jonathan Nieder (2): config, gitignore: failure to access with ENOTDIR is ok config: treat user and xdg config permission problems as errors Yeah, those look sane, modulo a question about the second one (I'll reply directly). -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] config: treat user and xdg config permission problems as errors
On Sat, Oct 13, 2012 at 05:04:02PM -0700, Jonathan Nieder wrote: Better to error out and ask the user to correct the problem. This only affects the user and xdg config files, since the user presumably has enough access to fix their permissions. If the system config file is unreadable, the best we can do is to warn about it so the user knows to notify someone and get on with work in the meantime. I'm on the fence about treating the systme config specially. On the one hand, I see the convenience if somebody has a bogus /etc/gitconfig and gets EPERM but can't fix it. On the other hand, if we get EIO, isn't that a good indication that we would want to die? For example, servers may depend on /etc/gitconfig to enforce security policy (e.g., setting transfer.fsckObjects or receive.deny*). Perhaps our default should be safe, and people can use GIT_CONFIG_NOSYSTEM to work around a broken machine. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 0/2] Re: [PATCH] config: warn on inaccessible files
On Sat, Oct 13, 2012 at 09:55:22PM -0700, Junio C Hamano wrote:
When ~/.gitconfig is unreadable (EPERM), the messages are a symptom of
an older issue: the config file is being ignored. Shouldn't git error
out instead so the permissions can be fixed? E.g., if the sysadmin
has set [branch] autoSetupRebase to true in /etc/gitconfig and I
have set it to false in my own ~/.gitconfig, I'd rather see git error
out because ~/.gitconfig has become unreadable in a chmod gone wrong
than have a branch set up with the wrong settings and have to learn to
fix it up myself.
In other words, how about something like this?
I think that is a reasonable issue to address, but I wonder if we
should be sharing more code between these. If the config side can
be switched to unconditionally attempt to fopen and then deal with
an error when it happens, we can get rid of access_or_{warn,die}
and replace them with fopen_or_{warn,die} and use them from the two
places (attr.c:read_attr_from_file() and the configuration stuff).
I haven't looked to see if that a too intrusive refactoring to be
worth it, though.
Handling the error at the fopen level would eliminate a minor race
condition (e.g., access() reports OK, then the file has its permissions
changed, then we fopen and get EPERM, but ignore it). So it would not
just be a refactoring, but would actually improve the code quality.
-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 04/12] wildmatch: remove unnecessary functions
On Sun, Oct 14, 2012 at 12:04 PM, Junio C Hamano gits...@pobox.com wrote: Nguyễn Thái Ngọc Duy pclo...@gmail.com writes: Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- The comment-fix seems to be new but otherwise this is unchanged, right? Right.-- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git smart-http do not authent to allow git ls-remote to be called anonymously
[re-adding git@vger; please keep discussion on-list] On Sun, Oct 14, 2012 at 01:29:13PM +0800, 乙酸鋰 wrote: Sorry, it does not serve the request. It returns http 401. But if I add the username and password as a part of the URL, it succeeds. In that case, then you probably need to upgrade your client version of git, as I mentioned here: Or is it that the server tells git that it needs authorization, but git does not prompt, and instead just fails with Authentication failed. In that case, the issue is that you need a newer git client. Traditionally the client expected to handle authentication during the initial info/refs request. I added support for handling authentication during later requests in commit b81401c, which is in git v1.7.11.7 and v1.7.12.1. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git reflog delete HEAD@{1} HEAD@{2} caught me by surprise...
I would actually call that behaviour a bug. Well, yes, that was my inclination, too. But writing documentation was easier than writing a code patch. :-) Even when it is fixed, a comment about when it was fixed and what the buggy version did should live in the BUGS section for a while, to warn people writing portable scripts. Perhaps it should grab all the command line arguments first, group them per the ref the reflog entries are based on, and expire _all_ reflog entries from the same reflog in one go? Two other options are to sort them in decreasing entry order (which you could do either per-reflog, or simply globally), or to remember previous deletions so you can adjust the numbers of later ones. One tricky point is whether it's possible for a reflog to have two names, via a symlink or something. That definitely complicates collision detection. Until that happens, it may make sense to error it out when more than one entries are given from the command line, at least for the same ref. Detecting this seems like half the implementation work of fixing it, so I'm not sure it's worth bothering. Looking at the code (builtin/reflog.c), I notice that expire_reflog() takes a lock on the ref, but the previous count_reflog_ent code doesn't, so things aren't necessarily race-proof. I haven't figured out if the race is a problem (i.e. does expire_reflog do something nasty if the struct cmd_reflog_expire_cb holds stale data?), but I noticed... -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] config: treat user and xdg config permission problems as errors
Jeff King wrote: For example, servers may depend on /etc/gitconfig to enforce security policy (e.g., setting transfer.fsckObjects or receive.deny*). Perhaps our default should be safe, and people can use GIT_CONFIG_NOSYSTEM to work around a broken machine. Very good point. How about these patches on top? Jonathan Nieder (2): config doc: advertise GIT_CONFIG_NOSYSTEM config: exit on error accessing any config file Documentation/git-config.txt | 8 config.c | 6 +++--- 2 files changed, 11 insertions(+), 3 deletions(-) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/2] config doc: advertise GIT_CONFIG_NOSYSTEM
When a syntax error or other problem renders /etc/gitconfig buggy on a multiuser system where mortals do not have write access to /etc, the GIT_CONFIG_NOSYSTEM variable is the best tool we have to keep getting work done until the sysadmin sorts the problem out. Noticed while experimenting with teaching git to error out when /etc/gitconfig is unreadable. Signed-off-by: Jonathan Nieder jrnie...@gmail.com --- Documentation/git-config.txt | 8 1 file changed, 8 insertions(+) diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt index eaea0791..907a1fd5 100644 --- a/Documentation/git-config.txt +++ b/Documentation/git-config.txt @@ -240,6 +240,14 @@ GIT_CONFIG:: Using the --global option forces this to ~/.gitconfig. Using the --system option forces this to $(prefix)/etc/gitconfig. +GIT_CONFIG_NOSYSTEM:: + Whether to skip reading settings from the system-wide + $(prefix)/etc/gitconfig file. This environment variable can + be used along with HOME and XDG_CONFIG_HOME to create a + predictable environment for a picky script, or you can set it + temporarily to avoid using a buggy /etc/gitconfig file while + waiting for someone with sufficient permissions to fix it. + See also FILES. -- 1.8.0.rc2 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/2] config: exit on error accessing any config file
There is convenience in warning and moving on when somebody has a
bogus permissions on /etc/gitconfig and cannot do anything about it.
But the cost in predictability and security is too high --- when
unreadable config files are skipped, it means an I/O error or
permissions problem causes important configuration to be bypassed.
For example, servers may depend on /etc/gitconfig to enforce security
policy (setting transfer.fsckObjects or receive.deny*). Best to
always error out when encountering trouble accessing a config file.
This may add inconvenience in some cases:
1. You are inspecting somebody else's repo, and you do not have
access to their .git/config file. Git typically dies in this
case already since we cannot read core.repositoryFormatVersion,
so the change should not be too noticeable.
2. You have used sudo -u or a similar tool to switch uid, and your
environment still points Git at your original user's global
config, which is not readable. In this case people really would
be inconvenienced (they would rather see the harmless warning and
continue the operation) but they can work around it by setting
HOME appropriately after switching uids.
3. You do not have access to /etc/gitconfig due to a broken setup.
In this case, erroring out is a good way to put pressure on the
sysadmin to fix the setup. While they wait for a reply, users
can set GIT_CONFIG_NOSYSTEM to true to keep Git working without
complaint.
After this patch, errors accessing the repository-local and systemwide
config files and files requested in include directives cause Git to
exit, just like errors accessing ~/.gitconfig.
Explained-by: Jeff King p...@peff.net
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
config.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/config.c b/config.c
index e8875b8a..a4d153f6 100644
--- a/config.c
+++ b/config.c
@@ -60,7 +60,7 @@ static int handle_path_include(const char *path, struct
config_include_data *inc
path = buf.buf;
}
- if (!access_or_warn(path, R_OK)) {
+ if (!access_or_die(path, R_OK)) {
if (++inc-depth MAX_INCLUDE_DEPTH)
die(include_depth_advice, MAX_INCLUDE_DEPTH, path,
cf cf-name ? cf-name : the command line);
@@ -939,7 +939,7 @@ int git_config_early(config_fn_t fn, void *data, const char
*repo_config)
home_config_paths(user_config, xdg_config, config);
- if (git_config_system() !access_or_warn(git_etc_gitconfig(), R_OK)) {
+ if (git_config_system() !access_or_die(git_etc_gitconfig(), R_OK)) {
ret += git_config_from_file(fn, git_etc_gitconfig(),
data);
found += 1;
@@ -955,7 +955,7 @@ int git_config_early(config_fn_t fn, void *data, const char
*repo_config)
found += 1;
}
- if (repo_config !access_or_warn(repo_config, R_OK)) {
+ if (repo_config !access_or_die(repo_config, R_OK)) {
ret += git_config_from_file(fn, repo_config, data);
found += 1;
}
--
1.8.0.rc2
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/2] doc: advertise GIT_CONFIG_NOSYSTEM
On a multiuser system where mortals do not have write access to /etc, the GIT_CONFIG_NOSYSTEM variable is the best tool we have to keep getting work done when a syntax error or other problem renders /etc/gitconfig buggy, until the sysadmin sorts the problem out. Noticed while experimenting with teaching git to error out when /etc/gitconfig is unreadable. Signed-off-by: Jonathan Nieder jrnie...@gmail.com --- Jonathan Nieder wrote: --- a/Documentation/git-config.txt +++ b/Documentation/git-config.txt @@ -240,6 +240,14 @@ GIT_CONFIG:: Using the --global option forces this to ~/.gitconfig. Using the --system option forces this to $(prefix)/etc/gitconfig. +GIT_CONFIG_NOSYSTEM:: Hm, unlike GIT_CONFIG this applies to all git commands (not just git config), so it is misleading to document them in the same place. Here's a better patch. Documentation/git-config.txt | 4 Documentation/git.txt| 8 2 files changed, 12 insertions(+) diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt index eaea0791..9ae2508f 100644 --- a/Documentation/git-config.txt +++ b/Documentation/git-config.txt @@ -240,6 +240,10 @@ GIT_CONFIG:: Using the --global option forces this to ~/.gitconfig. Using the --system option forces this to $(prefix)/etc/gitconfig. +GIT_CONFIG_NOSYSTEM:: + Whether to skip reading settings from the system-wide + $(prefix)/etc/gitconfig file. See linkgit:git[1] for details. + See also FILES. diff --git a/Documentation/git.txt b/Documentation/git.txt index d1d227a3..ae1f833a 100644 --- a/Documentation/git.txt +++ b/Documentation/git.txt @@ -757,6 +757,14 @@ for further details. and read the password from its STDOUT. See also the 'core.askpass' option in linkgit:git-config[1]. +'GIT_CONFIG_NOSYSTEM':: + Whether to skip reading settings from the system-wide + `$(prefix)/etc/gitconfig` file. This environment variable can + be used along with `$HOME` and `$XDG_CONFIG_HOME` to create a + predictable environment for a picky script, or you can set it + temporarily to avoid using a buggy `/etc/gitconfig` file while + waiting for someone with sufficient permissions to fix it. + 'GIT_FLUSH':: If this environment variable is set to 1, then commands such as 'git blame' (in incremental mode), 'git rev-list', 'git log', -- 1.8.0.rc2 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 0/2] Re: [PATCH] config: warn on inaccessible files
Junio C Hamano wrote:
If the config side can
be switched to unconditionally attempt to fopen and then deal with
an error when it happens, we can get rid of access_or_{warn,die}
and replace them with fopen_or_{warn,die} and use them from the two
places (attr.c:read_attr_from_file() and the configuration stuff).
I haven't looked to see if that a too intrusive refactoring to be
worth it, though.
That sounds reasonable, but I'm punting on it. The first step would
be tweaking the git_config_from_file() calling convention to convey
missing file errors specially, perhaps by making sure errno is
meaningful when the return value is -1, and that already sounds like
work. ;-)
Thanks,
Jonathan
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: A design for subrepositories
Quoting Junio C Hamano gits...@pobox.com: If the submodules ever get reorganized and foo is moved to ./bar, then it is impossible to check out older versions or alternate branches, since the submodule is no longer where it is expected to be at the origin. Isn't that exactly what the module name vs module path mapping in .gitmodules file is meant to address? Yes, and as I showed after the part you quoted, it is possible to refer to a module by name, although it looks like such a hack that I can't imagine it's currently something that git-submodule is intended to support. But still, git submodule update only looks at the modules in the currently checked-out tree. If we have other branches or old tags that refer to other submodules, there's no simple way to fetch those, too. Didn't I already suggest you to think about how you can improve existing git submodule to suit your use case better? Yes, and I listed three possible ways. Two of them seem technically unattractive, whereas one of them (submodules as ref directories) seems like a huge change that could introduce incompatibilities. That is why a separate tool seems like a cleaner choice. If you want enhancements to git-submodule, at least deign to comment on the issues above. There is actually a fourth alternative: extend the git protocol so that a remote repository could be queried for its list of submodules. But this seems particularly icky: git is at its core such a low-level framework. Nested repositories are such a high-level concept that something is wrong if the core needs specialized support for it. The ref directories approach, on the other hand, is completely transparent to standard tools. Lauri -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 05/12] Integrate wildmatch to git
diff --git a/t/t3070-wildmatch.sh b/t/t3070-wildmatch.sh new file mode 100755 index 000..dbd3c8b --- /dev/null +++ b/t/t3070-wildmatch.sh @@ -0,0 +1,188 @@ +#!/bin/sh +#else +#test_expect_success BROKEN_FNMATCH fnmatch: '$3' '$4' +#! test-wildmatch fnmatch '$3' '$4' +# +fi +} + Thanks: On my Mac OS X box: # passed all 259 test(s) And a quick test on cygwin: $ ./t3070-wildmatch.sh 21 | grep not ok not ok - 148 fnmatch: match '5' '[[:xdigit:]]' not ok - 150 fnmatch: match 'f' '[[:xdigit:]]' not ok - 152 fnmatch: match 'D' '[[:xdigit:]]' And 2 micronits: a) Commented out code b) Whithespace damage ( 4 spaces used for an indent of 1, TAB for indent of 2) /Torsten -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] exclude: fix a bug in prefix comparison optimization
When namelen becomes zero at this stage, we have matched the fixed part, but whether it actually matches the pattern still depends on the pattern in exclude. As demonstrated in t3001, path three/a.3 exists and it matches the three/a.3 part in pattern three/a.3[abc], but that does not mean a true match. Don't be too optimistic and let fnmatch() do the job. Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- dir.c | 2 +- t/t3001-ls-files-others-exclude.sh | 6 ++ 2 files changed, 7 insertions(+), 1 deletion(-) diff --git a/dir.c b/dir.c index 4868339..90bf3a4 100644 --- a/dir.c +++ b/dir.c @@ -575,7 +575,7 @@ int excluded_from_list(const char *pathname, namelen -= prefix; } - if (!namelen || !fnmatch_icase(exclude, name, FNM_PATHNAME)) + if (!fnmatch_icase(exclude, name, FNM_PATHNAME)) return to_exclude; } return -1; /* undecided */ diff --git a/t/t3001-ls-files-others-exclude.sh b/t/t3001-ls-files-others-exclude.sh index c8fe978..dc2f045 100755 --- a/t/t3001-ls-files-others-exclude.sh +++ b/t/t3001-ls-files-others-exclude.sh @@ -214,4 +214,10 @@ test_expect_success 'subdirectory ignore (l1)' ' test_cmp expect actual ' +test_expect_success 'pattern matches prefix completely' ' + : expect + git ls-files -i -o --exclude /three/a.3[abc] actual + test_cmp expect actual +' + test_done -- 1.8.0.rc2.11.g2b79d01 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC 0/2] Re: [PATCH 2/7] Change canonicalize_url() to use the SVN 1.7 API when available.
Hi Eric,
Michael G Schwern wrote:
On 2012.7.28 6:50 AM, Jonathan Nieder wrote:
Michael G Schwern wrote:
--- a/perl/Git/SVN/Utils.pm
+++ b/perl/Git/SVN/Utils.pm
[...]
@@ -100,6 +102,20 @@ API as a URL.
=cut
sub canonicalize_url {
+ my $url = shift;
+
+ # The 1.7 way to do it
+ if ( defined SVN::_Core::svn_uri_canonicalize ) {
+ return SVN::_Core::svn_uri_canonicalize($url);
+ }
+ # There wasn't a 1.6 way to do it, so we do it ourself.
+ else {
+ return _canonicalize_url_ourselves($url);
[...]
Leaves me a bit nervous.
As it should, SVN dumped a mess on us.
Here's a pair of patches that address some of the bugs I was alluding
to. Patch 1 makes _canonicalize_url_ourselves() match Subversion's
own canonicalization behavior more closely, though even with that
patch it still does not meet Subversion's requirements perfectly
(e.g., %ab is not canonicalized to %AB). Patch 2 makes that not
matter by using svn_path_canonicalize() when possible, which is the
standard way to do this kind of thing.
Sorry for the lack of clarity before.
Jonathan Nieder (2):
git svn: do not overescape URLs (fallback case)
Git::SVN::Utils::canonicalize_url: use svn_path_canonicalize when
available
perl/Git/SVN/Utils.pm | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] git svn: do not overescape URLs (fallback case)
Subversion's canonical URLs are intended to make URL comparison easy
and therefore have strict rules about what characters are special
enough to urlencode and what characters should be left alone.
When in the fallback codepath because unable to use libsvn's own
canonicalization function for some reason, escape special characters
in URIs according to the svn_uri__char_validity[] table in
subversion/libsvn_subr/path.c (r935829). The libsvn versions that
trigger this code path are not likely to be strict enough to care, but
it's nicer to be consistent.
Noticed by using SVN 1.6.17 perl bindings, which do not provide
SVN::_Core::svn_uri_canonicalize (triggering the fallback code),
with libsvn 1.7.5, whose do_switch is fussy enough to care:
Committing to file:///home/jrn/src/git/t/trash%20directory.\
t9118-git-svn-funky-branch-names/svnrepo/pr%20ject/branches\
/more%20fun%20plugin%21 ...
svn: E235000: In file '[...]/subversion/libsvn_subr/dirent_uri.c' \
line 2291: assertion failed (svn_uri_is_canonical(url, pool))
error: git-svn died of signal 6
not ok - 3 test dcommit to funky branch
After this change, the '!' in 'more%20fun%20plugin!' is not urlencoded
and t9118 passes again.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
perl/Git/SVN/Utils.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/perl/Git/SVN/Utils.pm b/perl/Git/SVN/Utils.pm
index 8b8cf375..3d1a0933 100644
--- a/perl/Git/SVN/Utils.pm
+++ b/perl/Git/SVN/Utils.pm
@@ -155,7 +155,7 @@ sub _canonicalize_url_path {
my @parts;
foreach my $part (split m{/+}, $uri_path) {
- $part =~
s/([^~\w.%+-]|%(?![a-fA-F0-9]{2}))/sprintf(%%%02X,ord($1))/eg;
+ $part =~
s/([^!\$%'()*+,.\/\w:=\@_`~-]|%(?![a-fA-F0-9]{2}))/sprintf(%%%02X,ord($1))/eg;
push @parts, $part;
}
--
1.8.0.rc2
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] git svn: canonicalize_url(): use svn_path_canonicalize when available
Until Subversion 1.7 (more precisely r873487), the standard way to
canonicalize a URI was to call svn_path_canonicalize(). Use it.
This saves git svn from having to rely on our imperfect
reimplementation of the same. If the function doesn't exist or
returns undef, though, it can use the fallback code, which we keep to
be conservative. Since svn_path_canonicalize() was added before
Subversion 1.1, hopefully that doesn't happen often.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
perl/Git/SVN/Utils.pm | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/perl/Git/SVN/Utils.pm b/perl/Git/SVN/Utils.pm
index 3d1a0933..40f7c799 100644
--- a/perl/Git/SVN/Utils.pm
+++ b/perl/Git/SVN/Utils.pm
@@ -138,15 +138,19 @@ API as a URL.
sub canonicalize_url {
my $url = shift;
+ my $rv;
# The 1.7 way to do it
if ( defined SVN::_Core::svn_uri_canonicalize ) {
- return SVN::_Core::svn_uri_canonicalize($url);
+ $rv = SVN::_Core::svn_uri_canonicalize($url);
}
- # There wasn't a 1.6 way to do it, so we do it ourself.
- else {
- return _canonicalize_url_ourselves($url);
+ # The 1.6 way to do it
+ elsif ( defined SVN::_Core::svn_path_canonicalize ) {
+ $rv = SVN::_Core::svn_path_canonicalize($url);
}
+ return $rv if defined $rv;
+
+ return _canonicalize_url_ourselves($url);
}
--
1.8.0.rc2
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] nd/attr-match-optim-more updates
This is on top of nd/attr-match-optim-more to fix the bug I sent recently [1] sharing the code, thus sharing any fixes. [1] http://thread.gmane.org/gmane.comp.version-control.git/207652 Nguyễn Thái Ngọc Duy (4): exclude: stricten a length check in EXC_FLAG_ENDSWITH case exclude: fix a bug in prefix compare optimization exclude/attr: share basename matching code exclude/attr: share full pathname matching code attr.c | 50 +++ dir.c | 121 +++-- dir.h | 5 ++ t/t3001-ls-files-others-exclude.sh | 6 ++ 4 files changed, 95 insertions(+), 87 deletions(-) -- 1.8.0.rc2.11.g2b79d01 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] exclude: stricten a length check in EXC_FLAG_ENDSWITH case
This block of code deals with the basename part only, which has the
length of pathlen - (basename - pathname). Stricten the length check
and remove pathname from the main expression to avoid confusion.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
dir.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/dir.c b/dir.c
index cddf043..d81498e 100644
--- a/dir.c
+++ b/dir.c
@@ -561,8 +561,9 @@ int excluded_from_list(const char *pathname,
if (!strcmp_icase(exclude, basename))
return to_exclude;
} else if (x-flags EXC_FLAG_ENDSWITH) {
- if (x-patternlen - 1 = pathlen
- !strcmp_icase(exclude + 1, pathname +
pathlen - x-patternlen + 1))
+ int len = pathlen - (basename - pathname);
+ if (x-patternlen - 1 = len
+ !strcmp_icase(exclude + 1, basename + len -
x-patternlen + 1))
return to_exclude;
} else {
if (fnmatch_icase(exclude, basename, 0) == 0)
--
1.8.0.rc2.11.g2b79d01
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] exclude: fix a bug in prefix compare optimization
When namelen becomes zero at this stage, we have matched the fixed part, but whether it actually matches the pattern still depends on the pattern in exclude. As demonstrated in t3001, path three/a.3 exists and it matches the three/a.3 part in pattern three/a.3[abc], but that does not mean a true match. Don't be too optimistic and let fnmatch() do the job. Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- dir.c | 2 +- t/t3001-ls-files-others-exclude.sh | 6 ++ 2 files changed, 7 insertions(+), 1 deletion(-) diff --git a/dir.c b/dir.c index d81498e..0f4aea6 100644 --- a/dir.c +++ b/dir.c @@ -601,7 +601,7 @@ int excluded_from_list(const char *pathname, namelen -= prefix; } - if (!namelen || !fnmatch_icase(exclude, name, FNM_PATHNAME)) + if (!fnmatch_icase(exclude, name, FNM_PATHNAME)) return to_exclude; } return -1; /* undecided */ diff --git a/t/t3001-ls-files-others-exclude.sh b/t/t3001-ls-files-others-exclude.sh index c8fe978..dc2f045 100755 --- a/t/t3001-ls-files-others-exclude.sh +++ b/t/t3001-ls-files-others-exclude.sh @@ -214,4 +214,10 @@ test_expect_success 'subdirectory ignore (l1)' ' test_cmp expect actual ' +test_expect_success 'pattern matches prefix completely' ' + : expect + git ls-files -i -o --exclude /three/a.3[abc] actual + test_cmp expect actual +' + test_done -- 1.8.0.rc2.11.g2b79d01 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] exclude/attr: share basename matching code
match_basename's declaration in dir.h does not have any description to
discourage the use of this function elsewhere as this function is
highly tied to how excluded_from_list and path_matches work.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
attr.c | 15 ---
dir.c | 37 -
dir.h | 2 ++
3 files changed, 30 insertions(+), 24 deletions(-)
diff --git a/attr.c b/attr.c
index 0964033..a28ce0d 100644
--- a/attr.c
+++ b/attr.c
@@ -663,17 +663,10 @@ static int path_matches(const char *pathname, int pathlen,
int namelen;
if (pat-flags EXC_FLAG_NODIR) {
- if (prefix == pat-patternlen
- !strcmp_icase(pattern, basename))
- return 1;
-
- if (pat-flags EXC_FLAG_ENDSWITH
- pat-patternlen - 1 = pathlen
- !strcmp_icase(pattern + 1, pathname +
- pathlen - pat-patternlen + 1))
- return 1;
-
- return (fnmatch_icase(pattern, basename, 0) == 0);
+ return match_basename(basename,
+ pathlen - (basename - pathname),
+ pattern, prefix,
+ pat-patternlen, pat-flags);
}
/*
* match with FNM_PATHNAME; the pattern has base implicitly
diff --git a/dir.c b/dir.c
index 0f4aea6..42c42cd 100644
--- a/dir.c
+++ b/dir.c
@@ -530,6 +530,25 @@ static void prep_exclude(struct dir_struct *dir, const
char *base, int baselen)
dir-basebuf[baselen] = '\0';
}
+int match_basename(const char *basename, int basenamelen,
+ const char *pattern, int prefix, int patternlen,
+ int flags)
+{
+ if (prefix == patternlen) {
+ if (!strcmp_icase(pattern, basename))
+ return 1;
+ } else if (flags EXC_FLAG_ENDSWITH) {
+ if (patternlen - 1 = basenamelen
+ !strcmp_icase(pattern + 1,
+ basename + basenamelen - patternlen + 1))
+ return 1;
+ } else {
+ if (fnmatch_icase(pattern, basename, 0) == 0)
+ return 1;
+ }
+ return 0;
+}
+
/* Scan the list and let the last match determine the fate.
* Return 1 for exclude, 0 for include and -1 for undecided.
*/
@@ -556,19 +575,11 @@ int excluded_from_list(const char *pathname,
}
if (x-flags EXC_FLAG_NODIR) {
- /* match basename */
- if (prefix == x-patternlen) {
- if (!strcmp_icase(exclude, basename))
- return to_exclude;
- } else if (x-flags EXC_FLAG_ENDSWITH) {
- int len = pathlen - (basename - pathname);
- if (x-patternlen - 1 = len
- !strcmp_icase(exclude + 1, basename + len -
x-patternlen + 1))
- return to_exclude;
- } else {
- if (fnmatch_icase(exclude, basename, 0) == 0)
- return to_exclude;
- }
+ if (match_basename(basename,
+ pathlen - (basename - pathname),
+ exclude, prefix, x-patternlen,
+ x-flags))
+ return to_exclude;
continue;
}
diff --git a/dir.h b/dir.h
index fd5c2aa..d416c5a 100644
--- a/dir.h
+++ b/dir.h
@@ -78,6 +78,8 @@ extern int read_directory(struct dir_struct *, const char
*path, int len, const
extern int excluded_from_list(const char *pathname, int pathlen, const char
*basename,
int *dtype, struct exclude_list *el);
+extern int match_basename(const char *, int,
+ const char *, int, int, int);
struct dir_entry *dir_add_ignored(struct dir_struct *dir, const char
*pathname, int len);
/*
--
1.8.0.rc2.11.g2b79d01
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] exclude/attr: share full pathname matching code
match_pathname's declaration in dir.h does not have any description to
discourage the use of this function elsewhere as this function is
highly tied to how excluded_from_list and path_matches work.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
attr.c | 35 +++
dir.c | 85 +-
dir.h | 3 +++
3 files changed, 59 insertions(+), 64 deletions(-)
diff --git a/attr.c b/attr.c
index a28ce0d..2fc6353 100644
--- a/attr.c
+++ b/attr.c
@@ -659,8 +659,6 @@ static int path_matches(const char *pathname, int pathlen,
{
const char *pattern = pat-pattern;
int prefix = pat-nowildcardlen;
- const char *name;
- int namelen;
if (pat-flags EXC_FLAG_NODIR) {
return match_basename(basename,
@@ -668,36 +666,9 @@ static int path_matches(const char *pathname, int pathlen,
pattern, prefix,
pat-patternlen, pat-flags);
}
- /*
-* match with FNM_PATHNAME; the pattern has base implicitly
-* in front of it.
-*/
- if (*pattern == '/') {
- pattern++;
- prefix--;
- }
-
- /*
-* note: unlike excluded_from_list, baselen here does not
-* count the trailing slash, and base[] does not end with
-* a trailing slash, either.
-*/
- if (pathlen baselen + 1 ||
- (baselen pathname[baselen] != '/') ||
- strncmp_icase(pathname, base, baselen))
- return 0;
-
- namelen = baselen ? pathlen - baselen - 1 : pathlen;
- name = pathname + pathlen - namelen;
-
- /*
-* if the non-wildcard part is longer than the remaining
-* pathname, surely it cannot match.
-*/
- if (!namelen || prefix namelen)
- return 0;
-
- return fnmatch_icase(pattern, name, FNM_PATHNAME) == 0;
+ return match_pathname(pathname, pathlen,
+ base, baselen,
+ pattern, prefix, pat-patternlen, pat-flags);
}
static int macroexpand_one(int attr_nr, int rem);
diff --git a/dir.c b/dir.c
index 42c42cd..ee8e711 100644
--- a/dir.c
+++ b/dir.c
@@ -549,6 +549,53 @@ int match_basename(const char *basename, int basenamelen,
return 0;
}
+int match_pathname(const char *pathname, int pathlen,
+ const char *base, int baselen,
+ const char *pattern, int prefix, int patternlen,
+ int flags)
+{
+ const char *name;
+ int namelen;
+
+ /*
+* match with FNM_PATHNAME; the pattern has base implicitly
+* in front of it.
+*/
+ if (*pattern == '/') {
+ pattern++;
+ prefix--;
+ }
+
+ /*
+* baselen does not count the trailing slash. base[] may or
+* may not end with a trailing slash though.
+*/
+ if (pathlen baselen + 1 ||
+ (baselen pathname[baselen] != '/') ||
+ strncmp_icase(pathname, base, baselen))
+ return 0;
+
+ namelen = baselen ? pathlen - baselen - 1 : pathlen;
+ name = pathname + pathlen - namelen;
+
+ if (prefix) {
+ /*
+* if the non-wildcard part is longer than the
+* remaining pathname, surely it cannot match.
+*/
+ if (prefix namelen)
+ return 0;
+
+ if (strncmp_icase(pattern, name, prefix))
+ return 0;
+ pattern += prefix;
+ name+= prefix;
+ namelen -= prefix;
+ }
+
+ return fnmatch_icase(pattern, name, FNM_PATHNAME) == 0;
+}
+
/* Scan the list and let the last match determine the fate.
* Return 1 for exclude, 0 for include and -1 for undecided.
*/
@@ -563,9 +610,9 @@ int excluded_from_list(const char *pathname,
for (i = el-nr - 1; 0 = i; i--) {
struct exclude *x = el-excludes[i];
- const char *name, *exclude = x-pattern;
+ const char *exclude = x-pattern;
int to_exclude = x-flags EXC_FLAG_NEGATIVE ? 0 : 1;
- int namelen, prefix = x-nowildcardlen;
+ int prefix = x-nowildcardlen;
if (x-flags EXC_FLAG_MUSTBEDIR) {
if (*dtype == DT_UNKNOWN)
@@ -583,36 +630,10 @@ int excluded_from_list(const char *pathname,
continue;
}
- /* match with FNM_PATHNAME:
-* exclude has base (baselen long) implicitly in front of it.
-*/
- if (*exclude == '/') {
- exclude++;
- prefix--;
- }
-
- if (pathlen x-baselen ||
- (x-baselen pathname[x-baselen-1] != '/') ||
-
Re: [PATCH v5 02/12] ctype: support iscntrl, ispunct, isxdigit and isprint
Am 14.10.2012 04:35, schrieb Nguyễn Thái Ngọc Duy:
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
ctype.c | 18 ++
git-compat-util.h | 13 +
2 files changed, 31 insertions(+)
diff --git a/ctype.c b/ctype.c
index faeaf34..b4bf48a 100644
--- a/ctype.c
+++ b/ctype.c
@@ -26,6 +26,24 @@ const unsigned char sane_ctype[256] = {
/* Nothing in the 128.. range */
};
+enum {
+ CN = GIT_CNTRL,
+ PU = GIT_PUNCT,
+ XD = GIT_XDIGIT,
+};
+
+const unsigned char sane_ctype2[256] = {
+ CN, CN, CN, CN, CN, CN, CN, CN, CN, CN, CN, CN, CN, CN, CN, CN, /*
0..15 */
+ CN, CN, CN, CN, CN, CN, CN, CN, CN, CN, CN, CN, CN, CN, CN, CN, /*
16..31 */
+ 0, PU, PU, PU, PU, PU, PU, PU, PU, PU, PU, PU, PU, PU, PU, PU, /*
32..47 */
+ XD, XD, XD, XD, XD, XD, XD, XD, XD, XD, PU, PU, PU, PU, PU, PU, /*
48..63 */
+ PU, 0, XD, 0, XD, 0, XD, 0, 0, 0, 0, 0, 0, 0, 0, 0, /*
64..79 */
+ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, PU, PU, PU, PU, PU, /*
80..95 */
+ PU, 0, XD, 0, XD, 0, XD, 0, 0, 0, 0, 0, 0, 0, 0, 0, /*
96..111 */
+ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, PU, PU, PU, PU, CN, /*
112..127 */
Shouldn't [ace] (65, 67, 69) and [ACE] (97, 99, 101) be xdigits as well?
But how about using the existing hexval_table instead, like this:
#define isxdigit(x) (hexval_table[(x)] != -1)
With that, couldn't you squeeze the other two classes into the existing
sane_type?
By the way, I'm working on a patch series for implementing a lot more
character classes with table lookups. It grew out of a desire to make
bad_ref_char() faster but perhaps got a bit out of hand by now; it's at
24 patches and still not finished. I'm curious how long we have until
it escapes. ;-)
#define is_regex_special(x) sane_istest(x,GIT_GLOB_SPECIAL | GIT_REGEX_SPECIAL)
+#define iscntrl(x) sane_istest2(x, GIT_CNTRL)
+#define ispunct(x) sane_istest2(x, GIT_PUNCT)
+#define isxdigit(x) sane_istest2(x, GIT_XDIGIT)
+#define isprint(x) (isalnum(x) || isspace(x) || ispunct(x))
If a single table is used, you can do with a single table lookup by
adding the bits for the component classes, like isalnum and
is_regex_special do.
René
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 02/12] ctype: support iscntrl, ispunct, isxdigit and isprint
On Sun, Oct 14, 2012 at 7:59 PM, René Scharfe
rene.scha...@lsrfire.ath.cx wrote:
+const unsigned char sane_ctype2[256] = {
+ CN, CN, CN, CN, CN, CN, CN, CN, CN, CN, CN, CN, CN, CN, CN, CN, /*
0..15 */
+ CN, CN, CN, CN, CN, CN, CN, CN, CN, CN, CN, CN, CN, CN, CN, CN, /*
16..31 */
+ 0, PU, PU, PU, PU, PU, PU, PU, PU, PU, PU, PU, PU, PU, PU, PU, /*
32..47 */
+ XD, XD, XD, XD, XD, XD, XD, XD, XD, XD, PU, PU, PU, PU, PU, PU, /*
48..63 */
+ PU, 0, XD, 0, XD, 0, XD, 0, 0, 0, 0, 0, 0, 0, 0, 0, /*
64..79 */
+ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, PU, PU, PU, PU, PU, /*
80..95 */
+ PU, 0, XD, 0, XD, 0, XD, 0, 0, 0, 0, 0, 0, 0, 0, 0, /*
96..111 */
+ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, PU, PU, PU, PU, CN, /*
112..127 */
Shouldn't [ace] (65, 67, 69) and [ACE] (97, 99, 101) be xdigits as well?
Hmm.. I generated it from LANG=C. I wonder where I got it wrong..
But how about using the existing hexval_table instead, like this:
#define isxdigit(x) (hexval_table[(x)] != -1)
With that, couldn't you squeeze the other two classes into the existing
sane_type?
No there are still conflicts: 9, 10 and 13 as spaces (vs controls) and
123, 124 and 126 as regex/pathspec special (vs punctuation).
By the way, I'm working on a patch series for implementing a lot more
character classes with table lookups. It grew out of a desire to make
bad_ref_char() faster but perhaps got a bit out of hand by now; it's at 24
patches and still not finished. I'm curious how long we have until it
escapes. ;-)
I don't think the series is going to graduate any time soon :)
--
Duy
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: A design for subrepositories
Am 14.10.2012 12:19, schrieb Lauri Alanko: Quoting Junio C Hamano gits...@pobox.com: If the submodules ever get reorganized and foo is moved to ./bar, then it is impossible to check out older versions or alternate branches, since the submodule is no longer where it is expected to be at the origin. Isn't that exactly what the module name vs module path mapping in .gitmodules file is meant to address? Yes, and as I showed after the part you quoted, it is possible to refer to a module by name, although it looks like such a hack that I can't imagine it's currently something that git-submodule is intended to support. Your initial statement is not correct. It is possible to check out older versions or alternate branches (at least since we moved the .git directory into the .git directory of the superproject). So no improvement gained here by your proposal (although I concede that the current user experience is suboptimal until my recursive submodule update work hits mainline). But still, git submodule update only looks at the modules in the currently checked-out tree. If we have other branches or old tags that refer to other submodules, there's no simple way to fetch those, too. Did you notice that git fetch fetches all those submodules too which have been updated in the commits fetched for the superproject, no matter on what branch they are on? Didn't I already suggest you to think about how you can improve existing git submodule to suit your use case better? Yes, and I listed three possible ways. Two of them seem technically unattractive, whereas one of them (submodules as ref directories) seems like a huge change that could introduce incompatibilities. That is why a separate tool seems like a cleaner choice. What's wrong with making git clone all submodules together with the superproject (when the user said he wants to update all submodules on clone too by setting a - still to be added - config option)? That's my plan to make automagic recursive submodule cloning work and it would clone all submodules seen in the history of the superproject to .git/modules so they could easily be checked out later (and those present in the HEAD of the superproject will be checked out immediately like git clone --recurse-submodules does right now). Were not there yet, but that's how I believe that should work. There is actually a fourth alternative: extend the git protocol so that a remote repository could be queried for its list of submodules. That information is contained in the different versions of the .gitmodules file, so no need to extend anything here. I saw nothing in your proposal which couldn't been handled by submodules, and for every issue there already have been proposals on how to do that. So adding another tool doesn't make any sense here. But you are welcome helping us to improve the submodule script (and some core commands too) to make submodules cover your use case too. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
fixes of previous commit
--- Hi Ralf Hi Thomas, thanks for your work! All your suggestions are very good. I just realized that, unfortunately, your original message is far beyond the message size limit on vger (10 bytes according to [1]). So nobody outside of the Cc list has seen it... Oops, I didn't notice that and can't remember of a hint from vger. Next time I'll check the mailing list whether the mail is there. +msgstr kopiert Dateien von einer benannten Bereitstellung Stage in this context means the 0/1/2/3 thing where unmerged entries differ from normal entries. Thank the Git gods for overloading yet another term heavily. We don't have a translation for stage in the glossary. The best I can come up with is Stufe, but if you can find something that evokes the mental image of the sides of a merge, that would be better IMO. What about Stand? +msgstr checkt ihre Version für nicht zusammengeführte Dateien aus You're translating 'our/their version' - unsere/ihre Version. Taken just by itself I think it would be okay or at worst mildly confusing (how about unsere/ihre Seite [der Zusammenführung]?). However, in the wider context it is actually dangerous, because you are overloading the (German) Version here. It already means 'commit'! I've changed it to Variante, what do you think? entfernt - gelöscht avoids the ambiguity with the whole remote branch/repo business. Thanks, I've changed also other messages this way. #: builtin/fast-export.c:643 msgid Dump marks to this file -msgstr +msgstr Anzeige von Kennzeichen für diese Datei [...] #: builtin/fast-export.c:645 msgid Import marks from this file -msgstr +msgstr Importiert Kennzeichen von dieser Datei How did you manage to nail the second one, but get the first one wrong? :-) Gaahh, how embarrassing :) po/de.po | 157 +++ 1 file changed, 78 insertions(+), 79 deletions(-) diff --git a/po/de.po b/po/de.po index 9ffe4f2..796ada1 100644 --- a/po/de.po +++ b/po/de.po @@ -50,12 +50,12 @@ msgstr git archive --list msgid git archive --remote repo [--exec cmd] [options] tree-ish [path...] msgstr -git archive --remote Projektarchiv [--exec Kommando] [Optionen] +git archive --remote Projektarchiv [--exec Programm] [Optionen] Versionsreferenz [Pfad...] #: archive.c:13 msgid git archive --remote repo [--exec cmd] --list -msgstr git archive --remote Projektarchiv [--exec Kommando] --list +msgstr git archive --remote Projektarchiv [--exec Programm] --list #: archive.c:322 msgid fmt @@ -63,7 +63,7 @@ msgstr Format #: archive.c:322 msgid archive format -msgstr Archivformat +msgstr Ausgabeformat #: archive.c:323 builtin/log.c:1079 msgid prefix @@ -71,7 +71,7 @@ msgstr Prefix #: archive.c:324 msgid prepend prefix to each pathname in the archive -msgstr stellt einen Prefix vor jeden Pfadnamen in dem Archiv +msgstr stellt einen Präfix vor jeden Pfadnamen in der Ausgabe #: archive.c:325 builtin/archive.c:91 builtin/blame.c:2332 #: builtin/blame.c:2333 builtin/config.c:56 builtin/fast-export.c:642 @@ -83,7 +83,7 @@ msgstr Datei #: archive.c:326 builtin/archive.c:92 msgid write the archive to this file -msgstr schreibt das Archiv in diese Datei +msgstr schreibt die Ausgabe in diese Datei #: archive.c:328 msgid read .gitattributes in working directory @@ -107,7 +107,7 @@ msgstr besser komprimieren #: archive.c:342 msgid list supported archive formats -msgstr listet unterstützte Archivformate auf +msgstr listet unterstützte Ausgabeformate auf #: archive.c:344 builtin/archive.c:93 builtin/clone.c:85 msgid repo @@ -119,11 +119,11 @@ msgstr ruft das Archiv von externem Projektarchiv Projektarchiv ab #: archive.c:346 builtin/archive.c:95 builtin/notes.c:616 msgid command -msgstr Kommando +msgstr Programm #: archive.c:347 builtin/archive.c:96 msgid path to the remote git-upload-archive command -msgstr Pfad zum externen \git-upload-archive\ Kommando +msgstr Pfad zum externen \git-upload-archive\-Programm #: bundle.c:36 #, c-format @@ -1346,25 +1346,25 @@ msgstr nichts zum Eintragen hinzugefügt, aber es gibt unbeobachtete Dateien\n #, c-format msgid nothing to commit (create/copy files and use \git add\ to track)\n msgstr -nichts zum Eintragen (Erstelle/Kopiere Dateien und benutze \git add\ zum +nichts einzutragen (Erstelle/Kopiere Dateien und benutze \git add\ zum Beobachten)\n #: wt-status.c:1043 wt-status.c:1048 #, c-format msgid nothing to commit\n -msgstr nichts zum Eintragen\n +msgstr nichts einzutragen\n #: wt-status.c:1046 #, c-format msgid nothing to commit (use -u to show untracked files)\n msgstr -nichts zum Eintragen (benutze die Option -u, um unbeobachtete Dateien +nichts einzutragen (benutze die Option -u, um unbeobachtete Dateien anzuzeigen)\n #: wt-status.c:1050 #, c-format msgid nothing to commit, working directory clean\n -msgstr nichts zum Eintragen, Arbeitsverzeichnis sauber\n
Re: [PATCH v5 02/12] ctype: support iscntrl, ispunct, isxdigit and isprint
Am 14.10.2012 15:25, schrieb Nguyen Thai Ngoc Duy: On Sun, Oct 14, 2012 at 7:59 PM, René Scharfe rene.scha...@lsrfire.ath.cx wrote: With that, couldn't you squeeze the other two classes into the existing sane_type? No there are still conflicts: 9, 10 and 13 as spaces (vs controls) and 123, 124 and 126 as regex/pathspec special (vs punctuation). That's not a problem, an entry in the table can have more than one bit set -- just OR them together in ctype.c. It may not look as nice, but that's OK. You could also define a character for GIT_SPACE | GIT_CNTRL etc. for cosmetic reasons. René -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 02/12] ctype: support iscntrl, ispunct, isxdigit and isprint
On Sun, Oct 14, 2012 at 03:59:31PM +0200, René Scharfe wrote:
Am 14.10.2012 15:25, schrieb Nguyen Thai Ngoc Duy:
On Sun, Oct 14, 2012 at 7:59 PM, René Scharfe
rene.scha...@lsrfire.ath.cx wrote:
With that, couldn't you squeeze the other two classes into the existing
sane_type?
No there are still conflicts: 9, 10 and 13 as spaces (vs controls) and
123, 124 and 126 as regex/pathspec special (vs punctuation).
That's not a problem, an entry in the table can have more than one bit
set -- just OR them together in ctype.c. It may not look as nice, but
that's OK. You could also define a character for GIT_SPACE | GIT_CNTRL
etc. for cosmetic reasons.
Only space chars is not a subset of control chars, which needs a new
combination. So the result does not look as bad as I thought:
-- 8 --
diff --git a/ctype.c b/ctype.c
index faeaf34..0bfebb4 100644
--- a/ctype.c
+++ b/ctype.c
@@ -11,18 +11,21 @@ enum {
D = GIT_DIGIT,
G = GIT_GLOB_SPECIAL, /* *, ?, [, \\ */
R = GIT_REGEX_SPECIAL, /* $, (, ), +, ., ^, {, | */
- P = GIT_PATHSPEC_MAGIC /* other non-alnum, except for ] and } */
+ P = GIT_PATHSPEC_MAGIC, /* other non-alnum, except for ] and } */
+ X = GIT_CNTRL,
+ U = GIT_PUNCT,
+ Z = GIT_CNTRL | GIT_SPACE
};
const unsigned char sane_ctype[256] = {
- 0, 0, 0, 0, 0, 0, 0, 0, 0, S, S, 0, 0, S, 0, 0, /* 0.. 15 */
- 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, /* 16.. 31 */
+ X, X, X, X, X, X, X, X, X, Z, Z, X, X, Z, X, X, /* 0.. 15 */
+ X, X, X, X, X, X, X, X, X, X, X, X, X, X, X, X, /* 16.. 31 */
S, P, P, P, R, P, P, P, R, R, G, R, P, P, R, P, /* 32.. 47 */
D, D, D, D, D, D, D, D, D, D, P, P, P, P, P, G, /* 48.. 63 */
P, A, A, A, A, A, A, A, A, A, A, A, A, A, A, A, /* 64.. 79 */
- A, A, A, A, A, A, A, A, A, A, A, G, G, 0, R, P, /* 80.. 95 */
+ A, A, A, A, A, A, A, A, A, A, A, G, G, U, R, P, /* 80.. 95 */
P, A, A, A, A, A, A, A, A, A, A, A, A, A, A, A, /* 96..111 */
- A, A, A, A, A, A, A, A, A, A, A, R, R, 0, P, 0, /* 112..127 */
+ A, A, A, A, A, A, A, A, A, A, A, R, R, U, P, X, /* 112..127 */
/* Nothing in the 128.. range */
};
diff --git a/git-compat-util.h b/git-compat-util.h
index f8b859c..db77f3e 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -510,6 +510,10 @@ extern const char tolower_trans_tbl[256];
#undef isupper
#undef tolower
#undef toupper
+#undef iscntrl
+#undef ispunct
+#undef isxdigit
+#undef isprint
extern const unsigned char sane_ctype[256];
#define GIT_SPACE 0x01
#define GIT_DIGIT 0x02
@@ -517,6 +521,8 @@ extern const unsigned char sane_ctype[256];
#define GIT_GLOB_SPECIAL 0x08
#define GIT_REGEX_SPECIAL 0x10
#define GIT_PATHSPEC_MAGIC 0x20
+#define GIT_CNTRL 0x40
+#define GIT_PUNCT 0x80
#define sane_istest(x,mask) ((sane_ctype[(unsigned char)(x)] (mask)) != 0)
#define isascii(x) (((x) ~0x7f) == 0)
#define isspace(x) sane_istest(x,GIT_SPACE)
@@ -527,6 +533,13 @@ extern const unsigned char sane_ctype[256];
#define isupper(x) sane_iscase(x, 0)
#define is_glob_special(x) sane_istest(x,GIT_GLOB_SPECIAL)
#define is_regex_special(x) sane_istest(x,GIT_GLOB_SPECIAL | GIT_REGEX_SPECIAL)
+#define iscntrl(x) (sane_istest(x,GIT_CNTRL))
+#define ispunct(x) sane_istest(x, GIT_PUNCT | GIT_REGEX_SPECIAL | \
+ GIT_GLOB_SPECIAL | GIT_PATHSPEC_MAGIC)
+#define isxdigit(x) (hexval_table[x] != -1)
+#define isprint(x) (sane_istest(x, GIT_ALPHA | GIT_DIGIT | GIT_SPACE | \
+ GIT_PUNCT | GIT_REGEX_SPECIAL | GIT_GLOB_SPECIAL | \
+ GIT_PATHSPEC_MAGIC))
#define tolower(x) sane_case((unsigned char)(x), 0x20)
#define toupper(x) sane_case((unsigned char)(x), 0)
#define is_pathspec_magic(x) sane_istest(x,GIT_PATHSPEC_MAGIC)
-- 8 --
--
Duy
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: A design for subrepositories
Quoting Jens Lehmann jens.lehm...@web.de: If the submodules ever get reorganized and foo is moved to ./bar, then it is impossible to check out older versions or alternate branches, since the submodule is no longer where it is expected to be at the origin. Your initial statement is not correct. Please elaborate. My initial statement was about git submodule add ./foo, and this is what I get: la@bq:~/tmp$ git --version git version 1.8.0.rc2.2.gfc364c7 la@bq:~/tmp$ git init super Initialized empty Git repository in /home/la/tmp/super/.git/ la@bq:~/tmp$ cd super la@bq:~/tmp/super$ echo foo foo la@bq:~/tmp/super$ git add foo la@bq:~/tmp/super$ git ci -m foo [master (root-commit) a0dd543] foo 1 file changed, 1 insertion(+) create mode 100644 foo la@bq:~/tmp/super$ git init sub Initialized empty Git repository in /home/la/tmp/super/sub/.git/ la@bq:~/tmp/super$ cd sub la@bq:~/tmp/super/sub$ echo bar bar la@bq:~/tmp/super/sub$ git add bar la@bq:~/tmp/super/sub$ git ci -m bar [master (root-commit) a6ee6d6] bar 1 file changed, 1 insertion(+) create mode 100644 bar la@bq:~/tmp/super/sub$ cd .. la@bq:~/tmp/super$ git submodule add ./sub Adding existing repo at 'sub' to the index la@bq:~/tmp/super$ git ci -m sub [master cb289e8] sub 2 files changed, 4 insertions(+) create mode 100644 .gitmodules create mode 16 sub la@bq:~/tmp/super$ git branch old la@bq:~/tmp/super$ git mv sub movedsub fatal: source directory is empty, source=sub, destination=movedsub la@bq:~/tmp/super$ mv sub movedsub la@bq:~/tmp/super$ git rm sub rm 'sub' la@bq:~/tmp/super$ git add movedsub la@bq:~/tmp/super$ git config -f .gitmodules submodule.sub.path movedsub la@bq:~/tmp/super$ git config -f .gitmodules submodule.sub.url ./movedsub la@bq:~/tmp/super$ git ci -am movedsub [master 5598bc0] movedsub 2 files changed, 2 insertions(+), 2 deletions(-) rename sub = movedsub (100%) la@bq:~/tmp/super$ cd .. la@bq:~/tmp$ git clone super superc Cloning into 'superc'... done. la@bq:~/tmp$ cd superc la@bq:~/tmp/superc$ git co old Branch old set up to track remote branch old from origin. Switched to a new branch 'old' la@bq:~/tmp/superc$ git submodule update --init Submodule 'sub' (/home/la/tmp/super/sub) registered for path 'sub' fatal: repository '/home/la/tmp/super/sub' does not exist Clone of '/home/la/tmp/super/sub' into submodule path 'sub' failed So a normal relative path in .gitmodules to inside the tree is fragile, since the location of the submodule can change. Did you notice that git fetch fetches all those submodules too which have been updated in the commits fetched for the superproject, no matter on what branch they are on? No. This would be great, but this is what I get: la@bq:~/tmp$ git init super Initialized empty Git repository in /home/la/tmp/super/.git/ la@bq:~/tmp$ cd super la@bq:~/tmp/super$ echo foo foo la@bq:~/tmp/super$ git add foo la@bq:~/tmp/super$ git ci -m foo [master (root-commit) 0f207c9] foo 1 file changed, 1 insertion(+) create mode 100644 foo la@bq:~/tmp/super$ git branch nosubs la@bq:~/tmp/super$ git init sub Initialized empty Git repository in /home/la/tmp/super/sub/.git/ la@bq:~/tmp/super$ cd sub la@bq:~/tmp/super/sub$ echo bar bar la@bq:~/tmp/super/sub$ git add bar la@bq:~/tmp/super/sub$ git ci -m bar [master (root-commit) 180c6c9] bar 1 file changed, 1 insertion(+) create mode 100644 bar la@bq:~/tmp/super/sub$ cd .. la@bq:~/tmp/super$ git submodule add ./sub Adding existing repo at 'sub' to the index la@bq:~/tmp/super$ git ci -m sub [master 16cff18] sub 2 files changed, 4 insertions(+) create mode 100644 .gitmodules create mode 16 sub la@bq:~/tmp/super$ cd .. la@bq:~/tmp$ git clone super superc Cloning into 'superc'... done. la@bq:~/tmp$ cd superc la@bq:~/tmp/superc$ git submodule update --init Submodule 'sub' (/home/la/tmp/super/sub) registered for path 'sub' Cloning into 'sub'... done. Submodule path 'sub': checked out '180c6c979289f4e25525003673e51d0e39dab8f6' la@bq:~/tmp/superc$ cd ../super/sub la@bq:~/tmp/super/sub$ echo baz bar la@bq:~/tmp/super/sub$ git ci -am baz [master 652c8b3] baz 1 file changed, 1 insertion(+) la@bq:~/tmp/super/sub$ cd .. la@bq:~/tmp/super$ git ci -am subbaz [master c7c3bfc] subbaz 1 file changed, 1 insertion(+), 1 deletion(-) la@bq:~/tmp/super$ cd ../superc la@bq:~/tmp/superc$ git co nosubs warning: unable to rmdir sub: Directory not empty Branch nosubs set up to track remote branch nosubs from origin. Switched to a new branch 'nosubs' la@bq:~/tmp/superc$ git fetch --recurse-submodules=yes remote: Counting objects: 3, done. remote: Compressing objects: 100% (2/2), done. remote: Total 2 (delta 1), reused 0 (delta 0) Unpacking objects: 100% (2/2), done. From /home/la/tmp/super 16cff18..c7c3bfc master - origin/master la@bq:~/tmp/superc$ git co master Switched to branch 'master' Your branch is behind 'origin/master' by 1 commit, and can be fast-forwarded. la@bq:~/tmp/superc$ git fetch --recurse-submodules=yes Fetching submodule sub remote:
[PATCH v5 0/3] completion: refactor and zsh wrapper
Hi, Here's a bit of reorganition. I'm introducing a new __gitcompadd helper that is useful to wrapp all changes to COMPREPLY. 2nd and 3rd patches show how it's useful. The zsh wrapper is now very very simple, but I haven't received much feedback yet. I hope it will get in at some point in time. Felipe Contreras (3): completion: add new __gitcompadd helper tests: use __gitcompadd to simplify completion tests completion: add new zsh completion contrib/completion/git-completion.bash | 65 ++ contrib/completion/git-completion.zsh | 48 + t/t9902-completion.sh | 29 +-- 3 files changed, 91 insertions(+), 51 deletions(-) create mode 100644 contrib/completion/git-completion.zsh -- 1.7.12.1 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 1/3] completion: add new __gitcompadd helper
The idea is to never touch the COMPREPLY variable directly.
This allows other completion systems override __gitcompadd, and do
something different instead.
Also, this allows the simplifcation of the completino tests (separate
patch).
There should be no functional changes.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/completion/git-completion.bash | 65 ++
1 file changed, 34 insertions(+), 31 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index d743e56..01325de 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -225,6 +225,11 @@ _get_comp_words_by_ref ()
fi
fi
+__gitcompadd ()
+{
+ COMPREPLY=($(compgen -W $1 -P $2 -S $4 -- $3))
+}
+
# Generates completion reply with compgen, appending a space to possible
# completion words, if necessary.
# It accepts 1 to 4 arguments:
@@ -238,13 +243,11 @@ __gitcomp ()
case $cur_ in
--*=)
- COMPREPLY=()
+ __gitcompadd
;;
*)
local IFS=$'\n'
- COMPREPLY=($(compgen -P ${2-} \
- -W $(__gitcomp_1 ${1-} ${4-}) \
- -- $cur_))
+ __gitcompadd $(__gitcomp_1 ${1-} ${4-}) ${2-} $cur_
;;
esac
}
@@ -261,7 +264,7 @@ __gitcomp ()
__gitcomp_nl ()
{
local IFS=$'\n'
- COMPREPLY=($(compgen -P ${2-} -S ${4- } -W $1 -- ${3-$cur}))
+ __gitcompadd $1 ${2-} ${3-$cur} ${4- }
}
__git_heads ()
@@ -486,7 +489,7 @@ __git_complete_remote_or_refspec ()
case $cmd in
push) no_complete_refspec=1 ;;
fetch)
- COMPREPLY=()
+ __gitcompadd
return
;;
*) ;;
@@ -502,7 +505,7 @@ __git_complete_remote_or_refspec ()
return
fi
if [ $no_complete_refspec = 1 ]; then
- COMPREPLY=()
+ __gitcompadd
return
fi
[ $remote = . ] remote=
@@ -776,7 +779,7 @@ _git_am ()
return
esac
- COMPREPLY=()
+ __gitcompadd
}
_git_apply ()
@@ -796,7 +799,7 @@ _git_apply ()
return
esac
- COMPREPLY=()
+ __gitcompadd
}
_git_add ()
@@ -811,7 +814,7 @@ _git_add ()
return
esac
- COMPREPLY=()
+ __gitcompadd
}
_git_archive ()
@@ -856,7 +859,7 @@ _git_bisect ()
__gitcomp_nl $(__git_refs)
;;
*)
- COMPREPLY=()
+ __gitcompadd
;;
esac
}
@@ -965,7 +968,7 @@ _git_clean ()
return
;;
esac
- COMPREPLY=()
+ __gitcompadd
}
_git_clone ()
@@ -989,7 +992,7 @@ _git_clone ()
return
;;
esac
- COMPREPLY=()
+ __gitcompadd
}
_git_commit ()
@@ -1023,7 +1026,7 @@ _git_commit ()
return
esac
- COMPREPLY=()
+ __gitcompadd
}
_git_describe ()
@@ -1154,7 +1157,7 @@ _git_fsck ()
return
;;
esac
- COMPREPLY=()
+ __gitcompadd
}
_git_gc ()
@@ -1165,7 +1168,7 @@ _git_gc ()
return
;;
esac
- COMPREPLY=()
+ __gitcompadd
}
_git_gitk ()
@@ -1242,7 +1245,7 @@ _git_init ()
return
;;
esac
- COMPREPLY=()
+ __gitcompadd
}
_git_ls_files ()
@@ -1261,7 +1264,7 @@ _git_ls_files ()
return
;;
esac
- COMPREPLY=()
+ __gitcompadd
}
_git_ls_remote ()
@@ -1377,7 +1380,7 @@ _git_mergetool ()
return
;;
esac
- COMPREPLY=()
+ __gitcompadd
}
_git_merge_base ()
@@ -1393,7 +1396,7 @@ _git_mv ()
return
;;
esac
- COMPREPLY=()
+ __gitcompadd
}
_git_name_rev ()
@@ -1563,7 +1566,7 @@ _git_send_email ()
return
;;
esac
- COMPREPLY=()
+ __gitcompadd
}
_git_stage ()
@@ -1616,7 +1619,7 @@ _git_config ()
local remote=${prev#remote.}
remote=${remote%.fetch}
if [ -z $cur ]; then
- COMPREPLY=(refs/heads/)
+ __gitcompadd refs/heads/
return
fi
__gitcomp_nl $(__git_refs_remotes $remote)
@@ -1676,7 +1679,7 @@ _git_config ()
return
;;
*.*)
- COMPREPLY=()
+ __gitcompadd
[PATCH v5 2/3] tests: use __gitcompadd to simplify completion tests
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
t/t9902-completion.sh | 29 +
1 file changed, 9 insertions(+), 20 deletions(-)
diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
index 92d7eb4..49c6eb4 100755
--- a/t/t9902-completion.sh
+++ b/t/t9902-completion.sh
@@ -39,19 +39,18 @@ _get_comp_words_by_ref ()
done
}
-print_comp ()
+__gitcompadd ()
{
- local IFS=$'\n'
- echo ${COMPREPLY[*]} out
+ compgen -P ${2-} -S ${4- } -W $1 -- ${3-$cur} out
}
run_completion ()
{
- local -a COMPREPLY _words
+ local -a _words
local _cword
_words=( $1 )
(( _cword = ${#_words[@]} - 1 ))
- __git_wrap__git_main print_comp
+ __git_wrap__git_main
}
test_completion ()
@@ -70,12 +69,10 @@ test_expect_success '__gitcomp - trailing space - options' '
--reset-author Z
EOF
(
- local -a COMPREPLY
cur=--re
__gitcomp --dry-run --reuse-message= --reedit-message=
--reset-author
- IFS=$newline
- echo ${COMPREPLY[*]} out
+ IFS=$newline
)
test_cmp expected out
'
@@ -88,12 +85,10 @@ test_expect_success '__gitcomp - trailing space - config
keys' '
browser.Z
EOF
(
- local -a COMPREPLY
cur=br
__gitcomp branch. branch.autosetupmerge
branch.autosetuprebase browser.
- IFS=$newline
- echo ${COMPREPLY[*]} out
+ IFS=$newline
)
test_cmp expected out
'
@@ -104,12 +99,10 @@ test_expect_success '__gitcomp - option parameter' '
resolve Z
EOF
(
- local -a COMPREPLY
cur=--strategy=re
__gitcomp octopus ours recursive resolve subtree
re
- IFS=$newline
- echo ${COMPREPLY[*]} out
+ IFS=$newline
)
test_cmp expected out
'
@@ -120,12 +113,10 @@ test_expect_success '__gitcomp - prefix' '
branch.maint.mergeoptions Z
EOF
(
- local -a COMPREPLY
cur=branch.me
__gitcomp remote merge mergeoptions rebase
branch.maint. me
- IFS=$newline
- echo ${COMPREPLY[*]} out
+ IFS=$newline
)
test_cmp expected out
'
@@ -136,12 +127,10 @@ test_expect_success '__gitcomp - suffix' '
branch.maint.Z
EOF
(
- local -a COMPREPLY
cur=branch.me
__gitcomp master maint next pu
branch. ma .
- IFS=$newline
- echo ${COMPREPLY[*]} out
+ IFS=$newline
)
test_cmp expected out
'
--
1.7.12.1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 3/3] completion: add new zsh completion
It seems there's always issues with zsh's bash completion emulation.
I've tried to fix as many as I could and most of the fixes are already
in the latest version of zsh, but still, there are issues.
There is no point in going through all that pain; the emulation is easy
to achieve, and this patch works better than zsh's emulation.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
v5:
* Even more simplification by using __gitcompadd
v4:
* Simplification updates for the latest bash completion
v3:
* Simplification
* Avoid COMPREPLY; call compadd directly
* Fix _get_comp_words_by_ref
contrib/completion/git-completion.zsh | 48 +++
1 file changed, 48 insertions(+)
create mode 100644 contrib/completion/git-completion.zsh
diff --git a/contrib/completion/git-completion.zsh
b/contrib/completion/git-completion.zsh
new file mode 100644
index 000..dbb5261
--- /dev/null
+++ b/contrib/completion/git-completion.zsh
@@ -0,0 +1,48 @@
+#compdef git gitk
+
+# zsh completion wrapper for git
+#
+# You need git's bash completion script installed somewhere, by default on the
+# same directory as this script.
+#
+# If your script is on ~/.git-completion.sh instead, you can configure it on
+# your ~/.zshrc:
+#
+# zstyle ':completion:*:*:git:*' script ~/.git-completion.sh
+#
+# The recommended way to install this script is to copy to
+# '~/.zsh/completion/_git', and then add the following to your ~/.zshrc file:
+#
+# fpath=(~/.zsh/completion $fpath)
+
+complete ()
+{
+ # do nothing
+ return 0
+}
+
+zstyle -s :completion:*:*:git:* script script
+test -z $script script=$(dirname
${funcsourcetrace[1]%:*})/git-completion.bash
+ZSH_VERSION='' . $script
+
+__gitcompadd ()
+{
+ compadd -Q -S $4 -P $2 -p ${(M)cur#*[=:]} -- ${=1} _ret=0
+}
+
+_git ()
+{
+ local _ret=1
+ () {
+ emulate -L ksh
+ local cur cword prev
+ cur=${words[CURRENT-1]}
+ prev=${words[CURRENT-2]}
+ let cword=CURRENT-1
+ __${service}_main
+ }
+ let _ret _default -S '' _ret=0
+ return _ret
+}
+
+_git
--
1.7.12.1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: A design for subrepositories
Am 14.10.2012 17:27, schrieb Lauri Alanko: Quoting Jens Lehmann jens.lehm...@web.de: If the submodules ever get reorganized and foo is moved to ./bar, then it is impossible to check out older versions or alternate branches, since the submodule is no longer where it is expected to be at the origin. Your initial statement is not correct. Please elaborate. My initial statement was about git submodule add ./foo, and this is what I get: la@bq:~/tmp$ git --version git version 1.8.0.rc2.2.gfc364c7 la@bq:~/tmp$ git init super Initialized empty Git repository in /home/la/tmp/super/.git/ la@bq:~/tmp$ cd super la@bq:~/tmp/super$ echo foo foo la@bq:~/tmp/super$ git add foo la@bq:~/tmp/super$ git ci -m foo [master (root-commit) a0dd543] foo 1 file changed, 1 insertion(+) create mode 100644 foo la@bq:~/tmp/super$ git init sub Initialized empty Git repository in /home/la/tmp/super/sub/.git/ la@bq:~/tmp/super$ cd sub la@bq:~/tmp/super/sub$ echo bar bar la@bq:~/tmp/super/sub$ git add bar la@bq:~/tmp/super/sub$ git ci -m bar [master (root-commit) a6ee6d6] bar 1 file changed, 1 insertion(+) create mode 100644 bar la@bq:~/tmp/super/sub$ cd .. la@bq:~/tmp/super$ git submodule add ./sub Adding existing repo at 'sub' to the index la@bq:~/tmp/super$ git ci -m sub [master cb289e8] sub 2 files changed, 4 insertions(+) create mode 100644 .gitmodules create mode 16 sub la@bq:~/tmp/super$ git branch old la@bq:~/tmp/super$ git mv sub movedsub fatal: source directory is empty, source=sub, destination=movedsub This error here indicates that we didn't teach git to properly move a submodule yet. It is one of my next goals to make git [submodule] mv sub movedsub do the right thing here. To do these steps manually you'll additionally have to do the following before moving the submodule (because after moving it the relative paths will be broken): $ HASH=$(cd sub; git rev-parse HEAD) la@bq:~/tmp/super$ mv sub movedsub Currently it is better to remove the submodule here, as recreating it with a git submodule update later will get the relative paths right. la@bq:~/tmp/super$ git rm sub rm 'sub' la@bq:~/tmp/super$ git add movedsub And to git this adds a completely different submodule (as its name is not sub), which breaks your expectation. To do what you intended use this line instead: $ git update-index --add --cacheinfo 16 $HASH movedsub (With the --next option currently in the next branch of Junio's repo a git submodule add --name sub movedsub should do the job. Until then a bit more magic is necessary). la@bq:~/tmp/super$ git config -f .gitmodules submodule.sub.path movedsub la@bq:~/tmp/super$ git config -f .gitmodules submodule.sub.url ./movedsub la@bq:~/tmp/super$ git ci -am movedsub [master 5598bc0] movedsub 2 files changed, 2 insertions(+), 2 deletions(-) rename sub = movedsub (100%) la@bq:~/tmp/super$ cd .. la@bq:~/tmp$ git clone super superc Cloning into 'superc'... done. la@bq:~/tmp$ cd superc la@bq:~/tmp/superc$ git co old Branch old set up to track remote branch old from origin. Switched to a new branch 'old' la@bq:~/tmp/superc$ git submodule update --init Submodule 'sub' (/home/la/tmp/super/sub) registered for path 'sub' fatal: repository '/home/la/tmp/super/sub' does not exist Clone of '/home/la/tmp/super/sub' into submodule path 'sub' failed And that fails because to be able to clone a submodule it has to be pushed into its own repo first, so it can be cloned from there somewhere else. After doing that this will work. So a normal relative path in .gitmodules to inside the tree is fragile, since the location of the submodule can change. As I said, the current user experience is suboptimal. The test case 'submodule update properly revives a moved submodule' in t7406 shows what has to be done with current git to properly move a submodule, which is way too much to remember for a regular git user. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] completion: add format-patch options to send-email
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/completion/git-completion.bash | 35 +-
t/t9902-completion.sh | 21
2 files changed, 39 insertions(+), 17 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index d743e56..2a83504 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1112,6 +1112,14 @@ _git_fetch ()
__git_complete_remote_or_refspec
}
+__git_format_patch_options=
+ --stdout --attach --no-attach --thread --thread= --output-directory
+ --numbered --start-number --numbered-files --keep-subject --signoff
+ --signature --no-signature --in-reply-to= --cc= --full-index --binary
+ --not --all --cover-letter --no-prefix --src-prefix= --dst-prefix=
+ --inline --suffix= --ignore-if-in-upstream --subject-prefix=
+
+
_git_format_patch ()
{
case $cur in
@@ -1122,21 +1130,7 @@ _git_format_patch ()
return
;;
--*)
- __gitcomp
- --stdout --attach --no-attach --thread --thread=
- --output-directory
- --numbered --start-number
- --numbered-files
- --keep-subject
- --signoff --signature --no-signature
- --in-reply-to= --cc=
- --full-index --binary
- --not --all
- --cover-letter
- --no-prefix --src-prefix= --dst-prefix=
- --inline --suffix= --ignore-if-in-upstream
- --subject-prefix=
-
+ __gitcomp $__git_format_patch_options
return
;;
esac
@@ -1550,6 +1544,12 @@ _git_send_email ()
__gitcomp ssl tls ${cur##--smtp-encryption=}
return
;;
+ --thread=*)
+ __gitcomp
+ deep shallow
+ ${cur##--thread=}
+ return
+ ;;
--*)
__gitcomp --annotate --bcc --cc --cc-cmd --chain-reply-to
--compose --confirm= --dry-run --envelope-sender
@@ -1559,11 +1559,12 @@ _git_send_email ()
--signed-off-by-cc --smtp-pass --smtp-server
--smtp-server-port --smtp-encryption= --smtp-user
--subject --suppress-cc= --suppress-from --thread --to
- --validate --no-validate
+ --validate --no-validate
+ $__git_format_patch_options
return
;;
esac
- COMPREPLY=()
+ __git_complete_revlist_file
}
_git_stage ()
diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
index 92d7eb4..c4b6c13 100755
--- a/t/t9902-completion.sh
+++ b/t/t9902-completion.sh
@@ -146,6 +146,22 @@ test_expect_success '__gitcomp - suffix' '
test_cmp expected out
'
+setup_repository ()
+{
+ mkdir $1 (
+ cd $1
+ git init
+ test_tick
+ git commit --allow-empty -m Initial
+ )
+}
+
+test_expect_success 'prepare' '
+ setup_repository one
+ git clone one test
+ cd test
+'
+
test_expect_success 'basic' '
run_completion git \\
# built-in
@@ -228,4 +244,9 @@ test_expect_success 'general options plus command' '
test_completion git --no-replace-objects check checkout
'
+test_expect_success 'send-email' '
+ test_completion git send-email --cov --cover-letter
+ test_completion git send-email ma master
+'
+
test_done
--
1.7.12.1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: A design for subrepositories
Am 14.10.2012 17:27, schrieb Lauri Alanko: Quoting Jens Lehmann jens.lehm...@web.de: What's wrong with making git clone all submodules together with the superproject (when the user said he wants to update all submodules on clone too by setting a - still to be added - config option)? Depends on how it's done. In a previous mail I just considered various ways to do it. If I see correctly, your choice is to read .gitmodules from every branch and every tag to find the total set of submodules used by the repository. As I said already, that is certainly possible, but it's just not very scalable, if fetch operations slow down linearly in the number of tags. Currently git fetch checks all newly fetched commits for changes in gitlinks too, so that would just add another file to that. And as a fetch is pretty much linear in the number of newly fetched commits anyway, its performance impact should be minimal. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: A design for subrepositories
Am 14.10.2012 17:27, schrieb Lauri Alanko: Quoting Jens Lehmann jens.lehm...@web.de: Did you notice that git fetch fetches all those submodules too which have been updated in the commits fetched for the superproject, no matter on what branch they are on? No. This would be great, but this is what I get: la@bq:~/tmp$ git init super Initialized empty Git repository in /home/la/tmp/super/.git/ la@bq:~/tmp$ cd super la@bq:~/tmp/super$ echo foo foo la@bq:~/tmp/super$ git add foo la@bq:~/tmp/super$ git ci -m foo [master (root-commit) 0f207c9] foo 1 file changed, 1 insertion(+) create mode 100644 foo la@bq:~/tmp/super$ git branch nosubs la@bq:~/tmp/super$ git init sub Initialized empty Git repository in /home/la/tmp/super/sub/.git/ la@bq:~/tmp/super$ cd sub la@bq:~/tmp/super/sub$ echo bar bar la@bq:~/tmp/super/sub$ git add bar la@bq:~/tmp/super/sub$ git ci -m bar [master (root-commit) 180c6c9] bar 1 file changed, 1 insertion(+) create mode 100644 bar la@bq:~/tmp/super/sub$ cd .. la@bq:~/tmp/super$ git submodule add ./sub Adding existing repo at 'sub' to the index la@bq:~/tmp/super$ git ci -m sub [master 16cff18] sub 2 files changed, 4 insertions(+) create mode 100644 .gitmodules create mode 16 sub la@bq:~/tmp/super$ cd .. la@bq:~/tmp$ git clone super superc Cloning into 'superc'... done. la@bq:~/tmp$ cd superc la@bq:~/tmp/superc$ git submodule update --init Submodule 'sub' (/home/la/tmp/super/sub) registered for path 'sub' Cloning into 'sub'... done. Submodule path 'sub': checked out '180c6c979289f4e25525003673e51d0e39dab8f6' la@bq:~/tmp/superc$ cd ../super/sub la@bq:~/tmp/super/sub$ echo baz bar la@bq:~/tmp/super/sub$ git ci -am baz [master 652c8b3] baz 1 file changed, 1 insertion(+) la@bq:~/tmp/super/sub$ cd .. la@bq:~/tmp/super$ git ci -am subbaz [master c7c3bfc] subbaz 1 file changed, 1 insertion(+), 1 deletion(-) la@bq:~/tmp/super$ cd ../superc la@bq:~/tmp/superc$ git co nosubs warning: unable to rmdir sub: Directory not empty Branch nosubs set up to track remote branch nosubs from origin. Switched to a new branch 'nosubs' la@bq:~/tmp/superc$ git fetch --recurse-submodules=yes remote: Counting objects: 3, done. remote: Compressing objects: 100% (2/2), done. remote: Total 2 (delta 1), reused 0 (delta 0) Unpacking objects: 100% (2/2), done. From /home/la/tmp/super 16cff18..c7c3bfc master - origin/master la@bq:~/tmp/superc$ git co master Switched to branch 'master' Your branch is behind 'origin/master' by 1 commit, and can be fast-forwarded. la@bq:~/tmp/superc$ git fetch --recurse-submodules=yes Fetching submodule sub remote: Counting objects: 5, done. remote: Total 3 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. From /home/la/tmp/super/sub 180c6c9..652c8b3 master - origin/master So I had to checkout master in order to fetch the updates to the submodule used by master. Yes, when you switch to a branch which hasn't got that submodule at all that is the case (as currently the .gitmodules found in the work tree is used to do the path - name mapping). The culprit is the git fetch does not yet examine the .gitmodules file of the commit it finds a submodule change in, but uses the one currently found inside the work tree. But I'll have to tackle too soon, as that also poses a problem when the submodule was moved. So no matter what branch they are on is not always correct at the moment ;-) Again, the user experience is currently suboptimal. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] config: treat user and xdg config permission problems as errors
On Sun, Oct 14, 2012 at 01:42:44AM -0700, Jonathan Nieder wrote: Jeff King wrote: For example, servers may depend on /etc/gitconfig to enforce security policy (e.g., setting transfer.fsckObjects or receive.deny*). Perhaps our default should be safe, and people can use GIT_CONFIG_NOSYSTEM to work around a broken machine. Very good point. How about these patches on top? Jonathan Nieder (2): config doc: advertise GIT_CONFIG_NOSYSTEM config: exit on error accessing any config file Documentation/git-config.txt | 8 config.c | 6 +++--- 2 files changed, 11 insertions(+), 3 deletions(-) This is my absolute favorite type of reply: the kind that you can apply with git am. The direction and the patches themselves look good to me. I agree with your reasoning in v2 of 3/2; it makes much more sense than v1. Thanks. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Why git shows staging area to users?
David Aguilar dav...@gmail.com writes: On Sat, Oct 13, 2012 at 2:08 PM, Yi, EungJun semtlen...@gmail.com wrote: Hi, all. Why git shows staging area to users, compared with the other scms hide it? What benefits users get? http://thkoch2001.github.com/whygitisbetter/#the-staging-area http://tomayko.com/writings/the-thing-about-git http://gitready.com/beginner/2009/01/18/the-staging-area.html Other scms do not hide; other scms lack this feature altogether. More precisely: there are several things in what git calls the index or the staging area (i.e. .git/index): 1) a list of files tracked by Git 2) a record of the last known meta-data of the file, used to avoid re-reading unmodified files content each time one runs diff, commit or so. 3) a record of the file's staged *content* (possible several records in case a merge is going on) Any decent revision control has the equivalent of 1) and 2), but AFAIK, 3) is a unique feature of Git. There is a frequent confusion between 2) and 3) that leads to people (often other revision-control users/developers) wonder why this is visible to the user. 2) is a performance optimization that can be hidden to the user (it is with Git's porcelain commands), but 3) is user-visible. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: A design for subrepositories
Jens Lehmann jens.lehm...@web.de writes: Again, the user experience is currently suboptimal. You mentioned multiple things in your responses that you are planning to address, but I am wondering if the first step before doing anything else is to have a list of known-to-be-suboptimal things and publish it somewhere other people can find it. Then Lauri or others may able to help code the design of the approach to address them for items you already have designs for, and they may even be able to help designing the approach for the ones you don't. More importantly, they do not have to waste time coming up with incompatible tools. Adding works in this scenario that is different from those other slightly different tools to the mix of third-party tool set would fragment and confuse the user base (which one of 47 different tools, all of which are incomplete, should I use?) and dilute developer attention. They all at some point want to interact with the core side, and without an overall consistent design and coordination, some of their demand on the core side would end up being imcompatible. The just let .gitmodules record which branch is of interest, without checking out a specific commit bound to the superproject tree and using as a base for diff (aka floating submodule) could be one of the items on the list, for example; to support it, we should not have to throw the entire git submodule with the bathwater. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] exclude/attr: share basename matching code
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
match_basename's declaration in dir.h does not have any description to
discourage the use of this function elsewhere as this function is
highly tied to how excluded_from_list and path_matches work.
If you do want to discourage, please explicitly describe it as such.
I actually think it should have an API description. The meaning of
its parameters and how you would formulate them is fairly clear and
this is a good example of a simple-and-stupid function that is
designed to do one thing and do it well.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
attr.c | 15 ---
dir.c | 37 -
dir.h | 2 ++
3 files changed, 30 insertions(+), 24 deletions(-)
diff --git a/attr.c b/attr.c
index 0964033..a28ce0d 100644
--- a/attr.c
+++ b/attr.c
@@ -663,17 +663,10 @@ static int path_matches(const char *pathname, int
pathlen,
int namelen;
if (pat-flags EXC_FLAG_NODIR) {
- if (prefix == pat-patternlen
- !strcmp_icase(pattern, basename))
- return 1;
-
- if (pat-flags EXC_FLAG_ENDSWITH
- pat-patternlen - 1 = pathlen
- !strcmp_icase(pattern + 1, pathname +
- pathlen - pat-patternlen + 1))
- return 1;
-
- return (fnmatch_icase(pattern, basename, 0) == 0);
+ return match_basename(basename,
+ pathlen - (basename - pathname),
+ pattern, prefix,
+ pat-patternlen, pat-flags);
}
/*
* match with FNM_PATHNAME; the pattern has base implicitly
diff --git a/dir.c b/dir.c
index 0f4aea6..42c42cd 100644
--- a/dir.c
+++ b/dir.c
@@ -530,6 +530,25 @@ static void prep_exclude(struct dir_struct *dir, const
char *base, int baselen)
dir-basebuf[baselen] = '\0';
}
+int match_basename(const char *basename, int basenamelen,
+const char *pattern, int prefix, int patternlen,
+int flags)
+{
+ if (prefix == patternlen) {
+ if (!strcmp_icase(pattern, basename))
+ return 1;
+ } else if (flags EXC_FLAG_ENDSWITH) {
+ if (patternlen - 1 = basenamelen
+ !strcmp_icase(pattern + 1,
+ basename + basenamelen - patternlen + 1))
+ return 1;
+ } else {
+ if (fnmatch_icase(pattern, basename, 0) == 0)
+ return 1;
+ }
+ return 0;
+}
+
/* Scan the list and let the last match determine the fate.
* Return 1 for exclude, 0 for include and -1 for undecided.
*/
@@ -556,19 +575,11 @@ int excluded_from_list(const char *pathname,
}
if (x-flags EXC_FLAG_NODIR) {
- /* match basename */
- if (prefix == x-patternlen) {
- if (!strcmp_icase(exclude, basename))
- return to_exclude;
- } else if (x-flags EXC_FLAG_ENDSWITH) {
- int len = pathlen - (basename - pathname);
- if (x-patternlen - 1 = len
- !strcmp_icase(exclude + 1, basename + len -
x-patternlen + 1))
- return to_exclude;
- } else {
- if (fnmatch_icase(exclude, basename, 0) == 0)
- return to_exclude;
- }
+ if (match_basename(basename,
+pathlen - (basename - pathname),
+exclude, prefix, x-patternlen,
+x-flags))
+ return to_exclude;
continue;
}
diff --git a/dir.h b/dir.h
index fd5c2aa..d416c5a 100644
--- a/dir.h
+++ b/dir.h
@@ -78,6 +78,8 @@ extern int read_directory(struct dir_struct *, const char
*path, int len, const
extern int excluded_from_list(const char *pathname, int pathlen, const char
*basename,
int *dtype, struct exclude_list *el);
+extern int match_basename(const char *, int,
+ const char *, int, int, int);
struct dir_entry *dir_add_ignored(struct dir_struct *dir, const char
*pathname, int len);
/*
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Planning to pass the baton to an interim maintainer
I am planning to * tag 1.8.0 final on Oct 21st (Sun); * go offline on Oct 22nd (Mon); and * come back online on Nov 12th (Mon). Peff, could you be the interim maintainer as you've done in earlier years while I was away? Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] exclude: fix a bug in prefix comparison optimization
Junio C Hamano gits...@pobox.com writes: Comparing the corresponding code in dir.c, there is no compare the literal prefix part with strcmp() before doing the fnmatch() optimization. Intended? (warning: I haven't had my caffeine yet) And it turns out that at the point I wrote the response, I still had the attr-match-optim-more updates to be read in my mailbox ;-) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: A design for subrepositories
Am 14.10.2012 20:04, schrieb Junio C Hamano: Jens Lehmann jens.lehm...@web.de writes: Again, the user experience is currently suboptimal. You mentioned multiple things in your responses that you are planning to address, but I am wondering if the first step before doing anything else is to have a list of known-to-be-suboptimal things and publish it somewhere other people can find it. Then Lauri or others may able to help code the design of the approach to address them for items you already have designs for, and they may even be able to help designing the approach for the ones you don't. I'm keeping such a list in the Issues still to be tackled in this repo section of the Wiki page of my github repo: https://github.com/jlehmann/git-submod-enhancements/wiki Currently that's just a collection of things to do and bugs to fix, but if people are interested I'm willing to add descriptions of the solutions I have in mind for those topics. More importantly, they do not have to waste time coming up with incompatible tools. Adding works in this scenario that is different from those other slightly different tools to the mix of third-party tool set would fragment and confuse the user base (which one of 47 different tools, all of which are incomplete, should I use?) and dilute developer attention. They all at some point want to interact with the core side, and without an overall consistent design and coordination, some of their demand on the core side would end up being imcompatible. The just let .gitmodules record which branch is of interest, without checking out a specific commit bound to the superproject tree and using as a base for diff (aka floating submodule) could be one of the items on the list, for example; to support it, we should not have to throw the entire git submodule with the bathwater. Yup, that's also on that list under always tip mode. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] exclude: fix a bug in prefix comparison optimization
On Mon, Oct 15, 2012 at 12:36 AM, Junio C Hamano gits...@pobox.com wrote: With your teach attr.c match the same optimization as dir.c series, you would need something like this diff --git i/attr.c w/attr.c index 6d39406..528e935 100644 --- i/attr.c +++ w/attr.c @@ -710,7 +710,7 @@ static int path_matches(const char *pathname, int pathlen, * if the non-wildcard part is longer than the remaining * pathname, surely it cannot match. */ - if (!namelen || prefix namelen) + if (prefix namelen) return 0; if (baselen != 0) baselen++; If there's still a chance to rewrite attr-match-optim-more series (I see it's in next now), then I could reorder the patches so that excluded_from_list code refactoring goes first, then rewrite teach attr.c match... as dir.c patch makes use of the new functions without code duplication. The end result would be the same, except that we won't see this bug in attr.c's history. Not much value so if it may take a lot of your time, don't bother. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Planning to pass the baton to an interim maintainer
On Sun, Oct 14, 2012 at 11:23:07AM -0700, Junio C Hamano wrote: I am planning to * tag 1.8.0 final on Oct 21st (Sun); * go offline on Oct 22nd (Mon); and * come back online on Nov 12th (Mon). Peff, could you be the interim maintainer as you've done in earlier years while I was away? Sure, I look forward to ruling the list with an iron fist...er, helping contributors review their patches. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
