* Re: Git 1.6.5-rc git clone unhandled exception using http protocol
From: Junio C Hamano @ 2009-10-13 21:06 UTC (permalink / raw)
To: Michael Wookey
Cc: Johannes Sixt, eduard stefan, Tay Ray Chuan, Git Mailing List,
msysgit
In-Reply-To: <d2e97e800910130443m56ea2850nf72274fc55a4be68@mail.gmail.com>
Michael Wookey <michaelwookey@gmail.com> writes:
> 2009/10/13 Johannes Sixt <j.sixt@viscovery.net>:
>> Michael Wookey schrieb:
>>> Using the above repository, I see the same crash with msysGit at git
>>> revision 1.6.5. Using windbg as the post-mortem debugger, the
>>> following information is captured:
>>> [ ... snip ... ]
>> Wow, this is great work, thank you very much! The function is
>> strip_path_suffix(). And here is a patch that fixes the crash.
>>
>> --- >8 ---
>> From: Johannes Sixt <j6t@kdbg.org>
>> Subject: [PATCH] remote-curl: add missing initialization of argv0_path
>>
>> All programs, in particular also the stand-alone programs (non-builtins)
>> must call git_extract_argv0_path(argv[0]) in order to help builds that
>> derive the installation prefix at runtime, such as the MinGW build.
>> Without this call, the program segfaults (or raises an assertion
>> failure).
>>
>> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
>> ---
>> remote-curl.c | 1 +
>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/remote-curl.c b/remote-curl.c
>> index ad6a163..d8d276a 100644
>> --- a/remote-curl.c
>> +++ b/remote-curl.c
>> @@ -82,6 +82,7 @@ int main(int argc, const char **argv)
>> const char *url;
>> struct walker *walker = NULL;
>>
>> + git_extract_argv0_path(argv[0]);
>> setup_git_directory();
>> if (argc < 2) {
>> fprintf(stderr, "Remote needed\n");
>> --
>> 1.6.5.1024.g31034.dirty
>
> No more crashes for me :)
Beautiful. Thanks, both of you!
^ permalink raw reply
* [msysgit? bug] crlf double-conversion on win32
From: Yann Dirson @ 2009-10-13 20:49 UTC (permalink / raw)
To: git
With a msysgit 1.6.4 package, I got stuck after someone copied a CRLF file
to a Linux box and committed it.
In that situation, the win32 client in autocrlf mode keeps telling that
the files are locally modified, even after eg "git reset --hard". Without
touching the crlf setting (which I believe should not ever be necessary),
this can be corrected by committing the faulty files after dos2unix'ing
them, and using "git fetch && git reset --hard origin/master" ("git pull
--rebase" refuses to do the job since it believes there are local
changes).
^ permalink raw reply
* Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so
From: Junio C Hamano @ 2009-10-13 20:53 UTC (permalink / raw)
To: Daniel Barkalow
Cc: Johannes Sixt, Thomas Rast, Johannes Schindelin, Euguess,
Mikael Magnusson, Matthieu Moy, Jeff King, Jay Soffian, git
In-Reply-To: <alpine.LNX.2.00.0910131358000.32515@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> I suspect that a very common pattern for people who follow trees for
> testing and such or who only develop in topic branches is:
> ...
> << many issues with this kind of DWIM omitted >>
> ...
> On the second cycle, either git refuses or does something actively
> confusing to this user, and the user has to learn the difference between
> local branches and remote branches on the *second* cycle. IMHO, it's much
> better to make users learn things at the point when they don't think they
> know how to use the system, rather than when they think they understand it
> and are just trying to get things done.
Yeah, and I think J6t pointed out the same issue.
I think it tells us something, after some of "the most trusted Git
contributors" thought "really long and hard, and making sure to take
user-friendliness into account at least as much as simplicity of
implementation", they are getting to the same conclusion that this
particular DWIMery is a misguided attempt to be helpful without really
helping but rather hurting the users.
I will stop trying to come up with a strawman for other people's itch that
I do not agree to begin with, at least for now. I will still look at
concrete and workable proposals from other people, though.
^ permalink raw reply
* Re: [RFC PATCH v2 08/16] remote-helpers: Support custom transport options
From: Shawn O. Pearce @ 2009-10-13 20:52 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <alpine.LNX.2.00.0910131550170.32515@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> wrote:
> On Tue, 13 Oct 2009, Shawn O. Pearce wrote:
> > > > +'option thin'::
> > > > + Transfer the data as a thin pack if possible.
> > >
> > > Does anyone still use non-default thinness?
> >
> > Its a command line option on the porcelain.
>
> Actually, the command line supports turning it on, and it defaults to on.
> So I think your helper can safely assume that it's on. :)
For fetch it defaults to "on", but for push I think it defaults
to "off". Turning it on when pushing on a low bandwidth network
connection might actually be useful to an end-user.
--
Shawn.
^ permalink raw reply
* Re: Supressing sorting of trees
From: Ealdwulf Wuffinga @ 2009-10-13 20:49 UTC (permalink / raw)
To: Sal Mangano; +Cc: git
In-Reply-To: <loom.20091012T182258-9@post.gmane.org>
On Mon, Oct 12, 2009 at 5:51 PM, Sal Mangano
<smangano@into-technology.com> wrote:
> 1) I can write by repository from scratch.
> 2) I can use Git unchanged but preserve order by storing some information in
> each sub tree (e.g. an extra blob) which retains the real order. I can also
> store this information once for the whole "chunks" of the repository.
> 3) I can change Git to suite my needs understanding that it is not Git
> anymore.
>
> For me, (1) makes no sense at this time. I started with the hope that (2)
> would work but realized it is very awkward and will cause performance problems
> because it means most updates where ordering matters will have to update the
> Git trees and my private ordering blob(s). So, after a quick look at the
> source code it seemed like hacking Git into what I wanted was easier than 1
> or 2.
You could add a prefix to the names so you get the order you want. Eg:
a-foo
b-bar
c-baz
If you need to move foo to between bar and baz, you just rename it to
ba-foo, etc.
Ealdwulf
^ permalink raw reply
* Re: [RFC PATCH v2 08/16] remote-helpers: Support custom transport options
From: Daniel Barkalow @ 2009-10-13 20:39 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20091013184531.GB9261@spearce.org>
On Tue, 13 Oct 2009, Shawn O. Pearce wrote:
> Daniel Barkalow <barkalow@iabervon.org> wrote:
> > > diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt
> > > +'option' <name>::
> > > + This helper supports the option <name> under fetch-multiple.
> > > +
> >
> > I'm a bit surprised that the options only apply in a fetch-multiple
> > section, rather than getting set at the beginning and applying to
> > everything for that run. At least, I think an "option" command should be
> > useable outside of a fetch-multiple (or possible future grouping
> > construct) and have global scope.
>
> In hindsight, I agree with you.
>
> I'll respin the series so the set_option method in the transport
> forwards the options immediately to the helper and lets the helper
> decide whether it accepts or rejects the option string. This will
> clean up the capabilities interface since we no longer need to dump
> the list of options we support in the helper, and as you point out,
> it will make a lot more sense to just set the options for this
> transport instance.
Great. That also makes the "fetch-multiple" start flag no longer
strictly necessary.
> > > REF LIST ATTRIBUTES
> > > -------------------
> > >
> > > @@ -76,10 +80,26 @@ None are defined yet, but the caller must accept any which are supplied.
> > >
> > > FETCH OPTIONS
> > > -------------
> > > +To enable an option the helper must list it in 'capabilities'.
> > >
> > > 'option verbose'::
> > > Print more verbose activity messages to stderr.
> >
> > I think you mis-split the above part; your previoud patch declared this
> > option without declaring any way to use it. Might be worth allowing
> > multiple "verboses" and "quiet" or "option verbosity quiet"/"option
> > verbosity verbose verbose".
>
> Hmmph. "option verbosity verbose verbose" is a bit verbose, don't
> you think? :-)
>
> I think we should just forward the verbosity setting from the
> frontend: "option verbosity [0-n]" where n is the number of
> times -v appeared on the command line/how verbose the user wants.
I think it can go down to -1. Also, I remember needing to have a "-v"
get eaten by the fetch/pull itself, so that you can have fetch/pull tell
you stuff without having the actual protocol interaction getting more
verbose, so it's not exactly the same numbers that get through.
> > > +'option uploadpack' <command>::
> > > + The program to use on the remote side to generate a pack.
> >
> > I sort of feel like the helper ought to read this one out of the config
> > file itself if it wants it.
>
> Eh, true, but you can also set this on the command line. An open
> question I still have for myself is how to set this in HTTP
> transports.
Good point. I doubt people really want to change the executable name for
the same remote between different runs, though.
> The reason why I care is Gerrit Code Review has overloaded the
> 'git-receive-pack' executable and taught it more command line flags:
>
> $ ssh r git receive-pack -h
> git receive-pack PROJECT.git [--cc EMAIL ...] [--help (-h)] [--reviewer (--re) EMAIL ...]
>
> PROJECT.git : project name
> --cc EMAIL : CC user on change(s)
> --help (-h) : display this help text
> --reviewer (--re) EMAIL : request reviewer for change(s)
>
> Which is typically invoked as:
>
> git push --receive-pack "git-receive-pack --reviewer spearce@spearce.org" URL REFSPEC
It seems to me like what we really want is a channel to communicate extra
information to hooks on the server side (or a modified command on the
server). Like:
git push --recv-opt "--reviewer spearce@spearce.org"
or something like that. This would arrange to pass that option to whatever
server-side code is responsible for accepting pushes, without specifying
how it gets there.
> Folks actually have scripts which make this invocation for them, so
> they can insert in the proper reviewer and/or cc arguments. Since
> the arguments vary its hard to set this up in the configuration file.
>
> Over SSH this is fine, we obtain the arguments off the SSH command
> line string and its no big deal. Over git:// this would fail as
> git-daemon can't parse the line anymore. Over HTTP this also is not
> going to work since the service can't receive arbitrary arguements.
>
> My primary motivator for doing smart HTTP now is folks who are
> stuck behind firewalls that permit only HTTP through their local
> proxy servers are unable to communicate with a Gerrit Code Review
> instance over SSH on port 29418. That --reviewer flag above is a
> very useful feature of Gerrit that I somehow have to support for
> the HTTP transport too.
>
> I started down the road of currying this data into the backend by
> at least exposing the option to the helper. How the helper reads
> and uses it is up to the helper.
>
> But given that the value can come in from the command line or from
> the configuration file, I think this should be handled by fetch
> or push porcelain and fed through the helper protocol, and not be
> something that the helper reads from the config directly.
I agree that the porcelain and transport.c should handle "--reviewer
spearce@spearce.org", but I still think they shouldn't handle the
"git-receive-pack" part, and it would probably be easier on everyone if it
was separated in the porcelain, and the native transport knew to stick it
into the receive-pack command line.
> > In general, it would be good to have
> > transport.c and remote.c out of the business of knowing this sort of
> > protocol-specific (albiet specific now to two protocols) information. (Of
> > course, the native protocol's transport methods are in transport.c, so
> > that's there, but I'd like to move that to a transport-native.c someday.)
>
> Agreed, but I have no solution for you due to the --receive-pack
> and --upload-pack arguments supported by the command line git push
> and git fetch/pull porcelain.
>
> But I have been trying to extend the helper interface in a way
> that would allow us to eject the native transport code entirely
> into a helper. We may never bother, there are some advantages to
> being in the push/fetch client process, but I also didn't want to
> get stuck in a corner.
>
> I think with my series we do almost everything we need to support
> native git:// in an external helper process rather than builtin.
> We honor the pack lock file system used by fetch to maintain safe
> concurrent mutations. We use push_refs API and signal back the
> complete information from the remote side. We permit arbitrary
> message strings per ref to be returned by the helper. Etc.
I think it would be a worthwhile exercise to actually write the series to
eject all of the transports into helpers. Then I think we should probably
make the extensions to the helper code this requires, eject the rsync one,
and put bundles and native in contrib instead of using them.
> > > +'option followtags'::
> > > + Aggressively fetch annotated tags if possible.
> >
> > I assume this means to fetch tags which annotate objects we have or are
> > fetching? (As opposed to fetching any annotated tag we could possibly
> > fetch, even if we don't otherwise care about the tag or the thing it
> > tags.) It's obvious in the context of git's config options, but I'd like
> > this document to avoid assuming that context, and the option could apply
> > more generally.
>
> Yes. I'll extend the documentation further in the next iteration.
>
> > > +'option thin'::
> > > + Transfer the data as a thin pack if possible.
> >
> > Does anyone still use non-default thinness?
>
> Its a command line option on the porcelain. Until we remove
> the command line flag I think we should still try to honor it
> in implementations that understand that notion.
Actually, the command line supports turning it on, and it defaults to on.
So I think your helper can safely assume that it's on. :)
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH v2] bisect reset: Allow resetting to any commit, not just a branch
From: Christian Couder @ 2009-10-13 20:30 UTC (permalink / raw)
To: Anders Kaseorg; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.2.00.0910131605170.5105@dr-wily.mit.edu>
On Tuesday 13 October 2009, Anders Kaseorg wrote:
> On Tue, 13 Oct 2009, Christian Couder wrote:
> > + 1) git rev-parse --quiet --verify "$1^{commit}" > /dev/null ||
> > + die "'$1' does not seem to point to a valid commit"
> >
> > It would give a better error message when "git rev-parse" fails instead
> > of:
> >
> > fatal: Needed a single revision
> >
> > and it would not print the SHA1 from "$1^{commit}" when "git rev-parse"
> > succeeds.
>
> Oh, oops, I somehow lost the > /dev/null in my version.
>
> But as for the ‘git rev-parse’ error being confusing, why don’t we fix
> ‘git rev-parse’ instead?
It's a plumbing command, and the output of plumbing commands is not supposed
to change a lot as some scripts may rely on it.
And anyway that would be in another patch.
Best regards,
Christian.
^ permalink raw reply
* Re: [PATCH v3 3/8] imap-send: use run-command API for tunneling
From: Erik Faye-Lund @ 2009-10-13 20:27 UTC (permalink / raw)
To: Johannes Sixt; +Cc: msysgit, git
In-Reply-To: <200910132159.11616.j6t@kdbg.org>
On Tue, Oct 13, 2009 at 9:59 PM, Johannes Sixt <j6t@kdbg.org> wrote:
> On Dienstag, 13. Oktober 2009, Erik Faye-Lund wrote:
>> + argv[0] = "/bin/sh";
>> + argv[1] = "-c";
>> + argv[2] = srvc->tunnel;
>> + argv[3] = NULL;
>
> Is there a particular reason that you run "/bin/sh" with a path? I doubt that
> this works on Windows.
>
> -- Hannes
>
It doesn't - I was being conservative. Getting tunneling to work on
Windows hasn't been a part of my priorities (even though I did
briefly test it at some point and got it working, provided a patch
that changed the path to sh to a windows-path). Changing it to "sh -c"
(as was suggested earlier) could AFAIK break something for people who
have other 'sh's in path before /bin -- not that I think it would
matter terribly much.
If I were to fix this, I'd prefer not using sh at all on Windows. I've
seen that connect.c doesn't prepend "/bin/sh -c" at all, requiring
tunnels to be self-contained scripts or native binaries, unless I'm
mistaken. I'm not sure if this works at all on Windows, though. I just
think that the assumption that sh is the shell that is going to run
the tunnel is wrong to make, especially on Windows.
I'm really unsure if it's worth the hassle.
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: [RFC/PATCH] gitweb: linkify author/committer names with search
From: Stephen Boyd @ 2009-10-13 20:16 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Jakub Narebski
In-Reply-To: <cb7bb73a0910131241t7220a3c2q16e99a8fc62dd29a@mail.gmail.com>
On Tue, Oct 13, 2009 at 12:41 PM, Giuseppe Bilotta
<giuseppe.bilotta@gmail.com> wrote:
>
> Reproduced, debugged, patch incoming (the problem is not in your patch
> but in esc_param).
>
Thanks. I will test later today. I think a similar problem affects the
branch name labels (the colored boxes with ref names in them) when the
name has utf8 characters.
^ permalink raw reply
* Re: How do I see all of my changes on a branch?
From: Shawn O. Pearce @ 2009-10-13 20:23 UTC (permalink / raw)
To: jonhud; +Cc: git
In-Reply-To: <25879435.post@talk.nabble.com>
jonhud <jon@huddler-inc.com> wrote:
> We are using github (but that's more or less irrelevant, since I'm just
> running git 1.6 locally on Ubuntu). Some time ago, I created a new branch
> (release.2.2) and pushed it out to the remote repository. All the digging
> through log, gitk, etc. has not made it possible for me to figure out the
> commit (or point in time) at which I cut the branch.
git merge-base release2.2 HEAD
Which really lets you do:
git diff $(git merge-base release.2.2 HEAD) HEAD
Which is the long form of:
git diff release-2.2...HEAD
(diff triple dot operator does the merge base computation for you).
--
Shawn.
^ permalink raw reply
* Re: quote in help code example
From: Thomas Rast @ 2009-10-13 20:15 UTC (permalink / raw)
To: Miklos Vajna; +Cc: bill lam, git
In-Reply-To: <20091013153031.GX23777@genesis.frugalware.org>
[-- Attachment #1: Type: Text/Plain, Size: 2721 bytes --]
Miklos Vajna wrote:
> On Tue, Oct 13, 2009 at 10:06:23PM +0800, bill lam <cbill.lam@gmail.com> wrote:
> > 2. now the .ft pair fixed but it still displayed incorrect quote.
> >
> > git filter-branch --tree-filter ´rm filename´ HEAD
> >
> > it should be 'rm filename' not ´rm filename´
>
> I can reproduce that here as well, that's how it is in the official
> manpages as well (see the man branch), so that's not specific to your
> system.
Same here. The patch below is a band-aid fix that works for me, but
I'd rather have it tested on various docbook/asciidoc combinations if
anyone still runs them.
My findings so far were that asciidoc correctly turns the apostrophe
into an ' entity in the .xml output, and xmlto then turns it into
\' instead of just ' in the troff output. Then, if the terminal
appears to support Unicode (this can be disabled with LC_ALL=C or
such) the formatter turns it into a "real" apostrophe that, of course,
is not understood by any ASCII-based tool.
So far so good, and sounded like an easy debugging job, right? Not
so. The buzzword-compliance people apparently felt it would be nice
to wrap a bad joke of a language in the bad joke of a language that
XML already is, and thus was XSL invented. Deep in the horrors of
these XSL files, in my case in
/usr/share/xml/docbook/stylesheet/nwalsh/1.75.2/manpages/other.xsl
there's a template that, according to the comment near it, maltreats
our apostrophes:
* The backslash, dot, dash, and apostrophe (\, ., -, ') characters
* have special meaning for roff, so before we do any other
* processing, we must escape those characters where they appear in
* the source content.
The patch below just replaces said template with a no-op for git's
manpage creation. I have not been able to substantiate the claim that
apostrophes are special, and in fact with the patch my manpages look
fine. Then again I don't know anything about roff syntax either, and
manuals seem a bit hard to come by.
Grrr.
diff --git i/Documentation/manpage-base.xsl w/Documentation/manpage-base.xsl
index a264fa6..7c14469 100644
--- i/Documentation/manpage-base.xsl
+++ w/Documentation/manpage-base.xsl
@@ -7,6 +7,11 @@
<xsl:param name="man.output.quietly" select="1"/>
<xsl:param name="refentry.meta.get.quietly" select="1"/>
+<xsl:template name="escape.apostrophe">
+ <xsl:param name="content"/>
+ <xsl:value-of select="$content"/>
+</xsl:template>
+
<!-- convert asciidoc callouts to man page format;
git.docbook.backslash and git.docbook.dot params
must be supplied by another XSL file or other means -->
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply related
* [PATCH] git-p4: Fixed bug that didn't allow spaces in the depot path [PATCH] git-p4: Fixed bug that didn't allow spaces in the depot path [PATCH] git-p4: Fixed bug that didn't allow spaces in the depot path
From: Per Strandh @ 2009-10-13 20:09 UTC (permalink / raw)
To: git@vger.kernel.org
git-p4 clone (and sync) did not work if the specified depot path contained spaces.
Fixed by quoting the argument to the "p4 changes" and "p4 files" commands.
Signed-off-by: Per Strandh <per.strandh@q-matic.se>
---
contrib/fast-import/git-p4 | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index e710219..01b6bbb 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -440,8 +440,8 @@ def originP4BranchesExist():
def p4ChangesForPaths(depotPaths, changeRange):
assert depotPaths
- output = p4_read_pipe_lines("changes " + ' '.join (["%s...%s" % (p, changeRange)
- for p in depotPaths]))
+ output = p4_read_pipe_lines("changes \"" + ' '.join (["%s...%s" % (p, changeRange)
+ for p in depotPaths]) + "\"" )
changes = {}
for line in output:
@@ -1437,10 +1437,10 @@ class P4Sync(Command):
newestRevision = 0
fileCnt = 0
- for info in p4CmdList("files "
+ for info in p4CmdList("files \""
+ ' '.join(["%s...%s"
% (p, revision)
- for p in self.depotPaths])):
+ for p in self.depotPaths]) + "\""):
if info['code'] == 'error':
sys.stderr.write("p4 returned an error: %s\n"
--
1.6.3.msysgit.0
git-p4 clone (and sync) did not work if the specified depot path contained spaces.
Fixed by quoting the argument to the "p4 changes" and "p4 files" commands.
Signed-off-by: Per Strandh <per.strandh@q-matic.se>
---
contrib/fast-import/git-p4 | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index e710219..01b6bbb 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -440,8 +440,8 @@ def originP4BranchesExist():
def p4ChangesForPaths(depotPaths, changeRange):
assert depotPaths
- output = p4_read_pipe_lines("changes " + ' '.join (["%s...%s" % (p, changeRange)
- for p in depotPaths]))
+ output = p4_read_pipe_lines("changes \"" + ' '.join (["%s...%s" % (p, changeRange)
+ for p in depotPaths]) + "\"" )
changes = {}
for line in output:
@@ -1437,10 +1437,10 @@ class P4Sync(Command):
newestRevision = 0
fileCnt = 0
- for info in p4CmdList("files "
+ for info in p4CmdList("files \""
+ ' '.join(["%s...%s"
% (p, revision)
- for p in self.depotPaths])):
+ for p in self.depotPaths]) + "\""):
if info['code'] == 'error':
sys.stderr.write("p4 returned an error: %s\n"
--
1.6.3.msysgit.0
git-p4 clone (and sync) did not work if the specified depot path contained spaces.
Fixed by quoting the argument to the "p4 changes" and "p4 files" commands.
Signed-off-by: Per Strandh <per.strandh@q-matic.se>
---
contrib/fast-import/git-p4 | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index e710219..01b6bbb 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -440,8 +440,8 @@ def originP4BranchesExist():
def p4ChangesForPaths(depotPaths, changeRange):
assert depotPaths
- output = p4_read_pipe_lines("changes " + ' '.join (["%s...%s" % (p, changeRange)
- for p in depotPaths]))
+ output = p4_read_pipe_lines("changes \"" + ' '.join (["%s...%s" % (p, changeRange)
+ for p in depotPaths]) + "\"" )
changes = {}
for line in output:
@@ -1437,10 +1437,10 @@ class P4Sync(Command):
newestRevision = 0
fileCnt = 0
- for info in p4CmdList("files "
+ for info in p4CmdList("files \""
+ ' '.join(["%s...%s"
% (p, revision)
- for p in self.depotPaths])):
+ for p in self.depotPaths]) + "\""):
if info['code'] == 'error':
sys.stderr.write("p4 returned an error: %s\n"
--
1.6.3.msysgit.0
^ permalink raw reply related
* Re: [PATCH v2] bisect reset: Allow resetting to any commit, not just a branch
From: Anders Kaseorg @ 2009-10-13 20:09 UTC (permalink / raw)
To: Christian Couder; +Cc: Junio C Hamano, git
In-Reply-To: <200910132206.18460.chriscool@tuxfamily.org>
On Tue, 13 Oct 2009, Christian Couder wrote:
> + 1) git rev-parse --quiet --verify "$1^{commit}" > /dev/null ||
> + die "'$1' does not seem to point to a valid commit"
>
> It would give a better error message when "git rev-parse" fails instead of:
>
> fatal: Needed a single revision
>
> and it would not print the SHA1 from "$1^{commit}" when "git rev-parse"
> succeeds.
Oh, oops, I somehow lost the > /dev/null in my version.
But as for the ‘git rev-parse’ error being confusing, why don’t we fix
‘git rev-parse’ instead?
Anders
^ permalink raw reply
* Re: [PATCH v3 5/8] imap-send: build imap-send on Windows
From: Erik Faye-Lund @ 2009-10-13 20:16 UTC (permalink / raw)
To: Johannes Sixt; +Cc: msysgit, git
In-Reply-To: <200910132157.41279.j6t@kdbg.org>
On Tue, Oct 13, 2009 at 9:57 PM, Johannes Sixt <j6t@kdbg.org> wrote:
> On Dienstag, 13. Oktober 2009, Erik Faye-Lund wrote:
>> PROGRAMS += git-unpack-file$X
>> PROGRAMS += git-upload-pack$X
>> PROGRAMS += git-var$X
>> +PROGRAMS += git-imap-send$X
>
> This list is sorted. Please keep it so.
>
> -- Hannes
>
Aha, I didn't notice! Thanks, I'll fix :)
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: [PATCH v2] bisect reset: Allow resetting to any commit, not just a branch
From: Christian Couder @ 2009-10-13 20:06 UTC (permalink / raw)
To: Anders Kaseorg; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.2.00.0910131116300.5105@dr-wily.mit.edu>
On Tuesday 13 October 2009, Anders Kaseorg wrote:
> @@ -311,8 +311,7 @@ bisect_reset() {
> }
> case "$#" in
> 0) branch=$(cat "$GIT_DIR/BISECT_START") ;;
> - 1) git show-ref --verify --quiet -- "refs/heads/$1" ||
> - die "$1 does not seem to be a valid branch"
> + 1) git rev-parse --verify "$1^{commit}" || exit
> branch="$1" ;;
> *)
> usage ;;
I agree with the purpose of the patch but I think something like the
following would be better:
@@ -311,8 +311,8 @@ bisect_reset() {
}
case "$#" in
0) branch=$(cat "$GIT_DIR/BISECT_START") ;;
- 1) git show-ref --verify --quiet -- "refs/heads/$1" ||
- die "$1 does not seem to be a valid branch"
+ 1) git rev-parse --quiet --verify "$1^{commit}" > /dev/null ||
+ die "'$1' does not seem to point to a valid commit"
branch="$1" ;;
*)
usage ;;
It would give a better error message when "git rev-parse" fails instead of:
fatal: Needed a single revision
and it would not print the SHA1 from "$1^{commit}" when "git rev-parse"
succeeds.
Best regards,
Christian.
^ permalink raw reply
* Re: [PATCH v3 3/8] imap-send: use run-command API for tunneling
From: Johannes Sixt @ 2009-10-13 19:59 UTC (permalink / raw)
To: msysgit; +Cc: Erik Faye-Lund, git, Erik Faye-Lund
In-Reply-To: <1255461925-2244-4-git-send-email-kusmabite@gmail.com>
On Dienstag, 13. Oktober 2009, Erik Faye-Lund wrote:
> + argv[0] = "/bin/sh";
> + argv[1] = "-c";
> + argv[2] = srvc->tunnel;
> + argv[3] = NULL;
Is there a particular reason that you run "/bin/sh" with a path? I doubt that
this works on Windows.
-- Hannes
^ permalink raw reply
* [PATCH] gitweb: fix esc_param
From: Giuseppe Bilotta @ 2009-10-13 19:51 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Stephen Boyd, Junio C Hamano, Giuseppe Bilotta
The custom CGI escaping done in esc_param failed to escape UTF-8
properly. Fix by using CGI::escape on each sequence of matched
characters instead of sprintf()ing a custom escaping for each byte.
Additionally, the space -> + escape was being escaped due to greedy
matching on the first substitution. Fix by adding space to the
list of characters not handled on the first substitution.
Finally, remove an unnecessary escaping of the + sign.
---
gitweb/gitweb.perl | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
The issues with this routine were exposed by Stephen's
"author as search link" patch. This should fix them.
Since the idea of esc_param is to replicate CGI::escape except for the /
character (if I read the comment correclty), a possible alternative
would be to just use CGI::escape on the whole string and then undo the
escaping for the / character.
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 6237865..6593e5c 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1115,8 +1115,7 @@ sub to_utf8 {
# correct, but quoted slashes look too horrible in bookmarks
sub esc_param {
my $str = shift;
- $str =~ s/([^A-Za-z0-9\-_.~()\/:@])/sprintf("%%%02X", ord($1))/eg;
- $str =~ s/\+/%2B/g;
+ $str =~ s/([^A-Za-z0-9\-_.~()\/:@ ]+)/CGI::escape($1)/eg;
$str =~ s/ /\+/g;
return $str;
}
--
1.6.3.rc1.192.gdbfcb
^ permalink raw reply related
* Re: [PATCH v3 5/8] imap-send: build imap-send on Windows
From: Johannes Sixt @ 2009-10-13 19:57 UTC (permalink / raw)
To: msysgit; +Cc: Erik Faye-Lund, git, Erik Faye-Lund
In-Reply-To: <1255461925-2244-6-git-send-email-kusmabite@gmail.com>
On Dienstag, 13. Oktober 2009, Erik Faye-Lund wrote:
> PROGRAMS += git-unpack-file$X
> PROGRAMS += git-upload-pack$X
> PROGRAMS += git-var$X
> +PROGRAMS += git-imap-send$X
This list is sorted. Please keep it so.
-- Hannes
^ permalink raw reply
* Re: [RFC/PATCH] gitweb: linkify author/committer names with search
From: Giuseppe Bilotta @ 2009-10-13 19:41 UTC (permalink / raw)
To: Stephen Boyd; +Cc: git, Jakub Narebski
In-Reply-To: <4AD4C94A.9010909@gmail.com>
On Tue, Oct 13, 2009 at 8:39 PM, Stephen Boyd <bebarino@gmail.com> wrote:
> Giuseppe Bilotta wrote:
>> On Monday 12 October 2009 08:19, Stephen Boyd wrote:
>>> The problem is I can't get it to work with UTF-8 characters. I'm not sure
>>> if it's my system or not, so I'm just posting here to see if others
>>> experience the same problem and if there's interest.
>>
>> Does it work if you use CGI::escape() on the author names when filling
>> the searchtext?
>
> This doesn't seem to work. Now I get %25 in front of the escaped
> characters. For example, a space is now %25%20.
>
> Can you reproduce my problem locally?
Reproduced, debugged, patch incoming (the problem is not in your patch
but in esc_param).
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* How do I see all of my changes on a branch?
From: jonhud @ 2009-10-13 19:40 UTC (permalink / raw)
To: git
Hi,
We are using github (but that's more or less irrelevant, since I'm just
running git 1.6 locally on Ubuntu). Some time ago, I created a new branch
(release.2.2) and pushed it out to the remote repository. All the digging
through log, gitk, etc. has not made it possible for me to figure out the
commit (or point in time) at which I cut the branch.
What I want to do is to get a list of files (and/or diffs for those files)
from that point in time to HEAD on the branch. I understand that git-diff
--name-only is part of the solution. What I can't figure out is how to
pinpoint the first commit. So that's my first question... how do I do that?
To complicate things, I was also working on a side branch which I merged to
master before cutting the release.2.2 branch. In the best of all worlds, I
would trace my changes back to the point at which I cut *that* branch and
follow through the HEAD of release.2.2. How do I do that? I know I might
have to take 2 passes, one for release 2.2 and one for the side branch and
that's OK.
Thanks!
Jon
--
View this message in context: http://www.nabble.com/How-do-I-see-all-of-my-changes-on-a-branch--tp25879435p25879435.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* [PATCH v3 0/8] imap-send: Windows support
From: Erik Faye-Lund @ 2009-10-13 19:25 UTC (permalink / raw)
To: git; +Cc: msysgit, Erik Faye-Lund
Here's the 3rd iteration of my patches for
Windows-compatibility in imap-send.
- Patch 1-3 is about getting rid of or rewriting
code with portability issues.
- Patch 4 fixes a compilation error on Windows
- Patch 5 enables compilation of imap-send
- Patch 6-7 enables SSL-suport for mingw
- Patch 8 enables imap-send and SSL for msvc
Changes in this iteration compared to v2 are as
follows:
- A typo has been corrected in the commit message
for 1/8
- some unneeded preprocessor directives has been
deleted from patch 4/8
Thanks to Matt Kraai for reviewing v2
P.S:
Perhaps some people are only on the msysgit mailing
list and wonders where v2 went -- I forgot to CC
you guys last round, sorry about that! If you're
interrested, you can read the discussion here:
http://thread.gmane.org/gmane.comp.version-control.git/129471
Erik Faye-Lund (6):
imap-send: use separate read and write fds
imap-send: use run-command API for tunneling
imap-send: fix compilation-error on Windows
imap-send: build imap-send on Windows
mingw: wrap SSL_set_(w|r)fd to call _get_osfhandle
mingw: enable OpenSSL
Jeff King (1):
imap-send: remove useless uid code
Marius Storm-Olsen (1):
MSVC: Enable OpenSSL, and translate -lcrypto
Makefile | 4 +-
compat/mingw.h | 21 ++++
compat/vcbuild/scripts/clink.pl | 3 +
contrib/buildsystems/engine.pl | 3 +
imap-send.c | 226 +++++++++------------------------------
5 files changed, 77 insertions(+), 180 deletions(-)
^ permalink raw reply
* [PATCH v3 8/8] MSVC: Enable OpenSSL, and translate -lcrypto
From: Erik Faye-Lund @ 2009-10-13 19:25 UTC (permalink / raw)
To: git; +Cc: msysgit, Marius Storm-Olsen, Erik Faye-Lund
In-Reply-To: <1255461925-2244-8-git-send-email-kusmabite@gmail.com>
From: Marius Storm-Olsen <mstormo@gmail.com>
We don't use crypto, but rather require libeay32 and
ssleay32. handle it in both the Makefile msvc linker
script, and the buildsystem generator.
Signed-off-by: Marius Storm-Olsen <mstormo@gmail.com>
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
Makefile | 1 -
compat/vcbuild/scripts/clink.pl | 3 +++
contrib/buildsystems/engine.pl | 3 +++
3 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index e416fdb..b39bed4 100644
--- a/Makefile
+++ b/Makefile
@@ -900,7 +900,6 @@ ifdef MSVC
GIT_VERSION := $(GIT_VERSION).MSVC
pathsep = ;
NO_PREAD = YesPlease
- NO_OPENSSL = YesPlease
NO_LIBGEN_H = YesPlease
NO_SYMLINK_HEAD = YesPlease
NO_IPV6 = YesPlease
diff --git a/compat/vcbuild/scripts/clink.pl b/compat/vcbuild/scripts/clink.pl
index f9528c0..8a2112f 100644
--- a/compat/vcbuild/scripts/clink.pl
+++ b/compat/vcbuild/scripts/clink.pl
@@ -29,6 +29,9 @@ while (@ARGV) {
push(@args, "zlib.lib");
} elsif ("$arg" eq "-liconv") {
push(@args, "iconv.lib");
+ } elsif ("$arg" eq "-lcrypto") {
+ push(@args, "libeay32.lib");
+ push(@args, "ssleay32.lib");
} elsif ("$arg" =~ /^-L/ && "$arg" ne "-LTCG") {
$arg =~ s/^-L/-LIBPATH:/;
push(@args, $arg);
diff --git a/contrib/buildsystems/engine.pl b/contrib/buildsystems/engine.pl
index 20bd061..d506717 100644
--- a/contrib/buildsystems/engine.pl
+++ b/contrib/buildsystems/engine.pl
@@ -315,6 +315,9 @@ sub handleLinkLine
$appout = shift @parts;
} elsif ("$part" eq "-lz") {
push(@libs, "zlib.lib");
+ } elsif ("$part" eq "-lcrypto") {
+ push(@libs, "libeay32.lib");
+ push(@libs, "ssleay32.lib");
} elsif ($part =~ /^-/) {
push(@lflags, $part);
} elsif ($part =~ /\.(a|lib)$/) {
--
1.6.4
^ permalink raw reply related
* [PATCH v3 6/8] mingw: wrap SSL_set_(w|r)fd to call _get_osfhandle
From: Erik Faye-Lund @ 2009-10-13 19:25 UTC (permalink / raw)
To: git; +Cc: msysgit, Erik Faye-Lund
In-Reply-To: <1255461925-2244-6-git-send-email-kusmabite@gmail.com>
SSL_set_fd (and friends) expects a OS file handle on Windows, not
a file descriptor as on UNIX(-ish).
This patch makes the Windows version of SSL_set_fd behave like the
UNIX versions, by calling _get_osfhandle on it's input.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
compat/mingw.h | 21 +++++++++++++++++++++
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/compat/mingw.h b/compat/mingw.h
index 5b5258b..6907345 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -124,6 +124,27 @@ static inline int waitpid(pid_t pid, int *status, unsigned options)
return -1;
}
+#ifndef NO_OPENSSL
+#include <openssl/ssl.h>
+static inline int mingw_SSL_set_fd(SSL *ssl, int fd)
+{
+ return SSL_set_fd(ssl, _get_osfhandle(fd));
+}
+#define SSL_set_fd mingw_SSL_set_fd
+
+static inline int mingw_SSL_set_rfd(SSL *ssl, int fd)
+{
+ return SSL_set_rfd(ssl, _get_osfhandle(fd));
+}
+#define SSL_set_rfd mingw_SSL_set_rfd
+
+static inline int mingw_SSL_set_wfd(SSL *ssl, int fd)
+{
+ return SSL_set_wfd(ssl, _get_osfhandle(fd));
+}
+#define SSL_set_wfd mingw_SSL_set_wfd
+#endif
+
/*
* implementations of missing functions
*/
--
1.6.4
^ permalink raw reply related
* [PATCH v3 7/8] mingw: enable OpenSSL
From: Erik Faye-Lund @ 2009-10-13 19:25 UTC (permalink / raw)
To: git; +Cc: msysgit, Erik Faye-Lund
In-Reply-To: <1255461925-2244-7-git-send-email-kusmabite@gmail.com>
Since we have OpenSSL in msysgit now, enable it to support SSL
encryption for imap-send.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
Makefile | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 3ddb3b3..e416fdb 100644
--- a/Makefile
+++ b/Makefile
@@ -952,7 +952,6 @@ else
ifneq (,$(findstring MINGW,$(uname_S)))
pathsep = ;
NO_PREAD = YesPlease
- NO_OPENSSL = YesPlease
NO_LIBGEN_H = YesPlease
NO_SYMLINK_HEAD = YesPlease
NO_IPV6 = YesPlease
--
1.6.4
^ permalink raw reply related
* [PATCH v3 5/8] imap-send: build imap-send on Windows
From: Erik Faye-Lund @ 2009-10-13 19:25 UTC (permalink / raw)
To: git; +Cc: msysgit, Erik Faye-Lund
In-Reply-To: <1255461925-2244-5-git-send-email-kusmabite@gmail.com>
Since the POSIX-specific tunneling code has been replaced
by the run-command API (and a compile-error has been
cleaned away), we can now enable imap-send on Windows
builds.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index fea237b..3ddb3b3 100644
--- a/Makefile
+++ b/Makefile
@@ -365,6 +365,7 @@ PROGRAMS += git-show-index$X
PROGRAMS += git-unpack-file$X
PROGRAMS += git-upload-pack$X
PROGRAMS += git-var$X
+PROGRAMS += git-imap-send$X
# List built-in command $C whose implementation cmd_$C() is not in
# builtin-$C.o but is linked in as part of some other command.
@@ -1075,7 +1076,6 @@ EXTLIBS += -lz
ifndef NO_POSIX_ONLY_PROGRAMS
PROGRAMS += git-daemon$X
- PROGRAMS += git-imap-send$X
endif
ifndef NO_OPENSSL
OPENSSL_LIBSSL = -lssl
--
1.6.4
^ permalink raw reply related
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