* Re: [RFC/PATCH 0/3] Enable in-process submodule traversal
From: Junio C Hamano @ 2009-01-12 2:07 UTC (permalink / raw)
To: Lars Hjemli; +Cc: git
In-Reply-To: <1231717555-10559-1-git-send-email-hjemli@gmail.com>
Sounds interesting except 1/3 didn't seem to reach the list...
^ permalink raw reply
* Re: [RFC PATCH 2/3] Add specification of git-vcs helpers
From: Daniel Barkalow @ 2009-01-12 2:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk591mhwj.fsf@gitster.siamese.dyndns.org>
On Sun, 11 Jan 2009, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > So far, I've actually used list and import; I've also implemented an
> > export, but haven't figured out exactly how the user should cause it to be
> > used.
> > ...
> > +'capabilities'::
> > + Prints the capabilities of the helper, one per line. These are:
> > + - import: the basic import command
> > + - marks: import should be done with a saved marks file
> > + - find-new-branches: detect new branches
> > + - export: the general export command
> > + - fork: create a new branch and export to it
> > + - anonymous-fork: make commits on a branch without an inherent name
> > + - merge: merge branches (of whatever type the system supports)
> > +
> > + If the helper doesn't support "merge", the default for pull is
> > + to rebase instead of merging.
>
> Have you tried formatting this to both html and man? I think you need to
> dedent the second paragraph, and have '+' as the sole character on a line
> immediately before, without any blank lines. The formatted output of the
> description of 'export' is probably more troublesome as it is much longer.
Nope, I've just been referring to it in the original text, so I've been
careless with markup.
> This list feels like overengineered yet without enough thinking behind it.
Yeah, I haven't really nailed this one down; it's hard to get really right
without having a bunch of different helpers which can do different amounts
of stuff and need different git-side help.
> Your 'list' allows to list what can become branches on the git end, so as
> long as you have tracking information on the git side, find-new-branches
> seems unnecessary, for examle.
I was unclear about what that one meant, I guess. It's supposed to handle
systems where it's possible to create things that work like branches but
are hard to find. If a helper doesn't report the capability, then the user
may need to say, "I also want some/branch/location", or the helper
wouldn't know that's a branch.
For example, in order to find all of the branches in Perforce, you have
to figure out both directions of integration, in order to find branches
that haven't been integrated back into the location you know about, and
that's kind of expensive to determine and a bit tricky to parse.
It's not intended to indicate that the helper will tell you which ones are
new or not, just that, if the helper doesn't have it, it will only tell
you about branches that it's been told about.
> What does 'merge' mean? It cannot mean to fetch their changes from
> foreign vcs and create a merge locally (you only need import from the
> backend, and merge will be a usual git merge). Perhaps you meant if you
> can export a merge back? Some foreign systems may support importing
> merges but not octopus, so it may not be just a black-or-white boolean.
If the helper supports "merge", it means that it is able to create a merge
in the foreign vcs. You're right about needing to separately list an
"octopus" capability, and maybe further refinements.
> Also "the default is to rebase instead of merge" is probably too weak.
> You would want to error out if the user tried to merge, wouldn't you?
I think users should be able to create merges in git if they want to, but
they'd have to linearize the history in order to push it back. Hopefully,
at some point, we'll have a tool to help with this (which would be helpful
for generating patch series, anyway).
> > +'list'::
> > + Takes the remote name, and outputs the names of refs. These
> > + may be followed, after a single space, by "changed" or
> > + "unchanged", indicating whether the foreign repository has
> > + changed from the state in the ref. If the helper doesn't know,
> > + it doesn't have to provide a value. (In particular, it
> > + shouldn't do expensive operations, such as importing the
> > + content, to see whether it matches.)
>
> I am guessing by 'a value' you mean 'changed/unchanged', iow you are not
> saying if the helper does not know it can omit such refs from the list,
> but it is unclear.
Yeah, that's what I meant.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2009, #02; Sun, 11)
From: Marcel Koeppen @ 2009-01-12 1:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v63kmtbk6.fsf@gitster.siamese.dyndns.org>
Hi,
Am 11.01.2009 um 10:51 schrieb Junio C Hamano:
> ----------------------------------------------------------------
> [Will merge to "master" soon]
> * mc/cd-p-pwd (Tue Dec 30 07:10:24 2008 -0800) 1 commit
> + git-sh-setup: Fix scripts whose PWD is a symlink to a work-dir on
> OS X
I think this belongs into maint - without it the testsuite fails on OSX.
Marcel
^ permalink raw reply
* [RFC/PATCH 1/3] tree.c: add support for traversal of submodules
From: Lars Hjemli @ 2009-01-11 23:45 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <1231717555-10559-1-git-send-email-hjemli@gmail.com>
If the commit referenced by a gitlink is available in the (possibly
alternate) object database, read_tree_recursive() is now able to descend
into the tree of the linked commit if the flag 'traverse_gitlinks' is
turned on.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---
tree.c | 20 +++++++++++++++++---
tree.h | 1 +
2 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/tree.c b/tree.c
index 03e782a..1468e10 100644
--- a/tree.c
+++ b/tree.c
@@ -7,6 +7,7 @@
#include "tree-walk.h"
const char *tree_type = "tree";
+int traverse_gitlinks = 0;
static int read_one_entry_opt(const unsigned char *sha1, const char *base, int baselen, const char *pathname, unsigned mode, int stage, int opt)
{
@@ -114,16 +115,29 @@ int read_tree_recursive(struct tree *tree,
default:
return -1;
}
- if (S_ISDIR(entry.mode)) {
+ if (S_ISDIR(entry.mode) || (traverse_gitlinks && S_ISGITLINK(entry.mode))) {
int retval;
char *newbase;
unsigned int pathlen = tree_entry_len(entry.path, entry.sha1);
-
+ struct commit *commit;
+ struct tree *node;
+
+ if (S_ISDIR(entry.mode)) {
+ node = lookup_tree(entry.sha1);
+ } else {
+ commit = lookup_commit_reference_gently(entry.sha1, 1);
+ if (!commit)
+ continue;
+ if (parse_commit(commit))
+ die("parse_commit(%s) failed",
+ sha1_to_hex(entry.sha1));
+ node = commit->tree;
+ }
newbase = xmalloc(baselen + 1 + pathlen);
memcpy(newbase, base, baselen);
memcpy(newbase + baselen, entry.path, pathlen);
newbase[baselen + pathlen] = '/';
- retval = read_tree_recursive(lookup_tree(entry.sha1),
+ retval = read_tree_recursive(node,
newbase,
baselen + pathlen + 1,
stage, match, fn, context);
diff --git a/tree.h b/tree.h
index 2ff01a4..b6b938f 100644
--- a/tree.h
+++ b/tree.h
@@ -4,6 +4,7 @@
#include "object.h"
extern const char *tree_type;
+extern int traverse_gitlinks;
struct tree {
struct object object;
--
1.6.1.81.g1df1.dirty
^ permalink raw reply related
* What's in my gitweb StGit queue (12 Jan 2009)
From: Jakub Narebski @ 2009-01-12 1:52 UTC (permalink / raw)
To: git
Starting from the bottom of the stack; all but first two are
unapplied, and might not apply without conflicts.
I wrote it down among others to get comments which features would you
like to see first. If you plan on working on some feature listed here
yourself, ask and I can send a patch as it is now.
* gitweb: Document that gitweb deals with bare repositories
This was sent to git mailing list with the comment that I could not
find best way of phrasing it. But I think it is worth applying,
anyway. But on the other hand side it can wait, too.
* gitweb: Incremental blame (proof of concept)
This patch was sent to git mailing list as an RFC. It is resend
(with some corrections and additions) of patch by Petr Baudis, which
in turn was tweaked up version of Fredrik Kuivinen. I think it
should be split into three or four patches:
- gitweb: Add optional "Generated in ..." info to footer
- gitweb: Incremental blame
- gitweb: Colorize output during incremental blame
- gitweb: Use incremental blame if JavaScript is enabled
* gitweb: Fix nested links problem with ref markers (WIP)
This is currently more of notification of a bug, than a feature.
The problem is that some browsers in strict mode actively forbid
nested links (which is not allowed according to (X)HTML standard),
and they move inner link to just outside outer link element,
breaking layout in the case of page header for 'commit' action and
other views.
I have just send email about this issue.
* gitweb: Separate features with no project specific override
Currently both per-project features like 'snapshots' (which can be
configured to be overridable by project repository config), and
global features like 'search' or 'forks' (which does not support
project specific overrides) are both put in %feature hash.
* gitweb: Extend project_index file format by project description
Change format of $projects_list file by making it possible to add
optional project description, and make 'project_index' output new
format, with description. This is to have all project info for
project list page in one place.
* gitweb: open files (e.g. indextext.html) in utf8 mode
TO BE DELETED. I think it was (independently?) sent and accepted
already.
* gitweb: Project search
TO BE DELETED. There is implementation by Pasky in gitweb already.
* gitweb: Paginate project list
This patch was sent to git mailing list together with the one above
in one series, but now it will probably conflict due to the changes
in the area. It was perhaps a bit overcomplicated because of trying
to calculate only _minimal_ set of information needed for sorting
(or searching) for all projects, and filling all info only for
_displayed_ projects.
Probably would have to be preceded by patch which makes selection of
what is displayed (searching projects, selecting tags, hiding forks)
be explicit and not happen at display time. Otherwise we will have
less items per page than it should be.
* gitweb: Remove commit title from comitdiff_plain body
This name is not entirely correct, as this commit is about making
commitdiff_plain view to look more like "git show --format=email".
It is a bit obsoleted by 'patch' view (in cooking); further
discussion is required about this patch, for example if
commitdiff_plain view should perhaps be dropped.
* gitweb: Uniquify usage of subroutine prototypes
Truth to be told this patch is mainly because imenu support for
CPerl mode in GNU Emacs trips from time to time on
"sub S_ISGITLINK($) {"
* gitweb: Redirect to appropriate view if 'a=' parameter is missing
* gitweb: Simplify object type detection in git_object()
* gitweb: Make 'object' action implicit by using no action URL
This series of patches is about the fact that gitweb currently has
two ways of filling 'action' parameter: one if it is missing by just
deciding based on type of object what to put in $action, without
changing URL; and the one used for generic 'object' view when we do
full HTTP redurection (and change URL). Those patches try to unify
this area a bit.
* gitweb: Use list form of 'open "-|"' pipeline
Gitweb uses list form of open, which has the double advantage of not
invoking shell (one fork less) and not having to shell escape
parameters... with the exception of a few places where output of git
command has to be filtered (pipelined) to other command. Currently
only snapshot uses that (to compress tarball from git-archive); in
the future syntax highlighting would also use the same mechanism.
This patch is very much work in progress / research in motion.
* gitweb: Try harder in parse_tag; perhaps it was given ambiguous name
This is companion to the patch which is already in gitweb making git
use full ref names, i.e. 'refs/tags/v1.6.0', and not 'v1.6.0' for
h/hb. Well, companion in the sense that it does the other side of
this issue: whet to do if we have ambiguous refs, and not generating
always unambiguous refs. The problem is with "git cat-file tag <ref>",
when <ref> is both tag and non-tag ref... but perhaps this should be
resolved in-core.
* gitweb: Change division of gitweb pages into parts
* gitweb: CSS cleanup (WIP)
This patch series tries to uniquify page division, and simplify CSS
for gitweb to not have to repeat rules, to not have to use class to
not break layout, etc.
* gitweb: Try to sanitize mimetype for 'blob_plain' view
Defensive programming: use 'text/plain' for files which are text and
can be viewed in a browser, and are not among a few 'text/*' mimetypes
universally recognized by web browsers (e.g. 'application/x-perl'
should be shown as 'text/plain'). Alternate solution would be to
use own mime.types (gitweb has configuration option for this).
* gitweb: Add an option to show size of blobs in the tree view
This probably has to be a %feature bacause of performance impact:
make use of the fact that 'git ls-tree -l' can show sizes of blobs.
Thsi feature is inspired by cgit.
* gitweb: Enable transparent compression for HTTP output
IIRC the consensus was that it usually doesn't make sense to use it,
but perhaps with caching... Is %feature. Requires quite modern Perl
with PerlIO::gzip, but fallback on no-compression if it does not
exists.
--
Jakub Narebski
Poland
^ permalink raw reply
* Help! My ISP blocks repo.or.cz. How to push changes?
From: Jakub Narebski @ 2009-01-12 1:46 UTC (permalink / raw)
To: git; +Cc: Petr Baudis
The ISP I use (Telekomunikacja Polska S.A., aka TP) made some
unannounced changes for ADSL service (Neostrada) which made it block
repo.or.cz (and of course its aliases, including git.or.cz where git
wiki resides). It blocks also gimp.org and some Polish IRC servers
(irc.freenode.org on which #git resides works O.K.). People speculate
that this blocking was based on MAPS (Mail Abuse Prevention System,
which is SPAM backwards) lists to fight SPAM and/or to block botnets,
and uses null routing (IP based) blocking. I have no idea why repo.or.cz
is blocked: gimp.org is supposedly blocked because it hosts
irc.gimp.org on the same IP. By block I mean that even ping doesn't
work (no reply at all).
I can access git wiki via one of many free HTTP proxies; currently I use
http://www.4proxy.de so there are only slight problems there.
The problems is with fetching (via git:// protocol) of forks of git
repository on repo.or.cz, and pushing (via SSH) to a few of my git
repositories hosted on repo.or.cz.
Do you have any suggestions to bypass this block for git? I have access
to Linux shell account (no root access, though) which doesn't have
problems with repo.or.cz, so I think I could set up SSH tunnel: but
how? And what to do with access via git:// - move to SSH too?
Thanks in advance
--
Jakub Narebski
Poland
http://forums.thedailywtf.com/forums/t/10789.aspx
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2009, #02; Sun, 11)
From: Junio C Hamano @ 2009-01-12 1:41 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Sebastien Cevey, Giuseppe Bilotta
In-Reply-To: <200901120225.30175.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> On Sun, 11 Jan 2009, Junio C Hamano wrote:
>> Jakub Narebski <jnareb@gmail.com> writes:
>> These should be moved to the Stalled category; nobody seems to be
>> discussing improvements and sending updates to the series as far as I
>> recall.
>
> I think it is just the author being slow moving; there was quite
> a bit of time between subsequent versions of this patch series.
Oh, being slow is fine and "Stalled" is exactly that.
> But if Sebastien would not resend this series in about a week,
> I'll try to clean it up, add fourth patch, and resend it.
Thanks.
^ permalink raw reply
* Re: [RFC PATCH 3/3] Support fetching from foreign VCSes
From: Junio C Hamano @ 2009-01-12 1:33 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <alpine.LNX.1.00.0901110335520.19665@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> This supports a useful subset of the usual fetch logic, mostly in the
> config file.
>
> Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
I like the direction this series is going. In the longer term, it would
be nice if we can have git-svn and git-cvsimport replaced with something
like this.
Is the current foreign vcs interface sufficiently rich to support git as a
foreign scm by using fast-import and fast-export?
Thanks.
^ permalink raw reply
* Re: [RFC PATCH 1/3] Add "vcs" config option in remotes
From: Daniel Barkalow @ 2009-01-12 1:32 UTC (permalink / raw)
To: Ping Yin; +Cc: git, Junio C Hamano
In-Reply-To: <46dff0320901111729y3869db2bxcc2b66a7be247d0b@mail.gmail.com>
On Mon, 12 Jan 2009, Ping Yin wrote:
> On Mon, Jan 12, 2009 at 4:12 AM, Daniel Barkalow <barkalow@iabervon.org> wrote:
> > This will indicate to programs using the remote that it should be
> > accessed through a VCS helper. Until programs support it, have them
> > fail it the option is set.
>
> s/it/if/ ?
Yes. It was pretty late last night when I wrote the commit messages.
-Daniel
^ permalink raw reply
* Re: [RFC PATCH 2/3] Add specification of git-vcs helpers
From: Junio C Hamano @ 2009-01-12 1:29 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <alpine.LNX.1.00.0901110334350.19665@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> So far, I've actually used list and import; I've also implemented an
> export, but haven't figured out exactly how the user should cause it to be
> used.
> ...
> +'capabilities'::
> + Prints the capabilities of the helper, one per line. These are:
> + - import: the basic import command
> + - marks: import should be done with a saved marks file
> + - find-new-branches: detect new branches
> + - export: the general export command
> + - fork: create a new branch and export to it
> + - anonymous-fork: make commits on a branch without an inherent name
> + - merge: merge branches (of whatever type the system supports)
> +
> + If the helper doesn't support "merge", the default for pull is
> + to rebase instead of merging.
Have you tried formatting this to both html and man? I think you need to
dedent the second paragraph, and have '+' as the sole character on a line
immediately before, without any blank lines. The formatted output of the
description of 'export' is probably more troublesome as it is much longer.
This list feels like overengineered yet without enough thinking behind it.
Your 'list' allows to list what can become branches on the git end, so as
long as you have tracking information on the git side, find-new-branches
seems unnecessary, for examle. Worse, find-new-branches needs its own
tracking mechansim anyway, but that means how the namespace for remote
tracking branches is managed is left to the vcs backends, even though that
namespace is directly visiblt to git --- my gut feeling is that it would
probably better to arrange things similar to what git native transport
does already. 'list' would say "The remote has what can become refs on
the git end and calls them A, B, C", and the built-in code, using ref
mapping specification, maps them to refs/remotes/somename/{A,B,C}. You do
it again and if you see the remote has D but does not have B anymore, you
know D is a new branch and B was deleted.
What does 'merge' mean? It cannot mean to fetch their changes from
foreign vcs and create a merge locally (you only need import from the
backend, and merge will be a usual git merge). Perhaps you meant if you
can export a merge back? Some foreign systems may support importing
merges but not octopus, so it may not be just a black-or-white boolean.
Also "the default is to rebase instead of merge" is probably too weak.
You would want to error out if the user tried to merge, wouldn't you?
> +'list'::
> + Takes the remote name, and outputs the names of refs. These
> + may be followed, after a single space, by "changed" or
> + "unchanged", indicating whether the foreign repository has
> + changed from the state in the ref. If the helper doesn't know,
> + it doesn't have to provide a value. (In particular, it
> + shouldn't do expensive operations, such as importing the
> + content, to see whether it matches.)
I am guessing by 'a value' you mean 'changed/unchanged', iow you are not
saying if the helper does not know it can omit such refs from the list,
but it is unclear.
^ permalink raw reply
* Re: [RFC PATCH 1/3] Add "vcs" config option in remotes
From: Ping Yin @ 2009-01-12 1:29 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git, Junio C Hamano
In-Reply-To: <alpine.LNX.1.00.0901110332580.19665@iabervon.org>
On Mon, Jan 12, 2009 at 4:12 AM, Daniel Barkalow <barkalow@iabervon.org> wrote:
> This will indicate to programs using the remote that it should be
> accessed through a VCS helper. Until programs support it, have them
> fail it the option is set.
s/it/if/ ?
^ permalink raw reply
* Re: [PATCH v2 1/4] Add color_fwrite(), a function coloring each line individually
From: Jakub Narebski @ 2009-01-12 1:27 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.DEB.1.00.0901120049190.3586@pacific.mpi-cbg.de>
Johannes Schindelin wrote:
> We have to set the color before every line and reset it before every
> newline. Add a function color_fwrite() which does that for us.
color_fwrite_lines(), but I guess Junio can correct this himself.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2009, #02; Sun, 11)
From: Jakub Narebski @ 2009-01-12 1:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Sebastien Cevey, Giuseppe Bilotta
In-Reply-To: <7vwsd1pjst.fsf@gitster.siamese.dyndns.org>
On Sun, 11 Jan 2009, Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>>> ----------------------------------------------------------------
>>> [Actively cooking]
>>>
>>> * sc/gitweb-category (Fri Dec 12 00:45:12 2008 +0100) 3 commits
>>> - gitweb: Optional grouping of projects by category
>>> - gitweb: Split git_project_list_body in two functions
>>> - gitweb: Modularized git_get_project_description to be more generic
>>
>> This I think needs some further cooking. I guess with addition of one
>> more patch to series categories could be sorted together with projects
>> they contain, and not always have to be in fixed ordering.
>
> These should be moved to the Stalled category; nobody seems to be
> discussing improvements and sending updates to the series as far as I
> recall.
I think it is just the author being slow moving; there was quite
a bit of time between subsequent versions of this patch series.
But if Sebastien would not resend this series in about a week,
I'll try to clean it up, add fourth patch, and resend it.
As to lack of discussion: I think it is cause bu two issues. First,
there is support for tags already implemented which somewhat reduces
need for categories support. Second, hosting sites which have large
number of projects for which categories support might be a nice thing,
use I guess modified gitweb with caching, don't they?
>>> * gb/gitweb-patch (Thu Dec 18 08:13:19 2008 +0100) 4 commits
>>> - gitweb: link to patch(es) view in commit(diff) and (short)log view
>>> - gitweb: add patches view
>>> - gitweb: change call pattern for git_commitdiff
>>> - gitweb: add patch view
>>
>> If I remember correctly the only point of discussion is calling
>> convention for git_commitdiff, and whether 'patches' view should
>> (re)use git_commitdiff or use its own subroutine.
>
> Thanks; I take it that it is basically usable, useful and can be
> incrementally improved in 'next'?
Yes, I think so. The changes are cosmetic in nature, and I think
the feature this patch adds is quite useful: you can now get patches
and [short] patch series from gitweb which you can apply using git-am.
Nice, isn't it?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Removing a commit from a local branch
From: Sitaram Chamarty @ 2009-01-12 1:20 UTC (permalink / raw)
To: git
In-Reply-To: <a038bef50901111442y16695664y4fed7cdd9d8af27@mail.gmail.com>
On 2009-01-11, Chris Packham <judge.packham@gmail.com> wrote:
> Consider the following example. The maintainer has the
> following branch locally
>
> todeliver: A-B-C-D
>
> He is happy with commits A, C and D but wants to reject B. Ideally I
> want to be able to say
> git rebase --onto <parent of B> <child of B> todelvier
>
> and get
> todeliver: A-C'-D'
you have an off-by-one error here. You need B, not child of
B. Problem solved :-)
^ permalink raw reply
* [BUG/RFH] gitweb: Trouble with ref markers being hyperlinks because of illegally nested links
From: Jakub Narebski @ 2009-01-12 1:15 UTC (permalink / raw)
To: git; +Cc: Giuseppe Bilotta
Commit 4afbaef by Giuseppe Bilotta (gitweb: ref markers link to named
shortlogs) turned ref markers for tags and heads into links to
appropriate views for the ref name.
Unfortunately the code didn't take into account the fact that nesting
links (A elements) is illegal in (X)HTML:
12.2.2 Nested links are illegal
Links and anchors defined by the A element must not be nested;
an A element must not contain any other A elements.
(from http://www.w3.org/TR/html401/struct/links.html#h-12.2.2), and that
some browsers (e.g. Mozilla 1.17.2 I still use) in the very strict
conformance mode (application/xhtml+xml mimetype and XML + XHTML DTD)
_enforce_ this requirement by moving inner link immediately outside the
end of outer link, i.e. for the HTML source looking like the following
<a ...> some text <a ...>v1.5.1</a></a>
rendered HTML (which you can see using "View Selection Source") is
instead
<a ...> some text </a><a ...>v1.5.1</a>
And of course SPAN elements which wraps inner link (inner A element) is
_not_ moved.
This is quite easy to fix for hyperlinked ref markers in 'shortlog' and
'history' views: just close the "title" hyperlink before printing
$extra, i.e. ref markers. I have even made a patch doing that. Then
instead of incorrect
_Merge branch into maint_ [] _maint_
where _aaa_ means that 'aaa' is hyperlink, and [xxx] is a fer marker,
we will have correct:
_Merge branch into maint_ [_maint_]
See that we have two separate and not nested links...
What is more complicated is the issue of ref marker from
git_print_header_div e.g. in 'commit'/'commitdiff' view, and in 'log'
view. There link is made into block element using "display: block;"
CSS rule (div.title, a.title), so that you can click _anywhere_ on the
header block. This breaks layout even worse, making hyperlinked ref
marker text appear *below* header div:
-----------------------------------------------------------
|_Merge branch into maint_ [] |
-----------------------------------------------------------
_maint_
To preserve current layout and behavior it would be needed to do some
deep HTML + CSS positioning hackery, perhaps with additional link block
without any text... But I don't know exactly how to do this; all [few]
experiments I did failed.
I see possible the following alternate solutions:
* Ignore this issue (e.g. if it does not affect modern browsers)
* Revert 4afbaef (we lose feature, but how often used is it?)
* Always use quirks mode, or check browser and use quirks mode if it
would break layout
* Use extra divs and links and CSS positioning to make layout which
looks like current one, and behaves as current one, but is more
complicated.
P.S. From what I have checked neither kernel.org nor repo.or.cz
have this issue.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Minimum required version of subversion for git-svn?
From: Eric Wong @ 2009-01-12 1:03 UTC (permalink / raw)
To: Tom G. Christensen; +Cc: git
In-Reply-To: <496722CF.1060802@statsbiblioteket.dk>
"Tom G. Christensen" <tgc@statsbiblioteket.dk> wrote:
> Hello,
>
> With git 1.6.0.5 I was able to run git-svn with subversion 1.1.4 on
> RHEL4/i386 but with 1.6.0.6 and 1.6.1 the testsuite now fails in the new
> test t9104.10:
...
> With 1.6.1 I also see t9129.10-12 failing with subversion 1.1.4:
> * FAIL 10: ISO-8859-1 should match UTF-8 in svn
...
> * failed 3 among 12 test(s)
> make[2]: Leaving directory `/builddir/build/BUILD/git-1.6.1/t'
> make[2]: *** [t9129-git-svn-i18n-commitencoding.sh] Error 1
>
> I see in git-svn.perl that only SVN::Core 1.1.0 is required. Is it still
> the intention that git-svn should work with subversion 1.1.x?
>
> If you're going to bump the minimum requirement I would ask that you
> atleast keep 1.3.x as supported. This is the last release of subversion
> where RHEL3 can satisfy the dependencies out of the box and I've
> verified that the testsuite will pass with 1.3.2.
It's still my intention that SVN 1.1.x is supported; but I haven't had
the chance to test those versions in a while.
Can you rerun the tests that failed with "sh -x t91..." ?
Thanks.
--
Eric Wong
^ permalink raw reply
* Recent annoying problem with Linus's git repository?
From: walt @ 2009-01-12 0:42 UTC (permalink / raw)
To: git
I've been tracking Junio's git.git and Linus's kernel.git for ages,
and just in the last two weeks or so I've been having a recurring
problem with the file "arch/arm/mach-integrator/clock.h" from Linus.
Any time I check out an old kernel version (e.g. during a bisect)
and then do a "checkout master" when I'm done fiddling, git thinks
my repository is "dirty".
This is the reason for my impurity:
# git status
# On branch master
# Changed but not updated:
# (use "git add/rm <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# deleted: arch/arm/mach-integrator/clock.h
It's always that same damned clock.h that remains in my working
directory after doing the "checkout master" but it shouldn't be
there -- it has indeed been deleted from branch master.
When I then do a "git reset --hard" I Am Purified! and no longer
considered dirty. But why should that extra reset step be needed?
Only that one file is involved in this recurring annoyance. Can
anyone figure out why, or at least reproduce the problem?
Thanks!
^ permalink raw reply
* [RFC/PATCH 3/3] builtin-ls-tree: enable traversal of submodules
From: Lars Hjemli @ 2009-01-11 23:45 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <1231717555-10559-3-git-send-email-hjemli@gmail.com>
The option '--submodules', which implies '-r', activates the traversal
of all submodules for which the linked commit is reachable.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---
builtin-ls-tree.c | 23 ++++++++---------------
1 files changed, 8 insertions(+), 15 deletions(-)
diff --git a/builtin-ls-tree.c b/builtin-ls-tree.c
index cb61717..8a1db54 100644
--- a/builtin-ls-tree.c
+++ b/builtin-ls-tree.c
@@ -23,7 +23,7 @@ static int chomp_prefix;
static const char *ls_tree_prefix;
static const char ls_tree_usage[] =
- "git ls-tree [-d] [-r] [-t] [-l] [-z] [--name-only] [--name-status] [--full-name] [--abbrev[=<n>]] <tree-ish> [path...]";
+ "git ls-tree [-d] [-r] [-t] [-l] [-z] [--name-only] [--name-status] [--full-name] [--abbrev[=<n>]] [--submodules] <tree-ish> [path...]";
static int show_recursive(const char *base, int baselen, const char *pathname)
{
@@ -63,20 +63,8 @@ static int show_tree(const unsigned char *sha1, const char *base, int baselen,
unsigned long size;
if (S_ISGITLINK(mode)) {
- /*
- * Maybe we want to have some recursive version here?
- *
- * Something similar to this incomplete example:
- *
- if (show_subprojects(base, baselen, pathname)) {
- struct child_process ls_tree;
-
- ls_tree.dir = base;
- ls_tree.argv = ls-tree;
- start_command(&ls_tree);
- }
- *
- */
+ if (show_recursive(base, baselen, pathname))
+ retval = READ_TREE_RECURSIVE;
type = commit_type;
} else if (S_ISDIR(mode)) {
if (show_recursive(base, baselen, pathname)) {
@@ -168,6 +156,11 @@ int cmd_ls_tree(int argc, const char **argv, const char *prefix)
abbrev = DEFAULT_ABBREV;
break;
}
+ if (!strcmp(argv[1]+2, "submodules")) {
+ ls_options |= LS_RECURSIVE;
+ traverse_gitlinks = 1;
+ break;
+ }
/* otherwise fallthru */
default:
usage(ls_tree_usage);
--
1.6.1.81.g1df1.dirty
^ permalink raw reply related
* [RFC/PATCH 2/3] archive.c: enable traversal of submodules
From: Lars Hjemli @ 2009-01-11 23:45 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <1231717555-10559-2-git-send-email-hjemli@gmail.com>
The option --submodules can be used to activate traversal of sub-
modules when creating archives.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---
archive.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/archive.c b/archive.c
index 9ac455d..973dde4 100644
--- a/archive.c
+++ b/archive.c
@@ -262,6 +262,8 @@ static int parse_archive_args(int argc, const char **argv,
OPT_STRING(0, "format", &format, "fmt", "archive format"),
OPT_STRING(0, "prefix", &base, "prefix",
"prepend prefix to each pathname in the archive"),
+ OPT_BOOLEAN(0, "submodules", &traverse_gitlinks,
+ "include reacheable submodules"),
OPT__VERBOSE(&verbose),
OPT__COMPR('0', &compression_level, "store only", 0),
OPT__COMPR('1', &compression_level, "compress faster", 1),
--
1.6.1.81.g1df1.dirty
^ permalink raw reply related
* Re: Removing a commit from a local branch
From: Chris Packham @ 2009-01-12 0:12 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: git
In-Reply-To: <20090111225220.GB15533@atjola.homenet>
Thanks thats exactly what I was after.
On Mon, Jan 12, 2009 at 11:52 AM, Björn Steinbrink <B.Steinbrink@gmx.de> wrote:
> On 2009.01.12 11:42:24 +1300, Chris Packham wrote:
>> Hi List,
>>
>> I'm part of a development team using git. We use a maintainer model
>> where developers send patches/pull requests to a maintainer who
>> applies the patches to a local branch, decides if they're good or not
>> and pushes the good patches to the public repository.
>>
>> What I want to do is script the removal of a bad patch so that the
>> maintainer identifies a patch in his local branch, sends an email to
>> the author telling them why their patch is being rejected then removes
>> the commit for that patch. Using git log a script can extract the
>> author email address, hash and headline of each commit. Based on that
>> information scripting the email is easy enough. Now I come to using
>> git rebase to remove the bad commit based on its hash which leads me
>> to my question - How do I refer to a commit based on the hash of its
>> parent?
>>
>> Consider the following example. The maintainer has the following branch locally
>>
>> todeliver: A-B-C-D
>>
>> He is happy with commits A, C and D but wants to reject B. Ideally I
>> want to be able to say
>> git rebase --onto <parent of B> <child of B> todelvier
>
> You don't want <child of B> there, just B.
>
> git rebase --onto <onto> <upstream> <branch>
>
> Rebases the commits from the range <upstream>..<branch>, and that
> _excludes_ the commit (referenced by) <upstream>.
>
> So:
> git rebase --onto B^ B todeliver
>
> Works on: B..todeliver == todeliver --not B
> And that range contains commits C and D.
>
> Björn
>
^ permalink raw reply
* [RFC/PATCH 0/3] Enable in-process submodule traversal
From: Lars Hjemli @ 2009-01-11 23:45 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
This patch series implements basic support for traversing the tree objects
in submodules when the linked commit object is reachable. Normally such
linked commit objects will not be reachable in the containing repository,
but adding local copies of submodule repositories as alternate object
databases for the containing repo solves this issue.
The first patch in the series does all the 'hard work' required for the
traversal to work, while the next two patches adds a '--submodules' flag
to git-archive and git-ls-tree as proof of concept.
Lars Hjemli (3):
tree.c: add support for traversal of submodules
archive.c: enable traversal of submodules
builtin-ls-tree: enable traversal of submodules
archive.c | 2 ++
builtin-ls-tree.c | 23 ++++++++---------------
tree.c | 20 +++++++++++++++++---
tree.h | 1 +
4 files changed, 28 insertions(+), 18 deletions(-)
^ permalink raw reply
* Re: git-svn: File was not found in commit
From: Morgan Christiansson @ 2009-01-12 0:04 UTC (permalink / raw)
To: git
In-Reply-To: <20090111215526.GA15533@atjola.homenet>
Björn Steinbrink wrote:
> On 2009.01.09 18:19:01 +0100, Morgan Christiansson wrote:
>
>> ------------------------------------------------------------------------
>> r10577 | morgan | 2008-11-28 18:31:00 +0000 (Fri, 28 Nov 2008) | 3 lines
>> Changed paths:
>> A /branches/rails/rails/vendor/plugins/acts_as_xapian/.git/FETCH_HEAD
>> M /branches/rails/rails/vendor/plugins/acts_as_xapian/.git/config
>> M /branches/rails/rails/vendor/plugins/acts_as_xapian/.git/index
>> M /branches/rails/rails/vendor/plugins/acts_as_xapian/.git/logs/HEAD
>> M /branches/rails/rails/vendor/plugins/acts_as_xapian/.git/logs/refs/heads/master
>> # -- THIS FILE --
>>
> Unless I totally misread that line, SVN reports that the file was
> _modified_, not added. For the file to be modified, it seems reasonable
> to expect that it existed in the previous commit.
>
> Is there anything "special" about how that file came into existence in
> that branch? Without further knowledge, that looks like a svn bug, but
> hey, it's svn, it might do funny stuff on purpose ;-)
>
> Maybe you could provide a small test case/repo?
>
> Björn
>
Something odd happened when "git svn fetch" was adding r10559 to git:
A rails/vendor/plugins/acts_as_xapian/README.txt
A rails/vendor/plugins/acts_as_xapian/.cvsignore
Ignoring path rails/vendor/plugins/acts_as_xapian/.git/refs/heads/master
Ignoring path
rails/vendor/plugins/acts_as_xapian/.git/refs/remotes/origin/HEAD
Ignoring path
rails/vendor/plugins/acts_as_xapian/.git/refs/remotes/origin/master
Ignoring path rails/vendor/plugins/acts_as_xapian/.git/HEAD
Ignoring path rails/vendor/plugins/acts_as_xapian/.git/description
Ignoring path rails/vendor/plugins/acts_as_xapian/.git/hooks/update
Ignoring path rails/vendor/plugins/acts_as_xapian/.git/hooks/post-receive
Ignoring path rails/vendor/plugins/acts_as_xapian/.git/hooks/post-update
Ignoring path rails/vendor/plugins/acts_as_xapian/.git/hooks/pre-rebase
Ignoring path
rails/vendor/plugins/acts_as_xapian/.git/hooks/prepare-commit-msg
Ignoring path rails/vendor/plugins/acts_as_xapian/.git/hooks/applypatch-msg
Ignoring path rails/vendor/plugins/acts_as_xapian/.git/hooks/pre-applypatch
Ignoring path rails/vendor/plugins/acts_as_xapian/.git/hooks/post-commit
Ignoring path rails/vendor/plugins/acts_as_xapian/.git/hooks/commit-msg
Ignoring path rails/vendor/plugins/acts_as_xapian/.git/hooks/pre-commit
Ignoring path
rails/vendor/plugins/acts_as_xapian/.git/logs/refs/heads/master
Ignoring path
rails/vendor/plugins/acts_as_xapian/.git/logs/refs/remotes/origin/HEAD
Ignoring path
rails/vendor/plugins/acts_as_xapian/.git/logs/refs/remotes/origin/master
Ignoring path rails/vendor/plugins/acts_as_xapian/.git/logs/HEAD
Ignoring path rails/vendor/plugins/acts_as_xapian/.git/config
Ignoring path rails/vendor/plugins/acts_as_xapian/.git/index
Ignoring path
rails/vendor/plugins/acts_as_xapian/.git/objects/pack/pack-570449ffe8ce399eca81f286cf942e51ace03448.pack
Ignoring path
rails/vendor/plugins/acts_as_xapian/.git/objects/pack/pack-570449ffe8ce399eca81f286cf942e51ace03448.idx
Ignoring path rails/vendor/plugins/acts_as_xapian/.git/info/exclude
W: +empty_dir:
branches/rails/rails/vendor/plugins/acts_as_xapian/.git/branches
W: +empty_dir:
branches/rails/rails/vendor/plugins/acts_as_xapian/.git/objects/info
W: +empty_dir:
branches/rails/rails/vendor/plugins/acts_as_xapian/.git/refs/tags
r10559 = 4f33ee36a5d933a62081a76c7788fb46a9e6f0e8 (rails)
The "Ignoring path" message appears to be coming from git which is
refusing to commit the .git directory. Which leads to git-svn being
unaware of the files being ignored and giving an error when it can't
find them.
#The following commands will create a repository that has this problem:
cd ~
rm -rf gittest*
svnadmin create gittest-repo
svn co file:///$HOME/gittest-repo gittest-checkout
cd gittest-checkout
mkdir -p .git
touch .git/file
svn add .git
svn commit -m "Create .git/file"
echo 1 > .git/file
svn commit -m "Modify .git/file"
# The following will try to import the repository, which fails.
cd ~
mkdir gittest
cd gittest
git svn init file:///$HOME/gittest-repo
git svn fetch
# Output:
$ git svn fetch
A .git/file
Ignoring path .git/file
r1 = ccc56451d54315bd253b65c514351e996fbe880e (git-svn)
.git/file was not found in commit
ccc56451d54315bd253b65c514351e996fbe880e (r1)
# Cleanup
rm -rf gittest gittest-repo gittest-checkout
I'm personally fine with these files being ignored by git, but git-svn
needs to be aware that they are not added to the repository.
^ permalink raw reply
* [PATCH v2 1/4] Add color_fwrite(), a function coloring each line individually
From: Johannes Schindelin @ 2009-01-11 23:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Thomas Rast
In-Reply-To: <alpine.DEB.1.00.0901120048430.3586@pacific.mpi-cbg.de>
We have to set the color before every line and reset it before every
newline. Add a function color_fwrite() which does that for us.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
color.c | 28 ++++++++++++++++++++++++++++
color.h | 1 +
2 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/color.c b/color.c
index fc0b72a..b028880 100644
--- a/color.c
+++ b/color.c
@@ -191,3 +191,31 @@ int color_fprintf_ln(FILE *fp, const char *color, const char *fmt, ...)
va_end(args);
return r;
}
+
+/*
+ * This function splits the buffer by newlines and colors the lines individually.
+ *
+ * Returns 0 on success.
+ */
+int color_fwrite_lines(FILE *fp, const char *color,
+ size_t count, const char *buf)
+{
+ if (!*color)
+ return fwrite(buf, count, 1, fp) != 1;
+ while (count) {
+ char *p = memchr(buf, '\n', count);
+ if (fputs(color, fp) < 0 ||
+ fwrite(buf, p ? p - buf : count, 1, fp) != 1 ||
+ fputs(COLOR_RESET, fp) < 0)
+ return -1;
+ if (!p)
+ return 0;
+ if (fputc('\n', fp) < 0)
+ return -1;
+ count -= p + 1 - buf;
+ buf = p + 1;
+ }
+ return 0;
+}
+
+
diff --git a/color.h b/color.h
index 6cf5c88..cd5c985 100644
--- a/color.h
+++ b/color.h
@@ -19,5 +19,6 @@ int git_config_colorbool(const char *var, const char *value, int stdout_is_tty);
void color_parse(const char *var, const char *value, char *dst);
int color_fprintf(FILE *fp, const char *color, const char *fmt, ...);
int color_fprintf_ln(FILE *fp, const char *color, const char *fmt, ...);
+int color_fwrite_lines(FILE *fp, const char *color, size_t count, const char *buf);
#endif /* COLOR_H */
--
1.6.1.223.g50c8f
^ permalink raw reply related
* Re: [PATCH 1/4] Add color_fwrite(), a function coloring each line individually
From: Johannes Schindelin @ 2009-01-11 23:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Thomas Rast
In-Reply-To: <7vwsd1o44i.fsf@gitster.siamese.dyndns.org>
Hi,
On Sun, 11 Jan 2009, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > +/*
> > + * This function splits the buffer by newlines and colors the lines individually.
> > + */
> > +void color_fwrite(FILE *f, const char *color, size_t count, const char *buf)
>
> Is it just me that this is grossly misnamed? It is not about fwrite of
> count bytes starting at buf in the specified color. At list it should be
> called color_fwrite_lines() or something like that.
>
> > diff --git a/color.h b/color.h
> > index 6cf5c88..9fb58f5 100644
> > --- a/color.h
> > +++ b/color.h
> > @@ -19,5 +19,6 @@ int git_config_colorbool(const char *var, const char *value, int stdout_is_tty);
> > void color_parse(const char *var, const char *value, char *dst);
> > int color_fprintf(FILE *fp, const char *color, const char *fmt, ...);
> > int color_fprintf_ln(FILE *fp, const char *color, const char *fmt, ...);
> > +void color_fwrite(FILE *f, const char *color, size_t count, const char *buf);
>
> Also if other functions in the family all return int to indicate errors
> and name the FILE * argument fp, I find it a very bad taste not to follow
> their patterns without having a good reason (which I do not see).
Valid points.
Sorry,
Dscho
^ permalink raw reply
* [PATCH] git-svn: add --authors-file test
From: Eric Wong @ 2009-01-11 23:44 UTC (permalink / raw)
To: git
I'm not sure how often this functionality is used, but in case
it's not, having an extra test here will help catch breakage
sooner.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
This was posted over a year ago and forgotten about. Updated and
cleaned up a bit to work with the new test suite.
t/t9130-git-svn-authors-file.sh | 94 +++++++++++++++++++++++++++++++++++++++
1 files changed, 94 insertions(+), 0 deletions(-)
create mode 100755 t/t9130-git-svn-authors-file.sh
diff --git a/t/t9130-git-svn-authors-file.sh b/t/t9130-git-svn-authors-file.sh
new file mode 100755
index 0000000..b8fb277
--- /dev/null
+++ b/t/t9130-git-svn-authors-file.sh
@@ -0,0 +1,94 @@
+#!/bin/sh
+#
+# Copyright (c) 2008 Eric Wong
+#
+
+test_description='git svn authors file tests'
+
+. ./lib-git-svn.sh
+
+cat > svn-authors <<EOF
+aa = AAAAAAA AAAAAAA <aa@example.com>
+bb = BBBBBBB BBBBBBB <bb@example.com>
+EOF
+
+test_expect_success 'setup svnrepo' '
+ for i in aa bb cc dd
+ do
+ svn mkdir -m $i --username $i "$svnrepo"/$i
+ done
+ '
+
+test_expect_success 'start import with incomplete authors file' '
+ ! git svn clone --authors-file=svn-authors "$svnrepo" x
+ '
+
+test_expect_success 'imported 2 revisions successfully' '
+ (
+ cd x
+ test "`git rev-list refs/remotes/git-svn | wc -l`" -eq 2 &&
+ git rev-list -1 --pretty=raw refs/remotes/git-svn | \
+ grep "^author BBBBBBB BBBBBBB <bb@example\.com> " &&
+ git rev-list -1 --pretty=raw refs/remotes/git-svn~1 | \
+ grep "^author AAAAAAA AAAAAAA <aa@example\.com> "
+ )
+ '
+
+cat >> svn-authors <<EOF
+cc = CCCCCCC CCCCCCC <cc@example.com>
+dd = DDDDDDD DDDDDDD <dd@example.com>
+EOF
+
+test_expect_success 'continues to import once authors have been added' '
+ (
+ cd x
+ git svn fetch --authors-file=../svn-authors &&
+ test "`git rev-list refs/remotes/git-svn | wc -l`" -eq 4 &&
+ git rev-list -1 --pretty=raw refs/remotes/git-svn | \
+ grep "^author DDDDDDD DDDDDDD <dd@example\.com> " &&
+ git rev-list -1 --pretty=raw refs/remotes/git-svn~1 | \
+ grep "^author CCCCCCC CCCCCCC <cc@example\.com> "
+ )
+ '
+
+test_expect_success 'authors-file against globs' '
+ svn mkdir -m globs --username aa \
+ "$svnrepo"/aa/trunk "$svnrepo"/aa/branches "$svnrepo"/aa/tags &&
+ git svn clone --authors-file=svn-authors -s "$svnrepo"/aa aa-work &&
+ for i in bb ee cc
+ do
+ branch="aa/branches/$i"
+ svn mkdir -m "$branch" --username $i "$svnrepo/$branch"
+ done
+ '
+
+test_expect_success 'fetch fails on ee' '
+ ( cd aa-work && ! git svn fetch --authors-file=../svn-authors )
+ '
+
+tmp_config_get () {
+ GIT_CONFIG=.git/svn/.metadata git config --get "$1"
+}
+
+test_expect_success 'failure happened without negative side effects' '
+ (
+ cd aa-work &&
+ test 6 -eq "`tmp_config_get svn-remote.svn.branches-maxRev`" &&
+ test 6 -eq "`tmp_config_get svn-remote.svn.tags-maxRev`"
+ )
+ '
+
+cat >> svn-authors <<EOF
+ee = EEEEEEE EEEEEEE <ee@example.com>
+EOF
+
+test_expect_success 'fetch continues after authors-file is fixed' '
+ (
+ cd aa-work &&
+ git svn fetch --authors-file=../svn-authors &&
+ test 8 -eq "`tmp_config_get svn-remote.svn.branches-maxRev`" &&
+ test 8 -eq "`tmp_config_get svn-remote.svn.tags-maxRev`"
+ )
+ '
+
+test_done
--
Eric Wong
^ permalink raw reply related
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