* Re: [PATCH] MSVC: Windows-native implementation for subset of Pthreads API
From: Nicolas Pitre @ 2009-11-05 0:22 UTC (permalink / raw)
To: Andrzej K. Haczewski; +Cc: git, Johannes Sixt
In-Reply-To: <4AF214D5.6050202@gmail.com>
On Thu, 5 Nov 2009, Andrzej K. Haczewski wrote:
> @@ -1638,6 +1657,8 @@ static void ll_find_deltas(struct object_entry **list, unsigned list_size,
> delta_search_threads);
> p = xcalloc(delta_search_threads, sizeof(*p));
>
> + init_threaded_search();
Careful. At the beginning of the function you'll find:
if (delta_search_threads <= 1) {
find_deltas(list, &list_size, window, depth, processed);
return;
}
That is, if we have thread support compiled in but we're told to use
only one thread, then the bulk of the work splitting is bypassed
entirely. Inside find_deltas() there will still be pthread_mutex_lock()
and pthread_mutex_unlock() calls even if no threads are spawned.
Nicolas
^ permalink raw reply
* Re: [PATCH v2 11/13] Allow helpers to request the path to the .git directory
From: Sverre Rabbelier @ 2009-11-05 0:15 UTC (permalink / raw)
To: Junio C Hamano
Cc: Daniel Barkalow, Git List, Johannes Schindelin, Johan Herland
In-Reply-To: <7vd43xg7lf.fsf@alter.siamese.dyndns.org>
Heya,
On Thu, Nov 5, 2009 at 01:04, Junio C Hamano <gitster@pobox.com> wrote:
> What do you mean by <alias> here? Is it the <alias> in
>
> [remote "alias"]
> url = hg::http://some.where/repo/sito/ry.hg
Yes, that one.
> IOW, can a user ever use the foreign interface directly from the command
> line, without ever defining such entries in .git/config, perhaps using
> "git remote"?
No, my primary use case for remote helpers is currently 'git clone
hg::https://soc.googlecode.com/hg/', and to have 'git fetch origin'
Just Work (tm) from that clone. My secondary use case though, is to
support 'git fetch hg:: https://soc.googlecode.com/hg/' just as well
and have 'git log FETCH_HEAD' Just Work (tm) too. In that light
.git/info/remote-<vcs>/ is probably a better idea, so that the helper
can use say '.git/info/remote-<vcs>/fetch/ for one-time fetches.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH v2 11/13] Allow helpers to request the path to the .git directory
From: Junio C Hamano @ 2009-11-05 0:04 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Daniel Barkalow, Git List, Johannes Schindelin, Johan Herland
In-Reply-To: <fabb9a1e0911041406tce0956ai2ad3fe6cfbdc546d@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
>> In any case, I think it would be good to have
>> something like that, but I think maybe we should tell it where it can put
>> its status files, rather than telling it where the .git dir is.
>
> Yes, that would probably be a good idea, .git/info/remote-<vcs>/<alias> perhaps?
What do you mean by <alias> here? Is it the <alias> in
[remote "alias"]
url = hg::http://some.where/repo/sito/ry.hg
IOW, can a user ever use the foreign interface directly from the command
line, without ever defining such entries in .git/config, perhaps using
"git remote"?
^ permalink raw reply
* Re: thoughts on setting core.logAllRefUpdates default true for bare repos
From: Sverre Rabbelier @ 2009-11-04 23:59 UTC (permalink / raw)
To: Nicolas Sebrecht; +Cc: Sitaram Chamarty, Johannes Schindelin, git
In-Reply-To: <20091104235241.GA12984@vidovic>
Heya,
On Thu, Nov 5, 2009 at 00:52, Nicolas Sebrecht <nicolas.s.dev@gmx.fr> wrote:
> Or did you mean if "non-admin users could" ?
We're talking about the case wherein a confidential object is pruned,
regardless of whether it is a non-admin or admin user doing the
pruning, they should be able to 'reflog expire' if they can 'git gc'.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] MSVC: Windows-native implementation for subset of Pthreads API
From: Junio C Hamano @ 2009-11-04 23:58 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Andrzej K. Haczewski, git, Johannes Sixt
In-Reply-To: <alpine.LFD.2.00.0911041247250.10340@xanadu.home>
Nicolas Pitre <nico@fluxnic.net> writes:
> On Wed, 4 Nov 2009, Andrzej K. Haczewski wrote:
>
>> + NO_STATIC_PTHREADS_INIT = YesPlease
>
> Let's not go that route please. If Windows can't get away without
> runtime initializations then let's use them on all platforms. There is
> no gain in exploding the code path combinations here wrt testing
> coverage.
Hear hear.
^ permalink raw reply
* [PATCH] MSVC: Windows-native implementation for subset of Pthreads API
From: Andrzej K. Haczewski @ 2009-11-04 23:57 UTC (permalink / raw)
Cc: git, Nicolas Pitre, Johannes Sixt
In-Reply-To: <4AF21283.3080407@gmail.com>
This patch implements native to Windows subset of pthreads API used by Git.
It allows to remove Pthreads for Win32 dependency for msysgit and cygwin.
The patch modifies Makefile only for MSVC (that's the environment I'm
capable of testing on), so it requires further corrections to compile
with MinGW or Cygwin.
Signed-off-by: Andrzej K. Haczewski <ahaczewski@gmail.com>
---
Ignore previous patch, there was a compile error for POSIX platform
(pthread_mutex_init takes 2 arguments, MSVC doesn't complain if
1 argument is supplied to a macro call, but on POSIX it's function
call).
I haven't integrated Nicolas patch.
Makefile | 4 +-
builtin-pack-objects.c | 34 ++++++++++--
compat/mingw.c | 2 +-
compat/mingw.h | 5 ++
compat/win32/pthread.h | 132 ++++++++++++++++++++++++++++++++++++++++++++++++
git-compat-util.h | 10 ++++
preload-index.c | 4 +-
7 files changed, 180 insertions(+), 11 deletions(-)
create mode 100644 compat/win32/pthread.h
diff --git a/Makefile b/Makefile
index 94d44b0..0146ac7 100644
--- a/Makefile
+++ b/Makefile
@@ -975,7 +975,7 @@ ifdef MSVC
OBJECT_CREATION_USES_RENAMES = UnfortunatelyNeedsTo
NO_REGEX = YesPlease
NO_CURL = YesPlease
- NO_PTHREADS = YesPlease
+ THREADED_DELTA_SEARCH = YesPlease
BLK_SHA1 = YesPlease
CC = compat/vcbuild/scripts/clink.pl
@@ -983,7 +983,7 @@ ifdef MSVC
CFLAGS =
BASIC_CFLAGS = -nologo -I. -I../zlib -Icompat/vcbuild -Icompat/vcbuild/include -DWIN32 -D_CONSOLE -DHAVE_STRING_H -D_CRT_SECURE_NO_WARNINGS -D_CRT_NONSTDC_NO_DEPRECATE
COMPAT_OBJS = compat/msvc.o compat/fnmatch/fnmatch.o compat/winansi.o
- COMPAT_CFLAGS = -D__USE_MINGW_ACCESS -DNOGDI -DHAVE_STRING_H -DHAVE_ALLOCA_H -Icompat -Icompat/fnmatch -Icompat/regex -Icompat/fnmatch -DSTRIP_EXTENSION=\".exe\"
+ COMPAT_CFLAGS = -D__USE_MINGW_ACCESS -DNOGDI -DHAVE_STRING_H -DHAVE_ALLOCA_H -Icompat -Icompat/fnmatch -Icompat/regex -Icompat/fnmatch -Icompat/win32 -DSTRIP_EXTENSION=\".exe\"
BASIC_LDFLAGS = -IGNORE:4217 -IGNORE:4049 -NOLOGO -SUBSYSTEM:CONSOLE -NODEFAULTLIB:MSVCRT.lib
EXTLIBS = advapi32.lib shell32.lib wininet.lib ws2_32.lib
lib =
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 02f9246..e897b16 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -1255,15 +1255,15 @@ static int delta_cacheable(unsigned long src_size, unsigned long trg_size,
#ifdef THREADED_DELTA_SEARCH
-static pthread_mutex_t read_mutex = PTHREAD_MUTEX_INITIALIZER;
+static pthread_mutex_t read_mutex;
#define read_lock() pthread_mutex_lock(&read_mutex)
#define read_unlock() pthread_mutex_unlock(&read_mutex)
-static pthread_mutex_t cache_mutex = PTHREAD_MUTEX_INITIALIZER;
+static pthread_mutex_t cache_mutex;
#define cache_lock() pthread_mutex_lock(&cache_mutex)
#define cache_unlock() pthread_mutex_unlock(&cache_mutex)
-static pthread_mutex_t progress_mutex = PTHREAD_MUTEX_INITIALIZER;
+static pthread_mutex_t progress_mutex;
#define progress_lock() pthread_mutex_lock(&progress_mutex)
#define progress_unlock() pthread_mutex_unlock(&progress_mutex)
@@ -1590,9 +1590,28 @@ struct thread_params {
unsigned *processed;
};
-static pthread_cond_t progress_cond = PTHREAD_COND_INITIALIZER;
+static pthread_cond_t progress_cond;
-static void *threaded_find_deltas(void *arg)
+/*
+ * Mutex and conditional variable can't be statically-initialized on Windows.
+ */
+static void init_threaded_search()
+{
+ pthread_mutex_init(&read_mutex, NULL);
+ pthread_mutex_init(&cache_mutex, NULL);
+ pthread_mutex_init(&progress_mutex, NULL);
+ pthread_cond_init(&progress_cond, NULL);
+}
+
+static void cleanup_threaded_search()
+{
+ pthread_cond_destroy(&progress_cond);
+ pthread_mutex_destroy(&read_mutex);
+ pthread_mutex_destroy(&cache_mutex);
+ pthread_mutex_destroy(&progress_mutex);
+}
+
+static THREAD_RET_TYPE threaded_find_deltas(void *arg)
{
struct thread_params *me = arg;
@@ -1620,7 +1639,7 @@ static void *threaded_find_deltas(void *arg)
pthread_mutex_unlock(&me->mutex);
}
/* leave ->working 1 so that this doesn't get more work assigned */
- return NULL;
+ return 0;
}
static void ll_find_deltas(struct object_entry **list, unsigned list_size,
@@ -1638,6 +1657,8 @@ static void ll_find_deltas(struct object_entry **list, unsigned list_size,
delta_search_threads);
p = xcalloc(delta_search_threads, sizeof(*p));
+ init_threaded_search();
+
/* Partition the work amongst work threads. */
for (i = 0; i < delta_search_threads; i++) {
unsigned sub_size = list_size / (delta_search_threads - i);
@@ -1745,6 +1766,7 @@ static void ll_find_deltas(struct object_entry **list, unsigned list_size,
active_threads--;
}
}
+ cleanup_threaded_search();
free(p);
}
diff --git a/compat/mingw.c b/compat/mingw.c
index 6b5b5b2..f2e9f02 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -5,7 +5,7 @@
#include <shellapi.h>
-static int err_win_to_posix(DWORD winerr)
+int err_win_to_posix(DWORD winerr)
{
int error = ENOSYS;
switch(winerr) {
diff --git a/compat/mingw.h b/compat/mingw.h
index 6907345..7e25fb5 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -294,3 +294,8 @@ struct mingw_dirent
#define readdir(x) mingw_readdir(x)
struct dirent *mingw_readdir(DIR *dir);
#endif // !NO_MINGW_REPLACE_READDIR
+
+/*
+ * Used by Pthread API implementation for Windows
+ */
+extern int err_win_to_posix(DWORD winerr);
diff --git a/compat/win32/pthread.h b/compat/win32/pthread.h
new file mode 100644
index 0000000..0e43714
--- /dev/null
+++ b/compat/win32/pthread.h
@@ -0,0 +1,132 @@
+/*
+ * Header used to adapt pthread-based POSIX code to Windows API threads.
+ *
+ * Copyright (C) 2009 Andrzej K. Haczewski <ahaczewski@gmail.com>
+ */
+
+#ifndef PTHREAD_H
+#define PTHREAD_H
+
+#ifndef WIN32_LEAN_AND_MEAN
+#define WIN32_LEAN_AND_MEAN
+#endif
+
+#include <windows.h>
+
+/*
+ * Implement simple condition variable for Windows threads, based on ACE
+ * implementation.
+ *
+ * See original implementation: http://bit.ly/1vkDjo
+ * ACE homepage: http://www.cse.wustl.edu/~schmidt/ACE.html
+ * See also: http://www.cse.wustl.edu/~schmidt/win32-cv-1.html
+ */
+typedef struct {
+ LONG waiters;
+ CRITICAL_SECTION waiters_lock;
+ HANDLE sema;
+} pthread_cond_t;
+
+static inline int pthread_cond_init(pthread_cond_t *cond, const void *unused)
+{
+ cond->waiters = 0;
+
+ InitializeCriticalSection(&cond->waiters_lock);
+
+ cond->sema = CreateSemaphore(NULL, 0, LONG_MAX, NULL);
+ if (!cond->sema)
+ return 0; /* POSIX do not allow pthread_cond_init to fail */
+ return 0;
+}
+
+static inline int pthread_cond_destroy(pthread_cond_t *cond)
+{
+ CloseHandle(cond->sema);
+ cond->sema = NULL;
+
+ DeleteCriticalSection(&cond->waiters_lock);
+
+ return 0;
+}
+
+static inline int pthread_cond_wait(pthread_cond_t *cond, CRITICAL_SECTION *mutex)
+{
+ /* serialize access to waiters count */
+ EnterCriticalSection(&cond->waiters_lock);
+ ++cond->waiters;
+ LeaveCriticalSection(&cond->waiters_lock);
+
+ /*
+ * Unlock external mutex and wait for signal.
+ * NOTE: we've held mutex locked long enough to increment
+ * waiters count above, so there's no problem with
+ * leaving mutex unlocked before we wait on semaphore.
+ */
+ LeaveCriticalSection(mutex);
+
+ /* let's wait */
+ WaitForSingleObject(cond->sema, INFINITE))
+
+ /* we're done waiting, so make sure we decrease waiters count */
+ EnterCriticalSection(&cond->waiters_lock);
+ --cond->waiters;
+ LeaveCriticalSection(&cond->waiters_lock);
+
+ /* lock external mutex again */
+ EnterCriticalSection(mutex);
+
+ return 0;
+}
+
+static inline int pthread_cond_signal(pthread_cond_t *cond)
+{
+ int have_waiters;
+
+ /* serialize access to waiters count */
+ EnterCriticalSection(&cond->waiters_lock);
+ have_waiters = cond->waiters > 0;
+ LeaveCriticalSection(&cond->waiters_lock);
+
+ /*
+ * Signal only when there are waiters
+ */
+ if (have_waiters)
+ return ReleaseSemaphore(cond->sema, 1, NULL) ?
+ 0 : err_win_to_posix(GetLastError();
+ else
+ return 0;
+}
+
+#define pthread_t HANDLE
+#define pthread_mutex_t CRITICAL_SECTION
+
+#define pthread_mutex_init(a,b) InitializeCriticalSection((a))
+#define pthread_mutex_destroy(a) DeleteCriticalSection((a))
+#define pthread_mutex_lock EnterCriticalSection
+#define pthread_mutex_unlock LeaveCriticalSection
+
+static inline int pthread_create(pthread_t *thread, const void *unused,
+ DWORD (__stdcall *start_routine)(LPVOID), void *arg)
+{
+ *thread = CreateThread(NULL, 0, start_routine, arg, 0, NULL);
+
+ if (!*thread)
+ return err_win_to_posix(GetLastError());
+ else
+ return 0;
+}
+
+static inline int pthread_join(pthread_t thread, void **unused)
+{
+ DWORD result = WaitForSingleObject(t, INFINITE);
+ switch (result) {
+ case WAIT_OBJECT_0:
+ return 0;
+ case WAIT_ABANDONED:
+ return EINVAL;
+ default:
+ return err_win_to_posix(GetLastError());
+ }
+}
+
+#endif /* PTHREAD_H */
diff --git a/git-compat-util.h b/git-compat-util.h
index ef60803..4311117 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -464,4 +464,14 @@ void git_qsort(void *base, size_t nmemb, size_t size,
*/
int unlink_or_warn(const char *path);
+/*
+ * Define type of thread function return type to distinguish
+ * Windows and POSIX.
+ */
+#ifndef _WIN32
+# define THREAD_RET_TYPE void *
+#else
+# define THREAD_RET_TYPE DWORD __stdcall
+#endif
+
#endif
diff --git a/preload-index.c b/preload-index.c
index 9289933..41b11a3 100644
--- a/preload-index.c
+++ b/preload-index.c
@@ -28,7 +28,7 @@ struct thread_data {
int offset, nr;
};
-static void *preload_thread(void *_data)
+static THREAD_RET_TYPE preload_thread(void* _data)
{
int nr;
struct thread_data *p = _data;
@@ -59,7 +59,7 @@ static void *preload_thread(void *_data)
continue;
ce_mark_uptodate(ce);
} while (--nr > 0);
- return NULL;
+ return 0;
}
static void preload_index(struct index_state *index, const char **pathspec)
-- 1.6.5.2
^ permalink raw reply related
* Re: thoughts on setting core.logAllRefUpdates default true for bare repos
From: Nicolas Sebrecht @ 2009-11-04 23:52 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: Johannes Schindelin, git, Nicolas Sebrecht
In-Reply-To: <2e24e5b90911040841l7741787et48fabb8c8066e946@mail.gmail.com>
The 04/11/09, Sitaram Chamarty wrote:
> But if you are able to do "gc" manually on any repo you can also do
> "reflog expire" before "gc" can you not? Please correct me if I'm
> wrong.
"If we are able to do 'gc' on any repo"... But a lot of users aren't
able to it because they aren't the admin.
Or did you mean if "non-admin users could" ?
--
Nicolas Sebrecht
^ permalink raw reply
* Re: gitweb - bare repos integration - owner info in description file
From: Eugene Sajine @ 2009-11-04 23:48 UTC (permalink / raw)
To: Petr Baudis; +Cc: Johannes Schindelin, Jakub Narebski, git
In-Reply-To: <20091103202211.GA17748@machine.or.cz>
>
> I think you got confused by perhaps unclear gitweb/README wording. There
> is a single property file, it's called "config" and _that's_ where you
> set the gitweb configuration variables, in its gitweb section.
>
> Try running
>
> git config gitweb.owner "Eugene Sajine"
> git config gitweb.description tralala
>
> within the repository (and optionally marveling at the config file again
> afterwards). Is this what you are after?
>
> Perhaps the gitweb/README file doesn't make it clear enough that these
> are gitweb configuration variables, not stand-alone files, and maybe it
> should provide an example on how to set them. I'm sure that if you will
> submit a patch for gitweb/README clarifying this, it will be welcome.
>
> Kind regards,
>
> --
> Petr "Pasky" Baudis
> A lot of people have my books on their bookshelves.
> That's the problem, they need to read them. -- Don Knuth
>
Thank you for the advice, but I found a better solution than gitweb - cgit!
I should say cgit is an amazing tool - nice design and graphic
appearance, easy to set up and very easy to maintain, full of features
and fits our environment nicely. Many thanks to the Author (Lars
Hjemli) and all contributors!
Eugene
^ permalink raw reply
* [PATCH] MSVC: Windows-native implementation for subset of Pthreads API
From: Andrzej K. Haczewski @ 2009-11-04 23:47 UTC (permalink / raw)
To: git; +Cc: Nicolas Pitre, Johannes Sixt
In-Reply-To: <16cee31f0911041316n20fc9f12s6595dadc813d8f46@mail.gmail.com>
This patch implements native to Windows subset of pthreads API used by Git.
It allows to remove Pthreads for Win32 dependency for msysgit and cygwin.
The patch modifies Makefile only for MSVC (that's the environment I'm
capable of testing on), so it requires further corrections to compile
with MinGW or Cygwin.
Signed-off-by: Andrzej K. Haczewski <ahaczewski@gmail.com>
---
Makefile | 4 +-
builtin-pack-objects.c | 34 ++++++++++--
compat/mingw.c | 2 +-
compat/mingw.h | 5 ++
compat/win32/pthread.h | 132 ++++++++++++++++++++++++++++++++++++++++++++++++
git-compat-util.h | 10 ++++
preload-index.c | 4 +-
7 files changed, 180 insertions(+), 11 deletions(-)
create mode 100644 compat/win32/pthread.h
diff --git a/Makefile b/Makefile
index 94d44b0..0146ac7 100644
--- a/Makefile
+++ b/Makefile
@@ -975,7 +975,7 @@ ifdef MSVC
OBJECT_CREATION_USES_RENAMES = UnfortunatelyNeedsTo
NO_REGEX = YesPlease
NO_CURL = YesPlease
- NO_PTHREADS = YesPlease
+ THREADED_DELTA_SEARCH = YesPlease
BLK_SHA1 = YesPlease
CC = compat/vcbuild/scripts/clink.pl
@@ -983,7 +983,7 @@ ifdef MSVC
CFLAGS =
BASIC_CFLAGS = -nologo -I. -I../zlib -Icompat/vcbuild -Icompat/vcbuild/include -DWIN32 -D_CONSOLE -DHAVE_STRING_H -D_CRT_SECURE_NO_WARNINGS -D_CRT_NONSTDC_NO_DEPRECATE
COMPAT_OBJS = compat/msvc.o compat/fnmatch/fnmatch.o compat/winansi.o
- COMPAT_CFLAGS = -D__USE_MINGW_ACCESS -DNOGDI -DHAVE_STRING_H -DHAVE_ALLOCA_H -Icompat -Icompat/fnmatch -Icompat/regex -Icompat/fnmatch -DSTRIP_EXTENSION=\".exe\"
+ COMPAT_CFLAGS = -D__USE_MINGW_ACCESS -DNOGDI -DHAVE_STRING_H -DHAVE_ALLOCA_H -Icompat -Icompat/fnmatch -Icompat/regex -Icompat/fnmatch -Icompat/win32 -DSTRIP_EXTENSION=\".exe\"
BASIC_LDFLAGS = -IGNORE:4217 -IGNORE:4049 -NOLOGO -SUBSYSTEM:CONSOLE -NODEFAULTLIB:MSVCRT.lib
EXTLIBS = advapi32.lib shell32.lib wininet.lib ws2_32.lib
lib =
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 02f9246..e897b16 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -1255,15 +1255,15 @@ static int delta_cacheable(unsigned long src_size, unsigned long trg_size,
#ifdef THREADED_DELTA_SEARCH
-static pthread_mutex_t read_mutex = PTHREAD_MUTEX_INITIALIZER;
+static pthread_mutex_t read_mutex;
#define read_lock() pthread_mutex_lock(&read_mutex)
#define read_unlock() pthread_mutex_unlock(&read_mutex)
-static pthread_mutex_t cache_mutex = PTHREAD_MUTEX_INITIALIZER;
+static pthread_mutex_t cache_mutex;
#define cache_lock() pthread_mutex_lock(&cache_mutex)
#define cache_unlock() pthread_mutex_unlock(&cache_mutex)
-static pthread_mutex_t progress_mutex = PTHREAD_MUTEX_INITIALIZER;
+static pthread_mutex_t progress_mutex;
#define progress_lock() pthread_mutex_lock(&progress_mutex)
#define progress_unlock() pthread_mutex_unlock(&progress_mutex)
@@ -1590,9 +1590,28 @@ struct thread_params {
unsigned *processed;
};
-static pthread_cond_t progress_cond = PTHREAD_COND_INITIALIZER;
+static pthread_cond_t progress_cond;
-static void *threaded_find_deltas(void *arg)
+/*
+ * Mutex and conditional variable can't be statically-initialized on Windows.
+ */
+static void init_threaded_search()
+{
+ pthread_mutex_init(&read_mutex);
+ pthread_mutex_init(&cache_mutex);
+ pthread_mutex_init(&progress_mutex);
+ pthread_cond_init(&progress_cond, NULL);
+}
+
+static void cleanup_threaded_search()
+{
+ pthread_cond_destroy(&progress_cond);
+ pthread_mutex_destroy(&read_mutex);
+ pthread_mutex_destroy(&cache_mutex);
+ pthread_mutex_destroy(&progress_mutex);
+}
+
+static THREAD_RET_TYPE threaded_find_deltas(void *arg)
{
struct thread_params *me = arg;
@@ -1620,7 +1639,7 @@ static void *threaded_find_deltas(void *arg)
pthread_mutex_unlock(&me->mutex);
}
/* leave ->working 1 so that this doesn't get more work assigned */
- return NULL;
+ return 0;
}
static void ll_find_deltas(struct object_entry **list, unsigned list_size,
@@ -1638,6 +1657,8 @@ static void ll_find_deltas(struct object_entry **list, unsigned list_size,
delta_search_threads);
p = xcalloc(delta_search_threads, sizeof(*p));
+ init_threaded_search();
+
/* Partition the work amongst work threads. */
for (i = 0; i < delta_search_threads; i++) {
unsigned sub_size = list_size / (delta_search_threads - i);
@@ -1745,6 +1766,7 @@ static void ll_find_deltas(struct object_entry **list, unsigned list_size,
active_threads--;
}
}
+ cleanup_threaded_search();
free(p);
}
diff --git a/compat/mingw.c b/compat/mingw.c
index 6b5b5b2..f2e9f02 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -5,7 +5,7 @@
#include <shellapi.h>
-static int err_win_to_posix(DWORD winerr)
+int err_win_to_posix(DWORD winerr)
{
int error = ENOSYS;
switch(winerr) {
diff --git a/compat/mingw.h b/compat/mingw.h
index 6907345..7e25fb5 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -294,3 +294,8 @@ struct mingw_dirent
#define readdir(x) mingw_readdir(x)
struct dirent *mingw_readdir(DIR *dir);
#endif // !NO_MINGW_REPLACE_READDIR
+
+/*
+ * Used by Pthread API implementation for Windows
+ */
+extern int err_win_to_posix(DWORD winerr);
diff --git a/compat/win32/pthread.h b/compat/win32/pthread.h
new file mode 100644
index 0000000..0e43714
--- /dev/null
+++ b/compat/win32/pthread.h
@@ -0,0 +1,132 @@
+/*
+ * Header used to adapt pthread-based POSIX code to Windows API threads.
+ *
+ * Copyright (C) 2009 Andrzej K. Haczewski <ahaczewski@gmail.com>
+ */
+
+#ifndef PTHREAD_H
+#define PTHREAD_H
+
+#ifndef WIN32_LEAN_AND_MEAN
+#define WIN32_LEAN_AND_MEAN
+#endif
+
+#include <windows.h>
+
+/*
+ * Implement simple condition variable for Windows threads, based on ACE
+ * implementation.
+ *
+ * See original implementation: http://bit.ly/1vkDjo
+ * ACE homepage: http://www.cse.wustl.edu/~schmidt/ACE.html
+ * See also: http://www.cse.wustl.edu/~schmidt/win32-cv-1.html
+ */
+typedef struct {
+ LONG waiters;
+ CRITICAL_SECTION waiters_lock;
+ HANDLE sema;
+} pthread_cond_t;
+
+static inline int pthread_cond_init(pthread_cond_t *cond, const void *unused)
+{
+ cond->waiters = 0;
+
+ InitializeCriticalSection(&cond->waiters_lock);
+
+ cond->sema = CreateSemaphore(NULL, 0, LONG_MAX, NULL);
+ if (!cond->sema)
+ return 0; /* POSIX do not allow pthread_cond_init to fail */
+ return 0;
+}
+
+static inline int pthread_cond_destroy(pthread_cond_t *cond)
+{
+ CloseHandle(cond->sema);
+ cond->sema = NULL;
+
+ DeleteCriticalSection(&cond->waiters_lock);
+
+ return 0;
+}
+
+static inline int pthread_cond_wait(pthread_cond_t *cond, CRITICAL_SECTION *mutex)
+{
+ /* serialize access to waiters count */
+ EnterCriticalSection(&cond->waiters_lock);
+ ++cond->waiters;
+ LeaveCriticalSection(&cond->waiters_lock);
+
+ /*
+ * Unlock external mutex and wait for signal.
+ * NOTE: we've held mutex locked long enough to increment
+ * waiters count above, so there's no problem with
+ * leaving mutex unlocked before we wait on semaphore.
+ */
+ LeaveCriticalSection(mutex);
+
+ /* let's wait */
+ WaitForSingleObject(cond->sema, INFINITE))
+
+ /* we're done waiting, so make sure we decrease waiters count */
+ EnterCriticalSection(&cond->waiters_lock);
+ --cond->waiters;
+ LeaveCriticalSection(&cond->waiters_lock);
+
+ /* lock external mutex again */
+ EnterCriticalSection(mutex);
+
+ return 0;
+}
+
+static inline int pthread_cond_signal(pthread_cond_t *cond)
+{
+ int have_waiters;
+
+ /* serialize access to waiters count */
+ EnterCriticalSection(&cond->waiters_lock);
+ have_waiters = cond->waiters > 0;
+ LeaveCriticalSection(&cond->waiters_lock);
+
+ /*
+ * Signal only when there are waiters
+ */
+ if (have_waiters)
+ return ReleaseSemaphore(cond->sema, 1, NULL) ?
+ 0 : err_win_to_posix(GetLastError();
+ else
+ return 0;
+}
+
+#define pthread_t HANDLE
+#define pthread_mutex_t CRITICAL_SECTION
+
+#define pthread_mutex_init(a,b) InitializeCriticalSection((a))
+#define pthread_mutex_destroy(a) DeleteCriticalSection((a))
+#define pthread_mutex_lock EnterCriticalSection
+#define pthread_mutex_unlock LeaveCriticalSection
+
+static inline int pthread_create(pthread_t *thread, const void *unused,
+ DWORD (__stdcall *start_routine)(LPVOID), void *arg)
+{
+ *thread = CreateThread(NULL, 0, start_routine, arg, 0, NULL);
+
+ if (!*thread)
+ return err_win_to_posix(GetLastError());
+ else
+ return 0;
+}
+
+static inline int pthread_join(pthread_t thread, void **unused)
+{
+ DWORD result = WaitForSingleObject(t, INFINITE);
+ switch (result) {
+ case WAIT_OBJECT_0:
+ return 0;
+ case WAIT_ABANDONED:
+ return EINVAL;
+ default:
+ return err_win_to_posix(GetLastError());
+ }
+}
+
+#endif /* PTHREAD_H */
diff --git a/git-compat-util.h b/git-compat-util.h
index ef60803..4311117 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -464,4 +464,14 @@ void git_qsort(void *base, size_t nmemb, size_t size,
*/
int unlink_or_warn(const char *path);
+/*
+ * Define type of thread function return type to distinguish
+ * Windows and POSIX.
+ */
+#ifndef _WIN32
+# define THREAD_RET_TYPE void *
+#else
+# define THREAD_RET_TYPE DWORD __stdcall
+#endif
+
#endif
diff --git a/preload-index.c b/preload-index.c
index 9289933..41b11a3 100644
--- a/preload-index.c
+++ b/preload-index.c
@@ -28,7 +28,7 @@ struct thread_data {
int offset, nr;
};
-static void *preload_thread(void *_data)
+static THREAD_RET_TYPE preload_thread(void* _data)
{
int nr;
struct thread_data *p = _data;
@@ -59,7 +59,7 @@ static void *preload_thread(void *_data)
continue;
ce_mark_uptodate(ce);
} while (--nr > 0);
- return NULL;
+ return 0;
}
static void preload_index(struct index_state *index, const char **pathspec)
--
1.6.5.2
^ permalink raw reply related
* Re: [PATCH v2 11/13] Allow helpers to request the path to the .git directory
From: Daniel Barkalow @ 2009-11-04 23:25 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Git List, Johannes Schindelin, Johan Herland
In-Reply-To: <fabb9a1e0911041518h9e3d07dneba3056848e98f3e@mail.gmail.com>
On Thu, 5 Nov 2009, Sverre Rabbelier wrote:
> Heya,
>
> On Thu, Nov 5, 2009 at 00:17, Daniel Barkalow <barkalow@iabervon.org> wrote:
> > Well, gfi is used with different native systems, each of which will
> > presumably put it somewhere different.
>
> Right, but I meant for git itself :). I assume that you meant that
> 'gitdir' (or 'infodir' , whatever) should return the same path,
> whatever we decide on?q
Yeah. I think the base that git uses wasn't decided on, although I may
have missed that part of the thread. In any case, I do think it should be
the directory passed to the helper.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH v2 11/13] Allow helpers to request the path to the .git directory
From: Sverre Rabbelier @ 2009-11-04 23:18 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Git List, Johannes Schindelin, Johan Herland
In-Reply-To: <alpine.LNX.2.00.0911041748150.14365@iabervon.org>
Heya,
On Thu, Nov 5, 2009 at 00:17, Daniel Barkalow <barkalow@iabervon.org> wrote:
> Well, gfi is used with different native systems, each of which will
> presumably put it somewhere different.
Right, but I meant for git itself :). I assume that you meant that
'gitdir' (or 'infodir' , whatever) should return the same path,
whatever we decide on?q
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH v2 11/13] Allow helpers to request the path to the .git directory
From: Daniel Barkalow @ 2009-11-04 23:17 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Git List, Johannes Schindelin, Johan Herland
In-Reply-To: <fabb9a1e0911041442k493c5d7cx493c2e5dac9d892c@mail.gmail.com>
On Wed, 4 Nov 2009, Sverre Rabbelier wrote:
> Heya,
>
> On Wed, Nov 4, 2009 at 23:27, Daniel Barkalow <barkalow@iabervon.org> wrote:
> >> The marks option has been dumped in favor of 'feature import-marks='
> >> and 'feature export-marks=' which will be in the reroll of
> >> sr/gfi-options.
> >
> > Right, but the values of those have to be paths, and I think they should
> > be relative paths, relative to the helper's state directory.
>
> Hmmm, I don't remember exactly what we decided the paths should be
> releative, pretty sure it was somewhere in .git/ though.
Well, gfi is used with different native systems, each of which will
presumably put it somewhere different.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Common setting for interoperability repo across windows and unix?
From: Erik Faye-Lund @ 2009-11-04 23:10 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Avery Pennarun, Anthony W. Youngman, git
In-Reply-To: <20091104230122.GK10505@spearce.org>
On Thu, Nov 5, 2009 at 12:01 AM, Shawn O. Pearce <spearce@spearce.org> wrote:
> Avery Pennarun <apenwarr@gmail.com> wrote:
>> >
>> > git-daemon doesn't (currently) work on msysgit. Currently I run git-daemon
>> > on my linpus netbook and pull/push from windows.
>>
>> I didn't know that. Windows sockets are mercifully very nearly
>> compatible with Linux ones, so hopefully this wouldn't be too hard to
>> fix for someone that needs it. (Not me; I prefer cygwin over msys in
>> all cases.)
>
> git-daemon relies on fork, do work, then later exec. Windows lacks
> this concept. Making it hard to port.
Before anyone starts hacking: I've got a working git-daemon on
Windows, based on some old patches from Mike Pape, plus some extending
of the start_async-api. It's still not ready for submission, but I
think I've got the last important technical details nailed down now,
all that is needed is a fair share of clean-up. Hopefully I'll have it
ready for submission during the week-end some time.
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: Common setting for interoperability repo across windows and unix?
From: Shawn O. Pearce @ 2009-11-04 23:01 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Anthony W. Youngman, git
In-Reply-To: <32541b130911041459y7a2201a3r18601522187891f2@mail.gmail.com>
Avery Pennarun <apenwarr@gmail.com> wrote:
> >
> > git-daemon doesn't (currently) work on msysgit. Currently I run git-daemon
> > on my linpus netbook and pull/push from windows.
>
> I didn't know that. Windows sockets are mercifully very nearly
> compatible with Linux ones, so hopefully this wouldn't be too hard to
> fix for someone that needs it. (Not me; I prefer cygwin over msys in
> all cases.)
git-daemon relies on fork, do work, then later exec. Windows lacks
this concept. Making it hard to port.
--
Shawn.
^ permalink raw reply
* Re: Common setting for interoperability repo across windows and unix?
From: Avery Pennarun @ 2009-11-04 22:59 UTC (permalink / raw)
To: Anthony W. Youngman; +Cc: git
In-Reply-To: <S0ax5AE0Xf8KFwjv@thewolery.demon.co.uk>
On Wed, Nov 4, 2009 at 4:45 PM, Anthony W. Youngman
<wol@thewolery.demon.co.uk> wrote:
> In message <32541b130911030733i734b9f6doc366934873bf7713@mail.gmail.com>,
> Avery Pennarun <apenwarr@gmail.com> writes
>> You can pull from a Windows box by running git-daemon on that box from
>> the command line. (It's easier than it sounds.)
>
> That presumes you're running Cygwin ...
>
> git-daemon doesn't (currently) work on msysgit. Currently I run git-daemon
> on my linpus netbook and pull/push from windows.
I didn't know that. Windows sockets are mercifully very nearly
compatible with Linux ones, so hopefully this wouldn't be too hard to
fix for someone that needs it. (Not me; I prefer cygwin over msys in
all cases.)
Avery
^ permalink raw reply
* Re: [PATCH] MSVC: Windows-native implementation for subset of Pthreads API
From: Andrzej K. Haczewski @ 2009-11-04 22:50 UTC (permalink / raw)
To: kusmabite; +Cc: Nicolas Pitre, git, Johannes Sixt
In-Reply-To: <40aa078e0911041341s1adbbf31t6961207ba9c7905b@mail.gmail.com>
Erik Faye-Lund pisze:
> Couldn't the windows version of pthread_create have a wrapper
> function, that corrected the calling convention, much like the
> function run_thread that start_async in run-command.c has?
Can't be done without allocations. I'd have to pass to that wrapping
thread function an address of original function *and* an original
argument, and there's no way to pack that as one void*.
--
Andrzej
^ permalink raw reply
* Re: [PATCH v2 11/13] Allow helpers to request the path to the .git directory
From: Sverre Rabbelier @ 2009-11-04 22:42 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Git List, Johannes Schindelin, Johan Herland
In-Reply-To: <alpine.LNX.2.00.0911041723010.14365@iabervon.org>
Heya,
On Wed, Nov 4, 2009 at 23:27, Daniel Barkalow <barkalow@iabervon.org> wrote:
>> Yes, that would probably be a good idea, .git/info/remote-<vcs>/<alias> perhaps?
>
> Seems reasonable to me, unless we make it .git/info/remote-<vcs>, and tell
> helper authors to deal with having different imports not conflict with
> each other.
Ah, yeah, the helper might want to store some global state as well, so
'.git/info/remote-<vcs>' is probably best.
>> The marks option has been dumped in favor of 'feature import-marks='
>> and 'feature export-marks=' which will be in the reroll of
>> sr/gfi-options.
>
> Right, but the values of those have to be paths, and I think they should
> be relative paths, relative to the helper's state directory.
Hmmm, I don't remember exactly what we decided the paths should be
releative, pretty sure it was somewhere in .git/ though.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Common setting for interoperability repo across windows and unix?
From: Anthony W. Youngman @ 2009-11-04 21:45 UTC (permalink / raw)
To: git
In-Reply-To: <32541b130911030733i734b9f6doc366934873bf7713@mail.gmail.com>
In message
<32541b130911030733i734b9f6doc366934873bf7713@mail.gmail.com>, Avery
Pennarun <apenwarr@gmail.com> writes
>You can pull from a Windows box by running git-daemon on that box from
>the command line. (It's easier than it sounds.)
That presumes you're running Cygwin ...
git-daemon doesn't (currently) work on msysgit. Currently I run
git-daemon on my linpus netbook and pull/push from windows.
Cheers,
Wol
--
Anthony W. Youngman - anthony@thewolery.demon.co.uk
^ permalink raw reply
* Re: [PATCH v2 11/13] Allow helpers to request the path to the .git directory
From: Daniel Barkalow @ 2009-11-04 22:27 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Git List, Johannes Schindelin, Johan Herland
In-Reply-To: <fabb9a1e0911041406tce0956ai2ad3fe6cfbdc546d@mail.gmail.com>
On Wed, 4 Nov 2009, Sverre Rabbelier wrote:
> Heya,
>
> On Wed, Nov 4, 2009 at 22:35, Daniel Barkalow <barkalow@iabervon.org> wrote:
> > I thought we cd into the repository in the middle of clone somewhere,
> > before running stuff.
>
> It does, but not soon enough, that is, not before I needed it in my helper.
>
> > In any case, I think it would be good to have
> > something like that, but I think maybe we should tell it where it can put
> > its status files, rather than telling it where the .git dir is.
>
> Yes, that would probably be a good idea, .git/info/remote-<vcs>/<alias> perhaps?
Seems reasonable to me, unless we make it .git/info/remote-<vcs>, and tell
helper authors to deal with having different imports not conflict with
each other.
> > It would
> > also be nice if this is the absolute path that gfi will base a relative
> > path for the "marks" options on when importing.
>
> The marks option has been dumped in favor of 'feature import-marks='
> and 'feature export-marks=' which will be in the reroll of
> sr/gfi-options.
Right, but the values of those have to be paths, and I think they should
be relative paths, relative to the helper's state directory.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] MSVC: port pthread code to native Windows threads
From: Daniel Barkalow @ 2009-11-04 22:22 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Andrzej K. Haczewski, Johannes Sixt, git
In-Reply-To: <alpine.LFD.2.00.0911041607250.10340@xanadu.home>
On Wed, 4 Nov 2009, Nicolas Pitre wrote:
> On Wed, 4 Nov 2009, Daniel Barkalow wrote:
>
> > On Wed, 4 Nov 2009, Andrzej K. Haczewski wrote:
> >
> > > 2009/11/4 Johannes Sixt <j.sixt@viscovery.net>:
> > > >
> > > > You are right. But #ifdef THREADED_DELTA_SEARCH is about a "generic"
> > > > property of the code and is already used elsewhere in the file, whereas
> > > > #ifdef WIN32 would be new and is is about platform differences.
> > > >
> > > > Anyway, we would have to see what Junio says about the new function calls,
> > > > because he's usually quite anal when it comes to added code vs. static
> > > > initialization. ;)
> > >
> > > I could do it with wrappers for pthread_mutex_lock and _unlock and
> > > lazy init there plus lazy init cond var in cond_wait and _signal, that
> > > way it could be done without any additional code in the first #ifdef.
> > > But I don't see any simple solution for working around
> > > deinitialization, that's why I'd leave non-static initialization. Let
> > > me put some touchups and resubmit for another round.
> >
> > Is it actually necessary to deinitialize? Since the variables are static
> > and therefore can't leak, and would presumably not need to be
> > reinitialized differently if they were used again, I think they should be
> > able to just stay. If Windows is unhappy about processes still having
> > locks initialized at exit, I suppose we could go through and destroy all
> > our mutexes and conds at cleanup time. Pthreads does have the appropriate
> > functions, and it would be correct to use them, although unnecessary.
>
> Lazy initialization would probably turn up to be more expensive
> (checking a flag on each usage) than unconditionally initializing them
> once. Remember that those are used at least once per object meaning a
> lot.
Meh, checking a flag on the same cache line as the lock you're about to
take can't be a big incremental cost, especially if it's actually checking
whether some sort of cookie is non-zero before doing something with it.
> And I much prefer having runtime initialization for both Unix and
> Windows than having separate paths on each platform potentially hiding
> different bugs. And given that on Unix you can statically initialize
> those, then a runtime initialization is certainly not going to be _that_
> costly.
Yeah, definitely best to have them match, whichever way we go.
I don't think it matters terribly much either way which we use, so long as
its consistent. It'd be nice if the static initializers worked, just
because people seem to write code with them, but we could just not do that
in the future.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH v2 11/13] Allow helpers to request the path to the .git directory
From: Sverre Rabbelier @ 2009-11-04 22:06 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Git List, Johannes Schindelin, Johan Herland
In-Reply-To: <alpine.LNX.2.00.0911041621400.14365@iabervon.org>
Heya,
On Wed, Nov 4, 2009 at 22:35, Daniel Barkalow <barkalow@iabervon.org> wrote:
> I thought we cd into the repository in the middle of clone somewhere,
> before running stuff.
It does, but not soon enough, that is, not before I needed it in my helper.
> In any case, I think it would be good to have
> something like that, but I think maybe we should tell it where it can put
> its status files, rather than telling it where the .git dir is.
Yes, that would probably be a good idea, .git/info/remote-<vcs>/<alias> perhaps?
> It would
> also be nice if this is the absolute path that gfi will base a relative
> path for the "marks" options on when importing.
The marks option has been dumped in favor of 'feature import-marks='
and 'feature export-marks=' which will be in the reroll of
sr/gfi-options.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] More precise description of 'git describe --abbrev'
From: Gisle Aas @ 2009-11-04 22:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmy38im51.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 603 bytes --]
Unfortunately there was still a grammar typo in that patch:
--- a/Documentation/git-describe.txt
+++ b/Documentation/git-describe.txt
@@ -120,7 +120,7 @@ closest tagname without any suffix:
tags/v1.0.0
Note that the suffix you get if you type these commands today may be
-longer than what Linus saw above when he ran this command, as your
+longer than what Linus saw above when he ran these commands, as your
git repository may have new commits whose object names begin with
975b that did not exist back then, and "-g975b" suffix alone may not
be sufficient to disambiguate these commits.
[-- Attachment #2: 0001-Fix-documentation-grammar-typo.patch --]
[-- Type: application/octet-stream, Size: 1029 bytes --]
From 8910eed48f0c4c53af1b74d0016ef772bdce5689 Mon Sep 17 00:00:00 2001
From: Gisle Aas <gisle@aas.no>
Date: Wed, 4 Nov 2009 22:57:46 +0100
Subject: [PATCH] Fix documentation grammar typo
Introduced in commit 492cf3f72f9d8...
Signed-off-by: Gisle Aas <gisle@aas.no>
---
Documentation/git-describe.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt
index e9dbca7..2f97916 100644
--- a/Documentation/git-describe.txt
+++ b/Documentation/git-describe.txt
@@ -120,7 +120,7 @@ closest tagname without any suffix:
tags/v1.0.0
Note that the suffix you get if you type these commands today may be
-longer than what Linus saw above when he ran this command, as your
+longer than what Linus saw above when he ran these commands, as your
git repository may have new commits whose object names begin with
975b that did not exist back then, and "-g975b" suffix alone may not
be sufficient to disambiguate these commits.
--
1.6.2.95.g934f7
^ permalink raw reply related
* Re: [RFC/PATCH 0/3] use '--bisect-refs' as bisect rev machinery option
From: Junio C Hamano @ 2009-11-04 21:52 UTC (permalink / raw)
To: Christian Couder; +Cc: Linus Torvalds, git
In-Reply-To: <200911042226.25599.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> So to do that you would use "git bisect start ..." and then you could use:
>
> $ git rev-list --bisect HEAD --not $GOOD_COMMITS
>
> to get the commit that you would have to test if the current commit is bad
> and:
>
> $ git rev-list --bisect $BAD --not $GOOD_COMMITS HEAD
>
> to get the commit that you would have to test if the current commit is good.
Even in that case, the problem is still about narrowing the set of the
current bisection graph. If --bisect option implicitly grabs good and bad
defined in the refspace like Linus's patch does, it will give you the same
behaviour of the above two commands, no?
^ permalink raw reply
* Re: [PATCH] MSVC: Windows-native implementation for subset of Pthreads API
From: Nicolas Pitre @ 2009-11-04 21:52 UTC (permalink / raw)
To: Andrzej K. Haczewski; +Cc: git, Johannes Sixt
In-Reply-To: <16cee31f0911041316n20fc9f12s6595dadc813d8f46@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 849 bytes --]
On Wed, 4 Nov 2009, Andrzej K. Haczewski wrote:
> 2009/11/4 Nicolas Pitre <nico@fluxnic.net>:
> > On Wed, 4 Nov 2009, Andrzej K. Haczewski wrote:
> >
> >> + NO_STATIC_PTHREADS_INIT = YesPlease
> >
> > Let's not go that route please. If Windows can't get away without
> > runtime initializations then let's use them on all platforms. There is
> > no gain in exploding the code path combinations here wrt testing
> > coverage.
> >
>
> I don't like that approach either, but I was frighten of Junio being
> anal about static inits ;).
I think the alternative is much worse than loosing those static inits.
> Let's make it clear: has anyone have any objections that I add
> explicit initialization of mutexes and condition variables for POSIX
> also?
Please do it and if anyone finds a problem with it then we'll start from
there.
Nicolas
^ permalink raw reply
* Re: BUG: git rebase -i -p silently looses commits
From: Greg Price @ 2009-11-04 21:46 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Constantine Plotnikov, git
In-Reply-To: <alpine.DEB.1.00.0911021832530.2479@felix-maschine>
On Mon, 2 Nov 2009, Johannes Schindelin wrote:
> Having said that, I worked for some time on fixing this issue, and I
> actually run a version of rebase -i -p here that allows reordering
> commits, but it is far from stable (and due to GSoC and day-job
> obligations, I had no time to work on it in months).
I'm interested in this topic too. Some weeks ago I took your
rebase-i-p branch from January and rebased it onto the latest release;
it's at
git://repo.or.cz/git/price.git rebase-i-p
and now based on v1.6.5.2. I fixed a few bugs and added a feature,
and it's the version I run day to day.
Constantine and others interested in reordering commits with -p,
you're welcome to pull and build this version and try it out. It
mostly solves my problems, and maybe it will solve yours. Be warned
it does have bugs, and also be warned that I may rewind and rebase
that branch. I'd be glad to hear about bugs you see, though.
Dscho, do you have a TODO written somewhere of what work you're aware
the topic still needs? I plan to continue spending a little time
working on it, and I have my own list but it'd be good to compare
it with yours.
Cheers,
Greg
PS - I'm open to suggestions on the workflow for how to develop a
topic branch like this. Some rewinding seems necessary as half-baked
patches get finished, etc, but if Dscho or someone else finds time to
work on it too, then the rewinding gets in the way of pull/push
collaboration.
PPS - For those just scanning along, the shortlog so far:
Greg Price (6):
rebase -i -p: honor -s
rebase -i -p: get full message from original merge commit
rebase -i -p: always merge --no-ff
rebase -i: Add the "ref" command
rebase -i -p: Preserve author information on merges.
[broken] rebase -i: implement pause
Johannes Schindelin (19):
Some of Dscho's tools
debug settings in Makefile
Make CFLAGS more strict
rebase -i --root: simplify code
rebase -i: make pick_one() safer
rebase -i -p: add helper parse_commit() to find rewritten commits
rebase -i: add the "goto" command
rebase -i -p: add a helper to add mappings for rewritten commits
rebase -i -p: Add the "merge" command
rebase -i: make sure that the commands record the rewritten commits
rebase -i: move the code to write the rebase script into generate_script()
rebase -i: let generate_script output to stdout
rebase -i -p: refactor the preparation for -p into its own function
rebase -i -p: use patch-id directly to determine the dropped commits
rebase tests' fake-editor.sh: allow debugging with DEBUG_EDIT
rebase's fake-editor: prepare for "goto" and "merge" commands
rebase -i -p: generate a script using "goto" and "merge"
TODO
Make some tests in t3412 a little bit stricter
^ 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