* [PATCH] [RFC] send-email: honor --suppress-from --signed-off-cc
From: Uwe Kleine-König @ 2007-07-10 17:02 UTC (permalink / raw)
To: git; +Cc: Uwe Kleine-König
In-Reply-To: <11840869641759-git-send-email-ukleinek@informatik.uni-freiburg.de>
From: Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
---
Not sure, if this is how it should be. Maybe we need another flag?
Best regards
Uwe
git-send-email.perl | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 8b3d450..a03153b 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -641,9 +641,11 @@ foreach my $t (@files) {
if (/^(Signed-off-by|Cc): (.*)$/i && $signed_off_cc) {
my $c = $2;
chomp $c;
- push @cc, $c;
- printf("(sob) Adding cc: %s from line '%s'\n",
- $c, $_) unless $quiet;
+ if (!$suppress_from or $c eq $from) {
+ push @cc, $c;
+ printf("(sob) Adding cc: %s from line '%s'\n",
+ $c, $_) unless $quiet;
+ }
}
}
}
--
1.5.3.rc0.823.gdedbf
^ permalink raw reply related
* [PATCH] send-email: extend sanitize_address_rfc822 to do rfc2047 quoting
From: Uwe Kleine-König @ 2007-07-10 17:02 UTC (permalink / raw)
To: git; +Cc: Uwe Kleine-König
Without this patch I'm not able to properly send emails as I have a
non-ascii character in my name.
Signed-off-by: Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
---
As I'm not a perl profi, someone wants to check this code.
Actually this series is a test, as it is sended with the patched send-email.
I hope it works :-)
Uwe
git-send-email.perl | 24 +++++++++++++++++++-----
1 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 89f7c36..8b3d450 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -459,16 +459,30 @@ sub unquote_rfc2047 {
return "$_";
}
-# If an address contains a . in the name portion, the name must be quoted.
+# If an address contains a non-ascii char in the name port, quote it according
+# to rfc2047.
+# If an address contains a . in the name portion, the name must be quoted using
+# double quotes.
sub sanitize_address_rfc822
{
my ($recipient) = @_;
- my ($recipient_name) = ($recipient =~ /^(.*?)\s+</);
+ my ($recipient_name, $recipient_addr) = ($recipient =~ /^(.*?)(\s+<.*)/);
+
+ if ($recipient_name && $recipient_name =~ /[^-a-zA-Z0-9!*+\/ ]/ && $recipient_name !~ /=\?utf-8\?q?.*\?=/) {
+ $recipient_name =~ s/([^-a-zA-Z0-9!*+ ])/sprintf("=%02X", ord($1))/eg;
+ $recipient_name =~ s/ /_/;
+ $recipient_name =~ s/(.*)/=\?utf-8\?q\?$1\?=/;
+ }
+
if ($recipient_name && $recipient_name =~ /\./ && $recipient_name !~ /^".*"$/) {
- my ($name, $addr) = ($recipient =~ /^(.*?)(\s+<.*)/);
- $recipient = "\"$name\"$addr";
+ $recipient_name = "\"$recipient_name\"";
+ }
+
+ if ($recipient_name) {
+ return "$recipient_name$recipient_addr";
+ } else {
+ return "$recipient";
}
- return $recipient;
}
sub send_message
--
1.5.3.rc0.823.gdedbf
^ permalink raw reply related
* Re: [WIP] Get rid of msys in favor of busybox port for windows
From: Nguyen Thai Ngoc Duy @ 2007-07-10 16:45 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0707101719390.4047@racer.site>
On 7/10/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Tue, 10 Jul 2007, Nguyen Thai Ngoc Duy wrote:
>
> > On 7/10/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > >
> > > On Tue, 10 Jul 2007, Nguyen Thai Ngoc Duy wrote:
> > >
> > > > I'm integrating some code from busybox to mingw tree so that mingw port
> > > > can work without msys. Posix utilities such as sed, awk, head, tail...
> > > > seem to work well. The main obstacle is ash, which is no where near
> > > > usable state (fork issues as always). Busybox ash is about 13000 lines
> > > > of code, not too big.
> > > >
> > > > Anyone interested in?
> > >
> > > Definitely.
> > >
> > > Last time I wanted to assess how much work it is to compile that on MinGW,
> > > though, it seemed to be too much to be tractable.
> >
> > The exact answer is "I don't know" :-) I cross compile all the time
> > however it should build fine on MinGW as it now uses git Makefile.
> > I'll push the patch into mob soon.
>
> Do you mean the whole busybox thing?
>
> If so, please do not put it into mingw.git. Rather, start a busybox.git
> project (I saw that you have already some projects on repo.or.cz, so it
> should be easy for you.)
No, I don't port the whole busybox (too big, too difficult). I
extracted stuffs that need to run shell scripts (mainly coreutils and
ash) and put them in my mingw tree. Just wanted to push it if you
wanted to try.. maybe later.
--
Duy
^ permalink raw reply
* Re: [WIP] Get rid of msys in favor of busybox port for windows
From: Johannes Schindelin @ 2007-07-10 16:20 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Git Mailing List
In-Reply-To: <fcaeb9bf0707100908o4be761b9t920cdc65a72d9aee@mail.gmail.com>
Hi,
On Tue, 10 Jul 2007, Nguyen Thai Ngoc Duy wrote:
> On 7/10/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >
> > On Tue, 10 Jul 2007, Nguyen Thai Ngoc Duy wrote:
> >
> > > I'm integrating some code from busybox to mingw tree so that mingw port
> > > can work without msys. Posix utilities such as sed, awk, head, tail...
> > > seem to work well. The main obstacle is ash, which is no where near
> > > usable state (fork issues as always). Busybox ash is about 13000 lines
> > > of code, not too big.
> > >
> > > Anyone interested in?
> >
> > Definitely.
> >
> > Last time I wanted to assess how much work it is to compile that on MinGW,
> > though, it seemed to be too much to be tractable.
>
> The exact answer is "I don't know" :-) I cross compile all the time
> however it should build fine on MinGW as it now uses git Makefile.
> I'll push the patch into mob soon.
Do you mean the whole busybox thing?
If so, please do not put it into mingw.git. Rather, start a busybox.git
project (I saw that you have already some projects on repo.or.cz, so it
should be easy for you.)
Thanks,
Dscho
^ permalink raw reply
* Re: [WIP] Get rid of msys in favor of busybox port for windows
From: Nguyen Thai Ngoc Duy @ 2007-07-10 16:12 UTC (permalink / raw)
To: Henning Rogge; +Cc: git
In-Reply-To: <87eacd830707100856l3132bee2k45b8d59ac1875d89@mail.gmail.com>
On 7/10/07, Henning Rogge <hrogge@googlemail.com> wrote:
> On 7/10/07, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> > I'm integrating some code from busybox to mingw tree so that mingw
> > port can work without msys. Posix utilities such as sed, awk, head,
> > tail... seem to work well. The main obstacle is ash, which is no where
> > near usable state (fork issues as always). Busybox ash is about 13000
> > lines of code, not too big.
> >
> > Anyone interested in?
> If I can use it without needing a "vi/vim" implementation I'm interested !
There is no vi/vim in the port :-) My goal is to make shell scripts
work with minimum effort. I don't even attempt to make ash
interactively usable (well, git add --interactive and friends have to
wait longer).
--
Duy
^ permalink raw reply
* [PATCH] Work around a bad interaction between Tcl and cmd.exe with "^{tree}"
From: Johannes Sixt @ 2007-07-10 16:10 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
It seems that MSYS's wish does some quoting for Bourne shells, in
particular, escape the first '{' of the "^{tree}" suffix, but then it uses
cmd.exe to run "git rev-parse". However, cmd.exe does not remove the
backslash, so that the resulting rev expression ends up in git's guts
as unrecognizable garbage: rev-parse fails, and git-gui hickups in a way
that it must be restarted.
Fortunately, recent versions of git can refer to the root tree object using
the notation "$commit:", which avoids the problematic case.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
This is a resend with a slightly improved commit message.
The first version didn't get through for some reason anyway, it seems.
lib/commit.tcl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib/commit.tcl b/lib/commit.tcl
index dc7c88c..43a5aca 100644
--- a/lib/commit.tcl
+++ b/lib/commit.tcl
@@ -258,7 +258,7 @@ proc commit_committree {fd_wt curHEAD msg} {
# -- Verify this wasn't an empty change.
#
if {$commit_type eq {normal}} {
- set old_tree [git rev-parse "$PARENT^{tree}"]
+ set old_tree [git rev-parse "$PARENT:"]
if {$tree_id eq $old_tree} {
info_popup {No changes to commit.
--
1.5.3.rc0.32.g2968f
^ permalink raw reply related
* Re: [WIP] Get rid of msys in favor of busybox port for windows
From: Nguyen Thai Ngoc Duy @ 2007-07-10 16:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0707101638521.4047@racer.site>
On 7/10/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Tue, 10 Jul 2007, Nguyen Thai Ngoc Duy wrote:
>
> > I'm integrating some code from busybox to mingw tree so that mingw port
> > can work without msys. Posix utilities such as sed, awk, head, tail...
> > seem to work well. The main obstacle is ash, which is no where near
> > usable state (fork issues as always). Busybox ash is about 13000 lines
> > of code, not too big.
> >
> > Anyone interested in?
>
> Definitely.
>
> Last time I wanted to assess how much work it is to compile that on MinGW,
> though, it seemed to be too much to be tractable.
The exact answer is "I don't know" :-) I cross compile all the time
however it should build fine on MinGW as it now uses git Makefile.
I'll push the patch into mob soon.
--
Duy
^ permalink raw reply
* Re: [WIP] Get rid of msys in favor of busybox port for windows
From: Henning Rogge @ 2007-07-10 15:56 UTC (permalink / raw)
To: git
In-Reply-To: <fcaeb9bf0707100832j3c2ff076gab5c9bd4f9d3f4a0@mail.gmail.com>
On 7/10/07, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> I'm integrating some code from busybox to mingw tree so that mingw
> port can work without msys. Posix utilities such as sed, awk, head,
> tail... seem to work well. The main obstacle is ash, which is no where
> near usable state (fork issues as always). Busybox ash is about 13000
> lines of code, not too big.
>
> Anyone interested in?
If I can use it without needing a "vi/vim" implementation I'm interested !
Henning
^ permalink raw reply
* Re: [WIP] Get rid of msys in favor of busybox port for windows
From: Johannes Schindelin @ 2007-07-10 15:39 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Git Mailing List
In-Reply-To: <fcaeb9bf0707100832j3c2ff076gab5c9bd4f9d3f4a0@mail.gmail.com>
Hi,
On Tue, 10 Jul 2007, Nguyen Thai Ngoc Duy wrote:
> I'm integrating some code from busybox to mingw tree so that mingw port
> can work without msys. Posix utilities such as sed, awk, head, tail...
> seem to work well. The main obstacle is ash, which is no where near
> usable state (fork issues as always). Busybox ash is about 13000 lines
> of code, not too big.
>
> Anyone interested in?
Definitely.
Last time I wanted to assess how much work it is to compile that on MinGW,
though, it seemed to be too much to be tractable.
Ciao,
Dscho
^ permalink raw reply
* [WIP] Get rid of msys in favor of busybox port for windows
From: Nguyen Thai Ngoc Duy @ 2007-07-10 15:32 UTC (permalink / raw)
To: Git Mailing List
Hi,
I'm integrating some code from busybox to mingw tree so that mingw
port can work without msys. Posix utilities such as sed, awk, head,
tail... seem to work well. The main obstacle is ash, which is no where
near usable state (fork issues as always). Busybox ash is about 13000
lines of code, not too big.
Anyone interested in?
--
Duy
^ permalink raw reply
* Re: [RFC] series headers
From: Johannes Schindelin @ 2007-07-10 15:23 UTC (permalink / raw)
To: Theodore Tso; +Cc: Junio C Hamano, Daniel Barkalow, git
In-Reply-To: <20070710144808.GA27033@thunk.org>
Hi,
On Tue, 10 Jul 2007, Theodore Tso wrote:
> On Tue, Jul 10, 2007 at 02:56:48PM +0100, Johannes Schindelin wrote:
> > And what is so wrong with
> >
> > [insert before format-patch] $EDITOR my-cover-letter.txt
> >
> > [replace $EDITOR 0000-cover-letter.txt] $EDITOR my-cover-letter.txt
> > 0000-cover-letter.patch
> >
> > and paste the changed text?
>
> Nothing is *wrong* with it per-se, but if you have multiple things that
> you are working on at the same-time, you might not want to keep
> 0000-cover-letter.patch in your working directory.
Ah, but then maybe you want to be able to say
git format-patch --cover-letter=<my-cover-letter> [...]
Where your cover-letter file looks something like this:
My patch series which will rule the world
Here is the body, and I explain what the world should look like,
and that they should accept me as the chosen one president of the
united geekheads of this world.
IOW the file contents to produce what is produced with my patch would look
like this:
*** SUBJECT HERE ***
*** BLURB HERE ***
Ciao,
Dscho
^ permalink raw reply
* finding the right remote branch for a commit
From: martin f krafft @ 2007-07-10 14:49 UTC (permalink / raw)
To: git discussion list
[-- Attachment #1: Type: text/plain, Size: 2853 bytes --]
Dear list,
I am trying to figure out a way to store ~/.etc in git. With SVN,
I would have a .etc repository for each machine, which would use
svn:externals to reference locations of the various subdirectories,
which SVN would then pull and assemble. Thus, my ~/.etc might be
~/.etc
~/.etc/ssh [svn+ssh://svn.madduck.net/priv/etc/ssh]
~/.etc/vim [svn+ssh://svn.madduck.net/pub/etc/vim]
...
With git, I am now considering using remote branches for this kind
of stuff. So I'll have a repository for my ssh config and
a repository for my vim config, and so on.
The idea then is to create another repository for each machine and
to register the remote tracking branches there in much the same way
that I used svn:externals previously (and with the added benefit
that I don't have to stay within subdirectories).
Thus, the vim repository might look like this:
.etc/
|-- vim/
| `-- rc.vim
`-- .vimrc -> .etc/vim/rc.vim
and the ssh configuration might be
.etc/
|-- ssh/
| |-- config
| `-- authorized_keys
`-- .ssh -> .etc/ssh/
My theory is that merging all those remotely tracked branches into
a local repo populates my home directory, and bringing it up to the
latest version is as simple as:
git remote update
git branch -r | xargs git merge # any way to just merge all remote branches?
So far so good, this seems to work just fine.
Right now I am trying to figure out how to push updates back to the
central store so that other machines who "subscribe" to a given
branch can receive the updates.
For instance, I may have made a change to ~/.vimrc and to
~/.ssh/config and committed each to the machine-local repository.
What I need now is a way to tell me
(a) which commits are local and have not been merged from a remote
tracking branch. If I actually want to keep commits local,
e.g. because of changes only applicable to this one machine,
I can move them to a local branch and rebase that whenever the
remotes change.
(b) which commits should be pushed where. This is a bit of
a strange one it may seem, but in my case, remote branches are
orthogonal and never touch the same file. Thus, each file
belongs to one remote branch. How can I determine which one?
Or even better, how could I push all my local commits to the
respective remotes?
Thanks for any comments, and sorry to be cluttering the list with my
newbie stuff...
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
spamtraps: madduck.bogus@madduck.net
"moderation is a fatal thing. enough is as bad as a meal. more than
enough is as good as a feast."
-- oscar wilde
[-- Attachment #2: Digital signature (GPG/PGP) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC] series headers
From: Theodore Tso @ 2007-07-10 14:48 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Daniel Barkalow, git
In-Reply-To: <Pine.LNX.4.64.0707101452250.4047@racer.site>
On Tue, Jul 10, 2007 at 02:56:48PM +0100, Johannes Schindelin wrote:
> And what is so wrong with
>
> [insert before format-patch] $EDITOR my-cover-letter.txt
>
> [replace $EDITOR 0000-cover-letter.txt] $EDITOR my-cover-letter.txt
> 0000-cover-letter.patch
>
> and paste the changed text?
Nothing is *wrong* with it per-se, but if you have multiple things
that you are working on at the same-time, you might not want to keep
0000-cover-letter.patch in your working directory.
The simplest place to put it is in .git/patches/<branch> while I'm
working with it using guilt (or the equivalent place in stgit), and if
you include it in the series file then it becomes easier to hack it so
that git-format-patches will create the cover letter for you. (And
ideally, you would be able to use guilt to edit the cover letter using
"guilt header -e cover-letter" but that feature hasn't been added yet;
should be simple, though.)
Basically, the issue is of handling the cover letter as a first-class
object, as opposed to something whic his manually handled via
cut-and-paste. A lot of the tools are actually there already if you
are using tools like guilt and stgit. So it's basically making a
particular workflow a bit more optimized, that's all.
There certainly is nothing *wrong* with manual maintenance of the
cover-letter file plus cut-and-paste when you want to update it. Just
as there's nothing *wrong* with using git-write-tree instead of
git-commit. Just a question of which is more convenient and less
error prone. :-)
- Ted
^ permalink raw reply
* pushing changes to a remote branch
From: martin f krafft @ 2007-07-10 14:36 UTC (permalink / raw)
To: git discussion list
[-- Attachment #1: Type: text/plain, Size: 1898 bytes --]
Hi list,
I am using git-remote to clone a remote repository and track only
a select number of branches:
git remote add -f -t vim -t ssh origin git://git.server.org/path/to/repo.git
git branch -r
origin/ssh
origin/vim
git merge ...
I now merge these into the local repo and decide that I need to make
a change to origin/vim. So I figure that it's probably easiest if
I just checkout the remote branch, make the change, commit it, push
it, return to the master branch, git-remote update and merge, but:
git checkout origin/vim
Note: moving to "origin/vim" which isn't a local branch
echo change > newfile; git add newfile
git commit -m'make change'
Created commit 64b8b2e: make change
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 newfile
If I now checkout master and then return to origin/vim, the commit
is gone.
If I repeat all this and, instead of returning to master, I push the
commit to origin, git suggests success (the push looks normal).
However, I then cannot find the commit anymore. It's not available
locally, nor in origin/vim, nor in the local master branch or in
origin/master.
This is curious and I'd love to find out what's going on.
Much more, however, I am interested how I am supposed to push
commits back to select remote branches.
Using
git push git://git.server.org/path/to/repo.git \
7fbb0655:refs/heads/vim
does push commit 7fbb0655 to the vim branch in the remote
repository, but I should be able to do this using origin/vim, no?
How?
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
spamtraps: madduck.bogus@madduck.net
"the worst part of being old is remembering when you was young."
-- alvin straight (the straight story)
[-- Attachment #2: Digital signature (GPG/PGP) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Fix --cherry-pick with given paths
From: Sam Vilain @ 2007-07-10 14:22 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0707101449220.4047@racer.site>
Johannes Schindelin wrote:
> If you say --cherry-pick, you do not want to see patches which are
> in the upstream. If you specify paths with that, what you usually
> expect is that only those parts of the patches are looked at which
> actually touch the given paths.
>
> With this patch, that expectation is met.
>
> Noticed by Sam Vilain.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
>
I just tested this, and it seems to work just like I hoped, so:
Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>
Sam.
^ permalink raw reply
* Re: I used git pull instead of stg pull !
From: Jean-Christian de Rivaz @ 2007-07-10 14:20 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20070710132957.GA9297@diana.vm.bytemark.co.uk>
Thanks a lot Karl,
Your method solved the problem perfectly.
Have a good day,
--
Jean-Christian de Rivaz
Karl Hasselström a écrit :
> On 2007-07-10 11:52:47 +0200, Jean-Christian de Rivaz wrote:
>
>> I have made the error to use the "git pull" command instead of the
>> "stg pull" command. The "git pull" have been executed successfuly,
>> but now stg seem to be confused:
>>
>> stg pull -n
>> stg pull: local changes in the tree. Use "refresh" to commit them
>>
>> stg new dummy -m "dummy"
>> stg new: HEAD and top are not the same. You probably committed
>> changes to the tree outside of StGIT. If you know what you
>> are doing, use the "refresh -f" command
>>
>> How can I restore the archive to a normal state for stg ?
>
> The problem is that you have committed a merge on top of the StGIT
> stack, and StGIT can't deal with that. You can undo the merge
> (provided that you haven't committed anything else on top of it) with
> "git reset --hard HEAD^".
>
> NOTE: "reset --hard" will erase uncommitted modifications to working
> tree files, so first make sure that "git status" doesn't report any
> modifications you want to keep.
>
> If you want to get a better view of what it is you're doing, you could
> fire up gitk and find the sha1 of the commit that is supposed to be at
> the top of the StGIT stack, and "git reset <sha1>" to that commit.
>
> Once the merge is undone, just "stg pull" like you wanted to do in the
> first place.
>
^ permalink raw reply
* Re: [PATCH 1/2] Add for_each_remote() function, and extend remote_find_tracking()
From: Johannes Schindelin @ 2007-07-10 14:11 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, Paolo Bonzini, git
In-Reply-To: <Pine.LNX.4.64.0707092323160.6977@iabervon.org>
Hi,
On Mon, 9 Jul 2007, Daniel Barkalow wrote:
> On Tue, 10 Jul 2007, Johannes Schindelin wrote:
>
> > The function for_each_remote() does exactly what the name suggests.
> >
> > The function remote_find_tracking() was extended to be able to search
> > remote refs for a given local ref. You have to set the parameter
> > "reverse" to true for that behavior.
>
> I think I'd like this better if reverse meant that it looked at
> refspec->dst and set refspec->src, rather than returning the refspec
> reversed; the current version sets the refspec so that it's effectively
> something from the list, which makes it easier to understand.
>
> Maybe make it so the user calls it with at most one of src and dst NULL,
> and it returns with neither NULL or returns -1 if it can't find anything?
Will do.
Ciao,
Dscho
^ permalink raw reply
* Re: git-svn and renames
From: Rogan Dawes @ 2007-07-10 14:18 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86fy3wpf95.fsf@lola.quinscape.zz>
David Kastrup wrote:
> Rogan Dawes <lists@dawes.za.net> writes:
>
>> However, when I try to push this change to the Google repo, git-svn
>> dies with the following error:
>>
>> $ git svn dcommit
>> RA layer request failed: PROPFIND request failed on '/svn/trunk/
>> webgoat/main/project/JavaSource/org/owasp/webgoat/lessons/DefaultLessonAction.java':
>> PROPFIND of '/svn/trunk/
>> webgoat/main/project/JavaSource/org/owasp/webgoat/lessons/DefaultLessonAction.java':
>> 400 Bad Request (https://webgoat.googlecode.com) at
>> /home/rdawes/bin/git-svn line 400
>>
>> [Yes, those paths have a space in them, however this does not seem to
>> have prevented me from committing the previous 20 or so changes.]
>>
>> I noted the following in the git-svn documentation, with regards to
>> handling renames. However, I am not renaming a directory, only a
>> couple of files.
>
>> ---- quote ----
>
> [...]
>> Renamed and copied directories are not detected by git and hence not
>> tracked when committing to SVN. I do not plan on adding support for
>> this as it's quite difficult and time-consuming to get working for all
>> the possible corner cases (git doesn't do it, either). Committing
>> renamed and copied files are fully supported if they're similar enough
>> for git to detect them.
>
>> Any ideas?
>
> dcommit Commit several diffs to merge with upstream
> --quiet, -q
> --fetch-all, --all
> --no-auth-cache
> --no-rebase
> --no-checkout
> --rmdir
> --dry-run, -n
> --find-copies-harder
> --follow-parent, --follow!
> --authors-file, -A <arg>
> --copy-similarity, -C <num>
> --username <arg>
> --repack-flags, --repack-args, --repack-opts <arg>
> --repack <num>
> --verbose, -v
> --edit, -e
> --log-window-size <num>
> --config-dir <arg>
> -l <num>
> --merge, -m, -M
> --strategy, -s <arg>
>
>
> Try playing with the --copy-similarity and --find-copies-harder flags.
>
Thanks for the suggestion.
However, even going all the way to 50% had no impact. I get the exact
same message.
$ git svn --find-copies-harder -C 50 dcommit
RA layer request failed: PROPFIND request failed on '/svn/trunk/
webgoat/main/project/JavaSource/org/owasp/webgoat/lessons/DefaultLessonAction.java':
PROPFIND of '/svn/trunk/
webgoat/main/project/JavaSource/org/owasp/webgoat/lessons/DefaultLessonAction.java':
400 Bad Request (https://webgoat.googlecode.com) at
/home/rdawes/bin/git-svn line 400
Unfortunately, the error seems to be in the SVN::Ra library, and I can
find no way to enable debugging output on this code.
One thing I did note is that performing a dry-run completes successfully:
$ git svn dcommit -n
diff-tree 486416188a3e49d60e1510166ac197e5e66cc4d2~1
486416188a3e49d60e1510166ac197e5e66cc4d2
diff-tree e0100ee6353c2160eca642ec600639004d92a99e~1
e0100ee6353c2160eca642ec600639004d92a99e
diff-tree ba64aa781efdc31a4ffceed8648ece45ac955186~1
ba64aa781efdc31a4ffceed8648ece45ac955186
diff-tree 23202df6f1533bf79c0ad127fdcb06db35d8b634~1
23202df6f1533bf79c0ad127fdcb06db35d8b634
diff-tree 42af98c396e66cc2c0377e267e5431414fb8d580~1
42af98c396e66cc2c0377e267e5431414fb8d580
diff-tree 16c76a9129cb66378851bb0bec8e983354d0c936~1
16c76a9129cb66378851bb0bec8e983354d0c936
diff-tree d1a1992abfdcba1a97989c29dd0f25257b03f16a~1
d1a1992abfdcba1a97989c29dd0f25257b03f16a
diff-tree dc7071e954e33a0c859db575f3b4be767194fa7e~1
dc7071e954e33a0c859db575f3b4be767194fa7e
diff-tree 107ef202137ba38325c28b95983ded23d67cae89~1
107ef202137ba38325c28b95983ded23d67cae89
diff-tree 01891b7a0cc03234145a29582dbd5061aed0b347~1
01891b7a0cc03234145a29582dbd5061aed0b347
diff-tree f047c06823632a10379255957302698375e62d26~1
f047c06823632a10379255957302698375e62d26
diff-tree 634664ef291c5f33594202dec9f5e081348e10d2~1
634664ef291c5f33594202dec9f5e081348e10d2
diff-tree 13e731927bc32e27a240cba647f1c6425cea6247~1
13e731927bc32e27a240cba647f1c6425cea6247
diff-tree df62b0a2ef3f5556b52b933b08409dc05a2ba671~1
df62b0a2ef3f5556b52b933b08409dc05a2ba671
diff-tree 745ec078b881cc87234a7bfe59635f7856094d8e~1
745ec078b881cc87234a7bfe59635f7856094d8e
diff-tree 91b08b5f2bc6bc1d235cb9d624be23346c5a2749~1
91b08b5f2bc6bc1d235cb9d624be23346c5a2749
diff-tree 8c1805e3be9595099832d9c55cdf740f3c20bd16~1
8c1805e3be9595099832d9c55cdf740f3c20bd16
diff-tree b06b234c5dbb046e4a56ee30f4a8b1bf17758794~1
b06b234c5dbb046e4a56ee30f4a8b1bf17758794
diff-tree 52313b6cb19fc962a7c51eacf9016870b93e2467~1
52313b6cb19fc962a7c51eacf9016870b93e2467
diff-tree 8689b19c8fc48a603c0b9992a7ba04f7e57f4e70~1
8689b19c8fc48a603c0b9992a7ba04f7e57f4e70
diff-tree 23e348e97ee5220e7514249a163647b187aa4f8b~1
23e348e97ee5220e7514249a163647b187aa4f8b
diff-tree 76479ab494bd6edfa306271be0919d4b210d1296~1
76479ab494bd6edfa306271be0919d4b210d1296
[word wrapped, unfortunately]
Thanks for your help.
Regards,
Rogan
^ permalink raw reply
* [PATCH] Work around a bad interaction between Tcl and cmd.exe with "^{tree}"
From: Johannes Sixt @ 2007-07-10 13:09 UTC (permalink / raw)
To: spearce; +Cc: git, Johannes Sixt
From: Johannes Sixt <johannes.sixt@telecom.at>
It seems that MSYS's wish does some quoting for Bourne shells, in
particular, escape the first '{' of the "^{tree}" suffix, but then it uses
cmd.exe to run the "git rev-parse" command. However, cmd.exe does not remove
the backslash, so that the resulting ref expression ends up in git's guts
as unrecognizable garbage.
Fortunately, recent versions of git can refer to the root tree object using
the notation "$commit:", which avoids the problematic case.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
lib/commit.tcl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib/commit.tcl b/lib/commit.tcl
index dc7c88c..43a5aca 100644
--- a/lib/commit.tcl
+++ b/lib/commit.tcl
@@ -258,7 +258,7 @@ proc commit_committree {fd_wt curHEAD msg} {
# -- Verify this wasn't an empty change.
#
if {$commit_type eq {normal}} {
- set old_tree [git rev-parse "$PARENT^{tree}"]
+ set old_tree [git rev-parse "$PARENT:"]
if {$tree_id eq $old_tree} {
info_popup {No changes to commit.
--
1.5.3.rc0.32.g2968f
^ permalink raw reply related
* Re: [PATCH] Support wholesale directory renames in fast-import
From: Shawn O. Pearce @ 2007-07-10 14:14 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: David Frech, git
In-Reply-To: <20070710140338.GA18450@informatik.uni-freiburg.de>
Uwe Kleine-K??nig <ukleinek@informatik.uni-freiburg.de> wrote:
> David Frech wrote:
> > Now my challenge is that the svn dump doesn't *actually* say "rename
> > a/ to b/"; it says "copy a/ to b/; delete a/", so I have to infer the
> > rename.
>
> I don't know fast-import very well, but why not doing exactly what the
> dump file suggests: copy a b; delete a ?
Because there is no copy operator in fast-import. So you cannot
do "copy a b". Apparently that's what I should have implemented,
as rename in Git really is as simple as the copy/delete pair. Ugh.
Copy isn't really that hard, it just can't be nearly as efficient as
rename, as copying a subtree will force me to either duplicate data
in memory or reload trees from disk to duplicate data in memory.
But its a copy, so data duplication is expected. ;-)
I'll implement a copy opertor soon. Shouldn't be too difficult.
Maybe someone else would like to take a shot at implementing it...
--
Shawn.
^ permalink raw reply
* Re: [RFC] series headers
From: Johannes Schindelin @ 2007-07-10 13:56 UTC (permalink / raw)
To: Theodore Tso; +Cc: Junio C Hamano, Daniel Barkalow, git
In-Reply-To: <20070710132401.GJ2343@thunk.org>
Hi,
On Tue, 10 Jul 2007, Theodore Tso wrote:
> In general a patch series goes through multiple cycles of
> improvements, where people send it out for review/comment, and then it
> gets fixed up, etc. etc. So you don't want to just do this:
>
> On Mon, Jul 09, 2007 at 11:57:21PM -0700, Junio C Hamano wrote:
>
> > $ work work work, commit commit commit, reorder and perfect
> > $ git format-patch --with-cover origin..HEAD
> > ... which notices --with-cover, and perhaps does
> > ... $ git-shortlog origin..HEAD
> > ... $ git diff --stat --summary origin..HEAD
> > ... $ echo "*** BLURB HERE ***"
> > ... to create 0/N which it did not do so far in
> > ... 0000-cover-letter.txt
> > $ $EDITOR 0000-cover-letter.txt
> > $ git-send-email 0*.txt
>
> Because you'll be sending out the 0000-cover-letter.txt multiple
> times, refining it (and the patches) as you go along.
And what is so wrong with
[insert before format-patch] $EDITOR my-cover-letter.txt
[replace $EDITOR 0000-cover-letter.txt] $EDITOR my-cover-letter.txt
0000-cover-letter.patch
and paste the changed text?
Of course, you can still hand roll something with a commit. Probably a
squash merge of your patch series.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Support wholesale directory renames in fast-import
From: Uwe Kleine-König @ 2007-07-10 14:03 UTC (permalink / raw)
To: David Frech; +Cc: Shawn O. Pearce, git
In-Reply-To: <7154c5c60707092116p70aaeb8l90cda9265311b999@mail.gmail.com>
Hallo David,
David Frech wrote:
> Now my challenge is that the svn dump doesn't *actually* say "rename
> a/ to b/"; it says "copy a/ to b/; delete a/", so I have to infer the
> rename.
I don't know fast-import very well, but why not doing exactly what the
dump file suggests: copy a b; delete a ?
Best regards
Uwe
--
Uwe Kleine-König
http://www.google.com/search?q=12+divided+by+3
^ permalink raw reply
* Re: git-svn and renames
From: Rogan Dawes @ 2007-07-10 14:01 UTC (permalink / raw)
To: Florian Weimer; +Cc: git
In-Reply-To: <87odik74tx.fsf@mid.deneb.enyo.de>
Florian Weimer wrote:
> * Rogan Dawes:
>
>> $ git svn dcommit
>> RA layer request failed: PROPFIND request failed on '/svn/trunk/
>> webgoat/main/project/JavaSource/org/owasp/webgoat/lessons/DefaultLessonAction.java':
>> PROPFIND of '/svn/trunk/
>> webgoat/main/project/JavaSource/org/owasp/webgoat/lessons/DefaultLessonAction.java':
>> 400 Bad Request (https://webgoat.googlecode.com) at
>> /home/rdawes/bin/git-svn line 400
>
> Does the "lessons" directory exist before that commit?
Yes. The file was in the lessons/ directory, and was moved to
lessons/GoatHillsFinancial/. This new directory also existed prior to
this commit.
Rogan
^ permalink raw reply
* [PATCH] Fix --cherry-pick with given paths
From: Johannes Schindelin @ 2007-07-10 13:50 UTC (permalink / raw)
To: Sam Vilain; +Cc: git
In-Reply-To: <4693800F.4010308@vilain.net>
If you say --cherry-pick, you do not want to see patches which are
in the upstream. If you specify paths with that, what you usually
expect is that only those parts of the patches are looked at which
actually touch the given paths.
With this patch, that expectation is met.
Noticed by Sam Vilain.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Wed, 11 Jul 2007, Sam Vilain wrote:
> Sam Vilain wrote:
> > I'm interested in extending the cherry analysis to allow
> > specification of the diff options used when calculating diff
> > IDs, presenting the calculated diff IDs for analysis by
> > external tools, and even calculating and dealing with per-hunk
> > diff IDs.
>
> On reflection I think so long as --cherry-pick works together
> with a file selection, it would probably be enough.
>
> ie, if I have these commits:
>
> A---B
> \
> \
> C
>
> B changes a file foo.c, adding a line of text. C changes foo.c
> as well as bar.c, but the change in foo.c was identical to
> change B.
>
> I want this to show me nothing:
>
> git-rev-list --left-right --cherry-pick B...C -- foo.c
>
> Would it be the right approach to put this information in
> ids->diffopts, or somewhere else?
That was interesting. And it is indeed the right place to put it.
revision.c | 9 +++++-
t/t6007-rev-list-cherry-pick-file.sh | 43 ++++++++++++++++++++++++++++++++++
2 files changed, 50 insertions(+), 2 deletions(-)
create mode 100755 t/t6007-rev-list-cherry-pick-file.sh
diff --git a/revision.c b/revision.c
index 33ee9ee..27cce09 100644
--- a/revision.c
+++ b/revision.c
@@ -437,7 +437,7 @@ static int add_parents_to_list(struct rev_info *revs, struct commit *commit, str
return 0;
}
-static void cherry_pick_list(struct commit_list *list)
+static void cherry_pick_list(struct commit_list *list, struct rev_info *revs)
{
struct commit_list *p;
int left_count = 0, right_count = 0;
@@ -458,6 +458,11 @@ static void cherry_pick_list(struct commit_list *list)
left_first = left_count < right_count;
init_patch_ids(&ids);
+ if (revs->diffopt.nr_paths) {
+ ids.diffopts.nr_paths = revs->diffopt.nr_paths;
+ ids.diffopts.paths = revs->diffopt.paths;
+ ids.diffopts.pathlens = revs->diffopt.pathlens;
+ }
/* Compute patch-ids for one side */
for (p = list; p; p = p->next) {
@@ -546,7 +551,7 @@ static int limit_list(struct rev_info *revs)
p = &commit_list_insert(commit, p)->next;
}
if (revs->cherry_pick)
- cherry_pick_list(newlist);
+ cherry_pick_list(newlist, revs);
revs->commits = newlist;
return 0;
diff --git a/t/t6007-rev-list-cherry-pick-file.sh b/t/t6007-rev-list-cherry-pick-file.sh
new file mode 100755
index 0000000..143f332
--- /dev/null
+++ b/t/t6007-rev-list-cherry-pick-file.sh
@@ -0,0 +1,43 @@
+#!/bin/sh
+
+test_description='test git rev-list --cherry-pick -- file'
+
+. ./test-lib.sh
+
+# A---B
+# \
+# \
+# C
+#
+# B changes a file foo.c, adding a line of text. C changes foo.c as
+# well as bar.c, but the change in foo.c was identical to change B.
+
+test_expect_success setup '
+ echo Hallo > foo &&
+ git add foo &&
+ test_tick &&
+ git commit -m "A" &&
+ git tag A &&
+ git checkout -b branch &&
+ echo Bello > foo &&
+ echo Cello > bar &&
+ git add foo bar &&
+ test_tick &&
+ git commit -m "C" &&
+ git tag C &&
+ git checkout master &&
+ git checkout branch foo &&
+ test_tick &&
+ git commit -m "B" &&
+ git tag B
+'
+
+test_expect_success '--cherry-pick foo comes up empty' '
+ test -z "$(git rev-list --left-right --cherry-pick B...C -- foo)"
+'
+
+test_expect_success '--cherry-pick bar does not come up empty' '
+ ! test -z "$(git rev-list --left-right --cherry-pick B...C -- bar)"
+'
+
+test_done
--
1.5.3.rc0.2782.g192a9-dirty
^ permalink raw reply related
* Re: [PATCH] Support wholesale directory renames in fast-import
From: Shawn O. Pearce @ 2007-07-10 13:55 UTC (permalink / raw)
To: Rogan Dawes; +Cc: David Frech, git
In-Reply-To: <469346D8.4080906@dawes.za.net>
Rogan Dawes <lists@dawes.za.net> wrote:
> Shawn O. Pearce wrote:
> >-Zero or more `filemodify`, `filedelete` and `filedeleteall` commands
> >+Zero or more `filemodify`, `filedelete`, `filename` and
> ^^ filerename
Ugh. Thanks. I just pushed out a corrected version.
--
Shawn.
^ 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