* Re: Unreachable code in builtin-merge.c ?
From: Mikael Magnusson @ 2009-10-23 15:12 UTC (permalink / raw)
To: Zivkov, Sasa; +Cc: git@vger.kernel.org
In-Reply-To: <B221C4384AE5104EB414A877DFD0372C0B0092C0C5@DEWDFECCR04.wdf.sap.corp>
2009/10/23 Zivkov, Sasa <sasa.zivkov@sap.com>:
> In the try_merge_strategy function the expression in the following if statement seems to always evaluate to TRUE:
>
> if (!strcmp(strategy, "recursive") || !strcmp(strategy, "subtree")) {
>
> If strategy is "recursive" then !strcmp(strategy, "subtree") evaluates to TRUE.
> If strategy is "subtree" then !strcmp(strategy, "recursive") evaluates to TRUE.
> If strategy is neither "recursive" nor "subtree" then any side of || evaluates to TRUE.
>
> Looks like the code in the else block is unreachable?
You seem to have forgotten that strcmp returns 0 when the strings
match. (It returns -1 or 1 when they don't, depending on their
alphabetical ordering).
--
Mikael Magnusson
^ permalink raw reply
* Unreachable code in builtin-merge.c ?
From: Zivkov, Sasa @ 2009-10-23 15:03 UTC (permalink / raw)
To: git@vger.kernel.org
In the try_merge_strategy function the expression in the following if statement seems to always evaluate to TRUE:
if (!strcmp(strategy, "recursive") || !strcmp(strategy, "subtree")) {
If strategy is "recursive" then !strcmp(strategy, "subtree") evaluates to TRUE.
If strategy is "subtree" then !strcmp(strategy, "recursive") evaluates to TRUE.
If strategy is neither "recursive" nor "subtree" then any side of || evaluates to TRUE.
Looks like the code in the else block is unreachable?
Saša Živkov
^ permalink raw reply
* Re: feature "git tag -r" to show tags and commits they are pointing to
From: Eugene Sajine @ 2009-10-23 14:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8wf2ejna.fsf@alter.siamese.dyndns.org>
> You do not have to live with a tag that points at another tag that points
> at a commit.
>
> You can still tag the commit directly with your new tag, and you do not
> need to have the exact commit object name to do so. You just tell the
> tool to follow the tag chain to get to the pointed-to object, like this:
>
> $ git tag -a -m "my message" newtag oldtag^0
>
> This assumes [*1*] that the old tag points at (strictly speaking, "might
> point at") a commit object, and uses "^0" (zeroth parent of) operator to
> make sure that the object the newtag points at (the last argument to the
> "git tag" command, i.e. "oldtag^0" in this example) is a commit object,
> not an annotated tag "oldtag" itself.
>
> That is what I meant by "just as usable as hexadecimal to the tools".
>
>>> ... "v0.1" is
>>> much more useful than 8794hke to humans, and these tag names are just as
>>> usable as the hexadecimal commit object names to the tools. You can say
>>> "git show v0.1^0" and "git show 8794hke" and get the same thing.
>
> [Footnote]
>
> *1* A tag can point at any object, not necessarily a commit. If oldtag
> points at a tree object (or a blob object), oldtag^0 will fail, because
> the operator "^0" is "zeroth parent of", and is applicable only to a
> commit. In general, you can write
>
> $ git tag -a -m "my message" newtag oldtag^{}
>
> The "^{}" operator is a special case of "^{type}" operator; the former
> means "dereference the tag repeatedly until it becomes something that is
> not a tag", and the latter means "dereference the tag repeatedly until it
> becomes something of that type". I.e. "oldtag^0" is "oldtag^{commit}".
>
Junio,
Thank you very much for such detailed explanation! I do appreciate it.
Eugene
^ permalink raw reply
* [PATCH] add tests for git diff --submodule
From: Jens Lehmann @ 2009-10-23 11:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin
In-Reply-To: <7veiovly35.fsf@alter.siamese.dyndns.org>
Copied from the submodule summary test and changed to reflect the
differences in the output of git diff --submodule.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---
Junio C Hamano schrieb:
> * js/diff-verbose-submodule (2009-10-14) 2 commits.
> - add tests for git diff --submodule-summary
> - Add the --submodule option to the diff option family
>
> I should retitle and fix some comments in the tip commit (the tests have
> already been adjusted to use the real option name), but otherwise I think
> this is ready for 'next'.
Sorry for sending the updated test so late, i haven't had much time for
git in the last few days.
Apart from your changes necessary to make the test run again my changes are:
- rename from "t4041-diff-submodule-summary.sh" to "t4041-diff-submodule.sh"
- corrected all comments still speaking of "summary"
- added tests to test the behaviour of "--submodule" and "--submodule=short"
t/t4041-diff-submodule.sh | 260 +++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 260 insertions(+), 0 deletions(-)
create mode 100755 t/t4041-diff-submodule.sh
diff --git a/t/t4041-diff-submodule.sh b/t/t4041-diff-submodule.sh
new file mode 100755
index 0000000..5bb4fed
--- /dev/null
+++ b/t/t4041-diff-submodule.sh
@@ -0,0 +1,260 @@
+#!/bin/sh
+#
+# Copyright (c) 2009 Jens Lehmann, based on t7401 by Ping Yin
+#
+
+test_description='Support for verbose submodule differences in git diff
+
+This test tries to verify the sanity of the --submodule option of git diff.
+'
+
+. ./test-lib.sh
+
+add_file () {
+ sm=$1
+ shift
+ owd=$(pwd)
+ cd "$sm"
+ for name; do
+ echo "$name" > "$name" &&
+ git add "$name" &&
+ test_tick &&
+ git commit -m "Add $name"
+ done >/dev/null
+ git rev-parse --verify HEAD | cut -c1-7
+ cd "$owd"
+}
+commit_file () {
+ test_tick &&
+ git commit "$@" -m "Commit $*" >/dev/null
+}
+
+test_create_repo sm1 &&
+add_file . foo >/dev/null
+
+head1=$(add_file sm1 foo1 foo2)
+
+test_expect_success 'added submodule' "
+ git add sm1 &&
+ git diff-index -p --submodule=log HEAD >actual &&
+ diff actual - <<-EOF
+Submodule sm1 0000000...$head1 (new submodule)
+EOF
+"
+
+commit_file sm1 &&
+head2=$(add_file sm1 foo3)
+
+test_expect_success 'modified submodule(forward)' "
+ git diff-index -p --submodule=log HEAD >actual &&
+ diff actual - <<-EOF
+Submodule sm1 $head1..$head2:
+ > Add foo3
+EOF
+"
+
+test_expect_success 'modified submodule(forward)' "
+ git diff --submodule=log >actual &&
+ diff actual - <<-EOF
+Submodule sm1 $head1..$head2:
+ > Add foo3
+EOF
+"
+
+test_expect_success 'modified submodule(forward) --submodule' "
+ git diff --submodule >actual &&
+ diff actual - <<-EOF
+Submodule sm1 $head1..$head2:
+ > Add foo3
+EOF
+"
+
+fullhead1=$(cd sm1; git rev-list --max-count=1 $head1)
+fullhead2=$(cd sm1; git rev-list --max-count=1 $head2)
+test_expect_success 'modified submodule(forward) --submodule=short' "
+ git diff --submodule=short >actual &&
+ diff actual - <<-EOF
+diff --git a/sm1 b/sm1
+index $head1..$head2 160000
+--- a/sm1
++++ b/sm1
+@@ -1 +1 @@
+-Subproject commit $fullhead1
++Subproject commit $fullhead2
+EOF
+"
+
+commit_file sm1 &&
+cd sm1 &&
+git reset --hard HEAD~2 >/dev/null &&
+head3=$(git rev-parse --verify HEAD | cut -c1-7) &&
+cd ..
+
+test_expect_success 'modified submodule(backward)' "
+ git diff-index -p --submodule=log HEAD >actual &&
+ diff actual - <<-EOF
+Submodule sm1 $head2..$head3 (rewind):
+ < Add foo3
+ < Add foo2
+EOF
+"
+
+head4=$(add_file sm1 foo4 foo5) &&
+head4_full=$(GIT_DIR=sm1/.git git rev-parse --verify HEAD)
+test_expect_success 'modified submodule(backward and forward)' "
+ git diff-index -p --submodule=log HEAD >actual &&
+ diff actual - <<-EOF
+Submodule sm1 $head2...$head4:
+ > Add foo5
+ > Add foo4
+ < Add foo3
+ < Add foo2
+EOF
+"
+
+commit_file sm1 &&
+mv sm1 sm1-bak &&
+echo sm1 >sm1 &&
+head5=$(git hash-object sm1 | cut -c1-7) &&
+git add sm1 &&
+rm -f sm1 &&
+mv sm1-bak sm1
+
+test_expect_success 'typechanged submodule(submodule->blob), --cached' "
+ git diff --submodule=log --cached >actual &&
+ diff actual - <<-EOF
+Submodule sm1 41fbea9...0000000 (submodule deleted)
+diff --git a/sm1 b/sm1
+new file mode 100644
+index 0000000..9da5fb8
+--- /dev/null
++++ b/sm1
+@@ -0,0 +1 @@
++sm1
+EOF
+"
+
+test_expect_success 'typechanged submodule(submodule->blob)' "
+ git diff --submodule=log >actual &&
+ diff actual - <<-EOF
+diff --git a/sm1 b/sm1
+deleted file mode 100644
+index 9da5fb8..0000000
+--- a/sm1
++++ /dev/null
+@@ -1 +0,0 @@
+-sm1
+Submodule sm1 0000000...$head4 (new submodule)
+EOF
+"
+
+rm -rf sm1 &&
+git checkout-index sm1
+test_expect_success 'typechanged submodule(submodule->blob)' "
+ git diff-index -p --submodule=log HEAD >actual &&
+ diff actual - <<-EOF
+Submodule sm1 $head4...0000000 (submodule deleted)
+diff --git a/sm1 b/sm1
+new file mode 100644
+index 0000000..$head5
+--- /dev/null
++++ b/sm1
+@@ -0,0 +1 @@
++sm1
+EOF
+"
+
+rm -f sm1 &&
+test_create_repo sm1 &&
+head6=$(add_file sm1 foo6 foo7)
+fullhead6=$(cd sm1; git rev-list --max-count=1 $head6)
+test_expect_success 'nonexistent commit' "
+ git diff-index -p --submodule=log HEAD >actual &&
+ diff actual - <<-EOF
+Submodule sm1 $head4...$head6 (commits not present)
+EOF
+"
+
+commit_file
+test_expect_success 'typechanged submodule(blob->submodule)' "
+ git diff-index -p --submodule=log HEAD >actual &&
+ diff actual - <<-EOF
+diff --git a/sm1 b/sm1
+deleted file mode 100644
+index $head5..0000000
+--- a/sm1
++++ /dev/null
+@@ -1 +0,0 @@
+-sm1
+Submodule sm1 0000000...$head6 (new submodule)
+EOF
+"
+
+commit_file sm1 &&
+rm -rf sm1
+test_expect_success 'deleted submodule' "
+ git diff-index -p --submodule=log HEAD >actual &&
+ diff actual - <<-EOF
+Submodule sm1 $head6...0000000 (submodule deleted)
+EOF
+"
+
+test_create_repo sm2 &&
+head7=$(add_file sm2 foo8 foo9) &&
+git add sm2
+
+test_expect_success 'multiple submodules' "
+ git diff-index -p --submodule=log HEAD >actual &&
+ diff actual - <<-EOF
+Submodule sm1 $head6...0000000 (submodule deleted)
+Submodule sm2 0000000...$head7 (new submodule)
+EOF
+"
+
+test_expect_success 'path filter' "
+ git diff-index -p --submodule=log HEAD sm2 >actual &&
+ diff actual - <<-EOF
+Submodule sm2 0000000...$head7 (new submodule)
+EOF
+"
+
+commit_file sm2
+test_expect_success 'given commit' "
+ git diff-index -p --submodule=log HEAD^ >actual &&
+ diff actual - <<-EOF
+Submodule sm1 $head6...0000000 (submodule deleted)
+Submodule sm2 0000000...$head7 (new submodule)
+EOF
+"
+
+test_expect_success 'given commit --submodule' "
+ git diff-index -p --submodule HEAD^ >actual &&
+ diff actual - <<-EOF
+Submodule sm1 $head6...0000000 (submodule deleted)
+Submodule sm2 0000000...$head7 (new submodule)
+EOF
+"
+
+fullhead7=$(cd sm2; git rev-list --max-count=1 $head7)
+
+test_expect_success 'given commit --submodule=short' "
+ git diff-index -p --submodule=short HEAD^ >actual &&
+ diff actual - <<-EOF
+diff --git a/sm1 b/sm1
+deleted file mode 160000
+index $head6..0000000
+--- a/sm1
++++ /dev/null
+@@ -1 +0,0 @@
+-Subproject commit $fullhead6
+diff --git a/sm2 b/sm2
+new file mode 160000
+index 0000000..$head7
+--- /dev/null
++++ b/sm2
+@@ -0,0 +1 @@
++Subproject commit $fullhead7
+EOF
+"
+
+test_done
--
1.6.5.rc2.19.gcbaec.dirty
^ permalink raw reply related
* Re: git bisect Vs branch
From: Grégory Romé @ 2009-10-23 9:24 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git@vger.kernel.org, Santi Béjar
In-Reply-To: <4AE16A82.1010103@viscovery.net>
Thanks even if that's what scared me :)
The draw is very simple comparing to the reality (much more merge points) and
rebase will require lot of conflicts resolutions but now I'm sure that's what I
have to do.
Grégory
Johannes Sixt wrote:
> Grégory Romé schrieb:
>> Thanks Santi but I have a problem, due to the fact that the commit which
>> has an impact on my code is in origin/master or first-origin/master
>>
>> When bisect checkout a commit from those branch I have none of my own
>> modifications... So I can' test if my code is good or bad excepted if I
>> can merge my commits in the bisect branch...
>> ᐁ
>> first-origin/master *---A---------B----------------o------C-
>> \ \ \
>> origin/master ----------B'----------U-----------C'-
>> \ \ \
>> master ------------U'----------C''-
>
> C" is the commit that merges upstream changes into your changes. You are
> saying that your changes alone (before the merge) are good, and that
> upstream before the merge is also good (since it doesn't contain your
> changes, it is good by definition, more or less). That indeed means that
> the merge commit is the first bad one; i.e., this is exactly the situation
> that the user manual describes.
>
> You should do:
>
> $ git checkout -b tmp master # master is at C"
> $ git rebase origin/master
> $ git bisect start tmp orgin/master
>
> That is, you rebuild your history on top of origin/master in a linear
> fashion. (If you had merge conflicts in U', then you will see them again.)
> Then you bisect the linearized history. This will point you to the bad
> commit and you will understand what is going wrong.
>
> With this new knowledge, go back to master (C") and fix the problem.
>
> -- Hannes
>
^ permalink raw reply
* [git question] how to handle few projects with common parts?
From: Ivan Dimitrov @ 2009-10-23 9:01 UTC (permalink / raw)
To: git
Hi list,
Maybe my question relates rather to configuration management, but it
is over GIT.
In short - I have to manage two projects with 95% same files
(components) and all the rest are platform depended. I am trying to
keep different platforms in different branches, but I can't figure out
how keep the common part of the project synchronized?
--
Best Regards,
Ivan Dimitrov
^ permalink raw reply
* Re: [PATCH 3/3] git checkout --nodwim
From: Michael J Gruber @ 2009-10-23 8:57 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Nanako Shiraishi, Avery Pennarun, Junio C Hamano, Alex Riesen,
git, Jay Soffian
In-Reply-To: <alpine.DEB.1.00.0910220226270.4985@pacific.mpi-cbg.de>
Johannes Schindelin venit, vidit, dixit 22.10.2009 02:27:
> Hi,
>
> On Thu, 22 Oct 2009, Nanako Shiraishi wrote:
>
>> Quoting Avery Pennarun <apenwarr@gmail.com>
>>
>>> On Sun, Oct 18, 2009 at 3:53 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>>> Helping hands in polishing it up is very welcome.
>>>
>>> I find the idea of an option for "don't do what I mean" to be pretty
>>> entertaining. Or maybe just misleading :)
>>>
>>> Have fun,
>>>
>>> Avery
>>
>> As Junio asked for helping hands, let's try to be helpful and constructive.
>>
>> Maybe "don't second-guess" explains it better?
>
> My take on it:
>
> 1) --no-porcelain
Between --no-dwim and --no-porcelain, maybe --no-wimp is a good compromise?
> 2) we all are bike-shedding, not being constructive at all
That's the fun part!
Michael
^ permalink raw reply
* Re: requesting info page (and pdf) doc releases
From: Michael J Gruber @ 2009-10-23 8:39 UTC (permalink / raw)
To: Rustom Mody; +Cc: Sebastian Pipping, git
In-Reply-To: <f46c52560910221513w1cb19949lfa05ef964987d809@mail.gmail.com>
Rustom Mody venit, vidit, dixit 23.10.2009 00:13:
> On Fri, Oct 23, 2009 at 2:11 AM, Sebastian Pipping <sping@gentoo.org> wrote:
>>
>> hi there!
>>
>>
>> would be nice to get info pages (and pdf) doc releases in addition to
>> html and man pages. i imagine such a change to the release machine
>> should not be too hard to integrate. we could use it in gentoo.
>>
>> thanks,
>>
>>
>>
>> sebastian
>
> +1
> Why only gentoo? I would use it on ubuntu or windows as well
Because they don't build from source!? ;)
Michael
^ permalink raw reply
* Re: Detached HEAD and "git log --all"
From: Michael J Gruber @ 2009-10-23 8:36 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200910222237.04056.jnareb@gmail.com>
Jakub Narebski venit, vidit, dixit 22.10.2009 22:37:
> When discussing differences between concept and implementation
> of branches in Git and in Mercurial on StackOverflow[1] (abusing
> SO comment system a bit), Steve Losh[2] wrote that he was surprised
> by the fact that "git log --all" doesn't include commits made
> on detached HEAD.
>
> While documentation clearly states:
>
> --all Pretend as if all the refs in `$GIT_DIR/refs/` are listed
> on the command line as <commit>.
>
> and HEAD is in `$GIT_DIR/HEAD`, which is outside `$GIT_DIR/refs/`,
> it is nevertheless a bit strange that "git log --all" doesn't list
> all (everything).
>
> This is of course only an issue if we are on detached HEAD; I guess
> that semantics of `--all` option to git-log predates this feature.
>
> [1] http://stackoverflow.com/questions/1598759/git-and-mercurial-compare-and-contrast/1599930#1599930
> [2] http://stevelosh.com/blog/entry/2009/8/30/a-guide-to-branching-in-mercurial/
>
...OK, finally found it: Dscho did just that in f0298cf (revision
walker: include a detached HEAD in --all, 2009-01-16) which is in
v1.6.1.3 and later.
Cheers,
Michael
^ permalink raw reply
* Re: [PATCH] describe: when failing, tell the user about options that work
From: Thomas Rast @ 2009-10-23 8:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Eugene Sajine, git
In-Reply-To: <7vljj3dkid.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Thomas Rast <trast@student.ethz.ch> writes:
>
> > @@ -259,7 +260,14 @@ static void describe(const char *arg, int last_one)
> > printf("%s\n", find_unique_abbrev(sha1, abbrev));
> > return;
> > }
> > - die("cannot describe '%s'", sha1_to_hex(sha1));
> > + if (unannotated_cnt)
> > + die("cannot describe '%s'"
> > + " with only\nannotated tags. Try --tags.",
>
> Did you mean UNannotated tags here?
No, but I think I see where the misunderstanding came from.
This code path means that we did not find a tag to describe with, but
we counted some unannotated tags (and because of how the counting
logic is wrapped, this only triggers when neither --all nor --tags are
in effect).
So I wanted it to say "it is impossible to describe this with the tags
you told me to use", which in this case are the annotated ones.
I tried to keep the general structure of the message ("cannot describe
..."), and with this restriction I can't seem to find a clearer
wording. However, it could be written e.g.
No annotated tags can describe '%s'. However, there were
unannotated tags: try --tags.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: git bisect Vs branch
From: Johannes Sixt @ 2009-10-23 8:34 UTC (permalink / raw)
To: Grégory Romé; +Cc: git@vger.kernel.org, Santi Béjar
In-Reply-To: <4AE156A9.9060809@maxim-ic.com>
Grégory Romé schrieb:
> Thanks Santi but I have a problem, due to the fact that the commit which
> has an impact on my code is in origin/master or first-origin/master
>
> When bisect checkout a commit from those branch I have none of my own
> modifications... So I can' test if my code is good or bad excepted if I
> can merge my commits in the bisect branch...
> ᐁ
> first-origin/master *---A---------B----------------o------C-
> \ \ \
> origin/master ----------B'----------U-----------C'-
> \ \ \
> master ------------U'----------C''-
C" is the commit that merges upstream changes into your changes. You are
saying that your changes alone (before the merge) are good, and that
upstream before the merge is also good (since it doesn't contain your
changes, it is good by definition, more or less). That indeed means that
the merge commit is the first bad one; i.e., this is exactly the situation
that the user manual describes.
You should do:
$ git checkout -b tmp master # master is at C"
$ git rebase origin/master
$ git bisect start tmp orgin/master
That is, you rebuild your history on top of origin/master in a linear
fashion. (If you had merge conflicts in U', then you will see them again.)
Then you bisect the linearized history. This will point you to the bad
commit and you will understand what is going wrong.
With this new knowledge, go back to master (C") and fix the problem.
-- Hannes
^ permalink raw reply
* Re: Detached HEAD and "git log --all"
From: Michael J Gruber @ 2009-10-23 8:33 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200910222237.04056.jnareb@gmail.com>
Jakub Narebski venit, vidit, dixit 22.10.2009 22:37:
> When discussing differences between concept and implementation
> of branches in Git and in Mercurial on StackOverflow[1] (abusing
> SO comment system a bit), Steve Losh[2] wrote that he was surprised
> by the fact that "git log --all" doesn't include commits made
> on detached HEAD.
>
> While documentation clearly states:
>
> --all Pretend as if all the refs in `$GIT_DIR/refs/` are listed
> on the command line as <commit>.
>
> and HEAD is in `$GIT_DIR/HEAD`, which is outside `$GIT_DIR/refs/`,
> it is nevertheless a bit strange that "git log --all" doesn't list
> all (everything).
>
> This is of course only an issue if we are on detached HEAD; I guess
> that semantics of `--all` option to git-log predates this feature.
>
> [1] http://stackoverflow.com/questions/1598759/git-and-mercurial-compare-and-contrast/1599930#1599930
> [2] http://stevelosh.com/blog/entry/2009/8/30/a-guide-to-branching-in-mercurial/
>
Commit 77abcbd (Let --decorate show HEAD position, 2009-10-12) goes a
little bit in that direction, adding HEAD to the "labels" that
--decorate may use, but not to the list of refs specified by "--all". But:
Well, after playing around a bit: git rev-list --all does list my
detached HEAD, git log --all shows it (which is the same statement, of
course), whether I use --decorate or not. Are you seeing different
behaviour?
git describe --all HEAD does not describe the detached HEAD (other than
v1.6.5-87-g4584daf in my case), which may or may not be desirable
(because describe outputs at most one description, unlike --decorate).
Michael
^ permalink raw reply
* [cvsimport] Import CVS repository from a specified date or branch name
From: Klaus Rödel @ 2009-10-23 7:52 UTC (permalink / raw)
To: git
Hello,
I have a very large and old (serveral years) cvs repository and I want
to import this in git.
For my work it is not nessecary to import all the revision history from
the cvs repository.
It is engough to import only the revisions from a specified date or
branch name of the cvs repo.
Is this possible with git-cvsimport?
If yes, how?
If no, is it possible to include such a function in the git-cvsimport
script?
Thanks for any help.
Greets Klaus
^ permalink raw reply
* Re: git bisect Vs branch
From: Grégory Romé @ 2009-10-23 7:09 UTC (permalink / raw)
Cc: git@vger.kernel.org
In-Reply-To: <adf1fd3d0910220950s50ccf8efwda891374e6480a30@mail.gmail.com>
Thanks Santi but I have a problem, due to the fact that the commit which has an
impact on my code is in origin/master or first-origin/master
When bisect checkout a commit from those branch I have none of my own
modifications... So I can' test if my code is good or bad excepted if I can
merge my commits in the bisect branch...
ᐁ
first-origin/master *---A---------B----------------o------C-
\ \ \
origin/master ----------B'----------U-----------C'-
\ \ \
master ------------U'----------C''-
I generalized the problem but I can give a real example. My problem concerns an
Linux USB driver for MIPS based SoC. first-origin is the official kernel
repository and origin/master is the MIPS repository.
Cheers!
Grégory
Santi Béjar wrote:
> On Thu, Oct 22, 2009 at 5:48 PM, Grégory Romé <gregory.rome@maxim-ic.com> wrote:
>> Considering the following story what is the method to find the regression
>> with bisect?
>>
>> I cloned a git repository (origin) which derives from another one
>> (first-origin). A merge is done from first-origin to origin at each stable
>> release (identified by a tag).
>>
>> first-origin/master *---A---------B-----------------------C-
>> \ \ \
>> origin/master ----------B'----------U-----------C'-
>> \ \ \ master
>> ------------U'----------C''-
>>
>> Now, after that I merged C' I fixed the conflicts and compiled without error
>> but I have a regression. It could come from any commit between B and C or U
>> and C', and I need to modify my code to correct the issue.
>>
>> I would like to find the commit which introduce this regression by using git
>> bisect but as the history is not linear it is not so easy (1). It though to
>> create a linear history but I have no idea how to proceed...
>
> You just have to proceed as normal, but you may test more commits than
> with a linear history.
>
> The only problem is iff the culprit is a merge commit (as in the
> user-manual chapter you linked). And the "problem" is to know where
> exactly in the (merge) commit is the bug, but not the procedure.
>
> HTH,
> Santi
^ permalink raw reply
* Re: [PATCH] git svn: fix fetch where glob is on the top-level URL
From: Eric Wong @ 2009-10-23 6:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Adam Brewster, Daniel Cordero, git
In-Reply-To: <20091023060751.GA14477@dcvr.yhbt.net>
Eric Wong <normalperson@yhbt.net> wrote:
> Eric Wong <normalperson@yhbt.net> wrote:
> > From 3abaf9fdf216fd0307bb9e9f03772bd80a64177c Mon Sep 17 00:00:00 2001
> > From: Adam Brewster <adambrewster@gmail.com>
> > Date: Thu, 22 Oct 2009 21:26:32 -0700
> > Subject: [PATCH] git svn: fix fetch where glob is on the top-level URL
>
> Actually, no, something is broken here it seems... Ugh, falling asleep :x
Oops, I was running the tests from the wrong machine that didn't have
the patch on that one.
As noted in my previous email, the leading slashes cause
SVN::Ra::get_log to fail with an assertion if the path passed to it
has a leading slash but is not a standalone slash.
Here's my original patch which seems to work fine (but doesn't allow the
more flexible, bare "*" in "branches = *:refs/remotes/*" Adam's one did.
>From 42079a567bef745996b6272ad546d682dfcf57d6 Mon Sep 17 00:00:00 2001
From: Eric Wong <normalperson@yhbt.net>
Date: Thu, 22 Oct 2009 23:39:04 -0700
Subject: [PATCH] git svn: fix fetch where glob is on the top-level URL
In cases where the top-level URL we're tracking is the path we
glob against, we can once again track odd repositories that keep
branches/tags at the top level. This regression was introduced
in commit 6f5748e14cc5bb0a836b649fb8e2d6a5eb166f1d.
Thanks to Daniel Cordero for the original bug report and
bisection.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-svn.perl | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index eb4b75a..56af221 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -1765,7 +1765,7 @@ sub read_all_remotes {
my $use_svm_props = eval { command_oneline(qw/config --bool
svn.useSvmProps/) };
$use_svm_props = $use_svm_props eq 'true' if $use_svm_props;
- my $svn_refspec = qr{\s*/?(.*?)\s*:\s*(.+?)\s*};
+ my $svn_refspec = qr{\s*(.*?)\s*:\s*(.+?)\s*};
foreach (grep { s/^svn-remote\.// } command(qw/config -l/)) {
if (m!^(.+)\.fetch=$svn_refspec$!) {
my ($remote, $local_ref, $remote_ref) = ($1, $2, $3);
@@ -1979,7 +1979,7 @@ sub find_ref {
my ($ref_id) = @_;
foreach (command(qw/config -l/)) {
next unless m!^svn-remote\.(.+)\.fetch=
- \s*/?(.*?)\s*:\s*(.+?)\s*$!x;
+ \s*(.*?)\s*:\s*(.+?)\s*$!x;
my ($repo_id, $path, $ref) = ($1, $2, $3);
if ($ref eq $ref_id) {
$path = '' if ($path =~ m#^\./?#);
--
Eric Wong
^ permalink raw reply related
* Re: [bug][bisected] git-svn with root branches
From: Eric Wong @ 2009-10-23 6:38 UTC (permalink / raw)
To: Adam Brewster; +Cc: Daniel Cordero, git
In-Reply-To: <c376da900910220824g2948dc2sa1156bda59b49405@mail.gmail.com>
Adam Brewster <adambrewster@gmail.com> wrote:
> > I'm not sure why Adam decided the leading slash needed to be removed for
> > the git refspec. That said, the globbing/branching code still makes me
> > want to hide under a rock and I'm generally afraid to touch it.
> > I'll wait for Adam to chime in since he's braver than I am :)
> >
> How's this for brave: I'm not sure why I did that either.
>
> Looking at it again it seems correct for the leading / to be ignored because
> it has no meaning. What's the difference between the above config and
> "branches = *:refs/remotes/*" (besides the fact that one works and one
> doesn't)? In both cases I think I've asked for all of the top-level
> directories to be branches. But that has nothing to do with the rest of the
> patch, so it shouldn't have been included.
<snip>
> That is, continue disregard the / on the actual input because it means
> nothing, and add a / in places where the code will crash if it's not there.
> Even better would be to find out _why_ $path and $local_ref need a leading /
> and fix it that way, but that's more work that I don't have time for right
> now.
Actually, SVN 1.5+ does not like the leading "/" and trips on an
assertion failure on all cases except a standalone "/". That is, "/*"
continues to work since we send "/" to SVN::Ra::get_log().
--
Eric Wong
^ permalink raw reply
* Re: Any way to "flatten" a series of changes in git
From: Junio C Hamano @ 2009-10-23 6:16 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Howard Miller, Jakub Narebski, git
In-Reply-To: <4AE143BC.7040507@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> The easiest way (IMHO) to achieve this is certainly:
>
> # start a new branch at the tip of the series
> $ git checkout -b all-in-one the-series
>
> # squash 17 commits
> $ git reset --soft HEAD~17
> $ git commit
>
> Now you have a new branch 'all-in-one' that has the same contents as the
> original series 'the-series', but with only one commit:
>
> $ git diff the-series..all-in-one # must show no differences
I think --squash "*merge*" is conceptually simpler to explain *and*
has an added advantage that it helps preparing the consolidated log
message.
# start from the last customer dump
$ git checkout -b customer-update last-release
# give the customer the greatness in the series, content-wise
$ git merge --squash the-series
$ git commit
This will start the "customer-update" branch starting from the
last dump you gave to the customer, merge in the changes made
in the series without history, and when you make a commit, you
will have access to all the individual log messages in the
series to look at as reference, so that you can cut and paste
from them to summarized message instead of typing everything anew.
^ permalink raw reply
* Re: [PATCH] git svn: fix fetch where glob is on the top-level URL
From: Eric Wong @ 2009-10-23 6:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Adam Brewster, Daniel Cordero, git
In-Reply-To: <20091023044843.GA16169@dcvr.yhbt.net>
Eric Wong <normalperson@yhbt.net> wrote:
> From 3abaf9fdf216fd0307bb9e9f03772bd80a64177c Mon Sep 17 00:00:00 2001
> From: Adam Brewster <adambrewster@gmail.com>
> Date: Thu, 22 Oct 2009 21:26:32 -0700
> Subject: [PATCH] git svn: fix fetch where glob is on the top-level URL
Actually, no, something is broken here it seems... Ugh, falling asleep :x
--
Eric Wong
^ permalink raw reply
* Re: feature "git tag -r" to show tags and commits they are pointing to
From: Junio C Hamano @ 2009-10-23 5:58 UTC (permalink / raw)
To: Eugene Sajine; +Cc: Junio C Hamano, git
In-Reply-To: <76c5b8580910221930s4b31b180t8298c262d9d9f421@mail.gmail.com>
Eugene Sajine <euguess@gmail.com> writes:
> I was looking for this info in order to create second tag for the same
> commit. For example if the first tag created by somebody or
> automatically (CI, release system), so i could add a verbose tag.
>
> But i just realized that i don't need commit id for that - just tag
> the tag, stupid...
You do not have to live with a tag that points at another tag that points
at a commit.
You can still tag the commit directly with your new tag, and you do not
need to have the exact commit object name to do so. You just tell the
tool to follow the tag chain to get to the pointed-to object, like this:
$ git tag -a -m "my message" newtag oldtag^0
This assumes [*1*] that the old tag points at (strictly speaking, "might
point at") a commit object, and uses "^0" (zeroth parent of) operator to
make sure that the object the newtag points at (the last argument to the
"git tag" command, i.e. "oldtag^0" in this example) is a commit object,
not an annotated tag "oldtag" itself.
That is what I meant by "just as usable as hexadecimal to the tools".
>> ... "v0.1" is
>> much more useful than 8794hke to humans, and these tag names are just as
>> usable as the hexadecimal commit object names to the tools. You can say
>> "git show v0.1^0" and "git show 8794hke" and get the same thing.
[Footnote]
*1* A tag can point at any object, not necessarily a commit. If oldtag
points at a tree object (or a blob object), oldtag^0 will fail, because
the operator "^0" is "zeroth parent of", and is applicable only to a
commit. In general, you can write
$ git tag -a -m "my message" newtag oldtag^{}
The "^{}" operator is a special case of "^{type}" operator; the former
means "dereference the tag repeatedly until it becomes something that is
not a tag", and the latter means "dereference the tag repeatedly until it
becomes something of that type". I.e. "oldtag^0" is "oldtag^{commit}".
^ permalink raw reply
* Re: Any way to "flatten" a series of changes in git
From: Johannes Sixt @ 2009-10-23 5:48 UTC (permalink / raw)
To: Howard Miller; +Cc: Jakub Narebski, git
In-Reply-To: <26ae428a0910221411l73aa7cbak5c060925ccdf4cea@mail.gmail.com>
Howard Miller schrieb:
> Actually thinking some more.... I don't understand something about
> this. I don't actually want to merge or rebase with anything. I just
> want to say "make those commits a series of commits on a branch into
> just one commit with a new message". I seriously suspect I'm missing
> the point somewhere but what has that got to do with merging or
> rebasing?
The easiest way (IMHO) to achieve this is certainly:
# start a new branch at the tip of the series
$ git checkout -b all-in-one the-series
# squash 17 commits
$ git reset --soft HEAD~17
$ git commit
Now you have a new branch 'all-in-one' that has the same contents as the
original series 'the-series', but with only one commit:
$ git diff the-series..all-in-one # must show no differences
-- Hannes
^ permalink raw reply
* Re: Any way to "flatten" a series of changes in git
From: Howard Miller @ 2009-10-23 5:40 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <26ae428a0910222236l58bc64b7l12c4cff09b086dac@mail.gmail.com>
>
> Hi Jakub,
>
> Yes it helps a lot. What I *don't* care about (or want to do) is
> actually do a merge or a rebase I just want to change history. Well,
> that's what I thought I wanted. What I suppose I really want is the
> full history for *me* and a second branch with the 'reduced' history
> to push to my client. I suppose that's different yet again?
>
> Howard
>
Actually, what I should have said in the first place is that this is
specifically nothing to do with the main trunk. We are doing small
custom developments for clients away from the main project
development. So we specifically don't want to merge or rebase with the
master - that's never going to happen. I want to keep the development
branch in tact for my reference, but when I push (the custom
development branch) to the client I need that sanitized. I think I
finally have it clear in my own head now!
Howard
^ permalink raw reply
* Re: Any way to "flatten" a series of changes in git
From: Howard Miller @ 2009-10-23 5:36 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200910222357.15189.jnareb@gmail.com>
2009/10/22 Jakub Narebski <jnareb@gmail.com>:
> On Thu, 22 Oct 2009, Howard Miller wrote:
>
>> > You can use either "git merge --squash" or "git rebase --interactive"
>> > (changing 'pick' to 'squash').
>> >
>>
>> Actually thinking some more.... I don't understand something about
>> this. I don't actually want to merge or rebase with anything. I just
>> want to say "make those commits a series of commits on a branch into
>> just one commit with a new message". I seriously suspect I'm missing
>> the point somewhere but what has that got to do with merging or
>> rebasing?
>
> Actually using "git merge --squash" is a bit different from using
> "git rebase --interactive".
>
>
> 1. "git merge --squash"
>
> From documentation:
>
> --squash::
> Produce the working tree and index state as if a real
> merge happened (except for the merge information),
> but do not actually make a commit or
> move the `HEAD`, nor record `$GIT_DIR/MERGE_HEAD` to
> cause the next `git commit` command to create a merge
> commit. This allows you to create a single commit on
> top of the current branch whose effect is the same as
> merging another branch (or more in case of an octopus).
>
> This means for example if you did your changes on a separate
> topic branch, and you want to merge your changes into 'master'
> branch, you would do
>
> $ git checkout master
> $ git merge side-branch
>
> which would result in the following history:
>
>
> ---*---*---*---*---*---*---*---M <-- master
> \ /
> \-.---.---.---.---.---.-/ <-- side-branch
>
>
> If you used '--squash' option to git-merge, because changes were
> made in throwaway topic branch, and as you said only final result
> matter, you would get:
>
> $ git checkout master
> $ git merge --squash side-branch
>
> ---*---*---*---*---*---*---*---M' <-- master
> \
> \-.---.---.---.---.---. <-- side-branch
>
>
> where commit M' has the same contents (the same tree) as commit M
> in previous example, but is not a merge commit.
>
> If you simply want to squash last say 5 commits into one, you can
> use "git merge --squash" for it in the following way:
>
> $ git reset --hard HEAD~5
> $ git merge --squash --no-ff HEAD@{1}
>
> which means basically: rewind to state 5 commits back, then merge
> in changes from before rewind, squashing them. The --no-ff is needed
> because otherwise it would be fast-forward and no commit would be
> created.
>
>
> 2. "git rebase --interactive"
>
> The interactive rebase is meant to edit commits being rebased, but
> it can be used simply to edit commits. It includes 'squash' command
> that can be used to concatenate (squash) commits.
>
> So to squash last say 5 commits into one, you would use
>
> $ git rebase --interactive HEAD~5
>
> then edit provided list of commands and commits to read something like
> this:
>
> pick deadbee The oneline of this commit
> squash fa1afe1 The oneline of the next commit
> ...
> squash beedead The oneline of the that commit
>
> i.e. replace 'pick' command by 'squash' command.
>
> This is a very powerfull command, and can be used for example to turn
> series of say 5 commits into series of say 2 commits; not simply squashing
> to a single commit, but reducing number of commits (and presumably
> cleaning up those commits).
>
>
> HTH (hope that helps)
> --
> Jakub Narebski
> Poland
>
Hi Jakub,
Yes it helps a lot. What I *don't* care about (or want to do) is
actually do a merge or a rebase I just want to change history. Well,
that's what I thought I wanted. What I suppose I really want is the
full history for *me* and a second branch with the 'reduced' history
to push to my client. I suppose that's different yet again?
Howard
^ permalink raw reply
* [PATCH] git svn: fix fetch where glob is on the top-level URL
From: Eric Wong @ 2009-10-23 4:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Adam Brewster, Daniel Cordero, git
In-Reply-To: <20091021144113.GA7440@cumin>
>From 3abaf9fdf216fd0307bb9e9f03772bd80a64177c Mon Sep 17 00:00:00 2001
From: Adam Brewster <adambrewster@gmail.com>
Date: Thu, 22 Oct 2009 21:26:32 -0700
Subject: [PATCH] git svn: fix fetch where glob is on the top-level URL
In cases where the top-level URL we're tracking is the path we
glob against, we can once again track odd repositories that keep
branches/tags at the top level. This regression was introduced
in commit 6f5748e14cc5bb0a836b649fb8e2d6a5eb166f1d.
Additionally, the leading slash is now optional when tracking
the top-level path to be consistent with non-top-level paths.
We now allow both of the following "branches" in [svn-remote
"foo"] sections of $GIT_CONFIG:
; with a leading slash (this worked before 6f5748e1)
branches = /*:refs/remotes/*
; now it it also works without a leading slash
branches = *:refs/remotes/*
Thanks to Daniel Cordero for the original bug report and
bisection.
[ew: commit message]
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
Daniel Cordero <theappleman@gmail.com> wrote:
> Hello,
>
> when trying to clone a svn repo with the command-line:
>
> $ git svn clone -b / http://svn.collab.net/repos/svn/
>
> (that is, each folder in the root of the repo should be considered it's
> own branch)
> the clone sometimes[1] fails saying:
>
> ref: 'refs/remotes/' ends with a trailing slash, this is not permitted by git nor Subversion
>
> The offending config is:
> [svn-remote "svn"]
> url = http://svn.collab.net/repos/svn
> branches = /*:refs/remotes/*
>
>
> This used to work in the past; I bisected the bad commit to
>
> commit 6f5748e14cc5bb0a836b649fb8e2d6a5eb166f1d
> Author: Adam Brewster <adambrewster@gmail.com>
> Date: Tue Aug 11 23:14:03 2009 -0400
>
> svn: allow branches outside of refs/remotes
>
>
> Thanks in advance.
>
>
> [1] It does work when the URL has at least 1 folder of depth
> (e.g. suffix "trunk" to the above URL).
>
> Its config section is:
> [svn-remote "svn"]
> url = http://svn.collab.net/repos/svn
> branches = trunk//*:refs/remotes/*
>
git-svn.perl | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index eb4b75a..2e9a720 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -1768,7 +1768,7 @@ sub read_all_remotes {
my $svn_refspec = qr{\s*/?(.*?)\s*:\s*(.+?)\s*};
foreach (grep { s/^svn-remote\.// } command(qw/config -l/)) {
if (m!^(.+)\.fetch=$svn_refspec$!) {
- my ($remote, $local_ref, $remote_ref) = ($1, $2, $3);
+ my ($remote, $local_ref, $remote_ref) = ($1, "/$2", $3);
die("svn-remote.$remote: remote ref '$remote_ref' "
. "must start with 'refs/'\n")
unless $remote_ref =~ m{^refs/};
@@ -1780,7 +1780,7 @@ sub read_all_remotes {
$r->{$1}->{url} = $2;
} elsif (m!^(.+)\.(branches|tags)=$svn_refspec$!) {
my ($remote, $t, $local_ref, $remote_ref) =
- ($1, $2, $3, $4);
+ ($1, $2, "/$3", $4);
die("svn-remote.$remote: remote ref '$remote_ref' ($t) "
. "must start with 'refs/'\n")
unless $remote_ref =~ m{^refs/};
@@ -1980,7 +1980,7 @@ sub find_ref {
foreach (command(qw/config -l/)) {
next unless m!^svn-remote\.(.+)\.fetch=
\s*/?(.*?)\s*:\s*(.+?)\s*$!x;
- my ($repo_id, $path, $ref) = ($1, $2, $3);
+ my ($repo_id, $path, $ref) = ($1, "/$2", $3);
if ($ref eq $ref_id) {
$path = '' if ($path =~ m#^\./?#);
return ($repo_id, $path);
--
Eric Wong
^ permalink raw reply related
* Re: [PATCH] pull: refuse complete src:dst fetchspec arguments
From: Daniel Barkalow @ 2009-10-23 3:43 UTC (permalink / raw)
To: Jeff King; +Cc: Thomas Rast, Björn Steinbrink, Sean Estabrooks, git
In-Reply-To: <20091023025434.GA29908@sigio.peff.net>
On Thu, 22 Oct 2009, Jeff King wrote:
> On Wed, Oct 21, 2009 at 10:05:27AM +0200, Thomas Rast wrote:
>
> > What if any combination of fetch and merge always gave you the long
> > form? After all, even if you do have a tracking branch for whatever
> > you are merging, that information is probably useless and it would be
> > nicer if all of the following resulted in the long form:
> >
> > * git fetch git://git.kernel.org/pub/scm/git/git pu
> > git merge FETCH_HEAD
> >
> > * git remote add origin git://git.kernel.org/pub/scm/git/git
> > git fetch origin
> > git merge origin/pu
> >
> > * git fetch git://git.kernel.org/pub/scm/git/git pu:tmp
> > git merge tmp
>
> Maybe it's just me, but I actually prefer the shorthand names. Five
> years from now when I browse the history and see that I merged
> remote branch "mike/topic", I'll know exactly what that means: developer
> Mike's version of a certain topic branch. But I am not likely to care
> about exactly where we were storing developer repos at that time.
>
> But probably that is an artifact of the workflow. The scenario I am
> describing above implies a somewhat centralized workflow, where the
> shorthand contains all of the interesting information. In a totally
> distributed, we-don't-share-anything-except-the-url-namespace setup of
> an open source repo, the full URL makes more sense.
>
> So maybe it is something that should be optional.
Surely you ought to be able to get the short form with "pull", though, if
you happen to like short forms. So it would make sense to decide how to
format the merge message based entirely on an option, not at all on
whether you use pull or fetch+merge.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] pull: refuse complete src:dst fetchspec arguments
From: Jeff King @ 2009-10-23 2:54 UTC (permalink / raw)
To: Thomas Rast; +Cc: Björn Steinbrink, Daniel Barkalow, Sean Estabrooks, git
In-Reply-To: <200910211005.29053.trast@student.ethz.ch>
On Wed, Oct 21, 2009 at 10:05:27AM +0200, Thomas Rast wrote:
> What if any combination of fetch and merge always gave you the long
> form? After all, even if you do have a tracking branch for whatever
> you are merging, that information is probably useless and it would be
> nicer if all of the following resulted in the long form:
>
> * git fetch git://git.kernel.org/pub/scm/git/git pu
> git merge FETCH_HEAD
>
> * git remote add origin git://git.kernel.org/pub/scm/git/git
> git fetch origin
> git merge origin/pu
>
> * git fetch git://git.kernel.org/pub/scm/git/git pu:tmp
> git merge tmp
Maybe it's just me, but I actually prefer the shorthand names. Five
years from now when I browse the history and see that I merged
remote branch "mike/topic", I'll know exactly what that means: developer
Mike's version of a certain topic branch. But I am not likely to care
about exactly where we were storing developer repos at that time.
But probably that is an artifact of the workflow. The scenario I am
describing above implies a somewhat centralized workflow, where the
shorthand contains all of the interesting information. In a totally
distributed, we-don't-share-anything-except-the-url-namespace setup of
an open source repo, the full URL makes more sense.
So maybe it is something that should be optional.
-Peff
>
> and so on.
>
> --
> Thomas Rast
> trast@{inf,student}.ethz.ch
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
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