* Re: Python extension commands in git - request for policy change
From: Patrick Donnelly @ 2012-12-12 0:28 UTC (permalink / raw)
To: Sitaram Chamarty
Cc: Nguyen Thai Ngoc Duy, Michael Haggerty, Felipe Contreras,
Eric S. Raymond, git
In-Reply-To: <CAMK1S_hy8U0rVY=-u-QCqXjhn-6jwz5ofj_q_mbokVn8CGCMtw@mail.gmail.com>
Hi Sitaram,
On Tue, Dec 11, 2012 at 7:09 PM, Sitaram Chamarty <sitaramc@gmail.com> wrote:
> On Tue, Dec 11, 2012 at 11:14 AM, Patrick Donnelly <batrick@batbytes.com> wrote:
>> Lua has been an incredible success for Nmap [2](and other projects).
>> As an embedded scripting language, it's unrivaled in terms of ease of
>> embedding, ease of use for users, and performance. I would strongly
>> recommend the git developers to seriously consider it.
>
> [snipping the rest; all valid points no doubt]
>
> Does lua have os.putenv() yet? The inability to even *set* an env var
> before calling something else was a killer for me when I last tried
> it.
Lua is pretty strict about being entirely ANSI C and makes very few
exceptions (e.g. dlopen). The exceptions that do exist are only in
base libraries which can easily be thrown out.
> That may make it fine as an embedded language (called *by* something
> else) but it is a bit too "frugal" to use as a glue language (calls
> other things).
As a glue language, this is a feature. The Programming in Lua (written
by the architect of Lua) preface [1] contains the philosophy of Lua on
this issue.
For cases where you do need access to functions like putenv, it's
trivial to either write wrappers for the functions you want to expose
or to incorporate a library that does it all, e.g. luaposix which
contains the majority of POSIX's system calls.
[1] http://www.lua.org/pil/p1.html
--
- Patrick Donnelly
^ permalink raw reply
* Re: Python extension commands in git - request for policy change
From: Tomas Carnecky @ 2012-12-12 0:53 UTC (permalink / raw)
To: Sitaram Chamarty, Patrick Donnelly
Cc: Nguyen Thai Ngoc Duy, Michael Haggerty, Felipe Contreras,
Eric S. Raymond, git
In-Reply-To: <CAMK1S_hy8U0rVY=-u-QCqXjhn-6jwz5ofj_q_mbokVn8CGCMtw@mail.gmail.com>
On Wed, 12 Dec 2012 05:39:43 +0530, Sitaram Chamarty <sitaramc@gmail.com> wrote:
> Does lua have os.putenv() yet? The inability to even *set* an env var
> before calling something else was a killer for me when I last tried
> it.
If it doesn't, it would be trivial to add. It's a one-liner. It's been a while
since I used Lua, but it would be something like this:
void L_putenv(lua_State *L) {
putenv(lua_tostring(L, 1));
}
and then somewhere during setup:
lua_register(L, "putenv", L_putenv);
^ permalink raw reply
* Re: Python extension commands in git - request for policy change
From: Nguyen Thai Ngoc Duy @ 2012-12-12 1:50 UTC (permalink / raw)
To: Tomas Carnecky
Cc: Sitaram Chamarty, Patrick Donnelly, Michael Haggerty,
Felipe Contreras, Eric S. Raymond, git
In-Reply-To: <1355273635-ner-4863@calvin>
On Wed, Dec 12, 2012 at 7:53 AM, Tomas Carnecky
<tomas.carnecky@gmail.com> wrote:
> If it doesn't, it would be trivial to add. It's a one-liner. It's been a while
> since I used Lua, but it would be something like this:
>
> void L_putenv(lua_State *L) {
> putenv(lua_tostring(L, 1));
> }
>
> and then somewhere during setup:
>
> lua_register(L, "putenv", L_putenv);
I should have done my homework before asking, but well.. is there any
way to automate this? If we use lua for writing "builtin" commands,
we'll need to export a lot of C functions and writing wrappers like
this is boring and time consuming. Also, assume I export fn(char*,int)
to Lua, then I change the prototype to fn(char*, char*), can Lua spot
all the call sites at compile time (or something) so I can update
them?
--
Duy
^ permalink raw reply
* Re: Python extension commands in git - request for policy change
From: Patrick Donnelly @ 2012-12-12 2:26 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: Tomas Carnecky, Sitaram Chamarty, Michael Haggerty,
Felipe Contreras, Eric S. Raymond, git
In-Reply-To: <CACsJy8A9h4QJ_iWvQqTtYa4NPH6Q1Gy0NTozbgukC3=ep58mLA@mail.gmail.com>
Hi Duy,
On Tue, Dec 11, 2012 at 8:50 PM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> On Wed, Dec 12, 2012 at 7:53 AM, Tomas Carnecky
> <tomas.carnecky@gmail.com> wrote:
>> If it doesn't, it would be trivial to add. It's a one-liner. It's been a while
>> since I used Lua, but it would be something like this:
>>
>> void L_putenv(lua_State *L) {
>> putenv(lua_tostring(L, 1));
>> }
>>
>> and then somewhere during setup:
>>
>> lua_register(L, "putenv", L_putenv);
>
> I should have done my homework before asking, but well.. is there any
> way to automate this?
If you want these basic POSIX functions, use an existing library.
If you want to automate adding a number of application specific
functions, you can use swig or similar. AFAIK, all languages rely on
third party tools like swig to assist in automated binding generation.
Although, automated binding generation is usually used to make it easy
to export bindings for multiple languages easily. If Lua is going to
be used as a "standard" module glue language, using swig is really
overkill.
> If we use lua for writing "builtin" commands,
> we'll need to export a lot of C functions and writing wrappers like
> this is boring and time consuming. Also, assume I export fn(char*,int)
> to Lua, then I change the prototype to fn(char*, char*), can Lua spot
> all the call sites at compile time (or something) so I can update
> them?
If the API calls are generic (don't require special handling), you can
use some preprocessor magic to save time/space.
--
- Patrick Donnelly
^ permalink raw reply
* Re: Python extension commands in git - request for policy change
From: Eric S. Raymond @ 2012-12-12 3:30 UTC (permalink / raw)
To: Sitaram Chamarty
Cc: Patrick Donnelly, Nguyen Thai Ngoc Duy, Michael Haggerty,
Felipe Contreras, git
In-Reply-To: <CAMK1S_hy8U0rVY=-u-QCqXjhn-6jwz5ofj_q_mbokVn8CGCMtw@mail.gmail.com>
Sitaram Chamarty <sitaramc@gmail.com>:
> [snipping the rest; all valid points no doubt]
I meant to respond to Patrick's post earlier.
I haven't actually written any code in lua yet, but I've read the book;
I think I get it. I've seen the effects of lua integration on another
large project, Battle for Wesnoth.
I'm not, despite conclusions some people here might have jumped to,
religiously attached to Python. So I can say this: I think lua as a
language is an *excellent* design. It is clever, economical,
minimalist, and (other than the one ugly detail of 1-origin indexing)
shows consistent good taste.
It might be a good fit for extending git; I wouldn't be very surprised if
that worked. However, I do have concerns about the "Oh, we'll just
lash together a binding to C" attitude common among lua programmers; I
foresee maintainability problems and the possibility of slow death by
low-level details as that strategy tries to scale up.
And, of course, one problem with calling back into C a lot is that
you walk back into C's resource-management issues.
My sense is that git's use cases are better served by a glue language
in the Python/Perl/Ruby class rather than an extension langage. But
my mind is open on this issue.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* Re: Python extension commands in git - request for policy change
From: Tomas Carnecky @ 2012-12-12 2:22 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: Sitaram Chamarty, Patrick Donnelly, Michael Haggerty,
Felipe Contreras, Eric S. Raymond, git
In-Reply-To: <CACsJy8A9h4QJ_iWvQqTtYa4NPH6Q1Gy0NTozbgukC3=ep58mLA@mail.gmail.com>
On Wed, 12 Dec 2012 08:50:27 +0700, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> On Wed, Dec 12, 2012 at 7:53 AM, Tomas Carnecky
> <tomas.carnecky@gmail.com> wrote:
> > If it doesn't, it would be trivial to add. It's a one-liner. It's been a while
> > since I used Lua, but it would be something like this:
> >
> > void L_putenv(lua_State *L) {
> > putenv(lua_tostring(L, 1));
> > }
> >
> > and then somewhere during setup:
> >
> > lua_register(L, "putenv", L_putenv);
>
> I should have done my homework before asking, but well.. is there any
> way to automate this? If we use lua for writing "builtin" commands,
> we'll need to export a lot of C functions and writing wrappers like
> this is boring and time consuming. Also, assume I export fn(char*,int)
> to Lua, then I change the prototype to fn(char*, char*), can Lua spot
> all the call sites at compile time (or something) so I can update
> them?
A Patrick mentioned in an earlier email, there is luaposix which includes lots
of these functions [1]. There may be tools which generate these bindings
automatically, but I'm not aware of any. Likewise, I'm not aware of any static
analyzer which would be required to spot changes in the prototypes (though you
could cover some(most?) of it through tests). The last time I seriously used
Lua and its C bindings was many years ago, so I am not the best person to
answer these questions.
[1]: http://luaposix.github.com/luaposix/docs/index.html
^ permalink raw reply
* Re: Python extension commands in git - request for policy change
From: Joshua Jensen @ 2012-12-12 5:11 UTC (permalink / raw)
To: esr
Cc: Sitaram Chamarty, Patrick Donnelly, Nguyen Thai Ngoc Duy,
Michael Haggerty, Felipe Contreras, git
In-Reply-To: <20121212033043.GA24937@thyrsus.com>
----- Original Message -----
From: Eric S. Raymond
Date: 12/11/2012 8:30 PM
> It might be a good fit for extending git; I wouldn't be very surprised if
> that worked. However, I do have concerns about the "Oh, we'll just
> lash together a binding to C" attitude common among lua programmers; I
> foresee maintainability problems and the possibility of slow death by
> low-level details as that strategy tries to scale up.
I don't understand this statement: "Oh, we'll just lash together a
binding to C" attitude.
??
> My sense is that git's use cases are better served by a glue language
> in the Python/Perl/Ruby class rather than an extension langage. But
> my mind is open on this issue.
I spend nearly 100% of my Git time on Windows.
Spawning new processes in Windows is dog slow. Using 'git rebase',
arguably my favorite Git command, is time-waiting torture. I'm also on
about as fast of a Windows machine as money can buy these days.
I have a Git add-on similar to git-media that uses the smudge and clean
filters to read/write large binary files into a separate storage
location. When checking out a workspace, Git shells out to run a filter
for each file it needs to write to the workspace.
I can get a maximum of 100 processes per second with this technique,
resulting in just 100 files being written to disk. However, I tend to
see closer to 60 files written to disk.
So, I patched Git to allow the smudge/clean filters to load up a DLL
that executes a Lua script. The Lua script properly retrieves+caches a
file locally, or it puts the file on a network share.
The in-process DLL checkout ends up being every bit as fast as when we
use Perforce to sync files to our local workspace. Git, then, can be a
Perforce replacement for our needs.
(For those who don't know, Perforce handles large workspaces with
massive binary files very efficiently.)
Anyway, my preference is to allow scripts to run in-process within Git,
because it is far, far faster on Windows. I imagine it is faster than
forking processes on non-Windows machines, too, but I have no statistics
to back that up.
Python, Perl, or Ruby can be embedded, too, but Lua probably embeds the
easiest and smallest out of those other 3 languages.
And shell scripts tend to be the slowest on Windows due to the excessive
numbers of process invocations needed to get anything reasonable done.
-Josh
^ permalink raw reply
* Re: Python extension commands in git - request for policy change
From: Joshua Jensen @ 2012-12-12 5:15 UTC (permalink / raw)
To: Patrick Donnelly
Cc: Nguyen Thai Ngoc Duy, Tomas Carnecky, Sitaram Chamarty,
Michael Haggerty, Felipe Contreras, Eric S. Raymond, git
In-Reply-To: <CACh33FqTBOMar=V8=aiE2asZ_ri37fAqeghJLqGecYk=qtvBiQ@mail.gmail.com>
----- Original Message -----
From: Patrick Donnelly
Date: 12/11/2012 7:26 PM
>> If we use lua for writing "builtin" commands,
>> we'll need to export a lot of C functions and writing wrappers like
>> this is boring and time consuming. Also, assume I export fn(char*,int)
>> to Lua, then I change the prototype to fn(char*, char*), can Lua spot
>> all the call sites at compile time (or something) so I can update
>> them?
> If the API calls are generic (don't require special handling), you can
> use some preprocessor magic to save time/space.
Since I mostly use C++, thanks to template metaprogramming, I get to
register functions like so:
void SomeExistingFunction(char* str, int num);
luaState->GetGlobals().RegisterDirect("SomeExistingFunction",
SomeExistingFunction);
I certainly am not suggesting C++ be used within Git, but in this case,
C++ has some nice compile-time advantages.
:)
-Josh
^ permalink raw reply
* Re: [PATCH v7 0/3] submodule update: add --remote for submodule's upstream changes
From: Junio C Hamano @ 2012-12-12 5:42 UTC (permalink / raw)
To: W. Trevor King
Cc: Git, Heiko Voigt, Jeff King, Phil Hord, Shawn Pearce,
Jens Lehmann, Nahor
In-Reply-To: <cover.1355251862.git.wking@tremily.us>
What branch did you base this series on?
The preimage of git-submodule.sh in [2/3] does not seem to match
anything I have (I could wiggle the patch, but in general I would
rather prefer not having to).
^ permalink raw reply
* Re: Python extension commands in git - request for policy change
From: Jeff King @ 2012-12-12 6:32 UTC (permalink / raw)
To: Eric S. Raymond
Cc: Sitaram Chamarty, Patrick Donnelly, Nguyen Thai Ngoc Duy,
Michael Haggerty, Felipe Contreras, git
In-Reply-To: <20121212033043.GA24937@thyrsus.com>
On Tue, Dec 11, 2012 at 10:30:43PM -0500, Eric S. Raymond wrote:
> My sense is that git's use cases are better served by a glue language
> in the Python/Perl/Ruby class rather than an extension langage. But
> my mind is open on this issue.
I think there are really two separate use cases to consider:
1. Providing snippets of script to Git to get Turing-complete behavior
for existing Git features. For example, selecting commits during a
traversal (e.g., a better "log --grep"), formatting output (e.g., a
better "log --format" or "for-each-ref --format").
2. Writing whole new git commands in a language that is quicker or
easier to develop in than C.
I think (1) is a good match for lua. It's light-weight and easy to
embed, we can map the few bits of information we want for each snippet
into the language (e.g., a commit object as a lua table), and the
language ecosystem is not that important (the user is more interested in
writing readable one-liners manipulating data provided by git than they
are in calling out to third-party modules).
But for (2), you are going to care a lot more about the language and its
ecosystem (because you'll be interacting more with the world outside of
git), and about having bindings to lots of different parts of git
(because you'll want to do more interesting things than just examine a
few data structures). We provide that right now with executable
plumbing commands. That's convenient for shell scripts, and you can
build bindings for other languages on top (e.g., see perl/Git.pm).
It's nicely universal, but of course there are some drawbacks: it's slow
(fork and pipe overhead), and it's sometimes awkward (parsing, quoting,
no interactivity between caller and plumbing). The other obvious choice
for a lingua franca is a linkable C library, with bindings in your
language of choice.
It would take a lot of effort to expose git-core's internals in a clean
way; you'd probably be better off starting from scratch and rewriting
large parts in a friendly library-like manner. Fortunately, there is
already a project underway to do so: libgit2. It does not yet have
feature parity with git, but it can do quite a bit. And there are
already ruby and python bindings.
-Peff
^ permalink raw reply
* Re: Python extension commands in git - request for policy change
From: Patrick Donnelly @ 2012-12-12 7:03 UTC (permalink / raw)
To: Jeff King
Cc: Eric S. Raymond, Sitaram Chamarty, Nguyen Thai Ngoc Duy,
Michael Haggerty, Felipe Contreras, git
In-Reply-To: <20121212063208.GA18322@sigill.intra.peff.net>
Hi Jeff,
On Wed, Dec 12, 2012 at 1:32 AM, Jeff King <peff@peff.net> wrote:
> It would take a lot of effort to expose git-core's internals in a clean
> way; you'd probably be better off starting from scratch and rewriting
> large parts in a friendly library-like manner. Fortunately, there is
> already a project underway to do so: libgit2. It does not yet have
> feature parity with git, but it can do quite a bit. And there are
> already ruby and python bindings.
Of course, this comes back to the issue of whether it's a good idea to
use perl/ruby/python as a front-end to regular git commands
(pull/push/etc.). While, yes, bindings can be made for these
languages, you are now making git depend on the presence of one of
these languages in order for git to function. With Lua, the (static)
dependence is very small yet brings much to git in terms of
extensibility and maintainability.
As for Lua's suitability for your (2) point, I admit I'm not familiar
with how much "interacting with the outside world" the git commands
do; however, I would suspect that it is not significant enough to rule
Lua out?
--
- Patrick Donnelly
^ permalink raw reply
* Re: Python extension commands in git - request for policy change
From: Patrick Donnelly @ 2012-12-12 7:11 UTC (permalink / raw)
To: Eric Raymond
Cc: Sitaram Chamarty, Nguyen Thai Ngoc Duy, Michael Haggerty,
Felipe Contreras, git
In-Reply-To: <20121212033043.GA24937@thyrsus.com>
Hi Eric,
On Tue, Dec 11, 2012 at 10:30 PM, Eric S. Raymond <esr@thyrsus.com> wrote:
> It might be a good fit for extending git; I wouldn't be very surprised if
> that worked. However, I do have concerns about the "Oh, we'll just
> lash together a binding to C" attitude common among lua programmers; I
> foresee maintainability problems and the possibility of slow death by
> low-level details as that strategy tries to scale up.
I think this is quite a prediction? Could you give an example
scenario? How would another language (e.g. Python) mitigate this?
> And, of course, one problem with calling back into C a lot is that
> you walk back into C's resource-management issues.
C resource management can be effectively dealt with by relying on
Lua's GC to track C resources via userdata.
> My sense is that git's use cases are better served by a glue language
> in the Python/Perl/Ruby class rather than an extension langage. But
> my mind is open on this issue.
I don't see how these languages are more appropriate based on your concerns.
--
- Patrick Donnelly
^ permalink raw reply
* Re: Python extension commands in git - request for policy change
From: Jeff King @ 2012-12-12 8:32 UTC (permalink / raw)
To: Patrick Donnelly
Cc: Eric S. Raymond, Sitaram Chamarty, Nguyen Thai Ngoc Duy,
Michael Haggerty, Felipe Contreras, git
In-Reply-To: <CACh33FrgZhsKp7o9ki6n1AbfRKYYbdLMWuGUGKUqDfH5m0Akng@mail.gmail.com>
On Wed, Dec 12, 2012 at 02:03:56AM -0500, Patrick Donnelly wrote:
> On Wed, Dec 12, 2012 at 1:32 AM, Jeff King <peff@peff.net> wrote:
> > It would take a lot of effort to expose git-core's internals in a clean
> > way; you'd probably be better off starting from scratch and rewriting
> > large parts in a friendly library-like manner. Fortunately, there is
> > already a project underway to do so: libgit2. It does not yet have
> > feature parity with git, but it can do quite a bit. And there are
> > already ruby and python bindings.
>
> Of course, this comes back to the issue of whether it's a good idea to
> use perl/ruby/python as a front-end to regular git commands
> (pull/push/etc.).
Yeah, I think that is a separate issue, though. I cannot see us ever
writing core commands like "git pull" in any scripting language besides
POSIX shell due to dependency issues. So language bindings are really
for things that are not going to go into git-core, or are ancillary
commands that people can live without (e.g., git-add--interactive,
remote helpers, etc).
> While, yes, bindings can be made for these languages, you are now
> making git depend on the presence of one of these languages in order
> for git to function. With Lua, the (static) dependence is very small
> yet brings much to git in terms of extensibility and maintainability.
And I would include Lua in my list of "I cannot see..." above. It can be
statically linked, so it is not a run-time dependency, but it would
still be a build-time dependency. The community has historically been
pretty resistant to dependencies (I do not care too much myself,
though).
I think doing anything significant in Lua would have the same problem as
doing anything significant in Python: there would need to be substantial
internal cleanup to make sane bindings. And again, that is what libgit2
is doing (and yes, there are Lua bindings for it already).
Using libgit2 bindings would introduce a new dependency, of course, but
that is on par with a Lua dependency.
> As for Lua's suitability for your (2) point, I admit I'm not familiar
> with how much "interacting with the outside world" the git commands
> do; however, I would suspect that it is not significant enough to rule
> Lua out?
I did not mean to rule it out for point (2); I only meant that it is
probably the only reasonable thing for point (1), whereas for point (2),
we have many more options. I suspect Lua would do just fine given the
right set of modules, though I tend to prefer other languages myself
when embeddedness is not an issue.
As for "interacting with the outside world", I was specifically thinking
of stuff like git-send-email (currently in perl) and git-imap-send
(written in C). They need to open network sockets and speak standard
protocols. I suspect Lua would need a module or custom bindings to do
the former at all, and certainly the code would be much simpler if we
re-used standard modules for speaking SMTP and IMAP (which of course
increases our dependencies again...).
-Peff
^ permalink raw reply
* Re: [BUG] Cannot push some grafted branches
From: Yann Dirson @ 2012-12-12 8:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git list
In-Reply-To: <7vd2yg8ngk.fsf@alter.siamese.dyndns.org>
On Tue, 11 Dec 2012 10:15:23 -0800
Junio C Hamano <gitster@pobox.com> wrote:
> Yann Dirson <dirson@bertin.fr> writes:
>
> > There seems to be some bad interactions between git-push and grafts.
> > The problem seems to occur when a commit that exists in the remote
> > repo is subject to a graft in the local repo, and we try to push one
> > of the fake parents.
>
> History tweaking by grafts is only visible inside your local
> repository and objects are not rewritten, and grafts are not
> transferred across repositories. They were invented to be used as a
> stop-gap measure until you filter-branch the history before
> publishing (or if you do not publish, then you can keep using your
> local grafts).
>
> Isn't this well known? Perhaps we would need to document it better.
I am well aware of that, and did not intend to push any grafted commit.
I am attempting to push a well-formed commit, which happens to be used as
a grafted commit's fake parent, and my interpretation is that git reacts
as if it was considering that the remote already had that commit, possibly
because it would not ignore grafts when deciding which commits are already
known to the remote.
> What you can do is to use "replace" instead and publish the replace
> refs, I think. Object transfer will then follow the true parenthood
> connectivity and people who choose to use the same replacement as
> you do can fetch the replace ref from you (this will grab objects
> necessary to complete the alternative history) and install it.
I am only using grafts as a temporary and lightweight drafting area,
before setting the results in stone - although in my case it will be
with filter-branch rather than replace, but the idea is the same. I just
got bitten when attempting to push a valid branch while the grafts were in
effect, when in fact they should have had no influence at all.
In fact, I even looked for a way to specify an alternate (or supplementary)
grafts file for this drafting work, so only well-controlled git invocations
would see them, whereas the others would just ignore them, and could not find
any - nor could I identify an existing way of disabling the use of grafts by
other means than moving it out of the way. In this respect, they seem to be
lacking a few features, when compared to "replace" refs, but they have different
uses, and just using the latter as a drafting area is just not adequate.
I thought about adding support for a GIT_GRAFTS_FILE envvar, which would
default to $GITDIR/info/grafts, or maybe with a more general addition of a
GIT_EXTRA_GRAFT_FILES envvar, but I'm not sure the latter would be that useful.
--
Yann Dirson - Bertin Technologies
^ permalink raw reply
* Re: git-prompt.sh vs leading white space in __git_ps1()::printf_format
From: Simon Oosthoek @ 2012-12-12 8:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Piotr Krukowiecki, git
In-Reply-To: <7vy5h45e7b.fsf@alter.siamese.dyndns.org>
Hi Junio
This removes most of the ambiguities :-)
Ack from me!
I still have some minor nits, but I'll leave that for another time when I'm less busy.
BTW, I haven't tried this yet, but if you pass 2 arguments to __git_ps1 when called from command-substition mode, I suppose it will think it's in PC mode and overwrite the PS1!
At some point, I'd like to see this code split off into "pc" and "cs" functions which call a common function to get the git status. But that's a major rewrite and it may involve more overhead, since each function should process the output of the common function in a different way.
Cheers
Simon
* Junio C Hamano <gitster@pobox.com> [2012-12-11 16:03:36 -0800]:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > Perhaps like this?
>
> OK, this time with a log message.
>
> -- >8 --
> Subject: [PATCH] git-prompt.sh: update PROMPT_COMMAND documentation
>
> The description of __git_ps1 function operating in two-arg mode was
> not very clear. It said "set PROMPT_COMMAND=__git_ps1" which is not
> the right usage for this mode, followed by "To customize the prompt,
> do this", giving a false impression that those who do not want to
> customize it can get away with no-arg form, which was incorrect.
>
> Make it clear that this mode always takes two arguments, pre and
> post, with an example.
>
> The straight-forward one should be listed as the primary usage, and
> the confusing one should be an alternate for advanced users. Swap
> the order of these two.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> contrib/completion/git-prompt.sh | 16 +++++++++++-----
> 1 file changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
> index a8b53ba..9b074e1 100644
> --- a/contrib/completion/git-prompt.sh
> +++ b/contrib/completion/git-prompt.sh
> @@ -10,14 +10,20 @@
> # 1) Copy this file to somewhere (e.g. ~/.git-prompt.sh).
> # 2) Add the following line to your .bashrc/.zshrc:
> # source ~/.git-prompt.sh
> -# 3a) In ~/.bashrc set PROMPT_COMMAND=__git_ps1
> -# To customize the prompt, provide start/end arguments
> -# PROMPT_COMMAND='__git_ps1 "\u@\h:\w" "\\\$ "'
> -# 3b) Alternatively change your PS1 to call __git_ps1 as
> +# 3a) Change your PS1 to call __git_ps1 as
> # command-substitution:
> # Bash: PS1='[\u@\h \W$(__git_ps1 " (%s)")]\$ '
> # ZSH: PS1='[%n@%m %c$(__git_ps1 " (%s)")]\$ '
> -# the optional argument will be used as format string
> +# the optional argument will be used as format string.
> +# 3b) Alternatively, if you are using bash, __git_ps1 can be
> +# used for PROMPT_COMMAND with two parameters, <pre> and
> +# <post>, which are strings you would put in $PS1 before
> +# and after the status string generated by the git-prompt
> +# machinery. e.g.
> +# PROMPT_COMMAND='__git_ps1 "\u@\h:\w" "\\\$ "'
> +# will show username, at-sign, host, colon, cwd, then
> +# various status string, followed by dollar and SP, as
> +# your prompt.
> #
> # The argument to __git_ps1 will be displayed only if you are currently
> # in a git repository. The %s token will be the name of the current
> --
> 1.8.1.rc1.128.gd8d1528
>
^ permalink raw reply
* Re: [BUG] Cannot push some grafted branches
From: Yann Dirson @ 2012-12-12 10:54 UTC (permalink / raw)
To: Yann Dirson; +Cc: Junio C Hamano, git list
In-Reply-To: <20121212094432.6e1e48c8@chalon.bertin.fr>
On Wed, 12 Dec 2012 09:44:32 +0100 Yann Dirson <dirson@bertin.fr> wrote:
> In fact, I even looked for a way to specify an alternate (or supplementary)
> grafts file for this drafting work, so only well-controlled git invocations
> would see them, whereas the others would just ignore them, and could not find
> any - nor could I identify an existing way of disabling the use of grafts by
> other means than moving it out of the way. In this respect, they seem to be
> lacking a few features, when compared to "replace" refs, but they have different
> uses, and just using the latter as a drafting area is just not adequate.
>
> I thought about adding support for a GIT_GRAFTS_FILE envvar, which would
> default to $GITDIR/info/grafts, or maybe with a more general addition of a
> GIT_EXTRA_GRAFT_FILES envvar, but I'm not sure the latter would be that useful.
My bad on this point: there *is* a GIT_GRAFT_FILE envvar, it is just undocumented.
In fact it is not the only one:
git.git$ for v in $(git grep define.*_ENVIRONMENT master -- cache.h | cut -d'"' -f2|grep ^GIT_); do git grep -q $v master -- Documentation || echo "missing $v"; done
missing GIT_GRAFT_FILE
missing GIT_CONFIG_PARAMETERS
--
Yann Dirson - Bertin Technologies
^ permalink raw reply
* [PATCH 0/2] mailmap from blobs
From: Jeff King @ 2012-12-12 10:58 UTC (permalink / raw)
To: git
I noticed recently that the GitHub contributions page for git.git did
not seem very accurate. The problem is that while it uses shortlog, it
does not respect .mailmap, because we do not have a working tree from
which to read the .mailmap.
This series adds a config option analogous to mailmap.file, but which
reads from a blob in the repository (so the obvious thing to set it to
is "HEAD:.mailmap" in a bare repo, and probably "master:.mailmap" if you
frequently want to traverse while on unrelated branches). The obvious
alternative is to checkout a temporary file of .mailmap and point
mailmap.file at it, but this is a bit more convenient.
A config option is perhaps not the most flexible way to access this. For
example, one could in theory want to pull the mailmap from the tip of
the history being traversed (e.g., because you have multiple unrelated
DAGs in a single repo). But that could also produce the _wrong_ results,
if you are looking at the shortlog of older history (e.g., when doing
"git shortlog v1.5.0..v1.5.5", you would still want to be using the
modern mailmap from "master").
By making it a config option, the simple, common case does the right
thing, and people with complex cases can use "git -c mailmap.blob=..."
to feed the appropriate map for the history they are traversing. If
somebody wants to do something fancier (like --mailmap-from-tip or
something), it would be easy to build on top later.
[1/2]: mailmap: refactor mailmap parsing for non-file sources
[2/2]: mailmap: support reading mailmap from blobs
-Peff
^ permalink raw reply
* [PATCH 1/2] mailmap: refactor mailmap parsing for non-file sources
From: Jeff King @ 2012-12-12 10:59 UTC (permalink / raw)
To: git
In-Reply-To: <20121212105822.GA15842@sigill.intra.peff.net>
The read_single_mailmap function opens a mailmap file and
parses each line. In preparation for having non-file
mailmaps, let's pull out the line-parsing logic into its own
function (read_mailmap_line), and rename the file-parsing
function to match (read_mailmap_file).
Signed-off-by: Jeff King <peff@peff.net>
---
Cleanup for the next patch. It's mostly indentation changes, so "diff
-w" is much easier to review.
mailmap.c | 74 ++++++++++++++++++++++++++++++++++-----------------------------
1 file changed, 40 insertions(+), 34 deletions(-)
diff --git a/mailmap.c b/mailmap.c
index ea4b471..89bc318 100644
--- a/mailmap.c
+++ b/mailmap.c
@@ -129,44 +129,50 @@ static int read_single_mailmap(struct string_list *map, const char *filename, ch
return (*right == '\0' ? NULL : right);
}
-static int read_single_mailmap(struct string_list *map, const char *filename, char **repo_abbrev)
+static void read_mailmap_line(struct string_list *map, char *buffer,
+ char **repo_abbrev)
+{
+ char *name1 = NULL, *email1 = NULL, *name2 = NULL, *email2 = NULL;
+ if (buffer[0] == '#') {
+ static const char abbrev[] = "# repo-abbrev:";
+ int abblen = sizeof(abbrev) - 1;
+ int len = strlen(buffer);
+
+ if (!repo_abbrev)
+ return;
+
+ if (len && buffer[len - 1] == '\n')
+ buffer[--len] = 0;
+ if (!strncmp(buffer, abbrev, abblen)) {
+ char *cp;
+
+ if (repo_abbrev)
+ free(*repo_abbrev);
+ *repo_abbrev = xmalloc(len);
+
+ for (cp = buffer + abblen; isspace(*cp); cp++)
+ ; /* nothing */
+ strcpy(*repo_abbrev, cp);
+ }
+ return;
+ }
+ if ((name2 = parse_name_and_email(buffer, &name1, &email1, 0)) != NULL)
+ parse_name_and_email(name2, &name2, &email2, 1);
+
+ if (email1)
+ add_mapping(map, name1, email1, name2, email2);
+}
+
+static int read_mailmap_file(struct string_list *map, const char *filename,
+ char **repo_abbrev)
{
char buffer[1024];
FILE *f = (filename == NULL ? NULL : fopen(filename, "r"));
if (f == NULL)
return 1;
- while (fgets(buffer, sizeof(buffer), f) != NULL) {
- char *name1 = NULL, *email1 = NULL, *name2 = NULL, *email2 = NULL;
- if (buffer[0] == '#') {
- static const char abbrev[] = "# repo-abbrev:";
- int abblen = sizeof(abbrev) - 1;
- int len = strlen(buffer);
-
- if (!repo_abbrev)
- continue;
-
- if (len && buffer[len - 1] == '\n')
- buffer[--len] = 0;
- if (!strncmp(buffer, abbrev, abblen)) {
- char *cp;
-
- if (repo_abbrev)
- free(*repo_abbrev);
- *repo_abbrev = xmalloc(len);
-
- for (cp = buffer + abblen; isspace(*cp); cp++)
- ; /* nothing */
- strcpy(*repo_abbrev, cp);
- }
- continue;
- }
- if ((name2 = parse_name_and_email(buffer, &name1, &email1, 0)) != NULL)
- parse_name_and_email(name2, &name2, &email2, 1);
-
- if (email1)
- add_mapping(map, name1, email1, name2, email2);
- }
+ while (fgets(buffer, sizeof(buffer), f) != NULL)
+ read_mailmap_line(map, buffer, repo_abbrev);
fclose(f);
return 0;
}
@@ -175,8 +181,8 @@ int read_mailmap(struct string_list *map, char **repo_abbrev)
{
map->strdup_strings = 1;
/* each failure returns 1, so >1 means both calls failed */
- return read_single_mailmap(map, ".mailmap", repo_abbrev) +
- read_single_mailmap(map, git_mailmap_file, repo_abbrev) > 1;
+ return read_mailmap_file(map, ".mailmap", repo_abbrev) +
+ read_mailmap_file(map, git_mailmap_file, repo_abbrev) > 1;
}
void clear_mailmap(struct string_list *map)
--
1.8.0.2.4.g59402aa
^ permalink raw reply related
* [PATCH 2/2] mailmap: support reading mailmap from blobs
From: Jeff King @ 2012-12-12 11:04 UTC (permalink / raw)
To: git
In-Reply-To: <20121212105822.GA15842@sigill.intra.peff.net>
In a bare repository, there isn't a simple way to respect an
in-tree mailmap without extracting it to a temporary file.
This patch provides a config variable, similar to
mailmap.file, which reads the mailmap from a blob in the
repository.
Signed-off-by: Jeff King <peff@peff.net>
---
The error-return convention from read_mailmap is really wonky, but I
didn't change it here. It will return "1" for error, and will do so only
if no mailmap sources could be read (including if they simply don't
exist). But it's perfectly OK not to have a mailmap at all. However,
nobody actually seems to check the return code, so nobody has cared.
A more sane convention would probably be:
1. If ENOENT (or no such blob), silently return success.
2. Otherwise, return -1 and print a message to stderr indicating that
there is a mailmap file, but it is broken or otherwise could not be
opened.
Documentation/config.txt | 6 ++++
cache.h | 1 +
config.c | 2 ++
mailmap.c | 49 ++++++++++++++++++++++++++++++--
t/t4203-mailmap.sh | 73 ++++++++++++++++++++++++++++++++++++++++++++++++
5 files changed, 129 insertions(+), 2 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index bf8f911..3760077 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1517,6 +1517,12 @@ mailmap.file::
subdirectory, or somewhere outside of the repository itself.
See linkgit:git-shortlog[1] and linkgit:git-blame[1].
+mailmap.blob::
+ Like `mailmap.file`, but consider the value as a reference to a
+ blob in the repository (e.g., `HEAD:.mailmap`). If both
+ `mailmap.file` and `mailmap.blob` are given, both are parsed,
+ with entries from `mailmap.file` taking precedence.
+
man.viewer::
Specify the programs that may be used to display help in the
'man' format. See linkgit:git-help[1].
diff --git a/cache.h b/cache.h
index 18fdd18..a65f6d1 100644
--- a/cache.h
+++ b/cache.h
@@ -1155,6 +1155,7 @@ extern const char *git_mailmap_file;
extern const char *git_commit_encoding;
extern const char *git_log_output_encoding;
extern const char *git_mailmap_file;
+extern const char *git_mailmap_blob;
/* IO helper functions */
extern void maybe_flush_or_die(FILE *, const char *);
diff --git a/config.c b/config.c
index fb3f868..97364c0 100644
--- a/config.c
+++ b/config.c
@@ -839,6 +839,8 @@ static int git_default_mailmap_config(const char *var, const char *value)
{
if (!strcmp(var, "mailmap.file"))
return git_config_string(&git_mailmap_file, var, value);
+ if (!strcmp(var, "mailmap.blob"))
+ return git_config_string(&git_mailmap_blob, var, value);
/* Add other config variables here and to Documentation/config.txt. */
return 0;
diff --git a/mailmap.c b/mailmap.c
index 89bc318..2f9c691 100644
--- a/mailmap.c
+++ b/mailmap.c
@@ -10,6 +10,7 @@ const char *git_mailmap_file;
#endif
const char *git_mailmap_file;
+const char *git_mailmap_blob;
struct mailmap_info {
char *name;
@@ -177,12 +178,56 @@ int read_mailmap(struct string_list *map, char **repo_abbrev)
return 0;
}
+static void read_mailmap_buf(struct string_list *map,
+ const char *buf, unsigned long len,
+ char **repo_abbrev)
+{
+ while (len) {
+ const char *end = strchrnul(buf, '\n');
+ unsigned long linelen = end - buf + 1;
+ char *line = xmemdupz(buf, linelen);
+
+ read_mailmap_line(map, line, repo_abbrev);
+
+ free(line);
+ buf += linelen;
+ len -= linelen;
+ }
+}
+
+static int read_mailmap_blob(struct string_list *map,
+ const char *name,
+ char **repo_abbrev)
+{
+ unsigned char sha1[20];
+ char *buf;
+ unsigned long size;
+ enum object_type type;
+
+ if (!name)
+ return 1;
+ if (get_sha1(name, sha1) < 0)
+ return 1;
+
+ buf = read_sha1_file(sha1, &type, &size);
+ if (!buf)
+ return 1;
+ if (type != OBJ_BLOB)
+ return 1;
+
+ read_mailmap_buf(map, buf, size, repo_abbrev);
+
+ free(buf);
+ return 0;
+}
+
int read_mailmap(struct string_list *map, char **repo_abbrev)
{
map->strdup_strings = 1;
- /* each failure returns 1, so >1 means both calls failed */
+ /* each failure returns 1, so >2 means all calls failed */
return read_mailmap_file(map, ".mailmap", repo_abbrev) +
- read_mailmap_file(map, git_mailmap_file, repo_abbrev) > 1;
+ read_mailmap_blob(map, git_mailmap_blob, repo_abbrev) +
+ read_mailmap_file(map, git_mailmap_file, repo_abbrev) > 2;
}
void clear_mailmap(struct string_list *map)
diff --git a/t/t4203-mailmap.sh b/t/t4203-mailmap.sh
index 1f182f6..e7ea40c 100755
--- a/t/t4203-mailmap.sh
+++ b/t/t4203-mailmap.sh
@@ -149,6 +149,79 @@ test_expect_success 'No mailmap files, but configured' '
test_cmp expect actual
'
+test_expect_success 'setup mailmap blob tests' '
+ git checkout -b map &&
+ test_when_finished "git checkout master" &&
+ cat >just-bugs <<-\EOF &&
+ Blob Guy <bugs@company.xx>
+ EOF
+ cat >both <<-\EOF &&
+ Blob Guy <author@example.com>
+ Blob Guy <bugs@company.xx>
+ EOF
+ git add just-bugs both &&
+ git commit -m "my mailmaps" &&
+ echo "Repo Guy <author@example.com>" >.mailmap &&
+ echo "Internal Guy <author@example.com>" >internal.map
+'
+
+test_expect_success 'mailmap.blob set' '
+ cat >expect <<-\EOF &&
+ Blob Guy (1):
+ second
+
+ Repo Guy (1):
+ initial
+
+ EOF
+ git -c mailmap.blob=map:just-bugs shortlog HEAD >actual &&
+ test_cmp expect actual
+'
+
+test_expect_success 'mailmap.blob overrides .mailmap' '
+ cat >expect <<-\EOF &&
+ Blob Guy (2):
+ initial
+ second
+
+ EOF
+ git -c mailmap.blob=map:both shortlog HEAD >actual &&
+ test_cmp expect actual
+'
+
+test_expect_success 'mailmap.file overrides mailmap.blob' '
+ cat >expect <<-\EOF &&
+ Blob Guy (1):
+ second
+
+ Internal Guy (1):
+ initial
+
+ EOF
+ git \
+ -c mailmap.blob=map:both \
+ -c mailmap.file=internal.map \
+ shortlog HEAD >actual &&
+ test_cmp expect actual
+'
+
+test_expect_success 'mailmap.blob can be missing' '
+ cat >expect <<-\EOF &&
+ Repo Guy (1):
+ initial
+
+ nick1 (1):
+ second
+
+ EOF
+ git -c mailmap.blob=map:nonexistent shortlog HEAD >actual &&
+ test_cmp expect actual
+'
+
+test_expect_success 'cleanup after mailmap.blob tests' '
+ rm -f .mailmap
+'
+
# Extended mailmap configurations should give us the following output for shortlog
cat >expect <<\EOF
A U Thor <author@example.com> (1):
--
1.8.0.2.4.g59402aa
^ permalink raw reply related
* [PATCH 3/2] mailmap: clean up read_mailmap error handling
From: Jeff King @ 2012-12-12 11:18 UTC (permalink / raw)
To: git
In-Reply-To: <20121212110404.GB19653@sigill.intra.peff.net>
On Wed, Dec 12, 2012 at 06:04:04AM -0500, Jeff King wrote:
> The error-return convention from read_mailmap is really wonky, but I
> didn't change it here. It will return "1" for error, and will do so only
> if no mailmap sources could be read (including if they simply don't
> exist). But it's perfectly OK not to have a mailmap at all. However,
> nobody actually seems to check the return code, so nobody has cared.
>
> A more sane convention would probably be:
>
> 1. If ENOENT (or no such blob), silently return success.
>
> 2. Otherwise, return -1 and print a message to stderr indicating that
> there is a mailmap file, but it is broken or otherwise could not be
> opened.
Maybe like this:
-- >8 --
Subject: [PATCH] mailmap: clean up read_mailmap error handling
The error handling for the read_mailmap function is odd. It
returns 1 on error, rather than -1. And it treats a
non-existent mailmap as an error, even though there is no
reason that one needs to exist. Unless some other mailmap
source loads successfully, in which case the original error
is completely masked.
This does not cause any bugs, however, because no caller
bothers to check the return value, anyway. Let's make this a
little more robust to real errors and less surprising for
future callers that do check the error code:
1. Return -1 on errors.
2. Treat a missing entry (e.g., no mailmap.file given),
ENOENT, or a non-existent blob (for mailmap.blob) as
"no error".
3. Complain loudly when a real error (e.g., a transient
I/O error, no permission to open the mailmap file,
missing or corrupted blob object, etc) occurs.
Signed-off-by: Jeff King <peff@peff.net>
---
mailmap.c | 32 +++++++++++++++++++++-----------
1 file changed, 21 insertions(+), 11 deletions(-)
diff --git a/mailmap.c b/mailmap.c
index 2f9c691..5ffe48a 100644
--- a/mailmap.c
+++ b/mailmap.c
@@ -168,10 +168,19 @@ static int read_mailmap_file(struct string_list *map, const char *filename,
char **repo_abbrev)
{
char buffer[1024];
- FILE *f = (filename == NULL ? NULL : fopen(filename, "r"));
+ FILE *f;
+
+ if (!filename)
+ return 0;
+
+ f = fopen(filename, "r");
+ if (!f) {
+ if (errno == ENOENT)
+ return 0;
+ return error("unable to open mailmap at %s: %s",
+ filename, strerror(errno));
+ }
- if (f == NULL)
- return 1;
while (fgets(buffer, sizeof(buffer), f) != NULL)
read_mailmap_line(map, buffer, repo_abbrev);
fclose(f);
@@ -205,15 +214,15 @@ static int read_mailmap_blob(struct string_list *map,
enum object_type type;
if (!name)
- return 1;
+ return 0;
if (get_sha1(name, sha1) < 0)
- return 1;
+ return 0;
buf = read_sha1_file(sha1, &type, &size);
if (!buf)
- return 1;
+ return error("unable to read mailmap object at %s", name);
if (type != OBJ_BLOB)
- return 1;
+ return error("mailmap is not a blob: %s", name);
read_mailmap_buf(map, buf, size, repo_abbrev);
@@ -223,11 +232,12 @@ int read_mailmap(struct string_list *map, char **repo_abbrev)
int read_mailmap(struct string_list *map, char **repo_abbrev)
{
+ int err = 0;
map->strdup_strings = 1;
- /* each failure returns 1, so >2 means all calls failed */
- return read_mailmap_file(map, ".mailmap", repo_abbrev) +
- read_mailmap_blob(map, git_mailmap_blob, repo_abbrev) +
- read_mailmap_file(map, git_mailmap_file, repo_abbrev) > 2;
+ err |= read_mailmap_file(map, ".mailmap", repo_abbrev);
+ err |= read_mailmap_blob(map, git_mailmap_blob, repo_abbrev);
+ err |= read_mailmap_file(map, git_mailmap_file, repo_abbrev);
+ return err;
}
void clear_mailmap(struct string_list *map)
--
1.8.0.2.4.g59402aa
^ permalink raw reply related
* [PATCH 0/5] git.git .mailmap cleanups
From: Jeff King @ 2012-12-12 11:30 UTC (permalink / raw)
To: git
I noticed a few obvious problems in the output of "git shortlog -nse" on
git.git. So I wrote an analysis script to find more, and of course there
were lots.
This series tries to clean up the low-hanging fruit. The first two
commits fix multiple names matching a single email. Hopefully not too
contentious, but I'll cc all involved parties to confirm. The second has
a different root cause, so I've broken it out into its own commit.
[1/5]: .mailmap: match up some obvious names/emails
[2/5]: .mailmap: fix broken entry for Martin Langhoff
Next up are multiple emails which match a single name. There are over a
hundred of these, and they are much less obvious to fix. They really
need individuals to post patches to fix their own identities (and some
may not want fixing at all, if they used different emails to have
meaningful different identities).
So I've left these untouched except for:
[3/5]: .mailmap: normalize emails for Jeff King
I am allowed to fix my own. :)
[4/5]: .mailmap: normalize emails for Linus Torvalds
As the benevolent dictator, Linus has underlings to fix such things for
him.
Also, his entry was the original reason I started looking at the data.
He fares quite poorly in "shortlog -nse" because his commits are
scattered across many addresses.
[5/5]: contrib: update stats/mailmap script
This replaces the current mailmap script in contrib, which has a bug and
lacks some of the features of my new script.
-Peff
^ permalink raw reply
* [PATCH 1/5] .mailmap: match up some obvious names/emails
From: Jeff King @ 2012-12-12 11:36 UTC (permalink / raw)
To: git
Cc: Cheng Renquan, Dan Johnson, Eric S. Raymond,
Frédéric Heitzmann, Jakub Narębski, Kevin Leung,
Marc-André Lureau, Mark Rada, Robert Zeh, Tay Ray Chuan
In-Reply-To: <20121212113036.GB19625@sigill.intra.peff.net>
This patch updates git's .mailmap in cases where multiple
names are matched to a single email. The "master" name for
each email was chosen by:
1. If the only difference is in the presence or absence
of accented characters, the accented form is chosen
(under the assumption that it is the natural spelling,
and accents are sometimes stripped in email).
2. Otherwise, the most commonly used name is chosen.
3. If all names are equally common, the most recently used name is
chosen.
Signed-off-by: Jeff King <peff@peff.net>
---
I'm cc-ing all involved authors. If you object or want to normalize your
name in some other way, please let me know.
.mailmap | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/.mailmap b/.mailmap
index bcf4f87..69301bd 100644
--- a/.mailmap
+++ b/.mailmap
@@ -9,7 +9,9 @@ Chris Shoemaker <c.shoemaker@cox.net>
Alexander Gavrilov <angavrilov@gmail.com>
Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Brian M. Carlson <sandals@crustytoothpaste.ath.cx>
+Cheng Renquan <crquan@gmail.com>
Chris Shoemaker <c.shoemaker@cox.net>
+Dan Johnson <computerdruid@gmail.com>
Dana L. How <danahow@gmail.com>
Dana L. How <how@deathvalley.cswitch.com>
Daniel Barkalow <barkalow@iabervon.org>
@@ -18,13 +20,16 @@ Horst H. von Brand <vonbrand@inf.utfsm.cl>
David S. Miller <davem@davemloft.net>
Deskin Miller <deskinm@umich.edu>
Dirk Süsserott <newsletter@dirk.my1.cc>
+Eric S. Raymond <esr@thyrsus.com>
Erik Faye-Lund <kusmabite@gmail.com> <kusmabite@googlemail.com>
Fredrik Kuivinen <freku045@student.liu.se>
+Frédéric Heitzmann <frederic.heitzmann@gmail.com>
H. Peter Anvin <hpa@bonde.sc.orionmulti.com>
H. Peter Anvin <hpa@tazenda.sc.orionmulti.com>
H. Peter Anvin <hpa@trantor.hos.anvin.org>
Horst H. von Brand <vonbrand@inf.utfsm.cl>
İsmail Dönmez <ismail@pardus.org.tr>
+Jakub Narębski <jnareb@gmail.com>
Jay Soffian <jaysoffian+git@gmail.com>
Joachim Berdal Haga <cjhaga@fys.uio.no>
Johannes Sixt <j6t@kdbg.org> <johannes.sixt@telecom.at>
@@ -41,11 +46,14 @@ Lukas Sandström <lukass@etek.chalmers.se>
Junio C Hamano <gitster@pobox.com> <junio@kernel.org>
Junio C Hamano <gitster@pobox.com> <junkio@cox.net>
Karl Hasselström <kha@treskal.com>
+Kevin Leung <kevinlsk@gmail.com>
Kent Engstrom <kent@lysator.liu.se>
Lars Doelle <lars.doelle@on-line ! de>
Lars Doelle <lars.doelle@on-line.de>
Li Hong <leehong@pku.edu.cn>
Lukas Sandström <lukass@etek.chalmers.se>
+Marc-André Lureau <marcandre.lureau@gmail.com>
+Mark Rada <marada@uwaterloo.ca>
Martin Langhoff <martin@laptop.org>
Martin von Zweigbergk <martinvonz@gmail.com> <martin.von.zweigbergk@gmail.com>
Michael Coleman <tutufan@gmail.com>
@@ -63,11 +71,13 @@ Steven Grimm <koreth@midwinter.com>
Ramsay Allan Jones <ramsay@ramsay1.demon.co.uk>
René Scharfe <rene.scharfe@lsrfire.ath.cx>
Robert Fitzsimons <robfitz@273k.net>
+Robert Zeh <robert.a.zeh@gmail.com>
Sam Vilain <sam@vilain.net>
Santi Béjar <sbejar@gmail.com>
Sean Estabrooks <seanlkml@sympatico.ca>
Shawn O. Pearce <spearce@spearce.org>
Steven Grimm <koreth@midwinter.com>
+Tay Ray Chuan <rctay89@gmail.com>
Theodore Ts'o <tytso@mit.edu>
Thomas Rast <trast@inf.ethz.ch> <trast@student.ethz.ch>
Tony Luck <tony.luck@intel.com>
--
1.8.0.2.4.g59402aa
^ permalink raw reply related
* [PATCH 2/5] .mailmap: fix broken entry for Martin Langhoff
From: Jeff King @ 2012-12-12 11:38 UTC (permalink / raw)
To: git; +Cc: Martin Langhoff
In-Reply-To: <20121212113036.GB19625@sigill.intra.peff.net>
Commit adc3192 (Martin Langhoff has a new e-mail address,
2010-10-05) added a mailmap entry, but forgot that both the
old and new email addresses need to appear for one to be
mapped to the other (i.e., we do not key mailmap emails by
name).
Signed-off-by: Jeff King <peff@peff.net>
---
.mailmap | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/.mailmap b/.mailmap
index 69301bd..e370e86 100644
--- a/.mailmap
+++ b/.mailmap
@@ -54,7 +54,7 @@ Mark Rada <marada@uwaterloo.ca>
Lukas Sandström <lukass@etek.chalmers.se>
Marc-André Lureau <marcandre.lureau@gmail.com>
Mark Rada <marada@uwaterloo.ca>
-Martin Langhoff <martin@laptop.org>
+Martin Langhoff <martin@laptop.org> <martin@catalyst.net.nz>
Martin von Zweigbergk <martinvonz@gmail.com> <martin.von.zweigbergk@gmail.com>
Michael Coleman <tutufan@gmail.com>
Michael J Gruber <git@drmicha.warpmail.net> <michaeljgruber+gmane@fastmail.fm>
--
1.8.0.2.4.g59402aa
^ permalink raw reply related
* [PATCH 3/5] .mailmap: normalize emails for Jeff King
From: Jeff King @ 2012-12-12 11:38 UTC (permalink / raw)
To: git
In-Reply-To: <20121212113036.GB19625@sigill.intra.peff.net>
I never meant anything special by using my @github.com
address; it is merely a mistake that it has sometimes bled
through to patches.
Signed-off-by: Jeff King <peff@peff.net>
---
.mailmap | 1 +
1 file changed, 1 insertion(+)
diff --git a/.mailmap b/.mailmap
index e370e86..4a27b7f 100644
--- a/.mailmap
+++ b/.mailmap
@@ -31,6 +31,7 @@ Jay Soffian <jaysoffian+git@gmail.com>
İsmail Dönmez <ismail@pardus.org.tr>
Jakub Narębski <jnareb@gmail.com>
Jay Soffian <jaysoffian+git@gmail.com>
+Jeff King <peff@peff.net> <peff@github.com>
Joachim Berdal Haga <cjhaga@fys.uio.no>
Johannes Sixt <j6t@kdbg.org> <johannes.sixt@telecom.at>
Johannes Sixt <j6t@kdbg.org> <j.sixt@viscovery.net>
--
1.8.0.2.4.g59402aa
^ permalink raw reply related
* [PATCH 4/5] .mailmap: normalize emails for Linus Torvalds
From: Jeff King @ 2012-12-12 11:41 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds
In-Reply-To: <20121212113036.GB19625@sigill.intra.peff.net>
Linus used a lot of different per-machine email addresses in
the early days. This means that "git shortlog -nse" does not
aggregate his counts, and he is listed well below where he
should be (8th instead of 3rd).
Signed-off-by: Jeff King <peff@peff.net>
---
Linus,
I recall you considered "email ident from random machine" as a feature
very early on in git's history, but you seem to have settled on using
the linux-foundation address pretty consistently these days. Please let
me know if you object to normalizing your entries in this way.
.mailmap | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/.mailmap b/.mailmap
index 4a27b7f..c7e8618 100644
--- a/.mailmap
+++ b/.mailmap
@@ -52,6 +52,12 @@ Li Hong <leehong@pku.edu.cn>
Lars Doelle <lars.doelle@on-line ! de>
Lars Doelle <lars.doelle@on-line.de>
Li Hong <leehong@pku.edu.cn>
+Linus Torvalds <torvalds@linux-foundation.org> <torvalds@woody.linux-foundation.org>
+Linus Torvalds <torvalds@linux-foundation.org> <torvalds@osdl.org>
+Linus Torvalds <torvalds@linux-foundation.org> <torvalds@g5.osdl.org>
+Linus Torvalds <torvalds@linux-foundation.org> <torvalds@evo.osdl.org>
+Linus Torvalds <torvalds@linux-foundation.org> <torvalds@ppc970.osdl.org>
+Linus Torvalds <torvalds@linux-foundation.org> <torvalds@ppc970.osdl.org.(none)>
Lukas Sandström <lukass@etek.chalmers.se>
Marc-André Lureau <marcandre.lureau@gmail.com>
Mark Rada <marada@uwaterloo.ca>
--
1.8.0.2.4.g59402aa
^ permalink raw reply related
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