* Re: [PATCH] Make sure $PERL_PATH is defined when the test suite is run.
From: Junio C Hamano @ 2009-11-17 18:25 UTC (permalink / raw)
To: Philippe Bruhat (BooK); +Cc: Johannes Sixt, git
In-Reply-To: <20091117083557.GC3608@plop>
"Philippe Bruhat (BooK)" <book@cpan.org> writes:
>> Make it: ... >>$@
>
> This proves late commits needs many extra pair of eyes. :-)
> ...
>> This one needs the double-quotes as well.
>
> Thanks. Sending again. (sorry for the noise)
Thanks, I also missed them. Will re-queue.
^ permalink raw reply
* Re: Make Gitweb behave like Apache mod_userdir
From: Jakub Narebski @ 2009-11-17 18:12 UTC (permalink / raw)
To: Sylvain Rabot; +Cc: Junio C Hamano, Petr Baudis, Luben Tuikov, J.H., git
In-Reply-To: <7fce93be0911170751r6d51ae7bn20fd593741b3eba6@mail.gmail.com>
On Tue, 17 Nov 2009, Sylvain Rabot wrote:
> On Tue, Nov 17, 2009 at 14:58, Jakub Narebski <jnareb@gmail.com> wrote:
> > The description is a bit lacking. Where user should put theirs git
> > repositories, or symbolic links to git repositories?
>
> As I said It's only configuration so It depends of your server
> architecture. If admin of the server decides he allows users to browse
> via gitweb their private/public repos which are linked in
> /home/*/.gitweb or anything else he has to modify the environmental
> variable in the rewrite rule according to his wish.
So in described configuration, to make repository visible user would have
to put repository, or symbolic link to repository (or .git/ directory of
the repository) in ~/gitweb/ directory (just like one would need to put
HTML files in ~/public_html/ or ~/WWW/ to have them visible as web site),
isn't it?
> > How it would look like in gitweb?
>
> What do you mean ?
How would example gitweb URL to repository look like?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH v2 0/2] user-manual: new "getting started" section
From: Matthieu Moy @ 2009-11-17 17:53 UTC (permalink / raw)
To: Nanako Shiraishi
Cc: Felipe Contreras, Michael J Gruber, Jonathan Nieder,
Junio C Hamano, git, J. Bruce Fields, Hannu Koivisto, Jeff King,
Wincent Colaiuta, Matthias Lederhofer
In-Reply-To: <20091117210625.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> I don't see how you can make them sanely be usable to
> other commands like "git log v1.0.0..WORKTREE".
See what gitk is showing you when you have uncommited changes. You
have some kind of "pseudo-commits" on top of your history for the
index and the worktree. "git log v1.0.0..WORKTREE" could very well be
a text-mode version of what's already in gitk.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH v2 0/2] user-manual: new "getting started" section
From: J. Bruce Fields @ 2009-11-17 17:28 UTC (permalink / raw)
To: Nanako Shiraishi
Cc: Felipe Contreras, Michael J Gruber, Jonathan Nieder,
Junio C Hamano, git, Hannu Koivisto, Jeff King, Wincent Colaiuta,
Matthias Lederhofer
In-Reply-To: <20091117210625.6117@nanako3.lavabit.com>
On Tue, Nov 17, 2009 at 09:06:25PM +0900, Nanako Shiraishi wrote:
> David's proposal introduced two magic tokens STAGE and WORKTREE.
>
> git diff STAGE WORKTREE (like "git diff" today)
> git diff HEAD WORKTREE (like "git diff HEAD" today)
> git diff WORKTREE HEAD (like "git diff -R HEAD" today)
> git diff HEAD STAGE (like "git diff --cached" today)
> git diff commit STAGE (like "git diff --cached commit" today)
>
> This looks nice on surface, but I think the apparent niceness
> is shallow. If of course has a small problem of introducing an
> obvious backward incompatibility. You can't use a branch whose
> name is STAGE anymore, but a deeper problem is that these two
> magic tokens pretend to be refs. But they do so only to the diff
> command. I don't see how you can make them sanely be usable to
> other commands like "git log v1.0.0..WORKTREE".
Doesn't appear that refs have to point to commits; e.g., on the linux
project:
git log v2.6.11-tree..v2.6.32-rc7
error: Object 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c is a tree, not a
commit
fatal: Invalid revision range v2.6.11-tree..v2.6.32-rc7
You might be able to add some extra syntax to prevent conflicts with
branch names. Uh, :STAGE, :WORKTREE ?? But I think that conflicts with
something else. And the "magic tokens" get a little uglier and harder
to remember. Bah.
--b.
^ permalink raw reply
* [PATCH v2] Expand ~ and ~user in core.excludesfile, commit.template
From: Matthieu Moy @ 2009-11-17 17:24 UTC (permalink / raw)
To: git, gitster; +Cc: Matthieu Moy, Karl Chen
In-Reply-To: <1258366060-27966-1-git-send-email-Matthieu.Moy@imag.fr>
These config variables are parsed to substitute ~ and ~user with getpw
entries.
user_path() refactored into new function expand_user_path(), to allow
dynamically allocating the return buffer.
Original patch by Karl Chen, modified by Matthieu Moy, and further
amended by Junio C Hamano.
Signed-off-by: Karl Chen <quarl@quarl.org>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
Here's the new version, with Junio's modifications squashed in.
I just replaced "user" with "specified user" to make it clear one can
specify a user with ~foo/, but since the documentation appears in two
places (possibly more in the future), I prefered to Keep It Simple.
Documentation/config.txt | 4 ++-
builtin-commit.c | 2 +-
cache.h | 2 +
config.c | 12 ++++++-
path.c | 80 ++++++++++++++++++++++++++-------------------
5 files changed, 63 insertions(+), 37 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index d1e2120..475d544 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -380,7 +380,8 @@ Common unit suffixes of 'k', 'm', or 'g' are supported.
core.excludesfile::
In addition to '.gitignore' (per-directory) and
'.git/info/exclude', git looks into this file for patterns
- of files which are not meant to be tracked. See
+ of files which are not meant to be tracked. "~/" and "~user/"
+ are expanded to the specified user's home directory. See
linkgit:gitignore[5].
core.editor::
@@ -670,6 +671,7 @@ color.ui::
commit.template::
Specify a file to use as the template for new commit messages.
+ "~/" and "~user/" are expanded to the specified user's home directory.
diff.autorefreshindex::
When using 'git-diff' to compare with work tree
diff --git a/builtin-commit.c b/builtin-commit.c
index d525b89..09d2840 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -999,7 +999,7 @@ static int git_commit_config(const char *k, const char *v, void *cb)
struct wt_status *s = cb;
if (!strcmp(k, "commit.template"))
- return git_config_string(&template_file, k, v);
+ return git_config_pathname(&template_file, k, v);
return git_status_config(k, v, s);
}
diff --git a/cache.h b/cache.h
index 71a731d..42f7cd8 100644
--- a/cache.h
+++ b/cache.h
@@ -645,6 +645,7 @@ int set_shared_perm(const char *path, int mode);
#define adjust_shared_perm(path) set_shared_perm((path), 0)
int safe_create_leading_directories(char *path);
int safe_create_leading_directories_const(const char *path);
+extern char *expand_user_path(const char *path);
char *enter_repo(char *path, int strict);
static inline int is_absolute_path(const char *path)
{
@@ -903,6 +904,7 @@ extern unsigned long git_config_ulong(const char *, const char *);
extern int git_config_bool_or_int(const char *, const char *, int *);
extern int git_config_bool(const char *, const char *);
extern int git_config_string(const char **, const char *, const char *);
+extern int git_config_pathname(const char **, const char *, const char *);
extern int git_config_set(const char *, const char *);
extern int git_config_set_multivar(const char *, const char *, const char *, int);
extern int git_config_rename_section(const char *, const char *);
diff --git a/config.c b/config.c
index c644061..b3d1ff4 100644
--- a/config.c
+++ b/config.c
@@ -351,6 +351,16 @@ int git_config_string(const char **dest, const char *var, const char *value)
return 0;
}
+int git_config_pathname(const char **dest, const char *var, const char *value)
+{
+ if (!value)
+ return config_error_nonbool(var);
+ *dest = expand_user_path(value);
+ if (!*dest)
+ die("Failed to expand user dir in: '%s'", value);
+ return 0;
+}
+
static int git_default_core_config(const char *var, const char *value)
{
/* This needs a better name */
@@ -474,7 +484,7 @@ static int git_default_core_config(const char *var, const char *value)
return git_config_string(&editor_program, var, value);
if (!strcmp(var, "core.excludesfile"))
- return git_config_string(&excludes_file, var, value);
+ return git_config_pathname(&excludes_file, var, value);
if (!strcmp(var, "core.whitespace")) {
if (!value)
diff --git a/path.c b/path.c
index 047fdb0..2470f78 100644
--- a/path.c
+++ b/path.c
@@ -11,6 +11,7 @@
* which is what it's designed for.
*/
#include "cache.h"
+#include "strbuf.h"
static char bad_path[] = "/bad-path/";
@@ -207,43 +208,44 @@ int validate_headref(const char *path)
return -1;
}
-static char *user_path(char *buf, char *path, int sz)
+static struct passwd *getpw_str(const char *username, size_t len)
{
struct passwd *pw;
- char *slash;
- int len, baselen;
+ char *username_z = xmalloc(len + 1);
+ memcpy(username_z, username, len);
+ username_z[len] = '\0';
+ pw = getpwnam(username_z);
+ free(username_z);
+ return pw;
+}
- if (!path || path[0] != '~')
- return NULL;
- path++;
- slash = strchr(path, '/');
- if (path[0] == '/' || !path[0]) {
- pw = getpwuid(getuid());
- }
- else {
- if (slash) {
- *slash = 0;
- pw = getpwnam(path);
- *slash = '/';
- }
- else
- pw = getpwnam(path);
- }
- if (!pw || !pw->pw_dir || sz <= strlen(pw->pw_dir))
- return NULL;
- baselen = strlen(pw->pw_dir);
- memcpy(buf, pw->pw_dir, baselen);
- while ((1 < baselen) && (buf[baselen-1] == '/')) {
- buf[baselen-1] = 0;
- baselen--;
- }
- if (slash && slash[1]) {
- len = strlen(slash);
- if (sz <= baselen + len)
- return NULL;
- memcpy(buf + baselen, slash, len + 1);
+/*
+ * Return a string with ~ and ~user expanded via getpw*. If buf != NULL,
+ * then it is a newly allocated string. Returns NULL on getpw failure or
+ * if path is NULL.
+ */
+char *expand_user_path(const char *path)
+{
+ struct strbuf user_path = STRBUF_INIT;
+ const char *first_slash = strchrnul(path, '/');
+ const char *to_copy = path;
+
+ if (path == NULL)
+ goto return_null;
+ if (path[0] == '~') {
+ const char *username = path + 1;
+ size_t username_len = first_slash - username;
+ struct passwd *pw = getpw_str(username, username_len);
+ if (!pw)
+ goto return_null;
+ strbuf_add(&user_path, pw->pw_dir, strlen(pw->pw_dir));
+ to_copy = first_slash;
}
- return buf;
+ strbuf_add(&user_path, to_copy, strlen(to_copy));
+ return strbuf_detach(&user_path, NULL);
+return_null:
+ strbuf_release(&user_path);
+ return NULL;
}
/*
@@ -291,8 +293,18 @@ char *enter_repo(char *path, int strict)
if (PATH_MAX <= len)
return NULL;
if (path[0] == '~') {
- if (!user_path(used_path, path, PATH_MAX))
+ char *newpath = expand_user_path(path);
+ if (!newpath || (PATH_MAX - 10 < strlen(newpath))) {
+ free(newpath);
return NULL;
+ }
+ /*
+ * Copy back into the static buffer. A pity
+ * since newpath was not bounded, but other
+ * branches of the if are limited by PATH_MAX
+ * anyway.
+ */
+ strcpy(used_path, newpath); free(newpath);
strcpy(validated_path, path);
path = used_path;
}
--
1.6.5.2.152.gbbe9e
^ permalink raw reply related
* Re: Make Gitweb behave like Apache mod_userdir
From: Sylvain Rabot @ 2009-11-17 15:51 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, Petr Baudis, Luben Tuikov, J.H., git
In-Reply-To: <200911171458.56047.jnareb@gmail.com>
On Tue, Nov 17, 2009 at 14:58, Jakub Narebski <jnareb@gmail.com> wrote:
> On Sun, 15 Nov 2009, Junio C Hamano wrote:
>> Sylvain Rabot <sylvain@abstraction.fr> writes:
>>
>> > I made gitweb behave a bit like UserDir module will in apache.
>> > In fact it's only configuration but I think it could be useful to others.
>>
>> Thanks. Any comment from gitweb gangs?
>
> I would respond earlier if it was submitted with patch inline in mail
> body, and not attached. If it needs to be attached (because of MUA/MTA
> linewrapping or encoding issues), it should use 8bit and not base64
> content transfer encoding, have 'text/plain' and not
> 'application/octet-stream' content type, and "inline" and not "attachement"
> in content disposition.
Sorry about that but I'm new in the git world and it is the first time
I submit a patch.
> It also lacks proper commit message (although email describes it quite
> well) and signoff, as per Documentation/SubmittingPatches.
>
> I like this patch. More examples in gitweb/README are always good idea.
>
>> > Basicly it allows users of your server who use git to be able to use
>
> "Basically"
Oops
>
>> > gitweb to browse their own root project. E.G. :
>
> "For example"
>
>> >
>> > Alice's private repos :
>> >
>> > /home/alice/git/product_a.git (cloned from /var/git/product_a.git)
>> > /home/alice/git/product_b.git (cloned from /var/git/product_b.git)
>> > /home/alice/git/product_c.git (cloned from /var/git/product_c.git)
>> >
>> > Alice's links to her repos which she wants to be able to browse with gitweb :
>
> "Alice links", or "Alice creates symbolic links"
>
>> >
>> > /home/alice/gitweb/product_a -> /home/alice/git/product_a.git/.git
>> > /home/alice/gitweb/product_c -> /home/alice/git/product_c.git/.git
>> >
>> > Bare repos :
>> >
>> > /var/git/product_a.git
>> > /var/git/product_b.git
>> > /var/git/product_c.git
>> > /var/git/product_d.git
>
> The description is a bit lacking. Where user should put theirs git
> repositories, or symbolic links to git repositories?
As I said It's only configuration so It depends of your server
architecture. If admin of the server decides he allows users to browse
via gitweb their private/public repos which are linked in
/home/*/.gitweb or anything else he has to modify the environmental
variable in the rewrite rule according to his wish.
> How it would look like in gitweb?
What do you mean ?
> --
> Jakub Narebski
> Poland
^ permalink raw reply
* Re: Make Gitweb behave like Apache mod_userdir
From: Jakub Narebski @ 2009-11-17 13:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, Luben Tuikov, J.H., git, Sylvain Rabot
In-Reply-To: <7vskcffqkn.fsf@alter.siamese.dyndns.org>
On Sun, 15 Nov 2009, Junio C Hamano wrote:
> Sylvain Rabot <sylvain@abstraction.fr> writes:
>
> > I made gitweb behave a bit like UserDir module will in apache.
> > In fact it's only configuration but I think it could be useful to others.
>
> Thanks. Any comment from gitweb gangs?
I would respond earlier if it was submitted with patch inline in mail
body, and not attached. If it needs to be attached (because of MUA/MTA
linewrapping or encoding issues), it should use 8bit and not base64
content transfer encoding, have 'text/plain' and not
'application/octet-stream' content type, and "inline" and not "attachement"
in content disposition.
It also lacks proper commit message (although email describes it quite
well) and signoff, as per Documentation/SubmittingPatches.
I like this patch. More examples in gitweb/README are always good idea.
> > Basicly it allows users of your server who use git to be able to use
"Basically"
> > gitweb to browse their own root project. E.G. :
"For example"
> >
> > Alice's private repos :
> >
> > /home/alice/git/product_a.git (cloned from /var/git/product_a.git)
> > /home/alice/git/product_b.git (cloned from /var/git/product_b.git)
> > /home/alice/git/product_c.git (cloned from /var/git/product_c.git)
> >
> > Alice's links to her repos which she wants to be able to browse with gitweb :
"Alice links", or "Alice creates symbolic links"
> >
> > /home/alice/gitweb/product_a -> /home/alice/git/product_a.git/.git
> > /home/alice/gitweb/product_c -> /home/alice/git/product_c.git/.git
> >
> > Bare repos :
> >
> > /var/git/product_a.git
> > /var/git/product_b.git
> > /var/git/product_c.git
> > /var/git/product_d.git
The description is a bit lacking. Where user should put theirs git
repositories, or symbolic links to git repositories? How it would
look like in gitweb?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] Expand ~ and ~user in core.excludesfile, commit.template
From: Jakub Narebski @ 2009-11-17 13:30 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Junio C Hamano, git, Karl Chen
In-Reply-To: <vpqlji5plyn.fsf@bauges.imag.fr>
Dnia wtorek 17. listopada 2009 09:57, Matthieu Moy napisał:
> Junio C Hamano <gitster@pobox.com> writes:
>> Jakub Narebski <jnareb@gmail.com> writes:
>>
>>> It would be nice to have an option to git-config which would do such
>>> expansion, as a separate type similar to --int and --bool, e.g.:
>>>
>>> git config --path section.key
>>>
>>> so that not only core.excludesfile could use this new feature, but for
>>> example also core.worktree, commit.template, gitcvs.logfile,
>>> mailmap.file, and perhaps also *.receivepack and *.uploadpack
>>
>> What should "git config -l" do for these (and core.excludesfile)?
>
> I don't know what it "should", but it "does" not do the expansion. I
> had the same questionning when testing the patch, I'd have liked to be
> able to write a simple test-case like
>
> $ git config core.excludesfile '~/foo'
> $ git config --i-dont-know-what core.excludesfile
>
> to go through this codepath. Maybe we can just say
>
> $ git config --default core.excludesfile
>
> to say "call git_default_config(...) on this before printing it". My
> understanding is that this is what the C code is doing, we should
> allow the shell scripts to do the same.
I think it is a very good idea. Nevertheless it can apply only to
config variables git core knows about, and not for example for git-gui,
or gitk, or qgit, or tig, or StGIT, etc. configuration. Therefore
"git config --path" would be still needed.
--
Jakub Narębski
Poland
^ permalink raw reply
* gitk does not show path file list
From: Mark Blakeney @ 2009-11-17 12:09 UTC (permalink / raw)
To: git
gitk takes a path to limit commits to those touching those files.
However, doing "gitk ." does not list any files in the right window
file list when trying to view commits for the current dir (which would
seem to be a common use-case, particularly for me at least). Why is
the affected [subset] of files not shown?
Just seems to be a bug to this newbie, particularly when it does work
as I expect if I do a "cd .." and then "gitk src" where src was my
original dir. I'm using version 1.6.5.3 now but this has existed since
I started with git quite some time ago.
^ permalink raw reply
* Re: [PATCH v2 0/2] user-manual: new "getting started" section
From: Nanako Shiraishi @ 2009-11-17 12:06 UTC (permalink / raw)
To: Felipe Contreras
Cc: Michael J Gruber, Jonathan Nieder, Junio C Hamano, git,
J. Bruce Fields, Hannu Koivisto, Jeff King, Wincent Colaiuta,
Matthias Lederhofer
In-Reply-To: <94a0d4530911161452xe82858el322a1985341bf13c@mail.gmail.com>
Quoting Felipe Contreras <felipe.contreras@gmail.com>
> On Fri, Nov 13, 2009 at 11:06 PM, Nanako Shiraishi <nanako3@lavabit.com> wrote:
>> ... I don't
>> think Felipe seriously wants to change them to --gogo vs --dance, but
>> if he made a more constructive proposal, instead of making such a
>> comment whose intended effect is only to annoy people, we may see
>> an improved UI at the end. Proposing "--index-only" vs "--index-too"
>> or even "--stage-only" vs "--stage-too" would have helped him appear
>> to be more serious and constructive and I think your expression
>> "mismatching participants" was a great way to say this.
>
> Right, your explanation is more clear:
You have a funny way of saying "I'm sorry, I wasn't constructive,
and my attitude repelled many participants from the discussion".
> the fact that we need both
> doesn't mean we cannot use the term "stage". As to "constructive
> proposal" I deliberately tried to avoid them in case somebody tried to
> disregard it as bike-shedding, and move on.
If the only constructive proposal you could make is to replace
words used in two operations without clarifying concepts any
better to newbies, then what you are doing is bike-shedding.
I don't think trying to hide that by not making any proposal
changes that.
> What I'm trying to do is
> bring up the issue that the stage is not user friendly.
I thought you were the one who wanted to use "stage" everywhere?
For what it's worth, "stage" isn't very user friendly to me;
maybe it is because I'm not a native English speaker. I'm not
saying that when I hear "index" or "cached" I'll understand
what they mean even if I didn't have any prior knowledge of
git, but I am saying "stage" isn't any better than these two
words in that respect. Of course the user needs to understand
what it is and how it is used, no matter what word you use.
I think a proposal to replace the word "index" with "stage"
will sound nothing but bike-shedding to anybody, especially
after getting familiar with "index" and seeing it taught on
many web pages and books.
> I like David Kågedal's suggestion more:
> http://kerneltrap.org/mailarchive/git/2008/10/29/3857134
For people who like a usable threaded interface to read
the message in context here is its URL.
http://thread.gmane.org/gmane.comp.version-control.git/99332/focus=99401
Yes, I had David's proposal in mind when I wrote my response.
Even though the fundamental idea is the same, I used --X-vs-Y
option to avoid the problems David's proposal has in a slightly
nicer way.
David's proposal introduced two magic tokens STAGE and WORKTREE.
git diff STAGE WORKTREE (like "git diff" today)
git diff HEAD WORKTREE (like "git diff HEAD" today)
git diff WORKTREE HEAD (like "git diff -R HEAD" today)
git diff HEAD STAGE (like "git diff --cached" today)
git diff commit STAGE (like "git diff --cached commit" today)
This looks nice on surface, but I think the apparent niceness
is shallow. If of course has a small problem of introducing an
obvious backward incompatibility. You can't use a branch whose
name is STAGE anymore, but a deeper problem is that these two
magic tokens pretend to be refs. But they do so only to the diff
command. I don't see how you can make them sanely be usable to
other commands like "git log v1.0.0..WORKTREE".
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.6.5.3
From: Jakub Narebski @ 2009-11-17 10:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4ootltzm.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> The RPM binary packages for a few architectures are found in:
>
> RPMS/$arch/git-*-1.6.5.3-1.fc9.$arch.rpm (RPM)
It's RPMS/$arch/git-*-1.6.5.3-1.fc11.$arch.rpm (RPM)
> Git v1.6.5.3 Release Notes
> ==========================
>
> Fixes since v1.6.5.2
> --------------------
> * Packages generated on newer FC were unreadable by older versions of
> RPM as the new default is to use stronger hash.
Thanks.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: bash completion on 4.0 broken?
From: Michael J Gruber @ 2009-11-17 9:54 UTC (permalink / raw)
To: Stephen Boyd; +Cc: git, Shawn O. Pearce
In-Reply-To: <4B0246C7.6020401@gmail.com>
Stephen Boyd venit, vidit, dixit 17.11.2009 07:46:
> When I try
>
> git show --pretty=<TAB><TAB>
>
> I get a list of filenames and not the list of pretty formats.
>
> I've debugged a little and see that the cur variable in _git_show () is
> set to '=' when it should be '--pretty='. So it looks like something is
> causing the command line to be split weirdly. Looking at the bash
> NEWS[1] for 4.0 I see
>
> i. The programmable completion code now uses the same set of characters as
> readline when breaking the command line into a list of words.
>
>
> which causes me to believe this is why it's broken now. I've tried
> removing '=' from COMP_WORDBREAKS and that shows the list of formats
> correctly, but then causes the entire '--pretty=' to be replaced with
> the selected format.
>
> Anyone else seeing the same problem or is my system just b0rked?
>
> $ bash --version
> GNU bash, version 4.0.35(2)-release (x86_64-pc-linux-gnu)
>
> References:
> [1] http://tiswww.case.edu/php/chet/bash/NEWS
Ouch, just when I decided to use completion rather than a bunch of
aliases it stops working. B0rked here 0ls0 on Fedora 12 (with git.git's
next):
GNU bash, Version 4.0.33(1)-release (x86_64-redhat-linux-gnu)
Command name completion and prompt magic do work.
Michael
^ permalink raw reply
* Re: [PATCH 1/2] replace: use a GIT_NO_REPLACE_OBJECTS env variable
From: Michael J Gruber @ 2009-11-17 9:33 UTC (permalink / raw)
To: Christian Couder
Cc: Junio C Hamano, git, Jakub Narebski, Johannes Sixt, bill lam,
Andreas Schwab, Paul Mackerras
In-Reply-To: <20091117051125.3588.91072.chriscool@tuxfamily.org>
Christian Couder venit, vidit, dixit 17.11.2009 06:11:
> This environment variable is set when the --no-replace-objects
> flag is passed to git, and it is read when other environment
> variables are read.
>
> It is useful for example for scripts, as the git commands used in
> them can now be aware that they must not read replace refs.
>
> Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Tested-by: Michael J Gruber <git@drmicha.warpmail.net>
:) This works, thanks, as well as the gitk patch 2/2, which is difficult
to cover by test scripts. Some OSes (or rather certain setenv/putenv
variants) have problems distinguishing an unset variable from an empty
one. I think we've worked around this, but avoiding it is safer, as J6t
pointed out.
Thanks!
Michael
^ permalink raw reply
* Re: [PATCH] Expand ~ and ~user in core.excludesfile, commit.template
From: Jakub Narebski @ 2009-11-17 9:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matthieu Moy, git, Karl Chen
In-Reply-To: <7viqd9isbm.fsf@alter.siamese.dyndns.org>
Dnia wtorek 17. listopada 2009 07:22, Junio C Hamano napisał:
> Jakub Narebski <jnareb@gmail.com> writes:
> >
> > It would be nice to have an option to git-config which would do such
> > expansion, as a separate type similar to --int and --bool, e.g.:
> >
> > git config --path section.key
> >
> > so that not only core.excludesfile could use this new feature, but for
> > example also core.worktree, commit.template, gitcvs.logfile,
> > mailmap.file, and perhaps also *.receivepack and *.uploadpack
>
> What should "git config -l" do for these (and core.excludesfile)?
Nothing (i.e. show unexpanded / not converted), just like for boolean
variables "git config -l" doesn't convert 1/on/yes to true, and 0/off/no
to false, just like for integer variables "git config -l" doesn't convert
to simple decimal number taking into account optional 'k', 'm' or 'g'
suffix.
BTW. the suffix part of integer conversion should really be described
in the paragraph about --int and --bool options (which should be made
into proper description list, and not a prose paragraph).
P.S. I am a bit missing --local / --repository option to git-config to
complement --global (which should probably be named --user) and --system
options.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] Expand ~ and ~user in core.excludesfile, commit.template
From: Matthieu Moy @ 2009-11-17 8:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Karl Chen
In-Reply-To: <7vy6m5hci0.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> I'd like to squash this to your patch, based on the earlier review
> comments.
Sure. And apologize for the style issues, I knew it, but one hardly
changes his (bad) habits ;-).
I'll resend soon.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH] Expand ~ and ~user in core.excludesfile, commit.template
From: Matthieu Moy @ 2009-11-17 8:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git, Karl Chen
In-Reply-To: <7viqd9isbm.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> It would be nice to have an option to git-config which would do such
>> expansion, as a separate type similar to --int and --bool, e.g.:
>>
>> git config --path section.key
>>
>> so that not only core.excludesfile could use this new feature, but for
>> example also core.worktree, commit.template, gitcvs.logfile,
>> mailmap.file, and perhaps also *.receivepack and *.uploadpack
>
> What should "git config -l" do for these (and core.excludesfile)?
I don't know what it "should", but it "does" not do the expansion. I
had the same questionning when testing the patch, I'd have liked to be
able to write a simple test-case like
$ git config core.excludesfile '~/foo'
$ git config --i-dont-know-what core.excludesfile
to go through this codepath. Maybe we can just say
$ git config --default core.excludesfile
to say "call git_default_config(...) on this before printing it". My
understanding is that this is what the C code is doing, we should
allow the shell scripts to do the same.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH] Expand ~ and ~user in core.excludesfile, commit.template
From: Jeff King @ 2009-11-17 8:56 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git, Karl Chen
In-Reply-To: <vpqpr7hpm5b.fsf@bauges.imag.fr>
On Tue, Nov 17, 2009 at 09:53:52AM +0100, Matthieu Moy wrote:
> Yes. "user" in the sentence is either the user running Git or the same
> string as "user" in "~user". I'm not against your proposal, but I'm
> afraid we're making the sentence uselessly heavy, since, as you say,
> this ~ and ~user convention is widely spread, and I hardly imagine
> someone interpreting the sentence as "if you say ~foo, it will expand
> to the home directory of bar".
I didn't think it would expand ~foo to the home directory of bar. I
thought that it might _only_ accept ~bar, and not ~foo.
If I'm the only one confused, then we can drop it. But if not, I don't
think it is much more work to be precise.
-Peff
^ permalink raw reply
* Re: [PATCH] Expand ~ and ~user in core.excludesfile, commit.template
From: Matthieu Moy @ 2009-11-17 8:53 UTC (permalink / raw)
To: Jeff King; +Cc: git, Karl Chen
In-Reply-To: <20091117073426.GB4007@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Mon, Nov 16, 2009 at 11:07:40AM +0100, Matthieu Moy wrote:
>
>> + of files which are not meant to be tracked. "~" and "~user"
>> + are expanded to the user's home directory. See
>> linkgit:gitignore[5].
>
> Reading this, it is not clear to me if:
>
> 1. "~" and "~user" are expanded to the home directory of "user", where
> "user" is the user running git
>
> or
>
> 2. "~" is expanded to the home directory of the user running git, and
> an arbitrary "~user" is expanded to that user's home directory.
>
> I would expect (2), since that is how everything else works.
Yes. "user" in the sentence is either the user running Git or the same
string as "user" in "~user". I'm not against your proposal, but I'm
afraid we're making the sentence uselessly heavy, since, as you say,
this ~ and ~user convention is widely spread, and I hardly imagine
someone interpreting the sentence as "if you say ~foo, it will expand
to the home directory of bar".
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* [PATCH] Make sure $PERL_PATH is defined when the test suite is run.
From: Philippe Bruhat (BooK) @ 2009-11-17 8:42 UTC (permalink / raw)
To: git; +Cc: Philippe Bruhat (BooK)
In-Reply-To: <4B025F19.1050809@viscovery.net>
Some test scripts run Perl scripts as if they were git-* scripts, and
thus need to use the same perl that will be put in the shebang line of
git*.perl commands. $PERL_PATH therefore needs to be used instead of
a bare "perl".
The tests can fail if another perl is found in $PATH before the one
defined in $PERL_PATH.
Example test failure caused by this: the perl defined in $PERL_PATH has
Error.pm installed, and therefore the Git.pm's Makefile.PL doesn't install
the private copy. The perl from $PATH doesn't have Error.pm installed, and
all git*.perl scripts invoked during the test will fail loading Error.pm.
Makefile patch by Jeff King <peff@peff.net>.
Signed-off-by: Philippe Bruhat (BooK) <book@cpan.org>
---
Makefile | 1 +
t/t9400-git-cvsserver-server.sh | 2 +-
t/t9401-git-cvsserver-crlf.sh | 2 +-
t/t9700-perl-git.sh | 4 ++--
4 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/Makefile b/Makefile
index 35f5294..287c7fc 100644
--- a/Makefile
+++ b/Makefile
@@ -1633,6 +1633,7 @@ GIT-CFLAGS: .FORCE-GIT-CFLAGS
# and the first level quoting from the shell that runs "echo".
GIT-BUILD-OPTIONS: .FORCE-GIT-BUILD-OPTIONS
@echo SHELL_PATH=\''$(subst ','\'',$(SHELL_PATH_SQ))'\' >$@
+ @echo PERL_PATH=\''$(subst ','\'',$(PERL_PATH_SQ))'\' >>$@
@echo TAR=\''$(subst ','\'',$(subst ','\'',$(TAR)))'\' >>$@
@echo NO_CURL=\''$(subst ','\'',$(subst ','\'',$(NO_CURL)))'\' >>$@
@echo NO_PERL=\''$(subst ','\'',$(subst ','\'',$(NO_PERL)))'\' >>$@
diff --git a/t/t9400-git-cvsserver-server.sh b/t/t9400-git-cvsserver-server.sh
index 64f947d..c2ec3cb 100755
--- a/t/t9400-git-cvsserver-server.sh
+++ b/t/t9400-git-cvsserver-server.sh
@@ -20,7 +20,7 @@ then
say 'skipping git-cvsserver tests, cvs not found'
test_done
fi
-perl -e 'use DBI; use DBD::SQLite' >/dev/null 2>&1 || {
+"$PERL_PATH" -e 'use DBI; use DBD::SQLite' >/dev/null 2>&1 || {
say 'skipping git-cvsserver tests, Perl SQLite interface unavailable'
test_done
}
diff --git a/t/t9401-git-cvsserver-crlf.sh b/t/t9401-git-cvsserver-crlf.sh
index aca40c1..40637d6 100755
--- a/t/t9401-git-cvsserver-crlf.sh
+++ b/t/t9401-git-cvsserver-crlf.sh
@@ -57,7 +57,7 @@ then
say 'skipping git-cvsserver tests, perl not available'
test_done
fi
-perl -e 'use DBI; use DBD::SQLite' >/dev/null 2>&1 || {
+"$PERL_PATH" -e 'use DBI; use DBD::SQLite' >/dev/null 2>&1 || {
say 'skipping git-cvsserver tests, Perl SQLite interface unavailable'
test_done
}
diff --git a/t/t9700-perl-git.sh b/t/t9700-perl-git.sh
index 4eb7d3f..8686086 100755
--- a/t/t9700-perl-git.sh
+++ b/t/t9700-perl-git.sh
@@ -11,7 +11,7 @@ if ! test_have_prereq PERL; then
test_done
fi
-perl -MTest::More -e 0 2>/dev/null || {
+"$PERL_PATH" -MTest::More -e 0 2>/dev/null || {
say "Perl Test::More unavailable, skipping test"
test_done
}
@@ -48,6 +48,6 @@ test_expect_success \
test_external_without_stderr \
'Perl API' \
- perl "$TEST_DIRECTORY"/t9700/test.pl
+ "$PERL_PATH" "$TEST_DIRECTORY"/t9700/test.pl
test_done
--
1.6.0.3.517.g759a
^ permalink raw reply related
* Re: [PATCH] Make sure $PERL_PATH is defined when the test suite is run.
From: Philippe Bruhat (BooK) @ 2009-11-17 8:35 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <4B025F19.1050809@viscovery.net>
On Tue, Nov 17, 2009 at 09:30:17AM +0100, Johannes Sixt wrote:
> Philippe Bruhat (BooK) schrieb:
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -1633,6 +1633,7 @@ GIT-CFLAGS: .FORCE-GIT-CFLAGS
> > # and the first level quoting from the shell that runs "echo".
> > GIT-BUILD-OPTIONS: .FORCE-GIT-BUILD-OPTIONS
> > @echo SHELL_PATH=\''$(subst ','\'',$(SHELL_PATH_SQ))'\' >$@
> > + @echo PERL_PATH=\''$(subst ','\'',$(PERL_PATH_SQ))'\' >$@
>
> Make it: ... >>$@
This proves late commits needs many extra pair of eyes. :-)
> > @echo TAR=\''$(subst ','\'',$(subst ','\'',$(TAR)))'\' >>$@
> > @echo NO_CURL=\''$(subst ','\'',$(subst ','\'',$(NO_CURL)))'\' >>$@
> > @echo NO_PERL=\''$(subst ','\'',$(subst ','\'',$(NO_PERL)))'\' >>$@
>
> > test_external_without_stderr \
> > 'Perl API' \
> > - perl "$TEST_DIRECTORY"/t9700/test.pl
> > + $PERL_PATH "$TEST_DIRECTORY"/t9700/test.pl
>
> This one needs the double-quotes as well.
Thanks. Sending again. (sorry for the noise)
--
Philippe Bruhat (BooK)
"Did I err?" (Groo, in too many issues to count - ...and *YES* he did!)
^ permalink raw reply
* Re: [PATCH] Make sure $PERL_PATH is defined when the test suite is run.
From: Johannes Sixt @ 2009-11-17 8:30 UTC (permalink / raw)
To: Philippe Bruhat (BooK); +Cc: git
In-Reply-To: <1258417206-5406-1-git-send-email-book@cpan.org>
Philippe Bruhat (BooK) schrieb:
> --- a/Makefile
> +++ b/Makefile
> @@ -1633,6 +1633,7 @@ GIT-CFLAGS: .FORCE-GIT-CFLAGS
> # and the first level quoting from the shell that runs "echo".
> GIT-BUILD-OPTIONS: .FORCE-GIT-BUILD-OPTIONS
> @echo SHELL_PATH=\''$(subst ','\'',$(SHELL_PATH_SQ))'\' >$@
> + @echo PERL_PATH=\''$(subst ','\'',$(PERL_PATH_SQ))'\' >$@
Make it: ... >>$@
> @echo TAR=\''$(subst ','\'',$(subst ','\'',$(TAR)))'\' >>$@
> @echo NO_CURL=\''$(subst ','\'',$(subst ','\'',$(NO_CURL)))'\' >>$@
> @echo NO_PERL=\''$(subst ','\'',$(subst ','\'',$(NO_PERL)))'\' >>$@
> test_external_without_stderr \
> 'Perl API' \
> - perl "$TEST_DIRECTORY"/t9700/test.pl
> + $PERL_PATH "$TEST_DIRECTORY"/t9700/test.pl
This one needs the double-quotes as well.
-- Hannes
^ permalink raw reply
* Re: [PATCH] Expand ~ and ~user in core.excludesfile, commit.template
From: Mike Hommey @ 2009-11-17 7:49 UTC (permalink / raw)
To: Jeff King; +Cc: Matthieu Moy, git, Karl Chen
In-Reply-To: <20091117073426.GB4007@coredump.intra.peff.net>
On Tue, Nov 17, 2009 at 02:34:26AM -0500, Jeff King wrote:
> Maybe:
>
> A leading path component of "~user" is expanded to the home directory
> of "user"; "~" is expanded to the home directory of the user running
> git.
>
> would be more clear?
Add "real" before "user running git" and you have my vote. Or maybe
using the effective user would be better, and the patch should use
geteuid() instead of getuid(), I don't know. ident.c uses getuid(), but
I'm wondering if that's what it should use (although it doesn't seem to
have been a problem to anyone)
Mike
^ permalink raw reply
* Re: [PATCH] Doc: mention the crlf attribute in config autocrlf section
From: Matthew Ogilvie @ 2009-11-17 7:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, git
In-Reply-To: <7v7htpirmy.fsf@alter.siamese.dyndns.org>
On Mon, Nov 16, 2009 at 10:37:09PM -0800, Junio C Hamano wrote:
> How about this? I didn't touch the patch text (other than dropping
> trailing whitespaces).
>
> commit ff68668695486b72b5f06146eddf85b70841088a
> Author: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
> Date: Sat Nov 14 11:35:00 2009 -0700
>
> core.autocrlf documentation: mention the crlf attribute
>
> The description of the configuration variable is obsolete and
> wrong (saying only file content is used), not just incomplete.
> It has used the attribute mechanism for a long time.
>
> The documentation of gitattributes mentions the core.autocrlf
> configuration variable in its description of crlf attribute.
> Refer to the gitattributes documentation from here as well.
>
> Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Looks good. Sorry about the extra space in the patch text;
stripping it sounds good as well.
--
Matthew Ogilvie [mmogilvi_git@miniinfo.net]
^ permalink raw reply
* Re: [PATCH 1/2] replace: use a GIT_NO_REPLACE_OBJECTS env variable
From: Johannes Sixt @ 2009-11-17 7:42 UTC (permalink / raw)
To: Christian Couder
Cc: Junio C Hamano, git, Michael J Gruber, Jakub Narebski, bill lam,
Andreas Schwab, Paul Mackerras
In-Reply-To: <20091117051125.3588.91072.chriscool@tuxfamily.org>
Christian Couder schrieb:
> diff --git a/git.c b/git.c
> index bd2c5fe..7f7d73d 100644
> --- a/git.c
> +++ b/git.c
> @@ -89,6 +89,9 @@ static int handle_options(const char ***argv, int *argc, int *envchanged)
> *envchanged = 1;
> } else if (!strcmp(cmd, "--no-replace-objects")) {
> read_replace_refs = 0;
> + setenv(NO_REPLACE_OBJECTS_ENVIRONMENT, "", 1);
It is safer to set to a non-empty string, e.g., "1".
I think this variable should be added to the list in connect.c around line
630 so that it does not propagate to the remote end.
-- Hannes
^ permalink raw reply
* Re: [PATCH] Document git-svn's first-parent rule
From: Eric Wong @ 2009-11-17 7:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, git
In-Reply-To: <7vd43his6n.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Eric Wong <normalperson@yhbt.net> writes:
>
> > Thomas Rast <trast@student.ethz.ch> wrote:
> >> git-svn has the following rule to detect the SVN base for its
> >> operations: find the first git-svn-id line reachable through
> >> first-parent ancestry. IOW,
> >>
> >> git log --grep=^git-svn-id: --first-parent -1
> >>
> >> Document this, as it is very important when using merges with git-svn.
> >>
> >> Signed-off-by: Thomas Rast <trast@student.ethz.ch>
> >
> > Thanks Thomas,
> >
> > Acked-by: Eric Wong <normalperson@yhbt.net>
>
> Thanks; is it a good time to pull from your bogomips repository to get
> accumulated changes?
Now is, I just pushed to it:
Eric Wong (3):
git svn: read global+system config for clone+init
git svn: add authorsfile test case for ~/.gitconfig
git svn: attempt to create empty dirs on clone+rebase
Thomas Rast (1):
Document git-svn's first-parent rule
Toby Allsopp (1):
git svn: handle SVN merges from revisions past the tip of the branch
HEAD=ce45a45f24cc7b3ccc7f6ebcd0025559b4421bda
--
Eric Wong
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox