* 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: 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 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: 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] 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: [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
* [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: [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 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: [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
* 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: [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: 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: 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
* 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: [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
* 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: [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
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: 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: 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: [PATCH] get_ref_states: strdup entries and free util in stale list
From: Bert Wesarg @ 2009-12-01 15:53 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:
> On Tue, Dec 1, 2009 at 09:35, Johannes Schindelin
>> Thanks. I trust you ran the test suite with valgrind just to make sure?
> Not the test suite. But my use case where I found the problem (Ie.
> cut-off branch names) which was 'git remote show <remote>'.
> 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.
I need this new suppression to run the test suite:
diff --git i/t/valgrind/default.supp w/t/valgrind/default.supp
index 9e013fa..39b080a 100644
--- i/t/valgrind/default.supp
+++ w/t/valgrind/default.supp
@@ -43,3 +43,10 @@
fun:write_buffer
fun:write_loose_object
}
+
+{
+ writing-data-from-zlib-triggers-even-more-errors-2
+ Memcheck:Param
+ write(buf)
+ obj:*libpthread-*.so
+}
Bert
^ permalink raw reply related
* Re: non-US-ASCII file names (e.g. Hiragana) on Windows
From: Erik Faye-Lund @ 2009-12-01 15:50 UTC (permalink / raw)
To: Thomas Singer; +Cc: Johannes Sixt, git
In-Reply-To: <4B15391C.5090302@syntevo.com>
On Tue, Dec 1, 2009 at 4:41 PM, Thomas Singer <thomas.singer@syntevo.com> wrote:
> Johannes Sixt wrote:
>> Thomas Singer schrieb:
>>> 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.
>>
>> This has been discussed at length here and in the msysgit mailing list.
>> Git expects that the file system returns file names with the same byte
>> sequence that git used to create a file. On Windows, this works only as
>> long as you do not switch the codepage.
>
> Now you confuse me: is this a problem of Windows, Git using a less capable
> Windows-API call or is there no unicode-capable API call to list file names
> on Windows? I ask myself how Java does it in its internals, finally it
> (also) consists of a C-base, I guess.
>
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.
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: non-US-ASCII file names (e.g. Hiragana) on Windows
From: Thomas Singer @ 2009-12-01 15:41 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <4B151782.8050309@viscovery.net>
Johannes Sixt wrote:
> Thomas Singer schrieb:
>> 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.
>
> This has been discussed at length here and in the msysgit mailing list.
> Git expects that the file system returns file names with the same byte
> sequence that git used to create a file. On Windows, this works only as
> long as you do not switch the codepage.
Now you confuse me: is this a problem of Windows, Git using a less capable
Windows-API call or is there no unicode-capable API call to list file names
on Windows? I ask myself how Java does it in its internals, finally it
(also) consists of a C-base, I guess.
--
Tom
^ permalink raw reply
* Re: Umlaut in filename makes troubles
From: Michael J Gruber @ 2009-12-01 14:10 UTC (permalink / raw)
To: Jochen; +Cc: git
In-Reply-To: <hf2pbp$rss$1@ger.gmane.org>
Jochen venit, vidit, dixit 01.12.2009 10:58:
> I found another strange effect...
>
> I made a file with "touch aöäü.txt" and from "git status" I get
> # "a\303\266\303\244\303\274.txt"
> reported as untracked. But when I start "git gui" I get file displayed with
> it's correct name...
>
Does this change after
git config core.quotepath false
Michael
^ 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