* Re: [ANNOUNCE] GIT 0.99.7b
From: H. Peter Anvin @ 2005-09-23 19:44 UTC (permalink / raw)
To: walt; +Cc: git
In-Reply-To: <dh0uur$h4g$1@sea.gmane.org>
walt wrote:
> Junio C Hamano wrote:
>
>> GIT 0.99.7b
>
> [...]
>
>> Or, if you use git already:
>>
>> {http,rsync}://kernel.org/pub/scm/git/git.git/
>
>
> I did it that way and now I see this:
>
> $git --version
> git version 0.99.7
>
> This is a bit confusing. Did I upgrade or downgrade?
> Maybe the version string should contain the same kind
> of hexadecimal string that Linus is appending to his
> kernel version?
>
Or just call it 0.99.7.1 and .2 or 0.99.8 and .9.
-hpa
^ permalink raw reply
* Re: 'bad file' error updating from Linus
From: H. Peter Anvin @ 2005-09-23 19:43 UTC (permalink / raw)
To: Linus Torvalds; +Cc: walt, git
In-Reply-To: <Pine.LNX.4.58.0509221630200.2553@g5.osdl.org>
Linus Torvalds wrote:
>
> Nope, it's not.
>
> It just depends on which IP address you happen to get when you look at
> www.kernel.org.
>
> www.kernel.org resolves to two addresses:
>
> Name: zeus-pub.kernel.org
> Address: 204.152.191.5
> Name: zeus-pub.kernel.org
> Address: 204.152.191.37
>
> and the .5 address is working, but the .37 address has the broken mirror.
>
> I thought hpa took it out of service while it was re-syncing, but
> apparently not.
>
Well, it had resynched, but the time and date stamp on the
refs/heads/master file were correct - just the data wrong - so rsync
didn't flag the file. I forced rsync --checksum and it's correct now.
-hpa
^ permalink raw reply
* Re: Please undo "Use git-merge instead of git-resolve in
From: Jon Loeliger @ 2005-09-23 13:51 UTC (permalink / raw)
To: git
>> (This is an intentional asymmetry, right? Distributed systems, right?)
>
>Right. It's intentional. The "master" branch tends to be the main one for
>everybody, but _my_ "master" branch is clearly _your_ "linus" branch, and
>_your_ "master" branch would be the "jon" branch for me.
OK, I'm being clued slowly... :-)
>So it's not "asymmetric". It _is_ symmetric, but it's symmetric the same
>way "left" and "right" are symmetric when facing each other - my left is
>your right, your left is my right. It's a symmetry, but it's not an
>_identity_.
Ah, right. I mis-spoke myself, I see. :-)
> What does
>
> git-cat-file -t 3fd07d3bf0077dcc0f5a33d2eb1938ea050da8da
It used to be nothing at all. It is now (after another fetch)
a commit. And, it did leave this:
jdl.com 231 % cat .git/refs/heads/origin.remote
3fd07d3bf0077dcc0f5a33d2eb1938ea050da8da
> Actually, the fact that it even left it as a head might
> cause problems (because now you have a reference to something
> that doesn't exist), so you are probably best off just removing
> the .git/refs/heads/origin.remote file entirely.
Excellent.
<aside stage=left>
IMO, one of the things that distinguishes those "who get git"
and those who don't yet git it, are the ones who can casually
toss out phrases like, "Oh, you don't need that, just rm it."
The rest of us sit around and ponder "Do I need _that_ data?
How do I know I can toss it? If I toss it, what will be lost
with it? But if I revert the index, I lose... _it_, right?"
There is a certain amount of opacity to Git and its Object
store that makes it a bit scary. And, at least for me, as
a result I am a bit reluctant to go wildly experimenting.
With more certainty as to "recovering from badness", I'll
be more familiar and more willing to experiment, I'm sure.
</aside>
Things are better, I've now been able to:
* committish: e484585ec3ee66cd07a627d3a9e2364640a3807f
branch 'master' of rsync://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
* refs/heads/origin: fast forward to branch 'master' of rsync://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
Thanks for your help!
jdl
^ permalink raw reply
* Re: git 0.99.7b doesn't build on Cygwin
From: Peter TB Brett @ 2005-09-23 13:50 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0509231537390.11109@wgmdd8.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
>> I wanted to use git on a Windows-based project (yes, there are some
>> out there still), so I fired up my Cygwin xterm, untarred the git
>> sources and totally failed to succeed in building them:
>
> Also see my mail regarding cygwin:
>
> http://www.gelato.unsw.edu.au/archives/git/0508/7956.html
Yes. I found that just after I'd spammed the list.
> This is the IPv6 stuff. There are patches to cygwin to support IPv6
> somewhere, but they haven't made it into mainline.
>
> As for the other problem I mentioned in my original mail:
>
> It seems that the fixup of the mmap()ed regions after a fork() does not
> work properly in cygwin. Remember that cygwin just wraps the non-POSIX
> Win32API and tries to make it sort of POSIX compliant. The problem is that
> Win32API lacks a proper fork(). This is therefore emulated, and after
> that, all the mmap()ed regions have to be mapped again. That fails.
Hmph. Sounds like I'm stuffed.
Ah well, I'll just have to use something else -- I know Mercurial works on
Windows. To be honest, I'd prefer to use git though; I've used it on
other projects and it's really nice.
Ah well, can't have everything you want all of the time, neh?
Peter
--
Quake II build tools: http://peter-b.co.uk/
Latest QuArK: http://quark.sourceforge.net/LatestVersion
v2sw6YShw7ln5pr6ck3ma8u7Lw3+2m0l7CFi6e4+8t4Eb8Aen4g6Pa2Xs5MSr5p4
hackerkey.com
^ permalink raw reply
* Re: git 0.99.7b doesn't build on Cygwin
From: Johannes Schindelin @ 2005-09-23 13:44 UTC (permalink / raw)
To: Peter TB Brett; +Cc: git
In-Reply-To: <ud5mznc1x.fsf@peter-b.co.uk>
Hi,
On Fri, 23 Sep 2005, Peter TB Brett wrote:
> I wanted to use git on a Windows-based project (yes, there are some
> out there still), so I fired up my Cygwin xterm, untarred the git
> sources and totally failed to succeed in building them:
Also see my mail regarding cygwin:
http://www.gelato.unsw.edu.au/archives/git/0508/7956.html
> gcc -o connect.o -c -g -O2 -Wall '-DSHA1_HEADER=<openssl/sha.h>' connect.c
> connect.c: In function `git_tcp_connect':
> connect.c:298: error: storage size of 'hints' isn't known
> connect.c:322: warning: implicit declaration of function `getaddrinfo'
> connect.c:324: warning: implicit declaration of function `gai_strerror'
> [...]
This is the IPv6 stuff. There are patches to cygwin to support IPv6
somewhere, but they haven't made it into mainline.
As for the other problem I mentioned in my original mail:
It seems that the fixup of the mmap()ed regions after a fork() does not
work properly in cygwin. Remember that cygwin just wraps the non-POSIX
Win32API and tries to make it sort of POSIX compliant. The problem is that
Win32API lacks a proper fork(). This is therefore emulated, and after
that, all the mmap()ed regions have to be mapped again. That fails.
Sidenote: I ran it inside gdb, and it worked fine! So I tried to recompile
the cygwin1.dll, but that wrecked my whole installation of cygwin and I
spent 2 hours just to be able to "gcc -o" again.
Ciao,
Dscho
^ permalink raw reply
* git 0.99.7b doesn't build on Cygwin
From: Peter TB Brett @ 2005-09-23 13:33 UTC (permalink / raw)
To: git
Hi folks,
I wanted to use git on a Windows-based project (yes, there are some
out there still), so I fired up my Cygwin xterm, untarred the git
sources and totally failed to succeed in building them:
---- ----
$ make
gcc -o apply.o -c -g -O2 -Wall '-DSHA1_HEADER=<openssl/sha.h>' apply.c
gcc -o blob.o -c -g -O2 -Wall '-DSHA1_HEADER=<openssl/sha.h>' blob.c
gcc -o commit.o -c -g -O2 -Wall '-DSHA1_HEADER=<openssl/sha.h>' commit.c
gcc -o connect.o -c -g -O2 -Wall '-DSHA1_HEADER=<openssl/sha.h>' connect.c
connect.c: In function `git_tcp_connect':
connect.c:298: error: storage size of 'hints' isn't known
connect.c:322: warning: implicit declaration of function `getaddrinfo'
connect.c:324: warning: implicit declaration of function `gai_strerror'
connect.c:324: warning: format argument is not a pointer (arg 3)
connect.c:326: error: dereferencing pointer to incomplete type
connect.c:327: error: dereferencing pointer to incomplete type
connect.c:327: error: dereferencing pointer to incomplete type
connect.c:327: error: dereferencing pointer to incomplete type
connect.c:330: error: dereferencing pointer to incomplete type
connect.c:330: error: dereferencing pointer to incomplete type
connect.c:338: warning: implicit declaration of function `freeaddrinfo'
connect.c:298: warning: unused variable `hints'
make: *** [connect.o] Error 1
$ gcc --version
gcc (GCC) 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125)
...
---- ----
It looks like the sort of problems I get when I'm missing header
files, but all the headers #included by connect.c are present on my
system, so I'm really not sure what's going on there...
Peter
P.S. Please Cc: me on any replies, I'm not subscribed to the list.
--
Quake II build tools: http://peter-b.co.uk/
Latest QuArK: http://quark.sourceforge.net/LatestVersion
v2sw6YShw7ln5pr6ck3ma8u7Lw3+2m0l7CFi6e4+8t4Eb8Aen4g6Pa2Xs5MSr5p4
hackerkey.com
^ permalink raw reply
* Re: [ANNOUNCE] GIT 0.99.7b
From: walt @ 2005-09-23 13:11 UTC (permalink / raw)
To: git
In-Reply-To: <7voe6ki9x7.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> GIT 0.99.7b
[...]
> Or, if you use git already:
>
> {http,rsync}://kernel.org/pub/scm/git/git.git/
I did it that way and now I see this:
$git --version
git version 0.99.7
This is a bit confusing. Did I upgrade or downgrade?
Maybe the version string should contain the same kind
of hexadecimal string that Linus is appending to his
kernel version?
^ permalink raw reply
* [ANNOUNCE] Cogito-0.15.1 (important bugfix)
From: Petr Baudis @ 2005-09-23 13:12 UTC (permalink / raw)
To: git; +Cc: linux-kernel
Hello,
I'm announcing the release of 0.15.1 of Cogito, the human-friendly UI
for Linus' GIT. You can find it at
http://www.kernel.org/pub/software/scm/cogito/
when kernel.org mirroring will go through another short period of
actually working. ;-)
I'm cc'ing the Linux Kernel mailing list since this release contains
a bugfix for an ugly potential data loss bug, which actually probably
covers nearly all Cogito users (it was introduced in cogito-0.11.2).
If you had some local uncommitted changes and merge new stuff (either
using cg-update or cg-merge), in some cases it would silently trash your
local changes. It was caused by a bogus git-checkout-cache invocation
pointed out by Linus.
Other interesting stuff:
* cg-clean -d would remove the arch/ and include/ subdirs in Linux
kernel - just any directories containing only subdirectories
(this isn't as horrible as it sounds since you didn't lose anything
precious you didn't want to lose - you can recover by just doing
cg-restore)
* Support for fetching from URLs of the 'git' protocol scheme
* cg-log -d filters based on date
* cg-diff works on BSD now
* Merge cg-(commit|parent|tree)-id to cg-object-id
* Some significant documentation enhancements
* Some new tests in the testsuite (for cg-merge ;-)
* Usual squad of minor bugfixes
Happy hacking,
--
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: [RFC] Do we still need the git command?
From: Sebastian Kuzminsky @ 2005-09-23 12:39 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Robert Watson, git
In-Reply-To: <46a038f905092304384d79d715@mail.gmail.com>
Martin Langhoff <martin.langhoff@gmail.com> wrote:
> > Pros:
> > (4) Do not conflict with GNU Interactive Tools. Make the life of
> > Debian people easier.
>
> +1! Anything to avoid yet another flamewar in debian-devel ;-) and it
> also shows some good manners towards a (mostly forgotten) but good
> project. The whole name conflict prompted me to install the GNU
> Interactive Tools and run it for a couple of days. Nifty little
> "midnight-commander" style utility.
I've been talking with the Debian maintainer of GNU Interactive Tools
about this. He says he's agreed with his upstream maintainer to change
the name of their git. I dont know if he means they'll change their
name in the upstream package or just in the Debian package. I offered
to do the work for them and do an NMU, but then I havent heard from them
for about 2 weeks, so I'm not sure what their status is.
"Ha ha, we sure bullied them into doing it our way."
--
Sebastian Kuzminsky
^ permalink raw reply
* [PATCH 6/6] git-local-fetch: Avoid confusing error messages on packed repositories
From: Sergey Vlasov @ 2005-09-23 12:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20050923122754.GB2197@master.mivlgu.local>
If the source repository was packed, and git-local-fetch needed to
fetch a pack file, it spewed a misleading error message about not
being able to find the unpacked object. Fixed by adding the
warn_if_not_exists argument to copy_file(), which controls printing
of error messages in case the source file does not exist.
Signed-off-by: Sergey Vlasov <vsu@altlinux.ru>
---
local-fetch.c | 17 ++++++++++++-----
1 files changed, 12 insertions(+), 5 deletions(-)
3417063eaaf7a9293621a72c8b5df4653daf04ea
diff --git a/local-fetch.c b/local-fetch.c
--- a/local-fetch.c
+++ b/local-fetch.c
@@ -52,7 +52,8 @@ static int setup_indices(void)
return 0;
}
-static int copy_file(const char *source, const char *dest, const char *hex)
+static int copy_file(const char *source, const char *dest, const char *hex,
+ int warn_if_not_exists)
{
if (use_link) {
if (!link(source, dest)) {
@@ -61,13 +62,16 @@ static int copy_file(const char *source,
}
/* If we got ENOENT there is no point continuing. */
if (errno == ENOENT) {
- fprintf(stderr, "does not exist %s\n", source);
+ if (warn_if_not_exists)
+ fprintf(stderr, "does not exist %s\n", source);
return -1;
}
}
if (use_symlink) {
struct stat st;
if (stat(source, &st)) {
+ if (!warn_if_not_exists && errno == ENOENT)
+ return -1;
fprintf(stderr, "cannot stat %s: %s\n", source,
strerror(errno));
return -1;
@@ -83,8 +87,11 @@ static int copy_file(const char *source,
void *map;
ifd = open(source, O_RDONLY);
if (ifd < 0 || fstat(ifd, &st) < 0) {
+ int err = errno;
if (ifd >= 0)
close(ifd);
+ if (!warn_if_not_exists && err == ENOENT)
+ return -1;
fprintf(stderr, "cannot open %s\n", source);
return -1;
}
@@ -129,11 +136,11 @@ static int fetch_pack(const unsigned cha
sprintf(filename, "%s/objects/pack/pack-%s.pack",
path, sha1_to_hex(target->sha1));
copy_file(filename, sha1_pack_name(target->sha1),
- sha1_to_hex(target->sha1));
+ sha1_to_hex(target->sha1), 1);
sprintf(filename, "%s/objects/pack/pack-%s.idx",
path, sha1_to_hex(target->sha1));
copy_file(filename, sha1_pack_index_name(target->sha1),
- sha1_to_hex(target->sha1));
+ sha1_to_hex(target->sha1), 1);
install_packed_git(target);
return 0;
}
@@ -154,7 +161,7 @@ static int fetch_file(const unsigned cha
filename[object_name_start+1] = hex[1];
filename[object_name_start+2] = '/';
strcpy(filename + object_name_start + 3, hex + 2);
- return copy_file(filename, dest_filename, hex);
+ return copy_file(filename, dest_filename, hex, 0);
}
int fetch(unsigned char *sha1)
^ permalink raw reply
* [PATCH 5/6] Fix "git-local-fetch -s" with packed source repository
From: Sergey Vlasov @ 2005-09-23 12:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20050923122754.GB2197@master.mivlgu.local>
"git-local-fetch -s" did not work with a packed repository, because
symlink() happily created a link to a non-existing object file,
therefore fetch_file() always returned success, and fetch_pack() was
not called. Fixed by calling stat() before symlink() to ensure the
file really exists.
Signed-off-by: Sergey Vlasov <vsu@altlinux.ru>
---
local-fetch.c | 14 +++++++++++---
1 files changed, 11 insertions(+), 3 deletions(-)
40d9d7c0c86ee790a330f2fb3e1355bde4e9d434
diff --git a/local-fetch.c b/local-fetch.c
--- a/local-fetch.c
+++ b/local-fetch.c
@@ -65,9 +65,17 @@ static int copy_file(const char *source,
return -1;
}
}
- if (use_symlink && !symlink(source, dest)) {
- pull_say("symlink %s\n", hex);
- return 0;
+ if (use_symlink) {
+ struct stat st;
+ if (stat(source, &st)) {
+ fprintf(stderr, "cannot stat %s: %s\n", source,
+ strerror(errno));
+ return -1;
+ }
+ if (!symlink(source, dest)) {
+ pull_say("symlink %s\n", hex);
+ return 0;
+ }
}
if (use_filecopy) {
int ifd, ofd, status;
^ permalink raw reply
* [PATCH 4/6] git-local-fetch: Avoid calling close(-1)
From: Sergey Vlasov @ 2005-09-23 12:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20050923122754.GB2197@master.mivlgu.local>
After open() failure, copy_file() called close(ifd) with ifd == -1
(harmless, but causes Valgrind noise). The same thing was possible
for the destination file descriptor.
Signed-off-by: Sergey Vlasov <vsu@altlinux.ru>
---
local-fetch.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
bb38750b6016dcd8dc71b2cd0a3bdef035f6508d
diff --git a/local-fetch.c b/local-fetch.c
--- a/local-fetch.c
+++ b/local-fetch.c
@@ -75,7 +75,8 @@ static int copy_file(const char *source,
void *map;
ifd = open(source, O_RDONLY);
if (ifd < 0 || fstat(ifd, &st) < 0) {
- close(ifd);
+ if (ifd >= 0)
+ close(ifd);
fprintf(stderr, "cannot open %s\n", source);
return -1;
}
@@ -89,7 +90,8 @@ static int copy_file(const char *source,
status = ((ofd < 0) ||
(write(ofd, map, st.st_size) != st.st_size));
munmap(map, st.st_size);
- close(ofd);
+ if (ofd >= 0)
+ close(ofd);
if (status)
fprintf(stderr, "cannot write %s\n", dest);
else
^ permalink raw reply
* [PATCH 3/6] git-local-fetch: Fix error checking and leak in setup_indices()
From: Sergey Vlasov @ 2005-09-23 12:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20050923122754.GB2197@master.mivlgu.local>
setup_indices() did not check the return value of opendir(), and
did not have a corresponding closedir() call.
Signed-off-by: Sergey Vlasov <vsu@altlinux.ru>
---
local-fetch.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
b2c9aab8c8186900cc4610e144513d45fc5b4865
diff --git a/local-fetch.c b/local-fetch.c
--- a/local-fetch.c
+++ b/local-fetch.c
@@ -38,6 +38,8 @@ static int setup_indices(void)
unsigned char sha1[20];
sprintf(filename, "%s/objects/pack/", path);
dir = opendir(filename);
+ if (!dir)
+ return -1;
while ((de = readdir(dir)) != NULL) {
int namelen = strlen(de->d_name);
if (namelen != 50 ||
@@ -46,6 +48,7 @@ static int setup_indices(void)
get_sha1_hex(de->d_name + 5, sha1);
setup_index(sha1);
}
+ closedir(dir);
return 0;
}
^ permalink raw reply
* [PATCH 1/6] fetch.c: Do not build object ref lists
From: Sergey Vlasov @ 2005-09-23 12:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20050923122754.GB2197@master.mivlgu.local>
The fetch code does not need object ref lists; by disabling them we
can save some time and memory.
Signed-off-by: Sergey Vlasov <vsu@altlinux.ru>
---
fetch.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
cf77c02b386647f312a86ffc342b010ae55725cd
diff --git a/fetch.c b/fetch.c
--- a/fetch.c
+++ b/fetch.c
@@ -206,6 +206,7 @@ int pull(char *target)
int fd = -1;
save_commit_buffer = 0;
+ track_object_refs = 0;
if (write_ref && current_ref) {
fd = lock_ref_sha1(write_ref, current_ref);
if (fd < 0)
^ permalink raw reply
* [PATCH 2/6] fetch.c: Plug memory leak in process_tree()
From: Sergey Vlasov @ 2005-09-23 12:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20050923122754.GB2197@master.mivlgu.local>
When freeing a tree entry, must free its name too.
Signed-off-by: Sergey Vlasov <vsu@altlinux.ru>
---
fetch.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
33e5d08bcd7c35725f704cb70ffcc7257df61bcb
diff --git a/fetch.c b/fetch.c
--- a/fetch.c
+++ b/fetch.c
@@ -48,6 +48,7 @@ static int process_tree(struct tree *tre
struct tree_entry_list *next = entry->next;
if (process(entry->item.any))
return -1;
+ free(entry->name);
free(entry);
entry = next;
}
^ permalink raw reply
* [PATCH 0/6] More fetch fixes
From: Sergey Vlasov @ 2005-09-23 12:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 503 bytes --]
Hello!
Here are some more patches for the fetch.c common code:
1) Disable building of object ref lists (as in git-rev-list)
2) Fix leak of tree entry names
And then some fixes for git-local-fetch:
3) Fix missing closedir() and check for success of opendir()
4) Avoid close(-1) (not exactly a bug, but Valgrind does not like it)
5) Fix "git-local-fetch -s" not working with packed repositories
6) Avoid confusing "cannot open" error messages before fetching a pack
--
Sergey Vlasov
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: /bin/sh portability question
From: Peter Eriksen @ 2005-09-23 12:17 UTC (permalink / raw)
To: git
In-Reply-To: <7vmzm4duf8.fsf@assigned-by-dhcp.cox.net>
On Fri, Sep 23, 2005 at 02:07:07AM -0700, Junio C Hamano wrote:
> "Peter Eriksen" <s022018@student.dtu.dk> writes:
>
> > It seems things are progressing nicely with regard to
> > Solaris portability.
>
> Good to have a Solaris user. I have one patch that I've been
> keeping in the proposed updates branch, waiting for a
> comfirmation or 'not-good-enough-for-me' answer from people that
> have cURL installed in nonstandard places.
GCC is not complaining. :-)
My current make command is like this:
gmake NO_STRCASESTR=YesPlease CURLDIR=/opt/sfw/ \
SHELL_PATH=/bin/bash INSTALL=ginstall install
There are two problems:
* First of all there really needs to be a TAR variable,
since Solaris tar doesn't like the C option.
* Secondly I've noticed that git.sh and gitk don't get
their /bin/sh line changed during install.
/Peter
^ permalink raw reply
* Re: [PATCH] Verbose git-daemon logging
From: Morten Welinder @ 2005-09-23 12:08 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050921213933.GB10575@pasky.or.cz>
> + buflen = snprintf(buf, 1024, "[%d] ", getpid());
pid_t is not int.
Please cast it to int, or use %ld and cast it to long int.
Morten
^ permalink raw reply
* Re: [RFC] Do we still need the git command?
From: Martin Langhoff @ 2005-09-23 11:38 UTC (permalink / raw)
To: Robert Watson; +Cc: git
In-Reply-To: <72499e3b050923042466011c4f@mail.gmail.com>
On 9/23/05, Robert Watson <robert.oo.watson@gmail.com> wrote:
> (2) Different style from CVS/SVN.
That is a plus in my book -- CVS implemented an awful UI, and everyone
else followed. CVS did make use if it in that it discriminated options
to the cvs utility from command options.
> Pros:
> (4) Do not conflict with GNU Interactive Tools. Make the life of
> Debian people easier.
+1! Anything to avoid yet another flamewar in debian-devel ;-) and it
also shows some good manners towards a (mostly forgotten) but good
project. The whole name conflict prompted me to install the GNU
Interactive Tools and run it for a couple of days. Nifty little
"midnight-commander" style utility.
cheers,
martin
^ permalink raw reply
* [RFC] Do we still need the git command?
From: Robert Watson @ 2005-09-23 11:24 UTC (permalink / raw)
To: git
Hello,
The function of the git command:
(1) As an alias for git-command. After the recent big tool rename,
all "git command" can be replaced by
"git-command".
(2) Report version number. This can be solved by a git-version
command. (3) List interesting commands.
This can be taken care by man git(7) or TAB-TAB. Or, add a git-help
command to list only interesting commands.
How about get rid of the git command all together?
Cons:
(1) Another change of the user interface;
(2) Different style from CVS/SVN.
Pros:
(1) Consistency. There is only one way to do it. People won't be
wondering what's the difference between "git-diff" and "git diff".
(2) Performance. One less shell script to parse and one less exec system call.
(3) TAB completion. git-whatchanged and other long commands are
easier to type with TAB completion. TAB-TAB also shows you all
available commands.
(4) Do not conflict with GNU Interactive Tools. Make the life of
Debian people easier.
What do you think?
Robertoo
^ permalink raw reply
* Re: /bin/sh portability question
From: Sean @ 2005-09-23 10:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfyrwdtv0.fsf@assigned-by-dhcp.cox.net>
On Fri, September 23, 2005 5:19 am, Junio C Hamano said:
> "Sean" <seanlkml@sympatico.ca> writes:
>
>> If not, would you accept a patch that first converted the shell scripts
>> to
>> #!/bin/bash and then added a "make install" option that allowed them to
>> be
>> replaced? Something like "make install S=/bin/ash" for instance?
>
> $ make SHELL_PATH=/bin/bash
>
> Perhaps?
>
Heh.. so you've already got that working :o) So on Solaris one fix would
be to just use the SHELL_PATH setting when installing to point to
/bin/bash. What do you think about making /bin/bash the default?
Sean
^ permalink raw reply
* Re: command to show diff of a commit
From: Robert Watson @ 2005-09-23 10:06 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.58.0509220820011.2553@g5.osdl.org>
On 9/22/05, Linus Torvalds <torvalds@osdl.org> wrote:
>
>
> On Thu, 22 Sep 2005, Robert Watson wrote:
> >
> > I am wondering what is the best way to show the change introduced by a
> > commit. In the other words, is there a better way to do this:
> >
> > git-diff b163512d4eb36ee946908b682c7863658c5a8db4^
> > b163512d4eb36ee946908b682c7863658c5a8db4
>
> Oh, absolutely.
>
> Do
>
> git-diff-tree -p --pretty b163512d4eb36ee946908b682c7863658c5a8db4
>
> and you're done.
>
> If you _just_ want the diff (and not the message), skip the "--pretty".
>
> Linus
>
Many thanks. I know there must be a way to do this.
Here is a patch to make the document a bit clearer.
Regards,
Robertoo
diff --git a/Documentation/git-diff-tree.txt b/Documentation/git-diff-tree.txt
--- a/Documentation/git-diff-tree.txt
+++ b/Documentation/git-diff-tree.txt
@@ -9,12 +9,15 @@ git-diff-tree - Compares the content and
SYNOPSIS
--------
-'git-diff-tree' [--stdin] [-m] [-s] [-v] [--pretty] [-t] [<common
diff options>] <tree-ish> <tree-ish> [<path>...]
+'git-diff-tree' [--stdin] [-m] [-s] [-v] [--pretty] [-t] [<common
diff options>] <tree-ish> [<tree-ish>] [<path>...]
DESCRIPTION
-----------
Compares the content and mode of the blobs found via two tree objects.
+If there is only one <tree-ish> given, the commit is compared with its parents
+(see --stdin below).
+
Note that "git-diff-tree" can use the tree encapsulated in a commit object.
OPTIONS
^ permalink raw reply
* Re: Please undo "Use git-merge instead of git-resolve in
From: Petr Baudis @ 2005-09-23 9:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vslvwcelj.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Fri, Sep 23, 2005 at 11:34:16AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> Petr Baudis <pasky@suse.cz> writes:
>
> > * cg-fetch can do with symlinked object database
>
> Do you mean ".git/object" in the repository you are fetching
> into is a symlink to somewhere, or something else?
Yes, exactly that. You get it by doing cg-clone -l /local/path. O(1)
cloning, but it has its downsides and dangers which I tried to describe
in the cg-clone documentation.
> > * cg-fetch won't do useless fetches when we are already
> > up-to-date
>
> Care to explain? Perhaps you are talking about rsync transport
> (in which case I would not be surprised)?
Just that if the reference pointer did not change, you don't try to pull
any objects. Speeds things up somewhat, and now it should always work
(well, cg-fetch has -f which makes it always try objects as well, in
case something went wrong anyway).
> > * I'm not sure if I could call git-fetch to do the initial
> > fetch during clone
>
> $ git-init-db && git fetch http://kernel.org/pub/scm/git/git.git
>
> should work.
Good.
> There is another minor "con", if you include git-clone in the
> discussion. Over http transport, it refuses to run against a
> remote repository that does not have info/refs and info/packs,
> even if it is not packed. I think cg-clone uses recursive wget
> for directory traversal and does not have to use them.
cg-clone just basically does cg-init && cg-fetch, and I'd really want to
keep it on that. So effectively, cg-clone over http just runs
git-http-fetch and trusts it to do the right thing (reasonably fast).
Recursive wget is used only for fetching tags (and it actually seems to
work nicely, when directory listing is enabled, obviously). Yes, I
should teach cg-fetch about info/refs too.
--
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: StGIT site down
From: Catalin Marinas @ 2005-09-23 9:41 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050923093149.GB10255@pasky.or.cz>
Petr Baudis <pasky@suse.cz> wrote:
> This is very unfortunate because the tutorial is now unavailable, and
> for some reason it is not available in the StGIT distribution either.
> Could you please bundle it?
I will put it back and upload a new snapshot tonight (and update the
repository as well).
--
Catalin
^ permalink raw reply
* Re: Please undo "Use git-merge instead of git-resolve in
From: Junio C Hamano @ 2005-09-23 9:34 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050923091012.GA10255@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> * cg-fetch can do with symlinked object database
Do you mean ".git/object" in the repository you are fetching
into is a symlink to somewhere, or something else?
> * cg-fetch will hardlink if possible when fetching locally
True, git-fetch and git-clone try to use pack protocols by
default, which is debatable. Adding -l (similar to what
git-clone does) would not be too hard, if enough people want
it.
> * cg-fetch won't do useless fetches when we are already
> up-to-date
Care to explain? Perhaps you are talking about rsync transport
(in which case I would not be surprised)?
> * I'm not sure if I could call git-fetch to do the initial
> fetch during clone
$ git-init-db && git fetch http://kernel.org/pub/scm/git/git.git
should work.
There is another minor "con", if you include git-clone in the
discussion. Over http transport, it refuses to run against a
remote repository that does not have info/refs and info/packs,
even if it is not packed. I think cg-clone uses recursive wget
for directory traversal and does not have to use them.
^ 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