* Re: [GUILT PATCH 2/5] guilt-guard: Assign guards to patches in series
From: Josef Sipek @ 2007-08-09 13:47 UTC (permalink / raw)
To: Eric Lesh; +Cc: git
In-Reply-To: <87bqdhnotj.fsf@hubert.paunchy.net>
On Thu, Aug 09, 2007 at 12:34:48AM -0700, Eric Lesh wrote:
> [ I'm finally back to this. Thanks for your comments. ]
Good. I was starting to get worried :)
> Josef Sipek <jsipek@fsl.cs.sunysb.edu> writes:
>
> [...]
>
> >> +}
> >> +
> >> +# usage: set_guards <patch> <guards...>
> >> +set_guards()
> >> +{
> >> + p="$1"
> >
> > Again, be careful about namespace polution.
> >
>
> Can I use "local", or is it a bashism? If not, use parentheses around
> the function body?
Right, "local" is a bashism therefore you must use a subshell (paretheses).
> >> + shift
> >> + for x in "$@"; do
> >> + if [ -z $(printf %s "$x" | grep -e "^[+-]") ]; then
> >
> > Out of curiosity, why printf and not echo?
> >
>
> For guards named '-e' or other funky things echo doesn't like and can't
> process with echo --.
Good enough reason :)
...
> I'm trying to clean the rest and get it ready again. This whole series
> will definitely need to incubate for a while once there's a
> reasonable-looking version, to make sure nothing goes crazy. Hopefully
> it ends up being useful somewhere!
I'd use it at times. For certain scenarios (2 series that are mostly
identical) using guards makes more sense than different branches.
Thanks,
Josef 'Jeff' Sipek.
--
Humans were created by water to transport it upward.
^ permalink raw reply
* [PATCH 2/2] send-email: get all the quoting of realnames right
From: Uwe Kleine-König @ 2007-08-09 13:27 UTC (permalink / raw)
To: Git Mailing List; +Cc: Uwe Kleine-König
In-Reply-To: <1186666080946-git-send-email-ukleinek@informatik.uni-freiburg.de>
- when sending several mails I got a slightly different behaviour for the first
mail compared to the second to last one. The reason is that $from was
assigned in line 608 and was not reset when beginning to handle the next
mail.
- Email::Valid can only handle properly quoted real names, so quote arguments
to extract_valid_address.
This patch cleans up variable naming to better differentiate between sender of
the mail and it's author.
Signed-off-by: Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
---
git-send-email.perl | 50 ++++++++++++++++++++++++--------------------------
1 files changed, 24 insertions(+), 26 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index a02ab96..69559b2 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -137,7 +137,7 @@ my $compose_filename = ".msg.$$";
# Variables we fill in automatically, or via prompting:
my (@to,@cc,@initial_cc,@bcclist,@xh,
- $initial_reply_to,$initial_subject,@files,$from,$compose,$time);
+ $initial_reply_to,$initial_subject,@files,$author,$sender,$compose,$time);
my $smtp_server;
my $envelope_sender;
@@ -179,7 +179,7 @@ if (!@bcclist or !$bcclist[0]) {
# Begin by accumulating all the variables (defined above), that we will end up
# needing, first, from the command line:
-my $rc = GetOptions("from=s" => \$from,
+my $rc = GetOptions("sender|from=s" => \$sender,
"in-reply-to=s" => \$initial_reply_to,
"subject=s" => \$initial_subject,
"to=s" => \@to,
@@ -216,8 +216,8 @@ foreach my $entry (@bcclist) {
# Now, let's fill any that aren't set in with defaults:
-my ($author) = $repo->ident_person('author');
-my ($committer) = $repo->ident_person('committer');
+my ($repoauthor) = $repo->ident_person('author');
+my ($repocommitter) = $repo->ident_person('committer');
my %aliases;
my @alias_files = $repo->config('sendemail.aliasesfile');
@@ -254,17 +254,17 @@ if (@alias_files and $aliasfiletype and defined $parse_alias{$aliasfiletype}) {
}
}
-($from) = expand_aliases($from) if defined $from;
+($sender) = expand_aliases($sender) if defined $sender;
my $prompting = 0;
-if (!defined $from) {
- $from = $author || $committer;
+if (!defined $sender) {
+ $sender = $repoauthor || $repocommitter;
do {
- $_ = $term->readline("Who should the emails appear to be from? [$from] ");
+ $_ = $term->readline("Who should the emails appear to be from? [$sender] ");
} while (!defined $_);
- $from = $_ if ($_);
- print "Emails will be sent from: ", $from, "\n";
+ $sender = $_ if ($_);
+ print "Emails will be sent from: ", $sender, "\n";
$prompting++;
}
@@ -330,7 +330,7 @@ if ($compose) {
# effort to have it be unique
open(C,">",$compose_filename)
or die "Failed to open for writing $compose_filename: $!";
- print C "From $from # This line is ignored.\n";
+ print C "From $sender # This line is ignored.\n";
printf C "Subject: %s\n\n", $initial_subject;
printf C <<EOT;
GIT: Please enter your email below.
@@ -433,11 +433,11 @@ sub make_message_id
my $date = time;
my $pseudo_rand = int (rand(4200));
my $du_part;
- for ($from, $committer, $author) {
- $du_part = extract_valid_address($_);
- last if ($du_part ne '');
+ for ($sender, $repocommitter, $repoauthor) {
+ $du_part = extract_valid_address(sanitize_address($_));
+ last if (defined $du_part and $du_part ne '');
}
- if ($du_part eq '') {
+ if (not defined $du_part or $du_part eq '') {
use Sys::Hostname qw();
$du_part = 'user@' . Sys::Hostname::hostname();
}
@@ -508,10 +508,10 @@ sub send_message
if ($cc ne '') {
$ccline = "\nCc: $cc";
}
- $from = sanitize_address($from);
+ my $sanitized_sender = sanitize_address($sender);
make_message_id();
- my $header = "From: $from
+ my $header = "From: $sanitized_sender
To: $to${ccline}
Subject: $subject
Date: $date
@@ -528,7 +528,7 @@ X-Mailer: git-send-email $gitversion
}
my @sendmail_parameters = ('-i', @recipients);
- my $raw_from = $from;
+ my $raw_from = $sanitized_sender;
$raw_from = $envelope_sender if (defined $envelope_sender);
$raw_from = extract_valid_address($raw_from);
unshift (@sendmail_parameters,
@@ -565,7 +565,7 @@ X-Mailer: git-send-email $gitversion
} else {
print "Sendmail: $smtp_server ".join(' ',@sendmail_parameters)."\n";
}
- print "From: $from\nSubject: $subject\nCc: $cc\nTo: $to\n\n";
+ print "From: $sanitized_sender\nSubject: $subject\nCc: $cc\nTo: $to\n\n";
if ($smtp) {
print "Result: ", $smtp->code, ' ',
($smtp->message =~ /\n([^\n]+\n)$/s), "\n";
@@ -582,7 +582,7 @@ $subject = $initial_subject;
foreach my $t (@files) {
open(F,"<",$t) or die "can't open file $t";
- my $author_not_sender = undef;
+ my $author = undef;
@cc = @initial_cc;
@xh = ();
my $input_format = undef;
@@ -604,12 +604,11 @@ foreach my $t (@files) {
$subject = $1;
} elsif (/^(Cc|From):\s+(.*)$/) {
- if (unquote_rfc2047($2) eq $from) {
- $from = $2;
+ if (unquote_rfc2047($2) eq $sender) {
next if ($suppress_from);
}
elsif ($1 eq 'From') {
- $author_not_sender = $2;
+ $author = unquote_rfc2047($2);
}
printf("(mbox) Adding cc: %s from line '%s'\n",
$2, $_) unless $quiet;
@@ -653,9 +652,8 @@ foreach my $t (@files) {
}
}
close F;
- if (defined $author_not_sender) {
- $author_not_sender = unquote_rfc2047($author_not_sender);
- $message = "From: $author_not_sender\n\n$message";
+ if (defined $author) {
+ $message = "From: $author\n\n$message";
}
--
1.5.3.rc3.943.g14c81
^ permalink raw reply related
* [PATCH 1/2] send-email: rfc822 forbids using <address@domain> without a non-empty "phrase"
From: Uwe Kleine-König @ 2007-08-09 13:27 UTC (permalink / raw)
To: Git Mailing List; +Cc: Uwe Kleine-König
In-Reply-To: <11866660781833-git-send-email-ukleinek@informatik.uni-freiburg.de>
Email::Valid does respect this considering such a mailbox specification
invalid. b06c6bc831cbb9e9eb82fd3ffd5a2b674cd940d0 addressed the issue, but
only if Email::Valid is available.
Signed-off-by: Uwe Kleine-König <ukleinek@informatik.uni-freiburg.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 39e433b..a02ab96 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -408,8 +408,8 @@ sub extract_valid_address {
# check for a local address:
return $address if ($address =~ /^($local_part_regexp)$/);
+ $address =~ s/^\s*<(.*)>\s*$/$1/;
if ($have_email_valid) {
- $address =~ s/^\s*<(.*)>\s*$/$1/;
return scalar Email::Valid->address($address);
} else {
# less robust/correct than the monster regexp in Email::Valid,
--
1.5.3.rc3.943.g14c81
^ permalink raw reply related
* [PATCH 0/2] patches for send-email
From: Uwe Kleine-König @ 2007-08-09 13:27 UTC (permalink / raw)
To: Git Mailing List
Hello,
this series is mainly a last test for the second patch.
The first patch is just a resend for a mail I sent a earlier today.
You can fetch these on top of Junio's current next from
git://www.modarm9.com/gitsrc/pub/people/ukleinek/git.git
(in case you fear not to be able to extract my name properly out of the mails
(or I didn't manage to get them right) :-))
Best regards,
Uwe
^ permalink raw reply
* Re: 'pu' branch for StGIT
From: Pavel Roskin @ 2007-08-09 13:24 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git, Catalin Marinas, Yann Dirson
In-Reply-To: <20070809073801.GA31482@diana.vm.bytemark.co.uk>
On Thu, 2007-08-09 at 09:38 +0200, Karl Hasselström wrote:
> I take it this all means you're actually using my branch? What's your
> opinion on its usefulness?
Well, I tried it, and then ran a script to update all local
repositories. It converted everything to "version 3", so I'm sort of
stuck with it. If the "version 3" code is not committed to the mainline
StGIT, I'll have to convert my repositories back or even re-fetch them.
I have noticed two problems so far, but I cannot tell is they are
specific to the "pu" branch.
1) Undead patches.
StGIT finds a patch I deleted long ago and shows it as unapplied. It
cannot be deleted by "stg delete" because some files are missing.
$ stg delete at76_usb
Traceback (most recent call last):
File "/home/proski/bin/stg", line 43, in <module>
main()
File "home/proski/lib/python2.5/site-packages/stgit/main.py", line 284, in main
File "home/proski/lib/python2.5/site-packages/stgit/commands/delete.py", line 76, in func
File "home/proski/lib/python2.5/site-packages/stgit/stack.py", line 1227, in delete_patch
File "home/proski/lib/python2.5/site-packages/stgit/stack.py", line 1209, in delete_patch_data
File "home/proski/lib/python2.5/site-packages/stgit/stack.py", line 160, in delete
OSError: [Errno 2] No such file or directory: '.git/patches/wireless-dev/patches/at76_usb'
That's Linux repository, and I'm on wireless-dev branch. There is a
file .git/patches/wireless-dev/trash/at76_usb containing "None". There
are two other files in that directory, but they have some SHA1 hashes.
There is also a file .git/patches/wireless-dev/patchorder, which
contains "at76_usb".
I was updating the repository by "stg pull", there were two patches,
"at76_usb" being first. It couldn't be merged, so I deleted it. I
deleted the other patch as well, since I new it was applied upstream.
After another "stg pull" at76_usb became "undead".
I cannot reproduce it on another repository.
2) Invisible branches.
StGIT stopped showing other branches. It's always showing the same
branch, although it can switch to other branches:
[proski@dv linux-2.6]$ stg branch --list
Available branches:
> s wireless-dev |
[proski@dv linux-2.6]$ stg branch wireless-2.6
Checking for changes in the working directory ... done
Switching to branch "wireless-2.6" ... done
[proski@dv linux-2.6]$ stg branch --list
Available branches:
s wireless-dev |
[proski@dv linux-2.6]$ stg branch linus
Checking for changes in the working directory ... done
Switching to branch "linus" ... done
[proski@dv linux-2.6]$ stg branch --list
Available branches:
s wireless-dev |
[proski@dv linux-2.6]$ stg init
stg init: linus already initialized
[proski@dv linux-2.6]$
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH] allow git-bundle to create bottomless bundle
From: Mark Levedahl @ 2007-08-09 12:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Git Mailing List, Mark Levedahl
In-Reply-To: <7v643pz4c9.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 1651 bytes --]
On 8/9/07, Junio C Hamano <gitster@pobox.com> wrote:
> Mark Levedahl <mlevedahl@gmail.com> writes:
>
> > Junio C Hamano wrote:
>
> Actually, there is another bug nearby.
>
Curious... I did a long time ago get git-bundle.sh to write out the
format Dscho finally implemented working in Linux and Cygwin. With
your latest patch, both produce identical bundles for a number of
cases, but the timing is very curious:
*builtin*
git>time git-bundle create foo refs/tags/v1.0.3
Generating pack...
Done counting 12288 objects.
Deltifying 12288 objects...
100% (12288/12288) done
Writing 12288 objects...
100% (12288/12288) done
Total 12288 (delta 8435), reused 11542 (delta 7961)
real 0m41.953s
user 0m5.060s
sys 0m39.685s
*shell script*
git>time git-bundle2 create foo2 refs/tags/v1.0.3
Generating pack...
Done counting 12288 objects.
Deltifying 12288 objects...
100% (12288/12288) done
Total 12288 (delta 8435), reused 11542 (delta 7961)
Created foo2
real 0m2.453s
user 0m1.842s
sys 0m1.190s
git>diff foo foo2
git>
Since when is shell 20 times faster than a builtin? Ok, those results
are on Cygwin. On Linux, I get 1.21 sec for the builtin vs 0.933 for
the shell script. Not as dramatic, but the script is still faster. So,
I think this qualifies as a bug. I'm attaching the script (for info
only, I'm not suggesting to replace the builtin), as I can't usefully
put it inline from gmail.
The timing difference seem to be in the rev walking (by eyeball,
packfile generation time is the same), so something the shell script
is doing to get the rev list is obviously more efficient than how the
builtin works for this case.
Mark
[-- Attachment #2: git-bundle2 --]
[-- Type: application/octet-stream, Size: 4705 bytes --]
#!/bin/sh
# Basic handler for bundle files to connect repositories via sneakernet.
# Invocation must include action.
# This function can create a bundle or provide information on an existing bundle
# supporting git-fetch, git-pull, and git-ls-remote
# bundle format is:
# line1 - version
# -sha1 commit msg : prerequisites
# sha1 name ; refs
# <blank line>
# pack file
USAGE='git-bundle ( create <bundle> [<rev-list-args>...] |
verify | list-heads | unbundle <bundle> )'
SUBDIRECTORY_OK=1
. git-sh-setup
LF='
'
verify() {
# Check bundle version
test "$version" = "# v2 git bundle" ||
die "$bfile is not a v2 git bundle"
# do fast check, then if any prereqs are missing then go line by line
# to be verbose about the errors
test -z "$prereqs" && return 0
if bad=$(echo "$prereqs" | cut -b-40 | git-rev-list --stdin --not --all 2>&1) &&
test -z "$bad" ; then
return 0
else
echo >/dev/stderr "error: $bfile requires the following missing commits:"
echo "$prereqs" |
while read sha1 comment ; do
if ! missing=$(git-rev-list $sha1 --not --all 2>&1) || test -n "$missing" ; then
echo >/dev/stderr "$sha1 $comment"
fi
done
return 1
fi
}
# list all refs or just a subset
list_heads() {
if test -z "$*" ; then
echo "$refs"
else
echo "$refs" |
while read sha1 ref ; do
for arg in $* ; do
if test "${ref%$arg}" != "$ref" ; then
echo "$sha1 $ref"
break
fi
done
done
fi
}
# create a bundle
create() {
unknown=$(git-rev-parse --no-revs $args)
test -z "$unknown" || die "unknown option: $unknown"
gitrevargs=$(git-rev-parse --symbolic --revs-only $args) || exit 1
# find the refs to carry along and get sha1s for each.
refs=
boundaryargs=
basis=
for arg in $gitrevargs ; do
#ignore options and basis refs, get full ref name for things
# we will transport rejecting anything ambiguous (e.g., user
# gives master, have heads/master and remotes/origin/master, we
# keep the former).
case "$arg" in
^*)
boundaryargs="$boundaryargs $arg"
basis="$basis ${arg/^/}";;
-*)
boundaryargs="$boundaryargs $arg";;
*)
refs="$refs$LF$(git show-ref $arg | head -n1)";;
esac
done
test -z "$refs" && die "No references specified, I don't know what to bundle."
sha1refs=$(echo "$refs" | cut -b-40)
# get prerequisite commits this bundle depends upon
prereqs=$(git-rev-list --boundary $boundaryargs $sha1refs | sed -ne 's/^-//p')
if test -n "$basis" ; then
prereqs=$(printf "%s\n" $prereqs $(git-rev-parse $basis) | sort | uniq)
fi
# create refs and pack. We do this in a subshell to avoid using >> to append,
# as that induces crlf breakage under Cygwin.
(
echo "# v2 git bundle" &&
(for p in $prereqs ; do
printf "%s\n" "-$(git-rev-list --pretty=one --max-count=1 $p)"
done) &&
git-show-ref $refs &&
echo "" &&
(printf "%s\n" $sha1refs &&
test -n "$prereqs" && printf "^%s\n" $prereqs ) |
git pack-objects --thin --stdout --progress
) > "$bfile"
if test $? -gt 0; then
rm -fv "$bfile"
else
echo "Created $bfile"
fi
}
# parse inputs, decide what to do
args=
action=
while test -n "$1" ; do
case $1 in
create|list-heads|unbundle|verify|show)
action=$1
shift
bfile=$1
test -z "$bfile" && die "$action requires filename";;
*)
args="$args $1";;
esac
shift
done
test -z "$action" && die "No action given, what should I do?"
if test "$action" = "create" ; then
create
else
test -f "$bfile" || die "Could not find $bfile"
# get the header once, verify all is ok
header=$(sed -e '/^$/,$d' "$bfile")
refs=$(echo "$header" | sed -e '1d;/^-/d')
prereqs=$(echo "$header" | sed -ne 's/^-//p')
version=$(echo "$header" | head -n1)
echo $version
case $action in
verify)
verify && echo "$bfile is ok";;
list-heads)
list_heads $args;;
show)
echo "$header" | sed -ne "/^-/p"
echo "$refs";;
unbundle)
verify || exit 1
sed -be '1,/^$/d' "$bfile" | git-index-pack --stdin --fix-thin ||
die "error: $bfile has a corrupted pack file"
list_heads $args;;
esac
fi
^ permalink raw reply
* Re: [PATCH] make git-send-email.perl handle email addresses with no names when Email::Valid is present
From: Uwe Kleine-König @ 2007-08-09 12:28 UTC (permalink / raw)
To: Greg KH; +Cc: Junio C Hamano, git
In-Reply-To: <20070713041749.GA28824@kroah.com>
Hello,
Greg KH wrote:
> When using git-send-email.perl on a changeset that has:
> Cc: <stable@kernel.org>
> in the body of the description, and the Email::Valid perl module is
> installed on the system, the email address will be deemed "invalid" for
> some reason (Email::Valid isn't smart enough to handle this?) and
> complain and not send the address the email.
The reason is probably that it is indeed invalid. From rfc822:
mailbox = addr-spec / phrase route-addr
addr-spec = local-part "@" domain
phrase = 1*word
word = atom / quoted-string
atom = 1*<any CHAR except specials, SPACE and CTLs>
quoted-string = <"> *(qtext/quoted-pair) <">
route-addr = "<" [route] addr-spec ">"
...
where 1* means "at least one of".
That is, either you must not use <...> or you need a non-empty phrase.
Actually this grammar looks wrong, because as I read it it would not
allow spaces between words in phrase. But that's another issue.
BTW: Outlook depends on this, because if you use Cc:
<stable@kernel.org>, it doesn't show anything in the Cc: line---at least
in the default configuration.
So I suggest the following:
---- >8 ----
send-email: rfc822 forbids using <address@domain> without a non-empty "phrase"
Email::Valid does respect this considering such a mailbox specification
invalid. b06c6bc831cbb9e9eb82fd3ffd5a2b674cd940d0 addressed the issue, but
only if Email::Valid is available.
Signed-off-by: Uwe Kleine-König <ukleinek@informatik.uni-freiburg.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 39e433b..a02ab96 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -408,8 +408,8 @@ sub extract_valid_address {
# check for a local address:
return $address if ($address =~ /^($local_part_regexp)$/);
+ $address =~ s/^\s*<(.*)>\s*$/$1/;
if ($have_email_valid) {
- $address =~ s/^\s*<(.*)>\s*$/$1/;
return scalar Email::Valid->address($address);
} else {
# less robust/correct than the monster regexp in Email::Valid,
--
1.5.3.rc3.943.g14c81
--
Uwe Kleine-König
If a lawyer and an IRS agent were both drowning, and you could only save
one of them, would you go to lunch or read the paper?
^ permalink raw reply related
* Re: [PATCH] send-email: teach sanitize_address to do rfc2047 quoting
From: Uwe Kleine-König @ 2007-08-09 12:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <11864324902764-git-send-email-ukleinek@informatik.uni-freiburg.de>
Hello Junio,
thanks for taking that patch in next (as 5b56aaa29e), but my name got
scrambled once again in a strange way.
Please correct me if I'm wrong, but I think this time it happened
completely on your side.
The mail I got returned from the list looks good and
http://article.gmane.org/gmane.comp.version-control.git/55172 looks
right, too.
Strange enough my name is right in your What's in git.git (stable) mail.
(http://article.gmane.org/gmane.comp.version-control.git/55221)
I have still another problem with send-email. I will try to come up
with a fix before 1.5.3.
Best regards
Uwe
--
Uwe Kleine-König
exit vi, lesson II:
: w q ! <CR>
NB: write the current file
^ permalink raw reply
* [PATCH] git-merge: do up-to-date check also for strategies ours, subtree.
From: Gerrit Pape @ 2007-08-09 12:08 UTC (permalink / raw)
To: git, Junio C Hamano
If called with one argument, check also for no_trivial_merge_strategies
whether all the merge can already be reached by HEAD. Otherwise git-merge
creates an unnecessary commit, e.g.:
$ (git init && touch foo && git add foo && git commit -m foo) >/dev/null
$ git merge -s ours master
Merge made by ours.
$ git log --pretty=oneline
d941346f022b7cb70c51d8122de4ae82657ae943 Merge branch 'master'
68a1d32229917d5d1f4c8f64096d1abde84e9f6b foo
$
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
git-merge.sh | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/git-merge.sh b/git-merge.sh
index 5ccf282..e90f62a 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -287,9 +287,6 @@ esac
echo "$head" >"$GIT_DIR/ORIG_HEAD"
case "$index_merge,$#,$common,$no_commit" in
-f,*)
- # We've been told not to try anything clever. Skip to real merge.
- ;;
?,*,'',*)
# No common ancestors found. We need a real merge.
;;
@@ -299,6 +296,9 @@ f,*)
finish_up_to_date "Already up-to-date."
exit 0
;;
+f,*)
+ # We've been told not to try anything clever. Skip to real merge.
+ ;;
?,1,"$head",*)
# Again the most common case of merging one remote.
echo "Updating $(git rev-parse --short $head)..$(git rev-parse --short $1)"
--
debian.1.5.3_rc4.1-dirty
^ permalink raw reply related
* git-rewrite-history behaves quite contrary to documentation
From: David Kastrup @ 2007-08-09 11:30 UTC (permalink / raw)
To: git
git-filter-branch --index-filter 'git-update-index --force-remove --remove -g bilder bilder3' master trunk
Rewrite a7a8f2fc263256c98ed5220e7467d34584c8c6ac (58/58)
Ref 'refs/heads/master' was rewritten
Ref 'refs/remotes/trunk' was rewritten
These refs were rewritten:
fatal: Not a git repository: '/rep/akspiele/.git-rewrite/t/../../.git'
The manual page, however, claims:
git-filter-branch [--env-filter <command>] [--tree-filter <command>]
[--index-filter <command>] [--parent-filter <command>]
[--msg-filter <command>] [--commit-filter <command>]
[--tag-name-filter <command>] [--subdirectory-filter <directory>]
[-d <directory>] <new-branch-name> [<rev-list options>...]
<new-branch-name> apparently is completely ignored: specifying a
non-existing branch will not work.
In the examples, it claims:
git filter-branch --index-filter 'git update-index --remove filename' newbranch
Now, you will get the rewritten history saved in the branch
newbranch (your current branch is left untouched).
This is again wrong: one needs to write "-g" at very least, or it will
not bother removing a file that is not present in the working dir.
Could someone please pass this on to Dscho? He has me in his killfile.
--
David Kastrup
^ permalink raw reply
* Re: git on Cygwin: Not a valid object name HEAD
From: Steffen Prohaska @ 2007-08-09 10:33 UTC (permalink / raw)
To: Marius Storm-Olsen, Johannes Schindelin
Cc: Mark Levedahl, Junio C Hamano, Linus Torvalds, Git Mailing List,
Shawn O. Pearce, Sebastian Schuberth
In-Reply-To: <46BAD793.9040906@trolltech.com>
On Aug 9, 2007, at 11:00 AM, Marius Storm-Olsen wrote:
> Johannes Schindelin said the following on 09.08.2007 10:50:
>> On Thu, 9 Aug 2007, Marius Storm-Olsen wrote:
>>> Try running gitme from a terminal.
>> And there I thought that you download GitMe-3.exe, and then double
>> click on it...
>
> Heh, yeah, normally that's indeed what you do. However, in this
> case I asked him to start it from the terminal to make sure that it
> wasn't affected by anything suspicious in his system PATH.
>
> Clearly having Cygwin in his path messed things up.
I think checking for a proper setup in the installer would
be a good idea, like checking if 'cygpath' runs and if so,
die with the request to cleanup the system PATH first.
The problem was not too hard to solve, but the first
impression was not optimal.
Where would I have to look to add something like this?
Steffen
^ permalink raw reply
* Re: git-svn: commit author x commit committer issue
From: Richard MUSIL @ 2007-08-09 9:45 UTC (permalink / raw)
To: Peter Baumann; +Cc: git
In-Reply-To: <20070808171323.GD27703@xp.machine.xx>
Peter Baumann wrote:
> On Wed, Aug 08, 2007 at 03:46:19PM +0200, Richard MUSIL wrote:
>> Normally, when patch is applied, git distinguishes commit author and
>> commit committer (relying on info from patch).
>> However, after the patches are committed to svn repository using:
>> git-svn dcommit
>> author and committer data are set to same values (or at least time and
>> date, I cannot verify it for names).
>> I wonder if there is any reason for this behavior, because I would
>> definitely like to keep original commit info (which came from patch) in
>> my git repository.
>
> I think it is because in SVN, you can't differentiate between author and
> committer. And git-svn just commits every local commit to svn, and after
> that, it throws away your local commits and uses the info from the
> reimported svn commits to recreate those thrown away commits. Thats why
> you loose your author name and also your commit date.
I guess you are right. I have been thinking about the possibility to
store the original author and patch date into svn unversioned property.
Something like git:author and git:date. There is however one catch.
Modifying unversioned properties must be explicitly allowed on svn
repository, so this will have to be optional in git (svn.userevprops ?).
I do not know what others think about this. For me it seems quite
attractive, to be able to store development history of original actions
inside svn, especially when the case might be that commits into git
happen at different time on different machines and by different people
than the final commit to svn.
I have been trying to find out how this works in git-svn, but since Perl
is worse than Greek to me, I found out only that I am not able to do
anything here. Would anyone be interested to work on it?
Richard
^ permalink raw reply
* Re: git-filter-branch
From: Johannes Schindelin @ 2007-08-09 9:38 UTC (permalink / raw)
To: Mike Hommey; +Cc: Git Mailing List
In-Reply-To: <20070809093051.GA21458@glandium.org>
Hi,
On Thu, 9 Aug 2007, Mike Hommey wrote:
> On Thu, Aug 09, 2007 at 10:19:20AM +0100, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > In the description in the manpage:
> > > Lets you rewrite git revision history by creating a new branch from
> > > your current branch, applying custom filters on each revision.
> > > (...)
> > > The command takes the new branch name as a mandatory argument and the
> > > filters as optional arguments
> > >
> > > And in example:
> > > Now, you will get the rewritten history saved in the branch newbranch
> > > (your current branch is left untouched).
> > >
> > > I must say this is a feature that would actually be nice to have...
> >
> > To compare with the old one? Use reflogs:
> >
> > git filter-branch --some-option master
> > git diff master@{1}..master
>
> To have, for example, a branch tracking an upstream (svn or whatever)
> repository and have a branch based on it, only differing in the fact that
> some directories get removed.
You can always achieve the same effect by
$ git branch new-branch master
$ git filter-branch <options> master
Anyway, I'm off for a few days.
Ciao,
Dscho
^ permalink raw reply
* Re: git-filter-branch
From: Mike Hommey @ 2007-08-09 9:30 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0708091018340.21857@racer.site>
On Thu, Aug 09, 2007 at 10:19:20AM +0100, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > In the description in the manpage:
> > Lets you rewrite git revision history by creating a new branch from
> > your current branch, applying custom filters on each revision.
> > (...)
> > The command takes the new branch name as a mandatory argument and the
> > filters as optional arguments
> >
> > And in example:
> > Now, you will get the rewritten history saved in the branch newbranch
> > (your current branch is left untouched).
> >
> > I must say this is a feature that would actually be nice to have...
>
> To compare with the old one? Use reflogs:
>
> git filter-branch --some-option master
> git diff master@{1}..master
To have, for example, a branch tracking an upstream (svn or whatever)
repository and have a branch based on it, only differing in the fact that
some directories get removed.
To be more specific, I'm tracking webkit's svn repository, and want to
have a branch which would be a base for making source tarballs for
debian, excluding a lot of cruft (such as LayoutTests which are *huge*,
or the website that also lives in the same svn trunk).
As files are added frequently in these directories, rebase or merge would
not be enough, and I'd like to be able to do this with a bare repository,
which rebase and merge don't allow me to...
So if you have a better idea than git-filter-branch for that, I'm open to
suggestions ;)
Cheers,
Mike
^ permalink raw reply
* Re: git-filter-branch
From: Johannes Schindelin @ 2007-08-09 9:19 UTC (permalink / raw)
To: Mike Hommey; +Cc: Git Mailing List
In-Reply-To: <20070809091550.GB20321@glandium.org>
Hi,
On Thu, 9 Aug 2007, Mike Hommey wrote:
> On Thu, Aug 09, 2007 at 09:58:27AM +0100, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > Hi,
> >
> > On Thu, 9 Aug 2007, Mike Hommey wrote:
> >
> > > What is supposed to be the usage() of git-fetch-branch ?
> > >
> > > git-filter-branch itself says:
> > > git-filter-branch [-d TEMPDIR] [FILTERS] DESTBRANCH [REV-RANGE]
> >
> > This is an unfortunate left-over. The syntax described in the
> > documentation should be right.
> >
> > > while the documentation doesn't explicitely talk about DESTBRANCH,
> > > expect in the form of an hypothetical /newbranch/, that you obviously
> > > don't give to the command line.
> >
> > Hmm. I don't have time to look into this now, but the syntax is this:
> >
> > git filter-branch [<options>] [--] [<rev-options>]
> >
> > Those refs that you give in the <rev-options> are rewritten. AFAIR the
> > old values of the refs (if different) are written to refs/original/*.
>
> In the description in the manpage:
> Lets you rewrite git revision history by creating a new branch from
> your current branch, applying custom filters on each revision.
> (...)
> The command takes the new branch name as a mandatory argument and the
> filters as optional arguments
>
> And in example:
> Now, you will get the rewritten history saved in the branch newbranch
> (your current branch is left untouched).
>
> I must say this is a feature that would actually be nice to have...
To compare with the old one? Use reflogs:
git filter-branch --some-option master
git diff master@{1}..master
> > > And whereas git-filter-branch itself says there is such an argument,
> > > it actually doesn't take it, and doesn't seem to be hardwired to create
> > > a new branch instead of overwriting the current one.
> > >
> > > So what is git-filter-branch supposed to be doing ?
> >
> > To rewrite refs.
> >
> > > As a side note, if it ever happens that git-filter-branch can create a
> > > new branch, it might be nice to have each commit on the branch to have
> > > the original commit as parent, as well as its branch parent, so that
> > > they are seen as merges.
> >
> > No, this will not happen. Filter-branch is meant to clean up branches, so
> > it will rewrite the commits. However, you might be able to hack something
> > in a parent filter.
>
> That would need the commit id for the original commit being treated at the
> time, which I don't think is available in parent filters...
IIRC the "map" function will handle that.
Ciao,
Dscho
^ permalink raw reply
* Re: git-filter-branch
From: Mike Hommey @ 2007-08-09 9:15 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0708090954550.21857@racer.site>
On Thu, Aug 09, 2007 at 09:58:27AM +0100, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Thu, 9 Aug 2007, Mike Hommey wrote:
>
> > What is supposed to be the usage() of git-fetch-branch ?
> >
> > git-filter-branch itself says:
> > git-filter-branch [-d TEMPDIR] [FILTERS] DESTBRANCH [REV-RANGE]
>
> This is an unfortunate left-over. The syntax described in the
> documentation should be right.
>
> > while the documentation doesn't explicitely talk about DESTBRANCH,
> > expect in the form of an hypothetical /newbranch/, that you obviously
> > don't give to the command line.
>
> Hmm. I don't have time to look into this now, but the syntax is this:
>
> git filter-branch [<options>] [--] [<rev-options>]
>
> Those refs that you give in the <rev-options> are rewritten. AFAIR the
> old values of the refs (if different) are written to refs/original/*.
In the description in the manpage:
Lets you rewrite git revision history by creating a new branch from
your current branch, applying custom filters on each revision.
(...)
The command takes the new branch name as a mandatory argument and the
filters as optional arguments
And in example:
Now, you will get the rewritten history saved in the branch newbranch
(your current branch is left untouched).
I must say this is a feature that would actually be nice to have...
> > And whereas git-filter-branch itself says there is such an argument,
> > it actually doesn't take it, and doesn't seem to be hardwired to create
> > a new branch instead of overwriting the current one.
> >
> > So what is git-filter-branch supposed to be doing ?
>
> To rewrite refs.
>
> > As a side note, if it ever happens that git-filter-branch can create a
> > new branch, it might be nice to have each commit on the branch to have
> > the original commit as parent, as well as its branch parent, so that
> > they are seen as merges.
>
> No, this will not happen. Filter-branch is meant to clean up branches, so
> it will rewrite the commits. However, you might be able to hack something
> in a parent filter.
That would need the commit id for the original commit being treated at the
time, which I don't think is available in parent filters...
Mike
^ permalink raw reply
* Re: Git on MSys (or how to make it easy for Windows users to compile git)
From: Johannes Schindelin @ 2007-08-09 9:14 UTC (permalink / raw)
To: Alex Riesen; +Cc: Marius Storm-Olsen, Torgil Svensson, Dmitry Kakurin, git
In-Reply-To: <81b0412b0708090147y11783e3i4f0a6251dbe2c736@mail.gmail.com>
Hi,
On Thu, 9 Aug 2007, Alex Riesen wrote:
> On 8/6/07, Marius Storm-Olsen <marius@trolltech.com> wrote:
> > Johannes Schindelin said the following on 06.08.2007 02:11:
> > On Windows we have a replacement terminal, which has all the features
> > you want, and also supports tabs like Konsole. I've used it for
> > several years, and it works great. Have a look and see if you like it,
> > then we can add it to the repo:
> > http://sourceforge.net/projects/console/
> >
> > Original name, ey? :-)
>
> A fine example of windows hackery (they had to inject some code into
> the process running a standard windows console to redirect the IO,
> because windows has no tty of any form).
> It is wonder it works, but it really does (surprisingly often).
> Very impressive.
I have some issues with it, though.
- I really hate to leave anything older than W2K behind. You might not
care, but I do.
- I tested it, and it gave a constant flicker, at least in the status bar.
Does not seem to be that fleshed out.
So I'd really like to see rxvt.exe fixed.
Ciao,
Dscho
^ permalink raw reply
* Re: [GUILT PATCH 2/5] guilt-guard: Assign guards to patches in series
From: Eric Lesh @ 2007-08-09 9:01 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86r6mdp1e1.fsf@lola.quinscape.zz>
David Kastrup <dak@gnu.org> writes:
>>>> + shift
>>>> + for x in "$@"; do
>>>> + if [ -z $(printf %s "$x" | grep -e "^[+-]") ]; then
>>>> + echo "'$x' is not a valid guard name"
>>>> + else
>>>> + sed -i -e "s,^\($p[[:space:]]*.*\)$,\1 #$x," "$series"
>>>
>>> Out of curiosity, why printf and not echo?
>>>
>>
>> For guards named '-e' or other funky things echo doesn't like and
>> can't process with echo --.
>
> The problem with the above is that it reacts strangely to multiline
> options.
>
There shouldn't be multiline options passed to this function, so it
might not be a problem.
> Should be much better (and faster on shells without builtin printf) to
> use
>
> case "$x" in
> [+-]*)
> sed -i -e ... ;;
> *)
> echo "'$x' is not ...
> esac
>
> and this runs portably without forking on shells that are 30 years
> old. Shell script programmers _really_ should know "case" inside out.
>
Heh, as you may have noticed, I'm no shell programmer :-) Thanks for
the advice though.
> Also, instead of 'for x in "$@"' one can just write "for x'
>
Nice.
>>> The regexp is in double quotes, so you should escape the $ (EOL),
>>> as well as all the \. Yep, this is shell scripting at its worst.
>
> \ does not need to be escaped in double quotes except before \, $ and `.
> You can write
>
> sed -i -e "s,^\($p[[:space:]]*.*\)\$,\1 #$x," "$series"
>
> and that's fine.
Yeah. That one made itself clear. The sed -i needs to go too, as
Thomas observed. The regexp itself also needs cleansing.
Lots of work to do...
Eric
^ permalink raw reply
* Re: git-filter-branch
From: Johannes Schindelin @ 2007-08-09 8:58 UTC (permalink / raw)
To: Mike Hommey; +Cc: Git Mailing List
In-Reply-To: <20070809063453.GA12602@glandium.org>
Hi,
On Thu, 9 Aug 2007, Mike Hommey wrote:
> What is supposed to be the usage() of git-fetch-branch ?
>
> git-filter-branch itself says:
> git-filter-branch [-d TEMPDIR] [FILTERS] DESTBRANCH [REV-RANGE]
This is an unfortunate left-over. The syntax described in the
documentation should be right.
> while the documentation doesn't explicitely talk about DESTBRANCH,
> expect in the form of an hypothetical /newbranch/, that you obviously
> don't give to the command line.
Hmm. I don't have time to look into this now, but the syntax is this:
git filter-branch [<options>] [--] [<rev-options>]
Those refs that you give in the <rev-options> are rewritten. AFAIR the
old values of the refs (if different) are written to refs/original/*.
> And whereas git-filter-branch itself says there is such an argument,
> it actually doesn't take it, and doesn't seem to be hardwired to create
> a new branch instead of overwriting the current one.
>
> So what is git-filter-branch supposed to be doing ?
To rewrite refs.
> As a side note, if it ever happens that git-filter-branch can create a
> new branch, it might be nice to have each commit on the branch to have
> the original commit as parent, as well as its branch parent, so that
> they are seen as merges.
No, this will not happen. Filter-branch is meant to clean up branches, so
it will rewrite the commits. However, you might be able to hack something
in a parent filter.
Ciao,
Dscho
^ permalink raw reply
* Re: git on Cygwin: Not a valid object name HEAD
From: Marius Storm-Olsen @ 2007-08-09 9:00 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Steffen Prohaska, Mark Levedahl, Junio C Hamano, Linus Torvalds,
Git Mailing List, Shawn O. Pearce, Sebastian Schuberth
In-Reply-To: <Pine.LNX.4.64.0708090949200.21857@racer.site>
[-- Attachment #1: Type: text/plain, Size: 508 bytes --]
Johannes Schindelin said the following on 09.08.2007 10:50:
> On Thu, 9 Aug 2007, Marius Storm-Olsen wrote:
>> Try running gitme from a terminal.
> And there I thought that you download GitMe-3.exe, and then double
> click on it...
Heh, yeah, normally that's indeed what you do. However, in this case I
asked him to start it from the terminal to make sure that it wasn't
affected by anything suspicious in his system PATH.
Clearly having Cygwin in his path messed things up.
--
.marius
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
* Re: [GUILT PATCH 2/5] guilt-guard: Assign guards to patches in series
From: Eric Lesh @ 2007-08-09 8:53 UTC (permalink / raw)
To: Thomas Adam; +Cc: David Kastrup, git
In-Reply-To: <18071eea0708090122h79dec205j4528f4dfd7aab588@mail.gmail.com>
"Thomas Adam" <thomas.adam22@gmail.com> writes:
> On 09/08/07, David Kastrup <dak@gnu.org> wrote:
>> sed -i -e "s,^\($p[[:space:]]*.*\)\$,\1 #$x," "$series"
>>
>> and that's fine.
>
> I'm surprised to see 'sed -i' being at all, it's certainly non-portable.
>
> -- Thomas Adam
You're definitely right. I've been asked to change this a couple of
times and keep forgetting. Thanks for the reminder.
Eric
^ permalink raw reply
* Re: git on Cygwin: Not a valid object name HEAD
From: Johannes Schindelin @ 2007-08-09 8:50 UTC (permalink / raw)
To: Marius Storm-Olsen
Cc: Steffen Prohaska, Mark Levedahl, Junio C Hamano, Linus Torvalds,
Git Mailing List, Shawn O. Pearce, Sebastian Schuberth
In-Reply-To: <46BAADC8.9020003@trolltech.com>
Hi,
On Thu, 9 Aug 2007, Marius Storm-Olsen wrote:
> Try running gitme from a terminal.
And there I thought that you download GitMe-3.exe, and then double click
on it...
Ciao,
Dscho
^ permalink raw reply
* Re: Git on MSys (or how to make it easy for Windows users to compile git)
From: Alex Riesen @ 2007-08-09 8:47 UTC (permalink / raw)
To: Marius Storm-Olsen
Cc: Johannes Schindelin, Torgil Svensson, Dmitry Kakurin, git
In-Reply-To: <46B6B60C.4080805@trolltech.com>
On 8/6/07, Marius Storm-Olsen <marius@trolltech.com> wrote:
> Johannes Schindelin said the following on 06.08.2007 02:11:
> On Windows we have a replacement terminal, which has all the features
> you want, and also supports tabs like Konsole. I've used it for
> several years, and it works great. Have a look and see if you like it,
> then we can add it to the repo:
> http://sourceforge.net/projects/console/
>
> Original name, ey? :-)
A fine example of windows hackery (they had to inject some code into
the process running a standard windows console to redirect the IO,
because windows has no tty of any form).
It is wonder it works, but it really does (surprisingly often).
Very impressive.
^ permalink raw reply
* Re: [PATCH] cvsserver: Fix for work trees
From: Johannes Schindelin @ 2007-08-09 8:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Brian Downing, git, Martin Langhoff
In-Reply-To: <7v1wedz2er.fsf@assigned-by-dhcp.cox.net>
Hi,
On Wed, 8 Aug 2007, Junio C Hamano wrote:
> This new world order is probably an improvement, and if the rules were
> like this from the beginning, it would have been much nicer. However,
> this _is_ a change of semantics in the middle of the road, and probably
> we will see many fallouts like this. Unfortunate... I am torn between
> a cleaner semantics and the short-term pain...
With your warning at the beginning of the ReleaseNotes, I think it would
be the same amount of pain if we did it later. It just would be...
later.
Ciao,
Dscho
^ permalink raw reply
* Re: [GUILT PATCH 2/5] guilt-guard: Assign guards to patches in series
From: David Kastrup @ 2007-08-09 8:43 UTC (permalink / raw)
To: git
In-Reply-To: <18071eea0708090122h79dec205j4528f4dfd7aab588@mail.gmail.com>
"Thomas Adam" <thomas.adam22@gmail.com> writes:
> On 09/08/07, David Kastrup <dak@gnu.org> wrote:
>> sed -i -e "s,^\($p[[:space:]]*.*\)\$,\1 #$x," "$series"
>>
>> and that's fine.
>
> I'm surprised to see 'sed -i' being at all, it's certainly non-portable.
Yes. Neither is [[:space:]]. The above actually is pretty much
equivalent to
$(RM) "$series+"
sed "/^$p/s/\$/ #$x/" "$series" >"$series+"
$(MV) "$series+" "$series"
Which is probably not what was intended (the whole [[:space:]]
construct is irrelevant). More likely it was intended to do something
like
$(RM) "$series+"
sed "/^$p[ ]/s/\$/ #$x/" "$series" >"$series+"
$(MV) "$series+" "$series"
or if $p can contain slashes but not commata,
$(RM) "$series+"
sed "\,^$p[ ],s,\$, #$x," "$series" >"$series+"
$(MV) "$series+" "$series"
Note that the included tab character will get safely from any shell to
any sed.
--
David Kastrup
^ 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