* Re: [PATCH RFC] rebase: add --revisions flag
From: Christian Couder @ 2009-12-09 5:30 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Junio C Hamano, Stephan Beyer, Christian Couder, Daniel Barkalow,
Git List, Johannes Schindelin
In-Reply-To: <fabb9a1e0912081229l7990a148j9cd2daa338662dd@mail.gmail.com>
Hi,
On mardi 08 décembre 2009, Sverre Rabbelier wrote:
> Heya,
>
> On Tue, Dec 8, 2009 at 21:22, Junio C Hamano <gitster@pobox.com> wrote:
> > But I think it is a reasonable thing to _implement_ the feature to
> > range-pick commits reusing the sequencing logic already in "rebase" and
> > "rebase -i". That essentially is what we wanted to do with "git
> > sequencer" that would be a sequencing logic backend shared among
> > rebase, cherry-pick, and perhaps am.
>
> Speaking of which, what's the status of git sequencer? I seem to
> remember some activity recently to slowly rewrite git rebase in c, but
> I haven't seen anything since then. Is it still moving forward? Is
> anyone interested in doing so? Just curious...
Last June and July, I sent some patch series to port "rebase -i" to C using
code from the sequencer project. My goal was to save some interesting code
from the sequencer GSoC 2008 project and at the same time to move
forward "rebase -i" code toward a sequencer.
But Dscho and Junio didn't like the fact that the code from the sequencer I
added was duplicating existing code and was not properly refactored, though
it also added things that would be needed later for the sequencer. My plan
was to refactor later, once I had a sequencer, but Junio and Dscho did not
like that plan. They said it would be a too big maintenance burden.
So I agreed to not duplicate any existing code and to properly refactor
everything. And I have been trying to take interesting and useful code from
the sequencer project and to integrate it into existing commands. And this
is why I sent yesterday the 4th version of my '"git reset --merge" related
improvements' patch series.
Best regards,
Christian.
^ permalink raw reply
* error: git-svn died of signal 13
From: Jonathan Nieder @ 2009-12-09 5:36 UTC (permalink / raw)
To: git; +Cc: Eric Wong
Hi,
Just wanted to pass on a few reports about git-svn dying with SIGPIPE
when trying to fetch large repositories. It seems to fetch a few
revisions, then die; the repositories can eventually be fetched
successfully by restarting 'git svn fetch' again and again.
Some bug reporters have been very patient, but I don’t really know
where to look or ask in solving this. Attempts at tracing so far have
given either too little or too much information to make any sense.
The problem goes back at least to v1.5.6.5.
At the end of the git-svn process’s life, the last few function calls
are these:
- SVN::Ra::Reporter::finish_report and related functions
- _p_apr_pool_t::DESTROY (libsvn-perl cleaning up, presumably)
- SVN::Ra::Callbacks::open_tmp_file, called from
SVN::_Ra::svn_ra_do_update, called from
Git::SVN::Ra::do_update, called from
Git::SVN::Ra::gs_do_update
- Git::SVN::_set_repos_root
- starting a 'git update-index -z --index-info' to feed commands to
Maybe /tmp is filling up? It is hard to know, since the SIGPIPE stops
everything and we do not get any nice, simple error message describing
what read or write would have received EPIPE.
See <http://bugs.debian.org/526989>, <http://bugs.debian.org/540150>,
<http://thread.gmane.org/gmane.comp.version-control.git/85868/>.
Any insights?
Jonathan
^ permalink raw reply
* Re: [PATCH RFC] rebase: add --revisions flag
From: Miles Bader @ 2009-12-09 4:51 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Björn Steinbrink, git, Junio C Hamano
In-Reply-To: <20091208164449.GA32204@redhat.com>
"Michael S. Tsirkin" <mst@redhat.com> writes:
> OTOH, rebase --revisions as I implemented is a "smarter cherry-pick" which
> can't easily be achieved with existing commands, especially if you add
> "-i".
It also allows making use of rebase's rather extensive machinery for
dealing with conflicts (e.g., rebase --continue / --skip / --abort).
But it would make more sense to have it in cherry-pick...
(cherry-pick --continue / --skip / --abort...)
-Miles
--
Consult, v.i. To seek another's disapproval of a course already decided on.
^ permalink raw reply
* Re: [PATCH 2/2] git-svn: Move setting of svn.authorsfile in clone to between init and fetch
From: Eric Wong @ 2009-12-09 4:44 UTC (permalink / raw)
To: Junio C Hamano, Alex Vandiver; +Cc: git
In-Reply-To: <1260305651-11111-2-git-send-email-alex@chmrr.net>
Alex Vandiver <alex@chmrr.net> wrote:
> If a clone errors out because of a missing author, or user interrupt,
> this allows `git svn fetch` to resume seamlessly, rather than forcing
> the user to re-provide the path to the authors file.
Thanks Alex,
I shortened the subject on this one, acked the series and pushed to
git://git.bogomips.org/git-svn
Alex Vandiver (2):
git-svn: Set svn.authorsfile to an absolute path when cloning
git-svn: set svn.authorsfile earlier when cloning
--
Eric Wong
^ permalink raw reply
* Re: [PATCH 0/3] Add a "fix" command to "rebase --interactive"
From: Aaron Cohen @ 2009-12-09 4:41 UTC (permalink / raw)
To: Nanako Shiraishi
Cc: Sverre Rabbelier, Jeff King, Junio C Hamano, Johannes Schindelin,
Matthieu Moy, Michael J Gruber, Michael Haggerty, git
In-Reply-To: <20091209125555.6117@nanako3.lavabit.com>
On Tue, Dec 8, 2009 at 10:55 PM, Nanako Shiraishi <nanako3@lavabit.com> wrote:
> Quoting Sverre Rabbelier <srabbelier@gmail.com>
>
>> Heya,
>>
>> On Tue, Dec 8, 2009 at 10:35, Jeff King <peff@peff.net> wrote:
>>> $ bash
>>> $ echo "!fixup commit"
>>> bash: !fixup: event not found
>>> $ echo "fixup! commit"
>>> fixup! commit
>>
>> Speaking of which, must we use that annoying bang? I hate how bash
>> gets in my way when I try to write a commit message with a a bang in
>> it, I'd much rather use a different character that is not in risk of
>> being mistreated by my shell. (Although it seems that bash does do TRT
>> in the 'fixup!' case.)
>>
>> --
>> Cheers,
>>
>> Sverre Rabbelier
>
> There was a strong objection (I think from Johanes) against not
> using 'unusual' letters during the initial round back in June
> 2009. Even when explicitly giving '--auto-squash' from the
> command line, there can be commits with confusing titles
> like "fixup the ancient bug in cat-file" in addition to
> the ones you wanted to mark with the "fixup!" marker.
>
> --
I'm sorry to pipe in with my perhaps half-baked idea from lurkerdom,
but would autosquash make more sense designed as a hook rather than as
a special case behavior of git-rebase?
I think this feature could be implemented by having git-rebase call a
hook if supplied the --autosquash command. The hook script would be
supplied with the id of the blobs being fixed up on standard input,
and it could do whatever it wanted internally (including looking for
magic !commands in the commit messages of the blobs).
The result of the script should be the list of blobs to be commited as
a result of the script's munging, on standard output.
^ permalink raw reply
* Re: Weird message when pulling git version 1.6.6.rc1.39.g9a42
From: Nanako Shiraishi @ 2009-12-09 3:55 UTC (permalink / raw)
To: Junio C Hamano
Cc: Alejandro Riveira, git, Horst H. von Brand, Nanako Shiraishi
In-Reply-To: <7vmy1t6nye.fsf@alter.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>
> Alejandro Riveira <ariveira@gmail.com> writes:
>
>> $ git pull
>> remote: Counting objects: 9, done.
>> remote: Compressing objects: 100% (5/5), done.
>> remote: Total 5 (delta 4), reused 0 (delta 0)
>> Unpacking objects: 100% (5/5), done.
>> From git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
>> 6035ccd..a252e74 master -> origin/master
>> Updating 6035ccd..a252e74
>> Fast-forward (no commit created; -m option ignored) # what is this ??
>> net/sctp/sysctl.c | 1 -
>> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> Thanks for reporting.
>
> Warning about a message that the end user didn't give the command is
> clearly wrong. I guess we would want to revert c0ecb07 (git-pull.sh: Fix
> call to git-merge for new command format, 2009-12-01), and b81e00a
> (git-merge: a deprecation notice of the ancient command line syntax,
> 2009-11-30).
>
> Reverting them will still keep 76bf488 (Do not misidentify "git merge foo
> HEAD" as an old-style invocation, 2009-12-02) that resulted in the change
> we are reverting here, so we are still ahead ;-)
>
> http://thread.gmane.org/gmane.comp.version-control.git/134103/focus=134145
Sorry for causing too much trouble. I feel bad.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCH 0/3] Add a "fix" command to "rebase --interactive"
From: Nanako Shiraishi @ 2009-12-09 3:55 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Jeff King, Junio C Hamano, Nanako Shiraishi, Johannes Schindelin,
Matthieu Moy, Michael J Gruber, Michael Haggerty, git
In-Reply-To: <fabb9a1e0912080551s32295cfahf05bdc715360360@mail.gmail.com>
Quoting Sverre Rabbelier <srabbelier@gmail.com>
> Heya,
>
> On Tue, Dec 8, 2009 at 10:35, Jeff King <peff@peff.net> wrote:
>> $ bash
>> $ echo "!fixup commit"
>> bash: !fixup: event not found
>> $ echo "fixup! commit"
>> fixup! commit
>
> Speaking of which, must we use that annoying bang? I hate how bash
> gets in my way when I try to write a commit message with a a bang in
> it, I'd much rather use a different character that is not in risk of
> being mistreated by my shell. (Although it seems that bash does do TRT
> in the 'fixup!' case.)
>
> --
> Cheers,
>
> Sverre Rabbelier
There was a strong objection (I think from Johanes) against not
using 'unusual' letters during the initial round back in June
2009. Even when explicitly giving '--auto-squash' from the
command line, there can be commits with confusing titles
like "fixup the ancient bug in cat-file" in addition to
the ones you wanted to mark with the "fixup!" marker.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCH v2 1/3] refactor ref status logic for pushing
From: Tay Ray Chuan @ 2009-12-09 3:40 UTC (permalink / raw)
To: Daniel Barkalow
Cc: git, Shawn O. Pearce, Sverre Rabbelier, Clemens Buchacher,
Jeff King, Junio C Hamano
In-Reply-To: <alpine.LNX.2.00.0912081158040.14365@iabervon.org>
Hi,
On Wed, Dec 9, 2009 at 1:17 AM, Daniel Barkalow <barkalow@iabervon.org> wrote:
> On Tue, 8 Dec 2009, Tay Ray Chuan wrote:
>
>> Move the logic that detects up-to-date and non-fast-forward refs to a
>> new function in remote.[ch], set_ref_status_for_push().
>
> Is there some reason to not have set_ref_status_for_push() be static in
> transport.c now? (Sorry for not suggesting this before.)
it can't be static, because builtin-send-pack.c::main() needs it too.
> Other than that, it looks good to me.
Thanks.
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: help: bisect single file from repos
From: SZEDER Gábor @ 2009-12-09 1:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Christian Couder, Michael J Gruber, wharms
In-Reply-To: <7vein5e2lc.fsf@alter.siamese.dyndns.org>
Hi,
On Tue, Dec 08, 2009 at 10:35:11AM -0800, Junio C Hamano wrote:
> But I wonder if there is
> something we _could_ have done better in the documentation area to avoid
> this from the beginning, iow, make it easier to "learn how things work
> before using"? I think there is a lesson to be learned by us in here, and
> I'd like to hear comments and improvement suggestions, especially from
> "usability" and "friendly to new people" advocates.
when a git command accepts a commit as command line option, the
documentation usually refers to the "Specifying revisions" section of
'git rev-parse's docs for "a more complete list of ways to spell
commits"[1]. Even the docs of porcelain commands and the user manual
do that. But 'git rev-parse' is plumbing, and we actively advertise
that avarage users don't really need to know about plumbing at all.
While new to git I repeatedly encountered this reference to 'git
rev-parse' all over the porcelain manpages, and it was a real burden
for me back then. I was like "but I don't want to know about all the
glory details, just give me a short summary".
I think the user should not refer to plumbing manpages to be able to
use porcelain commands. Therefore, the manpage of every command
accepting a commit option need to have a section about specifying
these commits. This section doesn't need to be as detailed as 'git
rev-parse'; perhaps we don't need to discuss the ^{} notation there.
Also, the precedence in case of an ambiguous symbolic ref name should
be described without reference to the internal $GIT_DIR/refs/
directory structure.
Furthermore, some manpages use the term "<commit>", while others
"<committish>" or "<rev>". The same term should be used everywhere.
Best,
Gábor
[1] - 'git cherry-pick' doc says the following:
<commit>
Commit to cherry-pick. For a more complete list of ways to spell
commits, see the "SPECIFYING REVISIONS" section in git-rev-parse(1).
What? "A _more_ complete list"!? Well, it's not very hard to be more
complete than this, there is not a single way described here (;
^ permalink raw reply
* Truth about manhood quality
From: Joachim Norman @ 2009-10-09 23:47 UTC (permalink / raw)
To: git
Always be ready http://oul.owiccypsu.com/
^ permalink raw reply
* Re: PATCH/RFC] gitweb.js: Workaround for IE8 bug
From: Stephen Boyd @ 2009-12-09 0:08 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200912082332.29925.jnareb@gmail.com>
On Tue, 2009-12-08 at 23:32 +0100, Jakub Narebski wrote:
> Dnia wtorek 8. grudnia 2009 22:56, Stephen Boyd napisał:
> > Yes, there is no longer an error but IE8 still locks up and takes about
> > 30 seconds. It doesn't seem to be any more responsive. Isn't putting the
> > error in a try-catch just papering over the issue?
>
> Does increasing interval in setInterval call at the end of startBlame
> finction in gitweb.js from 1000 (1 second) to e.g. 2000 (2 seconds)
> help there?
>
I tried numbers from 100 to 10000 and didn't see a difference. Files
with only a few hundred lines or less don't lock up though. I've been
using builtin-apply.c for testing.
^ permalink raw reply
* Re: [REROLL PATCH 7/8] Support remote archive from external protocol helpers
From: Junio C Hamano @ 2009-12-08 23:39 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git
In-Reply-To: <1260278177-9029-8-git-send-email-ilari.liusvaara@elisanet.fi>
Ilari Liusvaara <ilari.liusvaara@elisanet.fi> writes:
> Helpers which support connect also should support remote archive
> snapshot (or at least there's only one way to attempt it). So support
> remote snapshotting for protocol helpers.
Sorry, but I cannot parse this "should", and cannot understand how the
first sentence leads to the conclusion ("So") that we must have this
patch.
"They should support it when able, because doing so gives them _this nice
property_ (that is unspecified)"???
Or "They must support it because we are changing the code not to work
without"???
Or "Because the transport layer has been restructured cleanly enough to
allow passing general payload, there is no reason not to do this change to
pass 'archive' output in addition to the 'git smart fetch/push protocol'
payload, and this allows the archive command to take advantage of the
helper based transports"???
^ permalink raw reply
* Re: [REROLL PATCH 6/8] Support remote helpers implementing smart transports
From: Junio C Hamano @ 2009-12-08 23:38 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git
In-Reply-To: <1260278177-9029-7-git-send-email-ilari.liusvaara@elisanet.fi>
Ilari Liusvaara <ilari.liusvaara@elisanet.fi> writes:
> Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
> ---
> Documentation/git-remote-helpers.txt | 25 +++++++-
> transport-helper.c | 126 ++++++++++++++++++++++++++++++++--
> 2 files changed, 144 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt
> index 20a05fe..b957813 100644
> --- a/Documentation/git-remote-helpers.txt
> +++ b/Documentation/git-remote-helpers.txt
> @@ -93,6 +93,20 @@ Supported if the helper has the "push" capability.
> +
> Supported if the helper has the "import" capability.
>
> +'connect' <service>::
> + Connects to given service. Stdin and stdout of helper are
A minor point, but in prose, unless it explains how to use "stdin" and
"stdout" as a variable, keyword, etc. in code, I'd prefer to see these
spelled out, like so:
The standard input and output of helpers are connected to ...
> @@ -34,12 +36,12 @@ static void sendline(struct helper_data *helper, struct strbuf *buffer)
> die_errno("Full write to remote helper failed");
> }
>
> -static int recvline(struct helper_data *helper, struct strbuf *buffer)
> +static int _recvline(FILE *helper, struct strbuf *buffer)
> {
Not a good naming for two reasons.
- Somebody new to the code wouldn't be able to tell which of recvline()
and _recvline() take helper_data and FILE easily.
- A function name that starts with an underscore, even if it is file
scoped static, is something we tend to avoid. This applies to
_process_connect() in the earlier patch as well.
recvline_fh() vs revline() might be better as most of the interaction in
this layer are done on helper_data, which makes the name recvline() pair
nicely with sendline that also takes helper_data; and the oddball one that
is _not_ an implementation detail (i.e. you have calls outside recvline()
implementation that call _recvline()) hints that it takes filehandle
instead.
^ permalink raw reply
* Re: [REROLL PATCH 5/8] Support taking over transports
From: Junio C Hamano @ 2009-12-08 23:37 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git
In-Reply-To: <1260278177-9029-6-git-send-email-ilari.liusvaara@elisanet.fi>
Ilari Liusvaara <ilari.liusvaara@elisanet.fi> writes:
> diff --git a/transport-helper.c b/transport-helper.c
> index 0e82553..3b7340c 100644
> --- a/transport-helper.c
> +++ b/transport-helper.c
> @@ -22,6 +22,7 @@ struct helper_data
> /* These go from remote name (as in "list") to private name */
> struct refspec *refspecs;
> int refspec_nr;
> + struct git_transport_options gitoptions;
> };
Will we ever have another 'xxxoptions' field in this structure that is not
so git-ish? 'gitoptions' somehow doesn't feel right, unless you plan to
later add scm specific options like 'hgoptions', 'bzroptions' in this
field you need to distinguish "git" one from them.
I know you needed to name the new field to store the transport option
under a different name from the existing 'option' field, but for that
purpose, 'transport_options' might be a more appropriate name.
> @@ -109,9 +111,19 @@ static struct child_process *get_helper(struct transport *transport)
> die("Unable to run helper: git %s", helper->argv[0]);
> data->helper = helper;
>
> + /*
> + * Open the output as FILE* so strbuf_getline() can be used.
> + * Do this with duped fd because fclose() will close the fd,
> + * and stuff like taking over will require the fd to remain.
> + *
> + */
> + duped = dup(helper->out);
> + if (duped < 0)
> + die_errno("Can't dup helper output fd");
> + data->out = xfdopen(duped, "r");
> +
Neat hack (the kind I often love), but it makes something deep inside me
cringe. This looks fragile and possibly wrong.
Who guarantees that reading from the (FILE *)data->out by strbuf_getline()
that eventually calls into fgetc() does not cause more data be read in the
buffer assiciated with the (FILE *) than we will consume? The other FILE*
you will make out of helper->out won't be able to read what data->out has
already slurped in to its stdio buffer.
The call sequence, after [6/8] is applied as I understand it is:
- _process_connect()
- get_helper()
- start_command() that gives a pipe to read from the helper in
helper->out;
- the above dup dance makes (FILE *)data->out out of a copied fd;
- read from data->out, potentially reading a lot more than
the loop consumes into the stdio buffer of data->out;
- dup dance again to make (FILE *)input;
- read from input, unbuffered.
But if "capabilities" exchange has read past the capability response from
the helper into helper->out inside get_helper(), wouldn't it make the dup
dance to make an extra "input" to read the rest unbuffered moot, as
"input" won't be even reading from the beginning of "the rest"?
^ permalink raw reply
* Re: [REROLL PATCH 3/8] Pass unknown protocols to external protocol handlers
From: Junio C Hamano @ 2009-12-08 23:35 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git
In-Reply-To: <1260278177-9029-4-git-send-email-ilari.liusvaara@elisanet.fi>
Ilari Liusvaara <ilari.liusvaara@elisanet.fi> writes:
> +const char *remove_ext_force(const char *url)
> +{
> + const char *url2 = url;
> + const char *first_colon = NULL;
> +
> + if (!url)
> + return NULL;
> +
> + while (*url2 && !first_colon)
> + if (*url2 == ':')
> + first_colon = url2;
> + else
> + url2++;
> +
> + if (first_colon && first_colon[1] == ':')
> + return first_colon + 2;
> + else
> + return url;
> +}
Sorry, I am slow today, but is this any different from:
if (url) {
const char *colon = strchr(url, ':');
if (colon && colon[1] == ':')
return url2 + 2;
}
return url;
> diff --git a/transport.c b/transport.c
> index 3eea836..e42a82b 100644
> --- a/transport.c
> +++ b/transport.c
> @@ -780,6 +780,58 @@ static int is_file(const char *url)
> return S_ISREG(buf.st_mode);
> }
>
> +static const char *strchrc(const char *str, int c)
> +{
> + while (*str)
> + if (*str == c)
> + return str;
> + else
> + str++;
> + return NULL;
> +}
I cannot spot how this is different from strchr()...
> +static int is_url(const char *url)
> +{
> + const char *url2, *first_slash;
> +
> + if (!url)
> + return 0;
> + url2 = url;
> + first_slash = strchrc(url, '/');
> +
> + /* Input with no slash at all or slash first can't be URL. */
> + if (!first_slash || first_slash == url)
> + return 0;
> + /* Character before must be : and next must be /. */
> + if (first_slash[-1] != ':' || first_slash[1] != '/')
> + return 0;
> + /* There must be something before the :// */
> + if (first_slash == url + 1)
> + return 0;
> + /*
> + * Check all characters up to first slash. Only alpha, num and
> + * colon (":") are allowed. ":" must be followed by ":" or "/".
> + */
Hmm, so "a::::bc:://" is ok?
Is the reason this does not to check the string up to (first_slash-1) for
a valid syntax for <scheme> (as in "<scheme>://") because this potentially
has "<helper>::" in front of it?
I cannot tell if you want to allow "<helper1>::<helper2>::<scheme>://..."
by reading this code.
> +static int external_specification_len(const char *url)
> +{
> + return strchrc(url, ':') - url;
> +}
Does the caller guarantee url has at least one colon in it?
> struct transport *transport_get(struct remote *remote, const char *url)
> {
> struct transport *ret = xcalloc(1, sizeof(*ret));
> @@ -805,30 +857,23 @@ struct transport *transport_get(struct remote *remote, const char *url)
>
> if (remote && remote->foreign_vcs) {
> transport_helper_init(ret, remote->foreign_vcs);
> + } else if (!prefixcmp(url, "rsync:")) {
> ret->get_refs_list = get_refs_via_rsync;
> ret->fetch = fetch_objs_via_rsync;
> ret->push = rsync_transport_push;
> } else if (is_local(url) && is_file(url)) {
> struct bundle_transport_data *data = xcalloc(1, sizeof(*data));
> ret->data = data;
> ret->get_refs_list = get_refs_from_bundle;
> ret->fetch = fetch_refs_from_bundle;
> ret->disconnect = close_bundle;
> + } else if (!is_url(url)
> + || !prefixcmp(url, "file://")
> + || !prefixcmp(url, "git://")
> + || !prefixcmp(url, "ssh://")
> + || !prefixcmp(url, "git+ssh://")
> + || !prefixcmp(url, "ssh+git://")) {
> + /* These are builtin smart transports. */
Hmm, what is !is_url(url) at the beginning for, if this lists "builtin"
smart transports?
> @@ -845,6 +890,21 @@ struct transport *transport_get(struct remote *remote, const char *url)
> data->receivepack = "git-receive-pack";
> if (remote->receivepack)
> data->receivepack = remote->receivepack;
> + } 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
> + } else {
> + /* Unknown protocol in URL. Pass to external handler. */
> + int len = external_specification_len(url);
> + char *handler = xmalloc(len + 1);
> + handler[len] = 0;
> + strncpy(handler, url, len);
> + transport_helper_init(ret, handler);
Hmph, external_specification_len() may get passed a colon-less string
after all, I think.
^ permalink raw reply
* Re: [REROLL PATCH 2/8] Support mandatory capabilities
From: Junio C Hamano @ 2009-12-08 23:34 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git
In-Reply-To: <1260278177-9029-3-git-send-email-ilari.liusvaara@elisanet.fi>
Ilari Liusvaara <ilari.liusvaara@elisanet.fi> writes:
> diff --git a/transport-helper.c b/transport-helper.c
> index a721dc2..f977d28 100644
> --- a/transport-helper.c
> +++ b/transport-helper.c
> @@ -93,25 +93,39 @@ static struct child_process *get_helper(struct transport *transport)
>
> data->out = xfdopen(helper->out, "r");
> while (1) {
> + const char *capname;
> + int mandatory = 0;
> recvline(data, &buf);
> ...
> + } else if (mandatory) {
> + fflush(stderr);
> + die("Unknown madatory capability %s. This remote "
> + "helper probably needs newer version of Git.\n",
> + capname);
Why fflush() here? Is the reason for needing to flush stderr before
letting die() to write into it very specific to this codepath, or shared
among other callers of die()? I am wondering if we should add this
fflush() to report() in usage.c instead.
^ permalink raw reply
* Re: [REROLL PATCH 1/8] Add remote helper debug mode
From: Junio C Hamano @ 2009-12-08 23:34 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git
In-Reply-To: <1260278177-9029-2-git-send-email-ilari.liusvaara@elisanet.fi>
Ilari Liusvaara <ilari.liusvaara@elisanet.fi> writes:
> Remote helpers deadlock easily, so support debug mode which shows the
> interaction steps.
Also new helper functions, sendline(), recvline(), write_constant() and
xchgline() introduces abstraction that makes the whole thing a lot nicer
to read ;-).
Nice.
^ permalink raw reply
* Re: Weird message when pulling git version 1.6.6.rc1.39.g9a42
From: Junio C Hamano @ 2009-12-08 23:33 UTC (permalink / raw)
To: Alejandro Riveira; +Cc: git, Horst H. von Brand, Nanako Shiraishi
In-Reply-To: <hfmijf$dl1$1@ger.gmane.org>
Alejandro Riveira <ariveira@gmail.com> writes:
> $ git pull
> remote: Counting objects: 9, done.
> remote: Compressing objects: 100% (5/5), done.
> remote: Total 5 (delta 4), reused 0 (delta 0)
> Unpacking objects: 100% (5/5), done.
> From git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
> 6035ccd..a252e74 master -> origin/master
> Updating 6035ccd..a252e74
> Fast-forward (no commit created; -m option ignored) # what is this ??
> net/sctp/sysctl.c | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
Thanks for reporting.
Warning about a message that the end user didn't give the command is
clearly wrong. I guess we would want to revert c0ecb07 (git-pull.sh: Fix
call to git-merge for new command format, 2009-12-01), and b81e00a
(git-merge: a deprecation notice of the ancient command line syntax,
2009-11-30).
Reverting them will still keep 76bf488 (Do not misidentify "git merge foo
HEAD" as an old-style invocation, 2009-12-02) that resulted in the change
we are reverting here, so we are still ahead ;-)
http://thread.gmane.org/gmane.comp.version-control.git/134103/focus=134145
-- >8 --
Subject: [PATCH] Revert recent "git merge <msg> HEAD <commit>..." deprecation
This reverts commit c0ecb07048ce2123589a2f077d296e8cf29a9570 "git-pull.sh:
Fix call to git-merge for new command format" and
commit b81e00a965c62ca72a4b9db425ee173de147808d "git-merge: a deprecation
notice of the ancient command line syntax".
They caused a "git pull" (without any arguments, and without any local
commits---only to update to the other side) to warn that commit log
message is ignored because the merge resulted in a fast-forward.
Another possible solution is to add an extra option to "git merge" so that
"git pull" can tell it that the message given is not coming from the end
user (the canned message is passed just in case the merge resulted in a
non-ff and caused commit), but I think it is easier _not_ to deprecate the
old syntax.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-merge.c | 6 ------
git-pull.sh | 6 +++---
2 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/builtin-merge.c b/builtin-merge.c
index 56a1bb6..f1c84d7 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -796,11 +796,6 @@ static int suggest_conflicts(void)
return 1;
}
-static const char deprecation_warning[] =
- "'git merge <msg> HEAD <commit>' is deprecated. Please update\n"
- "your script to use 'git merge -m <msg> <commit>' instead.\n"
- "In future versions of git, this syntax will be removed.";
-
static struct commit *is_old_style_invocation(int argc, const char **argv)
{
struct commit *second_token = NULL;
@@ -814,7 +809,6 @@ static struct commit *is_old_style_invocation(int argc, const char **argv)
die("'%s' is not a commit", argv[1]);
if (hashcmp(second_token->object.sha1, head))
return NULL;
- warning(deprecation_warning);
}
return second_token;
}
diff --git a/git-pull.sh b/git-pull.sh
index 502af1a..bfeb4a0 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -216,7 +216,7 @@ fi
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 \
+ exec git-rebase $diffstat $strategy_args --onto $merge_head \
${oldremoteref:-$merge_head}
-exec git merge $verbosity $diffstat $no_commit $squash $no_ff $ff_only $log_arg $strategy_args \
- -m "$merge_name" $merge_head
+exec git-merge $diffstat $no_commit $squash $no_ff $ff_only $log_arg $strategy_args \
+ "$merge_name" HEAD $merge_head $verbosity
--
1.6.6.rc1.42.gf9ad7
^ permalink raw reply related
* false directory/file merge conflict
From: Jeffrey Middleton @ 2009-12-08 22:55 UTC (permalink / raw)
To: git
When a directory (with contents) has changed into a file on one
branch, and another branch attempts to merge it, there's a false
conflict - the directory is processed before its contents are removed.
This is particularly nasty, because "resolving" the non-existent
conflict results in no changes, so future merges will fail in exactly
the same way. Test script and failed merge output below.
Jeffrey
-- 8< --
rm -rf directory-file
mkdir directory-file
cd directory-file
git init
mkdir foo
echo bar > foo/bar
echo bas > foo/baz
git add foo/bar foo/baz
git commit -m "check in files"
git branch foo_unchanged
git rm -r foo
echo foo > foo
git add foo
git commit -m "foo changes from directory to file"
git checkout foo_unchanged
echo foobar > foobar
git add foobar
git commit -m "make a separate change"
git merge master
-- 8< --
CONFLICT (directory/file): There is a directory with name foo in HEAD.
Adding foo as foo~master
Removing foo/bar
Removing foo/baz
Automatic merge failed; fix conflicts and then commit the result.
^ permalink raw reply
* Re: PATCH/RFC] gitweb.js: Workaround for IE8 bug
From: Jakub Narebski @ 2009-12-08 22:32 UTC (permalink / raw)
To: Stephen Boyd; +Cc: git
In-Reply-To: <1260309382.5658.41.camel@swboyd-laptop>
Dnia wtorek 8. grudnia 2009 22:56, Stephen Boyd napisał:
> On Tue, 2009-12-08 at 17:29 +0100, Jakub Narebski wrote:
> >
> > Does the following fixes the issue for IE8 for you (it works for me)?
> >
>
> Yes, there is no longer an error but IE8 still locks up and takes about
> 30 seconds. It doesn't seem to be any more responsive. Isn't putting the
> error in a try-catch just papering over the issue?
Does increasing interval in setInterval call at the end of startBlame
finction in gitweb.js from 1000 (1 second) to e.g. 2000 (2 seconds)
help there?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: PATCH/RFC] gitweb.js: Workaround for IE8 bug
From: Jakub Narebski @ 2009-12-08 22:24 UTC (permalink / raw)
To: Stephen Boyd; +Cc: git
In-Reply-To: <1260309382.5658.41.camel@swboyd-laptop>
On Tue, 8 Dec 2009, Stephen Boyd wrote:
> On Tue, 2009-12-08 at 17:29 +0100, Jakub Narebski wrote:
> >
> > Does the following fixes the issue for IE8 for you (it works for me)?
> >
>
> Yes, there is no longer an error but IE8 still locks up and takes about
> 30 seconds. It doesn't seem to be any more responsive. Isn't putting the
> error in a try-catch just papering over the issue?
Well, I wrote it is *workaround* for IE8 bug, didn't I?
There are actually two separate issues. First is 'blame_incremental'
freezing browser (making it non responsive), second is proper solution
to this bug.
The problem with 'blame_incremental' freezing is that JavaScript is
single-threaded, and that modifying DOM is not lightweight. gitweb.js
should then use technique described in
http://www.nczonline.net/blog/2009/08/11/timed-array-processing-in-javascript/
to avoid freezing browser, and perhaps also some technique to avoid
reflowing (if possible).
The proper solution for IE8 bug would be to use 'progress', 'error'
and 'load' events of XHR 2.0 (XMLHttpRequest specification level 2)
if they are available, instead of mucking with underspecified
'readystatechange' event from XHR 1.0 and timer. But it is a more
complicated solution.
--
Jakub Narebski
Poland
^ permalink raw reply
* Weird message when pulling git version 1.6.6.rc1.39.g9a42
From: Alejandro Riveira @ 2009-12-08 22:05 UTC (permalink / raw)
To: git
$ git pull
remote: Counting objects: 9, done.
remote: Compressing objects: 100% (5/5), done.
remote: Total 5 (delta 4), reused 0 (delta 0)
Unpacking objects: 100% (5/5), done.
From git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
6035ccd..a252e74 master -> origin/master
Updating 6035ccd..a252e74
Fast-forward (no commit created; -m option ignored) # what is this ??
net/sctp/sysctl.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
^ permalink raw reply
* Re: delete remote branches
From: Andreas Schwab @ 2009-12-08 22:06 UTC (permalink / raw)
To: Patrick Grimard; +Cc: git
In-Reply-To: <9cdb17250912081235m2b061ca5x70fe42749b49670f@mail.gmail.com>
Patrick Grimard <pgrimard@gmail.com> writes:
> However from DIR1 if I do "git branch -r" I still see the remote
> branch and can't seem to delete it using the above method.
Try "git remote prune origin".
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: PATCH/RFC] gitweb.js: Workaround for IE8 bug
From: Stephen Boyd @ 2009-12-08 21:56 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200912081729.11890.jnareb@gmail.com>
On Tue, 2009-12-08 at 17:29 +0100, Jakub Narebski wrote:
>
> Does the following fixes the issue for IE8 for you (it works for me)?
>
Yes, there is no longer an error but IE8 still locks up and takes about
30 seconds. It doesn't seem to be any more responsive. Isn't putting the
error in a try-catch just papering over the issue?
^ permalink raw reply
* [PATCH 1/2] git-svn: Set svn.authorsfile to an absolute path when cloning
From: Alex Vandiver @ 2009-12-08 20:54 UTC (permalink / raw)
To: git; +Cc: Eric Wong
If --authors-file is passed a relative path, cloning will work, but
future `git svn fetch`es will fail to locate the authors file
correctly. Thus, use File::Spec->rel2abs to determine an absolute
path for the authors file before setting it.
Signed-off-by: Alex Vandiver <alex@chmrr.net>
---
git-svn.perl | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 957d44e..cf5e75e 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -392,9 +392,11 @@ sub cmd_clone {
$path = $url;
}
$path = basename($url) if !defined $path || !length $path;
+ my $authors_absolute = $_authors ? File::Spec->rel2abs($_authors) : "";
cmd_init($url, $path);
Git::SVN::fetch_all($Git::SVN::default_repo_id);
- command_oneline('config', 'svn.authorsfile', $_authors) if $_authors;
+ command_oneline('config', 'svn.authorsfile', $authors_absolute)
+ if $_authors;
}
sub cmd_init {
--
1.6.6.rc0.360.gc408
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox