* Re: What's in git.git (part #2)
From: Jakub Narebski @ 2006-06-01 9:31 UTC (permalink / raw)
To: git
In-Reply-To: <7v1wu9i608.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Junio C Hamano <junkio@cox.net> writes:
>
>> It's been a while since the last feature release,...
>
> So apparently somehow part #1 (the regular "master has these",
> "next in addition has these" message I occasionally do) is not
> liked by the mailing list. I wonder what's in it that makes it
> dropped on the floor...
I had same problem (message not appearing on list), and as far as
I was able to analyse it was because message accidentally (via unclean
copy'n'paste) had some unusual characters.
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* What's on git.git "master" (1/2)
From: Junio C Hamano @ 2006-06-01 9:29 UTC (permalink / raw)
To: git
* The 'master' branch has these since the last announcement.
(this is only the first half of "master" -- I am bisecting)
- Misc Fixes and Enhancements
Dennis Stosberg:
git-clean fails on files beginning with a dash
Dmitry V. Levin:
execv_git_cmd: Fix stack buffer overflow.
git_exec_path, execv_git_cmd: ignore empty environment variables
Paul Mackerras:
Make git-diff-tree indicate when it flushes
Salikh Zakirov:
Fixed Cygwin CR-munging problem in mailsplit
Shawn Pearce:
Allow multiple -m options to git-commit.
- Tests and Documentation
Eric Wong:
t3300-funny-names: shell portability fixes
tests: Remove heredoc usage inside quotes
t5500-fetch-pack: remove local (bashism) usage.
t6000lib: workaround a possible dash bug
Horst von Brand:
Fix some documentation typoes
J. Bruce Fields:
documentation: mention gitk font adjustment in tutorial
documentation: add brief mention of cat-file to tutorial part I
Documentation: retitle the git-core tutorial
Documentation: fix a tutorial-2 typo
Shawn Pearce:
Remove unnecessary output from t3600-rm.
Improved pack format documentation.
^ permalink raw reply
* What's in git.git (part #1-2)
From: Junio C Hamano @ 2006-06-01 9:27 UTC (permalink / raw)
To: git
(this one is about "next" only -- I am bisecting)
* The 'next' branch, in addition, has these.
- git-svnimport
Florian Forster:
git-svnimport: Improved detection of merges.
- read-tree/write-tree --prefix
Junio C Hamano:
read-tree: --prefix=<path>/ option.
write-tree: --prefix=<path>
read-tree: reorganize bind_merge code.
- format-patch
Junio C Hamano:
format-patch --signoff
- tree parser updates
Linus Torvalds:
Add raw tree buffer info to "struct tree"
Make "tree_entry" have a SHA1 instead of a union of object pointers
Switch "read_tree_recursive()" over to tree-walk functionality
Remove "tree->entries" tree-entry list from tree parser
Make "struct tree" contain the pointer to the tree buffer
Make "tree_entry" have a SHA1 instead of a union of object pointers
Switch "read_tree_recursive()" over to tree-walk functionality
builtin-read-tree.c: avoid tree_entry_list in prime_cache_tree_rec()
Remove "tree->entries" tree-entry list from tree parser
fsck-objects: avoid unnecessary tree_entry_list usage
Remove unused "zeropad" entry from tree_list_entry
Convert "mark_tree_uninteresting()" to raw tree walker
Convert fetch.c: process_tree() to raw tree walker
Remove last vestiges of generic tree_entry_list
tree_entry(): new tree-walking helper function
- fetch-pack into a repository with more root than the server
Junio C Hamano:
fetch-pack: give up after getting too many "ack continue"
- http-fetch fixes
Nick Hengeveld:
http: prevent segfault during curl handle reuse
Sean Estabrooks:
Remove possible segfault in http-fetch.
- reflog
Junio C Hamano:
fetch.c: do not pass uninitialized lock to unlock_ref().
Shawn Pearce:
Improve abstraction of ref lock/write.
Convert update-ref to use ref_lock API.
Log ref updates to logs/refs/<ref>
Support 'master@2 hours ago' syntax
Fix ref log parsing so it works properly.
General ref log reading improvements.
Added logs/ directory to repository layout.
Force writing ref if it doesn't exist.
Log ref updates made by fetch.
Change 'master@noon' syntax to 'master@{noon}'.
Correct force_write bug in refs.c
Change order of -m option to update-ref.
Include ref log detail in commit, reset, etc.
Create/delete branch ref logs.
Enable ref log creation in git checkout -b.
Verify git-commit provides a reflog message.
Test that git-branch -l works.
^ permalink raw reply
* Re: What's in git.git (part #2)
From: Junio C Hamano @ 2006-06-01 9:23 UTC (permalink / raw)
To: git
In-Reply-To: <7v64jli66m.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> It's been a while since the last feature release,...
So apparently somehow part #1 (the regular "master has these",
"next in addition has these" message I occasionally do) is not
liked by the mailing list. I wonder what's in it that makes it
dropped on the floor...
^ permalink raw reply
* Re: [PATCH] git-svnimport: Improved detection of merges.
From: Eric Wong @ 2006-06-01 9:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Florian Forster
In-Reply-To: <7vlkshs618.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Florian Forster <octo@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?
Sounds sane to me, but I've not seen the patch from Florian.
I've been toying around a bit with enhanced branch/merge-tracking
support in git-svn, too.
>
> BTW, did anybody received the latest "What's in git.git" I sent
> out about 20 minutes ago?
Nope, I haven't seen that nor Florian's patch (assuming it was sent to
the ml). Ah, I just saw (part #2) pop up.
--
Eric Wong
^ permalink raw reply
* What's in git.git (part #2)
From: Junio C Hamano @ 2006-06-01 9:19 UTC (permalink / raw)
To: git
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:
- read/write-tree --prefix. This is remnant of now-vetoed
subproject support using "bind commit". I kept both of them
because they could be useful independent of "bind commit",
but I do not know how much. I think read-tree --prefix might
probably be more useful than write-tree --prefix, since the
latter can be writing out the whole tree and run rev-parse
$tree:/path/name to extract that part, but the former does
not have an easy equivalent (you could pipe ls-tree output to
sed and pipe that to update-cache --index-info, but that is
crumsy).
I'd like to do "gitlink" based subproject support but most
likely that needs to come after tree/index/directory walker.
- fetch-pack client-side hack. When your repository has more
roots than the repository you are fetching from, the common
commit discovery exchange between fetch-pack and upload-pack
ends up traversing down the ancestry chain of the history the
other end do not have. The hack in the "next" branch is to
give up the common commit discovery early on the client side,
which Ralf Baechle who originally reported the problem says
to fix the problem (<20060526154239.GA20839@linux-mips.org>);
but the proper fix involves a bit smarter upload-pack.
I've posted a hacky upload-pack patch:
<7vfyiwi4xl.fsf@assigned-by-dhcp.cox.net>
but I think it should really needs to be cleaned up properly.
Things that we might want to have in 1.4.0 but not even in "next"
yet include:
- p4 importer (Sean Estabrooks) -- are people interested?
- letting fetch-pack to ask for an arbitrary commit object the
user obtained out of band (Eric W Biederman) -- waiting for
updated patch. We would need a corresponding one-liner patch
to upload-pack when we do this.
- using ~/.gitrc to give a fall-back default when
$GIT_DIR/config does not have values.
- command aliases and possibly default arguments via the
configuration file.
^ permalink raw reply
* Re: irc usage..
From: Martin Langhoff @ 2006-06-01 7:47 UTC (permalink / raw)
To: antarus
Cc: Donnie Berkholz, Linus Torvalds, Yann Dirson, Git Mailing List,
Matthias Urlichs, Johannes Schindelin
In-Reply-To: <447E4611.7000309@gentoo.org>
On 6/1/06, Alec Warner <antarus@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 raw reply
* Re: [PATCH] git-svnimport: Improved detection of merges.
From: Junio C Hamano @ 2006-06-01 7:12 UTC (permalink / raw)
To: git; +Cc: Florian Forster
In-Reply-To: <11490715283626-git-send-email-octo@verplant.org>
Florian Forster <octo@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 raw reply
* Re: [PATCH] Automatically line wrap long commit messages.
From: Junio C Hamano @ 2006-06-01 6:37 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060601033430.GA13485@spearce.org>
Shawn Pearce <spearce@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 raw reply
* Re: [PATCH] Automatically line wrap long commit messages.
From: Shawn Pearce @ 2006-06-01 3:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v64jm2380.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
>
> > Junio C Hamano <junkio@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....'
>
> Presumably Etc.... will be an multiline argument to -m. The
> distinction is even more blurry to me than before.
>
> Emacs users would just do "ESC q" and vi users would know how to
> filter the file contents through fmt, so this seems to come from
> aversion against invoking your $EDITOR. I just do not see why.
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...
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.
It is just the way I am used to working.
> Having said that, I do realize that the current behaviour of
> accepting multiple -m without complaining and discarding all but
> the last one silently is far worse than what is being proposed,
> and I do not see downside to the multiple -m patch, so let's
> apply that. You can have your "fmt -w60" provided if it is made
> into an option.
I'll rework the fmt -w60 patch to instead accept an optional filter
command from .git/config; if the filter command is set then the
command line commit message will get run through the filter before
being piped into git-commit-tree.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 0/10] re-based and expanded tree-walker cleanup patches
From: Shawn Pearce @ 2006-06-01 3:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <7vpshtyffk.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Linus Torvalds <torvalds@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
outputting the revisions?
git-rev-list --ancestors-first $revargs | git-format-patch --stdin
--
Shawn.
^ permalink raw reply
* Re: irc usage..
From: Alec Warner @ 2006-06-01 1:42 UTC (permalink / raw)
To: Martin Langhoff
Cc: Donnie Berkholz, Linus Torvalds, Yann Dirson, Git Mailing List,
Matthias Urlichs, Johannes Schindelin
In-Reply-To: <46a038f90605311503o1526c664qe61b0f3f40929b92@mail.gmail.com>
Martin Langhoff wrote:
> On 6/1/06, Alec Warner <antarus@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 raw reply
* Re: [PATCH] format-patch --signoff
From: Johannes Schindelin @ 2006-05-31 23:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Geoff Russell, Marco Costalba, git, Seth Falcon
In-Reply-To: <7vlkshyedf.fsf@assigned-by-dhcp.cox.net>
Hi,
On Wed, 31 May 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@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@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;
> append_to_commit_buffer(so_list->item);
> }
> return tail - commit_buffer;
Actually, I did not think of a linked list, but one buffer, but I like
your solution better.
> > And shouldn't we error out if there is not enough room for a sign-off?
>
> I do not think we error out if the commit message is too long
> either, so...
... so you could say that should be an error, too.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] http: prevent segfault during curl handle reuse
From: Nick Hengeveld @ 2006-05-31 23:25 UTC (permalink / raw)
To: git
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@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
@@ -25,7 +25,6 @@ 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;
@@ -208,7 +207,6 @@ 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:");
#ifdef USE_CURL_MULTI
{
@@ -344,9 +342,14 @@ #endif
slot->finished = NULL;
slot->callback_data = NULL;
slot->callback_func = NULL;
+ curl_easy_setopt(slot->curl, CURLOPT_HTTPHEADER, NULL);
curl_easy_setopt(slot->curl, CURLOPT_HTTPHEADER, pragma_header);
- curl_easy_setopt(slot->curl, CURLOPT_HTTPHEADER, no_range_header);
curl_easy_setopt(slot->curl, CURLOPT_ERRORBUFFER, curl_errorstr);
+ curl_easy_setopt(slot->curl, CURLOPT_CUSTOMREQUEST, NULL);
+ curl_easy_setopt(slot->curl, CURLOPT_READFUNCTION, NULL);
+ curl_easy_setopt(slot->curl, CURLOPT_WRITEFUNCTION, NULL);
+ curl_easy_setopt(slot->curl, CURLOPT_UPLOAD, 0);
+ curl_easy_setopt(slot->curl, CURLOPT_HTTPGET, 1);
return slot;
}
--
1.3.3.g2186-dirty
^ permalink raw reply related
* Re: [PATCH] format-patch --signoff
From: Junio C Hamano @ 2006-05-31 23:16 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Geoff Russell, Marco Costalba, git, Seth Falcon
In-Reply-To: <Pine.LNX.4.63.0606010032410.21774@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@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@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;
append_to_commit_buffer(so_list->item);
}
return tail - commit_buffer;
> And shouldn't we error out if there is not enough room for a sign-off?
I do not think we error out if the commit message is too long
either, so...
^ permalink raw reply
* [PATCH] send-email: only 'require' instead of 'use' Net::SMTP
From: Johannes Schindelin @ 2006-05-31 22:55 UTC (permalink / raw)
To: git, junkio, Eric Wong
This was proposed by Eric Wong and fixes the test. (Of course, git-send-email
does not work, if there is no Net::SMTP here, but it will say what is wrong
when you actually try to use send-email.)
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
git-send-email.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 0e368ff..ed1d89b 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -21,7 +21,6 @@ use warnings;
use Term::ReadLine;
use Getopt::Long;
use Data::Dumper;
-use Net::SMTP;
# most mail servers generate the Date: header, but not all...
$ENV{LC_ALL} = 'C';
@@ -394,6 +393,7 @@ X-Mailer: git-send-email $gitversion
print $sm "$header\n$message";
close $sm or die $?;
} else {
+ require Net::SMTP;
$smtp ||= Net::SMTP->new( $smtp_server );
$smtp->mail( $from ) or die $smtp->message;
$smtp->to( @recipients ) or die $smtp->message;
--
1.3.3.gc46d3-dirty
^ permalink raw reply related
* Re: [PATCH 0/10] re-based and expanded tree-walker cleanup patches
From: Junio C Hamano @ 2006-05-31 22:53 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0605292112530.5623@g5.osdl.org>
Linus Torvalds <torvalds@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
>
> because the "--pretty=oneline" format is actually very nice as a way to
> re-order things and select single commits to be deleted or whatever..
I am thinking about doing "format-patch --stdin" while I am
futzing with it for other reasons, and one issue is where to
"tac" the revision list.
We could internally reverse topo-sort what we read from --stdin
inside format-patch, but that would defeat the reordering that
is done in the step (b) above, so that is not a useful thing to
do.
If we wanted to make rev-list piped straight to format-patch
equilvalent to giving the arguments you would have given rev-list
directly to format-patch, then format-patch should read --stdin
and reverse the list before emitting them out.
However, that would mean in the step (b) above the user needs to
be conscious that the list being edited is in the reverse order,
so if the list of commits needs to be reordered (and that is one
of the reasons the user is doing this step) what comes earlier
in the edited list will be output later in the result.
Tentatively my feeling is that we should make it known that the
list format-patch takes from --stdin is supposed to be _not_
reversed, and do nothing in format-patch. In other words, the
list fed is a moral equivalent to quilt "series" file.
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?
^ permalink raw reply
* Re: [PATCH] format-patch --signoff
From: Johannes Schindelin @ 2006-05-31 22:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Geoff Russell, Marco Costalba, git, Seth Falcon
In-Reply-To: <7v4pz5zvtc.fsf_-_@assigned-by-dhcp.cox.net>
Hi,
On Wed, 31 May 2006, Junio C Hamano wrote:
> This resurrects --signoff option to format-patch.
Sorry; I was in cinema, so I missed all the action.
> + const char *committer = git_committer_info(1);
> + const char *endpos = strchr(committer, '>');
> + if (!endpos)
> + die("bogos committer info %s\n", committer);
> + add_signoff = xmalloc(endpos - committer + 2);
> + memcpy(add_signoff, committer, endpos - committer + 1);
> + add_signoff[endpos - committer + 1] = 0;
> + }
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@mit.com>"'), and
maybe even Acked-by's?
> + /* First see if we already have the sign-off by the signer */
> + while (1) {
> + cp = strstr(cp, signed_off_by);
> + if (!cp)
> + break;
> + cp += strlen(signed_off_by);
> + if ((cp + signoff_len < buf + at) &&
> + !strncmp(cp, signoff, signoff_len) &&
> + isspace(cp[signoff_len]))
> + return at; /* we already have him */
> + }
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.
And shouldn't we error out if there is not enough room for a sign-off?
Sorry for all the nit-picking.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] format-patch --signoff
From: Junio C Hamano @ 2006-05-31 22:14 UTC (permalink / raw)
To: Geoff Russell, Marco Costalba, Johannes Schindelin; +Cc: git, Seth Falcon
In-Reply-To: <7vejyayq46.fsf@assigned-by-dhcp.cox.net>
This resurrects --signoff option to format-patch.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
builtin-log.c | 18 ++++++++++++++++--
log-tree.c | 35 +++++++++++++++++++++++++++++++++++
revision.h | 1 +
3 files changed, 52 insertions(+), 2 deletions(-)
diff --git a/builtin-log.c b/builtin-log.c
index db1912a..ac4822d 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -150,6 +150,7 @@ int cmd_format_patch(int argc, const cha
int numbered = 0;
int start_number = -1;
int keep_subject = 0;
+ char *add_signoff = NULL;
init_revisions(&rev);
rev.commit_format = CMIT_FMT_EMAIL;
@@ -179,11 +180,13 @@ int cmd_format_patch(int argc, const cha
if (i == argc)
die("Need a number for --start-number");
start_number = strtol(argv[i], NULL, 10);
- } else if (!strcmp(argv[i], "-k") ||
+ }
+ else if (!strcmp(argv[i], "-k") ||
!strcmp(argv[i], "--keep-subject")) {
keep_subject = 1;
rev.total = -1;
- } else if (!strcmp(argv[i], "-o")) {
+ }
+ else if (!strcmp(argv[i], "-o")) {
if (argc < 3)
die ("Which directory?");
if (mkdir(argv[i + 1], 0777) < 0 && errno != EEXIST)
@@ -192,6 +195,16 @@ int cmd_format_patch(int argc, const cha
output_directory = strdup(argv[i + 1]);
i++;
}
+ else if (!strcmp(argv[i], "--signoff") ||
+ !strcmp(argv[i], "-s")) {
+ const char *committer = git_committer_info(1);
+ const char *endpos = strchr(committer, '>');
+ if (!endpos)
+ die("bogos committer info %s\n", committer);
+ add_signoff = xmalloc(endpos - committer + 2);
+ memcpy(add_signoff, committer, endpos - committer + 1);
+ add_signoff[endpos - committer + 1] = 0;
+ }
else if (!strcmp(argv[i], "--attach"))
rev.mime_boundary = git_version_string;
else if (!strncmp(argv[i], "--attach=", 9))
@@ -230,6 +243,7 @@ int cmd_format_patch(int argc, const cha
total = nr;
if (numbered)
rev.total = total + start_number - 1;
+ rev.add_signoff = add_signoff;
while (0 <= --nr) {
int shown;
commit = list[nr];
diff --git a/log-tree.c b/log-tree.c
index 58b0163..e86e16b 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -12,6 +12,37 @@ static void show_parents(struct commit *
}
}
+static int append_signoff(char *buf, int buf_sz, int at, const char *signoff)
+{
+ int signoff_len = strlen(signoff);
+ static const char signed_off_by[] = "Signed-off-by: ";
+ char *cp = buf;
+
+ /* Do we have enough space to add it? */
+ if (buf_sz - at <= strlen(signed_off_by) + signoff_len + 2)
+ return at;
+
+ /* First see if we already have the sign-off by the signer */
+ while (1) {
+ cp = strstr(cp, signed_off_by);
+ if (!cp)
+ break;
+ cp += strlen(signed_off_by);
+ if ((cp + signoff_len < buf + at) &&
+ !strncmp(cp, signoff, signoff_len) &&
+ isspace(cp[signoff_len]))
+ return at; /* we already have him */
+ }
+
+ strcpy(buf + at, signed_off_by);
+ at += strlen(signed_off_by);
+ strcpy(buf + at, signoff);
+ at += signoff_len;
+ buf[at++] = '\n';
+ buf[at] = 0;
+ return at;
+}
+
void show_log(struct rev_info *opt, struct log_info *log, const char *sep)
{
static char this_header[16384];
@@ -111,6 +142,10 @@ void show_log(struct rev_info *opt, stru
* And then the pretty-printed message itself
*/
len = pretty_print_commit(opt->commit_format, commit, ~0u, this_header, sizeof(this_header), abbrev, subject, after_subject);
+
+ if (opt->add_signoff)
+ len = append_signoff(this_header, sizeof(this_header), len,
+ opt->add_signoff);
printf("%s%s%s", this_header, extra, sep);
}
diff --git a/revision.h b/revision.h
index bdbdd23..75796bc 100644
--- a/revision.h
+++ b/revision.h
@@ -60,6 +60,7 @@ struct rev_info {
struct log_info *loginfo;
int nr, total;
const char *mime_boundary;
+ const char *add_signoff;
/* special limits */
int max_count;
--
1.3.3.g1361-dirty
^ permalink raw reply related
* Re: irc usage..
From: Martin Langhoff @ 2006-05-31 22:03 UTC (permalink / raw)
To: antarus
Cc: Donnie Berkholz, Linus Torvalds, Yann Dirson, Git Mailing List,
Matthias Urlichs, Johannes Schindelin
In-Reply-To: <447DA028.3040606@gentoo.org>
On 6/1/06, Alec Warner <antarus@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
^ permalink raw reply
* Re: git --version
From: Paolo Ciarrocchi @ 2006-05-31 20:19 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0605311311480.24646@g5.osdl.org>
On 5/31/06, Linus Torvalds <torvalds@osdl.org> wrote:
>
>
> On Wed, 31 May 2006, Paolo Ciarrocchi wrote:
> >
> > Don't know whay $PATH are different
>
> See ENVIRONMENT in the sudo man-page:
>
> PATH Set to a sane value if sudo was configured with
> the --with-secure-path option
>
> so apparently your distro builds sudo with "--with-secure-path".
Yup, you must be correct. Thanks.
My distro is Ubuntu Dapper.
Ciao,
--
Paolo
http://paolociarrocchi.googlepages.com
^ permalink raw reply
* Re: git --version
From: Linus Torvalds @ 2006-05-31 20:16 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: Junio C Hamano, git
In-Reply-To: <4d8e3fd30605311308j6a784635g91e2721258f53c9f@mail.gmail.com>
On Wed, 31 May 2006, Paolo Ciarrocchi wrote:
>
> Don't know whay $PATH are different
See ENVIRONMENT in the sudo man-page:
PATH Set to a sane value if sudo was configured with
the --with-secure-path option
so apparently your distro builds sudo with "--with-secure-path".
Linus
^ permalink raw reply
* Re: git --version
From: Paolo Ciarrocchi @ 2006-05-31 20:08 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <4d8e3fd30605311256o67e45d06ve0efeff65fcf4851@mail.gmail.com>
On 5/31/06, Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> wrote:
> On 5/31/06, Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> wrote:
> [...]
> > And even more intersting:
> > make clean && make && sudo make install
> > git --version
> > git version 1.3.GIT
> >
> > make install
> > [...]
> > mv git-cherry-pick+ git-cherry-pick
> > mv: sovrascrivo `git-cherry-pick' ignorando il modo 0755?
> > that in english is something like:
> > mv: overwrite `git-cherry-pick' ignoring mod 0755?
> >
> > Wow...of course, make clean && make install fix everything
> >
>
> Thanks to loops on #git for asking me to do the following test:
>
> <PaoloC> paolo@Italia:~/git$ sudo ./GIT-VERSION-GEN
> <PaoloC> GIT_VERSION = 1.3.GIT
> <PaoloC> paolo@Italia:~/git$ ./GIT-VERSION-GEN
> <PaoloC> GIT_VERSION = 1.3.3.g2186
>
> I don't know why it's happening...
Ok, thanks to the people living in #git!!
the problem is the following, from GIT-VERSION-GEN:
#!/bin/sh
GVF=GIT-VERSION-FILE
DEF_VER=v1.3.GIT
# First try git-describe, then see if there is a version file
# (included in release tarballs), then default
if VN=$(git describe --abbrev=4 HEAD 2>/dev/null); then
VN=$(echo "$VN" | sed -e 's/-/./g');
elif test -f version
then
VN=$(cat version) || VN="$DEF_VER"
else
VN="$DEF_VER"
fi
paolo@Italia:~/git$ git describe --abbrev=4 HEAD
v1.3.3-g2186
but...
paolo@Italia:~/git$ sudo git describe --abbrev=4 HEAD
sudo: git: command not found
that's because:
paolo@Italia:~/git$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/games:/home/paolo/bin
but...
paolo@Italia:~/git$ sudo sh
sh-3.1# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin
Don't know whay $PATH are different but at least why I know why git
has that strange behaviour.
Ciao,
--
Paolo
http://paolociarrocchi.googlepages.com
^ permalink raw reply
* Re: git --version
From: Linus Torvalds @ 2006-05-31 20:08 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: Junio C Hamano, git
In-Reply-To: <4d8e3fd30605311256o67e45d06ve0efeff65fcf4851@mail.gmail.com>
On Wed, 31 May 2006, Paolo Ciarrocchi wrote:
>
> Thanks to loops on #git for asking me to do the following test:
>
> <PaoloC> paolo@Italia:~/git$ sudo ./GIT-VERSION-GEN
> <PaoloC> GIT_VERSION = 1.3.GIT
> <PaoloC> paolo@Italia:~/git$ ./GIT-VERSION-GEN
> <PaoloC> GIT_VERSION = 1.3.3.g2186
>
> I don't know why it's happening...
Heh. You don't have git in your PATH as root. So as root you don't know
what version of git you have ;)
Linus
^ permalink raw reply
* Re: git --version
From: Paolo Ciarrocchi @ 2006-05-31 19:56 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <4d8e3fd30605311249l6ba4ff74l72778ffe60462263@mail.gmail.com>
On 5/31/06, Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> wrote:
[...]
> And even more intersting:
> make clean && make && sudo make install
> git --version
> git version 1.3.GIT
>
> make install
> [...]
> mv git-cherry-pick+ git-cherry-pick
> mv: sovrascrivo `git-cherry-pick' ignorando il modo 0755?
> that in english is something like:
> mv: overwrite `git-cherry-pick' ignoring mod 0755?
>
> Wow...of course, make clean && make install fix everything
>
Thanks to loops on #git for asking me to do the following test:
<PaoloC> paolo@Italia:~/git$ sudo ./GIT-VERSION-GEN
<PaoloC> GIT_VERSION = 1.3.GIT
<PaoloC> paolo@Italia:~/git$ ./GIT-VERSION-GEN
<PaoloC> GIT_VERSION = 1.3.3.g2186
I don't know why it's happening...
--
Paolo
http://paolociarrocchi.googlepages.com
^ 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