* 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
* 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] 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
* 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: 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
* [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: [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
* 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: 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] 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: [PATCH] Document git-svn's first-parent rule
From: Junio C Hamano @ 2009-11-17 18:25 UTC (permalink / raw)
To: Eric Wong; +Cc: Junio C Hamano, Thomas Rast, git
In-Reply-To: <20091117074208.GA337@dcvr.yhbt.net>
Eric Wong <normalperson@yhbt.net> writes:
>> 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
Thanks, pulled.
^ permalink raw reply
* Re: [PATCH v2 0/2] user-manual: new "getting started" section
From: Junio C Hamano @ 2009-11-17 18:25 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Nanako Shiraishi, Felipe Contreras, Michael J Gruber,
Jonathan Nieder, Junio C Hamano, git, Hannu Koivisto, Jeff King,
Wincent Colaiuta, Matthias Lederhofer
In-Reply-To: <20091117172815.GH31767@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> writes:
> 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
True. A ref can even point to a blob.
I think "diff" always takes two (pseudo-)tree-ish in David's world, and
you should be able to use these magic topens anywhere that expects a
tree-ish. For example:
$ git checkout STAGE Makefile
would be a way to say "please check out the version of Makefile in the
staging area". And
$ git archive WORKTREE
$ git archive STAGE
would be a version of tar that is index-aware.
But we do not have to support commit-ish operations, such as "git log".
It is a different story if these pseudo-refs that denote tree-ish are
useful outside the context of "diff". I do not think of many commands
that take arbitrary tree-ish other than the ones I mentioned above. Even
though they take arbitrary tree-ish, people almost always use commit-ish
with them.
Which points to another issue with the approach.
The original intention of these magic tokens are to make things easier,
but they actually may make things _harder_ to teach, because you have to
explain why "git log WORKTREE" does not work but "git archive WORKTREE"
does. Admittedly, you already have to explain your example to people
saying "it does not work because v2.6.11 is a tree and a tree by itself
does not have a point in history", but the thing is, v2.6.11-tree and
v2.6.11 are oddballs, and you do not have to give that explanation very
often, simply because the users are not exposed to a raw tree.
But WORKTREE and STAGE tokens are _meant_ to be exposed to them much more
prominently. That's the whole point of the "git diff STAGE WORKTREE"
proposal.
People would become aware that they are very different from ordinary
commits, and then eventually they will realize that they are not even
trees [*1*].
At that point, I suspect that these magic tokens become larger UI warts
themselves; they behave differently from everything else that is spelled
in all caps (e.g. HEAD, ORIG_HEAD, MERGE_HEAD).
As to --tree-vs-index counterproposal (was it a counterproposal?), except
for that I think they are too long to type in practice and need to be
shortened to be useful, I do not have a fundamental objection against it.
[Footnote]
*1* For example, I would not expect that we will make "git show WORKTREE"
to build a tree on the fly by running "git add -A && git write-tree" with
a temporary index and then running "git show" on the resulting tree
object, because there would be a better response than that if a user asks
"please show my worktree".
^ permalink raw reply
* Re: Make Gitweb behave like Apache mod_userdir
From: Sylvain Rabot @ 2009-11-17 19:56 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, Petr Baudis, Luben Tuikov, J.H., git
In-Reply-To: <200911171912.40658.jnareb@gmail.com>
On Tue, Nov 17, 2009 at 19:12, Jakub Narebski <jnareb@gmail.com> wrote:
> 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?
>
That's right.
>> > How it would look like in gitweb?
>>
>> What do you mean ?
>
> How would example gitweb URL to repository look like?
http://repo.or.cz/ -> list the main GITWEB_PROJECTROOT (e.g.: /pub/scm)
http://repo.or.cz/~user -> list /home/user/gitweb
http://repo.or.cz/~user2 -> list /home/user2/gitweb
...
>
> --
> Jakub Narebski
> Poland
>
^ permalink raw reply
* Re: Make Gitweb behave like Apache mod_userdir
From: Junio C Hamano @ 2009-11-17 20:15 UTC (permalink / raw)
To: Sylvain Rabot; +Cc: git, Jakub Narebski
In-Reply-To: <7fce93be0911150204h259b7424md251c54186d05b7d@mail.gmail.com>
Sylvain Rabot <sylvain@abstraction.fr> writes:
> +If you want gitweb to act a bit like UserDir mod in apache, knowing, http://<host>/~<user>
> +will list all git repos of <user> located in a special directory in his home (/home/<user>/gitweb/),
> +do the following steps :
> +
> +Add this to the VirtualHost section of your apache configuration file :
> +
> + RewriteRule ^/~([^\/]+)/?$ /cgi-bin/gitweb.cgi [QSA,E=GITWEB_PROJECTROOT:/home/$1/gitweb/,L,PT]
> +
> +Modify your gitweb.conf file, located at /etc/gitweb.conf in this example, with :
> +
> + $projectroot = $ENV{'GITWEB_PROJECTROOT'} || "/path/to/the/defaul/project/root";
> +
> +Thus, each user with a gitweb folder in his home will be able to browse it with gitweb.
> +/!\ The gitweb folder and user's home folder must be readable by the webserver user.
Wouldn't it be a good idea to somehow make this work well together with
the --user-path feature of git-daemon?
Perhaps the recommended name given in the example shouldn't be ~/gitweb,
but more like ~/public_git, as this is like ~/public_html but for git
repositories. Then the end users will browse
http://my.site/~gitster/public_git/git.git
and gitweb can be told to show
clone URL: git://my.site/~gitster/public_git/git.git
on the page. If the site administrator runs git-daemon with --user-path
set to public_git, everything will work seamlessly, no?
^ permalink raw reply
* Re: Make Gitweb behave like Apache mod_userdir
From: Sylvain Rabot @ 2009-11-17 20:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jakub Narebski
In-Reply-To: <7vhbssewm7.fsf@alter.siamese.dyndns.org>
On Tue, Nov 17, 2009 at 21:15, Junio C Hamano <gitster@pobox.com> wrote:
> Sylvain Rabot <sylvain@abstraction.fr> writes:
>
>> +If you want gitweb to act a bit like UserDir mod in apache, knowing, http://<host>/~<user>
>> +will list all git repos of <user> located in a special directory in his home (/home/<user>/gitweb/),
>> +do the following steps :
>> +
>> +Add this to the VirtualHost section of your apache configuration file :
>> +
>> + RewriteRule ^/~([^\/]+)/?$ /cgi-bin/gitweb.cgi [QSA,E=GITWEB_PROJECTROOT:/home/$1/gitweb/,L,PT]
>> +
>> +Modify your gitweb.conf file, located at /etc/gitweb.conf in this example, with :
>> +
>> + $projectroot = $ENV{'GITWEB_PROJECTROOT'} || "/path/to/the/defaul/project/root";
>> +
>> +Thus, each user with a gitweb folder in his home will be able to browse it with gitweb.
>> +/!\ The gitweb folder and user's home folder must be readable by the webserver user.
>
> Wouldn't it be a good idea to somehow make this work well together with
> the --user-path feature of git-daemon?
>
> Perhaps the recommended name given in the example shouldn't be ~/gitweb,
> but more like ~/public_git, as this is like ~/public_html but for git
> repositories. Then the end users will browse
As I said, it's configuration :)
>
> http://my.site/~gitster/public_git/git.git
>
would be http://my.site/~gitster/git.git
> and gitweb can be told to show
>
> clone URL: git://my.site/~gitster/public_git/git.git
and git://my.site/~gitster/git.git
if --user-path of git daemon set to public_git
> on the page. If the site administrator runs git-daemon with --user-path
> set to public_git, everything will work seamlessly, no?
>
Yes :)
^ permalink raw reply
* Re: [PATCH] Expand ~ and ~user in core.excludesfile, commit.template
From: Andreas Schwab @ 2009-11-17 21:20 UTC (permalink / raw)
To: Mike Hommey; +Cc: Jeff King, Matthieu Moy, git, Karl Chen
In-Reply-To: <20091117074930.GB11636@glandium.org>
Mike Hommey <mh@glandium.org> writes:
> 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)
"~" should just expand to the value of $HOME, like in the shell,
independent of the real home directory of the real or effective user.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH v2 0/2] user-manual: new "getting started" section
From: Felipe Contreras @ 2009-11-17 22:00 UTC (permalink / raw)
To: Junio C Hamano
Cc: J. Bruce Fields, Nanako Shiraishi, Michael J Gruber,
Jonathan Nieder, git, Hannu Koivisto, Jeff King, Wincent Colaiuta,
Matthias Lederhofer
In-Reply-To: <7vocn1dn5d.fsf@alter.siamese.dyndns.org>
On Tue, Nov 17, 2009 at 8:25 PM, Junio C Hamano <gitster@pobox.com> wrote:
> But we do not have to support commit-ish operations, such as "git log".
Right, and actuallly don't have to support WORKTREE/STAGE on all the
commands that work with the stage. For example I think 'git apply'
behaves completely different than 'git diff', since you cannot apply a
patch on top of a commit, therefore it doesn't make sense to stage
stuff as pseudo-refs; it makes sense to keep the --foo options
(although I would prefer something like --stage and --stage-only).
> It is a different story if these pseudo-refs that denote tree-ish are
> useful outside the context of "diff". I do not think of many commands
> that take arbitrary tree-ish other than the ones I mentioned above. Even
> though they take arbitrary tree-ish, people almost always use commit-ish
> with them.
>
> Which points to another issue with the approach.
>
> The original intention of these magic tokens are to make things easier,
> but they actually may make things _harder_ to teach, because you have to
> explain why "git log WORKTREE" does not work but "git archive WORKTREE"
> does. Admittedly, you already have to explain your example to people
> saying "it does not work because v2.6.11 is a tree and a tree by itself
> does not have a point in history", but the thing is, v2.6.11-tree and
> v2.6.11 are oddballs, and you do not have to give that explanation very
> often, simply because the users are not exposed to a raw tree.
>
> But WORKTREE and STAGE tokens are _meant_ to be exposed to them much more
> prominently. That's the whole point of the "git diff STAGE WORKTREE"
> proposal.
>
> People would become aware that they are very different from ordinary
> commits, and then eventually they will realize that they are not even
> trees [*1*].
>
> At that point, I suspect that these magic tokens become larger UI warts
> themselves; they behave differently from everything else that is spelled
> in all caps (e.g. HEAD, ORIG_HEAD, MERGE_HEAD).
That could be easily fixed by making explicit in the syntax that these
are not typical refs: i.e. @stage and @work.
--
Felipe Contreras
^ permalink raw reply
* Re: Make Gitweb behave like Apache mod_userdir
From: Junio C Hamano @ 2009-11-17 22:10 UTC (permalink / raw)
To: Sylvain Rabot; +Cc: git, Jakub Narebski
In-Reply-To: <7fce93be0911171224r1cfc438ay7b38b81646154a23@mail.gmail.com>
Sylvain Rabot <sylvain@abstraction.fr> writes:
>> Wouldn't it be a good idea to somehow make this work well together with
>> the --user-path feature of git-daemon?
>>
>> Perhaps the recommended name given in the example shouldn't be ~/gitweb,
>> but more like ~/public_git, as this is like ~/public_html but for git
>> repositories. Then the end users will browse
>
> As I said, it's configuration :)
Wrong answer.
Exactly because it is configurable, the document that outlines the
recommended practice should suggest the best convention. My point was
that it is likely to be tied to "git"-ness of the specified directory
under $HOME/, not limited to "gitweb"-ness, and it is wrong to recommend a
name tied to "gitweb"-ness in this document.
^ permalink raw reply
* Re: [PATCH] Expand ~ and ~user in core.excludesfile, commit.template
From: Junio C Hamano @ 2009-11-17 22:16 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Mike Hommey, Jeff King, Matthieu Moy, git, Karl Chen
In-Reply-To: <m2lji43l20.fsf@igel.home>
Andreas Schwab <schwab@linux-m68k.org> writes:
> Mike Hommey <mh@glandium.org> writes:
>
>> 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)
>
> "~" should just expand to the value of $HOME, like in the shell,
> independent of the real home directory of the real or effective user.
How should this interact with installations that run gitosis/gitlite that
use shared account, giving user identity via the ssh key?
Note that the question is not "how would this...", but "how _should_
this...".
^ permalink raw reply
* Re: [PATCH v2 0/2] user-manual: new "getting started" section
From: Junio C Hamano @ 2009-11-17 22:19 UTC (permalink / raw)
To: Felipe Contreras
Cc: Junio C Hamano, J. Bruce Fields, Nanako Shiraishi,
Michael J Gruber, Jonathan Nieder, git, Hannu Koivisto, Jeff King,
Wincent Colaiuta, Matthias Lederhofer
In-Reply-To: <94a0d4530911171400ub3b093ai668fd2404b12272f@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> That could be easily fixed by making explicit in the syntax that these
> are not typical refs: i.e. @stage and @work.
The message I get from that suggestion is that the most sensible approach,
if we are going to add something from this discussion to "git diff", is to
do what you did _not_ quote from my message, which is:
As to --tree-vs-index counterproposal (was it a counterproposal?),
except for that I think they are too long to type in practice and need
to be shortened to be useful, I do not have a fundamental objection
against it.
IOW, this is about options, and should not be done as syntax sugar that
does a half-baked job of pretending to be refs.
^ permalink raw reply
* Re: Make Gitweb behave like Apache mod_userdir
From: Sylvain Rabot @ 2009-11-17 22:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jakub Narebski
In-Reply-To: <7vd43gerak.fsf@alter.siamese.dyndns.org>
On Tue, Nov 17, 2009 at 23:10, Junio C Hamano <gitster@pobox.com> wrote:
> Sylvain Rabot <sylvain@abstraction.fr> writes:
>
>>> Wouldn't it be a good idea to somehow make this work well together with
>>> the --user-path feature of git-daemon?
>>>
>>> Perhaps the recommended name given in the example shouldn't be ~/gitweb,
>>> but more like ~/public_git, as this is like ~/public_html but for git
>>> repositories. Then the end users will browse
>>
>> As I said, it's configuration :)
>
> Wrong answer.
>
Am I passing a test ?
> Exactly because it is configurable, the document that outlines the
> recommended practice should suggest the best convention. My point was
> that it is likely to be tied to "git"-ness of the specified directory
> under $HOME/, not limited to "gitweb"-ness, and it is wrong to recommend a
> name tied to "gitweb"-ness in this document.
Again, git is a brand new world for me and I don't know any of his
conventions yet.
I am not trying to impose my own conventions, I am just proposing an idea.
If you like it and want to make it more "git world compliant", please do so.
^ permalink raw reply
* Re: Make Gitweb behave like Apache mod_userdir
From: J.H. @ 2009-11-17 22:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sylvain Rabot, git, Jakub Narebski
In-Reply-To: <7vd43gerak.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Sylvain Rabot <sylvain@abstraction.fr> writes:
>
>>> Wouldn't it be a good idea to somehow make this work well together with
>>> the --user-path feature of git-daemon?
>>>
>>> Perhaps the recommended name given in the example shouldn't be ~/gitweb,
>>> but more like ~/public_git, as this is like ~/public_html but for git
>>> repositories. Then the end users will browse
>> As I said, it's configuration :)
>
> Wrong answer.
>
> Exactly because it is configurable, the document that outlines the
> recommended practice should suggest the best convention. My point was
> that it is likely to be tied to "git"-ness of the specified directory
> under $HOME/, not limited to "gitweb"-ness, and it is wrong to recommend a
> name tied to "gitweb"-ness in this document.
For starters I think overriding the /~<user> (specifically the ~ here)
is going to be a bad idea no matter what you do and gives the wrong
impression about what / how the request is being responded to. You
might want to try and pick a different delimiter or re-work the rule so
that you could have something like:
http://git.kernel.org/<gitweb urls>
http://git.kernel.org/user/<gitweb urls>
Your also, likely, going to need to take into account things like
index.cgi and gitweb.cgi in the url as things like:
http://git.kernel.org/?p=bluetooth/bluez-gnome.git;a=summary
http://git.kernel.org/gitweb.cgi?p=bluetooth/bluez-gnome.git;a=summary
are likely to be correct for almost all installations.
I would agree with Junio on this, if your suggesting a possible practice
you should focus on the best convention. Making it depend on something
like ~/gitweb doesn't make it clear or obvious enough to a user, or an
administrator, that the directory is being exported for the world to
see. There is a reason it's called ~/public_html.
Keep in mind most people are going to read the documentation and
copy/paste what they need and not change anything.
- John 'Warthog9' Hawley
^ permalink raw reply
* Re: [PATCH v2 0/2] user-manual: new "getting started" section
From: Felipe Contreras @ 2009-11-17 23:06 UTC (permalink / raw)
To: Junio C Hamano
Cc: J. Bruce Fields, Nanako Shiraishi, Michael J Gruber,
Jonathan Nieder, git, Hannu Koivisto, Jeff King, Wincent Colaiuta,
Matthias Lederhofer
In-Reply-To: <7v4ooseqvb.fsf@alter.siamese.dyndns.org>
On Wed, Nov 18, 2009 at 12:19 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> That could be easily fixed by making explicit in the syntax that these
>> are not typical refs: i.e. @stage and @work.
>
> The message I get from that suggestion is that the most sensible approach,
> if we are going to add something from this discussion to "git diff", is to
> do what you did _not_ quote from my message, which is:
>
> As to --tree-vs-index counterproposal (was it a counterproposal?),
> except for that I think they are too long to type in practice and need
> to be shortened to be useful, I do not have a fundamental objection
> against it.
>
> IOW, this is about options, and should not be done as syntax sugar that
> does a half-baked job of pretending to be refs.
Sorry, I thought your only objection to STAGE and WORKTREE was that
they were not clearly differentiated, and my proposal gets rid of that
issue. Now I fail to see what's the problem since you didn't explain
what's wrong with adding syntactic sugar.
If the goal of the change is to make things more user-friendly, then
I'd say "git diff HEAD @stage" is better than "git diff
--tree-vs-staged HEAD".
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH v2 0/2] user-manual: new "getting started" section
From: Junio C Hamano @ 2009-11-17 23:13 UTC (permalink / raw)
To: Felipe Contreras
Cc: Junio C Hamano, J. Bruce Fields, Nanako Shiraishi,
Michael J Gruber, Jonathan Nieder, git, Hannu Koivisto, Jeff King,
Wincent Colaiuta, Matthias Lederhofer
In-Reply-To: <94a0d4530911171506o2b08954bw4acba8ea9193e65d@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> If the goal of the change is to make things more user-friendly, then
> I'd say "git diff HEAD @stage" is better than "git diff
> --tree-vs-staged HEAD".
Exactly. That is where we disagree. The funny "@stage" does not convey
the fact that it is affecting how "git diff" operates, like any other
option like "-R" does in "git diff -R" command line does. Now the user
needs to know git commands take -option like other normal tools do, but in
addition they need to remember that an oddball "diff" subcommand takes
"@funny" in addition to the usual "-option".
How would that be an improvement?
^ permalink raw reply
* Re: Make Gitweb behave like Apache mod_userdir
From: Junio C Hamano @ 2009-11-17 23:40 UTC (permalink / raw)
To: Sylvain Rabot; +Cc: J.H., git, Jakub Narebski
In-Reply-To: <7fce93be0911171454i61e995a1ob0bf80013bcb0727@mail.gmail.com>
Sylvain Rabot <sylvain@abstraction.fr> writes:
> On Tue, Nov 17, 2009 at 23:10, Junio C Hamano <gitster@pobox.com> wrote:
>> Sylvain Rabot <sylvain@abstraction.fr> writes:
>>
>>>> Wouldn't it be a good idea to somehow make this work well together with
>>>> the --user-path feature of git-daemon?
>>>>
>>>> Perhaps the recommended name given in the example shouldn't be ~/gitweb,
>>>> but more like ~/public_git, as this is like ~/public_html but for git
>>>> repositories. Then the end users will browse
>>>
>>> As I said, it's configuration :)
>>
>> Wrong answer.
>
> Am I passing a test ?
Sorry, but that wasn't what I meant.
>> Exactly because it is configurable, the document that outlines the
>> recommended practice should suggest the best convention. My point was
>> that it is likely to be tied to "git"-ness of the specified directory
>> under $HOME/, not limited to "gitweb"-ness, and it is wrong to recommend a
>> name tied to "gitweb"-ness in this document.
>
> Again, git is a brand new world for me and I don't know any of his
> conventions yet.
I do not see this as git-specific conventions.
But suggesting ~/gitweb is perfectly excusable, especially if you did not
know that git-daemon can respond to "git://host/~user/".
John warthog19 (hmm, I thought he used to be warthog9) explained the above
much better than I did. People tend to cut and paste without thinking, so
we should describe a good default layout in our documentation.
> I am not trying to impose my own conventions, I am just proposing an idea.
Yeah, I know. We are all in this to improve things for people who follow
us.
^ 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