* Re: Possibility of a MinGW version?
From: Andreas Ericsson @ 2005-12-24 23:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwthus7gr.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Andreas Ericsson <ae@op5.se> writes:
>
>
>>The fact that there are 39 bash'ish shell-scripts does little to help a
>>native port...
>
>
> Can you defend that "bash'ism" comment for all 39? The one I
> know of and would want to get rid of its bashism by rewriting is
> git-grep, but most of them I thought was plain POSIX.
>
Not really, no. I meant "there are 39 shell-scripts known to work with
bash but not necessarily known to fail with any other shell", which
usually means "it will break with some shell or other, although the
shell that breaks is unusual enough for everyone not to have tested it
yet". I'm probably being a bit super-anal and anti-MS biased.
I wrote the first mail being terribly hung over and this one being
slightly tipsy. I now get the feeling that everything will work out for
the best. Happy christmas everyone.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Add a "git-describe" command
From: Linus Torvalds @ 2005-12-24 22:13 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0512241339120.14098@g5.osdl.org>
On Sat, 24 Dec 2005, Linus Torvalds wrote:
>
> This is useful for two things:
>
> - automatic version naming in Makefiles, for example. We could use it in
> git itself: when doing "git --version", we could use this to give a
> much more useful description of exactly what version was installed.
This trivial patch fails to do that correctly, but maybe somebody could
fix it.
The problem is not that it generates GIT_VERSION wrong. The problem is
two-fold:
- it should notice when "git-describe" doesn't exist, and fall back on
the old less-than-descriptive behaviour
- it doesn't do dependencies correctly (ie it should now make "git"
depend on the version number, but it doesn't, so it doesn't re-build
git after a commit/pull)
but at least it shows the _idea_ of using git-describe.
With this I get
[torvalds@g5 git]$ git --version
git version v1.0.4-g6e9961d6
which I think is better than "1.0.GIT" which doesn't say anything about
what the _actual_ version was.
(Ignore the particular SHA1 hash - it has my local commit that you can't
re-create that just created that git-describe thing. You'll get your own
version number).
Linus
---
diff --git a/Makefile b/Makefile
index 47e7898..2e5c569 100644
--- a/Makefile
+++ b/Makefile
@@ -55,7 +55,7 @@ all:
# Define USE_STDEV below if you want git to care about the underlying device
# change being considered an inode change from the update-cache perspective.
-GIT_VERSION = 1.0.GIT
+GIT_VERSION = $(shell git-describe HEAD | sed 's:refs/tags/::')
# CFLAGS and LDFLAGS are for the users to override from the command line.
^ permalink raw reply related
* Add a "git-describe" command
From: Linus Torvalds @ 2005-12-24 21:50 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
It shows you the most recent tag that is reachable from a particular
commit is.
Maybe this is something that "git-name-rev" should be taught to do,
instead of having a separate command for it. Regardless, I find it useful.
What it does is to take any random commit, and "name" it by looking up the
most recent commit that is tagged and reachable from that commit. If the
match is exact, it will just print out that ref-name directly. Otherwise
it will print out the ref-name, followed by the 8-character "short SHA".
IOW, with something like Junios current tree, I get:
[torvalds@g5 git]$ git-describe parent
refs/tags/v1.0.4-g2414721b
ie the current head of my "parent" branch (ie Junio) is based on v1.0.4,
but since it has a few commits on top of that, it has added the git hash
of the thing to the end: "-g" + 8-char shorthand for the commit
2414721b194453f058079d897d13c4e377f92dc6.
Doing a "git-describe" on a tag-name will just show the full tag path:
[torvalds@g5 git]$ git-describe v1.0.4
refs/tags/v1.0.4
unless there are _other_ tags pointing to that commit, in which case it
will just choose one at random.
This is useful for two things:
- automatic version naming in Makefiles, for example. We could use it in
git itself: when doing "git --version", we could use this to give a
much more useful description of exactly what version was installed.
- for any random commit (say, you use "gitk <pathname>" or
"git-whatchanged" to look at what has changed in some file), you can
figure out what the last version of the repo was. Ie, say I find a bug
in commit 39ca371c45b04cd50d0974030ae051906fc516b6, I just do:
[torvalds@g5 linux]$ git-describe 39ca371c45b04cd50d0974030ae051906fc516b6
refs/tags/v2.6.14-rc4-g39ca371c
and I now know that it was _not_ in v2.6.14-rc4, but was presumably in
v2.6.14-rc5.
The latter is useful when you want to see what "version timeframe" a
commit happened in.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
Comments?
Linus
diff --git a/Makefile b/Makefile
index 3395a9e..47e7898 100644
--- a/Makefile
+++ b/Makefile
@@ -135,7 +135,8 @@ PROGRAMS = \
git-unpack-objects$X git-update-index$X git-update-server-info$X \
git-upload-pack$X git-verify-pack$X git-write-tree$X \
git-update-ref$X git-symbolic-ref$X git-check-ref-format$X \
- git-name-rev$X git-pack-redundant$X git-repo-config$X git-var$X
+ git-name-rev$X git-pack-redundant$X git-repo-config$X git-var$X \
+ git-describe$X
# what 'all' will build and 'install' will install.
ALL_PROGRAMS = $(PROGRAMS) $(SIMPLE_PROGRAMS) $(SCRIPTS) git$X
diff --git a/describe.c b/describe.c
new file mode 100644
index 0000000..ebfa429
--- /dev/null
+++ b/describe.c
@@ -0,0 +1,118 @@
+#include "cache.h"
+#include "commit.h"
+#include "refs.h"
+
+#define SEEN (1u << 0)
+
+static const char describe_usage[] = "git-describe [--all] <committish>*";
+
+static int all = 0; /* Default to tags only */
+
+static int names = 0, allocs = 0;
+static struct commit_name {
+ const struct commit *commit;
+ char path[];
+} **name_array = NULL;
+
+static struct commit_name *match(struct commit *cmit)
+{
+ int i = names;
+ struct commit_name **p = name_array;
+
+ while (i-- > 0) {
+ struct commit_name *n = *p++;
+ if (n->commit == cmit)
+ return n;
+ }
+ return NULL;
+}
+
+static void add_to_known_names(const char *path, const struct commit *commit)
+{
+ int idx;
+ int len = strlen(path)+1;
+ struct commit_name *name = xmalloc(sizeof(struct commit_name) + len);
+
+ name->commit = commit;
+ memcpy(name->path, path, len);
+ idx = names;
+ if (idx >= allocs) {
+ allocs = (idx + 50) * 3 / 2;
+ name_array = xrealloc(name_array, allocs*sizeof(*name_array));
+ }
+ name_array[idx] = name;
+ names = ++idx;
+}
+
+static int get_name(const char *path, const unsigned char *sha1)
+{
+ struct commit *commit = lookup_commit_reference_gently(sha1, 1);
+ if (!commit)
+ return 0;
+ if (!all && strncmp(path, "refs/tags/", 10))
+ return 0;
+ add_to_known_names(path, commit);
+ return 0;
+}
+
+static int compare_names(const void *_a, const void *_b)
+{
+ struct commit_name *a = *(struct commit_name **)_a;
+ struct commit_name *b = *(struct commit_name **)_b;
+ unsigned long a_date = a->commit->date;
+ unsigned long b_date = b->commit->date;
+ return (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1;
+}
+
+static void describe(struct commit *cmit)
+{
+ struct commit_list *list;
+ static int initialized = 0;
+ struct commit_name *n;
+
+ if (!initialized) {
+ initialized = 1;
+ for_each_ref(get_name);
+ qsort(name_array, names, sizeof(*name_array), compare_names);
+ }
+
+ n = match(cmit);
+ if (n) {
+ printf("%s\n", n->path);
+ return;
+ }
+
+ list = NULL;
+ commit_list_insert(cmit, &list);
+ while (list) {
+ struct commit *c = pop_most_recent_commit(&list, SEEN);
+ n = match(c);
+ if (n) {
+ printf("%s-g%.8s\n", n->path, sha1_to_hex(cmit->object.sha1));
+ return;
+ }
+ }
+}
+
+int main(int argc, char **argv)
+{
+ int i;
+
+ for (i = 1; i < argc; i++) {
+ const char *arg = argv[i];
+ unsigned char sha1[20];
+ struct commit *cmit;
+
+ if (!strcmp(arg, "--all")) {
+ all = 1;
+ continue;
+ }
+ if (get_sha1(arg, sha1) < 0)
+ usage(describe_usage);
+ cmit = lookup_commit_reference(sha1);
+ if (!cmit)
+ usage(describe_usage);
+ describe(cmit);
+ }
+ return 0;
+}
^ permalink raw reply related
* Re: [PATCH] add strcpy_user_path() and use it in init-db.c and git.c
From: Eric Wong @ 2005-12-24 21:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git list
In-Reply-To: <7vu0cyqk5d.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Eric Wong <normalperson@yhbt.net> writes:
>
> > My home directories have different names on different machines I'm
> > on, and I want to avoid having to recompile git for each one.
> > I don't have root access to some of them, so installing globally in /usr
> > or /usr/local isn't an option, either.
>
> Then you probably need to use GIT_EXEC_PATH environment
> variable.
That works with git.c but not init-db. But then again I don't use
git-init-db that often. I'll just write a shell script wrapper for the
latter if I do.
No need for this patch anymore :)
--
Eric Wong
^ permalink raw reply
* Re: [PATCH 4/4] git-compat-util.h: dietlibc-friendly x{malloc,realloc,calloc}
From: Eric Wong @ 2005-12-24 21:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3bkis631.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Eric Wong <normalperson@yhbt.net> writes:
>
> > dietlibc versions of these allocators returns NULL if a size of zero is
> > specified. Obviously, this is a problem with the x* wrappers since
> > we check for them returning NULL.
> >
> > Down the line, it'd be better to hunt down and eliminate all calls to
> > these functions when they are called with a zero argument. I've already
> > added some checks for these cases that were exposed by tests.
>
> I agree that it is a bug to rely on *alloc(0) not returning
> NULL, but this patch is too risky. It would be a good thing to
> have debugging variant of x* wrappers that barf on a 0-byte
> allocation request to find the offending callers, instead of
> returning NULL, maybe like the attached patch.
>
> Since eradicating *alloc(0) calls is the right way to go, but it
> takes time. Touching x* wrappers for general public should not
> be done before it is done. It breaks things for everybody,
> while the current code is broken only for diet people and
> developers that use the debugging variant of x* wrappers.
I'll be using the following patch to collect results for the next few
days without interrupting my work on other projects. I'll post
patches to remove *alloc(0) calls when I find them.
diff --git a/git-compat-util.h b/git-compat-util.h
index 0c98c99..43be289 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -60,9 +60,41 @@ extern int gitsetenv(const char *, const
extern char *gitstrcasestr(const char *haystack, const char *needle);
#endif
+static void fork_for_core (const char * caller)
+{
+ pid_t child = fork();
+ if (child == 0) {
+ int i;
+ char out[4096];
+ char * progname = "unknown";
+ FILE * dbg = fopen("/var/tmp/git_alloc_dbg.log","a");
+
+ for(i = 0; environ[i]; i++) {
+ if (strstr(environ[i],"_=") == environ[i])
+ progname = environ[i];
+ }
+
+ snprintf(out, 4096, "%s:%s: pid %d dumping core for pid %d\n",
+ progname, caller, getpid(), getppid());
+
+ fputs(out, stderr);
+ fputs(out, dbg);
+ fflush(NULL);
+
+ abort();
+ }
+}
+
static inline void *xmalloc(size_t size)
{
- void *ret = malloc(size);
+ void *ret;
+
+ if (!size) {
+ fork_for_core(__func__);
+ return NULL;
+ }
+
+ ret = malloc(size);
if (!ret)
die("Out of memory, malloc failed");
return ret;
@@ -70,7 +102,15 @@ static inline void *xmalloc(size_t size)
static inline void *xrealloc(void *ptr, size_t size)
{
- void *ret = realloc(ptr, size);
+ void *ret;
+
+ if (!size) {
+ fork_for_core(__func__);
+ free(ptr);
+ return NULL;
+ }
+
+ ret = realloc(ptr, size);
if (!ret)
die("Out of memory, realloc failed");
return ret;
@@ -78,7 +118,14 @@ static inline void *xrealloc(void *ptr,
static inline void *xcalloc(size_t nmemb, size_t size)
{
- void *ret = calloc(nmemb, size);
+ void *ret;
+
+ if (!nmemb || !size) {
+ fork_for_core(__func__);
+ return NULL;
+ }
+
+ ret = calloc(nmemb, size);
if (!ret)
die("Out of memory, calloc failed");
return ret;
--
Eric Wong
^ permalink raw reply related
* Re: [PATCH 3/4] add xmktime() function that always accounts for the TZ env
From: Junio C Hamano @ 2005-12-24 21:10 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20051224195247.GF3963@mail.yhbt.net>
Eric Wong <normalperson@yhbt.net> writes:
> Junio C Hamano <junkio@cox.net> wrote:
>> Eric Wong <normalperson@yhbt.net> writes:
>>
>> > This function was added because mktime in dietlibc doesn't seem to
>> > account for the TZ env. Also, xmktime() now shares the same
>> > always-summer bug TZ parsing elsewhere,
>>
>> Where elsewhere?
>
> match_alpha() in date.c
Then probably we should extract partime.c from rcs and munge
that.
^ permalink raw reply
* Re: [PATCH] add strcpy_user_path() and use it in init-db.c and git.c
From: Junio C Hamano @ 2005-12-24 21:07 UTC (permalink / raw)
To: Eric Wong; +Cc: git list
In-Reply-To: <20051224195033.GE3963@mail.yhbt.net>
Eric Wong <normalperson@yhbt.net> writes:
> My home directories have different names on different machines I'm
> on, and I want to avoid having to recompile git for each one.
> I don't have root access to some of them, so installing globally in /usr
> or /usr/local isn't an option, either.
Then you probably need to use GIT_EXEC_PATH environment
variable.
^ permalink raw reply
* Re: [PATCH 3/4] add xmktime() function that always accounts for the TZ env
From: Eric Wong @ 2005-12-24 19:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy82aqp5r.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Eric Wong <normalperson@yhbt.net> writes:
>
> > This function was added because mktime in dietlibc doesn't seem to
> > account for the TZ env. Also, xmktime() now shares the same
> > always-summer bug TZ parsing elsewhere,
>
> Where elsewhere?
match_alpha() in date.c
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] add strcpy_user_path() and use it in init-db.c and git.c
From: Eric Wong @ 2005-12-24 19:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git list
In-Reply-To: <7virtes6zd.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Eric Wong <normalperson@yhbt.net> writes:
>
> > Hint: build git with: make 'prefix=~'
>
> Sorry, I do not see why you would want to do this. I understand
> "make prefix=~" or "make prefix=$HOME", but "make prefix='~'"
> and expanding tilde and friends at runtime you need to justify
> why it helps in which situation.
>
> We are not DOS and do not do argument expansion shell should
> have done for us ourselves.
My home directories have different names on different machines I'm
on, and I want to avoid having to recompile git for each one.
I don't have root access to some of them, so installing globally in /usr
or /usr/local isn't an option, either.
--
Eric Wong
^ permalink raw reply
* Re: [PATCH 3/4] add xmktime() function that always accounts for the TZ env
From: Junio C Hamano @ 2005-12-24 19:18 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20051224121339.GB3963@mail.yhbt.net>
Eric Wong <normalperson@yhbt.net> writes:
> This function was added because mktime in dietlibc doesn't seem to
> account for the TZ env. Also, xmktime() now shares the same
> always-summer bug TZ parsing elsewhere,
Where elsewhere?
^ permalink raw reply
* Re: [PATCH 4/4] git-compat-util.h: dietlibc-friendly x{malloc,realloc,calloc}
From: Junio C Hamano @ 2005-12-24 18:28 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20051224121454.GC3963@mail.yhbt.net>
Eric Wong <normalperson@yhbt.net> writes:
> dietlibc versions of these allocators returns NULL if a size of zero is
> specified. Obviously, this is a problem with the x* wrappers since
> we check for them returning NULL.
>
> Down the line, it'd be better to hunt down and eliminate all calls to
> these functions when they are called with a zero argument. I've already
> added some checks for these cases that were exposed by tests.
I agree that it is a bug to rely on *alloc(0) not returning
NULL, but this patch is too risky. It would be a good thing to
have debugging variant of x* wrappers that barf on a 0-byte
allocation request to find the offending callers, instead of
returning NULL, maybe like the attached patch.
Since eradicating *alloc(0) calls is the right way to go, but it
takes time. Touching x* wrappers for general public should not
be done before it is done. It breaks things for everybody,
while the current code is broken only for diet people and
developers that use the debugging variant of x* wrappers.
-- >8 --
diff --git a/git-compat-util.h b/git-compat-util.h
index 0c98c99..08fd6bc 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -60,9 +60,17 @@ extern int gitsetenv(const char *, const
extern char *gitstrcasestr(const char *haystack, const char *needle);
#endif
+#ifdef DEBUG_0ALLOC
+#define debug_0alloc(sz) assert(0 < (sz))
+#else
+#define debug_0alloc(sz)
+#endif
+
static inline void *xmalloc(size_t size)
{
void *ret = malloc(size);
+
+ debug_0alloc(size);
if (!ret)
die("Out of memory, malloc failed");
return ret;
@@ -71,6 +79,7 @@ static inline void *xmalloc(size_t size)
static inline void *xrealloc(void *ptr, size_t size)
{
void *ret = realloc(ptr, size);
+ debug_0alloc(size);
if (!ret)
die("Out of memory, realloc failed");
return ret;
@@ -79,6 +88,7 @@ static inline void *xrealloc(void *ptr,
static inline void *xcalloc(size_t nmemb, size_t size)
{
void *ret = calloc(nmemb, size);
+ debug_0alloc(nmemb);
if (!ret)
die("Out of memory, calloc failed");
return ret;
^ permalink raw reply related
* Re: [PATCH] add strcpy_user_path() and use it in init-db.c and git.c
From: Junio C Hamano @ 2005-12-24 18:08 UTC (permalink / raw)
To: Eric Wong; +Cc: git list
In-Reply-To: <20051224122016.GD3963@mail.yhbt.net>
Eric Wong <normalperson@yhbt.net> writes:
> Hint: build git with: make 'prefix=~'
Sorry, I do not see why you would want to do this. I understand
"make prefix=~" or "make prefix=$HOME", but "make prefix='~'"
and expanding tilde and friends at runtime you need to justify
why it helps in which situation.
We are not DOS and do not do argument expansion shell should
have done for us ourselves.
^ permalink raw reply
* Re: Possibility of a MinGW version?
From: Junio C Hamano @ 2005-12-24 17:58 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <43AD1E63.4040103@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> The fact that there are 39 bash'ish shell-scripts does little to help a
> native port...
Can you defend that "bash'ism" comment for all 39? The one I
know of and would want to get rid of its bashism by rewriting is
git-grep, but most of them I thought was plain POSIX.
^ permalink raw reply
* Re: Possibility of a MinGW version?
From: David Brown @ 2005-12-24 16:40 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: skimo, Rob McDonald, git
In-Reply-To: <43AD21D7.5060306@op5.se>
On Sat, Dec 24, 2005 at 11:24:23AM +0100, Andreas Ericsson wrote:
> Sven Verdoolaege wrote:
> >On Sat, Dec 24, 2005 at 11:09:39AM +0100, Andreas Ericsson wrote:
> >
> >>The worst trouble you're likely to run into is all the hardcoded paths.
> >>They are everywhere and ofcourse use the / for path entity separation.
> >
> >
> >AFAIR, '/' is a valid path separator on Windows.
> >It's just command.com (does that still exist?) that insisted on '\\'
> >separators.
>
> Are you sure? I've seen lots of porting patches that transliterate those
> to '\\'. Perhaps those who wrote those patches just took for granted
> that it was needed, the same as I did.
AFAIK all of the Win32 APIs accept either forward or backward slash as a
separator. It has been this way since when they added directories to DOS.
What doesn't always accept forward slashes are commandline utilities that
are using '/' as an option separator. Most of them these days will accept
the '/', at least in many circumstances.
Dave
^ permalink raw reply
* [ANNOUNCE] qgit-1.0rc2
From: Marco Costalba @ 2005-12-24 14:41 UTC (permalink / raw)
To: git; +Cc: proski
There have been some important fixes this week that deserve a new and not
foreseen release candidate.
Me and Pavel are still fighting against an obscure
file_history_truncated_while_loading bug and I would like to fix before 1.0
Thanks to Pavel for providing patches and suggestions.
Merry Christmas Everybody
Marco
DOWNLOAD
TARBALL: http://prdownloads.sourceforge.net/qgit/qgit-1.0rc2.tar.bz2?download
GIT: http://digilander.libero.it/mcostalba/qgit.git
BINARY: http://digilander.libero.it/mcostalba/qgit
Links page: http://digilander.libero.it/mcostalba/
CHANGELOG
- fix tree browsing corner case
- allow overriding CCFLAGS [by Pavel Roskin]
- use git-am instead of git-applymbox to import patches
- enforce const return types when possible
- disable filter tree action while filtering
- fix missing resume after refresh in file history loading
- remove static variables from read functions
- added 'Check working dir' menu entry
- adjust widgets size with font
- patchesStillToFind not initialized [by Pavel Roskin]
- set 'View diff' and 'View file' as toggle actions
- enable compiler warnings [by Pavel Roskin]
- add range select dialog options
- fix drag and drop between StGIT patches
___________________________________
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB
http://mail.yahoo.it
^ permalink raw reply
* Re: Possibility of a MinGW version?
From: Rob McDonald @ 2005-12-24 13:51 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <43AD1E63.4040103@op5.se>
> The worst trouble you're likely to run into is all the hardcoded paths.
> They are everywhere and ofcourse use the / for path entity separation.
>
> The fact that there are 39 bash'ish shell-scripts does little to help a
> native port, and although they can be fairly easily replaced by "real"
> programs it still means quite a bit of work with little real value for
> the unix-version, so I'm guessing you'll have to write those up for
> yourself.
MSYS is a minimal system that includes ports of all build-chain tools you
need to get Makefiles to work. I would envision using it along with native
ports of Perl, Tk/Tcl, etc.
> Is there some reason you can't install Cygwin, which effectively
> overcomes both those problems?
I've had consistently lousy luck with Cygwin which has left a bad taste in
my mouth. Cygwin is generally a lot slower than Mingw, although that is
most noticeable when you're making extensive use of math.h. Also, it seems
that every time I install some package in Cygwin, something else I've
installed gets messed up. It just seems to me that there isn't any reason
for an efficient command-line tool like git to depend on a large
unmaintained project like Cygwin.
Of course, one could use -mno-cygwin (or whatever it is) to use the MinGW
headers when compiling in Cygwin as an intermediate step. That would give
any speed advantages.
However, I've had great luck porting Linux apps using the gcc toolchain to
Windows using MinGW. All these programs 'just worked'. However, none of
them really did things outside the realm of simple, portable C and Fortran.
Most of them have been old engineering analysis codes which have been ported
a dozen times in their life anyway.
Thanks for the comments. The best idea may be to just try it....
Rob
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.0.0b quickfix
From: Krzysztof Halasa @ 2005-12-24 12:21 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Junio C Hamano, Ingo Oeser, linux-kernel, Linus Torvalds,
Benjamin Herrenschmidt, H. Peter Anvin, git
In-Reply-To: <43AD2003.3060609@op5.se>
Andreas Ericsson <ae@op5.se> writes:
>> *1* Which one is the heaviest, 5h, 3kg, or 20cm?
>>
>
> 5h, without a doubt. Because time can be broken down into infinitely
> small pieces
This is uncertain. If the time is quantified 5 hrs might as well contain
much less quanta than 3 kg, let alone 20 cm :-)
--
Krzysztof Halasa
^ permalink raw reply
* [PATCH] add strcpy_user_path() and use it in init-db.c and git.c
From: Eric Wong @ 2005-12-24 12:20 UTC (permalink / raw)
To: git list
strcpy_user_path(dest,src) acts just like strcpy() except tildes
in src are expanded appropriately to point to a user's home
directory.
The following expansions are supported:
~user/path reads home directory from getpwnam()
~/path reads home directory from $HOME env,
or getpwuid() if $HOME is not set
This patch makes it easier for an ordinary user to share compiled
binaries across different machines, especially if they have different
account names and home directories on those machines.
Hint: build git with: make 'prefix=~'
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
cache.h | 1 +
git.c | 6 ++++++
init-db.c | 3 ++-
path.c | 41 +++++++++++++++++++++++++++++++++++++++++
4 files changed, 50 insertions(+), 1 deletions(-)
c46a17b746572e6d16aa026de50d7911eddf8664
diff --git a/cache.h b/cache.h
index c5ff4b7..041bf94 100644
--- a/cache.h
+++ b/cache.h
@@ -184,6 +184,7 @@ extern const unsigned char null_sha1[20]
int git_mkstemp(char *path, size_t n, const char *template);
+char * strcpy_user_path(char *dest, const char *path);
int safe_create_leading_directories(char *path);
char *safe_strncpy(char *, const char *, size_t);
char *enter_repo(char *path, int strict);
diff --git a/git.c b/git.c
index 434a3d9..15f4c69 100644
--- a/git.c
+++ b/git.c
@@ -12,6 +12,8 @@
#include <termios.h>
#include "git-compat-util.h"
+extern char * strcpy_user_path(char *dest, const char *path);
+
#ifndef PATH_MAX
# define PATH_MAX 4096
#endif
@@ -234,6 +236,7 @@ int main(int argc, char **argv, char **e
{
char git_command[PATH_MAX + 1];
char wd[PATH_MAX + 1];
+ char tmp[PATH_MAX + 1];
int i, len, show_help = 0;
char *exec_path = getenv("GIT_EXEC_PATH");
@@ -269,6 +272,9 @@ int main(int argc, char **argv, char **e
cmd_usage(NULL, NULL);
}
+ strcpy_user_path(tmp, exec_path);
+ exec_path = tmp;
+
if (i >= argc || show_help) {
if (i >= argc)
cmd_usage(exec_path, NULL);
diff --git a/init-db.c b/init-db.c
index ead37b5..468c93a 100644
--- a/init-db.c
+++ b/init-db.c
@@ -119,7 +119,8 @@ static void copy_templates(const char *g
if (!template_dir)
template_dir = DEFAULT_GIT_TEMPLATE_DIR;
- strcpy(template_path, template_dir);
+ strcpy_user_path(template_path, template_dir);
+
template_len = strlen(template_path);
if (template_path[template_len-1] != '/') {
template_path[template_len++] = '/';
diff --git a/path.c b/path.c
index 334b2bd..3caa188 100644
--- a/path.c
+++ b/path.c
@@ -131,6 +131,47 @@ int validate_symref(const char *path)
return -1;
}
+char * strcpy_user_path(char *dest, const char *path)
+{
+ if (path[0] == '~') {
+ struct passwd *pw;
+
+ if (path[1] == '/' || path[1] == '\0') {
+ char *home;
+
+ if (!(home = getenv("HOME"))) {
+ pw = getpwuid(getuid());
+ if (pw && pw->pw_dir)
+ home = pw->pw_dir;
+ }
+
+ strcpy(dest, home);
+
+ if (path[1] == '/')
+ strcat(dest, path + 1);
+ } else {
+ char *slash;
+
+ if ((slash = strchr(path,'/'))) {
+ memcpy(pathname, path + 1, slash - path - 1);
+ pathname[slash - path] = '\0';
+ pw = getpwnam(pathname);
+ } else
+ pw = getpwnam(path + 1);
+
+ if (pw && pw->pw_dir) {
+ strcpy(dest, pw->pw_dir);
+ if (slash)
+ strcat(dest,slash);
+ } else
+ strcpy(dest, path);
+ }
+ } else
+ strcpy(dest, path);
+
+ return dest;
+}
+
static char *user_path(char *buf, char *path, int sz)
{
struct passwd *pw;
--
1.0.GIT
^ permalink raw reply related
* [PATCH 4/4] git-compat-util.h: dietlibc-friendly x{malloc,realloc,calloc}
From: Eric Wong @ 2005-12-24 12:14 UTC (permalink / raw)
To: git list
In-Reply-To: <20051224121007.GA19136@mail.yhbt.net>
dietlibc versions of these allocators returns NULL if a size of zero is
specified. Obviously, this is a problem with the x* wrappers since
we check for them returning NULL.
Down the line, it'd be better to hunt down and eliminate all calls to
these functions when they are called with a zero argument. I've already
added some checks for these cases that were exposed by tests.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-compat-util.h | 23 ++++++++++++++++++++---
1 files changed, 20 insertions(+), 3 deletions(-)
113dca27f9f95a76a0f98929720f5f567c7586b2
diff --git a/git-compat-util.h b/git-compat-util.h
index 0c98c99..bd2f150 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -62,7 +62,12 @@ extern char *gitstrcasestr(const char *h
static inline void *xmalloc(size_t size)
{
- void *ret = malloc(size);
+ void *ret;
+
+ if (!size)
+ return NULL;
+
+ ret = malloc(size);
if (!ret)
die("Out of memory, malloc failed");
return ret;
@@ -70,7 +75,14 @@ static inline void *xmalloc(size_t size)
static inline void *xrealloc(void *ptr, size_t size)
{
- void *ret = realloc(ptr, size);
+ void *ret;
+
+ if (!size) {
+ free(ptr);
+ return NULL;
+ }
+
+ ret = realloc(ptr, size);
if (!ret)
die("Out of memory, realloc failed");
return ret;
@@ -78,7 +90,12 @@ static inline void *xrealloc(void *ptr,
static inline void *xcalloc(size_t nmemb, size_t size)
{
- void *ret = calloc(nmemb, size);
+ void *ret;
+
+ if (!nmemb || !size)
+ return NULL;
+
+ ret = calloc(nmemb, size);
if (!ret)
die("Out of memory, calloc failed");
return ret;
--
1.0.GIT
^ permalink raw reply related
* [PATCH 3/4] add xmktime() function that always accounts for the TZ env
From: Eric Wong @ 2005-12-24 12:13 UTC (permalink / raw)
To: git list
In-Reply-To: <20051224121007.GA19136@mail.yhbt.net>
This function was added because mktime in dietlibc doesn't seem to
account for the TZ env. Also, xmktime() now shares the same
always-summer bug TZ parsing elsewhere, so at least we can
be wrong about summer consistently.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
cache.h | 2 ++
convert-objects.c | 4 ++--
date.c | 30 ++++++++++++++++++++++++++----
3 files changed, 30 insertions(+), 6 deletions(-)
3b0763ae6fce6c69021e1216660f4c0ee301512b
diff --git a/cache.h b/cache.h
index cb87bec..c5ff4b7 100644
--- a/cache.h
+++ b/cache.h
@@ -5,6 +5,7 @@
#include SHA1_HEADER
#include <zlib.h>
+#include <time.h>
#if ZLIB_VERNUM < 0x1200
#define deflateBound(c,s) ((s) + (((s) + 7) >> 3) + (((s) + 63) >> 6) + 11)
@@ -236,6 +237,7 @@ extern void *read_object_with_reference(
const char *show_date(unsigned long time, int timezone);
int parse_date(const char *date, char *buf, int bufsize);
+time_t xmktime(struct tm *tm);
void datestamp(char *buf, int bufsize);
unsigned long approxidate(const char *);
diff --git a/convert-objects.c b/convert-objects.c
index b49bce2..0fe1229 100644
--- a/convert-objects.c
+++ b/convert-objects.c
@@ -178,7 +178,7 @@ static unsigned long parse_oldstyle_date
const char *next = strptime(buf, *fmt, &tm);
if (next) {
if (!*next)
- return mktime(&tm);
+ return xmktime(&tm);
buf = next;
} else {
const char **p = timezones;
@@ -195,7 +195,7 @@ static unsigned long parse_oldstyle_date
fmt++;
} while (*buf && *fmt);
printf("left: %s\n", buf);
- return mktime(&tm);
+ return xmktime(&tm);
}
static int convert_date_line(char *dst, void **buf, unsigned long *sp)
diff --git a/date.c b/date.c
index 3e11500..5596476 100644
--- a/date.c
+++ b/date.c
@@ -141,6 +141,28 @@ static int match_string(const char *date
return i;
}
+time_t xmktime(struct tm *tm)
+{
+ time_t ret = my_mktime(tm);
+ char * tz = getenv("TZ");
+
+ if (tz) {
+ int i;
+ for (i = 0; i < NR_TZ; i++) {
+ int match = match_string(tz, timezone_names[i].name);
+ if (match >= 3) {
+ int off = timezone_names[i].offset;
+
+ /* This is bogus, but we like summer */
+ off += timezone_names[i].dst;
+
+ ret += 60*off;
+ }
+ }
+ }
+ return ret;
+}
+
static int skip_alpha(const char *date)
{
int i = 0;
@@ -436,10 +458,10 @@ int parse_date(const char *date, char *r
date += match;
}
- /* mktime uses local timezone */
+ /* (x)mktime uses local timezone */
then = my_mktime(&tm);
if (offset == -1)
- offset = (then - mktime(&tm)) / 60;
+ offset = (then - xmktime(&tm)) / 60;
if (then == -1)
return -1;
@@ -464,7 +486,7 @@ void datestamp(char *buf, int bufsize)
static void update_tm(struct tm *tm, unsigned long sec)
{
- time_t n = mktime(tm) - sec;
+ time_t n = xmktime(tm) - sec;
localtime_r(&n, tm);
}
@@ -642,5 +664,5 @@ unsigned long approxidate(const char *da
tm.tm_mday = number;
if (tm.tm_mon > now.tm_mon)
tm.tm_year--;
- return mktime(&tm);
+ return xmktime(&tm);
}
--
1.0.GIT
^ permalink raw reply related
* [PATCH 2/4] short circuit out of a few places where we would allocate zero bytes
From: Eric Wong @ 2005-12-24 12:12 UTC (permalink / raw)
To: git list
In-Reply-To: <20051224121007.GA19136@mail.yhbt.net>
dietlibc versions of malloc, calloc and realloc all return NULL if
they're told to allocate 0 bytes, causes the x* wrappers to die().
There are several more places where these calls could end up asking
for 0 bytes, too...
Maybe simply not die()-ing in the x* wrappers if 0/NULL is returned
when the requested size is zero is a safer and easier way to go.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
commit.c | 3 +++
diffcore-rename.c | 2 +-
2 files changed, 4 insertions(+), 1 deletions(-)
ee9d90c652be126345dec2ac204284e80e685160
diff --git a/commit.c b/commit.c
index e867b86..edd4ded 100644
--- a/commit.c
+++ b/commit.c
@@ -560,6 +560,9 @@ void sort_in_topological_order(struct co
next = next->next;
count++;
}
+
+ if (!count)
+ return;
/* allocate an array to help sort the list */
nodes = xcalloc(count, sizeof(*nodes));
/* link the list to the array */
diff --git a/diffcore-rename.c b/diffcore-rename.c
index dba965c..39d9126 100644
--- a/diffcore-rename.c
+++ b/diffcore-rename.c
@@ -282,7 +282,7 @@ void diffcore_rename(struct diff_options
else if (detect_rename == DIFF_DETECT_COPY)
register_rename_src(p->one, 1);
}
- if (rename_dst_nr == 0 ||
+ if (rename_dst_nr == 0 || rename_src_nr == 0 ||
(0 < rename_limit && rename_limit < rename_dst_nr))
goto cleanup; /* nothing to do */
--
1.0.GIT
^ permalink raw reply related
* [PATCH 1/4] git.c: extra #include for dietlibc (and possibly other C libraries)
From: Eric Wong @ 2005-12-24 12:11 UTC (permalink / raw)
To: git list
In-Reply-To: <20051224121007.GA19136@mail.yhbt.net>
struct winsize is defined in <termios.h>, and that's not pulled
in by other #includes in that file
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
ae5641fcbc58509572d080c33a20c829b82ae9b0
diff --git a/git.c b/git.c
index e795ddb..434a3d9 100644
--- a/git.c
+++ b/git.c
@@ -9,6 +9,7 @@
#include <limits.h>
#include <stdarg.h>
#include <sys/ioctl.h>
+#include <termios.h>
#include "git-compat-util.h"
#ifndef PATH_MAX
--
1.0.GIT
^ permalink raw reply related
* [PATCH 0/4] dietlibc compatibility
From: Eric Wong @ 2005-12-24 12:10 UTC (permalink / raw)
To: git list
I've started statically-linking git binaries against dietlibc to avoid
having to recompile it for every machine/distro and chroot (lots!) I
would use it in.
For building git (on a Debian unstable system with dietlibc-dev),
I used the following make vars:
CC=diet -v gcc
NO_STRCASESTR=YesPlease
NO_SETENV=YesPlease
The dietlibc setenv() doesn't seem very nice to **envp in git.c,
resulting in $PATH being clobbered when it runs execve(). This
caused tests to fail. Fortunately, gitsetenv() saved the day.
The following patches fix other issues I had with dietlibc.
--
Eric Wong
^ permalink raw reply
* Re: Possibility of a MinGW version?
From: Andreas Ericsson @ 2005-12-24 10:24 UTC (permalink / raw)
To: skimo; +Cc: Rob McDonald, git
In-Reply-To: <20051224101849.GY1279MdfPADPa@greensroom.kotnet.org>
Sven Verdoolaege wrote:
> On Sat, Dec 24, 2005 at 11:09:39AM +0100, Andreas Ericsson wrote:
>
>>The worst trouble you're likely to run into is all the hardcoded paths.
>>They are everywhere and ofcourse use the / for path entity separation.
>
>
> AFAIR, '/' is a valid path separator on Windows.
> It's just command.com (does that still exist?) that insisted on '\\'
> separators.
>
Are you sure? I've seen lots of porting patches that transliterate those
to '\\'. Perhaps those who wrote those patches just took for granted
that it was needed, the same as I did.
>
>>The fact that there are 39 bash'ish shell-scripts does little to help a
>>native port, and although they can be fairly easily replaced by "real"
>>programs it still means quite a bit of work with little real value for
>>the unix-version, so I'm guessing you'll have to write those up for
>>yourself.
>
>
> Or just use MinGW's bash.
>
Didn't know it had one. Live and learn, I suppose. Good to know though.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Possibility of a MinGW version?
From: Sven Verdoolaege @ 2005-12-24 10:18 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Rob McDonald, git
In-Reply-To: <43AD1E63.4040103@op5.se>
On Sat, Dec 24, 2005 at 11:09:39AM +0100, Andreas Ericsson wrote:
> The worst trouble you're likely to run into is all the hardcoded paths.
> They are everywhere and ofcourse use the / for path entity separation.
AFAIR, '/' is a valid path separator on Windows.
It's just command.com (does that still exist?) that insisted on '\\'
separators.
> The fact that there are 39 bash'ish shell-scripts does little to help a
> native port, and although they can be fairly easily replaced by "real"
> programs it still means quite a bit of work with little real value for
> the unix-version, so I'm guessing you'll have to write those up for
> yourself.
Or just use MinGW's bash.
skimo
^ 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