* Re: [PATCH 1/2] gitk: Import msgcat for translation support
From: Paul Mackerras @ 2007-07-27 23:53 UTC (permalink / raw)
To: Christian Stimming; +Cc: git
In-Reply-To: <20070727165318.e96b1yxxwsooo884@webmail.tu-harburg.de>
Christian Stimming writes:
> Import tcl's msgcat package to have the [mc...] procedure for
> translation available.
I would prefer
if {[catch {
package require msgcat
# rest of your new stuff
}]} {
proc mc {str} {
return $str
}
}
so that everything still works if msgcat isn't available. In other
words I don't want to introduce a possible regression by increasing
gitk's requirements.
Paul.
^ permalink raw reply
* Re: [PATCH 2/8] Add functions get_relative_cwd() and is_inside_dir()
From: Johannes Schindelin @ 2007-07-28 1:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, matled
In-Reply-To: <7vps2dy3hb.fsf@assigned-by-dhcp.cox.net>
Hi,
On Fri, 27 Jul 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > +char *get_relative_cwd(char *buffer, int size, const char *dir)
> > +{
> > + char *cwd = buffer;
> > +
> > + if (!dir)
> > + return 0;
> > +
> > + if (!getcwd(buffer, PATH_MAX))
> > + return 0;
>
> Can size be less than PATH_MAX?
Thanks. Will fix.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 1/8] Add is_absolute_path() and make_absolute_path()
From: Johannes Schindelin @ 2007-07-28 1:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, matled
In-Reply-To: <7vvec5y3i0.fsf@assigned-by-dhcp.cox.net>
Hi,
On Fri, 27 Jul 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > diff --git a/path.c b/path.c
> > index c4ce962..0f7012f 100644
> > --- a/path.c
> > +++ b/path.c
> > @@ -292,3 +292,65 @@ int adjust_shared_perm(const char *path)
> > return -2;
> > return 0;
> > }
> > +
> > +/* We allow "recursive" symbolic links. Only within reason, though. */
> > +#define MAXDEPTH 5
> > +
> > +const char *make_absolute_path(const char *path)
> > +{
> > + static char bufs[2][PATH_MAX + 1], *buf = bufs[0], *next_buf = bufs[1];
> > + char cwd[1024] = "";
> > + int buf_index = 1, len;
> > +
> > + int depth = MAXDEPTH;
> > + char *last_elem = NULL;
> > + struct stat st;
> > +
> > + if (strlcpy(buf, path, PATH_MAX) >= PATH_MAX)
> > + die ("Too long path: %.*s", 60, path);
> > +
> > + while (depth--) {
> > + if (stat(buf, &st) || !S_ISDIR(st.st_mode)) {
> > + char *last_slash = strrchr(buf, '/');
> > + *last_slash = '\0';
> > + last_elem = xstrdup(last_slash + 1);
>
> What happens when incoming path is just "abc"? Does your test
> script checks that case?
No, and you already guessed it: there will be a segmentation fault.
Will fix.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 5/8] work-trees are allowed inside a git-dir
From: Johannes Schindelin @ 2007-07-28 1:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, matled
In-Reply-To: <7vabthwdyg.fsf@assigned-by-dhcp.cox.net>
Hi,
On Fri, 27 Jul 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >>
> >> > It is allowed to call
> >> >
> >> > $ git --git-dir=../ --work-tree=. bla
> >> >
> >> > when you really want to. In this case, you are both in the git directory
> >> > and in the working tree.
> > ...
> > There are files in that directory (and all of its subdirectories) of a
> > certain type, which are the only ones which are human generated, and
> > therefore precious. I like to add them, and inspect them, with
> >
> > git --git-dir=$HOME/x.git add
> >
> > and
> >
> > git --git-dir=$HOME/x.git diff
>
> I understand the --git-dir=$HOME/x.git to keep track of
> something in $HOME/foo/bar example.
>
> But that is not the issue you described in the original message.
> I was asking about this (which is the way I read your original
> message):
>
> $ GIT_DIR=$HOME/x.git git init
> $ mkdir $HOME/x.git/workroot
> $ cd $HOME/x.git/workroot
> $ git --git-dir=../ --work-tree=.
>
> That is, $HOME/x.git/ is the GIT_DIR that has HEAD, index and
> refs/, and you are keeping track of contents whose rootlevel is
> at $HOME/x.git/workroot
Ah! But I have a really nice use case for that, too. I track a
.git/refs/exclude in one of my branches, because I do not want anybody
else to have those excludes. They only apply to me.
Another example would be a temporary checkout+change+checkin to some
branch that is not currently checked out in the default working tree. (I
do that, too, and had to work around that by cloning with "-l -n -s")
What I do there is to keep a checkout of some often-rsync'ed (actually
wget'ed) state in the current working tree, automatically committing when
upstream changes, and tracking upstream _releases_ in a different branch.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 3/8] Clean up work-tree handling
From: Johannes Schindelin @ 2007-07-28 0:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, matled
In-Reply-To: <7vejitwe8m.fsf@assigned-by-dhcp.cox.net>
Hi,
On Fri, 27 Jul 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> This changes semantics, I think.
> >>
> >> It used to be relative "up" path when no funny work-tree stuff
> >> is used, but get_git_work_tree() now seems to return absolute,
> >> hence this option as well. If it introduces regression to
> >> existing callers is up to what the caller does to the resulting
> >> path, though. If it only is used to prefix other things
> >> (i.e. path="$(git rev-parse --show-cdup)$1"), the caller would
> >> be safe, but if the caller counted number of ../ in the return
> >> value to see how deep it is, or if the caller expected to see
> >> empty string in order to see if the process is at the toplevel,
> >> this change would become a regression.
> >
> > I am somewhat negative on keeping _that_ much backwards compatibility.
> > Scripts which depend on show-cdup being a relative path _will_ be broken
> > by work-tree. Is it worth it to detect those errors late?
>
> Well, one of the conditions to accept the worktree stuff was not
> to break anybody who never ever uses worktree. So if we can
> keep the UP-ness of cdup, it would be much better.
One could record if the work tree was changed from the default one, and
do the old thing in that case.
But I really have to wonder what other use people concocted for
"--show-cdup"? Potentially some directory-counting? But --show-prefix
would be much better at that.
I'll try to flange something into the code to detect unchanged working
tree, but that is rather ugly, so I'd prefer not to.
Ciao,
Dscho
^ permalink raw reply
* Re: git diff with add/modified codes
From: Jon Smirl @ 2007-07-28 0:54 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0707280148340.14781@racer.site>
On 7/27/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Fri, 27 Jul 2007, Junio C Hamano wrote:
>
> > Would --stat --summary be satisfactory?
>
> Or does "--raw" do the job?
Raw is much closer. Combine the file stats from --raw with --stat and
it would be perfect.
>
> Ciao,
> Dscho
>
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: git diff with add/modified codes
From: Johannes Schindelin @ 2007-07-28 0:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jon Smirl, Git Mailing List
In-Reply-To: <7vir85whxy.fsf@assigned-by-dhcp.cox.net>
Hi,
On Fri, 27 Jul 2007, Junio C Hamano wrote:
> Would --stat --summary be satisfactory?
Or does "--raw" do the job?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 5/8] work-trees are allowed inside a git-dir
From: Junio C Hamano @ 2007-07-28 0:48 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, matled
In-Reply-To: <Pine.LNX.4.64.0707280122160.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>
>> > It is allowed to call
>> >
>> > $ git --git-dir=../ --work-tree=. bla
>> >
>> > when you really want to. In this case, you are both in the git directory
>> > and in the working tree.
> ...
> There are files in that directory (and all of its subdirectories) of a
> certain type, which are the only ones which are human generated, and
> therefore precious. I like to add them, and inspect them, with
>
> git --git-dir=$HOME/x.git add
>
> and
>
> git --git-dir=$HOME/x.git diff
I understand the --git-dir=$HOME/x.git to keep track of
something in $HOME/foo/bar example.
But that is not the issue you described in the original message.
I was asking about this (which is the way I read your original
message):
$ GIT_DIR=$HOME/x.git git init
$ mkdir $HOME/x.git/workroot
$ cd $HOME/x.git/workroot
$ git --git-dir=../ --work-tree=.
That is, $HOME/x.git/ is the GIT_DIR that has HEAD, index and
refs/, and you are keeping track of contents whose rootlevel is
at $HOME/x.git/workroot
^ permalink raw reply
* Re: [PATCH 8/8] Fix t1500 for sane work-tree behavior
From: Johannes Schindelin @ 2007-07-28 0:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, matled
In-Reply-To: <7v8x91y3h7.fsf@assigned-by-dhcp.cox.net>
Hi,
On Fri, 27 Jul 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > When GIT_DIR=../.git, and no worktree is specified, it is reasonable
> > to assume that the repository is not bare, that the work tree is ".."
> > and that the prefix is the basename of the current directory.
> >
> > This is the sane behavior.
>
> That is a bit too strong blanket statement, while being weak on
> exact conditions, giving only one example.
Okay, let me defend it.
> It makes me wonder...
>
> * When GIT_DIR=../../.git, and no worktree is specified, the
> same holds true, with worktree is "../.."? (probably yes)
You meant with "GIT_DIR=../.."? No. In that case, I'd assume a bare
repository, and we're inside the git directory, and unless the user
specified a working tree, assume that we have none.
> * "GIT_DIR=../../foo/.git"? (I dunno)
Unless ../../foo == .. no. When we're outside, we're outside.
> * "GIT_DIR=../foo.git"? (probably not)
Unless "$(basename "$(pwd)")" == foo.git, no.
> I am assuming that you meant something like this:
>
> When no worktree is specified, and GIT_DIR (or --git-dir=) is
> zero or more "../" followed by ".git" after stripping trailing
> and/or redundant slashes, it is reasonable to assume that the
> repository is not bare, and the work tree is the parent
> directory of the GIT_DIR directory.
>
> but that requires guesswork if you give only one example and let
> the readers to guess.
Your explanation is really much more coherent than mine. Please replace
mine.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 3/8] Clean up work-tree handling
From: Junio C Hamano @ 2007-07-28 0:42 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, matled
In-Reply-To: <Pine.LNX.4.64.0707280115370.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> This changes semantics, I think.
>>
>> It used to be relative "up" path when no funny work-tree stuff
>> is used, but get_git_work_tree() now seems to return absolute,
>> hence this option as well. If it introduces regression to
>> existing callers is up to what the caller does to the resulting
>> path, though. If it only is used to prefix other things
>> (i.e. path="$(git rev-parse --show-cdup)$1"), the caller would
>> be safe, but if the caller counted number of ../ in the return
>> value to see how deep it is, or if the caller expected to see
>> empty string in order to see if the process is at the toplevel,
>> this change would become a regression.
>
> I am somewhat negative on keeping _that_ much backwards compatibility.
> Scripts which depend on show-cdup being a relative path _will_ be broken
> by work-tree. Is it worth it to detect those errors late?
Well, one of the conditions to accept the worktree stuff was not
to break anybody who never ever uses worktree. So if we can
keep the UP-ness of cdup, it would be much better.
^ permalink raw reply
* Re: [PATCH 5/8] work-trees are allowed inside a git-dir
From: Johannes Schindelin @ 2007-07-28 0:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, matled
In-Reply-To: <7vejity3h8.fsf@assigned-by-dhcp.cox.net>
Hi,
On Fri, 27 Jul 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > It is allowed to call
> >
> > $ git --git-dir=../ --work-tree=. bla
> >
> > when you really want to. In this case, you are both in the git directory
> > and in the working tree.
> >
> > The earlier handling of this situation was seriously bogus. For regular
> > working tree operations, it checked if inside git dir. That makes no
> > sense, of course, since the check should be for a work tree, and nothing
> > else.
> >
> > Fix that.
>
> I do not doubt this patch makes the above command line to work
> better, but I have to wonder how that layout is useful. Care to
> give a use case or two in the commit log message?
In the commit log message? Better somewhere else. Only git developers
read the commit message.
But yes, I can point to a use case. AFAIR Martin Krafft brought up the
issue to track different components of the home directory in different
repositories.
I have a similar scenario here, which does not involve a home directory,
but rather a directory where I should not put anything into (I could, but
if the admin was anything akin to competent, I could not).
There are files in that directory (and all of its subdirectories) of a
certain type, which are the only ones which are human generated, and
therefore precious. I like to add them, and inspect them, with
git --git-dir=$HOME/x.git add
and
git --git-dir=$HOME/x.git diff
Another similar scenario is a network drive on Losedows, where the locking
always fails. So I do not _want_ a repo there, even if I _could_.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 3/8] Clean up work-tree handling
From: Johannes Schindelin @ 2007-07-28 0:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, matled
In-Reply-To: <7vk5sly3h9.fsf@assigned-by-dhcp.cox.net>
Hi,
On Fri, 27 Jul 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Not only because of ohloh am I proud that in spite of removing
> > more lines than I added, there were more comments added than
> > removed...
>
> > diff --git a/builtin-rev-parse.c b/builtin-rev-parse.c
> > index 497903a..3f787a8 100644
> > --- a/builtin-rev-parse.c
> > +++ b/builtin-rev-parse.c
> > @@ -320,15 +320,9 @@ int cmd_rev_parse(int argc, const char **argv, const char *prefix)
> > continue;
> > }
> > if (!strcmp(arg, "--show-cdup")) {
> > - const char *pfx = prefix;
> > - while (pfx) {
> > - pfx = strchr(pfx, '/');
> > - if (pfx) {
> > - pfx++;
> > - printf("../");
> > - }
> > - }
> > - putchar('\n');
> > + const char *work_tree = get_git_work_tree();
> > + if (work_tree)
> > + printf("%s\n", work_tree);
> > continue;
>
> This changes semantics, I think.
>
> It used to be relative "up" path when no funny work-tree stuff
> is used, but get_git_work_tree() now seems to return absolute,
> hence this option as well. If it introduces regression to
> existing callers is up to what the caller does to the resulting
> path, though. If it only is used to prefix other things
> (i.e. path="$(git rev-parse --show-cdup)$1"), the caller would
> be safe, but if the caller counted number of ../ in the return
> value to see how deep it is, or if the caller expected to see
> empty string in order to see if the process is at the toplevel,
> this change would become a regression.
I am somewhat negative on keeping _that_ much backwards compatibility.
Scripts which depend on show-cdup being a relative path _will_ be broken
by work-tree. Is it worth it to detect those errors late?
> > @@ -62,15 +66,8 @@ static void setup_git_env(void)
> >
> > int is_bare_repository(void)
> > {
> > + /* if core.bare is not 'false', let's see if there is a work tree */
> > + return is_bare_repository_cfg && !get_git_work_tree();
> > }
>
> I thought about making core.bare a tertiary, true/false/depends,
> but I think this makes more sense.
Actually, you made me think again, and I am more along those lines now:
return is_bare_repository_cfg >= 0 ?
is_bare_repository_cfg : !get_git_work_tree();
and according patch to get_git_work_tree to return NULL if
is_bare_repository_cfg == 1.
Ciao,
Dscho
^ permalink raw reply
* Re: git diff with add/modified codes
From: Jon Smirl @ 2007-07-28 0:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vir85whxy.fsf@assigned-by-dhcp.cox.net>
On 7/27/07, Junio C Hamano <gitster@pobox.com> wrote:
> Would --stat --summary be satisfactory?
That's not what I want. I'm looking a report that indicates new files
vs modified ones in a single list. These old patches I am working with
often create 100 files and modify another 200.
Adding a code like (Added (A), Copied (C), Deleted (D), Modified (M),
Renamed (R)) to --stat would be perfect.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: git diff with add/modified codes
From: Junio C Hamano @ 2007-07-27 23:22 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910707271505x4eac928axe639308afed20cb3@mail.gmail.com>
Would --stat --summary be satisfactory?
^ permalink raw reply
* Re: git-gui: i18n introductory document (2nd draft)
From: Junio C Hamano @ 2007-07-27 23:18 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Shawn O. Pearce, Christian Stimming, Irina Riesen,
Paolo Ciarrocchi, Xudong Guan, Nanako Shiraishi, git,
Brett Schwarz
In-Reply-To: <7v4pjq7net.fsf@assigned-by-dhcp.cox.net>
My thanks go to Nana, VMiklos, Christian and Brett for their
feedbacks to the draft.
It quickly gets cumbersome, both for myself and reviewers, to go
back and forth sending the whole of Nth draft every time on the
mailing list. At the same time, I can not really afford to be
in the translation business myself, so I'd like to let this
document go in the best shape I could make, and have people more
competent around gettext than me to take it over.
I've updated the document somewhat and pushed it out to the mob
branch. The issues I addressed:
* "Running without installing does not work with ./git-gui, but
with ./git-gui.sh" (Nana).
* After the initial cloning, resulting local directory is
git-gui-i18n, not git-gui-i18n.git (VMiklos).
* "Please install them" (Christian). I meant by "them", git,
gettext and any one of po editors. I reworded the example
enumeration of available po editors to make it clear the
translator needs only one.
* "Parameter permutation needs $ sign quoted" (Brett).
* "Message marked with '# ,fuzzy' are not used -- remove the
fuzzy marker when you are done" (Christian).
I did not address the following issues, not because I did not
agree with the comments, but because I felt Christian is more
qualified to do these kinds of things.
* "Parameter permutation" should be in a separate "Advanced
translation" section (Christian).
* "po/git-gui.pot" should be generated by translators any time,
and other workflow improvements regarding merging of the po
files (Christian).
^ permalink raw reply
* Re: gitweb chokes on recursive symlink
From: Jakub Narebski @ 2007-07-27 22:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8x922r2w.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
[cut explanation about why one would want something like below]
> ln -s /pub /pub/pub
[...]
> However, gitweb chokes if there is such a symlink (File::Find
> barfs with "/pub/pub is a recursive symbolic link" --- I think
> this is because you use "follow_fast => 1").
>
> As I happen to think using a symlink that goes up for backward
> compatible URL support is a rather common practice, I think we
> should do something about it. My gut feeling is that we could
> simply ignore such symlinks.
>
> What do you think about this issue?
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index b381692..c8ad84e 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -1492,6 +1492,7 @@ sub git_get_projects_list {
>
> File::Find::find({
> follow_fast => 1, # follow symbolic links
> + follow_skip => 2, # ignore duplicates
> dangling_symlinks => 0, # ignore dangling symlinks, silently
> wanted => sub {
> # skip project-list toplevel, if we get it.
>
I guess that is a good solution, but I'm not Perl expert...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [RFC] Git User's Survey 2007
From: Jakub Narebski @ 2007-07-27 19:07 UTC (permalink / raw)
To: Andy Parkins, git; +Cc: Paolo Ciarrocchi
In-Reply-To: <200707271401.57833.andyparkins@gmail.com>
On Friday, 27 July 2007, Andy Parkins wrote:
> On Friday 2007 July 27, Jakub Narebski wrote:
>
> > Getting started with GIT
> >
> > 1. How did you hear about GIT?
> > 2. Did you find GIT easy to learn?
> > - very easy/easy/reasonably/hard/very hard
> > 3. What helped you most in learning to use it?
> > 4. What did you find hardest?
> > 5. When did you start using git? From which version?
>
> The primary assumption of the survey seems to be that the responder
> is already using git. What about some questions for people _not_
> using git; things like (badly written I'm sure, but you get
> the idea):
>
> Not using GIT
>
> Have you heard of git? i.e. do you know what it's for?
> Do you already use a VCS? Which one? Are you happy with it?
> If not, would you like to use a VCS?
> If you don't use a VCS already and don't want to - why not?
> If you do use a VCS already, but it's not git - why not?
> Would you like to use git but git doesn't supply a feature you need?
> What would you require from git to enable you to change?
Well, it is meant to be Git _USER'S_ Survey. The rest of questions
wouldn't have much sense if responder is not familiar with Git.
But I'd like to add the following questions about foreign SCM/VCS
to the survey:
-- >8 --
Other SCMs
1. What other SCM did/do you use?
2. What other SCM do you use as a main SCM for your project
instead of git, if any? Why?
* example: Mercurial, better MS Windows support
3. Do your git repository interact with other SCM? Or what SCM
did you import from? What tool did/do you use?
* examples: CVS, import fromcvs, interaction git-cvsserver;
Subversion, git-svn
-- >8 --
> > What you think of GIT
> >
> > 1. Overall, how happy are you with GIT?
> > - unhappy/not so happy/happy/very happy/completely extatic
>
> "extatic" should be "ecstatic"
Thanks. That reminds me to spellcheck the survey before
posting/creating it.
--
Jakub Narebski
Poland
^ permalink raw reply
* git diff with add/modified codes
From: Jon Smirl @ 2007-07-27 22:05 UTC (permalink / raw)
To: Git Mailing List
Is there a magic git diff incantation that will add file status codes
(Added (A), Copied (C), Deleted (D), Modified (M), Renamed (R)) to the
--stat output? I can't see how to get this info on any diff output
without doing multiple diffs with --diff-filter.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH] Make verify-tag a builtin.
From: Junio C Hamano @ 2007-07-27 21:08 UTC (permalink / raw)
To: Carlos Rica; +Cc: git, Johannes Schindelin
In-Reply-To: <1b46aba20707271251g7cf968a6o3840739dec548408@mail.gmail.com>
"Carlos Rica" <jasampler@gmail.com> writes:
> In my system, some of the tests give 141 and others give 1 as exit code.
> Dscho said that it could depend on the CPU current load of the computer,
> since he got always 141 as you said, so perhaps it's me.
This is expected. It depends on how processess are scheduled.
What is happening is:
1. Your process prepares the whole thing in vtag-tmp, to hand
to gpg;
2. You make a pipe and start gpg with the above file telling it
"here is a detached signature file, the payload will be fed
through your stdin";
3-a. You feed the payload to the pipe, expecting gpg to read it.
3-b. gpg reads the detached signature file, finds no signature in
the vtag-tmp file because the tag in question is not signed,
and exits without reading a single byte from the pipe;
Now, 3-a and 3-b run in parallel. If 3-a is scheduled before
3-b happens, because payload is very often much smaller than the
in-kernel pipe buffer, your write(2) succeeds before gpg gives up
and exits without reading from the pipe. If 3-b is scheduled
before 3-a, then gpg exits and when 3-a gets around to write(2)
to the pipe, write notices that there is nobody on the other end
of the pipe, and you get SIGPIPE.
^ permalink raw reply
* [PATCH] --base-path-relaxed option
From: Junio C Hamano @ 2007-07-27 21:00 UTC (permalink / raw)
To: git; +Cc: Jens Axboe
In-Reply-To: <20070727083814.GE32258@kernel.dk>
From: Jens Axboe <jens.axboe@oracle.com>
I switched git.kernel.dk to --base-path a few minutes ago, to get rid of
a /data/git postfix in the posted urls. But transitioning is tricky,
since now all old paths will fail miserably.
So I added this --base-path-relaxed option, that will make git-daemon
try the absolute path without prefixing --base-path before giving up.
With this in place and --base-path-relaxed added, both my new url of
git://git.kernel.dk/linux-2.6-block.git
and the old
git://git.kernel.dk/data/git/linux-2.6-block.git
work fine.
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
---
* I think this patch is a right step; we would need to help
people transitioning their repository URL, not necessarily
limited to --base-path usage. This patch only deals with
"with this base path or without" case, and does not help
people who used to use base-path A and now wants to use
different base-path B, so in that sense there *might* still
be a room for improvement. It could be as simple as allowing
more than than one base-path and taking the first match.
If you set one of them to an empty string, it would cover the
case this patch addresses, I think.
I personally do not think we would want to try 47 different
base-paths, though. List?
Documentation/git-daemon.txt | 6 ++++++
daemon.c | 26 ++++++++++++++++++++++++--
2 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-daemon.txt b/Documentation/git-daemon.txt
index 4b30b18..f902161 100644
--- a/Documentation/git-daemon.txt
+++ b/Documentation/git-daemon.txt
@@ -54,6 +54,12 @@ OPTIONS
'git://example.com/hello.git', `git-daemon` will interpret the path
as '/srv/git/hello.git'.
+--base-path-relaxed::
+ If --base-path is enabled and repo lookup fails, with this option
+ `git-daemon` will attempt to lookup without prefixing the base path.
+ This is useful for switching to --base-path usage, while still
+ allowing the old paths.
+
--interpolated-path=pathtemplate::
To support virtual hosting, an interpolated path template can be
used to dynamically construct alternate paths. The template
diff --git a/daemon.c b/daemon.c
index a3f2ac1..9cf22fe 100644
--- a/daemon.c
+++ b/daemon.c
@@ -16,7 +16,8 @@ static int reuseaddr;
static const char daemon_usage[] =
"git-daemon [--verbose] [--syslog] [--export-all]\n"
" [--timeout=n] [--init-timeout=n] [--strict-paths]\n"
-" [--base-path=path] [--user-path | --user-path=path]\n"
+" [--base-path=path] [--base-path-relaxed]\n"
+" [--user-path | --user-path=path]\n"
" [--interpolated-path=path]\n"
" [--reuseaddr] [--detach] [--pid-file=file]\n"
" [--[enable|disable|allow-override|forbid-override]=service]\n"
@@ -34,6 +35,7 @@ static int export_all_trees;
/* Take all paths relative to this one if non-NULL */
static char *base_path;
static char *interpolated_path;
+static int base_path_relaxed;
/* Flag indicating client sent extra args. */
static int saw_extended_args;
@@ -180,6 +182,7 @@ static char *path_ok(struct interp *itable)
{
static char rpath[PATH_MAX];
static char interp_path[PATH_MAX];
+ int retried_path = 0;
char *path;
char *dir;
@@ -235,7 +238,22 @@ static char *path_ok(struct interp *itable)
dir = rpath;
}
- path = enter_repo(dir, strict_paths);
+ do {
+ path = enter_repo(dir, strict_paths);
+ if (path)
+ break;
+
+ /*
+ * if we fail and base_path_relaxed is enabled, try without
+ * prefixing the base path
+ */
+ if (base_path && base_path_relaxed && !retried_path) {
+ dir = itable[INTERP_SLOT_DIR].value;
+ retried_path = 1;
+ continue;
+ }
+ break;
+ } while (1);
if (!path) {
logerror("'%s': unable to chdir or not a git archive", dir);
@@ -1061,6 +1079,10 @@ int main(int argc, char **argv)
base_path = arg+12;
continue;
}
+ if (!strcmp(arg, "--base-path-relaxed")) {
+ base_path_relaxed = 1;
+ continue;
+ }
if (!prefixcmp(arg, "--interpolated-path=")) {
interpolated_path = arg+20;
continue;
--
Jens Axboe
^ permalink raw reply related
* Re: [PATCH 8/8] Fix t1500 for sane work-tree behavior
From: Junio C Hamano @ 2007-07-27 20:51 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, matled
In-Reply-To: <Pine.LNX.4.64.0707271958590.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> When GIT_DIR=../.git, and no worktree is specified, it is reasonable
> to assume that the repository is not bare, that the work tree is ".."
> and that the prefix is the basename of the current directory.
>
> This is the sane behavior.
That is a bit too strong blanket statement, while being weak on
exact conditions, giving only one example.
It makes me wonder...
* When GIT_DIR=../../.git, and no worktree is specified, the
same holds true, with worktree is "../.."? (probably yes)
* "GIT_DIR=../../foo/.git"? (I dunno)
* "GIT_DIR=../foo.git"? (probably not)
I am assuming that you meant something like this:
When no worktree is specified, and GIT_DIR (or --git-dir=) is
zero or more "../" followed by ".git" after stripping trailing
and/or redundant slashes, it is reasonable to assume that the
repository is not bare, and the work tree is the parent
directory of the GIT_DIR directory.
but that requires guesswork if you give only one example and let
the readers to guess.
^ permalink raw reply
* Re: [PATCH 5/8] work-trees are allowed inside a git-dir
From: Junio C Hamano @ 2007-07-27 20:51 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, matled
In-Reply-To: <Pine.LNX.4.64.0707271957250.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> It is allowed to call
>
> $ git --git-dir=../ --work-tree=. bla
>
> when you really want to. In this case, you are both in the git directory
> and in the working tree.
>
> The earlier handling of this situation was seriously bogus. For regular
> working tree operations, it checked if inside git dir. That makes no
> sense, of course, since the check should be for a work tree, and nothing
> else.
>
> Fix that.
I do not doubt this patch makes the above command line to work
better, but I have to wonder how that layout is useful. Care to
give a use case or two in the commit log message?
^ permalink raw reply
* Re: [PATCH 3/8] Clean up work-tree handling
From: Junio C Hamano @ 2007-07-27 20:51 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: gitster, git, matled
In-Reply-To: <Pine.LNX.4.64.0707271956420.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Not only because of ohloh am I proud that in spite of removing
> more lines than I added, there were more comments added than
> removed...
> diff --git a/builtin-rev-parse.c b/builtin-rev-parse.c
> index 497903a..3f787a8 100644
> --- a/builtin-rev-parse.c
> +++ b/builtin-rev-parse.c
> @@ -320,15 +320,9 @@ int cmd_rev_parse(int argc, const char **argv, const char *prefix)
> continue;
> }
> if (!strcmp(arg, "--show-cdup")) {
> - const char *pfx = prefix;
> - while (pfx) {
> - pfx = strchr(pfx, '/');
> - if (pfx) {
> - pfx++;
> - printf("../");
> - }
> - }
> - putchar('\n');
> + const char *work_tree = get_git_work_tree();
> + if (work_tree)
> + printf("%s\n", work_tree);
> continue;
This changes semantics, I think.
It used to be relative "up" path when no funny work-tree stuff
is used, but get_git_work_tree() now seems to return absolute,
hence this option as well. If it introduces regression to
existing callers is up to what the caller does to the resulting
path, though. If it only is used to prefix other things
(i.e. path="$(git rev-parse --show-cdup)$1"), the caller would
be safe, but if the caller counted number of ../ in the return
value to see how deep it is, or if the caller expected to see
empty string in order to see if the process is at the toplevel,
this change would become a regression.
> @@ -62,15 +66,8 @@ static void setup_git_env(void)
>
> int is_bare_repository(void)
> {
> + /* if core.bare is not 'false', let's see if there is a work tree */
> + return is_bare_repository_cfg && !get_git_work_tree();
> }
I thought about making core.bare a tertiary, true/false/depends,
but I think this makes more sense.
^ permalink raw reply
* Re: [PATCH 2/8] Add functions get_relative_cwd() and is_inside_dir()
From: Junio C Hamano @ 2007-07-27 20:51 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, matled
In-Reply-To: <Pine.LNX.4.64.0707271956140.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> +char *get_relative_cwd(char *buffer, int size, const char *dir)
> +{
> + char *cwd = buffer;
> +
> + if (!dir)
> + return 0;
> +
> + if (!getcwd(buffer, PATH_MAX))
> + return 0;
Can size be less than PATH_MAX?
^ permalink raw reply
* Re: [PATCH 1/8] Add is_absolute_path() and make_absolute_path()
From: Junio C Hamano @ 2007-07-27 20:51 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, matled
In-Reply-To: <Pine.LNX.4.64.0707271955450.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> diff --git a/path.c b/path.c
> index c4ce962..0f7012f 100644
> --- a/path.c
> +++ b/path.c
> @@ -292,3 +292,65 @@ int adjust_shared_perm(const char *path)
> return -2;
> return 0;
> }
> +
> +/* We allow "recursive" symbolic links. Only within reason, though. */
> +#define MAXDEPTH 5
> +
> +const char *make_absolute_path(const char *path)
> +{
> + static char bufs[2][PATH_MAX + 1], *buf = bufs[0], *next_buf = bufs[1];
> + char cwd[1024] = "";
> + int buf_index = 1, len;
> +
> + int depth = MAXDEPTH;
> + char *last_elem = NULL;
> + struct stat st;
> +
> + if (strlcpy(buf, path, PATH_MAX) >= PATH_MAX)
> + die ("Too long path: %.*s", 60, path);
> +
> + while (depth--) {
> + if (stat(buf, &st) || !S_ISDIR(st.st_mode)) {
> + char *last_slash = strrchr(buf, '/');
> + *last_slash = '\0';
> + last_elem = xstrdup(last_slash + 1);
What happens when incoming path is just "abc"? Does your test
script checks that case?
^ 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