* Re: [RFC 0/2] Git-over-TLS (gits://) client side support
From: Avery Pennarun @ 2010-01-13 19:30 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: Andreas Krey, Nguyen Thai Ngoc Duy, git
In-Reply-To: <20100113191802.GA8110@Knoppix>
On Wed, Jan 13, 2010 at 2:18 PM, Ilari Liusvaara
<ilari.liusvaara@elisanet.fi> wrote:
>> Please consider my objections revoked, other than the claim that
>> it could be done with stunnel, however ugly that would be.
>
> Only if you don't care about complexity introducing PKI would bring
> (yes, I read those manuals).
I think you're overstating the situation a bit here. You can use
X.509 certificates without setting up a full PKI. Basically, an X.509
cert is just a public key with some extra crud thrown into the data
file. You could validate it using a PKI, but you could also validate
it by checking the verbatim public key just like ssh does. It's not
elegant, but it works, and it's a worldwide standard.
(I don't know if stunnel does this type of validation... but *I've*
done this with the openssl libraries, so I know it can be done.)
>> Of course, you have another problem in that case...also I'd personally
>> like to rely on ssl client certificates when using https.
>
> And how many (relative) use client ceritificates with SSL? Keypairs with SSH?
> Why you think this is?
At least hundreds of thousands of people, including non-technical
people, use X.509 client certificates and SSL in various big
industries with high security requirements. That's why every major
web browser supports them. In contrast, ssh is only ever used by
techies, and there are fewer of those. Of course, as techies our
informal observations might lead us to believe otherwise.
Furthermore, how many people who really want ssh-style keypairs (and
thus refuse to use X.509 and PKI) can't just use ssh as their git
transport? I don't actually understand what the goal is here.
Have fun,
Avery
^ permalink raw reply
* Re: [RFC 0/2] Git-over-TLS (gits://) client side support
From: Andreas Krey @ 2010-01-13 19:40 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: Nguyen Thai Ngoc Duy, git
In-Reply-To: <20100113191802.GA8110@Knoppix>
On Wed, 13 Jan 2010 21:18:02 +0000, Ilari Liusvaara wrote:
...
> That feature is grossly underdocumented (and also nonportable). Unix(7)
> should document it, except that it doesn't for me (it documents that
> SO_PASSCRED takes a boolean, except that what the server implementation
> passes is something completely different).
Actually, I meant how you plan to map credentials (however obtained)
into allowed actions inside git-daemon (or the hooks).
...
> And how many (relative) use client ceritificates with SSL? Keypairs with SSH?
> Why you think this is?
Because ssh is much more popular than ssl client auth. Obtaining client
certificates isn't much more complicated than getting an ssh account,
once you have scripts for the stuff ready.
But I wonder: When you want keypair auth, why not just use ssh?
I didn't quite understand the use case yet, it seems. With ssh
I have all the infrastructure like ssh-agent in place already;
with gits: (any kind of) it will be asked for sooner or later.
Andreas
^ permalink raw reply
* Re: [PATCH 2/3] strbuf: add strbuf_percentquote_buf
From: Junio C Hamano @ 2010-01-13 19:47 UTC (permalink / raw)
To: Jeff King; +Cc: Adam Megacz, git
In-Reply-To: <20100113170636.GA21318@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
>> (2) perhaps have assert(dst != src). The loop won't terminate when
>> called with src == dst, I think.
>
> Oops again. I think it is sensible to protect against this. I thought
> about trying to make it magically work in-place, but I don't think there
> is a simple way to do so.
As I said, I don't think appending p-quoted version of itself to a string
makes much sense, but I don't think in-place is too difficult.
strbuf_addbuf_pquote(*dst, *src)
{
int len = src->len, i;
for (i = 0; i < len; i++) {
if (src->buf[i] == '%')
strbuf_addch(dst, '%');
strbuf_addch(dst, src->buf[i]);
}
}
>> --- a/strbuf.h
>> +++ b/strbuf.h
>> @@ -105,7 +105,13 @@ static inline void strbuf_addstr(struct strbuf *sb, const char *s) {
>> strbuf_add(sb, s, strlen(s));
>> }
>> static inline void strbuf_addbuf(struct strbuf *sb, const struct strbuf *sb2) {
>> - strbuf_add(sb, sb2->buf, sb2->len);
>> + char *buf = sb2->buf;
>> + int len = sb2->len;
>> + if (sb->buf == sb2->buf) {
>> + strbuf_grow(sb, len);
>> + buf = sb->buf;
>> + }
>> + strbuf_add(sb, buf, len);
>> }
>
> Shouldn't this be "if (sb == sb2)"? Two strbufs in the initial state
> will point to the same strbuf_slopbuf, but obviously growing sb will not
> impact sb2. Though that would simply provoke a false positive, which I
> don't think has any negative consequences.
Ok, that is a good catch. And two strbufs that share the same allocated
string is a user error
> Also, since reallocating sb will reallocate sb2, can't you just write it
> safely like this:
>
> strbuf_grow(sb, sb2->len);
> strbuf_add(sb, sb2->buf, sb2->len);
I didn't want to worry about a semi-clever (read: broken) compilers doing
semi-clever things assuming sb and sb2 do not alias, but I agree that your
approach is much simpler.
Thanks.
^ permalink raw reply
* Re: default behaviour for `gitmerge` (no arguments)
From: Junio C Hamano @ 2010-01-13 19:48 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, Gareth Adams, git
In-Reply-To: <alpine.DEB.1.00.1001131202510.3043@intel-tinevez-2-302>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> So you meant to say that substitute_branch_name() calls
> interpret_branch_name(), so the change should be in the latter. (This is
> supposed to be the summary of your 4 paragraphs.)
Not quite. What I was asking was:
*PROVIDED* *IF* you wanted to keep the same semantics between
them, then you would have patched i-b-n, but you didn't. Was there
a reason callers of s-b-n should know about @{u} but callers of i-b-n
shouldn't?
Expected answer was either:
(a) Codepath X that uses i-b-n shouldn't interpret @{upstream} as
a symbolic name given by the user, but it should treat it as a
mere SHA-1 expression instead for *this and that* reason.
Otherwise we will see *this* breakage when the user does
*that*. That is why i-b-n doesn't know about the new syntax;
or
(b) It was a thinko; all codepaths that use i-b-n should know the
new syntax as they _are_ interested in learning the symbolic
name when the user gives @{upstream}.
^ permalink raw reply
* Re: [PATCH] grep: -L should show empty files
From: Junio C Hamano @ 2010-01-13 19:48 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: git, Linus Torvalds, Miles Bader, Jeff King, Nguyen Thai Ngoc Duy
In-Reply-To: <fabb9a1e1001130804s4716587l57d56884b5d0d068@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> I'm not that familiar with the code, but wouldn't it be possible to
> keep the early abort, but make it dependent on not using the '-L'
> flag?
Anything codable is possible to code, but my point was I don't think such
an optimization to avoid reading empty files is worth the time to write
and maintain extra code necessary for it.
^ permalink raw reply
* Re: [PATCH 3/3] commit: show interesting ident information in summary
From: Junio C Hamano @ 2010-01-13 19:48 UTC (permalink / raw)
To: Jeff King; +Cc: Adam Megacz, git
In-Reply-To: <20100113173050.GB21318@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Just adding the "Committer:" reminder is slightly annoying (though
> perhaps some people will even like it). Adding a big advice message on
> every commit is going to be annoying to everyone who sees it, and is
> really crossing the line of "we don't really support implicit identities
> anymore", since anyone seeing it is going to want to fix it.
>
> I know there has been some discussion of that area in the last few
> months, but I admit I didn't pay any attention. Is that the direction we
> want to move in? I don't have a particular problem with it, but I want
> to point out that if there _are_ people who really like the implicit
> ident feature, we are effectively killing it off for them.
Traditionally, we've only had a minimal sanity check (e.g. to barf when
the name is empty, or something silly like that) and tried to come up with
a reasonable name/email given the available system information.
In olden days, `whoami`@`hostname`, at least on systems that were
competently maintained, gave a reasonable mail address for most people,
but I think it stopped being adequate more than 10 years ago, and it is
not useful anymore to majority of people, especially the ones who work on
Open Source projects as individuals, whose desired public identities are
often tied to their email account at their ISPs or mailbox providers (like
gmail). There is no way for us to guess, when `whoami`@`hostname -f` is
the only thing we can go by without explicit user configuration.
Inside corporate environments, `whoami`@`hostname -f` might still be a
reasonable and usable default, though.
So I think the safest thing to do would be to give a big advice but make
it squelch-able with advice.howToSetYourIdentity or something.
^ permalink raw reply
* Re: Filenames and prefixes in extended diffs
From: Junio C Hamano @ 2010-01-13 19:49 UTC (permalink / raw)
To: Andreas Gruenbacher; +Cc: git
In-Reply-To: <201001131713.05505.agruen@suse.de>
Andreas Gruenbacher <agruen@suse.de> writes:
> Any ideas?
How about studying what "git-apply" does?
^ permalink raw reply
* Re: [PATCH 2/3] strbuf: add strbuf_percentquote_buf
From: Jeff King @ 2010-01-13 19:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Adam Megacz, git
In-Reply-To: <7vwrzln5x5.fsf@alter.siamese.dyndns.org>
On Wed, Jan 13, 2010 at 11:47:18AM -0800, Junio C Hamano wrote:
> As I said, I don't think appending p-quoted version of itself to a string
> makes much sense, but I don't think in-place is too difficult.
>
> strbuf_addbuf_pquote(*dst, *src)
> {
> int len = src->len, i;
> for (i = 0; i < len; i++) {
> if (src->buf[i] == '%')
> strbuf_addch(dst, '%');
> strbuf_addch(dst, src->buf[i]);
Oops, of course. I was still thinking of actually doing a single
in-place conversion, not appending in-place. Of course yours is right.
Can you mark up my patch instead of using the assert?
-Peff
^ permalink raw reply
* Re: [RFC 0/2] Git-over-TLS (gits://) client side support
From: Ilari Liusvaara @ 2010-01-13 20:00 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Nguyen Thai Ngoc Duy, git
In-Reply-To: <32541b131001131111u6bb0de01qe6cc1ecde5119084@mail.gmail.com>
On Wed, Jan 13, 2010 at 02:11:14PM -0500, Avery Pennarun wrote:
> On Wed, Jan 13, 2010 at 8:57 AM, Ilari Liusvaara
> <ilari.liusvaara@elisanet.fi> wrote:
> It sounds to me like you're doing two different things with this patch series:
>
> 1) Adding additional authorization features (assuming the user is
> already authenticated) to git-daemon
>
> 2) Creating a TLS encryption layer with authentication support.
>
> #1 sounds like it could be its own patch series even if you don't have
> #2, and could be reviewed separately.
This series (really only one patch, only split because its large) only
contains client parts, not server ones (not seperately or via patching
git-daemon).
And besides the daemon for gits:// was written from libraries up.
> #2 sounds like it is not even git-specific. You've decided that ssh
> and stunnel don't fit your needs; what makes your solution not a
> general TLS-based authentication layer, like stunnel but with
> different certificate management?
Stunnel seems mainly "tunnel stuff using SSL/TLS" type thing and any
support for auth in it seems afterthought. At least that's what I got
from reading the manuals for it.
> If it's really a general layer,
> maybe it should be distributed separately and git could be taught how
> to use it *or* stunnel (or ssh, as it does now) for its transport
> encryption/authentication.
The way serverside works is quite different from git-daemon. On client
side there are also some virtually inavoidable bidirectional couplings
(breaks layering) between generic and git-specific parts.
Yes, the code is split into two layers, but both layers contain git-
specific details. And the lower layer is low-level transport control code,
that doesn't even know how to configure TLS connection (that is quite
high-level task).
And ssh:// is not git:// tunneled over SSH, the request passing is done
differently.
-Ilari
^ permalink raw reply
* Re: discussion: an option to fail git fetch if a pulled branch tip is not a fast forward of the existing remote tip?
From: Jon Seymour @ 2010-01-13 17:14 UTC (permalink / raw)
To: Thomas Rast; +Cc: Git Mailing List
In-Reply-To: <201001131359.09613.trast@student.ethz.ch>
Thomas,
Ah - thanks for your very helpful response!
jon.
On 13/01/2010, at 23:59, Thomas Rast <trast@student.ethz.ch> wrote:
> Jon Seymour wrote:
> [discussion of a case of branch rewriting, called "backtracking" here]
>> Now clearly the upstream developer should not have backtracked. That
>> said, it would have been nice if I could have easily configured my
>> porcelain to detect the backtracking condition. An option on git
>> fetch
>> that implemented something similar to the git push check would have
>> made this easy to achieve.
>
> This is an instance of a non-fast-foward update, which is indicated by
> the little "+" in git-fetch's output. E.g., fetching git.git a moment
> ago gave me
>
> From git://git.kernel.org/pub/scm/git/git
> fbb9971..8efa5f6 maint -> origin/maint
> c0eb604..054d2fa master -> origin/master
> e295b7f..e84eab0 next -> origin/next
> + 10659b7...6a048fc pu -> origin/pu (forced update)
>
> which means that the 'pu' branch was a non-fast-forward update.
>
> If you do not want to rely on checking the results manually, you can
> edit the remote configuration. Normally, it will look like
>
> [remote "origin"]
> url = git://git.kernel.org/pub/scm/git/git.git
> fetch = +refs/heads/*:refs/remotes/origin/*
>
> Note the "+" in the 'fetch' line, which means "allow non-fast-forward
> updates". Removing the + (leaving the rest intact) results in
>
> From git://git.kernel.org/pub/scm/git/git
> ! [rejected] pu -> origin/pu (non-fast-forward)
>
> You can then manually add lines _with_ the "+" for branches where you
> do want to allow non-ff updates, e.g., for git.git I might say
>
> [remote "origin"]
> url = git://git.kernel.org/pub/scm/git/git.git
> fetch = +refs/heads/pu:refs/remotes/origin/pu
> fetch = refs/heads/*:refs/remotes/origin/*
>
> since only 'pu' will be rewritten regularly. ('next' gets the
> occasional treatment too, so that config would not be very
> futureproof.)
>
> --
> Thomas Rast
> trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [RFC 0/2] Git-over-TLS (gits://) client side support
From: Ilari Liusvaara @ 2010-01-13 20:06 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Andreas Krey, Nguyen Thai Ngoc Duy, git
In-Reply-To: <32541b131001131130i6afae1a1xd3a70e5de5daa5cf@mail.gmail.com>
On Wed, Jan 13, 2010 at 02:30:20PM -0500, Avery Pennarun wrote:
> On Wed, Jan 13, 2010 at 2:18 PM, Ilari Liusvaara
> <ilari.liusvaara@elisanet.fi> wrote:
>
> I think you're overstating the situation a bit here. You can use
> X.509 certificates without setting up a full PKI. Basically, an X.509
> cert is just a public key with some extra crud thrown into the data
> file. You could validate it using a PKI, but you could also validate
> it by checking the verbatim public key just like ssh does. It's not
> elegant, but it works, and it's a worldwide standard.
Grossly overcomplicated standard... ASN.1? And there are other usable
standards that can be used with TLS.
> (I don't know if stunnel does this type of validation... but *I've*
> done this with the openssl libraries, so I know it can be done.)
AFAIK, it doesn't.
> > And how many (relative) use client ceritificates with SSL? Keypairs with SSH?
> > Why you think this is?
>
> At least hundreds of thousands of people, including non-technical
> people, use X.509 client certificates and SSL in various big
> industries with high security requirements.
That is: Epsilon.
> That's why every major web browser supports them.
Supports != is actually usable.
> In contrast, ssh is only ever used by
> techies, and there are fewer of those. Of course, as techies our
> informal observations might lead us to believe otherwise.
Most of those that use git are techies anyway.
> Furthermore, how many people who really want ssh-style keypairs (and
> thus refuse to use X.509 and PKI) can't just use ssh as their git
> transport? I don't actually understand what the goal is here.
As said, I got fed up with failure modes of SSH.
-Ilari
^ permalink raw reply
* Re: [RFC 0/2] Git-over-TLS (gits://) client side support
From: Edward Z. Yang @ 2010-01-13 20:13 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git
In-Reply-To: <1263388786-6880-1-git-send-email-ilari.liusvaara@elisanet.fi>
Excerpts from Ilari Liusvaara's message of Wed Jan 13 08:19:44 -0500 2010:
> Supported authentication mechanisms include passwords, keypairs and on
> some platforms Unix authentication if using unix domain sockets. Server
> is authenticated using keypair (hostkey).
As a Git user, I'd like to say: it's about damn time! :-)
Cheers,
Edward
^ permalink raw reply
* Re: [RFC 0/2] Git-over-TLS (gits://) client side support
From: Avery Pennarun @ 2010-01-13 20:13 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: Andreas Krey, Nguyen Thai Ngoc Duy, git
In-Reply-To: <20100113200629.GA8383@Knoppix>
On Wed, Jan 13, 2010 at 3:06 PM, Ilari Liusvaara
<ilari.liusvaara@elisanet.fi> wrote:
> On Wed, Jan 13, 2010 at 02:30:20PM -0500, Avery Pennarun wrote:
>> That's why every major web browser supports them. [X.509 client-side certificates]
>
> Supports != is actually usable.
Lots of people use it. That was my point. If it weren't important,
web browser makers wouldn't bother putting it in; God knows they leave
out a lot of other stuff that I'd like.
>> Furthermore, how many people who really want ssh-style keypairs (and
>> thus refuse to use X.509 and PKI) can't just use ssh as their git
>> transport? I don't actually understand what the goal is here.
>
> As said, I got fed up with failure modes of SSH.
I think this is the answer that needs clarification. What failure
modes are these? ssh doesn't seem to fail for me. And github.com
seems to be working rather well with a huge number of users and ssh
authentication.
If you're upset at the failure modes of ssh, is it possible to fix ssh
instead of introducing Yet Another Tunneling Protocol?
Have fun,
Avery
^ permalink raw reply
* Re: [PATCH 3/3] commit: show interesting ident information in summary
From: Jeff King @ 2010-01-13 20:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Adam Megacz, git
In-Reply-To: <7vbpgxn5ui.fsf@alter.siamese.dyndns.org>
On Wed, Jan 13, 2010 at 11:48:53AM -0800, Junio C Hamano wrote:
> In olden days, `whoami`@`hostname`, at least on systems that were
> competently maintained, gave a reasonable mail address for most people,
> but I think it stopped being adequate more than 10 years ago, and it is
> not useful anymore to majority of people, especially the ones who work on
> Open Source projects as individuals, whose desired public identities are
> often tied to their email account at their ISPs or mailbox providers (like
> gmail). There is no way for us to guess, when `whoami`@`hostname -f` is
> the only thing we can go by without explicit user configuration.
Even outside of competent maintenance or individuals being served by
ISPs, I think it is really that it is no longer the case that the
machines we get our mail on and the machines we do our work on are less
and less the same. Even as an individual, I can afford a Linux
workstation on my desk _and_ one to serve my mail. But I don't advertise
peff@workstation.peff.net as my email.
Which isn't to say there aren't people in the separate situation, like:
> Inside corporate environments, `whoami`@`hostname -f` might still be a
> reasonable and usable default, though.
>
> So I think the safest thing to do would be to give a big advice but make
> it squelch-able with advice.howToSetYourIdentity or something.
I think that is a good idea. Administrators of competent shared
environments can turn off the advice via /etc/gitconfig if they want,
and everyone else needs to opt into it consciously, which should help
reduce errors. I'm sure there will still be somebody, somewhere, who
complains about having to set the config, but that minority is hopefully
small enough to justify the errors saved by new git users.
Can you apply the patch below to my series as 4/3?
-- >8 --
Subject: [PATCH] commit: allow suppression of implicit identity advice
We now nag the user with a giant warning when their identity
was pulled from the username, hostname, and gecos
information, in case it is not correct. Most users will
suppress this by simply setting up their information
correctly.
However, there may be some users who consciously want to use
that information, because having the value change from host
to host contains useful information. These users can now set
advice.implicitidentity to false to suppress the message.
Signed-off-by: Jeff King <peff@peff.net>
---
Pretty straightforward. The biggest question is whether to suppress the
"Committer: XXX <YYY@ZZZ>" line, too. I kind of think it is useful if
you are intentionally using this feature; by definition if you are using
it intentionally then the information is of some interest to you.
Documentation/config.txt | 4 ++++
advice.c | 2 ++
advice.h | 1 +
builtin-commit.c | 6 ++++--
4 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 9f40955..905076f 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -130,6 +130,10 @@ advice.*::
Advice shown when linkgit:git-merge[1] refuses to
merge to avoid overwritting local changes.
Default: true.
+ implicitIdentity::
+ Advice on how to set your identity configuration when
+ your information is guessed from the system username and
+ domain name. Default: true.
--
core.fileMode::
diff --git a/advice.c b/advice.c
index cb666ac..8f7de0e 100644
--- a/advice.c
+++ b/advice.c
@@ -3,6 +3,7 @@
int advice_push_nonfastforward = 1;
int advice_status_hints = 1;
int advice_commit_before_merge = 1;
+int advice_implicit_identity = 1;
static struct {
const char *name;
@@ -11,6 +12,7 @@ static struct {
{ "pushnonfastforward", &advice_push_nonfastforward },
{ "statushints", &advice_status_hints },
{ "commitbeforemerge", &advice_commit_before_merge },
+ { "implicitidentity", &advice_implicit_identity },
};
int git_default_advice_config(const char *var, const char *value)
diff --git a/advice.h b/advice.h
index 3de5000..728ab90 100644
--- a/advice.h
+++ b/advice.h
@@ -4,6 +4,7 @@
extern int advice_push_nonfastforward;
extern int advice_status_hints;
extern int advice_commit_before_merge;
+extern int advice_implicit_identity;
int git_default_advice_config(const char *var, const char *value);
diff --git a/builtin-commit.c b/builtin-commit.c
index 3fa9b39..d687cf1 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -1082,8 +1082,10 @@ static void print_summary(const char *prefix, const unsigned char *sha1)
if (!user_ident_explicitly_given) {
strbuf_addstr(&format, "\n Committer: ");
strbuf_addbuf_percentquote(&format, &committer_ident);
- strbuf_addch(&format, '\n');
- strbuf_addstr(&format, implicit_ident_advice);
+ if (advice_implicit_identity) {
+ strbuf_addch(&format, '\n');
+ strbuf_addstr(&format, implicit_ident_advice);
+ }
}
strbuf_release(&author_ident);
strbuf_release(&committer_ident);
--
1.6.6.146.gdaab9.dirty
^ permalink raw reply related
* Re: [PATCH 3/3] commit: show interesting ident information in summary
From: Jeff King @ 2010-01-13 20:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Adam Megacz, git
In-Reply-To: <20100113201708.GA23018@coredump.intra.peff.net>
On Wed, Jan 13, 2010 at 03:17:08PM -0500, Jeff King wrote:
> Even outside of competent maintenance or individuals being served by
> ISPs, I think it is really that it is no longer the case that the
> machines we get our mail on and the machines we do our work on are less
> and less the same. Even as an individual, I can afford a Linux
Er, re-reading that I think I have too many negatives. But hopefully you
get the point: "it is less and less the case that..." or "it is no
longer the case that..."
-Peff
^ permalink raw reply
* Re: [PATCH master] expand "<branch>" in format.subjectprefix
From: Jeff King @ 2010-01-13 20:29 UTC (permalink / raw)
To: Bernhard Reutner-Fischer; +Cc: git
In-Reply-To: <1263402988-925-1-git-send-email-rep.dot.nop@gmail.com>
On Wed, Jan 13, 2010 at 06:16:28PM +0100, Bernhard Reutner-Fischer wrote:
> Replace "<branch>" with the current branch name for
> [format]
> subjectprefix = PATCH <branch>
>
> A subject-prefix given on the command-line overrides the one given in
> the config.
I don't have a big opinion on whether this feature is useful (it
wouldn't be to me, but I can see workflows where it could be).
I'm not sure that "current branch" makes sense, though. format-patch is
about showing commits, and the current branch is not a property of that
commit. It is about where you happen to be currently. So doing:
git checkout X
git format-patch Y..Z --subject-prefix "PATCH <branch>"
shows "X" which is not really useful information. Something like git
log's "--source" would be more useful; it shows the command-line ref
that was used to reach a given commit.
Also, please don't introduce a new substitution syntax. We already have
code to do %-expansion. In fact, if you are going to do something like
this, maybe it would be best as two patches:
1. Support '%B' as a user-format expansion for the --source branch.
2. Support user-format expansions in the subject prefix.
But I don't know if people would find any of the other substitutions
useful in the subject line.
-Peff
^ permalink raw reply
* [PATCH] Removed the .git/config check from "git submodule status"
From: Peter Collingbourne @ 2010-01-13 20:31 UTC (permalink / raw)
To: git; +Cc: Lars Hjemli, Peter Collingbourne
"git submodule status" requires that the following conditions be met
for a submodule to be considered initialised:
1) The existence of an entry in .git/config for that module
2) The existence of a .git subdirectory under the submodule directory
Plumbing only requires condition 2 to be met, and does not care about
condition 1 (these entries being part of the git-submodule porcelain).
Therefore removing condition 1 from "git submodule status" will make
git-submodule's view of the world consistent with plumbing's thus
eliminating unexpected behaviour.
Furthermore if the user is using the git-submodule porcelain and
not cloning submodules himself, condition 1 should always follow
from condition 2 because "git submodule update" requires that the
submodule entry in .git/config be present.
By removing condition 1 we can also remove the call to module_name from
cmd_status. "git submodule status" will now work if the user is using
a submodule porcelain other than git-submodule, because module_name
requires that the .gitmodules file be maintained by git-submodule.
Signed-off-by: Peter Collingbourne <peter@pcc.me.uk>
---
git-submodule.sh | 4 +---
t/t7400-submodule-basic.sh | 8 ++------
2 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index 77d2232..811f001 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -738,10 +738,8 @@ cmd_status()
module_list "$@" |
while read mode sha1 stage path
do
- name=$(module_name "$path") || exit
- url=$(git config submodule."$name".url)
displaypath="$prefix$path"
- if test -z "$url" || ! test -d "$path"/.git -o -f "$path"/.git
+ if ! test -d "$path"/.git -o -f "$path"/.git
then
say "-$sha1 $displaypath"
continue;
diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
index 1a4dc5f..c16fb14 100755
--- a/t/t7400-submodule-basic.sh
+++ b/t/t7400-submodule-basic.sh
@@ -106,12 +106,8 @@ test_expect_success 'submodule add with ./, /.. and // in path' '
)
'
-test_expect_success 'status should fail for unmapped paths' '
- if git submodule status
- then
- echo "[OOPS] submodule status succeeded"
- false
- elif ! GIT_CONFIG=.gitmodules git config submodule.example.path init
+test_expect_success 'mapping a path using git config' '
+ if ! GIT_CONFIG=.gitmodules git config submodule.example.path init
then
echo "[OOPS] git config failed to update .gitmodules"
false
--
1.6.5
^ permalink raw reply related
* [PATCH resend] gitk: font and theme use
From: Mark Hills @ 2010-01-13 20:40 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
Hi Paul,
I'm following up this email with a re-send of some earlier patches for
your review (previously sent to the list). They make some fixes to the
font and theme use, mainly for consistency.
Since last time and have based them on gitk.git master (instead of
git.git); no other changes.
Thanks
--
Mark
^ permalink raw reply
* [PATCH 5/5] gitk: Use consistent font for all text input fields
From: Mark Hills @ 2010-01-13 20:40 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <1263415222-5911-4-git-send-email-mark@pogo.org.uk>
Instead of setting the font for specific widgets, set the font for the
widget type. If themed widgets are not available, this is via the X
resources. If themed widgets are available, the theme font is used.
The exception is the SHA1 ID which is forced to use the fixed-width
font, even where themed widgets are used.
Signed-off-by: Mark Hills <mark@pogo.org.uk>
---
gitk | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/gitk b/gitk
index 54f4fb3..1f5f456 100755
--- a/gitk
+++ b/gitk
@@ -1877,7 +1877,8 @@ proc setoptions {} {
option add *Menubutton.font uifont startupFile
option add *Label.font uifont startupFile
option add *Message.font uifont startupFile
- option add *Entry.font uifont startupFile
+ option add *Entry.font textfont startupFile
+ option add *Text.font textfont startupFile
option add *Labelframe.font uifont startupFile
option add *Spinbox.font textfont startupFile
option add *Listbox.font mainfont startupFile
@@ -2176,7 +2177,7 @@ proc makewindow {} {
set findstring {}
set fstring .tf.lbar.findstring
lappend entries $fstring
- ${NS}::entry $fstring -width 30 -font textfont -textvariable findstring
+ ${NS}::entry $fstring -width 30 -textvariable findstring
trace add variable findstring write find_change
set findtype [mc "Exact"]
set findtypemenu [makedroplist .tf.lbar.findtype \
@@ -2219,7 +2220,7 @@ proc makewindow {} {
pack .bleft.top.search -side left -padx 5
set sstring .bleft.top.sstring
set searchstring ""
- ${NS}::entry $sstring -width 20 -font textfont -textvariable searchstring
+ ${NS}::entry $sstring -width 20 -textvariable searchstring
lappend entries $sstring
trace add variable searchstring write incrsearch
pack $sstring -side left -expand 1 -fill x
@@ -4039,7 +4040,7 @@ proc vieweditor {top n title} {
} elseif {$type eq "path"} {
${NS}::label $top.l -text $title
pack $top.l -in $top -side top -pady [list 3 0] -anchor w -padx 3
- text $top.t -width 40 -height 5 -background $bgcolor -font uifont
+ text $top.t -width 40 -height 5 -background $bgcolor
if {[info exists viewfiles($n)]} {
foreach f $viewfiles($n) {
$top.t insert end $f
--
1.6.6.5.ge408
^ permalink raw reply related
* [PATCH 4/5] gitk: Disable option when themed widgets are not available
From: Mark Hills @ 2010-01-13 20:40 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <1263415222-5911-3-git-send-email-mark@pogo.org.uk>
Disable the widget instead of using the label to indicate that themed
widgets are not available.
Signed-off-by: Mark Hills <mark@pogo.org.uk>
---
gitk | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/gitk b/gitk
index 3cdc31e..54f4fb3 100755
--- a/gitk
+++ b/gitk
@@ -10736,14 +10736,14 @@ proc doprefs {} {
${NS}::label $top.lgen -text [mc "General options"]
grid $top.lgen - -sticky w -pady 10
- ${NS}::checkbutton $top.want_ttk -variable want_ttk \
- -text [mc "Use themed widgets"]
if {$have_ttk} {
- ${NS}::label $top.ttk_note -text [mc "(change requires restart)"]
+ ${NS}::checkbutton $top.want_ttk -variable want_ttk \
+ -text [mc "Use themed widgets (change requires restart)"]
} else {
- ${NS}::label $top.ttk_note -text [mc "(currently unavailable)"]
+ ${NS}::checkbutton $top.want_ttk \
+ -text [mc "Use themed widgets"] -state disabled
}
- grid x $top.want_ttk $top.ttk_note -sticky w
+ grid x $top.want_ttk - -sticky w
${NS}::label $top.cdisp -text [mc "Colors: press to choose"]
grid $top.cdisp - -sticky w -pady 10
--
1.6.6.5.ge408
^ permalink raw reply related
* [PATCH 2/5] gitk: Set the font for all spinbox widgets
From: Mark Hills @ 2010-01-13 20:40 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <1263415222-5911-1-git-send-email-mark@pogo.org.uk>
Use the X resources to set the font, removing the need to set the font
for specific widgets.
Signed-off-by: Mark Hills <mark@pogo.org.uk>
---
gitk | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/gitk b/gitk
index 0e430bd..e010010 100755
--- a/gitk
+++ b/gitk
@@ -1879,6 +1879,7 @@ proc setoptions {} {
option add *Message.font uifont startupFile
option add *Entry.font uifont startupFile
option add *Labelframe.font uifont startupFile
+ option add *Spinbox.font textfont startupFile
}
# Make a menu and submenus.
@@ -2229,7 +2230,7 @@ proc makewindow {} {
-command changediffdisp -variable diffelide -value {1 0}
${NS}::label .bleft.mid.labeldiffcontext -text " [mc "Lines of context"]: "
pack .bleft.mid.diff .bleft.mid.old .bleft.mid.new -side left
- spinbox .bleft.mid.diffcontext -width 5 -font textfont \
+ spinbox .bleft.mid.diffcontext -width 5 \
-from 0 -increment 1 -to 10000000 \
-validate all -validatecommand "diffcontextvalidate %P" \
-textvariable diffcontextstring
--
1.6.6.5.ge408
^ permalink raw reply related
* [PATCH 3/5] gitk: Set the font for all listbox widgets
From: Mark Hills @ 2010-01-13 20:40 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <1263415222-5911-2-git-send-email-mark@pogo.org.uk>
This affects the font chooser.
Signed-off-by: Mark Hills <mark@pogo.org.uk>
---
gitk | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/gitk b/gitk
index e010010..3cdc31e 100755
--- a/gitk
+++ b/gitk
@@ -1880,6 +1880,7 @@ proc setoptions {} {
option add *Entry.font uifont startupFile
option add *Labelframe.font uifont startupFile
option add *Spinbox.font textfont startupFile
+ option add *Listbox.font mainfont startupFile
}
# Make a menu and submenus.
--
1.6.6.5.ge408
^ permalink raw reply related
* [PATCH 1/5] gitk: Remove forced use of sans-serif font
From: Mark Hills @ 2010-01-13 20:40 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <alpine.NEB.2.01.1001132030010.15349@jrf.vwaro.pbz>
The X resources set using uifont cover this case.
Signed-off-by: Mark Hills <mark@pogo.org.uk>
---
gitk | 12 ------------
1 files changed, 0 insertions(+), 12 deletions(-)
diff --git a/gitk b/gitk
index 48cfce3..0e430bd 100755
--- a/gitk
+++ b/gitk
@@ -10528,7 +10528,6 @@ proc mkfontdisp {font top which} {
set fontpref($font) [set $font]
${NS}::button $top.${font}but -text $which \
-command [list choosefont $font $which]
- if {!$use_ttk} {$top.${font}but configure -font optionfont}
${NS}::label $top.$font -relief flat -font $font \
-text $fontattr($font,family) -justify left
grid x $top.${font}but $top.$font -sticky w
@@ -10791,15 +10790,6 @@ proc doprefs {} {
mkfontdisp textfont $top [mc "Diff display font"]
mkfontdisp uifont $top [mc "User interface font"]
- if {!$use_ttk} {
- foreach w {maxpctl maxwidthl showlocal autoselect tabstopl ntag
- ldiff lattr extdifff.l extdifff.b bgbut fgbut
- diffoldbut diffnewbut hunksepbut markbgbut selbgbut
- want_ttk ttk_note} {
- $top.$w configure -font optionfont
- }
- }
-
${NS}::frame $top.buts
${NS}::button $top.buts.ok -text [mc "OK"] -command prefsok -default active
${NS}::button $top.buts.can -text [mc "Cancel"] -command prefscan -default normal
@@ -11411,8 +11401,6 @@ namespace import ::msgcat::mc
catch {source ~/.gitk}
-font create optionfont -family sans-serif -size -12
-
parsefont mainfont $mainfont
eval font create mainfont [fontflags mainfont]
eval font create mainfontbold [fontflags mainfont 1]
--
1.6.6.5.ge408
^ permalink raw reply related
* Re: [RFC 0/2] Git-over-TLS (gits://) client side support
From: Ilari Liusvaara @ 2010-01-13 20:47 UTC (permalink / raw)
To: Andreas Krey; +Cc: Nguyen Thai Ngoc Duy, git
In-Reply-To: <20100113194050.GA11688@inner.home.ulmdo.de>
On Wed, Jan 13, 2010 at 08:40:50PM +0100, Andreas Krey wrote:
> On Wed, 13 Jan 2010 21:18:02 +0000, Ilari Liusvaara wrote:
> ...
> > That feature is grossly underdocumented (and also nonportable). Unix(7)
> > should document it, except that it doesn't for me (it documents that
> > SO_PASSCRED takes a boolean, except that what the server implementation
> > passes is something completely different).
>
> Actually, I meant how you plan to map credentials (however obtained)
> into allowed actions inside git-daemon (or the hooks).
Its actually git-daemon2. And it doesn't authorize anything, only delegates
the authorization (e.g. to gitolite).
> ...
> > And how many (relative) use client ceritificates with SSL? Keypairs with SSH?
> > Why you think this is?
>
> Because ssh is much more popular than ssl client auth. Obtaining client
> certificates isn't much more complicated than getting an ssh account,
> once you have scripts for the stuff ready.
SSL client certificate usability is horrible. SSH keypairs are actually
almost usable.
> But I wonder: When you want keypair auth, why not just use ssh?
IIRC, I already have told at least twice...
> I didn't quite understand the use case yet, it seems. With ssh
> I have all the infrastructure like ssh-agent in place already;
> with gits: (any kind of) it will be asked for sooner or later.
gpg-agent can be used (since client uses gpg to protect the keys
if needed).
-Ilari
^ permalink raw reply
* Re: [PATCH 3/3] commit: show interesting ident information in summary
From: Junio C Hamano @ 2010-01-13 20:50 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Adam Megacz, git
In-Reply-To: <20100113201843.GB23018@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Wed, Jan 13, 2010 at 03:17:08PM -0500, Jeff King wrote:
>
>> Even outside of competent maintenance or individuals being served by
>> ISPs, I think it is really that it is no longer the case that the
>> machines we get our mail on and the machines we do our work on are less
>> and less the same. Even as an individual, I can afford a Linux
>
> Er, re-reading that I think I have too many negatives. But hopefully you
> get the point: "it is less and less the case that..." or "it is no
> longer the case that..."
Yes, I am in full agreement with everything you wrote in the message you
are responding to, including the comments after three-dash line about
showing the "Committer: " line even when the advice.implicitidentity is
declined.
Thanks.
^ 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