Re: Git Daemon Dummy: 301 Redirects for git:// to https://
On Tue, Feb 23, 2016 at 4:11 PM, Jason A. Donenfeld wrote: > That's interesting. I didn't realize that even the smart protocol was > not as efficient as HTTP Can't type today. *as efficient as git:// -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git Daemon Dummy: 301 Redirects for git:// to https://
On Tue, Feb 23, 2016 at 11:51 AM, John Keeping wrote: > On Tue, Feb 23, 2016 at 03:32:02AM +0100, Jason A. Donenfeld wrote: > There's no license specified in the repo, it just says "All rights > reserved" in the .c file. I'm sure you intend it to be open source, but > it isn't unless a license is specified. https://git.zx2c4.com/git-daemon-dummy/commit/?id=a7ebbf5ab63cb2e95c38a58197cd2805a2deb56f There you go. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git Daemon Dummy: 301 Redirects for git:// to https://
On Tue, Feb 23, 2016 at 7:15 AM, Jeff King wrote: > > Yeah, the existence of HTTPS (and the fact that the same URL can be both > anonymous and authenticated) is nice. Unfortunately, git-over-https is > not as efficient as the other protocols, because it's not asynchronously > bi-directional. It would probably be relatively simple to make a > "gits://" protocol, but I think it would be more interesting still if we > could do git-over-websockets, to get the ubiquity benefits of HTTP. That's interesting. I didn't realize that even the smart protocol was not as efficient as HTTP, but that makes sense. git+ws:// would indeed be quite nice! > Darn printed books. I thought the Ministry of Truth was supposed to take > care of keeping our facts up to date. :-P -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Git Daemon Dummy: 301 Redirects for git:// to https://
Hi folks, In case anyone else finds this useful, I wrote this: https://git.zx2c4.com/git-daemon-dummy/about/ It's an epoll-based responder for git:// that simply returns an error telling users of a new URI. The purpose is to phase out git-daemon in favor of more secure TLS/HTTPS endpoints. With HTTPS certificates now being free, seems like this could be useful. My personal motivation is that I'd like to just totally kill the git-daemon service, but somebody hard coded a URI of mine into a real printed textbook [1], so I don't want it to go stale suddenly. So, I need some way of informing users of the new URI. Let me know what you think. Jason [1] https://books.google.fr/books?id=kJsQAwAAQBAJ&pg=PA314&lpg=PA314&dq=git://git.zx2c4.com&source=bl&ots=W6M9TlYzCY&sig=g-PY0glN2ddWygtFDLiHgbiC69I&hl=en&sa=X&redir_esc=y#v=onepage&q=git%3A%2F%2Fgit.zx2c4.com&f=false -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git-send-email doesn't deal with quoted names
Hi,
My commit author name is "Jason A. Donenfeld". Because this has a dot,
SMTP handling likes to put it in quotes.
git-send-email has this line:
if (defined $author and $author ne $sender) {
With my name, this always winds up false, because it's comparing
'"Jason A. Donenfeld" ' with 'Jason A. Donenfeld
'.
So, the logic needs to be fixed somehow.
Thanks,
Jason
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] config: allow inaccessible configuration under $HOME
Jonathan's patch would indeed be nice. In cgit, we are forced to do
ugly things like this:
/* Do not look in /etc/ for gitconfig and gitattributes. */
setenv("GIT_CONFIG_NOSYSTEM", "1", 1);
setenv("GIT_ATTR_NOSYSTEM", "1", 1);
/* We unset HOME and XDG_CONFIG_HOME before calling the git
setup function
* so that we don't make unneccessary filesystem accesses. */
user_home = getenv("HOME");
xdg_home = getenv("XDG_CONFIG_HOME");
unsetenv("HOME");
unsetenv("XDG_CONFIG_HOME");
/* Setup the git directory and initialize the notes system.
Both of these
* load local configuration from the git repository, so we do
them both while
* the HOME variables are unset. */
setup_git_directory_gently(&nongit);
init_display_notes(NULL);
/* We restore the unset variables afterward. */
if (user_home)
setenv("HOME", user_home, 1);
if (xdg_home)
setenv("XDG_CONFIG_HOME", xdg_home, 1);
A big nasty guard around the git setup function, so that we don't error out.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] Revert "graph.c: mark private file-scope symbols as static"
On Sun, Mar 3, 2013 at 10:42 PM, Junio C Hamano wrote: > I suspect that many people outside CGit circle may not know who this > Jason > That active contributor is Jason. The repository has also been moved > to Jason's http://git.zx2c4.com/cgit/ > So, thanks, Jason and John for your efforts. Hey folks, Sorry for not providing the explanation myself, but Junio -- thanks for introducing me! Jason -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] Revert "graph.c: mark private file-scope symbols as static"
Signed-off-by: Jason A. Donenfeld
On Sun, Mar 3, 2013 at 7:03 PM, John Keeping wrote:
> This reverts commit ba35480439d05b8f6cca50527072194fe3278bbb.
>
> CGit uses these symbols to output the correct HTML around graph
> elements. Making these symbols private means that CGit cannot be
> updated to use Git 1.8.0 or newer, so let's not do that.
>
> On top of the revert, also add comments so that we avoid reintroducing
> this problem in the future and suggest to those modifying this API
> that they might want to discuss it with the CGit developers.
>
> Signed-off-by: John Keeping
> ---
> On Sun, Mar 03, 2013 at 03:32:08PM -0800, Junio C Hamano wrote:
>> John Keeping writes:
>> > I think CGit expects to have to respond to changes in Git, so I don't
>> > think it's worth restricting changes in Git for that reason - it's just
>> > a case of exposing useful functionality somehow.
>>
>> I think you misread me.
>
> You're right - this makes more sense that what I originally thought you
> meant :-)
>
>> It is not about restricting. It is to use their expertise to come up
>> with generally more useful API than responding only to the immediate
>> need we see in in-tree users. We want a discussion/patch to update
>> the graph.c infrastructure to be Cc'ed to them.
>>
>> For example, with the current codeflow, the callers of these
>> functions we have in-tree may be limited to those in graph.c but if
>> there are legitimate reason CGit wants to call them from sideways,
>> perhaps there may be use cases in our codebase in the future to call
>> them from outside the normal graph.c codeflow.
>
> graph.c | 32 ++--
> graph.h | 33 +
> 2 files changed, 35 insertions(+), 30 deletions(-)
>
> diff --git a/graph.c b/graph.c
> index 2a3fc5c..b24d04c 100644
> --- a/graph.c
> +++ b/graph.c
> @@ -8,34 +8,6 @@
> /* Internal API */
>
> /*
> - * Output the next line for a graph.
> - * This formats the next graph line into the specified strbuf. It is not
> - * terminated with a newline.
> - *
> - * Returns 1 if the line includes the current commit, and 0 otherwise.
> - * graph_next_line() will return 1 exactly once for each time
> - * graph_update() is called.
> - */
> -static int graph_next_line(struct git_graph *graph, struct strbuf *sb);
> -
> -/*
> - * Set up a custom scheme for column colors.
> - *
> - * The default column color scheme inserts ANSI color escapes to colorize
> - * the graph. The various color escapes are stored in an array of strings
> - * where each entry corresponds to a color, except for the last entry,
> - * which denotes the escape for resetting the color back to the default.
> - * When generating the graph, strings from this array are inserted before
> - * and after the various column characters.
> - *
> - * This function allows you to enable a custom array of color escapes.
> - * The 'colors_max' argument is the index of the last "reset" entry.
> - *
> - * This functions must be called BEFORE graph_init() is called.
> - */
> -static void graph_set_column_colors(const char **colors, unsigned short
> colors_max);
> -
> -/*
> * Output a padding line in the graph.
> * This is similar to graph_next_line(). However, it is guaranteed to
> * never print the current commit line. Instead, if the commit line is
> @@ -90,7 +62,7 @@ enum graph_state {
> static const char **column_colors;
> static unsigned short column_colors_max;
>
> -static void graph_set_column_colors(const char **colors, unsigned short
> colors_max)
> +void graph_set_column_colors(const char **colors, unsigned short colors_max)
> {
> column_colors = colors;
> column_colors_max = colors_max;
> @@ -1144,7 +1116,7 @@ static void graph_output_collapsing_line(struct
> git_graph *graph, struct strbuf
> graph_update_state(graph, GRAPH_PADDING);
> }
>
> -static int graph_next_line(struct git_graph *graph, struct strbuf *sb)
> +int graph_next_line(struct git_graph *graph, struct strbuf *sb)
> {
> switch (graph->state) {
> case GRAPH_PADDING:
> diff --git a/graph.h b/graph.h
> index 19b0f66..0be62bd 100644
> --- a/graph.h
> +++ b/graph.h
> @@ -4,6 +4,25 @@
> /* A graph is a pointer to this opaque structure */
> struct git_graph;
>
> +/*
> + * Set up a custom scheme for column colors.
> + *
> + * The default column color scheme inserts ANSI color escapes to colorize
> + * the graph. The various color escapes are stored in an array of strings
> + * where each entry corresponds to a color, exce
