* Re: t5801-remote-helpers.sh fails
From: Torsten Bögershausen @ 2012-11-18 15:52 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Torsten Bögershausen, Git Mailing List
In-Reply-To: <CAMP44s22kuXqUjY2Oy2YtBfj1+kF2rHnRKcovV8sPkhu1oR+2A@mail.gmail.com>
On 18.11.12 09:23, Felipe Contreras wrote:
> Hi,
>
> On Sun, Nov 18, 2012 at 6:50 AM, Torsten Bögershausen <tboegi@web.de> wrote:
>
>> I managed to have a working solution for
>> "d) add a check for the bash version to the top of the test in t/"
>> Please see diff below.
>>
>> This unbreaks the test suite here.
>> Is this a good way forward?
>>
>> Filipe, does the code line you mention above work for you?
>>
>> If yes: I can test it here, if you send it as a patch.
>
> It's already sent:
> http://article.gmane.org/gmane.comp.version-control.git/209364
>
Thanks for working on it, and sorry that you need to remind me:
I had the V5 series already on my harddisk, but forgot to test it.
It applied on v.1.8.0 with the following results:
ok 1 - setup repository
ok 2 - cloning from local repo
ok 3 - create new commit on remote
ok 4 - pulling from local repo
ok 5 - pushing to local repo
ok 6 - fetch new branch
ok 7 - fetch multiple branches
ok 8 - push when remote has extra refs
ok 9 - push new branch by name
not ok 10 - push new branch with old:new refspec # TODO known breakage
ok 11 - cloning without refspec
ok 12 - pulling without refspecs
not ok 13 - pushing without refspecs # TODO known breakage
not ok 14 - pulling with straight refspec # TODO known breakage
not ok 15 - pushing with straight refspec # TODO known breakage
not ok 16 - pulling without marks # TODO known breakage
not ok 17 - pushing without marks # TODO known breakage
ok 18 - push ref with existing object
# still have 6 known breakage(s)
/Torsten
^ permalink raw reply
* Motd message on git cloning
From: Adam Stankiewicz @ 2012-11-18 16:04 UTC (permalink / raw)
To: git
I'm dreaming about git feature that shows custom message on git clone.
It would be extremely helpful for informing the person cloning about
init scripts he/she need to execute (for example submodule inits or
hooks set up). For now there is no way to make sure cloning person
will receive such message (unless he/she will read the README).
The server does not need to know if it's fetch or clone, if programmer
executes git clone on client side, then the MOTD message would be
shown.
I think good candidate for MOTD message is .git/description (because
for now no one seems to care about setting repository description).
Another option is to introduce .git/motd file that would consist of
some maximum number of non-control ASCII characters.
I don't really see any security concerns. Git could filter any control
characters from MOTD out, and automation script could add --no-motd
flag. The could also be limit on MOTD file size so no one could
"flood" the terminal window with MOTD messages.
Also it's important to me that such message would be shown
automatically by default and could be turned off, not the other way
(for example --motd flag).
Some other tools like brew package manager have this feature from the
beginning and I find it extremely helpful.
What do you think?
^ permalink raw reply
* Re: Motd message on git cloning
From: Drew Northup @ 2012-11-18 16:34 UTC (permalink / raw)
To: Adam Stankiewicz; +Cc: git
In-Reply-To: <CANCidP-d0tXfo6ZsC80LmaS1CJ475rew2D7ztrx9TkNa94a-uw@mail.gmail.com>
On Sun, Nov 18, 2012 at 11:04 AM, Adam Stankiewicz <sheerun@sher.pl> wrote:
> I'm dreaming about git feature that shows custom message on git clone.
> It would be extremely helpful for informing the person cloning about
> init scripts he/she need to execute (for example submodule inits or
> hooks set up). For now there is no way to make sure cloning person
> will receive such message (unless he/she will read the README).
So we should clog up the output (which may contain important error
messages) just to protect the user from themselves?
> The server does not need to know if it's fetch or clone, if programmer
> executes git clone on client side, then the MOTD message would be
> shown.
>
> I think good candidate for MOTD message is .git/description (because
> for now no one seems to care about setting repository description).
> Another option is to introduce .git/motd file that would consist of
> some maximum number of non-control ASCII characters.
>
> I don't really see any security concerns. Git could filter any control
> characters from MOTD out, and automation script could add --no-motd
> flag. The could also be limit on MOTD file size so no one could
> "flood" the terminal window with MOTD messages.
While I think that it is helpful and sometimes important to set the
description (especially for public repositories) I suspect that if
somebody is cloning it then they already have a good chance of knowing
what _should_ be in that file. This isn't a text-interactive session
on an FTP server of yore.
> Also it's important to me that such message would be shown
> automatically by default and could be turned off, not the other way
> (for example --motd flag).
Ummm....NO. I cannot see this being an improvement for enough users to
justify the extra noise.
Granted, I am not the definitive word on much of anything around here,
but I cannot see this making much sense in the big picture of things.
If you wanted to make this change to something more like Google's
"repo" wrapper script that would make at least some modicum of sense
to me.
--
-Drew Northup
--------------------------------------------------------------
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
^ permalink raw reply
* Re: Auto-repo-repair
From: Drew Northup @ 2012-11-18 16:37 UTC (permalink / raw)
To: Enrico Weigelt; +Cc: Jeff King, git
In-Reply-To: <075f74ff-cafb-4021-ba4d-2474b6fb1853@zcs>
On Sat, Nov 17, 2012 at 4:21 AM, Enrico Weigelt <enrico.weigelt@vnc.biz> wrote:
> Hi,
>
>> You can't reliably just grab the broken objects, because most
>> transports
>> don't support grabbing arbitrary objects (you can do it if you have
>> shell access to a known-good repository, but it's not automated).
>
> can we introduce a new or extend existing transports to support that ?
How would the broken repository be sure of what it is missing to
request it from the other side?
--
-Drew Northup
--------------------------------------------------------------
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
^ permalink raw reply
* Re: Motd message on git cloning
From: Adam Stankiewicz @ 2012-11-18 16:51 UTC (permalink / raw)
To: Drew Northup; +Cc: git
In-Reply-To: <CAM9Z-nkxLqrS5i6Ycz02Amit5itmGJojy=e8+SG9LQYcBHJVxQ@mail.gmail.com>
It we would agree that .git/motd should serve as MOTD file then at the
beginning there would be no noise at all, because currently no
repository contains that file.
I don't think developers would place there non-critical information
about the repository. The community would blame them for that.
Also if one does not like any additional noise, no one prevents him
from adding --no-motd flag as the default.
Thank you for attention.
On Sun, Nov 18, 2012 at 5:34 PM, Drew Northup <n1xim.email@gmail.com> wrote:
> On Sun, Nov 18, 2012 at 11:04 AM, Adam Stankiewicz <sheerun@sher.pl> wrote:
>> I'm dreaming about git feature that shows custom message on git clone.
>> It would be extremely helpful for informing the person cloning about
>> init scripts he/she need to execute (for example submodule inits or
>> hooks set up). For now there is no way to make sure cloning person
>> will receive such message (unless he/she will read the README).
>
> So we should clog up the output (which may contain important error
> messages) just to protect the user from themselves?
>
>> The server does not need to know if it's fetch or clone, if programmer
>> executes git clone on client side, then the MOTD message would be
>> shown.
>>
>> I think good candidate for MOTD message is .git/description (because
>> for now no one seems to care about setting repository description).
>> Another option is to introduce .git/motd file that would consist of
>> some maximum number of non-control ASCII characters.
>>
>> I don't really see any security concerns. Git could filter any control
>> characters from MOTD out, and automation script could add --no-motd
>> flag. The could also be limit on MOTD file size so no one could
>> "flood" the terminal window with MOTD messages.
>
> While I think that it is helpful and sometimes important to set the
> description (especially for public repositories) I suspect that if
> somebody is cloning it then they already have a good chance of knowing
> what _should_ be in that file. This isn't a text-interactive session
> on an FTP server of yore.
>
>> Also it's important to me that such message would be shown
>> automatically by default and could be turned off, not the other way
>> (for example --motd flag).
>
> Ummm....NO. I cannot see this being an improvement for enough users to
> justify the extra noise.
>
> Granted, I am not the definitive word on much of anything around here,
> but I cannot see this making much sense in the big picture of things.
> If you wanted to make this change to something more like Google's
> "repo" wrapper script that would make at least some modicum of sense
> to me.
>
> --
> -Drew Northup
> --------------------------------------------------------------
> "As opposed to vegetable or mineral error?"
> -John Pescatore, SANS NewsBites Vol. 12 Num. 59
^ permalink raw reply
* Re: git-reset man page
From: Drew Northup @ 2012-11-18 16:55 UTC (permalink / raw)
To: Krzysztof Mazur, Angelo Borsotti; +Cc: Junio C Hamano, git, peff
In-Reply-To: <20121110204633.GA29363@shrek.podlesie.net>
On Sat, Nov 10, 2012 at 3:46 PM, Krzysztof Mazur <krzysiek@podlesie.net> wrote:
> On Sat, Nov 10, 2012 at 12:02:12PM -0800, Junio C Hamano wrote:
>> Krzysztof Mazur <krzysiek@podlesie.net> writes:
>>
>> > Maybe we should just add that <paths> is an shortcut for <pathspec>
>> > and fix places where paths and pathspec are mixed or <path> is used as
>> > <pathspec>.
>>
>> We should unify uses of <paths> and <path> (the former should be
>> <path>... or something).
>
> Currently in most cases "<paths>..." is used ;)
> 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
_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.)
--
-Drew Northup
--------------------------------------------------------------
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
^ permalink raw reply
* Re: Auto-repo-repair
From: Enrico Weigelt @ 2012-11-18 16:55 UTC (permalink / raw)
To: Drew Northup; +Cc: Jeff King, git
In-Reply-To: <CAM9Z-nn1S9JvfcymotOvSis4CoYco0Htn4uoETZn2kCto0z9zw@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.
>
> --
> -Drew Northup
> --------------------------------------------------------------
> "As opposed to vegetable or mineral error?"
> -John Pescatore, SANS NewsBites Vol. 12 Num. 59
>
--
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: Local clones aka forks disk size optimization
From: Enrico Weigelt @ 2012-11-18 17:02 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: Michael J Gruber, Andrew Ardill, Javier Domingo, git
In-Reply-To: <CAMK1S_hCk3QdDn8XnXVisL1i2V0iPCZBYN989JmZ3JYr7ckRrA@mail.gmail.com>
Hi,
> That's not the only problem. I believe you only get the savings when
> the main repo gets the commits first. Which is probably ok most of
> the time but it's worth mentioning.
Well, the saving will just be deferred to the point where the commit
finally went to the main repo and downstreams are gc'ed.
> > hmm, distributed GC is a tricky problem.
>
> Except for one little issue (see other thread, subject line "cloning
> a
> namespace downloads all the objects"), namespaces appear to do
> everything we want in terms of the typical use cases for alternates,
> and/or 'git clone -l', at least on the server side.
hmm, not sure about the actual internals, but that namespace filtering
should work in a way that local clone should never see (or consider)
remote refs that are outside of the requested namespace. Perhaps that
should be handled entirely on server side, so all called commands treat
these refs as nonexisting.
By the way: what happens if one tries to clone from an broken repo
(which has several refs pointing to nonexisting objects ?
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: Local clones aka forks disk size optimization
From: Jörg Rosenkranz @ 2012-11-18 17:18 UTC (permalink / raw)
To: Javier Domingo; +Cc: git
In-Reply-To: <CAKs0BQ7RyLZr+ZU=hAC4U7xXpE0+xvORTrvfzFYb6muA2TgM4Q@mail.gmail.com>
2012/11/15 Javier Domingo <javierdo1@gmail.com>
>
> Is there any way to avoid this? I mean, can something be done in git,
> that it checks for (when pulling) the same objects in the other forks?
I've been using git-new-workdir
(https://github.com/git/git/blob/master/contrib/workdir/git-new-workdir)
for a similar problem. Maybe that's what you're searching?
Joerg.
^ permalink raw reply
* 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
* [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
* 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
* 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
* 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: 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
* 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
* 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
* 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
* 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
* 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: 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
* 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: 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: 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: [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
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