* Re: libgit2 - a true git library
From: Shawn O. Pearce @ 2008-11-01 1:52 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Junio C Hamano, Pieter de Bie, Pierre Habouzit, git, Scott Chacon
In-Reply-To: <alpine.LFD.2.00.0810312135190.13034@xanadu.home>
Nicolas Pitre <nico@cam.org> wrote:
> On Fri, 31 Oct 2008, Shawn O. Pearce wrote:
>
> > > Both the negative code and errno style are lightweight in the common "no
> > > error" case. The errno style is probably more handy for those functions
> > > returning a pointer which should be NULL in the error case.
> >
> > I'm sticking with return a negative code for now, to the extent
> > that some functions which return a pointer but also have many
> > common failure modes (e.g. git_odb_open) use an output parameter
> > as their first arg, so the error code can be returned as the result
> > of the function.
>
> Actually, the pointer-returning functions can encode error cases into a
> "negative" pointer. See include/linux/err.h for example.
>
> void *ptr = git_alloc_foo(...);
> if (IS_ERR(ptr))
> die("git_alloc_foo failed: %s", git_strerr(PTR_ERR(ptr)));
Oh, good point. We could also stagger the errors so they are
always odd, and never return an odd-alignment pointer from a
successful function. Thus IS_ERR can be written as:
#define IS_ERR(ptr) (((intptr_t)(ptr)) & 1)
which is quite cheap, and given the (probably required anyway)
aligned allocation policy means we still have 2^31 possible
error codes available.
--
Shawn.
^ permalink raw reply
* Re: libgit2 - a true git library
From: Nicolas Pitre @ 2008-11-01 1:53 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Pierre Habouzit, david, git
In-Reply-To: <20081101014336.GI14786@spearce.org>
On Fri, 31 Oct 2008, Shawn O. Pearce wrote:
> My take on the consensus for the license part of the discussion is
> that libgit2 should be under the "GPL gcc library" license.
>
> BTW, I can't actually find a copy of that license; the only thing
> I can locate in the GCC SVN tree is a copy of the LGPL.
The exception is usually found at the top of files constituting
libgcc.a. One example is gcc/config/arm/ieee754-df.S. ;-)
Nicolas
^ permalink raw reply
* [PATCH] connect.c: add a way for git-daemon to pass an error back to client
From: Tom Preston-Werner @ 2008-11-01 1:59 UTC (permalink / raw)
To: git; +Cc: gitster
The current behavior of git-daemon is to simply close the connection on
any error condition. This leaves the client without any information as
to the cause of the failed fetch/push/etc.
This patch allows get_remote_heads to accept a line prefixed with "ERR"
that it can display to the user in an informative fashion. Once clients
can understand this ERR line, git-daemon can be made to properly report
"repository not found", "permission denied", or other errors.
Example
S: ERR No matching repository.
C: fatal: remote error: No matching repository.
Signed-off-by: Tom Preston-Werner <tom@github.com>
---
connect.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/connect.c b/connect.c
index 0c50d0a..3af91d6 100644
--- a/connect.c
+++ b/connect.c
@@ -70,6 +70,9 @@ struct ref **get_remote_heads(int in, struct ref **list,
if (buffer[len-1] == '\n')
buffer[--len] = 0;
+ if (len > 4 && !memcmp("ERR", buffer, 3))
+ die("remote error: %s", buffer + 4);
+
if (len < 42 || get_sha1_hex(buffer, old_sha1) || buffer[40] != ' ')
die("protocol error: expected sha/ref, got '%s'", buffer);
name = buffer + 41;
--
1.6.0.2
^ permalink raw reply related
* Re: [PATCH] connect.c: add a way for git-daemon to pass an error back to client
From: Johannes Schindelin @ 2008-11-01 2:19 UTC (permalink / raw)
To: Tom Preston-Werner; +Cc: git, gitster
In-Reply-To: <b97024a40810311859t2e5a6102u31ad4480e7c75c03@mail.gmail.com>
Hi,
On Fri, 31 Oct 2008, Tom Preston-Werner wrote:
> The current behavior of git-daemon is to simply close the connection on
> any error condition. This leaves the client without any information as
> to the cause of the failed fetch/push/etc.
>
> This patch allows get_remote_heads to accept a line prefixed with "ERR"
> that it can display to the user in an informative fashion. Once clients
> can understand this ERR line, git-daemon can be made to properly report
> "repository not found", "permission denied", or other errors.
>
> Example
>
> S: ERR No matching repository.
> C: fatal: remote error: No matching repository.
Makes sense to me.
The cute trick with this is that even older clients would be able to
display the error, albeit with a sort of funny message:
protocol error: expected sha/ref, got 'No matching repository.'
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] connect.c: add a way for git-daemon to pass an error back to client
From: Tom Preston-Werner @ 2008-11-01 2:18 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <alpine.DEB.1.00.0811010316340.22125@pacific.mpi-cbg.de.mpi-cbg.de>
On Fri, Oct 31, 2008 at 7:19 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> The cute trick with this is that even older clients would be able to
> display the error, albeit with a sort of funny message:
>
> protocol error: expected sha/ref, got 'No matching repository.'
This is exactly what GitHub does right now with our custom Erlang
git-daemon. Try doing:
$ git clone git://github.com/mojombo/foo
and you'll get:
fatal: protocol error: expected sha/ref, got '
*********'
No matching repositories found.
*********'
This has cut down tremendously on the number of support requests we
get from new users. It would be nice to cut out the clutter from the
error message though.
Tom
^ permalink raw reply
* Re: libgit2 - a true git library
From: Johannes Schindelin @ 2008-11-01 2:26 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Nicolas Pitre, Junio C Hamano, Pieter de Bie, Pierre Habouzit,
git, Scott Chacon
In-Reply-To: <20081101015217.GJ14786@spearce.org>
Hi,
On Fri, 31 Oct 2008, Shawn O. Pearce wrote:
> Nicolas Pitre <nico@cam.org> wrote:
> > On Fri, 31 Oct 2008, Shawn O. Pearce wrote:
> >
> > > > Both the negative code and errno style are lightweight in the
> > > > common "no error" case. The errno style is probably more handy
> > > > for those functions returning a pointer which should be NULL in
> > > > the error case.
Unfortunately, errno would not be thread-safe, unless you can guarantee
that errno is a thread-local variable.
> > >
> > > I'm sticking with return a negative code for now, to the extent that
> > > some functions which return a pointer but also have many common
> > > failure modes (e.g. git_odb_open) use an output parameter as their
> > > first arg, so the error code can be returned as the result of the
> > > function.
> >
> > Actually, the pointer-returning functions can encode error cases into a
> > "negative" pointer. See include/linux/err.h for example.
> >
> > void *ptr = git_alloc_foo(...);
> > if (IS_ERR(ptr))
> > die("git_alloc_foo failed: %s", git_strerr(PTR_ERR(ptr)));
>
> Oh, good point. We could also stagger the errors so they are
> always odd, and never return an odd-alignment pointer from a
> successful function. Thus IS_ERR can be written as:
>
> #define IS_ERR(ptr) (((intptr_t)(ptr)) & 1)
>
> which is quite cheap, and given the (probably required anyway)
> aligned allocation policy means we still have 2^31 possible
> error codes available.
Oh boy, both solutions are ugly as hell. Although the &1 method does not
limit the memory space as much (except if you plan to work in
space-contrained environments, where you do not want to be forced to
word-align structs).
The only pointer game I would remotely consider clean is if you had
const char *errors[] = {
...
};
inline int is_error(void *ptr) {
return ptr >= errors && ptr < errors + ARRAY_SIZE(errors);
}
although that would be less performant.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] connect.c: add a way for git-daemon to pass an error back to client
From: Nicolas Pitre @ 2008-11-01 2:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Tom Preston-Werner, git, gitster
In-Reply-To: <alpine.DEB.1.00.0811010316340.22125@pacific.mpi-cbg.de.mpi-cbg.de>
On Sat, 1 Nov 2008, Johannes Schindelin wrote:
> Hi,
>
> On Fri, 31 Oct 2008, Tom Preston-Werner wrote:
>
> > The current behavior of git-daemon is to simply close the connection on
> > any error condition. This leaves the client without any information as
> > to the cause of the failed fetch/push/etc.
> >
> > This patch allows get_remote_heads to accept a line prefixed with "ERR"
> > that it can display to the user in an informative fashion. Once clients
> > can understand this ERR line, git-daemon can be made to properly report
> > "repository not found", "permission denied", or other errors.
> >
> > Example
> >
> > S: ERR No matching repository.
> > C: fatal: remote error: No matching repository.
>
> Makes sense to me.
Note that this behavior of not returning any reason for failure was
argued to be a security feature in the past, by Linus I think.
Nicolas
^ permalink raw reply
* Re: [PATCH 2/3] git send-email: do not ask questions when --compose is used.
From: Ian Hilt @ 2008-11-01 2:26 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <20081031213803.GB21799@artemis.corp>
On Fri, Oct 31, 2008 at 06:01:49PM -0400, Ian Hilt wrote:
> I've thought something like this would be a good thing. An editor makes
> things easier to fix than the command-line.
Speaking of which, maybe let's add the To field to the list.
--->8---
From: Ian Hilt <ian.hilt@gmx.com>
Date: Fri, 31 Oct 2008 22:15:46 -0400
Subject: [PATCH] git-send-email.perl: add To field in editor
This allows the compose mode to add the To field in the editor. However
it currently will not remove an address.
Signed-off-by: Ian Hilt <ian.hilt@gmx.com>
---
This is on top of the previous patch I sent.
git-send-email.perl | 12 +++++++++++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 0944be7..ed95402 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -450,6 +450,12 @@ if ($compose) {
my $tpl_sender = $sender || $repoauthor || $repocommitter || '';
+ my @tpl_to;
+ if (@to) {
+ foreach my $i (0..$#to) {
+ $tpl_to[$i] = $to[$i];
+ }
+ }
my $tpl_subject = $initial_subject || '';
my $tpl_reply_to = $initial_reply_to || '';
@@ -459,6 +465,7 @@ From $tpl_sender # This line is ignored.
# Consider including an overall diffstat or table of contents
# for the patch you are writing.
From: $tpl_sender
+To: @tpl_to
Subject: $tpl_subject
In-Reply-To: $tpl_reply_to
@@ -514,6 +521,9 @@ EOT
} elsif (/^From:\s*(.+)\s*$/i) {
$sender = $1;
next;
+ } elsif (/^To:\s*(.+)\s*$/i) {
+ push @to, $1;
+ next;
}
$summary_empty = 0;
print C2 $_;
@@ -522,7 +532,7 @@ EOT
close(C2);
if ($summary_empty) {
- print "Summary email is empty, skpping it\n";
+ print "Summary email is empty, skipping it\n";
$compose = -1;
}
} elsif ($annotate) {
--
1.6.0.3.523.g304d0
^ permalink raw reply related
* Re: [PATCH] connect.c: add a way for git-daemon to pass an error back to client
From: Johannes Schindelin @ 2008-11-01 2:35 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Tom Preston-Werner, git, gitster
In-Reply-To: <alpine.LFD.2.00.0810312218300.13034@xanadu.home>
Hi,
On Fri, 31 Oct 2008, Nicolas Pitre wrote:
> On Sat, 1 Nov 2008, Johannes Schindelin wrote:
>
> > On Fri, 31 Oct 2008, Tom Preston-Werner wrote:
> >
> > > The current behavior of git-daemon is to simply close the connection
> > > on any error condition. This leaves the client without any
> > > information as to the cause of the failed fetch/push/etc.
> > >
> > > This patch allows get_remote_heads to accept a line prefixed with
> > > "ERR" that it can display to the user in an informative fashion.
> > > Once clients can understand this ERR line, git-daemon can be made to
> > > properly report "repository not found", "permission denied", or
> > > other errors.
> > >
> > > Example
> > >
> > > S: ERR No matching repository.
> > > C: fatal: remote error: No matching repository.
> >
> > Makes sense to me.
>
> Note that this behavior of not returning any reason for failure was
> argued to be a security feature in the past, by Linus I think.
Yes. And it might still be considered one. You do not need to patch
git-daemon to use that facility (note that Tom's patch was only for the
client side).
But for hosting sites such as repo.or.cz or GitHub, that security feature
just does not make sense, but it makes for support requests that could be
resolved better with a proper error message.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] connect.c: add a way for git-daemon to pass an error back to client
From: Tom Preston-Werner @ 2008-11-01 3:35 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Nicolas Pitre, git, gitster
In-Reply-To: <alpine.DEB.1.00.0811010334010.22125@pacific.mpi-cbg.de.mpi-cbg.de>
On Fri, Oct 31, 2008 at 7:35 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Fri, 31 Oct 2008, Nicolas Pitre wrote:
>
>> On Sat, 1 Nov 2008, Johannes Schindelin wrote:
>>
>> > On Fri, 31 Oct 2008, Tom Preston-Werner wrote:
>> >
>> > > The current behavior of git-daemon is to simply close the connection
>> > > on any error condition. This leaves the client without any
>> > > information as to the cause of the failed fetch/push/etc.
>> > >
>> > > This patch allows get_remote_heads to accept a line prefixed with
>> > > "ERR" that it can display to the user in an informative fashion.
>> > > Once clients can understand this ERR line, git-daemon can be made to
>> > > properly report "repository not found", "permission denied", or
>> > > other errors.
>> > >
>> > > Example
>> > >
>> > > S: ERR No matching repository.
>> > > C: fatal: remote error: No matching repository.
>> >
>> > Makes sense to me.
>>
>> Note that this behavior of not returning any reason for failure was
>> argued to be a security feature in the past, by Linus I think.
>
> Yes. And it might still be considered one. You do not need to patch
> git-daemon to use that facility (note that Tom's patch was only for the
> client side).
>
> But for hosting sites such as repo.or.cz or GitHub, that security feature
> just does not make sense, but it makes for support requests that could be
> resolved better with a proper error message.
We could also have the error messages sent back conditionally based on
a command line switch. I've begun porting the changes I made in our
Erlang git-daemon back to the C code, so maybe I'll give that a try.
We *definitely* need good error messages for GitHub and I see no
security risk in doing so.
Maybe this is worth asking the question: does anybody use git-daemon
for private code? If so, why are they not using SSH instead? And in
that case, how are informative error messages a security risk?
Tom
^ permalink raw reply
* Re: commit type
From: 7rans @ 2008-11-01 4:15 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.DEB.1.00.0811010025570.22125@pacific.mpi-cbg.de.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin <at> gmx.de> writes:
> So you want to force this onto all Git users?
Not at all. It would be a purely optional. You would never even need to know the
feature existed if you didn't want to use it. So I'm not sure how that is
forcing it upon anyone.
Moreover, I suggested it b/c I would find such a feature very useful, and, by
extension, thought others might as well. Perhaps others have done something
similar, in which case it would be interesting the hear their take, or on the
other hand they've never considered it before, but now can consider the
potential utility of just such a feature.
> If yes: that murmur you hear in the background, it might well be the
> collective "thanks, but no thanks" of people who do not want that type of
> distinction between different commits.
There is no need to make one. It's purely annotative.
T.
^ permalink raw reply
* git reset --hard w/o touching every file
From: Edward Z. Yang @ 2008-11-01 4:48 UTC (permalink / raw)
To: git
I was wondering if there was any way to run `git reset --hard $revlike`,
or a command with the same effect, without having Git touch every file?
Cheers,
Edward
^ permalink raw reply
* Re: [PATCH] connect.c: add a way for git-daemon to pass an error back to client
From: Junio C Hamano @ 2008-11-01 5:39 UTC (permalink / raw)
To: Tom Preston-Werner; +Cc: git
In-Reply-To: <b97024a40810311859t2e5a6102u31ad4480e7c75c03@mail.gmail.com>
"Tom Preston-Werner" <tom@github.com> writes:
> Example
>
> S: ERR No matching repository.
> C: fatal: remote error: No matching repository.
I like what this tries to do.
I briefly wondered if this should be restricted to the very first message
from the other end, but I think it is not necessary. If the remote throws
a few valid looking "SHA-1 SP refname" lines and then said "ERR" (which
cannot be the beginning of a valid SHA-1), we can safely and unambiguously
declare that this is an error message from the remote end.
> diff --git a/connect.c b/connect.c
> index 0c50d0a..3af91d6 100644
> --- a/connect.c
> +++ b/connect.c
> @@ -70,6 +70,9 @@ struct ref **get_remote_heads(int in, struct ref **list,
> if (buffer[len-1] == '\n')
> buffer[--len] = 0;
>
> + if (len > 4 && !memcmp("ERR", buffer, 3))
Would matching 4 bytes "ERR " here an improvement? You are expecting
buffer+4 is where the message begins in die() anyway, and otherwise you
would show the message without "N" if you got "ERRNo matching repo".
> + die("remote error: %s", buffer + 4);
> +
It was very considerate that you did not say "server error" in the error
message. This code is shared between both the fetch side and the push
side.
^ permalink raw reply
* Re: [PATCH] connect.c: add a way for git-daemon to pass an error back to client
From: Tom Preston-Werner @ 2008-11-01 6:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy7043sy9.fsf@gitster.siamese.dyndns.org>
On Fri, Oct 31, 2008 at 10:39 PM, Junio C Hamano <gitster@pobox.com> wrote:
> "Tom Preston-Werner" <tom@github.com> writes:
>
>> Example
>>
>> S: ERR No matching repository.
>> C: fatal: remote error: No matching repository.
>
> I like what this tries to do.
>
> I briefly wondered if this should be restricted to the very first message
> from the other end, but I think it is not necessary. If the remote throws
> a few valid looking "SHA-1 SP refname" lines and then said "ERR" (which
> cannot be the beginning of a valid SHA-1), we can safely and unambiguously
> declare that this is an error message from the remote end.
>
>> diff --git a/connect.c b/connect.c
>> index 0c50d0a..3af91d6 100644
>> --- a/connect.c
>> +++ b/connect.c
>> @@ -70,6 +70,9 @@ struct ref **get_remote_heads(int in, struct ref **list,
>> if (buffer[len-1] == '\n')
>> buffer[--len] = 0;
>>
>> + if (len > 4 && !memcmp("ERR", buffer, 3))
>
> Would matching 4 bytes "ERR " here an improvement? You are expecting
> buffer+4 is where the message begins in die() anyway, and otherwise you
> would show the message without "N" if you got "ERRNo matching repo".
I saw several methods of testing for a specific prefix in connect.c.
Looking more closely at the source, the closest similar call is
actually the test for ACK:
if (!prefixcmp(line, "ACK ")) {
if (!get_sha1_hex(line+4, result_sha1)) {
if (strstr(line+45, "continue"))
return 2;
return 1;
}
}
Explicitly testing for "ERR " (including the space) does seem like the
more correct thing to do. Would you like me to resubmit a modified
patch that uses prefixcmp()?
Tom
^ permalink raw reply
* [PATCH] add instructions on how to send patches to the mailing list with Gmail
From: Tom Preston-Werner @ 2008-11-01 7:28 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Gmail is one of the most popular email providers in the world. Now that Gmail
supports IMAP, sending properly formatted patches via `git imap-send` is
trivial. This section in SubmittingPatches explains how to do so.
Signed-off-by: Tom Preston-Werner <tom@github.com>
---
Documentation/SubmittingPatches | 27 +++++++++++++++++++++++++++
1 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index a1e9100..f0295c6 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -456,3 +456,30 @@ This should help you to submit patches inline using KMail.
5) Back in the compose window: add whatever other text you wish to the
message, complete the addressing and subject fields, and press send.
+
+
+Gmail
+-----
+
+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
+
+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!
--
1.6.0.2
^ permalink raw reply related
* Re: Git/Mercurial interoperability (and what about bzr?)
From: Florian Weimer @ 2008-11-01 8:06 UTC (permalink / raw)
To: git
In-Reply-To: <20081028213144.GC10862@mit.edu>
* Theodore Tso:
> In the past I've looked at the possibility of creating a
> bi-directional, incremental gateway between hg and git repositories.
> The main thing which makes this difficult is that hg stores tags
> in-band inside the change-controlled .hgtags file. This means that if
> you cut a release, tag it, and then create a commit to further modify
> the repository, the new commit is descended from the tag commit,
> whereas in git, the tag is a "bookmark" --- perhaps signed via GPG,
> but not part of the revision history.
Couldn't you just keep the .hgtags file and have everyone interested
in the tags use special scripts?
(Admittedly, I'm horribly totally by Git's behavior in this area. I
haven't figured out yet under what circumstances tags are pushed and
pulled, so I'm not totally opposed to the Mercurial model. 8-/)
^ permalink raw reply
* Re: [PATCH] add instructions on how to send patches to the mailing list with Gmail
From: Santi Béjar @ 2008-11-01 10:00 UTC (permalink / raw)
To: Tom Preston-Werner; +Cc: git, Junio C Hamano
In-Reply-To: <b97024a40811010028l36606128v61172807f4cf503a@mail.gmail.com>
On Sat, Nov 1, 2008 at 8:28 AM, Tom Preston-Werner <tom@github.com> wrote:
> Gmail is one of the most popular email providers in the world. Now that Gmail
> supports IMAP, sending properly formatted patches via `git imap-send` is
> trivial. This section in SubmittingPatches explains how to do so.
>
> Signed-off-by: Tom Preston-Werner <tom@github.com>
> ---
> Documentation/SubmittingPatches | 27 +++++++++++++++++++++++++++
> 1 files changed, 27 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
> index a1e9100..f0295c6 100644
> --- a/Documentation/SubmittingPatches
> +++ b/Documentation/SubmittingPatches
> @@ -456,3 +456,30 @@ This should help you to submit patches inline using KMail.
>
> 5) Back in the compose window: add whatever other text you wish to the
> message, complete the addressing and subject fields, and press send.
> +
> +
> +Gmail
> +-----
> +
> +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
Warning: It is not secure.
> +
> +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!
Are you sure the mail does not get whitespace damaged?
Santi
^ permalink raw reply
* Re: Git/Mercurial interoperability (and what about bzr?)
From: Santi Béjar @ 2008-11-01 10:03 UTC (permalink / raw)
To: Florian Weimer; +Cc: git
In-Reply-To: <87ljw3zx8i.fsf@mid.deneb.enyo.de>
On Sat, Nov 1, 2008 at 9:06 AM, Florian Weimer <fw@deneb.enyo.de> wrote:
>
> (Admittedly, I'm horribly totally by Git's behavior in this area. I
> haven't figured out yet under what circumstances tags are pushed and
> pulled, so I'm not totally opposed to the Mercurial model. 8-/)
Tag are pushed when you tell it so, and pulled if they are pointing to
the history you have, or you can ask to fetch them explicitly.
HTH,
Santi
^ permalink raw reply
* Re: Git/Mercurial interoperability (and what about bzr?) (was: Re: [VOTE] git versus mercurial)
From: Peter Krefting @ 2008-11-01 10:16 UTC (permalink / raw)
To: Pieter de Bie; +Cc: Git Mailing List
In-Reply-To: <E026EBDF-F402-49AB-A7A8-0A0EFB513907@ai.rug.nl>
Hi!
Pieter de Bie:
> What would you want that the fast-export/imports are lacking? I think
> they are excellent tools to build some integration on.
Speed. I am cloning from a rather overloaded server on the other side
of the globe (the US). If I were to go the fast-export/import route, I
fear it would take even longer.
> You might want to look at my git-bzr script
Looks very interesting. *adding to my things-to-examine list*
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: Git/Mercurial interoperability (and what about bzr?)
From: Jakub Narebski @ 2008-11-01 10:33 UTC (permalink / raw)
To: Florian Weimer; +Cc: git
In-Reply-To: <87ljw3zx8i.fsf@mid.deneb.enyo.de>
Florian Weimer <fw@deneb.enyo.de> writes:
> * Theodore Tso:
>
> > In the past I've looked at the possibility of creating a
> > bi-directional, incremental gateway between hg and git repositories.
> > The main thing which makes this difficult is that hg stores tags
> > in-band inside the change-controlled .hgtags file. This means that if
> > you cut a release, tag it, and then create a commit to further modify
> > the repository, the new commit is descended from the tag commit,
> > whereas in git, the tag is a "bookmark" --- perhaps signed via GPG,
> > but not part of the revision history.
>
> Couldn't you just keep the .hgtags file and have everyone interested
> in the tags use special scripts?
>
> (Admittedly, I'm horribly totally by Git's behavior in this area. I
> haven't figured out yet under what circumstances tags are pushed and
> pulled, so I'm not totally opposed to the Mercurial model. 8-/)
I think you don't understand the issue here.
First, I think that we all agree here that by definition tags should
named reference (for example 'v1.0' or '1.0') to some immutable
snapshot of a state of repository, so for example when somebody says
'v1.0' everybody knows what it is. In Git tags are immutable (you
can't checkout a tag, you can only checkout state pointed by tag)
external pointers to commits in the DAG (graph) of revisions.
Global tags (tags used to mark releases like 'v1.0') have to _not
versioned_ and _transferable_. Transferable (global) because we want
to know for example what 'v1.0' version was in each clone / each
repository. Non-versioned because we want to have the same set of
tags independent on what branch we are (when we are on 'master', we
want to be able to know about 'v1.0.1' which is on 'maint'), and what
revision we have checked out (for example during bisection, we want to
be able to compare to 'v1.0' even if we have checked out revision
which is earlier than 'v1.0').
Do you agree that global tags should be both non-versioned and
trasferable?
Now Mercurial has chosen to use in-tree '.hgtags' file to have global
tags transferable. Never mind the fact that it had to treat this file
in special way to have it non-versioned (as opposed to for example
.*ignore file, which should be both transferable and versioned); the
fact that in-tree file is used means that tag is visible to outside
(transferable) only after you commit changes in .hgtags file.
In Git tags are external to object database; they reside in
refs/tags/* namespace. They are of course non-versioned, as not being
in-tree. In default configuration however (from what I understand) if
you transfer (get) some tagged commit, you also get a tag that points
to transferred commit. You don't need to create "PROJECT 1.0" (or
"Tagged v1.0") commit to make tag visible to outside.
In short, if you want to have bi-directional gateway between Mercurial
and Git, Git has to be limited:
* no octopus merges (with more than two parents)
* always create 'tagging commits' (bump version number for example)
for tagging purposes on Mercurial side.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Git/Mercurial interoperability (and what about bzr?)
From: Florian Weimer @ 2008-11-01 10:44 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3prlffzk2.fsf@localhost.localdomain>
* Jakub Narebski:
> Florian Weimer <fw@deneb.enyo.de> writes:
>> * Theodore Tso:
>>
>> > In the past I've looked at the possibility of creating a
>> > bi-directional, incremental gateway between hg and git repositories.
>> > The main thing which makes this difficult is that hg stores tags
>> > in-band inside the change-controlled .hgtags file. This means that if
>> > you cut a release, tag it, and then create a commit to further modify
>> > the repository, the new commit is descended from the tag commit,
>> > whereas in git, the tag is a "bookmark" --- perhaps signed via GPG,
>> > but not part of the revision history.
>>
>> Couldn't you just keep the .hgtags file and have everyone interested
>> in the tags use special scripts?
>>
>> (Admittedly, I'm horribly totally by Git's behavior in this area. I
>> haven't figured out yet under what circumstances tags are pushed and
>> pulled, so I'm not totally opposed to the Mercurial model. 8-/)
>
> I think you don't understand the issue here.
Probably yes.
> Do you agree that global tags should be both non-versioned and
> trasferable?
Yes, I do. In case of Git, I've got trouble with understanding how to
actually implement the "transferable" part with Git. The Mercurial
way is easier to understand, but it means that tags may need some sort
of "tag at this revision" qualifier to disambiguate, which is rather
problematic.
> Now Mercurial has chosen to use in-tree '.hgtags' file to have global
> tags transferable. Never mind the fact that it had to treat this file
> in special way to have it non-versioned
Oops, thought this file was versioned. Things like
<http://tycoon.hpl.hp.com/changeset/932:931d181e9f58/.hgtags>
suggest it was at some point.
^ permalink raw reply
* Re: libgit2 - a true git library
From: Andreas Ericsson @ 2008-11-01 10:52 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Pierre Habouzit, Shawn O. Pearce, git, Scott Chacon
In-Reply-To: <alpine.LFD.2.00.0810311756160.13034@xanadu.home>
Nicolas Pitre wrote:
> On Fri, 31 Oct 2008, Pierre Habouzit wrote:
>
>> Git is currently mostly "GPLv2 or later". A BSDish license was
>> mentioned, because it's the most permissive one and that nobody cared
>> that much, though a LGPL/GPL-with-GCC-exception would probably fly.
>
> I do care. I think the BSD license is too permissive. There are really
> nifty pieces of code in Git that I would be really sorry to see go
> proprietary.
>
I agree with Nicolas, for what it's worth. Although I realize my small
contributions to the git code can be trivially rewritten, I think that
will definitely be trickier with Nicolas' contributions.
>
>> OT: FWIW I prefer BSDish licenses (even the MIT actually) for libraries
>> because I believe that computing is overall better if everyone can use
>> the right tool for the task, and I don't want to prevent people from
>> using good stuff (I hope I write good stuff ;P) because of the license.
>
> Everybody can and does link against glibc on Linux which is LGPL. So
> that doesn't affect "usage".
>
For dynamic libraries, yes, as you can replace them in-flight if you need
to. For static libraries, it's a different matter. I think the gcc exception
is rather special, as parts of gcc is the dynamic linker initialization code,
which has to be shipped in object form and included in all executables
produced with gcc. Perhaps we'd be better off asking one of EFF's lawyers
what each license means, exactly.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: libgit2 - a true git library
From: Pierre Habouzit @ 2008-11-01 11:01 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Shawn O. Pearce, Nicolas Pitre, Junio C Hamano, Pieter de Bie,
git, Scott Chacon
In-Reply-To: <alpine.DEB.1.00.0811010320370.22125@pacific.mpi-cbg.de.mpi-cbg.de>
[-- Attachment #1: Type: text/plain, Size: 4088 bytes --]
On Sat, Nov 01, 2008 at 02:26:45AM +0000, Johannes Schindelin wrote:
> Hi,
>
> On Fri, 31 Oct 2008, Shawn O. Pearce wrote:
>
> > Nicolas Pitre <nico@cam.org> wrote:
> > > On Fri, 31 Oct 2008, Shawn O. Pearce wrote:
> > >
> > > > > Both the negative code and errno style are lightweight in the
> > > > > common "no error" case. The errno style is probably more handy
> > > > > for those functions returning a pointer which should be NULL in
> > > > > the error case.
>
> Unfortunately, errno would not be thread-safe, unless you can guarantee
> that errno is a thread-local variable.
Well, TLS afaict is implemented on arches that have GNU ld, or on win32
with a recent enough mingw. Though this is quite a requirement.
> > Oh, good point. We could also stagger the errors so they are
> > always odd, and never return an odd-alignment pointer from a
> > successful function. Thus IS_ERR can be written as:
> >
> > #define IS_ERR(ptr) (((intptr_t)(ptr)) & 1)
> >
> > which is quite cheap, and given the (probably required anyway)
> > aligned allocation policy means we still have 2^31 possible
> > error codes available.
>
> Oh boy, both solutions are ugly as hell. Although the &1 method does not
> limit the memory space as much (except if you plan to work in
> space-contrained environments, where you do not want to be forced to
> word-align structs).
>
> The only pointer game I would remotely consider clean is if you had
>
> const char *errors[] = {
> ...
> };
>
> inline int is_error(void *ptr) {
> return ptr >= errors && ptr < errors + ARRAY_SIZE(errors);
> }
Well, you can't return _sanely_ an error through a pointer. The &1
method is broken as soon as you return a char* (there is an alignment
requirement for malloc, not for any pointer out there), hence shall not
be used, as it would not be the sole way to test for error.
Another option, that is _theorically_ not portable, but is ttbomk on all
the platforms we intend to support (IOW POSIX-ish and windows), is to
use "small" values of the pointers for errors. [NULL .. (void *)(PAGE_SIZE - 1)[
cannot exist, which gives us probably always 512 different errors, and
the test is ((uintptr_t)ptr < (PAGE_SIZE)) which is cheap. It's butt
ugly, but encoding errors into pointers is butt ugly in the first place.
Another option that is what I would prefer, would be for the use of
errno where it makes sense. E.g. if you want a function that fetches an
object, this is somehow what read(3) would look like on our store, more
or less, and errno's are enough. For the other functions where errno
cannot be used, I'm pretty sure we will always pass a handle to some
kind of libgit2 stuff, like the "repository" we're working on. The
_easiest_ way is to put the "last error" into that structure and use
that. I mean, if we want libgit2 to be useful for _everyone_ we *WILL*
have to pass a repository context around. I see almost no way around it.
And there, NULL means error, and if you want to know about the specific
error, git_repo_errno(&ctx) / git_repo_strerr(&ctx) is just easy.
Note: What is important is to be able to check for errors _fast_, I
don't think printing out the error and knowing which error it was would
be in the fast path, so it's less useful to have this information
immediately.
_My_ taste (but again, like the _t I would use what is there, and won't
make a fuss about it at all) is to see function return -1 or NULL for
errors, and "abuse" errno for system-like functions, or put the last
error into the context on which you're working (your "this" more or
less). We don't need a specific error context at all, because we already
have a repository context available.
I'm not really a fan of pointer semantics abuse (it's sometimes useful,
but as the public interface of a library, this is butt-ugly.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] git send-email: do not ask questions when --compose is used.
From: Pierre Habouzit @ 2008-11-01 11:04 UTC (permalink / raw)
To: Ian Hilt; +Cc: git
In-Reply-To: <20081101022649.GB17961@sys-0.hiltweb.site>
[-- Attachment #1: Type: text/plain, Size: 1050 bytes --]
On Sat, Nov 01, 2008 at 02:26:49AM +0000, Ian Hilt wrote:
> On Fri, Oct 31, 2008 at 06:01:49PM -0400, Ian Hilt wrote:
> > I've thought something like this would be a good thing. An editor makes
> > things easier to fix than the command-line.
>
> Speaking of which, maybe let's add the To field to the list.
I didn't do it for a very good reason: the To field is tricker to parse
because very fast it's multiline, and must be split along the ',' when
parsed back and so on.
And even moreuseful than the To is the Cc list that git-send-email
bloats to death and that I would like to reduce very often.
But sadly that needs an expertise of perl I absolutely don't have. We
probably even want to depend on some MIME perl library that knows about
those kind of issues and do it for us well.
But yeah, I knew I left out those, and this was the reason.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: git reset --hard w/o touching every file
From: Pierre Habouzit @ 2008-11-01 11:05 UTC (permalink / raw)
To: Edward Z. Yang; +Cc: git
In-Reply-To: <gegn38$lku$1@ger.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 439 bytes --]
On Sat, Nov 01, 2008 at 04:48:38AM +0000, Edward Z. Yang wrote:
> I was wondering if there was any way to run `git reset --hard $revlike`,
> or a command with the same effect, without having Git touch every file?
git checkout HEAD -- <list of the files>
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ 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