* Re: [PATCH] Git wrapper: add --redirect-stderr option
From: Shawn O. Pearce @ 2007-05-30 3:53 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Han-Wen Nienhuys, Johannes Sixt, Nguyen Thai Ngoc Duy,
Marius Storm-Olsen, git
In-Reply-To: <Pine.LNX.4.64.0705300444020.4011@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> On Tue, 29 May 2007, Shawn O. Pearce wrote:
>
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > >
> > > With this option, stderr is redirected to stdout. The short option is '-2'.
> > >
> > > Alternatively, you can say '--redirect-stderr=<filename>' to redirect
> > > stderr to a file.
> >
> > Yes, that works nicely. ;-)
> >
> > Now here's my other problem: How does git-gui know the underlying
> > git will accept --redirect-stderr? Or that it supports any other
> > recent features we've developed?
>
> I thought that git-gui is now really closely coupled with core-git.
Not really. It requires 1.5.0 and later, but after that it should
be OK with any 1.5.x version of Git. Junio graciously bundles it
with core Git, to help it get a wider audience. ;-)
However I'd like to let it be smarter about what it expects from the
underling core Git. I'm sure the other Porcelain authors would also
like to be able to determine if they can rely on something, or not.
At the least we can just tell the user "Your Git old. Upgrade to new
Git today!". Yes, bad Engrish included... ;-)
> > Sure I can check the version, but until I know what version of Git
> > its shipping in I cannot put the check into git-gui.
> >
> > I was thinking about adding a "git-supported-features" plumbing
> > command that prints back feature code strings, much as our
> > network protocol supplies back the few feature codes it supports
> > ("multi-ack", "sideband", etc.).
>
> Problem is: it would be more interesting to have this program in _older_
> versions... ;-)
Lack of git-supported-features means only features before it coming
into existance? ;-)
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Git wrapper: add --redirect-stderr option
From: Johannes Schindelin @ 2007-05-30 3:45 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Han-Wen Nienhuys, Johannes Sixt, Nguyen Thai Ngoc Duy,
Marius Storm-Olsen, git
In-Reply-To: <20070530033830.GO7044@spearce.org>
Hi,
On Tue, 29 May 2007, Shawn O. Pearce wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >
> > With this option, stderr is redirected to stdout. The short option is '-2'.
> >
> > Alternatively, you can say '--redirect-stderr=<filename>' to redirect
> > stderr to a file.
>
> Yes, that works nicely. ;-)
>
> Now here's my other problem: How does git-gui know the underlying
> git will accept --redirect-stderr? Or that it supports any other
> recent features we've developed?
I thought that git-gui is now really closely coupled with core-git.
> Sure I can check the version, but until I know what version of Git
> its shipping in I cannot put the check into git-gui.
>
> I was thinking about adding a "git-supported-features" plumbing
> command that prints back feature code strings, much as our
> network protocol supplies back the few feature codes it supports
> ("multi-ack", "sideband", etc.).
Problem is: it would be more interesting to have this program in _older_
versions... ;-)
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Git wrapper: add --redirect-stderr option
From: Shawn O. Pearce @ 2007-05-30 3:38 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Han-Wen Nienhuys, Johannes Sixt, Nguyen Thai Ngoc Duy,
Marius Storm-Olsen, git
In-Reply-To: <Pine.LNX.4.64.0705300407170.4011@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> With this option, stderr is redirected to stdout. The short option is '-2'.
>
> Alternatively, you can say '--redirect-stderr=<filename>' to redirect
> stderr to a file.
Yes, that works nicely. ;-)
Now here's my other problem: How does git-gui know the underlying
git will accept --redirect-stderr? Or that it supports any other
recent features we've developed?
Sure I can check the version, but until I know what version of Git
its shipping in I cannot put the check into git-gui.
I was thinking about adding a "git-supported-features" plumbing
command that prints back feature code strings, much as our
network protocol supplies back the few feature codes it supports
("multi-ack", "sideband", etc.). E.g.:
$ git supported-features
redirect-stderr
...
That way higher level Porcelain can poll the plumbing to see what
is available, and what isn't.
--
Shawn.
^ permalink raw reply
* [PATCH] Git wrapper: add --redirect-stderr option
From: Johannes Schindelin @ 2007-05-30 3:25 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Han-Wen Nienhuys, Johannes Sixt, Nguyen Thai Ngoc Duy,
Marius Storm-Olsen, git
In-Reply-To: <20070530025705.GN7044@spearce.org>
With this option, stderr is redirected to stdout. The short option is '-2'.
Alternatively, you can say '--redirect-stderr=<filename>' to redirect
stderr to a file.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Tue, 29 May 2007, Shawn O. Pearce wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >
> > BTW Almost any operation I run in git-gui fails, because cat
> > is not found.
>
> That's the stuff that goes into a console and dumps both to
> stdout and stderr. E.g. fetch, push, "compress database".
>
> The issue is Tcl doesn't give me a way to get a pipe to both
> stdout and stderr. I cannot get two pipes, nor can I get a
> single pipe with both stdout+stderr redirected to that pipe.
> Unless I pipe it into another process. Enter `cat`.
>
> Would we consider a "--stderr-to-stdout" long option to git
> itself? Then I could have git-gui do:
>
> git --stderr-to-stdout fetch
>
> and bypass the pipe into cat. Yes, I know, its crap. Welcome
> to Tcl.
How about this?
git.c | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/git.c b/git.c
index 53d81e9..72e0539 100644
--- a/git.c
+++ b/git.c
@@ -82,6 +82,20 @@ static int handle_options(const char*** argv, int* argc)
} else if (!strcmp(cmd, "--bare")) {
static char git_dir[PATH_MAX+1];
setenv(GIT_DIR_ENVIRONMENT, getcwd(git_dir, sizeof(git_dir)), 1);
+ } else if (!strcmp(cmd, "-2") ||
+ !strcmp(cmd, "--redirect-stderr")) {
+ if (dup2(1, 2) < 0)
+ return error("Could not redirect stderr: %s",
+ strerror(errno));
+ } else if (!prefixcmp(cmd, "--redirect-stderr=")) {
+ int fd = open(cmd + 18, O_WRONLY | O_CREAT, 0777), ret;
+ if (fd < 0)
+ return error("Could not open %s", cmd + 18);
+ ret = dup2(fd, 2);
+ close(fd);
+ if (ret < 0)
+ return error("Could not redirect stderr: %s",
+ strerror(errno));
} else {
fprintf(stderr, "Unknown option: %s\n", cmd);
usage(git_usage_string);
--
1.5.2.2642.gc8bae-dirty
^ permalink raw reply related
* [PATCH] Silence $(CC) command line when compiling test tools
From: Shawn O. Pearce @ 2007-05-30 3:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Like our other $(CC) rules in the Makefile we typically build with
$(QUIET_CC) in front of $(CC) so that we hide the compiler options.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
Makefile | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/Makefile b/Makefile
index 3680b09..25c3f37 100644
--- a/Makefile
+++ b/Makefile
@@ -956,25 +956,25 @@ test: all
$(MAKE) -C t/ all
test-date$X: test-date.c date.o ctype.o
- $(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) test-date.c date.o ctype.o
+ $(QUIET_CC)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) test-date.c date.o ctype.o
test-delta$X: test-delta.o diff-delta.o patch-delta.o $(GITLIBS)
- $(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS)
+ $(QUIET_CC)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS)
test-dump-cache-tree$X: dump-cache-tree.o $(GITLIBS)
- $(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS)
+ $(QUIET_CC)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS)
test-sha1$X: test-sha1.o $(GITLIBS)
- $(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS)
+ $(QUIET_CC)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS)
test-match-trees$X: test-match-trees.o $(GITLIBS)
- $(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS)
+ $(QUIET_CC)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS)
test-chmtime$X: test-chmtime.c
- $(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $<
+ $(QUIET_CC)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $<
test-genrandom$X: test-genrandom.c
- $(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $<
+ $(QUIET_CC)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $<
check-sha1:: test-sha1$X
./test-sha1.sh
--
1.5.2.869.g6b3ba
^ permalink raw reply related
* [PATCH] Make git-k an alias to gitk
From: Johannes Schindelin @ 2007-05-30 3:03 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Johannes Sixt, Marius Storm-Olsen, git
In-Reply-To: <fcaeb9bf0705291145q6a0d276o6a94ded3c3e0b6d1@mail.gmail.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Tue, 29 May 2007, Nguyen Thai Ngoc Duy wrote:
> On 5/29/07, Johannes Sixt <J.Sixt@eudaptics.com> wrote:
> > Nguyen Thai Ngoc Duy wrote:
> > > I'd suggest create a small C wrapper to launch gitk. It
> > > would be much easier that way IMHO.
> >
> > Doh! You're right! It's even there already, right before our
> > eyes:
> >
> > pointy..clicky..pointy..clicky (aka: cp gitk git-k)
> >
> > $ git k
> >
> > :)
>
> Maybe we should teach git.c to try gitk if git-k is not found ;)
Something like this?
Makefile | 2 +-
git.c | 6 ++++++
2 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 5f94630..01ab1ff 100644
--- a/Makefile
+++ b/Makefile
@@ -262,7 +262,7 @@ EXTRA_PROGRAMS =
BUILT_INS = \
git-format-patch$X git-show$X git-whatchanged$X git-cherry$X \
git-get-tar-commit-id$X git-init$X git-repo-config$X \
- git-fsck-objects$X git-cherry-pick$X \
+ git-fsck-objects$X git-cherry-pick$X git-k$X \
$(patsubst builtin-%.o,git-%$X,$(BUILTIN_OBJS))
# what 'all' will build and 'install' will install, in gitexecdir
diff --git a/git.c b/git.c
index 04eb344..53d81e9 100644
--- a/git.c
+++ b/git.c
@@ -216,6 +216,11 @@ static int handle_alias(int *argcp, const char ***argv)
return ret;
}
+static int cmd_gitk(int argc, const char **argv, const char *prefix)
+{
+ return execv("gitk", (char *const *)argv);
+}
+
const char git_version_string[] = GIT_VERSION;
#define RUN_SETUP (1<<0)
@@ -274,6 +279,7 @@ static void handle_internal_command(int argc, const char **argv, char **envp)
{ "help", cmd_help },
{ "init", cmd_init_db },
{ "init-db", cmd_init_db },
+ { "k", cmd_gitk },
{ "log", cmd_log, RUN_SETUP | USE_PAGER },
{ "ls-files", cmd_ls_files, RUN_SETUP },
{ "ls-tree", cmd_ls_tree, RUN_SETUP },
--
1.5.2.2641.g404de-dirty
^ permalink raw reply related
* Re: GIT on MinGW problem
From: Shawn O. Pearce @ 2007-05-30 2:57 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Han-Wen Nienhuys, Johannes Sixt, Nguyen Thai Ngoc Duy,
Marius Storm-Olsen, git
In-Reply-To: <Pine.LNX.4.64.0705300337510.4011@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> BTW Almost any operation I run in git-gui fails, because cat is
> not found.
That's the stuff that goes into a console and dumps both to
stdout and stderr. E.g. fetch, push, "compress database".
The issue is Tcl doesn't give me a way to get a pipe to both stdout
and stderr. I cannot get two pipes, nor can I get a single pipe
with both stdout+stderr redirected to that pipe. Unless I pipe
it into another process. Enter `cat`.
Would we consider a "--stderr-to-stdout" long option to git itself?
Then I could have git-gui do:
git --stderr-to-stdout fetch
and bypass the pipe into cat. Yes, I know, its crap. Welcome to
Tcl.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] diff-delta: use realloc instead of xrealloc
From: Nicolas Pitre @ 2007-05-30 2:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Martin Koegler, git
In-Reply-To: <7v1wgz5gus.fsf@assigned-by-dhcp.cox.net>
On Tue, 29 May 2007, Junio C Hamano wrote:
> Martin Koegler <mkoegler@auto.tuwien.ac.at> writes:
>
> > Commit 83572c1a914d3f7a8dd66d954c11bbc665b7b923 changed many
> > realloc to xrealloc. This change was made in diff-delta.c too,
> > although the code can handle an out of memory failure.
> >
> > This patch reverts this change in diff-delta.c.
>
> Wasn't there a discussion around this exact issue when the
> original patch was applied?
Maybe, but I cannot remember it, not can I justify that xrealloc now.
Nicolas
^ permalink raw reply
* Re: GIT on MinGW problem
From: Johannes Schindelin @ 2007-05-30 2:39 UTC (permalink / raw)
To: Han-Wen Nienhuys
Cc: Johannes Sixt, Nguyen Thai Ngoc Duy, Marius Storm-Olsen, git
In-Reply-To: <465CDE61.40103@xs4all.nl>
Hi,
On Tue, 29 May 2007, Han-Wen Nienhuys wrote:
> Johannes Sixt escreveu:
> >> I'd suggest create a small C wrapper to launch gitk. It would be much
> >> easier that way IMHO.
> >
> > Doh! You're right! It's even there already, right before our eyes:
> >
> > pointy..clicky..pointy..clicky (aka: cp gitk git-k)
> >
> > $ git k
> >
> > :)
>
> how about
>
> git tk
>
> that's more in line what actually happens. We can ship a gitk.bat
> that runs git-tk.
>
> BTW, I got one report that gitk doesn't work with the tcl/tk that I
> ship. Can I have other reports too? ie.
>
> "It doesn't work for me, I use windows 92"
It worked for me, using Windows XP. (But I don't remember if I had to do
some adjustments for it, or only for git-gui.)
BTW Almost any operation I run in git-gui fails, because cat is not found.
Ciao,
Dscho
^ permalink raw reply
* Re: What's new in git-gui.git
From: Shawn O. Pearce @ 2007-05-30 2:39 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0705291157540.4648@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> On Tue, 29 May 2007, Shawn O. Pearce wrote:
>
> > Apparently the Linux folks have this new fangled inotify thing that is
> > also good at telling applications about changed files. It seems the hg
> > folks are using it to speed up "hg status" by having a background daemon
> > keep track of which files are dirty, and which aren't.
>
> An SCM which runs a background process? Please, no.
Well, not required. Making it required to make things work is
clearly insane. But letting a user optionally start a background
process to monitor their working directory and cache dirty
flags for files may be faster for some users on some systems
and some workflows. And it could make git-gui more responsive.
If git-gui starts/stops the "background process" along with its
window opening/closing, who cares that its running? Especially if
it can be enabled/disabled by a little checkbox thingy?
> Next thing is, you have a daemon running which permanently scans your
> source code for copynotsoright violations.
I won't. Maybe a future employer of yours might... ;-)
--
Shawn.
^ permalink raw reply
* Re: What's new in git-gui.git
From: Shawn O. Pearce @ 2007-05-30 2:34 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20070529111836.GW4489@pasky.or.cz>
Petr Baudis <pasky@suse.cz> wrote:
> On Tue, May 29, 2007 at 06:11:08AM CEST, Shawn O. Pearce wrote:
> > Apparently the Linux folks have this new fangled inotify thing
> > that is also good at telling applications about changed files.
> > It seems the hg folks are using it to speed up "hg status" by
> > having a background daemon keep track of which files are dirty,
> > and which aren't.
>
> How well does this play with NFS? I'm working at two places and at both
> have my ~ on NFS and sometimes touch the working tree from various
> machines. Would the inotify-based approach silently fail here? Or does
> inotify just refuse to work on NFS? Quick google search suggests the
> former, which is more than ok for informative purposes but big problem
> if you actually _rely_ on the inotify to keep your index up-to-date.
>From what I've read on it thus far (which isn't much) inotify
doesn't work over NFS.
I would *never* suggest relying on inotify for everything.
But making it an option for folks who can use it may be nice.
A lot of us do work on a local filesystem. Being able to get
faster status output in those cases could be nice, especially on
a big tree and slow VFS systems like Windows.
--
Shawn.
^ permalink raw reply
* Re: GIT on MinGW problem
From: Han-Wen Nienhuys @ 2007-05-30 2:16 UTC (permalink / raw)
To: Johannes Sixt
Cc: Nguyen Thai Ngoc Duy, Johannes Schindelin, Marius Storm-Olsen,
git
In-Reply-To: <465C4B0E.C34795B@eudaptics.com>
Johannes Sixt escreveu:
>> I'd suggest create a small C wrapper to launch gitk. It would be much
>> easier that way IMHO.
>
> Doh! You're right! It's even there already, right before our eyes:
>
> pointy..clicky..pointy..clicky (aka: cp gitk git-k)
>
> $ git k
>
> :)
how about
git tk
that's more in line what actually happens. We can ship a gitk.bat
that runs git-tk.
BTW, I got one report that gitk doesn't work with the tcl/tk that I
ship. Can I have other reports too? ie.
"It doesn't work for me, I use windows 92"
"It works for me, I use windows QZ"
etc.?
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: [PATCH] rev-parse: Identify short sha1 sums correctly.
From: Shawn O. Pearce @ 2007-05-30 2:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, James Bowes
In-Reply-To: <7vabvn5hca.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> James Bowes <jbowes@dangerouslyinc.com> writes:
>
> > find_short_packed_object was not loading the pack index files.
> > Teach it to do so.
> >
> > Signed-off-by: James Bowes <jbowes@dangerouslyinc.com>
>
> I think this is the proper fix of the problem I was unhappy
> about with 'next'
Actually this bug is exactly the reason why I *always* run 'next'
in production use on all of my systems, and why I also get a number
of coworkers to run it. Many people beating on the same code in
weird ways notice things.
Today I found this because I have a shell script that tried to
do something of the form "git checkout v1.8.0-18-g18as1f' and Git
couldn't believe that was a revision... It held up day-job work
for an hour while I tracked it down, but I did catch it. ;-)
--
Shawn.
^ permalink raw reply
* Re: [PATCH] rev-parse: Identify short sha1 sums correctly.
From: Shawn O. Pearce @ 2007-05-30 1:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, James Bowes
In-Reply-To: <7vabvn5hca.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> James Bowes <jbowes@dangerouslyinc.com> writes:
>
> > find_short_packed_object was not loading the pack index files.
> > Teach it to do so.
> >
> > Signed-off-by: James Bowes <jbowes@dangerouslyinc.com>
>
> I think this is the proper fix of the problem I was unhappy
> about with 'next', rather than reverting the lazy index
> loading. But I wonder how many _other_ places like this there
> are that we might be missing...
>
> Shawn, an Ack, and any ideas for futureproofing?
Ack, though late. ;-)
I actually found this exact same bug today. At first I thought it
was related to alternates, but when I dug into the code I came up
with basically the same patch as James did. His was sent in first
and is logically identical, so I'm not going to send my version.
With regards to future proofing this, I have no idea. I'm going to
write up a test case that catches this and submit that, to avoid a
future regression here, but otherwise I'm not sure what we can do.
I had thought I had visited every callsite and checked them, but
apparently that wasn't true.
What would probably help is to change the name of the structure
member in the .h file when its initialization time changes (or its
meaning changes in a subtle way) and then go through and manually
update every mention of the old name to the new name, then flip it
back with a global search and replace when done.
E.g. I should have done:
* in cache.h rename num_objects to num_objects_SHAWNCHANGEHERE;
* manually update every num_objects usage to my private name;
* finally globally search-replace back to the standard name.
It would have forced me to more carefully visit every damn callsite.
I'll go back through the code tonight and double check my work,
because this bug was completely my fault. I'm hoping this was the
only bug however.
--
Shawn.
^ permalink raw reply
* [PATCH] cvsimport: add support for new style remote layout
From: Andy Whitcroft @ 2007-05-30 0:56 UTC (permalink / raw)
To: git
cvsimport creates any branches found in the remote CVS repository
in the refs/heads namespace. This makes sense for a repository
conversion. When using git as a sane interface to a remote CVS
repository, that repository may well remain as the 'master'
respository. In this model it makes sense to import the CVS
repository into the refs/remotes namespace.
Add a new option '-r <remote>' to set the remote name for
this import. When this option is specified branches are named
refs/remotes/<remote>/branch, with HEAD named as master matching
git-clone separate remotes layout. Without branches are placed
ion refs/heads, with HEAD named origin as before.
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
---
Given that separate remotes is the default for 1.5
it could be argued that this the default should be the
equivalent of '-r origin'. This patch does not do that.
---
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index f68afe7..f16ac3d 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -29,7 +29,7 @@ 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_P, $opt_s,$opt_m,$opt_M,$opt_A,$opt_S,$opt_L, $opt_a);
+our ($opt_h,$opt_o,$opt_v,$opt_k,$opt_u,$opt_d,$opt_p,$opt_C,$opt_z,$opt_i,$opt_P, $opt_s,$opt_m,$opt_M,$opt_A,$opt_S,$opt_L, $opt_a, $opt_r);
my (%conv_author_name, %conv_author_email);
sub usage(;$) {
@@ -114,7 +114,7 @@ sub read_repo_config {
}
}
-my $opts = "haivmkuo:d:p:C:z:s:M:P:A:S:L:";
+my $opts = "haivmkuo:d:p:r:C:z:s:M:P:A:S:L:";
read_repo_config($opts);
getopts($opts) or usage();
usage if $opt_h;
@@ -134,13 +134,21 @@ if ($opt_d) {
} else {
usage("CVSROOT needs to be set");
}
-$opt_o ||= "origin";
$opt_s ||= "-";
$opt_a ||= 0;
my $git_tree = $opt_C;
$git_tree ||= ".";
+my $remote;
+if (defined $opt_r) {
+ $remote = 'refs/remotes/' . $opt_r;
+ $opt_o ||= "master";
+} else {
+ $opt_o ||= "origin";
+ $remote = 'refs/heads';
+}
+
my $cvs_tree;
if ($#ARGV == 0) {
$cvs_tree = $ARGV[0];
@@ -522,7 +530,7 @@ sub get_headref ($$) {
my $name = shift;
my $git_dir = shift;
- my $f = "$git_dir/refs/heads/$name";
+ my $f = "$git_dir/$remote/$name";
if (open(my $fh, $f)) {
chomp(my $r = <$fh>);
is_sha1($r) or die "Cannot get head id for $name ($r): $!";
@@ -573,12 +581,12 @@ unless (-d $git_dir) {
# Get the last import timestamps
my $fmt = '($ref, $author) = (%(refname), %(author));';
- open(H, "git-for-each-ref --perl --format='$fmt' refs/heads |") or
+ open(H, "git-for-each-ref --perl --format='$fmt' $remote |") or
die "Cannot run git-for-each-ref: $!\n";
while (defined(my $entry = <H>)) {
my ($ref, $author);
eval($entry) || die "cannot eval refs list: $@";
- my ($head) = ($ref =~ m|^refs/heads/(.*)|);
+ my ($head) = ($ref =~ m|^$remote/(.*)|);
$author =~ /^.*\s(\d+)\s[-+]\d{4}$/;
$branch_date{$head} = $1;
}
@@ -701,9 +709,9 @@ sub commit {
$index{$branch} = tmpnam();
$ENV{GIT_INDEX_FILE} = $index{$branch};
if ($ancestor) {
- system("git-read-tree", $ancestor);
+ system("git-read-tree", "$remote/$ancestor");
} else {
- system("git-read-tree", $branch);
+ system("git-read-tree", "$remote/$branch");
}
die "read-tree failed: $?\n" if $?;
}
@@ -762,7 +770,7 @@ sub commit {
waitpid($pid,0);
die "Error running git-commit-tree: $?\n" if $?;
- system("git-update-ref refs/heads/$branch $cid") == 0
+ system("git-update-ref $remote/$branch $cid") == 0
or die "Cannot write branch $branch for update: $!\n";
if ($tag) {
@@ -883,12 +891,12 @@ while (<CVS>) {
print STDERR "Branch $branch erroneously stems from itself -- changed ancestor to $opt_o\n";
$ancestor = $opt_o;
}
- if (-f "$git_dir/refs/heads/$branch") {
+ if (-f "$git_dir/$remote/$branch") {
print STDERR "Branch $branch already exists!\n";
$state=11;
next;
}
- unless (open(H,"$git_dir/refs/heads/$ancestor")) {
+ unless (open(H,"$git_dir/$remote/$ancestor")) {
print STDERR "Branch $ancestor does not exist!\n";
$ignorebranch{$branch} = 1;
$state=11;
@@ -896,7 +904,7 @@ while (<CVS>) {
}
chomp(my $id = <H>);
close(H);
- unless (open(H,"> $git_dir/refs/heads/$branch")) {
+ unless (open(H,"> $git_dir/$remote/$branch")) {
print STDERR "Could not create branch $branch: $!\n";
$ignorebranch{$branch} = 1;
$state=11;
@@ -1010,13 +1018,13 @@ if ($orig_branch) {
die "Fast-forward update failed: $?\n" if $?;
}
else {
- system(qw(git-merge cvsimport HEAD), "refs/heads/$opt_o");
+ system(qw(git-merge cvsimport HEAD), "$remote/$opt_o");
die "Could not merge $opt_o into the current branch.\n" if $?;
}
} else {
$orig_branch = "master";
print "DONE; creating $orig_branch branch\n" if $opt_v;
- system("git-update-ref", "refs/heads/master", "refs/heads/$opt_o")
+ system("git-update-ref", "refs/heads/master", "$remote/$opt_o")
unless -f "$git_dir/refs/heads/master";
system('git-update-ref', 'HEAD', "$orig_branch");
unless ($opt_i) {
^ permalink raw reply related
* Re: [PATCH] rev-parse: Identify short sha1 sums correctly.
From: James Bowes @ 2007-05-30 1:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Shawn Pearce
In-Reply-To: <7vtztv3zf1.fsf@assigned-by-dhcp.cox.net>
On 5/29/07, Junio C Hamano <junkio@cox.net> wrote:
> Thanks, James.
Glad to help when I can.
> This seems to fix the bug I mentioned about 'next' in the last
> "What's cooking" message. Also I have been seeing a segfault
> from rev-parse in t5500 (rev-parse --short hits the same issue,
> because the bug caused object name not to be abreviated) but
> that is also fixed with this patch.
>
> Will apply, instead of reverting the "lazy index loading".
>
>
>
-James
^ permalink raw reply
* Re: [PATCH] rev-parse: Identify short sha1 sums correctly.
From: Junio C Hamano @ 2007-05-30 0:53 UTC (permalink / raw)
To: James Bowes; +Cc: git, Shawn Pearce
In-Reply-To: <1180481391179-git-send-email-jbowes@dangerouslyinc.com>
Thanks, James.
This seems to fix the bug I mentioned about 'next' in the last
"What's cooking" message. Also I have been seeing a segfault
from rev-parse in t5500 (rev-parse --short hits the same issue,
because the bug caused object name not to be abreviated) but
that is also fixed with this patch.
Will apply, instead of reverting the "lazy index loading".
^ permalink raw reply
* Re: [PATCH] diff-delta: use realloc instead of xrealloc
From: Junio C Hamano @ 2007-05-29 23:51 UTC (permalink / raw)
To: Martin Koegler; +Cc: git
In-Reply-To: <1180465715346-git-send-email-mkoegler@auto.tuwien.ac.at>
Martin Koegler <mkoegler@auto.tuwien.ac.at> writes:
> Commit 83572c1a914d3f7a8dd66d954c11bbc665b7b923 changed many
> realloc to xrealloc. This change was made in diff-delta.c too,
> although the code can handle an out of memory failure.
>
> This patch reverts this change in diff-delta.c.
Wasn't there a discussion around this exact issue when the
original patch was applied?
^ permalink raw reply
* Re: [PATCH] Don't ignore write failure from git-diff, git-log, etc.
From: Junio C Hamano @ 2007-05-29 23:50 UTC (permalink / raw)
To: Jim Meyering; +Cc: Marco Roeland, git
In-Reply-To: <87veebs84i.fsf@rho.meyering.net>
Jim Meyering <jim@meyering.net> writes:
> ...
> Also, to be consistent with e.g., write_or_die, do not
> diagnose EPIPE write failures.
>
> Signed-off-by: Jim Meyering <jim@meyering.net>
> ---
> git.c | 19 ++++++++++++++++++-
> 1 files changed, 18 insertions(+), 1 deletions(-)
>
> diff --git a/git.c b/git.c
> index 29b55a1..8258885 100644
> --- a/git.c
> +++ b/git.c
> @@ -308,6 +308,7 @@ static void handle_internal_command(int argc, const char **argv, char **envp)
> for (i = 0; i < ARRAY_SIZE(commands); i++) {
> struct cmd_struct *p = commands+i;
> const char *prefix;
> + int status;
> if (strcmp(p->cmd, cmd))
> continue;
>
> @@ -321,7 +322,23 @@ static void handle_internal_command(int argc, const char **argv, char **envp)
> die("%s must be run in a work tree", cmd);
> trace_argv_printf(argv, argc, "trace: built-in: git");
>
> - exit(p->fn(argc, argv, prefix));
> + status = p->fn(argc, argv, prefix);
> +
> + /* Close stdout if necessary, and diagnose any failure
> + other than EPIPE. */
> + if (fcntl(fileno (stdout), F_GETFD) >= 0) {
> + errno = 0;
> + if ((ferror(stdout) || fclose(stdout))
> + && errno != EPIPE) {
> + if (errno == 0)
> + die("write failure on standard output");
> + else
> + die("write failure on standard output"
> + ": %s", strerror(errno));
> + }
This makes the final write failure trump the breakage p->fn()
already diagnosed, doesn't it? Maybe if (fcntrl(...) >=0 )
should read if (!status && fcntrl(...) >= 0).
> + }
> +
> + exit(status);
> }
> }
>
> --
> 1.5.2.73.g18bece
^ permalink raw reply
* Re: [PATCH] rev-parse: Identify short sha1 sums correctly.
From: Junio C Hamano @ 2007-05-29 23:40 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git, James Bowes
In-Reply-To: <1180478596243-git-send-email-jbowes@dangerouslyinc.com>
James Bowes <jbowes@dangerouslyinc.com> writes:
> find_short_packed_object was not loading the pack index files.
> Teach it to do so.
>
> Signed-off-by: James Bowes <jbowes@dangerouslyinc.com>
I think this is the proper fix of the problem I was unhappy
about with 'next', rather than reverting the lazy index
loading. But I wonder how many _other_ places like this there
are that we might be missing...
Shawn, an Ack, and any ideas for futureproofing?
> sha1_name.c | 7 +++++--
> 1 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/sha1_name.c b/sha1_name.c
> index 8dfceb2..7df01af 100644
> --- a/sha1_name.c
> +++ b/sha1_name.c
> @@ -76,8 +76,11 @@ static int find_short_packed_object(int len, const unsigned char *match, unsigne
>
> prepare_packed_git();
> for (p = packed_git; p && found < 2; p = p->next) {
> - uint32_t num = p->num_objects;
> - uint32_t first = 0, last = num;
> + uint32_t num, last;
> + uint32_t first = 0;
> + open_pack_index(p);
> + num = p->num_objects;
> + last = num;
> while (first < last) {
> uint32_t mid = (first + last) / 2;
> const unsigned char *now;
> --
> 1.5.2.869.g6b3ba
^ permalink raw reply
* [PATCH] rev-parse: Identify short sha1 sums correctly.
From: James Bowes @ 2007-05-29 23:29 UTC (permalink / raw)
To: git, junkio
find_short_packed_object was not loading the pack index files.
Teach it to do so.
Signed-off-by: James Bowes <jbowes@dangerouslyinc.com>
---
sha1_name.c | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index 8dfceb2..7df01af 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -76,8 +76,11 @@ static int find_short_packed_object(int len, const unsigned char *match, unsigne
prepare_packed_git();
for (p = packed_git; p && found < 2; p = p->next) {
- uint32_t num = p->num_objects;
- uint32_t first = 0, last = num;
+ uint32_t num, last;
+ uint32_t first = 0;
+ open_pack_index(p);
+ num = p->num_objects;
+ last = num;
while (first < last) {
uint32_t mid = (first + last) / 2;
const unsigned char *now;
--
1.5.2.869.g6b3ba
^ permalink raw reply related
* Re: [PATCH (tig)] Infrastructure for tig rpm builds.
From: Jakub Narebski @ 2007-05-29 23:31 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git
In-Reply-To: <20070529202923.GA6358@diku.dk>
On Tue, 29 May 2007, Jonas Fonseca wrote:
> Jakub Narebski <jnareb@gmail.com> wrote Mon, May 28, 2007:
>> Minimally tested (meaning "make rpm" from tig repository works).
>
> Trying 'make rpm' on ubuntu 7.04 I get:
>
> $ rpmbuild -ta tig-0.6.g2463b4e.tar.gz
> error: Name field must be present in package: (main package)
> error: Version field must be present in package: (main package)
> error: Release field must be present in package: (main package)
> error: Summary field must be present in package: (main package)
> error: Group field must be present in package: (main package)
> error: License field must be present in package: (main package)
> $ ls -l /usr/src/rpm/SPECS/
> total 0
> -rw------- 1 root root 0 2007-05-29 21:46 tar: Pattern matching characters used in file names. Please,
>
> Strange.
Hmmm... WORKSFORME. Aurox 11.1 (Fedora Core 4 based distribution),
with rpm 4.4.1. By the way, isn't Ubuntu based on Debian? Do you
have rpmbuild installed?
BTW. perhaps you could provide spec equivalent for building tig*.deb?
1000:[master!tig]$ make rpm
sed -e 's/@@VERSION@@/0.6.5.g2bba6eb/g' < tig.spec.in > tig.spec+
mv tig.spec+ tig.spec
git-archive --format=tar \
--prefix=tig-0.6.5.g2bba6eb/ HEAD^{tree} > tig-0.6.5.g2bba6eb.tar
tar rf tig-0.6.5.g2bba6eb.tar \
tig-0.6.5.g2bba6eb/tig.spec \
tig-0.6.5.g2bba6eb/version
gzip -f -9 tig-0.6.5.g2bba6eb.tar
rpmbuild -ta tig-0.6.5.g2bba6eb.tar.gz
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.85822
+ umask 022
+ cd /home/local/builddir/BUILD
+ LANG=C
+ export LANG
+ unset DISPLAY
+ cd /home/local/builddir/BUILD
+ rm -rf tig-0.6.5.g2bba6eb
+ /usr/bin/gzip -dc /home/jnareb/tig/tig-0.6.5.g2bba6eb.tar.gz
+ tar -xf -
+ STATUS=0
>> Signed-off-by: Jakub Narebski <jnareb@gmail.com>
>> ---
>> 'tig.spec.in' is based on 'git.spec.in' from git repository.
>>
>> This is the initial, minimal version. For example it does not add
>> TIG-VERSION-GEN file and the rest of versioning infrastructure that is
>> used in git Makefile.
>
> I would prefer to do without. ;)
I think we can do without it, but in current implementation there is
no guarantee that we would not get wrong version.
[...]
>> P.S. I have build tig-0.6.4.g9eded37-1.i386.rpm using "make rpm" from
>> tig repository, and installed it without problems, but when trying to
>> build it again _without network_ it failed on building
>> manual.pdf. Error log attached.
>
> Looks like some problems with the SGML catalogs info.
If I only knew how to debug that...
>> I think we can skip generation of manual.pdf, and generate it only on
>> request (e.g. "make doc-pdf"), or using doc-man and doc-html in place
>> of doc in the spec file... but this is better left for the next
>> commit.
>
> Good idea, PDF is not essential and probably suboptimal to either of the
> HTML versions of the manual.
And it is very easy to implement: just replace 'doc' in make invocation
in tig.spec.in by the 'doc-man doc-html'.
>> By the way, why do you use xmlto and docbook2pdf, instead of a2x from
>> asciidoc package?
>
> It is a fairly recent addition to the asciidoc. Besides, I just tried it
> and it seems to be completely unusable on ubuntu because of the way it
> has been packaged; it cannot find required files.
Fair enough.
[...]
>> diff --git a/Makefile b/Makefile
>> index 06a5d6a..45c833b 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -18,8 +18,16 @@ DOCS = $(DOCS_MAN) $(DOCS_HTML) \
>> ifneq (,$(wildcard .git))
>> VERSION = $(shell git-describe)
>> WTDIRTY = $(shell git-diff-index --name-only HEAD 2>/dev/null)
>> -CFLAGS += '-DVERSION="$(VERSION)$(if $(WTDIRTY),-dirty)"'
>> +else
>> +GEN_VER="tig-0.6.TIG"
>> +VERSION = $(shell test -f version && cat version || echo "$(GEN_VER)")
>> endif
>> +CFLAGS += '-DVERSION="$(VERSION)$(if $(WTDIRTY),-dirty)"'
>> +RPM_VERSION = $(subst tig-,,$(VERSION))
>> +RPM_VERSION := $(subst -,.,$(RPM_VERSION))
>
> I will probably try to simplify and clean this up a bit.
That would be nice.
[...]
>> +dist: tig.spec
>> + git-archive --format=tar \
>> + --prefix=$(TARNAME)/ HEAD^{tree}> $(TARNAME).tar
>> + @mkdir -p $(TARNAME)
>> + @cp tig.spec $(TARNAME)
>> + @echo $(VERSION)> $(TARNAME)/version
>> + tar rf $(TARNAME).tar \
>> + $(TARNAME)/tig.spec \
>> + $(TARNAME)/version
>> + @rm -rf $(TARNAME)
>> + gzip -f -9 $(TARNAME).tar
>
> Does the .spec file need to be in the tarball for rpm to work? I mean,
> if it can be generated from .spec.in, I would rather have the rpm target
> create it?
Having .spec file in the tarbal allows to download tarball and use
'rpmbuild -ta tig-*.tar.gz' to build rpms; no need to unpack then do
'make rpm'.
Besides rpm target makes use of this, although there is alternate
solution.
>> +rpm: dist
>> + rpmbuild -ta $(TARNAME).tar.gz
[...]
>> +BuildRequires: ncurses-devel%{!?_without_docs:, xmlto, asciidoc> 6.0.3, /usr/bin/docbook2pdf}
>
> Is the last entry a shorthand for the doc dependencies you listed above?
Nope, the list of packages was because the error with creating
manual.pdf might depend on versions of packages I have installed.
The last entry written using name of binary (needed to generate
manual.pdf) because I think where this tool can be found, i.e.
in which package, might depend on distribution you use. For example
in FC4 it is in docbook-utils-pdf package.
[...]
>> +%files
>> +%defattr(-,root,root)
>> +%{_bindir}/*
>> +%doc README COPYING INSTALL SITES BUGS TODO tigrc
By the way, should we put tigrc in examples/tigrc, or perhaps in some
skeleton file?
> I don't know if manual.txt should perhaps be included if
> HTML and PDF files will not be generated.
>
>> +%{!?_without_docs: %{_mandir}/man1/*.1*}
>> +%{!?_without_docs: %{_mandir}/man5/*.5*}
>> +%{!?_without_docs: %doc *.html *.pdf}
O.K. It would be as easy as %{?_without_docs: %doc *.txt}
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] gitweb: handle non UTF-8 text
From: Martin Koegler @ 2007-05-29 21:55 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Petr Baudis, git, Martin Langhoff, Martyn Smith
In-Reply-To: <200705291121.12119.jnareb@gmail.com>
On Tue, May 29, 2007 at 11:21:11AM +0200, Jakub Narebski wrote:
> On Tue, 29 May 2007, Petr Baudis wrote:
> > On Mon, May 28, 2007 at 10:47:34PM CEST, Martin Koegler wrote:
>
> >> gitweb assumes, that everything is in UTF-8. If a text contains invalid
> >> UTF-8 character sequences, the text must be in a different encoding.
>
> But it doesn't tell us _what_ is the encoding. For commit messages,
> with reasonable new git, we have 'encoding' header if git known that
> commit message was not in utf-8.
>
> By the way, I winder why we don't have such header for tag objects
> (i18n.tagEncoding ;-)...
Why do I need to set i18n.commitEncoding on a normal Linux systems? We
have a locale, which contains this information. With this, its more
likely, that the commits can be read correctly later, if somebody
forget to set "i18n.commitEncoding" in a repository.
> >> This patch interprets such a text as latin1.
>
> Meaning that it tries to recode text from latin1 (iso-8859-1) to utf-8
> (not changing gitweb output encoding, which is utf-8).
>
> It would be much better, and much easier at least for commit message
> to add --encoding=utf-8 to git-rev-list / git-log invocation.
It does not help for old commits, where the encoding was not specified
correctly. If my research is correct, the encoding handling was
introduced at the end of 2006 and released this february.
> >> Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
> >> ---
> >> For correct UTF-8, the patch does not change anything.
> >>
> >> If commit/blob/... is not in UTF-8, it displays the text
> >> with a very high probability correct.
>
> It is commit (with its 'encoding' header, and `--encoding' option
> we can use instead of doing it in gitweb, provided that git was
> compiled with iconv support), tag (similar to commit, but IIRC
> without 'encoding' header, and `--encoding' option), blob (with
> no place to store encoding) and pathname in tree (which can be
> different from blob encoding).
>
> And I doubt very much about this "very high probability to be
> correct".
For normal text, this should be true:
We can divide ISO-8859-1 into some groups:
a) 0x00-0x7f: shared with UTF-8
b) 0x80-0xBF: continuation characters in UTF-8 (0x80-0x9F are control characters/unused)
c) 0xC0-0xDF: start of a two byte UTF-8 character
d) 0xE0-0xEF: start of a tree byte UTF-8 character
e) 0xF0-0xFF: start of other longer UTF-8 sequences
To misinterpret a ISO-8859-1 text as UTF-8, each character of class
c/d/e must be followed by the correct number of character of class b.
Character of class b are "special character", characters of class
c/d/e are mostly special letters. As "special character" are normally not part
of a word (at least in German), any occurence of c/d/e at the begin
or the in the middle of the word will therefore result in a invalid UTF-8
sequence. Only a occurence of c/d/e at the end of an word, which is
followed by the correct number occurences of class b result in a correct UTF-8
sequence.
In german, the commonly used character of c/d/e are: ÄÖÜäöüß
The uppercase ÄÖÜ appear ony at the beginning of a word => invalid combination.
Other combinations:
* äöü followed by two "special characters" (I don't know, where such a combination could occur).
* ß followed by one "special character" (I regard this as the most likly misinterpretation).
I can not speak for other languages. If you doubt, please look at an
character table (eg. http://en.wikipedia.org/wiki/ISO-8859-1#ISO-8859-1)
and think about the possibiltiy of UTF-8 compatible combinations in your languague.
As gitweb is processing a line of text at once, one UTF-8 compatible
combinations has no effect, if any other non UTF-8 combatible
character sequence occurs.
> >> As git itself is not aware of any encoding, I know no better
> >> possibility to handle non UTF-8 text in gitweb.
> >
> > I don't think this is a reasonable approach; I actually dispute the high
> > probability - in western Europe it's obvious to assume latin1, but does
> > majority of users using non-ascii characters come from there? Or rather
> > from central Europe (like me, Petr Baudiš? ;-))? Somewhere else?
>
> I also don't think that hardcoding latin1 (iso-8859-1) as default
> alternate encoding is a good idea. I don't think using iso-8859-1
> (outside us-ascii) is _nowadays_ that common. On the other hand I think
> that not all users of koi8r, eucjp or iso-2022-jp converted (and can
> convert) to utf-8; latin1 users can.
UTF-8 is not the universal, dropin solution for ISO-8859-1. It has some drawbacks:
- Some operations are slower, eg.
$$ hexdump -C s
00000000 78 0a 78 0a 78 0a 78 0a 78 0a 78 0a 78 0a 78 0a |x.x.x.x.x.x.x.x.|
*
01000000
$ grep --version
grep (GNU grep) 2.5.1
$LANG=en_US.ISO-8859-15 time grep "[a]" s
Command exited with non-zero status 1
0.38user 0.05system 0:00.46elapsed 93%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+219minor)pagefaults 0swaps
$ LANG=en_US.UTF-8 time grep "[a]" s
Command exited with non-zero status 1
10.86user 0.31system 0:14.29elapsed 78%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+17151minor)pagefaults 0swaps
- Anything using string length/character position is more complicated.
For some problems, UTF-16 might be a simpler solution.
But I agree, that there should be the possibilty to choose a the
fallback encoding.
> And using latin1 (other encoding) _only_ when there is an invalid utf-8
> sequence is not a good idea either; I think that that there are some
> latin1 sequences outside us-ascii which are valid utf-8 sequences. That
> kind of magic is wrong, wrong, wrong...
Please tell me a better alternative. The non UTF-8 will be in the history
(in blobs/trees/commits/..) forever, where it can not be changed.
I need a solution for this. I can use this patch on my system, but I
would like to see support other encodings in upstream gitweb.
> > If we do something like this, we should do it properly and look at
> > configured i18n.commitEncoding for the project. (But as config lookup
> > may be expensive, probably do it only when we need it.)
>
> I think it would be best to make it into %feature, overridable
> or not (which would look at i18n.commitEncoding instead of at
> gitweb.commitEncoding, but still a feature).
I would use i18n.commitEncoding only as last fallback. In a project
more different encodings could be used and the guessing logic may need
additional parameter, so I would create a own set of config parameters
for this.
> About config lookup: we can either "borrow" config reading code in Perl
> from git-cvsserver, perhaps via putting it into Git.pm. Or we can
> implement at last core git support for dumping whole config in
> unambiguous machine parseable output: "git config --dump", e.g.
> key <LF> value <NUL>
> or
> key <NUL>
> (the second for "boolean" variables without set value).
If we use a new file (in the gitweb config format), the whole thing
will be faster and less complicated.
mfg Martin Kögler
^ permalink raw reply
* Re: [PATCH] Don't ignore write failure from git-diff, git-log, etc.
From: Linus Torvalds @ 2007-05-29 21:19 UTC (permalink / raw)
To: Jim Meyering; +Cc: git
In-Reply-To: <87r6ozs7q5.fsf@rho.meyering.net>
On Tue, 29 May 2007, Jim Meyering wrote:
> >
> > Maybe you have not noticed, but my argument has ben about EPIPE.
>
> Ha ha. That's a good one.
> The point was that even you must see that your
> "[Jim's] WHOLE patch is crap" statement was wrong.
Ehh. That's a rather edited version of what I said, isn't it?
That's after I explicitly _quoted_ the part where you actively removed the
code that said "EPIPE is right", and also after I had told you several
times that you should consider EPIPE as a special case in your other part.
In other words, yes, EVERY SINGLE HUNK of your patch was wrong, and I had
told you exactly why.
How wrong does a patch have to be to be "crap"? Maybe I have higher
standards than you do (apparently so), but "every single hunk was wrong"
should certainly be a damn good reason to consider _any_ patch crap,
wouldn't you say?
And now you have trouble accepting that, even after you have sent out a
fixed patch without the crap. Thanks for finally bothering to get the
patch right, but I don't see why you have to try to make-believe that it
was ever about anything but EPIPE.
So go back and read my emails. You'll see that in every single one I made
it very clear that EPIPE was special. From the very first one (where I
didn't call your patch crap, btw: I said it was wrong, and that some
errors are expected and good, and I explicitly told you about EPIPE).
So what did you do? Instead of acknowledging that EPIPE was different, you
actually *expanded* on that original patch, and made the other places
where we _did_ handle EPIPE correctly, and made those places handle it
_incorrectly_.
And then you expect me to be _polite_ about it? Grow up. I was polite
before you started explicitly doing the reverse of what I told you you
should do. At that point, your patch went from "meant well, but the patch
was wrong" to "That's just obviously crap".
Linus
^ permalink raw reply
* Re: [PATCH (tig)] Infrastructure for tig rpm builds.
From: Jonas Fonseca @ 2007-05-29 20:29 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200705281054.05376.jnareb@gmail.com>
Hej Jakub,
Jakub Narebski <jnareb@gmail.com> wrote Mon, May 28, 2007:
> Adds RPM_VERSION to Makefile and new make targets: tig.spec, dist, and
> rpm. A simple 'make rpm' will build the rpm. Also adds tig.spec.in
> which is used to generate tig.spec.
Thank you. :)
> Accidentally VERSION (and adding -DVERSION=$(VERSION) to CFLAGS) is
> now defined always, even if we do not compile from the "live" tig
> repository.
Yeah, this is probably a good idea; the same goes for moving version
info to a file instead of having it in tig.c.
> Minimally tested (meaning "make rpm" from tig repository works).
Trying 'make rpm' on ubuntu 7.04 I get:
$ rpmbuild -ta tig-0.6.g2463b4e.tar.gz
error: Name field must be present in package: (main package)
error: Version field must be present in package: (main package)
error: Release field must be present in package: (main package)
error: Summary field must be present in package: (main package)
error: Group field must be present in package: (main package)
error: License field must be present in package: (main package)
$ ls -l /usr/src/rpm/SPECS/
total 0
-rw------- 1 root root 0 2007-05-29 21:46 tar: Pattern matching characters used in file names. Please,
Strange.
> Signed-off-by: Jakub Narebski <jnareb@gmail.com>
> ---
> 'tig.spec.in' is based on 'git.spec.in' from git repository.
>
> This is the initial, minimal version. For example it does not add
> TIG-VERSION-GEN file and the rest of versioning infrastructure that is
> used in git Makefile.
I would prefer to do without. ;)
> Commands used to get version string (in RPM_VERSION) suitable as a
> version field in the rpm can, most probably, be improved. Perhaps
> (with the new git-describe output) we should put closest version tag
> as version of tig in rpm, and distance from the tag (perhaps plus 1)
> as release number (in the rpm sense).
>
> TODO: Change '--without docs' to '--with rebuild-docs' and use
> pre-generated docs when creating rpm, instead of generating them (and
> requiring asciidoc, xmlto and docbook2pdf to build rpm if we want tig
> documentation).
Yeah, once the "official" tarballs contains the version info, this
sounds like a good idea.
> P.S. I have build tig-0.6.4.g9eded37-1.i386.rpm using "make rpm" from
> tig repository, and installed it without problems, but when trying to
> build it again _without network_ it failed on building
> manual.pdf. Error log attached.
Looks like some problems with the SGML catalogs info.
> asciidoc-7.1.2-2.fc3.rf
> docbook-dtds-1.0-26
> docbook-style-dsssl-1.79-1
> docbook-style-xsl-1.68.1-1
> docbook-utils-0.6.14-4
> docbook-utils-pdf-0.6.14-4
> jadetex-3.12-13
> openjade-1.3.2-16
>
> I think we can skip generation of manual.pdf, and generate it only on
> request (e.g. "make doc-pdf"), or using doc-man and doc-html in place
> of doc in the spec file... but this is better left for the next
> commit.
Good idea, PDF is not essential and probably suboptimal to either of the
HTML versions of the manual.
> By the way, why do you use xmlto and docbook2pdf, instead of a2x from
> asciidoc package?
It is a fairly recent addition to the asciidoc. Besides, I just tried it
and it seems to be completely unusable on ubuntu because of the way it
has been packaged; it cannot find required files.
> .gitignore | 2 ++
> Makefile | 34 ++++++++++++++++++++++++++++++++--
> tig.spec.in | 56 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 90 insertions(+), 2 deletions(-)
> create mode 100644 tig.spec.in
>
> diff --git a/.gitignore b/.gitignore
> index 8f6aa93..f7ab840 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -2,3 +2,5 @@ manual.html-chunked
> manual.pdf
> manual.toc
> tig
> +tig.spec
> +tig-*.tar.gz
> diff --git a/Makefile b/Makefile
> index 06a5d6a..45c833b 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -18,8 +18,16 @@ DOCS = $(DOCS_MAN) $(DOCS_HTML) \
> ifneq (,$(wildcard .git))
> VERSION = $(shell git-describe)
> WTDIRTY = $(shell git-diff-index --name-only HEAD 2>/dev/null)
> -CFLAGS += '-DVERSION="$(VERSION)$(if $(WTDIRTY),-dirty)"'
> +else
> +GEN_VER="tig-0.6.TIG"
> +VERSION = $(shell test -f version && cat version || echo "$(GEN_VER)")
> endif
> +CFLAGS += '-DVERSION="$(VERSION)$(if $(WTDIRTY),-dirty)"'
> +RPM_VERSION = $(subst tig-,,$(VERSION))
> +RPM_VERSION := $(subst -,.,$(RPM_VERSION))
I will probably try to simplify and clean this up a bit.
> +
> +TARNAME=tig-$(RPM_VERSION)
> +
>
> all: $(PROGS)
> all-debug: $(PROGS)
> @@ -57,6 +65,9 @@ install-doc: install-doc-man install-doc-html
> clean:
> rm -rf manual.html-chunked
> rm -f $(PROGS) $(DOCS) core *.xml
> + rm -f *.spec
> + rm -rf $(TARNAME)
> + rm -f $(TARNAME).tar.gz
>
> spell-check:
> aspell --lang=en --check tig.1.txt tigrc.5.txt manual.txt
> @@ -64,7 +75,7 @@ spell-check:
> strip: all
> strip $(PROGS)
>
> -.PHONY: all all-debug doc doc-man doc-html install install-doc install-doc-man install-doc-html clean spell-check
> +.PHONY: all all-debug doc doc-man doc-html install install-doc install-doc-man install-doc-html clean spell-check dist rpm
>
> manual.html: manual.toc
> manual.toc: manual.txt
> @@ -119,3 +130,22 @@ sync-docs:
> make doc
> cg commit -m "Sync docs"
> cg switch master
> +
> +tig.spec: tig.spec.in
> + sed -e 's/@@VERSION@@/$(RPM_VERSION)/g' < $< > $@+
> + mv $@+ $@
> +
> +dist: tig.spec
> + git-archive --format=tar \
> + --prefix=$(TARNAME)/ HEAD^{tree} > $(TARNAME).tar
> + @mkdir -p $(TARNAME)
> + @cp tig.spec $(TARNAME)
> + @echo $(VERSION) > $(TARNAME)/version
> + tar rf $(TARNAME).tar \
> + $(TARNAME)/tig.spec \
> + $(TARNAME)/version
> + @rm -rf $(TARNAME)
> + gzip -f -9 $(TARNAME).tar
Does the .spec file need to be in the tarball for rpm to work? I mean,
if it can be generated from .spec.in, I would rather have the rpm target
create it?
> +rpm: dist
> + rpmbuild -ta $(TARNAME).tar.gz
> diff --git a/tig.spec.in b/tig.spec.in
> new file mode 100644
> index 0000000..2ce6cdb
> --- /dev/null
> +++ b/tig.spec.in
> @@ -0,0 +1,56 @@
> +# -*- mode: rpm-spec-mode; encoding: utf-8; -*-
> +# Pass '--without docs' to rpmbuild if you don't want the documentation
> +
> +Summary: Tig: text-mode interface for git
> +Name: tig
> +Version: @@VERSION@@
> +Release: 1%{?dist}
> +License: GPL
> +Group: Development/Tools
> +Vendor: Jonas Fonseca <fonseca@diku.dk>
> +URL: http://jonas.nitro.dk/tig/
> +Source: http://jonas.nitro.dk/tig/releases/%{name}-%{version}.tar.gz
> +BuildRequires: ncurses-devel%{!?_without_docs:, xmlto, asciidoc > 6.0.3, /usr/bin/docbook2pdf}
Is the last entry a shorthand for the doc dependencies you listed above?
> +BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
> +Requires: git-core, ncurses
> +
> +%description
> +Tig is a git repository browser that additionally can act as a pager
> +for output from various git commands.
> +
> +When browsing repositories, it uses the underlying git commands to
> +present the user with various views, such as summarized revision log
> +and showing the commit with the log message, diffstat, and the diff.
> +
> +Using it as a pager, it will display input from stdin and colorize it.
> +
> +%prep
> +%setup -q
> +
> +%build
> +CFLAGS="$RPM_OPT_FLAGS -DVERSION=tig-%{version}-%{release}"
> +%{__make} %{_smp_mflags} \
> + prefix=%{_prefix} \
> + all %{!?_without_docs: doc}
> +
> +%install
> +[ "$RPM_BUILD_ROOT" != "/" ] && rm -rf $RPM_BUILD_ROOT
> +CFLAGS="$RPM_OPT_FLAGS -DVERSION=tig-%{version}-%{release}"
> +%{__make} %{_smp_mflags} DESTDIR=$RPM_BUILD_ROOT \
> + prefix=%{_prefix} bindir=%{_bindir} mandir=%{_mandir} \
> + install %{!?_without_docs: install-doc-man}
> +
> +%clean
> +[ "$RPM_BUILD_ROOT" != "/" ] && rm -rf $RPM_BUILD_ROOT
> +
> +%files
> +%defattr(-,root,root)
> +%{_bindir}/*
> +%doc README COPYING INSTALL SITES BUGS TODO tigrc
I don't know if manual.txt should perhaps be included if
HTML and PDF files will not be generated.
> +%{!?_without_docs: %{_mandir}/man1/*.1*}
> +%{!?_without_docs: %{_mandir}/man5/*.5*}
> +%{!?_without_docs: %doc *.html *.pdf}
> +
> +%changelog
> +* Mon May 28 2007 Jakub Narebski <jnareb@gmail.com>
> +- Initial tig spec file
--
Jonas Fonseca
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox