* Re: [PATCH RFC] git-send-email --expand-aliases
From: Junio C Hamano @ 2009-11-24 7:25 UTC (permalink / raw)
To: Karl Wiberg; +Cc: Alex Chiang, Catalin Marinas, git
In-Reply-To: <b8197bcb0911232312l251dfbc9va671388cfb7fe57b@mail.gmail.com>
Karl Wiberg <kha@treskal.com> writes:
> I think that sounds like a splendid idea. It would be interesting to
> see just how thin a wrapper around git send-email (and format-patch)
> stg mail could become, without sacrificing features anyone actually
> uses. The main complication could be stg mail's templates.
Why do you even need to run format-patch? If stg mail supports a good
templates to prepare message files, it would be natural to keep using that
to prepare message files.
^ permalink raw reply
* Re: [PATCH 1/2] Refactor winsock initialization into a separate function
From: Johannes Sixt @ 2009-11-24 7:36 UTC (permalink / raw)
To: Martin Storsjö; +Cc: git, gitster
In-Reply-To: <alpine.DEB.2.00.0911240054420.14228@cone.home.martin.st>
Martin Storsjö schrieb:
> Signed-off-by: Martin Storsjo <martin@martin.st>
I have used this series in my tree for 6 weeks without negative
sideffects. I haven't tested IPv6, though.
Here's an updated commit message with my ACK:
--- >8 ---
Refactor winsock initialization into a separate function
The winsock library must be initialized. Since gethostbyname() is the
first function that calls into winsock, it was overridden to do the
initialization. This refactoring helps the next patch, where other
functions can be called earlier.
Signed-off-by: Martin Storsjo <martin@martin.st>
Acked-by: Johannes Sixt <j6t@kdbg.org>
--- >8 ---
> ---
> compat/mingw.c | 15 ++++++++++++---
> 1 files changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/compat/mingw.c b/compat/mingw.c
> index 15fe33e..f9d82ff 100644
> --- a/compat/mingw.c
> +++ b/compat/mingw.c
> @@ -903,16 +903,25 @@ char **make_augmented_environ(const char *const *vars)
> return env;
> }
>
> -/* this is the first function to call into WS_32; initialize it */
> -#undef gethostbyname
> -struct hostent *mingw_gethostbyname(const char *host)
> +static void ensure_socket_initialization(void)
> {
> WSADATA wsa;
> + static int initialized = 0;
> +
> + if (initialized)
> + return;
>
> if (WSAStartup(MAKEWORD(2,2), &wsa))
> die("unable to initialize winsock subsystem, error %d",
> WSAGetLastError());
> atexit((void(*)(void)) WSACleanup);
> + initialized = 1;
> +}
> +
> +#undef gethostbyname
> +struct hostent *mingw_gethostbyname(const char *host)
> +{
> + ensure_socket_initialization();
> return gethostbyname(host);
> }
>
^ permalink raw reply
* Re: [PATCH 2/2] Enable support for IPv6 on MinGW
From: Johannes Sixt @ 2009-11-24 7:41 UTC (permalink / raw)
To: Martin Storsjö; +Cc: git, gitster
In-Reply-To: <alpine.DEB.2.00.0911240055170.14228@cone.home.martin.st>
Martin Storsjö schrieb:
> The IPv6 support functions are loaded dynamically, to maintain backwards
> compatibility with versions of Windows prior to XP, and fallback wrappers
> are provided, implemented in terms of gethostbyname and gethostbyaddr.
>
> Signed-off-by: Martin Storsjo <martin@martin.st>
Acked-by: Johannes Sixt <j6t@kdbg.org>
-- Hannes
^ permalink raw reply
* Re: [PATCH RFC] git-send-email --expand-aliases
From: Karl Wiberg @ 2009-11-24 7:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Chiang, Catalin Marinas, git
In-Reply-To: <7vfx84jsef.fsf@alter.siamese.dyndns.org>
On Tue, Nov 24, 2009 at 8:25 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Karl Wiberg <kha@treskal.com> writes:
>
>> I think that sounds like a splendid idea. It would be interesting to
>> see just how thin a wrapper around git send-email (and format-patch)
>> stg mail could become, without sacrificing features anyone actually
>> uses. The main complication could be stg mail's templates.
>
> Why do you even need to run format-patch? If stg mail supports a good
> templates to prepare message files, it would be natural to keep using that
> to prepare message files.
The only thing stg mail _really_ needs to do, strictly speaking, is to
be git send-email with an easy way to specify a patch, or a range of
patches, to send. Anything above and beyond that is functionality that
we have to write and maintain without the help of the larger git
community, and which won't be of use to said community for no good
reason. Take the template system for cover letters and patches, for
example: there's no reason why it couldn't be part of the git tools,
and if it had been, it would have had many more users and much more
developer love.
It's a question of deciding in which areas the benefits of doing it
ourselves are worth the cost, and where it's better to let git do the
job for us. And of recognizing that StGit is old enough that tradeoffs
that were worth it when git was not as mature and featureful as today
might be worth reconsidering from time to time.
(Alex: Sorry if I'm making a big deal out of this. Just because
rewriting stg mail entirely in terms of the git tools might be
_possible_ doesn't mean that just a few steps in that direction
wouldn't be worthwhile. But I thought I should raise the possibility.)
--
Karl Wiberg, kha@treskal.com
subrabbit.wordpress.com
www.treskal.com/kalle
^ permalink raw reply
* Re: gitk does not show path file list
From: Johannes Sixt @ 2009-11-24 7:57 UTC (permalink / raw)
To: Mark Blakeney; +Cc: git
In-Reply-To: <loom.20091124T060334-836@post.gmane.org>
Mark Blakeney schrieb:
> This seems to me to be a straight out bug but given I've had no response here
> and given this is such a simple issue then I guess it's not a bug and I'm just
> missing something? Please somebody, why does gitk (usually) not show the subset
> list of files affected when you give it a path?
>
> E.g. If I am in a src dir then "gitk ." does not list files. Neither does "gitk
> $PWD" nor "gitk ../src". However "cd ..; git src" does list files!?
gitk doesn't list the files in your examples because the patterns you gave
are not initial substrings of any files in the list.
-- Hannes
^ permalink raw reply
* Re: gitk does not show path file list
From: Junio C Hamano @ 2009-11-24 8:11 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Mark Blakeney, git
In-Reply-To: <4B0B91DC.1020902@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Mark Blakeney schrieb:
>> This seems to me to be a straight out bug but given I've had no response here
>> and given this is such a simple issue then I guess it's not a bug and I'm just
>> missing something? Please somebody, why does gitk (usually) not show the subset
>> list of files affected when you give it a path?
>>
>> E.g. If I am in a src dir then "gitk ." does not list files. Neither does "gitk
>> $PWD" nor "gitk ../src". However "cd ..; git src" does list files!?
>
> gitk doesn't list the files in your examples because the patterns you gave
> are not initial substrings of any files in the list.
Yes, but if you are in src/ and run "gitk .", then...
- clicking on a commit runs "diff-tree $commit .", that lists
src/hello.c, src/goodbye.c, etc.
- gitk tries to filter paths read from diff-tree with the "." given from
the command line as the filter---it removes paths that do not match.
So the only case that would produce any output would be for you to have:
src/src/hello.c
src/frotz.c
and run
cd src && gitk src
whose invocation of "diff-tree src" will show _only_ src/src/hello.c and
then the filter procedure will limit it to whatever begins with src/
(which would be everything).
That does not sound very useful to me...
^ permalink raw reply
* [PATCH] grep: --full-tree
From: Junio C Hamano @ 2009-11-24 8:56 UTC (permalink / raw)
To: git
While working inside a deep subdirectory, it sometimes is necessary to
find a string you see in a file you are working on from the files in the
entire project. This is especially true when you are dipping your toe
into an unfamiliar project.
By default, "git grep" limits its search space to the current directory
and below (i.e. as if "-r ." is specified), and it is rather cumbersome to
repeat ../ as many times as necessary. This new option tells "git grep"
not to limit the search space to the current directory.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* In http://article.gmane.org/gmane.comp.version-control.git/111717, I
once argued in the opposite way, but I think it is Ok to aim for making
the default --full-tree in the longer run (cf. $gmane/127885). This is
the first step in that direction.
I am not sure if there can be a sane way to flip the default without
hurting existing scripts and users. Backward compatibility always is
a pain.
builtin-grep.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/builtin-grep.c b/builtin-grep.c
index 761799d..5787f35 100644
--- a/builtin-grep.c
+++ b/builtin-grep.c
@@ -693,6 +693,7 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
{
int hit = 0;
int cached = 0;
+ int full_tree = 0;
int external_grep_allowed = 1;
int seen_dashdash = 0;
struct grep_opt opt;
@@ -732,6 +733,8 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
OPT_BIT('H', NULL, &opt.pathname, "show filenames", 1),
OPT_NEGBIT(0, "full-name", &opt.relative,
"show filenames relative to top directory", 1),
+ OPT_BIT(0, "full-tree", &full_tree,
+ "search from the top of the tree", 1),
OPT_BOOLEAN('l', "files-with-matches", &opt.name_only,
"show only filenames instead of matching lines"),
OPT_BOOLEAN(0, "name-only", &opt.name_only,
@@ -862,7 +865,7 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
if (i < argc)
paths = get_pathspec(prefix, argv + i);
- else if (prefix) {
+ else if (prefix && !full_tree) {
paths = xcalloc(2, sizeof(const char *));
paths[0] = prefix;
paths[1] = NULL;
--
1.6.6.rc0.47.g1fdffa.dirty
^ permalink raw reply related
* Re: [PATCH RFC] git-send-email --expand-aliases
From: Catalin Marinas @ 2009-11-24 10:43 UTC (permalink / raw)
To: Karl Wiberg; +Cc: Alex Chiang, Junio C Hamano, git
In-Reply-To: <b8197bcb0911232312l251dfbc9va671388cfb7fe57b@mail.gmail.com>
2009/11/24 Karl Wiberg <kha@treskal.com>:
> On Tue, Nov 24, 2009 at 1:45 AM, Alex Chiang <achiang@hp.com> wrote:
>
>> * Junio C Hamano <gitster@pobox.com>:
>>
>> > If you are changing StGit to call git-send-email anyway, why not
>> > arrange stgit to call git-send-email to send the message out
>> > instead, instead of sending messages on its own?
>>
>> Yeah, I thought about that as I was poking around further in StGit
>> to figure out how it would be calling git-send-email. ;)
>>
>> > I imagine the internal implementation of stg mail would work
>> > something like:
>> >
>> > prepare messages to send out
>> > call git-send-email and have it send them
>> >
>> > What am I missing?
>>
>> My lack of familiarity with StGit internals. ;)
>>
>> Your suggestion is much better. I'll take a closer look at StGit and
>> see how feasible it is.
>>
>> Unless Catalin has strong objections?
>
> I think that sounds like a splendid idea. It would be interesting to
> see just how thin a wrapper around git send-email (and format-patch)
> stg mail could become, without sacrificing features anyone actually
> uses. The main complication could be stg mail's templates.
>
> Catalin, how wedded are you to those? ;-)
Historically, I think "stg mail" was implemented before git-send-email
existed. It was also a good way to check who's using stgit for sending
patches :-) (the message-id).
I use templates to send patches to the ARM Linux gatekeeper via a
patch management system which only accepts patches formatted in a
certain way (things improved a bit recently and the format was
relaxed). But I find myself mostly sending pull requests these days,
so that's not a critical feature for me.
If there are no other users of the stg mail templates, I'm happy to
let them go. Otherwise, we can replace the sendmail with
git-send-email in stgit.
It seems that git-format-patch and git-send-email have all the
features stgit has. We would need to keep some of the interactive
options like --edit-cover and --edit-patches since we use
git-format-patch and git-send-email in one go.
--
Catalin
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2009, #05; Sun, 22)
From: Jakub Narebski @ 2009-11-24 10:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhbsl935q.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> * jn/gitweb-blame (2009-11-19) 6 commits.
> - gitweb.js: fix null object exception in initials calculation
> - gitweb: Minify gitweb.js if JSMIN is defined
> - gitweb: Create links leading to 'blame_incremental' using JavaScript
> (merged to 'next' on 2009-10-11 at 73c4a83)
> + gitweb: Colorize 'blame_incremental' view during processing
> + gitweb: Incremental blame (using JavaScript)
> + gitweb: Add optional "time to generate page" info in footer
>
> Ajax-y blame, with a few recent fixes.
Unfortunately current version does not work with IE8 (reported by
Stephen Boyd); it stops at the very beginning of JavaScript blaming
with the two JavaScript errors:
- "firstChild is null or not an object", caused by the fact that
'<a href=""> </a>' element doesn't have firstChild which is text
node with space as contents in DOM. This can be easily worked
around.
- "Unspecified error" (twice (sic!) for the same line), which
I have currently no idea how to fix; it points to the following
line:
if (xhr.readyState === 3 && xhr.status !== 200) {
> * pb/gitweb-no-project-list (2009-11-06) 3 commits.
> . gitweb: Polish the content tags support
> . gitweb: Support for no project list on gitweb front page
> . gitweb: Refactor project list routines
>
> I picked these up but didn't queue as Warthog9's comments made certain
> amount of sense to me.
I'd like to see at least refactoring project list subroutine:
currently printing list of projects is entangled with filtering
said list; IMHO filtering list of projects should be done upfront.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] mailinfo: remove [PATCH...] prefix from Subject regardless of length
From: Jim Meyering @ 2009-11-24 10:58 UTC (permalink / raw)
To: git list
Before this change, a [...] prefix would be removed only as long as
its length did not exceed 2/3 of the subject length. Now, when the
bracketed quantity starts with PATCH, it is removed unconditionally.
Otherwise, the existing behavior remains unchanged.
While with a bare "PATCH M/N" prefix, this inconsistency shows up only
on a subject of length 2 or 1 (assuming one-digit M and N), if you set
format.subjectprefix to the name of a project or sub-project, the
minimum affected length may be substantially larger.
Contrast the behavior before:
for i in 1234 123 12 1 ''; do echo 'Subject: [PATCH 1/1] '$i \
| git mailinfo m p | head -1; done
Subject: 1234
Subject: 123
Subject: [PATCH 1/1] 12
Subject: [PATCH 1/1] 1
Subject: [PATCH 1/1]
and after this change:
for i in 1234 123 12 1 ''; do echo 'Subject: [PATCH 1/1] '$i \
| ./git mailinfo m p | head -1; done
Subject: 1234
Subject: 123
Subject: 12
Subject: 1
Subject:
Along the way, I added a "const" to indicate that the "header"
array itself is constant.
Signed-off-by: Jim Meyering <meyering@redhat.com>
---
builtin-mailinfo.c | 10 ++++++++--
t/t5100-mailinfo.sh | 9 +++++++++
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
index 3c4f075..f07bca6 100644
--- a/builtin-mailinfo.c
+++ b/builtin-mailinfo.c
@@ -237,9 +237,15 @@ static void cleanup_subject(struct strbuf *subject)
strbuf_remove(subject, 0, 1);
continue;
case '[':
+ /* If there's a [...] enclosed prefix, always remove
+ it when it starts with "PATCH". If it does not
+ start with PATCH, remove the bracketed quantity
+ only as long as that removes no more than 2/3 of
+ the length. */
if ((pos = strchr(subject->buf, ']'))) {
remove = pos - subject->buf;
- if (remove <= (subject->len - remove) * 2) {
+ if (remove <= (subject->len - remove) * 2
+ || !prefixcmp (subject->buf + 1, "PATCH")) {
strbuf_remove(subject, 0, remove + 1);
continue;
}
@@ -265,7 +271,7 @@ static void cleanup_space(struct strbuf *sb)
}
static void decode_header(struct strbuf *line);
-static const char *header[MAX_HDR_PARSED] = {
+static const char *const header[MAX_HDR_PARSED] = {
"From","Subject","Date",
};
diff --git a/t/t5100-mailinfo.sh b/t/t5100-mailinfo.sh
index ebc36c1..86fb116 100755
--- a/t/t5100-mailinfo.sh
+++ b/t/t5100-mailinfo.sh
@@ -89,4 +89,13 @@ test_expect_success 'mailinfo on from header without name works' '
'
+test_expect_success 'mailinfo strips [PATCH... even on very short Subject' '
+
+ printf "Subject: [PATCH 1/1] ..\n" > in &&
+ printf "Subject: ..\n\n" > expect &&
+ git mailinfo /dev/null /dev/null < in > out &&
+ test_cmp expect out
+
+'
+
test_done
--
1.6.6.rc0.236.ge0b94
^ permalink raw reply related
* Re: Re: Android needs repo, Chrome needs gclient. Neither work. What does that say about git?
From: Bob Hazard @ 2009-11-24 11:29 UTC (permalink / raw)
To: adrian.alexander.may; +Cc: tytso, git, chromium-discuss
In-Reply-To: <65e170e70911231948l3b032dbeu7c99b65ce3ec97ff@mail.gmail.com>
Git's raison d'etre was to make merging cheaper. You are encouraged
to make as many local branches as you want to experiment on features
"if a longer experiment that I have committed several stages of turns
out to be a
blind alley, I'd like to go back a few steps on main, declare
everything after that to be a side branch that I'll probably never use
again, and continue on main with my next attempt. Is that possible?"
Yes.
This google tech talk by Randal Schwartz is a little old but it might help
http://www.youtube.com/watch?v=8dhZ9BXQgc4
2009/11/24 Adrian May <adrian.alexander.may@gmail.com>:
>> If you don't have bolt-on scripts, and you move that into the the core
>> SCM, then you force *all* projects to use whatever workflow was
>> decided as being the One True Way of doing things as seen by the SCM
>> designer. So the question is whether the SCM *should* regiment all
>> projects into following the SCM's designers idea of the One True
>> Workflow.
>
> Of course I'd want the workflow configurable by whoever controls the
> main repository. I couldn't possibly suggest that all git projects
> need the same workflow. The number of developers can vary by five
> orders of magnitude - that calls for different workflow models.
>
>> Git's approach is to say that it will be fairly flexible about
>> dictating workflow --- who pushs to whom; whether there is a single
>> "star" repository topology, or something that is more flexible, etc.
>> You seem to hate this flexibility, because it makes life harder until
>> you set up these bolt-on scripts. But that's what many of us like
>> about git; that it doesn't force us (the project lead) into a single
>> way of doing things.
>
> Leaving aside topology, I suppose we can agree that the subject
> divides into two aspects: offering the developer some optional tools,
> and asserting control over what gets commited to the official repo.
> Perhaps we can also agree that the former belongs under the control of
> the developer and the latter should be in the PM's hands. You seem to
> have opinions about which of these two aspects is more or less
> important, and to what extent git suffices, but I don't. I assume that
> the project manager has his own opinions about both aspects and I'm
> observing two big projects that independantly have augmented git's
> features with their own scripts. Their docs talk about both aspects,
> especially repo's, but they are entirely implemented in
> developer-overridable scripts. So any repo functions to do with the
> second aspect are either features that git needs to grow, or bits of
> the git manual that the repo designer didn't read. I'd kinda like to
> know which.
>
> Returning to topology, I think that also divides up similarly. The PM
> can't forbid you and me from casually swapping diffs back and forth,
> but he can dictate who we are supposed to submit our final candidate
> to for review. The very existence of a PM, who controls a subset of
> the repositories in the world, already implies a star topology, and I
> think pretty much everybody is using distributed source control in
> this way, at least when it comes down to *controlling* anything.
> People may also be causally bouncing diffs around, but that's not
> control, it's communication. I've got a one-man project on github
> which I edit from two locations, and even on that scale I find myself
> working star-fashion because either computer might have junk
> experiments in progress, but I only push to github if it's meaningful
> and tidy.
>
> That reminds me of a slightly different question: if a longer
> experiment that I have committed several stages of turns out to be a
> blind alley, I'd like to go back a few steps on main, declare
> everything after that to be a side branch that I'll probably never use
> again, and continue on main with my next attempt. Is that possible? I
> know that I can just start a new branch from the before the bad
> experiment, but if that happens a lot, the name of my current main
> branch would be changing all the time, and I think that's bad. I
> suspect what I want is possible, but I'm not sure how to do it.
>
>> As far as my wanting to impose a particular regimen on my project's
>> developers, I've never been a big fan of the Bondage and Discpline
>> school of software engineering. They can use whatever workflow they
>> like; they just have to deliver patches that are clean. If they are,
>> I'll pull from their repository. If they aren't, I won't.
>
> Repo talks a lot about automating the workflow that leads to precisely
> that decision. They evidently want something more evolved than
> somebody simply having a look at the code. I'm not sure what they
> want, but I'm pretty sure it's none of the developer's business.
>
> Adrian.
>
> --
> Chromium Discussion mailing list: chromium-discuss@googlegroups.com
> View archives, change email options, or unsubscribe:
> http://groups.google.com/group/chromium-discuss
--
Chromium Discussion mailing list: chromium-discuss@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-discuss
^ permalink raw reply
* Re: [PATCH 0/2] Add support for IPv6 on MinGW
From: Martin Storsjö @ 2009-11-24 11:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy6lwrb5p.fsf@alter.siamese.dyndns.org>
On Mon, 23 Nov 2009, Junio C Hamano wrote:
> I am aware of the exchange between you and J6t on msysgit@googlegroups
> where he suggested you to send them here. Giving better visibility to
> these patches for public review is good.
>
> But you didn't have to Cc: me; in Windows API issues I have no clue so I
> won't be a good reviewer. I do not even compile git on Windows myself,
> let alone testing nor using.
Ah, sorry for notifying you prematurely there.
> As hinted by J6t, he will be saying Ack or something else, so I'll act on
> these patches when it happens.
And thanks for handling this!
// Martin
^ permalink raw reply
* git init --bare --shared=group
From: Eric Schaefer @ 2009-11-24 13:05 UTC (permalink / raw)
To: Git Mailing List
Hello List,
according to 'git help init' would --shared=group "Make the repository
group-writable".
I extracted a bare repo out of my local repo and scp'ed it to the
server. There I did a 'git init --bare --shared=group'. It created the
branches dir (there were no branches yet) and the config file and set
the correct permissions. But it did not do so with the existsing files
and dirs. Is it suffient to 'chmod -R g+ws .' or is there anything
else to do to make the repo writeable for my group?
Thanks,
Eric
^ permalink raw reply
* Re: git init --bare --shared=group
From: Johannes Schindelin @ 2009-11-24 13:25 UTC (permalink / raw)
To: Eric Schaefer; +Cc: Git Mailing List
In-Reply-To: <34f8975d0911240505k4727fef2n8ef0efd3533aef1e@mail.gmail.com>
Hi,
On Tue, 24 Nov 2009, Eric Schaefer wrote:
> according to 'git help init' would --shared=group "Make the repository
> group-writable".
> I extracted a bare repo out of my local repo and scp'ed it to the
> server. There I did a 'git init --bare --shared=group'. It created the
> branches dir (there were no branches yet) and the config file and set
> the correct permissions. But it did not do so with the existsing files
> and dirs. Is it suffient to 'chmod -R g+ws .' or is there anything
> else to do to make the repo writeable for my group?
That should be enough, if all files and directories belong to the correct
group. Otherwise, you should 'chown -R .group .', too.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] shortlog: respect commit encoding
From: Uwe Kleine-König @ 2009-11-24 15:12 UTC (permalink / raw)
To: git; +Cc: Jiri Kosina
In-Reply-To: <20091111141342.GA1849@pengutronix.de>
Before this change the author was taken from the raw commit without
reencoding.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Cc: Jiri Kosina <jkosina@suse.cz>
---
builtin-shortlog.c | 25 +++++++++++++++----------
t/t4201-shortlog.sh | 24 ++++++++++++++++++++++++
2 files changed, 39 insertions(+), 10 deletions(-)
diff --git a/builtin-shortlog.c b/builtin-shortlog.c
index 8aa63c7..050bda8 100644
--- a/builtin-shortlog.c
+++ b/builtin-shortlog.c
@@ -139,14 +139,19 @@ static void read_from_stdin(struct shortlog *log)
void shortlog_add_commit(struct shortlog *log, struct commit *commit)
{
const char *author = NULL, *buffer;
+ struct strbuf buf = STRBUF_INIT;
+ struct strbuf ufbuf = STRBUF_INIT;
+ struct pretty_print_context ctx = {0};
- buffer = commit->buffer;
+ pretty_print_commit(CMIT_FMT_RAW, commit, &buf, &ctx);
+
+ buffer = buf.buf;
while (*buffer && *buffer != '\n') {
const char *eol = strchr(buffer, '\n');
- if (eol == NULL)
+ if (eol == NULL) {
eol = buffer + strlen(buffer);
- else
+ } else
eol++;
if (!prefixcmp(buffer, "author "))
@@ -157,20 +162,20 @@ void shortlog_add_commit(struct shortlog *log, struct commit *commit)
die("Missing author: %s",
sha1_to_hex(commit->object.sha1));
if (log->user_format) {
- struct strbuf buf = STRBUF_INIT;
struct pretty_print_context ctx = {0};
ctx.abbrev = DEFAULT_ABBREV;
ctx.subject = "";
ctx.after_subject = "";
ctx.date_mode = DATE_NORMAL;
- pretty_print_commit(CMIT_FMT_USERFORMAT, commit, &buf, &ctx);
- insert_one_record(log, author, buf.buf);
- strbuf_release(&buf);
- return;
- }
- if (*buffer)
+ pretty_print_commit(CMIT_FMT_USERFORMAT, commit, &ufbuf, &ctx);
+ buffer = ufbuf.buf;
+
+ } else if (*buffer)
buffer++;
+
insert_one_record(log, author, !*buffer ? "<none>" : buffer);
+ strbuf_release(&ufbuf);
+ strbuf_release(&buf);
}
static void get_from_rev(struct rev_info *rev, struct shortlog *log)
diff --git a/t/t4201-shortlog.sh b/t/t4201-shortlog.sh
index 405b971..118204b 100755
--- a/t/t4201-shortlog.sh
+++ b/t/t4201-shortlog.sh
@@ -51,5 +51,29 @@ git log HEAD > log
GIT_DIR=non-existing git shortlog -w < log > out
test_expect_success 'shortlog from non-git directory' 'test_cmp expect out'
+iconvfromutf8toiso885915() {
+ printf "%s" "$@" | iconv -f UTF-8 -t ISO-8859-15
+}
+
+git reset --hard "$commit"
+git config --unset i18n.commitencoding
+echo 2 > a1
+git commit --quiet -m "set a1 to 2 and some non-ASCII chars: Äßø" --author="Jöhännës \"Dschö\" Schindëlin <Johannes.Schindelin@gmx.de>" a1
+
+git config i18n.commitencoding "ISO-8859-15"
+echo 3 > a1
+git commit --quiet -m "$(iconvfromutf8toiso885915 "set a1 to 3 and some non-ASCII chars: áæï")" --author="$(iconvfromutf8toiso885915 "Jöhännës \"Dschö\" Schindëlin <Johannes.Schindelin@gmx.de>")" a1
+git config --unset i18n.commitencoding
+
+git shortlog HEAD~2.. > out
+
+cat > expect << EOF
+Jöhännës "Dschö" Schindëlin (2):
+ set a1 to 2 and some non-ASCII chars: Äßø
+ set a1 to 3 and some non-ASCII chars: áæï
+
+EOF
+
+test_expect_success 'shortlog encoding' 'test_cmp expect out'
test_done
--
1.6.5.3
^ permalink raw reply related
* more problems with commit encoding [Was: [PATCH] shortlog: respect commit encoding]
From: Uwe Kleine-König @ 2009-11-24 16:08 UTC (permalink / raw)
To: git; +Cc: Jiri Kosina
In-Reply-To: <1259075555-7831-1-git-send-email-u.kleine-koenig@pengutronix.de>
Hello,
On Tue, Nov 24, 2009 at 04:12:35PM +0100, Uwe Kleine-König wrote:
> Before this change the author was taken from the raw commit without
> reencoding.
while at it, userformats have the same problem:
linux-2.6$ for rev in b71a8eb bc9be01; do git show --format=%an $rev | head -n1; git show $rev | grep Auth; done
Uwe Kleine-K�nig
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Uwe Kleine-König
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
That is, git show correctly reencodes its output for b71a8eb, but only
without --format=...
(The patches above are in linux-next.)
And now take this (assuming locale and commitencoding are utf-8):
git init
git config user.name 'Jöhännës Dschö'
echo spam > ham
git add ham
git commit -m 'initial commit'
git branch branch
echo more spam > ham
git add ham
git commit -m "Commitlog matching '\nencoding:'
encoding: latin1
"
git checkout branch
echo much more spam > ham
git add ham
git commit -C master
git show | grep Author:
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* insecurity in verify-tag?
From: David Roundy @ 2009-11-24 16:56 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 2070 bytes --]
I've just been looking at the code and I see what looks like a (minor)
security hole in the verify-tag feature. In particular, the tag
verification code doesn't check that the tag is signed by the same
user that created the tag. To be fair, gpg does output the identity
of the key that created the signature as well as the key used to
create the signature, so an astute user could detect that some
shenanigans is going on.
An attack would simply require getting one's own public key into the
keyring of a user. This probably wouldn't be very easy at the moment,
but if people were to actually use encrypted email (and if they set
their mail agents to download public keys), it might require no more
then sending a signed email to a mailing list.
Of course, you'd also somehow have to trick them into pulling (or
cloning) your corrupt tag, which probably requires compromising a
server (or mirror) somewhere. But of course, the whole point of
signing tags is to eliminate precisely this danger.
What should be done about this? First, there ought to be a feature to
limit git verify-tag to use a specific keyring. Maybe there is an
environment variable, and it's just not documented in the man page?
It would also seem like a good idea to at a minimum check that the
name/email associated with the signature is the same as that of the
tagger. This doesn't gain you *too* much, since an attacker can
always create his own key with any name and email he likes, but at
least it means that users could feel safe adding keys to their public
keyring, as long as those keys have reasonable names/emails associated
with them, and as long as they run git show on a tag before trusting
that that tag came from a particular person. i.e. it seems reasonable
for me to expect that if I run:
$ git show v1.0
tag v1.0
Tagger: Linus Torvalds ...
...
[user carefully reads the Tagger line...]
$ git verify-tag v1.0 && make
That I won't be running make on a repository that wasn't signed by a
key that at least *claims* to belong to Linus Torvalds.
Thoughts?
--
David Roundy
[-- Attachment #2: tagtest.txt --]
[-- Type: text/plain, Size: 1496 bytes --]
mkdir temp
cd temp
git init
Initialized empty Git repository in /tmp/temp/.git/
date > foo
git add foo
export GIT_AUTHOR_NAME="Someone else"
export GIT_AUTHOR_EMAIL="notme@example.com"
export GIT_COMMITTER_NAME="Linus Torvalds"
export GIT_COMMITTER_EMAIL="linus@example.com"
git commit -m 'hello world'
Created initial commit dc3b7e9: hello world
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 foo
git tag -u droundy -m foo v1.0
gpg: Invalid passphrase; please try again ...
gpg: Invalid passphrase; please try again ...
git verify-tag v1.0
gpg: Signature made Tue 24 Nov 2009 11:41:49 AM EST using DSA key ID D3D5BCEC
gpg: Good signature from "David Roundy <roundyd@physics.oregonstate.edu>"
gpg: aka "David Roundy <droundy@darcs.net>"
gpg: aka "David Roundy <droundy@abridgegame.org>"
gpg: aka "David Roundy <daveroundy@gmail.com>"
git show v1.0
tag v1.0
Tagger: Linus Torvalds <linus@example.com>
Date: Tue Nov 24 11:41:49 2009 -0500
foo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEABECAAYFAksMDM0ACgkQQ6uZI9PVvOyXFQCgoc4UYfNFYzVH4HduLdh9VUc/
NSkAn05yr/ARnWGUC8I/OmjhZJEjG5Oa
=ro48
-----END PGP SIGNATURE-----
commit dc3b7e9f8f5c49bdfe8816abdb4bb392c30e3ef5
Author: Someone else <notme@example.com>
Date: Tue Nov 24 11:41:49 2009 -0500
hello world
diff --git a/foo b/foo
new file mode 100644
index 0000000..c1857fa
--- /dev/null
+++ b/foo
@@ -0,0 +1 @@
+Tue Nov 24 11:41:49 EST 2009
^ permalink raw reply related
* Re: [PATCH] t/gitweb-lib: Split HTTP response with non-GNU sed
From: Jakub Narebski @ 2009-11-24 16:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Brian Gernhardt, Git List
In-Reply-To: <7vocmtyu3v.fsf@alter.siamese.dyndns.org>
On Mon, 23 Nov 2009, Junio C Hamano wrote:
> Brian Gernhardt <brian@gernhardtsoftware.com> writes:
>
> > Recognizing \r in a regex is something GNU sed will do, but other sed
> > implementation's won't. (Found with BSD sed on OS X.) So use a
> > literal carriage return instead.
[...]
> > diff --git a/t/gitweb-lib.sh b/t/gitweb-lib.sh
> > index 32b841d..35dda58 100644
> > --- a/t/gitweb-lib.sh
> > +++ b/t/gitweb-lib.sh
> > @@ -52,8 +52,8 @@ gitweb_run () {
> > rm -f gitweb.log &&
> > perl -- "$SCRIPT_NAME" \
> > >gitweb.output 2>gitweb.log &&
> > - sed -e '/^\r$/q' <gitweb.output >gitweb.headers &&
> > - sed -e '1,/^\r$/d' <gitweb.output >gitweb.body &&
> > + sed -e '/^
> > $/q' <gitweb.output >gitweb.headers &&
> > + sed -e '1,/^
> > $/d' <gitweb.output >gitweb.body &&
> > if grep '^[[]' gitweb.log >/dev/null 2>&1; then false; else
> > true; fi
> > # gitweb.log is left for debugging
If we were to do it this way, I would prefer to set and then use
'cr' or 'crlf' variable (in sed expression).
>
> I'd actually prefer not having to deal with this issue. How about doing
> something like this instead?
>
> t/gitweb-lib.sh | 14 ++++++++++++--
> 1 files changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/t/gitweb-lib.sh b/t/gitweb-lib.sh
> index 32b841d..3121950 100644
> --- a/t/gitweb-lib.sh
> +++ b/t/gitweb-lib.sh
> @@ -52,8 +52,18 @@ gitweb_run () {
> rm -f gitweb.log &&
> perl -- "$SCRIPT_NAME" \
> >gitweb.output 2>gitweb.log &&
> - sed -e '/^\r$/q' <gitweb.output >gitweb.headers &&
> - sed -e '1,/^\r$/d' <gitweb.output >gitweb.body &&
> + perl -w -e '
"perl", or "$PERL", or "$PERL_PATH"?
> + open O, ">gitweb.headers";
Well, modern Perl would use here
+ open my $fh, ">", "gitweb.headers";
But it is not that important here.
> + while (<>) {
> + print O;
> + last if (/^\r$/ || /^$/);
> + }
> + open O, ">gitweb.body";
> + while (<>) {
> + print O;
> + }
> + close O;
> + ' gitweb.output &&
> if grep '^[[]' gitweb.log >/dev/null 2>&1; then false; else true; fi
>
> # gitweb.log is left for debugging
>
This is a good solution. We test Perl script anyway (so Perl is required
for running this test), and this way we can do this portably and in one
pass (one fork).
--
Jakub Narebski
Poland
^ permalink raw reply
* Git over cvs
From: Michael J Gruber @ 2009-11-24 17:07 UTC (permalink / raw)
To: Git Mailing List
Hi there,
I got so annoyed by (my own incompetence using) cvs on mozdev that I got
myself to use git cvsimport/cvsexportcommit now, just shortly before it
gets obsoleted by the new shiny remote helpers, and knowing how many
failing tests we have for it now.
Setting up a convenient roundtrip with minimal exposure to cvs required
collecting some scattered info. I thought this makes a good first blog
entry (the one after the zeroth) for reference, so in case anyone is
interested:
http://grubix.blogspot.com/2009/11/git-over-cvs.html
I guess it does require some acquaintance with Git, that's intentional.
(In short it uses the combined work tree, -W approach.)
Cheers,
Michael
P.S.: There's AdSense on there. I assume you block it anyway using
NoScript, AdBlock etc. if you don't like it.
^ permalink raw reply
* git tag listing order
From: Peter van der Does @ 2009-11-24 15:56 UTC (permalink / raw)
To: git
I'm using git 1.6.5.3 on Ubuntu and was wondering if there is a way to
list tags in order of when they were added to the tree, instead of
alphabetical?
--
Peter van der Does
GPG key: E77E8E98
Twitter: @petervanderdoes
git Ubuntu Packages:
http://blog.avirtualhome.com/git-packages-for-ubuntu/
^ permalink raw reply
* Re: [PATCH] send-email: new 'add-envelope' option
From: Felipe Contreras @ 2009-11-24 17:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7v7htice04.fsf@alter.siamese.dyndns.org>
On Mon, Nov 23, 2009 at 1:54 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>> a) --add-envelope: add the sender envelope, by default it would be the
>> 'from' address, but could be overridden by --envelope-sender.
>
> I do not think the latter half of this description makes much sense, as
> the existing --envelope-sender=<this-address> alone already says "add this
> envelope sender".
--envelope-sender=foo@bar.com would imply --add-envelope.
> It is unfortunate that we cannot sanely have an option that takes an
> optional string argument from the command line. Ideally, if we can
> specify --envelope-sender without any argument, we could make it to mean
> "pretend as if the 'from' address is given to this option", but that would
> make the command line pasing ambiguous, so we would need an extra option
> like this one. "--envelope-sender=from" might be a more intuitive way to
> say this, though.
I agree, but --envelope-sender=from looks a bit strange to me.
>> b) --envelope-sender="" or "auto": this would require minimal changes
>> but looks a bita strange.
>
> An explicit empty string does look very strange, but I do not think a
> magic word like "auto" (or "from") that cannot sanely be your envelope
> sender address is a bad idea.
I think "auto" is the least worst option right now.
>> Any thoughts?
>
> It is much easier to work on the configuration front, by the way, and I
> expect people who regularly interact with multiple projects to appreciate
> this feature would configure their send-email once and forget about it, so
> the command line clunkiness might not be such a big issue.
>
> A user who works with more than one projects with different identity known
> to each project would use $HOME/.gitconfig and send-email configuration
> identity feature to set "sendemail.<identity>.from" and friends in there,
> while setting sendemail.identity configuration in .git/config for each
> project, so being able to say "use whatever 'from' as the envelope sender"
> once in $HOME/.gitconfig would be convenient.
>
> So I could have in $HOME/.gitconfig:
>
> [sendemail]
> ; used as a boolean to say "use from"
> envelopesender
> [sendemail.git]
> from = Junio C Hamano <gitster@pobox.com>
> to = git mailing list <git@vger.kernel.org>
> [sendemail.frotz]
> from = Junio C Hamano <frotzster@example.xz>
> to = frotz mailing list <frotz@example.xz>
>
> and then in my {git,frotz}.git/.git/config would have
>
> [sendemail] [sendemail]
> identity = git identity = frotz
>
> respectively. Without your patch, in $HOME/.gitconfig, I wouldn't have
> the global sendemail.envelopesender but have separate individual
> configuration variables sendemail.{git,frotz}.envelopesender defined.
I also thought about having an identity (profile) for sendmail; it
would be very useful to specify the smtp server, aliases file, and
from address that multiple repositories can share and can be easily
changed (working for my company vs working for myself).
However, even in this case I would like to have a global option to add
the sender automatically from the 'from' address.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH RFC] git-send-email --expand-aliases
From: Alex Chiang @ 2009-11-24 18:46 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Karl Wiberg, Junio C Hamano, git
In-Reply-To: <b0943d9e0911240243m13730f0bw34f2f18cf41f9079@mail.gmail.com>
* Catalin Marinas <catalin.marinas@gmail.com>:
> 2009/11/24 Karl Wiberg <kha@treskal.com>:
> > On Tue, Nov 24, 2009 at 1:45 AM, Alex Chiang <achiang@hp.com> wrote:
> >> * Junio C Hamano <gitster@pobox.com>:
> >> > I imagine the internal implementation of stg mail would work
> >> > something like:
> >> >
> >> > prepare messages to send out
> >> > call git-send-email and have it send them
> >> >
> >> > What am I missing?
> >>
> >> Your suggestion is much better. I'll take a closer look at StGit and
> >> see how feasible it is.
> >>
> >> Unless Catalin has strong objections?
> >
> > I think that sounds like a splendid idea. It would be interesting to
> > see just how thin a wrapper around git send-email (and format-patch)
> > stg mail could become, without sacrificing features anyone actually
> > uses. The main complication could be stg mail's templates.
> >
> > Catalin, how wedded are you to those? ;-)
>
> Historically, I think "stg mail" was implemented before git-send-email
> existed. It was also a good way to check who's using stgit for sending
> patches :-) (the message-id).
Heh, I like looking at that too. ;)
> If there are no other users of the stg mail templates, I'm happy to
> let them go. Otherwise, we can replace the sendmail with
> git-send-email in stgit.
>
> It seems that git-format-patch and git-send-email have all the
> features stgit has. We would need to keep some of the interactive
> options like --edit-cover and --edit-patches since we use
> git-format-patch and git-send-email in one go.
So, is this something you (or Karl) plan on doing? Or should I
take a crack at it?
I don't mind doing the work, but it will definitely take me
longer than it would take you.
All I was doing was trying to get stg mail to understand my mutt
aliases. ;)
Thanks,
/ac
^ permalink raw reply
* Re: git tag listing order
From: Jeff King @ 2009-11-24 19:00 UTC (permalink / raw)
To: Peter van der Does; +Cc: git
In-Reply-To: <20091124105609.0980e796@montecarlo.grandprix.int>
On Tue, Nov 24, 2009 at 10:56:09AM -0500, Peter van der Does wrote:
> I'm using git 1.6.5.3 on Ubuntu and was wondering if there is a way to
> list tags in order of when they were added to the tree, instead of
> alphabetical?
You can use for-each-ref with its sort option:
git for-each-ref --sort=taggerdate --format='%(refname:short)' refs/tags
Though note that unannotated tags will have no taggerdate, and will all
sort to the front of the list. To exclude them, I think you'd have to
use a special format to grep and sort yourself. Something like:
git for-each-ref \
--format='%(taggerdate:iso8601) %(refname:short)' refs/tags |
grep -v '^ ' |
sort |
cut -d' ' -f4-
-Peff
^ permalink raw reply
* Private remote repo setup
From: Derek D @ 2009-11-24 19:04 UTC (permalink / raw)
To: git
Hi all, I am new to Git and I am getting quite frustrated with setting a repo
on my server so that people with Windows machines can ssh to it and contribute.
This is what I am doing:
On the server:
#git --bare init
Initialized empty Git repository in /opt/apps/git-test/
In tortoiseGIT I go to git clone, provide correct url:
ssh://user@domain/opt/apps/git-test/
tortoiseGIT asks me for a password, I provide it, it's correct, the repository
gets created on the local machine and...
fatal: '/opt/apps/git-test': unable to chdir or not a git archive
Initialized empty Git repository in C:/path/.git/
fatal: The remote end hung up unexpectedly
Failed
What happened there?
^ permalink raw reply
* Re: [PATCH RFC] git-send-email --expand-aliases
From: Karl Wiberg @ 2009-11-24 19:08 UTC (permalink / raw)
To: Alex Chiang; +Cc: Catalin Marinas, Junio C Hamano, git
In-Reply-To: <20091124184629.GB27418@ldl.fc.hp.com>
On Tue, Nov 24, 2009 at 7:46 PM, Alex Chiang <achiang@hp.com> wrote:
> * Catalin Marinas <catalin.marinas@gmail.com>:
>
> > If there are no other users of the stg mail templates, I'm happy
> > to let them go. Otherwise, we can replace the sendmail with
> > git-send-email in stgit.
> >
> > It seems that git-format-patch and git-send-email have all the
> > features stgit has. We would need to keep some of the interactive
> > options like --edit-cover and --edit-patches since we use
> > git-format-patch and git-send-email in one go.
>
> So, is this something you (or Karl) plan on doing? Or should I take
> a crack at it?
I wasn't planning to do it, at least. I haven't had much time for
StGit lately, but when I do there are other things I was planning to
fix before this.
If you feel like trying, please go ahead. I'll be happy to assist.
> I don't mind doing the work, but it will definitely take me longer
> than it would take you.
>
> All I was doing was trying to get stg mail to understand my mutt
> aliases. ;)
Yeah, sorry about that. ;-)
Seriously, though, doing just what you started out wanting to do would
be fine too. If you decide to do the larger project, it shouldn't be
because we made you feel you had to.
--
Karl Wiberg, kha@treskal.com
subrabbit.wordpress.com
www.treskal.com/kalle
^ 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