* Re: RFD: fast-import is picky with author names (and maybe it should - but how much so?)
From: Jeff King @ 2012-11-11 17:15 UTC (permalink / raw)
To: A Large Angry SCM; +Cc: Felipe Contreras, Michael J Gruber, Git Mailing List
In-Reply-To: <509FD9BC.7050204@gmail.com>
On Sun, Nov 11, 2012 at 12:00:44PM -0500, A Large Angry SCM wrote:
> >>>a) Leave the name conversion to the export tools, and when they miss
> >>>some weird corner case, like 'Author<email', let the user face the
> >>>consequences, perhaps after an hour of the process.
> [...]
> >>>b) Do the name conversion in fast-import itself, perhaps optionally,
> >>>so if a tool missed some weird corner case, the user does not have to
> >>>face the consequences.
> [...]
> >>c) Do the name conversion, and whatever other cleanup and manipulations
> >>you're interesting in, in a filter between the exporter and git-fast-import.
> >
> >Such a filter would probably be quite complicated, and would decrease
> >performance.
> >
>
> Really?
>
> The fast import stream protocol is pretty simple. All the filter
> really needs to do is pass through everything that isn't a 'commit'
> command. And for the 'commit' command, it only needs to do something
> with the 'author' and 'committer' lines; passing through everything
> else.
>
> I agree that an additional filter _may_ decrease performance somewhat
> if you are already CPU constrained. But I suspect that the effect
> would be negligible compared to the all of the SHA-1 calculations.
It might be measurable, as you are passing every byte of every version
of every file in the repo through an extra pipe. But more importantly, I
don't think it helps.
If there is not a standard filter for fixing up names, we do not need to
care. The user can use "sed" or whatever and pay the performance penalty
(and deal with the possibility of errors from being lazy about parsing
the fast-import stream).
If there is a standard filter, then what is the advantage in doing it as
a pipe? Why not just teach fast-import the same trick (and possibly make
it optional)? That would be simpler, more efficient, and it would make
it easier for remote helpers to turn it on (they use a command-line
switch rather than setting up an extra process).
But what I don't understand is: what would such a standard filter look
like? Fast-import (or a filter) would already receive the exporter's
best attempt at a git-like ident string. We can clean up and normalize
things like whitespace (and we probably should if we do not do so
already). But beyond that, we have no context about the name; only the
exporter has that.
So if we receive:
Foo Bar<foo.bar@example.com> <none@none>
or:
Foo Bar<foo.bar@example.com <none@none>
or:
Foo Bar<foo.bar@example.com
what do we do with it? Is the first part a malformed name/email pair,
and the second part is crap added by a lazy exporter? Or does the
exporter want to keep the angle brackets as part of the name field? Is
there a malformed email in the last one, or no email at all?
The exporter is the only program that actually knows where the data came
from, how it should be broken down, and what is appropriate for pulling
data out of its particular source system. For that reason, the exporter
has to be the place where we come up with a syntactically correct and
unambiguous ident.
I am not opposed to adding a mailmap-like feature to fast-import to map
identities, but it has to start with sane, unambiguous output from the
exporter.
-Peff
^ permalink raw reply
* Re: RFD: fast-import is picky with author names (and maybe it should - but how much so?)
From: Felipe Contreras @ 2012-11-11 17:16 UTC (permalink / raw)
To: gitzilla; +Cc: Michael J Gruber, Git Mailing List, Jeff King
In-Reply-To: <509FD9BC.7050204@gmail.com>
On Sun, Nov 11, 2012 at 6:00 PM, A Large Angry SCM <gitzilla@gmail.com> wrote:
> On 11/11/2012 07:41 AM, Felipe Contreras wrote:
>> Such a filter would probably be quite complicated, and would decrease
>> performance.
>
> Really?
>
> The fast import stream protocol is pretty simple. All the filter really
> needs to do is pass through everything that isn't a 'commit' command. And
> for the 'commit' command, it only needs to do something with the 'author'
> and 'committer' lines; passing through everything else.
And how do you propose to find the commit commands without parsing all
the other commands? If you randomly look for lines that begin with
'commit /refs' you might end up in the middle of a commit message or
the contents of a file.
> I agree that an additional filter _may_ decrease performance somewhat if you
> are already CPU constrained. But I suspect that the effect would be
> negligible compared to the all of the SHA-1 calculations.
Well. If it's so easy surely you can write one quickly, and I can measure it.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH] Add new git-cc-cmd helper to contrib
From: Ramkumar Ramachandra @ 2012-11-11 17:18 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <1352653804-2203-1-git-send-email-felipe.contreras@gmail.com>
Hi Felipe,
Felipe Contreras wrote:
> The code finds the changes in each commit in the list, runs 'git blame'
> to see which other commits are relevant to those lines, and then adds
> the author and signer to the list.
>
> Finally, it calculates what percentage of the total relevant commits
> each person was involved in, and if it passes the threshold, it goes in.
This is very cool.
> diff --git a/contrib/cc-cmd/git-cc-cmd b/contrib/cc-cmd/git-cc-cmd
> new file mode 100755
> index 0000000..17b14d4
> --- /dev/null
> +++ b/contrib/cc-cmd/git-cc-cmd
> @@ -0,0 +1,186 @@
> +#!/usr/bin/env ruby
Just out of curiosity, why didn't you write it in Python? (I noticed
that you wrote remote-hg and remote-bzr in Python, and assumed that it
was your preferred language)
> +$alias_file = "~/.mutt/aliases"
Please read sendemail.aliasfiletype instead of assuming mutt.
Ram
^ permalink raw reply
* Re: RFD: fast-import is picky with author names (and maybe it should - but how much so?)
From: A Large Angry SCM @ 2012-11-11 17:39 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Michael J Gruber, Git Mailing List, Jeff King
In-Reply-To: <CAMP44s1pWm_n-SwB5Bi8UxM-oRG=4dGXq7jVKx_E1rcoRaXaHw@mail.gmail.com>
On 11/11/2012 12:16 PM, Felipe Contreras wrote:
> On Sun, Nov 11, 2012 at 6:00 PM, A Large Angry SCM<gitzilla@gmail.com> wrote:
>> On 11/11/2012 07:41 AM, Felipe Contreras wrote:
>
>>> Such a filter would probably be quite complicated, and would decrease
>>> performance.
>>
>> Really?
>>
>> The fast import stream protocol is pretty simple. All the filter really
>> needs to do is pass through everything that isn't a 'commit' command. And
>> for the 'commit' command, it only needs to do something with the 'author'
>> and 'committer' lines; passing through everything else.
>
> And how do you propose to find the commit commands without parsing all
> the other commands? If you randomly look for lines that begin with
> 'commit /refs' you might end up in the middle of a commit message or
> the contents of a file.
I didn't say you didn't have to parse the protocol. I said that the
protocol is pretty simple.
>
>> I agree that an additional filter _may_ decrease performance somewhat if you
>> are already CPU constrained. But I suspect that the effect would be
>> negligible compared to the all of the SHA-1 calculations.
>
> Well. If it's so easy surely you can write one quickly, and I can measure it.
Not my itch; You care, you do it.
^ permalink raw reply
* Re: What's cooking in git.git (Oct 2012, #09; Mon, 29)
From: Jeff King @ 2012-11-11 17:41 UTC (permalink / raw)
To: Ramsay Jones; +Cc: Chris Rorvick, git
In-Reply-To: <509E9E02.3000500@ramsay1.demon.co.uk>
On Sat, Nov 10, 2012 at 06:33:38PM +0000, Ramsay Jones wrote:
> > We should probably wrap it. I'm planning to queue this on top of Chris's
> > patch:
>
> Unfortunately, I haven't had time yet to test this patch. (Early this week, I
> went into hospital for a "minor" surgical procedure - I have not yet fully
> recovered). The patch looks good and I don't anticipate any problems. I will
> hopefully test it soon (I see it's in pu now) and let you know.
Thanks. I merged it to "next" on Friday, so we will see if anybody
screams. But please take your time and recover. Git will wait. :)
-Peff
^ permalink raw reply
* Re: RFD: fast-import is picky with author names (and maybe it should - but how much so?)
From: Felipe Contreras @ 2012-11-11 17:45 UTC (permalink / raw)
To: Jeff King; +Cc: A Large Angry SCM, Michael J Gruber, Git Mailing List
In-Reply-To: <20121111171518.GA20115@sigill.intra.peff.net>
On Sun, Nov 11, 2012 at 6:15 PM, Jeff King <peff@peff.net> wrote:
> On Sun, Nov 11, 2012 at 12:00:44PM -0500, A Large Angry SCM wrote:
> If there is a standard filter, then what is the advantage in doing it as
> a pipe? Why not just teach fast-import the same trick (and possibly make
> it optional)? That would be simpler, more efficient, and it would make
> it easier for remote helpers to turn it on (they use a command-line
> switch rather than setting up an extra process).
Right, but instead of a command-line switch it probably should be
enabled on the stream:
feature clean-authors
Or something.
> But what I don't understand is: what would such a standard filter look
> like? Fast-import (or a filter) would already receive the exporter's
> best attempt at a git-like ident string.
Currently, yeah, because there's no other option. It's either try to
clean it up, or fail.
But if 'git fast-import' as a superior alternative, I certainly would
remove my custom code and enable that feature.
> We can clean up and normalize
> things like whitespace (and we probably should if we do not do so
> already). But beyond that, we have no context about the name; only the
> exporter has that.
There is no context.
> So if we receive:
>
> Foo Bar<foo.bar@example.com> <none@none>
>
> or:
>
> Foo Bar<foo.bar@example.com <none@none>
>
> or:
>
> Foo Bar<foo.bar@example.com
>
> what do we do with it? Is the first part a malformed name/email pair,
> and the second part is crap added by a lazy exporter? Or does the
> exporter want to keep the angle brackets as part of the name field? Is
> there a malformed email in the last one, or no email at all?
These are exactly the same questions every exporter must answer. And
there's no answer, because the field is not a git author, it's a
mercurial user, or a bazaar committer, or who knows what.
>From whatever source, these all might be valid authors:
john
john <john@travolta.com> (grease)
<test@test.com>
test@test.com
test<test@test.com>
test <test@test.com
test # a space
test < test@test.com >
test >test@est.com>
test <test <at> test <dot> com>
<>
>
<
The first chapter of the LOTR
There is no context.
> The exporter is the only program that actually knows where the data came
> from,
It doesn't matter where it came from, it's not a name/email pair.
> how it should be broken down,
It cannot be broken down, it's free-form text. Any text.
> and what is appropriate for pulling
> data out of its particular source system.
This free-form text is the lowest granularity. There is nothing else.
> For that reason, the exporter
> has to be the place where we come up with a syntactically correct and
> unambiguous ident.
*If* the exporter is able to do this, sure, but many don't have any
more information.
See:
% hg commit -u 'Foo Bar<foo.bar@example.com> <none@none>' -m one
% hg --debug log
changeset: 0:5ef37a2c773f02d0e01f1ecdcc59149832d294e8
tag: tip
phase: draft
parent: -1:0000000000000000000000000000000000000000
parent: -1:0000000000000000000000000000000000000000
manifest: 0:c6d4cd25b9fc2f83b0dd51f4acbea9486fce54d7
user: Foo Bar<foo.bar@example.com> <none@none>
date: Sun Nov 11 18:33:00 2012 +0100
files+: file
extra: branch=default
description:
one
What is a hg exporter tool supposed to do with that?
What such a tool can do, 'git fast-import' can do.
> I am not opposed to adding a mailmap-like feature to fast-import to map
> identities, but it has to start with sane, unambiguous output from the
> exporter.
And if that's not possible?
--
Felipe Contreras
^ permalink raw reply
* Re: RFD: fast-import is picky with author names (and maybe it should - but how much so?)
From: Felipe Contreras @ 2012-11-11 17:49 UTC (permalink / raw)
To: gitzilla; +Cc: Michael J Gruber, Git Mailing List, Jeff King
In-Reply-To: <509FE2EA.3020407@gmail.com>
On Sun, Nov 11, 2012 at 6:39 PM, A Large Angry SCM <gitzilla@gmail.com> wrote:
> On 11/11/2012 12:16 PM, Felipe Contreras wrote:
>> And how do you propose to find the commit commands without parsing all
>> the other commands? If you randomly look for lines that begin with
>> 'commit /refs' you might end up in the middle of a commit message or
>> the contents of a file.
>
> I didn't say you didn't have to parse the protocol. I said that the protocol
> is pretty simple.
Parsing is never simple.
>>> I agree that an additional filter _may_ decrease performance somewhat if
>>> you
>>> are already CPU constrained. But I suspect that the effect would be
>>> negligible compared to the all of the SHA-1 calculations.
>>
>> Well. If it's so easy surely you can write one quickly, and I can measure
>> it.
>
> Not my itch; You care, you do it.
It was your idea, I don't care.
If it's so simple, why don't you do it? Because it's not that simple.
And anyway it will have a performance penalty.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH v5 01/15] fast-export: avoid importing blob marks
From: Felipe Contreras @ 2012-11-11 17:53 UTC (permalink / raw)
To: Torsten Bögershausen
Cc: git, Junio C Hamano, Johannes Schindelin, Max Horn, Jeff King,
Sverre Rabbelier, Brandon Casey, Brandon Casey, Jonathan Nieder,
Ilari Liusvaara, Pete Wyckoff, Ben Walton, Matthieu Moy,
Julian Phillips
In-Reply-To: <509FD425.5030702@web.de>
On Sun, Nov 11, 2012 at 5:36 PM, Torsten Bögershausen <tboegi@web.de> wrote:
> On 11.11.12 14:59, Felipe Contreras wrote:
>> test_expect_success 'test biridectionality' '
>> + echo -n > marks-cur &&
>> + echo -n > marks-new &&
> Unless I messed up the patch:
>
> Minor issue: still a typo "biridectionality"
> Major issue: "echo -n" is still not portable.
Yeah.
> Could we simply use
>
> touch marks-cur &&
> touch marks-new
Unless somebody else already modified those marks. Better be safe than sorry.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH] send-email: add proper default sender
From: Felipe Contreras @ 2012-11-11 18:06 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: git, Thomas Rast, Junio C Hamano, Jonathan Nieder
In-Reply-To: <CALkWK0kvScgtqwCLA2BPZxs5qc-ZVyZPiCu6BHrqjne-Yfr8-A@mail.gmail.com>
On Sun, Nov 11, 2012 at 6:12 PM, Ramkumar Ramachandra
<artagnon@gmail.com> wrote:
> Felipe Contreras wrote:
>> I got really tired of 'git send-email' always asking me from which address to send mails... that's already configured.
>
> Use sendemail.from. The email sender doesn't necessarily have to be the author.
And when it's not the author, then sendemail.from would be used.
% git config user.email felipe.contreras@nokia.com
% git send-email master
From: Felipe Contreras <felipe.contreras@nokia.com>
% git config user.email felipe.contreras@gmail.com
% git send-email.perl master
From: Felipe Contreras <felipe.contreras@gmail.com>
% git send-email --from=foo@bar.com master
From: foo@bar.com
% git config sendemail.from test@example.com
% git send-email master
From: test@example.com
What do you loose with this code? Nothing. What do you gain by asking
the user every time: "Who should the emails appear to be from?", when
the default GIT_AUTHOR_IDENT is already fine? Nothing.
The problem with sendemail.from, is that each time the user needs to
change email address, it has to be done in multiple places:
user.email, and sendemail.from. There's no need for that.
But I screwed the patch, it should be:
+if (!defined $sender) {
+ my $name = Git::config('user.name');
+ my $email = Git::config('user.email');
+
+ if (defined $email) {
+ if (defined $name) {
+ $sender = sprintf("%s <%s>", $name, $email);
+ } else {
+ $sender = $email;
+ }
+ }
+}
Cheers.
--
Felipe Contreras
^ permalink raw reply
* RE: Failure using webdav basic auth by git client
From: Jason Pyeron @ 2012-11-11 18:09 UTC (permalink / raw)
To: 'Pyeron, Jason J CTR (US)', git
I had to munge the body so the list would post it.
See: http://vger.kernel.org/majordomo-taboos.txt
> -----Original Message-----
> From: Pyeron, Jason J CTR (US)
> Sent: Thursday, November 08, 2012 2:49 PM
> To: git@vger.kernel.org
> Subject: Failure using webdav basic auth by git client
>
> My google fu has failed me on this issue. I am trying to setup http(s)
> repositories for git. If I require authenticated users then git asks
> for a username and password for the first volley of communications, but
> then does not include the Authorization header on subsequent requests.
>
> Below is the log if I enable username and password BASIC auth in
> Apache.
>
> user@host /tmp/foo/test
> $ git push origin master
> trace: built-in: git 'push' 'origin' 'master'
> trace: run_command: 'git-remote-http' 'origin'
> 'http://server/git/test/'
> * Couldn't find host server in the .netrc file; using defaults
> * About to connect() to server port 80 (#0)
> * Trying server...
> * 0x800766e8 is at send pipe head!
> * STATE: CONNECT => WAITCONNECT handle 0x8007f040; (connection #0)
> * Connected to server (server) port 80 (#0)
> * Connected to server (server) port 80 (#0)
> * STATE: WAITCONNECT => DO handle 0x8007f040; (connection #0)
> > GET /git/test/info/refs?service=git-receive-pack HTTP/1.1
> User-Agent: git/1.7.9
> Host: server
> Accept: */*
> Pragma: no-cache
>
> * STATE: DO => DO_DONE handle 0x8007f040; (connection #0)
> * STATE: DO_DONE => WAITPERFORM handle 0x8007f040; (connection #0)
> * STATE: WAITPERFORM => PERFORM handle 0x8007f040; (connection #0)
> * additional stuff not fine /usr/src/ports/curl/curl-7.27.0-1/src/curl-
> 7.27.0/lib/transfer.c:1037: 0 0
> * The requested URL returned error: 401 Authorization Required
> * Closing connection #0
> Username for 'http://server':
> Password for 'http://test@server':
> * Couldn't find host server in the .netrc file; using defaults
> * About to connect() to server port 80 (#0)
> * Trying server...
> * 0x800766e8 is at send pipe head!
> * STATE: CONNECT => WAITCONNECT handle 0x8007f9c0; (connection #0)
> * Connected to server (server) port 80 (#0)
> * Connected to server (server) port 80 (#0)
> * STATE: WAITCONNECT => DO handle 0x8007f9c0; (connection #0)
> > GET /git/test/info/refs?service=git-receive-pack HTTP/1.1
> User-Agent: git/1.7.9
> Host: server
> Accept: */*
> Pragma: no-cache
>
> * STATE: DO => DO_DONE handle 0x8007f9c0; (connection #0)
> * STATE: DO_DONE => WAITPERFORM handle 0x8007f9c0; (connection #0)
> * STATE: WAITPERFORM => PERFORM handle 0x8007f9c0; (connection #0)
> * additional stuff not fine /usr/src/ports/curl/curl-7.27.0-1/src/curl-
> 7.27.0/lib/transfer.c:1037: 0 0
> * HTTP 1.1 or later with persistent connection, pipelining supported
> < HTTP/1.1 401 Authorization Required
> < Date: Fri, 02 Nov 2012 03:11:53 GMT
> < Server: Apache/2.0.52 (CentOS)
> < WWW-Authenticate: Basic realm="Git"
> < Content-Length: 479
> < Connection: close
> < C-o-n-t-e-n-t---T-y-p-e-:- -t-e-x-t-/-h-t-m-l-;-
-c-h-a-r-s-e-t-=-i-s-o---8-8-5-9---1-
> <
> * Closing connection #0
> * Issue another request to this URL:
> 'http://server/git/test/info/refs?service=git-receive-pack'
> * Couldn't find host server in the .netrc file; using defaults
> * About to connect() to server port 80 (#0)
> * Trying server...
> * 0x800766e8 is at send pipe head!
> * STATE: CONNECT => WAITCONNECT handle 0x8007f9c0; (connection #0)
> * Connected to server (server) port 80 (#0)
> * Connected to server (server) port 80 (#0)
> * STATE: WAITCONNECT => DO handle 0x8007f9c0; (connection #0)
> * Server auth using Basic with user 'test'
> > GET /git/test/info/refs?service=git-receive-pack HTTP/1.1
> Authorization: Basic dGVzdDpwYXNzd29yZA==
> User-Agent: git/1.7.9
> Host: server
> Accept: */*
> Pragma: no-cache
>
> * STATE: DO => DO_DONE handle 0x8007f9c0; (connection #0)
> * STATE: DO_DONE => WAITPERFORM handle 0x8007f9c0; (connection #0)
> * STATE: WAITPERFORM => PERFORM handle 0x8007f9c0; (connection #0)
> * additional stuff not fine /usr/src/ports/curl/curl-7.27.0-1/src/curl-
> 7.27.0/lib/transfer.c:1037: 0 0
> * HTTP 1.1 or later with persistent connection, pipelining supported
> < HTTP/1.1 200 OK
> < Date: Fri, 02 Nov 2012 03:11:53 GMT
> < Server: Apache/2.0.52 (CentOS)
> < Last-Modified: Thu, 01 Nov 2012 01:32:28 GMT
> < ETag: "714064-0-fdf5a300"
> < Accept-Ranges: bytes
> < Content-Length: 0
> < Connection: close
> < Content-Type: text/plain; charset=UTF-8
> <
> * STATE: PERFORM => DONE handle 0x8007f9c0; (connection #0)
> * Closing connection #0
> * Couldn't find host server in the .netrc file; using defaults
> * About to connect() to server port 80 (#0)
> * Trying server...
> * 0x800766e8 is at send pipe head!
> * STATE: CONNECT => WAITCONNECT handle 0x80076678; (connection #0)
> * Connected to server (server) port 80 (#0)
> * Connected to server (server) port 80 (#0)
> * STATE: WAITCONNECT => DO handle 0x80076678; (connection #0)
> * Server auth using Basic with user 'test'
> > GET /git/test/HEAD HTTP/1.1
> Authorization: Basic dGVzdDpwYXNzd29yZA==
> User-Agent: git/1.7.9
> Host: server
> Accept: */*
> Pragma: no-cache
>
> * STATE: DO => DO_DONE handle 0x80076678; (connection #0)
> * STATE: DO_DONE => WAITPERFORM handle 0x80076678; (connection #0)
> * STATE: WAITPERFORM => PERFORM handle 0x80076678; (connection #0)
> * additional stuff not fine /usr/src/ports/curl/curl-7.27.0-1/src/curl-
> 7.27.0/lib/transfer.c:1037: 0 0
> * additional stuff not fine /usr/src/ports/curl/curl-7.27.0-1/src/curl-
> 7.27.0/lib/transfer.c:1037: 0 0
> * HTTP 1.1 or later with persistent connection, pipelining supported
> < HTTP/1.1 200 OK
> < Date: Fri, 02 Nov 2012 03:11:53 GMT
> < Server: Apache/2.0.52 (CentOS)
> < Last-Modified: Thu, 01 Nov 2012 01:23:43 GMT
> < ETag: "704053-17-deaac5c0"
> < Accept-Ranges: bytes
> < Content-Length: 23
> < Connection: close
> < Content-Type: text/plain; charset=UTF-8
> <
> * STATE: PERFORM => DONE handle 0x80076678; (connection #0)
> * Closing connection #0
> trace: run_command: 'http-push' '--helper-status'
> 'http://server/git/test/' 'refs/heads/master:refs/heads/master'
> trace: exec: 'git' 'http-push' '--helper-status'
> 'http://server/git/test/' 'refs/heads/master:refs/heads/master'
> trace: exec: 'git-http-push' '--helper-status'
> 'http://server/git/test/' 'refs/heads/master:refs/heads/master'
> trace: run_command: 'git-http-push' '--helper-status'
> 'http://server/git/test/' 'refs/heads/master:refs/heads/master'
> * Couldn't find host server in the .netrc file; using defaults
> * About to connect() to server port 80 (#0)
> * Trying server...
> * 0x8006f558 is at send pipe head!
> * STATE: CONNECT => WAITCONNECT handle 0x80077e58; (connection #0)
> * Connected to server (server) port 80 (#0)
> * Connected to server (server) port 80 (#0)
> * STATE: WAITCONNECT => DO handle 0x80077e58; (connection #0)
> > PROPFIND /git/test/ HTTP/1.1
> User-Agent: git/1.7.9
> Host: server
> Accept: */*
> Depth: 0
> Content-Type: text/xml
> Content-Length: 159
> Expect: 100-continue
>
> * STATE: DO => DO_DONE handle 0x80077e58; (connection #0)
> * STATE: DO_DONE => WAITPERFORM handle 0x80077e58; (connection #0)
> * STATE: WAITPERFORM => PERFORM handle 0x80077e58; (connection #0)
> * additional stuff not fine /usr/src/ports/curl/curl-7.27.0-1/src/curl-
> 7.27.0/lib/transfer.c:1037: 0 0
> * HTTP 1.1 or later with persistent connection, pipelining supported
> < HTTP/1.1 100 Continue
> * additional stuff not fine /usr/src/ports/curl/curl-7.27.0-1/src/curl-
> 7.27.0/lib/transfer.c:1037: 0 0
> * We are completely uploaded and fine
> * The requested URL returned error: 401 Authorization Required
> * Closing connection #0
> * Expire cleared
> error: Cannot access URL http://server/git/test/, return code 22
> fatal: git-http-push failed
>
>
> Disabling the auth requirement gives in the apache config, I have the
> full trace (quite long) available for the below upon request:
>
> user@host /tmp/foo/test
> $ git push origin master
> To http://server/git/test/
> * [new branch] master -> master
^ permalink raw reply
* Re: [PATCH] Add new git-cc-cmd helper to contrib
From: Felipe Contreras @ 2012-11-11 18:10 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: git
In-Reply-To: <CALkWK0ksDBbWfxbT=PbKiWaC87vghTADPqcy+ujgJ9iZOVZv0w@mail.gmail.com>
Hi,
On Sun, Nov 11, 2012 at 6:18 PM, Ramkumar Ramachandra
<artagnon@gmail.com> wrote:
> Felipe Contreras wrote:
>> The code finds the changes in each commit in the list, runs 'git blame'
>> to see which other commits are relevant to those lines, and then adds
>> the author and signer to the list.
>>
>> Finally, it calculates what percentage of the total relevant commits
>> each person was involved in, and if it passes the threshold, it goes in.
>
> This is very cool.
>
>> diff --git a/contrib/cc-cmd/git-cc-cmd b/contrib/cc-cmd/git-cc-cmd
>> new file mode 100755
>> index 0000000..17b14d4
>> --- /dev/null
>> +++ b/contrib/cc-cmd/git-cc-cmd
>> @@ -0,0 +1,186 @@
>> +#!/usr/bin/env ruby
>
> Just out of curiosity, why didn't you write it in Python? (I noticed
> that you wrote remote-hg and remote-bzr in Python, and assumed that it
> was your preferred language)
No, in fact I hate python :) I only used it because both bazaar and
mercurial are written in python.
Ruby is my favorite language, after C.
I'm fairly certain that the equivalent code in python would be much
more complicated.
>> +$alias_file = "~/.mutt/aliases"
>
> Please read sendemail.aliasfiletype instead of assuming mutt.
Right. Will do.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH 3/5] run-command: drop silent_exec_failure arg from wait_or_whine
From: Felipe Contreras @ 2012-11-11 18:13 UTC (permalink / raw)
To: Jeff King; +Cc: Kalle Olavi Niemitalo, Paul Fox, git
In-Reply-To: <20121111165544.GC19850@sigill.intra.peff.net>
On Sun, Nov 11, 2012 at 5:55 PM, Jeff King <peff@peff.net> wrote:
> We do not actually use this parameter; instead we complain
> from the child itself (for fork/exec) or from start_command
> (if we are using spawn on Windows).
FWIW I noticed the same while looking at that code. Looks good to me.
--
Felipe Contreras
^ permalink raw reply
* Re: RFD: fast-import is picky with author names (and maybe it should - but how much so?)
From: Jeff King @ 2012-11-11 18:14 UTC (permalink / raw)
To: Felipe Contreras; +Cc: A Large Angry SCM, Michael J Gruber, Git Mailing List
In-Reply-To: <CAMP44s1mny-fBCxywM0V=AgEoxV5EZdDWc_0NK3gepcKf32nww@mail.gmail.com>
On Sun, Nov 11, 2012 at 06:45:32PM +0100, Felipe Contreras wrote:
> > If there is a standard filter, then what is the advantage in doing it as
> > a pipe? Why not just teach fast-import the same trick (and possibly make
> > it optional)? That would be simpler, more efficient, and it would make
> > it easier for remote helpers to turn it on (they use a command-line
> > switch rather than setting up an extra process).
>
> Right, but instead of a command-line switch it probably should be
> enabled on the stream:
>
> feature clean-authors
>
> Or something.
Yeah, I was thinking it would need a feature switch to the remote helper
to turn on the command-line, but I forgot that fast-import can take
feature lines directly.
> > We can clean up and normalize
> > things like whitespace (and we probably should if we do not do so
> > already). But beyond that, we have no context about the name; only the
> > exporter has that.
>
> There is no context.
There may not be a lot, but there is some:
> These are exactly the same questions every exporter must answer. And
> there's no answer, because the field is not a git author, it's a
> mercurial user, or a bazaar committer, or who knows what.
The exporter knows that the field is a mercurial user (or whatever).
Fast-import does not even know that, and cannot apply any rules or
heuristics about the format of a mercurial user string, what is common
in the mercurial world, etc. It may not be a lot of context in some
cases (I do not know anything about mercurial's formats, so I can't say
what knowledge is available). But at least the exporter has a chance at
domain-specific interpretation of the string. Fast-import has no chance,
because it does not know the domain.
I've snipped the rest of your argument, which is basically that
mercurial does not have any context at all, and knowing that it is a
mercurial author is useless. I am not sure that is true; even knowing
that it is a free-form field versus something structured (e.g., we know
CVS authors are usernames on the server server) is useful.
But I would agree there are probably multiple systems that are like
mercurial in that the author field is usually something like "name
<email>", but may be arbitrary text (I assume bzr is the same way, but
you would know better than me). So it may make sense to have some stock
algorithm to try to convert arbitrary almost-name-and-email text into
name and email to reduce duplication between exporters, but:
1. It must be turned on explicitly by the exporter, since we do not
want to munge more structured input from clueful exporters.
2. The exporter should only turn it on after replacing its own munging
(e.g., it shouldn't be adding junk like <none@none>; fast-import
would need to receive as pristine an input as possible).
3. Exporters should not use it if they have any broken-down
representation at all. Even knowing that the first half is a human
name and the second half is something else would give it a better
shot at cleaning than fast-import would get.
Alternatively, the feature could enable the exporter to pass a more
structured ident to git.
-Peff
^ permalink raw reply
* Re: RFD: fast-import is picky with author names (and maybe it should - but how much so?)
From: A Large Angry SCM @ 2012-11-11 18:16 UTC (permalink / raw)
To: Jeff King; +Cc: Felipe Contreras, Michael J Gruber, Git Mailing List
In-Reply-To: <20121111171518.GA20115@sigill.intra.peff.net>
On 11/11/2012 12:15 PM, Jeff King wrote:
> On Sun, Nov 11, 2012 at 12:00:44PM -0500, A Large Angry SCM wrote:
>
>>>>> a) Leave the name conversion to the export tools, and when they miss
>>>>> some weird corner case, like 'Author<email', let the user face the
>>>>> consequences, perhaps after an hour of the process.
>> [...]
>>>>> b) Do the name conversion in fast-import itself, perhaps optionally,
>>>>> so if a tool missed some weird corner case, the user does not have to
>>>>> face the consequences.
>> [...]
>>>> c) Do the name conversion, and whatever other cleanup and manipulations
>>>> you're interesting in, in a filter between the exporter and git-fast-import.
>>>
>>> Such a filter would probably be quite complicated, and would decrease
>>> performance.
>>>
>>
>> Really?
>>
>> The fast import stream protocol is pretty simple. All the filter
>> really needs to do is pass through everything that isn't a 'commit'
>> command. And for the 'commit' command, it only needs to do something
>> with the 'author' and 'committer' lines; passing through everything
>> else.
>>
>> I agree that an additional filter _may_ decrease performance somewhat
>> if you are already CPU constrained. But I suspect that the effect
>> would be negligible compared to the all of the SHA-1 calculations.
>
> It might be measurable, as you are passing every byte of every version
> of every file in the repo through an extra pipe. But more importantly, I
> don't think it helps.
>
> If there is not a standard filter for fixing up names, we do not need to
> care. The user can use "sed" or whatever and pay the performance penalty
> (and deal with the possibility of errors from being lazy about parsing
> the fast-import stream).
>
> If there is a standard filter, then what is the advantage in doing it as
> a pipe? Why not just teach fast-import the same trick (and possibly make
> it optional)? That would be simpler, more efficient, and it would make
> it easier for remote helpers to turn it on (they use a command-line
> switch rather than setting up an extra process).
>
> But what I don't understand is: what would such a standard filter look
> like? Fast-import (or a filter) would already receive the exporter's
> best attempt at a git-like ident string. We can clean up and normalize
> things like whitespace (and we probably should if we do not do so
> already). But beyond that, we have no context about the name; only the
> exporter has that.
>
> So if we receive:
>
> Foo Bar<foo.bar@example.com> <none@none>
>
> or:
>
> Foo Bar<foo.bar@example.com<none@none>
>
> or:
>
> Foo Bar<foo.bar@example.com
>
> what do we do with it? Is the first part a malformed name/email pair,
> and the second part is crap added by a lazy exporter? Or does the
> exporter want to keep the angle brackets as part of the name field? Is
> there a malformed email in the last one, or no email at all?
>
> The exporter is the only program that actually knows where the data came
> from, how it should be broken down, and what is appropriate for pulling
> data out of its particular source system. For that reason, the exporter
> has to be the place where we come up with a syntactically correct and
> unambiguous ident.
>
> I am not opposed to adding a mailmap-like feature to fast-import to map
> identities, but it has to start with sane, unambiguous output from the
> exporter.
I don't think that there is or can be a standard filter. Cleaning up
after a broken exporter is likely to always be a repository unique
situation. The example here is about names and email addresses but it
could easily be about other things (dates, history, content, etc.). Some
of which that could possible be fixed using git-filter-branch; some
possibly not.
Fixing the exporter is always the most desirable option, but it may not
be the best option for the particular situation. Locally modifying
git-fast-import is another option; again, possibly not the best option.
Convincing the git maintainers to handle your specific situation, though
a good option for you, is not likely to be scalable. A filter in front
of git-fast-import is always _an_ option and can tailored to the
particular situation.
My preference is to follow the "Unix philosophy": the tools are focused
on what they need to do and can be composed with other tools/scripts to
accomplish the desired result.
d) Another (bad) option is to make git-fast-import very permissive and
warn the user to fix things via git-filter-branch before distributing
the repository or git's standard repository checks find the problems.
This isn't my itch so I think I may have exhausted my $0.02 on this subject.
^ permalink raw reply
* Re: [PATCH 0/5] ignore SIGINT while editor runs
From: Paul Fox @ 2012-11-11 18:27 UTC (permalink / raw)
To: Jeff King; +Cc: Kalle Olavi Niemitalo, git
In-Reply-To: <20121111163100.GB13188@sigill.intra.peff.net>
jeff wrote:
> On Sun, Nov 11, 2012 at 10:48:46AM -0500, Jeff King wrote:
>
> > Silly me. When I thought through the impact of Paul's patch, I knew that
> > we would notice signal death of the editor. But I totally forgot to
> > consider that the blocked signal is inherited by the child process. I
> > think we just need to move the signal() call to after we've forked. Like
> > this (on top of Paul's patch):
> > [...]
> > Note that this will give you a slightly verbose message from git.
> > Potentially we could notice editor death due to SIGINT and suppress the
> > message, under the assumption that the user hit ^C and does not need to
> > be told.
>
> Here's a series that I think should resolve the situation for everybody.
thanks! i've tested -- this certainly scratches my initial itch.
ack,
paul
>
> [1/5]: launch_editor: refactor to use start/finish_command
>
> The cleanup I sent out a few minutes ago.
>
> [2/5]: launch_editor: ignore SIGINT while the editor has control
>
> Paul's patch rebased on my 1/5.
>
> [3/5]: run-command: drop silent_exec_failure arg from wait_or_whine
> [4/5]: run-command: do not warn about child death by SIGINT
> [5/5]: launch_editor: propagate SIGINT from editor to git
>
> Act more like current git when the editor dies from SIGINT.
>
> -Peff
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
=---------------------
paul fox, pgf@foxharp.boston.ma.us (arlington, ma, where it's 56.3 degrees)
^ permalink raw reply
* Re: Failure using webdav basic auth by git client
From: Jeff King @ 2012-11-11 18:28 UTC (permalink / raw)
To: Jason Pyeron; +Cc: 'Pyeron, Jason J CTR (US)', git
In-Reply-To: <121F1C4AA6A845229D3DF5808B4F0F9E@black>
On Sun, Nov 11, 2012 at 01:09:02PM -0500, Jason Pyeron wrote:
> > My google fu has failed me on this issue. I am trying to setup http(s)
> > repositories for git. If I require authenticated users then git asks
> > for a username and password for the first volley of communications, but
> > then does not include the Authorization header on subsequent requests.
> [...]
> > > GET /git/test/info/refs?service=git-receive-pack HTTP/1.1
> > User-Agent: git/1.7.9
Can you try with a more recent git version? There were some bugs with
on-demand http auth when using the dumb protocol (which I see you are
using). They were fixed in v1.7.10.2 and higher.
Also, consider setting up the smart-http protocol, as it is way more
efficient.
-Peff
^ permalink raw reply
* Re: RFD: fast-import is picky with author names (and maybe it should - but how much so?)
From: Felipe Contreras @ 2012-11-11 18:48 UTC (permalink / raw)
To: Jeff King; +Cc: A Large Angry SCM, Michael J Gruber, Git Mailing List
In-Reply-To: <20121111181406.GA21654@sigill.intra.peff.net>
On Sun, Nov 11, 2012 at 7:14 PM, Jeff King <peff@peff.net> wrote:
> On Sun, Nov 11, 2012 at 06:45:32PM +0100, Felipe Contreras wrote:
>
>> > If there is a standard filter, then what is the advantage in doing it as
>> > a pipe? Why not just teach fast-import the same trick (and possibly make
>> > it optional)? That would be simpler, more efficient, and it would make
>> > it easier for remote helpers to turn it on (they use a command-line
>> > switch rather than setting up an extra process).
>>
>> Right, but instead of a command-line switch it probably should be
>> enabled on the stream:
>>
>> feature clean-authors
>>
>> Or something.
>
> Yeah, I was thinking it would need a feature switch to the remote helper
> to turn on the command-line, but I forgot that fast-import can take
> feature lines directly.
>
>> > We can clean up and normalize
>> > things like whitespace (and we probably should if we do not do so
>> > already). But beyond that, we have no context about the name; only the
>> > exporter has that.
>>
>> There is no context.
>
> There may not be a lot, but there is some:
>
>> These are exactly the same questions every exporter must answer. And
>> there's no answer, because the field is not a git author, it's a
>> mercurial user, or a bazaar committer, or who knows what.
>
> The exporter knows that the field is a mercurial user (or whatever).
> Fast-import does not even know that, and cannot apply any rules or
> heuristics about the format of a mercurial user string, what is common
> in the mercurial world, etc. It may not be a lot of context in some
> cases (I do not know anything about mercurial's formats, so I can't say
> what knowledge is available). But at least the exporter has a chance at
> domain-specific interpretation of the string. Fast-import has no chance,
> because it does not know the domain.
>
> I've snipped the rest of your argument, which is basically that
> mercurial does not have any context at all, and knowing that it is a
> mercurial author is useless. I am not sure that is true; even knowing
> that it is a free-form field versus something structured (e.g., we know
> CVS authors are usernames on the server server) is useful.
It is useful in the sense that we know we cannot do anything sensible
about it. All we can do is try.
> But I would agree there are probably multiple systems that are like
> mercurial in that the author field is usually something like "name
> <email>", but may be arbitrary text (I assume bzr is the same way, but
> you would know better than me). So it may make sense to have some stock
> algorithm to try to convert arbitrary almost-name-and-email text into
> name and email to reduce duplication between exporters, but:
Yes, bazaar seems to be the same way.
% bzr log
------------------------------------------------------------
revno: 1
committer: Foo Bar<foo.bar@example.com> <none@none
branch nick: bzr
timestamp: Sun 2012-11-11 19:41:10 +0100
message:
one
> 1. It must be turned on explicitly by the exporter, since we do not
> want to munge more structured input from clueful exporters.
Agreed.
> 2. The exporter should only turn it on after replacing its own munging
> (e.g., it shouldn't be adding junk like <none@none>; fast-import
> would need to receive as pristine an input as possible).
Agreed.
> 3. Exporters should not use it if they have any broken-down
> representation at all. Even knowing that the first half is a human
> name and the second half is something else would give it a better
> shot at cleaning than fast-import would get.
I'm not sure what you mean by this. If they have name and email, then
sure, it's easy.
And for the record, I've have encountered this problem also with
monotone. There's quite a lot of strategies to convert names to git
authors.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH 0/5] ignore SIGINT while editor runs
From: Krzysztof Mazur @ 2012-11-11 19:15 UTC (permalink / raw)
To: Jeff King; +Cc: Kalle Olavi Niemitalo, Paul Fox, git
In-Reply-To: <20121111163100.GB13188@sigill.intra.peff.net>
On Sun, Nov 11, 2012 at 11:31:00AM -0500, Jeff King wrote:
>
> Here's a series that I think should resolve the situation for everybody.
>
> [1/5]: launch_editor: refactor to use start/finish_command
>
> The cleanup I sent out a few minutes ago.
>
> [2/5]: launch_editor: ignore SIGINT while the editor has control
>
> Paul's patch rebased on my 1/5.
>
> [3/5]: run-command: drop silent_exec_failure arg from wait_or_whine
> [4/5]: run-command: do not warn about child death by SIGINT
> [5/5]: launch_editor: propagate SIGINT from editor to git
>
> Act more like current git when the editor dies from SIGINT.
>
Looks ok, but what about SIGQUIT? Some editors like GNU ed (0.4 and 1.6)
ignore SIGQUIT, and after SIGQUIT git dies, but editor is still running.
After pressing any key ed receives -EIO and prints "stdin: Input/output
error". GNU ed 1.6 then exits, but ed 0.4 prints this error forever.
Maybe git should kill the editor in such case?
Krzysiek
^ permalink raw reply
* Re: [PATCH 5/5] launch_editor: propagate SIGINT from editor to git
From: Johannes Sixt @ 2012-11-11 19:48 UTC (permalink / raw)
To: Jeff King; +Cc: Kalle Olavi Niemitalo, Paul Fox, git
In-Reply-To: <20121111165706.GE19850@sigill.intra.peff.net>
Am 11.11.2012 17:57, schrieb Jeff King:
> @@ -51,6 +51,8 @@ int launch_editor(const char *path, struct strbuf *buffer, const char *const *en
> sigchain_push(SIGINT, SIG_IGN);
> ret = finish_command(&p);
> sigchain_pop(SIGINT);
> + if (WIFSIGNALED(ret) && WTERMSIG(ret) == SIGINT)
> + raise(SIGINT);
The return value of finish_command() is already a digested version of
waitpid's status value. According to
Documentation/technical/api-run-command.txt:
. If the program terminated due to a signal, then the return value is
the signal number - 128, ...
the correct condition would be
if (ret == SIGINT - 128)
-- Hannes
^ permalink raw reply
* Re: Test failures in contrib/remote-helpers
From: Felipe Contreras @ 2012-11-11 19:50 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Git List
In-Reply-To: <CALkWK0k9trxx8NC1GWw-yYzBKhFchrvg2JLeBtyoAkokmv9A0w@mail.gmail.com>
On Sun, Nov 11, 2012 at 1:48 PM, Ramkumar Ramachandra
<artagnon@gmail.com> wrote:
> Felipe Contreras wrote:
>> On Sun, Nov 11, 2012 at 11:32 AM, Ramkumar Ramachandra
>> <artagnon@gmail.com> wrote:
>>> I'm experiencing test failures in contrib/remote-helpers.
>>
>> Which are your versions of hg, and bzr?
>
> Mercurial Distributed SCM (version 1.9.1)
I can reproduce the issue, this fixes it for versions up to 1.8:
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
@@ -294,7 +294,7 @@ def export_ref(repo, name, kind, head):
if tip and tip == head.rev():
# nothing to do
return
- revs = repo.revs('%u:%u' % (tip, head))
+ revs = xrange(tip, head.rev() + 1)
count = 0
revs = [rev for rev in revs if not marks.is_marked(rev)]
I don't think it makes sense to aim anything lower.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH 0/5] ignore SIGINT while editor runs
From: Paul Fox @ 2012-11-11 20:24 UTC (permalink / raw)
To: Krzysztof Mazur; +Cc: Jeff King, Kalle Olavi Niemitalo, git
In-Reply-To: <20121111191520.GA9474@shrek.podlesie.net>
krzysztof wrote:
> On Sun, Nov 11, 2012 at 11:31:00AM -0500, Jeff King wrote:
> >
> > Here's a series that I think should resolve the situation for everybody.
> >
> > [1/5]: launch_editor: refactor to use start/finish_command
> >
> > The cleanup I sent out a few minutes ago.
> >
> > [2/5]: launch_editor: ignore SIGINT while the editor has control
> >
> > Paul's patch rebased on my 1/5.
> >
> > [3/5]: run-command: drop silent_exec_failure arg from wait_or_whine
> > [4/5]: run-command: do not warn about child death by SIGINT
> > [5/5]: launch_editor: propagate SIGINT from editor to git
> >
> > Act more like current git when the editor dies from SIGINT.
> >
>
> Looks ok, but what about SIGQUIT? Some editors like GNU ed (0.4 and 1.6)
> ignore SIGQUIT, and after SIGQUIT git dies, but editor is still running.
> After pressing any key ed receives -EIO and prints "stdin: Input/output
> error". GNU ed 1.6 then exits, but ed 0.4 prints this error forever.
> Maybe git should kill the editor in such case?
there's certainly lots of precedent for treating SIGINT and SIGQUIT
the same. but there's also some merit to saying that if the user
knows to send SIGQUIT instead of SIGINT, they may well have a reason.
(after all, if we always treat them the same, there's no point in
having both.)
the em editor (linus' microemacs) behaves as you describe ed 0.4 does,
except without the error message -- it just spins silently getting EIO
from reading stdin. i think em needs to be fixed, and it sounds like
GNU ed already has been. (unless i misunderstand the relationship of
0.4 and 1.6.)
paul
>
> Krzysiek
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
=---------------------
paul fox, pgf@foxharp.boston.ma.us (arlington, ma, where it's 57.2 degrees)
^ permalink raw reply
* Re: [PATCH 0/5] ignore SIGINT while editor runs
From: Krzysztof Mazur @ 2012-11-11 20:43 UTC (permalink / raw)
To: Paul Fox; +Cc: Jeff King, Kalle Olavi Niemitalo, git
In-Reply-To: <20121111202419.7602E2E8B6A@grass.foxharp.boston.ma.us>
On Sun, Nov 11, 2012 at 03:24:19PM -0500, Paul Fox wrote:
> krzysztof wrote:
> > Looks ok, but what about SIGQUIT? Some editors like GNU ed (0.4 and 1.6)
> > ignore SIGQUIT, and after SIGQUIT git dies, but editor is still running.
> > After pressing any key ed receives -EIO and prints "stdin: Input/output
> > error". GNU ed 1.6 then exits, but ed 0.4 prints this error forever.
> > Maybe git should kill the editor in such case?
>
> there's certainly lots of precedent for treating SIGINT and SIGQUIT
> the same. but there's also some merit to saying that if the user
> knows to send SIGQUIT instead of SIGINT, they may well have a reason.
> (after all, if we always treat them the same, there's no point in
> having both.)
That's why I'm proposing in case of SIGQUIT just killing the editor
(SIGTERM is sufficient for ed).
So git will ignore SIGINT, but die on SIGQUIT (and kill editor
that ignores SIGQUIT).
>
> the em editor (linus' microemacs) behaves as you describe ed 0.4 does,
> except without the error message -- it just spins silently getting EIO
> from reading stdin. i think em needs to be fixed, and it sounds like
> GNU ed already has been. (unless i misunderstand the relationship of
> 0.4 and 1.6.)
Yes, the version 1.6 is fixed, it just prints an error once and exits.
Krzysiek
^ permalink raw reply
* Re: [PATCH v5 11/15] remote-testgit: make clear the 'done' feature
From: Max Horn @ 2012-11-11 20:49 UTC (permalink / raw)
To: Felipe Contreras
Cc: git, Junio C Hamano, Johannes Schindelin, Jeff King,
Sverre Rabbelier, Brandon Casey, Brandon Casey, Jonathan Nieder,
Ilari Liusvaara, Pete Wyckoff, Ben Walton, Matthieu Moy,
Julian Phillips
In-Reply-To: <1352642392-28387-12-git-send-email-felipe.contreras@gmail.com>
On 11.11.2012, at 14:59, Felipe Contreras wrote:
> People seeking for reference would find it useful.
Hm, I don't understand this commit message. Probably means I am just too dumb, but since I am one of those people who would likely be seeking for reference, I would really appreciate if it could clarified. Like, for example, I don't see how the patch below makes anything "clear", it just seems to change the "import" command of git-remote-testgit to make use of the 'done' feature?
Perhaps the idea of the patch is to make use of the "done" feature so that remote-testgit acts as "reference implementation"? If that is the intention, then perhaps this could be used as commit message:
remote-testgit: make use of the 'done' feature
This might be helpful for people who would like to see how to properly
implement the "done" feature.
But again, I am not sure if I understood the purpose of this patch correctly. So please forgive me if this was totally off-base :-(.
Cheers,
Max
>
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> ---
> git-remote-testgit | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/git-remote-testgit b/git-remote-testgit
> index 698effc..812321e 100755
> --- a/git-remote-testgit
> +++ b/git-remote-testgit
> @@ -55,8 +55,10 @@ while read line; do
>
> echo "feature import-marks=$gitmarks"
> echo "feature export-marks=$gitmarks"
> - git fast-export --use-done-feature --{import,export}-marks="$testgitmarks" $refs | \
> + echo "feature done"
> + git fast-export --{import,export}-marks="$testgitmarks" $refs | \
> sed -e "s#refs/heads/#${prefix}/heads/#g"
> + echo "done"
> ;;
> export)
> before=$(git for-each-ref --format='%(refname) %(objectname)')
> --
> 1.8.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH v5 02/15] remote-testgit: fix direction of marks
From: Max Horn @ 2012-11-11 20:39 UTC (permalink / raw)
To: Felipe Contreras
Cc: git, Junio C Hamano, Johannes Schindelin, Jeff King,
Sverre Rabbelier, Brandon Casey, Brandon Casey, Jonathan Nieder,
Ilari Liusvaara, Pete Wyckoff, Ben Walton, Matthieu Moy,
Julian Phillips
In-Reply-To: <1352642392-28387-3-git-send-email-felipe.contreras@gmail.com>
On 11.11.2012, at 14:59, Felipe Contreras wrote:
> Basically this is what we want:
>
> == pull ==
>
> testgit transport-helper
>
> * export -> import
>
> # testgit.marks git.marks
>
> == push ==
>
> testgit transport-helper
>
> * import <- export
>
> # testgit.marks git.marks
>
> Each side should be agnostic of the other side. Because testgit.marks
> (our helper marks) could be anything, not necesarily a format parsable
Typo: necesarily => necessarily
Cheers,
Max
^ permalink raw reply
* Re: [PATCH v5 05/15] Add new simplified git-remote-testgit
From: Max Horn @ 2012-11-11 20:40 UTC (permalink / raw)
To: Felipe Contreras
Cc: git, Junio C Hamano, Johannes Schindelin, Jeff King,
Sverre Rabbelier, Brandon Casey, Brandon Casey, Jonathan Nieder,
Ilari Liusvaara, Pete Wyckoff, Ben Walton, Matthieu Moy,
Julian Phillips
In-Reply-To: <1352642392-28387-6-git-send-email-felipe.contreras@gmail.com>
On 11.11.2012, at 14:59, Felipe Contreras wrote:
> It's way simpler. It exerceises the same features of remote helpers.
Typo: exerceises => exercises
Cheers,
Max
^ 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