* [PATCH] git-clone: Add option --branch to override initial branch
From: Tor Arne Vestbø @ 2009-03-02 22:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
The options --branch and -b allow the user to override the initial
branch created and checked out by git-clone. Normally this is the
active branch of the remote repository, which is also the fallback
if the selected branch is not found.
Signed-off-by: Tor Arne Vestbø <torarnv@gmail.com>
---
Documentation/git-clone.txt | 5 +++++
builtin-clone.c | 33 +++++++++++++++++++++++++++++----
2 files changed, 34 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index 95f08b9..e7feb4d 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -119,6 +119,11 @@ then the cloned repository will become corrupt.
Instead of using the remote name 'origin' to keep track
of the upstream repository, use <name> instead.
+--branch <name>::
+-b <name>::
+ Instead of using the remote repository's active branch as the
+ initial branch, use <name> instead.
+
--upload-pack <upload-pack>::
-u <upload-pack>::
When given, and the repository to clone from is accessed
diff --git a/builtin-clone.c b/builtin-clone.c
index c338910..601c2c2 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -38,6 +38,7 @@ static int option_quiet, option_no_checkout, option_bare, option_mirror;
static int option_local, option_no_hardlinks, option_shared;
static char *option_template, *option_reference, *option_depth;
static char *option_origin = NULL;
+static char *option_branch = NULL;
static char *option_upload_pack = "git-upload-pack";
static int option_verbose;
@@ -66,6 +67,8 @@ static struct option builtin_clone_options[] = {
"path to git-upload-pack on the remote"),
OPT_STRING(0, "depth", &option_depth, "depth",
"create a shallow clone of that depth"),
+ OPT_STRING('b', "branch", &option_branch, "branch",
+ "initial remote branch to check out"),
OPT_END()
};
@@ -372,7 +375,9 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
const char *repo_name, *repo, *work_tree, *git_dir;
char *path, *dir;
int dest_exists;
- const struct ref *refs, *head_points_at, *remote_head, *mapped_refs;
+ const struct ref *refs, *mapped_refs;
+ const struct ref *remote_head = NULL;
+ const struct ref *head_points_at = NULL;
struct strbuf key = STRBUF_INIT, value = STRBUF_INIT;
struct strbuf branch_top = STRBUF_INIT, reflog_msg = STRBUF_INIT;
struct transport *transport = NULL;
@@ -545,12 +550,32 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
mapped_refs = write_remote_refs(refs, &refspec, reflog_msg.buf);
- head_points_at = locate_head(refs, mapped_refs, &remote_head);
+ if (option_branch) {
+ const int offset = 11;
+ const char *branch = option_branch;
+ if (!prefixcmp(branch, "refs/heads/"))
+ branch += offset;
+
+ const struct ref *r;
+ for (r = mapped_refs; r; r = r->next) {
+ if (!strcmp(r->name + offset, branch)) {
+ /* Override initial branch */
+ head_points_at = r;
+ remote_head = r;
+ break;
+ }
+ }
+
+ if (!head_points_at)
+ warning("remote has no branch named '%s', "
+ "falling back to default.", option_branch);
+ }
+
+ if (!head_points_at)
+ head_points_at = locate_head(refs, mapped_refs, &remote_head);
}
else {
warning("You appear to have cloned an empty repository.");
- head_points_at = NULL;
- remote_head = NULL;
option_no_checkout = 1;
if (!option_bare)
install_branch_config("master", option_origin,
--
1.6.2.rc2.16.gf474c.dirty
^ permalink raw reply related
* Re: [RFC] Refspec patterns with * in the middle
From: Jay Soffian @ 2009-03-02 22:07 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LNX.1.00.0903021323180.19665@iabervon.org>
On Mon, Mar 2, 2009 at 1:25 PM, Daniel Barkalow <barkalow@iabervon.org> wrote:
>> But the following is not:
>>
>> - foo/bar*/baz
>>
>> IOW, '*' can only appear as a non-terminating symbol if it is bounded
>> by '/' on each side.
>
> You have my criterion right, but I want that to be valid, but only match
> things like "foo/bar-something/baz", not "foo/bar-a/b/baz".
Ah, that makes sense. Perhaps use "**" to mean matching across path
components which is what rsync does:
o a '*' matches any non-empty path component (it stops at slashes).
o use '**' to match anything, including slashes.
?
j.
^ permalink raw reply
* Re: [RFC PATCH] Windows: Assume all file names to be UTF-8 encoded.
From: Robin Rosenberg @ 2009-03-02 21:21 UTC (permalink / raw)
To: Peter Krefting; +Cc: Johannes Sixt, git
In-Reply-To: <alpine.DEB.2.00.0903022146510.20047@perkele.intern.softwolves.pp.se>
måndag 02 mars 2009 21:52:41 skrev Peter Krefting <peter@softwolves.pp.se>:
> Robin Rosenberg:
>
> > I'd be almost happy with a solution that works when people are interacting
> > using the subset that is convertible between the character sets in use.
>
> You mean like the "invariant" character set? :-) Using Unicode internally
> (in whatever encoding) is nice, the problem is when you have to interact
> with the world around you.
Not sure what that is. I mean that in a local nordic, setting people can use iso-8859-1|15/windows-1252/UTF-8 for their needs be means of converting the characters as-needed without loss, with very few practial restrictions.
For a larger setting that won't do, but then the need is typically less since people tend to use ASCII only, or you jump to all unicode.
Just because I use UTF-8 doesn't mean I use start using more characters in practice.
-- robin
^ permalink raw reply
* Re: [RFC PATCH] Windows: Assume all file names to be UTF-8 encoded.
From: Peter Krefting @ 2009-03-02 20:52 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Johannes Sixt, git
In-Reply-To: <200903022058.33392.robin.rosenberg.lists@dewire.com>
Robin Rosenberg:
> Pipes are just bytes so you have to know what you're piping by convention
> or protocol. You can ask for the console output page, which may be set to
> a multibyte locale or unicode and maybe trust that.... (just guessing,
> really).
You can get cmd.exe to write data to pipes and redirections as UTF-16
Unicode (cmd.exe /u), perhaps there is a way to capitalise on that?
"Unfortunately", the Git stuff is mostly called from a bash shell inside
msys, so it requires a "bit" more work...
> architecture? Like the "architecture" of species? No, it's evolution.
There's still an architecture there, somewhere. Perhaps not intended or
specified, but there definitely is one :-)
> http://www.jgit.org/cgi-bin/gitweb/gitweb.cgi?p=GIT.git;a=shortlog;h=i18n
>
> The goal is locale neutrality yielding the "expected", in the users eyes,
> result regardless of locale as much as possible.
Ah, yes, that looks like an interesting starting point. I already assumed
that Git on Linux would use UTF-8 for everything already, since it already
does that for the commit messages despite me using an iso8859-1 locale.
Apparently I haven't done my homework.
> We let the runtime decide on how to encode file names in the file system
> using the user's locale.
That's good. That's what I'm trying to achieve. Or, rather, avoid the user
locale altogether (which is easy on Windows since the file names are always
stored in Unicode, and the user locale can be bypassed).
> I'd be almost happy with a solution that works when people are interacting
> using the subset that is convertible between the character sets in use.
You mean like the "invariant" character set? :-) Using Unicode internally
(in whatever encoding) is nice, the problem is when you have to interact
with the world around you.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* remote branches, and branch names in general
From: John Dlugosz @ 2009-03-02 20:46 UTC (permalink / raw)
To: git
I see the remote branches with names of the form remotes/pub/name where
pub is the nickname of the place I pull from. To specify such branches,
must I always spell it out with the leading "remotes/", or can that be
shorted or implied somehow?
Meanwhile, I see that branch names can be hierarchical, as I found out
when I accidently created a branch called "pub/xxx". So I'm wondering
about the usefulness of using that for organizing topic branches based
on assigned tasks organization and the person owning that branch.
--John
TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
If you received this in error, please contact the sender and delete the material from any computer.
^ permalink raw reply
* Re: [RFC PATCH] Windows: Assume all file names to be UTF-8 encoded.
From: Peter Krefting @ 2009-03-02 20:41 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <200903021530.01165.trast@student.ethz.ch>
Thomas Rast:
> Have you thought about all the consequences this would have for the *nix
> people here? [*]
Yeah. It will fix problems trying to check out a Git repository created by
me in a iso8859-1 locale on a machine using a utf-8 locale, where both ends
would like to have a file named "Ü".
Or, hopefully, a careful adoption of this on Windows won't affect Unixes and
other systems with pre-Unicode APIs at all, since the Windows code would be
in the "compat" directory.
> you're still in a world of hurt when trying to check out such paths under
> a locale (or whatever setting might control this new encoding logic) that
> does not support the whole range of UTF-8.
Yeah. That would be a case similar to the casing problem on Windows.
> With backwards compatibility it's even worse as you're suddenly imposing
> extra restrictions on what a valid filename in the repository must look
> like.
Indeed. It is unfortunate that this wasn't properly specified to start with.
It's mostly a minor issue since *most* people will not use non-ASCII file
names. At least for most of the kind of projects that Git have attracted so
far, so the problem is not that big. The problem is if Git is to attract
"the masses". Especially on Windows, where file names using non-ASCII are
common, this needs to be addressed eventually.
> [*] I'm _extremely_ tempted to write "people using non-broken OSes", but
> let's pretend to be neutral for a second.
In most cases, I would most definitely agree with you on calling it that,
but when it comes to Unicode support, Windows is one of the least broken
OSes (with Symbian being my favourite).
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: [PATCH 3/3] Documentation: minor grammatical fixes.
From: Junio C Hamano @ 2009-03-02 20:35 UTC (permalink / raw)
To: David J. Mellor; +Cc: git
In-Reply-To: <20090302163548.D6ECC17A49@sandstone.whistlingcat.com>
Thanks.
^ permalink raw reply
* move files between disparate repos and maintain version history
From: davetron5000 @ 2009-03-02 20:30 UTC (permalink / raw)
To: git
Using git-svn at work, and had to do some svn moves that I'm wondering
would be handled with git?
Our repo is setup like this:
$SVNROOT/main/core/{trunk,tags,branches}
$SVNROOT/main/app/{trunk,tags,branches}
core and app are treated as different project roots internally, and my
git-svn treats them as such.
We recently needed to move some files from app to core. I could've
just moved them in between my git repos, but the version history would
be lost, since these are two separate repos. I did the move via svn
mv, which works simply because our "separate projects" are really just
in the same SVN repo.
So, is there a way I can move a file between two git repositories,
maintaining the change history? I guess it would be something like
"apply all patches that this file was involved in, but ONLY apply the
ones affecting this file, to the new repo, then delete from the old"?
^ permalink raw reply
* Re: [RFC PATCH] Windows: Assume all file names to be UTF-8 encoded.
From: Robin Rosenberg @ 2009-03-02 19:58 UTC (permalink / raw)
To: Peter Krefting; +Cc: Johannes Sixt, git
In-Reply-To: <alpine.DEB.2.00.0903021404000.17877@perkele.intern.softwolves.pp.se>
> Johannes Sixt:
>
> > Can you set the local codepage per program? (I don't know.)
>
> The locale is set per thread, and gets reset when the program exits. So
> setting the codepage to UTF-8 before outputting should work. That should
> also work for displaying the log to the terminal if you have UTF-8 log
> messages.
Messing with locale is probably going to break subtly. An explicit approach
is better, respecting the user's locale when necessary.
> Converting it to wchar_t and using wprintf and similar should be safer,
> though (and I have no idea what happens if you try to pipe the output to
> something else).
>
> > - What encoding should 'ls-files' use for its output? Certainly not always
> > UTF-8: stdout should use the local code page so that the file names are
> > interpreted correctly by the terminal window (it expects the local code
> > page).
>
> That is exactly why trying to mix "protocol" data ("plumbing" in Git's case)
> and user output will always come back and bite you, one way or another. I
> haven't really the faintest how pipes work with Unicode on Windows.
> Somewhere along the line there will probably be some conversions, which
> would cause interesting issues.
Pipes are just bytes so you have to know what you're piping by convention
or protocol. You can ask for the console output page, which may be set to
a multibyte locale or unicode and maybe trust that.... (just guessing, really).
> Better not use pipes, then. Heh. I sense that there is a slight problem with
> the architecture of Git and trying to get it to behave on Windows... :-)
architecture? Like the "architecture" of species? No, it's evolution.
If that applies to the linux kernel, it's not so strange it applies to git too.
> > - What encoding should 'update-index' expect from its input? Can you be
> > sure that other programs generate UTF-8 output?
>
> Theoretically, if all the internal stuff is hacked around to output Unicode,
> and the thread codepage is set up to use UTF-8, it should "just work". And
msys doesn't seem to understand UTF-8 at all, so depending on that to work
seems futile. Simply bypassing the locale for any internal work is probably the
most sane thing. That also won't depend of the quality of the locale support in
the runtime. Start by making the git commands working without msys bash,
and figure a way to fix msys later, unless someone has a very good idea on
how to fix msys.
> if run directly from the shell, it should still be converted to whatever the
> system is set up to emit. That would mean, however, that a Git program that
> internally runs
>
> git-foo | git-bar | git-gazonk
>
> might behave differently compared to if a user would enter it on the
> command-line.
>
You might also want to check out my work in the area. See
http://www.jgit.org/cgi-bin/gitweb/gitweb.cgi?p=GIT.git;a=shortlog;h=i18n
The goal is locale neutrality yielding the "expected", in the users eyes, result regardless
of locale as much as possible. Junio didn't want to have it for five years, so I
guess there's still three and half to go. Hopefully he can change his mind. That branch
is heavily outdated by now, as some of functionality have been introduced by other
means like logoutputencoding and other parts of git have been rewritten.
Related to this, JGit assumes UTF-8 on reading. If it's not valid UTF-8 we try the user's
locale (rougly) and on writing object meta data, including any sort of identifier,
we always write UTF-8 when have to be explicit. We let the runtime decide on how
to encode file names in the file system using the user's locale.
I'd be almost happy with a solution that works when people are interacting using
the subset that is convertible between the character sets in use.
-- robin
^ permalink raw reply
* Re: VSS to git
From: Alexander Gavrilov @ 2009-03-02 18:55 UTC (permalink / raw)
To: Mike Ralphson; +Cc: Chris Velevitch, git
In-Reply-To: <e2b179460903020951h7f1538daya4d3cdb96fc7c65d@mail.gmail.com>
On Monday 02 March 2009 20:51:12 Mike Ralphson wrote:
> 2009/3/2 Chris Velevitch <chris.velevitch@gmail.com>:
> > I can't seem to find any utilities to convert a vss repository to git.
> > In the absence of such a tool, what is the best approach to converting
> > an vss repository to git?
>
> You might be able to two-stage through vss2svn[1], and from there to git.
> Or take the guts of vss2* [2] and rewrite the backend to create git
> fast-import format?
Last year I experimented with conversion using vss2svn plus a heavily
patched version of git-svnimport, and it worked quite well. The largest
problem is that VSS cannot record directory copies, so the resulting
SVN repository does not have them either. This makes conversion tools
unable to detect any branching, so I had to implement support for
completely arbitrary mapping specs.
I also made an incremental synchronization script for simple actions
(requires logging to be enabled in VSS).
Alexander
P.S: I made some fixes to vss2svn too, they are in a separate branch:
http://www.pumacode.org/projects/vss2svn/browser/branches/Alexander
^ permalink raw reply
* Re: [RFC] Refspec patterns with * in the middle
From: Daniel Barkalow @ 2009-03-02 18:25 UTC (permalink / raw)
To: Jay Soffian; +Cc: Junio C Hamano, git
In-Reply-To: <76718490903021001h16009570p7ac8c66a8e8e1f90@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1809 bytes --]
On Mon, 2 Mar 2009, Jay Soffian wrote:
> On Mon, Mar 2, 2009 at 12:08 PM, Junio C Hamano <gitster@pobox.com> wrote:
> > Daniel Barkalow <barkalow@iabervon.org> writes:
> >
> >> My use case is actually, more precisely:
> >>
> >> some/constant/stuff/$PROJ-$NUMBER/junk/my-proj
> >>
> >> Where $NUMBER is the version number, and $PROJ is usually, but not quite
> >> always "my-proj"; the exception being that it might be effectively a
> >> superproject. So I'd like to have:
> >>
> >> fetch = some/constant/stuff/my-proj-*/junk/my-proj:refs/remotes/origin/*
> >
> > ... and expect "some/constant/stuff/my-proj-2.5/junk/my-proj" to be mapped
> > to "refs/remotes/origin/2.5"? I think it does not look too bad.
> >
> >> But I can live with remote branches like "my-proj-2.4" instead of "2.4".
> >>
> >> I think it would make sense, and limit typo damage, to say that the * can
> >> only expand to something with a '/' in it if the star has a slash or the
> >> end of the string on each side.
> >
> > I do not understand what you mean by "* can only expand to something with
> > a '/' in it if ..." part. None of the examples in your message have a
> > case where the asterisk matches across directory boundaries, and I thought
> > you would simply say "* does not match /" and be done with that.
> >
> > What scenario do you have in mind that wants to match a slash with an
> > asterisk?
>
> I think he means the following are valid:
>
> - foo/bar/*/baz
> - foo/bar/baz/*
>
> But the following is not:
>
> - foo/bar*/baz
>
> IOW, '*' can only appear as a non-terminating symbol if it is bounded
> by '/' on each side.
You have my criterion right, but I want that to be valid, but only match
things like "foo/bar-something/baz", not "foo/bar-a/b/baz".
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [RFC] Refspec patterns with * in the middle
From: Daniel Barkalow @ 2009-03-02 18:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jay Soffian
In-Reply-To: <7viqmrn98i.fsf@gitster.siamese.dyndns.org>
On Mon, 2 Mar 2009, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > My use case is actually, more precisely:
> >
> > some/constant/stuff/$PROJ-$NUMBER/junk/my-proj
> >
> > Where $NUMBER is the version number, and $PROJ is usually, but not quite
> > always "my-proj"; the exception being that it might be effectively a
> > superproject. So I'd like to have:
> >
> > fetch = some/constant/stuff/my-proj-*/junk/my-proj:refs/remotes/origin/*
>
> ... and expect "some/constant/stuff/my-proj-2.5/junk/my-proj" to be mapped
> to "refs/remotes/origin/2.5"? I think it does not look too bad.
Yeah.
> > But I can live with remote branches like "my-proj-2.4" instead of "2.4".
> >
> > I think it would make sense, and limit typo damage, to say that the * can
> > only expand to something with a '/' in it if the star has a slash or the
> > end of the string on each side.
>
> I do not understand what you mean by "* can only expand to something with
> a '/' in it if ..." part. None of the examples in your message have a
> case where the asterisk matches across directory boundaries, and I thought
> you would simply say "* does not match /" and be done with that.
>
> What scenario do you have in mind that wants to match a slash with an
> asterisk?
Backwards compatibility? Currently, refs/heads/*:refs/remotes/origin/*
will match refs/heads/js/notes with refs/remotes/origin/js/notes, because
it simply copies everything after the fixed prefix.
I was assuming that that particular matching is an existing requirement
(and that you used it regularly to share topic-maintenance work between
machines).
So my idea was that a path component of "*" would be able to match
multiple levels, while a path component of "something-*" or "*-something"
can only match a single path component that starts or ends with the right
thing. Looking at it now, I think it might be more sane to use "%" for the
second case, and say: "*" must be used as a full path component, and
matches one or more path components; "%" may be used as part of a path
component, and doesn't match the path separator; you can only use one such
character, and both sides of the refspec have to agree on which.
I think the problem cases were typos like:
refs/heads*:refs/remotes/origin/* (used to cause problems)
and
refs/heads/*:refs/remotes/origin* (gives you the originmaster remote?)
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [RFC] Refspec patterns with * in the middle
From: Jay Soffian @ 2009-03-02 18:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Daniel Barkalow, git
In-Reply-To: <7viqmrn98i.fsf@gitster.siamese.dyndns.org>
On Mon, Mar 2, 2009 at 12:08 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
>> My use case is actually, more precisely:
>>
>> some/constant/stuff/$PROJ-$NUMBER/junk/my-proj
>>
>> Where $NUMBER is the version number, and $PROJ is usually, but not quite
>> always "my-proj"; the exception being that it might be effectively a
>> superproject. So I'd like to have:
>>
>> fetch = some/constant/stuff/my-proj-*/junk/my-proj:refs/remotes/origin/*
>
> ... and expect "some/constant/stuff/my-proj-2.5/junk/my-proj" to be mapped
> to "refs/remotes/origin/2.5"? I think it does not look too bad.
>
>> But I can live with remote branches like "my-proj-2.4" instead of "2.4".
>>
>> I think it would make sense, and limit typo damage, to say that the * can
>> only expand to something with a '/' in it if the star has a slash or the
>> end of the string on each side.
>
> I do not understand what you mean by "* can only expand to something with
> a '/' in it if ..." part. None of the examples in your message have a
> case where the asterisk matches across directory boundaries, and I thought
> you would simply say "* does not match /" and be done with that.
>
> What scenario do you have in mind that wants to match a slash with an
> asterisk?
I think he means the following are valid:
- foo/bar/*/baz
- foo/bar/baz/*
But the following is not:
- foo/bar*/baz
IOW, '*' can only appear as a non-terminating symbol if it is bounded
by '/' on each side.
j.
^ permalink raw reply
* [PATCH v2 1/1] cvsimport: add test illustrating a bug in cvsps
From: Heiko Voigt @ 2009-03-02 17:59 UTC (permalink / raw)
To: Michael Haggerty, Junio C Hamano; +Cc: git
In-Reply-To: <49A37ED1.5090506@alum.mit.edu>
Some cvs repositories may have time deviations in their recorded commits. This
is a test for one of such cases. These kind of repositories can happen if the
system time of cvs clients is not fully synchronised.
Consider the following sequence of events:
* client A commits file a r1.1
* client A commits file a r1.2, b r1.1
* client B commits file b r1.2 using the same timestamp as a r1.1
This can be resolved but due to cvsps grouping its patchsets solely based
on the timestamp and never breaking these groups it outputs the wrong
order which then leads to a broken import.
I hit this bug when importing from a real repository which was originally
converted from another rcs based scm. Other import tools can handle this
correctly, e.g. parsecvs.
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
---
t/t9603-cvsimport-patchsets.sh | 33 +++++++++++++++++++++++++++++
t/t9603/cvsroot/CVSROOT/.gitignore | 2 +
t/t9603/cvsroot/module/a,v | 40 ++++++++++++++++++++++++++++++++++++
t/t9603/cvsroot/module/b,v | 40 ++++++++++++++++++++++++++++++++++++
4 files changed, 115 insertions(+), 0 deletions(-)
create mode 100755 t/t9603-cvsimport-patchsets.sh
create mode 100644 t/t9603/cvsroot/CVSROOT/.gitignore
create mode 100644 t/t9603/cvsroot/module/a,v
create mode 100644 t/t9603/cvsroot/module/b,v
diff --git a/t/t9603-cvsimport-patchsets.sh b/t/t9603-cvsimport-patchsets.sh
new file mode 100755
index 0000000..15a971f
--- /dev/null
+++ b/t/t9603-cvsimport-patchsets.sh
@@ -0,0 +1,33 @@
+#!/bin/sh
+
+# Structure of the test cvs repository
+#
+# Message File:Content Commit Time
+# Rev 1 a: 1.1 2009-02-21 19:11:43 +0100
+# Rev 2 a: 1.2 b: 1.1 2009-02-21 19:11:14 +0100
+# Rev 3 b: 1.2 2009-02-21 19:11:43 +0100
+#
+# As you can see the commit of Rev 3 has the same time as
+# Rev 1 this leads to a broken import because of a cvsps
+# bug.
+
+test_description='git cvsimport testing for correct patchset estimation'
+. ./lib-cvs.sh
+
+CVSROOT="$TEST_DIRECTORY"/t9603/cvsroot
+export CVSROOT
+
+test_expect_failure 'import with criss cross times on revisions' '
+
+ git cvsimport -p"-x" -C module-git module &&
+ cd module-git &&
+ git log --pretty=format:%s > ../actual &&
+ echo "" >> ../actual &&
+ cd .. &&
+ echo "Rev 3
+Rev 2
+Rev 1" > expect &&
+ test_cmp actual expect
+'
+
+test_done
diff --git a/t/t9603/cvsroot/CVSROOT/.gitignore b/t/t9603/cvsroot/CVSROOT/.gitignore
new file mode 100644
index 0000000..3bb9b34
--- /dev/null
+++ b/t/t9603/cvsroot/CVSROOT/.gitignore
@@ -0,0 +1,2 @@
+history
+val-tags
diff --git a/t/t9603/cvsroot/module/a,v b/t/t9603/cvsroot/module/a,v
new file mode 100644
index 0000000..e86adfc
--- /dev/null
+++ b/t/t9603/cvsroot/module/a,v
@@ -0,0 +1,40 @@
+head 1.2;
+access;
+symbols;
+locks; strict;
+comment @# @;
+
+
+1.2
+date 2009.02.21.18.11.14; author tester; state Exp;
+branches;
+next 1.1;
+
+1.1
+date 2009.02.21.18.11.43; author tester; state Exp;
+branches;
+next ;
+
+
+desc
+@@
+
+
+1.2
+log
+@Rev 2
+@
+text
+@1.2
+@
+
+
+1.1
+log
+@Rev 1
+@
+text
+@d1 1
+a1 1
+1.1
+@
diff --git a/t/t9603/cvsroot/module/b,v b/t/t9603/cvsroot/module/b,v
new file mode 100644
index 0000000..ab3089f
--- /dev/null
+++ b/t/t9603/cvsroot/module/b,v
@@ -0,0 +1,40 @@
+head 1.2;
+access;
+symbols;
+locks; strict;
+comment @# @;
+
+
+1.2
+date 2009.02.21.18.11.43; author tester; state Exp;
+branches;
+next 1.1;
+
+1.1
+date 2009.02.21.18.11.14; author tester; state Exp;
+branches;
+next ;
+
+
+desc
+@@
+
+
+1.2
+log
+@Rev 3
+@
+text
+@1.2
+@
+
+
+1.1
+log
+@Rev 2
+@
+text
+@d1 1
+a1 1
+1.1
+@
--
1.6.1.2.390.gba743
^ permalink raw reply related
* [PATCH v2 0/1] cvsimport: add test illustrating a bug in cvsps
From: Heiko Voigt @ 2009-03-02 17:59 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git, Junio C Hamano
In-Reply-To: <49A37ED1.5090506@alum.mit.edu>
Hallo,
here is the second version of my patch with one more test for cvsimport.
This mail is just for documentation what has been fixed since the first
version.
Michael Haggerty schrieb:
> Heiko Voigt wrote:
>> Some cvs repositories may have time deviations in their recorded commits. This
>> is a test for one of such cases. [...]
>
> Based on the numbering of your test, it looks like you've seen my
> proposed patch [1]. If my patch is accepted, it would make sense for
> yours to use the lib-cvs.sh library that I started. But I guess that
> can be changed if and when my patch is accepted.
Indeed, I saw your patches which actually let me start to work on tests
of the problems I have found in cvsimport. I have already switched to
your library because I did not like to copy that code in the first
place. So this patch is now dependent on your series.
> To share the most test code, it would help to choose the same CVS module
> name for each test when possible. I imitated t9600 and named the CVS
> modules in my tests "module", and for now the library assumes that name.
> Unless there is a special reason to use the module name "time", you
> might think of renaming it, and similarly renaming your conversion
> directory "module-git".
Done.
>
>> +test_expect_success 'import with criss cross times on revisions' '
>
> Since this test is known to fail, I think it should be
> "test_expect_failure".
Adapted. I was not aware that this function marked a known bug. Sounded
to me like "if this test does succeed its an error".
>
>> diff --git a/t/t9603/cvsroot/CVSROOT/.empty b/t/t9603/cvsroot/CVSROOT/.empty
>> new file mode 100644
>> index 0000000..e69de29
>
> I suggest adding a .gitignore file instead of .empty to keep the CVSROOT
> directory around, and in it to list the filenames "history" and
> "val-tags" (which are created by some cvs commands). This will preserve
> a clean "git status" even after running the test.
Done.
>> diff --git a/t/t9603/cvsroot/time/a,v b/t/t9603/cvsroot/time/a,v
>> new file mode 100644
>> index 0000000..66a96aa
>> --- /dev/null
>> +++ b/t/t9603/cvsroot/time/a,v
>> [...]
>
> To avoid complaints from "git diff --check" about trailing whitespace in
> the *,v files, you can add a file .gitattributes in your cvsroot
> directory, containing the line "* -whitespace". There is also trailing
> whitespace in t9603-cvsimport-time.sh that can simply be deleted.
That would have been another possibility. I actually deleted the
whitespace in the ,v files which seems to cause no problems.
I share Michael's opinion that fixing these issues in cvsps are probably
not worth the effort. It did fix a few but ultimately gave up when
finding this one. Knowing that there are other tools available that do
the job more robust I would vote to switch to a new import tool if that
is possible. Also the users could be pointed to a more robust one in the
documentation like cvs2svn or parsecvs (which I found quite useful
because tag exactness was not that important)
cheers Heiko
^ permalink raw reply
* Re: VSS to git
From: Mike Ralphson @ 2009-03-02 17:51 UTC (permalink / raw)
To: Chris Velevitch; +Cc: git
In-Reply-To: <b0a3bf780903020915g60d97b76pfdbbd60017625f0a@mail.gmail.com>
2009/3/2 Chris Velevitch <chris.velevitch@gmail.com>:
> I can't seem to find any utilities to convert a vss repository to git.
> In the absence of such a tool, what is the best approach to converting
> an vss repository to git?
You might be able to two-stage through vss2svn[1], and from there to git.
Or take the guts of vss2* [2] and rewrite the backend to create git
fast-import format?
Mike
[1]http://www.pumacode.org/projects/vss2svn
[2]http://sourceforge.net/projects/vss2cvs
^ permalink raw reply
* Re: VSS to git
From: Michael J Gruber @ 2009-03-02 17:48 UTC (permalink / raw)
To: Chris Velevitch; +Cc: git
In-Reply-To: <b0a3bf780903020915g60d97b76pfdbbd60017625f0a@mail.gmail.com>
Chris Velevitch venit, vidit, dixit 02.03.2009 18:15:
> I can't seem to find any utilities to convert a vss repository to git.
> In the absence of such a tool, what is the best approach to converting
> an vss repository to git?
Depending on the complexity of your vss repo, going through svn may be
an option, see
http://kerneltrap.org/mailarchive/git/2008/5/27/1952124
which points at
http://www.pumacode.org/projects/vss2svn
Using those pieces you may even be able to produce a fast-exporter for
vss, whose output you could feed into git-fast-import (vss2svn already
creates an svn dump file).
Michael
^ permalink raw reply
* VSS to git
From: Chris Velevitch @ 2009-03-02 17:15 UTC (permalink / raw)
To: git
I can't seem to find any utilities to convert a vss repository to git.
In the absence of such a tool, what is the best approach to converting
an vss repository to git?
Chris
--
Chris Velevitch
Manager - Adobe Platform Users Group, Sydney
m: 0415 469 095
www.apugs.org.au
Adobe Platform Users Group, Sydney
Mar meeting: Bzoo, FlashDevelop, Who's Doing What With AIR and Eclipse Tips
Date: Mon 30th Mar 6pm for 6:30 start
Details and RSVP on http://groups.adobe.com/posts/db02e98146
^ permalink raw reply
* Re: [RFC] Refspec patterns with * in the middle
From: Junio C Hamano @ 2009-03-02 17:08 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <alpine.LNX.1.00.0903011820590.19665@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> My use case is actually, more precisely:
>
> some/constant/stuff/$PROJ-$NUMBER/junk/my-proj
>
> Where $NUMBER is the version number, and $PROJ is usually, but not quite
> always "my-proj"; the exception being that it might be effectively a
> superproject. So I'd like to have:
>
> fetch = some/constant/stuff/my-proj-*/junk/my-proj:refs/remotes/origin/*
... and expect "some/constant/stuff/my-proj-2.5/junk/my-proj" to be mapped
to "refs/remotes/origin/2.5"? I think it does not look too bad.
> But I can live with remote branches like "my-proj-2.4" instead of "2.4".
>
> I think it would make sense, and limit typo damage, to say that the * can
> only expand to something with a '/' in it if the star has a slash or the
> end of the string on each side.
I do not understand what you mean by "* can only expand to something with
a '/' in it if ..." part. None of the examples in your message have a
case where the asterisk matches across directory boundaries, and I thought
you would simply say "* does not match /" and be done with that.
What scenario do you have in mind that wants to match a slash with an
asterisk?
^ permalink raw reply
* Re: "warning: no common commits" triggered due to change of remote's IP address?
From: Brent Goodrick @ 2009-03-02 16:43 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <200903020956.45975.trast@student.ethz.ch>
On Mon, Mar 2, 2009 at 12:56 AM, Thomas Rast <trast@student.ethz.ch> wrote:
> Actually this should name the remote's idea of the ref, i.e.,
>
> git fetch-pack -v $url refs/heads/home 2>&1 \
> | git name-rev --stdin
Sorry, but I had since done a git fetch from home using the local IP
address before I realized that you would want to try more
experiments on it. But that "local" git-fetch did not emit the
"warning: no common commits" message and was fast. Maybe the majority
of the fetch I had started at the Internet cafe but terminated had
done a lion share of the work already, and the speedy local fetch
finished up the leftovers.
But for completeness sake, I did as you said on the now (mostly) up to
date repo:
git fetch-pack -v <remote_ip_address>:git.repos/environ.git
refs/heads/home 2>&1 \
| git name-rev --stdin
Server supports multi_ack
Server supports side-band-64k
Marking 67cb0521a93778a9d9c4d8f4608f2c6c796a7558 (home) as complete
already have 67cb0521a93778a9d9c4d8f4608f2c6c796a7558 (home) (refs/heads/home)
67cb0521a93778a9d9c4d8f4608f2c6c796a7558 (home) refs/heads/home
where <remote_ip_address> is the remote IP address, and not the usual
local IP address that is referenced in .git/config.
What does "Marking ... as complete" mean?
Is the git-fetch-pack method shown above the only way to get a report
of what git finds out of date? Seems that git-fetch-pack actually
downloads objects, instead of just reporting what it would do without
actually doing it.
Brent
^ permalink raw reply
* [PATCH 3/3] Documentation: minor grammatical fixes.
From: David J. Mellor @ 2009-03-02 6:42 UTC (permalink / raw)
To: gitster; +Cc: git
The final hunk in this patch corrects what appears to be a typo:
of --> or
Signed-off-by: David J. Mellor <dmellor@whistlingcat.com>
---
Documentation/git-apply.txt | 26 +++++++++++++-------------
1 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/Documentation/git-apply.txt b/Documentation/git-apply.txt
index 0566376..9e5baa2 100644
--- a/Documentation/git-apply.txt
+++ b/Documentation/git-apply.txt
@@ -25,7 +25,7 @@ and a work tree.
OPTIONS
-------
<patch>...::
- The files to read patch from. '-' can be used to read
+ The files to read the patch from. '-' can be used to read
from the standard input.
--stat::
@@ -33,8 +33,8 @@ OPTIONS
input. Turns off "apply".
--numstat::
- Similar to \--stat, but shows number of added and
- deleted lines in decimal notation and pathname without
+ Similar to \--stat, but shows the number of added and
+ deleted lines in decimal notation and the pathname without
abbreviation, to make it more machine friendly. For
binary files, outputs two `-` instead of saying
`0 0`. Turns off "apply".
@@ -60,15 +60,15 @@ OPTIONS
causes the index file to be updated.
--cached::
- Apply a patch without touching the working tree. Instead, take the
- cached data, apply the patch, and store the result in the index,
+ Apply a patch without touching the working tree. Instead take the
+ cached data, apply the patch, and store the result in the index
without using the working tree. This implies '--index'.
--build-fake-ancestor=<file>::
Newer 'git-diff' output has embedded 'index information'
for each blob to help identify the original version that
the patch applies to. When this flag is given, and if
- the original versions of the blobs is available locally,
+ the original versions of the blobs are available locally,
builds a temporary index containing those blobs.
+
When a pure mode change is encountered (which has no index information),
@@ -109,13 +109,13 @@ the information is read from the current index instead.
applying a diff generated with --unified=0. To bypass these
checks use '--unidiff-zero'.
+
-Note, for the reasons stated above usage of context-free patches are
+Note, for the reasons stated above usage of context-free patches is
discouraged.
--apply::
If you use any of the options marked "Turns off
'apply'" above, 'git-apply' reads and outputs the
- information you asked without actually applying the
+ requested information without actually applying the
patch. Give this flag after those flags to also apply
the patch.
@@ -124,7 +124,7 @@ discouraged.
patch. This can be used to extract the common part between
two files by first running 'diff' on them and applying
the result with this option, which would apply the
- deletion part but not addition part.
+ deletion part but not the addition part.
--allow-binary-replacement::
--binary::
@@ -162,7 +162,7 @@ By default, the command outputs warning messages but applies the patch.
When `git-apply` is used for statistics and not applying a
patch, it defaults to `nowarn`.
+
-You can use different `<action>` to control this
+You can use different `<action>` values to control this
behavior:
+
* `nowarn` turns off the trailing whitespace warning.
@@ -170,7 +170,7 @@ behavior:
patch as-is (default).
* `fix` outputs warnings for a few such errors, and applies the
patch after fixing them (`strip` is a synonym --- the tool
- used to consider only trailing whitespaces as errors, and the
+ used to consider only trailing whitespace characters as errors, and the
fix involved 'stripping' them, but modern gits do more).
* `error` outputs warnings for a few such errors, and refuses
to apply the patch.
@@ -195,7 +195,7 @@ behavior:
adjusting the hunk headers appropriately).
--directory=<root>::
- Prepend <root> to all filenames. If a "-p" argument was passed, too,
+ Prepend <root> to all filenames. If a "-p" argument was also passed,
it is applied before prepending the new root.
+
For example, a patch that talks about updating `a/git-gui.sh` to `b/git-gui.sh`
@@ -221,7 +221,7 @@ ignored, i.e., they are not required to be up-to-date or clean and they
are not updated.
If --index is not specified, then the submodule commits in the patch
-are ignored and only the absence of presence of the corresponding
+are ignored and only the absence or presence of the corresponding
subdirectory is checked and (if possible) updated.
Author
--
1.6.1.3
^ permalink raw reply related
* [PATCH 2/3] Documentation: minor grammatical fixes.
From: David J. Mellor @ 2009-03-02 6:38 UTC (permalink / raw)
To: gitster; +Cc: git
Signed-off-by: David J. Mellor <dmellor@whistlingcat.com>
---
Documentation/blame-options.txt | 6 +++---
Documentation/git-annotate.txt | 6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/blame-options.txt b/Documentation/blame-options.txt
index 7f28432..df2a7c1 100644
--- a/Documentation/blame-options.txt
+++ b/Documentation/blame-options.txt
@@ -74,7 +74,7 @@ of lines before or after the line given by <start>.
Detect moving lines in the file as well. When a commit
moves a block of lines in a file (e.g. the original file
has A and then B, and the commit changes it to B and
- then A), traditional 'blame' algorithm typically blames
+ then A), the traditional 'blame' algorithm typically blames
the lines that were moved up (i.e. B) to the parent and
assigns blame to the lines that were moved down (i.e. A)
to the child commit. With this option, both groups of lines
@@ -90,8 +90,8 @@ commit.
files that were modified in the same commit. This is
useful when you reorganize your program and move code
around across files. When this option is given twice,
- the command looks for copies from all other files in the
- parent for the commit that creates the file in addition.
+ the command additionally looks for copies from all other
+ files in the parent for the commit that creates the file.
+
<num> is optional but it is the lower bound on the number of
alphanumeric characters that git must detect as moving
diff --git a/Documentation/git-annotate.txt b/Documentation/git-annotate.txt
index 0aba022..0590eec 100644
--- a/Documentation/git-annotate.txt
+++ b/Documentation/git-annotate.txt
@@ -3,7 +3,7 @@ git-annotate(1)
NAME
----
-git-annotate - Annotate file lines with commit info
+git-annotate - Annotate file lines with commit information
SYNOPSIS
--------
@@ -12,11 +12,11 @@ SYNOPSIS
DESCRIPTION
-----------
Annotates each line in the given file with information from the commit
-which introduced the line. Optionally annotate from a given revision.
+which introduced the line. Optionally annotates from a given revision.
The only difference between this command and linkgit:git-blame[1] is that
they use slightly different output formats, and this command exists only
-for backward compatibility to support existing scripts, and provide more
+for backward compatibility to support existing scripts, and provide a more
familiar command name for people coming from other SCM systems.
OPTIONS
--
1.6.1.3
^ permalink raw reply related
* [PATCH 1/3] Documentation: minor grammatical fixes.
From: David J. Mellor @ 2009-03-02 6:37 UTC (permalink / raw)
To: gitster; +Cc: git
Signed-off-by: David J. Mellor <dmellor@whistlingcat.com>
---
Documentation/git-am.txt | 36 ++++++++++++++++++------------------
1 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
index ff307eb..1e71dd5 100644
--- a/Documentation/git-am.txt
+++ b/Documentation/git-am.txt
@@ -27,8 +27,8 @@ OPTIONS
-------
<mbox>|<Maildir>...::
The list of mailbox files to read patches from. If you do not
- supply this argument, reads from the standard input. If you supply
- directories, they'll be treated as Maildirs.
+ supply this argument, the command reads from the standard input.
+ If you supply directories, they will be treated as Maildirs.
-s::
--signoff::
@@ -48,7 +48,7 @@ OPTIONS
preferred encoding if it is not UTF-8).
+
This was optional in prior versions of git, but now it is the
-default. You could use `--no-utf8` to override this.
+default. You can use `--no-utf8` to override this.
--no-utf8::
Pass `-n` flag to 'git-mailinfo' (see
@@ -57,8 +57,8 @@ default. You could use `--no-utf8` to override this.
-3::
--3way::
When the patch does not apply cleanly, fall back on
- 3-way merge, if the patch records the identity of blobs
- it is supposed to apply to, and we have those blobs
+ 3-way merge if the patch records the identity of blobs
+ it is supposed to apply to and we have those blobs
available locally.
--whitespace=<option>::
@@ -121,18 +121,18 @@ the commit, after stripping common prefix "[PATCH <anything>]".
It is supposed to describe what the commit is about concisely as
a one line text.
-The body of the message (iow, after a blank line that terminates
-RFC2822 headers) can begin with "Subject: " and "From: " lines
-that are different from those of the mail header, to override
-the values of these fields.
+The body of the message (the rest of the message after the blank line
+that terminates the RFC2822 headers) can begin with "Subject: " and
+"From: " lines that are different from those of the mail header,
+to override the values of these fields.
The commit message is formed by the title taken from the
"Subject: ", a blank line and the body of the message up to
-where the patch begins. Excess whitespaces at the end of the
+where the patch begins. Excess whitespace characters at the end of the
lines are automatically stripped.
The patch is expected to be inline, directly following the
-message. Any line that is of form:
+message. Any line that is of the form:
* three-dashes and end-of-line, or
* a line that begins with "diff -", or
@@ -141,18 +141,18 @@ message. Any line that is of form:
is taken as the beginning of a patch, and the commit log message
is terminated before the first occurrence of such a line.
-When initially invoking it, you give it names of the mailboxes
-to crunch. Upon seeing the first patch that does not apply, it
-aborts in the middle,. You can recover from this in one of two ways:
+When initially invoking it, you give it the names of the mailboxes
+to process. Upon seeing the first patch that does not apply, it
+aborts in the middle. You can recover from this in one of two ways:
-. skip the current patch by re-running the command with '--skip'
+. skip the current patch by re-running the command with the '--skip'
option.
. hand resolve the conflict in the working directory, and update
- the index file to bring it in a state that the patch should
- have produced. Then run the command with '--resolved' option.
+ the index file to bring it into a state that the patch should
+ have produced. Then run the command with the '--resolved' option.
-The command refuses to process new mailboxes while `.git/rebase-apply`
+The command refuses to process new mailboxes while the `.git/rebase-apply`
directory exists, so if you decide to start over from scratch,
run `rm -f -r .git/rebase-apply` before running the command with mailbox
names.
--
1.6.1.3
^ permalink raw reply related
* Re: topgit patches
From: Uwe Kleine-König @ 2009-03-02 16:26 UTC (permalink / raw)
To: martin f krafft; +Cc: Petr Baudis, git
In-Reply-To: <20090226060652.GA16251@lapse.rw.madduck.net>
Hello,
On Thu, Feb 26, 2009 at 07:06:52AM +0100, martin f krafft wrote:
> also sprach Uwe Kleine-König <u.kleine-koenig@pengutronix.de> [2009.02.26.0015 +0100]:
> > Well, I already wondered if there is someone using topgit apart
> > from me. :-)
>
> I use it and would like to actively maintain it, but time is short
> and I wanted to push out a new option parser with 0.6, but it's just
> not finished yet. As soon as I find a few hours, I'll try to revisit
> it. But if someone else has the time, maybe we can prepare a 0.6
> without a new option parser?
I assume you planned to use git rev-parse --parseopt?
Since topgit-0.5 we have some fixes, a new export method and improved
bash completion. Just repackaging the current state into a new Debian
package closes 4 bugs in the Debian BTS.
Before 0.6 I still need to write some documentation for the new export
method, but after that I consider releasing the then current state as
0.6 is a good idea.
martin, Petr, others: any comments? Should I just tag if I feel ready?
martin: I can try to prepare the Debian package, AFAIK I cannot upload
it, so here I need your help. (And maybe you should check the package,
because up to now I only created Debian packages for my private use.)
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Strasse 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: Bug in Git-Gui - Creates corrupt patch
From: Johannes Sixt @ 2009-03-02 14:39 UTC (permalink / raw)
To: Grzegorz Kossakowski; +Cc: 4jxDQ6FQee2H, spearce, git
In-Reply-To: <49ABEE6C.3000500@tuffmail.com>
Grzegorz Kossakowski schrieb:
> Johannes Sixt pisze:
>> 4jxDQ6FQee2H@dyweni.com schrieb:
>>> 3. Using git-gui, try to stage *only* the last line marked for removal
>>> (should be '- }').
>>>
>>> I get 'fatal: corrupt patch at line 22'.
>> "Stage/Unstage line" does not work for files that have
>>
>> \ No newline at end of file
>
> I've just stumpled across this problem. Does above imply that reported problem is not considered as a bug?
No, it means that I was too lazy to implement it. I tried to do that after
this report came in, but gave up because it is not trivial and I have too
little time to think it through. :-(
-- Hannes
^ 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