* Re: Newbie / git / gitosis question
From: Graham Perks @ 2009-08-26 11:54 UTC (permalink / raw)
To: Howard Miller; +Cc: git
In-Reply-To: <26ae428a0908260227k7ac6aeden9a4eae7ee95d4d45@mail.gmail.com>
On Aug 26, 2009, at 4:27 AM, Howard Miller wrote:
> there's one bit that's unclear to me...
>
> git push origin master:refs/heads/master
>
> Would somebody kindly explain (or point to docs) what
> refs/heads/master means?
I wish somehow these refs would be hidden so newbies like me and
everyone I introduce to git didn't have to know about them. They feel
like an "advanced concept", some internal syntax that 99% of users
shouldn't need to know about. When I see a refspec in the help pages
my eyes glaze over!
Graham.
^ permalink raw reply
* Re: [RFC] Use a 16-tree instead of a 256-tree for storing notes
From: Alex Riesen @ 2009-08-26 12:05 UTC (permalink / raw)
To: Johan Herland
Cc: Johannes Schindelin, git, gitster, trast, tavestbo, git,
chriscool, spearce
In-Reply-To: <200908261231.01616.johan@herland.net>
On Wed, Aug 26, 2009 at 12:31, Johan Herland<johan@herland.net> wrote:
> The 256-tree structure is considerably faster than storing all entries in a
This part is confusing. Was 256-tree better (as in "faster") then?
> hash_map. Also, the memory consumption of the 256-tree structure is lower
> than the hash_map, provided that you're only loading a few notes from a
> "properly fanned-out" notes tree (i.e. 100000 notes in a 2/2/36 structure).
> However, in the worst case (loading all 100000 notes), the memory usage of
> the 256-tree structure (62.64 MB) is significantly worse than the hash_map
> approach (10.25 MB).
>
> This patch modifies the 256-tree structure into a 16-tree structure. This
> significantly improves the memory situation. The result uses less memory
> than both the 256-tree structure, and the hash_map approach, with a worst
> case usage of 8.54 MB. Additionally, it seems to slightly improve the
> runtime performance as well (probably because of the improved memory usage).
^ permalink raw reply
* Re: [PATCH] git-bisect: call the found commit "*the* first bad commit"
From: Alex Riesen @ 2009-08-26 12:10 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Nanako Shiraishi, git
In-Reply-To: <alpine.DEB.1.00.0908261207400.4713@intel-tinevez-2-302>
On Wed, Aug 26, 2009 at 12:08, Johannes
Schindelin<Johannes.Schindelin@gmx.de> wrote:
> On Wed, 26 Aug 2009, Junio C Hamano wrote:
>> Nanako Shiraishi <nanako3@lavabit.com> writes:
>>
>> > .. as we learned in the school ;-)
>>
>> Thanks.
>>
>> Is it "learned in school", or do you also need "*the*" there?
>>
>> ;-)
>
> Well, I learnt at school that it is "learnt" and "at school"...
>
> double ;-)
There is not one native speaker in this discussion, BTW :)
http://www.thefreedictionary.com/learn
http://www.thefreedictionary.com/school (look for American
in "Translation")
^ permalink raw reply
* Re: [PATCH] Add option -b/--branch to clone for select a new HEAD
From: Björn Steinbrink @ 2009-08-26 12:16 UTC (permalink / raw)
To: Kirill A. Korinskiy; +Cc: gitster, git
In-Reply-To: <87ljl694fd.wl%catap@catap.ru>
On 2009.08.26 15:53:58 +0400, Kirill A. Korinskiy wrote:
> At Wed, 26 Aug 2009 00:36:37 +0200,
> Björn Steinbrink <B.Steinbrink@gmx.de> wrote:
>
>
> > > @@ -518,7 +521,21 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
> > >
> > > mapped_refs = write_remote_refs(refs, refspec, reflog_msg.buf);
> > >
> > > - remote_head = find_ref_by_name(refs, "HEAD");
> > > + if (option_branch) {
> > > + strbuf_addf(&branch_head, "%s%s", src_ref_prefix, option_branch);
> > > +
> > > + remote_head = find_ref_by_name(refs, branch_head.buf);
> > > + }
> > > +
> > > + if (!remote_head) {
> > > + if (option_branch)
> > > + warning("Remote branch %s not found in upstream %s"
> > > + ", using HEAD instead",
> > > + option_branch, option_origin);
> > > +
> > > + remote_head = find_ref_by_name(refs, "HEAD");
> > > + }
> > > +
> > > head_points_at = guess_remote_head(remote_head, mapped_refs, 0);
> >
> > This would still pick refs/heads/master if refs/heads/master and
> > refs/heads/<branch> reference the same commit. That's due to the check
> > in guess_remote_head() which prefers refs/heads/master over all other
> > refs. While this is acceptable for the HEAD lookup, I'd treat that as a
> > bug for this new option.
> >
>
> My english is not a good and I don't understand it, sorry.
guess_remote_head() compares the object ids from remote_head and all of
the remote's refs to guess which is the right one.
Let's say that the repo has:
refs/heads/master: object1
refs/heads/foo: object2
refs/heads/bar: object1
If you do "git clone -b foo ...", then remote_head->old_sha1 will be
"object2". guess_remote_head() compares that to all the remote heads. In
this case, it will find refs/heads/foo (as expected).
But when you do "git clone -b bar", then remote_head->old_sha1 will be
"object1". And guess_remote_head() will then take refs/heads/master,
as it prefers that one.
doener@atjola:h $ mkdir a; cd a; git init
Initialized empty Git repository in /home/doener/h/a/.git/
doener@atjola:a (master) $ git commit --allow-empty -m init
[master (root-commit) a7a0b54] init
doener@atjola:a (master) $ git branch bar
doener@atjola:a (master) $ git checkout -b foo
Switched to a new branch 'foo'
doener@atjola:a (foo) $ git commit --allow-empty -m on_foo
[foo 375047e] on_foo
doener@atjola:a (foo) $ cd ..
doener@atjola:h $ (git clone -b foo a foo; cd foo; git branch)
Initialized empty Git repository in /home/doener/h/foo/.git/
* foo
doener@atjola:h $ (git clone -b bar a bar; cd bar; git branch)
Initialized empty Git repository in /home/doener/h/bar/.git/
* master
That said, I actually wonder why you don't simple set HEAD in the
original repo so that you get whichever branch you want by default
anyway.
Björn
^ permalink raw reply
* Re: git clone http://git.savannah.gnu.org/cgit/xboard.git segfaults
From: Tay Ray Chuan @ 2009-08-26 12:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Ali Polatel, git
In-Reply-To: <alpine.DEB.1.00.0908171620160.4991@intel-tinevez-2-302>
Hi,
On Mon, Aug 17, 2009 at 10:22 PM, Johannes Schindelin<Johannes.Schindelin@gmx.de> wrote:
> Seems that an object request is aborted, but the slot, and therefore the
> callback, is called nevertheless. Tay, does that ring a bell?
thanks Johannes, your diagnosis was a vital clue.
Ali, could you see if this patch fixes it for you? On my side, I had
some difficulty reproducing your problem reliably (it happened
sometimes but not on other times).
--
Cheers,
Ray Chuan
-- >8 --
Subject: [PATCH] http.c: set slot callback members to NULL when releasing object
Set the members callback_func and callback_data of freq->slot to NULL
when releasing a http_object_request. release_active_slot() is also
invoked on the slot to remove the curl handle associated with the slot
from the multi stack (CURLM *curlm in http.c).
These prevent the callback function and data from being used in http
methods (like http.c::finish_active_slot()) after a
http_object_request has been free'd.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
http.c | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/http.c b/http.c
index a2720d5..1ae19e0 100644
--- a/http.c
+++ b/http.c
-1285,5 +1285,10 @@ void release_http_object_request(struct http_object_request *freq)
free(freq->url);
freq->url = NULL;
}
- freq->slot = NULL;
+ if (freq->slot != NULL) {
+ freq->slot->callback_func = NULL;
+ freq->slot->callback_data = NULL;
+ release_active_slot(freq->slot);
+ freq->slot = NULL;
+ }
}
--
1.6.4.193.gaceaa.dirty
^ permalink raw reply
* Re: [RFC] Use a 16-tree instead of a 256-tree for storing notes
From: Johan Herland @ 2009-08-26 12:56 UTC (permalink / raw)
To: Alex Riesen
Cc: Johannes Schindelin, git, gitster, trast, tavestbo, git,
chriscool, spearce
In-Reply-To: <81b0412b0908260505m233d9a5cmefdd81e1ef51a299@mail.gmail.com>
On Wednesday 26 August 2009, Alex Riesen wrote:
> On Wed, Aug 26, 2009 at 12:31, Johan Herland<johan@herland.net> wrote:
> > The 256-tree structure is considerably faster than storing all
> > entries in a
>
> This part is confusing. Was 256-tree better (as in "faster") then?
256-tree is faster than the everything-in-hash_map draft.
16-tree is slightly faster than 256-tree
256-tree uses more memory (in the worst case) that the
everything-in-hash-map draft.
16-tree uses less memory than both.
Makes sense?
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: git clone http://git.savannah.gnu.org/cgit/xboard.git segfaults
From: Ali Polatel @ 2009-08-26 13:12 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: git
In-Reply-To: <20090826202053.6e6442a6.rctay89@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 609 bytes --]
Tay Ray Chuan yazmış:
> Hi,
>
> On Mon, Aug 17, 2009 at 10:22 PM, Johannes Schindelin<Johannes.Schindelin@gmx.de> wrote:
> > Seems that an object request is aborted, but the slot, and therefore the
> > callback, is called nevertheless. Tay, does that ring a bell?
>
> thanks Johannes, your diagnosis was a vital clue.
>
> Ali, could you see if this patch fixes it for you? On my side, I had
> some difficulty reproducing your problem reliably (it happened
> sometimes but not on other times).
>
It works, I don't get any segfaults after applying this patch.
--
Regards,
Ali Polatel
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [RFC] Use a 16-tree instead of a 256-tree for storing notes
From: Alex Riesen @ 2009-08-26 13:24 UTC (permalink / raw)
To: Johan Herland
Cc: Johannes Schindelin, git, gitster, trast, tavestbo, git,
chriscool, spearce
In-Reply-To: <200908261456.55906.johan@herland.net>
On Wed, Aug 26, 2009 at 14:56, Johan Herland<johan@herland.net> wrote:
> On Wednesday 26 August 2009, Alex Riesen wrote:
>> On Wed, Aug 26, 2009 at 12:31, Johan Herland<johan@herland.net> wrote:
>> > The 256-tree structure is considerably faster than storing all
>> > entries in a
>>
>> This part is confusing. Was 256-tree better (as in "faster") then?
>
> 256-tree is faster than the everything-in-hash_map draft.
> 16-tree is slightly faster than 256-tree
>
> 256-tree uses more memory (in the worst case) that the
> everything-in-hash-map draft.
> 16-tree uses less memory than both.
>
> Makes sense?
Oh, it does, it is just confusingly presented. How about:
The 16-tree is both faster and has lower footprint then 256-tree
code, which in its turn is noticably faster and smaller then existing
hash_map implementation. ...
^ permalink raw reply
* Re: [RFC] Use a 16-tree instead of a 256-tree for storing notes
From: Andreas Ericsson @ 2009-08-26 13:27 UTC (permalink / raw)
To: Alex Riesen
Cc: Johan Herland, Johannes Schindelin, git, gitster, trast, tavestbo,
git, chriscool, spearce
In-Reply-To: <81b0412b0908260624v30d32cc1m96e798076b51cbc9@mail.gmail.com>
Alex Riesen wrote:
> On Wed, Aug 26, 2009 at 14:56, Johan Herland<johan@herland.net> wrote:
>> On Wednesday 26 August 2009, Alex Riesen wrote:
>>> On Wed, Aug 26, 2009 at 12:31, Johan Herland<johan@herland.net> wrote:
>>>> The 256-tree structure is considerably faster than storing all
>>>> entries in a
>>> This part is confusing. Was 256-tree better (as in "faster") then?
>> 256-tree is faster than the everything-in-hash_map draft.
>> 16-tree is slightly faster than 256-tree
>>
>> 256-tree uses more memory (in the worst case) that the
>> everything-in-hash-map draft.
>> 16-tree uses less memory than both.
>>
>> Makes sense?
>
> Oh, it does, it is just confusingly presented. How about:
>
> The 16-tree is both faster and has lower footprint then 256-tree
> code, which in its turn is noticably faster and smaller then existing
> hash_map implementation. ...
If it's to be squashed in, why mention the 256-tree at all (except
for possibly as something to compare with at the end)?
If it goes on top, why mention the hash_map at all?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* [PATCH] Minor improvement to the write-tree documentation
From: David Kågedal @ 2009-08-26 14:04 UTC (permalink / raw)
To: git; +Cc: David Kågedal
Signed-off-by: David Kågedal <davidk@lysator.liu.se>
---
Documentation/git-write-tree.txt | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-write-tree.txt b/Documentation/git-write-tree.txt
index 26d3850..3eee11f 100644
--- a/Documentation/git-write-tree.txt
+++ b/Documentation/git-write-tree.txt
@@ -12,7 +12,8 @@ SYNOPSIS
DESCRIPTION
-----------
-Creates a tree object using the current index.
+Creates a tree object using the current index. The sha1 of the new
+tree object is printed to standard output.
The index must be in a fully merged state.
--
1.6.4.rc3.21.g3b9e
^ permalink raw reply related
* Re: [PATCH] upload-pack: add a trigger for post-upload-pack hook
From: Jeff King @ 2009-08-26 14:19 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Tom Werner, Tom Preston-Werner, git
In-Reply-To: <alpine.DEB.1.00.0908261200160.4713@intel-tinevez-2-302>
On Wed, Aug 26, 2009 at 12:06:59PM +0200, Johannes Schindelin wrote:
> > Did you get an impression that I was saying "you must add these
> > otherwise I'll reject the patch"?
>
> Well, I got the impression that you'd not accept the patch without
> additional information given by the hook, and I got the impression that
> Tom would decide as a consequence to rather live with his eternal fork
> instead of working on getting this patch included.
I don't think any of us wants that. My point in bringing it up at all
was just "is there anything obvious that we should be adding before this
makes it into master, because after that we will have to deal with an
interface change". I certainly don't want to delay a useful patch too
much while we wait for the moon.
-Peff
^ permalink raw reply
* Re: git+http:// proof-of-concept (not using CONNECT)
From: Douglas Campos @ 2009-08-26 14:34 UTC (permalink / raw)
To: Eric Wong; +Cc: Tony Finch, Constantine Plotnikov, git
In-Reply-To: <20090707205003.GA31195@dcvr.yhbt.net>
Any news about this approach? I've heard some noise about a CGI
implementation....
--
Douglas Campos
qmx.me
^ permalink raw reply
* Re: [RFC] Use a 16-tree instead of a 256-tree for storing notes
From: Johan Herland @ 2009-08-26 14:43 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Alex Riesen, Johannes Schindelin, git, gitster, trast, tavestbo,
git, chriscool, spearce
In-Reply-To: <4A95383A.4080104@op5.se>
On Wednesday 26 August 2009, Andreas Ericsson wrote:
> Alex Riesen wrote:
> > On Wed, Aug 26, 2009 at 14:56, Johan Herland<johan@herland.net>
wrote:
> >> On Wednesday 26 August 2009, Alex Riesen wrote:
> >>> On Wed, Aug 26, 2009 at 12:31, Johan Herland<johan@herland.net>
wrote:
> >>>> The 256-tree structure is considerably faster than storing all
> >>>> entries in a
> >>>
> >>> This part is confusing. Was 256-tree better (as in "faster")
> >>> then?
> >>
> >> 256-tree is faster than the everything-in-hash_map draft.
> >> 16-tree is slightly faster than 256-tree
> >>
> >> 256-tree uses more memory (in the worst case) that the
> >> everything-in-hash-map draft.
> >> 16-tree uses less memory than both.
> >>
> >> Makes sense?
> >
> > Oh, it does, it is just confusingly presented. How about:
> >
> > The 16-tree is both faster and has lower footprint then 256-tree
> > code, which in its turn is noticably faster and smaller then
> > existing hash_map implementation. ...
>
> If it's to be squashed in, why mention the 256-tree at all (except
> for possibly as something to compare with at the end)?
> If it goes on top, why mention the hash_map at all?
Ah. Sorry for the confusion. These patches are not meant to standalone
patches in the jh/notes series. They just compare various solutions to
the problem of parsing a notes tree structure with fanout in an
efficient manner.
The next iteration of the jh/notes series will include the preferred
solution (16-tree unless something better shows up), _without_ talking
about the differences between alternative solutions. As such the
hash_map and 256-tree will not be mentioned at all.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* [PATCH] Add option -b/--branch to clone for select a new HEAD
From: Kirill A. Korinskiy @ 2009-08-26 14:46 UTC (permalink / raw)
To: B.Steinbrink; +Cc: git, Kirill A. Korinskiy
In-Reply-To: <20090826121600.GA29098@atjola.homenet>
Sometimes (especially on production systems) we need to use only one
remote branch for building software. It's really annoying to clone
origin and then switch branch by hand everytime. So this patch
provides functionality to clone a remote branch with one command
without using checkout after clone.
Signed-off-by: Kirill A. Korinskiy <catap@catap.ru>
---
Documentation/git-clone.txt | 5 ++++
builtin-clone.c | 25 ++++++++++++++++++---
t/t5706-clone-branch.sh | 49 +++++++++++++++++++++++++++++++++++++++++++
3 files changed, 75 insertions(+), 4 deletions(-)
create mode 100755 t/t5706-clone-branch.sh
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index 2c63a0f..5cd106c 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -127,6 +127,11 @@ objects from the source repository into a pack in the cloned repository.
Instead of using the remote name 'origin' to keep track
of the upstream repository, use <name>.
+--branch <name>::
+-b <name>::
+ Create a local branch head for <name> instead of the branch
+ referenced by the remote repos HEAD.
+
--upload-pack <upload-pack>::
-u <upload-pack>::
When given, and the repository to clone from is accessed
diff --git a/builtin-clone.c b/builtin-clone.c
index 32dea74..91392a3 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -41,6 +41,7 @@ static int option_quiet, option_no_checkout, option_bare, option_mirror;
static int option_local, option_no_hardlinks, option_shared;
static char *option_template, *option_reference, *option_depth;
static char *option_origin = NULL;
+static char *option_branch = NULL;
static char *option_upload_pack = "git-upload-pack";
static int option_verbose;
@@ -65,6 +66,8 @@ static struct option builtin_clone_options[] = {
"reference repository"),
OPT_STRING('o', "origin", &option_origin, "branch",
"use <branch> instead of 'origin' to track upstream"),
+ OPT_STRING('b', "branch", &option_branch, "branch",
+ "use <branch> from upstream as HEAD"),
OPT_STRING('u', "upload-pack", &option_upload_pack, "path",
"path to git-upload-pack on the remote"),
OPT_STRING(0, "depth", &option_depth, "depth",
@@ -347,8 +350,8 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
const char *repo_name, *repo, *work_tree, *git_dir;
char *path, *dir;
int dest_exists;
- const struct ref *refs, *head_points_at, *remote_head, *mapped_refs;
- struct strbuf key = STRBUF_INIT, value = STRBUF_INIT;
+ const struct ref *refs, *head_points_at, *remote_head = NULL, *mapped_refs;
+ struct strbuf key = STRBUF_INIT, value = STRBUF_INIT, branch_head = STRBUF_INIT;
struct strbuf branch_top = STRBUF_INIT, reflog_msg = STRBUF_INIT;
struct transport *transport = NULL;
char *src_ref_prefix = "refs/heads/";
@@ -518,8 +521,22 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
mapped_refs = write_remote_refs(refs, refspec, reflog_msg.buf);
- remote_head = find_ref_by_name(refs, "HEAD");
- head_points_at = guess_remote_head(remote_head, mapped_refs, 0);
+ if (option_branch) {
+ strbuf_addf(&branch_head, "%s%s", src_ref_prefix, option_branch);
+
+ remote_head = find_ref_by_name(refs, branch_head.buf);
+ }
+
+ if (!remote_head) {
+ if (option_branch)
+ warning("Remote branch %s not found in upstream %s"
+ ", using HEAD instead",
+ option_branch, option_origin);
+
+ remote_head = find_ref_by_name(refs, "HEAD");
+ }
+
+ head_points_at = guess_remote_head(remote_head, mapped_refs, 1);
}
else {
warning("You appear to have cloned an empty repository.");
diff --git a/t/t5706-clone-branch.sh b/t/t5706-clone-branch.sh
new file mode 100755
index 0000000..b5fec50
--- /dev/null
+++ b/t/t5706-clone-branch.sh
@@ -0,0 +1,49 @@
+#!/bin/sh
+
+test_description='branch clone options'
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+
+ mkdir parent &&
+ (cd parent && git init &&
+ echo one >file && git add file &&
+ git commit -m one && git branch foo &&
+ git checkout -b two &&
+ echo two >f && git add f && git commit -m two &&
+ git checkout master)
+
+'
+
+test_expect_success 'clone' '
+
+ git clone parent clone &&
+ (cd clone &&
+ test $(git rev-parse --verify HEAD) = \
+ $(git rev-parse --verify refs/remotes/origin/master) &&
+ test $(git rev-parse --verify HEAD) != \
+ $(git rev-parse --verify refs/remotes/origin/two))
+
+
+'
+
+test_expect_success 'clone -b two' '
+
+ git clone -b two parent clone-b &&
+ (cd clone-b &&
+ test $(git rev-parse --verify HEAD) = \
+ $(git rev-parse --verify refs/remotes/origin/two) &&
+ test $(git rev-parse --verify HEAD) != \
+ $(git rev-parse --verify refs/remotes/origin/master))
+
+'
+
+test_expect_success 'clone -b foo' '
+
+ git clone -b foo parent clone-b-foo &&
+ (cd clone-b-foo &&
+ test $(git branch | grep \* | sed -e s:\*\ ::) = foo)
+
+'
+
+test_done
--
1.6.2
^ permalink raw reply related
* Re: [PATCH] git-bisect: call the found commit "*the* first bad commit"
From: Jeff King @ 2009-08-26 15:29 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Nanako Shiraishi, git
In-Reply-To: <alpine.DEB.1.00.0908261207400.4713@intel-tinevez-2-302>
On Wed, Aug 26, 2009 at 12:08:11PM +0200, Johannes Schindelin wrote:
> Well, I learnt at school that it is "learnt" and "at school"...
>
> double ;-)
Bloody Europeans. ;)
-Peff
^ permalink raw reply
* Re: [PATCH] Add option -b/--branch to clone for select a new HEAD
From: Björn Steinbrink @ 2009-08-26 15:50 UTC (permalink / raw)
To: Kirill A. Korinskiy; +Cc: git
In-Reply-To: <1251298007-18693-1-git-send-email-catap@catap.ru>
On 2009.08.26 18:46:47 +0400, Kirill A. Korinskiy wrote:
> @@ -518,8 +521,22 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
>
> mapped_refs = write_remote_refs(refs, refspec, reflog_msg.buf);
>
> - remote_head = find_ref_by_name(refs, "HEAD");
> - head_points_at = guess_remote_head(remote_head, mapped_refs, 0);
> + if (option_branch) {
> + strbuf_addf(&branch_head, "%s%s", src_ref_prefix, option_branch);
> +
> + remote_head = find_ref_by_name(refs, branch_head.buf);
> + }
> +
> + if (!remote_head) {
> + if (option_branch)
> + warning("Remote branch %s not found in upstream %s"
> + ", using HEAD instead",
> + option_branch, option_origin);
> +
> + remote_head = find_ref_by_name(refs, "HEAD");
> + }
> +
> + head_points_at = guess_remote_head(remote_head, mapped_refs, 1);
Just setting "all" to 1 there is wrong. With "all" set to 1,
guess_remote_head() returns a linked list of _all_ matching refs. The
first entry in that list depends on the order of mapped_refs.
doener@atjola:h $ mkdir a; cd a; git init
Initialized empty Git repository in /home/doener/h/a/.git/
doener@atjola:a (master) $ git commit --allow-empty -m init
[master (root-commit) aa39247] init
doener@atjola:a (master) $ git branch foo
doener@atjola:a (master) $ cd ..
doener@atjola:h $ (git clone -b foo a foo; cd foo; git branch)
Initialized empty Git repository in /home/doener/h/foo/.git/
* foo
doener@atjola:h $ (git clone -b master a master; cd master; git branch)
Initialized empty Git repository in /home/doener/h/master/.git/
* foo
Here, "foo" was first in mapped_refs, and so "-b master" used that, too.
Using guess_remote_head() seems pretty wrong. With -b given, you don't
want to guess anymore, you _know_ which one you want. Unfortunately, I
don't see a straight-forward way to handle that (but I'm totally
clueless about the code, so don't let me scare you ;-)).
> diff --git a/t/t5706-clone-branch.sh b/t/t5706-clone-branch.sh
> new file mode 100755
> index 0000000..b5fec50
> --- /dev/null
> +++ b/t/t5706-clone-branch.sh
> @@ -0,0 +1,49 @@
> +#!/bin/sh
> +
> +test_description='branch clone options'
> +. ./test-lib.sh
> +
> +test_expect_success 'setup' '
> +
> + mkdir parent &&
> + (cd parent && git init &&
> + echo one >file && git add file &&
> + git commit -m one && git branch foo &&
> + git checkout -b two &&
> + echo two >f && git add f && git commit -m two &&
> + git checkout master)
> +
> +'
> +
> +test_expect_success 'clone' '
> +
> + git clone parent clone &&
> + (cd clone &&
> + test $(git rev-parse --verify HEAD) = \
> + $(git rev-parse --verify refs/remotes/origin/master) &&
> + test $(git rev-parse --verify HEAD) != \
> + $(git rev-parse --verify refs/remotes/origin/two))
> +
> +
> +'
> +
> +test_expect_success 'clone -b two' '
> +
> + git clone -b two parent clone-b &&
> + (cd clone-b &&
> + test $(git rev-parse --verify HEAD) = \
> + $(git rev-parse --verify refs/remotes/origin/two) &&
> + test $(git rev-parse --verify HEAD) != \
> + $(git rev-parse --verify refs/remotes/origin/master))
> +
> +'
> +
> +test_expect_success 'clone -b foo' '
> +
> + git clone -b foo parent clone-b-foo &&
> + (cd clone-b-foo &&
> + test $(git branch | grep \* | sed -e s:\*\ ::) = foo)
This should probably do "git symbolic-ref HEAD" instead of the branch +
grep + sed. And it should also verify that rev-parse foo == rev-parse
origin/foo.
And to catch the above bug, you need a second test like that, but for
"master" instead of "foo".
HTH
Björn
^ permalink raw reply
* Re: Newbie / git / gitosis question
From: Jeff King @ 2009-08-26 15:56 UTC (permalink / raw)
To: Howard Miller; +Cc: git
In-Reply-To: <26ae428a0908260227k7ac6aeden9a4eae7ee95d4d45@mail.gmail.com>
On Wed, Aug 26, 2009 at 10:27:30AM +0100, Howard Miller wrote:
> I've been working away at Gitosis and it's mostly fair enough but
> there's one bit that's unclear to me...
>
> git push origin master:refs/heads/master
>
> Would somebody kindly explain (or point to docs) what
> refs/heads/master means? How is this different from just 'git push
> origin master' or even 'git push origin master:master'?
I'll try to explain.
Refs are pointers to commits. In other words, you can think of
"refs/heads/master" as a key pointing to a SHA-1 commit id. The long-ish
name divides up the namespace for refs.
There are a few special refs that live outside of the refs/ hierarchy,
like HEAD, FETCH_HEAD, MERGE_HEAD, ORIG_HEAD, etc. Normal refs are
generally under refs/.
The refs/heads/ hierarchy is for branches (they are the "head" of a line
of development). The refs/tags hierarchy is for tags. The refs/remotes
hierarchy is where we store our local idea of where remote repositories'
branches point.
Pushing (and fetching) take a "refspec": two refs, a source and
destination, separated by a colon. So "git push foo:bar" means "look up
my local ref 'foo' and update or create the remote ref 'bar' with the
same commit".
Every ref has a "full name" that is much longer than what we often
see. We can generally abbreviate because one of the following applies:
1. We are specifying a name to look up, and there is a set of lookup
rules. For example, the name "master" will be considered as a tag,
and then as a branch, and then as a remote branch.
The lookup rules are described in "git help rev-parse" under the
section "Specifying Revisions".
2. We are using a name in a context that expects a particular type.
For example, "git branch foo" knows that "foo" is a new branch
name, and so will create the ref as refs/heads/foo. Similarly "git
tag foo" will create refs/tags/foo.
3. We can infer the type from the other half of a refspec. For
example, given a local branch "master" and a tag "v1.0" (and
neither currently existing on the remote side), we can do:
git push origin master:master v1.0:v1.0
and we know that the "master" we create on the remote will be a
branch, because the local "master" is a branch, and similarly the
"v1.0" we create on the remote will be a tag because the local
"v1.0" is a tag.
And finally, "git push" knows a shorthand for refspecs: a refspec
without a colon is treated as having the same string on both sides. So
"master" is really a shortcut for "master:master".
Knowing all of that, let's look at your examples:
A. git push origin master
This is really a syntactic shortcut for "git push origin
master:master".
B. git push origin master:master
The left-hand side of the refspec is looked up locally. In this
case, it is probably going to be "refs/heads/master". The right-hand
side is looked up on the remote. If it exists (i.e., you are
updating your branch), it is probably "refs/heads/master".
If it doesn't exist on the remote (i.e., you are pushing a new
branch), then we can infer from the prefix of the left-hand side
that the right-hand side should also be a branch (i.e., under
"refs/heads/").
So assuming "master" is a branch, this is really equivalent to:
git push origin refs/heads/master:refs/heads/master
C. git push origin master:refs/heads/master
If you understood the explanation for (B) above, you will know that
this is again basically the same thing. :)
However, note that in (B), if the branch is being created on the
remote, we rely on the "refspec inference" rule described earlier.
This behavior was adopted in git in v1.5.5.2 (commit f8aae120,
2008-04-23). So you may still see examples that pre-date this
feature and recommend using the full ref-name, which should no
longer be necessary.
Hope that helps. Let me know if you need clarification on any of the
above.
-Peff
^ permalink raw reply
* Re: [PATCH] Add option -b/--branch to clone for select a new HEAD
From: Jeff King @ 2009-08-26 16:10 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Kirill A. Korinskiy, git
In-Reply-To: <20090826155029.GA5750@atjola.homenet>
On Wed, Aug 26, 2009 at 05:50:29PM +0200, Björn Steinbrink wrote:
> Using guess_remote_head() seems pretty wrong. With -b given, you don't
> want to guess anymore, you _know_ which one you want. Unfortunately, I
> don't see a straight-forward way to handle that (but I'm totally
> clueless about the code, so don't let me scare you ;-)).
Thanks for pointing this out, Björn (I really should have noticed it on
first review, but I guess many eyes, shallow bugs, etc. :) ).
This code is a little bit confusing, so let me explain:
- we look up the remote HEAD, getting its commit sha1. If the protocol
supports it, we also get its symref information.
- we then pass the result to guess_remote_head. _If_ we have symref
information, then we can quit immediately, as the symref contains
what we want. If it doesn't, then we proceed with trying to match up
the commit sha1 with one of the other refs.
So if you want to create a "remote_head" object via "-b" which acts as
if it was the remote HEAD, you would need to actually create a new ref
object and set the "symref" field appropriately.
But I don't think there is any need to do that here. We simply want to
avoid calling guess_remote_head at all, since we know there is nothing
to guess at. We do still need to know whether remote_head is non-NULL
later, though.
So I think the code should probably look like this (totally untested):
remote_head = find_ref_by_name(refs, "HEAD");
if (option_branch) {
strbuf_addf(&branch_head, "%s%s", src_ref_prefix, option_branch);
head_points_at = find_ref_by_name(refs, branch_head.buf);
if (!head_points_at)
warning("remote branch not found, etc");
}
if (!head_points_at)
head_points_at = guess_remote_head(remote_head, mapped_refs, 0);
and then initialize head_points_at to NULL instead of remote_head.
-Peff
^ permalink raw reply
* Re: [PATCH] Add option -b/--branch to clone for select a new HEAD
From: Björn Steinbrink @ 2009-08-26 16:56 UTC (permalink / raw)
To: Jeff King; +Cc: Kirill A. Korinskiy, git
In-Reply-To: <20090826161059.GC32741@coredump.intra.peff.net>
On 2009.08.26 12:10:59 -0400, Jeff King wrote:
> So I think the code should probably look like this (totally untested):
>
> remote_head = find_ref_by_name(refs, "HEAD");
> if (option_branch) {
> strbuf_addf(&branch_head, "%s%s", src_ref_prefix, option_branch);
> head_points_at = find_ref_by_name(refs, branch_head.buf);
> if (!head_points_at)
> warning("remote branch not found, etc");
> }
> if (!head_points_at)
> head_points_at = guess_remote_head(remote_head, mapped_refs, 0);
Hm, why "refs" for find_ref_by_name(), but "mapped_ref" for
guess_remote_head()?
Björn
^ permalink raw reply
* [git-svn] [FEATURE-REQ] track merges from git
From: Ximin Luo @ 2009-08-26 16:42 UTC (permalink / raw)
To: git
Hi,
I'm have 2 separate svn projects from googlecode imported into a single git
repo. One is a semi-fork of the other, so I thought I'd be able to use git's
merge feature to repeatedly merge from the mother project (and possibly vice
versa too).
However, this doesn't happen. I "git pull" and this works fine, but when I "git
svn dcommit" back into svn, this rewrites my git history and it loses track of
the merge (and next time I try to pull, the same conflicts appear).
For now I just have a .git/info/grafts, but this doesn't get exported anywhere,
so if other people "git svn clone" from svn, or "git clone" from my git repo,
they don't get the merge information.
It would be nice if git-svn saved the merge info somewhere instead of getting
rid of it. #git tells me this is impossible at the moment, hence the mail.
Relevant parts of the convo are pasted below.
I understand if this is a low priority, but I don't think it would be a major
PITA to implement (some suggestions are listed in the convo log). And it'd be
useful for people converting from svn to git.
Thanks for your time.
X
P.S. please don't troll me.
(17:13:10) The topic for #git is: 1.6.4.1 | Homepage: http://git-scm.com |
Everyone asleep or clueless? Try git@vger.kernel.org | Git User's Survey 2009!
http://tinyurl.com/GitSurvey2009 | Channel log http://tinyurl.com/gitlog |
Mailing list archives: http://tinyurl.com/gitml | Gits on git:
http://tinyurl.com/gittalks | Pastebin: http://gist.github.com/ | GSoC '09:
http://socghop.appspot.com/org/home/google/gsoc2009/git
(17:13:14) infinity0: hi
(17:13:21) infinity0: i've used git-svn to import two svn repo
(17:13:23) infinity0: repos*
(17:13:28) infinity0: and used git to merge the two
(17:13:45) infinity0: the problem is, when i git-svn dcommit back to svn,
git-svn rewrites my git history
(17:13:50) infinity0: and loses the merge i just did
(17:14:01) offby1: infinity0: of course
(17:14:04) infinity0: how do i get it to retain knowledge of the merge?
(17:14:11) offby1: infinity0: you don't. Next questions.
(17:14:16) infinity0: why not?
(17:14:29) offby1: svn is incapable of storing a merge, at least in the sense
that we git people use the term "merge"
(17:14:46) Grum: you should be able to store the result of a merge as a commit
(17:14:51) offby1: sure
(17:14:57) infinity0: sure, but why does git-svn have to rewrite my *git*
history to remove knowledge of the merge?
(17:15:02) offby1: but not as a "merge commit", whatever that might mean in svn
(17:15:35) Grum: because it has to be representative of the svn repo after you
dcommit there obviously
(17:15:42) offby1: infinity0: it's trying to mirror the svn repository in your
git repository. I assume the original, un-rewritten commits are still in your
git repository; they're just not pointed at by any branch. Poke around in the
reflog; I imagine you'll find 'em in there
(17:16:09) infinity0: ok, but that's not useful if they're dangling
(17:16:26) infinity0: it's trying to mirror the svn repo yes... but as you
said, svn doesn't know about merges
(17:16:26) ***offby1 idly wonders if it'd be possible for git svn to indeed
store merge commits, by applying the appropriate svn:mergeinfo properties
(17:16:40) infinity0: i read a thread where it says those are different things
(17:16:41) offby1: infinity0: I suspect you're using git svn for something for
which it wasn't designed.
(17:17:17) infinity0: would it be possible, in theory, to have git-svn store
the git merge information in eg. the same way it stores the git-svn tag in the
svn commit message
(17:17:33) Grum: then just use svn?
(17:17:37) Grum: and a postit?
(17:18:01) infinity0: i'm trying to link two separate svn repos together via git
(17:18:17) Grum: and that is just what offby1 said
(17:18:30) infinity0: "what" is
(17:18:40) Grum: I suspect you're using git svn for something for which it
wasn't designed.
(17:18:42) infinity0: as you all are saying, git merges and svn "merges" are
different things
(17:18:58) infinity0: ok, but it would be possible to make git-svn have this
functionality? or not
(17:18:59) offby1: certainly
(17:19:16) offby1: I fear not, since Eric Wong seems like a smart fella; if it
were doable, I suspect he'd have done it already.
(17:19:21) offby1: But then ... who knows, maybe he's busy.
(17:20:07) infinity0: well afaic it would just involve adding some extra
git-svn info to the svn commit messages, but meh
(17:20:10) infinity0: i'll go file a bug
(17:21:14) offby1: infinity0: if it were me, I'd shy away from cramming more
junk into the svn commit messages; that strikes me as an unreliable storage medium
(17:21:22) offby1: I'd use properties instead
(17:21:24) Grum: ok lets do this properly
(17:21:31) Grum: why do you want to 'merge' 2 svn 'repos' this way?
(17:21:34) Grum: as you are not actually merging them
(17:21:45) offby1: Grum: go, man, go!
(17:21:58) infinity0: what do you mean "not actually merging them"
(17:22:17) infinity0: they are "actually merged" in git
(17:22:24) infinity0: then i git-svn dcommit and they become unmerged again
(17:22:34) Grum: why do you want to merge them?
(17:22:42) infinity0: so i can grab changes from one into the other
(17:22:42) Grum: and what is your goal with dcommitting this?
(17:22:57) infinity0: long story short, the two projects use svn on google code
(17:23:06) infinity0: one is a semi-fork of the other
(17:23:10) offby1: aaahhh
(17:23:13) infinity0: i need to pull changes quite often
(17:23:17) offby1: and you want to keep them in sync, kinda
(17:23:19) infinity0: yeah
(17:23:28) offby1: yeesh, dunno how I'd do that
(17:24:09) infinity0: ok well i guess the only thing i can do atm is file a bug
for git-svn and tell people to manually add the .git/info/grafts
(17:24:12) infinity0: but thanks for your info
(17:27:24) infinity0: uh, where is the git bug tracker
(17:27:40) Grum: its the mailinglist =)
(17:27:41) sitaram: no bugs, so no tracker
(17:27:44) sitaram: :
(17:27:45) sitaram: :D
(17:27:51) infinity0: lol
(17:27:59) Grum: and erm you want a feature, its nt a bug you are reporting
(17:27:59) Grum: s
(17:28:00) infinity0: ok i'll post on the mailing list then.. *grumble*
(17:28:08) infinity0: ok, *feature request :p
(17:28:08) Grum: you are not using the tool for what it is meant to
(17:28:13) Grum: and you can still do waht you want in either case
(17:28:17) Grum: just not by merging
(17:28:22) infinity0: well, how then?
(17:29:48) infinity0: aww fuck 120 messages a day? oh come on... are
non-members allowed to post to it?
(17:30:00) Grum: infinity0: just 120 yeah, and yeah they are
(17:30:06) infinity0: ah ok
^ permalink raw reply
* Re: [PATCH] fix simple deepening of a repo
From: Shawn O. Pearce @ 2009-08-26 17:03 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Sixt, Nicolas Pitre, Julian Phillips, Daniel Barkalow,
Johannes Schindelin, git
In-Reply-To: <7vk50reykp.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
> >> How will this mesh with 'git clone --mirror'?
> >
> > Not well.
>
> But we at least can assume that the server operator is reasonable and
> wouldn't go overboard, (ab)using this "abbreviated advertisement" feature
> to hide heads and tags from the clients.
Yes. My patch is hardcoded to show only heads and tags, and nothing else.
But I think we want to make this configurable, and show everything
by default, but if there is a configuration entry, show only what
the configuration entry patterns suggest to advertise.
Thus an admin could hide refs/heads/*, but maybe he wants to, and
show only refs/heads/master, refs/heads/maint, refs/heads/next by
default. This is actually a rather clear indication to a client
that although there may be individual cooking topics scattered
through the expanded refs/heads/* space, any reasonable default
clone wouldn't take them.
> Think about in what situation you would want to do a mirror clone.
...
> That means the version of git used to prime, update
> and serve the mirror will know the expand extention.
Great point Junio. The backwards compatibility may be a non-issue
then, especially if this is configurable and we advertise refs/*
by default like we do now, and any reasonable admin who does enable
the hiding still advertises the core namspaces that really matter
to the majority of clients.
> I am hoping that we can finish 1.6.5 by mid September (let's tentatively
> say we will shoot for 16th). I expect the expand extention to be in
> 'next' by that time, cooking for 1.7.0. How does that timetable sound?
Oh, if 1.6.5 is mid-September, this is certainly not 1.6.5 material.
I'm not in any rush, this should go in when its ready, but 1.7
might be reasonable.
--
Shawn.
^ permalink raw reply
* [PATCH] git-p4: Avoid modules deprecated in Python 2.6.
From: Reilly Grant @ 2009-08-26 16:52 UTC (permalink / raw)
To: git, gitster; +Cc: Reilly Grant
The popen2, sha and sets modules are deprecated in Python 2.6 (sha in
Python 2.5). Both popen2 and sha are not actually used in git-p4.
Replace usage of sets.Set with the builtin set object.
Signed-off-by: Reilly Grant <reillyeon@qotw.net>
---
contrib/fast-import/git-p4 | 12 +++++-------
1 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 342529d..ca58700 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -8,12 +8,10 @@
# License: MIT <http://www.opensource.org/licenses/mit-license.php>
#
-import optparse, sys, os, marshal, popen2, subprocess, shelve
-import tempfile, getopt, sha, os.path, time, platform
+import optparse, sys, os, marshal, subprocess, shelve
+import tempfile, getopt, os.path, time, platform
import re
-from sets import Set;
-
verbose = False
@@ -861,8 +859,8 @@ class P4Sync(Command):
self.usage += " //depot/path[@revRange]"
self.silent = False
- self.createdBranches = Set()
- self.committedChanges = Set()
+ self.createdBranches = set()
+ self.committedChanges = set()
self.branch = ""
self.detectBranches = False
self.detectLabels = False
@@ -1627,7 +1625,7 @@ class P4Sync(Command):
if len(self.changesFile) > 0:
output = open(self.changesFile).readlines()
- changeSet = Set()
+ changeSet = set()
for line in output:
changeSet.add(int(line))
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH] Add option -b/--branch to clone for select a new HEAD
From: Jeff King @ 2009-08-26 17:48 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Kirill A. Korinskiy, git
In-Reply-To: <20090826165618.GA7477@atjola.homenet>
On Wed, Aug 26, 2009 at 06:56:18PM +0200, Björn Steinbrink wrote:
> On 2009.08.26 12:10:59 -0400, Jeff King wrote:
> > So I think the code should probably look like this (totally untested):
> >
> > remote_head = find_ref_by_name(refs, "HEAD");
> > if (option_branch) {
> > strbuf_addf(&branch_head, "%s%s", src_ref_prefix, option_branch);
> > head_points_at = find_ref_by_name(refs, branch_head.buf);
> > if (!head_points_at)
> > warning("remote branch not found, etc");
> > }
> > if (!head_points_at)
> > head_points_at = guess_remote_head(remote_head, mapped_refs, 0);
>
> Hm, why "refs" for find_ref_by_name(), but "mapped_ref" for
> guess_remote_head()?
Blind copying of the current code? :)
Good question, though. AFAICT, the difference between mapped_refs and
refs is that the former contains only the refs we are actually fetching,
and its peer_ref member is filled in as appropriate.
Later in the code, we look at head_points_at->peer_ref, which means it
_must_ come from mapped_refs. And which means the code I posted is
bogus, as the ref we look up in "refs" will not have that member filled
in. So I think we do need:
head_points_at = find_ref_by_name(mapped_refs, branch_head.buf);
Good catch.
-Peff
^ permalink raw reply
* Re: [PATCH] git-p4: Avoid modules deprecated in Python 2.6.
From: Junio C Hamano @ 2009-08-26 18:14 UTC (permalink / raw)
To: Reilly Grant; +Cc: git
In-Reply-To: <1251305536-25887-1-git-send-email-reillyeon@qotw.net>
Reilly Grant <reillyeon@qotw.net> writes:
> The popen2, sha and sets modules are deprecated in Python 2.6 (sha in
> Python 2.5). Both popen2 and sha are not actually used in git-p4.
> Replace usage of sets.Set with the builtin set object.
Does the code already rely on a feature not found in Python older than 2.4
before your patch? Otherwise I would have liked to see the last sentence
like this:
Replace usage of sets.Set with the builtin set object, which has
been available since Python 2.4.
This change makes the script unusable with Python older than 2.4,
which was released in 2004. Hopefully nobody uses ancient 2.3.
So that I did not have to check myself to get a feel of how safe this
change is.
^ permalink raw reply
* Re: [PATCH] git-p4: Avoid modules deprecated in Python 2.6.
From: Reilly Grant @ 2009-08-26 18:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhbvucuj5.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Reilly Grant <reillyeon@qotw.net> writes:
>
>
>> The popen2, sha and sets modules are deprecated in Python 2.6 (sha in
>> Python 2.5). Both popen2 and sha are not actually used in git-p4.
>> Replace usage of sets.Set with the builtin set object.
>>
>
> Does the code already rely on a feature not found in Python older than 2.4
> before your patch? Otherwise I would have liked to see the last sentence
> like this:
>
> Replace usage of sets.Set with the builtin set object, which has
> been available since Python 2.4.
>
> This change makes the script unusable with Python older than 2.4,
> which was released in 2004. Hopefully nobody uses ancient 2.3.
>
> So that I did not have to check myself to get a feel of how safe this
> change is.
>
Thank you for the advice, this is my first patch. The existing code
uses the built-in set module in other places so the 2.4 requirement
already exists. I should have mentioned this in the original description.
--
Reilly Grant
reillyeon@qotw.net http://www.qotw.net/~reillyeon
GPG Key Signature: 2A41 A3E5 F3CA D3A0 F5CF 02DF B1EB CDEC 7850 E278
^ 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