* Re: [PATCH/RFC] Allow curl to rewind the RPC read buffer
From: Shawn O. Pearce @ 2009-12-01 16:01 UTC (permalink / raw)
To: Martin Storsj?
Cc: Tay Ray Chuan, git, Nicholas Miell, gsky51, Clemens Buchacher,
Mark Lodato, Johannes Schindelin
In-Reply-To: <alpine.DEB.2.00.0912011232450.5582@cone.home.martin.st>
Martin Storsj? <martin@martin.st> wrote:
> When using multi-pass authentication methods, the curl library may need
> to rewind the read buffers used for providing data to HTTP POST, if data
> has been output before a 401 error is received.
In theory, since the cURL session stays active, we would have
received the 401 authentication error during the initial
"GET $GIT_DIR/info/refs?service=git-$service" request, and the subsequent
"POST $GIT_DIR/git-$service" requests would automatically include the
authentication data.
That's theory. Reality doesn't always agree with my theories. :-)
> remote-curl.c | 30 ++++++++++++++++++++++++++++++
> 1 files changed, 30 insertions(+), 0 deletions(-)
Acked-by: Shawn O. Pearce <spearce@spearce.org>
--
Shawn.
^ permalink raw reply
* Re: Transplant branch from another repository
From: Michael J Gruber @ 2009-12-01 16:07 UTC (permalink / raw)
To: Jeenu V; +Cc: git
In-Reply-To: <5195c8760912010301r63d5e27axf53c17db799a798f@mail.gmail.com>
Jeenu V venit, vidit, dixit 01.12.2009 12:01:
> Hi,
>
> Say, I have two repositories A and B (local, independent, but similar
> - they are for content tracking and not collaboration purposes). A has
> a branch 'a', which I want to have in B. What I mean is that I'd like
> to have the sequence of changes in the branch 'a' to be present in B,
> thus creating an independent branch 'b' in B.
>
> Is there any way to achieve this? One thing that I could think of is
> to use 'format-patch' to generate the list of patch files from A. But
> I don't see how to convert those patches to a sequence of commits in
> repo B. I could do a 'git apply patches/*' but then all patches
> collapse to one single commit. If format-patch is a/the way, could
> somebody tell me how to get this done? Or are there any alternatives?
>
> FWIW: I'm running Git under Cygwin, and sendmail isn't configured.
>From within your B repo:
git fetch pathtoA a:b
Cheers,
Michael
^ permalink raw reply
* Re: [PATCH/RFC] Allow curl to rewind the RPC read buffer
From: Tay Ray Chuan @ 2009-12-01 16:12 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Martin Storsj?, git, Nicholas Miell, gsky51, Clemens Buchacher,
Mark Lodato, Johannes Schindelin
In-Reply-To: <20091201160150.GB21299@spearce.org>
Hi,
On Wed, Dec 2, 2009 at 12:01 AM, Shawn O. Pearce <spearce@spearce.org> wrote:
> In theory, since the cURL session stays active, we would have
> received the 401 authentication error during the initial
> "GET $GIT_DIR/info/refs?service=git-$service" request, and the subsequent
> "POST $GIT_DIR/git-$service" requests would automatically include the
> authentication data.
>
> That's theory. Reality doesn't always agree with my theories. :-)
that's because the curl session where the 401 was received (and thus
successful authentication takes place) is closed.
I sent out a patch series recently which contains a patch to maintain
at least one curl session throughout a http session (from http_init()
to http_cleanup()), you can see this here:
http://www.spinics.net/lists/git/msg118190.html
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: [RFC PATCH 0/8] Git remote helpers to implement smart transports.
From: Sverre Rabbelier @ 2009-12-01 16:12 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git
In-Reply-To: <1259675838-14692-1-git-send-email-ilari.liusvaara@elisanet.fi>
Heya,
On Tue, Dec 1, 2009 at 14:57, Ilari Liusvaara
<ilari.liusvaara@elisanet.fi> wrote:
> This series implements extensions to remote helpers for carrying smary
> transports. It is against next, because master doesn't contain necressary
> patches (the allow specifying remote helper in url one).
Could you please explain how this relates to Shawn's smart http series
and the sr/vcs-helper series?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH/RFC] Allow curl to rewind the RPC read buffer at any time
From: Shawn O. Pearce @ 2009-12-01 16:14 UTC (permalink / raw)
To: Martin Storsj?
Cc: Tay Ray Chuan, git, Nicholas Miell, gsky51, Clemens Buchacher,
Mark Lodato, Johannes Schindelin
In-Reply-To: <alpine.DEB.2.00.0912011236360.5582@cone.home.martin.st>
Martin Storsj? <martin@martin.st> wrote:
> When using multi-pass authentication methods, the curl library may
> need to rewind the read buffers used for providing data to HTTP POST,
> if data has been output before a 401 error is received.
>
> This solution buffers all data read by the curl library, in order to allow
> it to rewind the reading buffer at any time later.
NAK.
In the case of git-upload-pack requests, we should fit into 1 MiB
almost all of the time, and thus not need to grow the http.postBuffer
to support a rewind. The state data plus current have list isn't
all that large. A 1 MiB request means we have over 20,900 commits
in common with the remote and still haven't been able to find a
sufficient cut point. Or the remote has 20,000 active, unrelated
branches we are trying to fetch. Either way, this is a really sick
and twisted situation.
In the case of git-receive-pack requests, we might be uploading an
entire project to an empty repository on the remote side. This could
be 8 GiB worth of data if the project was something huge like KDE.
We can't assume that we should malloc 8 GiB of memory to buffer
the payload.
The *correct* way to support an arbitrary rewind is to modify the
outgoing channel from remote-curl to its protocol engine (client.in
within the rpc_service method) to somehow request the protocol engine
(aka git-send-pack or git-fetch-pack) to stop and regenerate the
current request.
Another approach would be to modify http-backend (and the protocol)
to support an "auth ping" request prior to spooling out the entire
payload if its more than an http.postBuffer size. Basically we
do what the "Expect: 100-continue" protocol is supposed to do,
but in the application layer rather than the HTTP/1.1 layer, so
our CGI actually gets invoked.
This unfortunately still relies on the underlying libcurl to not
discard the authentication data after that initial "auth ping".
But to be honest, I think that is a reasonable expectation. The
#@!*@!* library should be able to generate two requests back-to-back
to the same URL without needing to rewind the 2nd request.
--
Shawn.
^ permalink raw reply
* Re: [PATCH/RFC] Allow curl to rewind the RPC read buffer
From: Shawn O. Pearce @ 2009-12-01 16:16 UTC (permalink / raw)
To: Tay Ray Chuan
Cc: Martin Storsj?, git, Nicholas Miell, gsky51, Clemens Buchacher,
Mark Lodato, Johannes Schindelin
In-Reply-To: <be6fef0d0912010812i54531ce0n18e4615c3f408569@mail.gmail.com>
Tay Ray Chuan <rctay89@gmail.com> wrote:
> On Wed, Dec 2, 2009 at 12:01 AM, Shawn O. Pearce <spearce@spearce.org> wrote:
> > In theory, since the cURL session stays active, we would have
> > received the 401 authentication error during the initial
> > "GET $GIT_DIR/info/refs?service=git-$service" request, and the subsequent
> > "POST $GIT_DIR/git-$service" requests would automatically include the
> > authentication data.
> >
> > That's theory. ?Reality doesn't always agree with my theories. ?:-)
>
> that's because the curl session where the 401 was received (and thus
> successful authentication takes place) is closed.
>
> I sent out a patch series recently which contains a patch to maintain
> at least one curl session throughout a http session (from http_init()
> to http_cleanup()), you can see this here:
>
> http://www.spinics.net/lists/git/msg118190.html
Right, this patch looked sane to me. It didn't touch code I recently
have touched myself, so I didn't bother to ACK, but if it helps,
Acked-by: Shawn O. Pearce <spearce@spearce.org>.
--
Shawn.
^ permalink raw reply
* git-svn: after fetch , move 'remotes/git-svn' commits to be under 'master' ?
From: Michael Norman @ 2009-12-01 16:18 UTC (permalink / raw)
To: git
I don't know if following work-flow makes sense, but here it is:
step 0) clone a (very!) large SVN repository: since --depth=1 doesn't
work for git-svn clone,
pick the revision manually. In this case, I picked the revision one
behind HEAD, so I have
only 2 commits in my working copy:
yellow-dot - master
|
blue-dot - misc. tweak settings
|
blue-dot - bug 295xx - fix
step 1) I then created a few local branches off of master - br1, br2, etc.
Some local commits are created under each branch
Pick up latest_&_greatest revisions from SVN
step 2) git svn fetch (about ~50 commits)
These all identify their branch as 'remotes/git-svn'
It is possible to move the fetched commits to be under 'master'? My
local branch commits
do not overlap (adding new functionality only), so if the new commits
are moved to be under
master, then branches br1 and br2 will inherit those changes - correct?
Any advice would be greatly appreciated - say if for example my work
flow is all wrong and
there is a better way to keep in sync with the remote SVN repository
while still commiting local
work in my working-copy tree
Mike Norman
^ permalink raw reply
* Re: non-US-ASCII file names (e.g. Hiragana) on Windows
From: Shawn O. Pearce @ 2009-12-01 16:26 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Thomas Singer, git
In-Reply-To: <4B14EB2E.9020906@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> wrote:
> Thomas Singer schrieb:
> > To be more precise: Who is interpreting the bytes in the file names as
> > characters? Windows, Git or Java?
>
> In the case of git: Windows does it, using the console's codepage to
> convert between bytes and Unicode.
>
> I don't know about Java, but I guess that no conversion is necessary
> because Java is Unicode-aware.
Actually, conversion is necessary, and its something that is proving
to be really painful within JGit.
The Java IO APIs use UTF-16 for file names. However we are reading
a stream of unknown bytes from the index file and tree objects.
Thus JGit must convert a stream of bytes into UTF-16 just to get
to the OS.
The JVM then turns around and converts from UTF-16 to some other
encoding for the filesystem.
On Win32 I suspect the JVM uses the native UTF-16 file APIs, so
this translation is lossless.
On POSIX, I suspect the JVM uses $LANG or some other related
environment variable to guess the user's preferred encoding, and
then converts from UTF-16 to bytes in that encoding. And I have
no idea how they handle normalization of composed code points.
All of these layers make for a *very* confusing situation for us
within JGit:
git tree
+---------+
| bytes | -+
+---------+ \
\ +--------+ +---------+
+-- JGit --> | UTF-16 | -- JVM --> | OS call |
.git/index / +--------+ +---------+
+---------+ /
| bytes | -+
+---------+
Its impossible for us to do what C git does, which is just use the
bytes used by the OS call within the git datastructure. Which of
course also isn't always portable, e.g. the Mac OS X HFS+ mess.
:-)
--
Shawn.
^ permalink raw reply
* Re: non-US-ASCII file names (e.g. Hiragana) on Windows
From: Thomas Singer @ 2009-12-01 16:33 UTC (permalink / raw)
To: kusmabite; +Cc: Johannes Sixt, git
In-Reply-To: <40aa078e0912010750m4518f068s9c955042307bf9fe@mail.gmail.com>
Erik Faye-Lund wrote:
> Git uses the 8-bit file APIs, and Windows doesn't support setting
> UTF-8 as the locale. Some work have been done in msysGit to use
> _wopen() and friends instead, but AFAIK it's not completed. See the
> branch called "work/utf-filenames" in
> git://repo.or.cz/git/mingw/4msysgit.git if you are interested in
> helping to complete it.
Thanks, now I understand.
--
Tom
^ permalink raw reply
* Re: [PATCH/RFC] Allow curl to rewind the RPC read buffer
From: Martin Storsjö @ 2009-12-01 16:51 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Tay Ray Chuan, git, Nicholas Miell, gsky51, Clemens Buchacher,
Mark Lodato, Johannes Schindelin
In-Reply-To: <20091201160150.GB21299@spearce.org>
On Tue, 1 Dec 2009, Shawn O. Pearce wrote:
> Martin Storsj? <martin@martin.st> wrote:
> > When using multi-pass authentication methods, the curl library may need
> > to rewind the read buffers used for providing data to HTTP POST, if data
> > has been output before a 401 error is received.
>
> In theory, since the cURL session stays active, we would have
> received the 401 authentication error during the initial
> "GET $GIT_DIR/info/refs?service=git-$service" request, and the subsequent
> "POST $GIT_DIR/git-$service" requests would automatically include the
> authentication data.
>
> That's theory. Reality doesn't always agree with my theories. :-)
As Tay said - his "maintain curl sessions" patch should make this
redundant in most cases. But in case request pattern gets changed or if
the curl session for some other reason isn't able to authenticate on the
first try, this is a quite non-intrusive way of ensuring that these
requests can be restarted.
// Martin
^ permalink raw reply
* Re: [RFC PATCH 0/8] Git remote helpers to implement smart transports.
From: Shawn O. Pearce @ 2009-12-01 16:52 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: Sverre Rabbelier, git
In-Reply-To: <fabb9a1e0912010812t4de8027dj1faf828051d1adc2@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> wrote:
> On Tue, Dec 1, 2009 at 14:57, Ilari Liusvaara
> <ilari.liusvaara@elisanet.fi> wrote:
> > This series implements extensions to remote helpers for carrying smary
> > transports. It is against next, because master doesn't contain necressary
> > patches (the allow specifying remote helper in url one).
>
> Could you please explain how this relates to Shawn's smart http series
> and the sr/vcs-helper series?
Or better, why this is even necessary?
I thought git:// over TCP is pretty simple and efficient, and fairly
widely deployed. Smart http(s):// will be in 1.6.6 and available
soon, and isn't all that ugly.
Since the introduction of git:// nobody has asked for another
protocol... other than wanting to make http:// as efficient as
git:// is. Which is now done.
So why do we need this?
The sr/vcs-helper series makes sense if you want to make SVN, Hg,
or P4 remotes act transparently like Git remotes. But that's not
embedding the git:// protocol inside of another protocol, its doing a
full up conversion from a non-Git set of semantics to Git semantics.
--
Shawn.
^ permalink raw reply
* Re: [RFC/PATCH] gitweb: Make linking to actions requiring JavaScript a feature
From: Jakub Narebski @ 2009-12-01 16:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Stephen Boyd, git, Martin Koegler
In-Reply-To: <7v4oob8pap.fsf@alter.siamese.dyndns.org>
On Tue, 1 Dec 2009, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > I had to step back a bit and ask myself what we are trying to achieve
> > here. When the current blame and incremental one are both working
> > perfectly and well, will there be a reason for the end users to choose
> > between them when they click?
> >
> > My answer is no. If the incremental one gives nicer user experience in
> > all cases, it will be shown without the non-incremental one; if the
> > incremental one makes the server or network load too heavy, a site owner
> > may decide to show only the non-incremental one.
> >
> > That makes my addLinks suggestion a change that would help _only_ while we
> > are working kinks out of the incremental one.
> >
> > Let's not waste too much effort doing that. Sorry for suggesting.
> >
> > Letting the site owner choose if the site wants to set the "incremental if
> > possible" boolean would be more than adequate, I think.
>
> Sorry, but I guess I dropped the ball after this message. If I understand
> correctly, the conclusion is that I can apply the patch in this one
>
> From: Jakub Narebski <jnareb@gmail.com>
> Subject: [RFC/PATCH] gitweb: Make linking to actions requiring JavaScript a feature
> Date: Thu, 26 Nov 2009 21:12:15 +0100
> Message-ID: <200911262112.16280.jnareb@gmail.com>
>
> and shipping 1.6.6 with it (perhaps setting 'default' to '[0]' instead)
> would be both reasonably safe and allows easy experimentation by willing
> site owners (or individual gitweb deployment), right?
Yes, I think it is right.
As a followup to this mail I have sent modified version of patch mentioned
above, only with default setting for 'javascript-actions' changed to '[0]'
(disabled), and new patch adding link to 'blame_incremental' action in an
ordinary 'blame' view and vice versa, so even if 'javascript-actions' is
turned off one can experiment with AJAX-y blame.
gitweb/gitweb.perl | 21 +++++++++++++++++++--
1 files changed, 19 insertions(+), 2 deletions(-)
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH 1/2] gitweb: Make linking to actions requiring JavaScript a feature
From: Jakub Narebski @ 2009-12-01 16:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Stephen Boyd, git, Martin Koegler
In-Reply-To: <200912011751.12172.jnareb@gmail.com>
Let gitweb turn some links (like 'blame' links) into linking to
actions which require JavaScript (like 'blame_incremental' action)
only if 'javascript-actions' feature is enabled.
This means that links to such actions would be present only if both
JavaScript is enabled, and 'javascript-actions' feature is enabled.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index a80cbd3..bb2d29c 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -432,6 +432,13 @@ our %feature = (
'timed' => {
'override' => 0,
'default' => [0]},
+
+ # Enable turning some links into links to actions which require
+ # JavaScript to run (like 'blame_incremental'). Disabled by default.
+ # Project specific override is currently not supported.
+ 'javascript-actions' => {
+ 'override' => 0,
+ 'default' => [0]},
);
sub gitweb_get_feature {
@@ -3326,7 +3333,7 @@ sub git_footer_html {
qq!startBlame("!. href(action=>"blame_data", -replay=>1) .qq!",\n!.
qq! "!. href() .qq!");\n!.
qq!</script>\n!;
- } else {
+ } elsif (gitweb_check_feature('javascript-actions')) {
print qq!<script type="text/javascript">\n!.
qq!window.onload = fixLinks;\n!.
qq!</script>\n!;
--
1.6.5.3
^ permalink raw reply related
* Re: [PATCH/RFC] Allow curl to rewind the RPC read buffer at any time
From: Martin Storsjö @ 2009-12-01 16:59 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Tay Ray Chuan, git, Nicholas Miell, gsky51, Clemens Buchacher,
Mark Lodato, Johannes Schindelin
In-Reply-To: <20091201161428.GC21299@spearce.org>
On Tue, 1 Dec 2009, Shawn O. Pearce wrote:
> In the case of git-receive-pack requests, we might be uploading an
> entire project to an empty repository on the remote side. This could
> be 8 GiB worth of data if the project was something huge like KDE.
> We can't assume that we should malloc 8 GiB of memory to buffer
> the payload.
True, fair enough. This was mostly a proof of concept of how this could be
implemented, but with these comments for you, it's clear that this isn't a
feasible solution at all. There's no acute need for it either.
> The *correct* way to support an arbitrary rewind is to modify the
> outgoing channel from remote-curl to its protocol engine (client.in
> within the rpc_service method) to somehow request the protocol engine
> (aka git-send-pack or git-fetch-pack) to stop and regenerate the
> current request.
That's a good idea!
> Another approach would be to modify http-backend (and the protocol)
> to support an "auth ping" request prior to spooling out the entire
> payload if its more than an http.postBuffer size. Basically we
> do what the "Expect: 100-continue" protocol is supposed to do,
> but in the application layer rather than the HTTP/1.1 layer, so
> our CGI actually gets invoked.
That's also quite a good idea, especially if it would be done in a way so
that it's certain that the same curl session will be reused, instead of
getting a potentially new curl session when using get_active_slot().
> This unfortunately still relies on the underlying libcurl to not
> discard the authentication data after that initial "auth ping".
> But to be honest, I think that is a reasonable expectation. The
> #@!*@!* library should be able to generate two requests back-to-back
> to the same URL without needing to rewind the 2nd request.
Yeah, as long as the same curl session is preserved, this should be no
problem.
// Martin
^ permalink raw reply
* [PATCH 2/2] gitweb: Add link to other blame implementation in blame views
From: Jakub Narebski @ 2009-12-01 16:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Stephen Boyd, git, Martin Koegler
In-Reply-To: <200912011751.12172.jnareb@gmail.com>
Add link to 'blame_incremental' action (which requires JavaScript) in
'blame' view, and add link to 'blame' action in 'blame_incremental'
view.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index bb2d29c..ca36761 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -5006,6 +5006,17 @@ sub git_blame_common {
my $formats_nav =
$cgi->a({-href => href(action=>"blob", -replay=>1)},
"blob") .
+ " | ";
+ if ($format eq 'incremental') {
+ $formats_nav .=
+ $cgi->a({-href => href(action=>"blame", javascript=>0, -replay=>1)},
+ "blame") . " (non-incremental)";
+ } else {
+ $formats_nav .=
+ $cgi->a({-href => href(action=>"blame_incremental", -replay=>1)},
+ "blame") . " (incremental)";
+ }
+ $formats_nav .=
" | " .
$cgi->a({-href => href(action=>"history", -replay=>1)},
"history") .
--
1.6.5.3
^ permalink raw reply related
* Re: [RFC PATCH 0/8] Git remote helpers to implement smart transports.
From: Ilari Liusvaara @ 2009-12-01 17:19 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Sverre Rabbelier, git
In-Reply-To: <20091201165245.GF21299@spearce.org>
On Tue, Dec 01, 2009 at 08:52:45AM -0800, Shawn O. Pearce wrote:
> Sverre Rabbelier <srabbelier@gmail.com> wrote:
> > On Tue, Dec 1, 2009 at 14:57, Ilari Liusvaara
> > <ilari.liusvaara@elisanet.fi> wrote:
> > > This series implements extensions to remote helpers for carrying smary
> > > transports. It is against next, because master doesn't contain necressary
> > > patches (the allow specifying remote helper in url one).
> >
> > Could you please explain how this relates to Shawn's smart http series
> > and the sr/vcs-helper series?
Ability to easily implement smart transports with underlying full-duplex
connection. The smart http stuff has loads of code to reimplement smart
transport client side.
> Or better, why this is even necessary?
>
> I thought git:// over TCP is pretty simple and efficient, and fairly
> widely deployed. Smart http(s):// will be in 1.6.6 and available
> soon, and isn't all that ugly.
I consider the authentication parts of smart http pretty ugly. TLS has some
nicer methods, but support for those is nonexistent. Also, I consider piggy-
backing on HTTP when you can have full-duplex connectivity ugly.
> Since the introduction of git:// nobody has asked for another
> protocol... other than wanting to make http:// as efficient as
> git:// is. Which is now done.
Incorrect. I have seen requests for gits:// (and in fact, I have plans to
implement that protocol).
> So why do we need this?
For instance, to support new types of authentication for smart transports
without patching client git binaries (SSH has lots of failure modes that
are quite nasty to debug) or abusing GIT_PROXY (yuck).
If the server can also handle authentication, it has a lot better idea
where things go wrong and can give better errors to logs or to client
(of course, not too much can be leaked to client or it will be too useful
for attack, but that's seperate topic).
> The sr/vcs-helper series makes sense if you want to make SVN, Hg,
> or P4 remotes act transparently like Git remotes. But that's not
> embedding the git:// protocol inside of another protocol, its doing a
> full up conversion from a non-Git set of semantics to Git semantics.
This is not about embedding git:// protol inside another. Its about
carrying the subprotocols. These transports share with git:// as much
as file:// and ssh:// share with git:// (note that service request is
given as command, not inside data pipe).
And IIRC, the only thing this needs from sr/vcs-helper is the patch to
allow selecting helper with URL. The first versions of series did contain
self-standing functionality equivalent to that, but that got dropped as
equivalent functionality appeared in upstream.
-Ilari
^ permalink raw reply
* Re: [PATCH] get_ref_states: strdup entries and free util in stale list
From: Junio C Hamano @ 2009-12-01 17:20 UTC (permalink / raw)
To: Bert Wesarg; +Cc: Johannes Schindelin, Jay Soffian, git
In-Reply-To: <36ca99e90912010132iee0d42fo933aeb12833ad1ad@mail.gmail.com>
Bert Wesarg <bert.wesarg@googlemail.com> writes:
>> - The ref abbrev_branch() is called and the address of whose substring is
>> taken to be used as "name" in handle_one_branch() is refspec.src, but
>> what goes to .util is refname that is refspec.dst---they are different
>> strings and one is not a substring of the other.
> I don't see you point here.
Of course you don't ;-) because we were looking at different versions.
I wanted to apply the same fix to both maint and master. For the code in
'master' your observation is 100% correct.
^ permalink raw reply
* Re: Transplant branch from another repository
From: Dale Farnsworth @ 2009-12-01 16:53 UTC (permalink / raw)
To: jeenuv, git
In-Reply-To: <hf2t2i$l2b$1@xyzzy.farnsworth.org>
> Say, I have two repositories A and B (local, independent, but similar
> - they are for content tracking and not collaboration purposes). A has
> a branch 'a', which I want to have in B. What I mean is that I'd like
> to have the sequence of changes in the branch 'a' to be present in B,
> thus creating an independent branch 'b' in B.
>
> Is there any way to achieve this? One thing that I could think of is
> to use 'format-patch' to generate the list of patch files from A. But
> I don't see how to convert those patches to a sequence of commits in
> repo B. I could do a 'git apply patches/*' but then all patches
> collapse to one single commit. If format-patch is a/the way, could
> somebody tell me how to get this done? Or are there any alternatives?
>
> FWIW: I'm running Git under Cygwin, and sendmail isn't configured.
Try "cd B; git fetch A a:b"
-Dale
Dale Farnsworth
^ permalink raw reply
* Re: [PATCH v2 5/6] run test suite without dashed git-commands in PATH
From: Jakub Narebski @ 2009-12-01 17:24 UTC (permalink / raw)
To: Matthew Ogilvie; +Cc: git, Junio Hamano
In-Reply-To: <1259561971-25730-6-git-send-email-mmogilvi_git@miniinfo.net>
Matthew Ogilvie <mmogilvi_git@miniinfo.net> writes:
> diff --git a/t/README b/t/README
> index 4e1d7dd..8c5d892 100644
> --- a/t/README
> +++ b/t/README
> @@ -75,6 +75,14 @@ appropriately before running "make".
> As the names depend on the tests' file names, it is safe to
> run the tests with this option in parallel.
>
> +--with-dashes::
> + By default tests are run without dashed forms of
> + commands (like git-commit) in the PATH (it only uses
> + wrappers from TOP/git-bin). Use this option to include TOP
> + in the PATH, which conains all the dashed forms of commands.
> + This option is currently implied by other options like --valgrind
> + and GIT_TEST_INSTALLED.
> +
Shouldn't it be 'TOP/bin-wrappers' and not 'TOP/git-bin'?
Shouldn't TOP be explained somewhere, or is it obvious in the context?
s/conains/contains/.
> +else # normal case, use ../bin-wrappers only unless $with_dashes:
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: non-US-ASCII file names (e.g. Hiragana) on Windows
From: Jakub Narebski @ 2009-12-01 17:24 UTC (permalink / raw)
To: Thomas Singer; +Cc: Johannes Sixt, git
In-Reply-To: <4B150747.2030900@syntevo.com>
Thomas Singer <thomas.singer@syntevo.com> writes:
> Johannes Sixt wrote:
>> Thomas Singer schrieb:
>>>
>>> Is it a German Windows limitation, that far-east characters are not
>>> supported on it (but work fine on a Japanese Windows), are there different
>>> (mysys)Git versions available or is this a configuration issue?
>>
>> It is a matter of configuration.
>>
>> Since 8 bits are not sufficient to support Japanese alphabet in addition
>> to the German alphabet, programs that are not Unicode aware -- such as git
>> -- have to make a decision which alphabet they support. The decision is
>> made by picking a "codepage".
>>
>> On German Windows, you are in codepage 850 (in the console). The filenames
>> (that actually are in Unicode) are converted to bytes according to
>> codepage 850 *before* git sees them. If your filenames contain Hiragana,
>> they are substituted by the "unknown character" marker because there is no
>> place for them in codepage 850.
[...]
>> Corollary: Stick to ASCII file names.
>>
>> There have been suggestions to switch the console to codepage 65001
>> (UTF-8), but I have never heard of success reports. I'm not saying it does
>> not work, though.
>
> Thanks for the detailed explanation. I know the differences between bytes
> and characters and the needed *encoding* to convert from one to another, but
> I did not know how Git handles it. I'm quite surprised, that -- as I
> understand you -- msys-Git (or Git at all?) is not able to handle all
> characters (aka unicode) at the same time. I expected it would be better
> than older tools, e.g. SVN.
The problem is not with Git, as Git is (currently) agnostic with
respect to filename encoding; for Git filenames are opaque NUL ('\0)
terminated binary data. There is some infrastructure to convert
between filename encodings and other filename quirks (like
case-insensivity), though...
The problem is with MS Windows *console*, from which you invoke git
commands, and which does translation from filename encoding used by
the filesystem to encoding / codepage used by console.
> BTW, we are invoking the Git executable from Java. Is there automatically a
> console "around" Git? Should we invoke a shell-script (which sets the
> console's code page) instead of the Git executable directly?
If you use Git from Java, why don't you just use JGit (www.jgit.org),
which is Git implementation in Java?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH/RFC] Add a --bouquet option to git rev-list
From: Nathan W. Panike @ 2009-12-01 17:31 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <4B14CF47.5020808@drmicha.warpmail.net>
Hello,
On Tue, Dec 1, 2009 at 2:09 AM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Nathan W. Panike venit, vidit, dixit 30.11.2009 21:55:
>> Add a command line option to rev-list so the command 'git rev-list --bouquet'
>> shows all revisions that are ancestors of refs which share history with HEAD.
>>
>> Signed-off-by: Nathan W. Panike <nathan.panike@gmail.com>
>> ---
>> I have a repository with the following structure:
>>
>> B
>> /
>> A'--A--C
>> \
>> D
>>
>> E'--E
>>
>> Thus the command 'git merge base E A' returns nothing, as there is no common
>> history. The E history contains stuff that is derived from the other history
>> (A, B, C, or D). Often I find myself doing the following:
>
> Either I don't understand the diagram or your term "derived". If
> "derived" means "on some branch of a merge" and E is derived from A, B,
> C, or D, then (since B, C, D is derived from A, and from A') E is
> derived from A', and they will have a merge base.
>
"Derived" in my case means that E is processed from a snapshot of the
tree at, say, A.
> Are these diagrams really disconnected from each other?
Yes. I started the history of E with plumbing using git commit-tree,
without a -p flag specifying a parent
>
>> git checkout C
>> gitk $(include_forks) &
>> <View history, make changes, merges, et cetera>
>> git checkout E
>> <go back to gitk, only see history for B, C, etc>
>>
>> Now the 'include_forks' command is a bash function in my .bashrc:
>>
>> include_forks ()
>> {
>> local head="$(git show -s --pretty=format:'%H' HEAD)";
>> echo "HEAD $(git for-each-ref --format='%(refname)' \
>> refs/heads refs/remotes | while read ref; do \
>> if test "$(git merge-base HEAD ${ref}^{commit})" != ""; \
>> then echo ${ref}; fi; done)"
>> }
>>
>> The shell thus intercepts my command and I must restart gitk to see the history
>> of E.
>>
>> With this patch, I can issue the command 'gitk --bouquet' and when I checkout
>> E, I can 'reload' in gitk and see the history of E automatically.
>
> What would your patch do in the example you gave above? Which refs would
> it cause gitk (rev-list) to show?
>
I wish to be concrete, so let us suppose you use a default clone of
git.git. Further, suppose you are on origin/master.
Then, with my patch,
git rev-list --bouquet
should be an---admittedly less efficient---equivalent to
git rev-list --all --not refs/remotes/origin/html
refs/remotes/origin/man refs/remotes/origin/todo
> Michael
>
Thanks,
Nathan Panike
^ permalink raw reply
* Re: [PATCH/RFC] Allow curl to rewind the RPC read buffer
From: Junio C Hamano @ 2009-12-01 17:49 UTC (permalink / raw)
To: Martin Storsjö
Cc: Tay Ray Chuan, git, Nicholas Miell, gsky51, Clemens Buchacher,
Mark Lodato, Johannes Schindelin
In-Reply-To: <alpine.DEB.2.00.0912011232450.5582@cone.home.martin.st>
Martin Storsjö <martin@martin.st> writes:
> As long as the current rpc read buffer is the first one, we're able to
> rewind without need for additional buffering.
... and if the current buffer isn't the first one, what do we do?
> +#ifndef NO_CURL_IOCTL
> +curlioerr rpc_ioctl(CURL *handle, int cmd, void *clientp)
> +{
> + struct rpc_state *rpc = clientp;
> +
> + switch (cmd) {
> + case CURLIOCMD_NOP:
> + return CURLIOE_OK;
> +
> + case CURLIOCMD_RESTARTREAD:
> + if (rpc->initial_buffer) {
> + rpc->pos = 0;
> + return CURLIOE_OK;
> + }
> + fprintf(stderr, "Unable to rewind rpc post data - try increasing http.postBuffer\n");
> + return CURLIOE_FAILRESTART;
> +
> + default:
> + return CURLIOE_UNKNOWNCMD;
> + }
> +}
> +#endif
What will this result in? A failed request, then the user increases
http.postBuffer, and re-runs the entire command? I am not suggesting the
code should do it differently (e.g. retry with a larger buffer without
having the user to help it). At least not yet. That is why my first
question above was "what do we do?" and not "what should we do?".
I am primarily interested in _documenting_ the expected user experience in
the failure case, so that people can notice the message, run "git grep" to
find the above line and then run "git blame" to find the commit to read
its log message to understand what is going on.
^ permalink raw reply
* Re: multiple working directories for long-running builds (was: "git merge" merges too much!)
From: Greg A. Woods @ 2009-12-01 17:59 UTC (permalink / raw)
To: The Git Mailing List; +Cc: Dmitry Potapov
In-Reply-To: <20091201054734.GB11235@dpotapov.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 2257 bytes --]
At Tue, 1 Dec 2009 08:47:34 +0300, Dmitry Potapov <dpotapov@gmail.com> wrote:
Subject: Re: "git merge" merges too much!
>
> On Mon, Nov 30, 2009 at 07:24:14PM -0500, Greg A. Woods wrote:
> >
> > Things get even weirder if you happen to be playing with older branches
> > too -- most build tools don't have ability to follow files that go back
> > in time as they assume any product files newer than the sources are
> > already up-to-date, no matter how much older the sources might become on
> > a second build.
>
> No, files do not go back in time when you switch between branches. The
> timestamp on files is the time when they are written to your working
> tree
Hmmm, I didn't really say anything in particular about file timestamps
-- I meant the file content may go back in time. More correctly I
should have said that the file content may become inconsistent with the
state of other files that have just been compiled.
If the timestamps do not get set back to commit time, but rather are
simply updated to move the last modify time to the time each change is
made to a working file (which is as you said, to be expected),
regardless of whether its content goes back in time or not, then this
may or may not help a currently running build to figure out what really
needs to be re-compiled. Likely it won't even for a recursive-make
style update build, but certainly not for one where all build actions
are pre-determined before any of them are started.
If the content of one or more files goes back in time to an earlier
state while the compile is happening then ultimately the result must be
considered to be undefined. The best you can hope for is a break in the
compile.
This is why I agreed with you that a build should never be done in a
working directory where any file editing or VCS action is occurring
simultaneously.
I just disagreed that "git archive" was a reasonable alternative to
leaving the working directory alone during the entire time of the build.
It is not really reasonable for large projects any more than stopping
all work on the sources is reasonable.
--
Greg A. Woods
Planix, Inc.
<woods@planix.com> +1 416 218 0099 http://www.planix.com/
[-- Attachment #2: Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Re: [PATCH] get_ref_states: strdup entries and free util in stale list
From: Bert Wesarg @ 2009-12-01 18:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Jay Soffian, git
In-Reply-To: <7v8wdm1ui1.fsf@alter.siamese.dyndns.org>
On Tue, Dec 1, 2009 at 18:20, Junio C Hamano <gitster@pobox.com> wrote:
> Bert Wesarg <bert.wesarg@googlemail.com> writes:
>
>>> - The ref abbrev_branch() is called and the address of whose substring is
>>> taken to be used as "name" in handle_one_branch() is refspec.src, but
>>> what goes to .util is refname that is refspec.dst---they are different
>>> strings and one is not a substring of the other.
>> I don't see you point here.
>
> Of course you don't ;-) because we were looking at different versions.
>
> I wanted to apply the same fix to both maint and master. For the code in
> 'master' your observation is 100% correct.
A quick test with my use case does not show errors in the maint
branch. So it should not be needed (except the memory leak fix of the
.util member). And valgrind confirms this.
Bert
>
^ permalink raw reply
* Re: [PATCH] get_ref_states: strdup entries and free util in stale list
From: Bert Wesarg @ 2009-12-01 18:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Jay Soffian, git
In-Reply-To: <36ca99e90912010105r428a7bfdw63928e8a5515bd1d@mail.gmail.com>
On Tue, Dec 1, 2009 at 10:05, Bert Wesarg <bert.wesarg@googlemail.com> wrote:
> There are still invalid reads of size 4. I think the problem is the
> flex array member of 'struct ref' and strlen(). If its worth I can
> look into this.
A short heads-up, here is the valgrind error I get for this invalid read:
==27305== Invalid read of size 4
==27305== at 0x4936AF: copy_ref (remote.c:870)
==27305== by 0x4942E4: get_fetch_map (remote.c:1271)
==27305== by 0x44473E: get_remote_ref_states (builtin-remote.c:271)
==27305== by 0x446DCE: cmd_remote (builtin-remote.c:1022)
==27305== by 0x4045F0: handle_internal_command (git.c:257)
==27305== by 0x404B8F: main (git.c:482)
==27305== Address 0x5b5ba38 is 104 bytes inside a block of size 107 alloc'd
==27305== at 0x4C24477: calloc (vg_replace_malloc.c:418)
==27305== by 0x4B09AD: xcalloc (wrapper.c:75)
==27305== by 0x493924: alloc_ref_with_prefix (remote.c:853)
==27305== by 0x46653B: get_remote_heads (connect.c:96)
==27305== by 0x4A9347: get_refs_via_connect (transport.c:453)
==27305== by 0x4A7F14: transport_get_remote_refs (transport.c:895)
==27305== by 0x4445B6: get_remote_ref_states (builtin-remote.c:810)
==27305== by 0x446DCE: cmd_remote (builtin-remote.c:1022)
==27305== by 0x4045F0: handle_internal_command (git.c:257)
==27305== by 0x404B8F: main (git.c:482)
^ 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