Re: [PATCH/RFC] git-blame.el: truncate author to avoid jagged left edge of code
Sorry for being absent a long time. I hope you have managed to sort out the git-blame fixes anyway. Jonathan Nieder writes: >Without this patch, the author column in git-blame-mode spills >over in some rows: > > 822a7d :const char git_usage_ > f2dd8c : "git [--version] [--exec- > a1bea2 : " [-p|--paginat > a1bea2 : " [--git-dir= 293b07 : " [-c name=valu > 62b469 :" 822a7d : > >As a result, code meant to line up does not line up correctly and the >colored code area has a jagged left edge. > >Specify a maximum width for the autohr email address in the default >blame prefix (i.e., use %20.20A instead of %20A) to fix it. > > 822a7df2dd8c : "git [--version] [--exec- > >The (format) function used to implement format-spec has supported >precision specifiers like ".20" in emacs since 2002-12-09, so this >should be safe. > >Helped-by: Kevin Ryde >Signed-off-by: Jonathan Nieder >--- >In February of 2011, I wrote: > >> - email addresses are often longer than 20 characters. Does >>format-spec provide a way to truncate to a certain length, >>so the prefixes can line up? > >Better late than never, I guess. Sensible? > > contrib/emacs/git-blame.el |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >diff --git a/contrib/emacs/git-blame.el b/contrib/emacs/git-blame.el >index d351cfb6..137d5ba9 100644 >--- a/contrib/emacs/git-blame.el >+++ b/contrib/emacs/git-blame.el >@@ -102,7 +102,7 @@ > :group 'git-blame) > > (defcustom git-blame-prefix-format >- "%h %20A:" >+ "%h %20.20A:" > "The format of the prefix added to each line in `git-blame' > mode. The format is passed to `format-spec' with the following format keys: -- David Kågedal -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Added an option to cvsimport to specify email domain
The authorship info in commits created by git-cvsimport-script
only contains the username of the CVS committer. This patch
adds a flag -e to git-cvsimport-script that makes it
possible to specify an email domain that is added to all email
addresses in the commit "author" and "committer" fields.
---
I have stopped using cvsimport, because cvsps seems to produce bad
output on the repository I'm using it with, but I had already prepared
this patch.
Documentation/git-cvsimport-script.txt |8 +++-
git-cvsimport-script | 18 +-
2 files changed, 20 insertions(+), 6 deletions(-)
cabbc2b5cae2dcd892d02a3c679698cdfb3b9de5
diff --git a/Documentation/git-cvsimport-script.txt
b/Documentation/git-cvsimport-script.txt
--- a/Documentation/git-cvsimport-script.txt
+++ b/Documentation/git-cvsimport-script.txt
@@ -12,7 +12,9 @@ SYNOPSIS
'git-cvsimport-script' [ -o ] [ -h ] [ -v ]
[ -d ] [ -p ]
[ -C ] [ -i ] [ -k ]
- [ -s ] [ -m ] [ -M regex ] [ ]
+ [ -s ] [ -m ] [ -M regex ]
+ [ -e ]
+ [ ]
DESCRIPTION
@@ -86,6 +88,10 @@ OPTIONS
-s ::
Substitute the character "/" in branch names with
+-e ::
+Append '@' to the author name to use as the email
+address in commit objects.
+
OUTPUT
--
If '-v' is specified, the script reports what it is doing.
diff --git a/git-cvsimport-script b/git-cvsimport-script
--- a/git-cvsimport-script
+++ b/git-cvsimport-script
@@ -29,19 +29,20 @@ use IPC::Open2;
$SIG{'PIPE'}="IGNORE";
$ENV{'TZ'}="UTC";
-our($opt_h,$opt_o,$opt_v,$opt_k,$opt_u,$opt_d,$opt_p,$opt_C,$opt_z,$opt_i,$opt_s,$opt_m,$opt_M);
+our($opt_h,$opt_o,$opt_v,$opt_k,$opt_u,$opt_d,$opt_p,$opt_C,$opt_z,$opt_i,$opt_s,$opt_m,$opt_M,$opt_e);
sub usage() {
print STDERR
Re: Tool renames? was Re: First stab at glossary
Junio C Hamano <[EMAIL PROTECTED]> writes: > Linus Torvalds <[EMAIL PROTECTED]> writes: > >> What's the upside? >> >> I can point to one downside: "git". That script right now is simple. If >> you rewrite git-cvsimport-script from shell to perl, it looks the same to >> git. > > What I've been working on was to: > > * have git-cvsimport.perl in the source > > * install it as $(bindir)/git-cvsimport That was what I suggested too, although I don't really care if it's called .perl or -script in the source. By the way, I'm not sure how the 'git' script is supposed to be used. I know that if there is a git-foo-script file in your path, you can run it as 'git foo'. But what about e.g. git-init-db? You can run that as 'git init-db' today. And 'git read-cache' should work too. And 'git ls-files', and 'git rev-parse', and 'git merge-one-file' and 'git sh-setup-script' in decreasing order of usefulness... But running 'git' without arguments only list the -script commands as available. -- David Kågedal - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Tool renames? was Re: First stab at glossary
Linus Torvalds <[EMAIL PROTECTED]> writes: > On Mon, 5 Sep 2005, David Kågedal wrote: >> >> But to the users (like myself), there's no point in naming it by >> whether it's a script or a binary. > > So? There's no downside. > > To you, as a user, you never see the "-script" ending anyway. You'd never > type it out, or you're already doing something wrong. Then I'm doing something wrong. And I'm pretty sure others are too. If I'm not supposed to see the "-script" ending, then don't install it in my $PATH. Until someone (possibly myself) writes some zsh completion code to handle git sub command, I will continue to hit TAB and see all those names. Furthermore, the man page for "git clone" is called "git-clone-script(1)". And the "-script" suffix appears inside the documentation in various places. I see it in howtos and log messages. And the git-merge-one-file-script script is supposed to be used in a way where I have to supply the long name. Etc. If the "-script" part is supposed to be hidden from me, why do I keep seeing it everywhere I turn? > So to users it doesn't matter, and to developers it _does_ matter (and > calling them ".pl" or ".sh" or something would be _bad_), why not please > the developers? I'm not suggesting we'd call them ".pl" or ".sh". -- David Kågedal - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Tool renames? was Re: First stab at glossary
Linus Torvalds <[EMAIL PROTECTED]> writes: > On Sun, 4 Sep 2005, Horst von Brand wrote: >> > I had the same opinion. The counter-argument people raised when >> > this topic came up on the list was that it would help grepping >> > in the source tree. >> >> Grepping for what? > > Grepping for strings. > > For example, when renaming a binary, the sane way to check that you fixed > all users right now is > > grep old-binary-name *.c *.h *-scripts > > and you catch all users. > > In contrast, "grep *" will catch totally uninteresting patterns like > object files etc. > > I personally find that very useful, and I don't see _any_ point to naming > by what _kind_ of interpreter you use. Why would _anybody_ care whether > something is written in perl vs shell? There's no reason to name things by > the interpreter. But to the users (like myself), there's no point in naming it by whether it's a script or a binary. Since, as a user, I couldn't care less that git-foobar is a shell script, I don't want to pollute the command name space with "-script" suffixes. Calling the command git-foobar makes much more sense, and allows us to reimplement the scripts as binaries, or whatever. So your argument that it makes it easier for git developers to work with the source doesn't help the user. The consequence is maybe that the scripts should be called *-script in the source, but be installed without the suffix? -- David Kågedal - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Teach applymbox to keep the Subject: line.
Linus Torvalds <[EMAIL PROTECTED]> writes: > On Wed, 17 Aug 2005, Jeff Garzik wrote: >> >> 1) Fix applymbox such that it understands RFC822-valid Subject lines >> which wrap across multiple text lines. > > It already should do this. > >> 2) Teach it to understand MIME, and not treat the MIME headers like part >> of the message. > > But this one I really realyl disagree with. > > The fact is, anybody who doesn't edit the emails that come in is BROKEN. > There are two kinds of emails: > > - the nicely formatted ones where the author follows all the rules > >This kind of email doesn't need MIME decoding anyway. Unless they want to write something that doesn't fit in ASCII, as discussed in another thread here. But maybe you are only talking about MIME attachments, and not about MIME content encodings? We probably need to separate the two. Note that I'm not really talking about your patch handling for Linux; you are free to disallow my name in Linux patches if you want to. But I'd like to see a way to get rid of that limitation for other uses of git. -- David Kågedal - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fixed two bugs in git-cvsimport-script.
Junio C Hamano <[EMAIL PROTECTED]> writes: > Junio C Hamano <[EMAIL PROTECTED]> writes: > >> Yes, the patch had some context conflicts with some other patch >> so the patch application was done by hand, and I did a quick and >> dirty cut & paste of the commit message from "cat mbox" output. >> >> I will probably drop future patches encoded in QP. > > This was totally inappropriate; sorry, but I was in a bad mood. > > A more serious response. > > - I personally consider commit message encoding a per project >issue (so is blob contents encoding). Agreed. And your response is probably good enough for now. I also think that having UTF-8 as the standard convention is the way to go. -- David Kågedal - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fixed two bugs in git-cvsimport-script.
Junio C Hamano <[EMAIL PROTECTED]> writes: >> Apparently, my mail was encoded as QP, which is not very popular >> around here. But it seems that the diff part was decoded properly >> before applying. Was that done manually? > > Yes, the patch had some context conflicts with some other patch > so the patch application was done by hand, and I did a quick and > dirty cut & paste of the commit message from "cat mbox" output. > > I will probably drop future patches encoded in QP. Ok, but do you have an answer to my real question? What is the character encoding for commit objects in your git repository? It is obviously one that is compatible with ASCII, which probably leaves you with the alternatives ASCII, Latin1, and UTF-8. And plain ASCII obviously doesn't work very well for me. -- David Kågedal - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fixed two bugs in git-cvsimport-script.
David Kågedal <[EMAIL PROTECTED]> writes: > The git-cvsimport-script had a copule of small bugs that prevented me > from importing a big CVS repository. > > The first was that it didn't handle removed files with a multi-digit > primary revision number. I noticed that this patch was accepted, which is great. But there is a problem with the character encoding in the commit message. The commit in question is b0921331030d52febf52839753eee1b2b9ca1f24 The "author" field is written as "iso-8859-1?Q?David_K=E5gedal <[EMAIL PROTECTED]>", which is taken from the "From:" line in my email. This should be decoded by the patch import script before generating the commit message. But the trickier question is what encoding to use in the commit message. This is the signed-off line in my mail: Signed-off-by: David Kågedal <[EMAIL PROTECTED]> This is what appears in the commit: Signed-off-by: David K?5gedal <[EMAIL PROTECTED]> Using ISO-8859-15 or UTF-8 would probably have made more sense here. Apparently, my mail was encoded as QP, which is not very popular around here. But it seems that the diff part was decoded properly before applying. Was that done manually? Since my name contains a character that is not part of ASCII, it isn't really an option to send the mails encoded as ASCII. I could probably convince my mailer (Gnus) to send it as "8bit" or "binary", but that is a pretty limited solution. An it isn't even legal to use anything but ASCII in the mail header. -- David Kågedal - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Importing from CVS issues
Alex Bennee <[EMAIL PROTECTED]> writes: > Before the import script finally dies with: > > WARNING: revision 1.3.2.1 of file > scripts/xmltools/t/data/gzip/DO-NOT-BACKUP on unnamed branch > DONE; creating master branch > cp: cannot stat `/export/test/cvstogit/.git/refs/heads/origin': No such > file or directory Was this done with an empty destination dir? I've seen similar things happen in a dir where an interrupted cvs import was done previously, and the 'origin' branch was never created. -- David Kågedal - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Fixed two bugs in git-cvsimport-script.
The git-cvsimport-script had a copule of small bugs that prevented me
from importing a big CVS repository.
The first was that it didn't handle removed files with a multi-digit
primary revision number.
The second was that it was asking the CVS server for "F" messages,
although they were not handled.
I also updated the documentation for that script to correspond to
actual flags.
Signed-off-by: David Kågedal <[EMAIL PROTECTED]>
---
Documentation/git-cvsimport-script.txt |9 -
git-cvsimport-script |4 ++--
2 files changed, 10 insertions(+), 3 deletions(-)
50452f9c0c2df1f04d83a26266ba704b13861632
diff --git a/Documentation/git-cvsimport-script.txt
b/Documentation/git-cvsimport-script.txt
--- a/Documentation/git-cvsimport-script.txt
+++ b/Documentation/git-cvsimport-script.txt
@@ -29,6 +29,10 @@ OPTIONS
currently, only the :local:, :ext: and :pserver: access methods
are supported.
+-C ::
+The GIT repository to import to. If the directory doesn't
+exist, it will be created. Default is the current directory.
+
-i::
Import-only: don't perform a checkout after importing. This option
ensures the working directory and cache remain untouched and will
@@ -44,7 +48,7 @@ OPTIONS
-p ::
Additional options for cvsps.
- The options '-x' and '-A' are implicit and should not be used here.
+ The options '-u' and '-A' are implicit and should not be used here.
If you need to pass multiple options, separate them with a comma.
@@ -57,6 +61,9 @@ OPTIONS
-h::
Print a short usage message and exit.
+-z ::
+Pass the timestamp fuzz factor to cvsps.
+
OUTPUT
--
If '-v' is specified, the script reports what it is doing.
diff --git a/git-cvsimport-script b/git-cvsimport-script
--- a/git-cvsimport-script
+++ b/git-cvsimport-script
@@ -190,7 +190,7 @@ sub conn {
$self->{'socketo'}->write("Root $repo\n");
# Trial and error says that this probably is the minimum set
- $self->{'socketo'}->write("Valid-responses ok error Valid-requests Mode
M Mbinary E F Checked-in Created Updated Merged Removed\n");
+ $self->{'socketo'}->write("Valid-responses ok error Valid-requests Mode
M Mbinary E Checked-in Created Updated Merged Removed\n");
$self->{'socketo'}->write("valid-requests\n");
$self->{'socketo'}->flush();
@@ -691,7 +691,7 @@ while() {
unlink($tmpname);
my $mode = pmode($cvs->{'mode'});
push(@new,[$mode, $sha, $fn]); # may be resurrected!
- } elsif($state == 9 and
/^\s+(\S+):\d(?:\.\d+)+->(\d(?:\.\d+)+)\(DEAD\)\s*$/) {
+ } elsif($state == 9 and
/^\s+(\S+):\d+(?:\.\d+)+->(\d+(?:\.\d+)+)\(DEAD\)\s*$/) {
my $fn = $1;
$fn =~ s#^/+##;
push(@old,$fn);
--
David Kågedal
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git-cvs-import-script problems
David Kågedal <[EMAIL PROTECTED]> writes: > I just tried importing a large CVS repository to git, using "git > cvsimport". It managed to import a lot of files and revisions, but > half-way through, it stopped with this message: > > Unknown: F > > As far as I can till, this "F" probably came from the CVS server > process. Could it be that my CVS is too new or too old? Upgrading to CVS 1.12.1 seems to have helped. -- David Kågedal - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
git-cvs-import-script problems
I just tried importing a large CVS repository to git, using "git cvsimport". It managed to import a lot of files and revisions, but half-way through, it stopped with this message: Unknown: F As far as I can till, this "F" probably came from the CVS server process. Could it be that my CVS is too new or too old? I'm using git b03e2d2091153d239063cfc086a840d74a9eadde, cvs 1.11.20, cvsps 2.1, and the CVS repository is a local directory. Also, when the process stops, I have .git/HEAD pointing to refs/heads/master (which doesn't exist). I thought it would be pointing to refs/heads/origin. -- David Kågedal - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
