* Re: [PATCH] Add .git/version
From: Josef Weidendorfer @ 2005-11-17 15:44 UTC (permalink / raw)
To: git; +Cc: Martin Atukunda, Junio C Hamano
In-Reply-To: <11322339372137-git-send-email-matlads@dsmagic.com>
On Thursday 17 November 2005 14:25, Martin Atukunda wrote:
> This patch series attempts to add .git/version support to init-db.c. THis
> is an overview of the patches.
As .git/version is part of the repository, it should contain the version
of the repository format used. Do you really want to link the version
of the repository format with the version of git which created the
repository? It think it is better to detach a repository version from
version of git.
Why? Ideally, the git commands first should check if they can handle the
repository format. If they can not handle the version, they should bail
out with an error [*]
Now suppose we want to release Git 2 without change the repository
format at all. Thus, even if Git 1 tool *would* work with repositories
created by Git 2, they will fail in the version check!
If this is meant to be used in scripts (as your commit comment mentions):
a script should never touch any files in the repository directly, but go
via commands supplied with git. So these scripts should actually check
against the version of installed git. Thus, such a version string should go
into git-var or better simply use the existing "git --version"?
Josef
[*] Junio: This should be done before Git 1.0 - it is needed to be able
to change the repository format in the future without taking the risk
that old git commands possibly corrupt a repo in the new format. This
has nothing to do with backwards compatibility. Without a version, we
are forced to be forwards compatible ;-)
Needed in init-db.c is a "echo 1 >.git/version"; and the mentioned check
in the tools against this version.
^ permalink raw reply
* "make test" fails with current HEAD
From: Matthias Urlichs @ 2005-11-17 15:31 UTC (permalink / raw)
To: git
t4103.sh:
fatal: patch with only garbage at line 30
* FAIL 7: check binary diff with replacement.
git-checkout master
git-apply --check --allow-binary-replacement BF.diff
May I suggest to please run "make test" before pushing? Thanks! ;-)
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
She balanced dignity on the tip of her nose.
^ permalink raw reply
* [PATCH] 'make clean' forgot about some files
From: Nicolas Pitre @ 2005-11-17 15:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Signed-off-by: Nicolas Pitre <nico@cam.org>
diff --git a/Makefile b/Makefile
index ebff990..3bdd059 100644
--- a/Makefile
+++ b/Makefile
@@ -466,7 +466,7 @@ deb: dist
### Cleaning rules
clean:
- rm -f *.o mozilla-sha1/*.o ppc/*.o compat/*.o $(PROGRAMS) $(LIB_FILE)
+ rm -f *.o mozilla-sha1/*.o arm/*.o ppc/*.o compat/*.o git $(PROGRAMS) $(LIB_FILE)
rm -f $(filter-out gitk,$(SCRIPTS))
rm -f *.spec *.pyc *.pyo
rm -rf $(GIT_TARNAME)
^ permalink raw reply related
* Re: [PATCH] Add .git/version
From: Johannes Schindelin @ 2005-11-17 15:38 UTC (permalink / raw)
To: Martin Atukunda; +Cc: git
In-Reply-To: <20051117151653.GB3626@igloo.ds.co.ug>
Hi,
On Thu, 17 Nov 2005, Martin Atukunda wrote:
> On Thu, Nov 17, 2005 at 02:39:21PM +0100, Johannes Schindelin wrote:
> >
> > I think you are more interested in knowing which version the tools are at.
>
> Actually this patch series is more a response to the thread
> "Re: [PATCH] Disable USE_SYMLINK_HEAD by default" in particular see
> this message 200511160205.43443.Josef.Weidendorfer@gmx.de by Josef
> Weidendorfer.
When we disable USE_SYMLINK_HEAD by default, tools are expected to work
with USE_SYMLINK_HEAD enabled, too, so .git/version is not needed for
that.
But yes, it might be handy to know at some time. But I think it would make
sense to add .git/version *then*, because you can distinguish repositories
before/after the change by testing for .git/version.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Add .git/version
From: Martin Atukunda @ 2005-11-17 15:16 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0511171436170.13358@wbgn013.biozentrum.uni-wuerzburg.de>
On Thu, Nov 17, 2005 at 02:39:21PM +0100, Johannes Schindelin wrote:
> Hi,
>
> On Thu, 17 Nov 2005, Martin Atukunda wrote:
>
> > This patch series attempts to add .git/version support to init-db.c.
>
> Wouldn't it make more sense to add the variable VERSION to git-var? After
> all, git is designed to be backwards compatible; newer versions are
> supposed to work with ancient repositories.
>
> I think you are more interested in knowing which version the tools are at.
Actually this patch series is more a response to the thread
"Re: [PATCH] Disable USE_SYMLINK_HEAD by default" in particular see
this message 200511160205.43443.Josef.Weidendorfer@gmx.de by Josef
Weidendorfer.
We've had at least one change that was backwards incompatible, though
this was in the ancient days of git development. This patch allows git to record what
version of the git tools created the repo we are dealing with. Just in
case future changes require this.
- Martin -
--
Due to a shortage of devoted followers, the production of great leaders has been discontinued.
^ permalink raw reply
* Problem with cg-update
From: Nico -telmich- Schottelius @ 2005-11-17 15:16 UTC (permalink / raw)
To: GIT ML
[-- Attachment #1: Type: text/plain, Size: 381 bytes --]
Hello!
I tried an update which failed and then to commit which failed [0].
Could someone tell me what would be the correct way now?
Nico
[0]: The log:
http://creme.schottelius.org/~nico/linux/debug/git/update-local_changes_commit
--
Latest project: cinit-0.2.1 (http://linux.schottelius.org/cinit/)
Open Source nutures open minds and free, creative developers.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 827 bytes --]
^ permalink raw reply
* [PATCH] git-repack: Fix variable name
From: Ralf Baechle @ 2005-11-17 14:34 UTC (permalink / raw)
To: git
Three times remove_redandant -> remove_redundant.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Index: git.git/git-repack.sh
===================================================================
--- git.git.orig/git-repack.sh
+++ git.git/git-repack.sh
@@ -11,7 +11,7 @@ do
case "$1" in
-n) no_update_info=t ;;
-a) all_into_one=t ;;
- -d) remove_redandant=t ;;
+ -d) remove_redundant=t ;;
-l) local=t ;;
*) break ;;
esac
@@ -42,7 +42,7 @@ name=$(git-rev-list --objects $rev_list
exit 1
if [ -z "$name" ]; then
echo Nothing new to pack.
- if test "$remove_redandant" = t ; then
+ if test "$remove_redundant" = t ; then
echo "Removing redundant packs."
sync
redundant=$(git-pack-redundant --all)
@@ -60,7 +60,7 @@ mv .tmp-pack-$name.pack "$PACKDIR/pack-$
mv .tmp-pack-$name.idx "$PACKDIR/pack-$name.idx" ||
exit
-if test "$remove_redandant" = t
+if test "$remove_redundant" = t
then
sync
redundant=$(git-pack-redundant --all)
^ permalink raw reply
* Re: git and cogito update, gitweb problem
From: Nico -telmich- Schottelius @ 2005-11-17 14:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvez0z8yj.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 145 bytes --]
Junio C Hamano [Thu, Nov 10, 2005 at 09:52:36AM -0800]:
> [...]
> I think this minimally should fix it [...]
Will try that the next days!
Nico
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 827 bytes --]
^ permalink raw reply
* BUG: 'make clean; make' won't rebuilt 'git'
From: Wayne Scott @ 2005-11-17 13:58 UTC (permalink / raw)
To: git
The 'make clean' target doesn't remove the 'git' application and since
the 'git' make target depends on git.c directly it won't get rebuilt
after a clean.
The net result is that if you do:
make
make clean
make prefix=/usr/local
make prefix=/usr/local install
it won't install the correct git binary.
-Wayne
^ permalink raw reply
* Re: [PATCH] Add .git/version
From: Johannes Schindelin @ 2005-11-17 13:39 UTC (permalink / raw)
To: Martin Atukunda; +Cc: git
In-Reply-To: <11322339372137-git-send-email-matlads@dsmagic.com>
Hi,
On Thu, 17 Nov 2005, Martin Atukunda wrote:
> This patch series attempts to add .git/version support to init-db.c.
Wouldn't it make more sense to add the variable VERSION to git-var? After
all, git is designed to be backwards compatible; newer versions are
supposed to work with ancient repositories.
I think you are more interested in knowing which version the tools are at.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Add .git/version
From: Martin Atukunda @ 2005-11-17 13:25 UTC (permalink / raw)
To: git
This patch series attempts to add .git/version support to init-db.c. THis
is an overview of the patches.
First patch makes the Makefile build GIT_VERSION from the variables VERSION,
PATCHLEVEL, and SUBLEVEL ala the kernel. These variables will be used later
in init-db.c
Second patch adds support to init-db.c for writing the .git/version file.
- Martin -
^ permalink raw reply
* [PATCH 1/2] Build GIT_VERSION from VERSION, PATCHLEVEL, and SUBLEVEL variables.
From: Martin Atukunda @ 2005-11-17 13:25 UTC (permalink / raw)
To: git; +Cc: Martin Atukunda
In-Reply-To: <11322339372137-git-send-email-matlads@dsmagic.com>
This will allow scripts to be able to determine which git release they
target (or require).
Signed-Off-By: Martin Atukunda <matlads@dsmagic.com>
---
Makefile | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
applies-to: 1e3fcf60526c196a46433e6947c9104ca236f230
968e5b59fba66a1b146c643e5161978c787d4273
diff --git a/Makefile b/Makefile
index ebff990..74c6b9e 100644
--- a/Makefile
+++ b/Makefile
@@ -50,7 +50,11 @@
# 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 = 0.99.9.GIT
+VERSION = 0
+PATCHLEVEL = 99
+SUBLEVEL = 9
+EXTRAVERSION = GIT
+GIT_VERSION=$(VERSION).$(PATCHLEVEL).$(SUBLEVEL).$(EXTRAVERSION)
# CFLAGS and LDFLAGS are for the users to override from the command line.
---
0.99.9.GIT
^ permalink raw reply related
* [PATCH 2/2] Make init-db record the version in $GIT_DIR/version when creating repo.
From: Martin Atukunda @ 2005-11-17 13:25 UTC (permalink / raw)
To: git; +Cc: Martin Atukunda
In-Reply-To: <11322339373013-git-send-email-matlads@dsmagic.com>
Signed-Off-By: Martin Atukunda <matlads@dsmagic.com>
---
Makefile | 3 +++
init-db.c | 15 +++++++++++++++
2 files changed, 18 insertions(+), 0 deletions(-)
applies-to: ec55de586902d26b3f55c3d0aeabf94be1b82586
ec733719bfee2ade91416bd429eeefe6c4acb5a8
diff --git a/Makefile b/Makefile
index 74c6b9e..c167120 100644
--- a/Makefile
+++ b/Makefile
@@ -400,6 +400,9 @@ git-rev-list$X: LIBS += $(OPENSSL_LIBSSL
init-db.o: init-db.c
$(CC) -c $(ALL_CFLAGS) \
+ -DVERSION='"$(VERSION)"' \
+ -DPATCHLEVEL='"$(PATCHLEVEL)"' \
+ -DSUBLEVEL='"$(SUBLEVEL)"' \
-DDEFAULT_GIT_TEMPLATE_DIR=$(call shellquote,"$(template_dir)") $*.c
$(LIB_OBJS): $(LIB_H)
diff --git a/init-db.c b/init-db.c
index bd88291..6230e8e 100644
--- a/init-db.c
+++ b/init-db.c
@@ -19,6 +19,17 @@ static void safe_create_dir(const char *
}
}
+static void record_repo_version(const char *path)
+{
+ FILE *verfile = fopen(path, "w");
+ if (!verfile)
+ die ("Can not write to %s?", path);
+
+ fprintf(verfile, "%d.%d.%d\n", VERSION, PATCHLEVEL, SUBLEVEL);
+
+ fclose(verfile);
+}
+
static int copy_file(const char *dst, const char *src, int mode)
{
int fdi, fdo, status;
@@ -212,6 +223,10 @@ static void create_default_files(const c
fprintf(stderr, "Ignoring file modes\n");
}
}
+
+ /* record the version of the git repo */
+ strcpy(path + len, "version");
+ record_repo_version(path);
}
static const char init_db_usage[] =
---
0.99.9.GIT
^ permalink raw reply related
* [PATCH] Make git-pack-redundant non-horribly slow on large sets of packs
From: Lukas Sandström @ 2005-11-17 13:11 UTC (permalink / raw)
To: git; +Cc: Alex Riesen, junkio, Lukas Sandström
In-Reply-To: <20051115223340.GA3951@steel.home>
Change the smallest-set detection algortithm so that when
we have found a good set, we don't check any larger sets.
Signed-off-by: Lukas Sandström <lukass@etek.chalmers.se>
---
This change might make git-pack-redundant return non-optimal
pack-sets in some cases. OTOH, the case which Alex reported
completes in 0.6 sec instead of several minutes.
pack-redundant.c | 62 +++++++++++++++++++++++++++++++++++++++++++-----------
1 files changed, 49 insertions(+), 13 deletions(-)
applies-to: 1e3fcf60526c196a46433e6947c9104ca236f230
498cc056d758b9e1cd21e984be281d55e24f1117
diff --git a/pack-redundant.c b/pack-redundant.c
index fcb36ff..51d7341 100644
--- a/pack-redundant.c
+++ b/pack-redundant.c
@@ -33,6 +33,7 @@ struct pack_list {
struct pll {
struct pll *next;
struct pack_list *pl;
+ size_t pl_size;
};
inline void llist_free(struct llist *list)
@@ -249,18 +250,45 @@ void cmp_two_packs(struct pack_list *p1,
}
}
+void pll_insert(struct pll **pll, struct pll **hint_table)
+{
+ struct pll *prev;
+ int i = (*pll)->pl_size - 1;
+
+ if (hint_table[i] == NULL) {
+ hint_table[i--] = *pll;
+ for (; i >= 0; --i) {
+ if (hint_table[i] != NULL)
+ break;
+ }
+ if (hint_table[i] == NULL) /* no elements in list */
+ die("Why did this happen?");
+ }
+
+ prev = hint_table[i];
+ while (prev->next && prev->next->pl_size < (*pll)->pl_size)
+ prev = prev->next;
+
+ (*pll)->next = prev->next;
+ prev->next = *pll;
+}
+
/* all the permutations have to be free()d at the same time,
* since they refer to each other
*/
struct pll * get_all_permutations(struct pack_list *list)
{
struct pll *subset, *pll, *new_pll = NULL; /*silence warning*/
-
+ static struct pll **hint = NULL;
+ if (hint == NULL)
+ hint = xcalloc(pack_list_size(list), sizeof(struct pll *));
+
if (list == NULL)
return NULL;
if (list->next == NULL) {
new_pll = xmalloc(sizeof(struct pll));
+ hint[0] = new_pll;
new_pll->next = NULL;
new_pll->pl = list;
return new_pll;
@@ -268,24 +296,30 @@ struct pll * get_all_permutations(struct
pll = subset = get_all_permutations(list->next);
while (pll) {
+ if (pll->pl->pack == list->pack) {
+ pll = pll->next;
+ continue;
+ }
new_pll = xmalloc(sizeof(struct pll));
- new_pll->next = pll->next;
- pll->next = new_pll;
new_pll->pl = xmalloc(sizeof(struct pack_list));
memcpy(new_pll->pl, list, sizeof(struct pack_list));
new_pll->pl->next = pll->pl;
+ new_pll->pl_size = pll->pl_size + 1;
+
+ pll_insert(&new_pll, hint);
+
+ pll = pll->next;
+ }
+ /* add ourself */
+ new_pll = xmalloc(sizeof(struct pll));
+ new_pll->pl = xmalloc(sizeof(struct pack_list));
+ memcpy(new_pll->pl, list, sizeof(struct pack_list));
+ new_pll->pl->next = NULL;
+ new_pll->pl_size = 1;
+ pll_insert(&new_pll, hint);
- pll = new_pll->next;
- }
- /* add ourself to the end */
- new_pll->next = xmalloc(sizeof(struct pll));
- new_pll->next->pl = xmalloc(sizeof(struct pack_list));
- new_pll->next->next = NULL;
- memcpy(new_pll->next->pl, list, sizeof(struct pack_list));
- new_pll->next->pl->next = NULL;
-
- return subset;
+ return hint[0];
}
int is_superset(struct pack_list *pl, struct llist *list)
@@ -401,6 +435,8 @@ void minimize(struct pack_list **min)
/* find the permutations which contain all missing objects */
perm_all = perm = get_all_permutations(non_unique);
while (perm) {
+ if (perm_ok && perm->pl_size > perm_ok->pl_size)
+ break; /* ignore all larger permutations */
if (is_superset(perm->pl, missing)) {
new_perm = xmalloc(sizeof(struct pll));
new_perm->pl = perm->pl;
---
0.99.9.GIT
^ permalink raw reply related
* Re: master has some toys
From: Alex Riesen @ 2005-11-17 12:40 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0511171249550.737@wbgn013.biozentrum.uni-wuerzburg.de>
On 11/17/05, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > It appears we'd better have something like this in the main
> > Makefile, so people do not have to do it themselves everywhere?
>
> I'd like to wait to have a reaction from other people. I vividly remember
> my eyes falling out of my sockets when somebody reported success on cygwin
> without NO_MMAP. If there is *any* cygwin version which fixes it, we
> should rather make people upgrade, no?
my eyes too. I used to compile Peters tree, and it never worked (w2k,
antivirus present, but self-disabled because of some lucky crash).
That is why the whole story started (and I started to look for
unclosed files and unmapped maps).
^ permalink raw reply
* Re: A case for tailor
From: Johannes Schindelin @ 2005-11-17 12:02 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: git
In-Reply-To: <pan.2005.11.16.23.40.20.119887@smurf.noris.de>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1226 bytes --]
Hi,
On Thu, 17 Nov 2005, Matthias Urlichs wrote:
> Hi, Johannes Schindelin wrote:
>
> > Possible explanation: at some early stage, the trunk was named "trunk",
> > but somehow (don´t ask me how, I am a fan of git, not svn) renamed to
> > "head".
>
> Well, you *could* use "-T trunk" to import the first part, ^C when it
> starts complaining about 'head', duplicate the last line of .git/svn2git
> (incrementing the SVN change number), and continue with "-T head".
>
> That hackery sortof depends on Upstream not changing anything *else* while
> renaming 'trunk' to 'head' ...
>
> Of course, the second possibility is to allow patterns as prefixes, drop
> the distinction of "trunk" and "branch", and store the refs as full
> paths under .git/refs/heads/**. You're welcome to submit a patch; please
> don't forget backwards compatibility for those poor souls who need to do
> incremental imports. ;-)
;-), too.
It is not *that* important for me, as that particular project is linear.
It is not even important to convert it to git, but I like to pickaxe the
source (why not let the machine do the work for you?).
So I will probably not work on svn->git end any more...
Ciao,
Dscho
^ permalink raw reply
* Re: recent patch breaks the build ?
From: Johannes Schindelin @ 2005-11-17 12:00 UTC (permalink / raw)
To: Andrew Wozniak; +Cc: git
In-Reply-To: <437B6997.8010903@mc.com>
Hi,
On Wed, 16 Nov 2005, Andrew Wozniak wrote:
> It appears that a recent patch "Fix for multiple alternates requests in
> http" references curlm without the necessary #ifdef USE_CURL_MULTI
Note that I had no success making http-fetch work without USE_CURL_MULTI.
So maybe you can compile it, but maybe you experience the same problems as
I had.
Hth,
Dscho
^ permalink raw reply
* Re: master has some toys
From: Johannes Schindelin @ 2005-11-17 11:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, git
In-Reply-To: <7vsltvwmlr.fsf@assigned-by-dhcp.cox.net>
Hi,
On Thu, 17 Nov 2005, Junio C Hamano wrote:
> It appears we'd better have something like this in the main
> Makefile, so people do not have to do it themselves everywhere?
I'd like to wait to have a reaction from other people. I vividly remember
my eyes falling out of my sockets when somebody reported success on cygwin
without NO_MMAP. If there is *any* cygwin version which fixes it, we
should rather make people upgrade, no?
Ciao,
Dscho
^ permalink raw reply
* Re: master has some toys
From: Johannes Schindelin @ 2005-11-17 11:22 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, git
In-Reply-To: <81b0412b0511170236r28572db9i84dc271700ded79a@mail.gmail.com>
Hi,
On Thu, 17 Nov 2005, Alex Riesen wrote:
> As it turned out, not the git.c is guilty, but the missing
> NO_MMAP=YesPlease in Cygwin section. I had it for a long time and
> accidentally removed by the recent pull. BTW, I couldn't find nowhere
> on original branch. Was it never submitted?
It was not, because someone (Peter?) had success without NO_MMAP=YesPlease
on cygwin. So it was decided to keep NO_MMAP an option which has to be
provided by the user.
> > Ideally I should get a cygwin environment myself, but for that
> > first I need to procure Windows box. Or does cygwin run on
> > Wine, and if so is cygwin running on Wine a good enough
> > approximation of the real thing?
It does not. The problem with mmap is a problem which stems from working
around Windows not being POSIX. Also note that the problem goes poof in a
gdb session. I tend to think it is a timing problem in conjunction with
the (very conservative) Antivirus setting.
Ciao,
Dscho
^ permalink raw reply
* Re: master has some toys
From: Alex Riesen @ 2005-11-17 11:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vsltvwmlr.fsf@assigned-by-dhcp.cox.net>
On 11/17/05, Junio C Hamano <junkio@cox.net> wrote:
> >> > Along with the git wrapper fixes and git-apply bugfix (it did
> >>
> >> cygwin is completely broken. Still debugging, but it looks like the
> >> old "windows can't unlink/rename open files" problem.
> >
> > FWIW I had no problems on cygwin (NO_MMAP=YesPlease).
>
> It appears we'd better have something like this in the main
> Makefile, so people do not have to do it themselves everywhere?
damn... Missed by 4 minutes... :)
^ permalink raw reply
* Re: master has some toys
From: Alex Riesen @ 2005-11-17 11:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0511171207580.20898@wbgn013.biozentrum.uni-wuerzburg.de>
[-- Attachment #1: Type: text/plain, Size: 408 bytes --]
On 11/17/05, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > Along with the git wrapper fixes and git-apply bugfix (it did
> >
> > cygwin is completely broken. Still debugging, but it looks like the
> > old "windows can't unlink/rename open files" problem.
>
> FWIW I had no problems on cygwin (NO_MMAP=YesPlease).
>
yes, that's what I had, too. Junio, how about the attached patch?
[-- Attachment #2: cygwin-has-no-mmap.patch --]
[-- Type: application/xxxxx, Size: 294 bytes --]
^ permalink raw reply
* Re: master has some toys
From: Junio C Hamano @ 2005-11-17 11:16 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Alex Riesen, git
In-Reply-To: <Pine.LNX.4.63.0511171207580.20898@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Thu, 17 Nov 2005, Alex Riesen wrote:
>
>> On 11/17/05, Junio C Hamano <junkio@cox.net> wrote:
>> > Along with the git wrapper fixes and git-apply bugfix (it did
>>
>> cygwin is completely broken. Still debugging, but it looks like the
>> old "windows can't unlink/rename open files" problem.
>
> FWIW I had no problems on cygwin (NO_MMAP=YesPlease).
It appears we'd better have something like this in the main
Makefile, so people do not have to do it themselves everywhere?
---
diff --git a/Makefile b/Makefile
index 7ce62e8..93d51c6 100644
--- a/Makefile
+++ b/Makefile
@@ -213,6 +213,7 @@ endif
ifeq ($(uname_O),Cygwin)
NO_STRCASESTR = YesPlease
NEEDS_LIBICONV = YesPlease
+ NO_MMAP = YesPlease
NO_IPV6 = YesPlease
X = .exe
endif
^ permalink raw reply related
* Re: recent patch breaks the build ?
From: Johannes Schindelin @ 2005-11-17 11:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nick Hengeveld, git
In-Reply-To: <7voe4jy36p.fsf@assigned-by-dhcp.cox.net>
Hi,
On Thu, 17 Nov 2005, Junio C Hamano wrote:
> Nick Hengeveld <nickh@reactrix.com> writes:
>
> > Assuming --vernum does work, is there a reasonable/portable way to
> > compare two hex values like 070801?
>
> I would assume that it is always 6 lowercase hexdigits %06x when
> supported, or showing nothing to stdout for ancient ones.
>
> A horrible but probably portable way would be:
>
> case `(echo 070801; curl-config --vernum) 2>/dev/null |
> sort -r | sed -ne 2p` in
> 070801)
> echo Happy ;;
> *)
> echo Sad ;;
> esac
Horrible to read, but actually portable (and can be produced by a small
script):
case "$NUMBER" in
07080[1-9] | \
0708[1-9]? | \
0709?? | \
07[1-9]??? | \
0[8-9]???? | \
[1-9]?????) echo "Yes";;
*) echo "No";;
esac
Ciao,
Dscho
^ permalink raw reply
* Re: master has some toys
From: Johannes Schindelin @ 2005-11-17 11:08 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, git
In-Reply-To: <81b0412b0511170029xac34cdbtddf74eb766281b3c@mail.gmail.com>
Hi,
On Thu, 17 Nov 2005, Alex Riesen wrote:
> On 11/17/05, Junio C Hamano <junkio@cox.net> wrote:
> > Along with the git wrapper fixes and git-apply bugfix (it did
>
> cygwin is completely broken. Still debugging, but it looks like the
> old "windows can't unlink/rename open files" problem.
FWIW I had no problems on cygwin (NO_MMAP=YesPlease).
Ciao,
Dscho
^ permalink raw reply
* Re: master has some toys
From: Junio C Hamano @ 2005-11-17 11:03 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0511170236r28572db9i84dc271700ded79a@mail.gmail.com>
Alex Riesen <raa.lkml@gmail.com> writes:
> As it turned out, not the git.c is guilty, but the missing
> NO_MMAP=YesPlease in Cygwin section. I had it for a long time and
> accidentally removed by the recent pull. BTW, I couldn't find nowhere
> on original branch. Was it never submitted?
Neither 'git-whatchanged Makefile' nor 'git-whatchanged
-SNO_MMAP Makefile' reports such on my end. Do we need one?
Johannes said he tests on Cygwin as well, and I am sure there
are others with Cygin on the list. Help us out here please?
^ 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