* Re: [PATCH v2] Fix fetch/pull when run without --update-head-ok
From: Daniel Barkalow @ 2008-10-13 17:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster, spearce
In-Reply-To: <alpine.DEB.1.00.0810131129110.22125@pacific.mpi-cbg.de.mpi-cbg.de>
On Mon, 13 Oct 2008, Johannes Schindelin wrote:
>
> Some confusing tutorials suggested that it would be a good idea to fetch
> into the current branch with something like this:
>
> git fetch origin master:master
>
> (or even worse: the same command line with "pull" instead of "fetch").
> While it might make sense to store what you want to pull, it typically
> is plain wrong when the current branch is "master".
>
> As noticed by Junio, this behavior should be triggered by _not_ passing
> the --update-head-ok option, but somewhere along the lines we lost that
> behavior.
>
> NOTE: this patch does not completely resurrect the original behavior
> without --update-head-ok: the check for the current branch is now _only_
> performed in non-bare repositories.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Acked-by: Daniel Barkalow <barkalow@iabervon.org>
^ permalink raw reply
* Re: [JGIT PATCH 0/5] Support receive.fsckobjects
From: Shawn O. Pearce @ 2008-10-13 16:54 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <1223916746-11262-1-git-send-email-spearce@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> wrote:
> This series adds support for receive.fsckobjects, but on the fetch
Sorry for the noise. Left over cover letter from a prior series.
/me adds a check for that to his format-patch wrapper...
--
Shawn.
^ permalink raw reply
* [JGIT PATCH] Add bundle creation support
From: Shawn O. Pearce @ 2008-10-13 16:52 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <1223916746-11262-1-git-send-email-spearce@spearce.org>
BundleWriter offers a safe API to create new bundles.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
I wrote this a while back but haven't had a chance to write unit
tests for it. It may be worthwhile including as it looks to be
obviously correct and is probably necessary to create pure Java
based unit tests for the bundle fetch transport.
.../org/spearce/jgit/transport/BundleWriter.java | 196 ++++++++++++++++++++
1 files changed, 196 insertions(+), 0 deletions(-)
create mode 100644 org.spearce.jgit/src/org/spearce/jgit/transport/BundleWriter.java
diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/BundleWriter.java b/org.spearce.jgit/src/org/spearce/jgit/transport/BundleWriter.java
new file mode 100644
index 0000000..f0fbd37
--- /dev/null
+++ b/org.spearce.jgit/src/org/spearce/jgit/transport/BundleWriter.java
@@ -0,0 +1,196 @@
+/*
+ * Copyright (C) 2008, Google Inc.
+ *
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ * - Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ *
+ * - Redistributions in binary form must reproduce the above
+ * copyright notice, this list of conditions and the following
+ * disclaimer in the documentation and/or other materials provided
+ * with the distribution.
+ *
+ * - Neither the name of the Git Development Community nor the
+ * names of its contributors may be used to endorse or promote
+ * products derived from this software without specific prior
+ * written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ * CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
+ * CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
+ * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
+ * ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+package org.spearce.jgit.transport;
+
+import java.io.BufferedOutputStream;
+import java.io.IOException;
+import java.io.OutputStream;
+import java.io.OutputStreamWriter;
+import java.io.Writer;
+import java.util.HashSet;
+import java.util.Map;
+import java.util.Set;
+import java.util.TreeMap;
+
+import org.spearce.jgit.lib.AnyObjectId;
+import org.spearce.jgit.lib.Constants;
+import org.spearce.jgit.lib.ObjectId;
+import org.spearce.jgit.lib.PackWriter;
+import org.spearce.jgit.lib.ProgressMonitor;
+import org.spearce.jgit.lib.Ref;
+import org.spearce.jgit.lib.Repository;
+import org.spearce.jgit.revwalk.RevCommit;
+
+/**
+ * Creates a Git bundle file, for sneaker-net transport to another system.
+ * <p>
+ * Bundles generated by this class can be later read in from a file URI using
+ * the bundle transport, or from an application controlled buffer by the more
+ * generic {@link TransportBundleStream}.
+ * <p>
+ * Applications creating bundles need to call one or more <code>include</code>
+ * calls to reflect which objects should be available as refs in the bundle for
+ * the other side to fetch. At least one include is required to create a valid
+ * bundle file, and duplicate names are not permitted.
+ * <p>
+ * Optional <code>assume</code> calls can be made to declare commits which the
+ * recipient must have in order to fetch from the bundle file. Objects reachable
+ * from these assumed commits can be used as delta bases in order to reduce the
+ * overall bundle size.
+ */
+public class BundleWriter {
+ private final PackWriter packWriter;
+
+ private final Map<String, ObjectId> include;
+
+ private final Set<RevCommit> assume;
+
+ /**
+ * Create a writer for a bundle.
+ *
+ * @param repo
+ * repository where objects are stored.
+ * @param monitor
+ * operations progress monitor.
+ */
+ public BundleWriter(final Repository repo, final ProgressMonitor monitor) {
+ packWriter = new PackWriter(repo, monitor);
+ include = new TreeMap<String, ObjectId>();
+ assume = new HashSet<RevCommit>();
+ }
+
+ /**
+ * Include an object (and everything reachable from it) in the bundle.
+ *
+ * @param name
+ * name the recipient can discover this object as from the
+ * bundle's list of advertised refs . The name must be a valid
+ * ref format and must not have already been included in this
+ * bundle writer.
+ * @param id
+ * object to pack. Multiple refs may point to the same object.
+ */
+ public void include(final String name, final AnyObjectId id) {
+ if (!Repository.isValidRefName(name))
+ throw new IllegalArgumentException("Invalid ref name: " + name);
+ if (include.containsKey(name))
+ throw new IllegalStateException("Duplicate ref: " + name);
+ include.put(name, id.toObjectId());
+ }
+
+ /**
+ * Include a single ref (a name/object pair) in the bundle.
+ * <p>
+ * This is a utility function for:
+ * <code>include(r.getName(), r.getObjectId())</code>.
+ *
+ * @param r
+ * the ref to include.
+ */
+ public void include(final Ref r) {
+ include(r.getName(), r.getObjectId());
+ }
+
+ /**
+ * Assume a commit is available on the recipient's side.
+ * <p>
+ * In order to fetch from a bundle the recipient must have any assumed
+ * commit. Each assumed commit is explicitly recorded in the bundle header
+ * to permit the recipient to validate it has these objects.
+ *
+ * @param c
+ * the commit to assume being available. This commit should be
+ * parsed and not disposed in order to maximize the amount of
+ * debugging information available in the bundle stream.
+ */
+ public void assume(final RevCommit c) {
+ if (c != null)
+ assume.add(c);
+ }
+
+ /**
+ * Generate and write the bundle to the output stream.
+ * <p>
+ * This method can only be called once per BundleWriter instance.
+ *
+ * @param os
+ * the stream the bundle is written to. If the stream is not
+ * buffered it will be buffered by the writer. Caller is
+ * responsible for closing the stream.
+ * @throws IOException
+ * an error occurred reading a local object's data to include in
+ * the bundle, or writing compressed object data to the output
+ * stream.
+ */
+ public void writeBundle(OutputStream os) throws IOException {
+ if (!(os instanceof BufferedOutputStream))
+ os = new BufferedOutputStream(os);
+
+ final HashSet<ObjectId> inc = new HashSet<ObjectId>();
+ final HashSet<ObjectId> exc = new HashSet<ObjectId>();
+ inc.addAll(include.values());
+ for (final RevCommit r : assume)
+ exc.add(r.getId());
+ packWriter.preparePack(inc, exc, exc.size() > 0, true);
+
+ final Writer w = new OutputStreamWriter(os, Constants.CHARSET);
+ w.write(TransportBundle.V2_BUNDLE_SIGNATURE);
+ w.write('\n');
+
+ final char[] tmp = new char[Constants.OBJECT_ID_LENGTH * 2];
+ for (final RevCommit a : assume) {
+ w.write('-');
+ a.copyTo(tmp, w);
+ if (a.getRawBuffer() != null) {
+ w.write(' ');
+ w.write(a.getShortMessage());
+ }
+ w.write('\n');
+ }
+ for (final Map.Entry<String, ObjectId> e : include.entrySet()) {
+ e.getValue().copyTo(tmp, w);
+ w.write(' ');
+ w.write(e.getKey());
+ w.write('\n');
+ }
+
+ w.write('\n');
+ w.flush();
+ packWriter.writePack(os);
+ }
+}
--
1.6.0.2.706.g340fc
^ permalink raw reply related
* [JGIT PATCH 0/5] Support receive.fsckobjects
From: Shawn O. Pearce @ 2008-10-13 16:52 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
This series adds support for receive.fsckobjects, but on the fetch
side of the connection. Perhaps it should be transfer.fsckobjects
or fetch.fsckobjects, but git.git doesn't support either of those
right now.
I mainly need this series because I'm fetching out of untrusted
bundles. The content of the bundle has to pass git-fsck for it
to be considered safe.
The ObjectChecker class covers the same rules as git-fsck does, and
is perhaps even stricter on some of the things git-fsck lets slide.
I think git-fsck is too lenient in some areas, and I'd like to try
and improve the rules more in git.git, but I don't have time for
it right now.
Shawn O. Pearce (5):
Expose RawParseUtils.match to application callers
Fix UnpackedObjectLoader.getBytes to return a copy
Object validation tests for "jgit fsck"
Expose the critical receive configuration options to JGit
Honor receive.fsckobjects during any fetch connection
.../org/spearce/jgit/lib/ObjectCheckerTest.java | 1294 ++++++++++++++++++++
.../src/org/spearce/jgit/lib/ObjectChecker.java | 352 ++++++
.../src/org/spearce/jgit/lib/ObjectLoader.java | 7 +-
.../org/spearce/jgit/lib/PackedObjectLoader.java | 7 -
.../src/org/spearce/jgit/lib/RepositoryConfig.java | 10 +
.../src/org/spearce/jgit/lib/TransferConfig.java | 56 +
.../org/spearce/jgit/lib/UnpackedObjectLoader.java | 4 -
.../jgit/transport/BasePackFetchConnection.java | 1 +
.../src/org/spearce/jgit/transport/IndexPack.java | 60 +-
.../src/org/spearce/jgit/transport/Transport.java | 24 +
.../spearce/jgit/transport/TransportBundle.java | 10 +-
.../jgit/transport/WalkFetchConnection.java | 26 +-
.../src/org/spearce/jgit/util/RawParseUtils.java | 23 +-
13 files changed, 1842 insertions(+), 32 deletions(-)
create mode 100644 org.spearce.jgit.test/tst/org/spearce/jgit/lib/ObjectCheckerTest.java
create mode 100644 org.spearce.jgit/src/org/spearce/jgit/lib/ObjectChecker.java
create mode 100644 org.spearce.jgit/src/org/spearce/jgit/lib/TransferConfig.java
^ permalink raw reply
* Re: [PATCH] Introduce core.keepHardLinks
From: Shawn O. Pearce @ 2008-10-13 16:23 UTC (permalink / raw)
To: Stephan Beyer; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <20081013162132.GB20371@leksak.fem-net>
Stephan Beyer <s-beyer@gmx.net> wrote:
> Johannes Schindelin wrote:
> > and I would have expected others to need a lot less arguments
> > to see it that way, too.
>
> Despite the fact that I've never used hardlinks in a git repository, I
> would have expected git to keep them. So I'm one of the "others" who
> thinks this config option is just sane (and should perhaps even be
> enabled by default, if it does not break stuff on file systems that do
> not have a hardlink feature... but ok)
My problem is many users do "cp -rl a b" to clone a->b and hardlink
the working directory. They expect "cd b && git checkout foo" to
then only unlink the paths that differ. Updating the original inode
would break repository a.
Its a change in behavior, to some of our oldest users. So it can't
really be on by default.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Introduce core.keepHardLinks
From: Stephan Beyer @ 2008-10-13 16:21 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Shawn O. Pearce, git
In-Reply-To: <alpine.DEB.1.00.0810131611470.22125@pacific.mpi-cbg.de.mpi-cbg.de>
Hi,
Johannes Schindelin wrote:
> and I would have expected others to need a lot less arguments
> to see it that way, too.
Despite the fact that I've never used hardlinks in a git repository, I
would have expected git to keep them. So I'm one of the "others" who
thinks this config option is just sane (and should perhaps even be
enabled by default, if it does not break stuff on file systems that do
not have a hardlink feature... but ok)
Regards,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: [PATCH] Introduce core.keepHardLinks
From: Johannes Schindelin @ 2008-10-13 16:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, git
In-Reply-To: <7vskr0bnlk.fsf@gitster.siamese.dyndns.org>
Hi,
On Mon, 13 Oct 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> I cannot fathom why a user wants this much rope to hang themselves
> >> with...
> >
> > The question is not so much why anyone want to do this, but _if_.
>
> Sorry, I think the question should be _why_.
>
> You can gain a sympathetic "Ah, that is sensible, and 'this much rope to
> hang themselves with' comment was unwarranted" only by answering that
> question.
Okay, here are a couple of reasons:
- all the editors that this guy tested keep the hard links, so it was
kinda hard to understand why Git insists on behaving differently,
- if the user asked for hard links, it is not Git's place to question that
decision,
- and in that user's scenario a certain file has to be shared between
different projects that are all version-controlled with Git, but in
different teams and with different servers they connect to. So no, you
cannot even make a submodule of it, because the guys involved do not
share any repository/server access. Besides, submodules are not
user-friendly enough yet.
Oh, and come to think of it, this could solve the old issue of "I want to
track only a few files in my $HOME/".
Anyway, I think that breaking hard links is not a nice habit of Git (after
all, from the user's point of view the file is not created, but
modified!), and I would have expected others to need a lot less arguments
to see it that way, too.
Ciao,
Dscho
^ permalink raw reply
* Re: tip tree clone fail
From: H. Peter Anvin @ 2008-10-13 15:59 UTC (permalink / raw)
To: Wang Chen
Cc: Ingo Molnar, Petr Baudis, Thomas Gleixner, FNST-Lai Jiangshan,
FJ-KOSAKI Motohiro, git, Junio C Hamano
In-Reply-To: <48F3178A.50106@cn.fujitsu.com>
Wang Chen wrote:
>
> Ingo, thank you for your work.
> I can clone more, but error still occurs:
>
> Getting alternates list for http://www.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-tip.git
> Also look at http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
> Also look at http://www.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git/
> Getting pack list for http://www.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-tip.git
> error: transfer closed with 8280 bytes remaining to read
> Getting pack list for http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
> Getting pack list for http://www.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git/
> error: Unable to find 95630fe2917f805a26f8d8beaafb80cd2f729eb5 under http://www.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-tip.git
> Cannot obtain needed object 95630fe2917f805a26f8d8beaafb80cd2f729eb5
I cleaned it up and it should work now.
-hpa
^ permalink raw reply
* [PATCH v2] describe: Make --tags and --all match lightweight tags more often
From: Shawn O. Pearce @ 2008-10-13 14:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Pierre Habouzit, Erez Zilber, Uwe Kleine-K�nig
In-Reply-To: <20081010171217.GB29028@artemis.corp>
If the caller supplies --tags they want the lightweight, unannotated
tags to be searched for a match. If a lightweight tag is closer
in the history, it should be matched, even if an annotated tag is
reachable further back in the commit chain.
The same applies with --all when matching any other type of ref.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Acked-By: Uwe Kleine-K�nig <ukleinek@strlen.de>
---
Changes since v1 of this patch:
- Documentation updates were added.
- Comment for "tags" flag modified per Uwe's suggestion.
Documentation/git-describe.txt | 9 +++++++--
builtin-describe.c | 6 ++----
t/t6120-describe.sh | 8 ++++----
3 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt
index c4dbc2a..40e061f 100644
--- a/Documentation/git-describe.txt
+++ b/Documentation/git-describe.txt
@@ -18,6 +18,9 @@ shown. Otherwise, it suffixes the tag name with the number of
additional commits on top of the tagged object and the
abbreviated object name of the most recent commit.
+By default (without --all or --tags) `git describe` only shows
+annotated tags. For more information about creating annoated tags
+see the -a and -s options to linkgit:git-tag[1].
OPTIONS
-------
@@ -26,11 +29,13 @@ OPTIONS
--all::
Instead of using only the annotated tags, use any ref
- found in `.git/refs/`.
+ found in `.git/refs/`. This option enables matching
+ any known branch, remote branch, or lightweight tag.
--tags::
Instead of using only the annotated tags, use any tag
- found in `.git/refs/tags`.
+ found in `.git/refs/tags`. This option enables matching
+ a lightweight (non-annotated) tag.
--contains::
Instead of finding the tag that predates the commit, find
diff --git a/builtin-describe.c b/builtin-describe.c
index ec404c8..d2cfb1b 100644
--- a/builtin-describe.c
+++ b/builtin-describe.c
@@ -15,8 +15,8 @@ static const char * const describe_usage[] = {
};
static int debug; /* Display lots of verbose info */
-static int all; /* Default to annotated tags only */
-static int tags; /* But allow any tags if --tags is specified */
+static int all; /* Any valid ref can be used */
+static int tags; /* Allow lightweight tags */
static int longformat;
static int abbrev = DEFAULT_ABBREV;
static int max_candidates = 10;
@@ -112,8 +112,6 @@ static int compare_pt(const void *a_, const void *b_)
{
struct possible_tag *a = (struct possible_tag *)a_;
struct possible_tag *b = (struct possible_tag *)b_;
- if (a->name->prio != b->name->prio)
- return b->name->prio - a->name->prio;
if (a->depth != b->depth)
return a->depth - b->depth;
if (a->found_order != b->found_order)
diff --git a/t/t6120-describe.sh b/t/t6120-describe.sh
index 16cc635..e6c9e59 100755
--- a/t/t6120-describe.sh
+++ b/t/t6120-describe.sh
@@ -91,10 +91,10 @@ check_describe D-* HEAD^^
check_describe A-* HEAD^^2
check_describe B HEAD^^2^
-check_describe A-* --tags HEAD
-check_describe A-* --tags HEAD^
-check_describe D-* --tags HEAD^^
-check_describe A-* --tags HEAD^^2
+check_describe c-* --tags HEAD
+check_describe c-* --tags HEAD^
+check_describe e-* --tags HEAD^^
+check_describe c-* --tags HEAD^^2
check_describe B --tags HEAD^^2^
check_describe B-0-* --long HEAD^^2^
--
1.6.0.2.706.g340fc
--
Shawn.
^ permalink raw reply related
* Re: [RFC PATCH] describe: Make --tags and --all match lightweight tags more often
From: Shawn O. Pearce @ 2008-10-13 14:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pierre Habouzit, git, Erez Zilber
In-Reply-To: <7vwsggl3ep.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
>
> The primary mode of operation without --tags of "describe" is about coming
> up with version numbers, and as such, it should try to base its output on
> immutable anchors as much as possible. For that reason, I think it should
> use "tag " line from the tag object, not the name of the ref, to describe
> the committish. They should match (otherwise fsck would say something
> about it) in practice, though...
FWIW the use of "tag " line for an annotated tag being output is what
212945d4 (Teach git-describe to verify annotated tag names before
output) was all about. That has been in tree since v1.5.5-rc0~86^2.
So we already are doing (have been doing) exactly what you are
asking for.
Or did I misunderstand you?
--
Shawn.
^ permalink raw reply
* Re: What's cooking in git/spearce.git (Oct 2008, #02; Sun, 12)
From: Junio C Hamano @ 2008-10-13 14:25 UTC (permalink / raw)
To: Stephen Haberman; +Cc: Shawn O. Pearce, git
In-Reply-To: <20081013013752.8fc16695.stephen@exigencecorp.com>
Stephen Haberman <stephen@exigencecorp.com> writes:
> (I also have a test comment typo and test_expect_failure change to make
> to rebase-i-p from Junio's feedback and would like to know the
> preferred way to submit those--e.g. a patch on top of your pu, a patch
> on top of the existing series, or a new series all together. Given it
> is not next, I'm guessing a new series all together.)
You guessed it right.
As sh/maint-rebase3 is about a pure fix, while the other -i-p is a more
involved enhancement, I am guessing Shawn decided not to queue the latter
for 1.6.0.X, and I agree with that. The final shape of the history should
look like:
* maint will eventually get sh/maint-rebase3 to be in 1.6.0.X, which in
turn will eventually be merged to master;
* master will eventually get sh/rebase-i-p.
When two series have dependencies like this, it is generally the easiest
and cleanest to prepare them to match such a final shape of the history.
Hence, we would want two series built like this:
* sh/maint-rebase3 applicable to the tip of 'maint' (this is already done;
what is in sh/maint-rebase3 is exactly that);
* apply the above locally to 'maint', merge the result locally to
'master', and prepare sh/rebase-i-p series applicable on top of that
merge.
Thanks.
^ permalink raw reply
* Re: [PATCH v2] Fix fetch/pull when run without --update-head-ok
From: Junio C Hamano @ 2008-10-13 14:23 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Daniel Barkalow, git, gitster, spearce
In-Reply-To: <alpine.DEB.1.00.0810131129110.22125@pacific.mpi-cbg.de.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Some confusing tutorials suggested that it would be a good idea to fetch
> into the current branch with something like this:
>
> git fetch origin master:master
>
> (or even worse: the same command line with "pull" instead of "fetch").
> While it might make sense to store what you want to pull, it typically
> is plain wrong when the current branch is "master".
>
> As noticed by Junio, this behavior should be triggered by _not_ passing
> the --update-head-ok option, but somewhere along the lines we lost that
> behavior.
Do you mean, by "this behavior should be triggered", "we should allow
updating the current branch head only when --update-head-ok is given", in
other words, "we should error out if the user tries to update the current
head with git-fetch without passing --update-head-ok"?
> NOTE: this patch does not completely resurrect the original behavior
> without --update-head-ok: the check for the current branch is now _only_
> performed in non-bare repositories.
I think that is a sensible improvement.
> Strangely, some more tests refused to pass this time, because they
> did not use --update-head-ok; this was fixed, too.
We need to look at these changes a bit carefully, as changes to existing
tests can be either (1) fixing those that depended on broken behaviour of
the command, or (2) trying to hide regressions introduced by the patch
under the rug.
> t/t5405-send-pack-rewind.sh | 2 +-
> t/t5505-remote.sh | 2 +-
> t/t5510-fetch.sh | 12 ++++++++++++
> t/t9300-fast-import.sh | 2 +-
I suspect all of these offending tests came after b888d61 (Make fetch a
builtin, 2007-09-10) which lacked the necessary check in do_fetch() to
cause the regression you are fixing (iow, I am suspecting that the
brokenness of the tests were hidden by the breakage you are fixing). The
parts of the tests you fixed came from these:
6738c81 (send-pack: segfault fix on forced push, 2007-11-08)
4ebc914 (builtin-remote: prune remotes correctly ..., 2008-02-29)
4942025 (t5510: test "git fetch" following tags minimally, 2008-09-21)
03db452 (Support gitlinks in fast-import., 2008-07-19)
all of which are indeed descendants of b888d61.
With these verified, I think I should move the "Strangely" comment to the
commit log message proper (after stripping "Strangely" part -- it is not
strange anymore after we understand why).
^ permalink raw reply
* Re: [PATCH v2] Fix fetch/pull when run without --update-head-ok
From: Shawn O. Pearce @ 2008-10-13 14:09 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Daniel Barkalow, git, gitster
In-Reply-To: <alpine.DEB.1.00.0810131129110.22125@pacific.mpi-cbg.de.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> Some confusing tutorials suggested that it would be a good idea to fetch
> into the current branch with something like this:
>
> git fetch origin master:master
>
> (or even worse: the same command line with "pull" instead of "fetch").
> While it might make sense to store what you want to pull, it typically
> is plain wrong when the current branch is "master".
>
> As noticed by Junio, this behavior should be triggered by _not_ passing
> the --update-head-ok option, but somewhere along the lines we lost that
> behavior.
>
> NOTE: this patch does not completely resurrect the original behavior
> without --update-head-ok: the check for the current branch is now _only_
> performed in non-bare repositories.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
> Strangely, some more tests refused to pass this time, because they
> did not use --update-head-ok; this was fixed, too.
Not strange, --update-head-ok was busted and the tests took advantage
of it. :-\
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Introduce core.keepHardLinks
From: Junio C Hamano @ 2008-10-13 14:01 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Shawn O. Pearce, git
In-Reply-To: <alpine.DEB.1.00.0810131057150.22125@pacific.mpi-cbg.de.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> I cannot fathom why a user wants this much rope to hang themselves
>> with...
>
> The question is not so much why anyone want to do this, but _if_.
Sorry, I think the question should be _why_.
You can gain a sympathetic "Ah, that is sensible, and 'this much rope to
hang themselves with' comment was unwarranted" only by answering that
question.
^ permalink raw reply
* Re: [PATCH 3/4] diff: introduce diff.<driver>.binary
From: Junio C Hamano @ 2008-10-13 13:54 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Sixt, Matthieu Moy, git
In-Reply-To: <20081013041525.GA32629@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> It's possible that one could, given the binary preimage and the two
> lossy textconv'd versions, produce a custom binary merge that would just
> munge the tags, or just munge the text, or whatever. But that is an
> order of magnitude more work than writing a textconv, which is usually
> as simple as "/path/to/existing/conversion-script".
>
> And the whole point of this exercise was to make it simple to set this
> conversion up.
>
>> I'd say that format-patch should always disable textconv so that we won't
>> have to worry about it for now.
>
> Agreed, if you remove "for now". I had never intended for these to be
> anything but a human-readable display (and while I am generally OK with
> generalizing functionality when we can, I think there is real value in
> the simplicity here).
Ok. I don't disagree with any of the above.
We however need to make it very clear that reversibility (aka ability to
produce applicable diff) is never the goal of the textconv mechanism (and
suggest your "for applicable and reviewable diff, you produce the standard
binary diff and add the textconv diff as a comment" in the documentation),
as I am quite sure that 6 months down the road somebody who was not
involved in this thread would complain.
^ permalink raw reply
* Re: [PATCHv5 0/5] *** SUBJECT HERE ***
From: Giuseppe Bilotta @ 2008-10-13 11:42 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Petr Baudis, Shawn O. Pearce, Junio C Hamano
In-Reply-To: <200810131300.35309.jnareb@gmail.com>
On Mon, Oct 13, 2008 at 1:00 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> Err... "*** SUBJECT HERE ***"? Not that it matters...
Yeah, I realized that as soon as I sent the thing 8-(
> I like it, and with the exception of the last patch (which looks like
> it doesn't check if $file_name contains '..', even as it checks if
> $file_parent contains '..', and which probably should not esc_url)
Oopsie. I'll get to fix that.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [PATCHv5 0/5] *** SUBJECT HERE ***
From: Jakub Narebski @ 2008-10-13 11:00 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Petr Baudis, Shawn O. Pearce, Junio C Hamano
In-Reply-To: <1223893165-26022-1-git-send-email-giuseppe.bilotta@gmail.com>
Err... "*** SUBJECT HERE ***"? Not that it matters...
On Mon, 13 Oct 2008, Giuseppe Bilotta wrote:
> Fifth attempt for my gitweb PATH_INFO patchset, whose purpose is to
> reduce the use of CGI parameters by embedding as many parameters as
> possible in the URL path itself, provided the pathinfo feature is
> enabled.
[...]
> Giuseppe Bilotta (5):
> gitweb: parse project/action/hash_base:filename PATH_INFO
> gitweb: generate project/action/hash URLs
> gitweb: use_pathinfo filenames start with /
> gitweb: parse parent..current syntax from PATH_INFO
> gitweb: generate parent..current URLs
I like it, and with the exception of the last patch (which looks like
it doesn't check if $file_name contains '..', even as it checks if
$file_parent contains '..', and which probably should not esc_url)
it looks OK. from (superficial) browsing through patches.
I'll try to review them soon.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCHv5 0/5] *** SUBJECT HERE ***
From: Ondrej Certik @ 2008-10-13 10:52 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git
In-Reply-To: <1223893165-26022-1-git-send-email-giuseppe.bilotta@gmail.com>
On Mon, Oct 13, 2008 at 12:19 PM, Giuseppe Bilotta
<giuseppe.bilotta@gmail.com> wrote:
> Fifth attempt for my gitweb PATH_INFO patchset, whose purpose is to
> reduce the use of CGI parameters by embedding as many parameters as
> possible in the URL path itself, provided the pathinfo feature is
> enabled.
>
> The new typical gitweb URL is therefore in the form
>
> $project/$action/$parent:$file..$hash:$file
>
> (with useless parts stripped). Backwards compatibility for old-style
> $project/$hash[:$file] URLs is kept, as long as $hash is not a refname whose
> name happens to match a git action.
Thanks Giuseppe for doing this. I just switched from Mercurial to git
recently and this is one thing that I was missing a lot in git.
Ondrej
^ permalink raw reply
* [PATCHv5 5/5] gitweb: generate parent..current URLs
From: Giuseppe Bilotta @ 2008-10-13 10:19 UTC (permalink / raw)
To: git
Cc: Jakub Narebski, Petr Baudis, Shawn O. Pearce, Junio C Hamano,
Giuseppe Bilotta
In-Reply-To: <1223893165-26022-5-git-send-email-giuseppe.bilotta@gmail.com>
If use_pathinfo is enabled, href now creates links that contain paths in
the form $project/$action/oldhash:/oldname..newhash:/newname for actions
that use hash_parent etc.
If any of the filename contains two consecutive dots, it's kept as a CGI
parameter since the resulting path would otherwise be ambiguous.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 30 +++++++++++++++++++++++++-----
1 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 1a7b0b9..f4642e7 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -759,7 +759,8 @@ sub href (%) {
# try to put as many parameters as possible in PATH_INFO:
# - project name
# - action
- # - hash or hash_base:/filename
+ # - hash_parent or hash_parent_base:/file_parent
+ # - hash or hash_base:/file_name
# When the script is the root DirectoryIndex for the domain,
# $href here would be something like http://gitweb.example.com/
@@ -778,17 +779,36 @@ sub href (%) {
delete $params{'action'};
}
- # Finally, we put either hash_base:/file_name or hash
+ # Next, we put hash_parent_base:/file_parent..hash_base:/file_name,
+ # stripping nonexistent or useless pieces
+ $href .= "/" if ($params{'hash_base'} || $params{'hash_parent_base'}
+ || $params{'hash_parent'} || $params{'hash'});
if (defined $params{'hash_base'}) {
- $href .= "/".esc_url($params{'hash_base'});
- if (defined $params{'file_name'}) {
+ if (defined $params{'hash_parent_base'}) {
+ $href .= esc_url($params{'hash_parent_base'});
+ # skip the file_parent if it's the same as the file_name
+ delete $params{'file_parent'} if $params{'file_parent'} eq $params{'file_name'};
+ if (defined $params{'file_parent'} && $params{'file_parent'} !~ /\.\./) {
+ $href .= ":/".esc_url($params{'file_parent'});
+ delete $params{'file_parent'};
+ }
+ $href .= "..";
+ delete $params{'hash_parent'};
+ delete $params{'hash_parent_base'};
+ } elsif (defined $params{'hash_parent'}) {
+ $href .= esc_url($params{'hash_parent'}). "..";
+ delete $params{'hash_parent'};
+ }
+
+ $href .= esc_url($params{'hash_base'});
+ if (defined $params{'file_name'} && $params{'file_name'} !~ /\.\./) {
$href .= ":/".esc_url($params{'file_name'});
delete $params{'file_name'};
}
delete $params{'hash'};
delete $params{'hash_base'};
} elsif (defined $params{'hash'}) {
- $href .= "/".esc_url($params{'hash'});
+ $href .= esc_url($params{'hash'});
delete $params{'hash'};
}
}
--
1.5.6.5
^ permalink raw reply related
* [PATCHv5 4/5] gitweb: parse parent..current syntax from PATH_INFO
From: Giuseppe Bilotta @ 2008-10-13 10:19 UTC (permalink / raw)
To: git
Cc: Jakub Narebski, Petr Baudis, Shawn O. Pearce, Junio C Hamano,
Giuseppe Bilotta
In-Reply-To: <1223893165-26022-4-git-send-email-giuseppe.bilotta@gmail.com>
This patch makes it possible to use an URL such as
$project/somebranch..otherbranch:/filename to get a diff between
different version of a file. Paths like
$project/$action/somebranch:/somefile..otherbranch:/otherfile are parsed
as well.
All '*diff' actions and in general actions that use $hash_parent[_base]
and $file_parent can now get all of their parameters from PATH_INFO
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 36 ++++++++++++++++++++++++++++++++++--
1 files changed, 34 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 49730f3..1a7b0b9 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -548,7 +548,12 @@ sub evaluate_path_info {
'history',
);
- my ($refname, $pathname) = split(/:/, $path_info, 2);
+ # horrible regexp to catch
+ # [$hash_parent_base[:$file_parent]..]$hash_parent[:$file_name]
+ my ($parentrefname, $parentpathname, $refname, $pathname) =
+ ($path_info =~ /^(?:(.+?)(?::(.+))?\.\.)?(.+?)(?::(.+))?$/);
+
+ # first, analyze the 'current' part
if (defined $pathname) {
# we got "branch:filename" or "branch:dir/"
# we could use git_get_type(branch:pathname), but it needs $git_dir
@@ -557,7 +562,13 @@ sub evaluate_path_info {
$input_params{'action'} ||= "tree";
$pathname =~ s,/$,,;
} else {
- $input_params{'action'} ||= "blob_plain";
+ # the default action depends on whether we had parent info
+ # or not
+ if ($parentrefname) {
+ $input_params{'action'} ||= "blobdiff_plain";
+ } else {
+ $input_params{'action'} ||= "blob_plain";
+ }
}
$input_params{'hash_base'} ||= $refname;
$input_params{'file_name'} ||= $pathname;
@@ -577,6 +588,27 @@ sub evaluate_path_info {
$input_params{'hash'} ||= $refname;
}
}
+
+ # next, handle the 'parent' part, if present
+ if (defined $parentrefname) {
+ # a missing pathspec defaults to the 'current' filename, allowing e.g.
+ # someproject/blobdiff/oldrev..newrev:/filename
+ if ($parentpathname) {
+ $parentpathname =~ s,^/+,,;
+ $parentpathname =~ s,/$,,;
+ $input_params{'file_parent'} ||= $parentpathname;
+ } else {
+ $input_params{'file_parent'} ||= $input_params{'file_name'};
+ }
+ # we assume that hash_parent_base is wanted if a path was specified,
+ # or if the action wants hash_base instead of hash
+ if (defined $input_params{'file_parent'} ||
+ grep($input_params{'action'}, @wants_base)) {
+ $input_params{'hash_parent_base'} ||= $parentrefname;
+ } else {
+ $input_params{'hash_parent'} ||= $parentrefname;
+ }
+ }
}
evaluate_path_info();
--
1.5.6.5
^ permalink raw reply related
* [PATCHv5 1/5] gitweb: parse project/action/hash_base:filename PATH_INFO
From: Giuseppe Bilotta @ 2008-10-13 10:19 UTC (permalink / raw)
To: git
Cc: Jakub Narebski, Petr Baudis, Shawn O. Pearce, Junio C Hamano,
Giuseppe Bilotta
In-Reply-To: <1223893165-26022-1-git-send-email-giuseppe.bilotta@gmail.com>
This patch enables gitweb to parse URLs with more information embedded
in PATH_INFO, reducing the need for CGI parameters. The typical gitweb
path is now $project/$action/$hash_base:$file_name or
$project/$action/$hash
This is mostly backwards compatible with the old-style gitweb paths,
$project/$branch[:$filename], except when it was used to access a branch
whose name matches a gitweb action.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 37 +++++++++++++++++++++++++++++++------
1 files changed, 31 insertions(+), 6 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index c5254af..6d0dc26 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -534,23 +534,48 @@ sub evaluate_path_info {
return if $input_params{'action'};
$path_info =~ s,^\Q$project\E/*,,;
+ # next, check if we have an action
+ my $action = $path_info;
+ $action =~ s,/.*$,,;
+ if (exists $actions{$action}) {
+ $path_info =~ s,^$action/*,,;
+ $input_params{'action'} = $action;
+ }
+
+ # list of actions that want hash_base instead of hash
+ my @wants_base = (
+ 'tree',
+ 'history',
+ );
+
my ($refname, $pathname) = split(/:/, $path_info, 2);
if (defined $pathname) {
- # we got "project.git/branch:filename" or "project.git/branch:dir/"
+ # we got "branch:filename" or "branch:dir/"
# we could use git_get_type(branch:pathname), but it needs $git_dir
$pathname =~ s,^/+,,;
if (!$pathname || substr($pathname, -1) eq "/") {
- $input_params{'action'} = "tree";
+ $input_params{'action'} ||= "tree";
$pathname =~ s,/$,,;
} else {
- $input_params{'action'} = "blob_plain";
+ $input_params{'action'} ||= "blob_plain";
}
$input_params{'hash_base'} ||= $refname;
$input_params{'file_name'} ||= $pathname;
} elsif (defined $refname) {
- # we got "project.git/branch"
- $input_params{'action'} = "shortlog";
- $input_params{'hash'} ||= $refname;
+ # we got "branch". in this case we have to choose if we have to
+ # set hash or hash_base.
+ #
+ # Most of the actions without a pathname only want hash to be
+ # set, except for the ones specified in @wants_base that want
+ # hash_base instead. It should also be noted that hand-crafted
+ # links having 'history' as an action and no pathname or hash
+ # set will fail, but that happens regardless of PATH_INFO.
+ $input_params{'action'} ||= "shortlog";
+ if (grep($input_params{'action'},@wants_base)) {
+ $input_params{'hash_base'} ||= $refname;
+ } else {
+ $input_params{'hash'} ||= $refname;
+ }
}
}
evaluate_path_info();
--
1.5.6.5
^ permalink raw reply related
* [PATCHv5 3/5] gitweb: use_pathinfo filenames start with /
From: Giuseppe Bilotta @ 2008-10-13 10:19 UTC (permalink / raw)
To: git
Cc: Jakub Narebski, Petr Baudis, Shawn O. Pearce, Junio C Hamano,
Giuseppe Bilotta
In-Reply-To: <1223893165-26022-3-git-send-email-giuseppe.bilotta@gmail.com>
When using path info, make filenames start with a / (right after the :
that separates them from the hash base). This minimal change allows
relative navigation to work properly when viewing HTML files in raw
('blob_plain') mode.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 5337d40..49730f3 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -727,7 +727,7 @@ sub href (%) {
# try to put as many parameters as possible in PATH_INFO:
# - project name
# - action
- # - hash or hash_base:filename
+ # - hash or hash_base:/filename
# When the script is the root DirectoryIndex for the domain,
# $href here would be something like http://gitweb.example.com/
@@ -746,11 +746,11 @@ sub href (%) {
delete $params{'action'};
}
- # Finally, we put either hash_base:file_name or hash
+ # Finally, we put either hash_base:/file_name or hash
if (defined $params{'hash_base'}) {
$href .= "/".esc_url($params{'hash_base'});
if (defined $params{'file_name'}) {
- $href .= ":".esc_url($params{'file_name'});
+ $href .= ":/".esc_url($params{'file_name'});
delete $params{'file_name'};
}
delete $params{'hash'};
--
1.5.6.5
^ permalink raw reply related
* [PATCHv5 2/5] gitweb: generate project/action/hash URLs
From: Giuseppe Bilotta @ 2008-10-13 10:19 UTC (permalink / raw)
To: git
Cc: Jakub Narebski, Petr Baudis, Shawn O. Pearce, Junio C Hamano,
Giuseppe Bilotta
In-Reply-To: <1223893165-26022-2-git-send-email-giuseppe.bilotta@gmail.com>
When generating path info URLs, reduce the number of CGI parameters by
embedding action and hash_parent:filename or hash in the path.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 33 ++++++++++++++++++++++++++++++---
1 files changed, 30 insertions(+), 3 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 6d0dc26..5337d40 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -724,14 +724,41 @@ sub href (%) {
my ($use_pathinfo) = gitweb_check_feature('pathinfo');
if ($use_pathinfo) {
- # use PATH_INFO for project name
+ # try to put as many parameters as possible in PATH_INFO:
+ # - project name
+ # - action
+ # - hash or hash_base:filename
+
+ # When the script is the root DirectoryIndex for the domain,
+ # $href here would be something like http://gitweb.example.com/
+ # Thus, we strip any trailing / from $href, to spare us double
+ # slashes in the final URL
+ $href =~ s,/$,,;
+
+ # Then add the project name, if present
$href .= "/".esc_url($params{'project'}) if defined $params{'project'};
delete $params{'project'};
- # Summary just uses the project path URL
- if (defined $params{'action'} && $params{'action'} eq 'summary') {
+ # Summary just uses the project path URL, any other action is
+ # added to the URL
+ if (defined $params{'action'}) {
+ $href .= "/".esc_url($params{'action'}) unless $params{'action'} eq 'summary';
delete $params{'action'};
}
+
+ # Finally, we put either hash_base:file_name or hash
+ if (defined $params{'hash_base'}) {
+ $href .= "/".esc_url($params{'hash_base'});
+ if (defined $params{'file_name'}) {
+ $href .= ":".esc_url($params{'file_name'});
+ delete $params{'file_name'};
+ }
+ delete $params{'hash'};
+ delete $params{'hash_base'};
+ } elsif (defined $params{'hash'}) {
+ $href .= "/".esc_url($params{'hash'});
+ delete $params{'hash'};
+ }
}
# now encode the parameters explicitly
--
1.5.6.5
^ permalink raw reply related
* [PATCHv5 0/5] *** SUBJECT HERE ***
From: Giuseppe Bilotta @ 2008-10-13 10:19 UTC (permalink / raw)
To: git
Cc: Jakub Narebski, Petr Baudis, Shawn O. Pearce, Junio C Hamano,
Giuseppe Bilotta
Fifth attempt for my gitweb PATH_INFO patchset, whose purpose is to
reduce the use of CGI parameters by embedding as many parameters as
possible in the URL path itself, provided the pathinfo feature is
enabled.
The new typical gitweb URL is therefore in the form
$project/$action/$parent:$file..$hash:$file
(with useless parts stripped). Backwards compatibility for old-style
$project/$hash[:$file] URLs is kept, as long as $hash is not a refname whose
name happens to match a git action.
The main implementation is provided by paired patches (#1#2, #4#5)
that implement parsing and generation of the new style URLs.
Patch #3 is a minor improvement to the URL syntax that allows web
sites to be properly browsable in raw mode.
The patchset depends on my previous input parameter handling patch currently
waiting in 'next'.
Giuseppe Bilotta (5):
gitweb: parse project/action/hash_base:filename PATH_INFO
gitweb: generate project/action/hash URLs
gitweb: use_pathinfo filenames start with /
gitweb: parse parent..current syntax from PATH_INFO
gitweb: generate parent..current URLs
gitweb/gitweb.perl | 124 +++++++++++++++++++++++++++++++++++++++++++++++----
1 files changed, 114 insertions(+), 10 deletions(-)
^ permalink raw reply
* Re: tip tree clone fail
From: Wang Chen @ 2008-10-13 9:40 UTC (permalink / raw)
To: Ingo Molnar
Cc: Petr Baudis, H. Peter Anvin, Thomas Gleixner, FNST-Lai Jiangshan,
FJ-KOSAKI Motohiro, git, Junio C Hamano
In-Reply-To: <20081012165954.GA2317@elte.hu>
Ingo Molnar said the following on 2008-10-13 0:59:
> * Petr Baudis <pasky@suse.cz> wrote:
>
>> On Sun, Oct 12, 2008 at 05:24:27PM +0200, Ingo Molnar wrote:
>>> hm, -tip's .git/hooks/post-update already contained this, for the last 2
>>> months:
>>>
>>> exec git update-server-info
>>>
>>> so ... _despite_ us having this in the git repo, the HTTP protocol still
>>> does not work. Why?
>> I think your problem is that HTTP does not know where to look for
>> objects coming from alternates; IIRC this would work if you used
>> relative paths in objects/info/alternates, or you can create
>> objects/info/http-alternates like
>>
>> /pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects
>> /pub/scm/linux/kernel/git/sfr/linux-next.git/objects
>
> ok, i've now set it up like this:
>
> $ pwd
> /pub/scm/linux/kernel/git/x86/linux-2.6-tip.git
>
> $ cat objects/info/alternates
> /home/ftp/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects
> /home/ftp/pub/scm/linux/kernel/git/sfr/linux-next.git/objects
>
> $ cat objects/info/http-alternates
> /pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects
> /pub/scm/linux/kernel/git/sfr/linux-next.git/objects
>
> and i've added "git update-server-info" to hooks/post-receive and made
> it chmod +x.
>
> that should be golden, right? I'm wondering why this isnt in the default
> setup - i've been behind a limited corporate firewall in a former life
> and having HTTP access is indeed very handy and pragmatic. Often hotel
> WLANs are HTTP only as well.
>
> Soapbox: in fact it would be outright stupid to limit the kernel
> source's availability artificially by not making HTTP a tier-one access
> method.
>
> Fighting against HTTP-only firewalls is like constantly pointing it out
> to the popular press that they should say 'cracker' instead of 'hacker'.
> It is pointless and only hurts the availability our own project.
>
Ingo, thank you for your work.
I can clone more, but error still occurs:
Getting alternates list for http://www.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-tip.git
Also look at http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
Also look at http://www.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git/
Getting pack list for http://www.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-tip.git
error: transfer closed with 8280 bytes remaining to read
Getting pack list for http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
Getting pack list for http://www.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git/
error: Unable to find 95630fe2917f805a26f8d8beaafb80cd2f729eb5 under http://www.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-tip.git
Cannot obtain needed object 95630fe2917f805a26f8d8beaafb80cd2f729eb5
^ 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