* Re: [StGit PATCH] Remove --undo flags from stg commands and docs
From: Catalin Marinas @ 2008-07-12 9:58 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20080708042131.GB2247@diana.vm.bytemark.co.uk>
2008/7/8 Karl Hasselström <kha@treskal.com>:
> On 2008-07-07 21:54:01 +0100, Catalin Marinas wrote:
>
>> 2008/7/4 Karl Hasselström <kha@treskal.com>:
>>
>> > In this one, I've just removed the --undo flag from sync without
>> > adding anything back. Still undetermined if that's OK.
>>
>> I think it should be ok (see the other thread). Anyway, have you
>> heard of anyone else using sync apart from me?
>
> No, I haven't.
>
> I've tried to understand what it does, and as far as I can tell it
> doesn't do quite what I want. (What I want is the ability to 3-way
> merge StGit patch stacks, so that I can modify the same patch stack in
> several places and merge back and forth. From what I recall, the sync
> command is more like a 2-way merge -- that is, it doesn't take the
> last common ancestor into account. But it's been a while since I
> studied it.)
No, the sync command is a 3-way merge between the top of a remote
patch, the top of the current patch (current HEAD actually) and the
bottom of the remote patch as ancestor. It also has a mode to
synchronise with a patch file and it applies the patch onto the bottom
of the current patch and does the merging between patch tops
afterwards.
This is not ideal as I have to deal with safe conflicts several time
(maybe adding git-rerere support would help). If you have better ideas
for keeping two stacks in sync, I'm happy to accept them (or maybe
just a different workflow).
--
Catalin
^ permalink raw reply
* Re: [PATCH] git-mailinfo: Fix getting the subject from the body
From: Junio C Hamano @ 2008-07-12 9:36 UTC (permalink / raw)
To: Lukas Sandström; +Cc: Git Mailing List, Don Zickus
In-Reply-To: <4876820D.4070806@etek.chalmers.se>
Lukas Sandström <lukass@etek.chalmers.se> writes:
> "Subject: " isn't in the static array "header", and thus
> memcmp("Subject: ", header[i], 7) will never match.
>
> Signed-off-by: Lukas Sandström <lukass@etek.chalmers.se>
> ---
>
> This has been broken since 2007-03-12, with commit
> 87ab799234639c26ea10de74782fa511cb3ca606
> so it might not be very important.
>
> builtin-mailinfo.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
> index 962aa34..2d1520f 100644
> --- a/builtin-mailinfo.c
> +++ b/builtin-mailinfo.c
> @@ -334,7 +334,7 @@ static int check_header(char *line, unsigned linesize, char **hdr_data, int over
> return 1;
> if (!memcmp("[PATCH]", line, 7) && isspace(line[7])) {
> for (i = 0; header[i]; i++) {
> - if (!memcmp("Subject: ", header[i], 9)) {
> + if (!memcmp("Subject", header[i], 7)) {
> if (! handle_header(line, hdr_data[i], 0)) {
> return 1;
> }
Actually, I do not think your patch alone makes any difference, and the
original code looks somewhat bogus. If there is no "Subject: " in the
same section of the message (either in e-mail header in which case
hdr_data == p_hdr_data[], or in the message body part in which case
hdr_data == s_hdr_data[]), hdr_data[1] will be NULL, because the only
place that allocates the storage for the data is the first loop of this
function that deals with real-RFC2822-header-looking lines.
You'd probably need something like this on top of your patch to actually
activate the code.
Another thing I noticed and found puzzling is the handling of ">From "
line that is shown in the context below. check_header() is supposed to
return true when it handled header (i.e. not part of the commit message)
and return false when line is not part of the header. As ">From " is part
of the commit log message, shouldn't it return zero?
Don, this part was what you introduced. Has this codepath ever been
exercised in the real life?
builtin-mailinfo.c | 2 ++
t/t5100-mailinfo.sh | 2 +-
t/t5100/sample.mbox | 35 +++++++++++++++++++++++++++++++++++
3 files changed, 38 insertions(+), 1 deletions(-)
diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
index 2d1520f..13f0502 100644
--- a/builtin-mailinfo.c
+++ b/builtin-mailinfo.c
@@ -332,12 +332,14 @@ static int check_header(char *line, unsigned linesize, char **hdr_data, int over
/* for inbody stuff */
if (!memcmp(">From", line, 5) && isspace(line[5]))
return 1;
if (!memcmp("[PATCH]", line, 7) && isspace(line[7])) {
for (i = 0; header[i]; i++) {
if (!memcmp("Subject", header[i], 7)) {
+ if (!hdr_data[i])
+ hdr_data[i] = xmalloc(linesize + 20);
if (! handle_header(line, hdr_data[i], 0)) {
return 1;
}
}
}
}
diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
index 2d1520f..13f0502 100644
--- a/builtin-mailinfo.c
+++ b/builtin-mailinfo.c
@@ -335,6 +335,8 @@ static int check_header(char *line, unsigned linesize, char **hdr_data, int over
if (!memcmp("[PATCH]", line, 7) && isspace(line[7])) {
for (i = 0; header[i]; i++) {
if (!memcmp("Subject", header[i], 7)) {
+ if (!hdr_data[i])
+ hdr_data[i] = xmalloc(linesize + 20);
if (! handle_header(line, hdr_data[i], 0)) {
return 1;
}
diff --git a/t/t5100-mailinfo.sh b/t/t5100-mailinfo.sh
index 577ecc2..e9f3e72 100755
--- a/t/t5100-mailinfo.sh
+++ b/t/t5100-mailinfo.sh
@@ -11,7 +11,7 @@ test_expect_success 'split sample box' \
'git mailsplit -o. ../t5100/sample.mbox >last &&
last=`cat last` &&
echo total is $last &&
- test `cat last` = 9'
+ test `cat last` = 10'
for mail in `echo 00*`
do
diff --git a/t/t5100/sample.mbox b/t/t5100/sample.mbox
index 0476b96..aba57f9 100644
--- a/t/t5100/sample.mbox
+++ b/t/t5100/sample.mbox
@@ -430,3 +430,38 @@ index b426a14..97756ec 100644
=20
=20
2. When the environment variable 'GIT_EXTERNAL_DIFF' is set, the
+From b9704a518e21158433baa2cc2d591fea687967f6 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Lukas=20Sandstr=C3=B6m?= <lukass@etek.chalmers.se>
+Date: Thu, 10 Jul 2008 23:41:33 +0200
+Subject: Re: discussion that lead to this patch
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+[PATCH] git-mailinfo: Fix getting the subject from the body
+
+"Subject: " isn't in the static array "header", and thus
+memcmp("Subject: ", header[i], 7) will never match.
+
+Signed-off-by: Lukas Sandström <lukass@etek.chalmers.se>
+Signed-off-by: Junio C Hamano <gitster@pobox.com>
+---
+ builtin-mailinfo.c | 2 +-
+ 1 files changed, 1 insertions(+), 1 deletions(-)
+
+diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
+index 962aa34..2d1520f 100644
+--- a/builtin-mailinfo.c
++++ b/builtin-mailinfo.c
+@@ -334,7 +334,7 @@ static int check_header(char *line, unsigned linesize, char **hdr_data, int over
+ return 1;
+ if (!memcmp("[PATCH]", line, 7) && isspace(line[7])) {
+ for (i = 0; header[i]; i++) {
+- if (!memcmp("Subject: ", header[i], 9)) {
++ if (!memcmp("Subject", header[i], 7)) {
+ if (! handle_header(line, hdr_data[i], 0)) {
+ return 1;
+ }
+--
+1.5.6.2.455.g1efb2
+
^ permalink raw reply related
* Re: [PATCH] Add pretty format %aN which gives the author name, respecting .mailmap
From: Sverre Rabbelier @ 2008-07-12 8:44 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: gitster, Git Mailinglist, David Symonds
In-Reply-To: <alpine.DEB.1.00.0807120041300.8950@racer>
On Sat, Jul 12, 2008 at 1:42 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Heh. The price is that my patches are usually more buggy than other
> contributors' patches.
Pick Two: Good, Fast, and Cheap...? ;)
>> I'm not sure what to do though, if I use this new %cN GitStats will
>> only work with the latest git version... :(
>
> Yes, that is correct. But my impression was that GitStats was never meant
> as a pure add-on, but rather some integral part of Git, no? IOW at least
> contrib/ stuff.
Aye, that is true. Currently it should run with pretty much any
version, but if it does end up in git.git there is no reason not to
benefit from the most recent changes.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Should we discuss Windows-related changes on git@vger.kernel.org?
From: Steffen Prohaska @ 2008-07-12 8:07 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Linus Torvalds, Johannes Sixt, Junio C Hamano, msysGit,
Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0807112226190.8950@racer>
On Jul 11, 2008, at 11:38 PM, Johannes Schindelin wrote:
>> Another example is the discussion about GIT_EXEC_PATH, see
>>
>> http://thread.gmane.org/gmane.comp.version-control.msysgit/2633
>
> This is a particularly good example that does not matter for Linux,
> MacOSX, Solaris or the BSDs (Git's principal platforms!) at all.
>
> And once this patch hits git@vger, it is still visible to other
> platforms.
Hmm... on Mac OS X, applications can typically be moved freely in the
filesystem. Installing such an application means no more than mounting
a disk image that contains a directory that you can drag and drop to any
location in the filesystem. You do not need administrative rights to do
this.
For command line programs, like git, moving the installation freely is
less common. Installers often place everything in /usr/local/ (they
need administrative rights to do so). But there are other examples too.
For example, I have other vims installed in addition to the system's
vim:
/Applications/vim70/Vim.app
/Applications/MacVim-snapshot-24/mvim
that I can freely move around.
The result of our discussion on GIT_EXEC_PATH might be useful to achieve
something similar for git -- although I think that it is not an
essential
feature.
Steffen
^ permalink raw reply
* Re: [GitStats] Bling bling or some statistics on the git.git repository
From: Sverre Rabbelier @ 2008-07-12 7:39 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailinglist, David Symonds
In-Reply-To: <alpine.DEB.1.00.0807120028280.8950@racer>
On Sat, Jul 12, 2008 at 1:33 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> If you were suspecting that I would write the patch once the semantics are
> finalized, you would be absolutely correct.
Awesome!
>> Mhhh, such would be beyond the scope of implementing manually indeed,
>> and should be left to the likes of a diff tool instead in order to
>> prevent reinventing the wheel :).
>
> That is why I was suggesting using the diff tool with munged input to find
> out what works best.
This makes sense, put the responsibility where it belongs, that way
someone else may use it as well.
> When that is done, I'll turn it into C.
Very much appreciated. I will start playing around with munged diffs
today and keep you posted of the result.
>> Correct, that's because that is what 'git log' tells me.
>
> I suspect that one big "git log" will not tell you enough. You probably
> need to make your tool aware (at least a little) about merges, just as you
> probably made it aware about parent/child relationships (to track the
> changes along renames)...
Atm it is not aware of parent/child relationships in the activity
analysis. (This is not the case in the 'branch contains' metric, in
which I use 'git rev-list --parents' to extract and analyse that.) I
thought of tracking renames by honoring what "git log -C -C -M" tells
me (e.g., whenever it says {foo/bar.c => bar.c} I move all the metrics
under key "foo/bar.c" to "bar.c").
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Should we discuss Windows-related changes on git@vger.kernel.org?
From: Steffen Prohaska @ 2008-07-12 7:38 UTC (permalink / raw)
To: Johannes Schindelin, Junio C Hamano
Cc: Johannes Sixt, msysGit, Git Mailing List, Linus Torvalds
In-Reply-To: <alpine.LFD.1.10.0807111653500.2875@woody.linux-foundation.org>
On Jul 12, 2008, at 1:58 AM, Linus Torvalds wrote:
> On Sat, 12 Jul 2008, Johannes Schindelin wrote:
>>
>> But we are talking about 4msysgit.git, no?
>
> I'm not. I'm just talking about Windows-related changes in git in
> general, that are expected to be merged into regular git one way or
> another.
The discussion is not about 4msysgit, because 4msysgit will no longer
be needed after we cleaned up all differences between Junio's master
and 4msysgit's master.
I propose the following steps:
- We review the differences and either prepare patches for official
git
or revert commits in 4msysgit.
-> It will no longer matter if we build the msysgit release from
Junio's master or from 4msysgit's master.
- We change the /git submodule in msysgit to point to Junio's repo.
-> Every developer on Windows will work with the official code base.
- Windows-users can (and should) participate in the official release
cycle. They should test the next branch and the master branch after
the merge window closed. We can easily create installers for
Junio's
release candidates (I will do this).
We should provide a guideline how developers and users should send
comments and improvements related to Windows. Such a guideline could be
included in Junio's "A note from the maintainer" mail. The section on
Windows needs to be changed anyway. Currently it says:
'''
- Johannes Schindelin and Johannes Sixt for their effort to
move things forward on the Windows front. Although my
repository does not have much from the effort of MinGW team,
I expect a merge into mainline will happen so that everybody
can work from the same codebase.
'''
[ Note that the last sentence will become true if we do what I propose
above. ]
We could send more detailed guidelines to the msysgit list and/or modify
the homepage of the msysgit project. I think Junio's rule of thumb in
http://article.gmane.org/gmane.comp.version-control.git/88191
is a good starting point.
It would be good to achieve all this during the 1.6 cycle, because
MinGW is officially part of 1.6. I am however not sure if it is
practical. We have some changes in 4msysgit that might need more
discussion and we did not even start discussing the tests. So maybe
1.6.1 is more realistic.
Steffen
^ permalink raw reply
* Re: [PATCH 3/3 FIXED] help (Windows): Display HTML in default browser using Windows' shell API
From: Junio C Hamano @ 2008-07-12 7:07 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git, Johannes Schindelin, Johannes Sixt
In-Reply-To: <8D150442-8B57-4025-9110-BC4C23C2310C@zib.de>
Steffen Prohaska <prohaska@zib.de> writes:
>> Do you mean to have that printf() or is it a leftover debugging
>> statement?
>
> I mean to have it.
Ok, I was just checking. Unless other Windows users complain, will apply
as-is. As you might guess, I am completely neutral on this one.
^ permalink raw reply
* Re: [PATCH 3/3 FIXED] help (Windows): Display HTML in default browser using Windows' shell API
From: Steffen Prohaska @ 2008-07-12 6:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, Johannes Sixt
In-Reply-To: <7vtzevhjf8.fsf@gitster.siamese.dyndns.org>
On Jul 12, 2008, at 5:26 AM, Junio C Hamano wrote:
> Steffen Prohaska <prohaska@zib.de> writes:
>
>> diff --git a/compat/mingw.c b/compat/mingw.c
>> index 3a05fe7..0ca73f7 100644
>> --- a/compat/mingw.c
>> +++ b/compat/mingw.c
>> @@ -1017,3 +1017,24 @@ sig_handler_t mingw_signal(int sig,
>> sig_handler_t handler)
>> ...
>> +void mingw_open_html(const char *unixpath)
>> +{
>> + const char *htmlpath = make_backslash_path(unixpath);
>> + printf("Launching default browser to display HTML ...\n");
>> + ShellExecute(NULL, "open", htmlpath, NULL, "\\", 0);
>> +}
>
> Do you mean to have that printf() or is it a leftover debugging
> statement?
I mean to have it. It takes some time until a fresh browser starts up
if no browser has been running before. Impatient people (like me) could
start believing that nothing would happen. But this certainly depends
on your machine. I run Windows inside a virtual machine on a Laptop,
which is probably rather slow compared to a desktop machine running
Windows natively.
Steffen
^ permalink raw reply
* Re:! [PATCH/RFC] git-mailinfo: use strbuf's instead of fixed buffers
From: Junio C Hamano @ 2008-07-12 6:10 UTC (permalink / raw)
To: Lukas Sandström; +Cc: Git Mailing List
In-Reply-To: <48769E91.60205@etek.chalmers.se>
Lukas Sandström <lukass@etek.chalmers.se> writes:
> -static char *sanity_check(char *name, char *email)
> +static void sanity_check(struct strbuf *out, struct strbuf *name, struct strbuf *email)
> {
> - int len = strlen(name);
> - if (len < 3 || len > 60)
> - return email;
> - if (strchr(name, '@') || strchr(name, '<') || strchr(name, '>'))
> - return email;
> - return name;
> + struct strbuf o = STRBUF_INIT;
> + if (name->len < 3 || name->len > 60)
> + strbuf_addbuf(&o, email);
> + if (strchr(name->buf, '@') || strchr(name->buf, '<') ||
> + strchr(name->buf, '>'))
> + strbuf_addbuf(&o, email);
> + strbuf_addbuf(&o, name);
> + strbuf_reset(out);
> + strbuf_addbuf(out, &o);
> + strbuf_release(&o);
This does not look like a correct conversion. When name is too short or
too long, we do not even look at name and return email straight. Perhaps
this would be more faithful conversion:
struct strbuf *src = name;
if (name->len < 3 ||
60 < name->len ||
strchr(name->buf, '@') ||
strchr(name->buf, '<') ||
strchr(name->buf, '>'))
src = email;
else if (name == out)
return;
strbuf_reset(out);
strbuf_addbuf(out, src);
It is not your fault, but sanity_check() is a grave misnomer for this
function. This does "get_sane_name" (i.e. we have name and email but if
name does not look right, use email instead).
> -static int bogus_from(char *line)
> +static int bogus_from(const struct strbuf *line)
> {
> /* John Doe <johndoe> */
> - char *bra, *ket, *dst, *cp;
>
> + char *bra, *ket;
> /* This is fallback, so do not bother if we already have an
> * e-mail address.
> */
> - if (*email)
> + if (email.len)
> return 0;
>
> - bra = strchr(line, '<');
> + bra = strchr(line->buf, '<');
> if (!bra)
> return 0;
> ket = strchr(bra, '>');
> if (!ket)
> return 0;
>
> - for (dst = email, cp = bra+1; cp < ket; )
> - *dst++ = *cp++;
> - *dst = 0;
> - for (cp = line; isspace(*cp); cp++)
> - ;
> - for (bra--; isspace(*bra); bra--)
> - *bra = 0;
> - cp = sanity_check(cp, email);
> - strcpy(name, cp);
> + strbuf_reset(&email);
> + strbuf_add(&email, bra + 1, ket - bra - 1);
> +
> + strbuf_reset(&name);
> + strbuf_add(&name, line->buf, bra - line->buf);
> + strbuf_trim(&name);
> + sanity_check(&name, &name, &email);
> return 1;
> }
Conversion looks correct but its return value does not make much sense
(again, not your fault). bogus_from() is given a bogus looking from line
(it is not about checking if it is bogus), and returns 0 if we already
have e-mail address, if the from line does not have bra-ket for grabbing
e-mail address for, but returns 1 if we managed to get name and email
pairs. The inconsistency does not matter only because its sole caller
handle_from() returns its return value, and its caller discards it. We
may be better off declaring this function and handle_from() as void.
> -static int handle_from(char *in_line)
> +static int handle_from(struct strbuf *from)
> ...
> + el = strcspn(at, " \n\t\r\v\f>");
> + strbuf_reset(&email);
> + strbuf_add(&email, at, el);
> + strbuf_remove(from, at - from->buf, el + 1);
> /* The remainder is name. It could be "John Doe <john.doe@xz>"
> * or "john.doe@xz (John Doe)", but we have whited out the
> * email part, so trim from both ends, possibly removing
> * the () pair at the end.
> */
Now, it should read "but we have removed the email part", I think.
> + strbuf_trim(from);
> + if (*from->buf == '(')
> + strbuf_remove(&name, 0, 1);
> + if (*(from->buf + from->len - 1) == ')')
Can from be empty at this point before this check?
> + strbuf_setlen(from, from->len - 1);
> +
> + sanity_check(&name, from, &email);
> return 1;
> }
We used to copy the data from the argument (in_line) before munging it in
this function, but now we are modifying it in place (from). Does this
upset our caller, or the original code was just doing an extra unnecessary
copy?
> -static int handle_header(char *line, char *data, int ofs)
> +static void handle_header(struct strbuf **out, const struct strbuf *line)
> {
> - if (!line || !data)
> - return 1;
> -
> - strcpy(data, line+ofs);
> + if (!*out) {
> + *out = xmalloc(sizeof(struct strbuf));
> + strbuf_init(*out, line->len);
> + } else
> + strbuf_reset(*out);
>
> - return 0;
> + strbuf_addbuf(*out, (struct strbuf *)line); /* const warning */
> }
I think its second parameter can safely become "const struct strbuf *";
perhaps we should fix the definition of strbuf_addbuf() in your first
patch?
> @@ -173,180 +153,176 @@ static int slurp_attr(const char *line, const char *name, char *attr)
> else
> ends = "; \t";
> sz = strcspn(ap, ends);
> - memcpy(attr, ap, sz);
> - attr[sz] = 0;
> + strbuf_add(attr, ap, sz);
> return 1;
> }
>
> struct content_type {
> - char *boundary;
> - int boundary_len;
> + struct strbuf *boundary;
> };
>
> static struct content_type content[MAX_BOUNDARIES];
Wouldn't it make more sense to get rid of "struct content_type" altogether
and use "struct strbuf *content[MAX_BOUNDARIES]" directly?
I'll review from handle_content_type() til the rest of the file
separately, as my concentration is wearing out..
^ permalink raw reply
* Re: [PATCH] setup.py: fix error message when running with python-2.3
From: Karl Hasselström @ 2008-07-12 5:19 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Catalin Marinas, Thomas Rast, Petr Baudis, Git Mailing List
In-Reply-To: <1215806972-18713-1-git-send-email-vmiklos@frugalware.org>
On 2008-07-11 22:09:31 +0200, Miklos Vajna wrote:
> When setup.py tries to check the python version, the check actually
> won't give a usable error message but it'll raise a SyntaxError. Fix
> this by not using generator expressions.
> - pyver = '.'.join(str(n) for n in sys.version_info)
> + pyver = '.'.join(map(lambda x: str(x), sys.version_info))
Thanks. And by not using a list comprehension, you stay compatible
with pre-2.0 versions as well (though I guess we'd need to test that,
since there may be other 2.0 things we rely on in this code path).
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] Fix backwards-incompatible handling of core.sharedRepository
From: Junio C Hamano @ 2008-07-12 3:44 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20080711150707.GE32184@machine.or.cz>
Thanks. Queued on 'maint'.
^ permalink raw reply
* Re: [JGIT PATCH 1/1] jgit: create a tag command
From: Shawn O. Pearce @ 2008-07-12 3:42 UTC (permalink / raw)
To: Mike Ralphson; +Cc: Robin Rosenberg, Marek Zawirski, git
In-Reply-To: <20080712030104.GB15838@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> wrote:
> Mike Ralphson <mike.ralphson@gmail.com> wrote:
>
> > > I think we are at the point where we need to either write a
> > > #@!*(!@(! command line option parser, import one, or stop writing
> > > command line programs. I would certainly appreciate any opinion
> > > you might have on the matter.
> >
> > a) is a distraction, c) is a backwards step, so maybe b) wins.
>
> So I looked at GNU getopt and its at least smaller than Apache
> Commons,
Probably the state-of-the-arg is args4j:
https://args4j.dev.java.net/
It uses Java 5 annotations to setup the argument parsing:
public class SampleMain {
@Option(name="-r",usage="recursively run something")
private boolean recursive;
@Option(name="-o",usage="output to this file",metaVar="OUTPUT")
private File out = new File(".");
@Option(name="-str") // no usage
private String str = "(default value)";
...
I'm usually not a big fan of reflection, but it may make sense to
take advantage of it in a case like this, and just import args4j
into our command line tools.
args4j is provided under the MIT license.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 3/3 FIXED] help (Windows): Display HTML in default browser using Windows' shell API
From: Junio C Hamano @ 2008-07-12 3:26 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git, Johannes Schindelin, Johannes Sixt
In-Reply-To: <1215761822-21356-1-git-send-email-prohaska@zib.de>
Steffen Prohaska <prohaska@zib.de> writes:
> diff --git a/compat/mingw.c b/compat/mingw.c
> index 3a05fe7..0ca73f7 100644
> --- a/compat/mingw.c
> +++ b/compat/mingw.c
> @@ -1017,3 +1017,24 @@ sig_handler_t mingw_signal(int sig, sig_handler_t handler)
> ...
> +void mingw_open_html(const char *unixpath)
> +{
> + const char *htmlpath = make_backslash_path(unixpath);
> + printf("Launching default browser to display HTML ...\n");
> + ShellExecute(NULL, "open", htmlpath, NULL, "\\", 0);
> +}
Do you mean to have that printf() or is it a leftover debugging statement?
^ permalink raw reply
* Re: [JGIT PATCH 1/1] jgit: create a tag command
From: Shawn O. Pearce @ 2008-07-12 3:01 UTC (permalink / raw)
To: Mike Ralphson; +Cc: Robin Rosenberg, Marek Zawirski, git
In-Reply-To: <e2b179460807110145n4182978awd3aa3f97c3caac95@mail.gmail.com>
Mike Ralphson <mike.ralphson@gmail.com> wrote:
> 2008/7/11 Shawn O. Pearce <spearce@spearce.org>:
> > Mike Ralphson <mike.ralphson@gmail.com> wrote:
> >>
> >> Loving the make_jgit stuff.
> >
> > So making jgit a single stand-alone, portable shell script for
> > command line usage was a good idea? ;-)
>
> It certainly seems so to me. It's a nice quick way of seeing what's
> implemented (I was toying with adding a jgit help command which would
> reflect over the TextBuiltins).
Yea, sadly our builtins don't register themselves into a table so its
a bit difficult to enumerate them at this time. But it probably would
not be a difficult thing to change at all, and since we don't have a
lot of them yet it wouldn't be that much work to do the conversion.
> I'm not sure which if any platforms would eventually be better off
> with a commandline jgit than trying to port c-git though.
Not all platforms can compile c git, e.g. they are missing a
c compiler, but have a JRE handy. Odd, I know, but sometimes
that's how it goes. Or maybe you have a JRE handy, and want to
just download the single stand-alone jgit jar to get some sort of a
basic git implementation available, so you can clone and build the
real thing direct from Junio's sources.
Or maybe you are using a transport (Amazon S3) that C Git just
doesn't support. :-)
> > I think we are at the point where we need to either write a
> > #@!*(!@(! command line option parser, import one, or stop writing
> > command line programs. I would certainly appreciate any opinion
> > you might have on the matter.
>
> a) is a distraction, c) is a backwards step, so maybe b) wins.
I don't disagree, I thought the very same thing myself.
> I don't know what the state of the art of Java option parsers is but
> there is a port of GNU getopt [1] which might drop in quite easily.
So I looked at GNU getopt and its at least smaller than Apache
Commons, and doesn't have this damned-if-you-do, damned-if-you-do
version selection choice they offer their end-users. But it really
makes building something like an automatic --help difficult if not
impossible, and certainly makes handling numeric vs. ObjectId vs.
String vs. File arguments annoying.
I'd almost rather just do a). It wouldn't take long to get something
small rolled out and working. We don't need to support every goddamn
weird syntax that C git supports for backward compatability reasons.
> PS apologies for the patch format, I'm stuck with Outlook or gmail,
> and a recalcitrant firewall for the moment.
Some people are terrified of that system of tubes. I feel for you.
Day-job is that way. :-(
> [1] http://www.urbanophile.com/arenn/hacking/download.html
--
Shawn.
^ permalink raw reply
* Re: [RFC/PATCH (WIP)] Git.pm: Add get_config() method and related subroutines
From: Petr Baudis @ 2008-07-12 1:47 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Lea Wiemann
In-Reply-To: <200807100133.38163.jnareb@gmail.com>
On Thu, Jul 10, 2008 at 01:33:36AM +0200, Jakub Narebski wrote:
> On Wed, Jul 09, 2008, Petr "Pasky" Baudis wrote:
> > On Thu, Jul 03, 2008 at 06:24:53PM +0200, Jakub Narebski wrote:
> > > * Should config_val_to_bool and config_val_to_int throw error or
> > > just return 'undef' on invalid values? One can check if variable
> > > is defined using "exists($config_hash{'varname'})".
> >
> > I think that it's more reasonable to throw an error here (as long as
> > you don't throw an error on undef argument). This particular case is
> > clearly a misconfiguration by the user and you rarely need to handle
> > this more gracefully, I believe.
>
> If we follow git-config convention (and I guess we should), it would be
> value of appropriate type if variable value is of appropriate type,
> 'undef' (no output in the case of git-config) when variable does not
> exists, and throwing error (status and "fatal: ..." message on STDERR
> in the case of git-config) if variable is not of given type.
Yes, this seems to be in agreement with what I suggested.
> > > * What should ->get_config() have as an optional parameter:
> > > PREFIX (/^$prefix/o), or simply SECTION (/^(?:$section)\./o)?
> >
> > Do we even _need_ a parameter like that? I don't understand what is
> > this interface trying to address.
>
> For example if one wants to access _all_ variables in gitweb.* section
> (or in gitcvs.* section), and _only_ config variables in given section.
But what is the practical benefit? Does anyone use a config file long
enough that this makes any difference?
Or if you mean foreach use, it's trivial to
foreach (grep { /^gitweb\./ } keys %$config)
or provide a method of Git::Config that will return this list, but it
does not seem appropriate to have specific Git::Config instances for
this. (Besides, if the script also needs to access a single variable
from a different section, it will need to re-parse the config again.)
So I think your approach would be good only if there are multiple
methods of Git::Config that would operate on the whole config and needed
a way to be restricted; is that the case?
> BTW. what should non-typecasting should be named? $c->get(<VAR>),
> $c->value(<VAR>), $c->param(<VAR>), or something yet different?
I would prefer 'get' since it's the shortest and most clear, but 'value'
would be fine too, I suppose (and more in line with bool etc.).
> > Also, having accessors for special types lets you return undef when
> > the type really isn't defined, instead of e.g. true with current
> > config_val_bool, which is clearly bogus and requires complicated code
> > on the user side.
>
> I don't follow you. Didn't we agree on casting an error when variable
> is not of given type?
Sorry, s/type really/variable really/. According to your original code,
config_val_bool(undef)
would return true, while the undef could be from both non-existent and
unassigned variable. (This 'unassigned variables' case is really
annoying to handle.)
> > --
> > Petr "Pasky" Baudis
> > The last good thing written in C++ was the Pachelbel Canon.
> > -- J. Olson
>
> Eh? Isn't it written C# rather?
Well, the quote is a bit dated and changing it would be too problematic.
;-)
--
Petr "Pasky" Baudis
GNU, n. An animal of South Africa, which in its domesticated state
resembles a horse, a buffalo and a stag. In its wild condition it is
something like a thunderbolt, an earthquake and a cyclone. -- A. Pierce
^ permalink raw reply
* Re: Git call graph
From: Miklos Vajna @ 2008-07-12 1:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd4ljj4u1.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 449 bytes --]
On Fri, Jul 11, 2008 at 05:58:46PM -0700, Junio C Hamano <gitster@pobox.com> wrote:
> > Here is the result:
> >
> > http://vmiklos.hu/pic/git-call-graph.png
>
> Your pull does not seem to call either fetch nor merge... Strange.
My bad. I tracked shell calls using a wrapper around 'git' so it missed
calls without the 'remove-dashes' patches I posted yesterday.
http://vmiklos.hu/pic/git-call-graph-v2.png
This one now shows that.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCHv4] Fix backwards-incompatible handling of core.sharedRepository
From: Petr Baudis @ 2008-07-12 1:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Heikki Orsila
In-Reply-To: <7vhcawhs1e.fsf@gitster.siamese.dyndns.org>
06cbe85 (Make core.sharedRepository more generic, 2008-04-16) broke the
traditional setting of core.sharedRepository to true, which was to make
the repository group writable: with umask 022, it would clear the
permission bits for 'other'. (umask 002 did not exhibit this behaviour
since pre-chmod() check in adjust_shared_perm() fails in that case.)
The call to adjust_shared_perm() should only loosen the permission.
If the user has umask like 022 or 002 that allow others to read, the
resulting files should be made readable and writable by group, without
restricting the readability by others.
This patch fixes the adjust_shared_perm() mode tweak based on Junio's
suggestion and adds the appropriate tests to t/t1301-shared-repo.sh.
Cc: Heikki Orsila <heikki.orsila@iki.fi>
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
Fourth iteration. The problem is in fact triggered with umask 022,
not 002; fixed the description and extended the testsuite appropriately.
Improved patch description as well as the adjust_shared_perm() fix based
on Junio's suggestions here and on #git, so by now it's more of his
patch than mine. :-)
path.c | 2 +-
t/t1301-shared-repo.sh | 22 ++++++++++++++++++++++
2 files changed, 23 insertions(+), 1 deletions(-)
diff --git a/path.c b/path.c
index 5983255..504eae0 100644
--- a/path.c
+++ b/path.c
@@ -272,7 +272,7 @@ int adjust_shared_perm(const char *path)
int tweak = shared_repository;
if (!(mode & S_IWUSR))
tweak &= ~0222;
- mode = (mode & ~0777) | tweak;
+ mode |= tweak;
} else {
/* Preserve old PERM_UMASK behaviour */
if (mode & S_IWUSR)
diff --git a/t/t1301-shared-repo.sh b/t/t1301-shared-repo.sh
index 6c78c8b..4c6d0b6 100755
--- a/t/t1301-shared-repo.sh
+++ b/t/t1301-shared-repo.sh
@@ -17,6 +17,28 @@ test_expect_success 'shared = 0400 (faulty permission u-w)' '
test $ret != "0"
'
+for u in 002 022; do
+ test_expect_success "shared=1 does not clear bits preset by umask $u" '
+ mkdir sub &&
+ cd sub &&
+ umask $u &&
+ git init --shared=1 &&
+ test 1 = $(git config core.sharedrepository) &&
+ actual="$(ls -l .git/HEAD)" &&
+ cd .. &&
+ rm -rf sub &&
+ case "$actual" in
+ -rw-rw-r--*)
+ : happy
+ ;;
+ *)
+ echo Oops, .git/HEAD is not 0664 but $actual
+ false
+ ;;
+ esac
+ '
+done
+
test_expect_success 'shared=all' '
mkdir sub &&
cd sub &&
^ permalink raw reply related
* Re: Should we discuss Windows-related changes on git@vger.kernel.org?
From: Linus Torvalds @ 2008-07-12 1:07 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Steffen Prohaska, Johannes Sixt, msysGit,
Git Mailing List
In-Reply-To: <alpine.LFD.1.10.0807111653500.2875@woody.linux-foundation.org>
On Fri, 11 Jul 2008, Linus Torvalds wrote:
>
> If it's something that should be merged, and if it concerns code that I'm
> interested in, I want to know about it. It's that simple.
Btw, an example of where I think we need to look at both windows and unix
behavior and not try to make them two different camps is in that
"start_command()" thing.
It was changed to have a totally separate __MINGW32__ part, but the thing
is, the unix side could really be improved - and actually made more like
the MINGW32 code at the same time!
For example, on many systems it is rather noticeably faster to use
"vfork+execve" than it is to do "fork+execve", because you avoid a whole
"duplicate and tear down page tables" sequence. So the UNIX code would
actually be better off using "vfork()" instead of "fork()" there.
But it can't right now - because if "cmd->env" changes the environment, it
would change it both in the caller and in the result.
It turns out that Windows has the exact same issue (because it uses a
spawn thing), and already does a "copy_env() + change-in-copy + free"
model for that reason.
If that was shared, the UNIX side could just use vfork, I believe. In
fact, the following trivial - but horribly ugly - patch passes all the
tests, by doing the vfork() in all cases except when the environment
changes. But I don't know what coverage that has, though (maybe env is
effectively always set?).
And I suspect there are other cases where we'd actually be better off
trying to share things than having all the differences hidden away in
compat layers.
Linus
---
builtin-grep.c | 2 +-
run-command.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin-grep.c b/builtin-grep.c
index ef29910..5d3053a 100644
--- a/builtin-grep.c
+++ b/builtin-grep.c
@@ -168,7 +168,7 @@ static int exec_grep(int argc, const char **argv)
int status;
argv[argc] = NULL;
- pid = fork();
+ pid = vfork();
if (pid < 0)
return pid;
if (!pid) {
diff --git a/run-command.c b/run-command.c
index 6e29fdf..200ba7b 100644
--- a/run-command.c
+++ b/run-command.c
@@ -68,7 +68,7 @@ int start_command(struct child_process *cmd)
trace_argv_printf(cmd->argv, "trace: run_command:");
#ifndef __MINGW32__
- cmd->pid = fork();
+ cmd->pid = cmd->env ? fork() : vfork();
if (!cmd->pid) {
if (cmd->no_stdin)
dup_devnull(0);
^ permalink raw reply related
* Git call graph
From: Miklos Vajna @ 2008-07-12 0:47 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 826 bytes --]
Hi,
I just did this for fun, if you are busy, you can stop reading now,
this mail is not about anything important. :-)
I thought it would worth a try to make a graph about git calls, when a
script calls an other git program. I tracked two types of calls:
- when a bultin calls an other builtin (like git reset calls
git read-tree)
- when a script calls a builtin (like git merge-resolve calls
git write-tree)
Here is the result:
http://vmiklos.hu/pic/git-call-graph.png
The code that was used to generate the graph is available at the 'graph'
branch of git://repo.or.cz/git/vmiklos.git.
If you check out that branch, you can simply type 'make' to generate the
picture, or you can read some minimal documentation (README).
And now I should stop playing with it, in fact it took much more time
than I expected. ;-)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCHv3] Fix backwards-incompatible handling of core.sharedRepository
From: Junio C Hamano @ 2008-07-12 0:20 UTC (permalink / raw)
To: Petr Baudis; +Cc: git, Heikki Orsila
In-Reply-To: <20080711234257.16449.85447.stgit@rover.dkm.cz>
Petr Baudis <pasky@suse.cz> writes:
> The 06cbe8550324e0fd2290839bf3b9a92aa53b70ab core.sharedRepository
> handling extension broke backwards compatibility; before, shared=1 meant
> that Git merely ensured the repository is group-writable, not that it's
> _only_ group-writable, which is the current behaviour. Thus, with umask 002,
> Git creates repository with /rw.rw.--./, this patch fixes it back to
> /rw.rw.r-./.
Is it just me who finds the above unreadable blob of black ink?
06cbe85 (Make core.sharedRepository more generic, 2008-04-16)
broke the traditional setting core.sharedRepository to true,
which was to make the repository group writable.
The call to adjust_shared_perm() should only loosen the
permission. If the user has umask 002 (or 022) that allow others
to read, the resulting files should be made readable and writable
by group, without restricting the readability by others.
> Maybe it makes sense to provide the current semantics in some way too,
> but that cannot be done at the expense of ditching backwards
> compatibility; this bug has just wasted me two hours and broke
> repo.or.cz pushing for several hours.
I do not think this gripe after the semicolon belongs before the
three-dash lines.
> Cc: Heikki Orsila <heikki.orsila@iki.fi>
> Signed-off-by: Petr Baudis <pasky@rover.dkm.cz>
> ---
>
> Oops, this testcase wouldn't really remove its test subrepository
> after itself properly, though the testsuite would still pass; of course
> this bug slipped through all the previous visual inspections of mine.
>
> Sorry for the continuous noise. :-)
Hmm, I am very puzzled.
I am afraid I have to ask you for another round. I applied only your
update to t/t1301 without the change to path.c, and the test passes, which
means either (1) the test is incorrect and does not exposing the breakage,
or (2) the breakage is not real and existing code is correct.
^ permalink raw reply
* Re: Should we discuss Windows-related changes on git@vger.kernel.org?
From: Johannes Schindelin @ 2008-07-12 0:06 UTC (permalink / raw)
To: Linus Torvalds
Cc: Junio C Hamano, Steffen Prohaska, Johannes Sixt, msysGit,
Git Mailing List
In-Reply-To: <alpine.LFD.1.10.0807111653500.2875@woody.linux-foundation.org>
Hi,
On Fri, 11 Jul 2008, Linus Torvalds wrote:
> On Sat, 12 Jul 2008, Johannes Schindelin wrote:
> >
> > But we are talking about 4msysgit.git, no?
>
> I'm not. I'm just talking about Windows-related changes in git in
> general, that are expected to be merged into regular git one way or
> another.
>
> [...]
>
> But I'd certainly _hope_ that future windows work is incremental, and at
> that point it's no longer a "drop the end result on people" situation.
Fair enough. You'll get all the crap now, I expect.
Seriously again, I really hope that things do not change very much. Even
if the occasional patch will now come in directly to git@vger.
Ciao,
Dscho
^ permalink raw reply
* Re: Should we discuss Windows-related changes on git@vger.kernel.org?
From: Linus Torvalds @ 2008-07-11 23:58 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Steffen Prohaska, Johannes Sixt, msysGit,
Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0807120043150.8950@racer>
On Sat, 12 Jul 2008, Johannes Schindelin wrote:
>
> But we are talking about 4msysgit.git, no?
I'm not. I'm just talking about Windows-related changes in git in
general, that are expected to be merged into regular git one way or
another.
If it's something that should be merged, and if it concerns code that I'm
interested in, I want to know about it. It's that simple.
The fact that _all_ windows discussion used to be in a different area and
not on the -git list is past. It was definitely the case that it didn't
affect any normal git code, since it was all maintained in a separate tree
and the normal git tree was simply not even _relevant_, and didn't even
try to be.
But that's changed. I think the windows support merge was really quite
well done, and was a rather clean series, and no, I don't think the unix
people cared about it when there was so much fundamental stuff needed to
be done - we didn't have any relevant input.
But I'd certainly _hope_ that future windows work is incremental, and at
that point it's no longer a "drop the end result on people" situation.
Linus
^ permalink raw reply
* Re: Should we discuss Windows-related changes on git@vger.kernel.org?
From: Johannes Schindelin @ 2008-07-11 23:47 UTC (permalink / raw)
To: Linus Torvalds
Cc: Junio C Hamano, Steffen Prohaska, Johannes Sixt, msysGit,
Git Mailing List
In-Reply-To: <alpine.LFD.1.10.0807111638130.3459@woody.linux-foundation.org>
Hi,
On Fri, 11 Jul 2008, Linus Torvalds wrote:
> On Sat, 12 Jul 2008, Johannes Schindelin wrote:
> >
> > I think that is a perfect example, since Hannes worked on it in
> > mingw.git. AFAIR a few comments came through msysGit, and were
> > incorporated. When everything was good for a first go at git@vger, it
> > was sent, and the interface finalized.
>
> Umm. Dscho - that was before the thing was merged.
>
> Now that the basic mingw support is part of standard git, the situation
> has changed.
>
> That's the main issue here - if mingw support is in standard git (and it
> is), then mingw issues that touch any non-mingw code should be discussed
> where all the git developers are.
>
> Can't you see the difference between the pre-merge and the post-merge
> situation?
Sure I can.
But we are talking about 4msysgit.git, no?
At least the patches that Steffen sent were all from 4msysgit.git, and for
some reason or other not necessary for Hannes' mingw.git.
We are talking about stuff like that putty thing, where people feel it
would be a better idea to avoid scripts, at the cost of a higher
maintenance burden.
We are talking about patches that were necessary a long time ago, but are
no longer, and we should have that sorted out on the msysGit list before
sending them to a list where many people could not care less for Windows,
and are probably annoyed to even read as much as _this_ thread about it,
let alone be bothered by patches that turn out to be stale in the first
place.
_That_ is what I am arguing should be sorted out, at least the early
stages, on msysGit. As we did in the past.
And that worked out rather well so far, do you disagree?
Ciao,
Dscho
^ permalink raw reply
* [PATCHv3] Fix backwards-incompatible handling of core.sharedRepository
From: Petr Baudis @ 2008-07-11 23:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Heikki Orsila
In-Reply-To: <20080711233841.30916.75885.stgit@rover.dkm.cz>
The 06cbe8550324e0fd2290839bf3b9a92aa53b70ab core.sharedRepository
handling extension broke backwards compatibility; before, shared=1 meant
that Git merely ensured the repository is group-writable, not that it's
_only_ group-writable, which is the current behaviour. Thus, with umask 002,
Git creates repository with /rw.rw.--./, this patch fixes it back to
/rw.rw.r-./.
Maybe it makes sense to provide the current semantics in some way too,
but that cannot be done at the expense of ditching backwards
compatibility; this bug has just wasted me two hours and broke
repo.or.cz pushing for several hours.
Cc: Heikki Orsila <heikki.orsila@iki.fi>
Signed-off-by: Petr Baudis <pasky@rover.dkm.cz>
---
Oops, this testcase wouldn't really remove its test subrepository
after itself properly, though the testsuite would still pass; of course
this bug slipped through all the previous visual inspections of mine.
Sorry for the continuous noise. :-)
path.c | 2 +-
t/t1301-shared-repo.sh | 20 ++++++++++++++++++++
2 files changed, 21 insertions(+), 1 deletions(-)
diff --git a/path.c b/path.c
index 5983255..75c5915 100644
--- a/path.c
+++ b/path.c
@@ -269,7 +269,7 @@ int adjust_shared_perm(const char *path)
mode = st.st_mode;
if (shared_repository) {
- int tweak = shared_repository;
+ int tweak = (mode & 0777) | shared_repository;
if (!(mode & S_IWUSR))
tweak &= ~0222;
mode = (mode & ~0777) | tweak;
diff --git a/t/t1301-shared-repo.sh b/t/t1301-shared-repo.sh
index 6c78c8b..3fe485c 100755
--- a/t/t1301-shared-repo.sh
+++ b/t/t1301-shared-repo.sh
@@ -17,6 +17,26 @@ test_expect_success 'shared = 0400 (faulty permission u-w)' '
test $ret != "0"
'
+test_expect_success 'shared=1 does not override sane umask' '
+ mkdir sub &&
+ cd sub &&
+ umask 002 &&
+ git init --shared=1 &&
+ test 1 = $(git config core.sharedrepository) &&
+ actual="$(ls -l .git/HEAD)" &&
+ cd .. &&
+ rm -rf sub &&
+ case "$actual" in
+ -rw-rw-r--*)
+ : happy
+ ;;
+ *)
+ echo Oops, .git/HEAD is not 0664 but $actual
+ false
+ ;;
+ esac
+'
+
test_expect_success 'shared=all' '
mkdir sub &&
cd sub &&
^ permalink raw reply related
* Re: [PATCH] Add pretty format %aN which gives the author name, respecting .mailmap
From: Johannes Schindelin @ 2008-07-11 23:42 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: gitster, Git Mailinglist, David Symonds
In-Reply-To: <bd6139dc0807111630j306f0225m90b501296a508552@mail.gmail.com>
Hi,
On Sat, 12 Jul 2008, Sverre Rabbelier wrote:
> On Sat, Jul 12, 2008 at 1:28 AM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> >
> > The pretty format %an does not respect .mailmap, but gives the exact
> > author name recorded in the commit. Sometimes it is more desirable,
> > however, to look if the email has another name mapped to it in
> > .mailmap.
> >
> > This commit adds %aN (and %cN for the committer name) to do exactly
> > that.
> >
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > ---
>
> Whoah, that's fast ;).
Heh. The price is that my patches are usually more buggy than other
contributors' patches.
> I'm not sure what to do though, if I use this new %cN GitStats will
> only work with the latest git version... :(
Yes, that is correct. But my impression was that GitStats was never meant
as a pure add-on, but rather some integral part of Git, no? IOW at least
contrib/ stuff.
Ciao,
Dscho
^ 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