* Re: [PATCH] Fixed Cygwin CR-munging problem in mailsplit
From: Junio C Hamano @ 2006-05-27 18:25 UTC (permalink / raw)
To: Salikh Zakirov; +Cc: git, Linus Torvalds
In-Reply-To: <7vfyivfhw4.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> I personally think this is a right change. Provided if MTAs on
> the path between patch originator and you are not broken and
> your MUA saved the message with CR/LF distinction in the
> contents intact, this should do more right thing.
>
> I see broken patches every once in a while, but when they are
> mangled by the mailpath, CRLF is the least of the problem; they
> have other whitespace breakage that makes them unapplicable
> anyway.
>
> Having said that, however, that historically used to be a big IF
> with capital letters.
>
>
> I have a feeling that Linus did this on purpose. For the
Heh, I had a trailing CR after the "with capital letters." and
one blank line between paragraphs, but I now see two blank lines
there. So even in this modern day, preserving CRLF is not
something that happens by default -- you would need to make sure
that everybody on your mailpath to the recipient is set up the
right way.
> So I am slightly in favor of the change, but just barely.
So now I am less in favor of the change than when I wrote that
response.
^ permalink raw reply
* Re: [PATCH] Fixed Cygwin CR-munging problem in mailsplit
From: Junio C Hamano @ 2006-05-27 18:21 UTC (permalink / raw)
To: Salikh Zakirov; +Cc: git, Linus Torvalds
In-Reply-To: <44789309.1030002@Intel.com>
Salikh Zakirov <Salikh.Zakirov@Intel.com> writes:
> Do not open mailbox file as fopen(..., "rt")
> as this strips CR characters from the diff,
> thus breaking the patch context for changes
> in CRLF files.
>
> Signed-off-by: Salikh Zakirov <Salikh.Zakirov@Intel.com>
>
> ---
> fd405a0843f3efd474bc7897b06d813d6498fbf4
> diff --git mailsplit.c mailsplit.c
> index c529e2d..70a569c 100644
> --- mailsplit.c
> +++ mailsplit.c
> @@ -162,7 +162,7 @@ int main(int argc, const char **argv)
>
> while (*argp) {
> const char *file = *argp++;
> - FILE *f = !strcmp(file, "-") ? stdin : fopen(file, "rt");
> + FILE *f = !strcmp(file, "-") ? stdin : fopen(file, "r");
> int file_done = 0;
>
> if ( !f )
I personally think this is a right change. Provided if MTAs on
the path between patch originator and you are not broken and
your MUA saved the message with CR/LF distinction in the
contents intact, this should do more right thing.
I see broken patches every once in a while, but when they are
mangled by the mailpath, CRLF is the least of the problem; they
have other whitespace breakage that makes them unapplicable
anyway.
Having said that, however, that historically used to be a big IF
with capital letters.
I have a feeling that Linus did this on purpose. For the
projects we originally cared about, a patch to introduce CRLF
in the tracked content was a broken patch 100% of the time (not
99%), and most likely caused by a breakage somewhere on the
mailpath. At least in the original git context, protecting
UNIX/POSIX people from broken MTA/MUA counted far more than
catering to people who deals with DOSsy contents.
So I am slightly in favor of the change, but just barely.
^ permalink raw reply
* Re: t8001-annotate.sh fails on Mac OS X
From: Nicolas Vilz 'niv' @ 2006-05-27 18:13 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Shawn Pearce, Stefan Pfetzing, Git Mailing List
In-Reply-To: <Pine.LNX.4.63.0605261534270.27610@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin schrieb:
> Hi,
>
> On Thu, 25 May 2006, Shawn Pearce wrote:
>
>> Stefan Pfetzing <stefan.pfetzing@gmail.com> wrote:
>>> for some reason I could not yet figure out, t8001-annotate.sh fails at test
>>> 18.
>> I've been seeing the same failed test case for a long time now on
>> my own Mac OS X system.
>
> ... which is sort of funny, because I don't see it on my system. Running
> an iBook G3 with Mac OS X 10.2.8. "make test" runs through, and no, AFAICT
> I do not have any local modifications which could be responsible for that.
I just tried it on my Powerbook G4 running MacOSX 10.4.6 and failed on
test 18, too.
I am just doing a complete test with make test...
same situation:
* FAIL 18: some edit
check_count A 1 B 1 B1 1 B2 1 "A U Thor" 1 C 1 D 1
* failed 1 among 18 test(s)
make[1]: *** [t8001-annotate.sh] Error 1
make: *** [test] Error 2
I am using the master tree for this test.
Any suggestions?
^ permalink raw reply
* [PATCH] Fixed Cygwin CR-munging problem in mailsplit
From: Salikh Zakirov @ 2006-05-27 17:57 UTC (permalink / raw)
Cc: git
In-Reply-To: <7virnsk6fe.fsf@assigned-by-dhcp.cox.net>
Do not open mailbox file as fopen(..., "rt")
as this strips CR characters from the diff,
thus breaking the patch context for changes
in CRLF files.
Signed-off-by: Salikh Zakirov <Salikh.Zakirov@Intel.com>
---
Junio C Hamano wrote:
>
> git init-db
> echo 'abc@' | tr '[@]' '[\015]' >a
> git add a
> git commit -m initial
> echo 'def@' | tr '[@]' '[\015]' >>a
> git commit -a -m second
> git format-patch HEAD^
> git reset --hard HEAD^
> git am 0*.txt
>
This reproduction scenario results in exactly the same problem.
The problem is observed on Cygwin.
My initial evaluation of the problem turned out to be completely bogus.
I've tracked the problem down to the fopen(file, "rt") in mailsplit.c,
which then truncates the CR character from the patch file.
This changes the patch context lines and it no longer applies.
Changing it to fopen(file, "r") fixes the problem.
> Having said that, CRLF is unsafe for E-mail transfers anyway, so
> I think we would need a special option to tell git-apply that it
> should match '\n' that appears in the patch with '\r\n' in the
> file being patched. But I do not think that has anything to do
> with the breakage you saw in your reproduction recipe.
My use case does not involve e-mail transfers at all.
I'm using git-format-patch and git-am to rewrite the
patch sequence with different commit messages.
Unfortunately, some of my fellow developers are not quite
careful, and occasionally some of the source files acquire
CR characters, sometimes in several lines only.
fd405a0843f3efd474bc7897b06d813d6498fbf4
mailsplit.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
fd405a0843f3efd474bc7897b06d813d6498fbf4
diff --git mailsplit.c mailsplit.c
index c529e2d..70a569c 100644
--- mailsplit.c
+++ mailsplit.c
@@ -162,7 +162,7 @@ int main(int argc, const char **argv)
while (*argp) {
const char *file = *argp++;
- FILE *f = !strcmp(file, "-") ? stdin : fopen(file, "rt");
+ FILE *f = !strcmp(file, "-") ? stdin : fopen(file, "r");
int file_done = 0;
if ( !f )
--
1.3.3.gfd40
^ permalink raw reply
* [PATCH 3/3] Make cvsexportcommit create parent directories as needed.
From: Yann Dirson @ 2006-05-27 16:39 UTC (permalink / raw)
To: junkio; +Cc: git
In-Reply-To: <20060527163641.474.93575.stgit@gandelf.nowhere.earth>
This is a quick port of my initial patch for 1.0.7, that I had forgotten to
post. Possibly needs some testing before applying to master.
Signed-off-by: Yann Dirson <ydirson@altern.org>
---
git-cvsexportcommit.perl | 37 ++++++++++++++++++++++++++++++++-----
1 files changed, 32 insertions(+), 5 deletions(-)
diff --git a/git-cvsexportcommit.perl b/git-cvsexportcommit.perl
index 3e4e90b..57088c3 100755
--- a/git-cvsexportcommit.perl
+++ b/git-cvsexportcommit.perl
@@ -2,7 +2,6 @@ #!/usr/bin/perl -w
# Known limitations:
# - cannot add or remove binary files
-# - cannot add parent directories when needed
# - does not propagate permissions
# - tells "ready for commit" even when things could not be completed
# (eg addition of a binary file)
@@ -11,7 +10,7 @@ use strict;
use Getopt::Std;
use File::Temp qw(tempdir);
use Data::Dumper;
-use File::Basename qw(basename);
+use File::Basename qw(basename dirname);
unless ($ENV{GIT_DIR} && -r $ENV{GIT_DIR}){
die "GIT_DIR is not defined or is unreadable";
@@ -91,7 +90,7 @@ close MSG;
`git-cat-file commit $commit | sed -e '1,/^\$/d' >> .msg`;
$? && die "Error extracting the commit message";
-my (@afiles, @dfiles, @mfiles);
+my (@afiles, @dfiles, @mfiles, @dirs);
my @files = safe_pipe_capture('git-diff-tree', '-r', $parent, $commit);
#print @files;
$? && die "Error in git-diff-tree";
@@ -99,7 +98,14 @@ foreach my $f (@files) {
chomp $f;
my @fields = split(m!\s+!, $f);
if ($fields[4] eq 'A') {
- push @afiles, $fields[5];
+ my $path = $fields[5];
+ push @afiles, $path;
+ # add any needed parent directories
+ $path = dirname $path;
+ while (!-d $path and ! grep { $_ eq $path } @dirs) {
+ unshift @dirs, $path;
+ $path = dirname $path;
+ }
}
if ($fields[4] eq 'M') {
push @mfiles, $fields[5];
@@ -114,13 +120,21 @@ undef @files; # don't need it anymore
# check that the files are clean and up to date according to cvs
my $dirty;
+foreach my $d (@dirs) {
+ if (-e $d) {
+ $dirty = 1;
+ warn "$d exists and is not a directory!\n";
+ }
+}
foreach my $f (@afiles) {
# This should return only one value
my @status = grep(m/^File/, safe_pipe_capture('cvs', '-q', 'status' ,$f));
if (@status > 1) { warn 'Strange! cvs status returned more than one line?'};
- unless ($status[0] =~ m/Status: Unknown$/) {
+ if (-d dirname $f and $status[0] !~ m/Status: Unknown$/
+ and $status[0] !~ m/^File: no file /) {
$dirty = 1;
warn "File $f is already known in your CVS checkout -- perhaps it has been added by another user. Or this may indicate that it exists on a different branch. If this is the case, use -f to force the merge.\n";
+ warn "Status was: $status\n";
}
}
foreach my $f (@mfiles, @dfiles) {
@@ -146,6 +160,19 @@ ### you MUST call cleanupcvs(@file
###
+print "Creating new directories\n";
+foreach my $d (@dirs) {
+ unless (mkdir $d) {
+ warn "Could not mkdir $d: $!";
+ $dirty = 1;
+ }
+ `cvs add $d`;
+ if ($?) {
+ $dirty = 1;
+ warn "Failed to cvs add directory $d -- you may need to do it manually";
+ }
+}
+
print "'Patching' binary files\n";
my @bfiles = grep(m/^Binary/, safe_pipe_capture('git-diff-tree', '-p', $parent, $commit));
^ permalink raw reply related
* [PATCH 1/3] Do not call 'cmp' with non-existant -q flag.
From: Yann Dirson @ 2006-05-27 16:39 UTC (permalink / raw)
To: junkio; +Cc: git
In-Reply-To: <20060527163641.474.93575.stgit@gandelf.nowhere.earth>
I cannot find when that flag was removed if it ever existed, I can find
nothing about it in the ChangeLog and NEWS file of GNU diff. The current
flag is -s aka --quiet aka --silent, so let's use -s, assuming it is a
portable flag. Feel free to lart me with a POSIX bible if needed.
Signed-off-by: Yann Dirson <ydirson@altern.org>
---
git-cvsexportcommit.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-cvsexportcommit.perl b/git-cvsexportcommit.perl
index f994443..ed87dc9 100755
--- a/git-cvsexportcommit.perl
+++ b/git-cvsexportcommit.perl
@@ -151,7 +151,7 @@ foreach my $f (@bfiles) {
my $blob = `git-ls-tree $tree "$f" | cut -f 1 | cut -d ' ' -f 3`;
chomp $blob;
`git-cat-file blob $blob > $tmpdir/blob`;
- if (system('cmp', '-q', $f, "$tmpdir/blob")) {
+ if (system('cmp', '-s', $f, "$tmpdir/blob")) {
warn "Binary file $f in CVS does not match parent.\n";
$dirty = 1;
next;
^ permalink raw reply related
* [PATCH 2/3] Document current cvsps limitations.
From: Yann Dirson @ 2006-05-27 16:39 UTC (permalink / raw)
To: junkio; +Cc: git
In-Reply-To: <20060527163641.474.93575.stgit@gandelf.nowhere.earth>
Since there is no bugtracker that I know of, let's just use the scripts
themselves to document their limitations.
Signed-off-by: Yann Dirson <ydirson@altern.org>
---
git-cvsexportcommit.perl | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/git-cvsexportcommit.perl b/git-cvsexportcommit.perl
index ed87dc9..3e4e90b 100755
--- a/git-cvsexportcommit.perl
+++ b/git-cvsexportcommit.perl
@@ -1,5 +1,12 @@
#!/usr/bin/perl -w
+# Known limitations:
+# - cannot add or remove binary files
+# - cannot add parent directories when needed
+# - does not propagate permissions
+# - tells "ready for commit" even when things could not be completed
+# (eg addition of a binary file)
+
use strict;
use Getopt::Std;
use File::Temp qw(tempdir);
^ permalink raw reply related
* [PATCH 0/3] Handful of cvsexportcommit patches
From: Yann Dirson @ 2006-05-27 16:36 UTC (permalink / raw)
To: junkio; +Cc: git
The following series contains a collection of cvsexportcommit changes I have at hand.
The support for creating directory files was only tested on a 1.0.7 code base, I'll
have to shake this one before being confident with it, but that will be done next week.
In the meantime, it may still be of interest for someone :)
Best regards,
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* Re: remaining git-cvsimport problems: robustness when cvsps feeds strange history
From: Yann Dirson @ 2006-05-27 16:35 UTC (permalink / raw)
To: Martin Langhoff; +Cc: GIT list, cvsps
In-Reply-To: <46a038f90605270823qdea766fxcf2327ae0bf7373a@mail.gmail.com>
On Sun, May 28, 2006 at 03:23:01AM +1200, Martin Langhoff wrote:
> I want to see if we can close these gaps. Have you got a public repo
> that shows this problem so can look more into it?
No, it holds proprietary code - I can only try to reproduce the
history pattern, but I have not succeeded in that yet. And that's not
something I can do on customer time :)
> On 5/28/06, Yann Dirson <ydirson@altern.org> wrote:
> >As a sidenote, I'm wondering why there is no precise information on
> >the branchpoint in "cvsps -A". I guess the semantics are "fork a new
> >branch from the ancestor one" at whatever point it currently is - that
> >would look quite risky to me, and could be part of the reason why
> >cvsps did not notice the inconsistency: it just did not try to find
> >out where the new branch was to be grafted exactly.
>
> It is perfectly possible for cvs to branch at a "point" that is not
> really a patchset/patchlevel. Just like it is to tag something that
> has never been a patchset.
>
> It is something we currently fudge a bit (or a lot, depending on your
> point of view). If the branch was made on a checkout with an
> inconsistent tree, we cannot really represent that in git matching
> what happened in CVS.
Yes, I know that too much. I've already thought that it could
possibly be represented by a merge commit taking as parents all
patchsets that contain a file revision holding the tag. But such
patchset synthesis ought to done at cvsps level IMHO.
> OTOH, the cvsps output you are showing us seems to be in the right
> order... patchset 20 should go on top of patchset 3... is cvsimport
> truly mishandling this?
That's the problem. I had just copypasted the logs for handling at
home, and then I discovered in the cvsps log that the timestamp for
patchset 2 is the same as the one for patchset 1, which is obviously
wrong. I'll look at the cvs repo next week to understand whether that
comes from the RCS file, or whether it is cvsps misunderstanding
something.
Best regards,
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* Re: [SCRIPT] chomp: trim trailing whitespace
From: Linus Torvalds @ 2006-05-27 16:13 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Jeff Garzik, Git Mailing List, Linux Kernel
In-Reply-To: <46a038f90605270828u7842ea48hda07331388694db2@mail.gmail.com>
On Sun, 28 May 2006, Martin Langhoff wrote:
>
> I love perl golf for this kind of stuff... but git-stripspace is part
> of git already. Even then, I tend to do it with perl -pi -e ''
> constructs ;-)
Well, git-stripspace actually does something slightly differently, in that
it also removes extraneous all-whitespace lines from the beginning, the
end, and the middle (in the middle, the rule is: two or more empty lines
are collapsed into one).
Ie it's a total hack for parsing just commit messages (and it is in C,
because I can personally write 25 lines of C in about a millionth of the
time I can write 3 lines of perl).
Linus
^ permalink raw reply
* Re: [SCRIPT] chomp: trim trailing whitespace
From: Martin Langhoff @ 2006-05-27 15:28 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Git Mailing List, Linux Kernel
In-Reply-To: <4477B905.9090806@garzik.org>
I love perl golf for this kind of stuff... but git-stripspace is part
of git already. Even then, I tend to do it with perl -pi -e ''
constructs ;-)
cheers,
m
^ permalink raw reply
* Re: remaining git-cvsimport problems: robustness when cvsps feeds strange history
From: Martin Langhoff @ 2006-05-27 15:23 UTC (permalink / raw)
To: Yann Dirson; +Cc: GIT list, cvsps
In-Reply-To: <20060527120105.GL6535@nowhere.earth>
Yann,
I want to see if we can close these gaps. Have you got a public repo
that shows this problem so can look more into it?
On 5/28/06, Yann Dirson <ydirson@altern.org> wrote:
> As a sidenote, I'm wondering why there is no precise information on
> the branchpoint in "cvsps -A". I guess the semantics are "fork a new
> branch from the ancestor one" at whatever point it currently is - that
> would look quite risky to me, and could be part of the reason why
> cvsps did not notice the inconsistency: it just did not try to find
> out where the new branch was to be grafted exactly.
It is perfectly possible for cvs to branch at a "point" that is not
really a patchset/patchlevel. Just like it is to tag something that
has never been a patchset.
It is something we currently fudge a bit (or a lot, depending on your
point of view). If the branch was made on a checkout with an
inconsistent tree, we cannot really represent that in git matching
what happened in CVS.
OTOH, the cvsps output you are showing us seems to be in the right
order... patchset 20 should go on top of patchset 3... is cvsimport
truly mishandling this?
martin
^ permalink raw reply
* Re: [PATCH 2/2] make init-db use GIT_TEMPLATE_DIR if --template option is not specified
From: Petr Baudis @ 2006-05-27 13:25 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: git
Dear diary, on Sat, May 27, 2006 at 12:25:39PM CEST, I got a letter
where Matthias Lederhofer <matled@gmx.net> said that...
> f61e19360f9b5965dda1ae762ffdab8ede860430
> diff --git a/builtin-init-db.c b/builtin-init-db.c
> index 2a1384c..cf5bd39 100644
> --- a/builtin-init-db.c
> +++ b/builtin-init-db.c
> @@ -253,6 +253,9 @@ int cmd_init_db(int argc, const char **a
> die(init_db_usage);
> }
>
> + if (!template_dir)
> + template_dir = getenv("GIT_TEMPLATE_DIR");
> +
> /*
> * Set up the default .git directory contents
> */
Please document such changes, in the spirit of
diff --git a/Documentation/git-init-db.txt b/Documentation/git-init-db.txt
index 8a150d8..378810e 100644
--- a/Documentation/git-init-db.txt
+++ b/Documentation/git-init-db.txt
@@ -15,6 +15,8 @@ OPTIONS
-------
--template=<template_directory>::
Provide the directory from which templates will be used.
+ If not specified, the value of the `GIT_TEMPLATE_DIR` environment
+ variable is used instead.
The default template directory is `/usr/share/git-core/templates`.
--shared::
(Signed-off-by: Petr Baudis <pasky@suse.cz>, whatever...)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply related
* Re: ~/.git/config ?
From: Horst von Brand @ 2006-05-27 12:52 UTC (permalink / raw)
To: Linus Torvalds
Cc: Petr Baudis, Pavel Roskin, Timo Hirvonen, Anand Kumria, git
In-Reply-To: <Pine.LNX.4.64.0605262007230.5623@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> wrote:
> On Sat, 27 May 2006, Petr Baudis wrote:
> >
> > ~/.gitrc might get useful for actually doing what ~/.cvsrc or ~/.cgrc
> > does, that is providing default options for git commands. ~/.gitconfig
> > would just give you per-user defaults for the repository config file.
Yep.
[...]
> So they would do "alias cvs git" in a desperate attempt to save themselves
> from CVS, and then add
>
> [alias "co"]
> cmd = commit -a
I don't like this syntax. What other stuff (beside "cmd") would be under
"[alias "co"]? Why not simply:
[alias]
co = commit -a
publish = push public.site.com:/pub/scm/my-public-repo
--
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: [SCRIPT] chomp: trim trailing whitespace
From: Jan Engelhardt @ 2006-05-27 12:42 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Git Mailing List, Linux Kernel
In-Reply-To: <447838EB.9060900@garzik.org>
>> Pretty long script. How about this two-liner? It does not show 'bytes
>> chomped' but it also trims trailing whitespace.
>>
>> #!/usr/bin/perl -i -p
>> s/[ \t\r\n]+$//
>
> Yes, it does, but a bit too aggressive for what we need :)
>
Whoops, should have been s/[ \t\r]+$//
And the CL form is
perl -i -pe '...'
Somehow, you can't group it to -ipe, but who cares.
Jan Engelhardt
--
^ permalink raw reply
* remaining git-cvsimport problems: relying on timestamps looses patchsets
From: Yann Dirson @ 2006-05-27 12:24 UTC (permalink / raw)
To: GIT list
I use git-cvsimport daily to sync from an inernal CVS repository at
work. Occasionally (in fact, much too often ;), I notice that not all
patchsets were really imported into git (and thus I have to reimport
from scratch, update my graft file, migrate my stgit branches, which
is quite a tedious and time-consuming task).
The problem seems to stem from the fact that git-cvsimport decides
which patch to import based on commit dates, and that we cannot rely
on all machines being correctly time-synchronized.
It would seem much more reliable to keep track of the latest patchset
imported on each branch. Now, maybe this option was considered
already, and rejected for various reasons. I'd welcome any info on
this.
One such reason I can think about is that cvsps patchset numbers seem
to be currently the only way to identify a patchset, and those are not
guaranted to be stable from one cvsps release to the other - eg. I
hope the bug mentionned in previous mail there can be fixed some day,
and thus the fixed patchsets will have different numbers; or maybe
some day cvsps will deal better with the pseudo-revisions introduced
by RCS when adding a file on a branch.
So we have to be able to detect when the cvsps output has changed and
the git history is now possibly out of sync, or it would also be
possible to have a corrupted mirror of the cvs history.
For this, we would need to record some patchset information in the
imported commits - currently only the patchset number seems to make
sense, but if new cvsps releases can show the commitid's introduced in
cvs 1.12.x that would be of great help here. Then we could validate
for each patchset whether we can find a commit with its patchset
number in the git history, and do some checks to assert this commit
corresponds to the expected patchset - until we have access to the cvs
commitid's, we can check that the files changed by the commit are the
same than those in the patchset.
Does that make sense to anyone, or am I completely off-track ?
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* remaining git-cvsimport problems: robustness when cvsps feeds strange history
From: Yann Dirson @ 2006-05-27 12:01 UTC (permalink / raw)
To: GIT list; +Cc: cvsps
Since there is quite some activity around git-cvsimport these days, I
think I'd raise a couple of issues which are still problematic.
It should at least issue a warning when cvsps feeds it with a
branchpoint that it cannot create because the base branch has not yet
been seen. I am still investigating why cvsps outputs such a buggy
patchset - it may be a cvs bug at the root, and cvsps probably did not
detect an consistency of the cvs data. While there is probably a real
bug to fix somewhere, git-cvsimport should not silently skip the
faulty patchset, especially as it will then miserably fail to import
any subsequent patch on that branch it ignored this way.
However, rerunning the script (after creating a master head by copying
heads/origin) manages to complete the import: the forgotten branch now
gets created, and all subsequent patchsets can now be imported.
I'm not sure what would be the best way to handle the issue. Maybe it
would sufficient to output a bold warning and let the user take the
necessary steps to finish the import (since this is after all a bug in
other tools, which will hopefully be fixed at some point). It could
also be useful to raise a flag when detecting that condition, and
automatically restart the import process on the first error due to
that branch not being available - otoh, that may be overkill, and
could possibly miss some other obscure cases.
As a sidenote, I'm wondering why there is no precise information on
the branchpoint in "cvsps -A". I guess the semantics are "fork a new
branch from the ancestor one" at whatever point it currently is - that
would look quite risky to me, and could be part of the reason why
cvsps did not notice the inconsistency: it just did not try to find
out where the new branch was to be grafted exactly.
======
PatchSet 1
Date: 2006/01/03 18:23:53
Author: ydirson
Branch: HEAD
Tag: (none)
Log:
Empty .cvsignore to be used as a branching base
Members:
.cvsignore:INITIAL->1.1
---------------------
PatchSet 2
Date: 2006/01/03 18:23:53
Author: ydirson
Branch: FOO_V3_0_0_HEAD
Ancestor branch: FOO_VENDOR_HEAD
Tag: (none)
Log:
file .cvsignore was added on branch FOO_V3_0_0_HEAD on 2006-05-24 07:51:07
+0000
Members:
.cvsignore:1.1->1.1.4.1(DEAD)
---------------------
PatchSet 3
Date: 2006/01/03 18:24:39
Author: ydirson
Branch: FOO_VENDOR_HEAD
Ancestor branch: HEAD
Tag: FOO_V1_1
Log:
Import de FOO 1.1
---------------------
PatchSet 20
Date: 2006/01/10 11:47:54
Author: ydirson
Branch: FOO_V3_0_0_HEAD
Tag: (none)
Log:
file script.sh was added on branch FOO_V3_0_0_HEAD on 2006-05-24 07:51:08
+0000
Members:
some/script.sh:1.1->1.1.4.1(DEAD)
===== first import
Fetching .cvsignore v 1.1
New .cvsignore: 0 bytes
Tree ID 87556a35bc2c438ede9eb2120c2cdb04baed33ae
Committing initial tree 87556a35bc2c438ede9eb2120c2cdb04baed33ae
Committed patch 1 (origin 2006-01-03 17:23:53)
Commit ID 2ddb63602915316e60b26d95414100fd80e602ef
Branch FOO_VENDOR_HEAD does not exist!
Delete .cvsignore
[...]
Tree ID ca6e986b5199b01604dfa459b6e3a2841024f11a
Parent ID 2ddb63602915316e60b26d95414100fd80e602ef
Committed patch 3 (FOO_VENDOR_HEAD 2006-01-03 17:24:39)
Commit ID 9e19f11520c89897704fff252901ff4dc5ae88ad
[...]
Committed patch 19 (origin 2006-01-10 10:47:54)
Commit ID 0c5063420b769f8db7c009843b3947350bf78eae
Switching from origin to FOO_V3_0_0_HEAD
fatal: Not a valid object name FOO_V3_0_0_HEAD
read-tree failed: 32768
===== second run
skip patchset 1: 1136309033 before 1136890074
Switching from master to FOO_V3_0_0_HEAD
Delete .cvsignore
Tree ID 38b8067e1d36ce7f45bb1121a22628927bfd2ac2
Parent ID b9cf667acd27ba7fd76a405166b355ec51261b17
Committed patch 2 (FOO_V3_0_0_HEAD 2006-01-03 17:23:53)
Commit ID 528efdac6113af50d4c14c3ccabde9661cb19359
skip patchset 3: 1136309079 before 1136312985
[...]
skip patchset 19: 1136890074 before 1136890074
Delete some/script.sh
Tree ID 38b8067e1d36ce7f45bb1121a22628927bfd2ac2
Parent ID 528efdac6113af50d4c14c3ccabde9661cb19359
Committed patch 20 (FOO_V3_0_0_HEAD 2006-01-10 10:47:54)
[...]
Committed patch 409 (origin 2006-05-24 18:59:44)
Commit ID 74a5c3b1f265f096177120166ae7da1a2cf3f64e
DONE.
=====
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* Re: [SCRIPT] chomp: trim trailing whitespace
From: Dmitry Fedorov @ 2006-05-27 11:48 UTC (permalink / raw)
To: Git Mailing List, Linux Kernel
In-Reply-To: <447838EB.9060900@garzik.org>
[-- Attachment #1: Type: text/plain, Size: 226 bytes --]
Jan Engelhardt wrote:
>> Attached to this email is chomp.pl, a Perl script which removes trailing
>> whitespace from several files. I've had this for years, as
trailing whitespace
>> is one of my pet peeves.
And my scripts.
[-- Attachment #2: find-text-files --]
[-- Type: application/octet-stream, Size: 7833 bytes --]
#!/usr/bin/perl -w
=head1 NAME
find-text-files - traverse a file tree and guess plain text files
=head1 SYNOPSIS
find-text-files [options] dir ...
=head1 DESCRIPTION
This program traverse a file tree, guess plain text files
and outputs their names to STDOUT.
=cut
require 5.004;
use strict;
use integer;
use File::Find;
use Getopt::Long;
use IPC::Open2;
sub usage {
warn "\n".join(" ", @_)."\n" if @_;
warn <<EOF;
Usage:
find-text-files [-exclude='perlre' ...] [-include='perlre' ...] \
[-total] [-excluded] [-included] [-selectors] \
dir ...
EOF
exit(1);
}
=head1 PARAMETERS
=over 4
=item dir ...
Directories list.
=back
=cut
=head1 OPTIONS
=over 4
=item -exclude='perlre' ...
Perl regular expression, case insensitive.
Matched file names excluded from output list.
=item -include='perlre' ...
Perl regular expression, case insensitive.
Matched file names included to output list.
=head2 Note
Directory part of the file name stripped before match,
'^filename\.ext$' will be matched exactly to filename.ext
with any directory prepended.
=item -total
print statistic counters to STDERR.
=item -excluded
print to STDERR what files are excluded and why.
=item -included
print to STDERR what files are included and why.
=item -selectors
Prints exclude/include regular expressions and file suffices and exits.
=back
=head1 HOW IT WORKS
Each of file names checked in that order:
* check against exclude RE; matched file excluded (see -exclude option);
if not matched, then:
* check against include RE; matched file included (see -include option);
if not matched, then:
* check against binary suffices table; matched file excluded;
if not matched, then:
* check against text suffices table; matched file included;
if not matched, then:
* checked by file(1)
All of this allows to avoid file(1)'s misdetection on some texts
and reduce time spent for file(1) calls.
=head1 NOTES
Does not follows symlinks.
Zero size files are skipped.
=cut
my $ help_option = 0;
my @ include_options;
my @ exclude_options;
my $ total_option = 0;
my $ excluded_option = 0;
my $ included_option = 0;
my $selectors_option = 0;
GetOptions(
'help' => \$ help_option,
'exclude=s' => \@ exclude_options,
'include=s' => \@ include_options,
'total' => \$ total_option,
'excluded' => \$ excluded_option,
'included' => \$ included_option,
'selectors' => \$selectors_option,
) or usage;
usage if $help_option;
my %bin_suffices;
my %txt_suffices;
BEGIN
{
map { $bin_suffices{$_} = undef }
(
'gif', 'tif', 'tiff', 'png', 'jpg', 'jpeg',
'avi', 'mpg', 'mpeg',
'o', 'obj', 'exe',
'cab', 'a', 'rar', 'arj', 'zip', 'tar', 'cpio',
'z', 'gz', 'bz', 'bz2', 'tgz', 'tbz', 'tbz2',
'iso', 'bin', 'img', 'imag', 'image',
'diff', 'patch' # diff/patch files could have EOL spaces!
);
map { $txt_suffices{$_} = undef }
(
'txt', 'text', 'html', 'htm', 'xml', 'php',
'c', 'cpp', 'c++', 'cc', 'cxx',
'h', 'hpp', 'h++', 'hh', 'hxx',
'asm', 'inc', 'mod',
'for', 'f77', 'g77',
'java', 'jav',
'bas', 'vb',
'pl', 'pm', 'pod',
'make', 'mak', 'mk',
'awk', 'sh', 'bat', 'cmd', 'rexx', 'rex',
'sql', 'def', 'man',
'cvsignore'
);
}
my $exclude_re = '(,v$)';
map { $exclude_re .= '|('.lc $_.')'; } @exclude_options;
my $include_re = '(^makefile$)';
map { $include_re .= '|('.lc $_.')'; } @include_options;
if ($selectors_option)
{
my $bin_suffices = join(" ", sort keys %bin_suffices);
my $txt_suffices = join(" ", sort keys %txt_suffices);
print STDERR "\n";
print STDERR "Exclude RE: ".$exclude_re."\n";
print STDERR "\n";
print STDERR "Include RE: ".$include_re."\n";
print STDERR "\n";
print STDERR "Exclude suffices: ".$bin_suffices."\n";
print STDERR "\n";
print STDERR "Include suffices: ".$txt_suffices."\n";
print STDERR "\n";
exit 0;
}
scalar(@ARGV) >= 1 or usage("no directory specified");
my (
$total_files_checked,
$total_files_empty,
$total_files_excluded_by_re,
$total_files_included_by_re,
$total_files_excluded_by_suffix,
$total_files_included_by_suffix,
$total_files_excluded_by_file,
$total_files_included_by_file
) = (0,0,0,0,0,0,0,0);
sub _by($$$$)
{
my ($inex_option, $inex_str, $by, $name) = @_;
printf(STDERR "%scluded by %13s: %s\n", $inex_str, $by, $name)
if $inex_option;
}
sub inby($$) { _by($included_option, 'in', $_[0], $_[1]); }
sub exby($$) { _by($excluded_option, 'ex', $_[0], $_[1]); }
local *FILE_RH;
local *FILE_WH;
my $file_pid;
$SIG{PIPE} = sub
{
close FILE_WH;
waitpid $file_pid, 0;
die "file(1) pipe broken"
};
$file_pid = open2(\*FILE_RH, \*FILE_WH, "file -n -f -" )
or die "can't fork: $!";
#+ main work
$| = 1; # STDOUT autoflush
find(\&onfile, @ARGV);
#- main work
close FILE_WH;
waitpid $file_pid, 0;
format STDERR =
Total files: checked empty
------- -------
@>>>>>> @>>>>>>
$total_files_checked, $total_files_empty
suffix re file(1)
------- ------- -------
excluded by: @>>>>>> @>>>>>> @>>>>>>
$total_files_excluded_by_suffix, $total_files_excluded_by_re, $total_files_excluded_by_file
included by: @>>>>>> @>>>>>> @>>>>>>
$total_files_included_by_suffix, $total_files_included_by_re, $total_files_included_by_file
.
write STDERR if $total_option;
exit 0;
sub onfile()
{
my $shortname = $_;
my $ fullname = "$File::Find::name";
return unless -f $shortname;
$total_files_checked++;
if ( ! -s $shortname )
{
$total_files_empty++;
return;
}
my $lcshortname = lc $shortname;
if ( $lcshortname =~ m/$exclude_re/o )
{
exby('RE', $fullname);
$total_files_excluded_by_re++;
return;
}
if ( $lcshortname =~ m/$include_re/o )
{
inby('RE', $fullname);
$total_files_included_by_re++;
}
else # check by suffix
{
my $suffix = $1 if $lcshortname =~ m/\.([^\.]+)$/;
if ( defined $suffix and length $suffix and
exists $bin_suffices{$suffix} )
{
exby('binary suffix', $fullname);
$total_files_excluded_by_suffix++;
return;
}
if ( defined $suffix and length $suffix and
exists $txt_suffices{$suffix} )
{
inby('text suffix', $fullname);
$total_files_included_by_suffix++;
}
else # check by file(1)
{
print FILE_WH $fullname."\n"
or die "bad write to file(1) pipe: $! $?";
my $fread = <FILE_RH>;
defined $fread or die "bad read from file(1) pipe: $! $?";
chomp $fread;
unless ( $fread =~ m|^(.+):\s+(.+)$| )
{
die "file(1) output does not match pattern:\n$fread\n";
}
my ($fname,$fdesc) = ($1,$2);
die "can't parse file(1) output:\n$fread\n"
if (! defined $fname) or (! defined $fdesc);
die "file name after file(1) does not match the original one:\n".
"\tbefore: $fullname\n".
"\tafter : $fname\n"
if $fname ne $fullname;
if ( $fdesc =~ m/^.* (text)|(source).*$/ )
{
inby('file(1)', $fullname);
$total_files_included_by_file++;
}
else
{
exby('file(1)', $fullname);
$total_files_excluded_by_file++;
return;
}
}
}
print $fullname . "\n";
}
=head1 AUTHOR
Dmitry Fedorov <dm.fedorov@gmail.com>
=head1 COPYRIGHT
Copyright (C) 2003 Dmitry Fedorov <dm.fedorov@gmail.com>
=head1 LICENSE
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License,
or (at your option) any later version.
=head1 DISCLAIMER
The author disclaims any responsibility for any mangling of your system
etc, that this script may cause.
=cut
[-- Attachment #3: truncate-eol-whitespace --]
[-- Type: application/octet-stream, Size: 4916 bytes --]
#!/usr/bin/perl -w
=head1 NAME
truncate-eol-whitespace - truncate white spaces at end of line.
=head1 SYNOPSIS
truncate-eol-whitespace [-total] [-truncated] [-nontruncated] [-dry-run] \
[file ...] [-f files-from]
=head1 DESCRIPTION
This program truncates extra white spaces just before end of line
in specified files. File names can be specified as parameters
and/or readed from specified file, '-' for STDIN.
=head1 EXAMPLE
Truncate all text files under DIR:
find-text-files DIR -total | truncate-eol-whitespace -total -f -
=cut
require 5.004;
use strict;
use integer;
use Getopt::Long;
sub usage {
warn "\n".join(" ", @_)."\n" if @_;
warn <<EOF;
Usage:
truncate-eol-whitespace [-total] [-truncated] [-nontruncated] [-dry-run] \
[file ...] [-f files-from]
Warning: this script truncates files! Use -dry-run for test first.
EOF
exit(1);
}
=head1 OPTIONS
=over 4
=item -total
print statistic counters to STDERR.
=item -truncated
print to STDERR what files was truncated;
=item -nontruncated
print to STDERR what files was not truncated;
=item -dry-run
Do not write files, report only
=item file ...
Files to truncate (optional)
=item -f files-from
File name with file names to truncate, one name per line.
Use '-' for STDIN.
=back
=cut
my $ help_option = 0;
my $ dry_run_option = 0;
my $ files_from_option;
my $ total_option = 0;
my $ truncated_option = 0;
my $nontruncated_option = 0;
GetOptions(
'help' => \$ help_option,
'total' => \$ total_option,
'truncated' => \$ truncated_option,
'nontruncated' => \$nontruncated_option,
'dry-run' => \$ dry_run_option,
'f=s' => \$ files_from_option,
) or usage;
usage if $help_option;
usage("no files specified")
if (! defined $files_from_option) and scalar(@ARGV) < 1;
my (
$total_files_checked,
$total_files_empty,
$total_files_truncated,
$total_files_no_chars_truncated
) = (0,0,0,0,0,0,0,0,0,0);
my ( $total_chars_readed, $total_chars_truncated ) = (0,0);
sub truncate_file($)
{
my $fname = shift;
$total_files_checked++;
if ( ! -f $fname )
{
print STDERR "is not a plain file: ".$fname."\n";
return;
}
if ( ! -s $fname )
{
print STDERR "zero size file: ".$fname."\n";
$total_files_empty++;
return;
}
local $/ = undef; # no records, slurp mode
local *IN;
open IN, "< $fname"
or die "Can't open $fname: $!";
my $file = <IN>;
defined $file or die "Can't read $fname: $!";
close IN;
my $length_before = length $file;
$total_chars_readed += $length_before;
$file =~ s/[\000-\011\013-\040]+\n/\n/mg;
my $length_after = length $file;
my $chars_truncated = $length_before - $length_after;
die "size become greater after truncating: ".$fname
if $chars_truncated < 0;
if ( $chars_truncated > 0 )
{
$total_files_truncated++;
$total_chars_truncated += $chars_truncated;
}
else
{
$total_files_no_chars_truncated++;
}
if ( $chars_truncated >0 and $truncated_option )
{
printf(STDOUT "%6u of %6u chars truncated from $fname\n",
$chars_truncated, $length_before);
}
elsif ( $chars_truncated==0 and $nontruncated_option )
{
printf(STDOUT "%-16s chars truncated from $fname\n", 'no');
}
if ( ! $dry_run_option and $chars_truncated > 0 )
{
local *OUT;
open OUT, "> $fname" or die "Can't open $fname: $!";
print OUT $file or die "Can't write $fname: $!";
close OUT or die "Error on closing $fname: $!";
}
}
#+ main work
# do process file names from the @ARGV first
truncate_file($_) while defined ($_ = shift);
if (defined $files_from_option) # do process file names from file|STDIN
{
local *IN;
open (IN, $files_from_option) or die "Can't open $files_from_option: $!";
while ( my $fname = <IN> )
{
chomp $fname;
next if length($fname) < 1; # skip empty lines
truncate_file($fname);
}
}
#- main work
format STDERR =
Total files: checked empty truncated non-truncated
------- ------- ------- -------
@>>>>>> @>>>>>> @>>>>>> @>>>>>>
$total_files_checked, $total_files_empty, $total_files_truncated, $total_files_no_chars_truncated
Total chars truncated: @>>>>>> of @<<<<<<<<<<<<<<<<<
$total_chars_truncated, $total_chars_readed
.
write STDERR if $total_option;
exit 0;
=head1 AUTHOR
Dmitry Fedorov <dm.fedorov@gmail.com>
=head1 COPYRIGHT
Copyright (C) 2003 Dmitry Fedorov <dm.fedorov@gmail.com>
=head1 LICENSE
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License,
or (at your option) any later version.
=head1 DISCLAIMER
The author disclaims any responsibility for any mangling of your system
etc, that this script may cause.
=cut
^ permalink raw reply
* Re: [SCRIPT] chomp: trim trailing whitespace
From: Jeff Garzik @ 2006-05-27 11:32 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Git Mailing List, Linux Kernel
In-Reply-To: <Pine.LNX.4.61.0605271212210.6670@yvahk01.tjqt.qr>
Jan Engelhardt wrote:
>> Attached to this email is chomp.pl, a Perl script which removes trailing
>> whitespace from several files. I've had this for years, as trailing whitespace
>> is one of my pet peeves.
>>
>> Now that git-applymbox complains loudly whenever a patch adds trailing
>> whitespace, I figured this script may be useful to others.
>>
>
> Pretty long script. How about this two-liner? It does not show 'bytes
> chomped' but it also trims trailing whitespace.
>
> #!/usr/bin/perl -i -p
> s/[ \t\r\n]+$//
Yes, it does, but a bit too aggressive for what we need :)
Jeff
^ permalink raw reply
* Re: [SCRIPT] chomp: trim trailing whitespace
From: Neil Brown @ 2006-05-27 10:36 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: Linux Kernel, GIT, Jan Engelhardt
In-Reply-To: <20060527102439.GB26430@cip.informatik.uni-erlangen.de>
On Saturday May 27, sithglan@stud.uni-erlangen.de wrote:
> Hello,
>
> > #!/usr/bin/perl -i -p
> > s/[ \t\r\n]+$//
>
> perl -p -i -e 's/\s+$//' file1 file2 file3 ...
>
Uhm... have either of you actually tried those? When I tried, I lose
all the '\n' characters :-(
perl -pi -e 's/[ \t\r]+$//' *.[ch]
seems to actually work.
NeilBrown
^ permalink raw reply
* [PATCH 1/2] add --template=<template_directory> option to git-clone
From: Matthias Lederhofer @ 2006-05-27 10:25 UTC (permalink / raw)
To: git; +Cc: Matthias Lederhofer
---
a176a8eae1d0e8e87028c4185ad5500ce2845441
Documentation/git-clone.txt | 8 ++++++--
git-clone.sh | 7 +++++--
2 files changed, 11 insertions(+), 4 deletions(-)
a176a8eae1d0e8e87028c4185ad5500ce2845441
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index b333f51..881b464 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -9,8 +9,8 @@ git-clone - Clones a repository
SYNOPSIS
--------
[verse]
-'git-clone' [-l [-s]] [-q] [-n] [--bare] [-o <name>] [-u <upload-pack>]
- [--reference <repository>]
+'git-clone' [--template=<template_directory>] [-l [-s]] [-q] [-n] [--bare]
+ [-o <name>] [-u <upload-pack>] [--reference <repository>]
<repository> [<directory>]
DESCRIPTION
@@ -34,6 +34,10 @@ branch you are currently working on. Re
OPTIONS
-------
+--template=<template_directory>::
+ Provide the directory from which templates will be used.
+ The default template directory is `/usr/share/git-core/templates`.
+
--local::
-l::
When the repository to clone from is on a local machine,
diff --git a/git-clone.sh b/git-clone.sh
index d96894d..1c7ae12 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -9,7 +9,7 @@ # See git-sh-setup why.
unset CDPATH
usage() {
- echo >&2 "Usage: $0 [--use-separate-remote] [--reference <reference-repo>] [--bare] [-l [-s]] [-q] [-u <upload-pack>] [--origin <name>] [-n] <repo> [<dir>]"
+ echo >&2 "Usage: $0 [--template=<template_directory>] [--use-separate-remote] [--reference <reference-repo>] [--bare] [-l [-s]] [-q] [-u <upload-pack>] [--origin <name>] [-n] <repo> [<dir>]"
exit 1
}
@@ -102,6 +102,7 @@ quiet=
local=no
use_local=no
local_shared=no
+template=
no_checkout=
upload_pack=
bare=
@@ -120,6 +121,8 @@ while
*,-l|*,--l|*,--lo|*,--loc|*,--loca|*,--local) use_local=yes ;;
*,-s|*,--s|*,--sh|*,--sha|*,--shar|*,--share|*,--shared)
local_shared=yes; use_local=yes ;;
+ *,--template=*)
+ template="$1" ;;
*,-q|*,--quiet) quiet=-q ;;
*,--use-separate-remote)
use_separate_remote=t ;;
@@ -203,7 +206,7 @@ trap 'err=$?; cd ..; rm -r "$D"; exit $e
case "$bare" in
yes) GIT_DIR="$D" ;;
*) GIT_DIR="$D/.git" ;;
-esac && export GIT_DIR && git-init-db || usage
+esac && export GIT_DIR && git-init-db "$template" || usage
case "$bare" in
yes)
GIT_DIR="$D" ;;
--
1.3.3.g40505
^ permalink raw reply related
* [PATCH 2/2] make init-db use GIT_TEMPLATE_DIR if --template option is not specified
From: Matthias Lederhofer @ 2006-05-27 10:25 UTC (permalink / raw)
To: git; +Cc: Matthias Lederhofer
In-Reply-To: <11487255393905-git-send-email-1>
---
f61e19360f9b5965dda1ae762ffdab8ede860430
builtin-init-db.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
f61e19360f9b5965dda1ae762ffdab8ede860430
diff --git a/builtin-init-db.c b/builtin-init-db.c
index 2a1384c..cf5bd39 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -253,6 +253,9 @@ int cmd_init_db(int argc, const char **a
die(init_db_usage);
}
+ if (!template_dir)
+ template_dir = getenv("GIT_TEMPLATE_DIR");
+
/*
* Set up the default .git directory contents
*/
--
1.3.3.g40505
^ permalink raw reply related
* gitview: Move the console error messages to message dialog
From: Aneesh Kumar K.V @ 2006-05-27 10:25 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #2: 0002-gitview-Move-the-console-error-messages-to-message-dialog.txt --]
[-- Type: text/plain, Size: 1154 bytes --]
gitview: Move the console error messages to message dialog
This changes display the error/warning info using message dialog
rather than printing them using print
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
---
contrib/gitview/gitview | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/contrib/gitview/gitview b/contrib/gitview/gitview
index c708534..b836047 100755
--- a/contrib/gitview/gitview
+++ b/contrib/gitview/gitview
@@ -983,10 +983,15 @@ class GitView:
try:
self.treeview.set_cursor(self.index[revid])
except KeyError:
- print "Revision %s not present in the list" % revid
+ dialog = gtk.MessageDialog(parent=None, flags=0,
+ type=gtk.MESSAGE_WARNING, buttons=gtk.BUTTONS_CLOSE,
+ message_format=None)
+ dialog.set_markup("Revision <b>%s</b> not present in the list" % revid)
# revid == 0 is the parent of the first commit
if (revid != 0 ):
- print "Try running gitview without any options"
+ dialog.format_secondary_text("Try running gitview without any options")
+ dialog.run()
+ dialog.destroy()
self.treeview.grab_focus()
--
1.3.3.g4d548-dirty
^ permalink raw reply related
* Re: [SCRIPT] chomp: trim trailing whitespace
From: Thomas Glanzmann @ 2006-05-27 10:24 UTC (permalink / raw)
To: Linux Kernel; +Cc: GIT, Jan Engelhardt
In-Reply-To: <Pine.LNX.4.61.0605271212210.6670@yvahk01.tjqt.qr>
Hello,
> #!/usr/bin/perl -i -p
> s/[ \t\r\n]+$//
perl -p -i -e 's/\s+$//' file1 file2 file3 ...
Thomas
^ permalink raw reply
* gitview: Add key binding for F5.
From: Aneesh Kumar K.V @ 2006-05-27 10:24 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #2: 0001-gitview-Add-key-binding-for-F5.txt --]
[-- Type: text/plain, Size: 2342 bytes --]
gitview: Add key binding for F5.
F5 will now refresh the window. This is useful if you are using git bisect
and want to visualize the change.
Also update the gitview version
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
---
contrib/gitview/gitview | 17 +++++++++++++----
contrib/gitview/gitview.txt | 6 ++++--
2 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/contrib/gitview/gitview b/contrib/gitview/gitview
index 781badb..c708534 100755
--- a/contrib/gitview/gitview
+++ b/contrib/gitview/gitview
@@ -425,7 +425,7 @@ class DiffWindow:
class GitView:
""" This is the main class
"""
- version = "0.7"
+ version = "0.8"
def __init__(self, with_diff=0):
self.with_diff = with_diff
@@ -449,8 +449,17 @@ class GitView:
self.accel_group = gtk.AccelGroup()
self.window.add_accel_group(self.accel_group)
+ self.accel_group.connect_group(0xffc2, 0, gtk.ACCEL_LOCKED, self.refresh);
- self.construct()
+ self.window.add(self.construct())
+
+ def refresh(self, widget, event=None, *arguments, **keywords):
+ self.get_encoding()
+ self.get_bt_sha1()
+ Commit.children_sha1 = {}
+ self.set_branch(sys.argv[without_diff:])
+ self.window.show()
+ return True
def get_bt_sha1(self):
""" Update the bt_sha1 dictionary with the
@@ -500,9 +509,9 @@ class GitView:
menu_bar.show()
vbox.pack_start(menu_bar, expand=False, fill=True)
vbox.pack_start(paned, expand=True, fill=True)
- self.window.add(vbox)
paned.show()
vbox.show()
+ return vbox
def construct_top(self):
@@ -987,8 +996,8 @@ class GitView:
window.set_diff(commit_sha1, parent_sha1, encoding)
self.treeview.grab_focus()
+without_diff = 0
if __name__ == "__main__":
- without_diff = 0
if (len(sys.argv) > 1 ):
if (sys.argv[1] == "--without-diff"):
diff --git a/contrib/gitview/gitview.txt b/contrib/gitview/gitview.txt
index fcf759c..e3bc4f4 100644
--- a/contrib/gitview/gitview.txt
+++ b/contrib/gitview/gitview.txt
@@ -25,6 +25,9 @@ OPTIONS
<args>
All the valid option for git-rev-list(1)
+ Key Bindings:
+ F5:
+ To reread references.
EXAMPLES
------
@@ -33,6 +36,5 @@ EXAMPLES
or drivers/scsi subdirectories
gitview --since=2.weeks.ago
- Show the changes during the last two weeks
+ Show the changes during the last two weeks
-
--
1.3.3.g4d548-dirty
^ 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