* [PATCH] instaweb: added support Ruby's WEBrick server
From: mike dalessio @ 2007-09-18 12:16 UTC (permalink / raw)
To: git, mike, normalperson
running the webrick server with git requires Ruby and Ruby's YAML and
Webrick libraries (both of which come standard with Ruby). nice for
single-user standalone invocations.
the --httpd=webrick option generates a ruby script on the fly to read
httpd.conf options and invoke the web server via library call. this
script is placed in the .git/gitweb directory. it also generates a
shell script in a feeble attempt to invoke ruby in a portable manner,
which assumes that 'ruby' is in the user's $PATH.
Signed-off-by: Mike Dalessio <mike@csa.net>
---
Documentation/git-instaweb.txt | 3 +-
git-instaweb.sh | 44 +++++++++++++++++++++++++++++++++++++++-
2 files changed, 45 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-instaweb.txt b/Documentation/git-instaweb.txt
index cec60ee..914fc4c 100644
--- a/Documentation/git-instaweb.txt
+++ b/Documentation/git-instaweb.txt
@@ -27,7 +27,8 @@ OPTIONS
The HTTP daemon command-line that will be executed.
Command-line options may be specified here, and the
configuration file will be added at the end of the command-line.
- Currently, lighttpd and apache2 are the only supported servers.
+ Currently, lighttpd, apache2 and webrick are the only supported
+ servers.
(Default: lighttpd)
-m|--module-path::
diff --git a/git-instaweb.sh b/git-instaweb.sh
index b79c6b6..803a754 100755
--- a/git-instaweb.sh
+++ b/git-instaweb.sh
@@ -37,7 +37,9 @@ start_httpd () {
else
# many httpds are installed in /usr/sbin or /usr/local/sbin
# these days and those are not in most users $PATHs
- for i in /usr/local/sbin /usr/sbin
+ # in addition, we may have generated a server script
+ # in $fqgitdir/gitweb.
+ for i in /usr/local/sbin /usr/sbin $fqgitdir/gitweb
do
if test -x "$i/$httpd_only"
then
@@ -137,6 +139,43 @@ GIT_DIR="$fqgitdir"
export GIT_EXEC_PATH GIT_DIR
+webrick_conf () {
+ # generate a standalone server script in $fqgitdir/gitweb.
+ cat > "$fqgitdir/gitweb/$httpd.rb" <<EOF
+require 'webrick'
+require 'yaml'
+options = YAML::load_file(ARGV[0])
+options[:StartCallback] = proc do
+ File.open(options[:PidFile],"w") do |f|
+ f.puts Process.pid
+ end
+end
+options[:ServerType] = WEBrick::Daemon
+server = WEBrick::HTTPServer.new(options)
+['INT', 'TERM'].each do |signal|
+ trap(signal) {server.shutdown}
+end
+server.start
+EOF
+ # generate a shell script to invoke the above ruby script,
+ # which assumes _ruby_ is in the user's $PATH. that's _one_
+ # portable way to run ruby, which could be installed anywhere,
+ # really.
+ cat > "$fqgitdir/gitweb/$httpd" <<EOF
+#! /bin/sh
+ruby $fqgitdir/gitweb/$httpd.rb \$*
+EOF
+ chmod +x "$fqgitdir/gitweb/$httpd"
+
+ cat > "$conf" <<EOF
+:Port: $port
+:DocumentRoot: "$fqgitdir/gitweb"
+:DirectoryIndex: ["gitweb.cgi"]
+:PidFile: "$fqgitdir/pid"
+EOF
+ test "$local" = true && echo ':BindAddress: "127.0.0.1"' >> "$conf"
+}
+
lighttpd_conf () {
cat > "$conf" <<EOF
server.document-root = "$fqgitdir/gitweb"
@@ -237,6 +276,9 @@ case "$httpd" in
*apache2*)
apache2_conf
;;
+webrick)
+ webrick_conf
+ ;;
*)
echo "Unknown httpd specified: $httpd"
exit 1
--
1.5.2.5
^ permalink raw reply related
* [PATCH] Fixed update-hook example allow-users format.
From: Väinö Järvelä @ 2007-09-18 12:26 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Väinö Järvelä
The example provided with the update-hook-example does not work on
either bash 2.05b.0(1)-release nor 3.1.17(1)-release. The matcher did
not match the lines that it advertised to match, such as:
refs/heads/bw/ linus
refs/heads/tmp/* *
In POSIX 1003.2 regular expressions, the star (*), is not an wildcard
meaning "match everything", it matches 0 or more matches of the atom
preceding it.
So to match "refs/heads/bw/topic-branch", the matcher should be written
as "refs/heads/bw/.*" to match "refs/heads/bw/" and everything after it.
---
Documentation/howto/update-hook-example.txt | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/howto/update-hook-example.txt b/Documentation/howto/update-hook-example.txt
index 3a33696..88765b5 100644
--- a/Documentation/howto/update-hook-example.txt
+++ b/Documentation/howto/update-hook-example.txt
@@ -158,11 +158,11 @@ This uses two files, $GIT_DIR/info/allowed-users and
allowed-groups, to describe which heads can be pushed into by
whom. The format of each file would look like this:
- refs/heads/master junio
+ refs/heads/master junio
refs/heads/cogito$ pasky
- refs/heads/bw/ linus
- refs/heads/tmp/ *
- refs/tags/v[0-9]* junio
+ refs/heads/bw/.* linus
+ refs/heads/tmp/.* .*
+ refs/tags/v[0-9].* junio
With this, Linus can push or create "bw/penguin" or "bw/zebra"
or "bw/panda" branches, Pasky can do only "cogito", and JC can
--
1.5.3.1.2.gd7c01
^ permalink raw reply related
* Re: [PATCH] git-merge: add option --no-ff
From: Johannes Schindelin @ 2007-09-18 12:29 UTC (permalink / raw)
To: Lars Hjemli
Cc: Sam Vilain, Junio C Hamano, Eric Wong, Andreas Ericsson,
Chris Shoemaker, git
In-Reply-To: <8c5c35580709180419i4500a2d4s8a997d45dd31944e@mail.gmail.com>
Hi,
On Tue, 18 Sep 2007, Lars Hjemli wrote:
> Sidenote: this might be slightly controversial, but I've sometimes
> missed a --no-ff option to 'git merge' when working on plain git
> repositories; IMHO preserving the 'logical' merge history when the merge
> of a topic branch results in a fast-forward can be interesting.
Linus explained a lot of times why this is wrong. It encourages
upstream-downstream thinking. We should really turn this into a FAQ.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] git-send-email: Add a --cc-nobody option
From: felipebalbi @ 2007-09-18 11:42 UTC (permalink / raw)
To: git, ae; +Cc: Felipe Balbi
From: Felipe Balbi <felipe.lima@indt.org.br>
This patch adds a --cc-nobody option to avoid sending emails
to everybody but the ones listed by --to option.
Signed-off-by: Felipe Balbi <felipe.lima@indt.org.br>
---
git-send-email.perl | 16 ++++++++++++----
1 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 4031e86..a5a466c 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -88,6 +88,9 @@ Options:
--suppress-from Suppress sending emails to yourself if your address
appears in a From: line. Defaults to off.
+ --cc-nobody Do not send emails to anyone unless explicitly listed by
+ --to option.
+
--thread Specify that the "In-Reply-To:" header should be set on all
emails. Defaults to on.
@@ -171,7 +174,7 @@ if ($@) {
my ($quiet, $dry_run) = (0, 0);
# Variables with corresponding config settings
-my ($thread, $chain_reply_to, $suppress_from, $signed_off_cc, $cc_cmd);
+my ($thread, $chain_reply_to, $suppress_from, $cc_nobody, $signed_off_cc, $cc_cmd);
my ($smtp_server, $smtp_authuser, $smtp_authpass, $smtp_ssl);
my ($identity, $aliasfiletype, @alias_files);
@@ -179,6 +182,7 @@ my %config_bool_settings = (
"thread" => [\$thread, 1],
"chainreplyto" => [\$chain_reply_to, 1],
"suppressfrom" => [\$suppress_from, 0],
+ "ccnobody" => [\$cc_nobody, 0],
"signedoffcc" => [\$signed_off_cc, 1],
"smtpssl" => [\$smtp_ssl, 0],
);
@@ -212,6 +216,7 @@ my $rc = GetOptions("sender|from=s" => \$sender,
"quiet" => \$quiet,
"cc-cmd=s" => \$cc_cmd,
"suppress-from!" => \$suppress_from,
+ "cc-nobody!" => \$cc_nobody,
"signed-off-cc|signed-off-by-cc!" => \$signed_off_cc,
"dry-run" => \$dry_run,
"envelope-sender=s" => \$envelope_sender,
@@ -669,8 +674,11 @@ foreach my $t (@files) {
$subject = $1;
} elsif (/^(Cc|From):\s+(.*)$/) {
- if (unquote_rfc2047($2) eq $sender) {
- next if ($suppress_from);
+ if (unquote_rfc2047($2)) {
+ next if ($cc_nobody);
+ }
+ elsif (unquote_rfc2047($2) eq $sender) {
+ next if ($suppress_from|$cc_nobody);
}
elsif ($1 eq 'From') {
$author = unquote_rfc2047($2);
@@ -707,7 +715,7 @@ foreach my $t (@files) {
}
} else {
$message .= $_;
- if (/^(Signed-off-by|Cc): (.*)$/i && $signed_off_cc) {
+ if (/^(Signed-off-by|Cc): (.*)$/i && $signed_off_cc && !$cc_nobody) {
my $c = $2;
chomp $c;
push @cc, $c;
--
1.5.3.1.91.gd3392
^ permalink raw reply related
* Re: [PATCH] contrib/fast-import: add perl version of simple example
From: Johannes Schindelin @ 2007-09-18 12:36 UTC (permalink / raw)
To: Sam Vilain
Cc: Jeff King, Andreas Ericsson, Junio C Hamano, git, Shawn O. Pearce
In-Reply-To: <46EFBD40.1070102@vilain.net>
Hi,
On Tue, 18 Sep 2007, Sam Vilain wrote:
> I personally want to be able to dump patches, including merges, to
> git-format-patch format, in such a way that all other information (eg,
> committer, date, etc) is preserved.
We already talked about that on IRC, and you have not even _begun_ to
think about the fundamental issues with merges-in-a-patch. I mentioned a
few on IRC, and am still awaiting your reply.
Unless you tackle those fundamental issues, I am afraid it is not worth
bothering to discuss this subject any more.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-merge: add option --no-ff
From: Lars Hjemli @ 2007-09-18 12:38 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0709181319050.28586@racer.site>
[...stripped the Cc, as we're slightly changing topic...]
On 9/18/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Tue, 18 Sep 2007, Lars Hjemli wrote:
> > Sidenote: this might be slightly controversial, but I've sometimes
> > missed a --no-ff option to 'git merge' when working on plain git
> > repositories; IMHO preserving the 'logical' merge history when the merge
> > of a topic branch results in a fast-forward can be interesting.
>
> Linus explained a lot of times why this is wrong. It encourages
> upstream-downstream thinking. We should really turn this into a FAQ.
Well, the cases where I've wanted to do this is when I've developed
some new feature in cgit as a topic branch. I've then merged the topic
branch into my master branch which had been idle since the creation of
the topic branch (cgit doesn't get as many patches as git...). So I
get a fast-forward and my precious topic-branch is no longer visible
(at least for anyone cloning my repo). Not very important, but I'd
like to preserve the fact that this was a topic branch. How would this
encourage 'upstream-downstream thinking'?
--
larsh
^ permalink raw reply
* Re: [PATCH] git-send-email: Add a --cc-nobody option
From: Alex Unleashed @ 2007-09-18 12:50 UTC (permalink / raw)
To: felipebalbi@users.sourceforge.net; +Cc: git, ae, Felipe Balbi
In-Reply-To: <11901157221792-git-send-email-felipebalbi@users.sourceforge.net>
On 9/18/07, felipebalbi@users.sourceforge.net
<felipebalbi@users.sourceforge.net> wrote:
> From: Felipe Balbi <felipe.lima@indt.org.br>
>
> This patch adds a --cc-nobody option to avoid sending emails
> to everybody but the ones listed by --to option.
>
> Signed-off-by: Felipe Balbi <felipe.lima@indt.org.br>
I wrote a similar patch a couple months ago, but they differ slightly,
maybe the code has changed somewhat:
http://marc.info/?l=git&m=118200193310898&w=2
--cc-nobody sounds better to me.
> } elsif (/^(Cc|From):\s+(.*)$/) {
> - if (unquote_rfc2047($2) eq $sender) {
> - next if ($suppress_from);
> + if (unquote_rfc2047($2)) {
> + next if ($cc_nobody);
> + }
> + elsif (unquote_rfc2047($2) eq $sender) {
> + next if ($suppress_from|$cc_nobody);
> }
> elsif ($1 eq 'From') {
> $author = unquote_rfc2047($2);
Here you could probably skip the whole branch if you check $cc_nobody
first of all.
> @@ -707,7 +715,7 @@ foreach my $t (@files) {
> }
> } else {
> $message .= $_;
> - if (/^(Signed-off-by|Cc): (.*)$/i && $signed_off_cc) {
> + if (/^(Signed-off-by|Cc): (.*)$/i && $signed_off_cc && !$cc_nobody) {
Minor, but almost the same here.
Alex
^ permalink raw reply
* Re: git-svn error when cloning apache repo
From: Jing Xue @ 2007-09-18 12:53 UTC (permalink / raw)
To: Sam Vilain; +Cc: git
In-Reply-To: <46ED17A9.2010603@vilain.net>
On Sun, Sep 16, 2007 at 11:46:49PM +1200, Sam Vilain wrote:
> Jing Xue wrote:
> > $ git svn clone https://svn.apache.org/repos/asf/incubator/ivy/core/ ivy-core -T trunk -b branches -t tags
> > Initialized empty Git repository in .git/
> > Using higher level of URL: https://svn.apache.org/repos/asf/incubator/ivy/core => https://svn.apache.org/repos/asf
> >
>
> I'm fairly sure this is where it went wrong. Try editing .git/config and
> putting your original URL in the source URL, and re-try the fetch.
Hmm... thanks, but didn't work. The repo didn't look right to begin
with. The HEAD pointed to refs/heads/master as usual, but there was
nothing in refs/heads at all.
I also tried:
git svn clone https://svn.apache.org/repos/asf/ ivy-core -s --prefix=incubator/ivy/core/
And got no errors, but there wasn't any working tree in ivy-core
afterwards. Then I tried 'git svn rebase':
fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions
fatal: Needed a single revision
invalid upstream
Due to the same "nothing in refs/heads" situation. Also there is this
23M file .git/svn/incubator/ivy/core/trunk/.rev_db.13f79535-47bb-0310-9956-ffa450edef6
that contains all 0's.
The part before "I also tried..." was with git 1.5.3. "I also tried..."
was with git 1.5.3.1.112.gb7a2 as of last night.
Cheers.
--
Jing Xue
^ permalink raw reply
* Re: [PATCH] git-send-email: Add a --cc-nobody option
From: Felipe Balbi @ 2007-09-18 13:01 UTC (permalink / raw)
To: Alex Unleashed; +Cc: git, ae, Felipe Balbi
In-Reply-To: <5e4707340709180550w3211e95fqd9fd648aab8ce78a@mail.gmail.com>
hi,
On 9/18/07, Alex Unleashed <unledev@gmail.com> wrote:
> On 9/18/07, felipebalbi@users.sourceforge.net
> <felipebalbi@users.sourceforge.net> wrote:
> > From: Felipe Balbi <felipe.lima@indt.org.br>
> >
> > This patch adds a --cc-nobody option to avoid sending emails
> > to everybody but the ones listed by --to option.
> >
> > Signed-off-by: Felipe Balbi <felipe.lima@indt.org.br>
>
> I wrote a similar patch a couple months ago, but they differ slightly,
> maybe the code has changed somewhat:
> http://marc.info/?l=git&m=118200193310898&w=2
>
> --cc-nobody sounds better to me.
>
> > } elsif (/^(Cc|From):\s+(.*)$/) {
> > - if (unquote_rfc2047($2) eq $sender) {
> > - next if ($suppress_from);
> > + if (unquote_rfc2047($2)) {
> > + next if ($cc_nobody);
> > + }
> > + elsif (unquote_rfc2047($2) eq $sender) {
> > + next if ($suppress_from|$cc_nobody);
> > }
> > elsif ($1 eq 'From') {
> > $author = unquote_rfc2047($2);
>
> Here you could probably skip the whole branch if you check $cc_nobody
> first of all.
Yeah, I tested this one too but when sending emails I was changing all
those From lines to my address, which means every mail I was sending
the patch would take my authorship.
So it looked better guaranteeing the authorship
>
> > @@ -707,7 +715,7 @@ foreach my $t (@files) {
> > }
> > } else {
> > $message .= $_;
> > - if (/^(Signed-off-by|Cc): (.*)$/i && $signed_off_cc) {
> > + if (/^(Signed-off-by|Cc): (.*)$/i && $signed_off_cc && !$cc_nobody) {
>
> Minor, but almost the same here.
sanity
>
> Alex
>
--
Best Regards,
Felipe Balbi
felipebalbi@users.sourceforge.net
^ permalink raw reply
* Re: [PATCH 1/3] git-apply: fix whitespace stripping
From: J. Bruce Fields @ 2007-09-18 13:12 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86r6kw4aki.fsf@lola.quinscape.zz>
On Tue, Sep 18, 2007 at 10:55:25AM +0200, David Kastrup wrote:
> As far as I can see, this does not really work since it does not
> maintain an idea of a current column.
>
> If you have
>
> abcd<four spaces><tab><four spaces><tab>
>
> then indeed the resulting conversion needs to be <tab><tab><tab>
> whereas with
>
> abc<four spaces><tab><four spaces><tab>
>
> the resulting conversion needs to be just <tab><tab>
Note that this code *only* handles whitespace in the initial indent;
processing stops as soon as it hits anything other than a tab or an
indent.
Given that, I believe the proposed patch is correct. Am I missing
something else?
--b.
^ permalink raw reply
* Re: [PATCH 4/7] Clean up stripspace a bit, use strbuf even more.
From: Johannes Schindelin @ 2007-09-18 13:12 UTC (permalink / raw)
To: Kristian Høgsberg; +Cc: git
In-Reply-To: <11900740153845-git-send-email-krh@redhat.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1001 bytes --]
Hi,
I really like your patch, except for this:
On Mon, 17 Sep 2007, Kristian Høgsberg wrote:
> diff --git a/builtin.h b/builtin.h
> index 03ee7bf..d6f2c76 100644
> --- a/builtin.h
> +++ b/builtin.h
> @@ -7,7 +7,6 @@ extern const char git_version_string[];
> extern const char git_usage_string[];
>
> extern void help_unknown_cmd(const char *cmd);
> -extern size_t stripspace(char *buffer, size_t length, int skip_comments);
> extern int write_tree(unsigned char *sha1, int missing_ok, const char *prefix);
> extern void prune_packed_objects(int);
>
> diff --git a/strbuf.h b/strbuf.h
> index 21fc111..5960637 100644
> --- a/strbuf.h
> +++ b/strbuf.h
> @@ -98,4 +98,6 @@ extern ssize_t strbuf_read(struct strbuf *, int fd, size_t hint);
>
> extern void read_line(struct strbuf *, FILE *, int);
>
> +extern void stripspace(struct strbuf *buf, int skip_comments);
> +
> #endif /* STRBUF_H */
If you do that, you have to move the function "stripspace" to strbuf.c,
too...
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 6/7] Export rerere() and launch_editor().
From: Johannes Schindelin @ 2007-09-18 13:14 UTC (permalink / raw)
To: Kristian Høgsberg; +Cc: git
In-Reply-To: <1190074016669-git-send-email-krh@redhat.com>
Hi,
I see rerere() in the patch, but not launch_editor().
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-merge: add option --no-ff
From: Sam Vilain @ 2007-09-18 13:22 UTC (permalink / raw)
To: Lars Hjemli
Cc: Junio C Hamano, Eric Wong, Andreas Ericsson, Johannes Schindelin,
Chris Shoemaker, git
In-Reply-To: <8c5c35580709180503g24ef6c5hda2877e2215ba58d@mail.gmail.com>
Lars Hjemli wrote:
> [...sorry for making this such a long thread...]
>
> On 9/18/07, Sam Vilain <sam@vilain.net> wrote:
>
>> Lars Hjemli wrote:
>>
>>> On 9/18/07, Sam Vilain <sam@vilain.net> wrote:
>>>
>>>
>>>> I think that writing a real fast-forward merge should only happen on
>>>> dcommit, not git merge, because that is what is required for SVN.
>>>>
>>>>
>>> I don't think git-svn has any way of knowing that the user wanted a
>>> merge, unless a merge commit is present. So the user would have to
>>> specify the set of commits which should be considered a merge during
>>> dcommit (this would actually resemble how merges are performed in
>>> subversion).
>>>
>>>
>> Sure it can. If you're committing to branch X, and the current tree has
>> a whole lot of commits above that, then it should do the only thing you
>> can do with SVN.
>>
>> Which is write a squash commit, and set the "svn:merge" and/or
>> "svk:merge" properties to represent what happened.
>>
>
> I often have prepared a series of local commits which I _want_ to
> preserve as different subversion revisions.
>
But for the scenario we are discussing the revisions already exist
upstream otherwise there would be no fast forward merge. So, if you
want that behaviour you can use cherry-pick on the git side and the
correct behaviour for git-svn is to write svn merge properties.
> Also, doing a --squash means that I loose the merge history in git
> (and then I need to edit the grafts file again)
>
There is no merge history in git, it was a fast forward.
>>> Sidenote: this might be slightly controversial, but I've sometimes
>>> missed a --no-ff option to 'git merge' when working on plain git
>>> repositories; IMHO preserving the 'logical' merge history when the
>>> merge of a topic branch results in a fast-forward can be interesting.
>>>
>> If you really want one, use git commit-tree directly.
>>
> Yeah, that's an option, but --no-ff is somewhat less work ;-)
>
Sure. I just don't see a good use case for it from this yet.
Sam.
^ permalink raw reply
* Re: [PATCH 1/1] git-send-email: Add a --suppress-all option
From: J. Bruce Fields @ 2007-09-18 13:22 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Felipe Balbi, git, Felipe Balbi
In-Reply-To: <46EF8107.1030607@op5.se>
On Tue, Sep 18, 2007 at 09:40:55AM +0200, Andreas Ericsson wrote:
> Felipe Balbi wrote:
>> From: Felipe Balbi <felipe.lima@indt.org.br>
>> This patch adds a --suppress-all option to avoid sending emails
>> to everybody but the ones listed by --to option.
>
> To my minds eye, --suppress-all is equivalent to --dry-run. Could you
> rename it to "--cc-nobody" or some such?
>
> On a side-note, I've never really understood why git-send-email *by
> default*
> sends to a bazillion people. Does anybody ever use it without suppressing
> most of the CC targets?
Yes. I never suppress the cc's. The cc-everyone thing is standard on
the kernel mailing lists.
The one exception is if I'm just sending the series to myself as a test.
--b.
^ permalink raw reply
* Re: [PATCH] contrib/fast-import: add perl version of simple example
From: Sam Vilain @ 2007-09-18 13:25 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Jeff King, Andreas Ericsson, Junio C Hamano, git, Shawn O. Pearce
In-Reply-To: <Pine.LNX.4.64.0709181334210.28586@racer.site>
Johannes Schindelin wrote:
>> I personally want to be able to dump patches, including merges, to
>> git-format-patch format, in such a way that all other information (eg,
>> committer, date, etc) is preserved.
>>
>
> We already talked about that on IRC, and you have not even _begun_ to
> think about the fundamental issues with merges-in-a-patch. I mentioned a
> few on IRC, and am still awaiting your reply.
>
Well, you could store diffs from both parents, or a custom diff format
that marks different ancestors, etc. Sure, they wouldn't apply with
'patch', but that's the breaks.
I don't see the encoding of the information as such a fundamental and
insurmountable issue. Why do you consider it so?
Sam.
^ permalink raw reply
* Re: [PATCH 1/1] git-send-email: Add a --suppress-all option
From: Felipe Balbi @ 2007-09-18 13:29 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Andreas Ericsson, git, Felipe Balbi
In-Reply-To: <20070918132251.GB12120@fieldses.org>
Hi,
On 9/18/07, J. Bruce Fields <bfields@fieldses.org> wrote:
> On Tue, Sep 18, 2007 at 09:40:55AM +0200, Andreas Ericsson wrote:
> > Felipe Balbi wrote:
> >> From: Felipe Balbi <felipe.lima@indt.org.br>
> >> This patch adds a --suppress-all option to avoid sending emails
> >> to everybody but the ones listed by --to option.
> >
> > To my minds eye, --suppress-all is equivalent to --dry-run. Could you
> > rename it to "--cc-nobody" or some such?
> >
> > On a side-note, I've never really understood why git-send-email *by
> > default*
> > sends to a bazillion people. Does anybody ever use it without suppressing
> > most of the CC targets?
>
> Yes. I never suppress the cc's. The cc-everyone thing is standard on
> the kernel mailing lists.
>
> The one exception is if I'm just sending the series to myself as a test.
And that the motivation for this patch :-p
Internally (in my company, where I work), we send patches to each
other for code review before sending it publicly.
>
> --b.
>
--
Best Regards,
Felipe Balbi
felipebalbi@users.sourceforge.net
^ permalink raw reply
* Re: [rfc] git submodules howto
From: J. Bruce Fields @ 2007-09-18 13:29 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20070918105538.GL19019@genesis.frugalware.org>
On Tue, Sep 18, 2007 at 12:55:38PM +0200, Miklos Vajna wrote:
> 1) is this correct? :) i use it and it seem to do what i except, but
> maybe it's not correct
I'm not able to answer that question.
> 2) does this worth adding to the documentation? maybe to a .txt under
> Documentation/howto? or to git-submodule.txt?
Could you add it as a new chapter to user-manual.txt (probably just
after the "git concepts" chapter), and then add links to that chapter
from git-submodule(1) and gitmodules(5)?
--b.
^ permalink raw reply
* Re: [PATCH 4/7] Clean up stripspace a bit, use strbuf even more.
From: Kristian Høgsberg @ 2007-09-18 13:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0709181411200.28586@racer.site>
On Tue, 2007-09-18 at 14:12 +0100, Johannes Schindelin wrote:
> Hi,
>
> I really like your patch, except for this:
>
> On Mon, 17 Sep 2007, Kristian Høgsberg wrote:
>
> > diff --git a/builtin.h b/builtin.h
> > index 03ee7bf..d6f2c76 100644
> > --- a/builtin.h
> > +++ b/builtin.h
> > @@ -7,7 +7,6 @@ extern const char git_version_string[];
> > extern const char git_usage_string[];
> >
> > extern void help_unknown_cmd(const char *cmd);
> > -extern size_t stripspace(char *buffer, size_t length, int skip_comments);
> > extern int write_tree(unsigned char *sha1, int missing_ok, const char *prefix);
> > extern void prune_packed_objects(int);
> >
> > diff --git a/strbuf.h b/strbuf.h
> > index 21fc111..5960637 100644
> > --- a/strbuf.h
> > +++ b/strbuf.h
> > @@ -98,4 +98,6 @@ extern ssize_t strbuf_read(struct strbuf *, int fd, size_t hint);
> >
> > extern void read_line(struct strbuf *, FILE *, int);
> >
> > +extern void stripspace(struct strbuf *buf, int skip_comments);
> > +
> > #endif /* STRBUF_H */
>
> If you do that, you have to move the function "stripspace" to strbuf.c,
> too...
Right, the alternative is to #include strbuf.h in builtin.h, or maybe
just add struct strbuf; at the top. And with Pierres latest patch
strbuf is included everywhere, so maybe this is already moot.
Kristian
^ permalink raw reply
* Re: [PATCH 7/7] Implement git commit as a builtin command.
From: Johannes Schindelin @ 2007-09-18 13:58 UTC (permalink / raw)
To: Kristian Høgsberg; +Cc: git
In-Reply-To: <11900740163661-git-send-email-krh@redhat.com>
Hi,
very nice!
Four nits, though, and a half:
- it would be nicer to put the option parsing it option.[ch] (you would
also need to pass the usage line then, instead of hardwiring it to
"git_commit_usage"),
- it seems more logical to me to call it "parse_option()" than
"scan_options()", since that is what it does,
- you might want to rename OPTION_NONE to OPTION_BOOLEAN, and maybe even
allow "--no-<option>" in that case for free,
- wt_status_prepare() could take a parameter "index_file", which would
default to git_path("index") when passed as NULL, and
- launch_editor() is defined in builtin-tag.c, which is not part of the
library, and therefore it would be technically more correct to either
move the function to editor.c (my preferred solution), or declare it in
builtin.h instead of strbuf.h.
As you can see, my nits are really minor, which means that I am pretty
happy with your work!
Thanks,
Dscho
^ permalink raw reply
* Re: [PATCH] git-merge: add option --no-ff
From: Lars Hjemli @ 2007-09-18 14:01 UTC (permalink / raw)
To: Sam Vilain
Cc: Junio C Hamano, Eric Wong, Andreas Ericsson, Johannes Schindelin,
Chris Shoemaker, git
In-Reply-To: <46EFD0F8.5050603@vilain.net>
On 9/18/07, Sam Vilain <sam@vilain.net> wrote:
> Lars Hjemli wrote:
> > On 9/18/07, Sam Vilain <sam@vilain.net> wrote:
> >> If you really want one, use git commit-tree directly.
> >>
> > Yeah, that's an option, but --no-ff is somewhat less work ;-)
> >
>
> Sure. I just don't see a good use case for it from this yet.
Ok. I'll try to explain why I needed --no-ff in the first place:
I have two git-svn brances, lets call them FEATURE and RELEASE. At one
point, I did
$ git checkout FEATURE
$ git merge RELEASE
$ git svn dcommit
Now, my coworkers can continue testing/developing on top of the
subversion branch FEATURE (I'm currently the only git user), knowing
that every bugfix from RELEASE have been merged.
A few days later, FEATURE is completed and tested and should be
integrated in RELEASE. I did
$ git checkout RELEASE
$ git merge FEATURE
$ git svn dcommit -n
and noticed that git-svn wanted to commit the result to FEATURE, since
the merge actually was a fast-forward. If this was a a pure git
environment it would be no problem, but as I needed to get a merge
revision on top of the subversion RELEASE branch, I was in trouble.
My options:
* rebase FEATURE onto RELEASE: this would have duplicated ~150
revisions from FEATURE onto RELEASE in subversion
* merge --squash: this would have created the wanted history in
subversion, but my git history would have lacked the info that
everything in FEATURE had been integrated into RELEASE (this could
have been fixed by editing the grafts file)
* merge --no-ff: this made both the subversion history and my local
git history reflect what actually happened.
So I went for the --no-ff option.
If this use-case isn't good enough, oh well. I can always carry the
patch forward in my git repo ;-)
--
larsh
^ permalink raw reply
* Re: [PATCH 1/1] git-send-email: Add a --suppress-all option
From: David Kastrup @ 2007-09-18 14:15 UTC (permalink / raw)
To: git
In-Reply-To: <20070918132251.GB12120@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> writes:
> On Tue, Sep 18, 2007 at 09:40:55AM +0200, Andreas Ericsson wrote:
>> Felipe Balbi wrote:
>>> From: Felipe Balbi <felipe.lima@indt.org.br>
>>> This patch adds a --suppress-all option to avoid sending emails
>>> to everybody but the ones listed by --to option.
>>
>> To my minds eye, --suppress-all is equivalent to --dry-run. Could you
>> rename it to "--cc-nobody" or some such?
>>
>> On a side-note, I've never really understood why git-send-email *by
>> default*
>> sends to a bazillion people. Does anybody ever use it without suppressing
>> most of the CC targets?
>
> Yes. I never suppress the cc's. The cc-everyone thing is standard on
> the kernel mailing lists.
>
> The one exception is if I'm just sending the series to myself as a test.
Wouldn't --no-cc be a nicer option name?
--
David Kastrup
^ permalink raw reply
* Re: [PATCH] git-merge: add option --no-ff
From: Sam Vilain @ 2007-09-18 14:34 UTC (permalink / raw)
To: Lars Hjemli
Cc: Junio C Hamano, Eric Wong, Andreas Ericsson, Johannes Schindelin,
Chris Shoemaker, git
In-Reply-To: <8c5c35580709180701m54810d80nefa4704abb8797dd@mail.gmail.com>
Lars Hjemli wrote:
> Ok. I'll try to explain why I needed --no-ff in the first place:
>
> I have two git-svn brances, lets call them FEATURE and RELEASE. At one
> point, I did
> $ git checkout FEATURE
> $ git merge RELEASE
> $ git svn dcommit
>
> Now, my coworkers can continue testing/developing on top of the
> subversion branch FEATURE (I'm currently the only git user), knowing
> that every bugfix from RELEASE have been merged.
>
> A few days later, FEATURE is completed and tested and should be
> integrated in RELEASE. I did
>
> $ git checkout RELEASE
> $ git merge FEATURE
> $ git svn dcommit -n
>
> and noticed that git-svn wanted to commit the result to FEATURE, since
> the merge actually was a fast-forward. If this was a a pure git
> environment it would be no problem, but as I needed to get a merge
> revision on top of the subversion RELEASE branch, I was in trouble.
>
I understand. But if you could specify a target branch of "RELEASE" to
dcommit (which git-svn might know based on which svn tracking branch it
was branched from), then it should be able to do the same thing that
'svn merge' would do on svn 1.5+, or 'svk sm' does. Which is to write
to the SVN repository a squash merge, and write svn properties to let
merge-aware svn tools know which SVN revisions are being squashed.
> My options:
> * rebase FEATURE onto RELEASE: this would have duplicated ~150
> revisions from FEATURE onto RELEASE in subversion
>
Yes, not desirable.
> * merge --squash: this would have created the wanted history in
> subversion, but my git history would have lacked the info that
> everything in FEATURE had been integrated into RELEASE (this could
> have been fixed by editing the grafts file)
>
This is a current deficiency in git-svn; bidirectional merge tracking is
not there yet.
> * merge --no-ff: this made both the subversion history and my local
> git history reflect what actually happened.
>
> So I went for the --no-ff option.
>
> If this use-case isn't good enough, oh well. I can always carry the
> patch forward in my git repo ;-)
>
And you'll probably need to keep it around until bidirectional merge
handling is in.
Sam.
^ permalink raw reply
* Re: [PATCH 1/3] git-apply: fix whitespace stripping
From: David Kastrup @ 2007-09-18 14:18 UTC (permalink / raw)
To: git
In-Reply-To: <20070918131237.GA12120@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> writes:
> On Tue, Sep 18, 2007 at 10:55:25AM +0200, David Kastrup wrote:
>> As far as I can see, this does not really work since it does not
>> maintain an idea of a current column.
>>
>> If you have
>>
>> abcd<four spaces><tab><four spaces><tab>
>>
>> then indeed the resulting conversion needs to be <tab><tab><tab>
>> whereas with
>>
>> abc<four spaces><tab><four spaces><tab>
>>
>> the resulting conversion needs to be just <tab><tab>
>
> Note that this code *only* handles whitespace in the initial indent;
> processing stops as soon as it hits anything other than a tab or an
> indent.
>
> Given that, I believe the proposed patch is correct. Am I missing
> something else?
Don't think so. Sorry for the noise.
--
David Kastrup
^ permalink raw reply
* Re: [PATCH 1/1] git-send-email: Add a --suppress-all option
From: Felipe Balbi @ 2007-09-18 14:39 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86bqc03vrq.fsf@lola.quinscape.zz>
Hi,
On 9/18/07, David Kastrup <dak@gnu.org> wrote:
> "J. Bruce Fields" <bfields@fieldses.org> writes:
>
> > On Tue, Sep 18, 2007 at 09:40:55AM +0200, Andreas Ericsson wrote:
> >> Felipe Balbi wrote:
> >>> From: Felipe Balbi <felipe.lima@indt.org.br>
> >>> This patch adds a --suppress-all option to avoid sending emails
> >>> to everybody but the ones listed by --to option.
> >>
> >> To my minds eye, --suppress-all is equivalent to --dry-run. Could you
> >> rename it to "--cc-nobody" or some such?
> >>
> >> On a side-note, I've never really understood why git-send-email *by
> >> default*
> >> sends to a bazillion people. Does anybody ever use it without suppressing
> >> most of the CC targets?
> >
> > Yes. I never suppress the cc's. The cc-everyone thing is standard on
> > the kernel mailing lists.
> >
> > The one exception is if I'm just sending the series to myself as a test.
>
> Wouldn't --no-cc be a nicer option name?
It'll probably conflict if I don't wanna CC patch's author nor
Signed-off-by but DO want to CC somebody special like the maintainer.
the option is changed to --cc-nobody and it's already resent. :-)
>
> --
> David Kastrup
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Best Regards,
Felipe Balbi
felipebalbi@users.sourceforge.net
^ permalink raw reply
* Re: testsuite problems
From: René Scharfe @ 2007-09-18 14:57 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20070917220408.GG19019@genesis.frugalware.org>
Miklos Vajna schrieb:
> On Mon, Sep 17, 2007 at 11:50:32PM +0200, René Scharfe <rene.scharfe@lsrfire.ath.cx> wrote:
>> The failing tests check ZIP file creation, not tar file creation.
>> Perhaps your unzip command works a bit differently from Info-ZIP's?
>
> $ zip -v
> Copyright (c) 1990-2006 Info-ZIP - Type 'zip "-L"' for software license.
> This is Zip 2.32 (June 19th 2006), by Info-ZIP.
>
> should this version be ok?
Info-ZIP zip and unzip are two different programs, each with their
own version numbers.
>> Also, what is the difference between t/trash/a and t/trash/d/a after
>> running the test script (that's what test 21 is comparing)?
>
> $ diff -Naur t/trash/a t/trash/d/a
> diff -Naur t/trash/a/l1 t/trash/d/a/l1
> --- t/trash/a/l1 2007-09-17 23:10:03.000000000 +0200
> +++ t/trash/d/a/l1 2007-09-17 23:10:03.000000000 +0200
> @@ -1 +1 @@
> -simple textfile
> +a
> \ No newline at end of file
Ah! l1 is a symlink to a. The target of a symlink is stored as file
content in a ZIP archive and marked with a special flag. An unzipper
that doesn't understand this flag would create a file containing the
link target's name instead of a symlink pointing to the target.
The unzip on my system says:
$ unzip -v
UnZip 5.52 of 28 February 2005, by Ubuntu. Original by Info-ZIP.
Latest sources and executables are at ftp://ftp.info-zip.org/pub/infozip/ ;
see ftp://ftp.info-zip.org/pub/infozip/UnZip.html for other sites.
Compiled with gcc 4.1.2 (Ubuntu 4.1.2-0ubuntu4) for Unix (Linux ELF) on Mar 31 2007.
UnZip special compilation options:
ACORN_FTYPE_NFS
COPYRIGHT_CLEAN (PKZIP 0.9x unreducing method not supported)
SET_DIR_ATTRIB
TIMESTAMP
USE_EF_UT_TIME
USE_UNSHRINK (PKZIP/Zip 1.x unshrinking method supported)
USE_DEFLATE64 (PKZIP 4.x Deflate64(tm) supported)
VMS_TEXT_CONV
WILD_STOP_AT_DIR
[decryption, version 2.9 of 05 May 2000]
I suspect you need SET_DIR_ATTRIB in order to extract symlinks.
René
^ 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