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
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 a...@lisas.de
Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net
---
Documentation/git-bisect.txt | 7 ++-
1
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 reset
Junio C Hamano gits...@pobox.com 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
On Mon, Feb 11, 2013 at 9:56 AM, Duy Nguyen pclo...@gmail.com 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.305s
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
Erik Faye-Lund kusmab...@gmail.com 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
On Mon, Feb 11, 2013 at 2:43 PM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
Erik Faye-Lund kusmab...@gmail.com 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
Erik Faye-Lund kusmab...@gmail.com 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
On Sun, Feb 10, 2013 at 9:21 PM, Duy Nguyen pclo...@gmail.com wrote:
On Mon, Feb 11, 2013 at 2:03 AM, Robert Zeh robert.allan@gmail.com
wrote:
On Sat, Feb 9, 2013 at 1:35 PM, Junio C Hamano gits...@pobox.com wrote:
Ramkumar Ramachandra artag...@gmail.com writes:
This is much better than
On Sun, Feb 10, 2013 at 11:17:24PM -0800, Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com 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
Matthieu Moy matthieu@grenoble-inp.fr writes:
Junio C Hamano gits...@pobox.com 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
Jonathan Nieder jrnie...@gmail.com 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
From: Michal Nazarewicz min...@mina86.com
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
From: Michal Nazarewicz min...@mina86.com
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
From: Michal Nazarewicz min...@mina86.com
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
From: Michal Nazarewicz min...@mina86.com
Signed-off-by: Michal Nazarewicz min...@mina86.com
---
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
On Mon, Feb 11, 2013 at 02:57:51AM -0500, Ethan Reesor wrote:
On Mon, Feb 11, 2013 at 2:50 AM, Konstantin Khomoutov
kostix+...@007spb.ru wrote:
What's wrong with
$ ssh myuser@remotehost 'mkdir /path/to/MyRepo.git; cd $_; git init --bare'
$ git push --all git@remotehost:MyOtherRepo.git
?
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 jrnie...@gmail.com writes:
Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com writes:
+To disable interactive logins, displaying a greeting instead:
++
+
+$ chsh -s /usr/bin/git-shell
+$ mkdir $HOME/git-shell-commands
+$ cat
On Mon, Feb 11, 2013 at 5:28 PM, Torsten Bögershausen tbo...@web.de 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
On Mon, Feb 11, 2013 at 05:23:34PM +0100, Michal Nazarewicz wrote:
From: Michal Nazarewicz min...@mina86.com
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
On Mon, Feb 11, 2013 at 05:23:38PM +0100, Michal Nazarewicz wrote:
+=item credential_read( FILE_HANDLE )
+
+Reads credential key-value pairs from CFILE_HANDLE. Reading stops at EOF
or
+when an empty line is encountered. Each line must be of the form
Ckey=value
+with a non-empty key.
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' =
Erik Faye-Lund kusmab...@gmail.com 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
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 layout
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 CFILE_HANDLE. 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 gits...@pobox.com wrote:
Erik Faye-Lund kusmab...@gmail.com 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.
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
Jeff King p...@peff.net writes:
On Sun, Feb 10, 2013 at 11:17:24PM -0800, Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com 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
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 d54b1a9e and
On Mon, Feb 11, 2013 at 6:19 PM, Jeff King p...@peff.net wrote:
On Mon, Feb 11, 2013 at 09:07:53AM -0800, Junio C Hamano wrote:
Erik Faye-Lund kusmab...@gmail.com writes:
However, since git only looks at one byte at the time for
short-options, it ends up reporting a partial UTF-8 sequence
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-disabled
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.
But we
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-mediawiki
On Mon, Feb 11, 2013 at 11:27 AM, Jeff King p...@peff.net 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
On Mon, Feb 11, 2013 at 7:45 AM, Konstantin Khomoutov
kostix+...@007spb.ru 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
Jonathan Nieder jrnie...@gmail.com 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
On Mon, Feb 11, 2013 at 1:00 AM, Jonathan Nieder jrnie...@gmail.com 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,
On Mon, Feb 11, 2013 at 08:42:21AM -0800, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk 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
Nguyễn Thái Ngọc Duy pclo...@gmail.com 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)
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 function
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.
John Keeping j...@keeping.me.uk writes:
On Mon, Feb 11, 2013 at 08:42:21AM -0800, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk 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
Jeff King p...@peff.net 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
John Keeping j...@keeping.me.uk 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
Jeff King p...@peff.net writes:
On Mon, Feb 11, 2013 at 12:36:52PM -0800, Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com writes:
Jeff King p...@peff.net writes:
On Fri, Feb 08, 2013 at 04:47:01PM -0800, Junio C Hamano wrote:
Yeah, that actually is a good point. We should
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
On Mon, Feb 11, 2013 at 12:59:55PM -0800, Matt Kraai wrote:
From: Matt Kraai matt.kr...@amo.abbott.com
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?
Jeff King p...@peff.net 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
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 matt.kr...@amo.abbott.com
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
Matt Kraai kr...@ftbfs.org writes:
From: Matt Kraai matt.kr...@amo.abbott.com
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 matt.kr...@amo.abbott.com
---
Two points and a possibly
On Mon, Feb 11, 2013 at 12:17:01PM -0800, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk 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
Jeff King p...@peff.net writes:
On Mon, Feb 11, 2013 at 12:59:55PM -0800, Matt Kraai wrote:
From: Matt Kraai matt.kr...@amo.abbott.com
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
John Keeping j...@keeping.me.uk 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
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, which
Matt Kraai kr...@ftbfs.org 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,
From: Matt Kraai matt.kr...@amo.abbott.com
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
Matt Kraai kr...@ftbfs.org writes:
From: Matt Kraai matt.kr...@amo.abbott.com
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.
From: Matt Kraai matt.kr...@amo.abbott.com
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
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.
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
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 j...@keeping.me.uk 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 the
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
Duy Nguyen pclo...@gmail.com writes:
On Tue, Feb 12, 2013 at 6:13 AM, Erik Faye-Lund kusmab...@gmail.com 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
Olsen, Alan R alan.r.ol...@intel.com 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
On Tue, Feb 12, 2013 at 9:10 AM, Junio C Hamano gits...@pobox.com 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.
Under the --color=when option, it says:
Show colored diff. The value must be always (the default for when),
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
Reuben Thomas r...@sc3d.org writes:
Under the --color=when option, it says:
Show colored diff. The value must be always (the default for when),
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
On 12 February 2013 02:54, Junio C Hamano gits...@pobox.com wrote:
Reuben Thomas r...@sc3d.org writes:
Under the --color=when option, it says:
Show colored diff. The value must be always (the default for when),
never, or auto. The default value is never.
I think it wants to say this:
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
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 config
76 matches
Mail list logo
