* 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: [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: 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: 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: [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: [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: 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] 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: [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: 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: 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: 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: 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: [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: 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: 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: Reviews on mailing-list
From: Krzysztof Mazur @ 2012-11-11 17:14 UTC (permalink / raw)
To: Thiago Farina
Cc: Felipe Contreras, Deniz Türkoglu, git, Junio C Hamano,
Shawn Pearce
In-Reply-To: <CACnwZYfP4=Fvt8T0GOEzjTOaEyYF_Ao6e_f02eqO_5_DyzM0Zw@mail.gmail.com>
On Sun, Nov 11, 2012 at 11:09:36AM -0200, Thiago Farina wrote:
> On Sun, Nov 11, 2012 at 10:14 AM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
> > Requiring everyone to use a web browser would limit the amount of ways
> > people can review patches.
> I don't see that as a limitation as I think everyone has access to a
> web browser these days, don't have?
Almost everyone, but not everyone likes using web browser.
With emails you can use your favorite interface: favorite MUA and in good
MUA also your favorite editor (program for writing text, not some
editor-like product in web browser). With web-based system you have only
ONE interface (or few), not chosen by you, you cannot change it, web admin
may change it in way you not like.
Krzysiek
^ permalink raw reply
* Re: [PATCH] send-email: add proper default sender
From: Ramkumar Ramachandra @ 2012-11-11 17:12 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, Thomas Rast, Junio C Hamano, Jonathan Nieder
In-Reply-To: <1352653610-2090-1-git-send-email-felipe.contreras@gmail.com>
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.
Ram
^ permalink raw reply
* [PATCH] Add new git-cc-cmd helper to contrib
From: Felipe Contreras @ 2012-11-11 17:10 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras
You can run it like format-patch:
% git cc-cmd master..my-branch
And you'll get relevant people to Cc.
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.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
This cannot be used as cc-cmd option for 'git send-email' but it can as
series-cc-cmd for which I just send some patches.
An example output:
% git cc-cmd --role-stat v1.8.0^^1..v1.8.0^^2
Vietor Liu <vietor@vxwo.org> (author: 12%)
"Shawn O. Pearce" <spearce@spearce.org> (signer: 37%)
Alexandre Erwin Ittner <alexandre@ittner.com.br> (author: 12%)
Peter Krefting <peter@softwolves.pp.se> (author: 12%)
Pat Thoyts <patthoyts@users.sourceforge.net> (signer: 37%, author: 12%)
Christian Stimming <stimming@tuhh.de> (author: 12%)
Heiko Voigt <hvoigt@hvoigt.net> (author: 25%)
Heiko Voigt <heiko.voigt@mahr.de> (signer: 12%)
Bert Wesarg <bert.wesarg@googlemail.com> (author: 12%)
Cheers.
contrib/cc-cmd/git-cc-cmd | 186 ++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 186 insertions(+)
create mode 100755 contrib/cc-cmd/git-cc-cmd
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
+
+require 'optparse'
+
+$since = '3-years-ago'
+$min_percent = 5
+$role_stats = false
+
+begin
+ OptionParser.new do |opts|
+ opts.on('--role-stats') do |v|
+ $role_stats = v
+ end
+ opts.on('--min-percent N', Integer) do |v|
+ $min_percent = v
+ end
+ opts.on('--since DATE') do |v|
+ $since = v
+ end
+ end.parse!
+rescue OptionParser::InvalidOption
+end
+
+revs = []
+File.popen(%w[git rev-parse --revs-only --default=HEAD --symbolic] + ARGV).each do |rev|
+ revs << rev.chomp
+end
+
+case revs.size
+when 0
+ committish = '%s..HEAD' % '@{upstream}'
+when 1
+ committish = '%s..HEAD' % revs[0]
+else
+ committish = revs.join(' ')
+end
+
+$alias_file = "~/.mutt/aliases"
+$aliases = {}
+
+if $alias_file
+ open(File.expand_path($alias_file)).each do |line|
+ if line =~ /^\s*alias\s+(?:-group\s+\S+\s+)*(\S+)\s+(.*)$/
+ key, addresses = $1, $2.split(', ')
+ addresses.each do |address|
+ $aliases[address] = key
+ end
+ end
+ end
+end
+
+class Commit
+
+ attr_reader :id
+ attr_accessor :author, :roles
+
+ def initialize(id)
+ @id = id
+ @roles = []
+ end
+
+ def self.parse(data)
+ id = author = msg = nil
+ roles = {}
+ data.each_line do |line|
+ if not msg
+ case line
+ when /^commit (.+)$/
+ id = $1
+ when /^author ([^<>]+) <(\S+)>$/
+ author = $1, $2
+ roles[author] = 'author'
+ when /^$/
+ msg = true
+ end
+ else
+ if line =~ /^(Signed-off|Reviewed|Acked)-by: ([^<>]+) <(\S+?)>$/
+ person = $2, $3
+ roles[person] = 'signer' if person != author
+ end
+ end
+ end
+ roles = roles.map do |person, role|
+ address = "%s <%s>" % person
+ if $aliases.include?(address)
+ person = nil, $aliases[address]
+ end
+ [person, role]
+ end
+ [id, author, roles]
+ end
+
+end
+
+class Commits
+
+ attr_reader :items
+
+ def initialize(items = {})
+ @items = items
+ import
+ end
+
+ def size
+ @items.size
+ end
+
+ def import
+ return if @items.empty?
+ ids = @items.keys.join(' ')
+ format = [
+ 'commit %H',
+ 'author %an <%ae>',
+ '', '%B' ].join('%n')
+ open("|git show -z -s --format='format:#{format}' #{ids}").each("\0") do |data|
+ next if data == "\0" # bug in git show?
+ id, author, roles = Commit.parse(data)
+ commit = @items[id]
+ commit.author = author
+ commit.roles = roles
+ end
+ end
+
+ def each_person_role
+ commit_roles = @items.values.map { |commit| commit.roles }.flatten(1)
+ commit_roles.group_by { |person, role| person }.each do |person, commit_roles|
+ commit_roles.group_by { |person, role| role }.each do |role, commit_roles|
+ yield person, role, commit_roles.size
+ end
+ end
+ end
+
+ def self.from_blame(committish)
+ main_commits = {}
+ items = {}
+ open("|git rev-list --reverse #{committish}").each do |e|
+ id = e.chomp
+ main_commits[id] = true
+ open("|git --no-pager show -C --oneline #{id}").each do |e|
+ case e
+ when /^---\s+(\S+)/
+ @source = $1 != '/dev/null' ? $1[2..-1] : nil
+ when /^@@\s-(\d+),(\d+)/
+ next unless @source
+ open("|git blame --incremental -C -L #{$1},+#{$2} --since=#{$since} #{id}^ -- #{@source}").each do |e|
+ if e =~ /^(\h{40})/
+ items[$1] = Commit.new($1) if not main_commits.include?($1)
+ end
+ end
+ end
+ end
+ end
+ self.new(items)
+ end
+
+end
+
+commits = Commits.from_blame(committish)
+
+# hash of hashes
+persons = Hash.new { |hash, key| hash[key] = {} }
+
+commits.each_person_role do |person, role, count|
+ persons[person][role] = count
+end
+
+persons.each do |person, roles|
+ roles = roles.map do |role, count|
+ percent = count.to_f * 100 / commits.size
+ next if percent < $min_percent
+ "%s: %u%%" % [role, percent]
+ end.compact
+ next if roles.empty?
+ name, email = person
+
+ # has must quote chars?
+ name = '"%s"' % name if name =~ /[^\w \-]/i
+
+ person = name ? "%s <%s>" % [name, email] : email
+
+ if $role_stats
+ puts "%s (%s)" % [person, roles.join(', ')]
+ else
+ puts person
+ end
+end
--
1.8.0
^ permalink raw reply related
* [PATCH] send-email: add proper default sender
From: Felipe Contreras @ 2012-11-11 17:06 UTC (permalink / raw)
To: git; +Cc: Thomas Rast, Junio C Hamano, Jonathan Nieder, Felipe Contreras
There's no point in asking this over and over if the user already
properly configured his/her name and email.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
I got really tired of 'git send-email' always asking me from which address to send mails... that's already configured.
git-send-email.perl | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/git-send-email.perl b/git-send-email.perl
index aea66a0..65b8328 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -748,6 +748,17 @@ if (!$force) {
}
}
+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;
+ }
+}
+
my $prompting = 0;
if (!defined $sender) {
$sender = $repoauthor || $repocommitter || '';
--
1.8.0
^ permalink raw reply related
* [PATCH 2/2] send-email: add series-cc-cmd option
From: Felipe Contreras @ 2012-11-11 17:04 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Joe Perches, Jonathan Nieder, Pascal Obry,
Felipe Contreras
In-Reply-To: <1352653463-1923-1-git-send-email-felipe.contreras@gmail.com>
cc-cmd is only per-file, and many times receipients get lost without
seing the full patch series.
So, add an option for series-cc-cmd, which receives as an argument
rev-list options, just like format-patch.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
Documentation/git-send-email.txt | 7 +++++++
contrib/completion/git-completion.bash | 2 +-
git-send-email.perl | 9 ++++++++-
3 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 3241170..1161d3e 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -218,6 +218,13 @@ Automating
Output of this command must be single email address per line.
Default is the value of 'sendemail.cccmd' configuration value.
+--series-cc-cmd=<command>::
+ Specify a command to execute to generate "Cc:" entries for the whole
+ patch series.
+ The arguments would be the same rev-list options the user specified.
+ Output of this command must be single email address per line.
+ Default is the value of 'sendemail.seriescccmd' configuration value.
+
--[no-]chain-reply-to::
If this is set, each email will be sent as a reply to the previous
email sent. If disabled with "--no-chain-reply-to", all emails after
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index be800e0..0b04229 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1555,7 +1555,7 @@ _git_send_email ()
return
;;
--*)
- __gitcomp "--annotate --bcc --cc --cc-cmd --chain-reply-to
+ __gitcomp "--annotate --bcc --cc --cc-cmd --series-cc-cmd --chain-reply-to
--compose --confirm= --dry-run --envelope-sender
--from --identity
--in-reply-to --no-chain-reply-to --no-signed-off-by-cc
diff --git a/git-send-email.perl b/git-send-email.perl
index 26d4477..da89ac6 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -191,7 +191,7 @@ sub do_edit {
# Variables with corresponding config settings
my ($thread, $chain_reply_to, $suppress_from, $signed_off_by_cc);
-my ($to_cmd, $cc_cmd);
+my ($to_cmd, $cc_cmd, $series_cc_cmd);
my ($smtp_server, $smtp_server_port, @smtp_server_options);
my ($smtp_authuser, $smtp_encryption);
my ($identity, $aliasfiletype, @alias_files, $smtp_domain);
@@ -224,6 +224,7 @@ my %config_settings = (
"tocmd" => \$to_cmd,
"cc" => \@initial_cc,
"cccmd" => \$cc_cmd,
+ "seriescccmd" => \$series_cc_cmd,
"aliasfiletype" => \$aliasfiletype,
"bcc" => \@bcclist,
"suppresscc" => \@suppress_cc,
@@ -305,6 +306,7 @@ my $rc = GetOptions("h" => \$help,
"compose" => \$compose,
"quiet" => \$quiet,
"cc-cmd=s" => \$cc_cmd,
+ "series-cc-cmd=s" => \$series_cc_cmd,
"suppress-from!" => \$suppress_from,
"suppress-cc=s" => \@suppress_cc,
"signed-off-cc|signed-off-by-cc!" => \$signed_off_by_cc,
@@ -766,6 +768,11 @@ if (!@initial_to && !defined $to_cmd) {
$prompting++;
}
+if (@rev_list_opts) {
+ push @initial_cc, recipients_cmd("series-cc-cmd", "cc", $series_cc_cmd, @rev_list_opts)
+ if defined $series_cc_cmd;
+}
+
sub expand_aliases {
return map { expand_one_alias($_) } @_;
}
--
1.8.0
^ permalink raw reply related
* [PATCH 1/2] send-email: refactor recipients_cmd()
From: Felipe Contreras @ 2012-11-11 17:04 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Joe Perches, Jonathan Nieder, Pascal Obry,
Felipe Contreras
In-Reply-To: <1352653463-1923-1-git-send-email-felipe.contreras@gmail.com>
If we pass the full command to run, we should be able to use it in more
extensible ways--see next patch.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
git-send-email.perl | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index aea66a0..26d4477 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -1373,11 +1373,11 @@ foreach my $t (@files) {
# Execute a command (e.g. $to_cmd) to get a list of email addresses
# and return a results array
sub recipients_cmd {
- my ($prefix, $what, $cmd, $file) = @_;
+ my ($prefix, $what, $cmd, @args) = @_;
my $sanitized_sender = sanitize_address($sender);
my @addresses = ();
- open my $fh, "$cmd \Q$file\E |"
+ open my $fh, "-|", $cmd, @args
or die "($prefix) Could not execute '$cmd'";
while (my $address = <$fh>) {
$address =~ s/^\s*//g;
--
1.8.0
^ permalink raw reply related
* [PATCH 0/2] send-email: new series-cc-cmd option
From: Felipe Contreras @ 2012-11-11 17:04 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Joe Perches, Jonathan Nieder, Pascal Obry,
Felipe Contreras
cc-cmd is probably not that useful, what we really want is to make a list of
people to Cc on a per-patch-series basis.
This patch series allows just that.
Felipe Contreras (2):
send-email: refactor recipients_cmd()
send-email: add series-cc-cmd option
Documentation/git-send-email.txt | 7 +++++++
contrib/completion/git-completion.bash | 2 +-
git-send-email.perl | 13 ++++++++++---
3 files changed, 18 insertions(+), 4 deletions(-)
--
1.8.0
^ permalink raw reply
* [PATCH 2/5] launch_editor: ignore SIGINT while the editor has control
From: Paul Fox @ 2012-11-11 16:55 UTC (permalink / raw)
To: Kalle Olavi Niemitalo; +Cc: Paul Fox, git
In-Reply-To: <20121111163100.GB13188@sigill.intra.peff.net>
The user's editor likely catches SIGINT (ctrl-C). but if
the user spawns a command from the editor and uses ctrl-C to
kill that command, the SIGINT will likely also kill git
itself (depending on the editor, this can leave the terminal
in an unusable state).
Signed-off-by: Paul Fox <pgf@foxharp.boston.ma.us>
Signed-off-by: Jeff King <peff@peff.net>
---
editor.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/editor.c b/editor.c
index 842f782..28aae85 100644
--- a/editor.c
+++ b/editor.c
@@ -1,6 +1,7 @@
#include "cache.h"
#include "strbuf.h"
#include "run-command.h"
+#include "sigchain.h"
#ifndef DEFAULT_EDITOR
#define DEFAULT_EDITOR "vi"
@@ -38,6 +39,7 @@ int launch_editor(const char *path, struct strbuf *buffer, const char *const *en
if (strcmp(editor, ":")) {
const char *args[] = { editor, path, NULL };
struct child_process p;
+ int ret;
memset(&p, 0, sizeof(p));
p.argv = args;
@@ -46,7 +48,10 @@ int launch_editor(const char *path, struct strbuf *buffer, const char *const *en
if (start_command(&p) < 0)
return error("unable to start editor '%s'", editor);
- if (finish_command(&p))
+ sigchain_push(SIGINT, SIG_IGN);
+ ret = finish_command(&p);
+ sigchain_pop(SIGINT);
+ if (ret)
return error("There was a problem with the editor '%s'.",
editor);
}
--
1.8.0.207.gdf2154c
^ permalink raw reply related
* 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:00 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Michael J Gruber, Git Mailing List, Jeff King
In-Reply-To: <CAMP44s1dsEU=E8tdgMYxWFyFw+F03bstdb5o7Ww_-RCQPd3R0w@mail.gmail.com>
On 11/11/2012 07:41 AM, Felipe Contreras wrote:
> On Sat, Nov 10, 2012 at 8:25 PM, A Large Angry SCM<gitzilla@gmail.com> wrote:
>> On 11/10/2012 01:43 PM, Felipe Contreras wrote:
>
>>> So, the options are:
>>>
>>> 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.
>>>
>>> We know there are sources of data that don't have git-formatted author
>>> names, so we know every tool out there must do this checking.
>>>
>>> In addition to that, let the export tool decide what to do when one of
>>> these bad names appear, which in many cases probably means do nothing,
>>> so the user would not even see that such a bad name was there, which
>>> might not be what they want.
>>>
>>> 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.
>>>
>>> The tool writers don't have to worry about this, so we would not have
>>> tools out there doing a half-assed job of this.
>>>
>>> And what happens when such bad names end up being consistent: warning,
>>> a scaffold mapping of bad names, etc.
>>>
>>>
>>> One is bad for the users, and the tools writers, only disadvantages,
>>> the other is good for the users and the tools writers, only
>>> advantages.
>>>
>>
>> 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.
^ 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