* Re: [PATCH] MSVC: port pthread code to native Windows threads
From: Andrzej K. Haczewski @ 2009-11-04 14:14 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <4AF175E8.7020400@viscovery.net>
2009/11/4 Johannes Sixt <j.sixt@viscovery.net>:
>> +static __inline int pthread_cond_init(pthread_cond_t *cond, const void *unused)
>
> What's wrong with 'static inline int ...' (without the underscores)?
>
Forgot to answer. 'inline' is avaliable in C++ only (on MSVC at
least), while '__inline' is MS extension for C and C++.
--
Andrew
^ permalink raw reply
* Re: [PATCH] MSVC: port pthread code to native Windows threads
From: Erik Faye-Lund @ 2009-11-04 14:19 UTC (permalink / raw)
To: Andrzej K. Haczewski; +Cc: Johannes Sixt, git
In-Reply-To: <16cee31f0911040614p2d58c418m29e66ac825b12986@mail.gmail.com>
On Wed, Nov 4, 2009 at 3:14 PM, Andrzej K. Haczewski
<ahaczewski@gmail.com> wrote:
> 2009/11/4 Johannes Sixt <j.sixt@viscovery.net>:
>
>>> +static __inline int pthread_cond_init(pthread_cond_t *cond, const void *unused)
>>
>> What's wrong with 'static inline int ...' (without the underscores)?
>>
>
> Forgot to answer. 'inline' is avaliable in C++ only (on MSVC at
> least), while '__inline' is MS extension for C and C++.
You don't need it:
compat/msvc.h:9:#define inline __inline
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: Problem signing a tag
From: Michael J Gruber @ 2009-11-04 14:28 UTC (permalink / raw)
To: Joshua J. Kugler; +Cc: Alex Riesen, git
In-Reply-To: <200911030911.47030.joshua@eeinternet.com>
Joshua J. Kugler venit, vidit, dixit 03.11.2009 19:11:
> On Monday 02 November 2009, Alex Riesen said something like:
>> On Tue, Nov 3, 2009 at 01:58, Joshua J. Kugler <joshua@eeinternet.com>
> wrote:
>>> Nobody on the git IRC channel responded to this question, even
>>> after asking it a few times, so I thought I'd try here.
>>>
>>> I'm having trouble signing a tag. I'm using this command:
>>>
>>> git tag -u EAFD344D14EA086E -F .git/TAG_EDITMSG tag_name
>>>
>>> I type in my passphrase, and am then told:
>>>
>>> error: gpg failed to sign the tag
>>> error: unable to sign the tag
>>>
>>> However, if I use this command:
>>>
>>> gpg -s -u EAFD344D14EA086E
>>>
>>> and use the same passphrase, it works fine. Is there any way to
>>> find out why a key-signing is failing?
>>
>> What does "echo $?" after it prints? IOW, maybe plain gpg fails too,
>> without printing anything special, and you don't pay attention to the
>> exit code. Git does. And it runs "gpg -bsau <key-id>".
>
> $ git tag -s -F .git/TAG_EDITMSG tag_name
>
> You need a passphrase to unlock the secret key for
> user: "Joshua J. Kugler <joshua@azariah.com>"
> 1024-bit DSA key, ID 14EA086E, created 2009-08-09
>
> gpg: problem with the agent - disabling agent use
> error: gpg failed to sign the tag
> error: unable to sign the tag
> $ echo $?
> 128
>
> And when I sign at the prompt:
>
> $ gpg -sa
>
> You need a passphrase to unlock the secret key for
> user: "Joshua J. Kugler <joshua@azariah.com>"
> 1024-bit DSA key, ID 14EA086E, created 2009-08-09
>
> gpg: problem with the agent - disabling agent use
> Blah blah blah blah
> Blah blah blah blah
> $ echo $?
> 2
[...]
I assume you don't want to use gpg-agent, that should be the easy way out.
If gpg is trying to contact the agent it means that "use-agent" is set
(from the config) and, probably, also that GPG_AGENT_INFO is set but no
agent responds at that socket. (echo $GPG_AGENT_INFO)
Many distros set up this stuff automatically. Try unsetting both:
unset GPG_AGENT_INFO
gpg --no-use-agent ...
If that helps you can put "--no-use-agent" in your gpg config.
2 is a non-fatal error, 128 a fatal one, btw.
Michael
^ permalink raw reply
* Re: [PATCH] MSVC: port pthread code to native Windows threads
From: Johannes Sixt @ 2009-11-04 14:34 UTC (permalink / raw)
To: Andrzej K. Haczewski; +Cc: git
In-Reply-To: <16cee31f0911040547m69e5b9cbi30e20d2a7790bd6f@mail.gmail.com>
Andrzej K. Haczewski schrieb:
> 2009/11/4 Johannes Sixt <j.sixt@viscovery.net>:
>> After staring some time on the code, I have convinced myself that the
>> pthread_cond_wait and pthread_cond_signal implementation will work *in our
>> usage scenario* that has these preconditions:
>
> But it is not impossible with that implementation.
Read again what I wrote: We are in agreement.
> On resubmit I'll give more credit to ACE.
Perhaps also a link to the source and, even better, to a discussion of the
implementation.
>> - pthread_cond_signal is called while the mutex is held.
>
> AFAIK that is a requirement for condition variable to be signaled
> while holding the same mutex that other threads cond_wait on. I just
> don't check that it is true, because Git is locking mutex.
It is not a requirement, but, yes, we do hold the mutex.
>> - We retest the condition after pthread_cond_wait returns.
>>
>> These conditions should be attached in BIG BOLD letters to this
>> implementation; particularly, the last one.
>
> That's also a known requirement for working with cond vars.
Indeed.
>> I think it would be OK to drop '= PTHREAD_{MUTEX,COND}_INITIALIZER' and
>> use *_init function calls without the #ifdef. Likewise for *_destroy.
>
> Actually it won't save us many #ifdefs. There's one #ifdef for
> initialization that could be saved, but then comes #ifdef for cleanup:
> #if defined(THREADED_DELTA_SEARCH) && defined(_WIN32)
>
> What you propose will remove one #ifdef _WIN32 for initialization, but
> the cleanup will look almost the same:
> #ifdef THREADED_DELTA_SEARCH
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. ;)
-- Hannes
^ permalink raw reply
* Re: [PATCH] MSVC: port pthread code to native Windows threads
From: Andrzej K. Haczewski @ 2009-11-04 14:50 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <4AF190F1.3020607@viscovery.net>
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.
--
Andrzej
^ permalink raw reply
* [QGIT PATCH/RFC]
From: Abdelrazak Younes @ 2009-11-04 14:56 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
Hello Marco,
While recompiling latest qgit4, I stumbled accross this. I am not quite
sure you used a QLatin1String instead of a QByteArray but the attached
seems to work fine...
Anyway, I'll let you decide what do to with it.
Thanks for QGit,
Abdel.
diff --git a/src/cache.cpp b/src/cache.cpp
index af18fbf..2d9f415 100644
--- a/src/cache.cpp
+++ b/src/cache.cpp
@@ -70,11 +70,11 @@ bool Cache::save(const QString& gitDir, const
RevFileMap& rf,
const ShaString& sha = it.key();
if ( sha == ZERO_SHA_RAW
|| sha == CUSTOM_SHA_RAW
- || sha.latin1()[0] == 'A') // ALL_MERGE_FILES + rev
sha
+ || sha.at(0) == 'A') // ALL_MERGE_FILES + rev sha
continue;
v.append(it.value());
- buf.append(sha.latin1()).append('\0');
+ buf.append(sha);
newSize += 41;
if (newSize > bufSize) {
dbs("ASSERT in Cache::save, out of allocated
space");
diff --git a/src/common.h b/src/common.h
index ceb62fb..0d65980 100644
--- a/src/common.h
+++ b/src/common.h
@@ -7,6 +7,7 @@
#ifndef COMMON_H
#define COMMON_H
+#include <QByteArray>
#include <QColor>
#include <QEvent>
#include <QFont>
@@ -49,7 +50,7 @@ class QDataStream;
class QProcess;
class QSplitter;
class QWidget;
-class ShaString;
+typedef QByteArray ShaString;
// type shortcuts
typedef const QString& SCRef;
@@ -274,18 +275,6 @@ namespace QGit {
extern const QString SCRIPT_EXT;
}
-class ShaString : public QLatin1String {
-public:
- inline ShaString() : QLatin1String(NULL) {}
- inline ShaString(const ShaString& sha) :
QLatin1String(sha.latin1()) {}
- inline explicit ShaString(const char* sha) : QLatin1String(sha) {}
-
- inline bool operator!=(const ShaString& o) const { return
!operator==(o); }
- inline bool operator==(const ShaString& o) const {
-
- return (latin1() == o.latin1()) || !qstrcmp(latin1(),
o.latin1());
- }
-};
class Rev {
// prevent implicit C++ compiler defaults
diff --git a/src/git.cpp b/src/git.cpp
index 177b24a..afa5234 100644
--- a/src/git.cpp
+++ b/src/git.cpp
@@ -725,7 +725,7 @@ const Rev* Git::revLookup(SCRef sha, const
FileHistory* fh) const {
const Rev* Git::revLookup(const ShaString& sha, const FileHistory* fh)
const {
const RevMap& r = (fh ? fh->revs : revData->revs);
- return (sha.latin1() ? r.value(sha) : NULL);
+ return (sha.isEmpty() ? NULL : r.value(sha));
}
bool Git::run(SCRef runCmd, QString* runOutput, QObject* receiver,
SCRef buf) {
diff --git a/src/namespace_def.cpp b/src/namespace_def.cpp
index 80c2551..2960c36 100644
--- a/src/namespace_def.cpp
+++ b/src/namespace_def.cpp
@@ -95,7 +95,7 @@ static inline uint hexVal(const uchar* ch) {
uint qHash(const ShaString& s) { // fast path, called 6-7 times per
revision
- const uchar* ch = reinterpret_cast<const uchar*>(s.latin1());
+ const uchar* ch = reinterpret_cast<const uchar*>(s.data());
return (hexVal(ch ) << 24)
+ (hexVal(ch + 2) << 20)
+ (hexVal(ch + 4) << 16)
^ permalink raw reply related
* Re: [PATCH] commit: fix too generous RFC-2822 footer handling
From: SZEDER Gábor @ 2009-11-04 15:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: David Brown, git
In-Reply-To: <7vljimlsza.fsf@alter.siamese.dyndns.org>
Hi,
On Tue, Nov 03, 2009 at 10:11:21PM -0800, Junio C Hamano wrote:
> That looks overly convoluted.
I figured that the function ends_rfc2822_footer() should tell us
whether the message, well, ends with an rfc2822 _footer_. But since
it may say so even if there is only a single line in the commit
message, I thought this function should be fixed in the first place.
But yeah, that solution was unnecessarily complicated, after a good
night's sleep I would do it this way:
diff --git a/builtin-commit.c b/builtin-commit.c
index beddf01..c7dcbd0 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -428,6 +428,8 @@ static int ends_rfc2822_footer(struct strbuf *sb)
break;
hit = (buf[i] == '\n');
}
+ if (i == 0) /* one-line message */
+ return 0;
while (i < len - 1 && buf[i] == '\n')
i++;
> Why isn't the attached patch enough?
>
> - We inspected the last line of the message buffer, and 'i' is at the
> beginning of that last line;
>
> - At the line that begins at 'i', we found something that does not match
> the sob we are going to add;
>
> - We want a newline if it is a single liner (i.e. i == 0), or if that
> last one is not sob/acked-by and friends.
You are right in that there is no need to look for an rfc-2822
formatted footer when the commit message has only a single line. But
ends_rfc2822_footer() still not completely behaves as its name would
suggest (i.e. it might match even if there is no footer). Perhaps it
could just be renamed to ends_rfc282().
Best,
Gábor
^ permalink raw reply related
* [PATCH] MSVC: Windows-native implementation for subset of Pthreads API
From: Andrzej K. Haczewski @ 2009-11-04 15:55 UTC (permalink / raw)
To: git; +Cc: Johannes Sixt, Andrzej K. Haczewski
In-Reply-To: <1257331059-26344-1-git-send-email-ahaczewski@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 | 8 ++-
builtin-pack-objects.c | 41 +++++++++++++-
compat/mingw.c | 2 +-
compat/mingw.h | 5 ++
compat/win32/pthread.h | 136 ++++++++++++++++++++++++++++++++++++++++++++++++
git-compat-util.h | 10 ++++
preload-index.c | 4 +-
7 files changed, 198 insertions(+), 8 deletions(-)
create mode 100644 compat/win32/pthread.h
diff --git a/Makefile b/Makefile
index 521e8a5..14c371c 100644
--- a/Makefile
+++ b/Makefile
@@ -939,7 +939,8 @@ ifdef MSVC
OBJECT_CREATION_USES_RENAMES = UnfortunatelyNeedsTo
NO_REGEX = YesPlease
NO_CURL = YesPlease
- NO_PTHREADS = YesPlease
+ THREADED_DELTA_SEARCH = YesPlease
+ NO_STATIC_PTHREADS_INIT = YesPlease
BLK_SHA1 = YesPlease
CC = compat/vcbuild/scripts/clink.pl
@@ -947,7 +948,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 =
@@ -1293,6 +1294,9 @@ ifdef THREADED_DELTA_SEARCH
BASIC_CFLAGS += -DTHREADED_DELTA_SEARCH
LIB_OBJS += thread-utils.o
endif
+ifdef NO_STATIC_PTHREADS_INIT
+ COMPAT_CFLAGS += -DNO_STATIC_PTHREADS_INIT
+endif
ifdef DIR_HAS_BSD_GROUP_SEMANTICS
COMPAT_CFLAGS += -DDIR_HAS_BSD_GROUP_SEMANTICS
endif
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 02f9246..f297d82 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -1592,7 +1592,34 @@ struct thread_params {
static pthread_cond_t progress_cond = PTHREAD_COND_INITIALIZER;
-static void *threaded_find_deltas(void *arg)
+/*
+ * For platforms that do support static pthreads initialization
+ * make these noops.
+ */
+#ifndef NO_STATIC_PTHREADS_INIT
+# define init_threaded_delta_search()
+# define cleanup_threaded_delta_search()
+#else
+static void init_threaded_delta_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_delta_search()
+{
+ /* cleanup Windows threads thingies */
+ pthread_cond_destroy(&progress_cond);
+ pthread_mutex_destroy(&read_mutex);
+ pthread_mutex_destroy(&cache_mutex);
+ pthread_mutex_destroy(&progress_mutex);
+
+}
+#endif
+
+static THREAD_RET_TYPE threaded_find_deltas(void *arg)
{
struct thread_params *me = arg;
@@ -1620,7 +1647,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,
@@ -2327,6 +2354,8 @@ int cmd_pack_objects(int argc, const char **argv, const char *prefix)
#ifdef THREADED_DELTA_SEARCH
if (!delta_search_threads) /* --threads=0 means autodetect */
delta_search_threads = online_cpus();
+
+ init_threaded_delta_search();
#endif
prepare_packed_git();
@@ -2345,7 +2374,7 @@ int cmd_pack_objects(int argc, const char **argv, const char *prefix)
stop_progress(&progress_state);
if (non_empty && !nr_result)
- return 0;
+ goto cleanup;
if (nr_result)
prepare_pack(window, depth);
write_pack_file();
@@ -2353,5 +2382,11 @@ int cmd_pack_objects(int argc, const char **argv, const char *prefix)
fprintf(stderr, "Total %"PRIu32" (delta %"PRIu32"),"
" reused %"PRIu32" (delta %"PRIu32")\n",
written, written_delta, reused, reused_delta);
+
+cleanup:
+#ifdef THREADED_DELTA_SEARCH
+ cleanup_threaded_delta_search();
+#endif
+
return 0;
}
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..a71b90f
--- /dev/null
+++ b/compat/win32/pthread.h
@@ -0,0 +1,136 @@
+/*
+ * 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;
+
+#define PTHREAD_COND_INITIALIZER { 0, { 0 }, NULL }
+
+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_INITIALIZER { 0 }
+
+#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: Sitaram Chamarty @ 2009-11-04 16:41 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0911041422170.2788@felix-maschine>
Hi Johannes,
On Wed, Nov 4, 2009 at 6:55 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> I did not have time yet to investigate, but it seems that there are
> problems with the permissions of shared bare repositories when activating
> the reflogs.
Interesting; I will try and investigate if I can find something.
> With gitweb on a public site, there might be a problem when you pushed
> some blob containing trade secrets accidentally, and try to scrub the
> repository using "git gc" after a forced push.
Agreed. This config variable is biased to *keep* data if set to true,
and (default) false value is biased not to keep that same data, so
that will always be a conflict.
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.
Regards,
Sitaram
^ permalink raw reply
* Re: [PATCH v2] commit -c/-C/--amend: reset timestamp and authorship to committer with --reset-author
From: Erick Mattos @ 2009-11-04 16:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpr7ykbh8.fsf@alter.siamese.dyndns.org>
2009/11/4 Junio C Hamano <gitster@pobox.com>:
> Erick Mattos <erick.mattos@gmail.com> writes:
>
>> Cutting --author away would make impossible for someone to force a new author
>> with a new timestamp in case he is templating. As an example he can be using
>> the --author because he is doing a change in a computer not his own or
>> something alike.
>
> Sorry, but I cannot help feeling a bit frustrated and mildly irritated.
>
> I had an impression that we have already established that setting the
> author with --author="Somebody Else <s@b.e>" and committing with the
> current time does not make much sense from the workflow point of view long
> time ago in this thread.
>
> The mail transport might have mangled the name, and when using --amend (or
> read-tree followed by commit -c), it is handy to fix the mangled name by
> using --author, but in such a case you would actively want to keep the
> timestamp obtained from the e-mail via either --amend or -c.
>
> But allowing this combination, even though it might not make much sense,
> is just giving extra length to the rope, so it may not be such a big deal.
I don't see a reason to be hassled by a suggestion, made because I
didn't really was confident you got it right from me from the previous
email flood. No big deal.
> I didn't feel motivated enough to read the whole thing while other patches
> are in my inbox, so I instead ran diff between the previous one (without
> my suggestion today) and this round.
I really can't imagine all the work you have. Probably very hard.
As we were doing before, you were saying what was wrong to you and I
was fixing it to your
demands. So I imagine that you are doing the diffs over my versions.
I haven't got a change in that way of working.
> I see that you fixed a lot of grammar in the log message of my earlier
> suggestion, all of which looked very good. Also you added a check in the
> program to make sure that --renew is given only when -C/-c/--amend is
> given, which is also good. Neither of our set of tests checks this
> condition, though. IOW, we would need to add something like this at the
> end of my version (adjust to --reset-author for your version):
>
> test_expect_success '--mine should be rejected without -c/-C/--amend' '
> git checkout Initial &&
> echo "Test 7" >>foo &&
> test_tick &&
> test_must_fail git commit -a --mine -m done
> '
>
> I am not sure why you insist to use your version of test script and keep
> changing it, though. It looks a lot worse even only after reviewing its
> early part.
As I told you before I thought you were wanting me to do it. I didn't
get a change about me working under your supervision as the coder...
I know anyone in this list is able to code those or any other change.
It is just about who is available to work at anything in particular.
> - author_id runs an extra grep that is unnecessary. The separation of
> _id and _timestamp are unnecessary if you checked against an expected
> author ident and timestamp as a single string, i.e.
author_id or author_timestamp could be changed independently and a
single string would find it corrected in any case. The new option
ought to change both as expected in the algorithm.
> FRIGATE='Frigate <flying@over.world>' ;# do this only once at the beginning
> ...
> git commit -C HEAD --reset-author --author="$FRIGATE" &&
> echo "author $FRIGATE $GIT_AUTHOR_TIME" >expect &&
> author_header HEAD >actual &&
> test_cmp expect actual
If you make my script fail in any of the checks then you are going to
have "trash..." folder holding the full message log history and the
file foo with each step recorded on it with the "initials" separating
the -C, -c and --amend. This way you can also check the differences
in the author log timestamp among cited options because the "initials"
make a barrier in between. I made it purposely to become easier to
audit.
> This becomes irrelevant if we don't support mixing --renew and
> --author, of course.
It won't be supported.
> - message_body() now has a backslash whose sole purpose is to be an
> eyesore.
No backslash then.
> - initiate_test() does not string the commands together with &&
It is not something difficult to add.
> I might change my mind after I take a break, review others' patches, and
> spend some time on my own hacking on other topics before revisiting this
> patch, but at this point I find that reviewing newer rounds of this series
> has rather quickly diminishing value, and more time is being spent on
> teaching shell scripting to you rather than on polishing the end result.
Now you are being impolite and then I am not saying anything back.
> Sorry, but I cannot help feeling a bit frustrated and mildly irritated.
> Time to take a break and attend other topics for a change.
>
Again: I don't see a reason to be irritated by a suggestion...
Sorry fellow. I just tried to help. Let me know if you want my work anytime.
And sorry for any communication problem we had, taking in account that
I am not a native english speaker.
Best regards.
^ permalink raw reply
* Re: [PATCH] gitk: disable checkout of remote branch
From: Sitaram Chamarty @ 2009-11-04 16:46 UTC (permalink / raw)
To: Tim Mazid; +Cc: git
In-Reply-To: <1257325697830-3943894.post@n2.nabble.com>
On Wed, Nov 4, 2009 at 2:38 PM, Tim Mazid <timmazid@hotmail.com> wrote:
> Hm. I actually meant inside gitk, not git itself. As in, when you click
> inside gitk and try to checkout a remote, it automatically creates a
> tracking branch and checks THAT out instead, whereas command-line git works
> the same way.
> Does that even make sense? :P
It certainly does. And if gitk is internally running the same
"checkout" command that may happen automatically (in 1.7 or whatever).
I will "watch this space" as they say :) I stated only my minimum
needs (prevent detached HEAD with even less warning [i.e., zero
warning] than in CLI) and managed minimum code for it. But any other
solution that achives the same effect is also fine!
^ permalink raw reply
* Re: thoughts on setting core.logAllRefUpdates default true for bare repos
From: demerphq @ 2009-11-04 17:15 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: Johannes Schindelin, git
In-Reply-To: <2e24e5b90911040841l7741787et48fabb8c8066e946@mail.gmail.com>
2009/11/4 Sitaram Chamarty <sitaramc@gmail.com>:
> Hi Johannes,
>
> On Wed, Nov 4, 2009 at 6:55 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>
>> I did not have time yet to investigate, but it seems that there are
>> problems with the permissions of shared bare repositories when activating
>> the reflogs.
>
> Interesting; I will try and investigate if I can find something.
Assuming you mean via ssh access then if there is we haven't noticed
the problems at $work, and we have had this setup from the first time
somebody did a forced push and broke things, which was like day 3 or
something of our switchover to git from cvs, which is about two years
ago.
IMO it would be nice if the reflog could be set to ONLY record forced
updates. This would make a lot of sense on a bare repo.
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
^ permalink raw reply
* Re: [PATCH v2] format-patch: autonumber by default
From: Junio C Hamano @ 2009-11-04 17:38 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Brian Gernhardt, Git List, Giuseppe Bilotta, Jakub Narebski,
Johannes Schindelin, Shawn O. Pearce, Andreas Ericsson
In-Reply-To: <m1ws261qqi.fsf@fess.ebiederm.org>
ebiederm@xmission.com (Eric W. Biederman) writes:
> Brian Gernhardt <benji@silverinsanity.com> writes:
>
>> format-patch is most commonly used for multiple patches at once when
>> sending a patchset, in which case we want to number the patches; on
>> the other hand, single patches are not usually expected to be
>> numbered.
>>
>> In other words, the typical behavior expected from format-patch is the
>> one obtained by enabling autonumber, so we set it to be the default.
>>
>> Users that want to disable numbering for a particular patchset can do
>> so with the existing -N command-line switch. Users that want to
>> change the default behavior can use the format.numbering config key.
>>
>> Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
>> ---
>
>
> Grumble. I updated git last night and this change just bit me.
> Grumble.
> Grumble.
>
> It is probably a good change, but it was unexpected.
> Grumble. Grumble. Grumble.
That change was in 1.6.1.1 or so, no? Welcome to year 2009 ;-)
Out of curiousity, which version did you update _from_?
^ permalink raw reply
* Re: Accessing the reflog remotely
From: Nicolas Pitre @ 2009-11-04 17:46 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqljimpr95.fsf@bauges.imag.fr>
On Wed, 4 Nov 2009, Matthieu Moy wrote:
> Hi,
>
> I guess the answer is "no", but I'll still ask in case ...
>
> Is it possible to access the reflog of a remote repository other than
> logging into this repository?
No.
> My use-case is the following: I want to checkout "the last revision
> pushed in master on ssh://host/repo/ on day D at midnight" (to fetch
> the project of my students ;-) ). If it were locally, I'd do
>
> git checkout 'origin/master@{Nov 3 00:00:00}'
>
> But this tells me where _my_ local master was on that date (i.e. the
> last revision I had pulled).
You could checkout the first revision which committer's date is older
than midnight. Of course that means you have to trust that students
didn't mess up with time stamps.
Nicolas
^ permalink raw reply
* Re: Accessing the reflog remotely
From: Sverre Rabbelier @ 2009-11-04 17:55 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqljimpr95.fsf@bauges.imag.fr>
Heya,
On Wed, Nov 4, 2009 at 10:35, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:
> My use-case is the following: I want to checkout "the last revision
> pushed in master on ssh://host/repo/ on day D at midnight" (to fetch
> the project of my students ;-) ). If it were locally, I'd do
I think your best bet here would be to either run a cronjob at the
target time that tags all submissions, or to deny pushes after the
target time with a pre-push hook.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH v2] format-patch: autonumber by default
From: Brian Gernhardt @ 2009-11-04 17:48 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Git List, Giuseppe Bilotta, Jakub Narebski, Johannes Schindelin,
Shawn O. Pearce, Andreas Ericsson
In-Reply-To: <m1ws261qqi.fsf@fess.ebiederm.org>
On Nov 4, 2009, at 6:20 AM, Eric W. Biederman wrote:
> Grumble. I updated git last night and this change just bit me.
> Grumble.
> Grumble.
>
> It is probably a good change, but it was unexpected.
> Grumble. Grumble. Grumble.
The change is a year old, and mentioned in the release notes from
1.6.1. If you're updating from old versions of git, it can be
extremely useful to read the release notes as we do periodically have
changes like this. (In the git repository, they can be found as
Documentation/RelNotes-*.txt)
If you wish to go back to the old default for a single project, use
`git config format.numbered false`. If you use the --global flag, it
will set it for you all the time. For a single set of unrelated
patches being output at once, use the --no-numbered (short: -N) option
to format-patch.
Sorry it caught you unawares. Having it auto-number seemed like the
most useful default.
~~ Brian
^ permalink raw reply
* Re: [PATCH] gitk: disable checkout of remote branch
From: Junio C Hamano @ 2009-11-04 18:03 UTC (permalink / raw)
To: Jeff King; +Cc: Sverre Rabbelier, Tim Mazid, git
In-Reply-To: <20091104072709.GC24263@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Wed, Nov 04, 2009 at 07:41:28AM +0100, Sverre Rabbelier wrote:
>
>> On Wed, Nov 4, 2009 at 07:17, Tim Mazid <timmazid@hotmail.com> wrote:
>> > So instead of invoking 'git checkout REMOTE/BRANCH', do 'git checkout -b
>> > BRANCH REMOTE/BRANCH'.
>>
>> Automagically doing 'git checkout -t remote/branch' when asked to do
>> 'git checkout remote/branch' was suggested earlier on the list and I
>> think there was even a patch that implemented it, not sure what the
>> outcome of the series was. I do remember that Peff was annoyed by it
>> at the GitTogether though so it might be a bad idea.
>
> It's in 'next' now.
Isn't it quite different? What's in 'next' for 1.7.0 is to guess the
user's intention when:
- he says 'git checkout BRANCH'; and
- BRANCH does not yet exist; and
- BRANCH does not name a commit so the request cannot be to detach HEAD
at some commit (like REMOTE/BRANCH); and
- there is a unique REMOTE that has BRANCH.
The user wants to check out his own BRANCH (the request lacks REMOTE to
start with) but such a branch does not exist yet, and there is only one
sensible commit to start that new branch, hence we DWIM it and helpfully
run "git branch -t BRANCH REMOTE/BRANCH" automatically before performing
"git checkout BRANCH" that was asked.
We never claim to allow checking out the remote tracking branch itself.
The new guessing is only about a local branch that does not exist yet.
> ... I am still not convinced that we won't later regret leaving the
> stale local branch sitting around, or that users won't find it confusing
> to see:
>
> $ git checkout foo
> Branch foo set up to track remote branch foo from origin.
> Switched to a new branch 'foo'
>
> ... time passes ...
>
> $ git checkout foo
> Switched to branch 'foo'
> Your branch is behind 'origin/foo' by 1 commit, and can be fast-forwarded.
>
> (i.e., you do the same thing, but get two very different results,...
I think this is primarily because the way this DWIM is totally silent in
the transcript is misleading. If you explain it the way I outlined above,
I do not think there is any confusion. That is, there is no way for the
user to get confused if the command sequence were like so:
$ git branch -t foo origin/foo
Branch foo set up to track remote branch foo from origin.
$ git checkout foo
Switched to a new branch 'foo'
... time passes ...
$ git checkout foo
Switched to branch 'foo'
Your branch is behind 'origin/foo' by 1 commit, and can be fast-forwarded.
It could just be a matter of telling what we are doing a bit more
explicitly when this DWIM kicks in. How about this?
$ git checkout foo
(first forking your own 'foo' from 'origin/foo')
Branch foo set up to track remote branch foo from origin.
Switched to a new branch 'foo'
In any case, I do not think the DWIM would kick in when you try to detach
at remote branch head. I did not check gitk code to find out the exact
command line it uses, but I do not think it runs "checkout BRANCH". The
command needs to be at least "checkout REMOTE/BRANCH" to work the way it
does now with any released version of git, and I would not be surprised if
paulus was cautious enough to have spelled it as "refs/REMOTE/BRANCH" to
avoid any potential ambiguity issues.
^ permalink raw reply
* Re: Accessing the reflog remotely
From: Junio C Hamano @ 2009-11-04 18:03 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqljimpr95.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> I guess the answer is "no", but I'll still ask in case ...
>
> Is it possible to access the reflog of a remote repository other than
> logging into this repository?
>
> My use-case is the following: I want to checkout "the last revision
> pushed in master on ssh://host/repo/ on day D at midnight" (to fetch
> the project of my students ;-) ). If it were locally, I'd do
This won't solve your problem but I'll mention it anyway as it may be
related.
A distribution point repository like this is often bare, and reflogs are
not enabled in bare repositories (primarily due to my stupidity^Wbeing
overly cautious---I was very skeptical about reflogs when we introduced
it). It may make sense to enable reflogs everywhere by default in some
major version bump.
Also a distribution point repository is often served by gitweb and it
would be really nice if there were an option to allow its summary view
to show commits annotated with reflog entries, e.g.
----------------------------------------------------------------
2 days ago JCH Merge branch 'maint'
(pushed 6 hrs ago)
----------------------------------------------------------------
2 days ago DVL Makefile: add compat/bswap.h to LIB_H
----------------------------------------------------------------
3 days ago JCH Revert "Don't create the $GIT_DIR/branches directory on init"
(pushed 60 hours ago)
----------------------------------------------------------------
4 days ago JCH fixup tr/stash-format merge
----------------------------------------------------------------
...
^ permalink raw reply
* Re: Automatically remote prune
From: Junio C Hamano @ 2009-11-04 18:04 UTC (permalink / raw)
To: John Tapsell; +Cc: Git List
In-Reply-To: <43d8ce650911040242l44bbf87dm35494e04ce9039aa@mail.gmail.com>
John Tapsell <johnflux@gmail.com> writes:
> $> git branch -r
> origin/blah1 [Deleted]
> origin/blah2
>
> (Some branches have been deleted on the remote server. Use "git
> remote prune origin" to remove these)
There is no information locally available to do this, unless you are
willing to contact the remote every time somebody says "branch -r" (or
"branch -a"). I tend to think it is not very nice for the branch command
that has long been a "local" command to suddenly start talking to outside
world.
You could store necessary information somewhere else when you contacted
the remote the last time, but we need to consider what the benefits are to
give this information in the first place.a
The [Deleted] mark in your suggestion tells the user:
This is already removed in the remote, and this tracking copy is the
only way for you to view it ever again. Do not run 'remote prune
origin' blindly otherwise you will lose it.
But that is already possible with "git remote show origin", isn't it?
^ permalink raw reply
* [PATCH 0/2] Set Makefile variables from configure
From: Ben Walton @ 2009-11-04 18:05 UTC (permalink / raw)
To: gitster, jrnieder, git; +Cc: Ben Walton
In-Reply-To: <20091103222123.GA17097@progeny.tock>
Ok, a second attempt, taking into account Jonathan's feedback and
proposed updates. The revised macro allows for specified help text.
I opted to use a more 'dry' approach to the macro instead of repeating
the boilerplate AC_WITH_ARG bits when calling this feature.
Additionally, I only WARN when 'yes' or 'no' is passed. Bailing on
errors in most cases is reasonable, but I don't think it's globally
appropriate.
As to why I want this...It's cleaner, in my opinion, to do all build
configuration through a single mechanism than to do most with
./configure and the rest with variables passed to make. In other
words, this is purely a style issue.
I like the extension of config.mak.in to support more of the autoconf
variables as well and would like to see it applied.
Ben Walton (2):
configure: add macro to set arbitrary make variables
configure: add settings for gitconfig, editor and pager
configure.ac | 43 +++++++++++++++++++++++++++++++++++++++++++
1 files changed, 43 insertions(+), 0 deletions(-)
^ permalink raw reply
* [PATCH 1/2] configure: add macro to set arbitrary make variables
From: Ben Walton @ 2009-11-04 18:05 UTC (permalink / raw)
To: gitster, jrnieder, git; +Cc: Ben Walton
In-Reply-To: <1257357960-12763-1-git-send-email-bwalton@artsci.utoronto.ca>
Add macro GIT_PARSE_WITH_SET_MAKE_VAR to configure.ac to allow --with
style options that set values for variables used during the make
process.
Arguments are the $name part of --with-$name, the name of
the variable to set in the Makefile (config.mak.autogen) and
the help text for the option.
Signed-off-by: Ben Walton <bwalton@artsci.utoronto.ca>
---
configure.ac | 20 ++++++++++++++++++++
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/configure.ac b/configure.ac
index 84b6cf4..a305d0b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -68,6 +68,26 @@ else \
GIT_CONF_APPEND_LINE(${PACKAGE}DIR=$withval); \
fi \
])# GIT_PARSE_WITH
+#
+# GIT_PARSE_WITH_SET_MAKE_VAR(WITHNAME, VAR, HELP_TEXT)
+# ---------------------
+# Set VAR to the value specied by --with-WITHNAME.
+# No verification of arguments is performed, but warnings are issued
+# if either 'yes' or 'no' is specified.
+# HELP_TEXT is presented when --help is called.
+# This is a direct way to allow setting variables in the Makefile.
+AC_DEFUN([GIT_PARSE_WITH_SET_MAKE_VAR],
+[AC_ARG_WITH([$1],
+ [AS_HELP_STRING([--with-$1=VALUE], $3)],
+ if test -n "$withval"; then \
+ if test "$withval" = "yes" -o "$withval" = "no"; then \
+ AC_MSG_WARN([You likely do not want either 'yes' or 'no' as]
+ [a value for $1 ($2). Maybe you do...?]); \
+ fi; \
+ \
+ AC_MSG_NOTICE([Setting $2 to $withval]); \
+ GIT_CONF_APPEND_LINE($2=$withval); \
+ fi)])# GIT_PARSE_WITH_SET_MAKE_VAR
dnl
dnl GIT_CHECK_FUNC(FUNCTION, IFTRUE, IFFALSE)
--
1.6.5.1
^ permalink raw reply related
* [PATCH 2/2] configure: add settings for gitconfig, editor and pager
From: Ben Walton @ 2009-11-04 18:06 UTC (permalink / raw)
To: gitster, jrnieder, git; +Cc: Ben Walton
In-Reply-To: <1257357960-12763-2-git-send-email-bwalton@artsci.utoronto.ca>
Use the new GIT_PARSE_WITH_SET_MAKE_VAR macro to allow configuration
settings for ETC_GITCONFIG, DEFAULT_PAGER and DEFAULT_EDITOR.
Signed-off-by: Ben Walton <bwalton@artsci.utoronto.ca>
---
configure.ac | 23 +++++++++++++++++++++++
1 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/configure.ac b/configure.ac
index a305d0b..78345eb 100644
--- a/configure.ac
+++ b/configure.ac
@@ -247,6 +247,29 @@ GIT_PARSE_WITH(iconv))
# change being considered an inode change from the update-index perspective.
#
+# Allow user to set ETC_GITCONFIG variable
+GIT_PARSE_WITH_SET_MAKE_VAR(gitconfig, ETC_GITCONFIG,
+ Use VALUE instead of /etc/gitconfig as the
+ global git configuration file.
+ If VALUE is not fully qualified it will be interpretted
+ as a path relative to the computed prefix at runtime.)
+
+#
+# Allow user to set the default pager
+GIT_PARSE_WITH_SET_MAKE_VAR(pager, DEFAULT_PAGER,
+ Use VALUE as the fall-back pager instead of 'less'.
+ This is used by things like 'git log' when the user
+ does not specify a pager to use through alternate
+ methods. eg: /usr/bin/pager)
+#
+# Allow user to set the default editor
+GIT_PARSE_WITH_SET_MAKE_VAR(editor, DEFAULT_EDITOR,
+ Use VALUE as the fall-back editor instead of 'vi'.
+ This is used by things like 'git commit' when the user
+ does not specify a preferred editor through other
+ methods. eg: /usr/bin/editor)
+
+#
# Define SHELL_PATH to provide path to shell.
GIT_ARG_SET_PATH(shell)
#
--
1.6.5.1
^ permalink raw reply related
* Re: [PATCH 0/2] Set Makefile variables from configure
From: Ben Walton @ 2009-11-04 18:07 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: gitster, git
In-Reply-To: <20091103222123.GA17097@progeny.tock>
[-- Attachment #1: Type: text/plain, Size: 504 bytes --]
Excerpts from Jonathan Nieder's message of Tue Nov 03 17:21:23 -0500 2009:
> Would the --sysconfdir option work for you here? Setting --sysconfdir
> currently does nothing, so the question is kind of moot without some
> change like this (untested):
I think this is a generally useful patch.
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH bg/format-patch-p-noop] log-tree: always add --- marker when options are patch and a stat
From: Junio C Hamano @ 2009-11-04 18:10 UTC (permalink / raw)
To: Jeff King; +Cc: Stephen Boyd, git, Björn Gustavsson
In-Reply-To: <20091104073731.GA15408@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
>> I don't imagine we want this option in the messaging group though.
>> Can you move it up?
>
> Thanks, good catch. I just tacked it onto the end, forgetting that we
> were using grouping. Junio, can you tweak it, or do you want a resend?
Just ater "no-binary" would be a good place for this to go; done.
^ permalink raw reply
* Re: [PATCH] MSVC: Windows-native implementation for subset of Pthreads API
From: Nicolas Pitre @ 2009-11-04 18:10 UTC (permalink / raw)
To: Andrzej K. Haczewski; +Cc: git, Johannes Sixt
In-Reply-To: <1257350100-29281-1-git-send-email-ahaczewski@gmail.com>
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.
> +static THREAD_RET_TYPE threaded_find_deltas(void *arg)
Why can't you just cast the function pointer in your pthread_create
wrapper instead? No one cares about the returned value anyway.
> @@ -2327,6 +2354,8 @@ int cmd_pack_objects(int argc, const char **argv, const char *prefix)
> #ifdef THREADED_DELTA_SEARCH
> if (!delta_search_threads) /* --threads=0 means autodetect */
> delta_search_threads = online_cpus();
> +
> + init_threaded_delta_search();
What about doing this at the beginning of ll_find_deltas() instead?
And similarly for cleanup_threaded_delta_search(): call it right before
leaving ll_find_deltas(). This way thread issues would remain more
localized. In fact I'd move the whole thing above in ll_find_deltas()
as well (separately from this patch though).
Nicolas
^ 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