* Re: bash completions code for git+porcelain
From: Petr Baudis @ 2005-12-05 0:16 UTC (permalink / raw)
To: Ben Clifford; +Cc: Git Mailing List
In-Reply-To: <0039D3CD-8254-4E29-8563-D60487719378@hawaga.org.uk>
Dear diary, on Sun, Dec 04, 2005 at 03:05:01AM CET, I got a letter
where Ben Clifford <benc@hawaga.org.uk> said that...
> just a note that I'm still plodding along slowly adding bits to the
> bash completion code available by typing:
>
> cg clone http://www.hawaga.org.uk/gitcompletion.git
>
> handles (some of) git, gitk, cg, stg commands - enough to be useful
> for me, at least ;-)
Thanks a lot. I've added the Cogito-related stuff to its contrib/
directory (just with a bit saner filenames). I will try to update them
as new changes appear in, but I would be grateful if you could please
notify me when you think I really should. ;-)
Thanks again,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: [PATCH] Document the --no-commit flag
From: Junio C Hamano @ 2005-12-05 0:04 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20051204232505.GZ22159@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Any problems with this patch?
It has been done a bit differently by Jon Loeliger (please see
Documentation/merge-options.txt).
Anyways, thanks for the patch and attention to the detail.
Always appreciated.
^ permalink raw reply
* Re: [PATCH gitweb] Visually indicating patch size with horizontal bars
From: Petr Baudis @ 2005-12-05 0:04 UTC (permalink / raw)
To: Chris Shoemaker; +Cc: Martin Langhoff, Kay Sievers, git
In-Reply-To: <20051102001206.GA21671@pe.Belkin>
Dear diary, on Wed, Nov 02, 2005 at 01:12:06AM CET, I got a letter
where Chris Shoemaker <c.shoemaker@cox.net> said that...
> On Wed, Nov 02, 2005 at 12:33:38PM +1300, Martin Langhoff wrote:
> > On 11/2/05, Petr Baudis <pasky@suse.cz> wrote:
> > > What about having the color indicate the number of affected files (let's
> > > say on a blue..red scale) and the width the size of patch?
> >
> > I'm a /little bit/ colour blind on the red scale -- so I vote for 2
> > bars, each half the heigth of the current bar. ;-)
>
> I was going to use two bars for add vs. delete, but this could work,
> too. I'm intending on getting back to this ASAP, but for now my
> cvsimport problems are higher priority (see other post).
Is there any progress, by the way?
If you didn't manage to finish it, no big deal - but it would be great
to have at least the last version you screenshotted, since IIRC I
couldn't find that one either, and I would like to play with it a bit.
Thanks,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: [PATCH] Add compat/setenv.c, use in git.c.
From: H. Peter Anvin @ 2005-12-04 23:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jason Riedy, git
In-Reply-To: <7vr78sebp8.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>
> Oops. Isn't the patch itself wrong, so is using alloca()?
>
> putenv(3) says
>
> int putenv(char *string);
>
> The string pointed to by string becomes part of the environment,
> so altering the string changes the environment.
>
> which tell sme that whatever we pass to putenv() we should *not*
> free.
Indeed.
-hpa
^ permalink raw reply
* [PATCH] Update the git-ls-tree documentation
From: Petr Baudis @ 2005-12-04 23:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This patch aims to freshen up a bit the git-ls-tree documentation. It hints
that the list of paths are in fact patterns to be matched, explains the new
-t, --name-only and --name-status options, corrects the original autorship
information to refer to yours sincerely, corrects several grammar mistakes,
etc.
Since the documentation still deserves some significant work (at least
proper description of the pattern matching), I also added the stub notice.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
Documentation/git-ls-tree.txt | 43 ++++++++++++++++++++++++++++-------------
1 files changed, 29 insertions(+), 14 deletions(-)
diff --git a/Documentation/git-ls-tree.txt b/Documentation/git-ls-tree.txt
index ba0438e..b92a8b2 100644
--- a/Documentation/git-ls-tree.txt
+++ b/Documentation/git-ls-tree.txt
@@ -8,12 +8,15 @@ git-ls-tree - Lists the contents of a tr
SYNOPSIS
--------
-'git-ls-tree' [-d] [-r] [-z] <tree-ish> [paths...]
+'git-ls-tree' [-d] [-r] [-t] [-z] [--name-only] [--name-status] <tree-ish> [paths...]
DESCRIPTION
-----------
-Lists the contents of a tree object, like what "/bin/ls -a" does
-in the current working directory.
+Lists the contents of a given tree object, like what "/bin/ls -a" does
+in the current working directory. Note that the usage is subtly different,
+though - 'paths' denote just a list of patterns to match, e.g. so specifying
+directory name (without '-r') will behave differently, and order of the
+arguments does not matter.
OPTIONS
-------
@@ -21,36 +24,48 @@ OPTIONS
Id of a tree-ish.
-d::
- show only the named tree entry itself, not its children
+ Show only the named tree entry itself, not its children.
-r::
- recurse into sub-trees
+ Recurse into sub-trees.
+
+-t::
+ Show tree entries even when going to recurse them. Has no effect
+ if '-r' was not passed. '-d' implies '-t'.
-z::
- \0 line termination on output
+ \0 line termination on output.
+
+--name-only::
+--name-status::
+ List only filenames (instead of the "long" output), one per line.
paths::
- When paths are given, show them. Otherwise implicitly
- uses the root level of the tree as the sole path argument.
+ When paths are given, show them (note that this isn't really raw
+ pathnames, but rather a list of patterns to match). Otherwise
+ implicitly uses the root level of the tree as the sole path argument.
Output Format
-------------
<mode> SP <type> SP <object> TAB <file>
-When `-z` option is not used, TAB, LF, and backslash characters
-in pathnames are represented as `\t`, `\n`, and `\\`,
-respectively.
+When the `-z` option is not used, TAB, LF, and backslash characters
+in pathnames are represented as `\t`, `\n`, and `\\`, respectively.
Author
------
-Written by Linus Torvalds <torvalds@osdl.org>
-Completely rewritten from scratch by Junio C Hamano <junkio@cox.net>
+Written by Petr Baudis <pasky@suse.cz>
+Completely rewritten from scratch by Junio C Hamano <junkio@cox.net>,
+another major rewrite by Linus Torvalds <torvalds@osdl.org>
Documentation
--------------
-Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+Documentation by David Greaves, Junio C Hamano and the git-list
+<git@vger.kernel.org>.
+
+This manual page is a stub. You can help the git documentation by expanding it.
GIT
---
^ permalink raw reply related
* Re: [PATCH] Document the --no-commit flag
From: Petr Baudis @ 2005-12-04 23:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20051104145505.6586.32084.stgit@machine.or.cz>
Dear diary, on Fri, Nov 04, 2005 at 03:55:05PM CET, I got a letter
where Petr Baudis <pasky@suse.cz> said that...
> Also add the reference to merge and fetch options in git-pull's synopsis.
>
> Signed-off-by: Petr Baudis <pasky@suse.cz>
Any problems with this patch?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* git.c: two fixes, gitsetenv type and off-by-one error.
From: Junio C Hamano @ 2005-12-04 23:03 UTC (permalink / raw)
To: git
gitsetenv as implemented in compat/setenv.c takes two const char*
and int; match that.
Also fix an incorrect attempt in prepend_to_path() to
NUL-terminate the string which stuffed the NUL character at one
past the end of allocation, and was not needed to begin with (we
copy the old_path string including the NUL which terminates it).
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
git.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
9a79c5a8b4e280601bcbeeed22e1e4968d06c10e
diff --git a/git.c b/git.c
index 619f25a..0975fc7 100644
--- a/git.c
+++ b/git.c
@@ -14,7 +14,7 @@
#endif
#ifdef NO_SETENV
-extern int gitsetenv(char *name, char *value, int overwrite);
+extern int gitsetenv(const char *, const char *, int);
#endif
static const char git_usage[] =
@@ -192,7 +192,6 @@ static void prepend_to_path(const char *
path_len = len + strlen(old_path) + 1;
path = malloc(path_len + 1);
- path[path_len + 1] = '\0';
memcpy(path, dir, len);
path[len] = ':';
--
0.99.9.GIT
^ permalink raw reply related
* [PATCH] compat/setenv: do not free what we fed putenv(3).
From: Junio C Hamano @ 2005-12-04 23:01 UTC (permalink / raw)
To: git
In-Reply-To: <28409.1133564908@lotus.CS.Berkeley.EDU>
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
compat/setenv.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
3a2674337c12e958f8c697af991a0ef6c06ddd4d
diff --git a/compat/setenv.c b/compat/setenv.c
index 94acd2d..b7d7678 100644
--- a/compat/setenv.c
+++ b/compat/setenv.c
@@ -16,7 +16,7 @@ int gitsetenv(const char *name, const ch
namelen = strlen(name);
valuelen = strlen(value);
- envstr = malloc((namelen + valuelen + 2) * sizeof(char));
+ envstr = malloc((namelen + valuelen + 2));
if (!envstr) return -1;
memcpy(envstr, name, namelen);
@@ -25,7 +25,11 @@ int gitsetenv(const char *name, const ch
envstr[namelen + valuelen + 1] = 0;
out = putenv(envstr);
+ /* putenv(3) makes the argument string part of the environment,
+ * and changing that string modifies the environment --- which
+ * means we do not own that storage anymore. Do not free
+ * envstr.
+ */
- free(envstr);
return out;
}
--
0.99.9.GIT
^ permalink raw reply related
* Re: [PATCH] Add compat/setenv.c, use in git.c.
From: Junio C Hamano @ 2005-12-04 22:31 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Jason Riedy, git
In-Reply-To: <43935A9E.2060602@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> Jason Riedy wrote:
>> +
>> +int gitsetenv(const char *name, const char *value, int replace)
>> +{
>> +...
>> + envstr = malloc((namelen + valuelen + 2) * sizeof(char));
>> +...
>> + out = putenv(envstr);
>> +
>> + free(envstr);
>> + return out;
>> +}
>
> Wouldn't this be a good case for using alloca()?
Oops. Isn't the patch itself wrong, so is using alloca()?
putenv(3) says
int putenv(char *string);
The string pointed to by string becomes part of the environment,
so altering the string changes the environment.
which tell sme that whatever we pass to putenv() we should *not*
free.
^ permalink raw reply
* Re: [PATCH] Add compat/setenv.c, use in git.c.
From: Junio C Hamano @ 2005-12-04 22:24 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Jason Riedy, git
In-Reply-To: <43935A9E.2060602@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> Wouldn't this be a good case for using alloca()?
Perhaps, but considering that (1) this function is not something
frequently called anyway, and (2) the proposed change would make
it the first alloca() user, and (3) this is compatibility
replacement function, I'd rather choose to keep it "old, known
to work at more places" malloc/free pair, and not having to
worry about it.
But now you quote the patch, sizeof(char) looks funny. Isn't it
always 1 by definition?
^ permalink raw reply
* Re: git-name-rev off-by-one bug
From: Petr Baudis @ 2005-12-04 21:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: linux, git
In-Reply-To: <7vhd9vgumb.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Tue, Nov 29, 2005 at 07:46:20PM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Petr Baudis <pasky@suse.cz> writes:
>
> > (ii) Cogito will handle trees with some local modifications better -
> > basically any local modifications git-read-tree -m won't care about.
> > I didn't read the whole conversation, so to reiterate: git-read-tree
> > will complain when the index does not match the HEAD, but won't
> > complain about modified files in the working tree if the merge is not
> > going to touch them. Now, let's say you do this (output is visually
> > only roughly or not at all resembling what would real tools tell you):
> >
> > $ ls
> > a b c
> > $ echo 'somelocalhack' >>a
> > $ git merge "blah" HEAD remotehead
> > File-level merge of 'b' and 'c'...
> > Oops, 'b' contained local conflicts.
> > Automatic merge aborted, fix up by hand.
> > $ fixup b
> > $ git commit
> > Committed files 'a', 'b', 'c'.
> >
> > Oops. It grabbed your local hack and committed it along the merge.
>
> Are you sure about this?
>
> In the above sequence, after you touch a with 'somelocalhack',
> there is no 'git update-index a', until you say 'git commit'
> there, so I do not think that mixup is possible.
>
> The "fixup b" step is actually two commands, so after merge
> command, you would do:
>
> $ edit b
> $ git update-index b ;# mark that you are dealt with it
> $ git commit ;# commits what is in index
>
> After the above steps, "git diff" (that is working tree against
> index) still reports your local change to "a", which were _not_
> committed.
Yes. I actually tried it out, but I was confused by the file list in the
commit message (I'm used to seeing just committed files there) and I
didn't check the status of the 'a' file after the commit.
Sorry about the confusion.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: [PATCH] Add compat/setenv.c, use in git.c.
From: H. Peter Anvin @ 2005-12-04 21:07 UTC (permalink / raw)
To: Jason Riedy; +Cc: git
In-Reply-To: <28409.1133564908@lotus.CS.Berkeley.EDU>
Jason Riedy wrote:
> +
> +int gitsetenv(const char *name, const char *value, int replace)
> +{
> + int out;
> + size_t namelen, valuelen;
> + char *envstr;
> +
> + if (!name || !value) return -1;
> + if (!replace) {
> + char *oldval = NULL;
> + oldval = getenv(name);
> + if (oldval) return 0;
> + }
> +
> + namelen = strlen(name);
> + valuelen = strlen(value);
> + envstr = malloc((namelen + valuelen + 2) * sizeof(char));
> + if (!envstr) return -1;
> +
> + memcpy(envstr, name, namelen);
> + envstr[namelen] = '=';
> + memcpy(envstr + namelen + 1, value, valuelen);
> + envstr[namelen + valuelen + 1] = 0;
> +
> + out = putenv(envstr);
> +
> + free(envstr);
> + return out;
> +}
Wouldn't this be a good case for using alloca()?
-hpa
^ permalink raw reply
* Re: gitk - ewww
From: Ben Clifford @ 2005-12-04 9:38 UTC (permalink / raw)
To: H. Peter Anvin, Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <4392871B.1030300@zytor.com>
>> What makes _me_ go "eww" in that screenshot is that tcl/tk doesn't
>> do anti-aliased fonts, but maybe that's just me, and that's
>> apparently 8.5 has that fixed (at a horrible performance impact,
>> I'm sure, but hey, one look at your screenshot and I'm saying
>> "bring it on").
>>
>
> It usually work OK for me, running on Fedora Core 4.
>
> Clearly, though, it's Tcl/Tk version dependent; especially since it
> looks absolutely *awful* on Cygwin.
The Wish/About Tcl & Tk menu option reports tcl/tk 8.4.7 - so I'd
guess any changes made for 8.5 won't have arrived at this host yet.
This is under Mac OS X 10.4.2.
--
Ben • ベン • Бэн • 벤 • 班明
http://www.hawaga.org.uk/ben/
My email is high latency but best way to contact me. Alternatively,
SMS number(s) at above URL.
^ permalink raw reply
* Re: [ANNOUNCE] GIT 0.99.9l aka 1.0rc4
From: H. Peter Anvin @ 2005-12-04 20:49 UTC (permalink / raw)
To: Horst von Brand; +Cc: Junio C Hamano, git, linux-kernel
In-Reply-To: <200512042016.jB4KGEIt031938@pincoya.inf.utfsm.cl>
Horst von Brand wrote:
> Junio C Hamano <junkio@cox.net> wrote:
>
>>GIT 0.99.9l aka 1.0rc4 is found at a new location.
>
> What would that new location be?
If you get RPMS, you want to get them from:
http://www.kernel.org/pub/software/scm/git/RPMS/$basearch/
I don't believe non-RPMs have changed.
-hpa
^ permalink raw reply
* Re: [ANNOUNCE] GIT 0.99.9l aka 1.0rc4
From: Horst von Brand @ 2005-12-04 20:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, linux-kernel
In-Reply-To: <7vy831p69i.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> GIT 0.99.9l aka 1.0rc4 is found at a new location.
What would that new location be?
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply
* Re: gitk - ewww
From: Nikolai Weibull @ 2005-12-04 17:12 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0512032040240.3099@g5.osdl.org>
Linus Torvalds wrote:
> On Sun, 4 Dec 2005, Ben Clifford wrote:
> > Screen shot is at:
> > http://www/hawaga.org.uk/ben/tech/gitk-eww-1.png
> What makes _me_ go "eww" in that screenshot is that tcl/tk doesn't do
> anti-aliased fonts, but maybe that's just me, and that's apparently
> 8.5 has that fixed (at a horrible performance impact, I'm sure, but
> hey, one look at your screenshot and I'm saying "bring it on").
Just use a slightly larger font and it should be fine. The lower-right
field, whatever that lists (changed files?) - I have never used gitk,
uses anti-aliasing, and the only problem I see is that the
commit-message listing uses a font that is way too small (or is badly
designed). The top pane is easily readable, although it could use a
slightly larger point-size.
Anti-aliasing is only a hack for displaying text on a screen. It's not
a substitute for choosing your fonts and point sizes with care. A
bitmapped font designed for small point-sizes will always look more
crisp than a generic TTF at small point-sizes.
nikolai
--
Nikolai Weibull: now available free of charge at http://bitwi.se/!
Born in Chicago, IL USA; currently residing in Gothenburg, Sweden.
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}
^ permalink raw reply
* [PATCH] Warn when send-pack does nothing
From: Daniel Barkalow @ 2005-12-04 16:59 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
If you try to push into an empty repository with no ref arguments to
git push, it doesn't do anything and doesn't say anything. This adds a
warning when send-pack isn't going to push anything, so you don't
assume that it silently did what you wanted.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
---
send-pack.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
applies-to: fe523a4df93cce3e5c5b0266b9d3f1cbea009afa
5519af6444d6da0ac55343fe48fe7f68fdb593d9
diff --git a/send-pack.c b/send-pack.c
index 3eeb18f..589e1f9 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -190,6 +190,12 @@ static int send_pack(int in, int out, in
if (match_refs(local_refs, remote_refs, &remote_tail,
nr_refspec, refspec, send_all))
return -1;
+
+ if (!remote_refs) {
+ fprintf(stderr, "No refs in common and none specified; doing nothing.\n");
+ return 0;
+ }
+
/*
* Finally, tell the other end!
*/
---
0.99.9.GIT
^ permalink raw reply related
* [ANNOUNCE] GIT 0.99.9l aka 1.0rc4
From: Junio C Hamano @ 2005-12-04 9:21 UTC (permalink / raw)
To: git, linux-kernel
GIT 0.99.9l aka 1.0rc4 is found at a new location.
RPM
http://kernel.org:/pub/software/git/RPMS/
Debian [*1*]
http://kernel.org:/pub/software/git/debian/
This is mostly fixes, with some improvements. As I said on the
git list earlier, no more major feature/semantics changes after
this is expected until 1.0.
Highlights are:
- After a conflicting merge, the index file is left unmerged.
As before, after such conflicting merge, "git diff" can be
used to view the differences between the half-merged file and
"our" branch version by default, but now you can say "git
diff --base" and "git diff --theirs" to view the differences
since the merge-base version and the other branch's version,
respectively.
- git-daemon and other git native protocols allow user-relative
paths (e.g. git://host/~user/repo). git-daemon's path
whitelist check used to be done with the realpath (i.e. what
getcwd() returns) in 0.99.9k and later "master" branch
versions, but it was changed back to check against what the
requester asked.
- The commands have been future-proofed so that they refuse to
operate on repositories from future unknown versions, to
avoid corrupting them by mistake.
- Bisect can take pathspec to cut down the number of revisions
that need to be tested.
- Many low-level commands have been updated to work better from
subdirectories (much of the barebone porcelain wrappers that
deal with the whole repository or the whole tree still need
to be run from the top level, though).
- Merge used to fail when it removed a file (fixed).
- When only GIT_OBJECT_DIRECTORY was exported things broke
since 0.99.9k (fixed).
- Comes with updated gitk.
[Footnote]
*1* It appears Debian finally has an official maintainer, so I
am inclined to stop building and supplying the debs starting
from the next version --- one less thing to worry about for me.
I hope the Debian side splits the packages along the same line
as we do RPMs.
^ permalink raw reply
* Re: git-update-server-info crashes on hera.kernel.org:/pub/scm/libs/klibc/klibc.git
From: H. Peter Anvin @ 2005-12-04 7:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v64q5tkhi.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> "H. Peter Anvin" <hpa@zytor.com> writes:
>
>
>>FWIW, I invoked this as:
>>
>>hpa@hera:~(0)$ GIT_DIR=/pub/scm/libs/klibc/klibc.git git-update-server-info
>>Segmentation fault
>
>
> Trusting that I *won't* be able to write into that repository, I
> tried to run that and after getting an error ("cannot update
> info/refs file", which I wanted to see) I seem to be getting the
> same segfault. GDB session reveals the binary is heavily
> optimized or inlined, so it is hard to see what it is doing
> though.
>
> But there is one thing that is mysterious about your repository,
> and by mirroring that peculiarity with the copy in my home
> directory, I managed to reproduce the problem with my copy. Why
> does the objects/info/alternates in that repository point at
> itself? I suspect if you remove that file you will be OK.
>
> update-server-info simply dying, instead of complaining about
> it, is a bug nevertheless, and removal of the
> unnecessary/possibly wrong alternate is only a workaround, but I
> hope that would unblock you in the meantime..
>
Removing that file did indeed work. I have no idea where it comes from,
though; although I would guess it comes from another repository that I
merged with (which had my original repository set as an alternate.)
-hpa
^ permalink raw reply
* Re: git-update-server-info crashes on hera.kernel.org:/pub/scm/libs/klibc/klibc.git
From: Junio C Hamano @ 2005-12-04 7:00 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: git
In-Reply-To: <43928C39.8050105@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> FWIW, I invoked this as:
>
> hpa@hera:~(0)$ GIT_DIR=/pub/scm/libs/klibc/klibc.git git-update-server-info
> Segmentation fault
Trusting that I *won't* be able to write into that repository, I
tried to run that and after getting an error ("cannot update
info/refs file", which I wanted to see) I seem to be getting the
same segfault. GDB session reveals the binary is heavily
optimized or inlined, so it is hard to see what it is doing
though.
But there is one thing that is mysterious about your repository,
and by mirroring that peculiarity with the copy in my home
directory, I managed to reproduce the problem with my copy. Why
does the objects/info/alternates in that repository point at
itself? I suspect if you remove that file you will be OK.
update-server-info simply dying, instead of complaining about
it, is a bug nevertheless, and removal of the
unnecessary/possibly wrong alternate is only a workaround, but I
hope that would unblock you in the meantime..
^ permalink raw reply
* Re: git-update-server-info crashes on hera.kernel.org:/pub/scm/libs/klibc/klibc.git
From: H. Peter Anvin @ 2005-12-04 6:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzmnhtmi1.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> I made a copy of that repository on hera and tried it but cannot
> reproduce (with or without -f flag -- and running under gdb with
> symbols did not make difference either). Sorry, I am baffled.
> The same machine, the same set of input and binary.
>
FWIW, I invoked this as:
hpa@hera:~(0)$ GIT_DIR=/pub/scm/libs/klibc/klibc.git git-update-server-info
Segmentation fault
-hpa
^ permalink raw reply
* Re: [PATCH] Add compat/setenv.c, use in git.c.
From: Junio C Hamano @ 2005-12-04 6:26 UTC (permalink / raw)
To: Jason Riedy; +Cc: git
In-Reply-To: <28409.1133564908@lotus.CS.Berkeley.EDU>
Jason Riedy <ejr@EECS.Berkeley.EDU> writes:
> The rule for building git$(X) also needs to include compat.
> objects and compiler flags. Those are now in makefile vars
> COMPAT_OBJS and COMPAT_CFLAGS.
Thanks for the cleanup. Looks much saner.
^ permalink raw reply
* Re: gitk - ewww
From: Junio C Hamano @ 2005-12-04 6:23 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0512032040240.3099@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Sun, 4 Dec 2005, Ben Clifford wrote:
>>
>> Screen shot is at:
>> http://www/hawaga.org.uk/ben/tech/gitk-eww-1.png
>
> Yes. gitk doesn't look wonderful with octopus merges, the lines start
> crossing. Oh well. I think you have to live with it, it's done this for a
> long time.
FWIW, when the first ever Octopus was made, it looked wonderful.
The way gitk renders octopus is somehow quite different these
days.
^ permalink raw reply
* Re: [PATCH] A few more options for git-cat-file
From: H. Peter Anvin @ 2005-12-04 6:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vu0dptmh3.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> "H. Peter Anvin" <hpa@zytor.com> writes:
>
>
>>This adds the following options to git-cat-file:
>>
>>-n, to get the canonical name of a resource. This is for one thing
>>useful in tagging scripts.
>
> Isn't "git-rev-parse --verify" good enough?
>
Ah, yes. Except for the fact that I couldn't find it when I looked for
a command that did that. git-rev-parse seems like an eclectic mixture
of stuff, and the name isn't very clear as to what it does.
>
>>-e, to test for the existence of a file.
>
> This might be useful and cleaner than "cat-file -s >/dev/null"
> but marginally so. While reading the whole file and discarding
> that to /dev/null is wasteful and would go against tastes of
> many people, -t and -s flags do not need to read the whole thing
> and not so expensive.
Still, -e as implemented here is definitely cheaper.
-hpa
^ permalink raw reply
* Re: [PATCH] A few more options for git-cat-file
From: Junio C Hamano @ 2005-12-04 6:17 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: git
In-Reply-To: <43924D1C.8070306@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> This adds the following options to git-cat-file:
>
> -n, to get the canonical name of a resource. This is for one thing
> useful in tagging scripts.
Isn't "git-rev-parse --verify" good enough?
> -e, to test for the existence of a file.
This might be useful and cleaner than "cat-file -s >/dev/null"
but marginally so. While reading the whole file and discarding
that to /dev/null is wasteful and would go against tastes of
many people, -t and -s flags do not need to read the whole thing
and not so expensive.
^ 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