* Re: [BUG] gitweb: XSS vulnerability of RSS feed
From: Jakub Narębski @ 2012-11-13 15:19 UTC (permalink / raw)
To: Drew Northup
Cc: Jeff King, glpk xypron, git, Junio C Hamano,
Jason J Pyeron CTR (US), Andreas Schwab
In-Reply-To: <CAM9Z-nkuHj8MWLfWsvY=EqHXCUS+Pk5Ezv6m5J+cnh7cQHNc_g@mail.gmail.com>
On Tue, Nov 13, 2012 at 3:44 PM, Drew Northup <n1xim.email@gmail.com> wrote:
> On Mon, Nov 12, 2012 at 3:24 PM, Jeff King <peff@peff.net> wrote:
>> On Mon, Nov 12, 2012 at 01:55:46PM -0500, Drew Northup wrote:
>>> + # No XSS <script></script> inclusions
>>> + if ($input =~ m!(<script>)(.*)(</script>)!){
>>> + return undef;
>>> + }
>> This is the wrong fix for a few reasons:
>>
>> 1. It is on the input-validation side, whereas the real problem is on
>> the output-quoting side. Your patch means I could not access a file
>> called "<script>foo</script>". What we really want is to have the
>> unquoted name internally, but then make sure we quote it when
>> outputting as part of an HTML (or XML) file.
>
> I don't buy the argument that we don't need to clean up the input as
> well. There are scant few of us that are going to name a file
> "<script>alert("Something Awful")</script>" in this world (I am
> probably one of them). Input validation is key to keeping problems
> like this from coming up repeatedly as those writing the guts of
> programs are typically more interested in getting the "assigned task"
> done and reporting the output to the user in a safe manner.
Input cleanup or blacklisting *does not* prevent code injection (XSS
in this case). This is a myth.
Input validation has its place, and is done by gitweb when possible
(see e.g. evaluate_and_validate_params, validate_project, etc.).
But the proposed solution is not input validation.
'<script>alert("Something Awful")</script>' is a perfectly valid filename.
As is more realistic "<<create>>.uml" or "File > Open screenshot.png".
And last and most important you have to escape output anyway;
filename is not HTML. Without escaping it would be rendered incorrectly.
And HTML escaping prevents XSS.
>> I think the right answer is going to be a well-placed call to esc_html.
>> This already happens automatically when we go through the CGI
>> element-building functions, but obviously we failed to make the call
>> when building the output manually. This is a great reason why template
>> languages which default to safe expansion should always be used.
>> Unfortunately, gitweb is living in 1995 in terms of web frameworks.
>
> Escaping the output protects the user, but it DOES NOT protect the
> server. We MUST handle both possibilities.
Errr, what?
If you are thinking about shell injection, we are covered.
Gitweb uses list form of open which is for shell what prepared
statements are for SQL. In one or two cases where we need to
use pipe we do shell escaping.
> Besides, inserting one call to esc_html only fixes one attack path. I
> didn't look to see if all others were already covered.
They should be covered. This case slipped.
--
Jakub Narebski
^ permalink raw reply
* Commit message problem of reverting multiple commits
From: 乙酸鋰 @ 2012-11-13 15:15 UTC (permalink / raw)
To: git
Hi,
I ran git 1.8.0 command line
git revert --no-commit rev1 rev2
I see a prepared commit message like
Revert "<description from one commit>"
This reverts commit <SHA1 of one commit>.
The actual revert content is correct - it is all the relevant commits
that were selected. I expect the message to reflect this:
Revert "<description from commit1>", "<description from commit2>"
This reverts commits <SHA1 of commit1>, <SHA1 of commit2>.
Regards,
ch3cooli
^ permalink raw reply
* Re: Launch separate program for HTTPS prompt
From: Erik Faye-Lund @ 2012-11-13 15:07 UTC (permalink / raw)
To: 乙酸鋰; +Cc: GIT Mailing-list
In-Reply-To: <CAHtLG6Q2LANj8WPMsRzpzKZ=zPbLysSFWs0pxSPNj1j87d_LRw@mail.gmail.com>
Please don't cull the CC list or top-post. Other people might be
interested, and quoting inline will make it easier to understand what
you're replying to in that case. I've restored the CC-list and fixed
the quoting for you this time.
On Tue, Nov 13, 2012 at 3:58 PM, 乙酸鋰 <ch3cooli@gmail.com> wrote:
> 2012/11/13 Erik Faye-Lund <kusmabite@gmail.com>:
>> On Tue, Oct 23, 2012 at 4:48 PM, Matthieu Moy
>> <Matthieu.Moy@grenoble-inp.fr> wrote:
>>> 乙酸鋰 <ch3cooli@gmail.com> writes:
>>>
>>>> Hi,
>>>>
>>>> Could you launch a separate program for HTTPS prompt like SSH_ASKPASS?
>>>> This allows GUI programs to answer the trust or not, not via stdin.
>>>
>>> Read about credential helpers, this is what they are meant for, and they
>>> do launch separate programs.
>>>
>>
>> The prompting-support for credential helpers didn't survive the
>> inclusion; instead we have git_prompt() that consults GIT_ASKPASS and
>> SSH_ASKPASS or falls back to git_terminal_prompt().
>
> Sorry, I don't understand what you mean.
>
> But I am asking for a solution of for HTTPS prompt which is similar to
> the credential part.
Quote from Documentation/technical/api-credentials.txt:
"Credential helpers are programs executed by git to fetch or save
credentials from and to long-term storage (where "long-term" is simply
longer than a single git process; e.g., credentials may be stored
in-memory for a few minutes, or indefinitely on disk)."
In other words, credential helpers are not intended for prompting the
user for a username/password pair. Prompting was included in the first
credential-helper proposal, but it didn't survive into the inclusion.
But you can override credential queries by setting GIT_ASKPASS or
SSH_ASKPASS.
I don't know if the credential-system works or not when using
HTTP/HTTPS, it might be that cURL is the one that does the
credential-negotiating in that case. But that's not really related to
credential-helpers; it affects the whole credential-system.
^ permalink raw reply
* Re: Launch separate program for HTTPS prompt
From: Erik Faye-Lund @ 2012-11-13 14:51 UTC (permalink / raw)
To: Matthieu Moy; +Cc: 乙酸鋰, git
In-Reply-To: <vpq6261nt0x.fsf@grenoble-inp.fr>
On Tue, Oct 23, 2012 at 4:48 PM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> 乙酸鋰 <ch3cooli@gmail.com> writes:
>
>> Hi,
>>
>> Could you launch a separate program for HTTPS prompt like SSH_ASKPASS?
>> This allows GUI programs to answer the trust or not, not via stdin.
>
> Read about credential helpers, this is what they are meant for, and they
> do launch separate programs.
>
The prompting-support for credential helpers didn't survive the
inclusion; instead we have git_prompt() that consults GIT_ASKPASS and
SSH_ASKPASS or falls back to git_terminal_prompt().
^ permalink raw reply
* Re: [BUG] gitweb: XSS vulnerability of RSS feed
From: Drew Northup @ 2012-11-13 14:44 UTC (permalink / raw)
To: Jeff King
Cc: glpk xypron, git, jnareb, Junio C Hamano, Jason J Pyeron CTR (US),
Andreas Schwab
In-Reply-To: <20121112202413.GD4623@sigill.intra.peff.net>
On Mon, Nov 12, 2012 at 3:24 PM, Jeff King <peff@peff.net> wrote:
> On Mon, Nov 12, 2012 at 01:55:46PM -0500, Drew Northup wrote:
>
>> On Sun, Nov 11, 2012 at 6:28 PM, glpk xypron <xypron.glpk@gmx.de> wrote:
>> > Gitweb can be used to generate an RSS feed.
>> >
>> > Arbitrary tags can be inserted into the XML document describing
>> > the RSS feed by careful construction of the URL.
>> [...]
>> Something like this may be useful to defuse the "file" parameter, but
>> I presume a more definitive fix is in order...
>>
>> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
>> index 10ed9e5..af93e65 100755
>> --- a/gitweb/gitweb.perl
>> +++ b/gitweb/gitweb.perl
>> @@ -1447,6 +1447,10 @@ sub validate_pathname {
>> if ($input =~ m!\0!) {
>> return undef;
>> }
>> + # No XSS <script></script> inclusions
>> + if ($input =~ m!(<script>)(.*)(</script>)!){
>> + return undef;
>> + }
>> return $input;
>> }
>
> This is the wrong fix for a few reasons:
>
> 1. It is on the input-validation side, whereas the real problem is on
> the output-quoting side. Your patch means I could not access a file
> called "<script>foo</script>". What we really want is to have the
> unquoted name internally, but then make sure we quote it when
> outputting as part of an HTML (or XML) file.
I don't buy the argument that we don't need to clean up the input as
well. There are scant few of us that are going to name a file
"<script>alert("Something Awful")</script>" in this world (I am
probably one of them). Input validation is key to keeping problems
like this from coming up repeatedly as those writing the guts of
programs are typically more interested in getting the "assigned task"
done and reporting the output to the user in a safe manner.
> 2. Script tags are only part of the problem. They are what make it
> obviously a security vulnerability, but it is equally incorrect for
> us to show the filename "<b>foo</b>" as bold. I would also not be
> surprised if there are other cross-site attacks one can do without
> using <script>.
Yes, there are. You are typically concerned with anything including
the following:
(1) Executable stuff;
(2) Out of nowhere resources that can reference executable stuff
(style / CSS, iframe, script includes);
(3) Media and other things that activate browser plugins directly.
> 3. Your filter is too simplistic. At the very least, it would not
> filter out "<SCRIPT>". I am not up to date on all of the
> sneaking-around-HTML-filters attacks that are available these days,
> but I wonder if one could also get around it using XML entities or
> similar.
You will note that I said "a more definitive fix is in order" in my
original. In other words, I claimed it to be utterly incomplete to
start with. I wanted to get some thought going about input validation
(in particular since I am not a perl guru of any sort whatsoever--the
fair number of things I've written from scratch or mangled into shape
notwithstanding).
> I think the right answer is going to be a well-placed call to esc_html.
> This already happens automatically when we go through the CGI
> element-building functions, but obviously we failed to make the call
> when building the output manually. This is a great reason why template
> languages which default to safe expansion should always be used.
> Unfortunately, gitweb is living in 1995 in terms of web frameworks.
Escaping the output protects the user, but it DOES NOT protect the
server. We MUST handle both possibilities.
Besides, inserting one call to esc_html only fixes one attack path. I
didn't look to see if all others were already covered.
--
-Drew Northup
--------------------------------------------------------------
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
^ permalink raw reply
* Re: [PATCH 0/5] win32: support echo for terminal-prompt
From: Erik Faye-Lund @ 2012-11-13 14:04 UTC (permalink / raw)
To: git, msysgit; +Cc: peff
In-Reply-To: <1352815288-3996-1-git-send-email-kusmabite@gmail.com>
Sorry, I messed up the subject (lacking RFC-prefix), so I aborted
after sending the cover-letter. I'll resend with a proper prefix right
away.
On Tue, Nov 13, 2012 at 3:01 PM, Erik Faye-Lund <kusmabite@gmail.com> wrote:
> We currently only support getpass, which does not echo at all, for
> git_terminal_prompt on Windows. The Windows console is perfectly
> capable of doing this, so let's make it so.
>
> This implementation tries to reuse the /dev/tty-code as much as
> possible.
>
> The big reason that this becomes a bit hairy is that Ctrl+C needs
> to be handled correctly, so we don't leak the console state to a
> non-echoing setting when a user aborts.
>
> Windows makes this bit a little bit tricky, in that we need to
> implement SIGINT for fgetc. However, I suspect that this is a good
> thing to do in the first place.
>
> An earlier iteration was also breifly discussed here:
> http://mid.gmane.org/CABPQNSaUCEDU4+2N63n0k_XwSXOP_iFZG3GEYSPSBPcSVV8wRQ@mail.gmail.com
>
> The series can also be found here, only with an extra patch that
> makes the (interactive) testing a bit easier:
>
> https://github.com/kusma/git/tree/work/terminal-cleanup
>
> Erik Faye-Lund (5):
> mingw: make fgetc raise SIGINT if apropriate
> compat/terminal: factor out echo-disabling
> compat/terminal: separate input and output handles
> mingw: reuse tty-version of git_terminal_prompt
> mingw: get rid of getpass implementation
>
> compat/mingw.c | 91 +++++++++++++++++++++++++++-----------
> compat/mingw.h | 8 +++-
> compat/terminal.c | 129 ++++++++++++++++++++++++++++++++++++++++--------------
> 3 files changed, 169 insertions(+), 59 deletions(-)
>
> --
> 1.8.0.7.gbeffeda
>
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
^ permalink raw reply
* [PATCH/RFC 5/5] mingw: get rid of getpass implementation
From: Erik Faye-Lund @ 2012-11-13 14:04 UTC (permalink / raw)
To: git, msysgit; +Cc: peff
In-Reply-To: <1352815447-8824-1-git-send-email-kusmabite@gmail.com>
There's no remaining call-sites, and as pointed out in the
previous commit message, it's not quite ideal. So let's just
lose it.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
compat/mingw.c | 15 ---------------
compat/mingw.h | 2 --
2 files changed, 17 deletions(-)
diff --git a/compat/mingw.c b/compat/mingw.c
index 33ddfdf..5fc14b7 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -1758,21 +1758,6 @@ int link(const char *oldpath, const char *newpath)
return 0;
}
-char *getpass(const char *prompt)
-{
- struct strbuf buf = STRBUF_INIT;
-
- fputs(prompt, stderr);
- for (;;) {
- char c = _getch();
- if (c == '\r' || c == '\n')
- break;
- strbuf_addch(&buf, c);
- }
- fputs("\n", stderr);
- return strbuf_detach(&buf, NULL);
-}
-
pid_t waitpid(pid_t pid, int *status, int options)
{
HANDLE h = OpenProcess(SYNCHRONIZE | PROCESS_QUERY_INFORMATION,
diff --git a/compat/mingw.h b/compat/mingw.h
index 6b9e69a..f494ecb 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -55,8 +55,6 @@ struct passwd {
char *pw_dir;
};
-extern char *getpass(const char *prompt);
-
typedef void (__cdecl *sig_handler_t)(int);
struct sigaction {
sig_handler_t sa_handler;
--
1.8.0.7.gbeffeda
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
^ permalink raw reply related
* [PATCH/RFC 4/5] mingw: reuse tty-version of git_terminal_prompt
From: Erik Faye-Lund @ 2012-11-13 14:04 UTC (permalink / raw)
To: git, msysgit; +Cc: peff
In-Reply-To: <1352815447-8824-1-git-send-email-kusmabite@gmail.com>
The getpass-implementation we use on Windows isn't at all ideal;
it works in raw-mode (as opposed to cooked mode), and as a result
does not deal correcly with deletion, arrow-keys etc.
Instead, use cooked mode to read a line at the time, allowing the
C run-time to process the input properly.
Since we set files to be opened in binary-mode by default on
Windows, introduce a FORCE_TEXT macro that expands to the "t"
modifier that forces the terminal to be opened in text-mode so we
do not have to deal with CRLF issues.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
compat/terminal.c | 69 +++++++++++++++++++++++++++++++++++++++++++++++--------
1 file changed, 60 insertions(+), 9 deletions(-)
diff --git a/compat/terminal.c b/compat/terminal.c
index 4a1fd3d..ce0fbd9 100644
--- a/compat/terminal.c
+++ b/compat/terminal.c
@@ -3,8 +3,22 @@
#include "sigchain.h"
#include "strbuf.h"
+#if defined(HAVE_DEV_TTY) || defined(WIN32)
+
+static void restore_term(void);
+
+static void restore_term_on_signal(int sig)
+{
+ restore_term();
+ sigchain_pop(sig);
+ raise(sig);
+}
+
#ifdef HAVE_DEV_TTY
+#define INPUT_PATH "/dev/tty"
+#define OUTPUT_PATH "/dev/tty"
+
static int term_fd = -1;
static struct termios old_term;
@@ -18,13 +32,6 @@ static void restore_term(void)
term_fd = -1;
}
-static void restore_term_on_signal(int sig)
-{
- restore_term();
- sigchain_pop(sig);
- raise(sig);
-}
-
static int disable_echo()
{
struct termios t;
@@ -46,17 +53,61 @@ error:
return -1;
}
+#elif defined(WIN32)
+
+#define INPUT_PATH "CONIN$"
+#define OUTPUT_PATH "CONOUT$"
+#define FORCE_TEXT "t"
+
+static HANDLE hconin = INVALID_HANDLE_VALUE;
+static DWORD cmode;
+
+static void restore_term(void)
+{
+ if (hconin == INVALID_HANDLE_VALUE)
+ return;
+
+ SetConsoleMode(hconin, cmode);
+ CloseHandle(hconin);
+ hconin = INVALID_HANDLE_VALUE;
+}
+
+static int disable_echo(void)
+{
+ hconin = CreateFile("CONIN$", GENERIC_READ | GENERIC_WRITE,
+ FILE_SHARE_READ, NULL, OPEN_EXISTING,
+ FILE_ATTRIBUTE_NORMAL, NULL);
+ if (hconin == INVALID_HANDLE_VALUE)
+ return -1;
+
+ GetConsoleMode(hconin, &cmode);
+ sigchain_push_common(restore_term_on_signal);
+ if (!SetConsoleMode(hconin, cmode & (~ENABLE_ECHO_INPUT))) {
+ CloseHandle(hconin);
+ hconin = INVALID_HANDLE_VALUE;
+ return -1;
+ }
+
+ return 0;
+}
+
+#endif
+
+#ifndef FORCE_TEXT
+#define FORCE_TEXT
+#endif
+
char *git_terminal_prompt(const char *prompt, int echo)
{
static struct strbuf buf = STRBUF_INIT;
int r;
FILE *input_fh, *output_fh;
- input_fh = fopen("/dev/tty", "r");
+ input_fh = fopen(INPUT_PATH, "r" FORCE_TEXT);
if (!input_fh)
return NULL;
- output_fh = fopen("/dev/tty", "w");
+ output_fh = fopen(OUTPUT_PATH, "w" FORCE_TEXT);
if (!output_fh) {
fclose(input_fh);
return NULL;
--
1.8.0.7.gbeffeda
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
^ permalink raw reply related
* [PATCH/RFC 3/5] compat/terminal: separate input and output handles
From: Erik Faye-Lund @ 2012-11-13 14:04 UTC (permalink / raw)
To: git, msysgit; +Cc: peff
In-Reply-To: <1352815447-8824-1-git-send-email-kusmabite@gmail.com>
On Windows, the terminal cannot be opened in read-write mode, so
we need distinct pairs for reading and writing. Since this works
fine on other platforms as well, always open them in pairs.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
compat/terminal.c | 29 ++++++++++++++++++-----------
1 file changed, 18 insertions(+), 11 deletions(-)
diff --git a/compat/terminal.c b/compat/terminal.c
index 3217838..4a1fd3d 100644
--- a/compat/terminal.c
+++ b/compat/terminal.c
@@ -50,29 +50,36 @@ char *git_terminal_prompt(const char *prompt, int echo)
{
static struct strbuf buf = STRBUF_INIT;
int r;
- FILE *fh;
+ FILE *input_fh, *output_fh;
- fh = fopen("/dev/tty", "w+");
- if (!fh)
+ input_fh = fopen("/dev/tty", "r");
+ if (!input_fh)
return NULL;
+ output_fh = fopen("/dev/tty", "w");
+ if (!output_fh) {
+ fclose(input_fh);
+ return NULL;
+ }
+
if (!echo && disable_echo()) {
- fclose(fh);
+ fclose(input_fh);
+ fclose(output_fh);
return NULL;
}
- fputs(prompt, fh);
- fflush(fh);
+ fputs(prompt, output_fh);
+ fflush(output_fh);
- r = strbuf_getline(&buf, fh, '\n');
+ r = strbuf_getline(&buf, input_fh, '\n');
if (!echo) {
- fseek(fh, SEEK_CUR, 0);
- putc('\n', fh);
- fflush(fh);
+ putc('\n', output_fh);
+ fflush(output_fh);
}
restore_term();
- fclose(fh);
+ fclose(input_fh);
+ fclose(output_fh);
if (r == EOF)
return NULL;
--
1.8.0.7.gbeffeda
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
^ permalink raw reply related
* [PATCH/RFC 2/5] compat/terminal: factor out echo-disabling
From: Erik Faye-Lund @ 2012-11-13 14:04 UTC (permalink / raw)
To: git, msysgit; +Cc: peff
In-Reply-To: <1352815447-8824-1-git-send-email-kusmabite@gmail.com>
By moving the echo-disabling code to a separate function, we can
implement OS-specific versions of it for non-POSIX platforms.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
compat/terminal.c | 43 +++++++++++++++++++++++++------------------
1 file changed, 25 insertions(+), 18 deletions(-)
diff --git a/compat/terminal.c b/compat/terminal.c
index bbb038d..3217838 100644
--- a/compat/terminal.c
+++ b/compat/terminal.c
@@ -14,6 +14,7 @@ static void restore_term(void)
return;
tcsetattr(term_fd, TCSAFLUSH, &old_term);
+ close(term_fd);
term_fd = -1;
}
@@ -24,6 +25,27 @@ static void restore_term_on_signal(int sig)
raise(sig);
}
+static int disable_echo()
+{
+ struct termios t;
+
+ term_fd = open("/dev/tty", O_RDWR);
+ if (tcgetattr(term_fd, &t) < 0)
+ goto error;
+
+ old_term = t;
+ sigchain_push_common(restore_term_on_signal);
+
+ t.c_lflag &= ~ECHO;
+ if (!tcsetattr(term_fd, TCSAFLUSH, &t))
+ return 0;
+
+error:
+ close(term_fd);
+ term_fd = -1;
+ return -1;
+}
+
char *git_terminal_prompt(const char *prompt, int echo)
{
static struct strbuf buf = STRBUF_INIT;
@@ -34,24 +56,9 @@ char *git_terminal_prompt(const char *prompt, int echo)
if (!fh)
return NULL;
- if (!echo) {
- struct termios t;
-
- if (tcgetattr(fileno(fh), &t) < 0) {
- fclose(fh);
- return NULL;
- }
-
- old_term = t;
- term_fd = fileno(fh);
- sigchain_push_common(restore_term_on_signal);
-
- t.c_lflag &= ~ECHO;
- if (tcsetattr(fileno(fh), TCSAFLUSH, &t) < 0) {
- term_fd = -1;
- fclose(fh);
- return NULL;
- }
+ if (!echo && disable_echo()) {
+ fclose(fh);
+ return NULL;
}
fputs(prompt, fh);
--
1.8.0.7.gbeffeda
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
^ permalink raw reply related
* [PATCH/RFC 1/5] mingw: make fgetc raise SIGINT if apropriate
From: Erik Faye-Lund @ 2012-11-13 14:04 UTC (permalink / raw)
To: git, msysgit; +Cc: peff
In-Reply-To: <1352815447-8824-1-git-send-email-kusmabite@gmail.com>
Set a control-handler to prevent the process from terminating, and
simulate SIGINT so it can be handled by a signal-handler as usual.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
compat/mingw.c | 76 ++++++++++++++++++++++++++++++++++++++++++++++++++--------
compat/mingw.h | 6 +++++
2 files changed, 72 insertions(+), 10 deletions(-)
diff --git a/compat/mingw.c b/compat/mingw.c
index 78e8f54..33ddfdf 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -319,6 +319,31 @@ ssize_t mingw_write(int fd, const void *buf, size_t count)
return write(fd, buf, min(count, 31 * 1024 * 1024));
}
+static BOOL WINAPI ctrl_ignore(DWORD type)
+{
+ return TRUE;
+}
+
+#undef fgetc
+int mingw_fgetc(FILE *stream)
+{
+ int ch;
+ if (!isatty(_fileno(stream)))
+ return fgetc(stream);
+
+ SetConsoleCtrlHandler(ctrl_ignore, TRUE);
+ while (1) {
+ ch = fgetc(stream);
+ if (ch != EOF || GetLastError() != ERROR_OPERATION_ABORTED)
+ break;
+
+ /* Ctrl+C was pressed, simulate SIGINT and retry */
+ mingw_raise(SIGINT);
+ }
+ SetConsoleCtrlHandler(ctrl_ignore, FALSE);
+ return ch;
+}
+
#undef fopen
FILE *mingw_fopen (const char *filename, const char *otype)
{
@@ -1524,7 +1549,7 @@ static HANDLE timer_event;
static HANDLE timer_thread;
static int timer_interval;
static int one_shot;
-static sig_handler_t timer_fn = SIG_DFL;
+static sig_handler_t timer_fn = SIG_DFL, sigint_fn = SIG_DFL;
/* The timer works like this:
* The thread, ticktack(), is a trivial routine that most of the time
@@ -1538,13 +1563,7 @@ static sig_handler_t timer_fn = SIG_DFL;
static unsigned __stdcall ticktack(void *dummy)
{
while (WaitForSingleObject(timer_event, timer_interval) == WAIT_TIMEOUT) {
- if (timer_fn == SIG_DFL) {
- if (isatty(STDERR_FILENO))
- fputs("Alarm clock\n", stderr);
- exit(128 + SIGALRM);
- }
- if (timer_fn != SIG_IGN)
- timer_fn(SIGALRM);
+ mingw_raise(SIGALRM);
if (one_shot)
break;
}
@@ -1635,12 +1654,49 @@ int sigaction(int sig, struct sigaction *in, struct sigaction *out)
sig_handler_t mingw_signal(int sig, sig_handler_t handler)
{
sig_handler_t old = timer_fn;
- if (sig != SIGALRM)
+
+ switch (sig) {
+ case SIGALRM:
+ timer_fn = handler;
+ break;
+
+ case SIGINT:
+ sigint_fn = handler;
+ break;
+
+ default:
return signal(sig, handler);
- timer_fn = handler;
+ }
+
return old;
}
+#undef raise
+int mingw_raise(int sig)
+{
+ switch (sig) {
+ case SIGALRM:
+ if (timer_fn == SIG_DFL) {
+ if (isatty(STDERR_FILENO))
+ fputs("Alarm clock\n", stderr);
+ exit(128 + SIGALRM);
+ } else if (timer_fn != SIG_IGN)
+ timer_fn(SIGALRM);
+ return 0;
+
+ case SIGINT:
+ if (sigint_fn == SIG_DFL)
+ exit(128 + SIGINT);
+ else if (sigint_fn != SIG_IGN)
+ sigint_fn(SIGINT);
+ return 0;
+
+ default:
+ return raise(sig);
+ }
+}
+
+
static const char *make_backslash_path(const char *path)
{
static char buf[PATH_MAX + 1];
diff --git a/compat/mingw.h b/compat/mingw.h
index 61a6521..6b9e69a 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -179,6 +179,9 @@ int mingw_open (const char *filename, int oflags, ...);
ssize_t mingw_write(int fd, const void *buf, size_t count);
#define write mingw_write
+int mingw_fgetc(FILE *stream);
+#define fgetc mingw_fgetc
+
FILE *mingw_fopen (const char *filename, const char *otype);
#define fopen mingw_fopen
@@ -287,6 +290,9 @@ static inline unsigned int git_ntohl(unsigned int x)
sig_handler_t mingw_signal(int sig, sig_handler_t handler);
#define signal mingw_signal
+int mingw_raise(int sig);
+#define raise mingw_raise
+
/*
* ANSI emulation wrappers
*/
--
1.8.0.7.gbeffeda
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
^ permalink raw reply related
* [PATCH/RFC 0/5] win32: support echo for terminal-prompt
From: Erik Faye-Lund @ 2012-11-13 14:04 UTC (permalink / raw)
To: git, msysgit; +Cc: peff
We currently only support getpass, which does not echo at all, for
git_terminal_prompt on Windows. The Windows console is perfectly
capable of doing this, so let's make it so.
This implementation tries to reuse the /dev/tty-code as much as
possible.
The big reason that this becomes a bit hairy is that Ctrl+C needs
to be handled correctly, so we don't leak the console state to a
non-echoing setting when a user aborts.
Windows makes this bit a little bit tricky, in that we need to
implement SIGINT for fgetc. However, I suspect that this is a good
thing to do in the first place.
An earlier iteration was also breifly discussed here:
http://mid.gmane.org/CABPQNSaUCEDU4+2N63n0k_XwSXOP_iFZG3GEYSPSBPcSVV8wRQ@mail.gmail.com
The series can also be found here, only with an extra patch that
makes the (interactive) testing a bit easier:
https://github.com/kusma/git/tree/work/terminal-cleanup
Erik Faye-Lund (5):
mingw: make fgetc raise SIGINT if apropriate
compat/terminal: factor out echo-disabling
compat/terminal: separate input and output handles
mingw: reuse tty-version of git_terminal_prompt
mingw: get rid of getpass implementation
compat/mingw.c | 91 +++++++++++++++++++++++++++-----------
compat/mingw.h | 8 +++-
compat/terminal.c | 129 ++++++++++++++++++++++++++++++++++++++++--------------
3 files changed, 169 insertions(+), 59 deletions(-)
--
1.8.0.7.gbeffeda
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
^ permalink raw reply
* [PATCH 0/5] win32: support echo for terminal-prompt
From: Erik Faye-Lund @ 2012-11-13 14:01 UTC (permalink / raw)
To: git, msysgit; +Cc: peff
We currently only support getpass, which does not echo at all, for
git_terminal_prompt on Windows. The Windows console is perfectly
capable of doing this, so let's make it so.
This implementation tries to reuse the /dev/tty-code as much as
possible.
The big reason that this becomes a bit hairy is that Ctrl+C needs
to be handled correctly, so we don't leak the console state to a
non-echoing setting when a user aborts.
Windows makes this bit a little bit tricky, in that we need to
implement SIGINT for fgetc. However, I suspect that this is a good
thing to do in the first place.
An earlier iteration was also breifly discussed here:
http://mid.gmane.org/CABPQNSaUCEDU4+2N63n0k_XwSXOP_iFZG3GEYSPSBPcSVV8wRQ@mail.gmail.com
The series can also be found here, only with an extra patch that
makes the (interactive) testing a bit easier:
https://github.com/kusma/git/tree/work/terminal-cleanup
Erik Faye-Lund (5):
mingw: make fgetc raise SIGINT if apropriate
compat/terminal: factor out echo-disabling
compat/terminal: separate input and output handles
mingw: reuse tty-version of git_terminal_prompt
mingw: get rid of getpass implementation
compat/mingw.c | 91 +++++++++++++++++++++++++++-----------
compat/mingw.h | 8 +++-
compat/terminal.c | 129 ++++++++++++++++++++++++++++++++++++++++--------------
3 files changed, 169 insertions(+), 59 deletions(-)
--
1.8.0.7.gbeffeda
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
^ permalink raw reply
* Re: [PATCHv4] replace: parse revision argument for -d
From: Jeff King @ 2012-11-13 13:37 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git, Junio C Hamano
In-Reply-To: <848bc8f48885acd63b4f6d29eea0543e73d86451.1352802239.git.git@drmicha.warpmail.net>
On Tue, Nov 13, 2012 at 11:34:11AM +0100, Michael J Gruber wrote:
> 'git replace' parses the revision arguments when it creates replacements
> (so that a sha1 can be abbreviated, e.g.) but not when deleting
> replacements.
>
> Make it parse the argument to 'replace -d' in the same way.
>
> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
> ---
>
> Notes:
> v4 names the aux variable more concisely and does away with a superfluous
> assignment.
Thanks. I agree the name "full_hex" is much better. Patch looks good to
me at this point.
-Peff
^ permalink raw reply
* Re: Reviews on mailing-list
From: Nguyen Thai Ngoc Duy @ 2012-11-13 13:38 UTC (permalink / raw)
To: David Lang
Cc: Krzysztof Mazur, Thiago Farina, Felipe Contreras,
Deniz Türkoglu, git, Junio C Hamano, Shawn Pearce
In-Reply-To: <alpine.DEB.2.02.1211111313140.19687@nftneq.ynat.uz>
On Mon, Nov 12, 2012 at 4:15 AM, David Lang <david@lang.hm> wrote:
> Using a web browser requires connectivity at the time you are doing the
> review.
>
> Mailing list based reviews can be done at times when you don't have
> connectivity.
I am not against email-based reviews but I'd like to point out that
with Google Gears (and HTML5 Storage?) Gerrit can be made work offline
too. I don't know how much work required though.
--
Duy
^ permalink raw reply
* Re: Notes in format-patch (was: Re: [PATCHv3] replace: parse revision argument for -d)
From: Jeff King @ 2012-11-13 13:38 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git, Junio C Hamano
In-Reply-To: <50A2213B.4060505@drmicha.warpmail.net>
On Tue, Nov 13, 2012 at 11:30:19AM +0100, Michael J Gruber wrote:
> Michael J Gruber venit, vidit, dixit 12.11.2012 15:18:
> > 'git replace' parses the revision arguments when it creates replacements
> > (so that a sha1 can be abbreviated, e.g.) but not when deleting
> > replacements.
> >
> > Make it parse the argument to 'replace -d' in the same way.
> >
> > Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
> > ---
> >
> > Notes:
> > v3 safeguards the hex buffer against reuse
> > builtin/replace.c | 16 ++++++++++------
> > t/t6050-replace.sh | 11 +++++++++++
> > 2 files changed, 21 insertions(+), 6 deletions(-)
> >
> > diff --git a/builtin/replace.c b/builtin/replace.c
>
> By the way - Junio, is that the intented outcome of "format-patch
> --notes"? I would rather put the newline between the note and the
> diffstat (and omit the one after the ---) but may have goofed up a rebase:
I do not know was intended, but the above quoted output is hard to read,
and your suggested change looks way better.
-Peff
^ permalink raw reply
* Re: Simple question ? [Git branch]
From: Ramkumar Ramachandra @ 2012-11-13 12:47 UTC (permalink / raw)
To: agatte; +Cc: git
In-Reply-To: <1352810777584-7571115.post@n2.nabble.com>
agatte wrote:
> I don't know what I could change branches ?
It's called "checkout".
Ram
^ permalink raw reply
* Simple question ? [Git branch]
From: agatte @ 2012-11-13 12:46 UTC (permalink / raw)
To: git
Hi All Users,
I am beginner in git. I am doing my first steps with this tool.
Now, I used git gui on linux OS.
I don't know what I could change branches ?
I need to change current working branch to do a commit.
I can see in the menu branch :
Create
checkout
rebase
Reset
--
Could anyone help me please ?
I would appreciate for any help.
agatte
--
View this message in context: http://git.661346.n2.nabble.com/Simple-question-Git-branch-tp7571115.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Fwd: [PATCH] Add tcsh-completion support to contrib by using git-completion.bash
From: SZEDER Gábor @ 2012-11-13 11:14 UTC (permalink / raw)
To: Marc Khouzam; +Cc: git
In-Reply-To: <CAFj1UpFd9X8Jq5o7B4m35i=merBDvOo4NOtwth=UnG2S5X_rGw@mail.gmail.com>
Hi,
On Mon, Nov 12, 2012 at 03:07:46PM -0500, Marc Khouzam wrote:
> Hi,
[...]
> Signed-off-by: Marc Khouzam <marc.khouzam@gmail.com>
[...]
> Thanks
>
> Marc
>
> ---
> contrib/completion/git-completion.bash | 53 +++++++++++++++++++++++++++++++-
> contrib/completion/git-completion.tcsh | 34 ++++++++++++++++++++
> 2 files changed, 86 insertions(+), 1 deletions(-)
> create mode 100755 contrib/completion/git-completion.tcsh
Please have a look at Documentation/SubmittingPatches to see how to
properly format the commit message, i.e. no greeting and sign-off in
the commit message part, and the S-o-b line should be the last before
the '---'.
Your patch seems to be severely line-wrapped. That document also
contains a few MUA-specific tips to help avoid that.
Other than that, it's a good description of the changes and
considerations. I agree that this approach seems to be the best from
the three.
> diff --git a/contrib/completion/git-completion.bash
> b/contrib/completion/git-completion.bash
> index be800e0..6d4b57a 100644
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -1,4 +1,6 @@
> -#!bash
> +#!/bin/bash
> +# The above line is important as this script can be executed when used
> +# with another shell such as tcsh
See comment near the end.
> #
> # bash/zsh completion support for core Git.
> #
> @@ -2481,3 +2483,52 @@ __git_complete gitk __gitk_main
> if [ Cygwin = "$(uname -o 2>/dev/null)" ]; then
> __git_complete git.exe __git_main
> fi
> +
> +# Method that will output the result of the completion done by
> +# the bash completion script, so that it can be re-used in another
> +# context than the bash complete command.
> +# It accepts 1 to 2 arguments:
> +# 1: The command-line to complete
> +# 2: The index of the word within argument #1 in which the cursor is
> +# located (optional). If parameter 2 is not provided, it will be
> +# determined as best possible using parameter 1.
> +_git_complete_with_output ()
> +{
> + # Set COMP_WORDS to the command-line as bash would.
> + COMP_WORDS=($1)
That comment is only true for older Bash versions. Since v4 Bash
splits the command line at characters that the readline library treats
as word separators when performing word completion. But the
completion script has functions to deal with both, so this shouldn't
be a problem.
> +
> + # Set COMP_CWORD to the cursor location as bash would.
> + if [ -n "$2" ]; then
> + COMP_CWORD=$2
> + else
> + # Assume the cursor is at the end of parameter #1.
> + # We must check for a space as the last character which will
> + # tell us that the previous word is complete and the cursor
> + # is on the next word.
> + if [ "${1: -1}" == " " ]; then
> + # The last character is a space, so our
> location is at the end
> + # of the command-line array
> + COMP_CWORD=${#COMP_WORDS[@]}
> + else
> + # The last character is not a space, so our
> location is on the
> + # last word of the command-line array, so we
> must decrement the
> + # count by 1
> + COMP_CWORD=$((${#COMP_WORDS[@]}-1))
> + fi
> + fi
> +
> + # Call _git() or _gitk() of the bash script, based on the first
> + # element of the command-line
> + _${COMP_WORDS[0]}
> +
> + # Print the result that is stored in the bash variable ${COMPREPLY}
Really? ;)
I like the above comments about setting COMP_CWORD, because they
explain why you do what you do, which would be otherwise difficult to
figure out. But telling that an echo in a for loop over an array
prints that array is, well, probably not necessary.
> + for i in ${COMPREPLY[@]}; do
> + echo "$i"
> + done
There is no need for the loop here to print the array one element per
line:
local IFS=$'\n'
echo "${COMPREPLY[*]}"
> +}
> +
> +if [ -n "$1" ] ; then
> + # If there is an argument, we know the script is being executed
> + # so go ahead and run the _git_complete_with_output function
> + _git_complete_with_output "$1" "$2"
Where does the second argument come from? Below you run this script
as '${__git_tcsh_completion_script} "${COMMAND_LINE}"', i.e. $2 is
never set. Am I missing something?
> +fi
> diff --git a/contrib/completion/git-completion.tcsh
> b/contrib/completion/git-completion.tcsh
> new file mode 100755
> index 0000000..7b7baea
> --- /dev/null
> +++ b/contrib/completion/git-completion.tcsh
> @@ -0,0 +1,34 @@
> +#!tcsh
> +#
> +# tcsh completion support for core Git.
> +#
> +# Copyright (C) 2012 Marc Khouzam <marc.khouzam@gmail.com>
> +# Distributed under the GNU General Public License, version 2.0.
> +#
> +# This script makes use of the git-completion.bash script to
> +# determine the proper completion for git commands under tcsh.
> +#
> +# To use this completion script:
> +#
> +# 1) Copy both this file and the bash completion script to your
> ${HOME} directory
> +# using the names ${HOME}/.git-completion.tcsh and
> ${HOME}/.git-completion.bash.
> +# 2) Add the following line to your .tcshrc/.cshrc:
> +# source ${HOME}/.git-completion.tcsh
> +
> +# One can change the below line to use a different location
> +set __git_tcsh_completion_script = ${HOME}/.git-completion.bash
> +
> +# Check that the user put the script in the right place
> +if ( ! -e ${__git_tcsh_completion_script} ) then
> + echo "ERROR in git-completion.tcsh script. Cannot find:
> ${__git_tcsh_completion_script}. Git completion will not work."
> + exit
> +endif
> +
> +# Make the script executable if it is not
> +if ( ! -x ${__git_tcsh_completion_script} ) then
> + chmod u+x ${__git_tcsh_completion_script}
> +endif
Not sure about this. If I source a script to provide completion for a
command, then I definitely don't expect it to change file permissions.
However, even if the git completion script is not executable, you can
still run it with 'bash ${__git_tcsh_completion_script}'. This way
neither the user would need to set permissions, not the script would
need to set it behind the users back. Furthermore, this would also
make changing the shebang line unnecessary.
> +
> +complete git 'p/*/`${__git_tcsh_completion_script} "${COMMAND_LINE}"
> | sort | uniq`/'
> +complete gitk 'p/*/`${__git_tcsh_completion_script} "${COMMAND_LINE}"
> | sort | uniq`/'
Is the 'sort | uniq' really necessary? After the completion function
returns Bash automatically sorts the elements in COMPREPLY and removes
any duplicates. Doesn't tcsh do the same? I have no idea about tcsh
completion.
Does the git completion script returns any duplicates at all?
Ambigious refs come to mind, but I just checked that refs completion,
or rather 'git for-each-ref' (the command driving refs completion), is
kind enough to make any ambigious ref names unique (i.e. a branch and
a tag with the same name is listed as 'heads/name' and 'tags/name').
Thanks,
Gábor
^ permalink raw reply
* [PATCH nd/wildmatch] Correct Git's version of isprint and isspace
From: Nguyễn Thái Ngọc Duy @ 2012-11-13 10:46 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, schnhrr, rene.scharfe,
Nguyễn Thái Ngọc Duy
In-Reply-To: <507E9FDE.7080706@cs.tu-berlin.de>
Git's ispace does not include 11 and 12. Git's isprint includes
control space characters (10-13). According to glibc-2.14.1 on C
locale on Linux, this is wrong. This patch fixes it.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
I wrote a small C program to compare the result of all is* functions
that Git replaces against the libc version. These are the only ones that
differ. Which matches what Jan Schönherr commented.
ctype.c | 6 +++---
git-compat-util.h | 11 ++++++-----
2 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/ctype.c b/ctype.c
index 0bfebb4..71311a3 100644
--- a/ctype.c
+++ b/ctype.c
@@ -14,11 +14,11 @@ enum {
P = GIT_PATHSPEC_MAGIC, /* other non-alnum, except for ] and } */
X = GIT_CNTRL,
U = GIT_PUNCT,
- Z = GIT_CNTRL | GIT_SPACE
+ Z = GIT_CNTRL_SPACE
};
-const unsigned char sane_ctype[256] = {
- X, X, X, X, X, X, X, X, X, Z, Z, X, X, Z, X, X, /* 0.. 15 */
+const unsigned int sane_ctype[256] = {
+ X, X, X, X, X, X, X, X, X, Z, Z, Z, Z, Z, X, X, /* 0.. 15 */
X, X, X, X, X, X, X, X, X, X, X, X, X, X, X, X, /* 16.. 31 */
S, P, P, P, R, P, P, P, R, R, G, R, P, P, R, P, /* 32.. 47 */
D, D, D, D, D, D, D, D, D, D, P, P, P, P, P, G, /* 48.. 63 */
diff --git a/git-compat-util.h b/git-compat-util.h
index 02f48f6..4ed3f94 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -474,8 +474,8 @@ extern const char tolower_trans_tbl[256];
#undef ispunct
#undef isxdigit
#undef isprint
-extern const unsigned char sane_ctype[256];
-#define GIT_SPACE 0x01
+extern const unsigned int sane_ctype[256];
+#define GIT_CNTRL_SPACE 0x01
#define GIT_DIGIT 0x02
#define GIT_ALPHA 0x04
#define GIT_GLOB_SPECIAL 0x08
@@ -483,9 +483,10 @@ extern const unsigned char sane_ctype[256];
#define GIT_PATHSPEC_MAGIC 0x20
#define GIT_CNTRL 0x40
#define GIT_PUNCT 0x80
-#define sane_istest(x,mask) ((sane_ctype[(unsigned char)(x)] & (mask)) != 0)
+#define GIT_SPACE 0x100
+#define sane_istest(x,mask) ((sane_ctype[(unsigned int)(x)] & (mask)) != 0)
#define isascii(x) (((x) & ~0x7f) == 0)
-#define isspace(x) sane_istest(x,GIT_SPACE)
+#define isspace(x) sane_istest(x,GIT_SPACE | GIT_CNTRL_SPACE)
#define isdigit(x) sane_istest(x,GIT_DIGIT)
#define isalpha(x) sane_istest(x,GIT_ALPHA)
#define isalnum(x) sane_istest(x,GIT_ALPHA | GIT_DIGIT)
@@ -493,7 +494,7 @@ extern const unsigned char sane_ctype[256];
#define isupper(x) sane_iscase(x, 0)
#define is_glob_special(x) sane_istest(x,GIT_GLOB_SPECIAL)
#define is_regex_special(x) sane_istest(x,GIT_GLOB_SPECIAL | GIT_REGEX_SPECIAL)
-#define iscntrl(x) (sane_istest(x,GIT_CNTRL))
+#define iscntrl(x) (sane_istest(x,GIT_CNTRL | GIT_CNTRL_SPACE))
#define ispunct(x) sane_istest(x, GIT_PUNCT | GIT_REGEX_SPECIAL | \
GIT_GLOB_SPECIAL | GIT_PATHSPEC_MAGIC)
#define isxdigit(x) (hexval_table[x] != -1)
--
1.8.0.rc2.23.g1fb49df
^ permalink raw reply related
* [PATCHv4] replace: parse revision argument for -d
From: Michael J Gruber @ 2012-11-13 10:34 UTC (permalink / raw)
To: git; +Cc: Jeff King, Junio C Hamano
In-Reply-To: <50A22026.60506@drmicha.warpmail.net>
'git replace' parses the revision arguments when it creates replacements
(so that a sha1 can be abbreviated, e.g.) but not when deleting
replacements.
Make it parse the argument to 'replace -d' in the same way.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
Notes:
v4 names the aux variable more concisely and does away with a superfluous
assignment.
builtin/replace.c | 15 +++++++++------
t/t6050-replace.sh | 11 +++++++++++
2 files changed, 20 insertions(+), 6 deletions(-)
diff --git a/builtin/replace.c b/builtin/replace.c
index e3aaf70..398ccd5 100644
--- a/builtin/replace.c
+++ b/builtin/replace.c
@@ -46,24 +46,27 @@ typedef int (*each_replace_name_fn)(const char *name, const char *ref,
static int for_each_replace_name(const char **argv, each_replace_name_fn fn)
{
- const char **p;
+ const char **p, *full_hex;
char ref[PATH_MAX];
int had_error = 0;
unsigned char sha1[20];
for (p = argv; *p; p++) {
- if (snprintf(ref, sizeof(ref), "refs/replace/%s", *p)
- >= sizeof(ref)) {
- error("replace ref name too long: %.*s...", 50, *p);
+ if (get_sha1(*p, sha1)) {
+ error("Failed to resolve '%s' as a valid ref.", *p);
had_error = 1;
continue;
}
+ full_hex = sha1_to_hex(sha1);
+ snprintf(ref, sizeof(ref), "refs/replace/%s", full_hex);
+ /* read_ref() may reuse the buffer */
+ full_hex = ref + strlen("refs/replace/");
if (read_ref(ref, sha1)) {
- error("replace ref '%s' not found.", *p);
+ error("replace ref '%s' not found.", full_hex);
had_error = 1;
continue;
}
- if (fn(*p, ref, sha1))
+ if (fn(full_hex, ref, sha1))
had_error = 1;
}
return had_error;
diff --git a/t/t6050-replace.sh b/t/t6050-replace.sh
index 5c87f28..decdc33 100755
--- a/t/t6050-replace.sh
+++ b/t/t6050-replace.sh
@@ -140,6 +140,17 @@ test_expect_success '"git replace" replacing' '
test "$HASH2" = "$(git replace)"
'
+test_expect_success '"git replace" resolves sha1' '
+ SHORTHASH2=$(git rev-parse --short=8 $HASH2) &&
+ git replace -d $SHORTHASH2 &&
+ git replace $SHORTHASH2 $R &&
+ git show $HASH2 | grep "O Thor" &&
+ test_must_fail git replace $HASH2 $R &&
+ git replace -f $HASH2 $R &&
+ test_must_fail git replace -f &&
+ test "$HASH2" = "$(git replace)"
+'
+
# This creates a side branch where the bug in H2
# does not appear because P2 is created by applying
# H2 and squashing H5 into it.
--
1.8.0.311.gdd08018
^ permalink raw reply related
* Notes in format-patch (was: Re: [PATCHv3] replace: parse revision argument for -d)
From: Michael J Gruber @ 2012-11-13 10:30 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git, Jeff King, Junio C Hamano
In-Reply-To: <a35a8f44b908bded0b475b02e7917011fb3bf90b.1352728712.git.git@drmicha.warpmail.net>
Michael J Gruber venit, vidit, dixit 12.11.2012 15:18:
> 'git replace' parses the revision arguments when it creates replacements
> (so that a sha1 can be abbreviated, e.g.) but not when deleting
> replacements.
>
> Make it parse the argument to 'replace -d' in the same way.
>
> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
> ---
>
> Notes:
> v3 safeguards the hex buffer against reuse
> builtin/replace.c | 16 ++++++++++------
> t/t6050-replace.sh | 11 +++++++++++
> 2 files changed, 21 insertions(+), 6 deletions(-)
>
> diff --git a/builtin/replace.c b/builtin/replace.c
By the way - Junio, is that the intented outcome of "format-patch
--notes"? I would rather put the newline between the note and the
diffstat (and omit the one after the ---) but may have goofed up a rebase:
...
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
Notes:
v3 safeguards the hex buffer against reuse
builtin/replace.c | 16 ++++++++++------
...
^ permalink raw reply
* Re: [PATCHv3] replace: parse revision argument for -d
From: Michael J Gruber @ 2012-11-13 10:25 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano
In-Reply-To: <20121112204254.GH4623@sigill.intra.peff.net>
Jeff King venit, vidit, dixit 12.11.2012 21:42:
> On Mon, Nov 12, 2012 at 03:18:02PM +0100, Michael J Gruber wrote:
>
>> 'git replace' parses the revision arguments when it creates replacements
>> (so that a sha1 can be abbreviated, e.g.) but not when deleting
>> replacements.
>>
>> Make it parse the argument to 'replace -d' in the same way.
>>
>> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
>> ---
>>
>> Notes:
>> v3 safeguards the hex buffer against reuse
>
> Thanks, I don't see any other functional problems.
>
>> diff --git a/builtin/replace.c b/builtin/replace.c
>> index e3aaf70..33e6ec3 100644
>> --- a/builtin/replace.c
>> +++ b/builtin/replace.c
>> @@ -46,24 +46,28 @@ typedef int (*each_replace_name_fn)(const char *name, const char *ref,
>>
>> static int for_each_replace_name(const char **argv, each_replace_name_fn fn)
>> {
>> - const char **p;
>> + const char **p, *q;
>
> I find this readable today, but I wonder if in six months we will wonder
> what in the world "q" means. Maybe "short_refname" or something would be
> appropriate?
That would be sooo inappropriate! ;)
Maybe "full_hex"?
I should also do away with the first replacement which really made sense
in v1 only.
v4 to follow.
Michael
^ permalink raw reply
* Re: RFD: fast-import is picky with author names (and maybe it should - but how much so?)
From: Michael J Gruber @ 2012-11-13 10:15 UTC (permalink / raw)
To: Felipe Contreras
Cc: Jeff King, A Large Angry SCM, Git Mailing List, Junio C Hamano
In-Reply-To: <CAMP44s1gA1P-Lr1M=7RDRqFQmvQAtNnB+yAJfKC1gk3XUjbfCQ@mail.gmail.com>
Felipe Contreras venit, vidit, dixit 12.11.2012 23:47:
> On Mon, Nov 12, 2012 at 10:41 PM, Jeff King <peff@peff.net> wrote:
>> On Sun, Nov 11, 2012 at 07:48:14PM +0100, Felipe Contreras wrote:
>>
>>>> 3. Exporters should not use it if they have any broken-down
>>>> representation at all. Even knowing that the first half is a human
>>>> name and the second half is something else would give it a better
>>>> shot at cleaning than fast-import would get.
>>>
>>> I'm not sure what you mean by this. If they have name and email, then
>>> sure, it's easy.
>>
>> But not as easy as just printing it. What if you have this:
>>
>> name="Peff <angle brackets> King"
>> email="<peff@peff.net>"
>>
>> Concatenating them does not produce a valid git author name. Sending the
>> concatenation through fast-import's cleanup function would lose
>> information (namely, the location of the boundary between name and
>> email).
>
> Right. Unfortunately I'm not aware of any DSCM that does that.
>
>> Similarly, one might have other structured data (e.g., CVS username)
>> where the structure is a useful hint, but some conversion to name+email
>> is still necessary.
>
> CVS might be the only one that has such structured data. I think in
> subversion the username has no meaning. A 'felipec' subversion
> username is as bad as a mercurial 'felipec' username.
In subversion, the username has the clearly defined meaning of being a
username on the subversion host. If the host is, e.g., a sourceforge
site then I can easily look up the user profile and convert the username
into a valid e-mail address (<username>@users.sf.net). That is the
advantage that the exporter (together with user knowledge) has over the
importer.
If the initial clone process aborts after every single "unknown" user
it's no fun, of course. On the other hand, if an incremental clone
(fetch) let's commits with unknown author sneak in it's no fun either
(because I may want to fetch in crontab and publish that converted beast
automatically). That is why I proposed neither approach.
Most conveniently, the export side of a remote helper would
- do "obvious" automatic lossless transformations
- use an author map for other names
- For names not covered by the above (or having an empty map entry):
Stop exporting commits but continue parsing commits and amend the author
map with any unknown usernames (empty entry), and warn the user.
(crontab script can notify me based on the return code.)
If the cloning involves a "foreign clone" (like the hg clone behind the
scene) then the runtime of the second pass should be much smaller. In
principle, one could even store all blobs and trees on the first run and
skip that step on the second, but that would rely on immutability on the
foreign side, so I dunno. (And to check the sha1, we have to get the
blob anyways.)
As for the format for incomplete entries (foo <some@where>), a technical
guideline should suffice for those that follow guidelines.
Michael
^ permalink raw reply
* [PATCH 14/13] test-wildmatch: avoid Windows path mangling
From: Nguyễn Thái Ngọc Duy @ 2012-11-13 10:06 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Jeff King, Johannes Sixt,
Nguyễn Thái Ngọc Duy
In-Reply-To: <7vvcdco1pf.fsf@alter.siamese.dyndns.org>
On Windows, arguments starting with a forward slash is mangled as if
it were full pathname. This causes the patterns beginning with a slash
not to be passed to test-wildmatch correctly. Avoid mangling by never
accepting patterns starting with a slash. Those arguments must be
rewritten with a leading "XXX" (e.g. "/abc" becomes "XXX/abc"), which
will be removed by test-wildmatch itself before feeding the patterns
to wildmatch() or fnmatch().
Reported-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
On Sun, Nov 11, 2012 at 5:47 PM, Junio C Hamano <gitster@pobox.com> wrote:
> The title taken together with the above explanation makes it sound
> as if wildmatch code does not work with the pattern /foo on Windows
> at all and to avoid the issue (instead of fixing the breakage) this
> patch removes such tests....
OK how about this?
t/t3070-wildmatch.sh | 10 +++++-----
test-wildmatch.c | 8 ++++++++
2 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/t/t3070-wildmatch.sh b/t/t3070-wildmatch.sh
index e6ad6f4..3155eab 100755
--- a/t/t3070-wildmatch.sh
+++ b/t/t3070-wildmatch.sh
@@ -74,7 +74,7 @@ match 0 0 'foo/bar' 'foo[/]bar'
match 0 0 'foo/bar' 'f[^eiu][^eiu][^eiu][^eiu][^eiu]r'
match 1 1 'foo-bar' 'f[^eiu][^eiu][^eiu][^eiu][^eiu]r'
match 1 0 'foo' '**/foo'
-match 1 x '/foo' '**/foo'
+match 1 x 'XXX/foo' '**/foo'
match 1 0 'bar/baz/foo' '**/foo'
match 0 0 'bar/baz/foo' '*/foo'
match 0 0 'foo/bar/baz' '**/bar*'
@@ -95,8 +95,8 @@ match 0 0 ']' '[!]-]'
match 1 x 'a' '[!]-]'
match 0 0 '' '\'
match 0 x '\' '\'
-match 0 x '/\' '*/\'
-match 1 x '/\' '*/\\'
+match 0 x 'XXX/\' '*/\'
+match 1 x 'XXX/\' '*/\\'
match 1 1 'foo' 'foo'
match 1 1 '@foo' '@foo'
match 0 0 'foo' '@foo'
@@ -187,8 +187,8 @@ match 0 0 '-' '[[-\]]'
match 1 1 '-adobe-courier-bold-o-normal--12-120-75-75-m-70-iso8859-1' '-*-*-*-*-*-*-12-*-*-*-m-*-*-*'
match 0 0 '-adobe-courier-bold-o-normal--12-120-75-75-X-70-iso8859-1' '-*-*-*-*-*-*-12-*-*-*-m-*-*-*'
match 0 0 '-adobe-courier-bold-o-normal--12-120-75-75-/-70-iso8859-1' '-*-*-*-*-*-*-12-*-*-*-m-*-*-*'
-match 1 1 '/adobe/courier/bold/o/normal//12/120/75/75/m/70/iso8859/1' '/*/*/*/*/*/*/12/*/*/*/m/*/*/*'
-match 0 0 '/adobe/courier/bold/o/normal//12/120/75/75/X/70/iso8859/1' '/*/*/*/*/*/*/12/*/*/*/m/*/*/*'
+match 1 1 'XXX/adobe/courier/bold/o/normal//12/120/75/75/m/70/iso8859/1' 'XXX/*/*/*/*/*/*/12/*/*/*/m/*/*/*'
+match 0 0 'XXX/adobe/courier/bold/o/normal//12/120/75/75/X/70/iso8859/1' 'XXX/*/*/*/*/*/*/12/*/*/*/m/*/*/*'
match 1 0 'abcd/abcdefg/abcdefghijk/abcdefghijklmnop.txt' '**/*a*b*g*n*t'
match 0 0 'abcd/abcdefg/abcdefghijk/abcdefghijklmnop.txtz' '**/*a*b*g*n*t'
diff --git a/test-wildmatch.c b/test-wildmatch.c
index 74c0864..e384c8e 100644
--- a/test-wildmatch.c
+++ b/test-wildmatch.c
@@ -3,6 +3,14 @@
int main(int argc, char **argv)
{
+ int i;
+ for (i = 2; i < argc; i++) {
+ if (argv[i][0] == '/')
+ die("Forward slash is not allowed at the beginning of the\n"
+ "pattern because Windows does not like it. Use `XXX/' instead.");
+ else if (!strncmp(argv[i], "XXX/", 4))
+ argv[i] += 3;
+ }
if (!strcmp(argv[1], "wildmatch"))
return !!wildmatch(argv[3], argv[2], 0);
else if (!strcmp(argv[1], "iwildmatch"))
--
1.8.0.rc2.23.g1fb49df
^ permalink raw reply related
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