headers
Junio C Hamano | 1 Jun 2006 01:16
Picon
Picon

Re: [PATCH] format-patch --signoff

Johannes Schindelin <Johannes.Schindelin <at> gmx.de> writes:

> I don't know, but it may be a good idea to make this more general: Why not 
> build the sign-off line here, so that you could also add more than one 
> sign-off lines ('--signoff="The great committer <ter <at> mit.com>"'), and 
> maybe even Acked-by's?

Perhaps.

> Okay, this would be a little harder with multiple sign-offs. But the check 
> could be easier, i.e. if we say
>
> 	rev.add_signoff = xmalloc(enough_room);
> 	strcpy(rev.add_signoff, "\nSigned-off-by: ");
> 	strcat(rev.add_signoff, committer_ident);
> 	strcat(rev.add_signoff, "\n");
>
> then a simple
>
> 	p = strstr(commit_buffer, rev.add_signoff);
> 	if (p)
> 		return (int)(p - commit_buffer);
>
> would do the trick.

Do you mean, by "multiple sign-offs", something like this?

	for (so_list = rev.add_signoff; so_list; so_list = so_list->next) {
		if (strstr(commit_buffer, so_list->item))
                	continue;
(Continue reading)

Permalink | Reply | 1 comment |
headers
Nick Hengeveld | 1 Jun 2006 01:25

[PATCH] http: prevent segfault during curl handle reuse

If a curl handle is configured with special options, they may reference
information that is freed after the request is complete which can cause
a segfault if the curl handle is reused for a different type of request.

This patch resets these options to a safe state when a transfer slot is
assigned to a new request.

Signed-off-by: Nick Hengeveld <nickh <at> reactrix.com>
---
 http.c |    9 ++++++---
 1 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/http.c b/http.c
index 0cb42a8..146cf7b 100644
--- a/http.c
+++ b/http.c
 <at>  <at>  -25,7 +25,6  <at>  <at>  long curl_low_speed_limit = -1;
 long curl_low_speed_time = -1;

 struct curl_slist *pragma_header;
-struct curl_slist *no_range_header;

 struct active_request_slot *active_queue_head = NULL;

 <at>  <at>  -208,7 +207,6  <at>  <at>  void http_init(void)
 	curl_global_init(CURL_GLOBAL_ALL);

 	pragma_header = curl_slist_append(pragma_header, "Pragma: no-cache");
-	no_range_header = curl_slist_append(no_range_header, "Range:");
(Continue reading)

Permalink | Reply | 0 comments |
headers
Johannes Schindelin | 1 Jun 2006 01:31
Picon
Picon

Re: [PATCH] format-patch --signoff

Hi,

On Wed, 31 May 2006, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin <at> gmx.de> writes:
> 
> > I don't know, but it may be a good idea to make this more general: Why not 
> > build the sign-off line here, so that you could also add more than one 
> > sign-off lines ('--signoff="The great committer <ter <at> mit.com>"'), and 
> > maybe even Acked-by's?
> 
> Perhaps.
> 
> > Okay, this would be a little harder with multiple sign-offs. But the check 
> > could be easier, i.e. if we say
> >
> > 	rev.add_signoff = xmalloc(enough_room);
> > 	strcpy(rev.add_signoff, "\nSigned-off-by: ");
> > 	strcat(rev.add_signoff, committer_ident);
> > 	strcat(rev.add_signoff, "\n");
> >
> > then a simple
> >
> > 	p = strstr(commit_buffer, rev.add_signoff);
> > 	if (p)
> > 		return (int)(p - commit_buffer);
> >
> > would do the trick.
> 
> Do you mean, by "multiple sign-offs", something like this?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alec Warner | 1 Jun 2006 03:42
Picon
Favicon

Re: irc usage..

Martin Langhoff wrote:
> On 6/1/06, Alec Warner <antarus <at> gentoo.org> wrote:
> 
>> I have a dual opteron with 4gb of ram "on loan" from work :)
>>
>> It still dies though, using git cvsimport or parsecvs.
> 
> 
> The machine I am running this is more constrained than that, and it
> doesn't die. It just takes maybe 30hs. Make sure it's not a bad cvs
> binary you got there (latest from gentoo seems to leak memory).
> 
> And if it's still dying... give us some more details ;-)
> 
> cheers,
> 
> 
> martin

After reading the whole thread on this, I've using a git checkout of 
git, cvsps-2.1 and cvs-1.11.12, running overnight in verbose mode with 
screen.  Hopefully will have a repo in the morning ;)
Permalink | Reply | 6 comments |
headers
Shawn Pearce | 1 Jun 2006 05:11
Gravatar

Re: [PATCH 0/10] re-based and expanded tree-walker cleanup patches

Junio C Hamano <junkio <at> cox.net> wrote:
> Linus Torvalds <torvalds <at> osdl.org> writes:
> 
> >  (a) git-rev-list --pretty=oneline "$upstream"..ORIG_HEAD > rev-list
> >
> >  (b) edit the rev-list, moving the single lines around, deleting them, etc
> >
> >  (c) cat rev-list |
> >      git-format-patch -k --stdout --stdin --full_index |
> >      git-am
> >
[snip]
> What this means is:
> 
> 	git-format-patch $revargs
> 
> is not equivalent to
> 
> 	git-rev-list $revargs | git-format-patch --stdin
> 
> but is equivalent to
> 
> 	git-rev-list $revargs | tac | git-format-patch --stdin
> 
> 
> Thoughts from the list?

