Jonathan Nieder venit, vidit, dixit 10.02.2013 02:49:
> Hi,
>
> Michael J Gruber wrote:
>
>> "reset" can be easily misunderstood as resetting a bisect session to its
>> start without finishing it. Clarify that it actually finishes the bisect
>> session.
>
> FWIW,
> Reviewed-by: Jonathan Nieder
Junio C Hamano wrote:
> The purpose of the directory is to keep custom commands that are
> allowed. If the site administrator does not want any command, it
> would be more natural to expect that the way to disable them would
> be _not_ to have that directory which is a collection of allowed
> com
"reset" can be easily misunderstood as resetting a bisect session to its
start without finishing it. Clarify that it actually quits the bisect
session.
Reported-by: Andreas Mohr
Signed-off-by: Michael J Gruber
---
Documentation/git-bisect.txt | 7 ++-
1 file changed, 6 insertions(+), 1 dele
Michael J Gruber wrote:
> --- a/Documentation/git-bisect.txt
> +++ b/Documentation/git-bisect.txt
[...]
> @@ -284,6 +284,7 @@ EXAMPLES
>
> $ git bisect start HEAD v1.2 -- # HEAD is bad, v1.2 is good
> $ git bisect run make# "make" builds the app
> +$ git bisect
Brandon Casey wrote:
>We want to be able to support lines that do
> not have email addresses on the right-hand side like:
>
>Bug: XXX
>Change-Id: XXX
Good call.
By the way, regarding what the right "--signoff" behavior is for
commit, cherry-pick, am, and forma
Junio C Hamano writes:
> * mm/allow-contrib-build (2013-02-07) 2 commits
> - perl.mak: introduce $(GIT_ROOT_DIR) to allow inclusion from other
> directories
> - Makefile: extract perl-related rules to make them available from other dirs
>
> Will merge to 'next'.
These two patches do not make
On Sun, Feb 10, 2013 at 02:38:46PM -0800, Junio C Hamano wrote:
> John Keeping writes:
> > On Sun, Feb 10, 2013 at 11:30:39AM -0800, Junio C Hamano wrote:
> > ...
> >> Is it correct to say that this essentially re-does 656197ad3805
> >> (graph.c: infinite loop in git whatchanged --graph -m, 2009-0
On Mon, Feb 11, 2013 at 9:56 AM, Duy Nguyen wrote:
> Yeah, it did not cut out syscall cost, I also cut a lot of user-space
> processing (plus .gitignore content access). From the timings I posted
> earlier,
>
>> unmodified dir.c
>> real0m0.550s0m0.287s
>> user0m0.305s0m0.2
On Mon, 11 Feb 2013 02:57:51 -0500
Ethan Reesor wrote:
[...]
> I want to create a git-command that 1) creates a bare version of the
> current repo, 2) and uploads it to the specified path on my server
> (using tar, but that's not the point).
Thanks, it's now a bit more clear.
> My problem is th
Even though parse-options doesn't support UTF-8 switches (which
makes sense; non-ascii switches would be difficult to enter on
some keyboard layouts), it can be useful to report incorrectly
entered UTF-8 switches to make the output somewhat less ugly
for those of us with keyboard layouts with UTF-8
Erik Faye-Lund writes:
> --- a/parse-options.c
> +++ b/parse-options.c
> @@ -3,6 +3,7 @@
> #include "cache.h"
> #include "commit.h"
> #include "color.h"
> +#include "utf8.h"
>
> static int parse_options_usage(struct parse_opt_ctx_t *ctx,
> const char * const *us
On Mon, Feb 11, 2013 at 2:43 PM, Matthieu Moy
wrote:
> Erik Faye-Lund writes:
>
>> --- a/parse-options.c
>> +++ b/parse-options.c
>> @@ -3,6 +3,7 @@
>> #include "cache.h"
>> #include "commit.h"
>> #include "color.h"
>> +#include "utf8.h"
>>
>> static int parse_options_usage(struct parse_opt_c
Erik Faye-Lund writes:
> But isn't UTF-8 constructed to be very unlikely to clash with existing
> encodings? If so, I could add a case for non-ascii and non-UTF-8, that
> simply writes the byte as a hex-tuple?
If it's non-ascii and non-UTF-8, I think you'd want to display the byte
as it is, beca
On Sun, Feb 10, 2013 at 9:21 PM, Duy Nguyen wrote:
> On Mon, Feb 11, 2013 at 2:03 AM, Robert Zeh
> wrote:
>> On Sat, Feb 9, 2013 at 1:35 PM, Junio C Hamano wrote:
>>> Ramkumar Ramachandra writes:
>>>
This is much better than Junio's suggestion to study possible
implementations on all
On Mon, Feb 11, 2013 at 3:05 PM, Matthieu Moy
wrote:
> Erik Faye-Lund writes:
>
>> But isn't UTF-8 constructed to be very unlikely to clash with existing
>> encodings? If so, I could add a case for non-ascii and non-UTF-8, that
>> simply writes the byte as a hex-tuple?
>
> If it's non-ascii and n
On Sun, Feb 10, 2013 at 11:17:24PM -0800, Junio C Hamano wrote:
> Jonathan Nieder writes:
>
> > Isn't that a criticism of the git-shell-commands facility in general?
> > If it is common to have a lot of users with distinct home directories
> > but all with git-shell as their login shell, then th
Matthieu Moy writes:
> Junio C Hamano writes:
>
>> * mm/allow-contrib-build (2013-02-07) 2 commits
>> - perl.mak: introduce $(GIT_ROOT_DIR) to allow inclusion from other
>> directories
>> - Makefile: extract perl-related rules to make them available from other
>> dirs
>>
>> Will merge to 'n
Jonathan Nieder writes:
> Junio C Hamano wrote:
>
>> The purpose of the directory is to keep custom commands that are
>> allowed. If the site administrator does not want any command, it
>> would be more natural to expect that the way to disable them would
>> be _not_ to have that directory which
From: Michal Nazarewicz
The third version of the patch with changes suggested by Jeff in the
4/5 patch. Also credential_read and credential_write are now public
functions in case someone wants to write a helper in perl.
Michal Nazarewicz (5):
Git.pm: allow command_close_bidi_pipe to be called
From: Michal Nazarewicz
The documentation of command_close_bidi_pipe() claims that it can
be called as a method, but it does not check whether the first
argument is $self or not assuming the latter. Using _maybe_self()
fixes this.
Signed-off-by: Michal Nazarewicz
---
perl/Git.pm | 2 +-
1 fil
From: Michal Nazarewicz
The command_close_bidi_pipe() function will insist on closing both
input and output pipes returned by command_bidi_pipe(). With this
change it is possible to close one of the pipes in advance and
pass undef as an argument.
Signed-off-by: Michal Nazarewicz
---
perl/Git.
From: Michal Nazarewicz
Signed-off-by: Michal Nazarewicz
---
perl/Git.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/perl/Git.pm b/perl/Git.pm
index bbb753a..11f310a 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -418,7 +418,7 @@ and it is the fourth value returned by
C
From: Michal Nazarewicz
If smtp_user is provided but smtp_pass is not, instead of
prompting for password, make git-send-email use git
credential command instead.
Signed-off-by: Michal Nazarewicz
---
Documentation/git-send-email.txt | 4 +--
git-send-email.perl | 59 ++
From: Michal Nazarewicz
Add a credential() function which is an interface to the git
credential command. The code is heavily based on credential_*
functions in .
Signed-off-by: Michal Nazarewicz
---
perl/Git.pm | 148 +++-
1 file changed
On Mon, Feb 11, 2013 at 02:57:51AM -0500, Ethan Reesor wrote:
> On Mon, Feb 11, 2013 at 2:50 AM, Konstantin Khomoutov
> wrote:
> > What's wrong with
> > $ ssh myuser@remotehost 'mkdir /path/to/MyRepo.git; cd $_; git init --bare'
> > $ git push --all git@remotehost:MyOtherRepo.git
> > ?
>
> Nothi
On 11.02.13 14:34, Erik Faye-Lund wrote:
> Even though parse-options doesn't support UTF-8 switches (which
> makes sense; non-ascii switches would be difficult to enter on
> some keyboard layouts), it can be useful to report incorrectly
> entered UTF-8 switches to make the output somewhat less ugly
Jonathan Nieder writes:
> Junio C Hamano wrote:
>> Jonathan Nieder writes:
>
>>> +To disable interactive logins, displaying a greeting instead:
>>> ++
>>> +
>>> +$ chsh -s /usr/bin/git-shell
>>> +$ mkdir $HOME/git-shell-commands
>>> +$ cat >$HOME/git-shell-commands/help <<\EOF
>>
On Mon, Feb 11, 2013 at 5:28 PM, Torsten Bögershausen wrote:
> On 11.02.13 14:34, Erik Faye-Lund wrote:
>> Even though parse-options doesn't support UTF-8 switches (which
>> makes sense; non-ascii switches would be difficult to enter on
>> some keyboard layouts), it can be useful to report incorre
John Keeping writes:
> Perhaps it's best to leave the patch as it originally was to guarantee
> that we can't get stuck in graph_show_commit(), even when it's called at
> an unexpected time, but I see you've already squashed this change in.
>
> Would you prefer me to resend the original patch or
On Mon, Feb 11, 2013 at 05:23:34PM +0100, Michal Nazarewicz wrote:
> From: Michal Nazarewicz
>
> The third version of the patch with changes suggested by Jeff in the
> 4/5 patch. Also credential_read and credential_write are now public
> functions in case someone wants to write a helper in perl
On Mon, Feb 11, 2013 at 05:23:38PM +0100, Michal Nazarewicz wrote:
> +=item credential_read( FILE_HANDLE )
> +
> +Reads credential key-value pairs from C. Reading stops at EOF
> or
> +when an empty line is encountered. Each line must be of the form
> C
> +with a non-empty key. Function return
On Mon, Feb 11, 2013 at 05:23:39PM +0100, Michal Nazarewicz wrote:
> + # TODO: Authentication may fail not because credentials were
> + # invalid but due to other reasons, in which we should not
> + # reject credentials.
> + $auth = Git::credential({
> + 'protocol' => '
On 11.02.13 17:36, Erik Faye-Lund wrote:
> On Mon, Feb 11, 2013 at 5:28 PM, Torsten Bögershausen wrote:
>> On 11.02.13 14:34, Erik Faye-Lund wrote:
>>> Even though parse-options doesn't support UTF-8 switches (which
>>> makes sense; non-ascii switches would be difficult to enter on
>>> some keyboa
Erik Faye-Lund writes:
> However, since git only looks at one byte at the time for
> short-options, it ends up reporting a partial UTF-8 sequence
> in such cases, leading to corruption of the output.
Isn't it a workable, easier and more robust alternative to punt and
use the entire ctx.argv[0] a
On Sun, Feb 10, 2013 at 11:33:26AM +0100, Thomas Koch wrote:
> thank you very much for your idea! It's good and simple. It just breaks down
> for the case when a large folder got renamed.
Yes, it would never find renames, which a true sha1->path map could.
> But I already hacked the basic layou
On Mon, Feb 11 2013, Jeff King wrote:
> On Mon, Feb 11, 2013 at 05:23:38PM +0100, Michal Nazarewicz wrote:
>
>> +=item credential_read( FILE_HANDLE )
>> +
>> +Reads credential key-value pairs from C. Reading stops at EOF
>> or
>> +when an empty line is encountered. Each line must be of the form
On Mon, Feb 11, 2013 at 6:07 PM, Junio C Hamano wrote:
> Erik Faye-Lund writes:
>
>> However, since git only looks at one byte at the time for
>> short-options, it ends up reporting a partial UTF-8 sequence
>> in such cases, leading to corruption of the output.
>
> Isn't it a workable, easier and
> On Mon, Feb 11, 2013 at 05:23:39PM +0100, Michal Nazarewicz wrote:
>> +# TODO: Authentication may fail not because credentials were
>> +# invalid but due to other reasons, in which we should not
>> +# reject credentials.
>> +$auth = Git::credential({
>> +'protocol' =>
On Mon, Feb 11 2013, Jeff King wrote:
> I have two minor comments, which I'll reply inline with. But even with
> those comments, I think this would be OK to merge.
I'll send a new patchset tomorrow with.
--
Best regards, _ _
.o. | Liege of Serenely Enl
Jeff King writes:
> On Sun, Feb 10, 2013 at 11:17:24PM -0800, Junio C Hamano wrote:
>
>> Jonathan Nieder writes:
>>
>> > Isn't that a criticism of the git-shell-commands facility in general?
>> > If it is common to have a lot of users with distinct home directories
>> > but all with git-shell a
On Mon, Feb 11, 2013 at 09:07:53AM -0800, Junio C Hamano wrote:
> Erik Faye-Lund writes:
>
> > However, since git only looks at one byte at the time for
> > short-options, it ends up reporting a partial UTF-8 sequence
> > in such cases, leading to corruption of the output.
>
> Isn't it a workab
>
> Looks perfectly normal to me. The message above:
>
> > HEAD is now at a0d271c... Linux 3.6
> > Bisecting: 0 revisions left to test after this (roughly 0 steps)
> > [d54b1a9e0eaca92cde678d19bd82b9594ed00450] perf script: Remove use of
> > die/exit
>
> is asking you to test the commit at d5
On Mon, Feb 11, 2013 at 6:19 PM, Jeff King wrote:
> On Mon, Feb 11, 2013 at 09:07:53AM -0800, Junio C Hamano wrote:
>
>> Erik Faye-Lund writes:
>>
>> > However, since git only looks at one byte at the time for
>> > short-options, it ends up reporting a partial UTF-8 sequence
>> > in such cases, l
On Mon, Feb 11, 2013 at 09:18:18AM -0800, Junio C Hamano wrote:
> That "shell-disabled" thing was to allow customizing the existing
> die() that triggers here:
> [...]
> so it is more like
>
> if ! test -d $HOME/git-shell-commands
> then
> if test -x /etc/git/shell-disab
On Mon, Feb 11, 2013 at 06:17:27PM +0100, Michal Nazarewicz wrote:
> > I am happy to put it off until it becomes a problem, but I wonder if the
> > Git::credential() interface is sufficient to express what we would want.
> > It only allows two return values: true for approve, false for reject.
> >
On Mon, Feb 11, 2013 at 06:14:24PM +0100, Michal Nazarewicz wrote:
> > Should this return a hash reference? It seems like that is how we end up
> > using and passing it elsewhere (since we have to anyway when passing it
> > as a parameter).
>
> Admittedly I mostly just copied what git-remote-medi
On Mon, Feb 11, 2013 at 06:18:04PM +0100, Michal Nazarewicz wrote:
> On Mon, Feb 11 2013, Jeff King wrote:
> > I have two minor comments, which I'll reply inline with. But even with
> > those comments, I think this would be OK to merge.
>
> I'll send a new patchset tomorrow with.
Based on our di
Jeff King writes:
> On Mon, Feb 11, 2013 at 09:07:53AM -0800, Junio C Hamano wrote:
>
>> Erik Faye-Lund writes:
>>
>> > However, since git only looks at one byte at the time for
>> > short-options, it ends up reporting a partial UTF-8 sequence
>> > in such cases, leading to corruption of the ou
On Mon, Feb 11, 2013 at 11:27 AM, Jeff King wrote:
[...]
> We talked about this a long time ago. One problem is that it's
> inherently unportable, as the procedure to make a repo is potentially
> different on every server (and certainly that is the case between a
> regular user running stock git a
On Mon, Feb 11, 2013 at 7:45 AM, Konstantin Khomoutov
wrote:
[...]
> OK, here's the sketch.
> On the server, in the home directory of your "git" user, you create a
> wrapper around git-receive-pack, like this:
>
> # mkdir ~git/git-shell-commands
> # cat >~git/git-shell-commands/git-receive-new-rep
Jonathan Nieder writes:
> diff --git a/Documentation/git-shell.txt b/Documentation/git-shell.txt
> index 9b925060..4fe93203 100644
> --- a/Documentation/git-shell.txt
> +++ b/Documentation/git-shell.txt
> @@ -9,25 +9,61 @@ git-shell - Restricted login shell for Git-only SSH access
> SYNOPSIS
>
On Mon, Feb 11 2013, Jeff King wrote:
> Based on our discussion, I think it would just need the patch below
> squashed into your 4/5 (this handles the "undef" thing, and I also fixed
> a few typos in the API documentation):
> @@ -1152,7 +1155,9 @@ sub credential {
> if ('CODE' eq ref $op_or_
On Mon, Feb 11, 2013 at 1:00 AM, Jonathan Nieder wrote:
> By the way, regarding what the right "--signoff" behavior is for
> commit, cherry-pick, am, and format-patch:
>
> I think the best behavior would be to check if the last signed-off-by
> line (ignoring acked-by, bug, change-id, and so on li
Sparse issues an "... was not declared. Should it be static?" warning
against the 'report_pack_garbage' symbol. In order to suppress the
warning, since this symbol requires more than file scope, we add an
extern declaration to the cache.h header file (and remove the now
redundant extern declaratio
On Mon, Feb 11, 2013 at 08:42:21AM -0800, Junio C Hamano wrote:
> John Keeping writes:
>
> > Perhaps it's best to leave the patch as it originally was to guarantee
> > that we can't get stuck in graph_show_commit(), even when it's called at
> > an unexpected time, but I see you've already squashe
Nguyễn Thái Ngọc Duy writes:
> +static char *get_head_description()
> +{
> + struct stat st;
> + struct strbuf sb = STRBUF_INIT;
> + struct strbuf result = STRBUF_INIT;
> + int bisect = 0;
> + int ret;
> + if (!stat(git_path("rebase-merge"), &st) && S_ISDIR(st.st_mode))
>
On Fri, Feb 08, 2013 at 04:47:01PM -0800, Junio C Hamano wrote:
> > Yeah, that actually is a good point. We should be using logmsg_reencode
> > so that we look for strings in the user's encoding.
>
> Perhaps like this. Just like the previous one (which should be
> discarded), this makes the fun
Commit eff80a9 (Allow custom "comment char") introduced a custom comment
character for commit messages but did not teach git-rebase--interactive
to use it.
Change git-rebase--interactive to read core.commentchar and use its
value when generating commit messages and for the todo list.
Signed-off-b
John Keeping writes:
> On Mon, Feb 11, 2013 at 08:42:21AM -0800, Junio C Hamano wrote:
>> John Keeping writes:
>>
>> > Perhaps it's best to leave the patch as it originally was to guarantee
>> > that we can't get stuck in graph_show_commit(), even when it's called at
>> > an unexpected time, bu
Jeff King writes:
> On Fri, Feb 08, 2013 at 04:47:01PM -0800, Junio C Hamano wrote:
>
>> > Yeah, that actually is a good point. We should be using logmsg_reencode
>> > so that we look for strings in the user's encoding.
>>
>> Perhaps like this. Just like the previous one (which should be
>> di
John Keeping writes:
> Commit eff80a9 (Allow custom "comment char") introduced a custom comment
> character for commit messages but did not teach git-rebase--interactive
> to use it.
>
> Change git-rebase--interactive to read core.commentchar and use its
> value when generating commit messages an
Junio C Hamano writes:
> Jeff King writes:
>
>> On Fri, Feb 08, 2013 at 04:47:01PM -0800, Junio C Hamano wrote:
>>
>>> > Yeah, that actually is a good point. We should be using logmsg_reencode
>>> > so that we look for strings in the user's encoding.
>>>
>>> Perhaps like this. Just like the p
On Mon, Feb 11, 2013 at 12:36:52PM -0800, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > Jeff King writes:
> >
> >> On Fri, Feb 08, 2013 at 04:47:01PM -0800, Junio C Hamano wrote:
> >>
> >>> > Yeah, that actually is a good point. We should be using logmsg_reencode
> >>> > so that we look
Jeff King writes:
> On Mon, Feb 11, 2013 at 12:36:52PM -0800, Junio C Hamano wrote:
>
>> Junio C Hamano writes:
>>
>> > Jeff King writes:
>> >
>> >> On Fri, Feb 08, 2013 at 04:47:01PM -0800, Junio C Hamano wrote:
>> >>
>> >>> > Yeah, that actually is a good point. We should be using
>> >>> >
If you run "git log --grep=foo", we will run your regex on
the literal bytes of the commit message. This can provide
confusing results if the commit message is not in the same
encoding as your grep expression (or worse, you have commits
in multiple encodings, in which case your regex would need
to
From: Matt Kraai
QNX 6.3.2 through 6.5.0 include Expat 1.1, which provides xmlparse.h
instead of expat.h, so include the former on QNX systems.
Signed-off-by: Matt Kraai
---
http-push.c | 4
1 file changed, 4 insertions(+)
diff --git a/http-push.c b/http-push.c
index 9923441..55c575e 100
On Sat, Feb 09, 2013 at 06:37:28PM +, Dasa Paddock wrote:
> I think this line should include --local:
>
> https://github.com/git/git/blob/next/contrib/completion/git-completion.bash#L1782
> "--global|--system|--file=*)"
Yeah, I think that makes sense.
Care to prepare a patch?
-Peff
--
On Mon, Feb 11, 2013 at 12:59:55PM -0800, Matt Kraai wrote:
> From: Matt Kraai
>
> QNX 6.3.2 through 6.5.0 include Expat 1.1, which provides xmlparse.h
> instead of expat.h, so include the former on QNX systems.
So it is not just QNX, but rather older versions of expat?
> diff --git a/http-pus
Jeff King writes:
> 1. I suppose we could also use $LANG or one of the $LC_* variables to
> guess at the encoding of the user's pattern. But I think using the
> output encoding makes the most sense, since then the pattern you
> searched for will actually be in the output.
I agre
On Mon, Feb 11, 2013 at 01:11:24PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > 1. I suppose we could also use $LANG or one of the $LC_* variables to
> > guess at the encoding of the user's pattern. But I think using the
> > output encoding makes the most sense, since then
On Mon, Feb 11, 2013 at 04:06:21PM -0500, Jeff King wrote:
> On Mon, Feb 11, 2013 at 12:59:55PM -0800, Matt Kraai wrote:
>
> > From: Matt Kraai
> >
> > QNX 6.3.2 through 6.5.0 include Expat 1.1, which provides xmlparse.h
> > instead of expat.h, so include the former on QNX systems.
>
> So it is
Matt Kraai writes:
> From: Matt Kraai
>
> QNX 6.3.2 through 6.5.0 include Expat 1.1, which provides xmlparse.h
> instead of expat.h, so include the former on QNX systems.
>
> Signed-off-by: Matt Kraai
> ---
Two points and a possibly irrelevant half:
- If a fix is platform specific (i.e. temp
On Mon, Feb 11, 2013 at 12:17:01PM -0800, Junio C Hamano wrote:
> John Keeping writes:
> > +comment_char=$(git config --get core.commentchar 2>/dev/null | cut -c1)
> > +: ${comment_char:=#}
>
> Hmm, somewhat ugly. I wonder if we can do this without pipe and cut.
Yeah, but I can't see a better w
Jeff King writes:
> On Mon, Feb 11, 2013 at 12:59:55PM -0800, Matt Kraai wrote:
>
>> From: Matt Kraai
>>
>> QNX 6.3.2 through 6.5.0 include Expat 1.1, which provides xmlparse.h
>> instead of expat.h, so include the former on QNX systems.
>
> So it is not just QNX, but rather older versions of e
John Keeping writes:
>> I do not think we would want to worry about comment_char being a
>> funny character that can possibly interfere with regexp. Can't we
>> do this with "git stripspace" piped to "wc -l" or something?
>
> I didn't know about "git stripspace",...
>> > -# If you remove a line
On Mon, Feb 11, 2013 at 01:34:52PM -0800, Junio C Hamano wrote:
> Two points and a possibly irrelevant half:
>
> - If a fix is platform specific (i.e. tempts to use #ifdef
>PLATFORM_NAME), we would prefer to see a patch that that is
>isolated to platform-specific compatibility layer, whic
Matt Kraai writes:
>> Assuming that this change is about building with expat1, it would
>> probably be better to do something like this instead, I would think.
>
> expat 1.95.0 through 1.95.8 used expat.h; should I still use
> EXPAT_VERSION = 1 to signify that it should use xmlparse.h, use
> EXPA
From: Matt Kraai
expat 1.1 and 1.2 provide xmlparse.h instead of expat.h. Include the
former on systems that define the EXPAT_NEEDS_XMLPARSE_H variable and
define that variable on QNX systems, which ship with expat 1.1.
Signed-off-by: Matt Kraai
---
Makefile | 6 ++
config.mak.una
Matt Kraai writes:
> From: Matt Kraai
>
> expat 1.1 and 1.2 provide xmlparse.h instead of expat.h. Include the
> former on systems that define the EXPAT_NEEDS_XMLPARSE_H variable and
> define that variable on QNX systems, which ship with expat 1.1.
>
> Signed-off-by: Matt Kraai
> ---
> ...
> d
From: Matt Kraai
expat 1.1 and 1.2 provide xmlparse.h instead of expat.h. Include the
former on systems that define the EXPAT_NEEDS_XMLPARSE_H variable and
define that variable on QNX systems, which ship with expat 1.1.
Signed-off-by: Matt Kraai
---
Makefile | 6 ++
config.mak.una
Matt Kraai writes:
> From: Matt Kraai
>
> expat 1.1 and 1.2 provide xmlparse.h instead of expat.h. Include the
> former on systems that define the EXPAT_NEEDS_XMLPARSE_H variable and
> define that variable on QNX systems, which ship with expat 1.1.
>
> Signed-off-by: Matt Kraai
> ---
> Makefi
Commit eff80a9 (Allow custom "comment char") introduced a custom comment
character for commit messages but did not teach git-rebase--interactive
to use it.
Change git-rebase--interactive to read core.commentchar and use its
value when generating commit messages and for the command list.
Signed-of
Because our command-line parser considers only one byte at the time
for short-options, we incorrectly report only the first byte when
multi-byte input was provided. This makes user-erros slightly
awkward to diagnose for instance under UTF-8 locale and non-English
keyboard layouts.
Make the reporti
Thanks.
--
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
John Keeping writes:
> @@ -179,7 +182,9 @@ die_abort () {
> }
>
> has_action () {
> - sane_grep '^[^#]' "$1" >/dev/null
> + echo "space stripped actions:" >&2
> + git stripspace --strip-comments <"$1" >&2
> + test -n "$(git stripspace --strip-comments <"$1")"
> }
I'll remove
I have found that if I add a remote and do a "git fetch -t -f remote_name" that
it *only* pulls tags.
Reading the man page it seems like it should pull all the remotes and all the
tags and the commits only reachable by tags.
Am I misreading this or it supposed to work this way. I don't mind do
On Tue, Feb 12, 2013 at 12:13:48AM +0100, Erik Faye-Lund wrote:
> I decided to change the text from what Jeff suggested; all we know is
> that it's non-ASCII. It might be Latin-1 or some other non-ASCII,
> single byte encoding. And since we're trying not to care, let's also
> try to not be overly
On Tue, Feb 12, 2013 at 6:13 AM, Erik Faye-Lund wrote:
> Because our command-line parser considers only one byte at the time
> for short-options, we incorrectly report only the first byte when
> multi-byte input was provided. This makes user-erros slightly
> awkward to diagnose for instance under
Duy Nguyen writes:
> On Tue, Feb 12, 2013 at 6:13 AM, Erik Faye-Lund wrote:
>> Because our command-line parser considers only one byte at the time
>> for short-options, we incorrectly report only the first byte when
>> multi-byte input was provided. This makes user-erros slightly
>> awkward to d
"Olsen, Alan R" writes:
> I have found that if I add a remote and do a "git fetch -t -f
> remote_name" that it *only* pulls tags.
>
> Reading the man page it seems like it should pull all the remotes
> and all the tags and the commits only reachable by tags.
This is what appears in the documenta
On Tue, Feb 12, 2013 at 9:10 AM, Junio C Hamano wrote:
>> Similar cases:
>>
>> config.c:git_default_core_config() assumes core.commentchar is ascii.
>> We should catch and report non-ascii chars, or simply accept it as a
>> string.
>
> That one is just an uninterpreted byte. core.commentString mi
Under the --color= option, it says:
Show colored diff. The value must be always (the default for ),
never, or auto. The default value is never.
That seems to imply that the default is both always and never. If I'm
right, I suggest removing the parenthesis, and putting the correct
default value at
Reuben Thomas writes:
> Under the --color= option, it says:
>
> Show colored diff. The value must be always (the default for ),
> never, or auto. The default value is never.
I think it wants to say this:
You can say "diff --color" without saying "when". That is the
same as saying "diff
On 12 February 2013 02:54, Junio C Hamano wrote:
> Reuben Thomas writes:
>
>> Under the --color= option, it says:
>>
>> Show colored diff. The value must be always (the default for ),
>> never, or auto. The default value is never.
>
> I think it wants to say this:
>
> You can say "diff --colo
I ran into these bugs the other day and didn't have time to
investigate further. So I wrote test cases for them instead.
Stephen Boyd (2):
t3501: Expose bug with cherry-pick into dirty trees w/ renames
t3501: Expose addinfo_cache error message in cherry-pick
t/t3501-revert-cherry-pick.sh |
I encountered a mysterious error message while doing some
cherry-picking into a dirty tree. In this case, the working tree
was dirty with changes to two files that had been renamed, we'll
call them 'file and 'otherfile'. The change I wanted to
cherry-pick was made along a branch before the rename t
I encountered this bug while doing some cherry-picking into a
dirty tree. In this case, the working tree was dirty with some
changes to a file that had been renamed. The change I wanted to
cherry-pick was made along another branch before the rename and
it matched a subset of my working tree modulo
When we are trying to show the list of config variables in a
file, we recognize "--system", "--global", and "--file" as
specifying a particular file. This list misses "--local",
which performs a similar function.
Without this patch, completing:
git config --get --local
shows items from all con
98 matches
Mail list logo
