* Re: Subversion-style incrementing revision numbers
From: Shawn Pearce @ 2006-09-19 22:23 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <eeppkl$rm9$2@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> wrote:
> Joel Dice wrote:
> > Proposal:
> >
> > As with Subversion, the IRN state in Git would be specific to a given
> > repository and have no significance beyond that repository. Also like
> > Subversion, IRN state would be global across a repository, so that a
> > commit to any branch would increment the current IRN value. Every Git
> > command taking a revision parameter would accept an IRN using a syntax
> > such as "r$IRN". Every commit would report the IRN to the user as well as
> > the SHA ID. The IRN feature could be enabled or disabled via a
> > configuration option.
>
> This of course limits IRN much. Tags are valid across repositories.
> I'm not sure if many repositories are managed using shared repositories
> (centralized approach).
Not only that but its somewhat difficult to execute
`git log v1.4.0..v1.4.1` on a central repository; if IRNs are only
valid within that repository then that's the only way they could
even be used.
Note that somewhat difficult here means you need to:
- gain direct read-only access to the repository's files (not
all systems may be able to offer this to all users);
- set GIT_DIR environment variable OR pass --git-dir before
the subcommand;
- do all of that without doing something stupid in the
repository directory such as `rm *` without realizing
where you are;
- but still maintain write access so you can push.
and that latter GIT_DIR/--git-dir part users are bound to forgot as
its not as natural as just assuming the repository is the directory
you are in. Of course that could be probably fixed...
--
Shawn.
^ permalink raw reply
* Re: Subversion-style incrementing revision numbers
From: Joel Dice @ 2006-09-19 22:24 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060919220011.GD8259@pasky.or.cz>
On Wed, 20 Sep 2006, Petr Baudis wrote:
> Dear diary, on Tue, Sep 19, 2006 at 11:42:20PM CEST, I got a letter
> where Joel Dice <dicej@mailsnare.net> said that...
>> On Tue, 19 Sep 2006, Petr Baudis wrote:
>>> Also, multiple IRNs could refer to a single real commit if you do e.g.
>>> cg-admin-uncommit, since revlog logs revision updates, not new revisions
>>> created. This may or may not be considered a good thing. If you rather
>>> want to just create a new IRN at commit object creation time, also note
>>> that some tools _might_ validly create commit objects and then throw
>>> them away, which would generate non-sensical (and after prune, invalid)
>>> IRNs.
>>
>> I'm not too worried about cg-admin-uncommit or git-reset, since the IRN
>> feature is intended mainly for shared repositories. I would suggest that
>> such commands simply be disallowed for such repositories.
>
> What kind of shared repositories? You yourself said that IRNs are
> local to a repository, thus they are not preserved over cloning/fetching
> from a repository, if you mean that.
The scenario I envision is several developers, each with a clone of a
shared repository. The clones would not have IRNs turned on, only the
shared repository. So, when I do a "git push", I get an IRN back, and I
am not confused, because I know that IRN only applies to the shared
repository. Then, when I mark a Bugzilla bug as fixed and attach the IRN
to it, everybody knows that IRN refers to the shared repository. After
all, I wouldn't mark the bug fixed if I had only committed it to my own
private repository.
I could also turn on IRNs on my clone if I really wanted, but not if I
thought it would confuse myself or others.
>> The problem of temporary commits certainly needs to be addressed. In this
>> case, may I assume nothing under $GIT_DIR/refs is ever modified? If so,
>> perhaps I could somehow hook into the git-update-ref step. Is that what
>> the revlog code does?
>
> Yes. But not every commit is always recorded to something in refs/.
> The simplest case is if you fetch from a remote repository (or push to
> your repository), only the latest commit is recorded.
That's what I figured. I should be able to walk the commit chain to get
at all the commits in a push or fetch, right?
- Joel
^ permalink raw reply
* Re: Subversion-style incrementing revision numbers
From: Joel Dice @ 2006-09-19 22:30 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <eeppkl$rm9$2@sea.gmane.org>
On Wed, 20 Sep 2006, Jakub Narebski wrote:
> Joel Dice wrote:
>
>> I'm considering adopting Git for a medium-sized project which is currently
>> managed using Subversion. I've used Git for a few smaller projects
>> already, and the thing I've missed most from Subversion is the convenience
>> of incrementing revision numbers. The following is a proposal to add this
>> feature to Git.
>>
>>
>> Rationale:
>>
>> Incrementing revision numbers (IRNs - an acronym I just made up) are
>> useful in that they can be treated as auto-generated tags which are easier
>> to remember and communicate than SHA hashes, yet do not require extra
>> effort to create like real tags. Also, they have the advantage of being
>> chronologically ordered, so if I assert that a bug was fixed in revision
>> 42 of a shared repository, everyone may assume that revision 45 has that
>> fix as well.
>
> That is true _only_ if you have linear history. If you have multiple
> concurrent branches, revision 42 can be in branch 'next', revision '45' in
> topic branch 'xx/topic' which forked before revision 42, and do not have
> the fix.
In practice, this is not a problem. The branch referred to is usually
understood from the context (ex. a Bugzilla bug for a particular version
of a product implies a particular branch). Otherwise, yes, you must also
explictly state which branch the fix was applied to.
> Unfortunately, one cannot (as of now) use result of git-describe as
> <commit-ish>. I'd rather have it fixed, than port idea from _centralized_
> SCM do distributed SCM.
>
>> Proposal:
>>
>> As with Subversion, the IRN state in Git would be specific to a given
>> repository and have no significance beyond that repository. Also like
>> Subversion, IRN state would be global across a repository, so that a
>> commit to any branch would increment the current IRN value. Every Git
>> command taking a revision parameter would accept an IRN using a syntax
>> such as "r$IRN". Every commit would report the IRN to the user as well as
>> the SHA ID. The IRN feature could be enabled or disabled via a
>> configuration option.
>
> This of course limits IRN much. Tags are valid across repositories.
> I'm not sure if many repositories are managed using shared repositories
> (centralized approach).
I would suggest that most repositories are centralized. They're just not
using Git yet :)
- Joel
^ permalink raw reply
* Re: Subversion-style incrementing revision numbers
From: Shawn Pearce @ 2006-09-19 22:33 UTC (permalink / raw)
To: Joel Dice; +Cc: Petr Baudis, git
In-Reply-To: <Pine.LNX.4.62.0609191609090.9752@joeldicepc.ecovate.com>
Joel Dice <dicej@mailsnare.net> wrote:
> The scenario I envision is several developers, each with a clone of a
> shared repository. The clones would not have IRNs turned on, only the
> shared repository. So, when I do a "git push", I get an IRN back, and I
> am not confused, because I know that IRN only applies to the shared
> repository. Then, when I mark a Bugzilla bug as fixed and attach the IRN
> to it, everybody knows that IRN refers to the shared repository. After
> all, I wouldn't mark the bug fixed if I had only committed it to my own
> private repository.
How about recording the Bugzilla bug id in the commit message (such
as by simply mentioning "bug 123") and having an update hook on the
central repository extract that from the commits being pushed and
posting an update to the Bugzilla database? The update can include
the branch name the commit(s) were pushed into and the final commit
SHA1 (or say 8 character abbreviation).
Its automatic and its easy for the developers. I'm (sort of) doing
this for a system that's a lot more difficult to use than Bugzilla.
My fellow developers are very happy.
> That's what I figured. I should be able to walk the commit chain to get
> at all the commits in a push or fetch, right?
In the update hook you get 3 args: refname oldsha1 newsha1
You can get the list of commits you are "receiving" during the single
push operation from:
git log --pretty=raw $2..$3
a quick parse for "bug (\d)+" on that text, make a set of of IDs
to update, then go update then storing the first 8 characters of
$3 and $1 (the branch name) into your bug tracker.
I said "receiving" in air quotes as you may already have some or
all of those commits in the current repository; they just are part
of other branches other than the one being pushed into.
Later another developer can ask if the fix for bug 123 is in any
given branch by looking at
git log master..$idfrombug
where 'master' is any branch and $idfrombug is the 8 character
abbreviation you stored into the bug record in the update hook.
If this returns no output then the bug fix is contained in the
branch master; if it returns output then those are the commits
which were considered to be part of the bug fix that aren't in the
branch master.
--
Shawn.
^ permalink raw reply
* Re: Subversion-style incrementing revision numbers
From: Shawn Pearce @ 2006-09-19 22:39 UTC (permalink / raw)
To: Joel Dice; +Cc: Petr Baudis, git
In-Reply-To: <Pine.LNX.4.62.0609191525490.9752@joeldicepc.ecovate.com>
Joel Dice <dicej@mailsnare.net> wrote:
> I'm not too worried about cg-admin-uncommit or git-reset, since the IRN
> feature is intended mainly for shared repositories. I would suggest that
> such commands simply be disallowed for such repositories.
>
> The problem of temporary commits certainly needs to be addressed. In this
> case, may I assume nothing under $GIT_DIR/refs is ever modified? If so,
> perhaps I could somehow hook into the git-update-ref step. Is that what
> the revlog code does?
$GIT_DIR/refs is always modified. Its probably the most heavily
modified part of a GIT_DIR, aside from the index. Simply because
the ref files must be modified every time a commit, fetch or merge
completes. Its also a directory you don't want to delete; I once
did an `rm -rf .git/refs` in a repository with a many branches.
That was no fun to recover.
git-update-ref is used by pretty much all non-C code to update a
ref file. The APIs it calls invoke the reflog code to record the
update being made to the ref if the user has enabled logging on
that ref (not all users want all refs logged apparently). I don't
think its a great idea to plug more complex logic into that part
of the system. The reflog code already made it more complex then
it needed to be; Linus apparently just found out how heavily we
use static buffers down there...
--
Shawn.
^ permalink raw reply
* Re: Subversion-style incrementing revision numbers
From: Joel Dice @ 2006-09-19 22:40 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060919220936.GA11601@spearce.org>
On Tue, 19 Sep 2006, Shawn Pearce wrote:
> Joel Dice <dicej@mailsnare.net> wrote:
>> I'm considering adopting Git for a medium-sized project which is currently
>> managed using Subversion. I've used Git for a few smaller projects
>> already, and the thing I've missed most from Subversion is the convenience
>> of incrementing revision numbers. The following is a proposal to add this
>> feature to Git.
>
> I can't say I miss that particular feature. Abbrevations of
> SHA1 IDs tend to work very well for the projects I use Git on;
> 6-8 characters is easily more than enough to uniquely identify
> a revision. Heck half the time even 4 hex characters is enough.
>
>> Rationale:
>>
>> Incrementing revision numbers (IRNs - an acronym I just made up) are
>> useful in that they can be treated as auto-generated tags which are easier
>> to remember and communicate than SHA hashes, yet do not require extra
>> effort to create like real tags. Also, they have the advantage of being
>> chronologically ordered, so if I assert that a bug was fixed in revision
>> 42 of a shared repository, everyone may assume that revision 45 has that
>> fix as well.
>
> But with respect to what branch?
>
> Branches in a Git repository are very common:
>
> o------o-o-o-o-o-o--- B1
> /
> -o--o--o-----o--------o B2
>
> Assuming the branch point on the left was r60, what is the latest
> commit on B1? On B2? What about if I merge B1 and B2 together?
Branches in Subversion are also very common. The "last changed" IRN for a
branch is the index of the head of the branch in the history.
> Or are you proposing that the commits are ordered by the time that
> they arrive into the repository?
Yes.
> But even if that's the case lets say I fix the bug on B1 in r42
> but a commit on B2 gets assigned r45. The bug isn't fixed in r45;
> not unless B1 was merged into B2 in r43, r44 or r45. But there's
> no way to know that from just an IRN.
>
> I fail to see how IRNs simplify commit naming or determining where
> a feature or bug fix is within the branching structure.
I'm not suggesting that an IRN stand on it's own in this way. Additional
context may be necessary depending on the situation. It's intended as a
convenience, not a replacement for the SHA IDs.
>> A simple, efficient implementation of this feature would be based on a
>> single file, $GIT_DIR/history, which would contain a newline-delimited
>> list of SHA commit IDs in chronological order, oldest first. The current
>> repository IRN would be calculated as the size of that file divided by the
>> SHA+newline length, and the commit ID of any IRN could be determined by
>> seeking to the correct offset in that file. Every commit would cause a
>> new line to be appended to the history file with that commit's ID.
>> Finally, a history file could be generated for an existing repository by
>> serializing the commit history based on chronological order.
>
> How about just using bare tags under the namespace 'refs/tags/r/'?
> With the new packed refs implemention these would cost you a tiny
> amount of overhead over what you propose (due to the ref name also
> being stored) but its already implemented and does the job just
> as well.
Good idea. I'll try that.
- Joel
^ permalink raw reply
* Re: Subversion-style incrementing revision numbers
From: Johannes Schindelin @ 2006-09-19 22:40 UTC (permalink / raw)
To: Joel Dice; +Cc: Petr Baudis, git
In-Reply-To: <Pine.LNX.4.62.0609191609090.9752@joeldicepc.ecovate.com>
Hi,
On Tue, 19 Sep 2006, Joel Dice wrote:
> The scenario I envision is several developers, each with a clone of a
> shared repository. The clones would not have IRNs turned on, only the
> shared repository. So, when I do a "git push", I get an IRN back, and I
> am not confused, because I know that IRN only applies to the shared
> repository. Then, when I mark a Bugzilla bug as fixed and attach the IRN
> to it, everybody knows that IRN refers to the shared repository. After
> all, I wouldn't mark the bug fixed if I had only committed it to my own
> private repository.
Why not just tag the commit with something like "bugzilla/#bugid"?
Granted, it makes for lots of tags. But we actually handle lots of tags.
BTW if your IRN just wants to serve to be less cryptic than SHA1s, you can
try git-name-rev (of course, it is only immutable if you have a recent
tag and use the --tags option).
Ciao,
Dscho
^ permalink raw reply
* [PATCH] gitweb: Even more support for PATH_INFO based URLs
From: Jakub Narebski @ 2006-09-19 22:49 UTC (permalink / raw)
To: git; +Cc: Martin Waitz, Matthias Lederhofer
Now the following types of path based URLs are supported:
* project overview (summary) page of project
* project/branch shortlog of branch
* project/branch:file file in branch, blob_plain view
* project/branch:dir/ directory listing of dir in branch, tree view
The following shortcuts works (see explanation below):
* project/branch: directory listing of branch, main tree view
* project/:file file in HEAD (raw)
* project/:dir/ directory listing of dir in HEAD
* project/: directory listing of project's HEAD
We use ':' as separator between branch (ref) name and file name
(pathname) because valid branch (ref) name cannot have ':' inside.
This limit applies to branch name only. This allow for hierarchical
branches e.g. topic branch 'topic/subtopic', separate remotes
tracking branches e.g. 'refs/remotes/origin/HEAD', and discriminate
between head (branch) and tag with the same name.
Empty branch should be interpreted as HEAD.
If pathname (the part after ':') ends with '/', we assume that pathname
is name of directory, and we want to show contents of said directory
using "tree" view. If pathname is empty, it is equivalent to '/' (top
directory).
If pathname (the part after ':') does not end with '/', we assume that
pathname is name of file, and we show contents of said file using
"blob_plain" view.
Pathname is stripped of leading '/', so we can use ':/' to separate
branch from pathname. The rationale behind support for PATH_INFO based
URLs was to support project web pages for small projects: just create
an html branch and then use an URL like
http://nowhere.com/gitweb.cgi/project.git/html:/index.html
The ':/' syntax allow for working links between .html files served
in such way, e.g. <a href="main.html"> link inside "index.html"
would get
http://nowhere.com/gitweb.cgi/project.git/html:/main.html.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Alternatively we could use git-cat-file -t (git_get_type subroutine)
to distinguish between trees and files (blobs), but first it would
slow gitweb somewhat (additional fork), and second git_get_type
assumes that $git_dir is set... and this variable is defined later!
See also:
"[PATCH] gitweb: more support for PATH_INFO based URLs"
Message-ID: <20060916210832.GV17042@admingilde.org>
http://permalink.gmane.org/gmane.comp.version-control.git/27133
(this email should be probably posted in this thread)
gitweb/gitweb.perl | 29 ++++++++++++++++++++---------
1 files changed, 20 insertions(+), 9 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 9445fa7..839b232 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -274,13 +274,16 @@ sub evaluate_path_info {
return if defined $project;
my $path_info = $ENV{"PATH_INFO"};
return if !$path_info;
- $path_info =~ s,(^/|/$),,gs;
- $path_info = validate_input($path_info);
+ $path_info =~ s,^/+,,;
return if !$path_info;
+ # find which part of PATH_INFO is project
$project = $path_info;
+ $project =~ s,/+$,,;
while ($project && !-e "$projectroot/$project/HEAD") {
$project =~ s,/*[^/]*$,,;
}
+ # validate project
+ $project = validate_input($project);
if (!$project ||
($export_ok && !-e "$projectroot/$project/$export_ok") ||
($strict_export && !project_in_list($project))) {
@@ -289,15 +292,23 @@ sub evaluate_path_info {
}
# do not change any parameters if an action is given using the query string
return if $action;
- if ($path_info =~ m,^$project/([^/]+)/(.+)$,) {
- # we got "project.git/branch/filename"
- $action ||= "blob_plain";
- $hash_base ||= validate_input($1);
- $file_name ||= validate_input($2);
- } elsif ($path_info =~ m,^$project/([^/]+)$,) {
+ $path_info =~ s,^$project/*,,;
+ my ($refname, $pathname) = split(/:/, $path_info, 2);
+ if (defined $pathname) {
+ # we got "project.git/branch:filename" or "project.git/branch:dir/"
+ # we could use git_get_type(branch:pathname), but it needs $git_dir
+ $pathname =~ s,^/+,,;
+ if (!$pathname || substr($pathname, -1) eq "/") {
+ $action ||= "tree";
+ } else {
+ $action ||= "blob_plain";
+ }
+ $hash_base ||= validate_input($refname);
+ $file_name ||= validate_input($pathname);
+ } elsif (defined $refname) {
# we got "project.git/branch"
$action ||= "shortlog";
- $hash ||= validate_input($1);
+ $hash ||= validate_input($refname);
}
}
evaluate_path_info();
--
1.4.2.1
^ permalink raw reply related
* [PATCH] gitweb: Support for custom per-project owner string
From: Petr Baudis @ 2006-09-19 22:55 UTC (permalink / raw)
To: git
This adds very simple support for per-project setting of the owner string
(in an environment where the actual owners won't have access to the
repositories accessed by gitweb, so faking identity is not an issue).
There should be an option to disable this, but this is just a patch
that someone might like (and/or pick up and polish), not intended for
inclusion as it is.
Also, ideally this would be in the configfile but calling repoconfig for
each repository in the index would slow things down way too much.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
gitweb/gitweb.perl | 11 +++++++++--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 7ecd7df..d50bae5 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -818,6 +818,13 @@ sub git_get_project_owner {
}
close $fd;
}
+ if (!defined $owner and -f "$projectroot/$project/owner") {
+ if (open my $fd, "$projectroot/$project/owner") {
+ $owner = <$fd>;
+ chomp $owner;
+ close $fd;
+ }
+ }
if (!defined $owner) {
$owner = get_file_owner("$projectroot/$project");
}
@@ -2186,7 +2193,7 @@ sub git_project_list {
$pr->{'descr'} = chop_str($descr, 25, 5);
}
if (!defined $pr->{'owner'}) {
- $pr->{'owner'} = get_file_owner("$projectroot/$pr->{'path'}") || "";
+ $pr->{'owner'} = git_get_project_owner($pr->{'path'}) || "";
}
push @projects, $pr;
}
@@ -2275,7 +2282,7 @@ sub git_project_index {
foreach my $pr (@projects) {
if (!exists $pr->{'owner'}) {
- $pr->{'owner'} = get_file_owner("$projectroot/$project");
+ $pr->{'owner'} = git_get_project_owner($project);
}
my ($path, $owner) = ($pr->{'path'}, $pr->{'owner'});
^ permalink raw reply related
* Re: [PATCH] gitweb: Support for custom per-project owner string
From: Jakub Narebski @ 2006-09-19 23:04 UTC (permalink / raw)
To: git
In-Reply-To: <20060919225522.GB13132@pasky.or.cz>
Petr Baudis wrote:
> This adds very simple support for per-project setting of the owner string
> (in an environment where the actual owners won't have access to the
> repositories accessed by gitweb, so faking identity is not an issue).
Is it really needed? If $projects_list is a _file_, you can set correct
ownership information there.
Now $projects_list being a directory (usually $projectroot) support
hierarchy of repositories; generating appropriate projects' index file
is as easy as unsetting $projects_list (so it is by default set to
$projectroot), going to summary view, clicking [TXT] link on the left of
[OPML] link at the bottom, copy the result to projects' index file, correct
ownership information (and perhaps remove some projects), and set
$projects_list to this file.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Subversion-style incrementing revision numbers
From: Joel Dice @ 2006-09-19 23:07 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <eepq7l$dc$1@sea.gmane.org>
On Wed, 20 Sep 2006, Jakub Narebski wrote:
> Jakub Narebski wrote:
>
>> Joel Dice wrote:
>>
>>> I'm considering adopting Git for a medium-sized project which is currently
>>> managed using Subversion. I've used Git for a few smaller projects
>>> already, and the thing I've missed most from Subversion is the convenience
>>> of incrementing revision numbers. The following is a proposal to add this
>>> feature to Git.
>>>
>>>
>>> Rationale:
>>>
>>> Incrementing revision numbers (IRNs - an acronym I just made up) are
>>> useful in that they can be treated as auto-generated tags which are easier
>>> to remember and communicate than SHA hashes, yet do not require extra
>>> effort to create like real tags. Also, they have the advantage of being
>>> chronologically ordered, so if I assert that a bug was fixed in revision
>>> 42 of a shared repository, everyone may assume that revision 45 has that
>>> fix as well.
>>
>> That is true _only_ if you have linear history. If you have multiple
>> concurrent branches, revision 42 can be in branch 'next', revision '45' in
>> topic branch 'xx/topic' which forked before revision 42, and do not have
>> the fix.
>
> Additionally, what does _chronological_ mean? Time the commit is recorded?
Yes.
> Remember that in distributed development commits can be fetched from other
> repository, or arrive via email and applied using git-am. In git you can
> also rebase branch. Git records merges, and said merges are sometimes
> just fast-forward. All those difficulties have to be solved for IRNs.
All of these boil down to pointing the head of a branch to a new commit
object, right? I'm simply proposing that every time this happens, that
new commit object (which may not really be *new*), should be appended to
the IRN history file, along with any commits attached to it (as in the
cases of fetch, etc.).
- Joel
^ permalink raw reply
* Re: [PATCH] gitweb: Support for custom per-project owner string
From: Petr Baudis @ 2006-09-19 23:09 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <eept0r$5d0$1@sea.gmane.org>
Dear diary, on Wed, Sep 20, 2006 at 01:04:50AM CEST, I got a letter
where Jakub Narebski <jnareb@gmail.com> said that...
> Petr Baudis wrote:
>
> > This adds very simple support for per-project setting of the owner string
> > (in an environment where the actual owners won't have access to the
> > repositories accessed by gitweb, so faking identity is not an issue).
>
> Is it really needed? If $projects_list is a _file_, you can set correct
> ownership information there.
>
> Now $projects_list being a directory (usually $projectroot) support
> hierarchy of repositories; generating appropriate projects' index file
> is as easy as unsetting $projects_list (so it is by default set to
> $projectroot), going to summary view, clicking [TXT] link on the left of
> [OPML] link at the bottom, copy the result to projects' index file, correct
> ownership information (and perhaps remove some projects), and set
> $projects_list to this file.
Which is not really easy at all. I would have to do some ugly script to
autogenerate the text file while this way I can just throw the data to
the hierarchy and having everything still working magically.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* [PATCH] Added --mirror-all to git-fetch.
From: Shawn Pearce @ 2006-09-19 23:28 UTC (permalink / raw)
To: git
The --mirror-all option to git-fetch can be used to obtain a copy of
every available remote ref into the current repository. This can be
a rather destructive update as the local repository will have its
HEAD ref overwritten, as well as any ref which it shares in common
with the remote repository. On the other hand it can be useful if
all you want to do is have this repository track another repository,
such as if you are providing Git repository hosting and mirroring
source repositories on other systems.
Currently local refs are not deleted even if they do not exist in the
remote repository. This may be taken as either a feature or a bug.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
pasky was asking about this on #git. So here it is.
Documentation/fetch-options.txt | 7 ++++++
git-fetch.sh | 43 ++++++++++++++++++++++++++++++++++++---
2 files changed, 47 insertions(+), 3 deletions(-)
diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
index 13f34d3..5ed9b4f 100644
--- a/Documentation/fetch-options.txt
+++ b/Documentation/fetch-options.txt
@@ -30,6 +30,13 @@
flag lets all tags and their associated objects be
downloaded.
+\--mirror-all::
+ All refs and tags on the remote side are downloaded to
+ the local side. This option is not intendend for user
+ repositories as it will overwrite every local ref,
+ including HEAD. You probably don't mean to use this
+ option.
+
-k, \--keep::
Keep downloaded pack.
diff --git a/git-fetch.sh b/git-fetch.sh
index 09a5d6c..d22c560 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -14,6 +14,7 @@ IFS="$LF"
rloga=fetch
no_tags=
tags=
+mirror_all=
append=
force=
verbose=
@@ -36,6 +37,9 @@ do
-f|--f|--fo|--for|--forc|--force)
force=t
;;
+ --mirror-all)
+ mirror_all=t
+ ;;
-t|--t|--ta|--tag|--tags)
tags=t
;;
@@ -216,12 +220,45 @@ case "$update_head_ok" in
;;
esac
-# If --tags (and later --heads or --all) is specified, then we are
-# not talking about defaults stored in Pull: line of remotes or
+# If --tags or -mirror_all (and later --heads) is specified, then we
+# are not talking about defaults stored in Pull: line of remotes or
# branches file, and just fetch those and refspecs explicitly given.
# Otherwise we do what we always did.
-reflist=$(get_remote_refs_for_fetch "$@")
+if test "$mirror_all"
+then
+ tags=0; # tags are implied in all
+ reflist=`IFS=" " &&
+ (
+ git-ls-remote $upload_pack "$remote" ||
+ echo fail ouch
+ ) |
+ while read sha1 name
+ do
+ case "$sha1" in
+ fail)
+ exit 1
+ esac
+ case "$name" in
+ *^*) continue ;;
+ esac
+ if git-check-ref-format "$name"
+ then
+ echo ".+${name}:${name}"
+ else
+ if test "x$name" = xHEAD
+ then
+ echo ".+${name}:${name}"
+ else
+ echo >&2 "warning: malformed ref ${name} ignored"
+ fi
+ fi
+ done` || exit
+else
+ # Not using all; do what we always have done.
+ reflist=$(get_remote_refs_for_fetch "$@")
+fi
+
if test "$tags"
then
taglist=`IFS=" " &&
--
1.4.2.1.g832e
^ permalink raw reply related
* Re: [PATCH] Added --mirror-all to git-fetch.
From: Petr Baudis @ 2006-09-19 23:41 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060919232851.GA12195@spearce.org>
Dear diary, on Wed, Sep 20, 2006 at 01:28:51AM CEST, I got a letter
where Shawn Pearce <spearce@spearce.org> said that...
> Currently local refs are not deleted even if they do not exist in the
> remote repository. This may be taken as either a feature or a bug.
It's a bug for my purposes, but a minor one.
> pasky was asking about this on #git. So here it is.
Thanks!
> @@ -216,12 +220,45 @@ case "$update_head_ok" in
> ;;
> esac
>
> -# If --tags (and later --heads or --all) is specified, then we are
> -# not talking about defaults stored in Pull: line of remotes or
> +# If --tags or -mirror_all (and later --heads) is specified, then we
^^ missing dash ;-)
> +# are not talking about defaults stored in Pull: line of remotes or
> # branches file, and just fetch those and refspecs explicitly given.
> # Otherwise we do what we always did.
>
> -reflist=$(get_remote_refs_for_fetch "$@")
> +if test "$mirror_all"
> +then
> + tags=0; # tags are implied in all
This should be tags=;
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* Re: Subversion-style incrementing revision numbers
From: Joel Dice @ 2006-09-19 23:35 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Petr Baudis, git
In-Reply-To: <Pine.LNX.4.64.0609191519090.4388@g5.osdl.org>
On Tue, 19 Sep 2006, Linus Torvalds wrote:
> On Wed, 20 Sep 2006, Petr Baudis wrote:
>> This is actually exactly how SVN revision numbering works. There's just
>> a single number (no '1.') and it indeed jumps randomly if you have
>> several concurrent branches in your (ok, Linus does not have any, just
>> someone's) repository.
>
> Oh, ok, if it's just a single numbering, then that's easy to do. It won't
> _mean_ anything, and you're seriously screwed if you ever merge anything
> else (or use a git that doesn't update the refcache or whatever), but it
> is simple and stable within a single repo.
Well, what it means is "this is the order in which commits were applied to
this repository". I suggest that this information is useful for the most
common development style - the kind which relies on a central repository
as the canonical source for a project's code. "gcc-trunk-r117064" means a
lot more to me than "39282037d7cc39829f1d56bf8307b8e5430d585f", and is no
less precise.
I do believe that distributed VCSs such as Git can improve the
productivity of these kinds of projects without forcing the developers to
suddenly and dramatically alter their workflow. I think ICNs would help
make this possible.
- Joel
^ permalink raw reply
* [PATCH] gitweb: Fix @git_base_url_list usage
From: Petr Baudis @ 2006-09-20 0:09 UTC (permalink / raw)
To: git
As it is now, that array was never used because the customurl accessor was
broken and ''unless @url_list'' never happenned.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
gitweb/gitweb.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 2d0d56f..1b029ac 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -731,7 +731,7 @@ sub git_get_project_description {
sub git_get_project_url_list {
my $path = shift;
- open my $fd, "$projectroot/$path/cloneurl" or return undef;
+ open my $fd, "$projectroot/$path/cloneurl" or return wantarray ? () : undef;
my @git_project_url_list = map { chomp; $_ } <$fd>;
close $fd;
^ permalink raw reply related
* Re: Subversion-style incrementing revision numbers
From: Jakub Narebski @ 2006-09-20 0:15 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.62.0609191709160.9752@joeldicepc.ecovate.com>
Joel Dice wrote:
> On Tue, 19 Sep 2006, Linus Torvalds wrote:
>> On Wed, 20 Sep 2006, Petr Baudis wrote:
>>> This is actually exactly how SVN revision numbering works. There's just
>>> a single number (no '1.') and it indeed jumps randomly if you have
>>> several concurrent branches in your (ok, Linus does not have any, just
>>> someone's) repository.
>>
>> Oh, ok, if it's just a single numbering, then that's easy to do. It won't
>> _mean_ anything, and you're seriously screwed if you ever merge anything
>> else (or use a git that doesn't update the refcache or whatever), but it
>> is simple and stable within a single repo.
>
> Well, what it means is "this is the order in which commits were applied to
> this repository". I suggest that this information is useful for the most
> common development style - the kind which relies on a central repository
> as the canonical source for a project's code. "gcc-trunk-r117064" means a
> lot more to me than "39282037d7cc39829f1d56bf8307b8e5430d585f", and is no
> less precise.
What about "v1.4.2.1-gf7f93e7", or "tags/v1.4.2-rc4^0~19", or just
"39282037"? Or "next@{2006-09-19 22:44:33 +0000}"?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] gitweb: Fix @git_base_url_list usage
From: Junio C Hamano @ 2006-09-20 0:28 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060920000946.GC13132@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> As it is now, that array was never used because the customurl accessor was
> broken and ''unless @url_list'' never happenned.
>
> Signed-off-by: Petr Baudis <pasky@suse.cz>
> ---
>...
> sub git_get_project_url_list {
> my $path = shift;
>
> - open my $fd, "$projectroot/$path/cloneurl" or return undef;
> + open my $fd, "$projectroot/$path/cloneurl" or return wantarray ? () : undef;
> my @git_project_url_list = map { chomp; $_ } <$fd>;
> close $fd;
Why on earth do you want to use wantarray for something like
this?
It's not like you are implementinging any fancy DWIM magic.
Isn't
open my $fd, "foobar" or return;
much easier to read?
#!/usr/bin/perl
sub return_undef {
open my $fd, "no-such-file"
or return wantarray ? () : undef;
}
sub return_broken {
open my $fd, "no-such-file"
or return undef;
}
sub return_empty {
open my $fd, "no-such-file"
or return;
}
my $returned_undef_1 = return_undef();
my ($returned_undef_2) = return_undef();
my @returned_undef = return_undef();
my $returned_broken_1 = return_broken();
my ($returned_broken_2) = return_broken();
my @returned_broken = return_broken();
my $returned_empty_1 = return_empty();
my ($returned_empty_2) = return_empty();
my @returned_empty = return_empty();
printf "U %d B %d E %d\n",
scalar(@returned_undef),
scalar(@returned_broken),
scalar(@returned_empty);
for ($returned_undef_1,
$returned_undef_2,
$returned_broken_1,
$returned_broken_2,
$returned_empty_1,
$returned_empty_2) {
print "What I said was bogus.\n" if (defined $_);
}
^ permalink raw reply
* Re: [PATCH] gitweb: Fix @git_base_url_list usage
From: Junio C Hamano @ 2006-09-20 0:43 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <7v64fjnzyr.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Why on earth do you want to use wantarray for something like
> this?
>
> It's not like you are implementinging any fancy DWIM magic.
Side note. I really hate it when people abuse wantarray.
I can think of only two valid reasons (well, perhaps three but
the last one is a logical consequence of the first two) to use
wantarray. They are:
(1) The information you are giving back the caller is list of
things in nature, but there is a natural representation for
that list as a single scalar, and that representation is
not the last element of the list. You would want to help
the caller by DWIMmery.
Perl's built-in localtime() is an excellent example for
wanting to do something like this. It returns broken-down
"struct tm" in list context, but returns string ctime(3) in
scalar context.
(2) You want to avoid complex computations when the caller does
not need full return values from you. A good example is
found in perlfunc.pod:
return unless defined wantarray; # don't bother doing more
my @a = complex_calculation();
return wantarray ? @a : "@a";
(3) You are emulating Perl's built-in function that DWIMs for
one of the above reasons, usually (1).
^ permalink raw reply
* [ANNOUNCE] Public Gitweb Hosting Service
From: Petr Baudis @ 2006-09-20 0:48 UTC (permalink / raw)
To: git
Hi,
there are various tiny repositories scatterred over the web that are
on crappy broken webhostings, don't have lifetime long enough and most
importantly have no gitweb interface for peeking inside - even e.g.
the StGIT repository suffers from that.
To fix that problem, I've decided to quickly set up a public gitweb
hosting service. The deal is basically that you tell the system your
repository URL (designed only for reasonably small repositories; if you
have big repository, you ought to have the resources to host it) and it
will mirror the repository and provide gitweb interface for it, as well
as publish the mirror for cloning.
It's running at
http://repo.or.cz/
with latest Git and Gitweb from #next and few custom patches (I've
posted the interesting ones), all features enabled. If I get some
time, I will hopefully further improve the Gitweb interface (blame is
almost unusable, pickaxe is top secret functionality, etc.) and I will
generally try to track #next gitweb version closely (at least for the
start).
This is still very experimental - I will watch how much interest, load
and traffic it generates; if it becomes unbearable, I will disable the
public mirror service and keep just the gitweb interface. Also, the web
interface is rather crude and you can currently use it only to register
new projects - if you want to make any adjustments to them, please drop
me a mail. Also please do if you have some cool ideas, or want to do a
nice design for the registration web interface. ;-)
Note that there is also a glibc CVS import available at that address,
entirely coincidentally. That one is an exception and is not synced from
any other Git repository. It took git-cvsimport two days to chew through
on a decent machine (but over the network), the resulting size of 107M
is pretty nice. I hope to set it up to automatically track glibc CVS
further (and possibly other popular non-Git projects later). There's
insane amount of tags which means the gitweb summary page takes "a bit"
long to load, I wonder if using packed refs would improve that.
Have fun,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* Re: [PATCH] gitweb: Fix @git_base_url_list usage
From: Petr Baudis @ 2006-09-20 0:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v64fjnzyr.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Wed, Sep 20, 2006 at 02:28:28AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Petr Baudis <pasky@suse.cz> writes:
>
> > As it is now, that array was never used because the customurl accessor was
> > broken and ''unless @url_list'' never happenned.
> >
> > Signed-off-by: Petr Baudis <pasky@suse.cz>
> > ---
> >...
> > sub git_get_project_url_list {
> > my $path = shift;
> >
> > - open my $fd, "$projectroot/$path/cloneurl" or return undef;
> > + open my $fd, "$projectroot/$path/cloneurl" or return wantarray ? () : undef;
> > my @git_project_url_list = map { chomp; $_ } <$fd>;
> > close $fd;
>
> Why on earth do you want to use wantarray for something like
> this?
>
> It's not like you are implementinging any fancy DWIM magic.
>
> Isn't
>
> open my $fd, "foobar" or return;
>
> much easier to read?
Sure, that's what I meant, I'm only already a bit tired so I just
mimicked the other return in that sub, sorry.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* Re: [ANNOUNCE] Public Gitweb Hosting Service
From: Jakub Narebski @ 2006-09-20 1:01 UTC (permalink / raw)
To: git
In-Reply-To: <20060920004828.GI8259@pasky.or.cz>
Petr Baudis wrote:
> There's
> insane amount of tags which means the gitweb summary page takes "a bit"
> long to load, I wonder if using packed refs would improve that.
Using git-for-each-ref would certainly improve speed (one fork vs. one per
tag), using packed refs (by the way, can it be limited to tags only?) will
improve speed further (one IO vs. one IO per tag).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH V2] Add virtualization support to git-daemon
From: Jon Loeliger @ 2006-09-20 1:31 UTC (permalink / raw)
To: git
Signed-off-by: Jon Loeliger
---
Avast Matey! [*1*]
Phat loot!
Here be the promised respin o' me patch. We be supportin'
git-daemon virtualization with this one. No more dreaded
hackery for multiple hosts, eh? A flaggon of mead around!
Aye, it's a bloody good start, here, eh?, but she could
sure use some keel-haulin' and testin'!
Cap'n jdl
[*1*] http://talklikeapirate.com/
Documentation/git-daemon.txt | 47 ++++++++++++++++++++++
Makefile | 4 +-
daemon.c | 89 +++++++++++++++++++++++++++++++++++++-----
interpolate.c | 82 +++++++++++++++++++++++++++++++++++++++
interpolate.h | 18 ++++++++
5 files changed, 229 insertions(+), 11 deletions(-)
diff --git a/Documentation/git-daemon.txt b/Documentation/git-daemon.txt
index 741f2c6..87444b4 100644
--- a/Documentation/git-daemon.txt
+++ b/Documentation/git-daemon.txt
@@ -11,6 +11,7 @@ SYNOPSIS
'git-daemon' [--verbose] [--syslog] [--inetd | --port=n] [--export-all]
[--timeout=n] [--init-timeout=n] [--strict-paths]
[--base-path=path] [--user-path | --user-path=path]
+ [--interpolated-path=pathtemplate]
[--enable=service] [--disable=service]
[--allow-override=service] [--forbid-override=service]
[--reuseaddr] [--detach] [--pid-file=file]
@@ -50,6 +51,12 @@ OPTIONS
'git://example.com/hello.git', `git-daemon` will interpret the path
as '/srv/git/hello.git'.
+--interpolated-path=pathtemplate::
+ To support virtual hosting, an interpolated path template can be
+ used to dynamically construct alternate paths. The template
+ supports %H for the target hostname as supplied by the client,
+ and %D for the absolute path of the named repository.
+
--export-all::
Allow pulling from all directories that look like GIT repositories
(have the 'objects' and 'refs' subdirectories), even if they
@@ -135,6 +142,46 @@ upload-pack::
disable it by setting `daemon.uploadpack` configuration
item to `false`.
+EXAMPLES
+--------
+git-daemon as inetd server::
+ To set up `git-daemon` as an inetd service that handles any
+ repository under the whitelisted set of directories, /pub/foo
+ and /pub/bar, place an entry like the following into
+ /etc/inetd all on one line:
++
+------------------------------------------------
+ git stream tcp nowait nobody /usr/bin/git-daemon
+ git-daemon --inetd --verbose
+ --syslog --export-all
+ /pub/foo /pub/bar
+------------------------------------------------
+
+
+git-daemon as inetd server for virtual hosts::
+ To set up `git-daemon` as an inetd service that handles
+ repositories for different virtual hosts, `www.example.com`
+ and `www.example.org`, place an entry like the following into
+ `/etc/inetd` all on one line:
++
+------------------------------------------------
+ git stream tcp nowait nobody /usr/bin/git-daemon
+ git-daemon --inetd --verbose
+ --syslog --export-all
+ --interpolated-path=/pub/%H%D
+ /pub/www.example.org/software
+ /pub/www.example.com/software
+ /software
+------------------------------------------------
++
+In this example, the root-level directory `/pub` will contain
+a subdirectory for each virtual host name supported.
+Further, both hosts advertise repositories simply as
+`git://www.example.com/software/repo.git`. For pre-1.4.0
+clients, a symlink from `/software` into the appropriate
+default repository could be made as well.
+
+
Author
------
Written by Linus Torvalds <torvalds@osdl.org>, YOSHIFUJI Hideaki
diff --git a/Makefile b/Makefile
index 7b3114f..673ba2d 100644
--- a/Makefile
+++ b/Makefile
@@ -244,7 +244,9 @@ DIFF_OBJS = \
LIB_OBJS = \
blob.o commit.o connect.o csum-file.o cache-tree.o base85.o \
- date.o diff-delta.o entry.o exec_cmd.o ident.o lockfile.o \
+ date.o diff-delta.o entry.o exec_cmd.o ident.o \
+ interpolate.o \
+ lockfile.o \
object.o pack-check.o patch-delta.o path.o pkt-line.o \
quote.o read-cache.o refs.o run-command.o dir.o object-refs.o \
server-info.o setup.o sha1_file.o sha1_name.o strbuf.o \
diff --git a/daemon.c b/daemon.c
index b14d808..ef3a955 100644
--- a/daemon.c
+++ b/daemon.c
@@ -12,6 +12,7 @@ #include <grp.h>
#include "pkt-line.h"
#include "cache.h"
#include "exec_cmd.h"
+#include "interpolate.h"
static int log_syslog;
static int verbose;
@@ -21,6 +22,7 @@ static const char daemon_usage[] =
"git-daemon [--verbose] [--syslog] [--inetd | --port=n] [--export-all]\n"
" [--timeout=n] [--init-timeout=n] [--strict-paths]\n"
" [--base-path=path] [--user-path | --user-path=path]\n"
+" [--interpolated-path=path]\n"
" [--reuseaddr] [--detach] [--pid-file=file]\n"
" [--[enable|disable|allow-override|forbid-override]=service]\n"
" [--user=user [[--group=group]] [directory...]";
@@ -34,6 +36,10 @@ static int export_all_trees;
/* Take all paths relative to this one if non-NULL */
static char *base_path;
+static char *interpolated_path;
+
+/* Flag indicating client sent extra args. */
+static int saw_extended_args;
/* If defined, ~user notation is allowed and the string is inserted
* after ~user/. E.g. a request to git://host/~alice/frotz would
@@ -45,6 +51,21 @@ static const char *user_path;
static unsigned int timeout;
static unsigned int init_timeout;
+/*
+ * Static table for now. Ugh.
+ * Feel free to make dynamic as needed.
+ */
+#define INTERP_SLOT_HOST (0)
+#define INTERP_SLOT_DIR (1)
+#define INTERP_SLOT_PERCENT (2)
+
+static struct interp interp_table[] = {
+ { "%H", 0},
+ { "%D", 0},
+ { "%%", "%"},
+};
+
+
static void logreport(int priority, const char *err, va_list params)
{
/* We should do a single write so that it is atomic and output
@@ -152,10 +173,14 @@ static int avoid_alias(char *p)
}
}
-static char *path_ok(char *dir)
+static char *path_ok(struct interp *itable)
{
static char rpath[PATH_MAX];
+ static char interp_path[PATH_MAX];
char *path;
+ char *dir;
+
+ dir = itable[INTERP_SLOT_DIR].value;
if (avoid_alias(dir)) {
logerror("'%s': aliased", dir);
@@ -184,16 +209,27 @@ static char *path_ok(char *dir)
dir = rpath;
}
}
+ else if (interpolated_path && saw_extended_args) {
+ if (*dir != '/') {
+ /* Allow only absolute */
+ logerror("'%s': Non-absolute path denied (interpolated-path active)", dir);
+ return NULL;
+ }
+
+ interpolate(interp_path, PATH_MAX, interpolated_path,
+ interp_table, ARRAY_SIZE(interp_table));
+ loginfo("Interpolated dir '%s'", interp_path);
+
+ dir = interp_path;
+ }
else if (base_path) {
if (*dir != '/') {
/* Allow only absolute */
logerror("'%s': Non-absolute path denied (base-path active)", dir);
return NULL;
}
- else {
- snprintf(rpath, PATH_MAX, "%s%s", base_path, dir);
- dir = rpath;
- }
+ snprintf(rpath, PATH_MAX, "%s%s", base_path, dir);
+ dir = rpath;
}
path = enter_repo(dir, strict_paths);
@@ -257,12 +293,14 @@ static int git_daemon_config(const char
return 0;
}
-static int run_service(char *dir, struct daemon_service *service)
+static int run_service(struct interp *itable, struct daemon_service *service)
{
const char *path;
int enabled = service->enabled;
- loginfo("Request %s for '%s'", service->name, dir);
+ loginfo("Request %s for '%s'",
+ service->name,
+ itable[INTERP_SLOT_DIR].value);
if (!enabled && !service->overridable) {
logerror("'%s': service not enabled.", service->name);
@@ -270,7 +308,7 @@ static int run_service(char *dir, struct
return -1;
}
- if (!(path = path_ok(dir)))
+ if (!(path = path_ok(itable)))
return -1;
/*
@@ -351,6 +389,28 @@ static void make_service_overridable(con
die("No such service %s", name);
}
+static void parse_extra_args(char *extra_args, int buflen)
+{
+ char *val;
+ int vallen;
+ char *end = extra_args + buflen;
+
+ while (extra_args < end && *extra_args) {
+ saw_extended_args = 1;
+ if (strncasecmp("host=", extra_args, 5) == 0) {
+ val = extra_args + 5;
+ vallen = strlen(val) + 1;
+ if (*val) {
+ char *save = xmalloc(vallen);
+ interp_table[INTERP_SLOT_HOST].value = save;
+ strlcpy(save, val, vallen);
+ }
+ /* On to the next one */
+ extra_args = val + vallen;
+ }
+ }
+}
+
static int execute(struct sockaddr *addr)
{
static char line[1000];
@@ -391,13 +451,18 @@ #endif
if (len && line[len-1] == '\n')
line[--len] = 0;
+ if (len != pktlen)
+ parse_extra_args(line + len + 1, pktlen - len - 1);
+
for (i = 0; i < ARRAY_SIZE(daemon_service); i++) {
struct daemon_service *s = &(daemon_service[i]);
int namelen = strlen(s->name);
if (!strncmp("git-", line, 4) &&
!strncmp(s->name, line + 4, namelen) &&
- line[namelen + 4] == ' ')
- return run_service(line + namelen + 5, s);
+ line[namelen + 4] == ' ') {
+ interp_table[INTERP_SLOT_DIR].value = line+namelen+5;
+ return run_service(interp_table, s);
+ }
}
logerror("Protocol error: '%s'", line);
@@ -860,6 +925,10 @@ int main(int argc, char **argv)
base_path = arg+12;
continue;
}
+ if (!strncmp(arg, "--interpolated-path=", 20)) {
+ interpolated_path = arg+20;
+ continue;
+ }
if (!strcmp(arg, "--reuseaddr")) {
reuseaddr = 1;
continue;
diff --git a/interpolate.c b/interpolate.c
new file mode 100644
index 0000000..d82f1b5
--- /dev/null
+++ b/interpolate.c
@@ -0,0 +1,82 @@
+/*
+ * Copyright 2006 Jon Loeliger
+ */
+
+#include <string.h>
+
+#include "interpolate.h"
+
+
+/*
+ * Convert a NUL-terminated string in buffer orig
+ * into the supplied buffer, result, whose length is reslen,
+ * performing substitutions on %-named sub-strings from
+ * the table, interps, with ninterps entries.
+ *
+ * Example interps:
+ * {
+ * { "%H", "example.org"},
+ * { "%port", "123"},
+ * { "%%", "%"},
+ * }
+ *
+ * Returns 1 on a successful substitution pass that fits in result,
+ * Returns 0 on a failed or overflowing substitution pass.
+ */
+
+int interpolate(char *result, int reslen,
+ char *orig,
+ struct interp *interps, int ninterps)
+{
+ char *src = orig;
+ char *dest = result;
+ int newlen = 0;
+ char *name, *value;
+ int namelen, valuelen;
+ int i;
+ char c;
+
+ memset(result, 0, reslen);
+
+ while ((c = *src) && newlen < reslen - 1) {
+ if (c == '%') {
+ /* Try to match an interpolation string. */
+ for (i = 0; i < ninterps; i++) {
+ name = interps[i].name;
+ namelen = strlen(name);
+ if (strncmp(src, name, namelen) == 0) {
+ break;
+ }
+ }
+
+ /* Check for valid interpolation. */
+ if (i < ninterps) {
+ value = interps[i].value;
+ valuelen = strlen(value);
+
+ if (newlen + valuelen < reslen - 1) {
+ /* Substitute. */
+ strncpy(dest, value, valuelen);
+ newlen += valuelen;
+ dest += valuelen;
+ src += namelen;
+ } else {
+ /* Something's not fitting. */
+ return 0;
+ }
+
+ } else {
+ /* Skip bogus interpolation. */
+ *dest++ = *src++;
+ newlen++;
+ }
+
+ } else {
+ /* Straight copy one non-interpolation character. */
+ *dest++ = *src++;
+ newlen++;
+ }
+ }
+
+ return newlen < reslen - 1;
+}
diff --git a/interpolate.h b/interpolate.h
new file mode 100644
index 0000000..00c63a5
--- /dev/null
+++ b/interpolate.h
@@ -0,0 +1,18 @@
+/*
+ * Copyright 2006 Jon Loeliger
+ */
+
+#ifndef INTERPOLATE_H
+#define INTERPOLATE_H
+
+
+struct interp {
+ char *name;
+ char *value;
+};
+
+extern int interpolate(char *result, int reslen,
+ char *orig,
+ struct interp *interps, int ninterps);
+
+#endif /* INTERPOLATE_H */
^ permalink raw reply related
* Re: [PATCH] Remove branch by putting a null sha1 into the ref file.
From: Christian Couder @ 2006-09-20 2:56 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio Hamano, git
In-Reply-To: <Pine.LNX.4.64.0609180926590.4388@g5.osdl.org>
Linus Torvalds wrote:
> On Mon, 18 Sep 2006, Christian Couder wrote:
> > With the new packed ref file format from Linus, this should be
> > the new way to remove a branch.
>
> Well, it's not really sufficient.
>
> Somebody should add this test-case
>
> git branch test
> git branch -d test
> git branch test/first
>
> which should work.
>
> It's entirely possible that the proper way to do branch deletion with
> packed branches is to simply re-pack without the old branch, rather than
> the negative branch model.
Yes, and anyway git-branch should probably use some other git command for
this, like "git-update-ref <ref> 0" or "git-update-ref --delete <ref>".
> I couldn't really decide.
>
> However: this part is definitely correct, considering that we allow the
> null sha1 in other places.
>
> > "refs.c" is fixed so that a null sha1 for a deleted branch does
> > not result in "refs/head/deleted does not point to a valid
> > commit object!" messages.
Well, it was in one of your patch already but I had not seen it. And I
wrongly assumed that your patches were all merged into next but this one
was not.
> And this last part is conceptually ok, but I think the implementaion is
> wrong:
> > "t/t3200-branch.sh" is fixed so that it uses git-show-ref
> > instead of checking that the ref does not exist when a branch
> > is deleted.
>
> I think you should change the
>
> ! git-show-ref --verify --quiet -- "refs/heads/d/e/f" &&
>
> into
>
> git-show-ref --verify --quiet -- "refs/heads/d/e/f" ||
>
> instead, no?
It seems Junio found it ok, and I still think it is ok, but my description
of the change is bad.
Maybe git-show-ref should have an option to check that a ref does not exist
for example "git-show-ref --inexistant --quiet -- "refs/heads/d/e/f".
Thanks for your comments.
Christian.
^ permalink raw reply
* Re: [ANNOUNCE] Public Gitweb Hosting Service
From: Linus Torvalds @ 2006-09-20 3:35 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060920004828.GI8259@pasky.or.cz>
On Wed, 20 Sep 2006, Petr Baudis wrote:
>
> It's running at
>
> http://repo.or.cz/
Well, "running" may be putting it a bit strongly.
When I click "summary" for the glibc-cvs.git tree, I get just a
<div class="title"> </div>
-------------------^
thing back.
Broken gitweb?
Linus
^ 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