[PATCH] l10n: gitk/ca.po: add Catalan translation
Signed-off-by: Alex Henrie --- gitk-git/po/ca.po | 1349 + 1 file changed, 1349 insertions(+) create mode 100644 gitk-git/po/ca.po diff --git a/gitk-git/po/ca.po b/gitk-git/po/ca.po new file mode 100644 index 000..1ac23e9 --- /dev/null +++ b/gitk-git/po/ca.po @@ -0,0 +1,1349 @@ +# Translation of gitk +# Copyright (C) 2005-2014 Paul Mackerras +# This file is distributed under the same license as the gitk package. +# Alex Henrie , 2015. +# +# +msgid "" +msgstr "" +"Project-Id-Version: gitk\n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2015-01-22 00:45-0700\n" +"PO-Revision-Date: 2015-01-27 00:24-0700\n" +"Last-Translator: Alex Henrie \n" +"Language-Team: Catalan\n" +"Language: ca\n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Plural-Forms: nplurals=2; plural=(n != 1);\n" +"X-Generator: Poedit 1.7.3\n" + +#: gitk:140 +msgid "Couldn't get list of unmerged files:" +msgstr "No s'ha pogut obtenir la llista de fitxers no fusionats:" + +#: gitk:212 gitk:2381 +msgid "Color words" +msgstr "Colora les paraules" + +#: gitk:217 gitk:2381 gitk:8108 gitk:8141 +msgid "Markup words" +msgstr "Marca les paraules" + +#: gitk:324 +msgid "Error parsing revisions:" +msgstr "Error en analitzar les revisions:" + +#: gitk:380 +msgid "Error executing --argscmd command:" +msgstr "Error en executar l'ordre --argscmd:" + +#: gitk:393 +msgid "No files selected: --merge specified but no files are unmerged." +msgstr "" +"No hi ha fitxers seleccionats: s'ha especificat --merge però cap fitxer està " +"sense fusionar." + +#: gitk:396 +msgid "" +"No files selected: --merge specified but no unmerged files are within file " +"limit." +msgstr "" +"No hi ha fitxers seleccionats: s'ha especificat --merge però cap fitxer " +"sense fusionar està dins del límit de fitxers." + +#: gitk:418 gitk:566 +msgid "Error executing git log:" +msgstr "Error en executar git log:" + +#: gitk:436 gitk:582 +msgid "Reading" +msgstr "Llegint" + +#: gitk:496 gitk:4415 +msgid "Reading commits..." +msgstr "Llegint les revisions..." + +#: gitk:499 gitk:1637 gitk:4418 +msgid "No commits selected" +msgstr "Cap comissió seleccionada" + +#: gitk:1511 +msgid "Can't parse git log output:" +msgstr "No es pot analitzar la sortida del git log:" + +#: gitk:1740 +msgid "No commit information available" +msgstr "Cap informació de comissió disponible" + +#: gitk:1897 +msgid "mc" +msgstr "mc" + +#: gitk:1932 gitk:4208 gitk:9557 gitk:11127 gitk:11406 +msgid "OK" +msgstr "D'acord" + +#: gitk:1934 gitk:4210 gitk:9084 gitk:9163 gitk:9279 gitk:9328 gitk:9559 +#: gitk:11128 gitk:11407 +msgid "Cancel" +msgstr "Cancel·la" + +#: gitk:2069 +msgid "Update" +msgstr "Actualitza" + +#: gitk:2070 +msgid "Reload" +msgstr "Recarrega" + +#: gitk:2071 +msgid "Reread references" +msgstr "Rellegeix les referències" + +#: gitk:2072 +msgid "List references" +msgstr "Llista les referències" + +#: gitk:2074 +msgid "Start git gui" +msgstr "Inicia el git gui" + +#: gitk:2076 +msgid "Quit" +msgstr "Surt" + +#: gitk:2068 +msgid "File" +msgstr "Fitxer" + +#: gitk:2080 +msgid "Preferences" +msgstr "Preferències" + +#: gitk:2079 +msgid "Edit" +msgstr "Edita" + +#: gitk:2084 +msgid "New view..." +msgstr "Vista nova..." + +#: gitk:2085 +msgid "Edit view..." +msgstr "Edita la vista..." + +#: gitk:2086 +msgid "Delete view" +msgstr "Suprimeix vista" + +#: gitk:2088 +msgid "All files" +msgstr "Tots els fitxers" + +#: gitk:2083 gitk:3961 +msgid "View" +msgstr "Vista" + +#: gitk:2093 gitk:2103 gitk:2920 +msgid "About gitk" +msgstr "Quant al gitk" + +#: gitk:2094 gitk:2108 +msgid "Key bindings" +msgstr "Associacions de tecles" + +#: gitk:2092 gitk:2107 +msgid "Help" +msgstr "Ajuda" + +#: gitk:2185 gitk:8540 +msgid "SHA1 ID:" +msgstr "ID SHA1:" + +#: gitk:2229 +msgid "Row" +msgstr "Fila" + +#: gitk:2267 +msgid "Find" +msgstr "Cerca" + +#: gitk:2295 +msgid "commit" +msgstr "comissió" + +#: gitk:2299 gitk:2301 gitk:4576 gitk:4599 gitk:4623 gitk:6643 gitk:6715 +#: gitk:6800 +msgid "containing:" +msgstr "que contingui:" + +#: gitk:2302 gitk:3433 gitk:3438 gitk:4652 +msgid "touching paths:" +msgstr "que toqui els camins:" + +#: gitk:2303 gitk:4666 +msgid "adding/removing string:" +msgstr "que afegeixi/elimini la cadena:" + +#: gitk:2304 gitk:4668 +msgid "changing lines matching:" +msgstr "que tingui línies canviades coincidents amb:" + +#: gitk:2313 gitk:2315 gitk:4655 +msgid "Exact" +msgstr "Exacte" + +#: gitk:2315 gitk:4743 gitk:6611 +msgid "IgnCase" +msgstr "Ignora majúscula i minúscula" + +#: gitk:2315 gitk:4625 gitk:4741 gitk:6607 +msgid "Regexp" +msgstr "Regexp" + +#: gitk:2317 gitk:2318 gitk:4763 gitk:4793 gitk:4800 gitk:6736 gitk:6804 +msgid "All fields" +msgstr "Tots els camps" + +#: gitk:2318 gitk:4760 gitk:4793 gitk:6674 +msgid "Headline" +msgstr "Titular" + +#: gitk:2319 gitk:4760 gitk:6674 gitk:6804 gitk:7277 +msgid "Comments" +msgstr "Comentaris" + +#: gitk:2319 gitk:4760 gitk:4765 gitk:4800
Re: patch-2.7.3 no longer applies relative symbolic link patches
Linus Torvalds writes: > Ugh. I don't see anything we can do about this on the git side, and I > do kind of understand why 'patch' would be worried about '..' files. > In a perfect world, patch would parse the filename and see that it > stays within the directory structure of the project, but that is a > rather harder thing to do than just say "no dot-dot files". It is unclear to me why "limit to the current directory and below" is such a big deal in the first place. If the user wants to apply a patch that touches ../etc/shadow, is the tool in the place to complain?" -- 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] refs.c: clean up write_ref_sha1 returns
Stefan Beller writes:
> I can redo the atomic-push-fix series with this cleanup merged
> into the appropriate patches or you could just queue it on top
> of said series.
Yeah, I do not think we are expecting to fast track these two series
through 'next' to 'master' before 2.3 final, so I think it would be
better to use this patch _only_ to see if the final shape of the
code this patch represents makes sense, so that we can expedite the
final submission in the next development cycle, at which time we
will have a chance to refresh 'next', hence a chance to clean-up
atomic-push series in place.
Thanks.
> refs.c | 27 +++
> 1 file changed, 15 insertions(+), 12 deletions(-)
>
> diff --git a/refs.c b/refs.c
> index 2594b23..c8fd4a4 100644
> --- a/refs.c
> +++ b/refs.c
> @@ -2817,9 +2817,6 @@ static int close_ref(struct ref_lock *lock)
>
> static int commit_ref(struct ref_lock *lock, const unsigned char *sha1)
> {
> - if (!lock->force_write && !hashcmp(lock->old_sha1, sha1))
> - return 0;
> -
> if (commit_lock_file(lock->lk))
> return -1;
> return 0;
> @@ -2880,7 +2877,6 @@ int rename_ref(const char *oldrefname, const char
> *newrefname, const char *logms
> error("unable to lock %s for update", newrefname);
> goto rollback;
> }
> - lock->force_write = 1;
> hashcpy(lock->old_sha1, orig_sha1);
Is this hashcpy() still necessary?
> if (write_ref_sha1(lock, orig_sha1, logmsg)
> || commit_ref(lock, orig_sha1)) {
--
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: [PATCHv3 6/6] refs.c: enable large transactions
Stefan Beller writes: > I do not see the problem in the code itself, but rather in understanding > the code. I will send a follow up patch which makes it easier to follow > by removing the early exit with no problem away. Taken as a whole the code may function correctly but the division of roles of individual functions seems screwed up. write_ref_sha1() sometimes unlocks, and sometimes leaves the unlocking to the caller, and the caller cannot even tell if it is expected to do the unlocking for it from the return value because both cases return 0 (success). I am not sure if it is sensible to call that "correct but hard to understand". I'd rather see us admit that its behaviour is screwey and needs fixing for better code health longer term. -- 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: t5539 broken under Mac OS X
Erik Faye-Lund writes: > On Fri, Jan 16, 2015 at 1:04 AM, Junio C Hamano wrote: >> Jeff King writes: >> >>> Exactly. I am happy to submit a patch, but I cannot think of any >>> mechanisms besides: >>> >>> 1. Calling `id`, which I suspect is very not portable. >>> >>> 2. Writing a C program to check getuid(). That's portable for most >>> Unixes. It looks like we already have a hacky wrapper on mingw that >>> will always return "1". >>> >>> Is (2) too gross? >> >> Not overly gross compared to some existing test-*.c files, I would >> say. >> >> I wondered what 'perl -e 'print $>' would say in mingw, and if that >> is portable enough, though. > > $ perl -e 'print $>' > 500 Thanks for a follow-up. Is "id -u" not useful over there? I ask because that is what is used in the version tentatively queued on 'pu' for NOT_ROOT prerequisite (the jk/sanity topic). The SANITY prerequisite in that topic needs to be replaced with the one from Torsten that attempts to check what we want to know in a more direct way; i.e. "after making a directory or a file read-only, does the filesystem really honours that, or lets us clobber?" is what we need to know to skip some tests, and we should check that, instead of "is / writable by us?" or "are we root?". -- 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: [PATCHv2] commit: reword --author error message
On Mon, Jan 26, 2015 at 06:43:46PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > ... I somehow had trouble making
> > sense of Z ("a match...") as a noun.
>
> > I wonder if adding back in the missing verb, rather than a colon, would
> > also make more sense:
> >
> > --author '%s' is neither 'Name ' nor a match for an existing author
>
> Then
>
> > --author '%s' is not 'Name ' and matches no existing author
>
> would be the shortest, sweetest and hopefully grammatical, perhaps?
Yes, that one make perfect sense to me.
-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: [PATCHv2] commit: reword --author error message
Jeff King writes:
> ... I somehow had trouble making
> sense of Z ("a match...") as a noun.
> I wonder if adding back in the missing verb, rather than a colon, would
> also make more sense:
>
> --author '%s' is neither 'Name ' nor a match for an existing author
Then
> --author '%s' is not 'Name ' and matches no existing author
would be the shortest, sweetest and hopefully grammatical, perhaps?
--
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: t5539 broken under Mac OS X
On Fri, Jan 16, 2015 at 1:04 AM, Junio C Hamano wrote: > Jeff King writes: > >> Exactly. I am happy to submit a patch, but I cannot think of any >> mechanisms besides: >> >> 1. Calling `id`, which I suspect is very not portable. >> >> 2. Writing a C program to check getuid(). That's portable for most >> Unixes. It looks like we already have a hacky wrapper on mingw that >> will always return "1". >> >> Is (2) too gross? > > Not overly gross compared to some existing test-*.c files, I would > say. > > I wondered what 'perl -e 'print $>' would say in mingw, and if that > is portable enough, though. $ perl -e 'print $>' 500 -- 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.7.3 no longer applies relative symbolic link patches
On Mon, Jan 26, 2015 at 4:30 PM, Linus Torvalds wrote: > On Mon, Jan 26, 2015 at 1:07 PM, Josh Boyer wrote: >> >> Or did I miss a way that git-apply can take a git patch and apply it >> to a tree that isn't a git repo? > > Exactly. "git apply" works as a straight "patch" replacement outside > of a git repository. It doesn't actually need a git tree to work. Ah. I had somehow missed that entirely. Good to know for future reference. > (Of course, "git apply" is _not_ a "patch" replacement in the general > sense. It only applies context diffs - preferentially git style ones - > so no old-style patches etc need apply. And it's not > replacement-compatible in a syntax sense either, in that while many of > the options are the same, not all are etc etc). Sure. Though for the Fedora kernel builds, we tend to use git formatted patches only anyway. I might play around with this and see how it works as the normal way to apply things. josh -- 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] Documentation/git-add.txt: add `add.ginore-errors` configuration variable
On Mon, Jan 26, 2015 at 11:55 AM, Alexander Kuleshov wrote: > 'git add' supports not only `add.ignoreErrors`, but also `add.ignore-errors` > configuration variable. See 6b3020a2 (add: introduce add.ignoreerrors synonym for add.ignore-errors, 2010-12-01) for why this patch is undesirable. > Signed-off-by: Alexander Kuleshov > --- > Documentation/git-add.txt | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt > index 1c74907..f68c2a2 100644 > --- a/Documentation/git-add.txt > +++ b/Documentation/git-add.txt > @@ -155,8 +155,8 @@ for "git add --no-all ...", i.e. ignored > removed files. > If some files could not be added because of errors indexing > them, do not abort the operation, but continue adding the > others. The command shall still exit with non-zero status. > - The configuration variable `add.ignoreErrors` can be set to > - true to make this the default behaviour. > + The configuration variable `add.ignoreErrors` or `add.ignore-errors` > + can be set to true to make this the default behaviour. > > --ignore-missing:: > This option can only be used together with --dry-run. By using > -- > 2.3.0.rc1.275.g028c360 -- 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.7.3 no longer applies relative symbolic link patches
On Mon, Jan 26, 2015 at 1:35 PM, Junio C Hamano wrote: > > What is your take on CVE-2015-1196, which brought this /regression/ to > GNU patch? > If "git apply" get /fixed/ for that same CVE, would that /break/ your fix? I _think_ we allow arbitrary symlinks to be created, but then we should be careful about actually _following_ them. At least I _thought_ we were already quite careful not to do that, even if it's been a long time since I looked at the code. So even if we create a symlink to outside the repository, it normally shouldn't matter. We have that whole "lstat_cache()" thing that exists exactly to make it efficient to do pathname lookups while at the same time being aware of symlinks in the middle. Of course, our lstat cache is racy if somebody else modifies the tree concurrently and changes things, but that's a non-issue, because if somebody can just directly create random symlinks in the middle of the tree, I don't think we care about any symlinks _git_ might be creating concurrently ;) But it is entirely possible that "git apply" - especially when used outside of a real git directory - ends up doing that. And it's not like we necessarily always use the whole "lstat-cache" mechanism to begin with, so the fact that we have the infrastructure to be careful in no way means that we necessarily always _are_ careful... Linus -- 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.7.3 no longer applies relative symbolic link patches
On Mon, Jan 26, 2015 at 1:30 PM, Linus Torvalds wrote: > On Mon, Jan 26, 2015 at 1:07 PM, Josh Boyer wrote: >> >> Or did I miss a way that git-apply can take a git patch and apply it >> to a tree that isn't a git repo? > > Exactly. "git apply" works as a straight "patch" replacement outside > of a git repository. It doesn't actually need a git tree to work. What is your take on CVE-2015-1196, which brought this /regression/ to GNU patch? If "git apply" get /fixed/ for that same CVE, would that /break/ your fix? -- 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.7.3 no longer applies relative symbolic link patches
On Mon, Jan 26, 2015 at 1:07 PM, Josh Boyer wrote: > > Or did I miss a way that git-apply can take a git patch and apply it > to a tree that isn't a git repo? Exactly. "git apply" works as a straight "patch" replacement outside of a git repository. It doesn't actually need a git tree to work. (Of course, "git apply" is _not_ a "patch" replacement in the general sense. It only applies context diffs - preferentially git style ones - so no old-style patches etc need apply. And it's not replacement-compatible in a syntax sense either, in that while many of the options are the same, not all are etc etc). Linus -- 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] refs.c: clean up write_ref_sha1 returns
write_ref_sha1 now either returns 0 for a successful write or !=0 if an
error occurred. This cleanup results in cleaning the code at other places
as well where we had to set force_write to make the write_ref_sha1(...)
|| commit_ref(...) combination work. Also the checks for the optimisation
of old and new sha1 values being the same has been moved to a helper
function so that check is not part of write_ref_sha1 or commit_ref any
more.
Signed-off-by: Stefan Beller
---
Notes:
v1:
applies on top of origin/sb/atomic-push-fix (79370dd9656)
This undoes some of the changes of previous patches
such as removing the check if old and new sha1 are equal
and not being forced to rewrite the value.
Junio, I think this patch adresses the concerns you raised.
I can redo the atomic-push-fix series with this cleanup merged
into the appropriate patches or you could just queue it on top
of said series.
refs.c | 27 +++
1 file changed, 15 insertions(+), 12 deletions(-)
diff --git a/refs.c b/refs.c
index 2594b23..c8fd4a4 100644
--- a/refs.c
+++ b/refs.c
@@ -2817,9 +2817,6 @@ static int close_ref(struct ref_lock *lock)
static int commit_ref(struct ref_lock *lock, const unsigned char *sha1)
{
- if (!lock->force_write && !hashcmp(lock->old_sha1, sha1))
- return 0;
-
if (commit_lock_file(lock->lk))
return -1;
return 0;
@@ -2880,7 +2877,6 @@ int rename_ref(const char *oldrefname, const char
*newrefname, const char *logms
error("unable to lock %s for update", newrefname);
goto rollback;
}
- lock->force_write = 1;
hashcpy(lock->old_sha1, orig_sha1);
if (write_ref_sha1(lock, orig_sha1, logmsg)
|| commit_ref(lock, orig_sha1)) {
@@ -2899,7 +2895,6 @@ int rename_ref(const char *oldrefname, const char
*newrefname, const char *logms
goto rollbacklog;
}
- lock->force_write = 1;
flag = log_all_ref_updates;
log_all_ref_updates = 0;
if (write_ref_sha1(lock, orig_sha1, NULL)
@@ -3062,12 +3057,22 @@ int is_branch(const char *refname)
return !strcmp(refname, "HEAD") || starts_with(refname, "refs/heads/");
}
+static int should_write_ref_sha1(struct ref_lock *lock,
+const unsigned char *new_sha1)
+{
+ /* If the old and new sha1 are equal only write if forced to. */
+ if (!lock->force_write && !hashcmp(lock->old_sha1, new_sha1))
+ return 0;
+ /* null sha indicates deletion, so don't write it */
+ return !is_null_sha1(new_sha1);
+}
+
/*
* Write sha1 into the ref specified by the lock. Make sure that errno
* is sane on error.
*/
-static int write_ref_sha1(struct ref_lock *lock,
- const unsigned char *sha1, const char *logmsg)
+static int write_ref_sha1(struct ref_lock *lock, const unsigned char *sha1,
+ const char *logmsg)
{
static char term = '\n';
struct object *o;
@@ -3076,8 +3081,6 @@ static int write_ref_sha1(struct ref_lock *lock,
errno = EINVAL;
return -1;
}
- if (!lock->force_write && !hashcmp(lock->old_sha1, sha1))
- return 0;
o = parse_object(sha1);
if (!o) {
@@ -3752,7 +3755,7 @@ int ref_transaction_commit(struct ref_transaction
*transaction,
update->refname);
goto cleanup;
}
- if (!is_null_sha1(update->new_sha1)) {
+ if (should_write_ref_sha1(update->lock, update->new_sha1)) {
if (write_ref_sha1(update->lock, update->new_sha1,
update->msg)) {
strbuf_addf(err, "Cannot write to the ref lock
'%s'.",
@@ -3769,7 +3772,7 @@ int ref_transaction_commit(struct ref_transaction
*transaction,
for (i = 0; i < n; i++) {
struct ref_update *update = updates[i];
- if (!is_null_sha1(update->new_sha1)) {
+ if (should_write_ref_sha1(update->lock, update->new_sha1)) {
if (commit_ref(update->lock, update->new_sha1)) {
strbuf_addf(err, "Cannot update the ref '%s'.",
update->refname);
@@ -3785,7 +3788,7 @@ int ref_transaction_commit(struct ref_transaction
*transaction,
for (i = 0; i < n; i++) {
struct ref_update *update = updates[i];
- if (update->lock) {
+ if (is_null_sha1(update->new_sha1)) {
if (delete_ref_loose(update->lock, update->type, err)) {
ret = TRANSACTION_GENERIC_ERROR;
goto cleanup;
--
2.2.1.62.g3f15098
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of
Re: patch-2.7.3 no longer applies relative symbolic link patches
On Mon, Jan 26, 2015 at 3:44 PM, Linus Torvalds wrote: > On Mon, Jan 26, 2015 at 8:32 AM, Josh Boyer wrote: >> >> I went to do the Fedora 3.19-rc6 build this morning and it failed in >> our buildsystem with: >> >> + '[' '!' -f /builddir/build/SOURCES/patch-3.19-rc6.xz ']' >> + case "$patch" in >> + unxz >> + patch -p1 -F1 -s >> symbolic link target '../../../../../include/dt-bindings' is invalid >> error: Bad exit status from /var/tmp/rpm-tmp.mWE3ZL (%prep) > > Ugh. I don't see anything we can do about this on the git side, and I > do kind of understand why 'patch' would be worried about '..' files. > In a perfect world, patch would parse the filename and see that it > stays within the directory structure of the project, but that is a > rather harder thing to do than just say "no dot-dot files". > > The short-term fix is likely to just use "git apply" instead of "patch". Well, that's one fix anyway. I just removed the hunk from the local copy of patch-3.19-rc6.xz and added the symlink manually. See why below. > The long-term fix? I dunno. I don't see us not using symlinks, and a > quick check says that every *single* symlink we have in the kernel > source tree is one that points to a different directory using ".." > format. And while I could imagine that "patch" ends up counting the > dot-dot entries and checking that it's all inside the same tree it is > patching, I could also easily see patch *not* doing that. So using > "git apply" _might_ end up being the long-term fix too. It could, but from a distro perspective that requires either doing 'untar linux-3.N.tar.xz; cd linux-3.N; git add .; git apply patch-3.N+1-rcX' , or just using a git tree to begin with, which then makes all of this unnecessary anyway. Creating a git repo from a tarball for each build is kind of silly. Some might say not just using a git tree to build from to begin with in 2015 is also kind of silly. Or did I miss a way that git-apply can take a git patch and apply it to a tree that isn't a git repo? > I suspect that if "patch" cannot apply even old-style kernel patches > due to the symlinks we have in the tree, and people end up having to > use "git apply" for them, I might end up starting to just use > rename-patches (ie using "git diff -M") for the kernel. I'm kind of wondering why we'd generate patches at all if you have to apply them to a git repo, but maybe people like doing things the old-fashioned way just for the hell of it. > I've considered that for a while already, because "patch" _does_ kind > of understand them these days, although I think it gets the > cross-rename case wrong because it fundamentally works on a > file-by-file basis. But if "patch" just ends up not working at all, > the argument for trying to maintain backwards compatibility gets > really weak. Yeah. I mostly wanted to give people a heads up on the issue. I'm sure it's going to impact more than just the kernel. I think for us it's mostly limited to the -rcX patches, because once the tarball for the final release is out the symlink should be created by tar just fine. josh -- 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.7.3 no longer applies relative symbolic link patches
Linus Torvalds writes: > On Mon, Jan 26, 2015 at 8:32 AM, Josh Boyer wrote: >> >> I went to do the Fedora 3.19-rc6 build this morning and it failed in >> our buildsystem with: >> >> + '[' '!' -f /builddir/build/SOURCES/patch-3.19-rc6.xz ']' >> + case "$patch" in >> + unxz >> + patch -p1 -F1 -s >> symbolic link target '../../../../../include/dt-bindings' is invalid >> error: Bad exit status from /var/tmp/rpm-tmp.mWE3ZL (%prep) > > Ugh. I don't see anything we can do about this on the git side, and I > do kind of understand why 'patch' would be worried about '..' files. > In a perfect world, patch would parse the filename and see that it > stays within the directory structure of the project, but that is a > rather harder thing to do than just say "no dot-dot files". > > The short-term fix is likely to just use "git apply" instead of "patch". > > The long-term fix? I dunno. I don't see us not using symlinks, and a > quick check says that every *single* symlink we have in the kernel > source tree is one that points to a different directory using ".." > format. And while I could imagine that "patch" ends up counting the > dot-dot entries and checking that it's all inside the same tree it is > patching, I could also easily see patch *not* doing that. I consider it rather hard and error-prone and/or an attack vector to choose a course of action for ../ in connection with the -p option. -- David Kastrup -- 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.7.3 no longer applies relative symbolic link patches
On Mon, Jan 26, 2015 at 8:32 AM, Josh Boyer wrote: > > I went to do the Fedora 3.19-rc6 build this morning and it failed in > our buildsystem with: > > + '[' '!' -f /builddir/build/SOURCES/patch-3.19-rc6.xz ']' > + case "$patch" in > + unxz > + patch -p1 -F1 -s > symbolic link target '../../../../../include/dt-bindings' is invalid > error: Bad exit status from /var/tmp/rpm-tmp.mWE3ZL (%prep) Ugh. I don't see anything we can do about this on the git side, and I do kind of understand why 'patch' would be worried about '..' files. In a perfect world, patch would parse the filename and see that it stays within the directory structure of the project, but that is a rather harder thing to do than just say "no dot-dot files". The short-term fix is likely to just use "git apply" instead of "patch". The long-term fix? I dunno. I don't see us not using symlinks, and a quick check says that every *single* symlink we have in the kernel source tree is one that points to a different directory using ".." format. And while I could imagine that "patch" ends up counting the dot-dot entries and checking that it's all inside the same tree it is patching, I could also easily see patch *not* doing that. So using "git apply" _might_ end up being the long-term fix too. I suspect that if "patch" cannot apply even old-style kernel patches due to the symlinks we have in the tree, and people end up having to use "git apply" for them, I might end up starting to just use rename-patches (ie using "git diff -M") for the kernel. I've considered that for a while already, because "patch" _does_ kind of understand them these days, although I think it gets the cross-rename case wrong because it fundamentally works on a file-by-file basis. But if "patch" just ends up not working at all, the argument for trying to maintain backwards compatibility gets really weak. Linus -- 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: [PATCHv3 6/6] refs.c: enable large transactions
On Fri, Jan 23, 2015 at 4:38 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> On Fri, Jan 23, 2015 at 4:14 PM, Junio C Hamano wrote:
>>
>> yeah that's the goal. Though as we're in one transaction, as soon
>> as we have an early exit, the transaction will abort.
>
> An early exit I am talking about is this:
>
> static int write_ref_sha1(struct ref_lock *lock,
> const unsigned char *sha1, const char *logmsg)
> {
> static char term = '\n';
> struct object *o;
>
> if (!lock) {
> errno = EINVAL;
> return -1;
> }
> if (!lock->force_write && !hashcmp(lock->old_sha1, sha1))
> return 0;
>
> It returns 0 and then the transaction side has this call in a loop:
>
> if (!is_null_sha1(update->new_sha1)) {
> if (write_ref_sha1(update->lock, update->new_sha1,
>update->msg)) {
> strbuf_addf(err, "Cannot write to the ref
> lock '%s'.",
> update->refname);
> ret = TRANSACTION_GENERIC_ERROR;
> goto cleanup;
> }
> }
And just after this code path there is the new
+ /* Do not keep all lock files open at the same time. */
+ close_ref(update->lock);
So in case we go the zero return path of write_ref_sha1 the loop looks like
/* Acquire all locks while verifying old values */
for (all updates) {
write_ref_sha1(...)
close_ref(...)
}
In case we do go the non zero return path, it is
if (write_ref_sha1(update->lock, update->new_sha1, ..)
goto cleanup;
...
cleanup:
for (i = 0; i < n; i++)
if (updates[i]->lock)
unlock_ref(updates[i]->lock);
I do not see the problem in the code itself, but rather in understanding
the code. I will send a follow up patch which makes it easier to follow
by removing the early exit with no problem away.
>
>>> If so, shouldn't the write function at least close the file
>>> descriptor even when it knows that the $ref.lock already has the
>>> correct object name? The call to close_ref() is never made when the
>>> early-return codepath is taken as far as I can see.
>>
>> The goto cleanup; will take care of unlocking (and closing fds of) all refs
>
> Yes, if write_ref_sha1() returns with non-zero signaling an error,
> then the goto will trigger.
>
> But if it short-cuts and returns zero, that goto will not be
> reached.
Yes, if the goto is not reached we just drop down to
close_ref(update->lock); which should take care of
the open fd.
Thanks,
Stefan
--
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: [PATCHv2] commit: reword --author error message
On Mon, Jan 26, 2015 at 04:48:33PM +0100, Michael J Gruber wrote:
> - die(_("No existing author found with '%s'"), name);
> + die(_("--author '%s': neither 'Name ' nor a match for an
> existing author"), name);
I had to add to the bikeshed, but I had to read this several times to
make sense of it. It is grammatically:
X [is] neither Y nor Z
except that by eliding the verb ("is"), I somehow had trouble making
sense of Z ("a match...") as a noun.
I came up with:
--author '%s': neither 'Name ' nor matches an existing author
only to see that it was suggested earlier in the thread as a predecessor
to this. ;)
I wonder if adding back in the missing verb, rather than a colon, would
also make more sense:
--author '%s' is neither 'Name ' nor a match for an existing author
> BTW: How do you pull cc/msgid from the list into format-patch/send-email most
> effectively?
> (granted that I move away from gmane/nntp, which is likely)
Here's what I do:
http://article.gmane.org/gmane.comp.version-control.git/262367
-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 1/2] l10n: de.po: translate "leave behind" correctly
2015-01-26 16:34 GMT+01:00 Michael J Gruber : > This message is about leaving orphaned commits behind, not about > behing behind an upstream branch. Try to make this clear. > > Signed-off-by: Michael J Gruber Thanks for both patches! -- 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] l10n: de.po: fix typo
From: Benedikt Heine Signed-off-by: Benedikt Heine Signed-off-by: Ralf Thielow --- po/de.po | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/po/de.po b/po/de.po index b2d4639..596f486 100644 --- a/po/de.po +++ b/po/de.po @@ -4295,8 +4295,8 @@ msgstr "" "git config --global user.name \"Ihr Name\"\n" "git config --global user.email i...@emailadresse.de\n" "\n" -"Nachdem Sie das getan hast, können Sie Ihre Identität für diesen Commit " -"ändern mit:\n" +"Nachdem Sie das getan haben, können Sie Ihre Identität für diesen Commit " +"ändern:\n" "\n" "git commit --amend --reset-author\n" -- 2.3.0.rc1.218.gc1bb7d0 -- 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
implement a stable 'Last updated' in Documentation
Several files in Documentation have an unstable 'Last updated' timestamp. The reason is that their mtime changes every time, which prevents reproducible builds. 341 technical/api-index.txt: technical/api-index-skel.txt \ 342 technical/api-index.sh $(patsubst %,%.txt,$(API_DOCS)) 343 $(QUIET_GEN)cd technical && '$(SHELL_PATH_SQ)' ./api-index.sh 388 howto-index.txt: howto-index.sh $(wildcard howto/*.txt) 389 $(QUIET_GEN)$(RM) $@+ $@ && \ 390 '$(SHELL_PATH_SQ)' ./howto-index.sh $(sort $(wildcard howto/*.txt)) >$@+ && \ 391 mv $@+ $@ 399 $(patsubst %.txt,%.html,$(wildcard howto/*.txt)): %.html : %.txt 400 $(QUIET_ASCIIDOC)$(RM) $@+ $@ && \ 401 sed -e '1,/^$$/d' $< | \ 402 $(TXT_TO_HTML) - >$@+ && \ 403 mv $@+ $@ What file timestamp should be used for them? Likely "../version"? The final file, before passing it to asciidoc, should get a fixed timestamp with 'touch -r $reference_file $file'. Olaf -- 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] git-gui: sort entries in tclIndex
ALL_LIBFILES uses wildcard, which provides the result in directory order. This order depends on the underlying filesystem on the buildhost. To get reproducible builds it is required to sort such list before using them. Signed-off-by: Olaf Hering --- git-gui/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/git-gui/Makefile b/git-gui/Makefile index cde8b2e..7564a18 100644 --- a/git-gui/Makefile +++ b/git-gui/Makefile @@ -258,7 +258,7 @@ lib/tclIndex: $(ALL_LIBFILES) GIT-GUI-VARS rm -f $@ ; \ echo '# Autogenerated by git-gui Makefile' >$@ && \ echo >>$@ && \ -$(foreach p,$(PRELOAD_FILES) $(ALL_LIBFILES),echo '$(subst lib/,,$p)' >>$@ &&) \ +$(foreach p,$(PRELOAD_FILES) $(sort $(ALL_LIBFILES)),echo '$(subst lib/,,$p)' >>$@ &&) \ echo >>$@ ; \ fi -- 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] Documentation/git-add.txt: add `add.ginore-errors` configuration variable
'git add' supports not only `add.ignoreErrors`, but also `add.ignore-errors` configuration variable. Signed-off-by: Alexander Kuleshov --- Documentation/git-add.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt index 1c74907..f68c2a2 100644 --- a/Documentation/git-add.txt +++ b/Documentation/git-add.txt @@ -155,8 +155,8 @@ for "git add --no-all ...", i.e. ignored removed files. If some files could not be added because of errors indexing them, do not abort the operation, but continue adding the others. The command shall still exit with non-zero status. - The configuration variable `add.ignoreErrors` can be set to - true to make this the default behaviour. + The configuration variable `add.ignoreErrors` or `add.ignore-errors` + can be set to true to make this the default behaviour. --ignore-missing:: This option can only be used together with --dry-run. By using -- 2.3.0.rc1.275.g028c360 -- 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.7.3 no longer applies relative symbolic link patches
[Adding Junio's correct email address. Sigh.] On Mon, Jan 26, 2015 at 11:29 AM, Josh Boyer wrote: > Hi, > > I went to do the Fedora 3.19-rc6 build this morning and it failed in > our buildsystem with: > > + '[' '!' -f /builddir/build/SOURCES/patch-3.19-rc6.xz ']' > + case "$patch" in > + unxz > + patch -p1 -F1 -s > symbolic link target '../../../../../include/dt-bindings' is invalid > error: Bad exit status from /var/tmp/rpm-tmp.mWE3ZL (%prep) > > That is coming from the hunk in patch-3.19-rc6.xz that creates the > symbolic link from arch/arm64/boot/dts/include/dt-bindings to > include/dt-bindings. Oddly enough, patch-3.19-rc5.xz contains the > same hunk and it built fine last week. > > Digging in, it seems that upstream patch has decided that relative > symlinks are forbidden now as part of a fix for CVE-2015-1196. You > can find the relevant bugs here: > > https://bugzilla.redhat.com/show_bug.cgi?id=1185928 > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775901#13 > > Aside from locally modifying patch-3.19-rc6.xz, I'm not sure what else > to do. I thought I would send a heads up since anyone that is using > patch-2.7.3 is probably going to run into this issue. > > josh -- 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 push --repo option not working as described in git manual.
The conclusions from the last time we discussed this [*1*], the last word was that git push $some_opt... --repo=$Repo $more_opt... $args... is designed to work exactly like git push $some_opt... $more_opt... $Repo $args... and the documentation that says otherwise is incorrect. It seems that we never followed up on this after we made that determination, which is unfortunate. We should at least correct the documentation. [Reference] *1* http://thread.gmane.org/gmane.comp.version-control.git/110827/focus=111715 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
patch-2.7.3 no longer applies relative symbolic link patches
Hi, I went to do the Fedora 3.19-rc6 build this morning and it failed in our buildsystem with: + '[' '!' -f /builddir/build/SOURCES/patch-3.19-rc6.xz ']' + case "$patch" in + unxz + patch -p1 -F1 -s symbolic link target '../../../../../include/dt-bindings' is invalid error: Bad exit status from /var/tmp/rpm-tmp.mWE3ZL (%prep) That is coming from the hunk in patch-3.19-rc6.xz that creates the symbolic link from arch/arm64/boot/dts/include/dt-bindings to include/dt-bindings. Oddly enough, patch-3.19-rc5.xz contains the same hunk and it built fine last week. Digging in, it seems that upstream patch has decided that relative symlinks are forbidden now as part of a fix for CVE-2015-1196. You can find the relevant bugs here: https://bugzilla.redhat.com/show_bug.cgi?id=1185928 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775901#13 Aside from locally modifying patch-3.19-rc6.xz, I'm not sure what else to do. I thought I would send a heads up since anyone that is using patch-2.7.3 is probably going to run into this issue. josh -- 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
[PATCHv2] commit: reword --author error message
If an --author argument is specified but does not contain a '>' then git tries
to find the argument within the existing authors; and gives the error
message "No existing author found with '%s'" if there is no match.
This is confusing for users who try to specify a valid complete author
name.
Rename the error message to make it clearer that the failure has two
reasons in this case.
(This codepath is touched only when we know already that the argument
cannot be a completely wellformed author ident.)
Signed-off-by: Michael J Gruber
---
There's really not much by me in this patch any more...
Everyone on cc contributed - bikeshedding in its best, productive form!
BTW: How do you pull cc/msgid from the list into format-patch/send-email most
effectively?
(granted that I move away from gmane/nntp, which is likely)
builtin/commit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index 7d90c35..240423b 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -1056,7 +1056,7 @@ static const char *find_author_by_nickname(const char
*name)
clear_mailmap(&mailmap);
return strbuf_detach(&buf, NULL);
}
- die(_("No existing author found with '%s'"), name);
+ die(_("--author '%s': neither 'Name ' nor a match for an
existing author"), name);
}
--
2.3.0.rc1.222.gae238f2
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] l10n: de.po: correct singular form
Signed-off-by: Michael J Gruber --- po/de.po | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/po/de.po b/po/de.po index 65a8ac0..6af1599 100644 --- a/po/de.po +++ b/po/de.po @@ -3559,21 +3559,21 @@ msgid "" "Warning: you are leaving %d commit behind, not connected to\n" "any of your branches:\n" "\n" "%s\n" msgid_plural "" "Warning: you are leaving %d commits behind, not connected to\n" "any of your branches:\n" "\n" "%s\n" msgstr[0] "" -"Warnung: Sie lassen %d Commit zurück. Folgende Commits sind in\n" +"Warnung: Sie lassen %d Commit zurück. Folgender Commit ist in\n" "keinem Ihrer Branches enthalten:\n" "\n" "%s\n" msgstr[1] "" "Warnung: Sie lassen %d Commits zurück. Folgende Commits sind in\n" "keinem Ihrer Branches enthalten:\n" "\n" "%s\n" #: builtin/checkout.c:729 -- 2.3.0.rc1.222.gae238f2 -- 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] l10n: de.po: translate "leave behind" correctly
This message is about leaving orphaned commits behind, not about behing behind an upstream branch. Try to make this clear. Signed-off-by: Michael J Gruber --- po/de.po | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/po/de.po b/po/de.po index 5a93ea8..65a8ac0 100644 --- a/po/de.po +++ b/po/de.po @@ -3559,26 +3559,26 @@ msgid "" "Warning: you are leaving %d commit behind, not connected to\n" "any of your branches:\n" "\n" "%s\n" msgid_plural "" "Warning: you are leaving %d commits behind, not connected to\n" "any of your branches:\n" "\n" "%s\n" msgstr[0] "" -"Warnung: Sie sind um %d Commit hinterher. Folgende Commits sind in\n" +"Warnung: Sie lassen %d Commit zurück. Folgende Commits sind in\n" "keinem Ihrer Branches enthalten:\n" "\n" "%s\n" msgstr[1] "" -"Warnung: Sie sind um %d Commits hinterher. Folgende Commits sind in\n" +"Warnung: Sie lassen %d Commits zurück. Folgende Commits sind in\n" "keinem Ihrer Branches enthalten:\n" "\n" "%s\n" #: builtin/checkout.c:729 #, c-format msgid "" "If you want to keep them by creating a new branch, this may be a good time\n" "to do so with:\n" "\n" -- 2.3.0.rc1.222.gae238f2 -- 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/2] Tweaking the gitk window title.
On 15-01-06 12:51 PM, Marc Branchaud wrote: > The first patch simply changes the title from "gitk: " to " - gitk", > which is the title layout used by most of the applications on my Kubuntu box. > > The second patch is the one that I'm more keen to see accepted. It relies > on the first only in that it follows the new title layout. Ping? M. -- 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
git push --repo option not working as described in git manual.
I am using git 2.2.2 and want to report an issue with git push --repo option. git 2.2.2 manual says that git push --repo=public will push to public only if the current branch does not track a remote branch. See http://git-scm.com/docs/git-push However, I see that git pushes even when the current branch is tracking a remote branch. Here is the test case (push default setting is simple, git version 2.2.2, Mac OS X 10.10.1): 1. I have a local branch "master". 2. "master" tracks remote branch "blah/master". Here "blah" is the remote repository. 3. While I am on my local master branch, I run git push --repo=silver 4. git pushes the local master branch to silver repository. 5. But per git manual, it shouldn't push to silver, as the local branch is tracking "blah/master". So is this broken or am I missing something? Here is another test case (push default setting is simple, git version 2.2.2, Mac OS X 10.10.1): 1. I have a local branch "whoa". 2. "whoa" tracks remote branch "origin/whoa". Here "origin" is the remote repository. 3. While I am on my local whoa branch, I run git push --repo=blah 4. git pushes the local whoa branch to blah repository. 5. But per git manual, it shouldn't push to blah, as the local branch is tracking "origin/whoa". So is this broken or am I missing something? Appreciate your help. -- 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
