* Re: What's cooking in git.git (Dec 2009, #01; Tue, 01)
From: Daniel Barkalow @ 2009-12-02 4:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vaay2tkfh.fsf@alter.siamese.dyndns.org>
On Tue, 1 Dec 2009, Junio C Hamano wrote:
> * sr/vcs-helper (2009-11-18) 12 commits
> (merged to 'next' on 2009-11-27 at 83268ab)
> + Add Python support library for remote helpers
> + Basic build infrastructure for Python scripts
> + Allow helpers to report in "list" command that the ref is unchanged
> + Fix various memory leaks in transport-helper.c
> + Allow helper to map private ref names into normal names
> + Add support for "import" helper command
> + Allow specifying the remote helper in the url
> + Add a config option for remotes to specify a foreign vcs
> + Allow fetch to modify refs
> + Use a function to determine whether a remote is valid
> + Allow programs to not depend on remotes having urls
> + Fix memory leak in helper method for disconnect
The bottom one here now needs another hunk that reverts a free of the same
memory (including in cases that this series will need to keep it) that
snuck in unannounced with ef08ef9ea0a271e5be5844408d2496a946d6e8d9.
diff --git a/transport-helper.c b/transport-helper.c
index 5078c71..d729146 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -72,7 +72,6 @@ static int disconnect_helper(struct transport
*transport)
free(data->helper);
data->helper = NULL;
}
- free(data);
return 0;
}
^ permalink raw reply related
* Re: [Cygwin 1.7] git difftool does not work with Windows kdiff3
From: David Aguilar @ 2009-12-02 5:11 UTC (permalink / raw)
To: David Antliff; +Cc: cygwin, git
In-Reply-To: <db95995b0911301445v3b757f75y7f4eaf4abaaa9f80@mail.gmail.com>
I added the git list to the CC: list.
On Tue, Dec 01, 2009 at 11:45:35AM +1300, David Antliff wrote:
>
> git-mergetool works very well with a native Windows (i.e. not Cygwin)
> installation of kdiff3 because it creates its working files in the
> current working directory, usually called
> ./<original-file>.LOCAL.xxxx.<ext> and
> ./<original-file>.REMOTE.xxxx.<ext>. Because these paths are relative
> to the CWD, the non-Cygwin version of kdiff3 handles this fine. E.g:
>
> kdiff3 --auto --L1 build.xml (Base) --L2 build.xml (Local) --L3
> build.xml (Remote) -o build.xml ./build.xml.BASE.5512.xml
> ./build.xml.LOCAL.5512.xml ./build.xml.REMOTE.5512.xml
>
> But git-difftool does something slightly different - it creates the
> temporary versions of the file in /tmp with a random prefix, e.g.
> /tmp/Vc0BZy_<original-file>. This causes the Windows version of kdiff3
> to fail to open the file, because the path "/tmp/...." is invalid. In
> my case, the path that would work is "c:/cygwin-1.7/tmp/..." instead:
>
> kdiff3 --auto --L1 "build.xml (A)" --L2 "build.xml (B)"
> /tmp/Vc0BZy_build.xml build.xml
>
> It's the /tmp/... bit that kdiff3 can't understand. On the other
> hand, this command does work:
>
> kdiff3 --auto --L1 "build.xml (A)" --L2 "build.xml (B)"
> c:/cygwin-1.7/tmp/Vc0BZy_build.xml build.xml
>
>
> Perhaps git-difftool should create the temporary file in CWD just like
> git-mergetool, rather than the Cygwin-specific path /tmp?
>
> I'm using the Windows version of kdiff3 to avoid dependency on the
> graphical X libraries that Cygwin's kdiff3 would require. I think it's
> a fairly common thing to do when working with git on Windows. I can
> see that the Cygwin version of kdiff3 would probably not exhibit this
> problem.
>
> I imagine the same problem will occur with other Windows versions of
> merge/diff tools.
>
> I also understand if there's no intention by the Cygwin git
> maintainer to support non-Cygwin gui merge tools, but I don't think
> I'm the only person using them extensively.
>
> -- David.
git-difftool is built on top of git's GIT_EXTERNAL_DIFF
mechanism. So this problem is not specific to difftool.
I don't have a general solution for you but I do have
a workaround until a better solution manifests itself.
Here's one workaround:
$ TMPDIR=.
$ export TMPDIR
git honors $TMPDIR and that'll make git write files in
the current directory.
Likewise, running `git difftool` should work since the
paths handed off to the difftool should be e.g.
./XXXXXX_build.xml.
That said, I don't know if git dereferences the "." thus
making the workaround invalid. I haven't tested it.
If that doesn't work then there's another alternative.
You could write a simple kdiff3 wrapper script to
translate the cygwin paths into Windows-native paths.
Drop it in the front of $PATH and it'll magically
work. Otherwise, set the difftool.kdiff3.path
configuration variable to the path of the wrapper
script and difftool will use your wrapper without
it being in $PATH.
I hope that helps for now.
An aside:
I've always tested git-difftool on Windows using msysgit.
Windows-native kdiff3 is one of the tools that I've tested
and didn't have any problems using msysgit and native kdiff3
together.
cygwin git and msysgit are very different, of course.
It's likely that msysgit does a lot more magic to
make this possible, but I just wanted to throw that
out there.
If anyone knows of a general solution to this problem
then I'm all ears.
Good luck and let us know how it goes,
--
David
^ permalink raw reply
* Re: [RFC PATCH 0/8] Git remote helpers to implement smart transports.
From: Ilari Liusvaara @ 2009-12-02 5:50 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20091201193009.GM21299@spearce.org>
On Tue, Dec 01, 2009 at 11:30:09AM -0800, Shawn O. Pearce wrote:
> Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote:
> >
> > 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).
>
> So the bulk of this series is about making a proxy for git://
> easier to tie into git?
This is making the "layer 5/6" parts of git:// easier to replace, for whatever
reason that replacement may be desired (and the lower layer is just assumed to
be some kind of full-duplex link).
The part about abusing GIT_PROXY is _very_ nasty hack to be able to layer 6
gateway git smart transports.
The git:// protocol stack is:
- Git smart transport subprotocols (upload-pack, upload-archive and receive-pack)
- git:// (request signaling and data passing)
- TCP/IP (or comparable)
And ssh://:
- Git smart transport subprotocols (upload-pack, upload-archive and receive-pack)
- SSH (request signaling, data passing, encrypt & auth).
- TCP/IP (or comparable)
Smart-HTTP:
- RPC versions of git smart transport subprotocols
- HTTP
- TLS (optional)
- TCP/IP (or comparable)
This is about:
- Git smart transport subprotocols (upload-pack, upload-archive and receive-pack)
- Some prtocol layer(s) (request signaling, data passing, maybe encrypt & auth, etc...)
- TCP/IP (or comparable)
> Forgive me if I sound stupid, but for gits:// shouldn't that just
> be a matter of git_connect() forking a git-remote-gits process
> linked against openssl? Or, maybe it just runs `openssl s_client`?
gits:// was just an example. There can be other interesting stuff (I don't
even pretend my imagination is the limit). And I would rather link the gits://
handler to GnuTLS than OpenSSL, but that's seperate matter...
As for "other interesting stuff": Smart transport using Kerberos auth (just
throwing ideas, probably not going to implement that)?
> Why go through all of this effort of making a really generic proxy
> protocol system when the long-term plan is to just ship native
> gits:// support as part of git-core?
gits:// is not actual goal of this series. Its just something to build on
top of it.
-Ilari
^ permalink raw reply
* Re: [RFC PATCH 6/8] Remove special casing of http, https and ftp
From: Ilari Liusvaara @ 2009-12-02 5:52 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <alpine.LNX.2.00.0912011351220.14365@iabervon.org>
On Tue, Dec 01, 2009 at 02:15:17PM -0500, Daniel Barkalow wrote:
> On Tue, 1 Dec 2009, Ilari Liusvaara wrote:
>
> > HTTP, HTTPS and FTP are no longer special to transport code. Also
> > add support for FTPS (curl supports it so it is easy).
>
> We've been through this extensively, and settled on having a special case
> for URLs that specify a pure location. That is, the distinction between
> http and ftp is at the level of how you get to the content for that
> location, not what you do to interact with it. (Even with webdav or the
> git-specific smart server support, we use the same detection method on all
> locations, and ftp simply never has the possibility of having these
> features detected.)
Currently the only thing about http:// and co git main executable knows is
to pass them to curl remote helper (and print error if compiled with NO_CURL,
possibly causing problems with version desync). Git main executable does
not know any difference between say http:// and ftp:// (the remote helper must
obiviously know the difference, but remote helper is not part of git main
executable).
> It would be fine to add "ftps" to the list of URL schemes that indicate a
> pure location, except that it's plausible that ftps supports writing, but
> obviously not by webdav, which is what the push support via curl will
> attempt, so it's more likely to be confusing than helpful.
remote-curl.c code doesn't seem to do anything stupid with ftps:// that it
wouldn't try with ftp://, and trying to push counts as "stupid" here (and
remember that many FTP servers do allow unencrypted uploads, especially with
authentication and CURL can AFAIK handle that).
-Ilari
^ permalink raw reply
* Re: [RFC PATCH 4/8] Support remote helpers implementing smart transports
From: Ilari Liusvaara @ 2009-12-02 5:55 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20091201192233.GL21299@spearce.org>
On Tue, Dec 01, 2009 at 11:22:33AM -0800, Shawn O. Pearce wrote:
>
> This flies against every other convention we have. git:// uses the
> string 'git-upload-pack' and 'git-receive-pack', and so does the
> smart-http code. We should continue to use the git- prefix here,
> to be consistent, even though by context its clearly implied.
Changed for next round (put the git- -prefixes into names).
> Why 'OK'? Currently remote-helpers return an empty blank line
> to any successful command, not 'OK'.
Changed to "" (i.e. blank line) for next round.
> FALLBACK almost makes sense, but ERROR we don't do in the
> the existing helper protocol. Instead the helper simply
> prints its error message(s) to stderr and does exit(128).
> aka what die() does.
ERROR case changed to exit(128) of helper for next round.
> Why both connect-r and invoke-r? Why isn't connect-r sufficient
> here? Isn't it sufficient for any service that runs over git:// ?
Invoke supports those --upload-pack &co (a'la ssh://). connect
doesn't (a'la to git://).
-Ilari
^ permalink raw reply
* Re: [RFC PATCH 0/8] Git remote helpers to implement smart transports.
From: Ilari Liusvaara @ 2009-12-02 5:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vskbuwhmy.fsf@alter.siamese.dyndns.org>
On Tue, Dec 01, 2009 at 12:42:29PM -0800, Junio C Hamano wrote:
>
> It is somewhat unfortunate that a few changes I liked (e.g. the "debug"
> bit), even though it was somewhat painful to read them due to coding style
> differences, were not at the beginning of the series but instead buried
> after changes that are much bigger and controversial (e.g. [6/8]).
Funny, I considered some other stuff in series much more controversial than
the 6/8 one.
And 6/8 large? Its smallest (source code files only) or second smallest (all
files) in number of line changes in the series.
If one looks at 6/8, what it basically does is:
- Alias remote-curl as remote-{http,ftp}{,s} since the special case dispatch
rules are no more (.gitignore + makefile).
- Remove the special case dispatch rules (transport.c).
Taking diffstat of fixed version of 6/8 (I'll send that later as second round,
possibly with additional fixes):
.gitignore | 4 ++++
Makefile | 19 +++++++++++++++++++
transport.c | 8 --------
3 files changed, 23 insertions(+), 8 deletions(-)
And here's what it does to transport.c:
- } else if (!prefixcmp(url, "http://")
- || !prefixcmp(url, "https://")
- || !prefixcmp(url, "ftp://")) {
- /* These three are just plain special. */
- transport_helper_init(ret, "curl");
-#ifdef NO_CURL
- error("git was compiled without libcurl support.");
-#endif
That's 8 lines killed in transport.c, 4 new binary aliases (yeah, I'm not that
good with makefiles plus this seems to be somewhat nasty case).
-Ilari
^ permalink raw reply
* Re: [PATCH v2 5/6] run test suite without dashed git-commands in PATH
From: Matthew Ogilvie @ 2009-12-02 5:49 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Junio Hamano
In-Reply-To: <m3fx7un7vb.fsf@localhost.localdomain>
On Tue, Dec 01, 2009 at 09:24:46AM -0800, Jakub Narebski wrote:
> Matthew Ogilvie <mmogilvi_git@miniinfo.net> writes:
> > +--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/.
I've appended a incremental patch for these.
Junio, do you want me to re-roll the 3 bin-wrappers patches to
include both this and the "@@ vs __" patch, or do you want
to just add or squash them in from the emails?
--
Matthew Ogilvie [mmogilvi_git@miniinfo.net]
From: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
Date: Tue, 1 Dec 2009 22:16:19 -0700
Subject: [PATCH] t/README: fix spelling in --with-dashes documentation
Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
---
t/README | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/t/README b/t/README
index 8c5d892..dcd3ebb 100644
--- a/t/README
+++ b/t/README
@@ -78,10 +78,11 @@ appropriately before running "make".
--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.
+ wrappers from ../bin-wrappers). Use this option to include
+ the build directory (..) in the PATH, which contains all
+ the dashed forms of commands. This option is currently
+ implied by other options like --valgrind and
+ GIT_TEST_INSTALLED.
You can also set the GIT_TEST_INSTALLED environment variable to
the bindir of an existing git installation to test that installation.
--
1.6.4.GIT
^ permalink raw reply related
* Re: [PATCH v2 5/6] run test suite without dashed git-commands in PATH
From: Junio C Hamano @ 2009-12-02 6:25 UTC (permalink / raw)
To: Matthew Ogilvie; +Cc: Jakub Narebski, git
In-Reply-To: <20091202054956.GA2089@comcast.net>
Matthew Ogilvie <mmogilvi_git@miniinfo.net> writes:
> Junio, do you want me to re-roll the 3 bin-wrappers patches to
> include both this and the "@@ vs __" patch, or do you want
> to just add or squash them in from the emails?
I expect that very soon I will be paying much less attention to topics
that will not be in 1.6.6 (in fact, I maybe am already as of tonight), to
save my mental bandwidth to concentrate more on bugfixes and regressions.
Please re-roll and feed me complete patches for anything that are not in
'next', telling me which ones to drop from 'pu' if I have older versions.
Just FYI, earlier you said to me something like "I see you already queued
this to 'pu', ...", but please be aware that being in 'pu' does not mean
that much---not much more than being in the mailing list archive. They
are fair game for rewriting, replacing and dropping. I merely keep them
on 'pu' so that it would be easier for me and others to look at them than
having to hunt for them in the mailing list archive.
Thanks.
^ permalink raw reply
* Re: [RFC PATCH 0/8] Git remote helpers to implement smart transports.
From: Junio C Hamano @ 2009-12-02 6:35 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: Junio C Hamano, git
In-Reply-To: <20091202055632.GD31244@Knoppix>
Ilari Liusvaara <ilari.liusvaara@elisanet.fi> writes:
> On Tue, Dec 01, 2009 at 12:42:29PM -0800, Junio C Hamano wrote:
>>
>> It is somewhat unfortunate that a few changes I liked (e.g. the "debug"
>> bit), even though it was somewhat painful to read them due to coding style
>> differences, were not at the beginning of the series but instead buried
>> after changes that are much bigger and controversial (e.g. [6/8]).
>
> Funny, I considered some other stuff in series much more controversial than
> the 6/8 one.
I didn't mean the line count by "large". I was referring to the size of
change at the conceptual level. As Daniel already explained, it has been
one of the design assumption so far that there are built-in mappings from
some common <scheme>:// to backend "helpers".
I am _not_ saying that that particular design assumption must be cast in
stone (nothing is)---that is a totally different matter to be debated.
But the fact that it needs to be debated means it is not "a trivial 8-line
reduction", but rather a large conceptual change (perhaps improvement).
^ permalink raw reply
* Re: [StGit PATCH v2 0/6] add support for git send-email
From: Karl Wiberg @ 2009-12-02 6:46 UTC (permalink / raw)
To: Alex Chiang; +Cc: catalin.marinas, git
In-Reply-To: <20091202003503.7737.51579.stgit@bob.kio>
On Wed, Dec 2, 2009 at 1:46 AM, Alex Chiang <achiang@hp.com> wrote:
> I also experimented with adding another test case for --git mode,
> basically duplicating t1900-mail.sh, and then adding the --git
> argument wherever it made sense.
Ah, good.
> However, that resulted in failure of the last 3 test cases, which is
> due to the fact that we no longer parse To/Cc/Bcc command line args
> in --git mode, and the resulting mbox file was missing the expected
> recipient addresses.
>
> I played around with that for a while, thinking that I could use git
> send-email --dry-run to do something equivalent, but then realized
> that git send-email's run-run mode is definitely not analogous to
> stg mail's --mbox mode.
>
> The upshot is that in stg mail, --git and --mbox don't interact
> well, and the resulting mbox file will lack the recipients. This
> might be fixed in the future if we teach git send-email how to
> generate mbox files, but then we introduce a versioning problem.
One wild idea: git send-email's --smtp-server flag will accept the
(full) path of a sendmail program; writing such a program, just
capable enough to receive the outgoing emails and dumping them to a
file, should be easy. Another option would be a program that speaks
just enough SMTP to accept the mails. (Incidentally, these two would
be useful in testing stg mail even without the --git option.)
I fully understand if you'd rather get on with scratching your actual
itch, though ...
> So let's just accept this wart for now, and say, if you want an mbox
> file generated, don't use --git. That seems reasonable to me.
Sure.
--
Karl Wiberg, kha@treskal.com
subrabbit.wordpress.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [StGit PATCH v2 1/6] stg mail: Refactor __send_message and friends
From: Karl Wiberg @ 2009-12-02 6:53 UTC (permalink / raw)
To: Alex Chiang; +Cc: catalin.marinas, git
In-Reply-To: <20091202004605.7737.2077.stgit@bob.kio>
On Wed, Dec 2, 2009 at 1:46 AM, Alex Chiang <achiang@hp.com> wrote:
> + if (smtppassword and not smtpuser):
> + raise Exception('SMTP password supplied, username needed')
> + if (smtpusetls and not smtpuser):
> + raise Exception('SMTP over TLS requested, username needed')
> + if (smtpuser and not smtppassword):
> + smtppassword = getpass.getpass("Please enter SMTP password: ")
Sorry if I confused you with my earlier explanation; I only meant that
you should use the _form_ "raise Exception('message')", not that you
should change the exception type from CmdException to Exception. If
you try to trigger these errors, I think you'll find that in the case
of CmdException, StGit will print just the message and exit with an
error; whereas for straight Exception, it'll print the full backtrace
as well under the assumption that it's a program bug.
--
Karl Wiberg, kha@treskal.com
subrabbit.wordpress.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [StGit PATCH v2 3/6] stg mail: make __send_message do more
From: Karl Wiberg @ 2009-12-02 7:03 UTC (permalink / raw)
To: Alex Chiang; +Cc: catalin.marinas, git
In-Reply-To: <20091202004616.7737.60382.stgit@bob.kio>
Just pointing out a couple of Python tricks you might've wanted to
use. No need to update the patch, though.
On Wed, Dec 2, 2009 at 1:46 AM, Alex Chiang <achiang@hp.com> wrote:
> + (patch_nr, total_nr) = (args[1], args[2])
Can be written as
(patch_nr, total_nr) = args[1:3]
or, if args[2] is the last element of the list (which it isn't in this
case?),
(patch_nr, total_nr) = args[1:]
> + for (p, n) in zip(patches, range(1, total_nr + 1)):
> + msg_id = __send_message('patch', tmpl, options, p, n, total_nr, ref_id)
Can be written as
for (n, p) in enumerate(patches):
if you use n + 1 instead of n in the loop body.
--
Karl Wiberg, kha@treskal.com
subrabbit.wordpress.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [StGit PATCH v2 0/6] add support for git send-email
From: Karl Wiberg @ 2009-12-02 7:08 UTC (permalink / raw)
To: Alex Chiang; +Cc: catalin.marinas, git
In-Reply-To: <20091202003503.7737.51579.stgit@bob.kio>
On Wed, Dec 2, 2009 at 1:46 AM, Alex Chiang <achiang@hp.com> wrote:
> This is v2 of the series that starts teaching stg mail how to
> call git send-email.
Acked-by: Karl Wiberg <kha@treskal.com>
when the CmdException/Exception thing is fixed in the first patch.
--
Karl Wiberg, kha@treskal.com
subrabbit.wordpress.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH v2] Add --track option to git clone
From: David Soria Parra @ 2009-12-02 7:20 UTC (permalink / raw)
To: git
In-Reply-To: <BLU0-SMTP487572F057CC9D30C837D7AE950@phx.gbl>
On 2009-12-02, Sean Estabrooks <seanlkml@sympatico.ca> wrote:
>> It tries to make the following usecase possible:
>> Imagine you are working on a project that has 1.x and a 2.x branch. The project
>> itself requires a complex setup (webserver, configuration files, etc). Setting up
>> 1.x and 2.x branch requires a lot of work, but a developer needs to maintain both.
>> He'll use the --track option to clone the 2.x branch into a directory and does the same
>> with the 1.x branch, where he setup the project. He can use locally separate repositories
>> while still being able to push to just one remote repository.
>
> This is already straightforward in Git without the limitation of tracking only
> a single remote branch. What is the necessity of doing this via the clone command?
>
> $ git init myrepo
> $ cd myrepo
> $ git remote add -t branch1.x -f origin <URL>
> $ git checkout -t origin/branch1.x
I'm aware that this is possible, but I want to have a shortcut for this as the users that I
helped with getting into git usually where confused about the point that you have to do it manually
via git init, so take the patch as a proposal to get more consistent interface for git clone.
david
^ permalink raw reply
* How to include full commit logs in git merge message?
From: Wenguang Wang @ 2009-12-02 7:30 UTC (permalink / raw)
To: git
Hi,
When I merge a branch, say myfix, to master,
I would like to let the merge log message contain
all commit messages I had for the branch I am
merging. However, the "git merge --log" only
populates one-line descriptions of the commits.
Is there any simple way to populate the full
merge messages into the log message of the
merge commit?
Thanks!
-Wenguang
^ permalink raw reply
* [PATCH] transport-helper: remove duplicate free()
From: Tay Ray Chuan @ 2009-12-02 7:39 UTC (permalink / raw)
To: git; +Cc: Daniel Barkalow, Sverre Rabbelier, Junio C Hamano
Remove the free() invocation on transport->data in release_helper(), as
disconnect_helper() has already done so.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
Applies on top of 'next'.
transport-helper.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/transport-helper.c b/transport-helper.c
index 9c5f860..2f77bd5 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -196,7 +196,6 @@ static int release_helper(struct transport *transport)
free_refspec(data->refspec_nr, data->refspecs);
data->refspecs = NULL;
disconnect_helper(transport);
- free(transport->data);
return 0;
}
--
1.6.6.rc0.306.g5bb1c0
^ permalink raw reply related
* Git GUI client SmartGit released
From: Marc Strapetz @ 2009-12-02 7:45 UTC (permalink / raw)
To: git
We are proud to announce the general availability of our Git client
SmartGit[1]:
http://www.syntevo.com/smartgit/index.html
Thank you, Git community, for the great DVCS you are building and the
feed-back to SmartGit!
--
Best regards,
Marc Strapetz
=============
syntevo GmbH
http://www.syntevo.com
http://blog.syntevo.com
[1] Please don't be offended by the name, it has historical roots. ;)
^ permalink raw reply
* Re: [PATCH/RFC] Allow curl to rewind the RPC read buffer
From: Martin Storsjö @ 2009-12-02 7:45 UTC (permalink / raw)
To: Tay Ray Chuan
Cc: Junio C Hamano, git, Nicholas Miell, gsky51, Clemens Buchacher,
Mark Lodato, Johannes Schindelin
In-Reply-To: <be6fef0d0912011832k12eaa093o73b057ddf4ab866@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2715 bytes --]
On Wed, 2 Dec 2009, Tay Ray Chuan wrote:
> > 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 guess that by "we" you're referring to the "normal" users of git?
>
> > 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.
>
> Yes, the code will just fail. As you might suspect, the code won't
> attempt to mitigate the failure by doing anything, and would require
> intervention on the part of the user.
>
> What the user could do to make this work:
>
> 1. Turn off multi-pass authentication and just go with Basic.
>
> 2. Allow for persistent curl sessions. In theory, we get a 401 the
> first time when we send a GET for info/refs; subsequently, curl knows
> what authentication to use, so the POST request *should* take place
> without the need for rewinding. In theory.
I'd actually put this as number 1 - if this error message pops up for some
reason, the first thing would be to find out why reusing the previous curl
sessions didn't work.
Other options are:
- Switch to a HTTP server that handles Expect: 100-continue properly
- Try pushing the data in smaller chunks, e.g. if populating a new repo
from scratch, don't push the whole history in one single run, or populate
through some other mechanism and just do the incremental pushs over HTTP.
And possibly: Update curl to a version post 7.19.7, which detects the
Expect header set by git and tries to await a response from the server
before proceeding. (The problem that would solve is if we start sending
and manage to send the whole initial 1 MB buffer before the 401 reply from
the server is received. But it doesn't solve the case if the server
doesn't understand the Expect header at all.)
> 3. Increase http.postBuffer size in the config.
As Shawn pointed out, if the whole request would have to be buffered, the
needed size may be prohibitively large, so I guess this isn't a good hint
to include in the error message after all. But if the request is sensibly
sized (e.g. on the order of tens of MBs), this may be a stopgap solution.
So, should we change the error message to something a bit more
descriptive, and add this discussion into the commit message?
// Martin
^ permalink raw reply
* Re: [PATCH/RFC] Allow curl to rewind the RPC read buffer at any time
From: Daniel Stenberg @ 2009-12-02 9:19 UTC (permalink / raw)
To: Tay Ray Chuan
Cc: Shawn O. Pearce, Martin Storsj?, git, Nicholas Miell, gsky51,
Clemens Buchacher, Mark Lodato, Johannes Schindelin
In-Reply-To: <be6fef0d0912011803u2ec9ab1bsa167cf59de4dd47c@mail.gmail.com>
On Wed, 2 Dec 2009, Tay Ray Chuan wrote:
> According to Martin, Expect: 100-continue is not working due to libcurl.
Right, that is/was a bug in how libcurl behaves when the application itself
has set the "Expect: 100-continue" header. Martin has provided a fix for that
for the next libcurl version though, but that won't make a lot of existing
users happy.
Thinking about this particular problem, what is the motivation for git to
forcily add that header in the first place? I mean, libcurl does add the
header by itself when it thinks it is necessary and then it handles it
correctly.
I'm just suggesting (and speculating widely since I don't know git internals)
that a possible way to work around this particular bug may be to reconsider
how git adds the Expect header.
It's just an idea. Please ignore it if it is totally crazy.
--
/ daniel.haxx.se
^ permalink raw reply
* choosing an issue tracker
From: Rakotomandimby Mihamina @ 2009-12-02 9:27 UTC (permalink / raw)
To: git
Hi all,
For a while, I used SVN and Trac.
They have a satisfying mutual integration.
I am looking for our new issue tracker, and would like to be advised.
Our context:
- developpers using git, developping
- web based applications (PHP, Python, OCaml,...)
- Unix-like system maintainance scripts (SHELL, Perl,...)
- a QA guy that makes functional tests only on the web applications
and reports bugs and potential improvements. He does not use git.
- multiple projects
What we look for:
something like the (Trac, SVN) but with git as SCM.
What issue tracker would you recommend?
--
Architecte Informatique chez Blueline/Gulfsat:
Administration Systeme, Recherche & Developpement
+261 33 11 207 36
^ permalink raw reply
* Marking commits as transitory for git bisect?
From: David Kastrup @ 2009-12-02 9:32 UTC (permalink / raw)
To: git
Hi,
sometimes there are changes which would seem better to restructure into
more than one commit, with a non-operative intermediate state.
What I am thinking of is something like
a) change an API (small but highly intricate patch warranting thorough
line-by-line review to make sure it's fine)
b) adapt all existing callers (really large but utterly trivial patch)
Substructuring this change into two commits may be quite nicer for
reviewing and following it.
Except that it breaks git bisect. If there was a way to mark a commit
as non-interesting, something which does not necessarily need any new
repo features but just a convention like automatically skipping commits
that contain the literal string [skip bisect] in the commit message,
that would be one way to implement basic functionality like that.
A more thorough approach might also warn against partial cherrypicks or
rebases or merges applying just part of one such a combined change.
But the main point is the ability to keep git bisect working on commit
combinations with deliberately non-operative transitory stage.
--
David Kastrup
^ permalink raw reply
* Re: [PATCH/RFC] Allow curl to rewind the RPC read buffer at any time
From: Martin Storsjö @ 2009-12-02 9:32 UTC (permalink / raw)
To: Daniel Stenberg
Cc: Tay Ray Chuan, Shawn O. Pearce, git, Nicholas Miell, gsky51,
Clemens Buchacher, Mark Lodato, Johannes Schindelin
In-Reply-To: <alpine.DEB.2.00.0912021011430.19179@tvnag.unkk.fr>
On Wed, 2 Dec 2009, Daniel Stenberg wrote:
> On Wed, 2 Dec 2009, Tay Ray Chuan wrote:
>
> > According to Martin, Expect: 100-continue is not working due to libcurl.
>
> Right, that is/was a bug in how libcurl behaves when the application itself
> has set the "Expect: 100-continue" header. Martin has provided a fix for that
> for the next libcurl version though, but that won't make a lot of existing
> users happy.
>
> Thinking about this particular problem, what is the motivation for git to
> forcily add that header in the first place? I mean, libcurl does add the
> header by itself when it thinks it is necessary and then it handles it
> correctly.
As far as I saw, the reason for it being manually added is that curl
actually didn't add it automatically in that case. That was the reason for
the second patch/rfc thread that I sent to curl-library (where postsize ==
0, as in unknown, didn't trigger the addition of any Expect header).
// Martin
^ permalink raw reply
* Re: choosing an issue tracker
From: Matthieu Moy @ 2009-12-02 9:40 UTC (permalink / raw)
To: Rakotomandimby Mihamina; +Cc: git
In-Reply-To: <4B16331A.3060606@gulfsat.mg>
Rakotomandimby Mihamina <mihamina@gulfsat.mg> writes:
> What we look for:
> something like the (Trac, SVN) but with git as SCM.
>
> What issue tracker would you recommend?
I couldn't recomand one, but the among the ones to look at:
InDefero (clone of google code)
trac+git (I've been told it wasn't as good as trac+svn, but it exists)
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH] git-pull.sh: Fix call to git-merge for new command format
From: Michael J Gruber @ 2009-12-02 10:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Horst H. von Brand, git
In-Reply-To: <7vmy22qmgp.fsf@alter.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 02.12.2009 00:54:
> "Horst H. von Brand" <vonbrand@inf.utfsm.cl> writes:
>
>> Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl>
>> ---
>> git-pull.sh | 4 ++--
>> 1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/git-pull.sh b/git-pull.sh
>> index bfeb4a0..a875809 100755
>> --- a/git-pull.sh
>> +++ b/git-pull.sh
>> @@ -218,5 +218,5 @@ merge_name=$(git fmt-merge-msg $log_arg <"$GIT_DIR/FETCH_HEAD") || exit
>> test true = "$rebase" &&
>> exec git-rebase $diffstat $strategy_args --onto $merge_head \
>> ${oldremoteref:-$merge_head}
>> -exec git-merge $diffstat $no_commit $squash $no_ff $ff_only $log_arg $strategy_args \
>> - "$merge_name" HEAD $merge_head $verbosity
>> +exec git-merge $verbosity -m $diffstat $no_commit $squash $no_ff $ff_only $log_arg $strategy_args \
>> + "$merge_name" $merge_head
>> --
>> 1.6.6.rc0.114.gc8648
>
> Heh, embarrasing.
>
> But I think you wanted to have -m immediately before "$merge_name", no?
This made me wonder a bit: Do we have a policy regarding the use of
"git-command" vs. "git command" in git shell scripts such as this one?
Of course, having been called through git, the dashed versions are in
the PATH. But I see a mix here ("git fmt-merge-msg" vs. "git-merge") and
in other scripts, which may potentially (in broken setups) lead to parts
of git from different installs being called. I would think the dashed
form is even more efficient (fewer lookups)?
Michael
^ permalink raw reply
* Re: [PATCH/RFC] Allow curl to rewind the RPC read buffer at any time
From: Daniel Stenberg @ 2009-12-02 10:04 UTC (permalink / raw)
To: Martin Storsjö
Cc: Tay Ray Chuan, Shawn O. Pearce, git, Nicholas Miell, gsky51,
Clemens Buchacher, Mark Lodato, Johannes Schindelin
In-Reply-To: <alpine.DEB.2.00.0912021130300.5582@cone.home.martin.st>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 692 bytes --]
On Wed, 2 Dec 2009, Martin Storsjö wrote:
>> Thinking about this particular problem, what is the motivation for git to
>> forcily add that header in the first place? I mean, libcurl does add the
>> header by itself when it thinks it is necessary and then it handles it
>> correctly.
>
> As far as I saw, the reason for it being manually added is that curl
> actually didn't add it automatically in that case. That was the reason for
> the second patch/rfc thread that I sent to curl-library (where postsize ==
> 0, as in unknown, didn't trigger the addition of any Expect header).
Ah right, thanks for the clarification. An unfortunate combination then... :-(
--
/ daniel.haxx.se
^ 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