* Re: Importing Mozilla CVS into git
From: Jakub Narebski @ 2006-06-04 7:05 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0606031631480.5498@g5.osdl.org>
On Sun, 4 Jun 2006, Linus Torvalds wrote:
> On Sun, 4 Jun 2006, Robin Rosenberg (list subscriber) wrote:
>>
>> (Yet) Another problem is that many windows tools use CR LF as the line ending.
>> Almost all windows editors default to CRLF and some detect existing line
>> endings. No editing with notepad anymore. Of course that is a problem
>> regardless of whether a git or cvs client is used. You'll get these big
>> everything-changed commits that alter between CRLF and LF.
>
> The only sane approach there (if you want to be at all cross-platform) is
> to just force everybody to _commit_ in UNIX '\n'-only format. Especially
> as most Windows tools probably handle that fine on reading (just have
> trouble writing them).
>
> And that shouldn't actually be that hard to do. The most trivial approach
> is to have just a pre-trigger on commits, but let's face it, that would
> not be a good "full" solution. A better one is to just make the whole
> "git update-index" thing just have a "automatically ignore CR/LF" mode.
Why wouldn't it be good solution?
BTW. wouldn't Mercurial encode/decode filters
http://www.selenic.com/mercurial/wiki/index.cgi/EncodeDecodeFilter
be a better solution than modifying files by "git update-index",
with all problems it can cause (not detected binary files, text files
which have to be in CR/LF line ending,...).
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: git daemon directory munging?
From: Junio C Hamano @ 2006-06-04 6:27 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0606031722340.5498@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> diff --git a/connect.c b/connect.c
> index 54f7bf7..36c5d04 100644
> --- a/connect.c
> +++ b/connect.c
> @@ -374,7 +374,7 @@ static int git_tcp_connect(int fd[2], co
>
> fd[0] = sockfd;
> fd[1] = sockfd;
> - packet_write(sockfd, "%s %s\n", prog, path);
> + packet_write(sockfd, "%s %s%c%s%c%s\n", prog, path, 0, host, 0, port);
> return 0;
> }
Adding host like HTTP does with Host: header makes sense but I
think the accept side can usually tell what the port it accepted
the connection to is.
^ permalink raw reply
* Re: More verbose "git fetch"?
From: Junio C Hamano @ 2006-06-04 6:25 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7v7j3xebg6.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Linus Torvalds <torvalds@osdl.org> writes:
>
>> Has it always spit out those annoying
>>
>> xyz: same as branch 'xyz' of so-and-so-repo
>>
>> even without "-v"? I thought I killed them at some point, but
>> either they're back, or I'm just confused.
>
> "same" is protected with [ "$verboase" ] only on the tag side
> but not on the head side, which I think is a bug. Will fix.
...like this.
---
diff --git a/git-fetch.sh b/git-fetch.sh
index 69bd810..6ee755c 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -166,7 +166,7 @@ fast_forward_local () {
mb=$(git-merge-base "$local" "$2") &&
case "$2,$mb" in
$local,*)
- echo >&2 "* $1: same as $3"
+ [ "$verbose" ] && echo >&2 "* $1: same as $3"
;;
*,$local)
echo >&2 "* $1: fast forward to $3"
^ permalink raw reply related
* Re: More verbose "git fetch"?
From: Junio C Hamano @ 2006-06-04 5:28 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0606031809550.5498@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Has it always spit out those annoying
>
> xyz: same as branch 'xyz' of so-and-so-repo
>
> even without "-v"? I thought I killed them at some point, but
> either they're back, or I'm just confused.
"same" is protected with [ "$verboase" ] only on the tag side
but not on the head side, which I think is a bug. Will fix.
^ permalink raw reply
* Using subversion tools on Mozilla CVS
From: Jon Smirl @ 2006-06-04 3:09 UTC (permalink / raw)
To: git
I found this tool written in Python for importing CVS into Subversion.
It seems to be handling the Mozilla CVS repository with fewer problems
than parsecvs.
http://cvs2svn.tigris.org/cvs2svn.html
Since I'm not a native Python speaker, anyone else want to give a try
at changing it to support git?
It found these symbols to be ambiguous, so I manually forced them the
way they look like they should be.
cvs2svn --trunk-only -s svntest \
--force-tag=THUNDERBIRD_0_7_RELEASE --force-tag=CVS \
--force-branch=JAVADEV_RTM_20001102 \
--force-branch=XPCOM_BRANCH_LANDING_981104 \
--force-branch=MOZILLA_1_3_BRANCH \
--force-branch=N3 \
--force-branch=SeaMonkey_M4_BRANCH \
--force-branch=NORMANDY_BRANCH \
--force-branch=FASTLOAD_20010529_BRANCH \
--force-branch=MozillaSourceClassic_19981026_BRANCH \
--force-branch=RDF_19981124_BRANCH \
--force-branch=OTIS_TEST_BRANCH \
--force-branch=Netscape61_PR1_Mini_BRANCH \
--force-branch=XPCOM20_BRANCH \
--force-branch=XPC_IDISP_20020417_BRANCH \
--force-branch=RDF_122898_BRANCH \
--force-branch=MOZILLA_1_4_BRANCH \
--force-branch=Netscape_20000922_BRANCH \
--force-branch=NETSCAPE_7_0_OEM_BRANCH \
--force-branch=RDF_19990407_BRANCH \
--force-branch=ALERT_SERVICE_BRANCH \
--force-branch=SeaMonkey_M12_BRANCH \
--force-branch=SpiderMonkey140_NES40Rtm_Branch \
mozilla/mozilla
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: gitk on Windows: layout problem
From: Martin Langhoff @ 2006-06-04 2:30 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, git
In-Reply-To: <Pine.LNX.4.63.0605302121410.11532@wbgn013.biozentrum.uni-wuerzburg.de>
On 5/31/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> This is a known problem. See
>
> http://article.gmane.org/gmane.comp.version-control.git/18209
Indeed. MacOSX has the same problem, and that patch "fixes" it too.
It's a bit of a hack but I think it should be merged in, conditional
on OS naturally.
cheers,
m
^ permalink raw reply
* Re: Importing Mozilla CVS into git
From: Bertrand Jacquin @ 2006-06-04 2:24 UTC (permalink / raw)
To: Linus Torvalds
Cc: Robin Rosenberg (list subscriber), Martin Langhoff, Jon Smirl,
Keith Packard, git
In-Reply-To: <Pine.LNX.4.64.0606031631480.5498@g5.osdl.org>
On 6/4/06, Linus Torvalds <torvalds@osdl.org> wrote:
>
>
> On Sun, 4 Jun 2006, Robin Rosenberg (list subscriber) wrote:
> >
> > (Yet) Another problem is that many windows tools use CR LF as the line ending.
> > Almost all windows editors default to CRLF and some detect existing line
> > endings. No editing with notepad anymore. Of course that is a problem
> > regardless of whether a git or cvs client is used. You'll get these big
> > everything-changed commits that alter between CRLF and LF.
>
> The only sane approach there (if you want to be at all cross-platform) is
> to just force everybody to _commit_ in UNIX '\n'-only format. Especially
> as most Windows tools probably handle that fine on reading (just have
> trouble writing them).
>
> And that shouldn't actually be that hard to do. The most trivial approach
> is to have just a pre-trigger on commits, but let's face it, that would
> not be a good "full" solution. A better one is to just make the whole
> "git update-index" thing just have a "automatically ignore CR/LF" mode.
>
> Which really shouldn't be that hard. I think it's literally a matter of
> teaching "index_fd()" in sha1_file.c to recognize text-files, and remove
> CR/LF from them. All done (except to add the flag that enables the
> detection, of course - just so that sane systems won't have the overhead
> or the "corrupt binary files" issue).
>
> Something like this is TOTALLY UNTESTED!
>
> (You also need to teach "diff" to ignore differences in cr/lf, and this
> patch is bad because it's unconditional, and probably doesn't work
> anyway, but hey, the idea is possibly sound. Maybe)
Is it also apply for binary files ? It could corrupt files as well.
If end-user application don't understand '\n' but '\r\n', you can have
bad issues (I think to notepad here (yes crappy, but ..)). Couldn't it
be configurable ?
--
# Beber : beber@gna.org
# IM : beber@jabber.fr
# http://guybrush.ath.cx, irc://irc.freenode.net/#{e.fr,gentoofr}
^ permalink raw reply
* Re: [PATCH 0/27] Documentation: Spelling fixes
From: Horst von Brand @ 2006-06-04 2:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Horst.H.von.Brand, git
In-Reply-To: <7vk67xenfe.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Most do not seem to be typoes, depending on where you learned
> the language (XYZour vs XYZor; ok, Ok, and OK; ie vs i.e.). I
> favour the latter two changes myself, but honestly, I do not
> deeply care that much. The rest are real typos.
>
> It seems that 1/27 did not make here, nor either of the two big
> mailing list archives (gmane and marc).
Just resent it alone.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply
* Re: Gitk feature - show nearby tags
From: Paul Mackerras @ 2006-06-04 1:59 UTC (permalink / raw)
To: Marco Costalba; +Cc: Junio C Hamano, git, Jonas Fonseca
In-Reply-To: <e5bfff550606030416s2ef6182crbde1395dd29e5b94@mail.gmail.com>
Marco Costalba writes:
> If I have understood correctly the patch runs a 'git rev-list --all
> --topo-order --parents'
> and then does a tree walking.
Yes, that's right. It means that gitk can show the nearest tags even
if they aren't included in the current view.
> I am wandering if there exist any native git way to found the previous tag.
I don't know of any. Doing the tree walking in Tcl turned out to be
not too much of an overhead, though; it does the whole kernel
repository in 1.5 seconds on my G5.
> As example given a selected revision with id <sha> is it possible to
> do something like this to fond the ancestor?
>
> 1) get the tag list with git-peek-remote or something similar if tags
> are not already loaded
>
> 2) given the tagList vector with n elements run
>
> git-rev-list --topo-order <sha> ^tagList[0] ^tagList[1] ....
> ^tagList[n-1]
>
> 3) take the last sha spit out by git-rev-list, be it <lastSha>.
>
> 4) Previous nearest tag is the parent of lastSha
>
> I've missed something?
I'm not sure exactly what that would do, but gitk can show more than
one tag (the term "nearest tag" is only a shorthand approximation for
what it does). For example, if you have two tagged commits where
neither is an ancestor of the other, and do a merge of the two, gitk
will show both tags when you select the merge. It doesn't actually
happen in the kernel repository, though, because the tags there form a
linear list (at least the tags in the upstream repository do).
Paul.
^ permalink raw reply
* Re: Gitk feature - show nearby tags
From: Paul Mackerras @ 2006-06-04 1:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy7wedvyx.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano writes:
> That would be useful I think.
Done. It was pretty easy with the infrastructure for doing the tags
in place.
> Yes, but I rarely if ever pull "next" as a whole into "master".
I see. In that case it probably would be good if you pulled the gitk
"new" branch into "next".
Paul.
^ permalink raw reply
* More verbose "git fetch"?
From: Linus Torvalds @ 2006-06-04 1:11 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
Is it just me who has been getting less accepting, or has "git fetch"
gotten more verbose?
Has it always spit out those annoying
xyz: same as branch 'xyz' of so-and-so-repo
even without "-v"? I thought I killed them at some point, but
either they're back, or I'm just confused.
Linus
^ permalink raw reply
* Re: [PATCH 0/27] Documentation: Spelling fixes
From: Junio C Hamano @ 2006-06-04 1:09 UTC (permalink / raw)
To: Horst.H.von.Brand; +Cc: git
In-Reply-To: <33723.2579863214$1149366476@news.gmane.org>
Thanks.
Most do not seem to be typoes, depending on where you learned
the language (XYZour vs XYZor; ok, Ok, and OK; ie vs i.e.). I
favour the latter two changes myself, but honestly, I do not
deeply care that much. The rest are real typos.
It seems that 1/27 did not make here, nor either of the two big
mailing list archives (gmane and marc).
^ permalink raw reply
* git clone takes ages on a slow link
From: Anton Blanchard @ 2006-06-04 1:01 UTC (permalink / raw)
To: git
Hi,
I tried cloning a local repository when connected over a slow (1 second+
latency) link. It took forever (I gave up after 10 minutes). If I ran
it in the background it took a few seconds.
I think the ticker is over anxious.
# git clone -l linux-2.6 linux-2.6-test
0 blocks
Checking files out...
5% (1060/19552) done <---- performance bottleneck
Anton
^ permalink raw reply
* Re: git daemon directory munging?
From: Linus Torvalds @ 2006-06-04 0:42 UTC (permalink / raw)
To: Jon Loeliger; +Cc: git
In-Reply-To: <E1FmgFV-0001i6-Kc@jdl.com>
On Sat, 3 Jun 2006, Jon Loeliger wrote:
>
> <jdl> Thus, I'd use something like:
> --map-base=www.foo.com/pub/scm:/pub/foo/scm
> --map-base=www.bar.com/pub/scm=/pub/bar/scm
The bigger problem is that nothing actually passes in the hostname to
git-daemon in the first place. By the time the git-daemon is contacted,
the hostname is long gone ;(
Now, you can just extend the git protocol to just pass in the host too.
You can in fact do this in a backwards-compatible manner (old git-daemons
will just ignore it, and new git daemons will automatically notice new
clients) with something evil like the appended.
Not tested (and this actualyl doesn't make the daemon _use_ the data, it
just adds a comment - the rest "is left as an exercise for the reader")
Linus
---
diff --git a/connect.c b/connect.c
index 54f7bf7..36c5d04 100644
--- a/connect.c
+++ b/connect.c
@@ -374,7 +374,7 @@ static int git_tcp_connect(int fd[2], co
fd[0] = sockfd;
fd[1] = sockfd;
- packet_write(sockfd, "%s %s\n", prog, path);
+ packet_write(sockfd, "%s %s%c%s%c%s\n", prog, path, 0, host, 0, port);
return 0;
}
diff --git a/daemon.c b/daemon.c
index 776749e..61e0af9 100644
--- a/daemon.c
+++ b/daemon.c
@@ -267,7 +267,7 @@ static int upload(char *dir)
static int execute(void)
{
static char line[1000];
- int len;
+ int len, n;
alarm(init_timeout ? init_timeout : timeout);
len = packet_read_line(0, line, sizeof(line));
@@ -276,6 +276,14 @@ static int execute(void)
if (len && line[len-1] == '\n')
line[--len] = 0;
+ n = strlen(line);
+ if (n != len) {
+ /* Cool, we have hidden info at the end */
+ /* Parse the hostname and the port, and */
+ /* leave some room for expansion for */
+ /* the future .. */
+ }
+
if (!strncmp("git-upload-pack ", line, 16))
return upload(line+16);
^ permalink raw reply related
* git daemon directory munging?
From: Jon Loeliger @ 2006-06-04 0:13 UTC (permalink / raw)
To: git
Scrapped right off the #git IRC channel...
<jdl> I stumbled across some git-daemon quirk for which I'd like opinions on
possible solutions. [18:56]
<jdl> I run a server that houses multiple virtual hosts on one physical
machine.
<jdl> It has multiple Apache based websites on it, and I want to front
multiple git repositories with gitweb. That all works fine. [18:57]
<jdl> But when I set up my repository stores, ie the /pub/scm/repo.git places,
it falls apart.
<jdl> I want to maintain separate sets of git repos for each virtual site.
[18:58]
<jdl> That is, www.foo.com can't see the repos of www.bar.com and vice versa.
<jdl> So I have an Apache directory set up that maps www.foo.com/pub/scm to
some place like /pub/foo/scm using an alias for /pub/scm. [18:59]
<jdl> Similarly, for www.bar.com I map /pub/scm to /pub/bar/scm
<jdl> Now, when I clone using http: all is well as it correctly maps the URL
using the Apache Alias entry. [19:00]
<jdl> However, when cloning via git: it doesn't do the Alias mapping based on
the given website prefix part of the URL.
<jdl> I would have to clone using git://www.foo.com/pub/foo/scm even though I
would clone using http://www.foo.com/pub/scm/ [19:01]
<jdl> So my proposed solution is to setup a genarlization of the git-daemon
-baser-path=path argument.
<jdl> Instead of a single --base-path, there are potentially multiple
--base-path entries that match multiple a URL prefixes. [19:02]
<jdl> Thus, I'd use something like:
--map-base=www.foo.com/pub/scm:/pub/foo/scm
--map-base=www.bar.com/pub/scm=/pub/bar/scm [19:04]
<dormando> mod_rewrite for git :|
<jdl> Quick prefix hack, yeah. [19:05]
<jdl> Um, stop me before I hack....? :-) [19:06]
<dormando> you're going to end up needing something that supports basic
regexes before long
<dormando> I can't think of many cases where you'd want to directly map like
that, and especially in that specific manner. [19:07]
<jdl> I can't hear you.
<dormando> sorry.
* dormando was going to have similar problems for his hosting service
^ permalink raw reply
* Re: [PATCH] Cleanup git-send-email.perl:extract_valid_email
From: Horst von Brand @ 2006-06-04 0:10 UTC (permalink / raw)
To: Eric Wong; +Cc: Horst H. von Brand, git, Junio C Hamano, Ryan Anderson
In-Reply-To: <20060603224935.GA10324@hand.yhbt.net>
Eric Wong <normalperson@yhbt.net> wrote:
> "Horst H. von Brand" <vonbrand@inf.utfsm.cl> wrote:
> > - Fix the regular expressions for local addresses
> > - Fix the fallback regexp for non-local addresses, simplify the logic
> >
> > Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl>
> > ---
> > git-send-email.perl | 9 +++------
> > 1 files changed, 3 insertions(+), 6 deletions(-)
> >
> > diff --git a/git-send-email.perl b/git-send-email.perl
> > index ed1d89b..a7a7797 100755
> > --- a/git-send-email.perl
> > +++ b/git-send-email.perl
> > @@ -314,18 +314,15 @@ sub extract_valid_address {
> > my $address = shift;
> >
> > # check for a local address:
> > - return $address if ($address =~ /^([\w\-]+)$/);
> > + return $address if ($address =~ /^([\w\-.]+)$/);
>
> I keep forgetting this, '+' is a valid (and useful) setup, too.
Oops...
> > if ($have_email_valid) {
> > return Email::Valid->address($address);
> > } else {
> > # less robust/correct than the monster regexp in Email::Valid,
> > # but still does a 99% job, and one less dependency
> > - my $cleaned_address;
> > - if ($address =~ /([^\"<>\s]+@[^<>\s]+)/) {
> > - $cleaned_address = $1;
> > - }
> > - return $cleaned_address;
> > + $address =~ /([\w\-.]+@[\w\-.]+)/;
> > + return $1;
>
> Actually, I'm retracting my earlier ack on this. This is way too
> restrictive. I'd rather allow an occasional invalid email address than
> to reject valid ones. I generally trust git users to know what they're
> doing when entering email addresses[1].
>
> *, $, ^, +, = are all valid characters in the username portion (not sure
> about local accounts, though), and I'm sure there are more that I don't
> know about.
As a general principle, I prefer to check what is legal instead of trying
to filter out what isn't.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply
* Re: Importing Mozilla CVS into git
From: Linus Torvalds @ 2006-06-03 23:47 UTC (permalink / raw)
To: Robin Rosenberg (list subscriber)
Cc: Martin Langhoff, Jon Smirl, Keith Packard, git
In-Reply-To: <200606040116.38036.robin.rosenberg.lists@dewire.com>
On Sun, 4 Jun 2006, Robin Rosenberg (list subscriber) wrote:
>
> (Yet) Another problem is that many windows tools use CR LF as the line ending.
> Almost all windows editors default to CRLF and some detect existing line
> endings. No editing with notepad anymore. Of course that is a problem
> regardless of whether a git or cvs client is used. You'll get these big
> everything-changed commits that alter between CRLF and LF.
The only sane approach there (if you want to be at all cross-platform) is
to just force everybody to _commit_ in UNIX '\n'-only format. Especially
as most Windows tools probably handle that fine on reading (just have
trouble writing them).
And that shouldn't actually be that hard to do. The most trivial approach
is to have just a pre-trigger on commits, but let's face it, that would
not be a good "full" solution. A better one is to just make the whole
"git update-index" thing just have a "automatically ignore CR/LF" mode.
Which really shouldn't be that hard. I think it's literally a matter of
teaching "index_fd()" in sha1_file.c to recognize text-files, and remove
CR/LF from them. All done (except to add the flag that enables the
detection, of course - just so that sane systems won't have the overhead
or the "corrupt binary files" issue).
Something like this is TOTALLY UNTESTED!
(You also need to teach "diff" to ignore differences in cr/lf, and this
patch is bad because it's unconditional, and probably doesn't work
anyway, but hey, the idea is possibly sound. Maybe)
Linus
---
diff --git a/sha1_file.c b/sha1_file.c
index aea0f40..6dc6a3f 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1740,9 +1740,30 @@ int index_pipe(unsigned char *sha1, int
return ret;
}
+static unsigned long autodetect_crlf(unsigned char *src, unsigned long size)
+{
+ unsigned long newsize = 0;
+ unsigned char *dst = src;
+ unsigned char last = 0;
+
+ while (size) {
+ unsigned char c = *src++;
+ if (last == '\r' && c == '\n') {
+ dst[-1] = '\n';
+ } else {
+ newsize++;
+ dst++;
+ if (dst != src)
+ dst[-1] = c;
+ }
+ last = c;
+ }
+ return newsize;
+}
+
int index_fd(unsigned char *sha1, int fd, struct stat *st, int write_object, const char *type)
{
- unsigned long size = st->st_size;
+ unsigned long size = st->st_size, use_size;
void *buf;
int ret;
unsigned char hdr[50];
@@ -1755,12 +1776,15 @@ int index_fd(unsigned char *sha1, int fd
if (buf == MAP_FAILED)
return -1;
- if (!type)
+ use_size = size;
+ if (!type) {
type = blob_type;
+ use_size = autodetect_crlf(buf, size);
+ }
if (write_object)
- ret = write_sha1_file(buf, size, type, sha1);
+ ret = write_sha1_file(buf, use_size, type, sha1);
else {
- write_sha1_file_prepare(buf, size, type, sha1, hdr, &hdrlen);
+ write_sha1_file_prepare(buf, use_size, type, sha1, hdr, &hdrlen);
ret = 0;
}
if (size)
^ permalink raw reply related
* Re: Importing Mozilla CVS into git
From: Robin Rosenberg (list subscriber) @ 2006-06-03 23:16 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Jon Smirl, Keith Packard, git
In-Reply-To: <46a038f90606012116t478edacex72a441544f395af4@mail.gmail.com>
fredag 02 juni 2006 06:16 skrev Martin Langhoff:
> On 6/2/06, Jon Smirl <jonsmirl@gmail.com> wrote:
> > It is going to have to be native Windows to move some of the
> > developers over. They are true blue MS types that won't touch anything
> > close to Unix so cygwin is out.
That could be fixed with nice packaging since many CVS users in Windows
never use a command line anyway since TortoiseCVS is so nice.
> As others have pointed out, you have git-cvsserver which emulates a
> CVS server on top of GIT, so it can be used with (almost any) CVS
> client. They will be 2nd class citizens however...
(Yet) Another problem is that many windows tools use CR LF as the line ending.
Almost all windows editors default to CRLF and some detect existing line
endings. No editing with notepad anymore. Of course that is a problem
regardless of whether a git or cvs client is used. You'll get these big
everything-changed commits that alter between CRLF and LF.
-- robin
^ permalink raw reply
* Re: [PATCH] Cleanup git-send-email.perl:extract_valid_email
From: Eric Wong @ 2006-06-03 22:49 UTC (permalink / raw)
To: Horst H. von Brand; +Cc: git, Junio C Hamano, Ryan Anderson
In-Reply-To: <11493547080-git-send-email-vonbrand@inf.utfsm.cl>
"Horst H. von Brand" <vonbrand@inf.utfsm.cl> wrote:
> - Fix the regular expressions for local addresses
> - Fix the fallback regexp for non-local addresses, simplify the logic
>
> Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl>
> ---
> git-send-email.perl | 9 +++------
> 1 files changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/git-send-email.perl b/git-send-email.perl
> index ed1d89b..a7a7797 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -314,18 +314,15 @@ sub extract_valid_address {
> my $address = shift;
>
> # check for a local address:
> - return $address if ($address =~ /^([\w\-]+)$/);
> + return $address if ($address =~ /^([\w\-.]+)$/);
I keep forgetting this, '+' is a valid (and useful) setup, too.
>
> if ($have_email_valid) {
> return Email::Valid->address($address);
> } else {
> # less robust/correct than the monster regexp in Email::Valid,
> # but still does a 99% job, and one less dependency
> - my $cleaned_address;
> - if ($address =~ /([^\"<>\s]+@[^<>\s]+)/) {
> - $cleaned_address = $1;
> - }
> - return $cleaned_address;
> + $address =~ /([\w\-.]+@[\w\-.]+)/;
> + return $1;
Actually, I'm retracting my earlier ack on this. This is way too
restrictive. I'd rather allow an occasional invalid email address than
to reject valid ones. I generally trust git users to know what they're
doing when entering email addresses[1].
*, $, ^, +, = are all valid characters in the username portion (not sure
about local accounts, though), and I'm sure there are more that I don't
know about.
[1] - of course, without address book support in git-send-email, I think
I would've left the 'k' out of Junio's email address by now. Of course
there's also the issue of where I work and having several people using
variations of rob/robert in their email address. I'm likely to make
errors like these far more than entering addresses that email systems
consider invalid, and I suspect I'm not the only one.
--
Eric Wong
^ permalink raw reply
* Re: [PATCH 0/27] Documentation: Spelling fixes
From: Jakub Narebski @ 2006-06-03 20:52 UTC (permalink / raw)
To: git
In-Reply-To: <33723.2579863214$1149366476@news.gmane.org>
Horst.H.von.Brand@inf.utfsm.cl wrote:
> From: Horst H. von Brand <vonbrand@inf.utfsm.cl>
>
> Result of a run of aspell(1) over the *.txt files in Documentation. Also
> fixed several other typoes.
Some of them (behavior vs. behaviour) are just the difference between
American nad British English. And couldn't do that all in _one_ patch?
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* [PATCH 24/27] Documentation: Spelling fixes
From: Horst.H.von.Brand @ 2006-06-03 20:27 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Horst H. von Brand
In-Reply-To: <11493665101874-git-send-email->
From: Horst H. von Brand <vonbrand@inf.utfsm.cl>
Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl>
---
Documentation/git-update-index.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt
index d043e86..3ae6e74 100644
--- a/Documentation/git-update-index.txt
+++ b/Documentation/git-update-index.txt
@@ -40,7 +40,7 @@ OPTIONS
--remove::
If a specified file is in the index but is missing then it's
removed.
- Default behaviour is to ignore removed file.
+ Default behavior is to ignore removed file.
--refresh::
Looks at the current index and checks to see if merges or
--
1.3.3.g86f7
^ permalink raw reply related
* [PATCH 27/27] Documentation: Spelling fixes
From: Horst.H.von.Brand @ 2006-06-03 20:27 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Horst H. von Brand
In-Reply-To: <11493665173464-git-send-email->
From: Horst H. von Brand <vonbrand@inf.utfsm.cl>
Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl>
---
Documentation/tutorial.txt | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
index 039a859..db56312 100644
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -194,7 +194,7 @@ Bob begins with:
This creates a new directory "myrepo" containing a clone of Alice's
repository. The clone is on an equal footing with the original
-project, posessing its own copy of the original project's history.
+project, possessing its own copy of the original project's history.
Bob then makes some changes and commits them:
@@ -240,7 +240,7 @@ of Bob's line of development without doi
shows a list of all the changes that Bob made since he branched from
Alice's master branch.
-After examing those changes, and possibly fixing things, Alice can
+After examining those changes, and possibly fixing things, Alice can
pull the changes into her master branch:
-------------------------------------
@@ -374,7 +374,7 @@ project, so
$ git grep "hello" v2.5
-------------------------------------
-searches for all occurences of "hello" in v2.5.
+searches for all occurrences of "hello" in v2.5.
If you leave out the commit name, git grep will search any of the
files it manages in your current directory. So
@@ -482,6 +482,6 @@ digressions that may be interesting at t
smart enough to perform a close-to-optimal search even in the
case of complex non-linear history with lots of merged branches.
- * link:everyday.html[Everday GIT with 20 Commands Or So]
+ * link:everyday.html[Everyday GIT with 20 Commands Or So]
* link:cvs-migration.html[git for CVS users].
--
1.3.3.g86f7
^ permalink raw reply related
* [PATCH 26/27] Documentation: Spelling fixes
From: Horst.H.von.Brand @ 2006-06-03 20:27 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Horst H. von Brand
In-Reply-To: <1149366517875-git-send-email->
From: Horst H. von Brand <vonbrand@inf.utfsm.cl>
Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl>
---
Documentation/tutorial-2.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/tutorial-2.txt b/Documentation/tutorial-2.txt
index 9c9500c..82c6922 100644
--- a/Documentation/tutorial-2.txt
+++ b/Documentation/tutorial-2.txt
@@ -49,7 +49,7 @@ tree
A tree can refer to one or more "blob" objects, each corresponding to
a file. In addition, a tree can also refer to other tree objects,
-thus creating a directory heirarchy. You can examine the contents of
+thus creating a directory hierarchy. You can examine the contents of
any tree using ls-tree (remember that a long enough initial portion
of the SHA1 will also work):
--
1.3.3.g86f7
^ permalink raw reply related
* [PATCH 22/27] Documentation: Spelling fixes
From: Horst.H.von.Brand @ 2006-06-03 20:27 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Horst H. von Brand
In-Reply-To: <11493665032900-git-send-email->
From: Horst H. von Brand <vonbrand@inf.utfsm.cl>
Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl>
---
Documentation/git-sh-setup.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-sh-setup.txt b/Documentation/git-sh-setup.txt
index 6742c9b..79217d8 100644
--- a/Documentation/git-sh-setup.txt
+++ b/Documentation/git-sh-setup.txt
@@ -13,7 +13,7 @@ DESCRIPTION
-----------
Sets up the normal git environment variables and a few helper functions
-(currently just "die()"), and returns ok if it all looks like a git archive.
+(currently just "die()"), and returns OK if it all looks like a git archive.
So, to make the rest of the git scripts more careful and readable,
use it as follows:
--
1.3.3.g86f7
^ permalink raw reply related
* [PATCH 25/27] Documentation: Spelling fixes
From: Horst.H.von.Brand @ 2006-06-03 20:27 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Horst H. von Brand
In-Reply-To: <11493665112903-git-send-email->
From: Horst H. von Brand <vonbrand@inf.utfsm.cl>
Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl>
---
Documentation/hooks.txt | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/hooks.txt b/Documentation/hooks.txt
index 3824a95..e853b93 100644
--- a/Documentation/hooks.txt
+++ b/Documentation/hooks.txt
@@ -100,7 +100,7 @@ update
This hook is invoked by `git-receive-pack` on the remote repository,
which is happens when a `git push` is done on a local repository.
Just before updating the ref on the remote repository, the update hook
-is invoked. It's exit status determins the success or failure of
+is invoked. It's exit status determines the success or failure of
the ref update.
The hook executes once for each ref to be updated, and takes
@@ -151,7 +151,7 @@ so it is a poor place to do log old..new
The default post-update hook, when enabled, runs
`git-update-server-info` to keep the information used by dumb
-transports (eg, http) up-to-date. If you are publishing
+transports (e.g.,, http) up-to-date. If you are publishing
a git repository that is accessible via http, you should
probably enable this hook.
--
1.3.3.g86f7
^ 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