* Re: [RFC 0/2] Git-over-TLS (gits://) client side support
From: Andreas Krey @ 2010-01-13 16:17 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: Nguyen Thai Ngoc Duy, git
In-Reply-To: <20100113144745.GA7246@Knoppix>
On Wed, 13 Jan 2010 16:47:47 +0000, Ilari Liusvaara wrote:
...
> > It doesn't need to, really. stunnel sets the environment variable
> > SSL_CLIENT_DN with the distinguished name of the client certificate,
> > which can be used in the hook scripts ('update') on the server.
>
> That would be useless. Data about authenticated client needs to fed to
> authorization decisions already before invoking git.
If you don't want public read access then you need to wedge a script
between stunnel and git itself that checks whether authentication is
present, yes.
> And besides: Gits:// uses certificates as keypairs,
My gripe with this is that I would expect gits: to be the same
as git: except that there is SSL underneath. git: does not have
authentication, so there should be none in gits: except what
SSL provides. (And the auth via unix domain sockets would be
usable for plain git: as well; there is no reason to encrypt
local traffic?)
(Is the unix auth via unix domain sockets part of GnuTLS?)
> which would make DN
> data absolutely useless because it is untrustworthy. And adding PKI
> is way too complicated.
That's another story. I think that it would be possible nowadays
to implement gits:// (in both ways) via core.gitproxy and a server-side
wrapper program (stunnel or else), but that has the disadvantage of
being unable to just provide a clone url without installing special
software besides git.
...
> The authentication support for smart-http seems pretty bad (making the
> old mistake of not binding authentications).
Mind to explain 'binding authentications'?
Andreas
^ permalink raw reply
* Re: [PATCH] git push --track
From: Ilari Liusvaara @ 2010-01-13 16:27 UTC (permalink / raw)
To: Rudolf Polzer; +Cc: git
In-Reply-To: <op.u6haiiiog402ra@nb-04>
On Wed, Jan 13, 2010 at 04:55:20PM +0100, Rudolf Polzer wrote:
> On Wed, 13 Jan 2010 16:43:10 +0100, Ilari Liusvaara
> <ilari.liusvaara@elisanet.fi> wrote:
>
> >On Wed, Jan 13, 2010 at 04:12:49PM +0100, Rudolf Polzer wrote:
> >>Hi,
> >>
>
> Of course, but I assume the sign-off would not be by me, but by some
> of the git developers, and would depend on whether they actually
> want this feature.
It would need sign-off by you. Even if you took the code from somewhere
(and then it would need theirs as well) and passed it along.
> >- Should the tracking be set up even if only part of ref update suceeded
> >(for those that succeeded), not requiring all to succeed?
>
> Good point, but I simply see no clean way to set it up for the
> succeeded refs. Would be a nice idea for improvement of this.
Ah, that is only known in transport_push and what it calls (and transport_push
is last point to insert common functionality)...
> @@ -218,6 +249,8 @@ int cmd_push(int argc, const char **argv, const
> char *prefix)
> OPT_BOOLEAN( 0 , "thin", &thin, "use thin pack"),
> OPT_STRING( 0 , "receive-pack", &receivepack, "receive-pack",
> "receive pack program"),
> OPT_STRING( 0 , "exec", &receivepack, "receive-pack", "receive
> pack program"),
> + OPT_BIT('t', "track", &flags, "set up tracking mode (see git-pull(1))",
> + TRANSPORT_PUSH_TRACK),
> OPT_END()
> };
Linewrap damage.
-Ilari
^ permalink raw reply
* Re: [PATCH] git push --track
From: Matthieu Moy @ 2010-01-13 16:37 UTC (permalink / raw)
To: Rudolf Polzer; +Cc: git
In-Reply-To: <op.u6haiiiog402ra@nb-04>
"Rudolf Polzer" <divVerent@alientrap.org> writes:
> Of course, but I assume the sign-off would not be by me, but by some
> of the git developers, and would depend on whether they actually want
> this feature.
Read Documentation/SubmittingPatches in Git's source to make sure you
understand what Signed-off-by: means for the Git project.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH 2/3] strbuf: add strbuf_percentquote_buf
From: Jeff King @ 2010-01-13 17:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Adam Megacz, git
In-Reply-To: <7viqb6trwu.fsf@alter.siamese.dyndns.org>
On Tue, Jan 12, 2010 at 10:55:45PM -0800, Junio C Hamano wrote:
> > +void strbuf_percentquote_buf(struct strbuf *dest, struct strbuf *src)
> > +{
>
> Just a style thing, but please call that "dst" to be consistent. You are
> already dropping vowels from the other side to spell it "src".
I personally dislike that spelling, but it certainly is consistent with
the rest of git, so OK.
> I wondered if the function should be just 1-arg that always quotes
> in-place instead, but your [PATCH 3/3] wants to have an appending
> semantics from this function, so changing it to be a 1-arg "in-place
> quoter" will force the caller to run strbuf_addbuf() on the result, which
> is not nice.
Yep. An in-place version would be a bit more complicated to write, and
would make the caller do extra work.
> Since tucking a p-quoted version of the same string to its original
> doesn't make sense at all, perhaps this should:
>
> (0) be renamed to have "append" somewhere in its name;
Yeah, I considered this. To follow the existing naming conventions, the
name should indicate:
1. it's a strbuf function
2. it's appending (and the pattern is to use "add")
3. it's appending a strbuf (and the pattern is to call this "buf")
4. it's percent-quoting
So perhaps following the existing standards, it should be
strbuf_addbuf_percentquote? Long, but I don't think there is any
confusion about what it does (and leaves room for addstr_percentquote).
> (1) mark the src side as const; and
Oops, good catch.
> (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. And since I don't actually need to do that, I
think leaving an assert in-place until somebody does need it and wants
to write it is fine.
> --- 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.
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);
The grow will not affect the length of sb2, so that doesn't need to be
saved. And there is no point in deciding whether to point the buf you
pass at sb->buf or sb2->buf. If they are the same, then the grow will
have reallocated sb2 as well as sb, and they are identical. And if they
are not, then sb2->buf is the right thing to pass.
-Peff
^ permalink raw reply
* [PATCH master] expand "<branch>" in format.subjectprefix
From: Bernhard Reutner-Fischer @ 2010-01-13 17:16 UTC (permalink / raw)
To: git; +Cc: Bernhard Reutner-Fischer
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.
Previously this didn't work for me:
$ git config --replace-all format.subjectprefix 'PATCH <branch>'
# edit something, commit it
$ git format-patch -o ~/foo/ HEAD^..HEAD
and that patch still has "<branch>" in the subject, even when
send-email'ed.
A manual
$ git-format-patch -o ~/foo/ HEAD^..HEAD --subject-prefix="PATCH something"
works, but is not convenient since i usually want to denote which branch
the patch is against.
Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
---
builtin-log.c | 43 ++++++++++++++++++++++++++++++++++++++++---
log-tree.c | 6 +++---
revision.h | 2 +-
3 files changed, 44 insertions(+), 7 deletions(-)
diff --git a/builtin-log.c b/builtin-log.c
index 41b6df4..d7624bf 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -31,6 +31,43 @@ static const char * const builtin_log_usage =
"git log [<options>] [<since>..<until>] [[--] <path>...]\n"
" or: git show [options] <object>...";
+static const char* subst_subject_prefix(void)
+{
+ char *ch;
+
+ /* now expand <branch> */
+ if ((ch = strstr(fmt_patch_subject_prefix, "<branch>")) != NULL)
+ {
+ /* get_or_ask_branch_name(): */
+ struct branch *current_branch;
+ size_t len;
+ int a, b = ch - fmt_patch_subject_prefix;
+ char *branch_name, *new_subject;
+
+ current_branch = branch_get(NULL);
+ if (!current_branch || !current_branch->merge
+ || !current_branch->merge[0]
+ || !current_branch->merge[0]->dst) {
+ branch_name = "(no branch)";
+ } else {
+ branch_name = current_branch->merge[0]->dst;
+ ch = strrchr(branch_name, '/');
+ if (ch)
+ branch_name = ++ch;
+ }
+ len = strlen(branch_name);
+ a = strlen(fmt_patch_subject_prefix) - b - strlen("<branch>");
+ new_subject = xcalloc(1, 1 + b + len + a);
+ memcpy(new_subject, fmt_patch_subject_prefix, b);
+ memcpy(new_subject + b, branch_name, len);
+ memcpy(new_subject + b + len,
+ fmt_patch_subject_prefix + b + strlen("<branch>"),
+ a);
+ *&fmt_patch_subject_prefix = new_subject;
+ }
+ return fmt_patch_subject_prefix;
+}
+
static void cmd_log_init(int argc, const char **argv, const char *prefix,
struct rev_info *rev)
{
@@ -44,7 +81,7 @@ static void cmd_log_init(int argc, const char **argv, const char *prefix,
rev->verbose_header = 1;
DIFF_OPT_SET(&rev->diffopt, RECURSIVE);
rev->show_root_diff = default_show_root;
- rev->subject_prefix = fmt_patch_subject_prefix;
+ rev->subject_prefix = &subst_subject_prefix;
DIFF_OPT_SET(&rev->diffopt, ALLOW_TEXTCONV);
if (default_date_mode)
@@ -795,7 +832,7 @@ static int subject_prefix_callback(const struct option *opt, const char *arg,
int unset)
{
subject_prefix = 1;
- ((struct rev_info *)opt->value)->subject_prefix = arg;
+ *&fmt_patch_subject_prefix = arg;
return 0;
}
@@ -962,7 +999,7 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
rev.ignore_merges = 1;
DIFF_OPT_SET(&rev.diffopt, RECURSIVE);
- rev.subject_prefix = fmt_patch_subject_prefix;
+ rev.subject_prefix = &subst_subject_prefix;
if (default_attach) {
rev.mime_boundary = default_attach;
diff --git a/log-tree.c b/log-tree.c
index 0fdf159..e29f009 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -203,15 +203,15 @@ void log_write_email_headers(struct rev_info *opt, struct commit *commit,
static char buffer[64];
snprintf(buffer, sizeof(buffer),
"Subject: [%s %0*d/%d] ",
- opt->subject_prefix,
+ opt->subject_prefix(),
digits_in_number(opt->total),
opt->nr, opt->total);
subject = buffer;
- } else if (opt->total == 0 && opt->subject_prefix && *opt->subject_prefix) {
+ } else if (opt->total == 0 && opt->subject_prefix()) {
static char buffer[256];
snprintf(buffer, sizeof(buffer),
"Subject: [%s] ",
- opt->subject_prefix);
+ opt->subject_prefix());
subject = buffer;
} else {
subject = "Subject: ";
diff --git a/revision.h b/revision.h
index d368003..ca45c57 100644
--- a/revision.h
+++ b/revision.h
@@ -100,7 +100,7 @@ struct rev_info {
const char *add_signoff;
const char *extra_headers;
const char *log_reencode;
- const char *subject_prefix;
+ const char *(*subject_prefix)(void);
int no_inline;
int show_log_size;
--
1.6.6.103.gbcea0.dirty
^ permalink raw reply related
* Re: [PATCH 1/7] gitweb: Load checking
From: Jakub Narebski @ 2010-01-13 17:18 UTC (permalink / raw)
To: git; +Cc: John 'Warthog9' Hawley
In-Reply-To: <1263374828-15342-2-git-send-email-warthog9@eaglescrag.net>
On Wed, 13 Jan 2010, John 'Warthog9' Hawley wrote:
>
> v3 - warthog9: small additional adjustment to indicate where new load
> checking should be added for future improvements
> v2 - Jakub: switching to using
"switching to using" what?
> v1 - warthog9: Initial creation
>
> Signed-off-by: John 'Warthog9' Hawley <warthog9@kernel.org>
> Signed-off-by: Jakub Narebski <jnareb@gmail.com>
> ---
Also, such comments should be put in the comment section, here i.e. between
"---\n" separator and the diffstat, and not in the commit message.
> gitweb/README | 7 ++++++-
> gitweb/gitweb.perl | 45 +++++++++++++++++++++++++++++++++++++++++----
> 2 files changed, 47 insertions(+), 5 deletions(-)
Other that this minor nick (which I guess could be fixed by Junio when
applying), this one looks good.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH v2] fast-import: tag may point to any object type
From: Shawn O. Pearce @ 2010-01-13 17:24 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: git, Junio C Hamano
In-Reply-To: <20100113123532.GC10586@dpotapov.dyndns.org>
Dmitry Potapov <dpotapov@gmail.com> wrote:
> If you tried to export the official git repository, and then to import it
> back then git-fast-import would die complaining that "Mark :1 not a commit".
...
> diff --git a/fast-import.c b/fast-import.c
> index cd87049..4fdf809 100644
> --- a/fast-import.c
> +++ b/fast-import.c
> @@ -2325,19 +2326,20 @@ static void parse_new_tag(void)
> } else if (!get_sha1(from, sha1)) {
> unsigned long size;
> char *buf;
>
> + type = sha1_object_info(sha1, NULL);
> buf = read_object_with_reference(sha1,
> - commit_type, &size, sha1);
> + typename(type), &size, sha1);
This is better spelled as:
buf = read_sha1_file(sha1, &type, &size);
But otherwise the patch looks correct now, thanks.
If you could make this one change, add my
Acked-by: Shawn O. Pearce <spearce@spearce.org>
and resend so Junio can apply, thanks.
--
Shawn.
^ permalink raw reply
* git svn problem
From: Julien POTIRON @ 2010-01-13 17:20 UTC (permalink / raw)
To: git
Hello, I have a problem with git.
Basically, here is what I have. I access a svn repository through git.
Until now, on python files, everything worked fine.
But lately I also added some pyd, dll and lib files on the repository. THe
first update went well. But then, these files have been modified and since
then I can't update. These files were added from a windows computer with
TortoiseSvn on the svn repository.
If I do a git svn rebase on linux, everything works fine.
If I do a git svn rebase on windows with msysgit (and also tortoisegit), I
have the following error : fatal: write error: Invalid argument
If I do a git svn rebase on windows with cygwin, I have the following
error : didn't find newline after blob at
/usr/lib/perl5/vendor_perl/5.10/Git.pm line 916
I tried several stuff (autocrlf true/false, safecrlf true/false), adding
.gitattributes file with the following line *.* -crlf -diff -merge and
nothing worked.
I'm a little stuck here so any suggestion would be welcome.
Thanks in advance.
^ permalink raw reply
* Re: [PATCH 3/3] commit: show interesting ident information in summary
From: Jeff King @ 2010-01-13 17:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Adam Megacz, git
In-Reply-To: <7v3a2asda8.fsf@alter.siamese.dyndns.org>
On Tue, Jan 12, 2010 at 10:57:03PM -0800, Junio C Hamano wrote:
> > + if (!user_ident_explicitly_given) {
> > + strbuf_addstr(&format, "\n Committer: ");
> > + strbuf_percentquote_buf(&format, &committer_ident);
> > + }
>
> This is much better.
>
> We might want an advice message inside the latter case, helping the user
> learn how to spell his name correctly. This is designed to trigger for
> people/repositories that are not configured, and by definition the
> majority of that target audience are new people.
>
> The extra message will disappear once committer information is explicitly
> given, there is no need to protect the advice message with the usual
> "advice.*" configuration.
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.
-Peff
^ permalink raw reply
* Re: [PATCH 2/7] gitweb: Add option to force version match
From: Jakub Narebski @ 2010-01-13 17:33 UTC (permalink / raw)
To: John 'Warthog9' Hawley, git; +Cc: warthog9
In-Reply-To: <1263374828-15342-3-git-send-email-warthog9@eaglescrag.net>
On Wed, 13 Jan 2010, John 'Warthog9' Hawley wrote:
> From: John 'Warthog9' Hawley <warthog9@kernel.org>
>
> This adds $git_versions_must_match variable, which is set to true
s/is set to true value/if set to true,/
> value checks that we are running on the same version of git that we
> shipped with, and if not throw '500 Internal Server Error' error.
> What is checked is the version of gitweb (embedded in building
> gitweb.cgi), against version of runtime git binary used.
>
> Gitweb can usually run with a mismatched git install. This is more
> here to give an obvious warning as to whats going on vs. silently
> failing.
>
> By default this feature is turned off.
[moved version info below, after "---" separator]
> Signed-off-by: John 'Warthog9' Hawley <warthog9@kernel.org>
> Signed-off-by: Jakub Narebski <jnareb@gmail.com>
> ---
Moved to the correct place: information about patch versioning should
be put in comment section[1], not in commit message.
[1] Which means between "---" separator and diffstat.
> v3 - warthog9: adjust to use die_error instead of recreating it
> v2 - Jakub: Changes to make non-default, and change naming
> v1 - warthog9: Initial
> gitweb/README | 3 +++
> gitweb/gitweb.perl | 28 ++++++++++++++++++++++++++++
> 2 files changed, 31 insertions(+), 0 deletions(-)
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> @@ -587,6 +590,31 @@ if (defined $maxload && get_loadavg() > $maxload) {
> our $git_version = qx("$GIT" --version) =~ m/git version (.*)$/ ? $1 : "unknown";
> $number_of_git_cmds++;
>
> +# Throw an error if git versions does not match, if $git_versions_must_match is true.
> +if ($git_versions_must_match &&
> + $git_version ne $version) {
> + my $admin_contact =
> + defined $ENV{'SERVER_ADMIN'} ? ", $ENV{'SERVER_ADMIN'}," : '';
> + my $err_msg = <<EOT;
> +Internal Server Error
> +<br />
> +</div>
> +<hr />
> +<div class="readme">
> +<h1 align="center">*** Warning ***</h1>
> +<p>
> +This version of gitweb was compiled for <b>@{[esc_html($version)]}</b>,
> +however git version <b>@{[esc_html($git_version)]}</b> was found on server,
> +and administrator requested strict version checking.
> +</p>
> +<p>
> +Please contact the server administrator${admin_contact} to either configure
> +gitweb to allow mismatched versions, or update git or gitweb installation.
> +</p>
> +EOT
> + die_error(500, $err_msg);
> +}
I'm sorry to be this picky, but don't you think that caller should not need
to know "intimate" details on how die_error works. In particular please
notice that you must have known that die_error wraps its output in <div>...
which is not even mentioned in comments.
The second argument of die_error() subroutine is meant to be alternative
description of error condition: short and one line. For situations such
like this one, where we want to describe error in more details, it would
be better, I think, to change signature of die_error() to take (optionally)
three arguments, and use 'die_error(500, undef, $err_msg);', with $err_msg
starting from '<h1>...</h1>'.
@@ -3460,6 +3460,7 @@
sub die_error {
my $status = shift || 500;
my $error = shift || "Internal server error";
+ my $extra = shift;
my %http_responses = (
400 => '400 Bad Request',
@@ -3475,8 +3476,13 @@ sub die_error {
<br /><br />
$status - $error
<br />
-</div>
EOF
+ if (defined $extra) {
+ print "<hr />\n" .
+ "$extra\n";
+ }
+ print "</div>\n";
+
git_footer_html();
exit;
}
Other that this minor issue it looks good.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] Display author and committer after "git commit"
From: Jeff King @ 2010-01-13 17:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Adam Megacz, git
In-Reply-To: <20100112153656.GA24840@coredump.intra.peff.net>
On Tue, Jan 12, 2010 at 10:36:56AM -0500, Jeff King wrote:
> [1/3]: strbuf_expand: convert "%%" to "%"
> [2/3]: strbuf: add strbuf_percentquote_buf
> [3/3]: commit: show interesting ident information in summary
And here's a re-roll based on Junio's comments.
[1/3]: strbuf_expand: convert "%%" to "%"
[2/3]: strbuf: add strbuf_addbuf_percentquote
[3/3]: commit: show interesting ident information in summary
-Peff
^ permalink raw reply
* [PATCH v2 1/3] strbuf_expand: convert "%%" to "%"
From: Jeff King @ 2010-01-13 17:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Adam Megacz, git
In-Reply-To: <20100113173408.GA16652@coredump.intra.peff.net>
The only way to safely quote arbitrary text in a
pretty-print user format is to replace instances of "%" with
"%x25". This is slightly unreadable, and many users would
expect "%%" to produce a single "%", as that is what printf
format specifiers do.
This patch converts "%%" to "%" for all users of
strbuf_expand:
1. git-daemon interpolated paths
2. pretty-print user formats
3. merge driver command lines
Case (1) was already doing the conversion itself outside of
strbuf_expand. Case (2) is the intended beneficiary of this
patch. Case (3) users probably won't notice, but as this is
user-facing behavior, consistently providing the quoting
mechanism makes sense.
Signed-off-by: Jeff King <peff@coredump.intra.peff.net>
---
Changes from v1:
- note change in strbuf api docs
Documentation/pretty-formats.txt | 1 +
Documentation/technical/api-strbuf.txt | 4 ++++
daemon.c | 1 -
strbuf.c | 6 ++++++
t/t6006-rev-list-format.sh | 7 +++++++
5 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index 53a9168..1686a54 100644
--- a/Documentation/pretty-formats.txt
+++ b/Documentation/pretty-formats.txt
@@ -134,6 +134,7 @@ The placeholders are:
- '%C(...)': color specification, as described in color.branch.* config option
- '%m': left, right or boundary mark
- '%n': newline
+- '%%': a raw '%'
- '%x00': print a byte from a hex code
- '%w([<w>[,<i1>[,<i2>]]])': switch line wrapping, like the -w option of
linkgit:git-shortlog[1].
diff --git a/Documentation/technical/api-strbuf.txt b/Documentation/technical/api-strbuf.txt
index a0e0f85..3b1da10 100644
--- a/Documentation/technical/api-strbuf.txt
+++ b/Documentation/technical/api-strbuf.txt
@@ -199,6 +199,10 @@ character if the letter `n` appears after a `%`. The function returns
the length of the placeholder recognized and `strbuf_expand()` skips
over it.
+
+The format `%%` is automatically expanded to a single `%` as a quoting
+mechanism; callers do not need to handle the `%` placeholder themselves,
+and the callback function will not be invoked for this placeholder.
++
All other characters (non-percent and not skipped ones) are copied
verbatim to the strbuf. If the callback returned zero, meaning that the
placeholder is unknown, then the percent sign is copied, too.
diff --git a/daemon.c b/daemon.c
index 918e560..360635e 100644
--- a/daemon.c
+++ b/daemon.c
@@ -147,7 +147,6 @@ static char *path_ok(char *directory)
{ "IP", ip_address },
{ "P", tcp_port },
{ "D", directory },
- { "%", "%" },
{ NULL }
};
diff --git a/strbuf.c b/strbuf.c
index a6153dc..6cbc1fc 100644
--- a/strbuf.c
+++ b/strbuf.c
@@ -227,6 +227,12 @@ void strbuf_expand(struct strbuf *sb, const char *format, expand_fn_t fn,
break;
format = percent + 1;
+ if (*format == '%') {
+ strbuf_addch(sb, '%');
+ format++;
+ continue;
+ }
+
consumed = fn(sb, format, context);
if (consumed)
format += consumed;
diff --git a/t/t6006-rev-list-format.sh b/t/t6006-rev-list-format.sh
index 5719315..b0047d3 100755
--- a/t/t6006-rev-list-format.sh
+++ b/t/t6006-rev-list-format.sh
@@ -19,6 +19,13 @@ test_cmp expect.$1 output.$1
"
}
+test_format percent %%h <<'EOF'
+commit 131a310eb913d107dd3c09a65d1651175898735d
+%h
+commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
+%h
+EOF
+
test_format hash %H%n%h <<'EOF'
commit 131a310eb913d107dd3c09a65d1651175898735d
131a310eb913d107dd3c09a65d1651175898735d
--
1.6.6.140.g92e4d.dirty
^ permalink raw reply related
* Re: [RFC 0/2] Git-over-TLS (gits://) client side support
From: Ilari Liusvaara @ 2010-01-13 17:36 UTC (permalink / raw)
To: Andreas Krey; +Cc: Nguyen Thai Ngoc Duy, git
In-Reply-To: <20100113161711.GB17687@inner.home.ulmdo.de>
On Wed, Jan 13, 2010 at 05:17:11PM +0100, Andreas Krey wrote:
> On Wed, 13 Jan 2010 16:47:47 +0000, Ilari Liusvaara wrote:
>
> If you don't want public read access then you need to wedge a script
> between stunnel and git itself that checks whether authentication is
> present, yes.
That would violate layering badly. You need to decode the request
first before you can authorize. And the git daemon does that.
> > And besides: Gits:// uses certificates as keypairs,
>
> My gripe with this is that I would expect gits: to be the same
> as git: except that there is SSL underneath. git: does not have
> authentication, so there should be none in gits: except what
> SSL provides.
All authentication in gits:// is at TLS (SSL) level or even lower.
> (And the auth via unix domain sockets would be
> usable for plain git: as well; there is no reason to encrypt
> local traffic?)
In fact, git-remote-gits has unencrypted mode (should be compatible
with git-daemon). The reason its there is mainly for Unix domain
sockets support and more advanced IPv6 support (interface indexes and
numeric addresses actually work).
> (Is the unix auth via unix domain sockets part of GnuTLS?)
No, that server-only feature is part of the OS itself. In fact, it
needs no client-side support.
> That's another story. I think that it would be possible nowadays
> to implement gits:// (in both ways) via core.gitproxy and a server-side
> wrapper program (stunnel or else), but that has the disadvantage of
> being unable to just provide a clone url without installing special
> software besides git.
GIT_PROXY abuse? There are even better ways: smart transport remote
helpers (in next I think). Git can actually dispatch those (and yes,
that's exactly what this uses).
And gits:// client is also buildable selfstanding. That would require
new client software, but its still nicer than GIT_PROXY abuse.
Another problem with GIT_PROXY abuse: How to deal with potentially
multiple custom protocols. Remote helpers can deal with that nicely.
> ...
> > The authentication support for smart-http seems pretty bad (making the
> > old mistake of not binding authentications).
>
> Mind to explain 'binding authentications'?
Actually, that was little badly choosen term and not the true problem,
but the basic problem is that one peer has to trust the the other peer's
authentication for security of its own authentication.
In how authentications used by gits:// are designed, even if client doesn't
detect trying to authenticate with attacker, the attacker doesn't get any
replayable credentials without breaking crypto keys (as opposed to just
passwords). This holds true even for password authentication (PAKE-type
scheme is used).
HTTP basic auth can be trivially sniffed if attacker can become other end
of the encrypted link (crypto is by far the strongest link...). Digest auth
is harder, but its essentially brute force against password (as opposed to
trying to break a key).
-Ilari
^ permalink raw reply
* [PATCH v2 2/3] strbuf: add strbuf_addbuf_percentquote
From: Jeff King @ 2010-01-13 17:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Adam Megacz, git
In-Reply-To: <20100113173408.GA16652@coredump.intra.peff.net>
This is handy for creating strings which will be fed to
strbuf_expand or printf.
Signed-off-by: Jeff King <peff@coredump.intra.peff.net>
---
Changes since v1:
- better name
- style: s/dest/dst/
- const src
- no infinite loop for src == dst
Documentation/technical/api-strbuf.txt | 7 +++++++
strbuf.c | 11 +++++++++++
strbuf.h | 1 +
3 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/Documentation/technical/api-strbuf.txt b/Documentation/technical/api-strbuf.txt
index 3b1da10..afe2759 100644
--- a/Documentation/technical/api-strbuf.txt
+++ b/Documentation/technical/api-strbuf.txt
@@ -218,6 +218,13 @@ which can be used by the programmer of the callback as she sees fit.
placeholder and replacement string. The array needs to be
terminated by an entry with placeholder set to NULL.
+`strbuf_addbuf_percentquote`::
+
+ Append the contents of one strbuf to another, quoting any
+ percent signs ("%") into double-percents ("%%") in the
+ destination. This is useful for literal data to be fed to either
+ strbuf_expand or to the *printf family of functions.
+
`strbuf_addf`::
Add a formatted string to the buffer.
diff --git a/strbuf.c b/strbuf.c
index 6cbc1fc..0c46054 100644
--- a/strbuf.c
+++ b/strbuf.c
@@ -257,6 +257,17 @@ size_t strbuf_expand_dict_cb(struct strbuf *sb, const char *placeholder,
return 0;
}
+void strbuf_addbuf_percentquote(struct strbuf *dst, const struct strbuf *src)
+{
+ int i;
+ assert(dst != src);
+ for (i = 0; i < src->len; i++) {
+ if (src->buf[i] == '%')
+ strbuf_addch(dst, '%');
+ strbuf_addch(dst, src->buf[i]);
+ }
+}
+
size_t strbuf_fread(struct strbuf *sb, size_t size, FILE *f)
{
size_t res;
diff --git a/strbuf.h b/strbuf.h
index fa07ecf..84ac942 100644
--- a/strbuf.h
+++ b/strbuf.h
@@ -116,6 +116,7 @@ struct strbuf_expand_dict_entry {
const char *value;
};
extern size_t strbuf_expand_dict_cb(struct strbuf *sb, const char *placeholder, void *context);
+extern void strbuf_addbuf_percentquote(struct strbuf *dst, const struct strbuf *src);
__attribute__((format (printf,2,3)))
extern void strbuf_addf(struct strbuf *sb, const char *fmt, ...);
--
1.6.6.140.g92e4d.dirty
^ permalink raw reply related
* [PATCH v2 3/3] commit: show interesting ident information in summary
From: Jeff King @ 2010-01-13 17:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Adam Megacz, git
In-Reply-To: <20100113173408.GA16652@coredump.intra.peff.net>
There are a few cases of user identity information that we
consider interesting:
1. When the author and committer identities do not match.
2. When the committer identity was picked automatically
from the username, hostname and GECOS information.
In these cases, we already show the information in the
commit message template. However, users do not always see
that template because they might use "-m" or "-F". With this
patch, we show these interesting cases after the commit,
along with the subject and change summary. The new output
looks like:
$ git commit \
-m "federalist papers" \
--author='Publius <alexander@hamilton.com>'
[master 3d226a7] federalist papers
Author: Publius <alexander@hamilton.com>
1 files changed, 1 insertions(+), 0 deletions(-)
for case (1), and:
$ git config --global --unset user.name
$ git config --global --unset user.email
$ git commit -m foo
[master 7c2a927] foo
Committer: Jeff King <peff@c-71-185-130-222.hsd1.va.comcast.net>
Your name and email address were configured automatically based
on your username and hostname. Please check that they are accurate.
You can suppress this message by setting them explicitly:
git config --global user.name Your Name
git config --global user.email you@example.com
If the identity used for this commit is wrong, you can fix it with:
git commit --amend --author='Your Name <you@example.com>'
1 files changed, 1 insertions(+), 0 deletions(-)
for case (2).
Signed-off-by: Jeff King <peff@coredump.intra.peff.net>
---
Changes since v1:
- rebase on v2 2/3 for function name change
- gigantic warning message
I have mixed feelings on the warning message, as I mentioned elsewhere
in the thread.
Also, if you run the "commit --amend" advice immediately (without fixing
your config), you will still have a bogus committer field. Alternate
advice could be:
If the identity used for this commit is wrong, you can fix it (after
having set your identity as above) with:
git commit --amend --reset-author
I dunno which is better. I went with what I did because it is something
the user can immediately do to fix this commit before they forget (of
course, they probably would just run the "git config" commands,
immediately, too...).
builtin-commit.c | 39 ++++++++++++++++++++++++++++++++++++---
t/t7501-commit.sh | 6 +++++-
2 files changed, 41 insertions(+), 4 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 073fe90..3fa9b39 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -36,6 +36,18 @@ static const char * const builtin_status_usage[] = {
NULL
};
+static const char implicit_ident_advice[] =
+"Your name and email address were configured automatically based\n"
+"on your username and hostname. Please check that they are accurate.\n"
+"You can suppress this message by setting them explicitly:\n"
+"\n"
+" git config --global user.name Your Name\n"
+" git config --global user.email you@example.com\n"
+"\n"
+"If the identity used for this commit is wrong, you can fix it with:\n"
+"\n"
+" git commit --amend --author='Your Name <you@example.com>'\n";
+
static unsigned char head_sha1[20];
static char *use_message_buffer;
static const char commit_editmsg[] = "COMMIT_EDITMSG";
@@ -1046,9 +1058,12 @@ static void print_summary(const char *prefix, const unsigned char *sha1)
{
struct rev_info rev;
struct commit *commit;
- static const char *format = "format:%h] %s";
+ struct strbuf format = STRBUF_INIT;
unsigned char junk_sha1[20];
const char *head = resolve_ref("HEAD", junk_sha1, 0, NULL);
+ struct pretty_print_context pctx = {0};
+ struct strbuf author_ident = STRBUF_INIT;
+ struct strbuf committer_ident = STRBUF_INIT;
commit = lookup_commit(sha1);
if (!commit)
@@ -1056,6 +1071,23 @@ static void print_summary(const char *prefix, const unsigned char *sha1)
if (!commit || parse_commit(commit))
die("could not parse newly created commit");
+ strbuf_addstr(&format, "format:%h] %s");
+
+ format_commit_message(commit, "%an <%ae>", &author_ident, &pctx);
+ format_commit_message(commit, "%cn <%ce>", &committer_ident, &pctx);
+ if (strbuf_cmp(&author_ident, &committer_ident)) {
+ strbuf_addstr(&format, "\n Author: ");
+ strbuf_addbuf_percentquote(&format, &author_ident);
+ }
+ 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);
+ }
+ strbuf_release(&author_ident);
+ strbuf_release(&committer_ident);
+
init_revisions(&rev, prefix);
setup_revisions(0, NULL, &rev, NULL);
@@ -1066,7 +1098,8 @@ static void print_summary(const char *prefix, const unsigned char *sha1)
rev.verbose_header = 1;
rev.show_root_diff = 1;
- get_commit_format(format, &rev);
+ get_commit_format(format.buf, &rev);
+ strbuf_release(&format);
rev.always_show_header = 0;
rev.diffopt.detect_rename = 1;
rev.diffopt.rename_limit = 100;
@@ -1085,7 +1118,7 @@ static void print_summary(const char *prefix, const unsigned char *sha1)
struct pretty_print_context ctx = {0};
struct strbuf buf = STRBUF_INIT;
ctx.date_mode = DATE_NORMAL;
- format_commit_message(commit, format + 7, &buf, &ctx);
+ format_commit_message(commit, format.buf + 7, &buf, &ctx);
printf("%s\n", buf.buf);
strbuf_release(&buf);
}
diff --git a/t/t7501-commit.sh b/t/t7501-commit.sh
index a529701..7940901 100755
--- a/t/t7501-commit.sh
+++ b/t/t7501-commit.sh
@@ -117,7 +117,11 @@ test_expect_success \
test_expect_success \
"overriding author from command line" \
"echo 'gak' >file && \
- git commit -m 'author' --author 'Rubber Duck <rduck@convoy.org>' -a"
+ git commit -m 'author' --author 'Rubber Duck <rduck@convoy.org>' -a >output 2>&1"
+
+test_expect_success \
+ "commit --author output mentions author" \
+ "grep Rubber.Duck output"
test_expect_success PERL \
"interactive add" \
--
1.6.6.140.g92e4d.dirty
^ permalink raw reply related
* workflow and repository orginization for tracking router configs
From: david @ 2010-01-13 18:26 UTC (permalink / raw)
To: git
I need to track router/firewall configs for several hundred to a few
thousand devices.
For each device the config is a single file.
Each device is updated independantly of the others.
The configs diff well not only against prior versions but against each
other.
The different devices are accessable (in many cases via serial ports) from
different boxes (in different datacenters in many cases)
I need to data to be replicated across many locations
I want to be able to easily/quickly track changes to a particular device,
and compare different devices against each other.
I am thinking that a DVCS like git may be a good fit for this situation. I
can do commits on the boxes that can directly access the devices, and then
do fetches/pulls between boxes to make sure that every box has the full
history of every device.
The question is, what is the best way to orginize this data.
One approach is to have a seperate branch for each device.
This has the advantage that each branch can have a new config committed
independantly of the others, making pulls/fetches trivial
Another approach is to have one branch with a different file for each
device.
This is easy for people to understand, but it seems to me that it would
make pulling from different boxes that updated different files an issue,
as well as adding confustion over which commit is related to which device.
Any thoughts or suggestions on what people think would work well? (both
from a usability and from an efficiancy point of view)
David Lang
^ permalink raw reply
* Re: [RFC 0/2] Git-over-TLS (gits://) client side support
From: Andreas Krey @ 2010-01-13 18:35 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: Nguyen Thai Ngoc Duy, git
In-Reply-To: <20100113173610.GA7609@Knoppix>
On Wed, 13 Jan 2010 19:36:10 +0000, Ilari Liusvaara wrote:
...
> That would violate layering badly. You need to decode the request
> first before you can authorize. And the git daemon does that.
Well, yes. The script hackery would just decide between 'is allowed
to read (or write commits)' and 'is allowed to modify refs'. On the
other hand, git-daemon does not do fine-grained (read: per-branch)
access control, you'd only prevent pushing commits at all.
...
> > (Is the unix auth via unix domain sockets part of GnuTLS?)
>
> No, that server-only feature is part of the OS itself. In fact, it
> needs no client-side support.
Ok, then I'll be really interested in the server-side support and
the man pages on the whole stuff. Especially in how this is going
to be different from what ssh:// does or can do.
...
> GIT_PROXY abuse? There are even better ways: smart transport remote
> helpers (in next I think). Git can actually dispatch those (and yes,
> that's exactly what this uses).
Yeah, since the last mail I noticed that gitproxy is not quite what
some google hits suggest, and should have read the patch in some
more detail to find that gits is a remote helper.
Please consider my objections revoked, other than the claim that
it could be done with stunnel, however ugly that would be.
...
> Actually, that was little badly choosen term and not the true problem,
> but the basic problem is that one peer has to trust the the other peer's
> authentication for security of its own authentication.
I don't see how that would endanger the standard certificate auth in ssl
(client or server).
...
> HTTP basic auth can be trivially sniffed if attacker can become other end
> of the encrypted link
Of course, you have another problem in that case...also I'd personally
like to rely on ssl client certificates when using https.
Andreas
^ permalink raw reply
* Re: [PATCH 1/5] MSVC: Windows-native implementation for subset of Pthreads API
From: Johannes Sixt @ 2010-01-13 18:40 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: kusmabite, msysgit, git, Andrzej K. Haczewski
In-Reply-To: <20100113125312.GD10586@dpotapov.dyndns.org>
On Mittwoch, 13. Januar 2010, Dmitry Potapov wrote:
> On Tue, Jan 12, 2010 at 10:13:38PM +0100, Johannes Sixt wrote:
> > In particular, it doesn't say that it is atomic WRT reads such as we have
> >
> > here:
> > > >> + /* we're done waiting, so make sure we decrease waiters count
> > > >> */ + EnterCriticalSection(&cond->waiters_lock);
> > > >> + --cond->waiters;
> > > >> + LeaveCriticalSection(&cond->waiters_lock);
>
> and these lines should be replaced with
>
> InterlockedDecrement(&cond->waiters)
Ah, yes, of course. I quoted the wrong section, sorry. By "atomic WRT reads" I
meant this snippet:
>> + EnterCriticalSection(&cond->waiters_lock);
>> + have_waiters = cond->waiters > 0;
>> + LeaveCriticalSection(&cond->waiters_lock);
Is there "InterlockedRead()"? I suppose no, but I would get confirmation that
a simple memory mov instruction is atomic WRT Interlocked* functions.
-- Hannes
^ permalink raw reply
* Re: [PATCH v2 3/3] commit: show interesting ident information in summary
From: Jeff King @ 2010-01-13 18:45 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Junio C Hamano, Adam Megacz, git
In-Reply-To: <1DDB570B-350A-40A0-B6E4-ADBDF4BE6BD2@wincent.com>
On Wed, Jan 13, 2010 at 07:39:47PM +0100, Wincent Colaiuta wrote:
> > Your name and email address were configured automatically based
> > on your username and hostname. Please check that they are accurate.
> > You can suppress this message by setting them explicitly:
> >
> > git config --global user.name Your Name
> > git config --global user.email you@example.com
> >
> > If the identity used for this commit is wrong, you can fix it with:
> >
> > git commit --amend --author='Your Name <you@example.com>'
> >
> > 1 files changed, 1 insertions(+), 0 deletions(-)
>
> I'll never see this message myself, but I think you could (and
> perhaps should) replace almost all of that with:
>
> Your name and email address were configured automatically.
> See "git config help" for information on setting them explicitly
> or "git commit help" if you wish to amend this commit.
I don't have a huge problem with your wording, except that it needs
s/(\w+) help/help \1/.
Mainly I was trying to hand-hold because not having this information set
up means it may be your first commit, and you are probably a bit
clueless (the exceptions are people who have been using git, but are
seeing this new behavior in their new version, and people who have git
configured on another machine but are using _this_ machine for the first
time).
As far as reducing verbosity goes, I don't think there is much point.
Both of ours are huge and annoying enough to nag you into setting up
your config, so the user is only likely to see it a few times.
> But like I said, seeing as I won't see the message its verbosity won't
> directly affect me.
I am also in this boat. :)
-Peff
^ permalink raw reply
* Re: [PATCH v2 3/3] commit: show interesting ident information in summary
From: Wincent Colaiuta @ 2010-01-13 18:39 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Adam Megacz, git
In-Reply-To: <20100113173951.GC16786@coredump.intra.peff.net>
El 13/01/2010, a las 18:39, Jeff King escribió:
> $ git config --global --unset user.name
> $ git config --global --unset user.email
> $ git commit -m foo
> [master 7c2a927] foo
> Committer: Jeff King <peff@c-71-185-130-222.hsd1.va.comcast.net>
> Your name and email address were configured automatically based
> on your username and hostname. Please check that they are accurate.
> You can suppress this message by setting them explicitly:
>
> git config --global user.name Your Name
> git config --global user.email you@example.com
>
> If the identity used for this commit is wrong, you can fix it with:
>
> git commit --amend --author='Your Name <you@example.com>'
>
> 1 files changed, 1 insertions(+), 0 deletions(-)
I'll never see this message myself, but I think you could (and perhaps
should) replace almost all of that with:
Your name and email address were configured automatically.
See "git config help" for information on setting them explicitly
or "git commit help" if you wish to amend this commit.
But like I said, seeing as I won't see the message its verbosity won't
directly affect me.
Cheers,
Wincent
^ permalink raw reply
* [PATCH] Show submodules as modified when they contain a dirty work tree
From: Jens Lehmann @ 2010-01-13 18:59 UTC (permalink / raw)
To: Junio C Hamano
Cc: Git Mailing List, Johannes Schindelin, Shawn O. Pearce,
Heiko Voigt, Lars Hjemli
In-Reply-To: <7vbpgyqy4a.fsf@alter.siamese.dyndns.org>
Until now a submodule only then showed up as modified in the supermodule
when the last commit in the submodule differed from the one in the index
or the diffed against commit of the superproject. A dirty work tree
containing new untracked or modified files in a submodule was
undetectable when looking at it from the superproject.
Now git status and git diff (against the work tree) in the superproject
will also display submodules as modified when they contain untracked or
modified files, even if the compared ref matches the HEAD of the
submodule.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---
Thanks for your review, here is the updated patch. Changes to the RFC
version are:
- Removed check for a dangling HEAD (now the testsuite runs fine)
- Reworded the commit message
- Inlined is_submodule_working_directory_dirty() into
is_submodule_modified()
- The new code will only be called when refs did match (when they
didn't the submodule will already show up as modified)
What do you think?
diff-lib.c | 4 ++-
submodule.c | 49 +++++++++++++++++++++++++++++++++++++++++++
submodule.h | 1 +
t/t7506-status-submodule.sh | 31 ++++++++++++++++++++++++++-
4 files changed, 83 insertions(+), 2 deletions(-)
diff --git a/diff-lib.c b/diff-lib.c
index 1c7e652..6918920 100644
--- a/diff-lib.c
+++ b/diff-lib.c
@@ -159,7 +159,7 @@ int run_diff_files(struct rev_info *revs, unsigned int option)
continue;
}
- if (ce_uptodate(ce) || ce_skip_worktree(ce))
+ if ((ce_uptodate(ce) && !S_ISGITLINK(ce->ce_mode)) || ce_skip_worktree(ce))
continue;
/* If CE_VALID is set, don't look at workdir for file removal */
@@ -176,6 +176,8 @@ int run_diff_files(struct rev_info *revs, unsigned int option)
continue;
}
changed = ce_match_stat(ce, &st, ce_option);
+ if (S_ISGITLINK(ce->ce_mode) && !changed)
+ changed = is_submodule_modified(ce->name);
if (!changed) {
ce_mark_uptodate(ce);
if (!DIFF_OPT_TST(&revs->diffopt, FIND_COPIES_HARDER))
diff --git a/submodule.c b/submodule.c
index 86aad65..3f851de 100644
--- a/submodule.c
+++ b/submodule.c
@@ -4,6 +4,7 @@
#include "diff.h"
#include "commit.h"
#include "revision.h"
+#include "run-command.h"
int add_submodule_odb(const char *path)
{
@@ -112,3 +113,51 @@ void show_submodule_summary(FILE *f, const char *path,
}
strbuf_release(&sb);
}
+
+int is_submodule_modified(const char *path)
+{
+ int len;
+ struct child_process cp;
+ const char *argv[] = {
+ "status",
+ "--porcelain",
+ NULL,
+ };
+ char *env[3];
+ struct strbuf buf = STRBUF_INIT;
+
+ strbuf_addf(&buf, "%s/.git/", path);
+ if (!is_directory(buf.buf)) {
+ strbuf_release(&buf);
+ /* The submodule is not checked out, so it is not modified */
+ return 0;
+
+ }
+ strbuf_reset(&buf);
+
+ strbuf_addf(&buf, "GIT_WORK_TREE=%s", path);
+ env[0] = strbuf_detach(&buf, NULL);
+ strbuf_addf(&buf, "GIT_DIR=%s/.git", path);
+ env[1] = strbuf_detach(&buf, NULL);
+ env[2] = NULL;
+
+ memset(&cp, 0, sizeof(cp));
+ cp.argv = argv;
+ cp.env = (const char *const *)env;
+ cp.git_cmd = 1;
+ cp.no_stdin = 1;
+ cp.out = -1;
+ if (start_command(&cp))
+ die("Could not run git status --porcelain");
+
+ len = strbuf_read(&buf, cp.out, 1024);
+ close(cp.out);
+
+ if (finish_command(&cp))
+ die("git status --porcelain failed");
+
+ free(env[0]);
+ free(env[1]);
+ strbuf_release(&buf);
+ return len != 0;
+}
diff --git a/submodule.h b/submodule.h
index 4c0269d..0773121 100644
--- a/submodule.h
+++ b/submodule.h
@@ -4,5 +4,6 @@
void show_submodule_summary(FILE *f, const char *path,
unsigned char one[20], unsigned char two[20],
const char *del, const char *add, const char *reset);
+int is_submodule_modified(const char *path);
#endif
diff --git a/t/t7506-status-submodule.sh b/t/t7506-status-submodule.sh
index 3ca17ab..47e205b 100755
--- a/t/t7506-status-submodule.sh
+++ b/t/t7506-status-submodule.sh
@@ -10,8 +10,12 @@ test_expect_success 'setup' '
: >bar &&
git add bar &&
git commit -m " Add bar" &&
+ : >foo &&
+ git add foo &&
+ git commit -m " Add foo" &&
cd .. &&
- git add sub &&
+ echo output > .gitignore
+ git add sub .gitignore &&
git commit -m "Add submodule sub"
'
@@ -23,6 +27,31 @@ test_expect_success 'commit --dry-run -a clean' '
git commit --dry-run -a |
grep "nothing to commit"
'
+
+echo "changed" > sub/foo
+test_expect_success 'status with modified file in submodule' '
+ git status | grep "modified: sub"
+'
+test_expect_success 'status with modified file in submodule (porcelain)' '
+ git status --porcelain >output &&
+ diff output - <<-EOF
+ M sub
+EOF
+'
+(cd sub && git checkout foo)
+
+echo "content" > sub/new-file
+test_expect_success 'status with untracked file in submodule' '
+ git status | grep "modified: sub"
+'
+test_expect_success 'status with untracked file in submodule (porcelain)' '
+ git status --porcelain >output &&
+ diff output - <<-EOF
+ M sub
+EOF
+'
+rm sub/new-file
+
test_expect_success 'rm submodule contents' '
rm -rf sub/* sub/.git
'
--
1.6.6.203.g28a8ba.dirty
^ permalink raw reply related
* Re: [PATCH v2 3/3] commit: show interesting ident information in summary
From: Wincent Colaiuta @ 2010-01-13 18:50 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Adam Megacz, git
In-Reply-To: <20100113184510.GA22849@coredump.intra.peff.net>
El 13/01/2010, a las 19:45, Jeff King escribió:
> On Wed, Jan 13, 2010 at 07:39:47PM +0100, Wincent Colaiuta wrote:
>
>>> Your name and email address were configured automatically based
>>> on your username and hostname. Please check that they are accurate.
>>> You can suppress this message by setting them explicitly:
>>>
>>> git config --global user.name Your Name
>>> git config --global user.email you@example.com
>>>
>>> If the identity used for this commit is wrong, you can fix it with:
>>>
>>> git commit --amend --author='Your Name <you@example.com>'
>>>
>>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> I'll never see this message myself, but I think you could (and
>> perhaps should) replace almost all of that with:
>>
>> Your name and email address were configured automatically.
>> See "git config help" for information on setting them explicitly
>> or "git commit help" if you wish to amend this commit.
>
> I don't have a huge problem with your wording, except that it needs
> s/(\w+) help/help \1/.
Whoops.
> Mainly I was trying to hand-hold because not having this information
> set
> up means it may be your first commit, and you are probably a bit
> clueless (the exceptions are people who have been using git, but are
> seeing this new behavior in their new version, and people who have git
> configured on another machine but are using _this_ machine for the
> first
> time).
Fair enough, but I'm sighing here at the thought of people jumping in
and using git commands without even having looked at _any_ of the
zillions of "your first 10 minutes with Git" tutorials out there,
which pretty much _all_ start with how to set up your user.name and
user.email...
Cheers,
Wincent
^ permalink raw reply
* Re: [RFC 0/2] Git-over-TLS (gits://) client side support
From: Avery Pennarun @ 2010-01-13 19:11 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: Nguyen Thai Ngoc Duy, git
In-Reply-To: <20100113135753.GA7095@Knoppix>
On Wed, Jan 13, 2010 at 8:57 AM, Ilari Liusvaara
<ilari.liusvaara@elisanet.fi> wrote:
> On Wed, Jan 13, 2010 at 08:39:12PM +0700, Nguyen Thai Ngoc Duy wrote:
>>
>> Can we rely on an external program, like stunnel, to do the job instead?
>
> No. The way authentication is done is very unusual. I don't think stunnel (or
> anything else) can deal with such modes. And the reason authentications are
> done like they are done in order to minimize points of failure (getting
> really annoyed at failure modes sshd introduced was one big reason for
> writing this).
>
> I _definitely_ do not want to mess with X.509. And its not just about me
> messing with it, it is also about pushing it to users.
>
> And one would need custom daemon anyway even if one used stunnel.
> git-daemon just can't deal with authentication data.
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.
#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? 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.
Have fun,
Avery
^ permalink raw reply
* Re: [RFC 0/2] Git-over-TLS (gits://) client side support
From: Ilari Liusvaara @ 2010-01-13 19:18 UTC (permalink / raw)
To: Andreas Krey; +Cc: Nguyen Thai Ngoc Duy, git
In-Reply-To: <20100113183520.GA23674@inner.home.ulmdo.de>
On Wed, Jan 13, 2010 at 07:35:20PM +0100, Andreas Krey wrote:
> On Wed, 13 Jan 2010 19:36:10 +0000, Ilari Liusvaara wrote:
>
> Ok, then I'll be really interested in the server-side support and
> the man pages on the whole stuff. Especially in how this is going
> to be different from what ssh:// does or can do.
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).
I found the intformation about how to forcibly get peer UID on Linux
from one secure programming HOWTO.
One other software that I know uses similar stuff is D-BUS. AFAIK, SSH
can't do it.
Essentially, it involves asking the kernel about UID the socket peer
runs as (with local sockets, kernel knows that information).
> 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 don't see how that would endanger the standard certificate auth in ssl
> (client or server).
It doesn't, but...
> 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?
-Ilari
^ permalink raw reply
* 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
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