* Re: [PATCH] diff-tree: stop on broken output pipe
From: Andreas Ericsson @ 2006-01-02 1:21 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0601020116020.11331@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> ---
>
> Without this, on my iBook git-whatchanged keeps running when I
> quit "less". I have to interrupt the process a second time. No
> idea why it works on Linux.
>
On Linux the sending end dies when it catches SIGPIPE. I would have
thought that should happen on OSX too. What shell are you running?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* [PATCH] diff-tree: stop on broken output pipe
From: Johannes Schindelin @ 2006-01-02 0:17 UTC (permalink / raw)
To: git, junkio
---
Without this, on my iBook git-whatchanged keeps running when I
quit "less". I have to interrupt the process a second time. No
idea why it works on Linux.
diff-tree.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
a3ff3aa99f1cc7d1e59563fbf22fed8a4f3f2d24
diff --git a/diff-tree.c b/diff-tree.c
index efa2b94..c06ccd3 100644
--- a/diff-tree.c
+++ b/diff-tree.c
@@ -25,8 +25,9 @@ static int call_diff_flush(void)
return 0;
}
if (header) {
- if (!no_commit_id)
- printf("%s%c", header, diff_options.line_termination);
+ if (!no_commit_id && printf("%s%c", header,
+ diff_options.line_termination) < 0)
+ die("broken output pipe");
header = NULL;
}
diff_flush(&diff_options);
--
1.0.GIT
^ permalink raw reply related
* Re: how to find outstanding patches in non-linux-2.6 repositories?
From: Linus Torvalds @ 2006-01-01 23:09 UTC (permalink / raw)
To: Olaf Hering; +Cc: git
In-Reply-To: <20060101200121.GA20633@suse.de>
On Sun, 1 Jan 2006, Olaf Hering wrote:
>
> How do I get a list of commits in the 'powerpc' tree, which are not part
> of the 'linux-2.6' tree? The git tutorial has a section 'Working with
> Others', but the examples dont work for me. Probably because
> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git has
> no info that it is not the "mainline tree".
> All I need is a list of individual commits in that tree, which are not
> (yet) in "mainline".
First, get a kernel tree, let's say that you just get the standard one
and thus my head will be in "origin" (and perhaps HEAD too, unless you
decide to do some stuff of your own). Then just do something like
git fetch \
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git \
master:powerpc
which gets the master branch from the powerpc.git tree into your "powerpc"
branch (or set up a .git/remotes/powerpc thing if you expect to do more of
this).
Then you can just do
gitk origin..powerpc
(or "git log" or "git-whatchanged -p" instead of "gitk") to see the
commits that are in powerpc but not in "origin".
Linus
^ permalink raw reply
* [PATCH] Documentation/git-svnimport: document -T and -t switches correctly
From: Eric Wong @ 2006-01-01 21:32 UTC (permalink / raw)
To: git list, Matthias Urlichs
The -T and -t switches are swapped in the documentation and actual
code. I've made the documentation match the code.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
Documentation/git-svnimport.txt | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
dedc4d56fc4ad95158d9de0f3c7b46cda2746659
diff --git a/Documentation/git-svnimport.txt b/Documentation/git-svnimport.txt
index f8dbee7..7583d78 100644
--- a/Documentation/git-svnimport.txt
+++ b/Documentation/git-svnimport.txt
@@ -11,7 +11,7 @@ SYNOPSIS
--------
'git-svnimport' [ -o <branch-for-HEAD> ] [ -h ] [ -v ] [ -d | -D ]
[ -C <GIT_repository> ] [ -i ] [ -u ] [-l limit_rev]
- [ -b branch_subdir ] [ -t trunk_subdir ] [ -T tag_subdir ]
+ [ -b branch_subdir ] [ -T trunk_subdir ] [ -t tag_subdir ]
[ -s start_chg ] [ -m ] [ -M regex ]
<SVN_repository_URL> [ <path> ]
@@ -47,10 +47,10 @@ When importing incementally, you might n
ensures the working directory and index remain untouched and will
not create them if they do not exist.
--t <trunk_subdir>::
+-T <trunk_subdir>::
Name the SVN trunk. Default "trunk".
--T <tag_subdir>::
+-t <tag_subdir>::
Name the SVN subdirectory for tags. Default "tags".
-b <branch_subdir>::
--
1.0.GIT
^ permalink raw reply related
* Re: how to find outstanding patches in non-linux-2.6 repositories?
From: Johannes Schindelin @ 2006-01-01 21:32 UTC (permalink / raw)
To: Olaf Hering; +Cc: Brian Gerst, git
In-Reply-To: <20060101210429.GA22033@suse.de>
Hi,
On Sun, 1 Jan 2006, Olaf Hering wrote:
> On Sun, Jan 01, Brian Gerst wrote:
>
> > Pull the powerpc tree into your local repo, then do something like:
> > git-whatchanged master..powerpc
> > or
> > gitk master..powerpc
>
> This worked for me:
>
> mkdir /dev/shm/x
> cd /dev/shm/x
> rsync -Ha --delete ~/kernel/git/{powerpc,linux-2.6} .
> cd linux-2.6/
> cat .git/HEAD > ../start
> git-pull /dev/shm/x/powerpc
> cat .git/HEAD > ../end
> git-format-patch `cat ../start` `cat ../end`
> view ????-*
Preferrable is the following:
cd /existing/clone/of/ppc-linux # OP said he had this already
git fetch \
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git \
master:refs/heads/linus
git-whatchanged linus..HEAD
Hth,
Dscho
^ permalink raw reply
* [PATCH] svnimport: support repositories requiring SSL authentication
From: Eric Wong @ 2006-01-01 21:25 UTC (permalink / raw)
To: git list, Matthias Urlichs
I looked at svn-mirror to see how it did this, seems about right.
"It works for me" when using it against https://svn.musicpd.org
tested command-line: git-svnimport -C mpc -i -m -v \
-T mpc/trunk -b mpc/branches -t mpc/tags https://svn.musicpd.org
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-svnimport.perl | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
926c84c0c96e43ca0341b541ed23e0f3874b8171
diff --git a/git-svnimport.perl b/git-svnimport.perl
index cb241d1..6e3a44a 100755
--- a/git-svnimport.perl
+++ b/git-svnimport.perl
@@ -96,8 +96,10 @@ sub new {
sub conn {
my $self = shift;
my $repo = $self->{'fullrep'};
- my $s = SVN::Ra->new($repo);
-
+ my $auth = SVN::Core::auth_open ([SVN::Client::get_simple_provider,
+ SVN::Client::get_ssl_server_trust_file_provider,
+ SVN::Client::get_username_provider]);
+ my $s = SVN::Ra->new(url => $repo, auth => $auth);
die "SVN connection to $repo: $!\n" unless defined $s;
$self->{'svn'} = $s;
$self->{'repo'} = $repo;
--
1.0.GIT
^ permalink raw reply related
* Re: how to find outstanding patches in non-linux-2.6 repositories?
From: Olaf Hering @ 2006-01-01 21:04 UTC (permalink / raw)
To: Brian Gerst; +Cc: git
In-Reply-To: <43B83EBC.9070905@didntduck.org>
On Sun, Jan 01, Brian Gerst wrote:
> Pull the powerpc tree into your local repo, then do something like:
> git-whatchanged master..powerpc
> or
> gitk master..powerpc
This worked for me:
mkdir /dev/shm/x
cd /dev/shm/x
rsync -Ha --delete ~/kernel/git/{powerpc,linux-2.6} .
cd linux-2.6/
cat .git/HEAD > ../start
git-pull /dev/shm/x/powerpc
cat .git/HEAD > ../end
git-format-patch `cat ../start` `cat ../end`
view ????-*
--
short story of a lazy sysadmin:
alias appserv=wotan
^ permalink raw reply
* Re: how to find outstanding patches in non-linux-2.6 repositories?
From: Brian Gerst @ 2006-01-01 20:42 UTC (permalink / raw)
To: Olaf Hering; +Cc: git
In-Reply-To: <20060101200121.GA20633@suse.de>
Olaf Hering wrote:
> How do I get a list of commits in the 'powerpc' tree, which are not part
> of the 'linux-2.6' tree? The git tutorial has a section 'Working with
> Others', but the examples dont work for me. Probably because
> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git has
> no info that it is not the "mainline tree".
> All I need is a list of individual commits in that tree, which are not
> (yet) in "mainline". I could get them also from the ozlabs mailing
> lists, for the few patches I need. But it would be better if there is
> some sort of automated way to extract a list of differences between two
> trees.
>
Pull the powerpc tree into your local repo, then do something like:
git-whatchanged master..powerpc
or
gitk master..powerpc
--
Brian Gerst
^ permalink raw reply
* how to find outstanding patches in non-linux-2.6 repositories?
From: Olaf Hering @ 2006-01-01 20:01 UTC (permalink / raw)
To: git
How do I get a list of commits in the 'powerpc' tree, which are not part
of the 'linux-2.6' tree? The git tutorial has a section 'Working with
Others', but the examples dont work for me. Probably because
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git has
no info that it is not the "mainline tree".
All I need is a list of individual commits in that tree, which are not
(yet) in "mainline". I could get them also from the ozlabs mailing
lists, for the few patches I need. But it would be better if there is
some sort of automated way to extract a list of differences between two
trees.
--
short story of a lazy sysadmin:
alias appserv=wotan
^ permalink raw reply
* Re: Possibility of a MinGW version?
From: Christopher Faylor @ 2006-01-01 5:25 UTC (permalink / raw)
To: H. Peter Anvin, git
In-Reply-To: <43B6FDC5.6020601@zytor.com>
On Sat, Dec 31, 2005 at 01:53:09PM -0800, H. Peter Anvin wrote:
>Christopher Faylor wrote:
>>As was mentioned, the Cygwin project is very far from dead and has
>>actually never been close to dead. It is, however, like any open
>>source project and things like the setup program are always under slow,
>>sporadic development.
>>
>>The core cygwin dll is under active development and maintenance and
>>most of the packages in the distribution are under active maintenance,
>>however.
>
>Cygwin probably could benefit greatly if they adopted something like
>rpm/yum for packaging, instead of reinventing the wheel.
Yes, Cygwin isn't a new project so ideas like this have been kicked
around many times over the years. You can't just port rpm, apt, or yum
and then say "We'll use this for updates now" because there are
chicken/egg problems. The problems are not unsolvable but, so far, no
one has cared enough to do anything about them.
cgf
^ permalink raw reply
* Re: Possibility of a MinGW version?
From: H. Peter Anvin @ 2005-12-31 21:53 UTC (permalink / raw)
To: Christopher Faylor; +Cc: git
In-Reply-To: <20051231163952.GA29284@trixie.casa.cgf.cx>
Christopher Faylor wrote:
>
> As was mentioned, the Cygwin project is very far from dead and has
> actually never been close to dead. It is, however, like any open source
> project and things like the setup program are always under slow,
> sporadic development.
>
> The core cygwin dll is under active development and maintenance and most
> of the packages in the distribution are under active maintenance, however.
Cygwin probably could benefit greatly if they adopted something like
rpm/yum for packaging, instead of reinventing the wheel.
-hpa
^ permalink raw reply
* [PATCH] git-init-db(1): Describe --shared and the idempotent nature of init-db
From: Jonas Fonseca @ 2005-12-31 17:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Based on the recent discussion on the mailing list.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
commit dbad4968a3d1f518e5102a241196380ba0bcce75
tree f8f0d7ed79046ec316d26b0ba84034b571416533
parent 58e3fb40f7ca1c28f9105c15166884f80bb22e55
author Jonas Fonseca <fonseca@diku.dk> Sat, 31 Dec 2005 18:06:33 +0100
committer Jonas Fonseca <fonseca@antimatter.localdomain> Sat, 31 Dec 2005 18:06:33 +0100
Documentation/git-init-db.txt | 16 ++++++++++++++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-init-db.txt b/Documentation/git-init-db.txt
index 6deef92..9cf9499 100644
--- a/Documentation/git-init-db.txt
+++ b/Documentation/git-init-db.txt
@@ -8,7 +8,7 @@ git-init-db - Creates an empty git repos
SYNOPSIS
--------
-'git-init-db' [--template=<template_directory>]
+'git-init-db' [--template=<template_directory>] [--shared]
OPTIONS
@@ -16,6 +16,9 @@ OPTIONS
--template=<template_directory>::
Provide the directory in from which templates will be used.
+--shared::
+ Specify that the git repository is to be shared amongst several users.
+
DESCRIPTION
-----------
@@ -30,7 +33,16 @@ If the object storage directory is speci
environment variable then the sha1 directories are created underneath -
otherwise the default `$GIT_DIR/objects` directory is used.
-`git-init-db` won't hurt an existing repository.
+A shared repository allows users belonging to the same group to push into that
+repository. When specifying `--shared` the config variable "core.sharedRepository"
+is set to 'true' so that directories under `$GIT_DIR` are made group writable
+(and g+sx, since the git group may be not the primary group of all users).
+
+
+Running `git-init-db` in an existing repository is safe. It will not overwrite
+things that are already there. The primary reason for rerunning `git-init-db`
+is to pick up newly added templates.
+
EXAMPLES
--
Jonas Fonseca
^ permalink raw reply related
* Re: Possibility of a MinGW version?
From: Christopher Faylor @ 2005-12-31 16:40 UTC (permalink / raw)
To: Andreas Ericsson, Rob McDonald, git
In-Reply-To: <009701c60891$50893fd0$6900a8c0@sps>
On Sat, Dec 24, 2005 at 08:51:53AM -0500, Rob McDonald wrote:
>MSYS is a minimal system that includes ports of all build-chain tools
>you need to get Makefiles to work. I would envision using it along
>with native ports of Perl, Tk/Tcl, etc.
MSYS is basically an unmaintained fork of Cygwin. It uses an old
version of the Cygwin DLL with some hacks to handle path names
differently. It isn't intended as a platform for porting packages to
MSYS. It is intended to be used as an environment for porting packages
to MinGW.
cgf
^ permalink raw reply
* Re: Possibility of a MinGW version?
From: Christopher Faylor @ 2005-12-31 16:39 UTC (permalink / raw)
To: git
In-Reply-To: <003101c60976$f2912ff0$6900a8c0@sps>
On Sun, Dec 25, 2005 at 12:16:29PM -0500, Rob McDonald wrote:
>>Well, cygwin is everything but unmaintained. It's unfair to blaim the
>>good work of the cygwin folks if you can't get it to work. I have
>>*never* had a problem I could not solve with cygwin. In particular,
>>*no* package got messed up when I installed/upgraded another package.
>>Before you ask: I use cygwin extensively.
>
>I'm sorry to have seemed harsh in my criticism. I have not used Cygwin
>seriously in a couple years. At the time, as a user, I saw no
>noticable progress. The project seemed dead. I always had trouble
>with their package management program. I'm glad you've never had
>similar problems.
As was mentioned, the Cygwin project is very far from dead and has
actually never been close to dead. It is, however, like any open source
project and things like the setup program are always under slow,
sporadic development.
The core cygwin dll is under active development and maintenance and most
of the packages in the distribution are under active maintenance, however.
--
Christopher Faylor spammer? -> aaaspam@sourceware.org
Cygwin Co-Project Leader aaaspam@duffek.com
TimeSys, Inc.
^ permalink raw reply
* [PATCH] gitk - show newly created files
From: Alecs King @ 2005-12-31 8:14 UTC (permalink / raw)
To: git
When specifying a filename as an argument to gitk, ie.
$ gitk apply.c
gitk does not show the diff when the file newly created.
That 'newly created' commit is the last one gitk gets from
'git-rev-list' so gitk thinks it has no parent while it normally does
(except that the commit itself is the root commit).
This patch is to (try to) fix this problem.
P.S, is it good if gitk also has a '--root' option like git-whatchanged?
Signed-off-by: Alecs King <alecsk@gmail.com>
diff --git a/gitk b/gitk
index f12b3ce..688ee12 100755
--- a/gitk
+++ b/gitk
@@ -2288,10 +2288,10 @@ proc selectline {l isnew} {
$cflist delete 0 end
$cflist insert end "Comments"
- if {$nparents($id) == 1} {
- startdiff $id
- } elseif {$nparents($id) > 1} {
+ if {$nparents($id) > 1} {
mergediff $id
+ } else {
+ startdiff $id
}
}
--
Alecs King
^ permalink raw reply related
* Re: [PATCH] Make GIT-VERSION-GEN tolerate missing git describe command
From: H. Peter Anvin @ 2005-12-31 0:15 UTC (permalink / raw)
To: John Ellson; +Cc: git
In-Reply-To: <dp41ve$v7r$1@sea.gmane.org>
John Ellson wrote:
> John Ellson wrote:
>
>> I think it is probably a bug that "git non_existent_command"
>> returns its error message to stdout without an error, where
>> "git-non_existent_command" behaves differently and does return an
>> error.
>
>
> BTW. Its the old shell-script version of "git" that fails to return an
> error on non_existent_commands. The newer C version of "git"
> correctly returns an error code.
>
> The reason that this is a sufficiently serious problem to require a fix
> is that the broken version of "git" is in the
> git-core-0.99.9a-2.fc5.i386.rpm that is currently in Fedora Core Extras
> development.
>
It has been fixed. What's broken is that Fedora Extras still contains
0.99.9a which is totally ancient.
-hpa
^ permalink raw reply
* Re: [PATCH] add strcpy_user_path() and use it in init-db.c and git.c
From: Eric Wong @ 2005-12-30 23:10 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git list
In-Reply-To: <Pine.LNX.4.63.0512261730170.7716@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Sat, 24 Dec 2005, Eric Wong wrote:
>
> > Junio C Hamano <junkio@cox.net> wrote:
> > > Eric Wong <normalperson@yhbt.net> writes:
> > >
> > > > My home directories have different names on different machines I'm
> > > > on, and I want to avoid having to recompile git for each one.
> > > > I don't have root access to some of them, so installing globally in /usr
> > > > or /usr/local isn't an option, either.
> > >
> > > Then you probably need to use GIT_EXEC_PATH environment
> > > variable.
> >
> > That works with git.c but not init-db. But then again I don't use
> > git-init-db that often. I'll just write a shell script wrapper for the
> > latter if I do.
>
> How about something like this?
Sure, seems reasonable, but I don't feel that strongly towards
making my env getting bigger and bigger all the time.
I've also been comtemplating just using my own wrapper instead of the
default 'git' wrapper (which being in C, is more difficult to customize
on-the-fly than sh or perl). Or have git read a config file from a
user's home directory.
> ---
> [PATCH] Introduce environment variable for the path to the templates
>
> The environment variable GIT_TEMPLATE_PATH can override the compiled-in
> setting, and can be overridden with the '--template=' argument to init-db.
>
> Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
>
> ---
>
> Eric said that GIT_EXEC_PATH is enough for most things, but not for
> init-db. I guess he wanted something like this.
>
> init-db.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> 5d95ce750b09a14bcb86e07ba23077ab0825089c
> diff --git a/init-db.c b/init-db.c
> index 863ec1a..774a91f 100644
> --- a/init-db.c
> +++ b/init-db.c
> @@ -238,7 +238,7 @@ int main(int argc, char **argv)
> {
> const char *git_dir;
> const char *sha1_dir;
> - char *path, *template_dir = NULL;
> + char *path, *template_dir = getenv("GIT_TEMPLATE_PATH");
> int len, i;
>
> for (i = 1; i < argc; i++, argv++) {
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] Avoid allocating 0 bytes, was Re: [PATCH 4/4] git-compat-util.h: dietlibc-friendly x{malloc,realloc,calloc}
From: Eric Wong @ 2005-12-30 23:00 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0512261916440.8435@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> diff --git a/index-pack.c b/index-pack.c
> index d4ce3af..2927632 100644
> --- a/index-pack.c
> +++ b/index-pack.c
> @@ -103,7 +103,7 @@ static void *unpack_entry_data(unsigned
> unsigned long pack_limit = pack_size - 20;
> unsigned long pos = *current_pos;
> z_stream stream;
> - void *buf = xmalloc(size);
> + void *buf = xmalloc(size ? size : 1);
>
> memset(&stream, 0, sizeof(stream));
> stream.next_out = buf;
This is the only one I've managed to hit upon further use the past week
of usage. No way to break out of the function, either, because
current_pos needs to be updated (and it is changed despite a zero-byte
blob object being in my repository).
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] Make GIT-VERSION-GEN tolerate missing git describe command
From: Linus Torvalds @ 2005-12-30 19:55 UTC (permalink / raw)
To: John Ellson; +Cc: git
In-Reply-To: <43B586B4.5030001@research.att.com>
On Fri, 30 Dec 2005, John Ellson wrote:
>
> I checked and that bug has been fixed since the older version of git that
> was causing me problems. "git non_existent_command" now returns 1.
Ahh, good.
> However, the error message was also changed to goto stderr, which it
> sounds like you disagree with?
Not that I can see:
[torvalds@g5 ~]$ git --version
git version 1.0.6-g58e3
[torvalds@g5 ~]$ git hjsdhjas > /dev/null
[torvalds@g5 ~]$ echo $?
1
so yes, it returns a proper error, and it outputs the help message to
stdout, not stderr. Which is fine, because it means that you can indeed do
git help | less
and it will do the right thing (apart from printing the line
git: 'help' is not a git-command
which is a bit sad).
Linus
^ permalink raw reply
* Re: [PATCH] Make GIT-VERSION-GEN tolerate missing git describe command
From: John Ellson @ 2005-12-30 19:31 UTC (permalink / raw)
To: git
In-Reply-To: <dp3mtp$rfm$1@sea.gmane.org>
John Ellson wrote:
> I think it is probably a bug that "git non_existent_command"
> returns its error message to stdout without an error, where
> "git-non_existent_command" behaves differently and does return an
> error.
BTW. Its the old shell-script version of "git" that fails to return an error on
non_existent_commands. The newer C version of "git" correctly returns an
error code.
The reason that this is a sufficiently serious problem to require a fix is that
the broken version of "git" is in the git-core-0.99.9a-2.fc5.i386.rpm that is
currently in Fedora Core Extras development.
John
^ permalink raw reply
* Re: [PATCH] Make GIT-VERSION-GEN tolerate missing git describe command
From: John Ellson @ 2005-12-30 19:12 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0512301046230.3249@g5.osdl.org>
Linus Torvalds wrote:
> On Fri, 30 Dec 2005, John Ellson wrote:
>
>> I think it is probably a bug that "git non_existent_command"
>> returns its error message to stdout without an error, where
>> "git-non_existent_command" behaves differently and does return an
>> error.
>>
>> Older versions of git did not implement "git describe" and
>> GIT-VERSION-GEN produces an empty version string if run on
>> a system with such a git installed. The consequence
>> is that "make rpm" fails.
>>
>> This patch fixes GIT-VERSION-GEN so that it works in the
>> absence of a working "git describe"
>>
>
> Shouldn't you make "git.c" return an error too, so that "git-describe" and
> "git describe" both fail properly?
>
> I realize that you'd want to do your patch _too_ (in case somebody has an
> old version of "git" installed), but I just think it would be sensible to
> fix the problem that causes this in the first place..
>
> Continuing to output to stdout rather than stderr is probably a good idea
> (so that it's easy to do "git help | less" or something), but yeah, I
> think an unrecognized command should at least return an error.
>
> Linus
>
I checked and that bug has been fixed since the older version of git that
was causing me problems. "git non_existent_command" now returns 1.
However, the error message was also changed to
goto stderr, which it sounds like you disagree with? Personally
I don't have a problem with it, although a real "git-help" command
might be a good idea too.
John
^ permalink raw reply
* Re: [PATCH] Make GIT-VERSION-GEN tolerate missing git describe command
From: Linus Torvalds @ 2005-12-30 18:49 UTC (permalink / raw)
To: John Ellson; +Cc: git
In-Reply-To: <dp3mtp$rfm$1@sea.gmane.org>
On Fri, 30 Dec 2005, John Ellson wrote:
>
> I think it is probably a bug that "git non_existent_command"
> returns its error message to stdout without an error, where
> "git-non_existent_command" behaves differently and does return an
> error.
>
> Older versions of git did not implement "git describe" and
> GIT-VERSION-GEN produces an empty version string if run on
> a system with such a git installed. The consequence
> is that "make rpm" fails.
>
> This patch fixes GIT-VERSION-GEN so that it works in the
> absence of a working "git describe"
Shouldn't you make "git.c" return an error too, so that "git-describe" and
"git describe" both fail properly?
I realize that you'd want to do your patch _too_ (in case somebody has an
old version of "git" installed), but I just think it would be sensible to
fix the problem that causes this in the first place..
Continuing to output to stdout rather than stderr is probably a good idea
(so that it's easy to do "git help | less" or something), but yeah, I
think an unrecognized command should at least return an error.
Linus
^ permalink raw reply
* Re: [PATCH] Stgit - gitmergeonefile.py: handle removal vs. changes
From: Blaisorblade @ 2005-12-30 17:59 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0511150154y2d2af24ck@mail.gmail.com>
On Tuesday 15 November 2005 10:54, Catalin Marinas wrote:
> On 13/11/05, Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> wrote:
> > I just got a "removal vs. changed" conflict, which is unhandled by StGit.
> > That is taken from git-merge-one-file resolver, but is bad, as stg
> > resolved does not handle unmerged entries (and probably it should be
> > fixed too).
>
> I think it 'stg resolved' should be fixed as well (in case there are
> unmerged entries for other reasons). My initial idea was to make
> gitmergeonefile not to leave any unmerged entries in the index. As you
> could see, there are cases where it failed.
The original patch hasn't been merged, nor (for what I see) anything else to
fix this problem has been done.
I assume the patch was lost waiting for the discussion to settle down, but the
patch can be merged, even changing the default choices in any way (see
below).
Also, another note: I just found Bruce Eckel mentioning pychecker, which is a
static code checker for Python (to perform the checks a compiler would
normally do). I've not the time to investigate more myself, but I hope it can
be useful to you.
> I can see the following scenarios for a file:
> 1. deleted in the base and modified by the patch. It should leave the
> file in the tree together with file.older. Another option would be to
> remove the file and leave both file.older and file.remote in the tree
> (here .remote means the version in the patch) but I would prefer the
> first one.
>
> 2. changed in the base but deleted by the patch. It should remove the
> file from the tree but leave file.older and file.local. The other
> option is to leave the file in the tree but, as above, I prefer the
> first one.
>
> Maybe StGIT should try to track the renaming as well but I haven't
> played with this feature in GIT at all.
--
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade
___________________________________
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB
http://mail.yahoo.it
^ permalink raw reply
* [PATCH] rpmbuild doesn't like '-' in version strings
From: John Ellson @ 2005-12-30 17:29 UTC (permalink / raw)
To: git
Problem:
ellson@ellson:git> make rpm
GIT_VERSION = 1.0.6-g58e3
sed -e 's/@@VERSION@@/1.0.6-g58e3/g' < git.spec.in > git.spec
./git-tar-tree HEAD git-1.0.6-g58e3 > git-1.0.6-g58e3.tar
tar rf git-1.0.6-g58e3.tar git-1.0.6-g58e3/git.spec
gzip -f -9 git-1.0.6-g58e3.tar
rpmbuild -ta git-1.0.6-g58e3.tar.gz
error: line 3: Illegal char '-' in version: Version: 1.0.6-g58e3
make: *** [rpm] Error 1
Suggested fix: Use '_' instead of '-'
There is probably a cleaner implementation of the fix, but this works for me.
----------------------------------------
diff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN
index 845b9dc..e4e0ab1 100755
--- a/GIT-VERSION-GEN
+++ b/GIT-VERSION-GEN
@@ -3,7 +3,9 @@
GVF=GIT-VERSION-FILE
VN=$(git-describe --abbrev=4 HEAD 2>/dev/null) || VN=v1.0.GIT
-VN=$(expr "$VN" : v'\(.*\)')
+VN1=$(expr "$VN" : '[^-]*-\(.*\)')
+VN=$(expr "$VN" : v'\([^-]*\)')
+test "$VN1" = "" || VN="$VN"_"$VN1"
if test -r $GVF
then
VC=$(sed -e 's/^GIT_VERSION = //' <$GVF)
--------------------------------------------
Signed-off-by: John Ellson <ellson@research.att.com>
^ permalink raw reply related
* [PATCH] Make GIT-VERSION-GEN tolerate missing git describe command
From: John Ellson @ 2005-12-30 16:23 UTC (permalink / raw)
To: git
I think it is probably a bug that "git non_existent_command"
returns its error message to stdout without an error, where
"git-non_existent_command" behaves differently and does return an
error.
Older versions of git did not implement "git describe" and
GIT-VERSION-GEN produces an empty version string if run on
a system with such a git installed. The consequence
is that "make rpm" fails.
This patch fixes GIT-VERSION-GEN so that it works in the
absence of a working "git describe"
----------------------------------------
diff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN
index 196402c..845b9dc 100755
--- a/GIT-VERSION-GEN
+++ b/GIT-VERSION-GEN
@@ -2,7 +2,7 @@
GVF=GIT-VERSION-FILE
-VN=$(git describe --abbrev=4 HEAD 2>/dev/null) || VN=v1.0.GIT
+VN=$(git-describe --abbrev=4 HEAD 2>/dev/null) || VN=v1.0.GIT
VN=$(expr "$VN" : v'\(.*\)')
if test -r $GVF
then
----------------------------------------
Signed-off-by: John Ellson <ellson@research.att.com>
^ 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