[PATCH v2] refs: use skip_prefix() in ref_is_hidden()
This is shorter, makes the logic a bit easier to follow, and is
perhaps a bit faster too.
The logic is to make the final decision only when "subject" is there,
its early part matches "match", and the match is at the slash
boundary (or the whole thing).
Signed-off-by: Christian Couder
---
The change with the previous version was suggested by Junio in
https://public-inbox.org/git/xmqqk231hgpz@gitster.mtv.corp.google.com/
refs.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/refs.c b/refs.c
index ba22f4acef..ea2b9f84f8 100644
--- a/refs.c
+++ b/refs.c
@@ -1160,7 +1160,7 @@ int ref_is_hidden(const char *refname, const char
*refname_full)
const char *match = hide_refs->items[i].string;
const char *subject;
int neg = 0;
- int len;
+ const char *p;
if (*match == '!') {
neg = 1;
@@ -1175,10 +1175,9 @@ int ref_is_hidden(const char *refname, const char
*refname_full)
}
/* refname can be NULL when namespaces are used. */
- if (!subject || !starts_with(subject, match))
- continue;
- len = strlen(match);
- if (!subject[len] || subject[len] == '/')
+ if (subject &&
+ skip_prefix(subject, match, &p) &&
+ (!*p || *p == '/'))
return !neg;
}
return 0;
--
2.14.0.rc0.26.g981adb928e.dirty
Re: [PATCH] PRItime: wrap PRItime for better l10n compatibility
Jiang Xin writes: > But it is rare to maintain po/git.pot file for 'maint' branch. And if > I need, I will switch to a different version of gettext. Makefile > will throw a error message, if I use a wrong version of gettext. Is that the "v1" in the check in your Makefile patch is about? That is, when we need to change the underlying type, your updated gettext would say something different from "v1" and you will have Makefile update to expect that new version? Then it would be workable, I'd guess. >> Compared to that, Dscho's "hack" at least ties what PRItime is >> replaced with and what the source code says by being in the >> Makefile, which is tracked alongside the rest of the source. So I >> somehow feel that the approach has smaller chance of going wrong. > > Benefit of using the tweak version of gettext: > > 1. `make pot` can be run in a tar extract directory (without git controlled). > 2. do not need to run `git reset --hard`. > 3. it's quick (nobody cares). This is about a tool and workflow only you (and your successor, when the time comes) need to use, so ultimately I'd prefer to leave it up to you, but I'd want to make sure you are making your decision with sound rationale. I personally do not think 1. and 2. above are real issues in practice, because (1) you'd be committing the result of "make pot" so that translators can work off of it---which at least to me means that being able to run on a tarball extract is not a useful feature, and (2) when you are about to run xgettext to extract strings from the message, you do not want to have local modifications, extracting potentially modified strings with potentially offset line numbers in the resulting pot file, so having to run "git reset --hard" at the end is not a problem. I do not know if 3. is a practical issue or not (I did try "make pot" with the tip of 'master' tonight myself, and I didn't find it much slower than the unmodified one). Having said all that, again, I'd prefer to leave this up to you, so unless I hear that you changed your mind, the tip of 'master' I'll tag, probably sometime tomorrow my time, will have your patch to the Makefile to rely on your private edition of xgettext. Thanks.
[PATCH] Makefile: generate pot file using a tweaked version of xgettext
Instead of doing a sed (s|PRItime|PRIuMAX) in working tree directly, we can use a tweaked version of gettext, which can replace PRItime macro to PRIuMAX (version 1.x) in runtime. We do not need to reset our working tree anymore, and this operation can be run without a version controlled working tree. The tweaked version of gettext is hosted at: https://github.com/jiangxin/gettext Signed-off-by: Jiang Xin --- Makefile | 29 ++--- 1 file changed, 10 insertions(+), 19 deletions(-) diff --git a/Makefile b/Makefile index 461c845d33..782c519133 100644 --- a/Makefile +++ b/Makefile @@ -2221,33 +2221,23 @@ LOCALIZED_SH += t/t0200/test.sh LOCALIZED_PERL += t/t0200/test.perl endif -## Note that this is meant to be run only by the localization coordinator -## under a very controlled condition, i.e. (1) it is to be run in a -## Git repository (not a tarball extract), (2) any local modifications -## will be lost. ## Gettext tools cannot work with our own custom PRItime type, so -## we replace PRItime with PRIuMAX. We need to update this to -## PRIdMAX if we switch to a signed type later. +## we use a hacked version of xgettext to replace PRItime with PRIuMAX. +## We need to update this to PRIdMAX if we switch to a signed type later. -po/git.pot: $(GENERATED_H) FORCE - # All modifications will be reverted at the end, so we do not - # want to have any local change. - git diff --quiet HEAD && git diff --quiet --cached - - @for s in $(LOCALIZED_C) $(LOCALIZED_SH) $(LOCALIZED_PERL); \ - do \ - sed -e 's|PRItime|PRIuMAX|g' <"$$s" >"$$s+" && \ - cat "$$s+" >"$$s" && rm "$$s+"; \ - done +check-xgettext: + @if ! $(XGETTEXT) --version | grep -q "PRItime tweak v1"; then \ + echo >&2 "Error: must use a hacked version of xgettext, which can convert PRItime macro as we need."; \ + echo >&2 "Error: download it from https://github.com/jiangxin/gettext";; \ + exit 1; \ + fi +po/git.pot: check-xgettext $(GENERATED_H) FORCE $(QUIET_XGETTEXT)$(XGETTEXT) -o$@+ $(XGETTEXT_FLAGS_C) $(LOCALIZED_C) $(QUIET_XGETTEXT)$(XGETTEXT) -o$@+ --join-existing $(XGETTEXT_FLAGS_SH) \ $(LOCALIZED_SH) $(QUIET_XGETTEXT)$(XGETTEXT) -o$@+ --join-existing $(XGETTEXT_FLAGS_PERL) \ $(LOCALIZED_PERL) - - # Reverting the munged source, leaving only the updated $@ - git reset --hard mv $@+ $@ .PHONY: pot @@ -2737,6 +2727,7 @@ check-builtins:: .PHONY: coverage coverage-clean coverage-compile coverage-test coverage-report .PHONY: coverage-untested-functions cover_db cover_db_html .PHONY: coverage-clean-results +.PHONY: check-xgettext coverage: $(MAKE) coverage-test -- 2.14.0.rc0.1.g3ccfa2fb49
Re: [PATCH] PRItime: wrap PRItime for better l10n compatibility
2017-07-22 7:34 GMT+08:00 Junio C Hamano : > Jiang Xin writes: > >> A very small hack on gettext. When extract l10n messages to pot file >> with `xgettext`, will grep "PRItime", and do "sed s/PRItime/PRIuMAX" >> inside `xgettext`. >> >> See this patch: >> https://github.com/jiangxin/gettext/commit/b0a726431c93b5a1ca0fe749de376b0752e75fb0 >> ... >> gettext-tools/src/x-c.c | 17 - >> gettext-tools/src/xgettext.c | 2 +- >> 2 files changed, 17 insertions(+), 2 deletions(-) > > I do not think the size of the "hack" is much of an issue. There is > no way you can sell this patch to the upstream, which would mean > that we would have to be relying on our own private edition of the > external tool, and that is what I feel very uncomfortable about. I never think about that, and I won't sell it to the upstream. ;) > You are not passing % through the toolchain and instead > turning it into %, which is less risky than the obvious > alternative, but when we switch to a signed timestamp_t type and > need to change it something else (e.g. PRIdMAX), you'd need to make > sure you update that private edition that matches the source being > compiled. That's why I grep "PRItime to PRIuMAX" from `xgettext --version`. When we need something else, we can tweak the "check-xgettext" task again in Makefile, to match with a grep-"PRItime to PRIdMAX" version of `xgettext`. > You might even be asked to do the po/git.pot thing for > both 'maint' and 'master' at the same time, when the former still > uses unsigned timestamp_t while the latter switched to signed one, > which would mean you'd need two hacked versions of gettext handy and > choose the "right" one. But it is rare to maintain po/git.pot file for 'maint' branch. And if I need, I will switch to a different version of gettext. Makefile will throw a error message, if I use a wrong version of gettext. > Compared to that, Dscho's "hack" at least ties what PRItime is > replaced with and what the source code says by being in the > Makefile, which is tracked alongside the rest of the source. So I > somehow feel that the approach has smaller chance of going wrong. Benefit of using the tweak version of gettext: 1. `make pot` can be run in a tar extract directory (without git controlled). 2. do not need to run `git reset --hard`. 3. it's quick (nobody cares). -- Jiang Xin
Re: [PATCH] PRItime: wrap PRItime for better l10n compatibility
Jiang Xin writes: > A very small hack on gettext. When extract l10n messages to pot file > with `xgettext`, will grep "PRItime", and do "sed s/PRItime/PRIuMAX" > inside `xgettext`. > > See this patch: > https://github.com/jiangxin/gettext/commit/b0a726431c93b5a1ca0fe749de376b0752e75fb0 > ... > gettext-tools/src/x-c.c | 17 - > gettext-tools/src/xgettext.c | 2 +- > 2 files changed, 17 insertions(+), 2 deletions(-) I do not think the size of the "hack" is much of an issue. There is no way you can sell this patch to the upstream, which would mean that we would have to be relying on our own private edition of the external tool, and that is what I feel very uncomfortable about. You are not passing % through the toolchain and instead turning it into %, which is less risky than the obvious alternative, but when we switch to a signed timestamp_t type and need to change it something else (e.g. PRIdMAX), you'd need to make sure you update that private edition that matches the source being compiled. You might even be asked to do the po/git.pot thing for both 'maint' and 'master' at the same time, when the former still uses unsigned timestamp_t while the latter switched to signed one, which would mean you'd need two hacked versions of gettext handy and choose the "right" one. Compared to that, Dscho's "hack" at least ties what PRItime is replaced with and what the source code says by being in the Makefile, which is tracked alongside the rest of the source. So I somehow feel that the approach has smaller chance of going wrong. Am I missing some concerns you had that you think the tweaked gettext would solve better?
Re: [PATCH] PRItime: wrap PRItime for better l10n compatibility
2017-07-22 6:40 GMT+08:00 Junio C Hamano :
> Jiang Xin writes:
>
>> Sorry, I'm late. I want to try a safer way to change PRItime to
>> PRInMax using a hacked version of gettext.
>
> Why? A vanilla version of gettext tool that is fed a known PRIuMAX
> in its input would be a safer choice, I would have thought.
>
> I've already queued the patch you responded to on 'master', but
> haven't tagged -rc1 yet, so it is possible for you to update on top
> of it before -rc1 is tagged. I do not yet understand why you think
> a modified version of gettext would be a safer way to go, though.
>
> Thanks.
A very small hack on gettext. When extract l10n messages to pot file
with `xgettext`, will grep "PRItime", and do "sed s/PRItime/PRIuMAX"
inside `xgettext`.
See this patch:
https://github.com/jiangxin/gettext/commit/b0a726431c93b5a1ca0fe749de376b0752e75fb0
---
gettext-tools/src/x-c.c | 17 -
gettext-tools/src/xgettext.c | 2 +-
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/gettext-tools/src/x-c.c b/gettext-tools/src/x-c.c
index 1844a5df7..51dd0a9bc 100644
--- a/gettext-tools/src/x-c.c
+++ b/gettext-tools/src/x-c.c
@@ -1802,6 +1802,12 @@ phase6_unget (token_ty *tp)
static bool
is_inttypes_macro (const char *name)
{
+ /* PRItime is a maro for timestamp_t in git.git. */
+ if (!strncmp(name, "PRItime", 7))
+{
+ return true;
+}
+
/* Syntax:
P R I { d | i | o | u | x | X }
{ { | LEAST | FAST } { 8 | 16 | 32 | 64 } | MAX | PTR } */
@@ -1843,8 +1849,17 @@ phase8a_get (token_ty *tp)
phase6_get (tp);
if (tp->type == token_type_name && is_inttypes_macro (tp->string))
{
+ char *new_string;
/* Turn PRIdXXX into "". */
- char *new_string = xasprintf ("<%s>", tp->string);
+ if (!strncmp(tp->string, "PRItime", 7))
+{
+ /* Replace PRItime with PRIuMAX for git.git project */
+ new_string = xasprintf ("<%s>", "PRIuMAX");
+}
+ else
+{
+ new_string = xasprintf ("<%s>", tp->string);
+}
free (tp->string);
tp->string = new_string;
tp->comment = add_reference (savable_comment);
diff --git a/gettext-tools/src/xgettext.c b/gettext-tools/src/xgettext.c
index f848d76d1..0350a1bee 100644
--- a/gettext-tools/src/xgettext.c
+++ b/gettext-tools/src/xgettext.c
@@ -676,7 +676,7 @@ main (int argc, char *argv[])
/* Version information requested. */
if (do_version)
{
- printf ("%s (GNU %s) %s\n", basename (program_name),
PACKAGE, VERSION);
+ printf ("%s (GNU %s) %s (PRItime to PRIuMAX for
git.git)\n", basename (program_name), PACKAGE, VERSION);
/* xgettext: no-wrap */
printf (_("Copyright (C) %s Free Software Foundation, Inc.\n\
License GPLv3+: GNU GPL version 3 or later
\n\
--
2.14.0.rc0.1.g3ccfa2fb49
--
蒋鑫
华为技术有限公司
邮件: xin.ji...@huawei.com, worldhello@gmail.com
博客: http://www.worldhello.net/
微博: http://weibo.com/gotgit/
电话: 18601196889
Re: [PATCH] PRItime: wrap PRItime for better l10n compatibility
Jiang Xin writes: > Sorry, I'm late. I want to try a safer way to change PRItime to > PRInMax using a hacked version of gettext. Why? A vanilla version of gettext tool that is fed a known PRIuMAX in its input would be a safer choice, I would have thought. I've already queued the patch you responded to on 'master', but haven't tagged -rc1 yet, so it is possible for you to update on top of it before -rc1 is tagged. I do not yet understand why you think a modified version of gettext would be a safer way to go, though. Thanks.
Re: [PATCH] PRItime: wrap PRItime for better l10n compatibility
2017-07-21 2:19 GMT+08:00 Junio C Hamano : > Junio C Hamano writes: > >> Johannes Schindelin writes: >> >>> But there may be hope. Since the character sequence "PRItime" is highly >>> unlikely to occur in Git's source code in any context other than the >>> format to print/parse timestamp_t, it should be possible to automate a the >>> string replacement >>> >>> git ls-files -z \*.[ch] | >>> xargs -0r sed -i 's/PRItime/PRIuMAX/g' >>> >>> (assuming, of course, that you use GNU sed, not BSD sed, for which the >>> `-i` needs to read `-i ''` instead) as part of the update? >> >> I somehow missed this bit. >> >> Given that this needs to be done only once every release by only one >> person (i.e. the l10n coordinator who updates *.pot file), as long >> as the procedure is automated as much as possible to ease the pain >> for the l10n coordinator and clearly described in the "Maintaining >> the po/git.pot file" section of po/README, something along that line >> does sound like a very tempting approach. If it works well, it is >> certainly much easier for normal developers than the other possible >> alternatives I mentioned in my previous response. > > So, I was offline for most of the day yesterday and with this issue > blocking the release candidate, didn't manage to tag -rc1. > > The use of "make pot" from the top-level is already described in > po/README, so the only thing that we need is something like this > change. I'll follow up this message with a sample output from the > updated process to ask others to sanity check the result (they are > tiny) in a separate message. > > Thanks. > > > Makefile | 10 ++ > 1 file changed, 10 insertions(+) > > diff --git a/Makefile b/Makefile > index ba4359ef8d..7069a12f75 100644 > --- a/Makefile > +++ b/Makefile > @@ -2216,12 +2216,22 @@ LOCALIZED_SH += t/t0200/test.sh > LOCALIZED_PERL += t/t0200/test.perl > endif > > +## Note that this is only meant to run by the localization coordinator > +## under a very controlled condition, i.e. (1) it is to be run in a > +## Git repository (not a tarball extract), (2) any local modifications > +## will be lost. > po/git.pot: $(GENERATED_H) FORCE > + @for s in $(LOCALIZED_C) $(LOCALIZED_SH) $(LOCALIZED_PERL); \ > + do \ > + sed -e 's|PRItime|PRIuMAX|g' <"$$s" >"$$s+" && \ > + cat "$$s+" >"$$s" && rm "$$s+"; \ > + done > $(QUIET_XGETTEXT)$(XGETTEXT) -o$@+ $(XGETTEXT_FLAGS_C) $(LOCALIZED_C) > $(QUIET_XGETTEXT)$(XGETTEXT) -o$@+ --join-existing > $(XGETTEXT_FLAGS_SH) \ > $(LOCALIZED_SH) > $(QUIET_XGETTEXT)$(XGETTEXT) -o$@+ --join-existing > $(XGETTEXT_FLAGS_PERL) \ > $(LOCALIZED_PERL) > + @git reset --hard > mv $@+ $@ > > .PHONY: pot Sorry, I'm late. I want to try a safer way to change PRItime to PRInMax using a hacked version of gettext. We can change Makefile like this: --- a/Makefile +++ b/Makefile @@ -2216,7 +2216,14 @@ LOCALIZED_SH += t/t0200/test.sh LOCALIZED_PERL += t/t0200/test.perl endif -po/git.pot: $(GENERATED_H) FORCE +check_gettext: + @if ! $(XGETTEXT) --version | grep -q -i PRItime; then \ + echo >&2 "Error: must use a hacked xgettext, which can handle PRItime macro properly."; \ + echo >&2 "Error: download the hacked version of gettext from https://github.com/.."; ; \ + exit 1; \ + fi + +po/git.pot: check_gettext $(GENERATED_H) FORCE $(QUIET_XGETTEXT)$(XGETTEXT) -o$@+ $(XGETTEXT_FLAGS_C) $(LOCALIZED_C) $(QUIET_XGETTEXT)$(XGETTEXT) -o$@+ --join-existing $(XGETTEXT_FLAGS_SH) \ $(LOCALIZED_SH) But I'm not sure I can handle this in this very busy weekend. -- Jiang Xin
Re: [RFC PATCH v2 2/4] promised-object, fsck: introduce promised objects
On Fri, 21 Jul 2017 12:24:52 -0400 Ben Peart wrote: > Today we have 3.5 million objects * 30 bytes per entry = 105 MB of > promises. Given the average developer only hydrates 56K files (2 MB > promises) that is 103 MB to download that no one will ever need. We > would like to avoid that if possible as this would be a significant > regression in clone times from where we are today. > > I'm also concerned about the performance of merging in promises given we > have 100M objects today and growing so the number of promises over time > could get pretty large. After some thought, maybe a hybrid solution is best, in which it is permissible but optional for some missing objects to have promises. In that case, it is more of a "size cache" (which stores the type as well) rather than a true promise. When fetching, the client can optionally request for the sizes and types of missing objects. This is good for the large-blob case, in which we can always have size information of missing blobs, and we can subsequently add blob-size filtering (as a parameter) to "git log -S" and friends to avoid needing to resolve a missing object. And this is, as far as I can tell, also good for the many-blob case - just have an empty size cache all the time. (And in the future, use cases could come up that desire non-empty but non-comprehensive caches - for example, a directory lister working on a partial clone that only needs to cache the sizes of frequently accessed directories.) Another option is to have a repo-wide option that toggles between mandatory entries in the "size cache" and prohibited entries. Switching to mandatory provides stricter fsck and negative lookups, but I think it's not worth it for both the developers and users of Git to have to know about these two modes. > >> I think we should have a flag (off by default) that enables someone to > >> say that promised objects are optional. If the flag is set, > >> "is_promised_object" will return success and pass the OBJ_ANY type and a > >> size of -1. > >> > >> Nothing today is using the size and in the two places where the object > >> type is being checked for consistency (fsck_cache_tree and > >> fsck_handle_ref) the test can add a test for OBJ_ANY as well. > >> > >> This will enable very large numbers of objects to be omitted from the > >> clone without triggering a download of the corresponding number of > >> promised objects. > > > > Eventually I plan to use the size when implementing parameters for > > history-searching commands (e.g. "git log -S"), but it's true that > > that's in the future. > > > > Allowing promised objects to be optional would indeed solve the issue of > > downloading too many promises. It would make the code more complicated, > > but I'm not sure by how much. > > > > For example, in this fsck patch, the easiest way I could think of to > > have promised objects was to introduce a 3rd state, called "promised", > > of "struct object" - one in which the type is known, but we don't have > > access to the full "struct commit" or equivalent. And thus fsck could > > assume that if the "struct object" is "parsed" or "promised", the type > > is known. Having optional promised objects would require that we let > > this "promised" state have a type of OBJ_UNKNOWN (or something like > > that) - maybe that would be fine, but I haven't looked into this in > > detail. > > > > Caveats apply as I only did a quick look but I only found the two > locations that were checking the object type for consistency. I haven't looked into detail, but you are probably right.
Re: [PATCH] config.mak.uname: set FREAD_READS_DIRECTORIES for cygwin
Ramsay Jones writes: > Signed-off-by: Ramsay Jones > --- > > Hi Junio, > > My 'make test' run for the v2.14.0-rc0 on cygwin turned up a new > test failure (over and above the v2.13.0 failures), namely t1308.23. > Running the test in the debugger showed that cygwin was fopen-ing > the 'a-directory' without problem. > > On one occasion, while in the debugger, I did see fopen return NULL > while trying to open a directory. So, I created a test program which > showed reliably that fopen succeeds on a directory. (So, maybe I was > just seeing things! :-D ). > > t1308 was reliably failing before this patch, afterwards it reliably > passes, so ... > > [I have a full test run going at the moment, but it won't finish for > about 3 hours.] > > ATB, > Ramsay Jones Thanks. Let's apply it for -rc1. > > config.mak.uname | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/config.mak.uname b/config.mak.uname > index 551e465a7..6604b130f 100644 > --- a/config.mak.uname > +++ b/config.mak.uname > @@ -185,6 +185,7 @@ ifeq ($(uname_O),Cygwin) > SPARSE_FLAGS = -isystem /usr/include/w32api -Wno-one-bit-signed-bitfield > OBJECT_CREATION_USES_RENAMES = UnfortunatelyNeedsTo > COMPAT_OBJS += compat/cygwin.o > + FREAD_READS_DIRECTORIES = UnfortunatelyYes > endif > ifeq ($(uname_S),FreeBSD) > NEEDS_LIBICONV = YesPlease
Re: git gc seems to break --symbolic-full-name
21.07.2017 21:56, Junio C Hamano пишет: Stas Sergeev writes: I do the following: $ git rev-parse --symbolic-full-name devel refs/heads/devel $ ls -l .git/`git rev-parse --symbolic-full-name devel` -rw-rw-r-- 1 stas stas 41 июл 21 15:05 .git/refs/heads/devel This is fine. But after git gc: $ git rev-parse --symbolic-full-name devel refs/heads/devel $ LC_ALL=C ls -l .git/`git rev-parse --symbolic-full-name devel` ls: cannot access '.git/refs/heads/devel': No such file or directory This is expected, and in the modern world (like, after year 2007), a refname "refs/heads/foo" does *not* mean that there is a file with such a path under .git/ directory. "rev-parse" does not return any "path" in the filesystem sense. See "git pack-refs --help", and depending on what you want to learn about the ref in question, perhaps "git show-ref refs/heads/devel" is what you want. I wanted some kind of file to use it as a build dependency for the files that needs to be re-built when the head changes. This works very well besides git gc. What other method can be used as simply as that? git show-ref does not seem to be giving this.
Re: git gc seems to break --symbolic-full-name
Stas Sergeev writes: > I do the following: > > $ git rev-parse --symbolic-full-name devel > refs/heads/devel > $ ls -l .git/`git rev-parse --symbolic-full-name devel` > -rw-rw-r-- 1 stas stas 41 июл 21 15:05 .git/refs/heads/devel > > This is fine. But after git gc: > > $ git rev-parse --symbolic-full-name devel > refs/heads/devel > $ LC_ALL=C ls -l .git/`git rev-parse --symbolic-full-name devel` > ls: cannot access '.git/refs/heads/devel': No such file or directory This is expected, and in the modern world (like, after year 2007), a refname "refs/heads/foo" does *not* mean that there is a file with such a path under .git/ directory. "rev-parse" does not return any "path" in the filesystem sense. See "git pack-refs --help", and depending on what you want to learn about the ref in question, perhaps "git show-ref refs/heads/devel" is what you want.
[PATCH] config.mak.uname: set FREAD_READS_DIRECTORIES for cygwin
Signed-off-by: Ramsay Jones --- Hi Junio, My 'make test' run for the v2.14.0-rc0 on cygwin turned up a new test failure (over and above the v2.13.0 failures), namely t1308.23. Running the test in the debugger showed that cygwin was fopen-ing the 'a-directory' without problem. On one occasion, while in the debugger, I did see fopen return NULL while trying to open a directory. So, I created a test program which showed reliably that fopen succeeds on a directory. (So, maybe I was just seeing things! :-D ). t1308 was reliably failing before this patch, afterwards it reliably passes, so ... [I have a full test run going at the moment, but it won't finish for about 3 hours.] ATB, Ramsay Jones config.mak.uname | 1 + 1 file changed, 1 insertion(+) diff --git a/config.mak.uname b/config.mak.uname index 551e465a7..6604b130f 100644 --- a/config.mak.uname +++ b/config.mak.uname @@ -185,6 +185,7 @@ ifeq ($(uname_O),Cygwin) SPARSE_FLAGS = -isystem /usr/include/w32api -Wno-one-bit-signed-bitfield OBJECT_CREATION_USES_RENAMES = UnfortunatelyNeedsTo COMPAT_OBJS += compat/cygwin.o + FREAD_READS_DIRECTORIES = UnfortunatelyYes endif ifeq ($(uname_S),FreeBSD) NEEDS_LIBICONV = YesPlease -- 2.13.0
Re: Binary files
On 20/07/2017 22:40, Junio C Hamano wrote: > Igor Djordjevic writes: >> On 20/07/2017 09:41, Volodymyr Sendetskyi wrote: >>> It is known, that git handles badly storing binary files in its >>> repositories at all. >>> This is especially about large files: even without any changes to >>> these files, their copies are snapshotted on each commit. So even >>> repositories with a small amount of code can grove very fast in size >>> if they contain some great binary files. Alongside this, the SVN is >>> much better about that, because it make changes to the server version >>> of file only if some changes were done. >> >> You already got some proposals on what you could try for making large >> binary files handling easier, but I just wanted to comment on this >> part of your message, as it doesn`t seem to be correct. > > All correct. Thanks. No problem, thanks for confirmation, being relatively new around it`s appreciated, at least knowing that I got it correct myself :)
git gc seems to break --symbolic-full-name
Hello. I do the following: $ git rev-parse --symbolic-full-name devel refs/heads/devel $ ls -l .git/`git rev-parse --symbolic-full-name devel` -rw-rw-r-- 1 stas stas 41 июл 21 15:05 .git/refs/heads/devel This is fine. But after git gc: $ git rev-parse --symbolic-full-name devel refs/heads/devel $ LC_ALL=C ls -l .git/`git rev-parse --symbolic-full-name devel` ls: cannot access '.git/refs/heads/devel': No such file or directory This is because after git gc there is nothing in .git/refs/heads: $ LC_ALL=C ls -l .git/refs/heads/ total 8 drwxrwxr-x 2 stas stas 4096 Jul 31 2013 feature drwxrwxr-x 2 stas stas 4096 Dec 23 2016 pr I prepend the path with .git above just as an example: the same happens with rev-parse --git-path. So I wonder if it is an expected behaviour for --symbolic-full-name to return the invalid pathes? If so, how can I get the path to the needed head file? I use that for dependency tracking.
Re: fatal: bad numeric config value '60 days' for 'gc.rerereresolved': invalid unit
Yeah, after I checked the code I saw that this is interpreted as integer and fixed my configuration 2017-07-21 16:33 GMT+02:00 Junio C Hamano : > Uwe Hausbrand writes: > >> seems like there is a bug with "git rerere gc" not understanding grace >> periods like "60 days" defined in the config. >> >> What I did: >> >> git config gc.rerereresolved "60 days" > > Let's see how the variable is explained in the documentation. > > gc.rerereResolved:: > Records of conflicted merge you resolved earlier are > kept for this many days when 'git rerere gc' is run. > The default is 60 days. See linkgit:git-rerere[1]. > > Notice that "for this many days" tries to (and probably > unsuccessfully) tell you that this variable is expected to be set to > an integer [*1*], counted in "days". IOW, you'd want "60" instead. > > Having said that, it may not be a bad idea to enumerate these > "expected to be an integer that counts in some unit" variables that > are described in a similar way (i.e. look for "this many" in > Documentation/config.txt), and then for each of them that could be > counted in different unit (e.g. it is not outrageously wrong to > expect that you could specify that rerere records that are older > than 3 months are expired): > > - decide what kind of quantity the variable specifies (e.g. "this >many days" and "this many seconds" variables are giving a >"timeperiod"). > > - keep the code that reacts to an integer without any unit to >behave the same (e.g. "[gc] rerereresolved = 30" will keep >meaning "30 days"); > > - extend the code so that when the value given is not an integer, >it tries to parse it as a specification for the expected quantity >(e.g. "this many days" and "this many seconds" variables would >understand if you said "60 days" or "2 months") > > > [Footnote] > > *1* I think we actually expect a scaled integer whenever we expect > an integral value, so you probably could say "6k" to specify > "6,000 days"; "days" not being any of the recognised unit > suffix like k, M, G, etc. is where "invalid unit" comes from.
Re: [PATCH v2] l10n: de.po: update German translation
Ralf Thielow writes: > after applying the patch, entries in date.c turned into this > > -#: date.c:122 date.c:129 date.c:136 date.c:143 date.c:149 date.c:156 > date.c:167 > -#: date.c:175 date.c:180 > -msgid "%" > -msgid_plural "%" > -msgstr[0] "%" > -msgstr[1] "%" > +#: date.c:122 > +#, fuzzy, c-format > +msgid "% second ago" > +msgid_plural "% seconds ago" > +msgstr[0] "vor %lu Sekunde" > +msgstr[1] "vor %lu Sekunden" > ... > > which seems to be OK. A full diff after updating de.po after this > patch can be found at https://pastebin.com/5yeSnGQj. > > Ralf Thanks for a quick report.
[PATCH v3] l10n: de.po: update German translation
Signed-off-by: Ralf Thielow --- v3 contains updated translations in date.c where %lu turned into %. po/de.po | 169 --- 1 file changed, 87 insertions(+), 82 deletions(-) diff --git a/po/de.po b/po/de.po index 347166240..283e68627 100644 --- a/po/de.po +++ b/po/de.po @@ -176,26 +176,26 @@ msgid "git apply: bad git-diff - inconsistent old filename on line %d" msgstr "" "git apply: ungültiges 'git-diff' - Inkonsistenter alter Dateiname in Zeile %d" #: apply.c:979 #, c-format msgid "git apply: bad git-diff - expected /dev/null on line %d" msgstr "git apply: ungültiges 'git-diff' - erwartete /dev/null in Zeile %d" #: apply.c:1008 -#, fuzzy, c-format +#, c-format msgid "invalid mode on line %d: %s" -msgstr "Ungültige Identifikationszeile: %s" +msgstr "Ungültiger Modus in Zeile %d: %s" #: apply.c:1326 #, c-format msgid "inconsistent header lines %d and %d" -msgstr "" +msgstr "Inkonsistente Kopfzeilen %d und %d." #: apply.c:1498 #, c-format msgid "recount: unexpected line: %.*s" msgstr "recount: unerwartete Zeile: %.*s" #: apply.c:1567 #, c-format msgid "patch fragment without header at line %d: %.*s" @@ -1525,80 +1525,80 @@ msgstr "" #, c-format msgid "LF would be replaced by CRLF in %s" msgstr "LF würde in %s durch CRLF ersetzt werden." #: date.c:116 msgid "in the future" msgstr "in der Zukunft" #: date.c:122 -#, fuzzy, c-format +#, c-format msgid "% second ago" msgid_plural "% seconds ago" -msgstr[0] "vor %lu Sekunde" -msgstr[1] "vor %lu Sekunden" +msgstr[0] "vor % Sekunde" +msgstr[1] "vor % Sekunden" #: date.c:129 -#, fuzzy, c-format +#, c-format msgid "% minute ago" msgid_plural "% minutes ago" -msgstr[0] "vor %lu Minute" -msgstr[1] "vor %lu Minuten" +msgstr[0] "vor % Minute" +msgstr[1] "vor % Minuten" #: date.c:136 -#, fuzzy, c-format +#, c-format msgid "% hour ago" msgid_plural "% hours ago" -msgstr[0] "vor %lu Stunde" -msgstr[1] "vor %lu Stunden" +msgstr[0] "vor % Stunde" +msgstr[1] "vor % Stunden" #: date.c:143 -#, fuzzy, c-format +#, c-format msgid "% day ago" msgid_plural "% days ago" -msgstr[0] "vor %lu Tag" -msgstr[1] "vor %lu Tagen" +msgstr[0] "vor % Tag" +msgstr[1] "vor % Tagen" #: date.c:149 -#, fuzzy, c-format +#, c-format msgid "% week ago" msgid_plural "% weeks ago" -msgstr[0] "vor %lu Woche" -msgstr[1] "vor %lu Wochen" +msgstr[0] "vor % Woche" +msgstr[1] "vor % Wochen" #: date.c:156 -#, fuzzy, c-format +#, c-format msgid "% month ago" msgid_plural "% months ago" -msgstr[0] "vor %lu Monat" -msgstr[1] "vor %lu Monaten" +msgstr[0] "vor % Monat" +msgstr[1] "vor % Monaten" #: date.c:167 -#, fuzzy, c-format +#, c-format msgid "% year" msgid_plural "% years" -msgstr[0] "vor %lu Jahr" -msgstr[1] "vor %lu Jahren" +msgstr[0] "vor % Jahr" +msgstr[1] "vor % Jahren" #. TRANSLATORS: "%s" is " years" #: date.c:170 -#, fuzzy, c-format +#, c-format msgid "%s, % month ago" msgid_plural "%s, % months ago" -msgstr[0] "%s, und %lu Monat" -msgstr[1] "%s, und %lu Monaten" +msgstr[0] "%s, und % Monat" +msgstr[1] "%s, und % Monaten" #: date.c:175 date.c:180 -#, fuzzy, c-format +#, c-format msgid "% year ago" msgid_plural "% years ago" -msgstr[0] "vor %lu Jahr" -msgstr[1] "vor %lu Jahren" +msgstr[0] "vor % Jahr" +msgstr[1] "vor % Jahren" #: diffcore-order.c:24 #, c-format msgid "failed to read orderfile '%s'" msgstr "Fehler beim Lesen der Reihenfolgedatei '%s'." #: diffcore-rename.c:536 msgid "Performing inexact rename detection" msgstr "Führe Erkennung für ungenaue Umbenennung aus" @@ -1940,53 +1940,50 @@ msgid "" msgstr "" "'%s' scheint ein git-Befehl zu sein, konnte aber\n" "nicht ausgeführt werden. Vielleicht ist git-%s fehlerhaft?" #: help.c:336 msgid "Uh oh. Your system reports no Git commands at all." msgstr "Uh oh. Keine Git-Befehle auf Ihrem System vorhanden." #: help.c:358 -#, fuzzy, c-format +#, c-format msgid "WARNING: You called a Git command named '%s', which does not exist." -msgstr "" -"Warnung: Sie haben den nicht existierenden Git-Befehl '%s' ausgeführt.\n" -"Setze fort unter der Annahme, dass Sie '%s' gemeint haben." +msgstr "WARNUNG: Sie haben Git-Befehl '%s' ausgeführt, welcher nicht existiert." #: help.c:363 #, c-format msgid "Continuing under the assumption that you meant '%s'." -msgstr "" +msgstr "Setze fort unter der Annahme, dass Sie '%s' meinten." #: help.c:368 #, c-format msgid "Continuing in %0.1f seconds, assuming that you meant '%s'." -msgstr "" +msgstr "Setze in %0.1f Sekunden fort unter der Annahme, dass Sie '%s' meinten." #: help.c:376 #, c-format msgid "git: '%s' is not a git command. See 'git --help'." msgstr "git: '%s' ist kein Git-Befehl. Siehe 'git --help'." #: help.c:380 msgid "" "\n" "The most similar command is" msgid_plural "" "\n" "The most similar commands are" -msgstr[0] "" -msgstr[1] "" +msgstr[0] "\nDer ähnlichste Befehl ist" +msgstr[1] "\nDie ähnlichsten Befehle sind" #: help.
Re: [PATCH] refs: use skip_prefix() in ref_is_hidden()
Christian Couder writes:
> This saves one line, makes the code a bit easier to understand
> and perhaps a bit faster too.
>
> Signed-off-by: Christian Couder
> ---
> refs.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/refs.c b/refs.c
> index ba22f4acef..15cb36d426 100644
> --- a/refs.c
> +++ b/refs.c
> @@ -1160,7 +1160,7 @@ int ref_is_hidden(const char *refname, const char
> *refname_full)
> const char *match = hide_refs->items[i].string;
> const char *subject;
> int neg = 0;
> - int len;
> + const char *p;
>
> if (*match == '!') {
> neg = 1;
> @@ -1175,10 +1175,9 @@ int ref_is_hidden(const char *refname, const char
> *refname_full)
> }
>
> /* refname can be NULL when namespaces are used. */
> - if (!subject || !starts_with(subject, match))
> + if (!subject || !skip_prefix(subject, match, &p))
> continue;
> - len = strlen(match);
> - if (!subject[len] || subject[len] == '/')
> + if (!*p || *p == '/')
> return !neg;
> }
> return 0;
If we were to rewrite this using skip_prefix(), I would imagine we
would rather write it this way:
if (subject &&
skip_prefix(subject, match, &p) &&
(*p || *p != '/'))
return !neg;
because it would be shorter and make the logic easier to follow:
We make the final decision only when "subject" is there, its
early part matches "match", and the match is at the slash
boundary (or the whole thing).
The original wanted to say the same thing, but it had to split that
logic into two only because it needed an assignment to "len" in the
middle, and because doing an assignment inside a conditional part of
if() statement is frowned upon.
Re: Reducing redundant build at Travis?
Lars Schneider writes:
> To answer your question: I don't see an easy solution to the problem.
That's OK. Thanks for digging.
I am wondering if the attached would be acceptable as a minimum
impact patch to address this issue.
I think I got the "are we building a tag, or are we building a
branch that happens to be at a tag?" logic right, but I have no idea
what I am writing in the "script" sections (I am just assuming that
these lines are squashed into a line by removing line-breaks and
become a single lng shell script), and can certainly use guiding
hands. I didn't bother skipping the work done in before_script.
Thanks.
diff --git a/.travis.yml b/.travis.yml
index 278943d14a..55af619830 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -53,6 +53,7 @@ matrix:
script:
- >
test "$TRAVIS_REPO_SLUG" != "git/git" ||
+ ci/skip-branch-tip-with-tag.sh ||
ci/run-windows-build.sh $TRAVIS_BRANCH $(git rev-parse HEAD)
after_failure:
- env: Linux32
@@ -65,6 +66,7 @@ matrix:
before_script:
script:
- >
+ ci/skip-branch-tip-with-tag.sh ||
docker run
--interactive
--env DEVELOPER
@@ -145,9 +147,10 @@ before_script: make --jobs=2
script:
- >
+ci/skip-branch-tip-with-tag.sh || {
mkdir -p $HOME/travis-cache;
ln -s $HOME/travis-cache/.prove t/.prove;
-make --quiet test;
+make --quiet test; }
after_failure:
- >
diff --git a/ci/skip-branch-tip-with-tag.sh b/ci/skip-branch-tip-with-tag.sh
new file mode 100755
index 00..a57e724b35
--- /dev/null
+++ b/ci/skip-branch-tip-with-tag.sh
@@ -0,0 +1,23 @@
+#!/bin/sh
+
+# Sometimes, a branch is pushed at the same time the tag that points
+# at the same commit as the tip of the branch is pushed, and building
+# both at the same time is a waste.
+#
+# Travis gives a tagname e.g. v2.14.0 in $TRAVIS_BRANCH when
+# the build is triggered by a push to a tag. Let's see if
+# $TRAVIS_BRANCH is exactly at a tag, and if so, if it is
+# different from $TRAVIS_BRANCH. That way, we can tell if
+# we are building the tip of a branch that is tagged---and
+# we can skip the build because we won't be skipping a build
+# of a tag.
+
+if TAG=$(git describe --exact-match "$TRAVIS_BRANCH" 2>/dev/null) &&
+ $TAG != $TRAVIS_BRANCH
+then
+ echo "Tip of $TRAVIS_BRANCH is exactly at $TAG"
+ exit 0
+else
+ exit 1
+fi
+
Re: [PATCH v2] l10n: de.po: update German translation
Hi, after applying the patch, entries in date.c turned into this -#: date.c:122 date.c:129 date.c:136 date.c:143 date.c:149 date.c:156 date.c:167 -#: date.c:175 date.c:180 -msgid "%" -msgid_plural "%" -msgstr[0] "%" -msgstr[1] "%" +#: date.c:122 +#, fuzzy, c-format +msgid "% second ago" +msgid_plural "% seconds ago" +msgstr[0] "vor %lu Sekunde" +msgstr[1] "vor %lu Sekunden" ... which seems to be OK. A full diff after updating de.po after this patch can be found at https://pastebin.com/5yeSnGQj. Ralf 2017-07-21 18:10 GMT+02:00 Junio C Hamano : > Ralf Thielow writes: > >> #: date.c:116 >> msgid "in the future" >> msgstr "in der Zukunft" >> >> #: date.c:122 date.c:129 date.c:136 date.c:143 date.c:149 date.c:156 >> date.c:167 >> #: date.c:175 date.c:180 >> msgid "%" >> msgid_plural "%" >> -msgstr[0] "" >> -msgstr[1] "" >> +msgstr[0] "%" >> +msgstr[1] "%" > > Sorry, but I think these need re-translation after -rc1 because the po/git.pot > is generated incorrectly. See the discussion: > > > https://public-inbox.org/git/%3cxmqqk233klvd@gitster.mtv.corp.google.com%3E/#t > > Also, if you can, please try the patch in > > > > like so: > > $ git reset --hard origin/master > $ git am > $ make pot > $ git commit -m 'update po/git.pot' -a > $ cd po > $ msgmerge --add-location --backup-off -U de.po git.pot > > to make sure you get corrected entries for date.c. If it works out > correctly, I'd want to ship -rc1 with that Makefile fix so that > Jiang can do the first four commands above to give translators a > correct po/git.pot to base their work on. > > Thanks. >
Re: [RFC PATCH v2 4/4] sha1_file: support promised object hook
On 7/20/2017 5:18 PM, Jonathan Tan wrote:
On Thu, 20 Jul 2017 16:58:16 -0400
Ben Peart wrote:
This is meant as a temporary measure to ensure that all Git commands
work in such a situation. Future patches will update some commands to
either tolerate promised objects (without invoking the hook) or be more
efficient in invoking the promised objects hook.
I agree that making git more tolerant of promised objects if possible
and precomputing a list of promised objects required to complete a
particular command and downloading them with a single request are good
optimizations to add over time.
That's good to know!
has_sha1_file also takes a hash "whether local or in an alternate object
database, and whether packed or loose" but never calls
sha1_object_info_extended. As a result, we had to add support in
check_and_freshen to download missing objects to get proper behavior in
all cases. I don't think this will work correctly without it.
Thanks for the attention to detail. Is this before or after commit
e83e71c ("sha1_file: refactor has_sha1_file_with_flags", 2017-06-26)?
Sorry, my bad. I missed the comment in the cover letter that said this
needed to be applied on top of your other patch series.
Re: [RFC PATCH v2 2/4] promised-object, fsck: introduce promised objects
On 7/20/2017 5:13 PM, Jonathan Tan wrote:
On Thu, 20 Jul 2017 15:58:51 -0400
Ben Peart wrote:
On 7/19/2017 8:21 PM, Jonathan Tan wrote:
Currently, Git does not support repos with very large numbers of objects
or repos that wish to minimize manipulation of certain blobs (for
example, because they are very large) very well, even if the user
operates mostly on part of the repo, because Git is designed on the
assumption that every referenced object is available somewhere in the
repo storage.
Great to see this idea making progress. Making git able to gracefully
handle partial clones (beyond the existing shallow clone support) is a
key piece of dealing with very large objects and repos.
Thanks.
As a first step to reducing this problem, introduce the concept of
promised objects. Each Git repo can contain a list of promised objects
and their sizes (if blobs) at $GIT_DIR/objects/promised. This patch
contains functions to query them; functions for creating and modifying
that file will be introduced in later patches.
If I'm reading this patch correctly, for a repo to successfully pass
"git fsck" either the object or a promise must exist for everything fsck
checks. From the documentation for fsck it says "git fsck defaults to
using the index file, all SHA-1 references in refs namespace, and all
reflogs (unless --no-reflogs is given) as heads." Doesn't this then
imply objects or promises must exist for all objects referenced by any
of these locations?
We're currently in the hundreds of millions of objects on some of our
repos so even downloading the promises for all the objects in the index
is unreasonable as it is gigabytes of data and growing.
For the index to contain all the files, the repo must already have
downloaded all the trees for HEAD (at least). The trees collectively
contain entries for all the relevant blobs. We need one promise for each
blob, and the size of a promise is comparable to the size of a tree
entry, so the size (of download and storage) needed would be just double
of what we would need if we didn't need promises. This is still only
linear growth, unless you have found that the absolute numbers are too
large?
Today we have 3.5 million objects * 30 bytes per entry = 105 MB of
promises. Given the average developer only hydrates 56K files (2 MB
promises) that is 103 MB to download that no one will ever need. We
would like to avoid that if possible as this would be a significant
regression in clone times from where we are today.
I'm also concerned about the performance of merging in promises given we
have 100M objects today and growing so the number of promises over time
could get pretty large.
Also, if the index is ever changed to not have one entry for every file,
we also wouldn't need one promise for every file.
I think we should have a flag (off by default) that enables someone to
say that promised objects are optional. If the flag is set,
"is_promised_object" will return success and pass the OBJ_ANY type and a
size of -1.
Nothing today is using the size and in the two places where the object
type is being checked for consistency (fsck_cache_tree and
fsck_handle_ref) the test can add a test for OBJ_ANY as well.
This will enable very large numbers of objects to be omitted from the
clone without triggering a download of the corresponding number of
promised objects.
Eventually I plan to use the size when implementing parameters for
history-searching commands (e.g. "git log -S"), but it's true that
that's in the future.
Allowing promised objects to be optional would indeed solve the issue of
downloading too many promises. It would make the code more complicated,
but I'm not sure by how much.
For example, in this fsck patch, the easiest way I could think of to
have promised objects was to introduce a 3rd state, called "promised",
of "struct object" - one in which the type is known, but we don't have
access to the full "struct commit" or equivalent. And thus fsck could
assume that if the "struct object" is "parsed" or "promised", the type
is known. Having optional promised objects would require that we let
this "promised" state have a type of OBJ_UNKNOWN (or something like
that) - maybe that would be fine, but I haven't looked into this in
detail.
Caveats apply as I only did a quick look but I only found the two
locations that were checking the object type for consistency.
A repository that is missing an object but has that object promised is not
considered to be in error, so also teach fsck this. As part of doing
this, object.{h,c} has been modified to generate "struct object" based
on only the information available to promised objects, without requiring
the object itself.
In your work on this, did you investigate if there are other commands
(ie repack/gc) that will need to learn about promised objects? Have you
had a chance (or have plans) to hack up the test suite so that it runs
all tests with promised objects and see what (if anything) breaks?
Re: Reducing redundant build at Travis?
> On 20 Jul 2017, at 17:16, Junio C Hamano wrote: > > Lars Schneider writes: > >>> On 14 Jul 2017, at 17:32, Jeff King wrote: >>> >>> I don't know if Travis's cache storage is up to that challenge. We could >>> probably build such a lock on top of third-party storage, but things are >>> rapidly getting more complex. >> >> I think we shouldn't go there because of the complexity. I reached out >> to TravisCI and asked about the "hash build twice" problem [1]. >> Unfortunately, >> I got no response, yet. The issue could also be considered a feature as you >> could perform different actions in your TravisCI configuration based on >> the branch name. > > Oh, no doubt that it is a feature, and a very useful one at that. > With that, we can change actions depending on the branch name in > such a way that normally we do our build and test, but when we are > on a branch (not testing a tag) and its tip is tagged, we become > no-op to avoid the cost of testing. That is the feature we exactly > want. > > The question I had, and wanted a help from you, was if there was a > way we can write that "are we on a branch (not testing a tag) and is > its tip tagged?" test only once in .travis.yml, even though we have > quite a many items in the matrix. With the current way .travis.yml > is laid out, without such a facility, we'd need the logic sprinkled > to at the beginning of all "before_install:" or something like that, > which is not quite optimal. To answer your question: I don't see an easy solution to the problem. However, maybe it is solvable with a creative usage of "build-stages"? https://blog.travis-ci.com/2017-05-11-introducing-build-stages Sorry, Lars
Re: [PATCH v2] l10n: de.po: update German translation
Ralf Thielow writes: > #: date.c:116 > msgid "in the future" > msgstr "in der Zukunft" > > #: date.c:122 date.c:129 date.c:136 date.c:143 date.c:149 date.c:156 > date.c:167 > #: date.c:175 date.c:180 > msgid "%" > msgid_plural "%" > -msgstr[0] "" > -msgstr[1] "" > +msgstr[0] "%" > +msgstr[1] "%" Sorry, but I think these need re-translation after -rc1 because the po/git.pot is generated incorrectly. See the discussion: https://public-inbox.org/git/%3cxmqqk233klvd@gitster.mtv.corp.google.com%3E/#t Also, if you can, please try the patch in like so: $ git reset --hard origin/master $ git am $ make pot $ git commit -m 'update po/git.pot' -a $ cd po $ msgmerge --add-location --backup-off -U de.po git.pot to make sure you get corrected entries for date.c. If it works out correctly, I'd want to ship -rc1 with that Makefile fix so that Jiang can do the first four commands above to give translators a correct po/git.pot to base their work on. Thanks.
Re: [PATCH] git-contacts: Add recognition of Reported-by
Eric Blake writes: > You mean, something like > > git config --add contacts.autocc Reported-by > git config --add contacts.autocc Suggested-by > > where contacts.autocc would be a new multi-valued config option > specifying additional Tag: patterns to scrape out of the commit message? Yes, something along that line, and you are correct to point out that I should have mentioned the need for command-line override. In fact, if you anticipate that the primary use of this contributed script is as "send-email --cccmd", then we probably are better off doing this without any configuration variables, but just add the mechanism for command-line override of the hardcoded default. I also should have mentioned the need for a way to say "remove all hardcoded default and start from scratch". > Also, putting it in 'git config' still means that it is a per-developer > responsibility to choose which patterns to add to their list. Is there > any easy way to make a particular repository supply the same list for > all developers who check it out, without them having to munge things? That is a good point, but we should be very careful. "Let's add whatever configuration the project supplies to the user's repository upon cloning" is an absolute no-no, as a malicious project can ship something like [alias] "co" = "!rm -rf ." and unsuspecting victim to blindly add it to the configuration. A standard practice we encourage is to ship a file that records the suggested set of configuration variables as part of the source tree and mention how to add these to their repository in README (which you are already using to talk about how to contribute to the project, etc.). That would give them a chance to inspect what potential damage the project suggestion will make to their environment (hopefully, there is none, but the user must be given a chance to ensure that). The extra lines you may need in your README may become something like Run this in your copy of the project: $ git config sendemail.cccmd "git contact --cc Suggested-by" with such a scheme.
Re: [PATCH] git-contacts: Add recognition of Reported-by
On 07/21/2017 09:37 AM, Junio C Hamano wrote:
> Eric Blake writes:
>
>> It's nice to cc someone that reported a bug, in order to let
>> them know that a fix is being considered, and possibly even
>> get their help in reviewing/testing the patch.
>>
>> Signed-off-by: Eric Blake
>> ---
>
> I don't know if this new one deserves to be part of the hardcoded
> defaults; it would be different between the projects and depends on
> their convention. I notice that there is no way to configure this
> script and I suspect that it would be a more generally useful update
> to have it read a configuration variable that lists what kind of sob
> like things to take addresses from.
You mean, something like
git config --add contacts.autocc Reported-by
git config --add contacts.autocc Suggested-by
where contacts.autocc would be a new multi-valued config option
specifying additional Tag: patterns to scrape out of the commit message?
The idea seems reasonable, except that I have less experience with
writing patches that interact with git config than I do for my one-liner
attempt, so I would welcome any help from someone with more familiarity
with the code base.
Also, putting it in 'git config' still means that it is a per-developer
responsibility to choose which patterns to add to their list. Is there
any easy way to make a particular repository supply the same list for
all developers who check it out, without them having to munge things?
Also, I'm worried about sendemail.cccmd - that's a script that could
usefully call 'git contacts' under the hood, but that argues that there
should be a command-line override (and not just 'git config') for
choosing an alternative list of autocc tag patterns on a per-invocation
basis. Again, it requires a per-developer setup to wire in a cccmd, but
telling developers a one-liner config to set up the command is easier
than telling them multiple lines for contacts.autocc.
And while we're on the topic of per-project useful defaults, it would be
nice if diff.orderFile could easily be set to a per-project default,
rather than requiring per-developer efforts to set that up.
But yes, I _definitely_ want to be able for a given project to easily
autocc the tags that it finds appropriate. Your point that different
projects have different tags makes total sense (I'm hoping to use
Suggested-by as one of the tags in qemu, but agree that it is not as
easy to argue that Suggested-by should be in the hardcoded defaults,
which is why my initial submission only added Reported-by).
>
> Thanks.
>
>> contrib/contacts/git-contacts | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/contrib/contacts/git-contacts b/contrib/contacts/git-contacts
>> index dbe2abf27..85ad732fc 100755
>> --- a/contrib/contacts/git-contacts
>> +++ b/contrib/contacts/git-contacts
>> @@ -11,7 +11,7 @@ use IPC::Open2;
>>
>> my $since = '5-years-ago';
>> my $min_percent = 10;
>> -my $labels_rx = qr/Signed-off-by|Reviewed-by|Acked-by|Cc/i;
>> +my $labels_rx = qr/Signed-off-by|Reviewed-by|Acked-by|Cc|Reported-by/i;
>> my %seen;
>>
>> sub format_contact {
>
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
[PATCH v2] l10n: de.po: update German translation
Signed-off-by: Ralf Thielow --- Hi Matthias, 2017-07-20 20:36 GMT+02:00 Matthias Rüster : > Hi Ralf, > > I think the following should be "hinzugefügt": > Sure. Thanks for review! Ciao, Ralf po/de.po | 123 +-- 1 file changed, 64 insertions(+), 59 deletions(-) diff --git a/po/de.po b/po/de.po index 5619fa962..f905c7ec7 100644 --- a/po/de.po +++ b/po/de.po @@ -176,26 +176,26 @@ msgid "git apply: bad git-diff - inconsistent old filename on line %d" msgstr "" "git apply: ungültiges 'git-diff' - Inkonsistenter alter Dateiname in Zeile %d" #: apply.c:979 #, c-format msgid "git apply: bad git-diff - expected /dev/null on line %d" msgstr "git apply: ungültiges 'git-diff' - erwartete /dev/null in Zeile %d" #: apply.c:1008 -#, fuzzy, c-format +#, c-format msgid "invalid mode on line %d: %s" -msgstr "Ungültige Identifikationszeile: %s" +msgstr "Ungültiger Modus in Zeile %d: %s" #: apply.c:1326 #, c-format msgid "inconsistent header lines %d and %d" -msgstr "" +msgstr "Inkonsistente Kopfzeilen %d und %d." #: apply.c:1498 #, c-format msgid "recount: unexpected line: %.*s" msgstr "recount: unerwartete Zeile: %.*s" #: apply.c:1567 #, c-format msgid "patch fragment without header at line %d: %.*s" @@ -1528,27 +1528,27 @@ msgstr "LF würde in %s durch CRLF ersetzt werden." #: date.c:116 msgid "in the future" msgstr "in der Zukunft" #: date.c:122 date.c:129 date.c:136 date.c:143 date.c:149 date.c:156 date.c:167 #: date.c:175 date.c:180 msgid "%" msgid_plural "%" -msgstr[0] "" -msgstr[1] "" +msgstr[0] "%" +msgstr[1] "%" #. TRANSLATORS: "%s" is " years" #: date.c:170 msgid "%s, %" msgid_plural "%s, %" -msgstr[0] "" -msgstr[1] "" +msgstr[0] "%s, %" +msgstr[1] "%s, %" #: diffcore-order.c:24 #, c-format msgid "failed to read orderfile '%s'" msgstr "Fehler beim Lesen der Reihenfolgedatei '%s'." #: diffcore-rename.c:536 msgid "Performing inexact rename detection" msgstr "Führe Erkennung für ungenaue Umbenennung aus" @@ -1890,53 +1890,50 @@ msgid "" msgstr "" "'%s' scheint ein git-Befehl zu sein, konnte aber\n" "nicht ausgeführt werden. Vielleicht ist git-%s fehlerhaft?" #: help.c:336 msgid "Uh oh. Your system reports no Git commands at all." msgstr "Uh oh. Keine Git-Befehle auf Ihrem System vorhanden." #: help.c:358 -#, fuzzy, c-format +#, c-format msgid "WARNING: You called a Git command named '%s', which does not exist." -msgstr "" -"Warnung: Sie haben den nicht existierenden Git-Befehl '%s' ausgeführt.\n" -"Setze fort unter der Annahme, dass Sie '%s' gemeint haben." +msgstr "WARNUNG: Sie haben Git-Befehl '%s' ausgeführt, welcher nicht existiert." #: help.c:363 #, c-format msgid "Continuing under the assumption that you meant '%s'." -msgstr "" +msgstr "Setze fort unter der Annahme, dass Sie '%s' meinten." #: help.c:368 #, c-format msgid "Continuing in %0.1f seconds, assuming that you meant '%s'." -msgstr "" +msgstr "Setze in %0.1f Sekunden fort unter der Annahme, dass Sie '%s' meinten." #: help.c:376 #, c-format msgid "git: '%s' is not a git command. See 'git --help'." msgstr "git: '%s' ist kein Git-Befehl. Siehe 'git --help'." #: help.c:380 msgid "" "\n" "The most similar command is" msgid_plural "" "\n" "The most similar commands are" -msgstr[0] "" -msgstr[1] "" +msgstr[0] "\nDer ähnlichste Befehl ist" +msgstr[1] "\nDie ähnlichsten Befehle sind" #: help.c:395 -#, fuzzy msgid "git version []" -msgstr "git column []" +msgstr "git version []" #: help.c:456 #, c-format msgid "%s: %s - %s" msgstr "%s: %s - %s" #: help.c:460 msgid "" "\n" @@ -3361,21 +3358,21 @@ msgstr "" "Ausführung erfolgreich: %s\n" "Aber Änderungen in Index oder Arbeitsverzeichnis verblieben.\n" "Committen Sie Ihre Änderungen oder benutzen Sie \"stash\".\n" "Führen Sie dann aus:\n" "\n" " git rebase --continue\n" "\n" #: sequencer.c:1925 -#, fuzzy, c-format +#, c-format msgid "Applied autostash.\n" -msgstr "Automatischen Stash angewendet." +msgstr "Automatischen Stash angewendet.\n" #: sequencer.c:1937 #, c-format msgid "cannot store %s" msgstr "kann %s nicht speichern" #: sequencer.c:1940 git-rebase.sh:173 #, c-format msgid "" @@ -3649,21 +3646,21 @@ msgstr "Konnte Eintrag '%s' nicht aus .gitmodules entfernen" #: submodule.c:126 msgid "staging updated .gitmodules failed" msgstr "Konnte aktualisierte .gitmodules-Datei nicht zum Commit vormerken" #: submodule.c:165 msgid "negative values not allowed for submodule.fetchJobs" msgstr "Negative Werte für submodule.fetchJobs nicht erlaubt" #: submodule.c:376 -#, fuzzy, c-format +#, c-format msgid "in unpopulated submodule '%s'" -msgstr "Überspringe Submodul '%s'" +msgstr "In nicht ausgechecktem Submodul '%s'." #: submodule.c:407 #, c-format msgid "Pathspec '%s' is in submodule '%.*s'" msgstr "Pfadspezifikation '%s' befindet sich in Submodul '%.*s'" #: submodule.c:1337 #, c-format msgid "'%s' not rec
Re: Handling of paths
Victor Toni writes: > 2017-07-20 22:30 GMT+02:00 Junio C Hamano : >> >> I've read the function again and I think the attached patch covers >> everything that ought to be a filename. >> > Your swift reaction is very much appreciated. > With the background you gave I just started to to create a patch > myself just to see that you already finished the patch. Heh, I guess I could have waited to save time ;-) I did the patch myself in order to avoid wasting your effort to find and report the issue and time and distraction cost from Charles to remember what happened 2 years ago and reply to me, because I will certainly forget if I didn't have some patch readily usable in the list archive. In general, I (and other experienced reviewers here) prefer to give chances to people who are new to the Git development community and are inclined to do so to scratch their own itch, by giving analysis of the problem and a suggested route to solve it, but without giving the final solution in a patch form. After all, many developers (including me) started from small changes before getting involved more deeply to the project and starting to play more important roles. Some reviewers are much better than myself in judging if a new person wants satisfaction of solving himself or herself[*1*], and they end their analysis and suggestion with a phrase like "Want to try doing a patch yourself?" I try to follow their example myself, but I do not always succeed, and this is one of such cases. I guess you could have immediately responded "OK, let me try to see if I can fix it myself" before starting to actually work on it ;-) Having said all that, I suspect that your original problem description might point at another thing we may want to look into. The patch under discussion may have solved the "~[username]/" prefix issue, but I offhand am not sure if a path-like variable that holds a relative path behaves sensibly when they appear in configuration files and in a file that has configuration snippets that is included with the "[include] path=..." thing, and if there is a need to clarify and/or update the rules. In any case, thanks for reporting the bugs on two variables, and welcome to the Git development community. [Footnote] *1* Some people just want to report an issue and move on, which is understandable.
Re: [PATCH] PRItime: wrap PRItime for better l10n compatibility
Jean-Noël Avila writes: > Le 20/07/2017 à 20:57, Junio C Hamano a écrit : >> >> +git diff --quiet HEAD && git diff --quiet --cached >> + >> +@for s in $(LOCALIZED_C) $(LOCALIZED_SH) $(LOCALIZED_PERL); \ > > Does PRIuMAX make sense for perl and sh files? Not really; I did this primarily because I would prefer to keep things consistent, anticipating there may be some other things we need to replace before running gettext(1) for other reasons later. I do not mind removing them, if Jiang/Dscho already reviewed and tested _this_ version (which we do not yet know), I'd prefer not to touch it for the upcoming release. Thanks for reading it over. >> +do \ >> +sed -e 's|PRItime|PRIuMAX|g' <"$$s" >"$$s+" && \ >> +cat "$$s+" >"$$s" && rm "$$s+"; \ >> +done >> + >> $(QUIET_XGETTEXT)$(XGETTEXT) -o$@+ $(XGETTEXT_FLAGS_C) $(LOCALIZED_C) >> $(QUIET_XGETTEXT)$(XGETTEXT) -o$@+ --join-existing $(XGETTEXT_FLAGS_SH) >> \ >> $(LOCALIZED_SH) >> $(QUIET_XGETTEXT)$(XGETTEXT) -o$@+ --join-existing >> $(XGETTEXT_FLAGS_PERL) \ >> $(LOCALIZED_PERL) >> + >> +git reset --hard >> mv $@+ $@ >> >> .PHONY: pot
Re: [PATCH] PRItime: wrap PRItime for better l10n compatibility
Le 20/07/2017 à 20:57, Junio C Hamano a écrit : > > + git diff --quiet HEAD && git diff --quiet --cached > + > + @for s in $(LOCALIZED_C) $(LOCALIZED_SH) $(LOCALIZED_PERL); \ Does PRIuMAX make sense for perl and sh files? > + do \ > + sed -e 's|PRItime|PRIuMAX|g' <"$$s" >"$$s+" && \ > + cat "$$s+" >"$$s" && rm "$$s+"; \ > + done > + > $(QUIET_XGETTEXT)$(XGETTEXT) -o$@+ $(XGETTEXT_FLAGS_C) $(LOCALIZED_C) > $(QUIET_XGETTEXT)$(XGETTEXT) -o$@+ --join-existing $(XGETTEXT_FLAGS_SH) > \ > $(LOCALIZED_SH) > $(QUIET_XGETTEXT)$(XGETTEXT) -o$@+ --join-existing > $(XGETTEXT_FLAGS_PERL) \ > $(LOCALIZED_PERL) > + > + git reset --hard > mv $@+ $@ > > .PHONY: pot
Re: [PATCH] git-contacts: Add recognition of Reported-by
Eric Blake writes:
> It's nice to cc someone that reported a bug, in order to let
> them know that a fix is being considered, and possibly even
> get their help in reviewing/testing the patch.
>
> Signed-off-by: Eric Blake
> ---
I don't know if this new one deserves to be part of the hardcoded
defaults; it would be different between the projects and depends on
their convention. I notice that there is no way to configure this
script and I suspect that it would be a more generally useful update
to have it read a configuration variable that lists what kind of sob
like things to take addresses from.
Thanks.
> contrib/contacts/git-contacts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/contrib/contacts/git-contacts b/contrib/contacts/git-contacts
> index dbe2abf27..85ad732fc 100755
> --- a/contrib/contacts/git-contacts
> +++ b/contrib/contacts/git-contacts
> @@ -11,7 +11,7 @@ use IPC::Open2;
>
> my $since = '5-years-ago';
> my $min_percent = 10;
> -my $labels_rx = qr/Signed-off-by|Reviewed-by|Acked-by|Cc/i;
> +my $labels_rx = qr/Signed-off-by|Reviewed-by|Acked-by|Cc|Reported-by/i;
> my %seen;
>
> sub format_contact {
Re: fatal: bad numeric config value '60 days' for 'gc.rerereresolved': invalid unit
Uwe Hausbrand writes: > seems like there is a bug with "git rerere gc" not understanding grace > periods like "60 days" defined in the config. > > What I did: > > git config gc.rerereresolved "60 days" Let's see how the variable is explained in the documentation. gc.rerereResolved:: Records of conflicted merge you resolved earlier are kept for this many days when 'git rerere gc' is run. The default is 60 days. See linkgit:git-rerere[1]. Notice that "for this many days" tries to (and probably unsuccessfully) tell you that this variable is expected to be set to an integer [*1*], counted in "days". IOW, you'd want "60" instead. Having said that, it may not be a bad idea to enumerate these "expected to be an integer that counts in some unit" variables that are described in a similar way (i.e. look for "this many" in Documentation/config.txt), and then for each of them that could be counted in different unit (e.g. it is not outrageously wrong to expect that you could specify that rerere records that are older than 3 months are expired): - decide what kind of quantity the variable specifies (e.g. "this many days" and "this many seconds" variables are giving a "timeperiod"). - keep the code that reacts to an integer without any unit to behave the same (e.g. "[gc] rerereresolved = 30" will keep meaning "30 days"); - extend the code so that when the value given is not an integer, it tries to parse it as a specification for the expected quantity (e.g. "this many days" and "this many seconds" variables would understand if you said "60 days" or "2 months") [Footnote] *1* I think we actually expect a scaled integer whenever we expect an integral value, so you probably could say "6k" to specify "6,000 days"; "days" not being any of the recognised unit suffix like k, M, G, etc. is where "invalid unit" comes from.
Re: fatal: bad numeric config value '60 days' for 'gc.rerereresolved': invalid unit
On 21 July 2017 at 14:59, Uwe Hausbrand wrote: > git config gc.rerereresolved "60 days" > git gc > > results in: [...] > fatal: bad numeric config value '60 days' for 'gc.rerereresolved': invalid > unit > error: failed to run rerere It's not entirely clear, but "man git-gc" does seem to suggest -- at least to me -- that one can say "60 days". Especially after reading about gc.reflogExpire a few paragraphs earlier, where "90 days" and "3 months" are given as examples. Luckily, "man git-config" is a bit clearer. It says that "records ... are kept for this many days". The latter matches the implementation and the tests, which are all written to work with just an integer. So "git config gc.rerereresolved 60" should work. Hope that helps. Martin
[PATCH] git-contacts: Add recognition of Reported-by
It's nice to cc someone that reported a bug, in order to let
them know that a fix is being considered, and possibly even
get their help in reviewing/testing the patch.
Signed-off-by: Eric Blake
---
contrib/contacts/git-contacts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/contacts/git-contacts b/contrib/contacts/git-contacts
index dbe2abf27..85ad732fc 100755
--- a/contrib/contacts/git-contacts
+++ b/contrib/contacts/git-contacts
@@ -11,7 +11,7 @@ use IPC::Open2;
my $since = '5-years-ago';
my $min_percent = 10;
-my $labels_rx = qr/Signed-off-by|Reviewed-by|Acked-by|Cc/i;
+my $labels_rx = qr/Signed-off-by|Reviewed-by|Acked-by|Cc|Reported-by/i;
my %seen;
sub format_contact {
--
2.13.3
fatal: bad numeric config value '60 days' for 'gc.rerereresolved': invalid unit
Hi all, seems like there is a bug with "git rerere gc" not understanding grace periods like "60 days" defined in the config. What I did: git config gc.rerereresolved "60 days" git gc results in: Counting objects: 158790, done. Delta compression using up to 8 threads. Compressing objects: 100% (26849/26849), done. Writing objects: 100% (158790/158790), done. Total 158790 (delta 116114), reused 158790 (delta 116114) fatal: bad numeric config value '60 days' for 'gc.rerereresolved': invalid unit error: failed to run rerere git --version = git version 2.13.0 Best regards, Uwe
Re: [PATCH 0/6] 2.14 RelNotes improvements
On Thu, Jul 20 2017, Junio C. Hamano jotted: > Ævar Arnfjörð Bjarmason writes: > >> Here's a few patches to improve the relnotes. I started just writing >> 6/6 since I think (I don't care about the wording) that we should in >> some way mention the items in the list in the 6/6 commit message. >> >> Along the way I noticed a few more missing things. >> >> Ævar Arnfjörð Bjarmason (6): >> RelNotes: mention "log: add -P as a synonym for --perl-regexp" >> RelNotes: mention "log: make --regexp-ignore-case work with >> --perl-regexp" >> RelNotes: mention "sha1dc: optionally use sha1collisiondetection as a >> submodule" >> RelNotes: mention that PCRE v2 exposes the same syntax >> RelNotes: remove duplicate mention of PCRE v2 >> RelNotes: add more notes about PCRE in 2.14 > > Thanks. 1-3/6 went straight to 'master'. I am not outright > rejecting the remainder, but I do not think these are release notes > material---if they need to be told, they should be in a part of the > regular documentation, and I suspect that they already are in your > series. Thanks. I agree that 4-6 are better left to the docs. I wasn't very familiar with the format of the release notes / what you preferref to list there & how. I'll integrate what 6/6 mentions with my nascent gitperformance.txt series.
[PATCH] refs: use skip_prefix() in ref_is_hidden()
This saves one line, makes the code a bit easier to understand
and perhaps a bit faster too.
Signed-off-by: Christian Couder
---
refs.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/refs.c b/refs.c
index ba22f4acef..15cb36d426 100644
--- a/refs.c
+++ b/refs.c
@@ -1160,7 +1160,7 @@ int ref_is_hidden(const char *refname, const char
*refname_full)
const char *match = hide_refs->items[i].string;
const char *subject;
int neg = 0;
- int len;
+ const char *p;
if (*match == '!') {
neg = 1;
@@ -1175,10 +1175,9 @@ int ref_is_hidden(const char *refname, const char
*refname_full)
}
/* refname can be NULL when namespaces are used. */
- if (!subject || !starts_with(subject, match))
+ if (!subject || !skip_prefix(subject, match, &p))
continue;
- len = strlen(match);
- if (!subject[len] || subject[len] == '/')
+ if (!*p || *p == '/')
return !neg;
}
return 0;
--
2.14.0.rc0.26.g981adb928e.dirty
Re: [PATCH 21/28] commit_packed_refs(): use a staging file separate from the lockfile
Junio C Hamano writes: > The general strategy we take for these atomic update of a file > entity at $path is to: > > (1) try to create $path.lock exclusively; if we cannot, somebody > else holds the lock so fail (or backoff and retry, which > amounts to the same thing in the larger picture). > > (2) update $path.lock and close the fd. > > (3) rename $path.lock to $path atomically to unlock. > > Would it be sufficent to tweak the above procedure with a new, > zeroth step? > > (0) see $path is a symlink; if so, readlink it and assign the > result to $path. Then go on to step (1) above. > > I do not think such an enhancement would break atomicity guarantee > we want from the locking. When updating .git/packed-refs in an > ancient new-workdir'ed directory, we would end up locking the > corresponding file in the real repository, which is exactly what we > want anyway. As the basic assumption of having a symbolic link in > the new-workdir'ed directory is that a symlink can stay the same > forever while the linked target will be updated, I think this would > be a reasonable short-term "fix". > > It would be ideal if we can do this at somewhat a low level, i.e. in > the lockfile subsystem. One thing I forgot to mention. For the above to work safely, we should think through the possible interaction this may have with the core.preferSymlinkRefs configuration. If the above is implemented naively, an update of a symref (e.g. "HEAD") that points at something to point at something else would end up taking a lock on the underlying ref and updating it, which is not what we want at all. Perhaps it is about time we stopped supporting the configuration. We may be able to come up with a solution while keeping it alive, but dropping it would mean we would have one less thing we need to worry about.
