Re: [l10n] date: Note for translators not included in .po files
2014-04-17 6:51 GMT+08:00 Brian Gesiak modoca...@gmail.com: According to po/README, the l10n coordinator is responsible for updating the git.pot file. Would it be possible to update it based on v1.9.2 and include the above comment? I have pushed a polished git.pot to the maint branch of git-l10n/git-po. It's based on Git v1.9.2, and you can get it from: https://github.com/git-l10n/git-po/blob/maint/po/git.pot But if you want to translate for the upcoming Git v2.0.0, you can use git.pot in the pu branch as a template. See: https://github.com/git-l10n/git-po/blob/pu/po/git.pot By the way, I am trying to organize contributors to produce a Japanese localization for Core Git. Currently we have plenty of interest but only two contributors. If you or anyone you know would like to contribute please visit the repository here: https://github.com/modocache/git-po-ja Thanks! - Brian Gesiak -- 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 -- 蒋鑫 北京群英汇信息技术有限公司 邮件: worldhello@gmail.com 网址: http://www.ossxp.com/ 博客: http://www.worldhello.net/ 微博: http://weibo.com/gotgit/ 电话: 18601196889 -- 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] Unicode: update of combining code points
On 16/04/2014 22:58, Torsten Bögershausen wrote: Excellent, thanks for the pointers. Running the script below shows that 0X00AD SOFT HYPHEN should have zero length (and some others too). I wonder if that is really the case, and which one of the last 2 lines in the script is the right one. What does this mean for us: CfFormat a format control character Maybe dig back through the Git logs to check the original logic, but the comments suggest that Cf characters have been viewed as zero-width. That makes sense - they're usually markers indicating things like bidirectional text flow, so won't be taking space. (Although they may be causing even more extreme layout effects...) Soft-hyphen is noted as an explicit exception to the rule in the utf8.c comments. As of Unicode 4.0, it's supposed to be a character indicating a point where a hyphen could be placed if a line-wrap occurs, and if that wrap happens, then it can actually take up 1 space, otherwise not. So its width could be either 0 or 1, depending. Or, quite likely, the terminal doesn't treat it specially, and it always just looks like a hyphen... Thus we err on the safe side and give it width 1. See http://en.wikipedia.org/wiki/Soft_hyphen for background. The comments suggest adding -00AD +1160-11FF to the uniset command line for that tweak and for composing Hangul. (The +200B tweak isn't necessary any more - Zero-Width Space U+200B became Cf officially in Unicode 4.0.1: http://en.wikipedia.org/wiki/Zero-width_space http://www.unicode.org/review/resolved-pri.html#pri21 ) All of this is only really an approximation - a best-effort attempt to figure out the width of a string without any actual communication with the display device. So it'll never be perfect. The choice between double and single width in particular will often be unpredictable, unless you had deeper locale knowledge. Actually, while doing this, I've realised that this was originally Markus Kuhn's implementation, and that is acknowledged at the top of the file: http://www.cl.cam.ac.uk/~mgk25/ucs/wcwidth.c Good, because he knows what he's doing. Kevin -- 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: only look at the new parts of svn:mergeinfo
In a Subversion repository where many feature branches are merged into a
trunk, the svn:mergeinfo property can grow very large. This severely
slows down git-svn's make_log_entry() because it is checking all
mergeinfo entries every time the property changes.
In most cases, the additions to svn:mergeinfo since the last commit are
pretty small, and there is nothing to gain by checking merges that were
already checked for the last commit in the branch.
Add a mergeinfo_changes() function which computes the set of interesting
changes to svn:mergeinfo since the last commit. Filter out merged
branches whose ranges haven't changed, and remove a common prefix of
ranges from other merged branches.
This speeds up git svn fetch by several orders of magnitude on a large
repository where thousands of feature branches have been merged.
Signed-off-by: Jakob Stoklund Olesen stokl...@2pi.dk
---
perl/Git/SVN.pm | 84 -
1 file changed, 72 insertions(+), 12 deletions(-)
diff --git a/perl/Git/SVN.pm b/perl/Git/SVN.pm
index a59564f..d3785ab 100644
--- a/perl/Git/SVN.pm
+++ b/perl/Git/SVN.pm
@@ -1178,7 +1178,7 @@ sub find_parent_branch {
or die SVN connection failed somewhere...\n;
}
print STDERR Successfully followed parent\n unless $::_q 1;
- return $self-make_log_entry($rev, [$parent], $ed);
+ return $self-make_log_entry($rev, [$parent], $ed, $r0,
$branch_from);
}
return undef;
}
@@ -1210,7 +1210,7 @@ sub do_fetch {
unless ($self-ra-gs_do_update($last_rev, $rev, $self, $ed)) {
die SVN connection failed somewhere...\n;
}
- $self-make_log_entry($rev, \@parents, $ed);
+ $self-make_log_entry($rev, \@parents, $ed, $last_rev);
}
sub mkemptydirs {
@@ -1478,9 +1478,9 @@ sub find_extra_svk_parents {
sub lookup_svn_merge {
my $uuid = shift;
my $url = shift;
- my $merge = shift;
+ my $source = shift;
+ my $revs = shift;
- my ($source, $revs) = split :, $merge;
my $path = $source;
$path =~ s{^/}{};
my $gs = Git::SVN-find_by_url($url.$source, $url, $path);
@@ -1702,6 +1702,62 @@ sub parents_exclude {
return @excluded;
}
+# Compute what's new in svn:mergeinfo.
+sub mergeinfo_changes {
+ my ($self, $old_path, $old_rev, $path, $rev, $mergeinfo_prop) = @_;
+ my %minfo = map {split :, $_ } split \n, $mergeinfo_prop;
+ my $old_minfo = {};
+
+ # Initialize cache on the first call.
+ unless (defined $self-{cached_mergeinfo_rev}) {
+ $self-{cached_mergeinfo_rev} = {};
+ $self-{cached_mergeinfo} = {};
+ }
+
+ my $cached_rev = $self-{cached_mergeinfo_rev}{$old_path};
+ if (defined $cached_rev $cached_rev == $old_rev) {
+ $old_minfo = $self-{cached_mergeinfo}{$old_path};
+ } else {
+ my $ra = $self-ra;
+ # Give up if $old_path isn't in the repo.
+ # This is probably a merge on a subtree.
+ if ($ra-check_path($old_path, $old_rev) != $SVN::Node::dir) {
+ warn W: ignoring svn:mergeinfo on $old_path, ,
+ directory didn't exist in r$old_rev\n;
+ return {};
+ }
+ my (undef, undef, $props) =
+ $self-ra-get_dir($old_path, $old_rev);
+ if (defined $props-{svn:mergeinfo}) {
+ my %omi = map {split :, $_ } split \n,
+ $props-{svn:mergeinfo};
+ $old_minfo = \%omi;
+ }
+ $self-{cached_mergeinfo}{$old_path} = $old_minfo;
+ $self-{cached_mergeinfo_rev}{$old_path} = $old_rev;
+ }
+
+ # Cache the new mergeinfo.
+ $self-{cached_mergeinfo}{$path} = \%minfo;
+ $self-{cached_mergeinfo_rev}{$path} = $rev;
+
+ my %changes = ();
+ foreach my $p (keys %minfo) {
+ my $a = $old_minfo-{$p} || ;
+ my $b = $minfo{$p};
+ # Omit merged branches whose ranges lists are unchanged.
+ next if $a eq $b;
+ # Remove any common range list prefix.
+ ($a ^ $b) =~ /^[\0]*/;
+ my $common_prefix = rindex $b, ,, $+[0] - 1;
+ $changes{$p} = substr $b, $common_prefix + 1;
+ }
+ print STDERR Checking svn:mergeinfo changes since r$old_rev: ,
+ scalar(keys %minfo), sources, ,
+ scalar(keys %changes), changed\n;
+
+ return \%changes;
+}
# note: this function should only be called if the various dirprops
# have actually changed
@@ -1715,14 +1771,15 @@ sub find_extra_svn_parents {
# history. Then, we figure out which git revisions are in
# that tip, but not this revision. If all of those revisions
[PATCH 2/2] git-svn: only look at the root path for svn:mergeinfo
Subversion can put mergeinfo on any sub-directory to track cherry-picks.
Since cherry-picks are not represented explicitly in git, git-svn should
just ignore it.
Signed-off-by: Jakob Stoklund Olesen stokl...@2pi.dk
---
perl/Git/SVN.pm | 29 +
1 file changed, 13 insertions(+), 16 deletions(-)
diff --git a/perl/Git/SVN.pm b/perl/Git/SVN.pm
index d3785ab..0aa4dd3 100644
--- a/perl/Git/SVN.pm
+++ b/perl/Git/SVN.pm
@@ -1210,7 +1210,7 @@ sub do_fetch {
unless ($self-ra-gs_do_update($last_rev, $rev, $self, $ed)) {
die SVN connection failed somewhere...\n;
}
- $self-make_log_entry($rev, \@parents, $ed, $last_rev);
+ $self-make_log_entry($rev, \@parents, $ed, $last_rev, $self-path);
}
sub mkemptydirs {
@@ -1859,21 +1859,18 @@ sub make_log_entry {
my $untracked = $self-get_untracked($ed);
my @parents = @$parents;
- my $ps = $ed-{path_strip} || ;
- for my $path ( grep { m/$ps/ } %{$ed-{dir_prop}} ) {
- my $props = $ed-{dir_prop}{$path};
- if ( $props-{svk:merge} ) {
- $self-find_extra_svk_parents
- ($ed, $props-{svk:merge}, \@parents);
- }
- if ( $props-{svn:mergeinfo} ) {
- my $mi_changes = $self-mergeinfo_changes
- ($parent_path || $path, $parent_rev,
-$path, $rev,
-$props-{svn:mergeinfo});
- $self-find_extra_svn_parents
- ($ed, $mi_changes, \@parents);
- }
+ my $props = $ed-{dir_prop}{$self-path};
+ if ( $props-{svk:merge} ) {
+ $self-find_extra_svk_parents
+ ($ed, $props-{svk:merge}, \@parents);
+ }
+ if ( $props-{svn:mergeinfo} ) {
+ my $mi_changes = $self-mergeinfo_changes
+ ($parent_path, $parent_rev,
+$self-path, $rev,
+$props-{svn:mergeinfo});
+ $self-find_extra_svn_parents
+ ($ed, $mi_changes, \@parents);
}
open my $un, '', $self-{dir}/unhandled.log or croak $!;
--
1.8.5.2 (Apple Git-48)
--
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] tag: add -i and --introduced modifier for --contains
Junio C Hamano gits...@pobox.com writes: And you are right that the commit is contained in v3.4, so we also should be able to describe it as v3.4~479^2~9^2 as well. IMHO it should be described as v3.4-rc1~192^2~9^2, which is what git describe --contains --match=v3.4\* returns. This path is only a few commits longer than v3.5-rc1~120^3~76^2. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 And now for something completely different. -- 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
automatic submodule deinit (platform specific blacklist)
Hi all in our cross-platform projects we always have a certain Windows-only submodule, which contains all the compatibility stuff and missing libraries for Windows. When cloning such a repository on a Linux machine the typical procedure is: git clone git@server:project.git cd project git submodule init git submodule deinit path/to/windows-stuff git submodule update This way you avoid wasting time and disk space to clone stuff that you don't need on Linux (or on whatever non-windows machine your are actually working). It would be really cool to add a kind of platform specific submodule blacklist, either in .gitconfig or maybe even better in .gitattributes so that we can add this configuration to the repository. Example .gitattributes how this could look like: # common stuff *.sh eol=lf *.conf eol=lf # submodule config [src/windows-compat] platforms = win32 By default the platforms could have the value all. But one can change it to a list of platform names e.g. platforms = linux, macosx or win32 like in the example above. Such a feature would also make it possible to simply use git clone -- recursive git@server:project.git avoiding the single stops as shown above. What do your think? Is something like this possible? Or is it even possible already somehow? Today I'm using a shell script to automate this steps, but this is just a workaround. It would be cool if git itself could do this for us. -- mit freundlichen Grüßen / best regards Gerhard Gappmeier ascolab GmbH - automation systems communication laboratory Tel.: +49 9131 691 123 Fax: +49 9131 691 128 Web: http://www.ascolab.com GPG-KeyId: 5AAC50C4 GPG-Fingerprint: 967A 15F1 2788 164D CCA3 6C46 07CD 6F82 5AAC 50C4 -- ascolab GmbH Geschäftsführer: Gerhard Gappmeier, Matthias Damm, Uwe Steinkrauß Sitz der Gesellschaft: Am Weichselgarten 7 • 91058 Erlangen • Germany Registernummer: HRB 9360 Registergericht: Amtsgericht Fürth signature.asc Description: This is a digitally signed message part.
Re: [PATCH 001/14] howto-index.sh: use the $( ... ) construct for command substitution
Elia Pinto gitter.spi...@gmail.com writes: The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. For patches 1 to 14: Reviewed-by: Matthieu Moy matthieu@imag.fr (reviewed the patches in my mailer, and the diff --color-words=. after applying in addition) -- 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: [RFC] t7410: 210 tests for various 'git submodule update' scenarios
TL;DR: I believe the update-related submodule.name.* options
(.branch, .update, .url, and even the --remote option) are
slowly growing into a separate DSL for specfying how to update
submodules. This adds a confusing and opaque layer in front of
what is essentially git commands run by git submodule update
within the submodule. Instead of adding more submodule.name.*
options to handle even more use cases, we should scale back on
the config options, and allow the user to specify what should
happen on git submodule update in the existing language of
git commands.
On Wed, Apr 16, 2014 at 7:21 PM, W. Trevor King wk...@tremily.us wrote:
On Wed, Apr 16, 2014 at 02:54:48AM +0200, Johan Herland wrote:
This is a work-in-progress to flesh out (and promote discussion about)
the expected behaviors for all possible scenarios in which
'git submodule update' might be run.
This is lovely :).
Thanks!
Having been active in git-submodule development a few years ago,
I thought I had a fairly firm grasp of most details regarding
submodules, but when I recently tried to explain to someone how
git submodule update was supposed to work, I quickly found that
I had forgotten a lot, and that git-submodule had also changed.
After (albeit casually) reading the docs, I still didn't feel much
wiser, and this humongous testcase is sort of my ultimate attempt
to regain some understanding.
So far, my impression is that there are too many details/variables
and too much state to be able to sanely comprehend what is the intended
behavior in all cases, much less document in a way that is approachable
to regular users...
+# - current state of submodule:
+# ?.?.?.1 - not yet cloned
+# ?.?.?.2 - cloned, detached, HEAD == gitlink
+# ?.?.?.3 - cloned, detached, HEAD != gitlink
+# ?.?.?.4 - cloned, on branch foo (exists upstream), HEAD == gitlink
+# ?.?.?.5 - cloned, on branch foo (exists upstream), HEAD != gitlink
+# ?.?.?.6 - cloned, on branch bar (MISSING upstream), HEAD == gitlink
+# ?.?.?.7 - cloned, on branch bar (MISSING upstream), HEAD != gitlink
The remote branches should only matter for the initial clone and
--remote updates. Also, only the configured submodule.name.branch
(your first axis) should be checked; the locally checked-out submodule
branch shouldn't matter.
Yes, I realized that while working out the various cases, but it was
not at all obvious from the start, given that the config option is
called submodule.name.branch and not submodule.name.upstream or
similar (which might prevent a casual user from misinterpreting the
option as having something to do with the current local branch in the
submodule). See D6 for more discussion about the naming of .branch.
In general, I experimented with a few different ways of organizing the
axes to get a flow of testcases that more naturally revealed the
behavior of git submodule update, but I haven't found a good
organization, yet. I suspect there is none...
+# T2: Test with submodule.name.url != submodule's remote.origin.url. Does
+# submodule update --remote sync with submodule.name.url, or with
the
+# submodule's origin? (or with the submodule's current branch's
upstream)?
All fetches should currently use the submodule's remote.origin.url.
submodule.name.url is only used for the initial clone (*.*.*.1), and
never referenced again. This would change using my tightly-bound
submodule proposal [1], where a difference between
submodule.name.url and the submodule's @{upstream} URL would be
trigger a dirty-tree condition (for folks with tight-bind syncing
enabled) from which you couldn't update before resolving the
difference.
Ok. As stated above, I am worried about the amount of duplicated
state between the superproject's submodule config (which itself is
split between .gitmodules and .git/config) and the submodule's own
config. And from the above paragraph, I suspect two more dimensions
need to be added to the test matrix:
- submodule's remote.origin.url ==/!= submodule.name.url
- tightly-bound submodule is enabled/disabled
Even if we might successfully deal with the duplicate state (and the
exploding test matrix), it will certainly not be easy to
describe/document the intended behavior in a way that's simple to
grasp and straightforward to use.
We should instead seek ways to minimize the duplication of state.
If it is indeed the case that several submodule.name.* values in the
superproject are only consulted _once_ (when cloning the submodule),
we should make it obvious that they will not be used after the clone
is done. Similarly, we should make it obvious that the update-related
options only apply exactly when git submodule update is run.
What about something like this:
- submodule.name.create: The command that will be used by
git submodule update to initially populate the contents of
the submodule. The command is run from within the submodule
directory, and the following environment variables
[PATCH v2] utf8.c: partially update to version 6.3
Unicode 6.3 defines more code points as combining or accents. For
example, the character ö could be expressed as an o followed by
U+0308 COMBINING DIARESIS (aka umlaut, double-dot-above). We should
consider that such a sequence of two codepoints occupies one display
column for the alignment purposes, and for that, git_wcwidth()
should return 0 for them.
The following script has been used to generate the combining table
in git_wcwidth():
#!/bin/sh
URLBASE=http://www.unicode.org/Public/UCD/latest/ucd
if ! test -f UnicodeData.txt; then
wget $URLBASE/UnicodeData.txt
fi
if ! test -f EastAsianWidth.txt; then
wget $URLBASE/EastAsianWidth.txt
fi
if ! test -d uniset; then
mkdir uniset
fi
if ! test -e Blocks.txt; then
ln -s uniset/Blocks.txt
fi
(
cd uniset
if ! test -f uniset.tar.gz; then
wget http://www.cl.cam.ac.uk/~mgk25/download/uniset.tar.gz
fi
if ! test -f uniset; then
tar xzf uniset.tar.gz
fi
)
./uniset/uniset +cat=Me +cat=Mn +cat=Cf -00AD +1160-11FF +200B c
Helped-by: Kevin Bracey ke...@bracey.fi
Signed-off-by: Torsten Bögershausen tbo...@web.de
---
utf8.c | 116 ++---
1 file changed, 76 insertions(+), 40 deletions(-)
diff --git a/utf8.c b/utf8.c
index 0d20e0a..3a8c282 100644
--- a/utf8.c
+++ b/utf8.c
@@ -84,48 +84,84 @@ static int git_wcwidth(ucs_char_t ch)
* uniset +cat=Me +cat=Mn +cat=Cf -00AD +1160-11FF +200B c.
*/
static const struct interval combining[] = {
- { 0x0300, 0x0357 }, { 0x035D, 0x036F }, { 0x0483, 0x0486 },
- { 0x0488, 0x0489 }, { 0x0591, 0x05A1 }, { 0x05A3, 0x05B9 },
- { 0x05BB, 0x05BD }, { 0x05BF, 0x05BF }, { 0x05C1, 0x05C2 },
- { 0x05C4, 0x05C4 }, { 0x0600, 0x0603 }, { 0x0610, 0x0615 },
- { 0x064B, 0x0658 }, { 0x0670, 0x0670 }, { 0x06D6, 0x06E4 },
- { 0x06E7, 0x06E8 }, { 0x06EA, 0x06ED }, { 0x070F, 0x070F },
- { 0x0711, 0x0711 }, { 0x0730, 0x074A }, { 0x07A6, 0x07B0 },
- { 0x0901, 0x0902 }, { 0x093C, 0x093C }, { 0x0941, 0x0948 },
- { 0x094D, 0x094D }, { 0x0951, 0x0954 }, { 0x0962, 0x0963 },
- { 0x0981, 0x0981 }, { 0x09BC, 0x09BC }, { 0x09C1, 0x09C4 },
- { 0x09CD, 0x09CD }, { 0x09E2, 0x09E3 }, { 0x0A01, 0x0A02 },
- { 0x0A3C, 0x0A3C }, { 0x0A41, 0x0A42 }, { 0x0A47, 0x0A48 },
- { 0x0A4B, 0x0A4D }, { 0x0A70, 0x0A71 }, { 0x0A81, 0x0A82 },
+ { 0x0300, 0x036F }, { 0x0483, 0x0489 }, { 0x0591, 0x05BD },
+ { 0x05BF, 0x05BF }, { 0x05C1, 0x05C2 }, { 0x05C4, 0x05C5 },
+ { 0x05C7, 0x05C7 }, { 0x0600, 0x0604 }, { 0x0610, 0x061A },
+ { 0x061C, 0x061C }, { 0x064B, 0x065F }, { 0x0670, 0x0670 },
+ { 0x06D6, 0x06DD }, { 0x06DF, 0x06E4 }, { 0x06E7, 0x06E8 },
+ { 0x06EA, 0x06ED }, { 0x070F, 0x070F }, { 0x0711, 0x0711 },
+ { 0x0730, 0x074A }, { 0x07A6, 0x07B0 }, { 0x07EB, 0x07F3 },
+ { 0x0816, 0x0819 }, { 0x081B, 0x0823 }, { 0x0825, 0x0827 },
+ { 0x0829, 0x082D }, { 0x0859, 0x085B }, { 0x08E4, 0x08FE },
+ { 0x0900, 0x0902 }, { 0x093A, 0x093A }, { 0x093C, 0x093C },
+ { 0x0941, 0x0948 }, { 0x094D, 0x094D }, { 0x0951, 0x0957 },
+ { 0x0962, 0x0963 }, { 0x0981, 0x0981 }, { 0x09BC, 0x09BC },
+ { 0x09C1, 0x09C4 }, { 0x09CD, 0x09CD }, { 0x09E2, 0x09E3 },
+ { 0x0A01, 0x0A02 }, { 0x0A3C, 0x0A3C }, { 0x0A41, 0x0A42 },
+ { 0x0A47, 0x0A48 }, { 0x0A4B, 0x0A4D }, { 0x0A51, 0x0A51 },
+ { 0x0A70, 0x0A71 }, { 0x0A75, 0x0A75 }, { 0x0A81, 0x0A82 },
{ 0x0ABC, 0x0ABC }, { 0x0AC1, 0x0AC5 }, { 0x0AC7, 0x0AC8 },
{ 0x0ACD, 0x0ACD }, { 0x0AE2, 0x0AE3 }, { 0x0B01, 0x0B01 },
- { 0x0B3C, 0x0B3C }, { 0x0B3F, 0x0B3F }, { 0x0B41, 0x0B43 },
- { 0x0B4D, 0x0B4D }, { 0x0B56, 0x0B56 }, { 0x0B82, 0x0B82 },
- { 0x0BC0, 0x0BC0 }, { 0x0BCD, 0x0BCD }, { 0x0C3E, 0x0C40 },
- { 0x0C46, 0x0C48 }, { 0x0C4A, 0x0C4D }, { 0x0C55, 0x0C56 },
- { 0x0CBC, 0x0CBC }, { 0x0CBF, 0x0CBF }, { 0x0CC6, 0x0CC6 },
- { 0x0CCC, 0x0CCD }, { 0x0D41, 0x0D43 }, { 0x0D4D, 0x0D4D },
- { 0x0DCA, 0x0DCA }, { 0x0DD2, 0x0DD4 }, { 0x0DD6, 0x0DD6 },
- { 0x0E31, 0x0E31 }, { 0x0E34, 0x0E3A }, { 0x0E47, 0x0E4E },
- { 0x0EB1, 0x0EB1 }, { 0x0EB4, 0x0EB9 }, { 0x0EBB, 0x0EBC },
- { 0x0EC8, 0x0ECD }, { 0x0F18, 0x0F19 }, { 0x0F35, 0x0F35 },
- { 0x0F37, 0x0F37 }, { 0x0F39, 0x0F39 }, { 0x0F71, 0x0F7E },
- { 0x0F80, 0x0F84 }, { 0x0F86, 0x0F87 }, { 0x0F90, 0x0F97 },
- { 0x0F99, 0x0FBC }, { 0x0FC6, 0x0FC6 }, { 0x102D, 0x1030 },
- { 0x1032, 0x1032 }, { 0x1036, 0x1037 }, {
Re: [PATCH v2] utf8.c: partially update to version 6.3
On 17/04/2014 14:47, Torsten Bögershausen wrote: ./uniset/uniset +cat=Me +cat=Mn +cat=Cf -00AD +1160-11FF +200B c 200B isn't a special case any more, as its database properties have been changed, so you can slightly simplify this command (both in the commit message and the comments). And while you're here I think it's probably worth updating the width=2 test now too, to make this a complete update to Unicode 6.3. I can see it needs a few extensions (eg A960-A97C, FE10-FE19, 1F200-1F251). Kevin -- 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] t7410: 210 tests for various 'git submodule update' scenarios
On Thu, Apr 17, 2014 at 01:42:42PM +0200, Johan Herland wrote:
+# T2: Test with submodule.name.url != submodule's remote.origin.url.
Does
+# submodule update --remote sync with submodule.name.url, or with
the
+# submodule's origin? (or with the submodule's current branch's
upstream)?
All fetches should currently use the submodule's remote.origin.url.
submodule.name.url is only used for the initial clone (*.*.*.1), and
never referenced again. This would change using my tightly-bound
submodule proposal [1], where a difference between
submodule.name.url and the submodule's @{upstream} URL would be
trigger a dirty-tree condition (for folks with tight-bind syncing
enabled) from which you couldn't update before resolving the
difference.
Ok. As stated above, I am worried about the amount of duplicated
state between the superproject's submodule config (which itself is
split between .gitmodules and .git/config) and the submodule's own
config. And from the above paragraph, I suspect two more dimensions
need to be added to the test matrix:
- submodule's remote.origin.url ==/!= submodule.name.url
- tightly-bound submodule is enabled/disabled
Tight-binding hasn't been implemented yet, or even accumulated much
support from other folks ;). However, the idea is to unify the state
between the superproject's .gitmodules and .git/config and the
submodule's .git/config (or ../.git/modules/name/config, or
whatever). Then folks with tightly-bound syncing enabled have only
one state space to maintain (and get auto-updates for each
superproject checkout), and folks who opt-out of tightly-bound syncing
are presumably embracing the complexity of our current system, with
it's two, confusingly-aligned configuration spaces.
I'm happy to force syncing (i.e. no opting-out allowed) [1], but I
imagine there are folks who would resist ;). Maybe a deprecation
period to help ease the transition? This is all assuming that I get
more folks to buy into the tight-syncing ;).
The end-goal of my tightly-bound approach is to remove 'submodule
update' altogether and end up with a simpler interface [2]:
On Sat, Jan 11, 2014 at 05:08:47PM -0800, W. Trevor King wrote:
* git submodule [--quiet] add [-b branch] [-f|--force] [--name name]
[--reference repository] [--] repository [path]
* git submodule [--quiet] init [--] [path...]
* git submodule [--quiet] deinit [-f|--force] [--] path...
* git submodule [--quiet] foreach [--recursive] command
All of this 'submodule update' integration confusion would be resolved
by the developer who updated the gitlink, and superproject checkouts
would just swap the local submodule branch/HEAD without having to
worry about clobbering uncommitted state.
On Thu, Apr 17, 2014 at 01:42:42PM +0200, Johan Herland wrote:
We should instead seek ways to minimize the duplication of state.
The tightly-bound-submodules I'm proposing try to use the submodule's
config settings (plus submodule.name.local-branch) as the familiar
language, while your proposal uses Git commands as the familiar
language. I think both would work, but config settings are easier to
parse automatically, which helps with automatically syncing between
the superproject and submodule configs. Syncing, in turn, helps
bridge the gap between the easily shared superproject/.gitmodules and
superproject/.git/modules/name/config (enabling familiar-to-use Git
commands in the submodule).
- submodule.name.create: …
Syncing submodule state back up into this is going to be a manual
operation. For example, changing the submodule's remote.origin.url is
going to require hand-tweaking to update this setting.
- submodule.name.update: …
…
- 'git reset --hard $GITLINK'
Equivalent to checkout-mode (without --remote).
- 'git fetch git reset --hard origin/HEAD'
Equivalent to checkout-mode with --remote.
Folks who sometimes use --remote updates will still need non-remote
updates. For example, if Alice and Bob are both developers on the
same superproject:
alice$ git submodule update --recursive --remote # integrate upstream changes
alice$ git commit -m 'Bumped submodules to upstream tips'
alice$ git push
bob$ git pull
bob$ git submodule update --recursive # integrate Alice's gitlink changes
so it should be easy to toggle back and forth between the two
integration targets. However:
git fetch git reset --hard origin/HEAD
is easy to run using 'git submodule foreach', or after changing into
the submodule directory, so I'm not particularly concerned here.
With tight-binding and superproject-checkout-time auto-updates, the
above would be:
alice$ git submodule foreach --recursive 'git pull'
alice$ git commit -m 'Bumped submodules to upstream tips'
alice$ git push
bob$ git pull # update to Alice's new gitlinks happens automatically
Another problem with a single submodule.name.update is if I want to
pull origin/HEAD into my
Re: automatic submodule deinit (platform specific blacklist)
Am 17.04.2014 10:02, schrieb Gerhard Gappmeier: Hi all in our cross-platform projects we always have a certain Windows-only submodule, which contains all the compatibility stuff and missing libraries for Windows. When cloning such a repository on a Linux machine the typical procedure is: git clone git@server:project.git cd project git submodule init git submodule deinit path/to/windows-stuff git submodule update This way you avoid wasting time and disk space to clone stuff that you don't need on Linux (or on whatever non-windows machine your are actually working). It would be really cool to add a kind of platform specific submodule blacklist, either in .gitconfig or maybe even better in .gitattributes so that we can add this configuration to the repository. Example .gitattributes how this could look like: # common stuff *.sh eol=lf *.conf eol=lf # submodule config [src/windows-compat] platforms = win32 By default the platforms could have the value all. But one can change it to a list of platform names e.g. platforms = linux, macosx or win32 like in the example above. Such a feature would also make it possible to simply use git clone -- recursive git@server:project.git avoiding the single stops as shown above. What do your think? Is something like this possible? Or is it even possible already somehow? Today I'm using a shell script to automate this steps, but this is just a workaround. It would be cool if git itself could do this for us. What about setting submodule.name.update to none in the config of your non-Windows machines? Then they would be initialized (= the URL setting gets copied to .git/config) but never checked out. -- 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] [RFC/PATCH 2/4] Submodules: Add the lib-submodule-update.sh test library
On Tue, Mar 25, 2014 at 06:05:05PM +0100, Jens Lehmann wrote: *) When a submodule is replaced with a tracked file of the same name the submodule work tree including any local modifications (and even the whole history if it uses a .git directory instead of a gitfile!) is simply removed. … I think the first bug really needs to be fixed, as that behavior is extremely nasty. We should always protect work tree modifications (unless forced) and *never* remove a .git directory (even when forced). I think this should be covered by the usual “don't allow checkouts from dirty workdirs unless the dirty-ing changes are easily applied to the target tree”. Are we waiting to land this series (or a successor) before starting on a fix for this issue? There have been a number of submodule series in flight recently, and I'm having trouble keeping track of them all ;). *) Forced work tree updates happily manipulate files in the directory of a submodule that has just been removed in the superproject (but is of course still present in the work tree due to the way submodules are currently handled). This becomes dangerous when files in the submodule directory are overwritten by files from the new superproject commit, as any modifications to the submodule files will be lost) and is expected to also destroy history in the - admittedly unlikely case - the new commit adds a file named .git to the submodule directory. … I'm not so sure about the second one. Even though I believe the current behavior is not correct (switching commits should never mess around in a submodule directory) This should also be covered by the usual “don't allow checkouts from dirty workdirs unless the dirty-ing changes are easily applied to the target tree”. We don't implement this yet, but I'd like to force users to move any about-to-be-clobbered state from their submodule into .git/modules/name/ (via commits or stashes) before allowing them to begin the checkout. Once we've ensured that the state is preserved out-of-tree, then clobber away ;). Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [git] What's cooking in git.git (Apr 2014, #03; Fri, 11)
On Fri, Apr 11, 2014 at 03:22:58PM -0700, Junio C Hamano wrote: * jl/submodule-recursive-checkout (2013-12-26) 5 commits - Teach checkout to recursively checkout submodules - submodule: teach unpack_trees() to update submodules - submodule: teach unpack_trees() to repopulate submodules - submodule: teach unpack_trees() to remove submodule contents - submodule: prepare for recursive checkout of submodules Expecting a reroll. I think this was rerolled with Jens' v2 [1]: * jl/submodule-recursive-checkout (2014-02-03) 9 commits - submodule: prepare for recursive checkout of submodules - Teach reset the --[no-]recurse-submodules option - Teach checkout the --[no-]recurse-submodules option - Teach merge the --[no-]recurse-submodules option - Teach bisect--helper the --[no-]recurse-submodules option - Teach bisect the --[no-]recurse-submodules option - submodule: teach unpack_trees() to remove submodule contents - submodule: teach unpack_trees() to repopulate submodules - submodule: teach unpack_trees() to update submodules Cheers, Trevor [1]: http://thread.gmane.org/gmane.comp.version-control.git/241455 -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [PATCH] tag: add -i and --introduced modifier for --contains
Luis R. Rodriguez mcg...@do-not-panic.com writes: And between v3.4 and v3.5-rc1, the latter is a closer anchor point for that commit (v3.5-rc1 only needs about 200 hops to reach the commit, while from v3.4 you would need close to 500 hops), Ah! Thanks for explaining this mysterious puzzle to me. I'm a bit perplexed why still. Can I trouble you for a little elaboration here? How could one view from a commit merged on v3.4 possibly yield more commits to v3.4 than to v3.5 ? Is it because it starts counting on the merge's parent (v3.3) ? The reason is very simple, once you realize that in a distributed environment it is very common to fork off a new branch from an ancient commit and then merging the result to a newer release without merging it all the way down to older maintenance releases. Try this sequence: 1. start from say v3.4~1^2~2 $ git checkout -b side v3.4~1^2~2 The history near v3.4 proper looks like this: $ git log --oneline -3 v3.4 76e10d1 Linux 3.4 d6c77973 Merge tag 'parisc-fixes' of git://git.kernel.o... 5d12045 Merge branch 'x86/ld-fix' of git://git.kernel.o... and the last merge before v3.4 brings three commits in to the history: $ git log --oneline d6c77973^1..d6c77973^2 b3cb867 [PARISC] fix panic on prefetch(NULL) on PA7300LC 207f583 [PARISC] fix crash in flush_icache_page_asm on PA1.1 5e18558 [PARISC] fix PA1.1 oops on boot We just forked a new side branch off of the bottom one (5e18558). 2. pretend a new development on this old codebase $ git commit --allow-empty -m [PARISC] another 3. let's merge this to v3.5 and call the result v9.0 $ git checkout v3.5 $ git merge --no-edit side $ git tag -a -m 'Nine' v9.0 Think what just happened to v3.4~1^2~2, the fork-point of this new side branch (I am not asking what *should* happen. This exercise is only to illustrate how the commit v3.5-rc1~120^3~76^2 can be closer to v3.5-rc1 than to v3.4 when it is reachable from both). Here is how the topology looks like: v3.4 v9.0 ---M---X-Y / / ---A---B---C / \ / --D (side) where X is v3.4, M is d6c77973, A thru C are the PARISC patches, D is the another, and Y is the phoney version Nine we just made. We are trying to describe --contains commit A. If you start counting from the new tag v9.0, it is on the merged side branch that brought in one new commit D, and in fact it is the direct parent of it, so even without asking describe --contains, we know that it is v9.0^2~1. That is 2 hops from v9.0 tag. If you count from v3.4, it is 4 hops. And both of these tags X and Y contain the commit A. Now, as to what *SHOULD* happen, I think the above exercise shows us a way to define what the desired semantics is, without resorting to heuristics (e.g. which tag has older timestamp? or which tag's name sorts older under Linux version naming convention?). Commit A can be described in terms of both v3.4 and v9.0, and it may be closer to v9.0 than v3.4, and under that definition we pick the closest tag, the current describe --contains behaviour may be correct, but from the human point of view, it is *WRONG*. It is wrong because v9.0 can reach v3.4. So perhaps the rule should be updated to do something like: - find candidate tags that can be used to describe --contains the commit A, yielding v3.4, v3.5 (not shown), and v9.0; - among the candidate tags, cull the ones that contain another candidate tag, rejecting v3.5 (not shown) and v9.0; - among the surviving tags, pick the closest. Hmm? -- 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] tag: add -i and --introduced modifier for --contains
Andreas Schwab sch...@suse.de writes: Junio C Hamano gits...@pobox.com writes: And you are right that the commit is contained in v3.4, so we also should be able to describe it as v3.4~479^2~9^2 as well. IMHO it should be described as v3.4-rc1~192^2~9^2, which is what git describe --contains --match=v3.4\* returns. This path is only a few commits longer than v3.5-rc1~120^3~76^2. Sure. In my response to Luis, I assumed that rc tags are not as desirable as the final release points for his purpose for whatever reason, as Luis compared between v3.4 and v3.5-rc1~120^3~76^2, not with v3.4-rc1 or any later rc. I also think this illustrates my earlier point. Depending on the project and the expectation of the users, which tags are good candidates as anchor points differ. Your example using --match probably shows a good direction to go in---somehow tell Git which tags to base the description on, to reject names that the users do not want. When your project does not mind basing the description on rc tags, between v3.4-rc1~192^2~9^2 and v3.5-rc1~120^3~76^2, I am not sure if we would want to say that the former is not so longer than the latter, so use that, or what kind of heuristics to employ to reach that conclusion. Date-based selection (i.e. earliest first) is one possibility. Tagname-based selection has the issue of having to configure whose version numbering convention would you use when sorting tags, and how you would tell Git that sorting order rule? For a possible cleaner alternative semantics, see the other message I just sent to the thread. 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 1/3] rebase: avoid non-function use of return on FreeBSD
Kyle J. McKay mack...@gmail.com writes:
Either return to the function that dot-sourced us or return from
the dot command that dot-sourced us,
but using the original wording
implies to me that the function that dot-sourced us will return as
soon as the dot-sourced script executes the return and that is exactly
one of the bugs we're working around.
True. return to the function that dot-sourced us is what I meant.
To be more pedantic, return to the point in the function that
dot-sourced this file.
I think just the s/from/to/ would fix it so it does not give me the
wrong impression, but that doesn't mean that would not confuse
everyone else. ;)
Yeah, let's do that. Thanks for carefully reading them.
So while this is allowed by POSIX may be a bit misleading and
needs to be reworded, I guess?
allowed by POSIX is not incorrect. ;)
Calling something that is required as allowed is a bit misleading,
if not outright dishonest. Allowed implies that you are free not to
do so and can still be in compliance, but I do not think that is the
case.
I'd think it makes it clearer to say that we take return stopping
the dot-sourced file as a given and FreeBSD does not behave that
way.
-- 8 --
From: Kyle J. McKay mack...@gmail.com
Date: Fri, 11 Apr 2014 01:28:17 -0700
Subject: [PATCH] rebase: avoid non-function use of return on FreeBSD
Since a1549e10, 15d4bf2e and 01a1e646 (first appearing in v1.8.4)
the git-rebase--*.sh scripts have used a return to stop execution
of the dot-sourced file and return to the dot command that
dot-sourced it. The /bin/sh utility on FreeBSD however behaves
poorly under some circumstances when such a return is executed.
In particular, if the dot command is contained within a function,
then when a return is executed by the script it runs (that is not
itself inside a function), control will return from the function
that contains the dot command skipping any statements that might
follow the dot command inside that function. Commit 99855ddf (first
appearing in v1.8.4.1) addresses this by making the dot command
the last line in the function.
Unfortunately the FreeBSD /bin/sh may also execute some statements
in the script run by the dot command that appear after the
troublesome return. The fix in 99855ddf does not address this
problem.
For example, if you have script1.sh with these contents:
run_script2() {
. $(dirname -- $0)/script2.sh
_e=$?
echo only this line should show
[ $_e -eq 5 ] || echo expected status 5 got $_e
return 3
}
run_script2
e=$?
[ $e -eq 3 ] || { echo expected status 3 got $e; exit 1; }
And script2.sh with these contents:
if [ 5 -gt 3 ]; then
return 5
fi
case bad in *)
echo always shows
esac
echo should not get here
! :
When running script1.sh (e.g. '/bin/sh script1.sh' or './script1.sh'
after making it executable), the expected output from a POSIX shell
is simply the single line:
only this line should show
However, when run using FreeBSD's /bin/sh, the following output
appears instead:
should not get here
expected status 3 got 1
Not only did the lines following the dot command in the run_script2
function in script1.sh get skipped, but additional lines in script2.sh
following the return got executed -- but not all of them (e.g. the
echo always shows line did not run).
These issues can be avoided by not using a top-level return in
script2.sh. If script2.sh is changed to this:
main() {
if [ 5 -gt 3 ]; then
return 5
fi
case bad in *)
echo always shows
esac
echo should not get here
! :
}
main
Then it behaves the same when using FreeBSD's /bin/sh as when using
other more POSIX compliant /bin/sh implementations.
We fix the git-rebase--*.sh scripts in a similar fashion by moving
the top-level code that contains return statements into its own
function and then calling that as the last line in the script.
Signed-off-by: Kyle J. McKay mack...@gmail.com
Acked-by: Matthieu Moy matthieu@imag.fr
Signed-off-by: Junio C Hamano gits...@pobox.com
---
git-rebase--am.sh | 15 +++
git-rebase--interactive.sh | 15 +++
git-rebase--merge.sh | 15 +++
3 files changed, 45 insertions(+)
diff --git a/git-rebase--am.sh b/git-rebase--am.sh
index a4f683a..1cdc139 100644
--- a/git-rebase--am.sh
+++ b/git-rebase--am.sh
@@ -4,6 +4,17 @@
# Copyright (c) 2010 Junio C Hamano.
#
+# The whole contents of this file is run by dot-sourcing it from
+# inside a shell function. It used to be that returns we see
+# below were not inside any function, and expected to return
+# to the function that dot-sourced us.
+#
+# However, FreeBSD /bin/sh misbehaves on such a construct and
+# continues to run the statements that follow such a return.
+# As a work-around, we introduce an extra layer of a function
+# here, and immediately call it after defining it.
+git_rebase__am () {
+
case $action in
Re: [PATCH] tag: add -i and --introduced modifier for --contains
Junio C Hamano gits...@pobox.com writes: I also think this illustrates my earlier point. Depending on the project and the expectation of the users, which tags are good candidates as anchor points differ. Your example using --match probably shows a good direction to go in---somehow tell Git which tags to base the description on, to reject names that the users do not want. I've used --match only to force git describe to find a better match. When your project does not mind basing the description on rc tags, between v3.4-rc1~192^2~9^2 and v3.5-rc1~120^3~76^2, I am not sure if we would want to say that the former is not so longer than the latter, so use that, or what kind of heuristics to employ to reach that conclusion. Date-based selection (i.e. earliest first) is one possibility. Tagname-based selection has the issue of having to configure whose version numbering convention would you use when sorting tags, and how you would tell Git that sorting order rule? IMHO git should select based on topology: the first tag that isn't contained in any other tag still containing the commit in question, only when ambigous it needs to fall back to other criteria. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. -- 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] git tag --contains : avoid stack overflow
Hi Peff,
On Wed, 16 Apr 2014, Jeff King wrote:
On Wed, Apr 16, 2014 at 04:15:19PM +0200, Stepan Kasal wrote:
From: Jean-Jacques Lafay at Sat, 10 Nov 2012 18:36:10 +0100
In large repos, the recursion implementation of contains(commit,
commit_list) may result in a stack overflow. Replace the recursion
with a loop to fix it.
This problem is more apparent on Windows than on Linux, where the
stack is more limited by default.
I think this is a good thing to be doing, and it looks mostly good to
me. A few comments:
-static int contains_recurse(struct commit *candidate,
+/*
+ * Test whether the candidate or one of its parents is contained in the
list.
+ * Do not recurse to find out, though, but return -1 if inconclusive.
+ */
+static int contains_test(struct commit *candidate,
const struct commit_list *want)
Can we turn this return value into
enum {
CONTAINS_UNKNOWN = -1,
CONTAINS_NO = 0,
CONTAINS_YES = 1,
} contains_result;
to make the code a little more self-documenting?
Good idea!
[... detailed instructions what changes are implied by the enum ...]
+expect
+# ulimit is a bash builtin; we can rely on that in MinGW, but nowhere else
+test_expect_success MINGW '--contains works in a deep repo' '
+ ulimit -s 64
It would be nice to test this on Linux.
Can we do something like:
test_lazy_prereq BASH 'bash --version'
test_expect_success BASH '--contains works in a deep repo' '
... setup repo ...
bash -c ulimit -s 64 git tag --contains HEAD actual
test_cmp expect actual
'
As a bonus, then our ulimit call does not pollute the environment of
subsequent tests.
That's a very good idea! We mulled it over a bit and did not come up with
this excellent solution.
Please see https://github.com/msysgit/git/c63d196 for the fixup, and
https://github.com/msysgit/git/compare/tag-contains%5E...tag-contains for
the updated patch.
Thanks,
Dscho
--
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] Update SVN.pm
Stepan Kasal ka...@ucw.cz writes: On Wed, Apr 16, 2014 at 12:13:21PM -0700, Junio C Hamano wrote: Interesting. What other strange forms can they record in their repositories, I have to wonder. Can they do 2014-01-07T5:8:6.048176Z for example? Roman Belinsky, the author of this fix, witnessed after large scale conversion that the problem happens with the hour part only. Is this large scale conversion done from a SVN repository that is created by bog standard SVN, or something else? How certain are we that this hour part is broken is the only kind of breakage in timestamps we would encouter? What I am trying to get at is that we didn't see any breakage at positions other than hour part after checking 2 million commits is different from there will no breakage at positions other than hour part, and by being slightly more lenient than necessary to cover one observed case that triggered the patch, we can cover SVN repositories broken in a similar but slightly different way. Especially given that this regexp matching is not used for finding a timestamp from random places but to parse out the datum we find at a place where we expect to see a timestamp (check the callers), I think loosening to allow single-digit minutes and seconds in the same commit that allows single-digit hours would be such slightly more lenient than necessary change without additional risk of mistaking something that is not a timestamp as a timestamp. 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: What's cooking in git.git (Apr 2014, #03; Fri, 11)
W. Trevor King wk...@tremily.us writes: On Fri, Apr 11, 2014 at 03:22:58PM -0700, Junio C Hamano wrote: * jl/submodule-recursive-checkout (2013-12-26) 5 commits - Teach checkout to recursively checkout submodules - submodule: teach unpack_trees() to update submodules - submodule: teach unpack_trees() to repopulate submodules - submodule: teach unpack_trees() to remove submodule contents - submodule: prepare for recursive checkout of submodules Expecting a reroll. I think this was rerolled with Jens' v2 [1]: * jl/submodule-recursive-checkout (2014-02-03) 9 commits - submodule: prepare for recursive checkout of submodules - Teach reset the --[no-]recurse-submodules option - Teach checkout the --[no-]recurse-submodules option - Teach merge the --[no-]recurse-submodules option - Teach bisect--helper the --[no-]recurse-submodules option - Teach bisect the --[no-]recurse-submodules option - submodule: teach unpack_trees() to remove submodule contents - submodule: teach unpack_trees() to repopulate submodules - submodule: teach unpack_trees() to update submodules Cheers, Trevor [1]: http://thread.gmane.org/gmane.comp.version-control.git/241455 Thanks, I'll add a reference to the RFC v2, but it also had significant discussion threads on it, so it would still be in Expecting a reroll state anyway. -- 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] Update SVN.pm
Stepan Kasal ka...@ucw.cz writes:
From: RomanBelinsky belinsky.ro...@gmail.com
Date: Tue, 11 Feb 2014 18:23:02 +0200
fix parsing error for dates like:
2014-01-07T5:58:36.048176Z
previous regex can parse only:
2014-01-07T05:58:36.048176Z
reproduced in my svn repository during conversion.
Signed-off-by: Stepan Kasal ka...@ucw.cz
---
Two niggles.
- The Subject line is not descriptive enough to let readers of git
shortlog know what this change is about.
- Can we have the patch signed-off by the author?
For the first point, I'd suggest rewriting the proposed commit
message like this (this is what I came up with after reading that
msysgit discussion page you referred to in the other message):
--
SVN.pm::parse_svn_date: allow timestamps with a single-digit hour
Some broken subversion server gives timestamps with only one digit
in the hour part, like this:
2014-01-07T5:58:36.048176Z
Loosen the regexp that expected to see two-digit hour, minute and
second parts to accept a single-digit hour (but not minute or
second).
Signed-off-by: Stepan Kasal ka...@ucw.cz
--
perl/Git/SVN.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/perl/Git/SVN.pm b/perl/Git/SVN.pm
index a59564f..09cff13 100644
--- a/perl/Git/SVN.pm
+++ b/perl/Git/SVN.pm
@@ -1321,7 +1321,7 @@ sub get_untracked {
sub parse_svn_date {
my $date = shift || return '+ 1970-01-01 00:00:00';
my ($Y,$m,$d,$H,$M,$S) = ($date =~ /^(\d{4})\-(\d\d)\-(\d\d)T
- (\d\d)\:(\d\d)\:(\d\d)\.\d*Z$/x) or
+ (\d\d?)\:(\d\d)\:(\d\d)\.\d*Z$/x) or
croak Unable to parse date: $date\n;
my $parsed_date;# Set next.
--
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/3] i18n: Only extract comments marked by special tag
Jiang Xin worldhello@gmail.com writes:
When extract l10n messages, we use --add-comments option to keep
comments right above the l10n messages for references. But sometimes
irrelevant comments are also extracted. For example in the following
code block, the comment in line 2 will be extracted as comment for the
l10n message in line 3, but obviously it's wrong.
{ OPTION_CALLBACK, 0, ignore-removal, addremove_explicit,
NULL /* takes no arguments */,
N_(ignore paths removed in the working tree (same as
--no-all)),
PARSE_OPT_NOARG, ignore_removal_cb },
Since almost all comments for l10n translators are marked with the same
prefix (tag): TRANSLATORS:, it's safe to only extract comments with
this special tag. I.E. it's better to call xgettext as:
xgettext --add-comments=TRANSLATORS: ...
Also tweaks the multi-line comment in init-db.c, to make it start with
the proper tag, not * TRANSLATORS: (which has a star before the tag).
Hmph.
I am not very happy with this change, as it would force us to
special case Translators comment to follow a non-standard
multi-line comment formatting convention. Is there a way to tell
xgettext to accept both of these forms?
/* TRANSLATORS: this is a short comment to help you */
_(foo bar);
/*
* TRANSLATORS: this comment is to help you, but it is
* a lot longer to fit on just a single line.
*/
_(bar baz);
Signed-off-by: Jiang Xin worldhello@gmail.com
---
Makefile | 2 +-
builtin/init-db.c | 8 +++-
2 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/Makefile b/Makefile
index 2128ce3..a53f3a8 100644
--- a/Makefile
+++ b/Makefile
@@ -2102,7 +2102,7 @@ pdf:
XGETTEXT_FLAGS = \
--force-po \
- --add-comments \
+ --add-comments=TRANSLATORS: \
--msgid-bugs-address=Git Mailing List git@vger.kernel.org \
--from-code=UTF-8
XGETTEXT_FLAGS_C = $(XGETTEXT_FLAGS) --language=C \
diff --git a/builtin/init-db.c b/builtin/init-db.c
index c7c76bb..56f85e2 100644
--- a/builtin/init-db.c
+++ b/builtin/init-db.c
@@ -412,11 +412,9 @@ int init_db(const char *template_dir, unsigned int flags)
if (!(flags INIT_DB_QUIET)) {
int len = strlen(git_dir);
- /*
- * TRANSLATORS: The first '%s' is either Reinitialized
- * existing or Initialized empty, the second shared or
- * , and the last '%s%s' is the verbatim directory name.
- */
+ /* TRANSLATORS: The first '%s' is either Reinitialized
+existing or Initialized empty, the second shared or
+, and the last '%s%s' is the verbatim directory name. */
printf(_(%s%s Git repository in %s%s\n),
reinit ? _(Reinitialized existing) : _(Initialized
empty),
shared_repository ? _( shared) : ,
--
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 0/3] extract proper comments for l10n translators
Jiang Xin worldhello@gmail.com writes: 2014-04-17 13:37 GMT+08:00 Jiang Xin worldhello@gmail.com: When generate git.pot, many irrelevant comments are extracted as references for translators, but one useful comment is lost. This series patches will fix this issue. Brief changes of po/git.pot after applied these patches: This is a very good way to make sure that 2/3 does not lose helpful comments. Thanks, but my complaint regarding the multi-line comment format still stands. diff --git a/po/git.pot b/po/git.pot index f70b46b..9e474f3 100644 --- a/po/git.pot +++ b/po/git.pot @@ -23,10 +23,6 @@ msgstr msgid hint: %.*s\n msgstr -#. -#. * Message used both when 'git commit' fails and when -#. * other commands doing a merge do. -#. #: advice.c:85 msgid Fix them up in the work tree,\n @@ -399,6 +395,7 @@ msgid_plural %lu years msgstr[0] msgstr[1] +#. TRANSLATORS: %s is n years #: date.c:149 #, c-format msgid %s, %lu month ago @@ -582,8 +579,6 @@ msgstr msgid Removing %s to make room for subdirectory\n msgstr -#. something else exists -#. .. but not some other error (who really cares what?) #: merge-recursive.c:700 merge-recursive.c:721 msgid : perhaps a D/F conflict? msgstr @@ -899,11 +894,6 @@ msgstr msgid Pathspec '%s' is in submodule '%.*s' msgstr -#. -#. * We may want to substitute this command with a command -#. * name. E.g. when add--interactive dies when running -#. * checkout -p -#. #: pathspec.c:353 #, c-format msgid %s: pathspec magic not supported by this command: %s @@ -953,11 +943,6 @@ msgstr msgid %s tracks both %s and %s msgstr -#. -#. * This last possibility doesn't occur because -#. * FETCH_HEAD_IGNORE entries always appear at -#. * the end of the list. -#. #: remote.c:774 msgid Internal error msgstr @@ -1306,13 +1291,11 @@ msgstr msgid Could not find section in .gitmodules where path=%s msgstr -#. Maybe the user already did that, don't error out here #: submodule.c:76 #, c-format msgid Could not update .gitmodules entry %s msgstr -#. Maybe the user already did that, don't error out here #: submodule.c:109 #, c-format msgid Could not remove .gitmodules entry for %s @@ -1884,7 +1867,6 @@ msgstr msgid add changes from all tracked and untracked files msgstr -#. takes no arguments #: builtin/add.c:260 msgid ignore paths removed in the working tree (same as --no-all) msgstr @@ -2044,7 +2026,6 @@ msgstr msgid corrupt binary patch at line %d: %.*s msgstr -#. there has to be one hunk (forward hunk) #: builtin/apply.c:1900 #, c-format msgid unrecognized binary patch at line %d @@ -2232,7 +2213,6 @@ msgstr msgid internal error msgstr -#. Say this even without --verbose #: builtin/apply.c:4043 #, c-format msgid Applying patch %%s with %d reject... @@ -3232,7 +3212,6 @@ msgstr msgid ... and %d more.\n msgstr -#. The singular version #: builtin/checkout.c:711 #, c-format msgid @@ -3280,7 +3259,6 @@ msgstr msgid invalid reference: %s msgstr -#. case (1): want a tree #: builtin/checkout.c:1002 #, c-format msgid reference is not a tree: %s @@ -4276,7 +4254,6 @@ msgstr msgid GPG sign commit msgstr -#. end commit message options #: builtin/commit.c:1508 msgid Commit contents options msgstr @@ -5140,7 +5117,6 @@ msgstr msgid See \git help gc\ for manual housekeeping.\n msgstr -#. be quiet on --auto #: builtin/gc.c:336 #, c-format msgid @@ -5894,12 +5870,10 @@ msgstr msgid unable to move %s to %s msgstr -#. -#. * TRANSLATORS: The first '%s' is either Reinitialized -#. * existing or Initialized empty, the second shared or -#. * , and the last '%s%s' is the verbatim directory name. -#. -#: builtin/init-db.c:420 +#. TRANSLATORS: The first '%s' is either Reinitialized +#. existing or Initialized empty, the second shared or +#. , and the last '%s%s' is the verbatim directory name. +#: builtin/init-db.c:418 #, c-format msgid %s%s Git repository in %s%s\n msgstr @@ -6627,7 +6601,6 @@ msgstr msgid Commit %s has a bad GPG signature allegedly by %s. msgstr -#. 'N' #: builtin/merge.c:1279 #, c-format msgid Commit %s does not have a GPG signature. @@ -9593,8 +9566,6 @@ msgstr msgid 'git bisect bad' can take only one argument. msgstr -#. have bad but not good. we could bisect although -#. this is less optimum. #: git-bisect.sh:273 msgid Warning: bisecting only with a bad commit. msgstr @@ -9690,10 +9661,6 @@ msgstr msgid updating an unborn branch with changes added to the index msgstr -#. The fetch involved updating the current branch. -#. The working tree and the index file is still based on the -#. $orig_head commit, but we are merging into $curr_head. -#. First update the working tree to match $curr_head. #: git-pull.sh:271 #, sh-format msgid @@ -9835,7 +9802,6 @@ msgstr msgid Changes from $mb to
Re: [PATCH 001/14] howto-index.sh: use the $( ... ) construct for command substitution
Matthieu Moy matthieu@grenoble-inp.fr writes: Elia Pinto gitter.spi...@gmail.com writes: The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. For patches 1 to 14: Reviewed-by: Matthieu Moy matthieu@imag.fr (reviewed the patches in my mailer, and the diff --color-words=. after applying in addition) Thanks both. Ideally, we should keep these scripted Porcelain implementations in the contrib/examples/ hierarchy up-to-date to still work with the recent versions of Git as they used to. We do not need to backport new features, but they should follow the best-current-practice of the use of plumbing features and scripting in general, and this update is probably a step in the right direction. It is somewhat sad that these are not tested but I do not think of an unintrusive easy way to keep them also in the test suite. Will queue. -- 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] tag: add -i and --introduced modifier for --contains
Andreas Schwab sch...@suse.de writes: Junio C Hamano gits...@pobox.com writes: ... When your project does not mind basing the description on rc tags, between v3.4-rc1~192^2~9^2 and v3.5-rc1~120^3~76^2, I am not sure if we would want to say that the former is not so longer than the latter, so use that, or what kind of heuristics to employ to reach that conclusion. Date-based selection (i.e. earliest first) is one possibility. Tagname-based selection has the issue of having to configure whose version numbering convention would you use when sorting tags, and how you would tell Git that sorting order rule? IMHO git should select based on topology: the first tag that isn't contained in any other tag still containing the commit in question, only when ambigous it needs to fall back to other criteria. I think we are in agreement. In the part you chopped from your quote, I said: For a possible cleaner alternative semantics, see the other message I just sent to the thread. didn't I? -- 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 2/4] Submodules: Add the lib-submodule-update.sh test library
W. Trevor King wk...@tremily.us writes: There have been a number of submodule series in flight recently, and I'm having trouble keeping track of them all ;). Unfortunately I share that same feeling X-. Could you guys collectively summarize what issues each of these in-flight topics try to address and how, how close it is to achieve concensus, and how it interact with other proposed topics? 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: [RFC] Speed up git status by caching untracked file info
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes: first run second (cached) run gentoo-x86500 ms 71.6 ms wine 140 ms 9.72 ms webkit125 ms 6.88 ms linux-2.6 106 ms 16.2 ms Basically untracked time is cut to one tenth in the best case scenario. The final numbers would be a bit higher because I haven't stored or read the cache from index yet. Real commit message follows.. As you allude to later with if you recompile a single file, the whole hierarchy in that directory is lost, two back-to-back runs of git status is not very interesting. - The list of files and directories of the direction in question - The $GIT_DIR/index - The content of $GIT_DIR/info/exclude - The content of core.excludesfile - The content (or the lack) of .gitignore of all parent directories from $GIT_WORK_TREE If we can cheaply validate all those inputs for a certain directory, we are sure that the current code will always produce the same results, so we can cache and reuse those results. This is not a silver bullet approach. When you compile a C file, for example, the old .o file is removed and a new one with the same name created, effectively invalidating the containing directory's cache. But at least with a large enough work tree, there could be many directories you never touch. The cache could help there. The first input can be checked using directory mtime. In many filesystems, directory mtime is updated when direct files/dirs are added or removed (*). An important thing is that creation of new cruft or deletion of existing cruft can be detected without any false negative with the mechanism, and mtime on directory would be a good way to check it. The second one can be hooked from read-cache.c. Whenever a file (or a submodule) is added or removed from a directory, we invalidate that directory. This will be done in a later patch. I would imagine that it would be done at the same places as we invalidate cache-trees, with the same invalidation percolates up logic. On subsequent runs, read_directory_recursive() reads stat info of the directory in question and verifies if files/dirs have been added or removed. Hmph. If you have a two-level hierarchy D1/D2 and you change the list of crufts in D2 but not in D1, the mtime of D1/D2 changes but not the mtime of D1, as you observed below. With the help of prep_exclude() to verify .gitignore chain, it may decide all is well and enable the fast path in treat_path(). read_directory_recursive() is still called for subdirectories even in fast path, because a directory mtime does not cover all subdirs recursively. I wonder if you can avoid recursing into D1 when no cached mtime (and .gitignore) information has changed in any subdirectory of it (e.g. both D1 and D1/D2 match the cache). -- 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 00/11] Use ref transactions from most callers
This patch series changes most of the places where the ref functions for locking and writing refs to instead use the new ref transaction API. There are still three more places where write_ref_sha1() is called from outside of refs.c but those all will require more complex work and review so those changes belong in a different patch series. Ronnie Sahlberg (11): refs.c: constify the sha arguments for ref_transaction_create|delete|update refs.c: change ref_transaction_update() to do error checking and return status refs.c: change ref_transaction_create to do error checking and return status refs.c: ref_transaction_delete to check for error and return status tag.c: use ref transactions when doing updates replace.c: use the ref transaction functions for updates commit.c: use ref transactions for updates sequencer.c: use ref transactions for all ref updates fast-import.c: change update_branch to use ref transactions branch.c: use ref transaction for all ref updates walker.c: use ref transaction for ref updates branch.c | 16 ++-- builtin/commit.c | 22 -- builtin/replace.c| 15 +-- builtin/tag.c| 15 +-- builtin/update-ref.c | 20 +--- fast-import.c| 23 +++ refs.c | 44 ++-- refs.h | 25 + sequencer.c | 17 + walker.c | 45 - 10 files changed, 144 insertions(+), 98 deletions(-) -- 1.9.1.513.gd486896 -- 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 04/11] refs.c: ref_transaction_delete to check for error and return status
Change ref_transaction_delete() to do basic error checking and return
status. Update all callers to check the return for ref_transaction_delete()
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
builtin/update-ref.c | 5 +++--
refs.c | 15 ++-
refs.h | 8
3 files changed, 17 insertions(+), 11 deletions(-)
diff --git a/builtin/update-ref.c b/builtin/update-ref.c
index 1b8a087..6ff8b86 100644
--- a/builtin/update-ref.c
+++ b/builtin/update-ref.c
@@ -258,8 +258,9 @@ static const char *parse_cmd_delete(struct strbuf *input,
const char *next)
if (*next != line_termination)
die(delete %s: extra input: %s, refname, next);
- ref_transaction_delete(transaction, refname, old_sha1,
- update_flags, have_old);
+ if (ref_transaction_delete(transaction, refname, old_sha1,
+ update_flags, have_old))
+ die(failed transaction delete for %s, refname);
update_flags = 0;
free(refname);
diff --git a/refs.c b/refs.c
index c46249f..9cbcffa 100644
--- a/refs.c
+++ b/refs.c
@@ -3366,19 +3366,24 @@ int ref_transaction_create(struct ref_transaction
*transaction,
return 0;
}
-void ref_transaction_delete(struct ref_transaction *transaction,
- const char *refname,
- const unsigned char *old_sha1,
- int flags, int have_old)
+int ref_transaction_delete(struct ref_transaction *transaction,
+ const char *refname,
+ const unsigned char *old_sha1,
+ int flags, int have_old)
{
- struct ref_update *update = add_update(transaction, refname);
+ struct ref_update *update;
+ if (have_old !old_sha1)
+ return error(have_old is true but old_sha1 is NULL);
+
+ update = add_update(transaction, refname);
update-flags = flags;
update-have_old = have_old;
if (have_old) {
assert(!is_null_sha1(old_sha1));
hashcpy(update-old_sha1, old_sha1);
}
+ return 0;
}
int update_ref(const char *action, const char *refname,
diff --git a/refs.h b/refs.h
index 8799e15..7050da2 100644
--- a/refs.h
+++ b/refs.h
@@ -259,10 +259,10 @@ int ref_transaction_create(struct ref_transaction
*transaction,
* old_sha1 holds the value that the reference should have had before
* the update (which must not be the null SHA-1).
*/
-void ref_transaction_delete(struct ref_transaction *transaction,
- const char *refname,
- const unsigned char *old_sha1,
- int flags, int have_old);
+int ref_transaction_delete(struct ref_transaction *transaction,
+ const char *refname,
+ const unsigned char *old_sha1,
+ int flags, int have_old);
/*
* Commit all of the changes that have been queued in transaction, as
--
1.9.1.513.gd486896
--
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 03/11] refs.c: change ref_transaction_create to do error checking and return status
Do basic error checking in ref_transaction_create() and make it return
status. Update all callers to check the result of ref_transaction_create()
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
builtin/update-ref.c | 4 +++-
refs.c | 17 +++--
refs.h | 8
3 files changed, 18 insertions(+), 11 deletions(-)
diff --git a/builtin/update-ref.c b/builtin/update-ref.c
index 12bfacc..1b8a087 100644
--- a/builtin/update-ref.c
+++ b/builtin/update-ref.c
@@ -226,7 +226,9 @@ static const char *parse_cmd_create(struct strbuf *input,
const char *next)
if (*next != line_termination)
die(create %s: extra input: %s, refname, next);
- ref_transaction_create(transaction, refname, new_sha1, update_flags);
+ if(ref_transaction_create(transaction, refname, new_sha1,
+ update_flags))
+ die(failed transaction create for %s, refname);
update_flags = 0;
free(refname);
diff --git a/refs.c b/refs.c
index da1761d..c46249f 100644
--- a/refs.c
+++ b/refs.c
@@ -3347,18 +3347,23 @@ int ref_transaction_update(struct ref_transaction
*transaction,
return 0;
}
-void ref_transaction_create(struct ref_transaction *transaction,
- const char *refname,
- const unsigned char *new_sha1,
- int flags)
+int ref_transaction_create(struct ref_transaction *transaction,
+ const char *refname,
+ const unsigned char *new_sha1,
+ int flags)
{
- struct ref_update *update = add_update(transaction, refname);
+ struct ref_update *update;
+
+ if (!new_sha1 || is_null_sha1(new_sha1))
+ return error(create ref with null new_sha1);
+
+ update = add_update(transaction, refname);
- assert(!is_null_sha1(new_sha1));
hashcpy(update-new_sha1, new_sha1);
hashclr(update-old_sha1);
update-flags = flags;
update-have_old = 1;
+ return 0;
}
void ref_transaction_delete(struct ref_transaction *transaction,
diff --git a/refs.h b/refs.h
index 00e4f7b..8799e15 100644
--- a/refs.h
+++ b/refs.h
@@ -249,10 +249,10 @@ int ref_transaction_update(struct ref_transaction
*transaction,
* null SHA-1. It is verified that the reference does not exist
* already.
*/
-void ref_transaction_create(struct ref_transaction *transaction,
- const char *refname,
- const unsigned char *new_sha1,
- int flags);
+int ref_transaction_create(struct ref_transaction *transaction,
+ const char *refname,
+ const unsigned char *new_sha1,
+ int flags);
/*
* Add a reference deletion to transaction. If have_old is true, then
--
1.9.1.513.gd486896
--
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 05/11] tag.c: use ref transactions when doing updates
Change tag.c to use ref transactions for all ref updates.
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
builtin/tag.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/builtin/tag.c b/builtin/tag.c
index 40356e3..dbeacc5 100644
--- a/builtin/tag.c
+++ b/builtin/tag.c
@@ -488,7 +488,6 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
struct strbuf ref = STRBUF_INIT;
unsigned char object[20], prev[20];
const char *object_ref, *tag;
- struct ref_lock *lock;
struct create_tag_options opt;
char *cleanup_arg = NULL;
int annotate = 0, force = 0, lines = -1;
@@ -496,6 +495,7 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
const char *msgfile = NULL, *keyid = NULL;
struct msg_arg msg = { 0, STRBUF_INIT };
struct commit_list *with_commit = NULL;
+ struct ref_transaction *transaction;
struct option options[] = {
OPT_CMDMODE('l', list, cmdmode, N_(list tag names), 'l'),
{ OPTION_INTEGER, 'n', NULL, lines, N_(n),
@@ -641,11 +641,14 @@ int cmd_tag(int argc, const char **argv, const char
*prefix)
if (annotate)
create_tag(object, tag, buf, opt, prev, object);
- lock = lock_any_ref_for_update(ref.buf, prev, 0, NULL);
- if (!lock)
- die(_(%s: cannot lock the ref), ref.buf);
- if (write_ref_sha1(lock, object, NULL) 0)
- die(_(%s: cannot update the ref), ref.buf);
+ transaction = ref_transaction_begin();
+ if (!transaction)
+ die(_(%s: cannot start transaction), ref.buf);
+ if (ref_transaction_update(transaction, ref.buf, object, prev,
+ 0, !is_null_sha1(prev)))
+ die(_(%s: cannot update transaction), ref.buf);
+ if (ref_transaction_commit(transaction, NULL, UPDATE_REFS_DIE_ON_ERR))
+ die(_(%s: cannot commit transaction), ref.buf);
if (force !is_null_sha1(prev) hashcmp(prev, object))
printf(_(Updated tag '%s' (was %s)\n), tag,
find_unique_abbrev(prev, DEFAULT_ABBREV));
--
1.9.1.513.gd486896
--
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 02/11] refs.c: change ref_transaction_update() to do error checking and return status
Update ref_transaction_update() do some basic error checking and return
true on error. Update all callers to check ref_transaction_update() for error.
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
builtin/update-ref.c | 11 +++
refs.c | 9 +++--
refs.h | 10 +-
3 files changed, 19 insertions(+), 11 deletions(-)
diff --git a/builtin/update-ref.c b/builtin/update-ref.c
index 405267f..12bfacc 100644
--- a/builtin/update-ref.c
+++ b/builtin/update-ref.c
@@ -197,8 +197,10 @@ static const char *parse_cmd_update(struct strbuf *input,
const char *next)
if (*next != line_termination)
die(update %s: extra input: %s, refname, next);
- ref_transaction_update(transaction, refname, new_sha1, old_sha1,
- update_flags, have_old);
+ if (ref_transaction_update(transaction, refname, new_sha1, old_sha1,
+ update_flags, have_old))
+ die(failed transaction update for %s, refname);
+
update_flags = 0;
free(refname);
@@ -286,8 +288,9 @@ static const char *parse_cmd_verify(struct strbuf *input,
const char *next)
if (*next != line_termination)
die(verify %s: extra input: %s, refname, next);
- ref_transaction_update(transaction, refname, new_sha1, old_sha1,
- update_flags, have_old);
+ if (ref_transaction_update(transaction, refname, new_sha1, old_sha1,
+ update_flags, have_old))
+ die(failed transaction update for %s, refname);
update_flags = 0;
free(refname);
diff --git a/refs.c b/refs.c
index 138ab70..da1761d 100644
--- a/refs.c
+++ b/refs.c
@@ -3327,19 +3327,24 @@ static struct ref_update *add_update(struct
ref_transaction *transaction,
return update;
}
-void ref_transaction_update(struct ref_transaction *transaction,
+int ref_transaction_update(struct ref_transaction *transaction,
const char *refname,
const unsigned char *new_sha1,
const unsigned char *old_sha1,
int flags, int have_old)
{
- struct ref_update *update = add_update(transaction, refname);
+ struct ref_update *update;
+
+ if (have_old !old_sha1)
+ return error(have_old is true but old_sha1 is NULL);
+ update = add_update(transaction, refname);
hashcpy(update-new_sha1, new_sha1);
update-flags = flags;
update-have_old = have_old;
if (have_old)
hashcpy(update-old_sha1, old_sha1);
+ return 0;
}
void ref_transaction_create(struct ref_transaction *transaction,
diff --git a/refs.h b/refs.h
index 892c5b6..00e4f7b 100644
--- a/refs.h
+++ b/refs.h
@@ -237,11 +237,11 @@ void ref_transaction_rollback(struct ref_transaction
*transaction);
* that the reference should have had before the update, or zeros if
* it must not have existed beforehand.
*/
-void ref_transaction_update(struct ref_transaction *transaction,
- const char *refname,
- const unsigned char *new_sha1,
- const unsigned char *old_sha1,
- int flags, int have_old);
+int ref_transaction_update(struct ref_transaction *transaction,
+ const char *refname,
+ const unsigned char *new_sha1,
+ const unsigned char *old_sha1,
+ int flags, int have_old);
/*
* Add a reference creation to transaction. new_sha1 is the value
--
1.9.1.513.gd486896
--
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 01/11] refs.c: constify the sha arguments for ref_transaction_create|delete|update
ref_transaction_create|delete|update has no need to modify the sha1
arguments passed to it so it should use const unsigned char* instead
of unsigned char*.
Some functions, such as fast_forward_to(), already have its old/new
sha1 arguments as consts. This function will at some point need to
use ref_transaction_update() in which case this change is required.
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
refs.c | 7 ---
refs.h | 7 ---
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/refs.c b/refs.c
index 728a761..138ab70 100644
--- a/refs.c
+++ b/refs.c
@@ -3329,7 +3329,8 @@ static struct ref_update *add_update(struct
ref_transaction *transaction,
void ref_transaction_update(struct ref_transaction *transaction,
const char *refname,
- unsigned char *new_sha1, unsigned char *old_sha1,
+ const unsigned char *new_sha1,
+ const unsigned char *old_sha1,
int flags, int have_old)
{
struct ref_update *update = add_update(transaction, refname);
@@ -3343,7 +3344,7 @@ void ref_transaction_update(struct ref_transaction
*transaction,
void ref_transaction_create(struct ref_transaction *transaction,
const char *refname,
- unsigned char *new_sha1,
+ const unsigned char *new_sha1,
int flags)
{
struct ref_update *update = add_update(transaction, refname);
@@ -3357,7 +3358,7 @@ void ref_transaction_create(struct ref_transaction
*transaction,
void ref_transaction_delete(struct ref_transaction *transaction,
const char *refname,
- unsigned char *old_sha1,
+ const unsigned char *old_sha1,
int flags, int have_old)
{
struct ref_update *update = add_update(transaction, refname);
diff --git a/refs.h b/refs.h
index 0f08def..892c5b6 100644
--- a/refs.h
+++ b/refs.h
@@ -239,7 +239,8 @@ void ref_transaction_rollback(struct ref_transaction
*transaction);
*/
void ref_transaction_update(struct ref_transaction *transaction,
const char *refname,
- unsigned char *new_sha1, unsigned char *old_sha1,
+ const unsigned char *new_sha1,
+ const unsigned char *old_sha1,
int flags, int have_old);
/*
@@ -250,7 +251,7 @@ void ref_transaction_update(struct ref_transaction
*transaction,
*/
void ref_transaction_create(struct ref_transaction *transaction,
const char *refname,
- unsigned char *new_sha1,
+ const unsigned char *new_sha1,
int flags);
/*
@@ -260,7 +261,7 @@ void ref_transaction_create(struct ref_transaction
*transaction,
*/
void ref_transaction_delete(struct ref_transaction *transaction,
const char *refname,
- unsigned char *old_sha1,
+ const unsigned char *old_sha1,
int flags, int have_old);
/*
--
1.9.1.513.gd486896
--
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 08/11] sequencer.c: use ref transactions for all ref updates
Change to use ref transactions for all updates to refs.
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
sequencer.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/sequencer.c b/sequencer.c
index bde5f04..fa14ac0 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -272,17 +272,26 @@ static int error_dirty_index(struct replay_opts *opts)
static int fast_forward_to(const unsigned char *to, const unsigned char *from,
int unborn, struct replay_opts *opts)
{
- struct ref_lock *ref_lock;
+ struct ref_transaction *transaction;
struct strbuf sb = STRBUF_INIT;
int ret;
read_cache();
if (checkout_fast_forward(from, to, 1))
exit(1); /* the callee should have complained already */
- ref_lock = lock_any_ref_for_update(HEAD, unborn ? null_sha1 : from,
- 0, NULL);
+
+ transaction = ref_transaction_begin();
+ if (!transaction)
+ return 1;
+ if (ref_transaction_update(transaction, HEAD, to, from,
+ 0, !unborn)) {
+ ref_transaction_rollback(transaction);
+ return 1;
+ }
+
strbuf_addf(sb, %s: fast-forward, action_name(opts));
- ret = write_ref_sha1(ref_lock, to, sb.buf);
+ ret = ref_transaction_commit(transaction, sb.buf,
+UPDATE_REFS_MSG_ON_ERR);
strbuf_release(sb);
return ret;
}
--
1.9.1.513.gd486896
--
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 10/11] branch.c: use ref transaction for all ref updates
Change branch.c to use ref transactions when doing updates.
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
branch.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/branch.c b/branch.c
index 660097b..45c7766 100644
--- a/branch.c
+++ b/branch.c
@@ -226,7 +226,7 @@ void create_branch(const char *head,
int force, int reflog, int clobber_head,
int quiet, enum branch_track track)
{
- struct ref_lock *lock = NULL;
+ struct ref_transaction *transaction;
struct commit *commit;
unsigned char sha1[20];
char *real_ref, msg[PATH_MAX + 20];
@@ -286,9 +286,12 @@ void create_branch(const char *head,
hashcpy(sha1, commit-object.sha1);
if (!dont_change_ref) {
- lock = lock_any_ref_for_update(ref.buf, NULL, 0, NULL);
- if (!lock)
- die_errno(_(Failed to lock ref for update));
+ transaction = ref_transaction_begin();
+ if (!transaction)
+ die_errno(_(Failed to begin transaction));
+ if (ref_transaction_update(transaction, ref.buf, sha1, NULL,
+ 0, 0))
+ die_errno(_(Failed to update transaction));
}
if (reflog)
@@ -305,8 +308,9 @@ void create_branch(const char *head,
setup_tracking(ref.buf + 11, real_ref, track, quiet);
if (!dont_change_ref)
- if (write_ref_sha1(lock, sha1, msg) 0)
- die_errno(_(Failed to write ref));
+ if (ref_transaction_commit(transaction, msg,
+UPDATE_REFS_DIE_ON_ERR))
+ die_errno(_(Failed to commit transaction));
strbuf_release(ref);
free(real_ref);
--
1.9.1.513.gd486896
--
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 09/11] fast-import.c: change update_branch to use ref transactions
Change update_branch() to use ref transactions for updates.
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
fast-import.c | 23 +++
1 file changed, 15 insertions(+), 8 deletions(-)
diff --git a/fast-import.c b/fast-import.c
index fb4738d..466dfe3 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -1678,36 +1678,43 @@ found_entry:
static int update_branch(struct branch *b)
{
static const char *msg = fast-import;
- struct ref_lock *lock;
+ struct ref_transaction *transaction;
unsigned char old_sha1[20];
if (is_null_sha1(b-sha1))
return 0;
if (read_ref(b-name, old_sha1))
hashclr(old_sha1);
- lock = lock_any_ref_for_update(b-name, old_sha1, 0, NULL);
- if (!lock)
- return error(Unable to lock %s, b-name);
+ transaction = ref_transaction_begin();
+ if (!transaction)
+ return error(Unable to begin transaction for %s, b-name);
if (!force_update !is_null_sha1(old_sha1)) {
struct commit *old_cmit, *new_cmit;
old_cmit = lookup_commit_reference_gently(old_sha1, 0);
new_cmit = lookup_commit_reference_gently(b-sha1, 0);
if (!old_cmit || !new_cmit) {
- unlock_ref(lock);
+ ref_transaction_rollback(transaction);
return error(Branch %s is missing commits., b-name);
}
if (!in_merge_bases(old_cmit, new_cmit)) {
- unlock_ref(lock);
+ ref_transaction_rollback(transaction);
warning(Not updating %s
(new tip %s does not contain %s),
b-name, sha1_to_hex(b-sha1),
sha1_to_hex(old_sha1));
return -1;
}
}
- if (write_ref_sha1(lock, b-sha1, msg) 0)
- return error(Unable to update %s, b-name);
+ if (ref_transaction_update(transaction, b-name, b-sha1, old_sha1,
+ 0, 1)) {
+ ref_transaction_rollback(transaction);
+ return error(Unable to update transaction for %s, b-name);
+ }
+ if (ref_transaction_commit(transaction, msg,
+ UPDATE_REFS_QUIET_ON_ERR))
+ return error(Unable to commit transaction for %s, b-name);
+
return 0;
}
--
1.9.1.513.gd486896
--
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 07/11] commit.c: use ref transactions for updates
Change commit.c to use ref transactions for all ref updates.
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
builtin/commit.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index d9550c5..b8e4389 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -1541,11 +1541,11 @@ int cmd_commit(int argc, const char **argv, const char
*prefix)
const char *index_file, *reflog_msg;
char *nl;
unsigned char sha1[20];
- struct ref_lock *ref_lock;
struct commit_list *parents = NULL, **pptr = parents;
struct stat statbuf;
struct commit *current_head = NULL;
struct commit_extra_header *extra = NULL;
+ struct ref_transaction *transaction;
if (argc == 2 !strcmp(argv[1], -h))
usage_with_options(builtin_commit_usage,
builtin_commit_options);
@@ -1667,12 +1667,6 @@ int cmd_commit(int argc, const char **argv, const char
*prefix)
strbuf_release(author_ident);
free_commit_extra_headers(extra);
- ref_lock = lock_any_ref_for_update(HEAD,
- !current_head
- ? NULL
- : current_head-object.sha1,
- 0, NULL);
-
nl = strchr(sb.buf, '\n');
if (nl)
strbuf_setlen(sb, nl + 1 - sb.buf);
@@ -1681,14 +1675,22 @@ int cmd_commit(int argc, const char **argv, const char
*prefix)
strbuf_insert(sb, 0, reflog_msg, strlen(reflog_msg));
strbuf_insert(sb, strlen(reflog_msg), : , 2);
- if (!ref_lock) {
+ transaction = ref_transaction_begin();
+ if (!transaction) {
rollback_index_files();
- die(_(cannot lock HEAD ref));
+ die(_(HEAD: cannot start transaction));
}
- if (write_ref_sha1(ref_lock, sha1, sb.buf) 0) {
+ if (ref_transaction_update(transaction, HEAD, sha1,
+ current_head-object.sha1,
+ 0, !!current_head)) {
rollback_index_files();
die(_(cannot update HEAD ref));
}
+ if (ref_transaction_commit(transaction, sb.buf,
+ UPDATE_REFS_QUIET_ON_ERR)) {
+ rollback_index_files();
+ die(_(cannot commit HEAD ref));
+ }
unlink(git_path(CHERRY_PICK_HEAD));
unlink(git_path(REVERT_HEAD));
--
1.9.1.513.gd486896
--
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 11/11] walker.c: use ref transaction for ref updates
Switch to using ref transactions in walker_fetch(). As part of the refactoring
to use ref transactions we also fix a potential memory leak where in the
original code if write_ref_sha1() would fail we would end up returning from
the function without free()ing the msg string.
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
walker.c | 45 -
1 file changed, 20 insertions(+), 25 deletions(-)
diff --git a/walker.c b/walker.c
index 1dd86b8..fa02d09 100644
--- a/walker.c
+++ b/walker.c
@@ -251,24 +251,16 @@ void walker_targets_free(int targets, char **target,
const char **write_ref)
int walker_fetch(struct walker *walker, int targets, char **target,
const char **write_ref, const char *write_ref_log_details)
{
- struct ref_lock **lock = xcalloc(targets, sizeof(struct ref_lock *));
+ struct ref_transaction *transaction;
unsigned char *sha1 = xmalloc(targets * 20);
- char *msg;
- int ret;
+ char *msg = NULL;
int i;
save_commit_buffer = 0;
- for (i = 0; i targets; i++) {
- if (!write_ref || !write_ref[i])
- continue;
-
- lock[i] = lock_ref_sha1(write_ref[i], NULL);
- if (!lock[i]) {
- error(Can't lock ref %s, write_ref[i]);
- goto unlock_and_fail;
- }
- }
+ transaction = ref_transaction_begin();
+ if (!transaction)
+ return -1;
if (!walker-get_recover)
for_each_ref(mark_complete, NULL);
@@ -276,14 +268,14 @@ int walker_fetch(struct walker *walker, int targets, char
**target,
for (i = 0; i targets; i++) {
if (interpret_target(walker, target[i], sha1[20 * i])) {
error(Could not interpret response from server '%s' as
something to pull, target[i]);
- goto unlock_and_fail;
+ goto rollback_and_fail;
}
if (process(walker, lookup_unknown_object(sha1[20 * i])))
- goto unlock_and_fail;
+ goto rollback_and_fail;
}
if (loop(walker))
- goto unlock_and_fail;
+ goto rollback_and_fail;
if (write_ref_log_details) {
msg = xmalloc(strlen(write_ref_log_details) + 12);
@@ -294,19 +286,22 @@ int walker_fetch(struct walker *walker, int targets, char
**target,
for (i = 0; i targets; i++) {
if (!write_ref || !write_ref[i])
continue;
- ret = write_ref_sha1(lock[i], sha1[20 * i], msg ? msg : fetch
(unknown));
- lock[i] = NULL;
- if (ret)
- goto unlock_and_fail;
+ if (ref_transaction_update(transaction, write_ref[i],
+ sha1[20 * i], NULL,
+ 0, 0))
+ goto rollback_and_fail;
}
- free(msg);
+ if (ref_transaction_commit(transaction, msg ? msg : fetch (unknown),
+ UPDATE_REFS_QUIET_ON_ERR))
+ goto rollback_and_fail;
+
+ free(msg);
return 0;
-unlock_and_fail:
- for (i = 0; i targets; i++)
- if (lock[i])
- unlock_ref(lock[i]);
+rollback_and_fail:
+ free(msg);
+ ref_transaction_rollback(transaction);
return -1;
}
--
1.9.1.513.gd486896
--
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 06/11] replace.c: use the ref transaction functions for updates
Update replace.c to use ref transactions for updates. Signed-off-by: Ronnie Sahlberg sahlb...@google.com --- builtin/replace.c | 15 +-- 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/builtin/replace.c b/builtin/replace.c index b62420a..d8bd6ee 100644 --- a/builtin/replace.c +++ b/builtin/replace.c @@ -129,7 +129,7 @@ static int replace_object(const char *object_ref, const char *replace_ref, unsigned char object[20], prev[20], repl[20]; enum object_type obj_type, repl_type; char ref[PATH_MAX]; - struct ref_lock *lock; + struct ref_transaction *transaction; if (get_sha1(object_ref, object)) die(Failed to resolve '%s' as a valid ref., object_ref); @@ -157,11 +157,14 @@ static int replace_object(const char *object_ref, const char *replace_ref, else if (!force) die(replace ref '%s' already exists, ref); - lock = lock_any_ref_for_update(ref, prev, 0, NULL); - if (!lock) - die(%s: cannot lock the ref, ref); - if (write_ref_sha1(lock, repl, NULL) 0) - die(%s: cannot update the ref, ref); + transaction = ref_transaction_begin(); + if (!transaction) + die(_(%s: cannot start transaction), ref); + if (ref_transaction_update(transaction, ref, repl, prev, + 0, !is_null_sha1(prev))) + die(_(%s: cannot update transaction), ref); + if (ref_transaction_commit(transaction, NULL, UPDATE_REFS_DIE_ON_ERR)) + die(_(%s: cannot commit transaction), ref); return 0; } -- 1.9.1.513.gd486896 -- 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: automatic submodule deinit (platform specific blacklist)
On 04/17/14 17:45, Jens Lehmann wrote: Am 17.04.2014 10:02, schrieb Gerhard Gappmeier: Hi all in our cross-platform projects we always have a certain Windows-only submodule, which contains all the compatibility stuff and missing libraries for Windows. When cloning such a repository on a Linux machine the typical procedure is: git clone git@server:project.git cd project git submodule init git submodule deinit path/to/windows-stuff git submodule update This way you avoid wasting time and disk space to clone stuff that you don't need on Linux (or on whatever non-windows machine your are actually working). It would be really cool to add a kind of platform specific submodule blacklist, either in .gitconfig or maybe even better in .gitattributes so that we can add this configuration to the repository. Example .gitattributes how this could look like: # common stuff *.sh eol=lf *.conf eol=lf # submodule config [src/windows-compat] platforms = win32 By default the platforms could have the value all. But one can change it to a list of platform names e.g. platforms = linux, macosx or win32 like in the example above. Such a feature would also make it possible to simply use git clone -- recursive git@server:project.git avoiding the single stops as shown above. What do your think? Is something like this possible? Or is it even possible already somehow? Today I'm using a shell script to automate this steps, but this is just a workaround. It would be cool if git itself could do this for us. What about setting submodule.name.update to none in the config of your non-Windows machines? Then they would be initialized (= the URL setting gets copied to .git/config) but never checked out. great! that works. It would be even better if we could store this config in the repository, but this helps already a lot. thx -- 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
What's cooking in git.git (Apr 2014, #05; Thu, 17)
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
Hopefully we can merge a few more topics slated for 'master' before
cutting an early preview release -rc0 tomorrow. Many of the topics
that are in 'next' have sizable impact on the codebase and I'd feel
safer to keep them cooking for the remainder of the cycle.
Also I am still waiting for acks for a few topics before merging
them to 'next'. I would feel it would be good if we can merge them
early to 'next' for wider and longer exposure and some of them may
even deserve to be in -rc1, but as none of them is a regression fix,
it is also OK to wait until 2.0 final.
You can find the changes described here in the integration branches
of the repositories listed at
http://git-blame.blogspot.com/p/git-public-repositories.html
--
[Graduated to master]
* km/avoid-bs-in-shell-glob (2014-04-11) 1 commit
(merged to 'next' on 2014-04-14 at a3d9a58)
+ test: fix t5560 on FreeBSD
Portability fix.
May want to merge to 'maint' later.
* km/avoid-cp-a (2014-04-11) 1 commit
(merged to 'next' on 2014-04-14 at be661c4)
+ test: fix t7001 cp to use POSIX options
Portability fix.
May want to merge to 'maint' later.
* mh/multimail (2014-04-07) 1 commit
(merged to 'next' on 2014-04-15 at eaba915)
+ git-multimail: update to version 1.0.0
* tb/unicode-6.3-zero-width (2014-04-09) 1 commit
(merged to 'next' on 2014-04-14 at 72ce72a)
+ utf8.c: partially update to version 6.3
Teach our display-column-counting logic about decomposed umlauts
and friends.
--
[New Topics]
* jl/git-gui-show-added-submodule-changes (2014-04-15) 1 commit
- git-gui: show staged submodules regardless of ignore config
Tentatively queued what I expect to receive via Pat Thoyts.
* jl/gitk-show-added-submodule-changes (2014-04-15) 3 commits
- gitk: show staged submodules regardless of ignore config
- gitk: Merge branch 'new' of https://github.com/vnwildman/gitk
- l10n: Init Vietnamese translation
Tentatively queued what I expect to receive via Paul Mackerras.
* bg/rebase-off-of-previous-branch (2014-04-16) 1 commit
- git-rebase: print name of rev when using shorthand
Teach git rebase - to report the concrete name of the branch
(i.e. the previous one).
But it stops short and does not do the same for git rebase @{-1}.
* ef/send-email-absolute-path-to-the-command (2014-04-16) 1 commit
- send-email: recognize absolute path on Windows
* jk/config-die-bad-number-noreturn (2014-04-16) 1 commit
(merged to 'next' on 2014-04-16 at 4d49036)
+ config.c: mark die_bad_number as NORETURN
Squelch a false compiler warning from older gcc.
Will merge to 'master'.
* ep/shell-command-substitution (2014-04-17) 14 commits
- t9362-mw-to-git-utf8.sh: use the $( ... ) construct for command substitution
- t9360-mw-to-git-clone.sh: use the $( ... ) construct for command substitution
- git-tag.sh: use the $( ... ) construct for command substitution
- git-revert.sh: use the $( ... ) construct for command substitution
- git-resolve.sh: use the $( ... ) construct for command substitution
- git-repack.sh: use the $( ... ) construct for command substitution
- git-merge.sh: use the $( ... ) construct for command substitution
- git-ls-remote.sh: use the $( ... ) construct for command substitution
- git-fetch.sh: use the $( ... ) construct for command substitution
- git-commit.sh: use the $( ... ) construct for command substitution
- git-clone.sh: use the $( ... ) construct for command substitution
- git-checkout.sh: use the $( ... ) construct for command substitution
- install-webdoc.sh: use the $( ... ) construct for command substitution
- howto-index.sh: use the $( ... ) construct for command substitution
Will merge to 'next' and perhaps to 'master'.
* jh/submodule-tests (2014-04-17) 1 commit
- t7410: 210 tests for various 'git submodule update' scenarios
* jx/i18n (2014-04-17) 3 commits
- i18n: only extract comments marked with TRANSLATORS:
- i18n: remove obsolete comments for translators in diffstat generation
- i18n: fix uncatchable comments for translators in date.c
The tip one is somewhat unfortunate to force us deviate from our
multi-line comment formatting convention when writing comments for
translators.
* rs/ref-update-check-errors-early (2014-04-17) 2 commits
- commit.c: check for lock error and return early
- sequencer.c: check for lock failure and bail early in fast_forward_to
* sk/svn-parse-datestamp (2014-04-17) 1 commit
- SVN.pm::parse_svn_date: allow timestamps with a single-digit hour
--
[Stalled]
* fc/publish-vs-upstream (2014-04-11) 8 commits
- sha1_name: add support for @{publish} marks
- sha1_name: simplify track finding
- sha1_name: cleanup interpret_branch_name()
- branch:
Re: [git] [RFC/PATCH 2/4] Submodules: Add the lib-submodule-update.sh test library
Am 17.04.2014 18:41, schrieb W. Trevor King: On Tue, Mar 25, 2014 at 06:05:05PM +0100, Jens Lehmann wrote: *) When a submodule is replaced with a tracked file of the same name the submodule work tree including any local modifications (and even the whole history if it uses a .git directory instead of a gitfile!) is simply removed. … I think the first bug really needs to be fixed, as that behavior is extremely nasty. We should always protect work tree modifications (unless forced) and *never* remove a .git directory (even when forced). I think this should be covered by the usual “don't allow checkouts from dirty workdirs unless the dirty-ing changes are easily applied to the target tree”. Nope, the target tree will be removed completely and everything in it is silently nuked. It should be allowed with '-f', but only if the submodule contains a gitfile, and never if it contains a .git directory (which is just what we do for rm too). Are we waiting to land this series (or a successor) before starting on a fix for this issue? I think so, as this bug is there for a long time (so I see no urge to fix it very soon) and my test harness is intended to document this current bug (and then soon its fix). *) Forced work tree updates happily manipulate files in the directory of a submodule that has just been removed in the superproject (but is of course still present in the work tree due to the way submodules are currently handled). This becomes dangerous when files in the submodule directory are overwritten by files from the new superproject commit, as any modifications to the submodule files will be lost) and is expected to also destroy history in the - admittedly unlikely case - the new commit adds a file named .git to the submodule directory. … I'm not so sure about the second one. Even though I believe the current behavior is not correct (switching commits should never mess around in a submodule directory) This should also be covered by the usual “don't allow checkouts from dirty workdirs unless the dirty-ing changes are easily applied to the target tree”. We don't implement this yet, but I'd like to force users to move any about-to-be-clobbered state from their submodule into .git/modules/name/ (via commits or stashes) before allowing them to begin the checkout. Once we've ensured that the state is preserved out-of-tree, then clobber away ;). I'm intending to fix this in the recursive checkout series, as I'm a) not sure if any users currently depend on that for a submodule to directory transition and b) recursive checkout is the place to consistently care about submodule modifications (the submodule script doesn't do that and it is impossible to change that without causing trouble to a lot of users. -- 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 v2 2/2] commit.c: check for lock error and return early
Michael Haggerty mhag...@alum.mit.edu writes: On 04/16/2014 08:56 PM, Ronnie Sahlberg wrote: Move the check for the lock failure to happen immediately after lock_any_ref_for_update(). Previously the lock and the check-if-lock-failed was separated by a handful of string manipulation statements. Please flow sentences together into paragraphs for easier reading, rather than having an extremely ragged right-hand margin. The rest looks good. Thanks, both. I tentatively queued with the suggested log message tweaks, and I think result reads better. -- 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 2/4] Submodules: Add the lib-submodule-update.sh test library
Am 17.04.2014 21:23, schrieb Junio C Hamano: W. Trevor King wk...@tremily.us writes: There have been a number of submodule series in flight recently, and I'm having trouble keeping track of them all ;). Unfortunately I share that same feeling X-. Could you guys collectively summarize what issues each of these in-flight topics try to address and how, how close it is to achieve concensus, and how it interact with other proposed topics? I'm aware of these topics: - My 4 Never ignore staged but ignored submodules patches I recall that everyone agreed that this is a good change. - Johan's Test various 'git submodule update' scenarios Intended to document current behavior of the submodule.name.branch setting (and others) as a starting point for a discussion of how that could (and should) evolve. Needs some cooking. - My submodule test harness RFC series (currently 14 patches) Similar to Johan's patch I try to document the current behavior of Git, but with the focus on all work tree manipulating commands (not only 'submodule update' handling all submodule changes. Will send to the list again when I resolved the last outstanding issues, current state can be seen in the submodule-test-harness branch of my GitHub repo. My next to-be-finished topic. - Ronald's two Teach add and commit the --ignore-submodules option options Will review v4 soonish, looking good from the first cursory look. - My recursive submodule checkout series Needs to be rerolled, I intend to extend my submodule test harness to cover all relevant scenarios for this series. - Heiko's config cache for submodules patch Needed for my recursive checkout series to populate new submodules. And then a not yet surfaced do not replace submodules with a file fix I intend to send between the submodule test harness and the recursive submodule checkout series. Hope that makes it clearer ;-) -- 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] git tag --contains : avoid stack overflow
On Thu, Apr 17, 2014 at 07:31:54PM +0200, Johannes Schindelin wrote: bash -c ulimit -s 64 git tag --contains HEAD actual [...] Please see https://github.com/msysgit/git/c63d196 for the fixup, and https://github.com/msysgit/git/compare/tag-contains%5E...tag-contains for the updated patch. I tried running the test on my Linux box, but it doesn't fail with the existing recursive code. So I tried a few different stack sizes, like: for i in `seq 1 64`; do bash -c ulimit -s $i ../../git tag --contains HEAD || echo fail $i done The results are strangely non-deterministic, but with -O0, we generally die reliably below about 60. With -O2, though, it's more like 43. We can't go _too_ low here, though, as lots of things start breaking around 32. If we instead bump the size of the history to 2000 commits, then I reliably fail with a 64k stack (even with -O2, it needs around 80k). Of course those numbers are all black magic, and are going to vary based on the system, the compiler, settings, etc. My system is 64-bit, and the current code needs at least 3 pointers per recursive invocation. So we're spending ~46K on those variables, not counting any calling convention overhead (and presumably we at least need a function return pointer there). So a 32-bit system might actually get by, as it would need half as much. So we can bump the depth further; probably 4000 is enough for any system to fail with a 64k stack. The deeper we make it, the longer it takes to run the test, though. At 4000, my machine seems to take about 300ms to run it. That's may be OK. -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] git tag --contains : avoid stack overflow
Hi Peff, On Thu, 17 Apr 2014, Jeff King wrote: On Thu, Apr 17, 2014 at 07:31:54PM +0200, Johannes Schindelin wrote: bash -c ulimit -s 64 git tag --contains HEAD actual [...] Please see https://github.com/msysgit/git/c63d196 for the fixup, and https://github.com/msysgit/git/compare/tag-contains%5E...tag-contains for the updated patch. I tried running the test on my Linux box, but it doesn't fail with the existing recursive code. I cannot recall how I came to choose 64, but I *think* I only tested on Windows, and I *think* I reduced the number of tags in order to make things faster (Windows is *unbearably* slow with spawn-happy programs such as Git's tests -- literally every single line in a shell script tests the patience of this developer, running the complete test suite with 15 parallel threads takes several hours, no kidding). The results are strangely non-deterministic, but with -O0, we generally die reliably below about 60. With -O2, though, it's more like 43. We can't go _too_ low here, though, as lots of things start breaking around 32. How about using 40, then? I am more interested in reducing the runtime than reducing the number of false negatives. The problem will be exercised enough on Windows, but not if the test suite becomes even slower than it already is. Ciao, Johannes -- 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] [RFC/PATCH 2/4] Submodules: Add the lib-submodule-update.sh test library
On Thu, Apr 17, 2014 at 11:08:06PM +0200, Jens Lehmann wrote: Am 17.04.2014 18:41, schrieb W. Trevor King: On Tue, Mar 25, 2014 at 06:05:05PM +0100, Jens Lehmann wrote: *) When a submodule is replaced with a tracked file of the same name the submodule work tree including any local modifications (and even the whole history if it uses a .git directory instead of a gitfile!) is simply removed. … I think the first bug really needs to be fixed, as that behavior is extremely nasty. We should always protect work tree modifications (unless forced) and *never* remove a .git directory (even when forced). I think this should be covered by the usual “don't allow checkouts from dirty workdirs unless the dirty-ing changes are easily applied to the target tree”. Nope, the target tree will be removed completely and everything in it is silently nuked. It should be allowed with '-f', but only if the submodule contains a gitfile, and never if it contains a .git directory (which is just what we do for rm too). I think it's not covered *now* because of a flaw in our “are dirty-ing changes easily applied to the target tree” detection logic, and the solution should involve updating that logic to hit on this case. b) recursive checkout is the place to consistently care about submodule modifications (the submodule script doesn't do that and it is impossible to change that without causing trouble to a lot of users. I agree that the submodule script is not the place for this, and the core checkout code is. I'd like checkouts to always be recursive, and see --[no-]recurse-submodules as a finger-breaking stop-gap until we can complete that transition for checkout, bisect, merge, reset, and other work-tree altering commands. I think this is one reason why some folks prefer the stiffer joints you get from a subtree approach. Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [PATCH] git tag --contains : avoid stack overflow
On Thu, Apr 17, 2014 at 11:52:56PM +0200, Johannes Schindelin wrote: I tried running the test on my Linux box, but it doesn't fail with the existing recursive code. I cannot recall how I came to choose 64, but I *think* I only tested on Windows, and I *think* I reduced the number of tags in order to make things faster (Windows is *unbearably* slow with spawn-happy programs such as Git's tests -- literally every single line in a shell script tests the patience of this developer, running the complete test suite with 15 parallel threads takes several hours, no kidding). Yeah, I figured speed had something to do with it. However, since you are using a bash loop to generate the input (and it should all be done as builtins in bash, I think), and fast-import to create the objects, I don't think bumping it will actually increase your process count. The results are strangely non-deterministic, but with -O0, we generally die reliably below about 60. With -O2, though, it's more like 43. We can't go _too_ low here, though, as lots of things start breaking around 32. How about using 40, then? I am more interested in reducing the runtime than reducing the number of false negatives. The problem will be exercised enough on Windows, but not if the test suite becomes even slower than it already is. I'm OK with doing that. My biggest concern is that it will cause false positives on systems that are hungrier for stack space, but we can address that if it happens. -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] tag: add -i and --introduced modifier for --contains
On Thu, Apr 17, 2014 at 10:04:52AM -0700, Junio C Hamano wrote: Commit A can be described in terms of both v3.4 and v9.0, and it may be closer to v9.0 than v3.4, and under that definition we pick the closest tag, the current describe --contains behaviour may be correct, but from the human point of view, it is *WRONG*. It is wrong because v9.0 can reach v3.4. So perhaps the rule should be updated to do something like: - find candidate tags that can be used to describe --contains the commit A, yielding v3.4, v3.5 (not shown), and v9.0; - among the candidate tags, cull the ones that contain another candidate tag, rejecting v3.5 (not shown) and v9.0; - among the surviving tags, pick the closest. Hmm? Interesting. I think that would cover some cases, but there are others in which the tags are not direct descendants. For example, imagine you have both a master and a maint branch. You fork a topic from an old commit that both branches contain, and then independently merge the topic to each branch. You then cut a release for each. So your graph might look like: ---A---B---C-D---E---F (maint, v3.4) \ \ / \ ---G-H---I (master, v4.0) \ / / --J--- The fix is J, and it got merged up to maint at D, and to master at H. v4.0 does not contain v3.4. What's the best description of J? By the rules above, we hit the third rule pick the closest. Which means we choose v3.4 or v4.0 based solely on how many commits are between the topic's merge and the tag release. Which has nothing at all to do with the topic itself. In this case we'd show v4.0 (because J-H-I is shorter than J-D-E-F). But I suspect most users would want to know v3.4, because they want to know the oldest release they can move up to that contains the commit. But that notion of oldness is not conveyed by the graph above; it's only an artifact of the tag names. So you can solve this by actually representing the relationship with a merge. IOW, by merging v3.4 into v4.0 to say yes, v4.0 is a superset. And that's generally what we do in git.git, merging maint into master periodically. But I imagine there are other possible workflows where people do not do that merge up, and the maint and master branches diverge (and maybe they even cherry-pick from each other, but sometimes merge if the fix can be based on a common ancestor, as in this case). -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] Speed up git status by caching untracked file info
On Fri, Apr 18, 2014 at 2:40 AM, Junio C Hamano gits...@pobox.com wrote: Nguyễn Thái Ngọc Duy pclo...@gmail.com writes: first run second (cached) run gentoo-x86500 ms 71.6 ms wine 140 ms 9.72 ms webkit125 ms 6.88 ms linux-2.6 106 ms 16.2 ms Basically untracked time is cut to one tenth in the best case scenario. The final numbers would be a bit higher because I haven't stored or read the cache from index yet. Real commit message follows.. As you allude to later with if you recompile a single file, the whole hierarchy in that directory is lost, two back-to-back runs of git status is not very interesting. No, if you recompile in directory A, then we need to recompute exclude files for A only, not A/B, A/B/C... We only need to invalidate the whole hierarchy when A/.gitignore (or worse $GIT_DIR/info/exclude) is changed. The second one can be hooked from read-cache.c. Whenever a file (or a submodule) is added or removed from a directory, we invalidate that directory. This will be done in a later patch. I would imagine that it would be done at the same places as we invalidate cache-trees, with the same invalidation percolates up logic. Yep yep. On subsequent runs, read_directory_recursive() reads stat info of the directory in question and verifies if files/dirs have been added or removed. Hmph. If you have a two-level hierarchy D1/D2 and you change the list of crufts in D2 but not in D1, the mtime of D1/D2 changes but not the mtime of D1, as you observed below. With the help of prep_exclude() to verify .gitignore chain, it may decide all is well and enable the fast path in treat_path(). read_directory_recursive() is still called for subdirectories even in fast path, because a directory mtime does not cover all subdirs recursively. I wonder if you can avoid recursing into D1 when no cached mtime (and .gitignore) information has changed in any subdirectory of it (e.g. both D1 and D1/D2 match the cache). The problem if when we need to decide to recurse into D1, we have no idea if any of its subdirs is changed. So we need to recurse in anyway (at least in the cache; if D1 is unchanged, we will not try to opendir() it, just get the exclude list from the cache and move on). -- 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: [PATCH 1/3] rebase: avoid non-function use of return on FreeBSD
On Apr 17, 2014, at 10:15, Junio C Hamano wrote: I think just the s/from/to/ would fix it so it does not give me the wrong impression, but that doesn't mean that would not confuse everyone else. ;) Yeah, let's do that. Thanks for carefully reading them. I'd think it makes it clearer to say that we take return stopping the dot-sourced file as a given and FreeBSD does not behave that way. -- 8 -- From: Kyle J. McKay mack...@gmail.com Date: Fri, 11 Apr 2014 01:28:17 -0700 Subject: [PATCH] rebase: avoid non-function use of return on FreeBSD [...] The new version of the patch looks great, let's use that. Thanks for adjusting it. -- 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: gitignore vs. exclude vs assume-unchanged?
On 2014-04-16 16:45, Jonathan Nieder wrote: Hi, a...@bellandwhistle.net wrote: In particular, 'exclude' is spottily documented. Where did you expect to read about it? I see some mention of .git/info/exclude in the gitignore(5) page, but I wouldn't be surprised if there's room for improvement there (improvements welcome). I suppose I might consider amending the opening sentence at: http://git-scm.com/docs/gitignore from: A gitignore file specifies intentionally untracked files that Git should ignore. to something that makes the point earlier about the similarity: Both gitignore and $GIT_DIR/info/exclude files specify intentionally untracked files that Git should ignore. or: Like the $GIT_DIR/info/exclude file, gitignore files specify intentionally untracked files that Git should ignore. The difference is that files matched by a pattern in a gitignore file will be untracked for all users of the repository. or somesuch. The other thing is that there is no warning in the docs that assume-unchanged is not an absolute promise to ignore. This is news to me. I don't see this anywhere. I understand now that the use case is performance, but that could be clearer. thanks again Alex -- 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
