* Re: Auto-repo-repair
From: Enrico Weigelt @ 2012-11-19 22:35 UTC (permalink / raw)
To: Drew Northup; +Cc: Jeff King, git
In-Reply-To: <CAM9Z-nmu2MiE9vF9T6Aw8vFTR8mTkuR3akHgZX6+=n3uA4fmpA@mail.gmail.com>
> >> How would the broken repository be sure of what it is missing to
> >> request it from the other side?
> >
> > fsck will find missing objects.
>
> And what about the objects referred to by objects that are missing?
Will be fetched after multiple iterations.
We could even introduce some 'fsck --autorepair' mode, which triggers
it to fetch any missing object from its remotes.
Maybe even introduce a concept of peer object stores, which (a bit like
alternates) are asked for objects that arent locally availabe - that
could be even a plain venti store.
cu
--
Mit freundlichen Grüßen / Kind regards
Enrico Weigelt
VNC - Virtual Network Consult GmbH
Head Of Development
Pariser Platz 4a, D-10117 Berlin
Tel.: +49 (30) 3464615-20
Fax: +49 (30) 3464615-59
enrico.weigelt@vnc.biz; www.vnc.de
^ permalink raw reply
* Re: Failure to extra stable@vger.kernel.org addresses
From: Felipe Contreras @ 2012-11-19 21:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Krzysztof Mazur, Felipe Balbi, git, Tomi Valkeinen
In-Reply-To: <7vk3thxuj2.fsf@alter.siamese.dyndns.org>
On Mon, Nov 19, 2012 at 8:27 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Krzysztof Mazur <krzysiek@podlesie.net> writes:
>
>> On Mon, Nov 19, 2012 at 11:57:47AM +0200, Felipe Balbi wrote:
>>> Hi guys,
>>>
>>> for whatever reason my git has started acting up with
>>> stable@vger.kernel.org addresses. It doesn't manage to extract a valid
>>> adress from the string:
>>>
>>> Cc: <stable@vger.kernel.org> # v3.4 v3.5 v3.6
>>>
>>> Removing the comment at the end of the line makes things work again. I
>>> do remember, however, seeing this working since few weeks back I sent a
>>> mail to stable (in fact the same one I'm using to test), so this could
>>> be related to some perl updates, who knows ?!?
>>
>> You probably just installed Email::Valid package.
>>
>> The current git-send-email works a little better and just prints an error:
>>
>> W: unable to extract a valid address from: <stable@vger.kernel.org> #v3.4 v3.5 v3.6
>>
>>
>> This patch should fix the problem, now after <email> any garbage is
>> removed while extracting address.
>>
>> diff --git a/git-send-email.perl b/git-send-email.perl
>> index 5a7c29d..bb659da 100755
>> --- a/git-send-email.perl
>> +++ b/git-send-email.perl
>> @@ -828,7 +828,7 @@ sub extract_valid_address {
>> # check for a local address:
>> return $address if ($address =~ /^($local_part_regexp)$/);
>>
>> - $address =~ s/^\s*<(.*)>\s*$/$1/;
>> + $address =~ s/^\s*<(.*)>.*$/$1/;
>> if ($have_email_valid) {
>> return scalar Email::Valid->address($address);
>> } else {
>
> Given that the problematic line
>
> Stable Kernel Maintainance Track <stable@vger.kernel.org> # vX.Y
>
> is not even a valid e-mail address, doesn't this new logic belong to
> sanitize_address() conceptually?
That would be great, it would also help the cc-cmd stuff. The
get_maintainer.pl patch from the Linux kernel outputs something like:
David Airlie <airlied@linux.ie> (maintainer:DRM DRIVERS)
Ben Skeggs <bskeggs@redhat.com>
(commit_signer:17/19=89%,commit_signer:43/46=93%)
Maxim Levitsky <maximlevitsky@gmail.com> (commit_signer:3/19=16%)
Greg Kroah-Hartman <gregkh@linuxfoundation.org> (commit_signer:2/19=11%)
Dave Airlie <airlied@redhat.com> (commit_signer:2/19=11%,commit_signer:3/46=7%)
Alex Deucher <alexander.deucher@amd.com> (commit_signer:1/19=5%)
dri-devel@lists.freedesktop.org (open list:DRM DRIVERS)
linux-kernel@vger.kernel.org (open list)
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH v6 0/2] New zsh wrapper
From: Felipe Contreras @ 2012-11-19 21:56 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Marc Khouzam, Marius Storm-Olsen, Marius Storm-Olsen,
Jonathan Nieder, Peter van der Does, SZEDER Gábor,
Mark Lodato
In-Reply-To: <7vpq39xw01.fsf@alter.siamese.dyndns.org>
On Mon, Nov 19, 2012 at 7:55 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> The second patch is new, in order for users to get the same features when
>> sourcing the bash script (they don't need to change anything). They'll get a
>> warning suggesting to check the new script git-completion.zsh. Eventually, that
>> support would be dropped from the bash script.
>>
>> Some people were suggesting something like this, so here it is.
>>
>> Can we merge the zsh wrapper now?
>>
>> Felipe Contreras (2):
>> completion: add new zsh completion
>> completion: start moving to the new zsh completion
>>
>> contrib/completion/git-completion.bash | 104 +++++++++++++++++++--------------
>> contrib/completion/git-completion.zsh | 78 +++++++++++++++++++++++++
>> 2 files changed, 139 insertions(+), 43 deletions(-)
>> create mode 100644 contrib/completion/git-completion.zsh
>
> Thanks; I am a bit puzzled as to the progression of this series, as
> it spanned many months. I *think* the following are the previous
> ones, but I may be mixing up v$n patches for other series, so just
> to make sure (please correct if I am mistaken):
>
> * (v1) http://thread.gmane.org/gmane.comp.version-control.git/189310
> with only git-completion.zsh without any changes to the bash
> side;
Yes, and with a lot of code that is not strictly needed.
> * (v2) http://thread.gmane.org/gmane.comp.version-control.git/189381
> without bash side changes;
Yes, also with more code.
> * (v3) http://thread.gmane.org/gmane.comp.version-control.git/196720
> without bash side changes;
Yes, now it's simpler due to changes in bash side already in.
> * (v6) http://thread.gmane.org/gmane.comp.version-control.git/208170
> with COMPREPLY changes;
Yeap.
> * This one, with removal of zsh specific workarounds from bash
> completion script.
Yes, although that is a separate patch.
> I do not care too much about how v4 and v5 looked like; I primarily
> am interested in knowing if I can discard 208170 from my inbox
> safely ;-).
Yes you can. The rest of the patches I sent in a different series.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH 3/4] pathspec: apply "*.c" optimization from exclude
From: Junio C Hamano @ 2012-11-19 21:20 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1353229989-13075-4-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> -O2 build on linux-2.6, without the patch:
Before the result, can you briefly explain what '"*.c" optimization
from exclude' the title talks about is?
When a pattern contains only a single asterisk, e.g. "foo*bar",
after literally comparing the leading part "foo" with the
string, we can compare the tail of the string and make sure it
matches "bar", instead of running fnmatch() on "*bar" against
the remainder of the string.
The funny thing was that trying to explain what the logic should do
makes one realize potential issues in the implementation of that
logic ;-) See below.
> $ time git rev-list --quiet HEAD -- '*.c'
>
> real 0m40.770s
> user 0m40.290s
> sys 0m0.256s
>
> With the patch
>
> $ time ~/w/git/git rev-list --quiet HEAD -- '*.c'
>
> real 0m34.288s
> user 0m33.997s
> sys 0m0.205s
>
> The above command is not supposed to be widely popular.
Hrm, perhaps. I use "git grep <pattern> -- \*.c" quite a lot, but
haven't seen use case for \*.c in the context of the "log" family.
> diff --git a/cache.h b/cache.h
> index bf031f1..d18f584 100644
> --- a/cache.h
> +++ b/cache.h
> @@ -473,6 +473,8 @@ extern int index_name_is_other(const struct index_state *, const char *, int);
> extern int ie_match_stat(const struct index_state *, struct cache_entry *, struct stat *, unsigned int);
> extern int ie_modified(const struct index_state *, struct cache_entry *, struct stat *, unsigned int);
>
> +#define PSF_ONESTAR 1
Together with the GF_ prefix in the previous, PSF_ prefix needs a
bit of in-code explanation. Is it just an RC3L (random combination
of 3 letters?)
> @@ -46,6 +46,12 @@ inline int git_fnmatch(const char *pattern, const char *string,
> pattern += prefix;
> string += prefix;
> }
> + if (flags & GF_ONESTAR) {
> + int pattern_len = strlen(++pattern);
> + int string_len = strlen(string);
> + return strcmp(pattern,
> + string + string_len - pattern_len);
> + }
What happens when pattern="foo*oob" and string="foob"?
The prefix match before this code determines that the literal prefix
in the pattern matches with the early part of the string, and makes
pattern="*oob" and string="b".
When you come to strcmp(), you see that string_len is 1, pattern_len
is 3, and pattern is "oob". string+string_len-pattern_len = "oob",
one past the beginning of the original string "foob". They match.
Oops?
return (string_len < pattern_len) ||
strcmp(pattern, string + string_len - pattern_len);
perhaps?
^ permalink raw reply
* Re: [PATCH 2/4] pathspec: do exact comparison on the leading non-wildcard part
From: Junio C Hamano @ 2012-11-19 20:54 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1353229989-13075-3-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
> dir.c | 18 +++++++++++++++++-
> dir.h | 8 ++++++++
> tree-walk.c | 6 ++++--
> 3 files changed, 29 insertions(+), 3 deletions(-)
>
> diff --git a/dir.c b/dir.c
> index c391d46..e4e6ca1 100644
> --- a/dir.c
> +++ b/dir.c
> @@ -34,6 +34,21 @@ int fnmatch_icase(const char *pattern, const char *string, int flags)
> return fnmatch(pattern, string, flags | (ignore_case ? FNM_CASEFOLD : 0));
> }
>
> +inline int git_fnmatch(const char *pattern, const char *string,
> + int flags, int prefix)
> +{
> + int fnm_flags = 0;
> + if (flags & GF_PATHNAME)
> + fnm_flags |= FNM_PATHNAME;
> + if (prefix > 0) {
> + if (strncmp(pattern, string, prefix))
> + return FNM_NOMATCH;
> + pattern += prefix;
> + string += prefix;
> + }
> + return fnmatch(pattern, string, fnm_flags);
How would we protect this optimization from future breakages?
Once we start using FNM_PERIOD, this becomes unsafe, as the simple
part in "foo/bar*baz" would be "foo/bar" with remainder "*baz".
The pattern "foo/bar*baz" should match "foo/bar.baz" with FNM_PERIOD
set. But with this optimization, fnmatch is fed pattern="*baz",
string=".baz" and they would not match.
^ permalink raw reply
* Re: [PATCH 1/4] pathspec: save the non-wildcard length part
From: Junio C Hamano @ 2012-11-19 20:48 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1353229989-13075-2-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> We marks pathspec with wildcards with the field use_wildcard. We could
s/marks/mark;
> do better by saving the length of the non-wildcard part, which can be
> for optimizations such as f9f6e2c (exclude: do strcmp as much as
s/for /used &/;
> possible before fnmatch - 2012-06-07)
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
The code looks straightforward and correct. Thanks.
> ---
> builtin/ls-files.c | 2 +-
> builtin/ls-tree.c | 2 +-
> cache.h | 2 +-
> dir.c | 6 +++---
> tree-walk.c | 4 ++--
> 5 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/builtin/ls-files.c b/builtin/ls-files.c
> index b5434af..4a9ee69 100644
> --- a/builtin/ls-files.c
> +++ b/builtin/ls-files.c
> @@ -337,7 +337,7 @@ void overlay_tree_on_cache(const char *tree_name, const char *prefix)
> matchbuf[0] = prefix;
> matchbuf[1] = NULL;
> init_pathspec(&pathspec, matchbuf);
> - pathspec.items[0].use_wildcard = 0;
> + pathspec.items[0].nowildcard_len = pathspec.items[0].len;
> } else
> init_pathspec(&pathspec, NULL);
> if (read_tree(tree, 1, &pathspec))
> diff --git a/builtin/ls-tree.c b/builtin/ls-tree.c
> index 235c17c..fb76e38 100644
> --- a/builtin/ls-tree.c
> +++ b/builtin/ls-tree.c
> @@ -168,7 +168,7 @@ int cmd_ls_tree(int argc, const char **argv, const char *prefix)
>
> init_pathspec(&pathspec, get_pathspec(prefix, argv + 1));
> for (i = 0; i < pathspec.nr; i++)
> - pathspec.items[i].use_wildcard = 0;
> + pathspec.items[i].nowildcard_len = pathspec.items[i].len;
> pathspec.has_wildcard = 0;
> tree = parse_tree_indirect(sha1);
> if (!tree)
> diff --git a/cache.h b/cache.h
> index dbd8018..bf031f1 100644
> --- a/cache.h
> +++ b/cache.h
> @@ -482,7 +482,7 @@ struct pathspec {
> struct pathspec_item {
> const char *match;
> int len;
> - unsigned int use_wildcard:1;
> + int nowildcard_len;
> } *items;
> };
>
> diff --git a/dir.c b/dir.c
> index 5a83aa7..c391d46 100644
> --- a/dir.c
> +++ b/dir.c
> @@ -230,7 +230,7 @@ static int match_pathspec_item(const struct pathspec_item *item, int prefix,
> return MATCHED_RECURSIVELY;
> }
>
> - if (item->use_wildcard && !fnmatch(match, name, 0))
> + if (item->nowildcard_len < item->len && !fnmatch(match, name, 0))
> return MATCHED_FNMATCH;
>
> return 0;
> @@ -1429,8 +1429,8 @@ int init_pathspec(struct pathspec *pathspec, const char **paths)
>
> item->match = path;
> item->len = strlen(path);
> - item->use_wildcard = !no_wildcard(path);
> - if (item->use_wildcard)
> + item->nowildcard_len = simple_length(path);
> + if (item->nowildcard_len < item->len)
> pathspec->has_wildcard = 1;
> }
>
> diff --git a/tree-walk.c b/tree-walk.c
> index 3f54c02..af871c5 100644
> --- a/tree-walk.c
> +++ b/tree-walk.c
> @@ -626,7 +626,7 @@ enum interesting tree_entry_interesting(const struct name_entry *entry,
> &never_interesting))
> return entry_interesting;
>
> - if (item->use_wildcard) {
> + if (item->nowildcard_len < item->len) {
> if (!fnmatch(match + baselen, entry->path, 0))
> return entry_interesting;
>
> @@ -642,7 +642,7 @@ enum interesting tree_entry_interesting(const struct name_entry *entry,
> }
>
> match_wildcards:
> - if (!item->use_wildcard)
> + if (item->nowildcard_len == item->len)
> continue;
>
> /*
^ permalink raw reply
* Re: `git mv` has ambiguous error message for non-existing target
From: Patrick Lehner @ 2012-11-19 21:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpq3cja4y.fsf@alter.siamese.dyndns.org>
On Sa 17 Nov 2012 20:35:09 CET, Junio C Hamano wrote:
> Patrick Lehner <lehner.patrick@gmx.de> writes:
>
>> But just because mv's error essage isnt very good, does that mean git
>> mv's error message mustn't be better?
>
> Did I say the error message from 'mv' was not very good in the
> message you are responding to (by the way, this is why you should
> never top-post when you are responding to a message on this list)?
>
> I meant to say that the message from 'mv' is good enough, so is the
> one given by 'git mv'.
>
> I wouldn't reject a patch that updates our message to something more
> informative without looking at it, though.
I apologize for top-posting -- I don't usually use mailing lists and am
not aware of the usual netiquette.
And yes, I did interpret a bit more into your reply than was there.
I wouldn't call the 'mv' error message "good enough" in this case, but
very well, opinions may very well differ. Unfortunately, I have no time
to get into the git code and contribution guidelines, so I cannot
submit a patch myself. I would appreciate if someone else who shares my
sentiment and knows their way around the git source a bit could find
the time to add this :)
Regards,
Patrick
^ permalink raw reply
* Re: git-describe fails with "--dirty is incompatible with committishes" if passing HEAD as argument
From: Francis Moreau @ 2012-11-19 20:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfw45xu4e.fsf@alter.siamese.dyndns.org>
On Mon, Nov 19, 2012 at 8:36 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Francis Moreau <francis.moro@gmail.com> writes:
>
>> Inside the kernel repository, I tried this:
>>
>> $ git describe --dirty --match 'v[0-9]*' --abbrev=4 HEAD
>> fatal: --dirty is incompatible with committishes
>>
>> If 'HEAD' is removed then git-describe works as expected.
>>
>> Is that expected ?
>
> I would say so, at least in modern codebase.
>
> "git describe" without any commit object name used to mean "describe
> the HEAD commit using the better known points" before the --dirty
> option was introduced.
>
> But "--dirty" makes it describe the current checkout. For example,
> output from "git describe --dirty" v1.8.0-211-gd8b4531-dirty means
> "your working tree contains work-in-progress based on d8b4531, which
> is 211 commits ahead of the v1.8.0 tag". So conceptually, it should
> not take any commit, even if it were spelled HEAD.
>
> "git describe --dirty HEAD^^" would be an utter nonsense for the
> same reason.
Thanks for explaining, that makes sense.
--
Francis
^ permalink raw reply
* Re: [PATCH v3 0/6] completion: test consolidations
From: Junio C Hamano @ 2012-11-19 20:34 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: git, Felipe Contreras
In-Reply-To: <1353235917-13059-1-git-send-email-felipe.contreras@gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> These started from a discussion with SZEDER, but then I realized there were
> many improvements possible.
Thanks; I'd loop him in and wait for his acks/reviews.
>
> Changes since v2:
>
> * Updated comments and commit messages
>
> Changes since v1:
>
> * A lot more cleanups
>
> Felipe Contreras (6):
> completion: add comment for test_completion()
> completion: standardize final space marker in tests
> completion: simplify tests using test_completion_long()
> completion: consolidate test_completion*() tests
> completion: refactor __gitcomp related tests
> completion: simplify __gitcomp() test helper
>
> t/t9902-completion.sh | 133 +++++++++++++++++++-------------------------------
> 1 file changed, 51 insertions(+), 82 deletions(-)
^ permalink raw reply
* Re: [PATCH v4.1 5/5] push: update remote tags only with force
From: Junio C Hamano @ 2012-11-19 20:23 UTC (permalink / raw)
To: Chris Rorvick
Cc: git, Angelo Borsotti, Drew Northup, Michael Haggerty,
Philip Oakley, Johannes Sixt, Kacper Kornet, Jeff King,
Felipe Contreras
In-Reply-To: <1353189237-19491-1-git-send-email-chris@rorvick.com>
Chris Rorvick <chris@rorvick.com> writes:
> References are allowed to update from one commit-ish to another if the
> former is a ancestor of the latter. This behavior is oriented to
> branches which are expected to move with commits. Tag references are
> expected to be static in a repository, though, thus an update to a
> tag (lightweight and annotated) should be rejected unless the update is
> forced.
>
> To enable this functionality, the following checks have been added to
> set_ref_status_for_push() for updating refs (i.e, not new or deletion)
> to restrict fast-forwarding in pushes:
>
> 1) The old and new references must be commits. If this fails,
> it is not a valid update for a branch.
>
> 2) The reference name cannot start with "refs/tags/". This
> catches lightweight tags which (usually) point to commits
> and therefore would not be caught by (1).
>
> If either of these checks fails, then it is flagged (by default) with a
> status indicating the update is being rejected due to the reference
> already existing in the remote. This can be overridden by passing
> --force to git push.
This, if it were implemented back when we first added "git push",
would have been a nice safety, but added after 1.8.0 it would be a
regression, so we would need backward compatibility notes in the
release notes.
Not an objection; just making a mental note.
> diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
> index fe46c42..479e25f 100644
> --- a/Documentation/git-push.txt
> +++ b/Documentation/git-push.txt
> @@ -51,11 +51,11 @@ be named. If `:`<dst> is omitted, the same ref as <src> will be
> updated.
> +
> The object referenced by <src> is used to update the <dst> reference
> -on the remote side, but by default this is only allowed if the
> -update can fast-forward <dst>. By having the optional leading `+`,
> -you can tell git to update the <dst> ref even when the update is not a
> -fast-forward. This does *not* attempt to merge <src> into <dst>. See
> -EXAMPLES below for details.
> +on the remote side. By default this is only allowed if the update is
> +a branch, and then only if it can fast-forward <dst>. By having the
I can already see the next person asking "I can update refs/notes
the same way. The doc says it applies only to the branches. Is
this a bug?".
> diff --git a/cache.h b/cache.h
> index f410d94..127e504 100644
> --- a/cache.h
> +++ b/cache.h
> @@ -1004,13 +1004,14 @@ struct ref {
> requires_force:1,
> merge:1,
> nonfastforward:1,
> - is_a_tag:1,
> + forwardable:1,
This is somewhat an unfortunate churn. Perhaps is_a_tag could have
started its life under its final name in the series?
I am assuming that the struct members will be initialized to 0 (false),
so everything by default is now not forwardable if somebody forgets
to set this flag?
> enum {
> REF_STATUS_NONE = 0,
> REF_STATUS_OK,
> REF_STATUS_REJECT_NONFASTFORWARD,
> + REF_STATUS_REJECT_ALREADY_EXISTS,
> REF_STATUS_REJECT_NODELETE,
> REF_STATUS_UPTODATE,
> REF_STATUS_REMOTE_REJECT,
> diff --git a/remote.c b/remote.c
> index 44e72d6..a723f7a 100644
> --- a/remote.c
> +++ b/remote.c
> @@ -1311,14 +1311,24 @@ void set_ref_status_for_push(struct ref *remote_refs, int send_mirror,
> * to overwrite it; you would not know what you are losing
> * otherwise.
> *
> - * (3) if both new and old are commit-ish, and new is a
> - * descendant of old, it is OK.
> + * (3) if new is commit-ish and old is a commit, new is a
> + * descendant of old, and the reference is not of the
> + * refs/tags/ hierarchy it is OK.
> *
> * (4) regardless of all of the above, removing :B is
> * always allowed.
> */
I think this is unreadable. Isn't this more like
(1.5) if the destination is inside refs/tags/ and already
exists, you are not allowed to overwrite it without
--force or +A:B notation.
early in the rule set?
> - ref->is_a_tag = !prefixcmp(ref->name, "refs/tags/");
> + if (prefixcmp(ref->name, "refs/tags/")) {
> + /* Additionally, disallow fast-forwarding if
> + * the old object is not a commit. This kicks
> + * out annotated tags that might pass the
> + * is_newer() test but dangle if the reference
> + * is updated.
> + */
Huh? prefixcmp() excludes refs/tags/ hierarchy. What is an
annotated tag doing there? Is this comment outdated???
/*
* Also please end the first line of a multi-line
* comment with '/', '*', and nothing else.
*/
Regarding the other arm of this "if (not in refs/tags/ hierarchy)",
what happens when refs/tags/foo is a reference to a blob or a tree?
This series declares that the point of tag is not to let people to
move it willy-nilly, and I think it is in line with its spirit if
you just rejected non-creation events.
Also, I suspect that you do not even need to have old object locally
when looking at refs/tags/ hierarchy. "Do not overwrite tags" can
be enforced by only noticing that they already have something; you
do not know what that something actually is to prevent yourself from
overwriting it. You may have to update the rule (2) in remote.c
around l.1311 for this.
> +test_expect_success 'push requires --force to update lightweight tag' '
> + mk_test heads/master &&
> + mk_child child1 &&
> + mk_child child2 &&
> + (
> + cd child1 &&
> + git tag Tag &&
> + git push ../child2 Tag &&
Don't you want to make sure that another "git push ../child2 Tag" at
this point, i.e. attempt to update Tag with the same, should succeed
without --force?
^ permalink raw reply
* Re: git-describe fails with "--dirty is incompatible with committishes" if passing HEAD as argument
From: Junio C Hamano @ 2012-11-19 19:36 UTC (permalink / raw)
To: Francis Moreau; +Cc: git
In-Reply-To: <CAC9WiBjw0W4kLCKMj6HhdjAXOJYpDW2Rgncb+06ahjiYOWtZ8Q@mail.gmail.com>
Francis Moreau <francis.moro@gmail.com> writes:
> Inside the kernel repository, I tried this:
>
> $ git describe --dirty --match 'v[0-9]*' --abbrev=4 HEAD
> fatal: --dirty is incompatible with committishes
>
> If 'HEAD' is removed then git-describe works as expected.
>
> Is that expected ?
I would say so, at least in modern codebase.
"git describe" without any commit object name used to mean "describe
the HEAD commit using the better known points" before the --dirty
option was introduced.
But "--dirty" makes it describe the current checkout. For example,
output from "git describe --dirty" v1.8.0-211-gd8b4531-dirty means
"your working tree contains work-in-progress based on d8b4531, which
is 211 commits ahead of the v1.8.0 tag". So conceptually, it should
not take any commit, even if it were spelled HEAD.
"git describe --dirty HEAD^^" would be an utter nonsense for the
same reason.
^ permalink raw reply
* Re: Failure to extra stable@vger.kernel.org addresses
From: Junio C Hamano @ 2012-11-19 19:27 UTC (permalink / raw)
To: Krzysztof Mazur; +Cc: Felipe Balbi, git, Tomi Valkeinen
In-Reply-To: <20121119151845.GA29678@shrek.podlesie.net>
Krzysztof Mazur <krzysiek@podlesie.net> writes:
> On Mon, Nov 19, 2012 at 11:57:47AM +0200, Felipe Balbi wrote:
>> Hi guys,
>>
>> for whatever reason my git has started acting up with
>> stable@vger.kernel.org addresses. It doesn't manage to extract a valid
>> adress from the string:
>>
>> Cc: <stable@vger.kernel.org> # v3.4 v3.5 v3.6
>>
>> Removing the comment at the end of the line makes things work again. I
>> do remember, however, seeing this working since few weeks back I sent a
>> mail to stable (in fact the same one I'm using to test), so this could
>> be related to some perl updates, who knows ?!?
>
> You probably just installed Email::Valid package.
>
> The current git-send-email works a little better and just prints an error:
>
> W: unable to extract a valid address from: <stable@vger.kernel.org> #v3.4 v3.5 v3.6
>
>
> This patch should fix the problem, now after <email> any garbage is
> removed while extracting address.
>
> diff --git a/git-send-email.perl b/git-send-email.perl
> index 5a7c29d..bb659da 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -828,7 +828,7 @@ sub extract_valid_address {
> # check for a local address:
> return $address if ($address =~ /^($local_part_regexp)$/);
>
> - $address =~ s/^\s*<(.*)>\s*$/$1/;
> + $address =~ s/^\s*<(.*)>.*$/$1/;
> if ($have_email_valid) {
> return scalar Email::Valid->address($address);
> } else {
Given that the problematic line
Stable Kernel Maintainance Track <stable@vger.kernel.org> # vX.Y
is not even a valid e-mail address, doesn't this new logic belong to
sanitize_address() conceptually?
^ permalink raw reply
* Re: [PATCH v6 0/2] New zsh wrapper
From: Junio C Hamano @ 2012-11-19 18:55 UTC (permalink / raw)
To: Felipe Contreras
Cc: git, Marc Khouzam, Marius Storm-Olsen, Marius Storm-Olsen,
Jonathan Nieder, Peter van der Does, SZEDER Gábor,
Mark Lodato
In-Reply-To: <1353236889-15052-1-git-send-email-felipe.contreras@gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> The second patch is new, in order for users to get the same features when
> sourcing the bash script (they don't need to change anything). They'll get a
> warning suggesting to check the new script git-completion.zsh. Eventually, that
> support would be dropped from the bash script.
>
> Some people were suggesting something like this, so here it is.
>
> Can we merge the zsh wrapper now?
>
> Felipe Contreras (2):
> completion: add new zsh completion
> completion: start moving to the new zsh completion
>
> contrib/completion/git-completion.bash | 104 +++++++++++++++++++--------------
> contrib/completion/git-completion.zsh | 78 +++++++++++++++++++++++++
> 2 files changed, 139 insertions(+), 43 deletions(-)
> create mode 100644 contrib/completion/git-completion.zsh
Thanks; I am a bit puzzled as to the progression of this series, as
it spanned many months. I *think* the following are the previous
ones, but I may be mixing up v$n patches for other series, so just
to make sure (please correct if I am mistaken):
* (v1) http://thread.gmane.org/gmane.comp.version-control.git/189310
with only git-completion.zsh without any changes to the bash
side;
* (v2) http://thread.gmane.org/gmane.comp.version-control.git/189381
without bash side changes;
* (v3) http://thread.gmane.org/gmane.comp.version-control.git/196720
without bash side changes;
* (v6) http://thread.gmane.org/gmane.comp.version-control.git/208170
with COMPREPLY changes;
* This one, with removal of zsh specific workarounds from bash
completion script.
I do not care too much about how v4 and v5 looked like; I primarily
am interested in knowing if I can discard 208170 from my inbox
safely ;-).
Thanks.
^ permalink raw reply
* Re: Should --pretty=format:%b respect i18n.logoutputencoding just like normal "git log"?
From: Pat Notz @ 2012-11-19 17:42 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Git Mailing List
In-Reply-To: <CACsJy8Ag7wZCKeTM-fW7MUjWs=7xq7ciwhfx4kroJupwvs0dXg@mail.gmail.com>
On Mon, Nov 19, 2012 at 6:08 AM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> Changes around this code in history is a bit unclear. User format
> learns to get log encoding from a field in 177b29d (pretty.c: teach
> format_commit_message() to reencode the output - 2010-11-02), but this
> field is only set for --fixup and --squash (in a few commits later).
> This makes "git log --pretty=format:%b" always ignore the output
> encoding config key. I don't think %b output should be different from
> normal log output, which does respect output encoding. Pat, any
> reasons not to do it?
Nope, that looks like it was an oversight on my part. Nice find.
~ Pat
> --
> Duy
^ permalink raw reply
* git-describe fails with "--dirty is incompatible with committishes" if passing HEAD as argument
From: Francis Moreau @ 2012-11-19 15:47 UTC (permalink / raw)
To: git
Hello,
Inside the kernel repository, I tried this:
$ git describe --dirty --match 'v[0-9]*' --abbrev=4 HEAD
fatal: --dirty is incompatible with committishes
If 'HEAD' is removed then git-describe works as expected.
Is that expected ?
Thanks
--
Francis
^ permalink raw reply
* Re: Failure to extra stable@vger.kernel.org addresses
From: Felipe Balbi @ 2012-11-19 15:37 UTC (permalink / raw)
To: Krzysztof Mazur; +Cc: Felipe Balbi, git, Tomi Valkeinen
In-Reply-To: <20121119151845.GA29678@shrek.podlesie.net>
[-- Attachment #1: Type: text/plain, Size: 1152 bytes --]
Hi,
On Mon, Nov 19, 2012 at 04:18:45PM +0100, Krzysztof Mazur wrote:
> On Mon, Nov 19, 2012 at 11:57:47AM +0200, Felipe Balbi wrote:
> > Hi guys,
> >
> > for whatever reason my git has started acting up with
> > stable@vger.kernel.org addresses. It doesn't manage to extract a valid
> > adress from the string:
> >
> > Cc: <stable@vger.kernel.org> # v3.4 v3.5 v3.6
> >
> > Removing the comment at the end of the line makes things work again. I
> > do remember, however, seeing this working since few weeks back I sent a
> > mail to stable (in fact the same one I'm using to test), so this could
> > be related to some perl updates, who knows ?!?
>
> You probably just installed Email::Valid package.
>
> The current git-send-email works a little better and just prints an error:
>
> W: unable to extract a valid address from: <stable@vger.kernel.org> #v3.4 v3.5 v3.6
>
>
> This patch should fix the problem, now after <email> any garbage is
> removed while extracting address.
worked like a charm. When you send as a proper patch, you can add my:
Tested-by: Felipe Balbi <balbi@ti.com>
thanks
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: Failure to extra stable@vger.kernel.org addresses
From: Krzysztof Mazur @ 2012-11-19 15:18 UTC (permalink / raw)
To: Felipe Balbi; +Cc: git, Tomi Valkeinen
In-Reply-To: <20121119095747.GA13552@arwen.pp.htv.fi>
On Mon, Nov 19, 2012 at 11:57:47AM +0200, Felipe Balbi wrote:
> Hi guys,
>
> for whatever reason my git has started acting up with
> stable@vger.kernel.org addresses. It doesn't manage to extract a valid
> adress from the string:
>
> Cc: <stable@vger.kernel.org> # v3.4 v3.5 v3.6
>
> Removing the comment at the end of the line makes things work again. I
> do remember, however, seeing this working since few weeks back I sent a
> mail to stable (in fact the same one I'm using to test), so this could
> be related to some perl updates, who knows ?!?
You probably just installed Email::Valid package.
The current git-send-email works a little better and just prints an error:
W: unable to extract a valid address from: <stable@vger.kernel.org> #v3.4 v3.5 v3.6
This patch should fix the problem, now after <email> any garbage is
removed while extracting address.
diff --git a/git-send-email.perl b/git-send-email.perl
index 5a7c29d..bb659da 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -828,7 +828,7 @@ sub extract_valid_address {
# check for a local address:
return $address if ($address =~ /^($local_part_regexp)$/);
- $address =~ s/^\s*<(.*)>\s*$/$1/;
+ $address =~ s/^\s*<(.*)>.*$/$1/;
if ($have_email_valid) {
return scalar Email::Valid->address($address);
} else {
Krzysiek
^ permalink raw reply related
* Should --pretty=format:%b respect i18n.logoutputencoding just like normal "git log"?
From: Nguyen Thai Ngoc Duy @ 2012-11-19 13:08 UTC (permalink / raw)
To: Git Mailing List, Pat Notz
Changes around this code in history is a bit unclear. User format
learns to get log encoding from a field in 177b29d (pretty.c: teach
format_commit_message() to reencode the output - 2010-11-02), but this
field is only set for --fixup and --squash (in a few commits later).
This makes "git log --pretty=format:%b" always ignore the output
encoding config key. I don't think %b output should be different from
normal log output, which does respect output encoding. Pat, any
reasons not to do it?
--
Duy
^ permalink raw reply
* Failure to extra stable@vger.kernel.org addresses
From: Felipe Balbi @ 2012-11-19 9:57 UTC (permalink / raw)
To: git; +Cc: Tomi Valkeinen
[-- Attachment #1.1: Type: text/plain, Size: 2492 bytes --]
Hi guys,
for whatever reason my git has started acting up with
stable@vger.kernel.org addresses. It doesn't manage to extract a valid
adress from the string:
Cc: <stable@vger.kernel.org> # v3.4 v3.5 v3.6
Removing the comment at the end of the line makes things work again. I
do remember, however, seeing this working since few weeks back I sent a
mail to stable (in fact the same one I'm using to test), so this could
be related to some perl updates, who knows ?!?
Anyway, here's output of git-send-email:
> $ git send-email --to linux-usb@vger.kernel.org ../linux/0001-usb-dwc3-gadget-fix-endpoint-always-busy-bug.diff --dry-run
> ../linux/0001-usb-dwc3-gadget-fix-endpoint-always-busy-bug.diff
> (mbox) Adding cc: Felipe Balbi <balbi@ti.com> from line 'From: Felipe Balbi <balbi@ti.com>'
> (body) Adding cc: <stable@vger.kernel.org> #v3.4 v3.5 v3.6 from line 'Cc: <stable@vger.kernel.org> #v3.4 v3.5 v3.6'
> (body) Adding cc: Felipe Balbi <balbi@ti.com> from line 'Signed-off-by: Felipe Balbi <balbi@ti.com>'
> Use of uninitialized value $cc in string eq at /usr/libexec/git-core/git-send-email line 997.
> Use of uninitialized value $cc in quotemeta at /usr/libexec/git-core/git-send-email line 997.
> W: unable to extract a valid address from: <stable@vger.kernel.org> #v3.4 v3.5 v3.6
> W: unable to extract a valid address from: <stable@vger.kernel.org> #v3.4 v3.5 v3.6
> Dry-OK. Log says:
> Sendmail: /usr/bin/msmtp -i linux-usb@vger.kernel.org balbi@ti.com
> From: Felipe Balbi <balbi@ti.com>
> To: linux-usb@vger.kernel.org
> Cc: Felipe Balbi <balbi@ti.com>
> Subject: [PATCH] usb: dwc3: gadget: fix 'endpoint always busy' bug
> Date: Mon, 19 Nov 2012 11:54:16 +0200
> Message-Id: <1353318856-14987-1-git-send-email-balbi@ti.com>
> X-Mailer: git-send-email 1.8.0
>
> Result: OK
$ perl --version
This is perl 5, version 14, subversion 2 (v5.14.2) built for x86_64-linux-gnu-thread-multi
(with 72 registered patches, see perl -V for more detail)
Copyright 1987-2011, Larry Wall
Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 5 source kit.
Complete documentation for Perl, including FAQ lists, should be found on
this system using "man perl" or "perldoc perl". If you have access to the
Internet, point your browser at http://www.perl.org/, the Perl Home Page.
And attached you can find the patch file which I'm using
--
balbi
[-- Attachment #1.2: 0001-usb-dwc3-gadget-fix-endpoint-always-busy-bug.diff --]
[-- Type: text/x-diff, Size: 1363 bytes --]
From 041d81f493d90c940ec41f0ec98bc7c4f2fba431 Mon Sep 17 00:00:00 2001
From: Felipe Balbi <balbi@ti.com>
Date: Thu, 4 Oct 2012 11:58:00 +0300
Subject: [PATCH] usb: dwc3: gadget: fix 'endpoint always busy' bug
If a USB transfer has already been started, meaning
we have already issued StartTransfer command to that
particular endpoint, DWC3_EP_BUSY flag has also
already been set.
When we try to cancel this transfer which is already
in controller's cache, we will not receive XferComplete
event and we must clear DWC3_EP_BUSY in order to allow
subsequent requests to be properly started.
The best place to clear that flag is right after issuing
DWC3_DEPCMD_ENDTRANSFER.
Cc: <stable@vger.kernel.org> #v3.4 v3.5 v3.6
Reported-by: Moiz Sonasath <m-sonasath@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
---
drivers/usb/dwc3/gadget.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index c9e729a..7b7dedd 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1904,7 +1904,7 @@ static void dwc3_stop_active_transfer(struct dwc3 *dwc, u32 epnum)
ret = dwc3_send_gadget_ep_cmd(dwc, dep->number, cmd, ¶ms);
WARN_ON_ONCE(ret);
dep->resource_index = 0;
-
+ dep->flags &= ~DWC3_EP_BUSY;
udelay(100);
}
--
1.8.0
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related
* Re: verifying git file contents without checking out history?
From: Marc Weber @ 2012-11-19 5:32 UTC (permalink / raw)
To: git
In-Reply-To: <7vtxsmxkcp.fsf@alter.siamese.dyndns.org>
Excerpts from Junio C Hamano's message of Mon Nov 19 05:55:18 +0100 2012:
> Define what you mean by "contents".
contents = the files git archive HEAD would put into an archive, those
determining a build result.
How could the repo be compromised:
1) An attacker triest to find a hash collision in the HEAD tree.
However finding a hash collision which also is a useful attack should
be very hard.
2) The attacker modifies a file the way he likes (thus the attack is
easy), then he tries to modify the history in a way causing the same
commit hash.
Probably this is very hard, too.
Does this make sense? I feared that having a HEAD^ you can manipulate to
change the hash of HEAD makes it easier to cause a collision without the
user noticing.
However adding additional useless files to HEAD could be used to cause a
imaginary hash collision, too. Thus having a second hash would not be of
any benefit. Thus referring to commit by hash (using all hash digits) is
best you can do. I finally got it.
Thanks
Marc Weber
^ permalink raw reply
* Re: verifying git file contents without checking out history?
From: Junio C Hamano @ 2012-11-19 4:55 UTC (permalink / raw)
To: Marc Weber; +Cc: git
In-Reply-To: <1353287836-sup-270@nixos>
Marc Weber <marco-oweber@gmx.de> writes:
> git clone --depth=20 $url; git checkout $hash
>
> How to verify that I have the contents I think I have - given that I
> trust my local git executable?
Define what you mean by "contents". Do you care only about the tree
state recorded in that $hash, and you also trust that $hash is the
correct one?
$ git cat-object commit $hash | git hash-object --stdin -t commit
would be a way to verify that you do have the commit object
everybody else calls $hash, and you can verify the objects contained
within the commit whose name is $hash (i.e. its tree and its
parents) in a similar way. Use "git ls-tree $tree" to find out the
objects your top-level tree recorded in the commit $hash, and you
can verify the contents recorded in the tree object recursively.
^ permalink raw reply
* Re: Auto-repo-repair
From: Drew Northup @ 2012-11-19 3:30 UTC (permalink / raw)
To: Enrico Weigelt; +Cc: Jeff King, git
In-Reply-To: <66719060-db68-45b4-8453-2fd996f27657@zcs>
On Sun, Nov 18, 2012 at 11:55 AM, Enrico Weigelt <enrico.weigelt@vnc.biz> wrote:
>
>> How would the broken repository be sure of what it is missing to
>> request it from the other side?
>
> fsck will find missing objects.
And what about the objects referred to by objects that are missing?
Jeff's solution doesn't suffer from this recursivity problem.
--
-Drew Northup
--------------------------------------------------------------
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
^ permalink raw reply
* verifying git file contents without checking out history?
From: Marc Weber @ 2012-11-19 1:50 UTC (permalink / raw)
To: git
git clone --depth=20 $url; git checkout $hash
How to verify that I have the contents I think I have - given that I
trust my local git executable?
Would it be enough to also store the git log --pretty=format:%T $hash
value and check that only? %T is the root tree hash.
Does git checkout verify the file tree checksum when receiving all blob
objects from a server?
Then verifying that %T didn't change should be enough to enable me
fetching sources and trust them without running git fsck which would
fetch all history.
Marc Weber
^ permalink raw reply
* [PATCH] USE CGYWIN_V15_WIN32API as macro to select api for cygwin
From: Mark Levedahl @ 2012-11-18 21:16 UTC (permalink / raw)
To: gitster; +Cc: git, Mark Levedahl
In-Reply-To: <7va9ufjqu1.fsf@alter.siamese.dyndns.org>
The previous macro was confusing to some, and did not include "cygwin" in
its name. The updated name more clearly expresses a choice of the
win32api implementation that shipped with version 1.5 of cygwin.
Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
---
Makefile | 6 +++---
compat/cygwin.c | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Makefile b/Makefile
index cf0ecde..9731c85 100644
--- a/Makefile
+++ b/Makefile
@@ -1091,7 +1091,7 @@ ifeq ($(uname_O),Cygwin)
NO_SYMLINK_HEAD = YesPlease
NO_IPV6 = YesPlease
OLD_ICONV = UnfortunatelyYes
- V15_MINGW_HEADERS = YesPlease
+ CYGWIN_V15_WIN32API = YesPlease
endif
NO_THREAD_SAFE_PREAD = YesPlease
NEEDS_LIBICONV = YesPlease
@@ -1906,8 +1906,8 @@ ifdef NO_REGEX
COMPAT_CFLAGS += -Icompat/regex
COMPAT_OBJS += compat/regex/regex.o
endif
-ifdef V15_MINGW_HEADERS
- COMPAT_CFLAGS += -DV15_MINGW_HEADERS
+ifdef CYGWIN_V15_WIN32API
+ COMPAT_CFLAGS += -DCYGWIN_V15_WIN32API
endif
ifdef USE_NED_ALLOCATOR
diff --git a/compat/cygwin.c b/compat/cygwin.c
index 59d86e4..5428858 100644
--- a/compat/cygwin.c
+++ b/compat/cygwin.c
@@ -1,5 +1,5 @@
#define WIN32_LEAN_AND_MEAN
-#ifdef V15_MINGW_HEADERS
+#ifdef CYGWIN_V15_WIN32API
#include "../git-compat-util.h"
#include "win32.h"
#else
--
1.8.0.0.0.14
^ permalink raw reply related
* Re: git-reset man page
From: Krzysztof Mazur @ 2012-11-18 17:48 UTC (permalink / raw)
To: Drew Northup; +Cc: Angelo Borsotti, Junio C Hamano, git, peff
In-Reply-To: <CAM9Z-nkon5ZtPuqxL0HZPr1es9DSpLA+70++hYpTR4D7WTxbUA@mail.gmail.com>
On Sun, Nov 18, 2012 at 11:55:09AM -0500, Drew Northup wrote:
>
> > So we should always use "<path>" for exact path, and "<pathspec>" for
> > pathspecs patterns as defined in gitglossary. I think it's better
> > to avoid "<paths>" and always use "<path>..." or "<pathspec>..."
>
> I suspect that the only reason why the differentiation between
> "<path>" and "<paths>" happened is because there may be some places
> where it was seen that a _list of paths_ was acceptable (which isn't a
> pathspec, as it isn't a search expression) and other places where
<paths> is usually used for a list of <pathspec>, not just a list of <path>.
> _only_ a single path was acceptable. Should that fail to be the case
> then there would be a good argument for changing the affected
> instances of "<paths>" to "<path>" in the documentation. (I know of no
> other good way to pluralize "<path>" myself.)
>
I think it's best to just add "...":
<path> for single exact path,
<path>... for a list of exact paths,
<pathspec> for single pathspec,
<pathspec>... for a list of pathspecs.
Krzysiek
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox