On Feb 27, 2015, at 17:01, Stefan Beller wrote:
From: Nguyễn Thái Ngọc Duy
The only difference from the original protocol client capabilities are
negotiated before initial refs advertisment.
Client capabilities are sent out of band (upload-pack receives it as
the second command line argument).
Signed-off-by: Stefan Beller
---
Documentation/technical/http-protocol.txt | 4 ++--
Documentation/technical/protocol-capabilities.txt | 4
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/Documentation/technical/http-protocol.txt
b/Documentation/technical/http-protoco
Heavily inspired by the ideas of Duy, who wrote the first
patches nearly a year ago.
Nguyễn Thái Ngọc Duy (2):
upload-pack: only accept capabilities on the first "want" line
upload-pack: support out of band client capability requests
Stefan Beller (3):
connect.c: connect to a remote service
From: Nguyễn Thái Ngọc Duy
pack-protocol.txt says so and fetch-pack also follows it even though
upload-pack is a bit lax. Fix it.
Signed-off-by: Stefan Beller
---
upload-pack.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/upload-pack.c b/upload-pack.c
index e0ce2bf
Before 73bb33a (daemon: Strictly parse the "extra arg" part of the
command - 2009-06-04) a client sending extra arguments could DoS
git-daemon. 73bb33a fixed it by forbidding extra arguments.
Allow arguments other than "host=" again as a preparation step for
upload-pack2. "host=" if present must b
If this is over git protocol, the flags is appended as the next
parameter after host=. If it's ssh, a new argument is appended to the
command line.
None of the callers use this now though.
[sb: originally by pclouds, rebased as jk implemented 1823bea10,
(git_connect: use argv_array), so any error
From: Nguyễn Thái Ngọc Duy
The only difference from the original protocol client capabilities are
negotiated before initial refs advertisment.
Client capabilities are sent out of band (upload-pack receives it as
the second command line argument). The server sends one pkt-line back
advertising it
On Fri, Feb 27, 2015 at 4:33 PM, Junio C Hamano wrote:
> On Fri, Feb 27, 2015 at 3:44 PM, Stefan Beller wrote:
>> On Fri, Feb 27, 2015 at 3:05 PM, Junio C Hamano wrote:
>>>
>>> I am _not_ proposing that we should go this route, at least not yet.
>>> I am merely pointing out that an in-place side
On Fri, Feb 27, 2015 at 3:44 PM, Stefan Beller wrote:
> On Fri, Feb 27, 2015 at 3:05 PM, Junio C Hamano wrote:
>>
>> I am _not_ proposing that we should go this route, at least not yet.
>> I am merely pointing out that an in-place sidegrade from v1 to a
>> protocol that avoids the megabyte-advert
On Fri, Feb 27, 2015 at 4:07 PM, Duy Nguyen wrote:
>
> There may be another hole, if we send "want ", it looks
> like it will go through without causing errors. It's not exactly no-op
> because an empty tree object will be bundled in result pack. But that
> makes no difference in pratice. I didn't
On Sat, Feb 28, 2015 at 6:05 AM, Junio C Hamano wrote:
> Just for fun, I was trying to see if there is a hole in the current
> protocol that allows a new client to talk a valid v1 protocol
> exchange with existing, deployed servers without breaking, while
> letting it to know a new server that it
On Fri, Feb 27, 2015 at 3:05 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> I do not think v1 can be fixed by "send one ref with capability,
>> newer client may respond immediately so we can stop enumerating
>> remaining refs and older one will get stuck so we can have a timeout
>> to se
Junio C Hamano writes:
> I do not think v1 can be fixed by "send one ref with capability,
> newer client may respond immediately so we can stop enumerating
> remaining refs and older one will get stuck so we can have a timeout
> to see if the connection is from the newer one, and send the rest
>
From: "Kyle J. McKay"
On Feb 26, 2015, at 12:54, Junio C Hamano wrote:
"Kyle J. McKay" writes:
I would like to better understand how the various heads are
maintained. I've read MaintNotes and I've got the concepts, but I'm
still a little fuzzy on some details. It looks to me like all
top
+git@vger.kernel.org
On Thu, Feb 26, 2015 at 5:42 PM, Duy Nguyen wrote:
> https://github.com/pclouds/git/commits/uploadpack2
I rebased your branch, changed the order of commits slightly and
started to add some.
they are found at https://github.com/stefanbeller/git/commits/uploadpack2
I think th
Jeff King writes:
> Like I mentioned before, I'm OK with not checking the actual diff output
> in the test. It's not like it was planned, and is just what diff_tree()
> happens to produce. It does make sense, though
When the topic is on processing broken input, I do not think "It
does make
Nguyễn Thái Ngọc Duy writes:
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> Second round. Looking better. We can do
> "1.0-pre12 < 1.0-rc0 < 1.0 < 1.0-post1" too but it relies on
> config key's loading order, a bit iffy.
>
> Documentation/config.txt | 7 +++
> t/t7004-tag.sh |
Nguyễn Thái Ngọc Duy writes:
> Notice that with "recent" Git versions, ofs-delta objects are
> preferred over ref-delta objects and ref-delta objects have no reason
> to be present in a clone pack.
It is true that we try to use ofs-delta as much as possible, but
where does "have no reason to be
Michael J Gruber writes:
> Junio C Hamano venit, vidit, dixit 26.02.2015 21:59:
>
>> So that does not sound to me a summary of the discussion at all.
>
> Well, your conditional
>
>> I do not recall its conclusion, but it it were "Yes, that is what it
>> means", then it might be reasonable to:
>>
Lasse Kliemann writes:
> As far as I understand, a push will always modify (or add) a ref in the
> remote repository. When pushing to branch B, then the ref pointing to the
> last commit in this branch will be moved, provided that this can be done in
> a fast-forward way. Otherwise the push will
Michael J Gruber writes:
> Without any config being set the result is certainly what I'm after.
>
> What I'm still wondering about is the case without --edit but with
> commit.cleanup: It seems to me that "git commit" being involved in a
> conflict-less cherry-pick is solely an implemention detai
On Fri, Feb 27, 2015 at 8:20 AM, Lasse Kliemann wrote:
> As far as I understand, a push will always modify (or add) a ref in the
> remote repository. When pushing to branch B, then the ref pointing to the
> last commit in this branch will be moved, provided that this can be done in
> a fast-forwar
2015-02-27 17:30 GMT+01:00 Michael J Gruber :
> 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 11fbd0f..aff3109 100644
> --- a/po/de.po
> +++ b/po/de.po
> @@ -4613,7 +4613,7 @@ msgstr "Ungültige
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 11fbd0f..aff3109 100644
--- a/po/de.po
+++ b/po/de.po
@@ -4613,7 +4613,7 @@ msgstr "Ungültiger \"cleanup\" Modus %s"
#: builtin/commit.c:1218
msgid "Paths
As far as I understand, a push will always modify (or add) a ref in the
remote repository. When pushing to branch B, then the ref pointing to the
last commit in this branch will be moved, provided that this can be done in
a fast-forward way. Otherwise the push will fail.
The following options exis
Junio C Hamano venit, vidit, dixit 26.02.2015 20:49:
> Michael J Gruber writes:
>
>> Hmm. With "--edit", current config being in effect should be expected,
>> right? So how about:
>>
>> In case of no conflict: force cleanup=verbatim unless --edit is used?
>
> Perhaps something like that.
>
> St
Junio C Hamano venit, vidit, dixit 26.02.2015 21:59:
> Michael J Gruber writes:
>
>> So, as a summary of the discussion, it seems it's time to switch the
>> default to --textconv for git grep?
>
> Hmmm, why?
>
> Nobody seems to be asking for such a change in this thread. The
> original issue I
The current help string is about --no-exclude-standard. But "git grep -h"
would show --exclude-standard instead. Flip the string. See 0a93fb8
(grep: teach --untracked and --exclude-standard options - 2011-09-27)
for more info about these options.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/g
On Fri, Feb 27, 2015 at 06:27:28PM +0700, Duy Nguyen wrote:
> > 31638 git-remote-https upstream https://git.openstack.org/openstack/nova
> > has pipe:[170381707] (fd 1), waiting for read from pipe:[170384472]
> > 31642 git fetch-pack --stateless-rpc --lock-pack --include-tag --thin
> > --no-p
On Fri, Feb 27, 2015 at 11:16:09AM +0100, Dmitry Neverov wrote:
> I followed your advice and removed a symlink ref from my repository.
> But didn't help.. automatic GC has just removed all packs again. May
> alternates cause such a behavior? Are any ways to make gc log
> somewhere why it removes p
On Fri, Feb 27, 2015 at 6:03 PM, Heald, Mike wrote:
> Hi,
>
> We have a cron job that runs remote update on a number of repositories.
> Sometimes, the processes deadlock and we have to go -TERM them. Here's a
> breakdown of what state the processes end up in when the deadlock happens,
> from on
Hi,
We have a cron job that runs remote update on a number of repositories.
Sometimes, the processes deadlock and we have to go -TERM them. Here's a
breakdown of what state the processes end up in when the deadlock happens, from
one of our production systems yesterday:
31629 git --git-dir=/var
I followed your advice and removed a symlink ref from my repository.
But didn't help.. automatic GC has just removed all packs again. May
alternates cause such a behavior? Are any ways to make gc log
somewhere why it removes packs?
On Thu, Feb 5, 2015 at 9:03 PM, Jeff King wrote:
> On Thu, Feb 05
On Wed, Feb 25, 2015 at 02:11:08PM -0500, Jeff King wrote:
> On Wed, Feb 25, 2015 at 11:01:22AM -0800, Junio C Hamano wrote:
>
> > Jeff King writes:
> >
> > > So I think _if_ using "diff" attributes is enough for this purpose, then
> > > there is no code to be written. But if somebody wants to
On Tue, Jun 17, 2014 at 14:38:56 -0500, Caleb Thompson wrote:
> This patch allows people to set commit.verbose to implicitly send
> --verbose to git-commit.
>
> It introduces several cleanup patches to t/t7505-commit-verbose.sh to
> bring it closer to the current state of the tests as they have be
35 matches
Mail list logo
