* Re: [PATCH] Remove more gcc extension usage.
From: Jan-Benedict Glaw @ 2006-07-10 6:25 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Shawn Pearce, Junio C Hamano, git
In-Reply-To: <1152512523.3504.28.camel@dv>
[-- Attachment #1: Type: text/plain, Size: 728 bytes --]
On Mon, 2006-07-10 02:22:03 -0400, Pavel Roskin <proski@gnu.org> wrote:
> This means that the Sun compiler has almost all c99 features used by git
> with just a little exception (initializers). I think it's fair that we
> fix this incompatibility. It's very very minor compared to what "gcc
> -std=c89 -pedantic" would have required.
^^^^^^^^
You're kidding, aren't you?
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] Move all builtin .c files into builtin/
From: Pavel Roskin @ 2006-07-10 6:41 UTC (permalink / raw)
To: Ryan Anderson; +Cc: git
In-Reply-To: <11525072491512-git-send-email-ryan@michonline.com>
Hello, Ryan!
On Mon, 2006-07-10 at 00:54 -0400, Ryan Anderson wrote:
> Signed-off-by: Ryan Anderson <ryan@michonline.com>
I agree that the top level directory is overcrowded, but wouldn't it be
better to move libgit.a sources to "lib" and then classify the remaining
files in some way (e.g. "git" or "src" for builtin commands, "commands"
for the rest)? While at that, the "buildin-" prefix could be stripped.
The main "git" executable is nothing but several builtin commands rolled
together. It's not like a shell, which has functionality beyond the
builtin commands. So "builtin" is git.
Or you can say that the git executable is a command line frontend to the
git library (it's moving in this direction anyway). Then you can have
"client" and "server" directories. That's more important for
understanding the source than "builtin", "standalone" or any
classification based on technical details.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH] Remove more gcc extension usage.
From: Pavel Roskin @ 2006-07-10 6:52 UTC (permalink / raw)
To: Jan-Benedict Glaw; +Cc: Shawn Pearce, Junio C Hamano, git
In-Reply-To: <20060710062513.GZ22573@lug-owl.de>
On Mon, 2006-07-10 at 08:25 +0200, Jan-Benedict Glaw wrote:
> On Mon, 2006-07-10 02:22:03 -0400, Pavel Roskin <proski@gnu.org> wrote:
> > This means that the Sun compiler has almost all c99 features used by git
> > with just a little exception (initializers). I think it's fair that we
> > fix this incompatibility. It's very very minor compared to what "gcc
> > -std=c89 -pedantic" would have required.
> ^^^^^^^^
>
> You're kidding, aren't you?
In fact I can build git with this command:
make CFLAGS="-std=c89 -pedantic -Dinline=__inline -D_GNU_SOURCE"
if I fix all C++ comments. It warns a lot about "flexible array
members" and other violations, but the resulting executable passes the
test. That's Fedora Core 5 with gcc 4.1.1.
What I meant it that if we go all the way to strict c89 (even with a
modern libc) and fix all the warnings, it will be much more than what is
needed to support Sun's C compiler with its partial c99 support.
We can satisfy the Sun's compiler and yet retain flexible arrays and
other c99 goodies.
Maybe I'm missing your point (or you joke).
--
Regards,
Pavel Roskin
^ permalink raw reply
* [PATCH] Avoid C++ comments, use C comments instead
From: Pavel Roskin @ 2006-07-10 6:57 UTC (permalink / raw)
To: git
From: Pavel Roskin <proski@gnu.org>
This doesn't make the code uglier or harder to read, yet it makes the
code more portable. This also simplifies checking for other potential
incompatibilities. "gcc -std=c89 -pedantic" can flag many incompatible
constructs as warnings, but C++ comments will cause it to emit an error.
Signed-off-by: Pavel Roskin <proski@gnu.org>
---
blame.c | 6 +++---
builtin-apply.c | 21 +++++++++++----------
builtin-push.c | 2 +-
convert-objects.c | 10 +++++-----
dir.c | 2 +-
http-fetch.c | 6 +++---
mktag.c | 5 +++--
read-cache.c | 2 +-
sha1_file.c | 4 ++--
ssh-fetch.c | 4 ++--
10 files changed, 32 insertions(+), 30 deletions(-)
diff --git a/blame.c b/blame.c
index 0a06026..b04b8f5 100644
--- a/blame.c
+++ b/blame.c
@@ -44,8 +44,8 @@ struct util_info {
};
struct chunk {
- int off1, len1; // ---
- int off2, len2; // +++
+ int off1, len1; /* --- */
+ int off2, len2; /* +++ */
};
struct patch {
@@ -255,7 +255,7 @@ static void print_map(struct commit *cmi
}
#endif
-// p is a patch from commit to other.
+/* p is a patch from commit to other. */
static void fill_line_map(struct commit *commit, struct commit *other,
struct patch *p)
{
diff --git a/builtin-apply.c b/builtin-apply.c
index 1e5b846..c903146 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -14,14 +14,15 @@ #include "blob.h"
#include "delta.h"
#include "builtin.h"
-// --check turns on checking that the working tree matches the
-// files that are being modified, but doesn't apply the patch
-// --stat does just a diffstat, and doesn't actually apply
-// --numstat does numeric diffstat, and doesn't actually apply
-// --index-info shows the old and new index info for paths if available.
-// --index updates the cache as well.
-// --cached updates only the cache without ever touching the working tree.
-//
+/*
+ * --check turns on checking that the working tree matches the
+ * files that are being modified, but doesn't apply the patch
+ * --stat does just a diffstat, and doesn't actually apply
+ * --numstat does numeric diffstat, and doesn't actually apply
+ * --index-info shows the old and new index info for paths if available.
+ * --index updates the cache as well.
+ * --cached updates only the cache without ever touching the working tree.
+ */
static const char *prefix;
static int prefix_length = -1;
static int newfd = -1;
@@ -284,8 +285,8 @@ static void parse_traditional_patch(cons
{
char *name;
- first += 4; // skip "--- "
- second += 4; // skip "+++ "
+ first += 4; /* skip "--- " */
+ second += 4; /* skip "+++ " */
if (is_dev_null(first)) {
patch->is_new = 1;
patch->is_delete = 0;
diff --git a/builtin-push.c b/builtin-push.c
index a8fac88..31cbfd7 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -273,7 +273,7 @@ static int do_push(const char *repo)
int cmd_push(int argc, const char **argv, char **envp)
{
int i;
- const char *repo = "origin"; // default repository
+ const char *repo = "origin"; /* default repository */
for (i = 1; i < argc; i++) {
const char *arg = argv[i];
diff --git a/convert-objects.c b/convert-objects.c
index 0fabd89..478571f 100644
--- a/convert-objects.c
+++ b/convert-objects.c
@@ -241,13 +241,13 @@ static void convert_date(void *buffer, u
char *new = xmalloc(size + 100);
unsigned long newlen = 0;
- // "tree <sha1>\n"
+ /* "tree <sha1>\n" */
memcpy(new + newlen, buffer, 46);
newlen += 46;
buffer = (char *) buffer + 46;
size -= 46;
- // "parent <sha1>\n"
+ /* "parent <sha1>\n" */
while (!memcmp(buffer, "parent ", 7)) {
memcpy(new + newlen, buffer, 48);
newlen += 48;
@@ -255,12 +255,12 @@ static void convert_date(void *buffer, u
size -= 48;
}
- // "author xyz <xyz> date"
+ /* "author xyz <xyz> date" */
newlen += convert_date_line(new + newlen, &buffer, &size);
- // "committer xyz <xyz> date"
+ /* "committer xyz <xyz> date" */
newlen += convert_date_line(new + newlen, &buffer, &size);
- // Rest
+ /* Rest */
memcpy(new + newlen, buffer, size);
newlen += size;
diff --git a/dir.c b/dir.c
index d778ecd..092d077 100644
--- a/dir.c
+++ b/dir.c
@@ -336,7 +336,7 @@ static int read_directory_recursive(stru
if (dir->show_other_directories &&
(subdir || !dir->hide_empty_directories) &&
!dir_exists(fullname, baselen + len)) {
- // Rewind the read subdirectory
+ /* Rewind the read subdirectory */
while (dir->nr > rewind_base)
free(dir->entries[--dir->nr]);
break;
diff --git a/http-fetch.c b/http-fetch.c
index 44eba5f..12493fb 100644
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -490,7 +490,7 @@ static int setup_index(struct alt_base *
{
struct packed_git *new_pack;
if (has_pack_file(sha1))
- return 0; // don't list this as something we can get
+ return 0; /* don't list this as something we can get */
if (fetch_index(repo, sha1))
return -1;
@@ -570,7 +570,7 @@ static void process_alternates_response(
base[serverlen - 1] != '/');
i += 3;
}
- // If the server got removed, give up.
+ /* If the server got removed, give up. */
okay = strchr(base, ':') - base + 3 <
serverlen;
} else if (alt_req->http_specific) {
@@ -581,7 +581,7 @@ static void process_alternates_response(
okay = 1;
}
}
- // skip 'objects' at end
+ /* skip 'objects' at end */
if (okay) {
target = xmalloc(serverlen + posn - i - 6);
strlcpy(target, base, serverlen);
diff --git a/mktag.c b/mktag.c
index f0fe528..27f4c4f 100644
--- a/mktag.c
+++ b/mktag.c
@@ -17,7 +17,7 @@ #include "tag.h"
* in that size, you're doing something wrong.
*/
-// Some random size
+/* Some random size */
#define MAXSIZE (8192)
/*
@@ -123,7 +123,8 @@ int main(int argc, char **argv)
die("could not read from stdin");
}
- // Verify it for some basic sanity: it needs to start with "object <sha1>\ntype\ntagger "
+ /* Verify it for some basic sanity: it needs to start with
+ "object <sha1>\ntype\ntagger " */
if (verify_tag(buffer, size) < 0)
die("invalid tag signature file");
diff --git a/read-cache.c b/read-cache.c
index 3c32aae..a50d361 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -748,7 +748,7 @@ int read_cache(void)
die("index file open failed (%s)", strerror(errno));
}
- size = 0; // avoid gcc warning
+ size = 0; /* avoid gcc warning */
map = MAP_FAILED;
if (!fstat(fd, &st)) {
size = st.st_size;
diff --git a/sha1_file.c b/sha1_file.c
index f7bb3a1..459430a 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -453,7 +453,7 @@ int use_packed_git(struct packed_git *p)
{
if (!p->pack_size) {
struct stat st;
- // We created the struct before we had the pack
+ /* We created the struct before we had the pack */
stat(p->pack_name, &st);
if (!S_ISREG(st.st_mode))
die("packfile %s not a regular file", p->pack_name);
@@ -1504,7 +1504,7 @@ static void *repack_object(const unsigne
int hdrlen;
void *buf;
- // need to unpack and recompress it by itself
+ /* need to unpack and recompress it by itself */
unpacked = read_packed_sha1(sha1, type, &len);
hdrlen = sprintf(hdr, "%s %lu", type, len) + 1;
diff --git a/ssh-fetch.c b/ssh-fetch.c
index 1e59cd2..28f7fd9 100644
--- a/ssh-fetch.c
+++ b/ssh-fetch.c
@@ -68,7 +68,7 @@ int fetch(unsigned char *sha1)
struct object_list *temp;
if (memcmp(sha1, in_transit->item->sha1, 20)) {
- // we must have already fetched it to clean the queue
+ /* we must have already fetched it to clean the queue */
return has_sha1_file(sha1) ? 0 : -1;
}
prefetches--;
@@ -85,7 +85,7 @@ int fetch(unsigned char *sha1)
if (read(fd_in, &remote, 1) < 1)
return -1;
}
- //fprintf(stderr, "Got %d\n", remote);
+ /* fprintf(stderr, "Got %d\n", remote); */
if (remote < 0)
return remote;
ret = write_sha1_from_fd(sha1, fd_in, conn_buf, 4096, &conn_buf_posn);
^ permalink raw reply related
* Re: [PATCH] Remove more gcc extension usage.
From: Jan-Benedict Glaw @ 2006-07-10 7:35 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Shawn Pearce, Junio C Hamano, git
In-Reply-To: <1152514328.3504.58.camel@dv>
[-- Attachment #1: Type: text/plain, Size: 1176 bytes --]
On Mon, 2006-07-10 02:52:08 -0400, Pavel Roskin <proski@gnu.org> wrote:
> On Mon, 2006-07-10 at 08:25 +0200, Jan-Benedict Glaw wrote:
> > On Mon, 2006-07-10 02:22:03 -0400, Pavel Roskin <proski@gnu.org> wrote:
> > > This means that the Sun compiler has almost all c99 features used by git
> > > with just a little exception (initializers). I think it's fair that we
> > > fix this incompatibility. It's very very minor compared to what "gcc
> > > -std=c89 -pedantic" would have required.
> > ^^^^^^^^
> > You're kidding, aren't you?
[...]
> We can satisfy the Sun's compiler and yet retain flexible arrays and
> other c99 goodies.
>
> Maybe I'm missing your point (or you joke).
Why should we jump through the hoops to support an obsolete standard
because proprietary compilers don't stand today's standards?
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Avoid C++ comments, use C comments instead
From: Junio C Hamano @ 2006-07-10 7:46 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <20060710065751.22902.43316.stgit@dv.roinet.com>
Pavel Roskin <proski@gnu.org> writes:
> From: Pavel Roskin <proski@gnu.org>
>
> This doesn't make the code uglier or harder to read, yet it makes the
> code more portable. This also simplifies checking for other potential
> incompatibilities. "gcc -std=c89 -pedantic" can flag many incompatible
> constructs as warnings, but C++ comments will cause it to emit an error.
>
> Signed-off-by: Pavel Roskin <proski@gnu.org>
The title should probably read "avoid C99 comments", but coming
from the previous century, I tend to agree with this.
The struct/array initializer stuff by Shawn makes them harder to
read (for structs, it moves initialization to actual code) and
more error prone (for arrays, now the initializers need to be
carefully kept ordered), but we do not have too many of them in
the code, so I do not think it is a not much of a practical
problem. It is sad that some people stay behind and we need to
cater to them, though.
^ permalink raw reply
* Re: [PATCH] Remove more gcc extension usage.
From: Junio C Hamano @ 2006-07-10 7:47 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <1152512523.3504.28.camel@dv>
Pavel Roskin <proski@gnu.org> writes:
> I think it's fair that we fix this incompatibility. It's very
> very minor compared to what "gcc -std=c89 -pedantic" would
> have required.
I think I agree with you. Let's have it in.
^ permalink raw reply
* Re: [PATCH] Remove more gcc extension usage.
From: Pavel Roskin @ 2006-07-10 8:07 UTC (permalink / raw)
To: Jan-Benedict Glaw; +Cc: Shawn Pearce, Junio C Hamano, git
In-Reply-To: <20060710073532.GA22573@lug-owl.de>
Quoting Jan-Benedict Glaw <jbglaw@lug-owl.de>:
> Why should we jump through the hoops to support an obsolete standard
> because proprietary compilers don't stand today's standards?
Because we want git to run on such systems, and asking to compile gcc first is
too much to ask for.
There are still missing or broken C99 features in the current gcc:
http://gcc.gnu.org/c99status.html
Why do we want to avoid C99 features broken in gcc? Because we want users to be
able to compile git with today's gcc, and installing a different compiler
(proprietary or even free) to compile git is too much to ask for.
Maybe if cvsup compiled with gcc, we would be using cvsup backend for git now.
Or maybe cvsup would develop to take the niche currently occupied by git. But
cvsup was written in Modula 3, perhaps a superior language compared to C. You
would have to compile a Modula 3 compiler and a Modula 3 library just to be
able to compile cvsup. The necessary software was free, but compiling it was
not trivial. Let's see, where is cvsup now? How popular is it?
After all, it's a trade-off between ease of coding and ease of installing. Make
coding too hard, and the developers will go elsewhere. Make installation too
hard, and the project starts losing users. And who wants to contribute to an
unpopular project?
Going all the way to strict c89 could be too much, but fixing initializers in a
few places is a minor issue. Users of the Sun's compiler can expect us to do
such changes, just like users of gcc would ask to fix a program that uses c99
features not yet available in gcc.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH] Remove more gcc extension usage.
From: Junio C Hamano @ 2006-07-10 8:10 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <20060710040711.z1h4w0wsgk8sskg4@webmail.spamcop.net>
Pavel Roskin <proski@gnu.org> writes:
> Going all the way to strict c89 could be too much, but fixing
> initializers in a few places is a minor issue. Users of the
> Sun's compiler can expect us to do such changes,...
I am fully with you on this one.
^ permalink raw reply
* Re: [PATCH] Remove more gcc extension usage.
From: Jan-Benedict Glaw @ 2006-07-10 8:18 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Shawn Pearce, Junio C Hamano, git
In-Reply-To: <20060710040711.z1h4w0wsgk8sskg4@webmail.spamcop.net>
[-- Attachment #1: Type: text/plain, Size: 1768 bytes --]
On Mon, 2006-07-10 04:07:11 -0400, Pavel Roskin <proski@gnu.org> wrote:
> Quoting Jan-Benedict Glaw <jbglaw@lug-owl.de>:
> > Why should we jump through the hoops to support an obsolete standard
> > because proprietary compilers don't stand today's standards?
>
> Because we want git to run on such systems, and asking to compile gcc first is
> too much to ask for.
As I said, there are precompiled binaries for basically all useable
systems out there.
> There are still missing or broken C99 features in the current gcc:
> http://gcc.gnu.org/c99status.html
Sure. As are in other compilers. But you forgot to mention that these
missing or broken features are mostly of no use to commonly used C
code. So that's a non-issue. (If it was a real issue, you can be sure
that I'd drop a ton of bug reports into GCC's Bugzilla...)
> Going all the way to strict c89 could be too much, but fixing initializers in a
> few places is a minor issue. Users of the Sun's compiler can expect us to do
> such changes, just like users of gcc would ask to fix a program that uses c99
> features not yet available in gcc.
I'm not sure about specifically the initializers thing. Personally, I
consider the new C99 initializers one of the very best things that
ever happened to the C language, because it fixes a _real_ problem.
You may have noticed that eg. for the kernel code, these are used
throughoutly...
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC+PATCH 1/1] Move SCM interoperability tools into scm/
From: Timo Hirvonen @ 2006-07-10 9:45 UTC (permalink / raw)
To: Ryan Anderson; +Cc: pasky, martin.langhoff, git
In-Reply-To: <44B19D42.6030701@michonline.com>
Ryan Anderson <ryan@michonline.com> wrote:
> By "don't split the Makefile", do mean, "Don't use recursive make"?
>
> I'm fine with that (and if you look at my patch, I "include
> scm/Makefile" to do just that), but if you mean "keep only a top-level
> Makefile", well, I think that continues the problem of "there is too
> much stuff going on here", but I can be persuaded otherwise.
Recursive make is a horrible hack. Splitting Makefile to smaller chunks
which would be included in the top level Makefile is almost as bad. You
can't cd to subdirectory and run make there and you have to prefix all
files with "subdir/".
If you really want to make Makefile shorter just move all the platform
specific stuff to a configure script.
--
http://onion.dynserv.net/~timo/
^ permalink raw reply
* Re: [PATCH] Avoid C++ comments, use C comments instead
From: Olivier Galibert @ 2006-07-10 9:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pavel Roskin, git
In-Reply-To: <7vzmfhdhrf.fsf@assigned-by-dhcp.cox.net>
On Mon, Jul 10, 2006 at 12:46:28AM -0700, Junio C Hamano wrote:
> It is sad that some people stay behind and we need to
> cater to them, though.
Do you, really?
OG.
^ permalink raw reply
* problems GIT_TRACE
From: Matthias Lederhofer @ 2006-07-10 11:05 UTC (permalink / raw)
To: git
I just discovered a problem with GIT_TRACE. Some scripts redirect
stderr to stdout and the trace messages go with it. For example from
git-repack:
> name=$(git-rev-list --objects --all $rev_list 2>&1 |
> git-pack-objects --non-empty $pack_objects .tmp-pack) ||
> exit 1
Then for example git-pack-objects complains:
> fatal: expected sha1, got garbage:
> trace: built-in: git 'rev-list' '--objects' '--all'
git-grep '2>&' shows a few other places that do this too, I'll take a
closer look at this later. Is there any reason to redirect stderr to
stdout? I think this will always fail with such a strange error
message when something is written to stderr.
^ permalink raw reply
* Re: [PATCH] Avoid C++ comments, use C comments instead
From: Johannes Schindelin @ 2006-07-10 11:06 UTC (permalink / raw)
To: Olivier Galibert; +Cc: Junio C Hamano, git
In-Reply-To: <20060710094653.GA52962@dspnet.fr.eu.org>
Hi,
On Mon, 10 Jul 2006, Olivier Galibert wrote:
> On Mon, Jul 10, 2006 at 12:46:28AM -0700, Junio C Hamano wrote:
> > It is sad that some people stay behind and we need to
> > cater to them, though.
>
> Do you, really?
Well, I guess as long as things do not break for _you_, we do not need to.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Fix linking for not-so-clever linkers.
From: Johannes Schindelin @ 2006-07-10 11:40 UTC (permalink / raw)
To: git, junkio
On one of my systems, the linker is not intelligent enough to link with
pager.o (in libgit.a) when only the variable pager_in_use is needed. The
consequence is that the linker complains about an undefined variable. So,
put the variable into environment.o, where it is linked always.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
environment.c | 1 +
| 2 --
2 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/environment.c b/environment.c
index 43823ff..97d42b1 100644
--- a/environment.c
+++ b/environment.c
@@ -21,6 +21,7 @@ char git_commit_encoding[MAX_ENCODING_LE
int shared_repository = PERM_UMASK;
const char *apply_default_whitespace = NULL;
int zlib_compression_level = Z_DEFAULT_COMPRESSION;
+int pager_in_use;
static char *git_dir, *git_object_dir, *git_index_file, *git_refs_dir,
*git_graft_file;
--git a/pager.c b/pager.c
index bb14e99..280f57f 100644
--- a/pager.c
+++ b/pager.c
@@ -5,8 +5,6 @@ #include "cache.h"
* something different on Windows, for example.
*/
-int pager_in_use;
-
static void run_pager(const char *pager)
{
execlp(pager, pager, NULL);
--
1.4.1.g6e33b-dirty
^ permalink raw reply related
* Re: [PATCH] Avoid C++ comments, use C comments instead
From: Olivier Galibert @ 2006-07-10 11:41 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0607101306030.29667@wbgn013.biozentrum.uni-wuerzburg.de>
On Mon, Jul 10, 2006 at 01:06:44PM +0200, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 10 Jul 2006, Olivier Galibert wrote:
>
> > On Mon, Jul 10, 2006 at 12:46:28AM -0700, Junio C Hamano wrote:
> > > It is sad that some people stay behind and we need to
> > > cater to them, though.
> >
> > Do you, really?
>
> Well, I guess as long as things do not break for _you_, we do not need to.
Supporting old, not-standard-anymore compilers has a cost in
maintainability, by precluding the use of better constructs (//
comments, declarations near initialisation, struct initializers...).
Additionally, it gets harder and harder to have people test for them.
Given than you can find gcc on pretty much everything that has a
filesystem cache decent enough to handle git correctly, is this cost
worth it? _That_ was the question.
OG.
^ permalink raw reply
* Perl gurus: why do we need Scalar::Util?
From: Johannes Schindelin @ 2006-07-10 11:44 UTC (permalink / raw)
To: git
Hi,
please do not let my die dumb: what is this "blessed" thing all about? And
why do we need it in the private-Error.pm??
Thanks,
Dscho
^ permalink raw reply
* newbie'ish FAQ/question about merging different trees
From: Peter Gervai @ 2006-07-10 11:56 UTC (permalink / raw)
To: git
Hello,
I ask with specifics to make it easier to get, but the question
probably general.
In one sentence: I would like to use
linux/kernel/git/jejb/aic94xx-sas-2.6.git with the current released
kernel, which is 2.6.17.4 at the moment.
In more sentences:
There are two trees on kernel.org's git:
linux/kernel/git/jejb/aic94xx-sas-2.6.git (it seems to be at 2.6.16-rc5)
linux/kernel/git/torvalds/linux-2.6.git (it probably does have a tag
at v2.6.17.4)
Is there a way to merge these to produce 2.6.17.4 (latest released), patched?
Thanks,
Peter
ps: ...apart from asking the subtree's maintainer to update his tree...
^ permalink raw reply
* [PATCH] read-tree --rename (WIP)
From: Junio C Hamano @ 2006-07-10 12:18 UTC (permalink / raw)
To: git
This adds '--rename' flag to 3-way merge done by "read-tree -m".
Currently it detects the case where one branch renamed but the
other branch didn't. It should be taught to notice that both
branches renamed the same old path to the same new path.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* To use this, you would copy git-merge-resolve.sh to create
git-merge-rename.sh, replace "git-read-tree --aggressive"
call with "git-read-tree --rename", or something like that.
I wanted to avoid the changes to threeway_merge(). They were
to force the code to leave "only one side added" cases
unmerged.
builtin-read-tree.c | 150 +++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 150 insertions(+), 0 deletions(-)
diff --git a/builtin-read-tree.c b/builtin-read-tree.c
index 6df5d7c..e7aba0e 100644
--- a/builtin-read-tree.c
+++ b/builtin-read-tree.c
@@ -11,6 +11,8 @@ #include "object.h"
#include "tree.h"
#include "tree-walk.h"
#include "cache-tree.h"
+#include "diff.h"
+#include "diffcore.h"
#include <sys/time.h>
#include <signal.h>
#include "builtin.h"
@@ -22,6 +24,7 @@ static int index_only = 0;
static int nontrivial_merge = 0;
static int trivial_merges_only = 0;
static int aggressive = 0;
+static int do_renames = 0;
static int verbose_update = 0;
static volatile int progress_update = 0;
static const char *prefix = NULL;
@@ -389,6 +392,130 @@ static void check_updates(struct cache_e
}
}
+static struct cache_entry *renamed_entry(const char *new_name, int namelen, struct cache_entry *old)
+{
+ struct cache_entry *renamed;
+
+ renamed = xcalloc(1, cache_entry_size(namelen));
+ renamed->ce_mode = old->ce_mode;
+ renamed->ce_flags = create_ce_flags(namelen, ce_stage(old));
+ strcpy(renamed->name, new_name);
+ memcpy(renamed->sha1, old->sha1, 20);
+ return renamed;
+}
+
+static void handle_renames(void)
+{
+ /* Find entries that have stages #1 and #2 (but not #3)
+ * and then entries that have stage #3 only.
+ * If #1 of the former and #3 of the latter are similar,
+ * that means we did not rename it but they did.
+ * Similarly, entries that have stages #1 and #3 can be
+ * matched up with entries that have only stage #2, in
+ * which case they did not rename but we did.
+ * In either case, move the #1 and unmoved stage to the
+ * path of the moved stage.
+ */
+ struct diff_options opt;
+ int i;
+
+ diff_setup(&opt);
+ opt.detect_rename = DIFF_DETECT_RENAME;
+ opt.output_format = DIFF_FORMAT_NO_OUTPUT;
+ opt.recursive = 1;
+ diff_setup_done(&opt);
+
+ for (i = 0; i < active_nr; i++) {
+ struct cache_entry *ce = active_cache[i];
+ int j;
+ if (!ce_stage(ce))
+ continue; /* fully merged */
+
+ for (j = i + 1; j < active_nr; j++) {
+ if (strcmp(ce->name, active_cache[j]->name))
+ break;
+ }
+
+ if (ce_stage(ce) == 1 && (j - i) == 2)
+ /* This entry has stage #1 and another one
+ * i.e. either #2 or #3 but not both.
+ */
+ diff_addremove(&opt, '-', ntohl(ce->ce_mode), ce->sha1,
+ ce->name, NULL);
+
+ if (1 < ce_stage(ce) && (j - i) == 1)
+ /* This entry has only stage #2 or #3 */
+ diff_addremove(&opt, '+', ntohl(ce->ce_mode), ce->sha1,
+ ce->name, NULL);
+
+ i = j - 1;
+ }
+ diffcore_std(&opt);
+
+ if (diff_queued_diff.nr) {
+ /* We have found the renames and stuff */
+ for (i = 0; i < diff_queued_diff.nr; i++) {
+ struct diff_filepair *p = diff_queued_diff.queue[i];
+ const char *old_name, *new_name;
+ int namelen;
+ struct cache_entry *e, *e_one, *e_kept, *e_moved;
+ int pos, kept;
+
+ if (p->status != DIFF_STATUS_RENAMED)
+ continue;
+
+ /* one->path has stage #1 and either stage #2
+ * or #3 that was kept on one branch, and
+ * two->path is where it was moved on the other
+ * branch, either stage #2 or stage #3.
+ */
+ old_name = p->one->path;
+ new_name = p->two->path;
+ namelen = strlen(new_name);
+ pos = cache_name_pos(old_name, strlen(old_name));
+ if (0 <= pos)
+ die("oops %s:%d", __FILE__, __LINE__);
+ pos = -pos - 1;
+ e = active_cache[pos++];
+ if (strcmp(e->name, old_name))
+ die("oops %s:%d", __FILE__, __LINE__);
+ if (ce_stage(e) != 1)
+ die("oops %s:%d", __FILE__, __LINE__);
+ e_one = renamed_entry(new_name, namelen, e);
+ if (active_nr <= pos)
+ die("oops %s:%d", __FILE__, __LINE__);
+ e = active_cache[pos];
+ if (strcmp(e->name, old_name))
+ die("oops %s:%d", __FILE__, __LINE__);
+ kept = ce_stage(e);
+ if (kept < 2)
+ die("oops %s:%d", __FILE__, __LINE__);
+ e_kept = renamed_entry(new_name, namelen, e);
+
+ pos = cache_name_pos(new_name, namelen);
+ if (0 <= pos)
+ die("oops %s:%d", __FILE__, __LINE__);
+ pos = -pos - 1;
+ e = active_cache[pos];
+ if (strcmp(e->name, new_name))
+ die("oops %s:%d", __FILE__, __LINE__);
+ if (ce_stage(e) + kept != 5)
+ /* If kept was #2 this must be #3 and
+ * vice versa.
+ */
+ die("oops %s:%d", __FILE__, __LINE__);
+ e_moved = renamed_entry(new_name, namelen, e);
+
+ remove_file_from_cache(old_name);
+ remove_file_from_cache(new_name);
+ add_cache_entry(e_one, ADD_CACHE_OK_TO_ADD);
+ add_cache_entry(e_kept, ADD_CACHE_OK_TO_ADD);
+ add_cache_entry(e_moved, ADD_CACHE_OK_TO_ADD);
+ }
+ }
+ diff_flush(&opt);
+}
+
static int unpack_trees(merge_fn_t fn)
{
int indpos = 0;
@@ -412,6 +539,9 @@ static int unpack_trees(merge_fn_t fn)
if (trivial_merges_only && nontrivial_merge)
die("Merge requires file-level merging");
+ if (merge_size == 3 && do_renames)
+ handle_renames();
+
check_updates(active_cache, active_nr);
return 0;
}
@@ -606,6 +736,10 @@ static int threeway_merge(struct cache_e
}
}
+ if (do_renames && remote && !head && !index && any_anc_missing)
+ /* they created, we didn't -- maybe they renamed */
+ return keep_entry(remote);
+
/* We start with cases where the index is allowed to match
* something other than the head: #14(ALT) and #2ALT, where it
* is permitted to match the result instead.
@@ -625,6 +759,10 @@ static int threeway_merge(struct cache_e
}
if (head) {
+ if (do_renames && !remote && any_anc_missing)
+ /* we created, they didn't -- maybe we renamed */
+ return keep_entry(head);
+
/* #5ALT, #15 */
if (same(head, remote))
return merged_entry(head, index);
@@ -868,6 +1006,9 @@ static void prime_cache_tree(void)
static const char read_tree_usage[] = "git-read-tree (<sha> | [[-m [--aggressive] | --reset | --prefix=<prefix>] [-u | -i]] <sha1> [<sha2> [<sha3>]])";
+static const char err_aggressive_rename[] =
+"--aggressive and --rename are mutually exclusive";
+
static struct lock_file lock_file;
int cmd_read_tree(int argc, const char **argv, char **envp)
@@ -952,10 +1093,19 @@ int cmd_read_tree(int argc, const char *
}
if (!strcmp(arg, "--aggressive")) {
+ if (do_renames)
+ die(err_aggressive_rename);
aggressive = 1;
continue;
}
+ if (!strcmp(arg, "--rename")) {
+ if (aggressive)
+ die(err_aggressive_rename);
+ do_renames = 1;
+ continue;
+ }
+
/* "-m" stands for "merge", meaning we start in stage 1 */
if (!strcmp(arg, "-m")) {
if (stage || merge || prefix)
--
1.4.1.gf157
^ permalink raw reply related
* Re: problems GIT_TRACE
From: Junio C Hamano @ 2006-07-10 12:22 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: git
In-Reply-To: <E1Fzta3-00066Z-8B@moooo.ath.cx>
Matthias Lederhofer <matled@gmx.net> writes:
> I just discovered a problem with GIT_TRACE. Some scripts redirect
> stderr to stdout and the trace messages go with it. For example from
> git-repack:
>> name=$(git-rev-list --objects --all $rev_list 2>&1 |
>> git-pack-objects --non-empty $pack_objects .tmp-pack) ||
>> exit 1
> Then for example git-pack-objects complains:
>> fatal: expected sha1, got garbage:
>> trace: built-in: git 'rev-list' '--objects' '--all'
> git-grep '2>&' shows a few other places that do this too, I'll take a
> closer look at this later. Is there any reason to redirect stderr to
> stdout? I think this will always fail with such a strange error
> message when something is written to stderr.
This particular one is trying to catch an error condition from
rev-list. Shell reports the exit status from the last command
in the pipeline, and when rev-list notices a corrupt repository,
it wants to tell pack-objects to stop producing incorrect pack,
but there is no way other than sending a garbage string (as an
error message) to cause pack-object to notice there is garbage
coming in.
^ permalink raw reply
* Re: newbie'ish FAQ/question about merging different trees
From: Alex Riesen @ 2006-07-10 12:31 UTC (permalink / raw)
To: Peter Gervai; +Cc: git
In-Reply-To: <d55656c10607100456o761bb342p3db229b499579dd9@mail.gmail.com>
On 7/10/06, Peter Gervai <grin@grin.hu> wrote:
> There are two trees on kernel.org's git:
>
> linux/kernel/git/jejb/aic94xx-sas-2.6.git (it seems to be at 2.6.16-rc5)
> linux/kernel/git/torvalds/linux-2.6.git (it probably does have a tag
> at v2.6.17.4)
It doesn't. The stable tags are in stable per-release repo
(linux-2.6.17.y.git currently)
> Is there a way to merge these to produce 2.6.17.4 (latest released), patched?
>
Why, doesn't "git pull aic94xx-sas-2.6.git master" work anymore?
^ permalink raw reply
* Re: Perl gurus: why do we need Scalar::Util?
From: Petr Baudis @ 2006-07-10 13:00 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0607101343060.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Hi,
Dear diary, on Mon, Jul 10, 2006 at 01:44:39PM CEST, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> please do not let my die dumb: what is this "blessed" thing all about? And
> why do we need it in the private-Error.pm??
I'm working on it. I'll try to get a patch together by the evening.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* Re: [Patch] Using 'perl' in *.sh
From: Randal L. Schwartz @ 2006-07-10 13:09 UTC (permalink / raw)
To: Michal Rokos; +Cc: Junio C Hamano, git
In-Reply-To: <200607100741.26377.michal.rokos@nextsoft.cz>
>>>>> "Michal" == Michal Rokos <michal.rokos@nextsoft.cz> writes:
Michal> I don't se the point. If you ask me, I'd say it should be either:
Michal> - controlled fully via env: which means 'perl' in scripts and /usr/bin/env in
Michal> *.perl; or
which *pointlessly* doesn't work if *I* have installed a private Perl and a
private git on a large shared systems, and *you* on the same system want to
use my git installation, but not necessarily have my Perl in your path.
There's *no* point to the env hack. You're *installing* the file, which means
you can *rewrite* it as needed. The env hack is a quick hack in case you have
a no-install file (something you're rsync'ing from one machine to another) for
strictly personal use. Don't introduce that to something like the formal
git installation.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: newbie'ish FAQ/question about merging different trees
From: Peter Gervai @ 2006-07-10 13:10 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0607100531k6fc6921do1990850aef259dba@mail.gmail.com>
On 7/10/06, Alex Riesen <raa.lkml@gmail.com> wrote:
> On 7/10/06, Peter Gervai <grin@grin.hu> wrote:
> > There are two trees on kernel.org's git:
> >
> > linux/kernel/git/jejb/aic94xx-sas-2.6.git (it seems to be at 2.6.16-rc5)
> > linux/kernel/git/torvalds/linux-2.6.git (it probably does have a tag
> > at v2.6.17.4)
>
> It doesn't. The stable tags are in stable per-release repo
> (linux-2.6.17.y.git currently)
Well, even that would do.
> > Is there a way to merge these to produce 2.6.17.4 (latest released), patched?
>
> Why, doesn't "git pull aic94xx-sas-2.6.git master" work anymore?
s/Why,/The answer /;
s/ anymore/s for you, right?/;
:)
Thanks, it merged. It does not compile, but that's what I get using
git trees. :)
^ permalink raw reply
* [PATCH] fix git-repack for use with GIT_TRACE
From: Matthias Lederhofer @ 2006-07-10 13:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwtalbqeo.fsf@assigned-by-dhcp.cox.net>
---
Junio C Hamano <junkio@cox.net> wrote:
> This particular one is trying to catch an error condition from
> rev-list. Shell reports the exit status from the last command
> in the pipeline, and when rev-list notices a corrupt repository,
> it wants to tell pack-objects to stop producing incorrect pack,
> but there is no way other than sending a garbage string (as an
> error message) to cause pack-object to notice there is garbage
> coming in.
Ok, this patch should fix this. Instead of "echo abort" another more
meaningful message could be used. I checked the other scripts which
redirect stderr and they should be fine. In the tests I found
t/t1200-tutorial.sh:38
t/t1300-repo-config.sh:276
t/t5500-fetch-pack.sh:66
redirecting stderr, which probably fail which GIT_TRACE.
git-cvsserver.perl:2138 has 2>&1 but uses an regexp to match for the
content, so the trace message should not make a problem. Can someone
using git-cvsserver confirm this? Perhaps this should be changed to
2>/dev/null anyway.
---
git-repack.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-repack.sh b/git-repack.sh
index 640ad8d..4dd7dad 100755
--- a/git-repack.sh
+++ b/git-repack.sh
@@ -43,7 +43,7 @@ case ",$all_into_one," in
;;
esac
pack_objects="$pack_objects $local $quiet $no_reuse_delta$extra"
-name=$(git-rev-list --objects --all $rev_list 2>&1 |
+name=$( (git-rev-list --objects --all $rev_list || echo abort) |
git-pack-objects --non-empty $pack_objects .tmp-pack) ||
exit 1
if [ -z "$name" ]; then
--
1.4.1.gf157-dirty
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox