* Re: Problem with "From:" line on "git format-patch" generated patches
From: André Goddard Rosa @ 2009-11-04 10:59 UTC (permalink / raw)
To: Jeff King; +Cc: Santi Béjar, Git Mailing List
In-Reply-To: <20091104084903.GA1137@coredump.intra.peff.net>
On 11/4/09, Jeff King <peff@peff.net> wrote:
> On Tue, Nov 03, 2009 at 04:06:39PM -0200, André Goddard Rosa wrote:
>
>> I'm not using any specific tool for inputting the git-format-patch,
>> but instead I'm sending the files generated by it through gmail as an
>> inlined patch in the email body.
>>
>> I like the convenience of format-patch for generating the patch files,
>> but in this case, formatting the header as rfc2047 is not necessary
>> and makes a funny/garbled output in my patch submission.
>>
>> Do you have a suggestion for my workflow?
>
> I don't think there's currently a way to turn off the rfc2047 from
> within format-patch. You can generate a single patch with the same
> format using:
>
> git log -1 -p --stat --summary \
> --pretty=tformat:'From: %an <%ae>%nDate: %aD%nSubject: [PATCH] %s%n%n%b'
>
> but it won't do nice things like putting one patch in each file.
>
> Probably it would make sense for format-patch to have an option to
> indicate that you are going to inline these patches into a different
> MUA. So drop the 'From' mbox header line, don't rfc2047 encode, and
> maybe some other behaviors. I do the same thing (including inline in
> mutt), but I just delete the unwanted lines manually, and fortunately my
> name doesn't contain any non-ascii characters. ;)
>
> -Peff
Hello, Peff!
It's good to know that I'm not alone on this. I think that should
be fairly easy, yes.
Thanks for helping!
Thank you all,
André
^ permalink raw reply
* Re: Accessing the reflog remotely
From: Tomas Carnecky @ 2009-11-04 10:58 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqljimpr95.fsf@bauges.imag.fr>
On Nov 4, 2009, at 10:35 AM, 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?
>
> 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).
Keep in mind that bare repos don't have reflogs by default, so unless
you enabled the reflog manually there is none.
tom
^ permalink raw reply
* Re: [PATCH] MSVC: port pthread code to native Windows threads
From: Andrzej K. Haczewski @ 2009-11-04 10:56 UTC (permalink / raw)
To: kusmabite; +Cc: git
In-Reply-To: <40aa078e0911040250k55fa1920g6eee5657c6e35345@mail.gmail.com>
2009/11/4 Erik Faye-Lund <kusmabite@googlemail.com>:
>
> Seeing how THREAD_RETURN is only called with NULL-parameter, perhaps
> it would be better to do this?
>
> +/*
> + * Properly defines thread routine for Windows and POSIX
> + */
> +#ifndef NO_PTHREADS
> +# ifndef _WIN32
> +# define THREAD_FUNC(f, a) void *f(void *a)
> +# define THREAD_RETURN() return NULL;
> +# else
> +# define THREAD_FUNC(f, a) DWORD __stdcall f(LPVOID a)
> +# define THREAD_RETURN() return 0;
> +# endif
> +#endif
Good point. Should I resubmit the patch again?
Andrew
^ permalink raw reply
* Re: Problem with "From:" line on "git format-patch" generated patches
From: André Goddard Rosa @ 2009-11-04 10:55 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Santi Béjar, Git Mailing List
In-Reply-To: <20091103225556.GA20160@progeny.tock>
On 11/3/09, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Hi André,
>
> André Goddard Rosa wrote:
>
>>> I'm not using any specific tool for inputting the git-format-patch,
>>> but instead I'm sending the files generated by it through gmail as an
>>> inlined patch in the email body.
>>>
>>> I like the convenience of format-patch for generating the patch files,
>>> but in this case, formatting the header as rfc2047 is not necessary
>>> and makes a funny/garbled output in my patch submission.
>
> The header fields git format-patch outputs are just intended as a
> starting point for the header of your mailing. It is more convenient
> to receive an e-mail with
>
> Delivered-to: maintainer@example.com
> Received: [...]
> Message-ID: <patch.sender.0001@example.com>
> Date: Tue, 03 Nov 2009 16:33:54 -0600
> From: Patch Sender <patch.sender@example.com>
> Subject: [PATCH] Fix one bug, add another
> Content-Type: text/plain; charset=us-ascii
>
> Blah blah blah
>
> than one in which the content includes some useless metadata that was
> already in the header. So you should just strip the header out from
> the body before sending.
>
> There are three common exceptions: 1) you might want to send a patch
> written by someone else, 2) you might want to mark a patch as written
> before it was sent, and 3) some people like to receive patches as
> attachments rather than inlined in messages. For the first two cases,
> the solution is to include the header fields to change in the body:
>
> From: Patch Writer <patch.writer@example.com>
> Date: Wed, 01 Apr 1970 01:23:45 +0100
>
> Blah blah blah
> ---
> Hi,
>
> Patch Writer wrote this patch a while ago that might be
> relevant. It needed a straightforward one-line change to
> apply and is otherwise unchanged.
>
> What do you think?
> [...]
>
> For the last case, I think it is most common to send unchanged 'git
> format-patch' output. But only the From, Date, and Subject fields
> are actually needed.
>
> I am not sure how well 'git am' copes with non-ascii characters in
> the pseudo-header lines: I would have guessed it could handle them
> both rfc2047-encoded and not, but I have not tried.
>
>> I really would like continuing having the convenience of using a web
>> access to my gmail for sending the patches, so I just need a way to
>> format the patches which makes it easy submitting them later. I'd like
>> to avoid using any other email client for that, if possible.
>
> Here, there is another danger: the Gmail web interface does not
> consider your whitespace precious, so it is very prone to mangling
> patches (especially with long lines).
>
> Documentation/SubmittingPatches [1] has some advice:
>
> | Gmail
> | -----
> |
> | GMail does not appear to have any way to turn off line wrapping in the web
> | interface, so this will mangle any emails that you send. You can however
> | use any IMAP email client to connect to the google imap server, and
> forward
> | the emails through that. Just make sure to disable line wrapping in that
> | email client. Alternatively, use "git send-email" instead.
> |
> | Submitting properly formatted patches via Gmail is simple now that
> | IMAP support is available. First, edit your ~/.gitconfig to specify your
> | account settings:
> |
> | [imap]
> | folder = "[Gmail]/Drafts"
> | host = imaps://imap.gmail.com
> | user = user@gmail.com
> | pass = p4ssw0rd
> | port = 993
> | sslverify = false
> |
> | You might need to instead use: folder = "[Google Mail]/Drafts" if you get
> an error
> | that the "Folder doesn't exist".
> |
> | Next, ensure that your Gmail settings are correct. In "Settings" the
> | "Use Unicode (UTF-8) encoding for outgoing messages" should be checked.
> |
> | Once your commits are ready to send to the mailing list, run the following
> | command to send the patch emails to your Gmail Drafts folder.
> |
> | $ git format-patch -M --stdout origin/master | git imap-send
> |
> | Go to your Gmail account, open the Drafts folder, find the patch email,
> fill
> | in the To: and CC: fields and send away!
>
> Good luck.
>
> Hope that helps,
Hello, Jonatan!
Thanks for your insights, surely I understand what is reasoning behind it.
I expect this thread will be useful to others in the future. Here
goes another relevant reference about sending patches using web GUI of
gmail :
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/email-clients.txt;h=a618efab7b156658be70b29c1a6a9b9c4093e0f5;hb=HEAD
Thanks a lot,
André
^ permalink raw reply
* Re: [PATCH 1/1] MSVC: port pthread code to native Windows threads
From: Andrzej K. Haczewski @ 2009-11-04 10:53 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <4AF13819.7050306@viscovery.net>
2009/11/4 Johannes Sixt <j.sixt@viscovery.net>:
> Can't you just use the pthread package that is included in msysgit?
I don't like bloat, and msysgit is bloated. Sure, there are parts of
msysgit that are even heavier (bash, perl), but this will be removed
with further C'ification of scripts. I did what I thought could be
sensible for my first patch. I'm newbie after all.
>> + /* we're waiting... */
>> + EnterCriticalSection(&cond->waiters_lock);
>> + ++cond->waiters;
>> + LeaveCriticalSection(&cond->waiters_lock);
>> +
>> + /* unlock external mutex and wait for signal */
>> + LeaveCriticalSection(mutex);
>> + result = WaitForSingleObject(cond->sema, INFINITE);
>
> Releasing the mutex and entering the wait state as well as leaving the
> wait state and reacquiring the mutex should be atomic. Neither are in this
> implementation. You are not mentioning why you are implementing things
> like this and why this would be acceptable.
It's safe to do it like this here because we're serializing waiters
count and when signaling we make sure we have waiters before we
release semaphore. That implementation is based on ACE.
Andrew
^ permalink raw reply
* Re: [PATCH] MSVC: port pthread code to native Windows threads
From: Erik Faye-Lund @ 2009-11-04 10:50 UTC (permalink / raw)
To: Andrzej K. Haczewski; +Cc: git
In-Reply-To: <1257331059-26344-1-git-send-email-ahaczewski@gmail.com>
On Wed, Nov 4, 2009 at 11:37 AM, Andrzej K. Haczewski
<ahaczewski@gmail.com> wrote:
> +/*
> + * Properly defines thread routine for Windows and POSIX
> + */
> +#ifndef NO_PTHREADS
> +# ifndef _WIN32
> +# define THREAD_FUNC(f, a) void *f(void *a)
> +# define THREAD_RETURN(x) return (x)
> +# else
> +# define THREAD_FUNC(f, a) DWORD __stdcall f(LPVOID a)
> +# define THREAD_RETURN(x) return (DWORD)(x);
> +# endif
> +#endif
> +
Seeing how THREAD_RETURN is only called with NULL-parameter, perhaps
it would be better to do this?
+/*
+ * Properly defines thread routine for Windows and POSIX
+ */
+#ifndef NO_PTHREADS
+# ifndef _WIN32
+# define THREAD_FUNC(f, a) void *f(void *a)
+# define THREAD_RETURN() return NULL;
+# else
+# define THREAD_FUNC(f, a) DWORD __stdcall f(LPVOID a)
+# define THREAD_RETURN() return 0;
+# endif
+#endif
> +
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Automatically remote prune
From: John Tapsell @ 2009-11-04 10:42 UTC (permalink / raw)
To: Git List
Hi all,
Is there any particular reason why "git update" doesn't
automatically remove remote branches that have been removed on the
server? I keep getting questions about this from confused users.
If there's strong resistance against that (there usually is for
changing any default behaviour), could we at least mark deleted
branches?
So maybe:
$> 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)
Or something.
John
^ permalink raw reply
* [PATCH] MSVC: port pthread code to native Windows threads
From: Andrzej K. Haczewski @ 2009-11-04 10:37 UTC (permalink / raw)
To: git; +Cc: Andrzej K. Haczewski
In-Reply-To: <1257283802-29726-1-git-send-email-ahaczewski@gmail.com>
Here is slightly modified patch with more comments where explanations were
requested (ie. non atomic release mutex and wait).
The implementation of conditional variable is based on ACE.
The patch needs testing from someone capable of compiling Git on Windows
and running it with msysgit environment. I can confirm that it compiles
cleanly on both Linux and Windows. I modified Makefile only for MSVC
part, so if you'd like to compile it with mingw or cygwin, proper
corrections have to be made. I aim for native MSVC compilation, that's
why I did it like that. That's also the reason I don't like
having Pthreads for Win32 dependency - it's faster to use native
calls than depend on 3rd party wrapper library to do it for you
(ie. pthreads for win32 does allocations to implement POSIX
standard, and full-conformance isn't required by Git, since Git uses
only small subset of pthreads).
One more motivation I had for the patch: as I was reading through
archives I had a feeling that Git aims to be as lightweight
as possible, hence removing additional dependencies (even for
Windows platform) seems sensible to me.
Signed-off-by: Andrzej K. Haczewski <ahaczewski@gmail.com>
---
Makefile | 4 +-
builtin-pack-objects.c | 29 +++++++++-
compat/mingw.c | 2 +-
compat/win32/pthread.h | 143 ++++++++++++++++++++++++++++++++++++++++++++++++
git-compat-util.h | 13 ++++
preload-index.c | 4 +-
6 files changed, 187 insertions(+), 8 deletions(-)
create mode 100644 compat/win32/pthread.h
diff --git a/Makefile b/Makefile
index 521e8a5..450d8fe 100644
--- a/Makefile
+++ b/Makefile
@@ -939,7 +939,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
@@ -947,7 +947,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..c96d293 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -1592,7 +1592,7 @@ struct thread_params {
static pthread_cond_t progress_cond = PTHREAD_COND_INITIALIZER;
-static void *threaded_find_deltas(void *arg)
+static THREAD_FUNC(threaded_find_deltas, arg)
{
struct thread_params *me = arg;
@@ -1620,7 +1620,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;
+ THREAD_RETURN(NULL);
}
static void ll_find_deltas(struct object_entry **list, unsigned list_size,
@@ -2327,6 +2327,18 @@ 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();
+
+#ifdef _WIN32
+ /*
+ * Windows requires initialization of mutex (CRITICAL_SECTION)
+ * and conditional variable.
+ */
+ pthread_mutex_init(&read_mutex);
+ pthread_mutex_init(&cache_mutex);
+ pthread_mutex_init(&progress_mutex);
+ pthread_cond_init(&progress_cond, NULL);
+#endif
+
#endif
prepare_packed_git();
@@ -2345,7 +2357,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 +2365,16 @@ 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:
+#if defined(THREADED_DELTA_SEARCH) && defined(_WIN32)
+ /* 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
+
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/win32/pthread.h b/compat/win32/pthread.h
new file mode 100644
index 0000000..8f82d3c
--- /dev/null
+++ b/compat/win32/pthread.h
@@ -0,0 +1,143 @@
+/*
+ * 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>
+
+/*
+ * don't include mingw.h for err_win_to_posix function - mingw.h doesn't
+ * have include-guards
+ */
+extern int err_win_to_posix(DWORD winerr);
+
+/* Implement simple condition variable for Windows threads, based on ACE implementation */
+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 (NULL == cond->sema)
+ return -1;
+ 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)
+{
+ int ret = 0;
+
+ /* 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 */
+ if (0 != WaitForSingleObject(cond->sema, INFINITE))
+ ret = -1;
+
+ /* 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 ret;
+}
+
+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 : -1;
+ 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 *t, const void *unused, DWORD (__stdcall *start_routine)(LPVOID), void *arg)
+{
+ *t = CreateThread(NULL, 0, start_routine, arg, 0, NULL);
+
+ if (NULL == *t) {
+ errno = err_win_to_posix(GetLastError());
+ return -1;
+ } else {
+ errno = 0;
+ return 0;
+ }
+}
+
+static __inline int pthread_join(pthread_t t, void **unused)
+{
+ DWORD result = WaitForSingleObject(t, INFINITE);
+ switch (result) {
+ case WAIT_OBJECT_0:
+ errno = 0;
+ return 0;
+ case WAIT_ABANDONED:
+ errno = EINVAL;
+ return -1;
+ default:
+ errno = err_win_to_posix(GetLastError());
+ return -1;
+ }
+}
+
+#endif /* PTHREAD_H */
+
diff --git a/git-compat-util.h b/git-compat-util.h
index ef60803..202b90e 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -464,4 +464,17 @@ void git_qsort(void *base, size_t nmemb, size_t size,
*/
int unlink_or_warn(const char *path);
+/*
+ * Properly defines thread routine for Windows and POSIX
+ */
+#ifndef NO_PTHREADS
+# ifndef _WIN32
+# define THREAD_FUNC(f, a) void *f(void *a)
+# define THREAD_RETURN(x) return (x)
+# else
+# define THREAD_FUNC(f, a) DWORD __stdcall f(LPVOID a)
+# define THREAD_RETURN(x) return (DWORD)(x);
+# endif
+#endif
+
#endif
diff --git a/preload-index.c b/preload-index.c
index 9289933..ace10fe 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_FUNC(preload_thread, _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;
+ THREAD_RETURN(NULL);
}
static void preload_index(struct index_state *index, const char **pathspec)
--
1.6.5.2
^ permalink raw reply related
* Re: Accessing the reflog remotely
From: Emanuele Aina @ 2009-11-04 10:16 UTC (permalink / raw)
To: git
In-Reply-To: <vpqljimpr95.fsf@bauges.imag.fr>
Matthieu Moy provò:
> 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).
>
> So, the best I can think of is:
>
> ssh host 'cd /repo/ ; git tag final-version "master@{Nov 3 00:00:00}"'
> git fetch --tags
> git checkout tags/final-version
At least you can avoid the tag:
git checkout `ssh host 'GIT_DIR=/repo/ git rev-parse "master@{Nov 3 00:00:00}"'`
--
Buongiorno.
Complimenti per l'ottima scelta.
^ permalink raw reply
* Accessing the reflog remotely
From: Matthieu Moy @ 2009-11-04 9:35 UTC (permalink / raw)
To: git
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?
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).
So, the best I can think of is:
ssh host 'cd /repo/ ; git tag final-version "master@{Nov 3 00:00:00}"'
git fetch --tags
git checkout tags/final-version
Is there a better way?
Thanks,
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH] gitk: disable checkout of remote branch
From: Tim Mazid @ 2009-11-04 9:08 UTC (permalink / raw)
To: git
In-Reply-To: <20091104072709.GC24263@coredump.intra.peff.net>
Jeff King wrote:
>
> 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. And for the record, my complaint about its behavior
> turned out to be partially because I was an idiot. 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.
>
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
--
View this message in context: http://n2.nabble.com/PATCH-gitk-disable-checkout-of-remote-branch-tp3939363p3943894.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* What happened to [PATCH] Support "core.excludesfile = ~/.gitignore" ?
From: Matthieu Moy @ 2009-11-04 8:56 UTC (permalink / raw)
To: git, quarl
Hi,
I found a patch to manage ~ in core.excludesfile here:
http://thread.gmane.org/gmane.comp.version-control.git/93250
It seems the patch was abandonned by its author near here:
http://thread.gmane.org/gmane.comp.version-control.git/93250/focus=94318
Was there any particular reason for dropping the patch other than lack
of time? If not, I'll try to resurect it.
(I have core.excludesfile = /home/moy/.gitignore hardcoded, and I have
to edit it each time I teach Git to a colleague, that would be so much
better to have the same value "~/.gitignore" for everybody ...)
Thanks,
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: Problem with "From:" line on "git format-patch" generated patches
From: Jeff King @ 2009-11-04 8:49 UTC (permalink / raw)
To: André Goddard Rosa; +Cc: Santi Béjar, Git Mailing List
In-Reply-To: <b8bf37780911031006q4bc4c487xd9db86eb0fa531e7@mail.gmail.com>
On Tue, Nov 03, 2009 at 04:06:39PM -0200, André Goddard Rosa wrote:
> I'm not using any specific tool for inputting the git-format-patch,
> but instead I'm sending the files generated by it through gmail as an
> inlined patch in the email body.
>
> I like the convenience of format-patch for generating the patch files,
> but in this case, formatting the header as rfc2047 is not necessary
> and makes a funny/garbled output in my patch submission.
>
> Do you have a suggestion for my workflow?
I don't think there's currently a way to turn off the rfc2047 from
within format-patch. You can generate a single patch with the same
format using:
git log -1 -p --stat --summary \
--pretty=tformat:'From: %an <%ae>%nDate: %aD%nSubject: [PATCH] %s%n%n%b'
but it won't do nice things like putting one patch in each file.
Probably it would make sense for format-patch to have an option to
indicate that you are going to inline these patches into a different
MUA. So drop the 'From' mbox header line, don't rfc2047 encode, and
maybe some other behaviors. I do the same thing (including inline in
mutt), but I just delete the unwanted lines manually, and fortunately my
name doesn't contain any non-ascii characters. ;)
-Peff
^ permalink raw reply
* Re: [PATCH 1/1] MSVC: port pthread code to native Windows threads
From: Michael Wookey @ 2009-11-04 8:48 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Andrzej K. Haczewski, git
In-Reply-To: <4AF13819.7050306@viscovery.net>
2009/11/4 Johannes Sixt <j.sixt@viscovery.net>:
> Andrzej K. Haczewski schrieb:
>
>> +static __inline int win32_cond_init(win32_cond_t *cond)
>> +{
>> + cond->waiters = 0;
>> +
>> + InitializeCriticalSection(&cond->waiters_lock);
>> +
>> + cond->sema = CreateSemaphore(NULL, 0, LONG_MAX, NULL);
>
> Wouldn't an Event object be lighter-weight? (I'm only guessing.)
Both events and semaphores resolve to wait-able kernel objects; so
neither is "lighter-weight" than the other.
^ permalink raw reply
* Re: [PATCH 1/1] MSVC: port pthread code to native Windows threads
From: Johannes Sixt @ 2009-11-04 8:24 UTC (permalink / raw)
To: Andrzej K. Haczewski; +Cc: git
In-Reply-To: <16cee31f0911032344m3263730l607c02eb4e9adef5@mail.gmail.com>
[please don't cull Cc list on this ML]
Andrzej K. Haczewski schrieb:
>> Pardon my ignorance, but is there a reason to not use Pthreads for Win32?
>> http://sourceware.org/pthreads-win32/
>>
>
> Not using pthreads on Windows makes Git:
> 1. faster on that platform
I believe this only if you present hard numbers. My guess is that (for
example) packing objects with two threads is still faster with a slow
pthreads emulation than without threading at all.
> 2. not depend on Pthreads for Win32
Why is this an advantage?
> IMHO that makes Git one step closer to become native on Windows, and
> is a sensible step.
Emulating pthreads on Windows with all its facets is an extremely
difficult task. If exact POSIX conformance is needed, I would choose an
existing package over doing it myself at any time.
Granted, we don't need the esoteric parts (cancelation points), which
would simplify the emulation a lot. But, as I pointed out in my other
mail, even a pthread_cond_wait() is not that trivial to implement with the
Windows API.
-- Hannes
^ permalink raw reply
* Re: [PATCH 1/1] MSVC: port pthread code to native Windows threads
From: Andrzej K. Haczewski @ 2009-11-04 8:17 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0911040031210.4985@pacific.mpi-cbg.de>
2009/11/4 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> Could you please add the reasoning from the cover letter to this commit
> message? And add a sign-off?
Sure, will do so for next submission of that patch.
> It is unlikely that an #ifdef "contamination" of this extent will go
> through easily, but I have a suggestion that may make your patch both
> easier to read and more likely to be accepted into git.git: Try to wrap
> the win32 calls into pthread-compatible function signatures. Then you can
> add a compat/win32/pthread.h and not even touch core files of git.git at
> all.
First of all I didn't want to use wrappers because (if not inlined)
they introduce one additional call, that can be avoided with #defines
(as you can see even pthread_init can be done with macro). Second
reason is that I didn't want to create wrapping structures that would
need to be initialized / allocated / tracked. That patch translates
pthread calls to purely Win32 calls without anything in between.
Here are my reasoning for some of these #ifdefs and what can be done
and what can't (without using wrappers):
1. Thread routine has very different signature:
void *__cdecl func(void *); /* pthreads */
uint32_t __stdcall func(void *); /* Windows API */
First I thought it might be a problem to do (especially return value,
which is different size for 64-bit architectures), but since Git
doesn't use return value, it can be done.
2. Initialization of CRITICAL_SECTION and SEMAPHORE (used by condition
variables implementation). These need explicit initialization on
Windows and can't be done statically with PTHREAD_MUTEX_INITIALIZER
and PTHREAD_COND_INITIALIZER. There's no easy way around that (read:
it needs wrappers).
> Oh, and you definitely do not want to copy-paste err_win_to_posix(). You
> definitely want to reuse the existing instance.
Yeah, that was lazy, mea culpa.
I'll resubmit the patch with some fixes shortly,
Andrew
^ permalink raw reply
* Re: [PATCH 1/1] MSVC: port pthread code to native Windows threads
From: Johannes Sixt @ 2009-11-04 8:15 UTC (permalink / raw)
To: Andrzej K. Haczewski; +Cc: git
In-Reply-To: <1257283802-29726-2-git-send-email-ahaczewski@gmail.com>
Andrzej K. Haczewski schrieb:
> ---
You should sign-off your patches.
> #ifdef THREADED_DELTA_SEARCH
> -#include "thread-utils.h"
> -#include <pthread.h>
> +# include "thread-utils.h"
> +# ifndef _WIN32
> +# include <pthread.h>
> +# else
> +# include <winthread.h>
> +# endif
> #endif
Can't you just use the pthread package that is included in msysgit?
> +#ifndef _WIN32
> static void *threaded_find_deltas(void *arg)
> +#else
> +static DWORD WINAPI threaded_find_deltas(LPVOID arg)
> +#endif
> ...
> +#ifndef _WIN32
> return NULL;
> +#else
> + return 0;
> +#endif
> etc ...
You have far too many #ifdef in the generic code. There must be a better
way to hide the implementation details of this emulation.
> +#ifdef _WIN32
> + /*
> + * Windows require initialization of mutex (CRITICAL_SECTION)
> + * and conditional variable.
> + */
> + pthread_mutex_init(&read_mutex);
> + pthread_mutex_init(&cache_mutex);
> + pthread_mutex_init(&progress_mutex);
> + win32_cond_init(&progress_cond);
> +#endif
*If* we are going to use this minimal pthreads implementation, then I
think it will be OK to call pthread_*_init even on non-Windows.
> +static __inline int win32_cond_init(win32_cond_t *cond)
> +{
> + cond->waiters = 0;
> +
> + InitializeCriticalSection(&cond->waiters_lock);
> +
> + cond->sema = CreateSemaphore(NULL, 0, LONG_MAX, NULL);
Wouldn't an Event object be lighter-weight? (I'm only guessing.)
> + if (NULL == cond->sema)
> + return -1;
> + return 0;
> +}
> +
> +static __inline int win32_cond_destroy(win32_cond_t *cond)
> +{
> + CloseHandle(cond->sema);
> + cond->sema = NULL;
> +
> + DeleteCriticalSection(&cond->waiters_lock);
> +
> + return 0;
> +}
> +
> +static __inline int win32_cond_wait(win32_cond_t *cond, CRITICAL_SECTION *mutex)
And the reason that this is not pthread_cond_wait, is...?
> +{
> + DWORD result;
> + int ret = 0;
> +
> + /* we're waiting... */
> + EnterCriticalSection(&cond->waiters_lock);
> + ++cond->waiters;
> + LeaveCriticalSection(&cond->waiters_lock);
> +
> + /* unlock external mutex and wait for signal */
> + LeaveCriticalSection(mutex);
> + result = WaitForSingleObject(cond->sema, INFINITE);
Releasing the mutex and entering the wait state as well as leaving the
wait state and reacquiring the mutex should be atomic. Neither are in this
implementation. You are not mentioning why you are implementing things
like this and why this would be acceptable.
> +
> + if (0 != result)
> + ret = -1;
> +
> + /* one waiter less */
> + EnterCriticalSection(&cond->waiters_lock);
> + --cond->waiters;
> + LeaveCriticalSection(&cond->waiters_lock);
> +
> + /* lock external mutex again */
> + EnterCriticalSection(mutex);
> +/* almost copy-paste code of mingw.c */
> +static int err_win_to_posix()
> +{
There must be a better way than to just copy & paste this huge piece of code.
-- Hannes
^ permalink raw reply
* Re: [PATCH bg/format-patch-p-noop] log-tree: always add --- marker when options are patch and a stat
From: Björn Gustavsson @ 2009-11-04 7:49 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Stephen Boyd, git
In-Reply-To: <20091104071053.GB24263@coredump.intra.peff.net>
On Wed, Nov 4, 2009 at 8:10 AM, Jeff King <peff@peff.net> wrote:
> This patch goes on top of master, and terribly conflicts with Björn's
> changes in the area. But I had the impression you wanted to revert those
> changes for now anyway, so probably this should go in as a bug fix and
> everything else should be built on top. It actually would be an even
> smaller change on top of his "always show patch, even when other formats
> are given" change, but I didn't want to depend on it.
No problem. I can re-implement my patch series on top of your patch.
/Björn
--
Björn Gustavsson, Erlang/OTP, Ericsson AB
^ permalink raw reply
* Re: [PATCH 1/1] MSVC: port pthread code to native Windows threads
From: Andrzej K. Haczewski @ 2009-11-04 7:44 UTC (permalink / raw)
To: git
In-Reply-To: <4AF0E842.2010201@workspacewhiz.com>
>
> Pardon my ignorance, but is there a reason to not use Pthreads for Win32?
> http://sourceware.org/pthreads-win32/
>
Not using pthreads on Windows makes Git:
1. faster on that platform
2. not depend on Pthreads for Win32
IMHO that makes Git one step closer to become native on Windows, and
is a sensible step.
Andrew
^ permalink raw reply
* Re: [PATCH bg/format-patch-p-noop] log-tree: always add --- marker when options are patch and a stat
From: Jeff King @ 2009-11-04 7:37 UTC (permalink / raw)
To: Stephen Boyd; +Cc: Junio C Hamano, git, Björn Gustavsson
In-Reply-To: <4AF12EC5.4030407@gmail.com>
On Tue, Nov 03, 2009 at 11:35:33PM -0800, Stephen Boyd wrote:
> >@@ -940,6 +941,8 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
> > { OPTION_CALLBACK, 0, "thread", &thread, "style",
> > "enable message threading, styles: shallow, deep",
> > PARSE_OPT_OPTARG, thread_callback },
> >+ OPT_BOOLEAN('p', NULL, &use_patch_format,
> >+ "show patch format instead of default (patch + stat)"),
> > OPT_END()
> > };
>
> 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?
-Peff
^ permalink raw reply
* Re: [PATCH bg/format-patch-p-noop] log-tree: always add --- marker when options are patch and a stat
From: Stephen Boyd @ 2009-11-04 7:35 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git, Björn Gustavsson
In-Reply-To: <20091104071940.GA15011@coredump.intra.peff.net>
Jeff King wrote:
>
> This patch unbreaks what 68daa64 did (while still preserving
> what 68daa64 was trying to do), reinstating "-p" to suppress
> the default behavior. We do this by parsing "-p" ourselves
> in format-patch, and noting whether it was used explicitly.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
>
This looks good to me; covering 2 and 3 of Junio's TODO list.
> @@ -940,6 +941,8 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
> { OPTION_CALLBACK, 0, "thread", &thread, "style",
> "enable message threading, styles: shallow, deep",
> PARSE_OPT_OPTARG, thread_callback },
> + OPT_BOOLEAN('p', NULL, &use_patch_format,
> + "show patch format instead of default (patch + stat)"),
> OPT_END()
> };
I don't imagine we want this option in the messaging group though. Can
you move it up?
^ 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 7:31 UTC (permalink / raw)
To: Björn Gustavsson; +Cc: Stephen Boyd, git
In-Reply-To: <6672d0160911032300w1a2dfdbck5b1db98f2059639b@mail.gmail.com>
Björn Gustavsson <bgustavsson@gmail.com> writes:
> Since -p has been broken for 14 months, is really necessary to reinstate
> it? (Or has the breakage not been reported because the people who care
> still use a git version older than 14 months?)
Oh, 1.6.0 has the old behaviour and we see many people still on 1.5.X
series. Hopefully nobody uses 1.4.X series anymore but I wouldn't be
overly surprised if somebody raised hand in the next 6 hours after seeing
this message ;-)
> Why not just add a new --no-stat option?
I am all for teaching _new_ people to say "format-patch --no-stat", but it
won't help people who have been happy with 1.6.0 when they update, if they
have to change their "format-patch -p" to "format-patch --no-stat".
^ permalink raw reply
* Re: [PATCH] Require a struct remote in transport_get()
From: Daniel Barkalow @ 2009-11-04 7:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbpjin8v0.fsf@alter.siamese.dyndns.org>
On Tue, 3 Nov 2009, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > cmd_ls_remote() was calling transport_get() with a NULL remote and a
> > non-NULL url in the case where it was run outside a git
> > repository. This involved a bunch of ill-tested special
> > cases. Instead, simply get the struct remote for the URL with
> > remote_get(), which works fine outside a git repository, and can also
> > take global options into account.
> >
> > This fixes a tiny and obscure bug where "git ls-remote" without a repo
> > didn't support global url.*.insteadOf, even though "git clone" and
> > "git ls-remote" in any repo did.
> >
> > Also, enforce that all callers provide a struct remote to transport_get().
> >
> > Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
> > ---
> > This is sufficient to stop the segfault when tring "git ls-remote
> > http://..." outside of a repo, but not to make it work, which requires
> > either something simple but not ideal or something complex.
>
> Thanks; I think this and your other patch are important fixes, and should
> go directly on 'maint'. Do you prefer to queue them on 'next' to cook for
> a week instead?
I don't think a week on 'next' is likely to turn up any new information;
these are all uncommon code paths. It might be worth seeing if the
original reporter is happy with how it's behaving now, though.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] gitk: disable checkout of remote branch
From: Jeff King @ 2009-11-04 7:27 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Tim Mazid, git
In-Reply-To: <fabb9a1e0911032241u3735fa30heaa195d959879f5a@mail.gmail.com>
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. And for the record, my complaint about its behavior
turned out to be partially because I was an idiot. 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, and
you have to know how to do the fast-forward. Trivial if you are used to
working with branches, but perhaps not if you are just sightseeing).
But I am no longer planning on writing a long-winded rant about the
feature. ;)
-Peff
^ 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 7:26 UTC (permalink / raw)
To: Jeff King; +Cc: Stephen Boyd, git, Björn Gustavsson
In-Reply-To: <20091104063612.GA24263@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Tue, Nov 03, 2009 at 09:49:46PM -0800, Junio C Hamano wrote:
>
>> Even though I personally find the stat information very useful, I would be
>> happier if somebody reverts the bg/format-patch-p-noop series and instead
>> fixes the regression caused by 68daa64, and does so without touching any
>> output from the low-level plumbing like diff-tree that may be used by
>> scripts.
>
> I agree that 68daa64 is a hack (and I even noted in the commit log that
> "-p" is now a no-op).
Correct, and thanks---it was not your fault and I didn't mean to blame
you. If anything it was mine.
> The problem is that we don't have the one critical
> bit of information in cmd_format_patch that we do in diff_opt_parse: was
> the format set explicitly, or was it a side-effect of -U (or --binary,
> or maybe others).
The appoarch your "how about this" takes feels right. We did discuss "set
of hardwired defaults specific to the individual commands, that are masked
by set of defaults read from the config, that are in turn masked by set of
command line options", but I do not think that level of complexity is worth
for this "is it -U<n> or -p" issue.
> My test case checks the current output (i.e., missing dashes). I think
> it should probably have dashes, but that should be fixed in a separate
> patch.
Agreed.
^ 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