* [PATCH 6/8] Add a config option for remotes to specify a foreign vcs
From: Daniel Barkalow @ 2009-09-04 2:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
If this is set, the url is not required, and the transport always uses
a helper named "git-remote-<value>".
It is a separate configuration option in order to allow a sensible
configuration for foreign systems which either have no meaningful urls
for repositories or which require urls that do not specify the system
used by the repository at that location. However, this only affects
how the name of the helper is determined, not anything about the
interaction with the helper, and the contruction is such that, if the
foreign scm does happen to use a co-named url method, a url with that
method may be used directly.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
---
Documentation/config.txt | 4 ++++
remote.c | 4 +++-
remote.h | 2 ++
transport.c | 5 +++++
4 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 5256c7f..436ee91 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1380,6 +1380,10 @@ remote.<name>.tagopt::
Setting this value to \--no-tags disables automatic tag following when
fetching from remote <name>
+remote.<name>.vcs::
+ Setting this to a value <vcs> will cause git to interact with
+ the remote with the git-remote-<vcs> helper.
+
remotes.<group>::
The list of remotes which are fetched by "git remote update
<group>". See linkgit:git-remote[1].
diff --git a/remote.c b/remote.c
index fec63fa..e9dbb3b 100644
--- a/remote.c
+++ b/remote.c
@@ -50,7 +50,7 @@ static char buffer[BUF_SIZE];
static int valid_remote(const struct remote *remote)
{
- return !!remote->url;
+ return !remote->url != !remote->foreign_vcs;
}
static const char *alias_url(const char *url)
@@ -427,6 +427,8 @@ static int handle_config(const char *key, const char *value, void *cb)
} else if (!strcmp(subkey, ".proxy")) {
return git_config_string((const char **)&remote->http_proxy,
key, value);
+ } else if (!strcmp(subkey, ".vcs")) {
+ return git_config_string(&remote->foreign_vcs, key, value);
}
return 0;
}
diff --git a/remote.h b/remote.h
index 5db8420..ac0ce2f 100644
--- a/remote.h
+++ b/remote.h
@@ -11,6 +11,8 @@ struct remote {
const char *name;
int origin;
+ const char *foreign_vcs;
+
const char **url;
int url_nr;
int url_alloc;
diff --git a/transport.c b/transport.c
index 684fd6c..38bebe3 100644
--- a/transport.c
+++ b/transport.c
@@ -818,6 +818,11 @@ struct transport *transport_get(struct remote *remote, const char *url)
url = remote->url[0];
ret->url = url;
+ if (remote && remote->foreign_vcs) {
+ transport_helper_init(ret, remote->foreign_vcs);
+ return ret;
+ }
+
if (!prefixcmp(url, "rsync:")) {
ret->get_refs_list = get_refs_via_rsync;
ret->fetch = fetch_objs_via_rsync;
--
1.6.4.2.419.gc86f8
^ permalink raw reply related
* [PATCH 7/8] Add support for "import" helper command
From: Daniel Barkalow @ 2009-09-04 2:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This command, supported if the "import" capability is advertized,
allows a helper to support fetching by outputting a git-fast-import
stream.
If both "fetch" and "import" are advertized, git itself will use
"fetch" (although other users may use "import" in this case).
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
---
Documentation/git-remote-helpers.txt | 10 ++++++
transport-helper.c | 53 ++++++++++++++++++++++++++++++++++
2 files changed, 63 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt
index 173ee23..e9aa67e 100644
--- a/Documentation/git-remote-helpers.txt
+++ b/Documentation/git-remote-helpers.txt
@@ -43,6 +43,13 @@ Commands are given by the caller on the helper's standard input, one per line.
+
Supported if the helper has the "fetch" capability.
+'import' <name>::
+ Produces a fast-import stream which imports the current value
+ of the named ref. It may additionally import other refs as
+ needed to construct the history efficiently.
++
+Supported if the helper has the "import" capability.
+
If a fatal error occurs, the program writes the error message to
stderr and exits. The caller should expect that a suitable error
message has been printed if the child closes the connection without
@@ -57,6 +64,9 @@ CAPABILITIES
'fetch'::
This helper supports the 'fetch' command.
+'import'::
+ This helper supports the 'import' command.
+
REF LIST ATTRIBUTES
-------------------
diff --git a/transport-helper.c b/transport-helper.c
index e2b5270..3825441 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -11,6 +11,7 @@ struct helper_data
const char *name;
struct child_process *helper;
unsigned fetch : 1;
+ unsigned import : 1;
};
static struct child_process *get_helper(struct transport *transport)
@@ -50,6 +51,8 @@ static struct child_process *get_helper(struct transport *transport)
break;
if (!strcmp(buf.buf, "fetch"))
data->fetch = 1;
+ if (!strcmp(buf.buf, "import"))
+ data->import = 1;
}
return data->helper;
}
@@ -93,6 +96,53 @@ static int fetch_with_fetch(struct transport *transport,
return 0;
}
+static int get_importer(struct transport *transport, struct child_process *fastimport)
+{
+ struct helper_data *data = transport->data;
+ struct child_process *helper = get_helper(transport);
+ memset(fastimport, 0, sizeof(*fastimport));
+ fastimport->in = helper->out;
+ fastimport->argv = xcalloc(5, sizeof(*fastimport->argv));
+ fastimport->argv[0] = "fast-import";
+ fastimport->argv[1] = "--quiet";
+
+ fastimport->git_cmd = 1;
+ return start_command(fastimport);
+}
+
+static int fetch_with_import(struct transport *transport,
+ int nr_heads, struct ref **to_fetch)
+{
+ struct child_process fastimport;
+ struct child_process *helper = get_helper(transport);
+ int i;
+ struct ref *posn;
+ struct strbuf buf = STRBUF_INIT;
+
+ if (get_importer(transport, &fastimport))
+ die("Couldn't run fast-import");
+
+ for (i = 0; i < nr_heads; i++) {
+ posn = to_fetch[i];
+ if (posn->status & REF_STATUS_UPTODATE)
+ continue;
+
+ strbuf_addf(&buf, "import %s\n", posn->name);
+ write_in_full(helper->in, buf.buf, buf.len);
+ strbuf_reset(&buf);
+ }
+ disconnect_helper(transport);
+ finish_command(&fastimport);
+
+ for (i = 0; i < nr_heads; i++) {
+ posn = to_fetch[i];
+ if (posn->status & REF_STATUS_UPTODATE)
+ continue;
+ read_ref(posn->name, posn->old_sha1);
+ }
+ return 0;
+}
+
static int fetch(struct transport *transport,
int nr_heads, struct ref **to_fetch)
{
@@ -110,6 +160,9 @@ static int fetch(struct transport *transport,
if (data->fetch)
return fetch_with_fetch(transport, nr_heads, to_fetch);
+ if (data->import)
+ return fetch_with_import(transport, nr_heads, to_fetch);
+
return -1;
}
--
1.6.4.2.419.gc86f8
^ permalink raw reply related
* [PATCH 8/8] Allow helpers to report in "list" command that the ref is unchanged
From: Daniel Barkalow @ 2009-09-04 2:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Helpers may use a line like "? name unchanged" to specify that there
is nothing new at that name, without any git-specific code to
determine the correct response.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
---
Documentation/git-remote-helpers.txt | 4 +++-
transport-helper.c | 22 ++++++++++++++++++++++
2 files changed, 25 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt
index e9aa67e..2c5130f 100644
--- a/Documentation/git-remote-helpers.txt
+++ b/Documentation/git-remote-helpers.txt
@@ -70,7 +70,9 @@ CAPABILITIES
REF LIST ATTRIBUTES
-------------------
-None are defined yet, but the caller must accept any which are supplied.
+'unchanged'::
+ This ref is unchanged since the last import or fetch, although
+ the helper cannot necessarily determine what value that produced.
Documentation
-------------
diff --git a/transport-helper.c b/transport-helper.c
index 3825441..1a05f0b 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -166,6 +166,22 @@ static int fetch(struct transport *transport,
return -1;
}
+static int has_attribute(const char *attrs, const char *attr) {
+ int len;
+ if (!attrs)
+ return 0;
+
+ len = strlen(attr);
+ for (;;) {
+ const char *space = strchrnul(attrs, ' ');
+ if (len == space - attrs && !strncmp(attrs, attr, len))
+ return 1;
+ if (!*space)
+ return 0;
+ attrs = space + 1;
+ }
+}
+
static struct ref *get_refs_list(struct transport *transport, int for_push)
{
struct child_process *helper;
@@ -202,6 +218,12 @@ static struct ref *get_refs_list(struct transport *transport, int for_push)
(*tail)->symref = xstrdup(buf.buf + 1);
else if (buf.buf[0] != '?')
get_sha1_hex(buf.buf, (*tail)->old_sha1);
+ if (eon) {
+ if (has_attribute(eon + 1, "unchanged")) {
+ (*tail)->status |= REF_STATUS_UPTODATE;
+ read_ref((*tail)->name, (*tail)->old_sha1);
+ }
+ }
tail = &((*tail)->next);
}
strbuf_release(&buf);
--
1.6.4.2.419.gc86f8
^ permalink raw reply related
* Re: [PATCH] clone: disconnect transport after fetching
From: Jeff King @ 2009-09-04 2:30 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Daniel Barkalow, Sverre Rabbelier, Björn Steinbrink,
Matthieu Moy, Sitaram Chamarty
In-Reply-To: <20090902063647.GA29559@coredump.intra.peff.net>
On Wed, Sep 02, 2009 at 02:36:47AM -0400, Jeff King wrote:
> This patch just explicitly calls disconnect after we are
> done with the remote end, which sends a flush packet to
> upload-pack and cleanly disconnects, avoiding the error
> message.
I see you applied this with some extra tests. I should have mentioned in
the original cover letter that I considered tests but intentionally did
not include them.
The problem is that clone forks upload-pack, and then hangs up on it by
exiting, and then upload-pack spews the unwanted message. But control
has returned to the shell after clone exits, meaning that the message
from upload-pack may or may not have gotten there by the time we grep
stderr.
So I don't think your test will ever incorrectly show a failure, but I
believe that it would pass randomly even without the related fix to the
code.
-Peff
^ permalink raw reply
* Re: [PATCH v6 5/6] fast-import: add option command
From: Ian Clatworthy @ 2009-09-04 3:42 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Junio C Hamano, Shawn O. Pearce, Johannes Schindelin, Git List,
Matt McClure, Miklos Vajna, Julian Phillips, vcs-fast-import-devs
In-Reply-To: <fabb9a1e0909022155r254c41c6s9ed962313c241e9@mail.gmail.com>
Sverre Rabbelier wrote:
> Heya,
>
> On Thu, Sep 3, 2009 at 04:41, Junio C Hamano<gitster@pobox.com> wrote:
>> I think at least the function should be made conditional to die() if it
>> was called from parse_argv() but simply ignore unknown if it was called
>> from the input stream.
>
> Makes sense, what do the fast-import devs think?
Sounds ok to me.
Ian C.
^ permalink raw reply
* Re: [JGIT] Request for help
From: Gabe McArthur @ 2009-09-04 5:00 UTC (permalink / raw)
To: git
In-Reply-To: <20090903155219.GI1033@spearce.org>
Shawn O. Pearce <spearce <at> spearce.org> writes:
>
> Please post patches; formatted with -M. I do want to do this, I just
> don't have the patience and Maven-fu to write the new poms myself.
>
Hey,
I'm a build engineer with a considerable amount of "Maven-fu" :). I've actually
generated a patch that does everything you want (and a bit more). I'm not that
familiar with git's command line yet, so it's a bit tricky to get the patch
thing right. However, here's a rough overview of what I did:
ROOT
====
README
/bin
bash.env -- A script that you can source from Bash that
will add the 'jgit' executable and the other
scripts in this 'bin' directory to your PATH
build.sh -- A general build script, that hides some
Maven complexities for initiates.
tag.sh -- Ok, this is the only thing that will have to
be re-written. It's too tied in with git commands for
me to fully extract what it's supposed to do.
/docs
LICENSE
SUBMITTING_PATCHES
TODO
pom.xml -- A considerable amount of build logic has been
centralized here. It references 3 sub-module
projects, listed below.
/sources
/jgit-lib
pom.xml
/src/main/java....
/src/test
/java....
/resources
/exttst -- Don't know exactly where this goes, as it
doesn't seem to be doing much/being run
currently.
/jgit-pgm
pom.xml -- Does the work to do a 'jar-with-dependencies'
so that org.spearce.jgit.pgm.build can be removed.
/src/main/java....
/jgit-exec
pom.xml -- Actually generates the 'jgit' executable and
installs it in ROOT/target/bin, so that it will
be on your path after sourcing 'bin/bash.env'
/src/main/scripts/jgit
I'll try to submit a full patch later, using your conventions.
My appreciation to Shawn for pointing out this thread....
-Gabe
^ permalink raw reply
* Re: [PATCH 1/8] Make the "traditionally-supported" URLs a special case
From: Sverre Rabbelier @ 2009-09-04 5:29 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LNX.2.00.0909032213180.28290@iabervon.org>
Heya,
On Fri, Sep 4, 2009 at 04:13, Daniel Barkalow<barkalow@iabervon.org> wrote:
> Instead of trying to make http://, https://, and ftp:// URLs
> indicative of some sort of pattern of transport helper usage, make
> them a special case which runs the "curl" helper, and leave the
> mechanism by which arbitrary helpers will be chosen entirely to future
> work.
I'm sorry, I missed a few emails I think :(. Would you mind explaining
why we chose to special-case the curl helpers instead of the symlink
scheme?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [BUG] 'add -u' doesn't work from untracked subdir
From: Clemens Buchacher @ 2009-09-04 7:02 UTC (permalink / raw)
To: Jeff King; +Cc: SZEDER Gábor, git
In-Reply-To: <20090902081917.GA5447@coredump.intra.peff.net>
On Wed, Sep 02, 2009 at 04:19:17AM -0400, Jeff King wrote:
> [1] I would prefer "git add -u ." to add only the current directory, and
> "git add -u" to touch everything.
FWIW, I feel the same way. And there is no easy way to do that now. (cd `git
rev-parse --show-cdup`; git add -u) ?
> But then, I am one of the people who
> turn off status.relativepaths, so I think I may be in the minority in
> always wanting to think of the project as a whole.
That mindset is one of git's greatest strengths IMO.
Clemens
^ permalink raw reply
* Re: [PATCH 0/8] VCS helpers
From: Junio C Hamano @ 2009-09-04 7:04 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git, Johan Herland
In-Reply-To: <alpine.LNX.2.00.0909032213120.28290@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> This is the next version of the db/vcs-helper series in pu.
Thanks.
> The first patch is new, a rework of the remote-curl build to produce
> "remote-curl" and call it as a special case for the sorts of URLs that
> we accept as indicating something that it now handled by this helper.
>
> The series is rebased onto current next, with some conflicts resolved.
Because the theme of the topic does not have anything to do with fixing
the deepening of shallow clones nor giving an extended error message from
non-fast-forward git-push, I queued the series after reverse-rebasing onto
old db/vcs-helper~8, in order to keep the topic branch pure, instead of
merging unrelated topics from maint, master or next into it. The result
merged in 'pu' obviously has to match what you expected by applying the
patches on top of 'next', and I am reasonably sure it does.
> Two patches have been dropped: a memory leak fix for code that was
> removed entirely by the first patch, and the "mark" helper capability,
> which is not needed (I believe) due to the "option" fast-import command.
Johan's cvs-helper series were depending on the previous iteration of this
series, but I thought it is being rerolled, so I'd drop it from pu for now.
^ permalink raw reply
* Re: [JGIT] Request for help
From: Mark Struberg @ 2009-09-04 7:12 UTC (permalink / raw)
To: Jonas Fonseca, Shawn O. Pearce
Cc: Johannes Schindelin, Nasser Grainawi, Git Mailing List
Hi!
Since I work on the sonatype repo and also being a maven guy, I'd be happy to help!
There are a few patches from the work we've done to come the next weeks anyway, starting with IgnoreRules and stuff. I think we still have to improve the code quality of SimpleRepository but I'd be happy to hear your opinion on this too, so I maybe send a RFC.
If you like to go with maven for JGIT, we have 2 options:
1.) Use the current directory structure and use the configuration you can see in the sonatype poms Jason did. E.g all paths have to be set in pom.sml
2.) Do a complete rework and move over to the standard maven layout [1] . This may include moving org.spearce.jgit.test/ to org.spearce.jgit/src/test/java resp org.spearce.jgit/src/test/resources.
In the meantime Eclipse is really fine with handling separate target folders for production code and test classes (target/classes vs target/test-classes) so this is not a showstopper any more.
LieGrue,
strub
[1] http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html
--- On Thu, 9/3/09, Shawn O. Pearce <spearce@spearce.org> wrote:
> From: Shawn O. Pearce <spearce@spearce.org>
> Subject: Re: [JGIT] Request for help
> To: "Jonas Fonseca" <jonas.fonseca@gmail.com>
> Cc: "Johannes Schindelin" <Johannes.Schindelin@gmx.de>, "Nasser Grainawi" <nasser@codeaurora.org>, "Git Mailing List" <git@vger.kernel.org>
> Date: Thursday, September 3, 2009, 5:52 PM
> Jonas Fonseca <jonas.fonseca@gmail.com>
> wrote:
> > On Thu, Sep 3, 2009 at 10:42, Shawn O. Pearce<spearce@spearce.org>
> wrote:
> > > Actually, now that we have forked out of the
> egit.git repository,
> > > I want to refactor the layout of the JGit project
> to be more maven
> > > like, and have a proper top-level pom to build
> things.
> >
> > What kind of module structure do you have in mind? Do
> you want to move
> > some of the modules/subdirectories?
> > Some refactoring of the maven setup for JGit back was
> done back in
> > April in sonatype's (a maven company) JGit clone. It
> is not
> > signed-off, but can serve as a reference.
>
> Yea, I was hoping they would contribute this back as
> patches,
> but thus far they haven't.
>
> > The Maven layout in the sonatype clone simply uses the
> Eclipse project layout.
> >
> > pom.xml: JGit :: Parent
> > |- org.spearce.jgit/pom.xml: JGit :: Core
> > |- org.spearce.jgit.pgm/pom.xml: JGit ::
> Programs
> > `- org.spearce.jgit.test/pom.xml: JGit :: Test
> >
> > However, having tests in a separate module can be both
> good/bad. For
> > example, they will not automatically get run when you
> only build the
> > Core module.
>
> Yea, I know. This is one area where Maven is just
> whack, by putting
> the tests in the same project the Maven plugin for Eclipse
> puts
> them into the same classpath, which means you can see test
> code
> from project code. Wrong. They should be
> different projects so
> the test classpath is isolated.
>
> However. This is a bug in the Eclipse plugin I think,
> not
> necessarily with Maven's approach of trying to keep tests
> alongside
> the code they test. Thus we probably want:
>
> pom.xml: JGit :: Parent
> |- jgit-lib/pom.xml: JGit
> |
> src/main/java <-- from
> org.spearce.jgit/src
> |
> src/test/java <-- from
> org.spearce.jgit.test/src
> |
> `- jgit-pgm/pom.xml: JGit pgm
> src/main/java
> <-- from org.spearce.jgit.pgm/src
>
> IIRC there is Maven support to create proper MANIFEST.MF
> files for
> OSGI bundles, which is what we need for the Eclipse plugin
> support.
> That should be able to replace the META-INF/MANIFEST.MF in
> the top
> of each of the current directories.
>
> > Anyway, I would like to help.
>
> Please post patches; formatted with -M. I do want to
> do this, I just
> don't have the patience and Maven-fu to write the new poms
> myself.
>
> --
> Shawn.
> --
> To unsubscribe from this list: send the line "unsubscribe
> git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCHv2] git-config: Parse config files leniently
From: Michael J Gruber @ 2009-09-04 7:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7viqfz4mu3.fsf@alter.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 04.09.2009 01:42:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>
>>> Why was I CC'ed, if the patch wasn't even self tested?
>>
>> Because
>> - not CC'ing you would have meant culling you from the existing CC,
>> - we've discussed v1 of this patch before,
>> - I asked in this patch (v2) whether to go for an alternative.
>
> Oh, so you did not mean this was for inclusion but as another round
> of RFC. I misread your intent. Sorry about that.
OK. I'll try to distinguish better between RFC and RFI in the future.
And, yes, usually I run *all* tests before sending patches. I had even
grepped all tests for "config" in order not to miss any, but failed to
note how the patch affects all other commands as well.
>
> The eralier analysis of the cause of the breakage indicated that the
> implementation in this patch was flawed. What it essentially did was to
> re-define all die() to warn() in the codepaths around configuration
> variable handling [*1*].
>
> However, it does not mean that the idea of "ignoring syntax errors while
> keeping other errors still noticed for all commands, not limited to config
> nor not limited to 'config -e'" is necessarily flawed.
>
> For example, the test I noticed the breakage with was stuffing an invalid
> value to branch.autosetuprebase and wanted to see "git branch" fail.
>
> Obviously we do want to fail a "git branch newbranch origin/master" when
> the value given to branch.autosetuprebase is misspelled, to avoid creating
> bogus settings the user did not intend to. We do care about semantic
> errors (i.e. this variable can take only one of these values, but the
> value given in the file is bogus) in such a case. But if you are running
> "git branch" only to view, but not to create, there is no reason for us to
> care about the branch.autosetuprebase variable [*2*].
>
> This observation suggests that it may make sense to make the error
> handling _even looser_ than what you intended to do in your patch (which I
> assume was "we ignore syntax errors and try to recover, pretending that we
> saw a comment until the end of line, but we still keep the validation of
> values assigned to variables that the existing commands rely on").
>
> Ideally, the rule would be "we care about the values of variables we are
> going to use, but allow misspelled values in variables that are not used
> by us---we have no business complaining about them." Unfortunately that
> is much harder to arrange with the current code structure, but under that
> rule, "config -e" would care only about "core.editor" and nothing else, so
> as long as that variable can be sanely read, it should be able to start.
>
>
> [Footnotes]
>
> *1* The additional test that came with the patch only checked for the
> positive case (i.e. "does the system with this patch treats errors looser
> than before?"), but failed to check the negative case (i.e. "does the
> change too much and stop catching errors that should be caught?"), which
> unfortunately is a common mistake that easily lets bugs go unnoticed.
>
> *2* Worse yet, the parsing of branch.autosetuprebase is part of the
> default_config and commands that do not have anything to do with new
> branch creation will fail with the current setup.
Thanks for the thorough explanations. Especially *2* makes me think that
quite some restructuring would be necessary in order to "do it right".
That would be above my head (and time constraints).
Given that, I think the practical options are
a) make "git config" parse leniently (both -e and others)
b) leave as is and document how to recover from bad config
c) launch the editor on a tmp copy, check and refuse or loop on fail...
I still think of "git config -e" as a shortcut only (meaning it doesn't
warrant large specific code efforts), and it's problematic because the
user base is split in two sets:
- Those who know their way around .git/config and editors.
- Those who should stick with the get and set modes of "git config".
"git config -e" helps users from the 2nd group shoot themselves in their
feet badly enough that they can recover only with insight from the first
group...
Michael
^ permalink raw reply
* Re: [JGIT] Request for help
From: Mark Struberg @ 2009-09-04 7:33 UTC (permalink / raw)
To: git, Gabe McArthur
In-Reply-To: <loom.20090904T064602-511@post.gmane.org>
Seems this speeds up lately ;)
Gabe, please allow me a few questions:
.) why do we need the /sources directory layer? I think /jgit and /jgit-pgm would be enough.
.) imho the docs should stay in / at least the LICENSE file
.) we don't need a tag.sh any more if we work with maven. Maven now has the maven-scm-provider-gitexe activated by default (since early 2008), so
mvn release:prepare
mvn release:perform
should work if we set the proper <scm> section. Any feedback or bugreporting on the maven-git integration is highly welcome btw ;)
LieGrue,
strub
--- On Fri, 9/4/09, Gabe McArthur <gabriel.mcarthur@gmail.com> wrote:
> From: Gabe McArthur <gabriel.mcarthur@gmail.com>
> Subject: Re: [JGIT] Request for help
> To: git@vger.kernel.org
> Date: Friday, September 4, 2009, 7:00 AM
>
> Shawn O. Pearce <spearce <at> spearce.org>
> writes:
>
> >
> > Please post patches; formatted with -M. I do
> want to do this, I just
> > don't have the patience and Maven-fu to write the new
> poms myself.
> >
>
>
> Hey,
> I'm a build engineer with a considerable amount of
> "Maven-fu" :). I've actually
> generated a patch that does everything you want (and a bit
> more). I'm not that
> familiar with git's command line yet, so it's a bit tricky
> to get the patch
> thing right. However, here's a rough overview of what
> I did:
>
> ROOT
> ====
> README
> /bin
> bash.env -- A script that you can
> source from Bash that
>
> will add the 'jgit' executable and the other
>
> scripts in this 'bin' directory to your PATH
> build.sh -- A general build script,
> that hides some
>
> Maven complexities for initiates.
> tag.sh -- Ok, this is the
> only thing that will have to
> be
> re-written. It's too tied in with git commands for
> me
> to fully extract what it's supposed to do.
> /docs
> LICENSE
> SUBMITTING_PATCHES
> TODO
> pom.xml -- A considerable amount of
> build logic has been
>
> centralized here. It references 3 sub-module
>
> projects, listed below.
> /sources
> /jgit-lib
> pom.xml
> /src/main/java....
> /src/test
> /java....
> /resources
> /exttst -- Don't know
> exactly where this goes, as it
>
> doesn't seem to be doing much/being run
>
> currently.
> /jgit-pgm
> pom.xml -- Does the
> work to do a 'jar-with-dependencies'
>
> so that org.spearce.jgit.pgm.build can be
> removed.
> /src/main/java....
> /jgit-exec
> pom.xml -- Actually
> generates the 'jgit' executable and
>
> installs it in ROOT/target/bin, so that it
> will
>
> be on your path after sourcing
> 'bin/bash.env'
> /src/main/scripts/jgit
>
> I'll try to submit a full patch later, using your
> conventions.
>
> My appreciation to Shawn for pointing out this thread....
> -Gabe
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe
> git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: Deleted folder keeps showing up?
From: Michael J Gruber @ 2009-09-04 7:41 UTC (permalink / raw)
To: Benjamin Buch; +Cc: git
In-Reply-To: <34230C98-81B8-4DC8-846F-8B6FA2A022DA@gmx.de>
Benjamin Buch venit, vidit, dixit 03.09.2009 18:59:
> I made a branch and deleted a folder there with git rm -rf foldername.
> So now i have to branches, A with the folder and B without the folder.
>
> I'm on B, the folder is not there.
> Then I check out A, the folder shows up like it should.
> When I check out B again, the folder is still there.
>
> A git rm -rf folder gives me:
>
> fatal: pathspec 'folder/' did not match any files
>
> , so git is not tracking the folder.
>
> I can rm -rf the filder without git and start the whole game from the
> beginning,
> but there has to be a better way?
>
> Strange enough this happens just to two folders I removed,
> with others there is no problem.
What does "git status" say when you've checked out B? Could some
contents of folder/ possibly be being ignored (.git/info/excludes etc.)?
Michael
^ permalink raw reply
* Re: Deleted folder keeps showing up?
From: Benjamin Buch @ 2009-09-04 8:18 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <4AA0C4A2.5040405@drmicha.warpmail.net>
Hi Michael,
thank you for your answer.
Strangely, I can't reproduce the error today.
As I did quite a lot branching and merging yesterday (learning git),
I can't remember the steps that led to the error.
And it doesn't have to be an error though -
perhaps it was just my clouded perception due to the lots of branches.
But I will keep an eye on this and see if it happens again.
Sorry for bothering,
- benjamin
Am 04.09.2009 um 09:41 schrieb Michael J Gruber:
> Benjamin Buch venit, vidit, dixit 03.09.2009 18:59:
>> I made a branch and deleted a folder there with git rm -rf
>> foldername.
>> So now i have to branches, A with the folder and B without the
>> folder.
>>
>> I'm on B, the folder is not there.
>> Then I check out A, the folder shows up like it should.
>> When I check out B again, the folder is still there.
>>
>> A git rm -rf folder gives me:
>>
>> fatal: pathspec 'folder/' did not match any files
>>
>> , so git is not tracking the folder.
>>
>> I can rm -rf the filder without git and start the whole game from the
>> beginning,
>> but there has to be a better way?
>>
>> Strange enough this happens just to two folders I removed,
>> with others there is no problem.
>
> What does "git status" say when you've checked out B? Could some
> contents of folder/ possibly be being ignored (.git/info/excludes
> etc.)?
>
> Michael
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Deleted folder keeps showing up?
From: Jeff King @ 2009-09-04 8:27 UTC (permalink / raw)
To: Benjamin Buch; +Cc: git
In-Reply-To: <34230C98-81B8-4DC8-846F-8B6FA2A022DA@gmx.de>
On Thu, Sep 03, 2009 at 06:59:18PM +0200, Benjamin Buch wrote:
> I made a branch and deleted a folder there with git rm -rf foldername.
> So now i have to branches, A with the folder and B without the folder.
>
> I'm on B, the folder is not there.
> Then I check out A, the folder shows up like it should.
> When I check out B again, the folder is still there.
Is there anything in the folder, like untracked files generated by your
build process? Remember that git tracks full paths, not directories. So
you never actually "deleted a folder" but rather deleted all of the
paths inside that folder.
When you switch to branch A, git creates the folder, because it contains
tracked files. When you switch back to branch B, git will remove the
tracked files, and will remove the directory _only_ if it is then empty.
Anything else would mean deleting your untracked files, which may be
precious.
You mentioned in a later email that you were having trouble reproducing
the issue. Try:
$ git checkout A
$ make ;# or whatever your build process is, or
;# normal work or whatever
$ git checkout B
and see if that reproduces it.
-Peff
^ permalink raw reply
* Re: [BUG] 'add -u' doesn't work from untracked subdir
From: SZEDER Gábor @ 2009-09-04 8:32 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20090902081917.GA5447@coredump.intra.peff.net>
[Oops, I 've just noticed that my reply to Jeff didn't made it to the
git list, because I hit 'reply' instead of 'reply to all'...]
Hi Jeff,
thanks for your quick reply.
On Wed, Sep 02, 2009 at 04:19:17AM -0400, Jeff King wrote:
> On Wed, Sep 02, 2009 at 10:03:05AM +0200, SZEDER Gábor wrote:
>
> > As the subject says, 'git add -u' does not work from an untracked
> > subdir, because it doesn't add modified files to the index. The
> > following script reproduces the issue:
> >
> > mkdir repo
> > cd repo
> > git init
> > echo 1 >foo
> > git add foo
> > git commit -m first
> > echo 2 >foo
> > mkdir untracked_subdir
> > cd untracked_subdir
> > git add -u
> > git diff
> >
> > It worked in the initial 'git add -u' implementation (dfdac5d,
> > git-add
> > -u: match the index with working tree, 2007-04-20), but 2ed2c222
> > (git-add -u paths... now works from subdirectory, 2007-08-16)
> > broke it
> > later, and is broken ever since.
>
> It is not just untracked subdirs. Try:
>
> mkdir repo && cd repo && git init
> echo 1 >foo
> mkdir subdir
> echo 1 >subdir/bar
> git add . && git commit -m first
> echo 2 >foo
> echo 2 >subdir/bar
> cd subdir
> git add -u
> git diff ;# still shows foo/1 in index
> git diff --cached ;# shows subdir/bar was updated
>
> While I have sometimes found the behavior a bit annoying[1], I
> always
> assumed that was the intended behavior.
>
> And indeed, in modern builtin-add.c, we find this:
>
> if ((addremove || take_worktree_changes) && !argc) {
> static const char *here[2] = { ".", NULL };
> argc = 1;
> argv = here;
> }
>
> which seems pretty explicit.
Since then I looked at the man page (I should have done that right
away ;), and it says under the description of -u that "If no paths are
specified, all tracked files in the current directory and its
subdirectories are updated." So this is indeed the intended
behaviour, but I was just not aware of it. Oh well, sorry for the
noise.
> [1] I would prefer "git add -u ." to add only the current directory,
> and
> "git add -u" to touch everything. But then, I am one of the people
> who
> turn off status.relativepaths, so I think I may be in the minority
> in
> always wanting to think of the project as a whole.
I don't really know which would I prefer.
I was updating some Javadoc documentation in Eclipse, and checking the
generated docs in terminal, deep down in an untracked subdir, and
performed some 'add -u ; commit --amend' from there (and was rather
surprised after the fifth amend to see all the changes still in the
worktree). Doing perform the desired add -u from there I should have
run 'git add -u ../../../../../..', what doesn't seem very convenient.
But since this was the first time I've done that since 2007-08-16, I
guess it's not a very common use case.
Gábor
^ permalink raw reply
* Re: Deleted folder keeps showing up?
From: Junio C Hamano @ 2009-09-04 8:36 UTC (permalink / raw)
To: Benjamin Buch; +Cc: Michael J Gruber, git
In-Reply-To: <8E56979B-5D85-4844-A492-8149EE9E9B2F@gmx.de>
Benjamin Buch <benni.buch@gmx.de> writes:
> Strangely, I can't reproduce the error today.
If a branch has dir/file tracked, and another branch does not have
anything tracked in dir/ directory at all, then switching from the former
branch to the latter can remove dir/ only when you do not have any
untracked files in there when you switch. Otherwise dir/ must stay
behind to keep the untracked files.
You can see it by a simple experiment.
$ rm -fr trial
$ mkdir trial
$ cd trial
$ git init
$ >elif
$ git commit -m initial
$ git branch lacksdir
$ mkdir dir
$ >dir/file
$ git add dir/file
$ git commit -m add-dir-file
Now, after this set-up, your 'master' has dir/file and 'lacksdir' does
not have anything tracked in dir/ directory.
Observe:
$ git checkout lacksdir
$ find ??*
elif
$ git checkout master
$ find ??*
dir
dir/file
elif
$ >dir/garbage
$ git checkout lacksdir
$ find ??*
dir
dir/garbage
elif
If switching to 'lacksdir' removed the dir/ directory, whatever was in the
untracked file dir/garbage will be lost. In the above exercise, I named
it garbage, so a casual reader might get a false impression that it should
be thrown away, but in real life workflow, it often happens that
(1) you start doing some interesting experimental changes, while on
'master';
(2) you realize that this change does not belong to 'master', but belongs
to some other branch, perhaps 'lacksdir';
(3) you switch to the branch, to keep working.
Remember that, in git, your uncommitted changes to the index and the work
tree do not belong to the branch. They try to follow you across branch
switching. Since untracked new files are something potentially you might
want to add after branch switching, we do not remove them. And because we
choose not to remove dir/file, even though the commit at the tip of the
lacksdir branch does not have anything tracked in dir/ directory, we
cannot remove it from the work tree.
^ permalink raw reply
* Re: [PATCHv2] git-config: Parse config files leniently
From: Junio C Hamano @ 2009-09-04 8:40 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <4AA0BE30.1030408@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
>> *2* Worse yet, the parsing of branch.autosetuprebase is part of the
>> default_config and commands that do not have anything to do with new
>> branch creation will fail with the current setup.
>
> Thanks for the thorough explanations. Especially *2* makes me think that
> quite some restructuring would be necessary in order to "do it right".
We need to distinguish at least the "syntax" and "semantics" errors, i.e.
not necessarily "do it right", but "how your patch should have looked
like".
I think a slightly hacky but practical workaround then becomes possible.
We can have a config callback function to parse only core.editor (and
perhaps some other very minimum set of variables needed to launch the
editor on the right config file) extremely loosely, i.e. not even calling
git_config_string() to complain about error-nonbool. You can use the
callback _only_ from the ACTION_EDIT codepath in builtin-config.c (which
currently uses git_default_config and errors out when some uninteresting
configuration variables have semantic errors).
That would get rid of the issue that the configuration mechanism triggers
semantic errors for unrelated variables, and would give us a usable
recovery editor, no?
^ permalink raw reply
* Re: [PATCH 1/8] Make the "traditionally-supported" URLs a special case
From: Mike Ralphson @ 2009-09-04 9:04 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LNX.2.00.0909032213180.28290@iabervon.org>
2009/9/4 Daniel Barkalow <barkalow@iabervon.org>:
> Instead of trying to make http://, https://, and ftp:// URLs
> indicative of some sort of pattern of transport helper usage, make
> them a special case which runs the "curl" helper, and leave the
> mechanism by which arbitrary helpers will be chosen entirely to future
> work.
> - PROGRAMS += git-remote-http$X $(CURL_SYNONYMS) git-http-fetch$X
> + PROGRAMS += git-remote-curl$X git-http-fetch$X
I think .gitignore would need to be updated again with the added and
removed executables?
Mike
^ permalink raw reply
* [PATCH 1/2] git: add new option --no-git-dir
From: Gerrit Pape @ 2009-09-04 9:29 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Junio C Hamano, git
In-Reply-To: <fabb9a1e0909020447p212594cake8c6fe3a43b667ec@mail.gmail.com>
This commit adds the --no-git-dir option to the git program. Setting
this option prevents the git program from searching for a path to a git
repository, which can be useful for commands that do not require one.
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
Documentation/git.txt | 6 +++++-
git.c | 6 +++++-
setup.c | 2 ++
3 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/Documentation/git.txt b/Documentation/git.txt
index ad44cac..6327203 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -11,7 +11,7 @@ SYNOPSIS
[verse]
'git' [--version] [--exec-path[=GIT_EXEC_PATH]] [--html-path]
[-p|--paginate|--no-pager]
- [--bare] [--git-dir=GIT_DIR] [--work-tree=GIT_WORK_TREE]
+ [--bare] [--git-dir=GIT_DIR|--no-git-dir] [--work-tree=GIT_WORK_TREE]
[--help] COMMAND [ARGS]
DESCRIPTION
@@ -212,6 +212,10 @@ help ...`.
setting the GIT_DIR environment variable. It can be an absolute
path or relative path to current working directory.
+--no-git-dir::
+ Do not set a path to a repository, and do not try to find one.
+ Setting this option is equivalent to setting --git-dir="".
+
--work-tree=<path>::
Set the path to the working tree. The value will not be
used in combination with repositories found automatically in
diff --git a/git.c b/git.c
index 0b22595..8e060b9 100644
--- a/git.c
+++ b/git.c
@@ -5,7 +5,7 @@
#include "run-command.h"
const char git_usage_string[] =
- "git [--version] [--exec-path[=GIT_EXEC_PATH]] [--html-path] [-p|--paginate|--no-pager] [--bare] [--git-dir=GIT_DIR] [--work-tree=GIT_WORK_TREE] [--help] COMMAND [ARGS]";
+ "git [--version] [--exec-path[=GIT_EXEC_PATH]] [--html-path] [-p|--paginate|--no-pager] [--bare] [--git-dir=GIT_DIR|--no-git-dir] [--work-tree=GIT_WORK_TREE] [--help] COMMAND [ARGS]";
const char git_more_info_string[] =
"See 'git help COMMAND' for more information on a specific command.";
@@ -99,6 +99,10 @@ static int handle_options(const char ***argv, int *argc, int *envchanged)
setenv(GIT_DIR_ENVIRONMENT, cmd + 10, 1);
if (envchanged)
*envchanged = 1;
+ } else if (!strcmp(cmd, "--no-git-dir")) {
+ setenv(GIT_DIR_ENVIRONMENT, "", 1);
+ if (envchanged)
+ *envchanged = 1;
} else if (!strcmp(cmd, "--work-tree")) {
if (*argc < 2) {
fprintf(stderr, "No directory given for --work-tree.\n" );
diff --git a/setup.c b/setup.c
index e3781b6..ee9be6e 100644
--- a/setup.c
+++ b/setup.c
@@ -335,6 +335,8 @@ const char *setup_git_directory_gently(int *nongit_ok)
*nongit_ok = 1;
return NULL;
}
+ if (!*gitdirenv)
+ die("This command requires a git repository");
die("Not a git repository: '%s'", gitdirenv);
}
--
1.6.0.3
^ permalink raw reply related
* [PATCH 2/2] git-completion.bash: prevent 'git help' from searching for git repository
From: Gerrit Pape @ 2009-09-04 9:29 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Junio C Hamano, git
In-Reply-To: <fabb9a1e0909020447p212594cake8c6fe3a43b667ec@mail.gmail.com>
On 'git <TAB><TAB>' the bash completion runs 'git help -a'. Since 'git
help' actually doesn't need to be run inside a git repository, this
commit uses the --no-git-dir option to prevent it from searching a git
directory. Unnecessary searching for a git directory can be annoying in
auto-mount environments.
The annoying behavior and suggested fix has been reported by Vincent
Danjean through
http://bugs.debian.org/539273
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
contrib/completion/git-completion.bash | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index bf688e1..a55e3cd 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -500,7 +500,7 @@ __git_all_commands ()
return
fi
local i IFS=" "$'\n'
- for i in $(git help -a|egrep '^ ')
+ for i in $(git --no-git-dir help -a|egrep '^ ')
do
case $i in
*--*) : helper pattern;;
--
1.6.0.3
^ permalink raw reply related
* Re: [PATCH] git-completion.bash: prevent 'git help' from searching for git repository
From: Rogan Dawes @ 2009-09-04 9:43 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Gerrit Pape, Junio C Hamano, git
In-Reply-To: <fabb9a1e0909020447p212594cake8c6fe3a43b667ec@mail.gmail.com>
Sverre Rabbelier wrote:
> Heya,
>
> On Wed, Sep 2, 2009 at 11:58, Gerrit Pape<pape@smarden.org> wrote:
>> + for i in $(git --git-dir=/nonexistent help -a|egrep '^ ')
>
> Wouldn't implementing "git --no-git-dir" be more appropriate?
>
Or documenting which git commands do/don't require a git dir at all?
I assume that documenting those that don't would be better than
documenting those that do . . .
And by documenting, I mean in the code, so that the code can DTRT.
Otherwise, having this switch lets people shoot themselves in the foot,
I'd think.
Rogan
^ permalink raw reply
* Re: [PATCH 2/2] git-completion.bash: prevent 'git help' from searching for git repository
From: Junio C Hamano @ 2009-09-04 9:57 UTC (permalink / raw)
To: Gerrit Pape; +Cc: Sverre Rabbelier, git
In-Reply-To: <20090904092929.23208.qmail@00cf3567a0e8b4.315fe32.mid.smarden.org>
Gerrit Pape <pape@smarden.org> writes:
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index bf688e1..a55e3cd 100755
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -500,7 +500,7 @@ __git_all_commands ()
> return
> fi
> local i IFS=" "$'\n'
> - for i in $(git help -a|egrep '^ ')
> + for i in $(git --no-git-dir help -a|egrep '^ ')
Thanks.
What the --no-git-dir option actually does is "pretend that cwd is the git
directory but do not worry if it is not", which is different from "there
is no git directory, so do not barf as long as you do not need to access
git-dir". The latter is what the name implies, and also additionally it
implies "but please do barf if you ever need to access something from git
directory." I do not know if that holds true with your Patch 1/2, and I
am a bit too tired to check.
Besides, "git --git-dir=." is shorter to type, and it is equally magical
that the user has to know about it anyway. Hopefully, most of the time
the end user would not have to use it directly, and the only demonstrated
use case is here in this completion script.
Would it be an option to chuck the Patch 1/2 at least for now and instead
say "git --git-dir=. help -a" here in this patch?
^ permalink raw reply
* Re: [PATCH 2/2] git-completion.bash: prevent 'git help' from searching for git repository
From: Johannes Schindelin @ 2009-09-04 10:22 UTC (permalink / raw)
To: Gerrit Pape; +Cc: Sverre Rabbelier, Junio C Hamano, git
In-Reply-To: <20090904092929.23208.qmail@00cf3567a0e8b4.315fe32.mid.smarden.org>
Hi,
On Fri, 4 Sep 2009, Gerrit Pape wrote:
> On 'git <TAB><TAB>' the bash completion runs 'git help -a'.
Correct me if I am wrong, but does "git help -a" not list aliases? If it
does, "git help" must search for the Git repository.
If it does not, then "git help" needs fixing, not the completions. I.e.
something like this:
-- snipsnap --
[PATCH] git help -a: do not look for a repository
<all the acknowledgements go here>
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
builtin-help.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/builtin-help.c b/builtin-help.c
index e1eba77..719aa23 100644
--- a/builtin-help.c
+++ b/builtin-help.c
@@ -416,9 +416,6 @@ int cmd_help(int argc, const char **argv, const char *prefix)
const char *alias;
load_command_list("git-", &main_cmds, &other_cmds);
- setup_git_directory_gently(&nongit);
- git_config(git_help_config, NULL);
-
argc = parse_options(argc, argv, prefix, builtin_help_options,
builtin_help_usage, 0);
@@ -429,6 +426,9 @@ int cmd_help(int argc, const char **argv, const char *prefix)
return 0;
}
+ setup_git_directory_gently(&nongit);
+ git_config(git_help_config, NULL);
+
if (!argv[0]) {
printf("usage: %s\n\n", git_usage_string);
list_common_cmds_help();
^ permalink raw reply related
* Re: Issue 323 in msysgit: Can't clone over http
From: Junio C Hamano @ 2009-09-04 10:25 UTC (permalink / raw)
To: git, Tay Ray Chuan; +Cc: msysgit
In-Reply-To: <0016e6470f36315b8a0472bc75a8@google.com>
codesite-noreply@google.com writes:
> Status: New
> Owner: ----
>
> New issue 323 by bjelli: Can't clone over http
> http://code.google.com/p/msysgit/issues/detail?id=323
>
> What steps will reproduce the problem?
> 1.Install Git-1.6.4-preview20090730.exe
> 2.Clone exsiting repository http://github.com/tekkub/addontemplate.git
This does not seem to be an msysgit issue. Even on a Linux host, v1.6.2.5
seems to work Ok but 'maint', 'master', nor 'next' does not clone this one
correctly.
> Output:
> got 2c8851d269d51676b8c626e63991ee68a6f5d578
> walk 2c8851d269d51676b8c626e63991ee68a6f5d578
> got 758419d18ad255c3417ca341c6e12c6ca1aa203e
> got fa8a1ec5a791c245789f70e90a844f2b9a275991
> walk fa8a1ec5a791c245789f70e90a844f2b9a275991
> got e884a228df0e08e0f862edab6012d8407907ab48
> got f7ea166470af2538a6a19642f8c45213bac7bd40
> got 6100842656e95bf50f2c6f3ff6e997bcbe2474cc
> got 445c0ea7c7193f6fcb42b32db50104926d328322
> got a44d6309e48622590b2780f96bed371122db6b71
> got 3ecefa3f04f394f64f8fe7be14ac20e69f2f2c18
> Getting alternates list for http://github.com/tekkub/addontemplate.git
> Getting pack list for http://github.com/tekkub/addontemplate.git
> error: Unable to verify pack 382c25c935b744e909c749532578112d72a4aff9 is
> available
> error: Unable to find 0a41ac04d56ccc96491989dc71d9875cd804fc6b under
> http://github.com/tekkub/addontemplate.git
> Cannot obtain needed blob 0a41ac04d56ccc96491989dc71d9875cd804fc6b
> while processing commit fa8a1ec5a791c245789f70e90a844f2b9a275991.
> fatal: Fetch failed.
>
> What version of the product are you using? On what operating system?
> Git-1.6.4-preview20090730.exe
> Windows XP
>
> Please provide any additional information below.
> Defect was discussed on the github support board here:
> http://support.github.com/discussions/repos/957-cant-clone-over-http-or-git
^ 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