* 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: 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: 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: [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] 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
* [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] 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] 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
* [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
* Re: [rfc] git submodules howto
From: Michael Smith @ 2007-09-18 12:10 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20070918105538.GL19019@genesis.frugalware.org>
On Tue, 18 Sep 2007, Miklos Vajna wrote:
> 1) is this correct? :) i use it and it seem to do what i except, but
> maybe it's not correct
Hi Miklos,
I had the same question, but you and I are both using it in a similar way
so that's encouraging.
I put something in the Wiki the other day.
http://git.or.cz/gitwiki/GitSubmoduleTutorial
Mike
^ permalink raw reply
* Re: [rfc] git submodules howto
From: Johannes Schindelin @ 2007-09-18 12:03 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20070918105538.GL19019@genesis.frugalware.org>
Hi,
On Tue, 18 Sep 2007, Miklos Vajna wrote:
> i saw several "is there any step by step howto on how to use git
> submodules?" question on irc, and as far as i think there is none
> available at the moment
AFAICT there is one, on the git Wiki, since yesterday.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-merge: add option --no-ff
From: Lars Hjemli @ 2007-09-18 12:03 UTC (permalink / raw)
To: Sam Vilain
Cc: Junio C Hamano, Eric Wong, Andreas Ericsson, Johannes Schindelin,
Chris Shoemaker, git
In-Reply-To: <46EFBB9A.5070404@vilain.net>
[...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.
Also, doing a --squash means that I loose the merge history in git
(and then I need to edit the grafts file again)
>
> > 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 ;-)
--
larsh
^ permalink raw reply
* Re: [PATCH] Mention that 'push .. master' is in explicit form master:refs/heads/master
From: Johannes Schindelin @ 2007-09-18 12:01 UTC (permalink / raw)
To: Jari Aalto; +Cc: git
In-Reply-To: <wsuomgyu.fsf@blue.sea.net>
Hi,
On Tue, 18 Sep 2007, Jari Aalto wrote:
> [no meaningful commit message]
Your patch is wrong. Try "git push origin <some-tag>". Works like a
charm, without starting a new branch.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] contrib/fast-import: add perl version of simple example
From: Sam Vilain @ 2007-09-18 11:57 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.0709181217200.28586@racer.site>
Johannes Schindelin wrote:
>> I think he means a dump that you can meaningfully edit with sed or a
>> text editor. And even nicer, one that could be fed back into
>> git-fast-import. So you could do something like:
>>
>> git-fast-export A..B >dump
>> vi dump
>> git-fast-import <dump
>>
>> to rewrite history in a very flexible way.
>>
>
> Exactly what I meant. Some people seem to have problems with
> filter-branch, but somehow no proper bug report, let alone fix, evolved
> from that.
>
> I guess these people are more comfortable with what you just described.
>
Guilty. my own filter-branch supports things like custom re-ordering of
commits prior to rewriting (eg, if you need to refer to one commit to
another in a commit message, you better make sure it happens in the
right order).
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. And probably using something akin to
Message-Id: headers for a "patch UUID" which is what you need when
you're working with piles of patches like that.
Sam.
^ permalink raw reply
* Re: [PATCH] git-send-email: Add a --cc-nobody option
From: Felipe Balbi @ 2007-09-18 11:51 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git, Felipe Balbi
In-Reply-To: <46EFBB5A.7090505@op5.se>
On 9/18/07, Andreas Ericsson <ae@op5.se> wrote:
> 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.
> >
>
> Sounds much better than --suppress-all. Thanks
Yeah, sure...
np :-)
>
> --
> Andreas Ericsson andreas.ericsson@op5.se
> OP5 AB www.op5.se
> Tel: +46 8-230225 Fax: +46 8-230231
>
--
Best Regards,
Felipe Balbi
felipebalbi@users.sourceforge.net
^ permalink raw reply
* Re: [PATCH] git-merge: add option --no-ff
From: Sam Vilain @ 2007-09-18 11:50 UTC (permalink / raw)
To: Lars Hjemli
Cc: Junio C Hamano, Eric Wong, Andreas Ericsson, Johannes Schindelin,
Chris Shoemaker, git
In-Reply-To: <8c5c35580709180419i4500a2d4s8a997d45dd31944e@mail.gmail.com>
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.
> 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.
Sam.
^ permalink raw reply
* Re: [PATCH] git-send-email: Add a --cc-nobody option
From: Andreas Ericsson @ 2007-09-18 11:49 UTC (permalink / raw)
To: felipebalbi; +Cc: git, Felipe Balbi
In-Reply-To: <11901157221792-git-send-email-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.
>
Sounds much better than --suppress-all. Thanks
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: commit summary, --pretty=short and other tools
From: Wincent Colaiuta @ 2007-09-18 11:43 UTC (permalink / raw)
To: Benoit SIGOURE; +Cc: Johannes Schindelin, Andreas Ericsson, Mike Hommey, git
In-Reply-To: <CEE6032F-39FB-42D8-A57A-671E4E0875C7@lrde.epita.fr>
El 18/9/2007, a las 12:27, Benoit SIGOURE escribió:
> OK, look, I think this is the typical case where there is no single
> solution to fit all use cases.
> To handle this specific case, you could say "OK let's stop at
> punctuation symbols then". But what if my commit message is "Add
> namespace::member whatever."
Uh, I don't think you'd stop a punctuation symbol unless it was the
last non-whitespace character before the newline.
Even then, as Johannes says, "oneline" is only meant as a hint
anyway, so it doesn't really matter that much.
Wincent
^ permalink raw reply
* Re: [PATCH] contrib/fast-import: add perl version of simple example
From: Andreas Ericsson @ 2007-09-18 11:28 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, Junio C Hamano, git, Shawn O. Pearce
In-Reply-To: <Pine.LNX.4.64.0709181217200.28586@racer.site>
Johannes Schindelin wrote:
> Hi,
>
> On Tue, 18 Sep 2007, Jeff King wrote:
>
>> I think he means a dump that you can meaningfully edit with sed or a
>> text editor. And even nicer, one that could be fed back into
>> git-fast-import. So you could do something like:
>>
>> git-fast-export A..B >dump
>> vi dump
>> git-fast-import <dump
>>
>> to rewrite history in a very flexible way.
>
> Exactly what I meant. Some people seem to have problems with
> filter-branch, but somehow no proper bug report, let alone fix, evolved
> from that.
>
The main problem is that it in my use-cases fixes a nuisance, but not a
real problem, while the man-page SYNOPSIS consists of a full 5 lines, most
of which are far from obvious at a first glance. The seeming effort involved
just doesn't seem worth bothering with.
> I guess these people are more comfortable with what you just described.
>
I know I would be, especially since all changes would show up in an entirely
different repo. I know filter-branch is probably completely safe, but even a
0.1% risk of losing *anything* isn't worth taking to fix a small nuisance.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: diffcore-rename performance mode
From: Johannes Schindelin @ 2007-09-18 11:20 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20070918085413.GA11751@coredump.intra.peff.net>
Hi,
On Tue, 18 Sep 2007, Jeff King wrote:
> On Tue, Sep 18, 2007 at 01:49:50AM -0700, Junio C Hamano wrote:
>
> > > However, keeping around _just_ the cnt_data caused only about 100M
> > > of extra memory consumption (and gave the same performance boost).
> >
> > That would be an interesting and relatively low-hanging optimization.
>
> OK, I will work up a patch. Is it worth making it configurable?
Yes, I think it would be worth making it configurable... For example, one
of the machines I work on has only 128M.
Thanks,
Dscho
^ permalink raw reply
* Re: [PATCH] contrib/fast-import: add perl version of simple example
From: Johannes Schindelin @ 2007-09-18 11:18 UTC (permalink / raw)
To: Jeff King; +Cc: Andreas Ericsson, Junio C Hamano, git, Shawn O. Pearce
In-Reply-To: <20070918103051.GA22239@coredump.intra.peff.net>
Hi,
On Tue, 18 Sep 2007, Jeff King wrote:
> I think he means a dump that you can meaningfully edit with sed or a
> text editor. And even nicer, one that could be fed back into
> git-fast-import. So you could do something like:
>
> git-fast-export A..B >dump
> vi dump
> git-fast-import <dump
>
> to rewrite history in a very flexible way.
Exactly what I meant. Some people seem to have problems with
filter-branch, but somehow no proper bug report, let alone fix, evolved
from that.
I guess these people are more comfortable with what you just described.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-merge: add option --no-ff
From: Lars Hjemli @ 2007-09-18 11:19 UTC (permalink / raw)
To: Sam Vilain
Cc: Junio C Hamano, Eric Wong, Andreas Ericsson, Johannes Schindelin,
Chris Shoemaker, git
In-Reply-To: <46EF9687.6070304@vilain.net>
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).
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.
--
larsh
^ permalink raw reply
* Re: [PATCH] contrib/fast-import: add perl version of simple example
From: Johannes Schindelin @ 2007-09-18 11:17 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Jeff King, Junio C Hamano, git, Shawn O. Pearce
In-Reply-To: <46EFA84C.3080906@op5.se>
Hi,
On Tue, 18 Sep 2007, Andreas Ericsson wrote:
> Johannes Schindelin wrote:
>
> > Maybe somebody will then grab the low-hanging fruit of writing a
> > "git-fast-export", which can be used to dump a complete repository in
> > text format?
>
> I thought that was already taken care of since format-patch handles
> --root flag properly?
Umm. Probably you forgot about merge commits, right? And about more than
one branch?
> Otherwise, "git repack -a --window=0 --depth=0" should provide an easily
> parseable dump of an entire repo.
This is not a dump. It is a log.
Ciao,
Dscho
^ permalink raw reply
* Re: git-fsck/lost-found's speed vs git-prune's
From: Johannes Schindelin @ 2007-09-18 11:13 UTC (permalink / raw)
To: Mike Hommey; +Cc: Junio C Hamano, git
In-Reply-To: <20070918095049.GA9388@glandium.org>
Hi,
On Tue, 18 Sep 2007, Mike Hommey wrote:
> On Tue, Sep 18, 2007 at 02:18:44AM -0700, Junio C Hamano <gitster@pobox.com> wrote:
> > Mike Hommey <mh@glandium.org> writes:
> >
> > > I was wondering if that was to be expected for git-fsck to be
> > > significantly slower than git-prune (by several orders of magnitude) ?
> >
> > fsck validates objects are correct and sane. prune only looks
> > at reachability.
>
> Now, the speed difference makes sense, but I wouldn't expect lost-found
> to actually bother validating objects...
That's why we should get rid of lost-found, and only keep the --lost-found
option to git-fsck, to make it clear.
And I think that it is too rare that you lost objects and want to find
them, to warrant a fast version of it.
Ciao,
Dscho
^ permalink raw reply
* [rfc] git submodules howto
From: Miklos Vajna @ 2007-09-18 10:55 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1794 bytes --]
hi,
i saw several "is there any step by step howto on how to use git
submodules?" question on irc, and as far as i think there is none
available at the moment
here is how i use it at the moment:
$ mkdir lib
$ cd lib
$ git init
Initialized empty Git repository in .git/
$ echo "libmakefile" > Makefile
$ dg add Makefile
$ git commit -m "libmakefile"
Created initial commit 57c1dce: libmakefile
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 Makefile
$ cd ..
$ mkdir main
$ cd main
$ git init
Initialized empty Git repository in .git/
$ echo "main makefile" > Makefile
$ git add Makefile
$ git commit -m "main makefile"
Created initial commit 8935291: main makefile
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 Makefile
$ git submodule add ../lib lib
Initialized empty Git repository in /home/vmiklos/scm/git/sub/main/lib/.git/
0 blocks
$ git commit -m "added lib submodule"
Created commit 9dbfedf: added lib submodule
2 files changed, 4 insertions(+), 0 deletions(-)
create mode 100644 .gitmodules
create mode 160000 lib
$ cd ..
$ git clone main cloned
Initialized empty Git repository in /home/vmiklos/scm/git/sub/cloned/.git/
0 blocks
$ cd cloned
$ git submodule init
Submodule 'lib' (/home/vmiklos/scm/git/sub/lib/.git) registered for path 'lib'
$ git submodule update
Initialized empty Git repository in /home/vmiklos/scm/git/sub/cloned/lib/.git/
0 blocks
Submodule path 'lib': checked out '57c1dce0e083e9ee50d06111d6aa1523116c2e15'
$ cat Makefile
main makefile
$ cat lib/Makefile
libmakefile
my questions:
1) is this correct? :) i use it and it seem to do what i except, but
maybe it's not correct
2) does this worth adding to the documentation? maybe to a .txt under
Documentation/howto? or to git-submodule.txt?
thanks,
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 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