Aside from not knowing what tac is I agree with the latter.
It is what the user would expect to happen.  Except maybe add a
--ancestors-first option to git-rev-list to do what tac does before
(Continue reading)

Permalink | Reply | 0 comments |
headers
Shawn Pearce | 1 Jun 2006 05:34
Gravatar

Re: [PATCH] Automatically line wrap long commit messages.

Junio C Hamano <junkio <at> cox.net> wrote:
> Shawn Pearce <spearce <at> spearce.org> writes:
> 
> > Junio C Hamano <junkio <at> cox.net> wrote:
> >
> >> If we supported multiple -m (presumably each becomes a single line?)
> >> with internal fmt, I do not see how it would become less work.
> >> 
> >> 	$ git commit -w60 -m "This is my message." \
> >>         	-m '' \
> >>         	-m 'This is the body.  Etc....'
> >> 
> >> looks more typing to me, even without the second line to force
> >> the empty line between the summary and the body.
> >
> > Actually I was thinking each -m would be its own paragraph so blank
> > lines would split each -m and maybe the -w60 should be a config
> > option in .git/config or .gitrc so it doesn't always need to be
> > supplied on the command line.
> 
> Now that makes the distinction between the current:
> 
> 	$ git commit -m 'This is my message.
> 
> 	This is the body.  Etc....'
> 
> vs. the proposed multi-em:
> 
> 	$ git commit -m 'This is my message.' \
>         -m 'This is the body.  Etc....'
(Continue reading)

Permalink | Reply | 1 comment |
headers
Junio C Hamano | 1 Jun 2006 08:37
Picon
Picon

Re: [PATCH] Automatically line wrap long commit messages.

Shawn Pearce <spearce <at> spearce.org> writes:

> Because git-commit currently performs a status update and throws
> that data into the editor buffer.  That takes longer than committing
> from the command line.  Especially if I've just done a git-diff or
> git-status to see what is changed and about to be committed...

Ah, why does it take this many exchanges to extract the true
motive behind what people do even in a technical forum like
this, I wonder...

So what you want is not multiple -m options nor piping to fmt.
What you really want is an option that is the opposite of -v to
git-commit that omits the status list ("_could_ commit if you
update-index" part -- since "will commit" is something we would
need to compute anyway).

> On a project the size of GIT on a Unix system this isn't a big deal;
> on a 9000 file project on Cygwin this difference is significant
> to me.

I suspect you are suffering from lstat() performance.  I wonder
if "assume unchanged" git help your situation?
Permalink | Reply | 0 comments |
headers
Junio C Hamano | 1 Jun 2006 09:12
Picon
Picon

Re: [PATCH] git-svnimport: Improved detection of merges.

Florian Forster <octo <at> verplant.org> writes:

> The regexes detecting merges (while still relying on the commit messages,
> though) have been improved to catch saner (and hopefully more) messages. The
> old regex was so generic that it often matched something else and missed the
> actual merge-message.

> Also, the regex given with the `-M' commandline-option is checked first:
> Explicitely given regexes should be considered better than the builtin ones,
> and should therefore be given a chance to match a message first.

The latter part sounds immensely sane.  The former I am not a
good judge, since I do not interact with subversion repositories
myself.  Opinions from real svn users?

BTW, did anybody received the latest "What's in git.git" I sent
out about 20 minutes ago?
Permalink | Reply | 3 comments |
headers
Martin Langhoff | 1 Jun 2006 09:47
Picon
Gravatar

Re: irc usage..

On 6/1/06, Alec Warner <antarus <at> gentoo.org> wrote:
> After reading the whole thread on this, I've using a git checkout of
> git, cvsps-2.1 and cvs-1.11.12, running overnight in verbose mode with
> screen.  Hopefully will have a repo in the morning ;)

Good stuff. I am rerunning it to prove (and bench) a complete an
uninterrupted import. So far it's done 4hs 30m, footprint grown to
207MB, 49750 commits. So I think it will be done in approx 30hs on
this single-cpu opteron.

Most commits are small, but there is a handful that are downright
massive -- and we hold all the file list in memory, which I think
explains (most of) the memory growth. I've looked into avoiding
holding the whole filelist in memory, but it involves rewriting the
cvsps output parsing loop, which is better left for a rainy day, with
a test case that doesn't take 30hs to resolve.

cheers,

martin
Permalink | Reply | 5 comments |
headers
Junio C Hamano | 1 Jun 2006 11:19
Picon
Picon

What's in git.git (part #2)

It's been a while since the last feature release, and I
think with the recent "many things built-in" (including the
busybox style integration) we are nearing a good time to do the
next feature release 1.4.0.

Before doing a 1.4.0-rc1, I would like to see the following
topics in the "next" branch graduate to "master":

 - re-add missing flags to format-patch.  I have resurrected
   "--signoff"; if people care about something else we dropped
   when we went built-in, please raise hand and submit patches.

 - tree-parser updates from Linus seems to be fine in the sense
   I haven't seen breakage from it; I'll push it out to "master"
   before the end of the week.  I'd like to do another round of
   update to introduce a unified tree/index/directory walker, so
   settling this down is sort of urgent.

 - http-fetch fixes from Nick, which looked obviously correct.
   I would appreciate test reports from people who saw breakages
   on this one.

 - reflog from Shawn.  Do people find this useful?  I've enabled
   reflog on "next" branch in my development repository to see
   how useful it would be for myself a few days ago, and also in
   a linux-2.6 repository I use for testing (I do not hack on
   kernel myself).  

Other topics in "next" includes:
(Continue reading)

Permalink | Reply | 9 comments |

Gmane