* Re: Noob Question
From: Andrew Ardill @ 2012-12-21 22:38 UTC (permalink / raw)
To: W T Riker; +Cc: git@vger.kernel.org
In-Reply-To: <50D463C4.6030208@gmail.com>
On 22 December 2012 00:27, W T Riker <wtriker.ffe@gmail.com> wrote:
> One basic question, since I don't make changes from the Linux
> side, only builds, do I need to install anything git related on that
> machine?
You don't need to install it, but there is no harm in it. If you ever
start doing a build from the linux box and decide you have the wrong
version of your code, it would be useful to have git installed so you
can checkout the right version. Installing git is quick and painless,
however, so you can cross that bridge once you get to it.
Regards,
Andrew Ardill
^ permalink raw reply
* Re: recommendation for patch maintenance
From: Junio C Hamano @ 2012-12-21 22:17 UTC (permalink / raw)
To: Manlio Perillo; +Cc: git
In-Reply-To: <50D4D511.4010003@gmail.com>
On Fri, Dec 21, 2012 at 1:30 PM, Manlio Perillo
<manlio.perillo@gmail.com> wrote:
>
> By the way, I would also like to be able to set the default value for
> the --output option in config file; something like:
>
> [format]
> output = +mp/$(git symbolic-ref --short HEAD)
>
> where the string will be processed by the shell:
>
> sh -c 'printf "+mp/$(git symbolic-ref --short HEAD)'"
My knee-jerk reaction is that, while it might make sense to give an
option to allow users to use a dedicated directory per branch, I am
not interested in that form; especially the part that lets the users too
long a rope to hang themselves with by allowing an arbitrary shell
expansions goes against my taste.
But you *can* prove me wrong; read on.
> I should be able to hack the patch in the weekend, but I'm not sure it
> will be accepted.
You got it backwards, just like many other new people who come and go on
this list. If something is very useful, you'd work on it even if the result may
not appear immediately in the upstream, and you'd keep maintaining a local
fork so that you can keep benefiting from it, once you have written such a
useful feature (whatever it is). If even the original "itch-holder"
does not think
that the benefit from his change outweighs the cost of such an effort, why
should *I* carry it in my tree?
The goal of a contributor who comes up with an idea, gets "It doesn't sound
like a good idea" during the review but disagrees and believes in his idea
ought to be to prove the reviewer(s) wrong by polishing the idea and the
implementation so much that the upstream comes begging for your change ;-)
The core part of the change to add --reroll $n option should be straight-forward
and will involve a few functions in builtin/log.c, but the existing
code is so badly
structured that it probably needs a couple of "preparatory steps" patch to clean
up the API between internal functions on that codepath, before the real change
can be made, I think.
^ permalink raw reply
* Re: Change in cvsps maintainership, abd a --fast-export option
From: Michael Haggerty @ 2012-12-21 22:16 UTC (permalink / raw)
To: esr; +Cc: git
In-Reply-To: <20121221214311.GA29147@thyrsus.com>
On 12/21/2012 10:43 PM, Eric S. Raymond wrote:
> Michael Haggerty <mhagger@alum.mit.edu>:
>> Perhaps your experience is with an older version of cvs2svn?
>
> Well, it has been at least four years since I ran it on anything.
> Maybe that counts as old.
cvs2svn version 2.0 (Aug 2007) totally changed how cvs2svn deduces
changesets. Any results from before that are utterly irrelevant to
modern times.
The changes between version 2.0 and version 2.4 (Sep 2012) have done a
lot more to improve the quality of the conversion. The state of the art
is far beyond what it was four years ago.
>> If not,
>> please be specific rather than just making complaints that are too vague
>> to be rebutted or fixed (whichever is appropriate). I put a *lot* of
>> effort into getting cvs2svn to run correctly, and I take bug reports
>> very seriously.
>
> I can't be specific now, but that may change shortly. I'm putting
> together a test suite for cvsps with the specific intention of
> capturing as many odd corner cases as I can. (I just finished writing
> a small Python framework for expressing interleaved CVS command
> sequences on multiple checkouts in a way that can be easily run.)
>
> It wouldn't be difficult for me to test whether these break cvs2svn.
> You've established that someone over there is paying attention, so
> I'll do that, I guess.
I look forward to your results (whether positive or negative).
> I'm willing to share my test suite as well. Do you have your own zoo
> of odd cases I could test on?
Yes, we have a rather extensive test suite that includes lots of CVS
perversions. See run-tests.py and the CVS repositories under test-data.
Unfortunately, the tests mostly cover only 2svn conversions, but since
most of the tricky work is in the common code that infers the CVS
history, cvs2git benefits from the tests too.
This discussion is getting pretty cvs2svn-specific, so we should
probably move it over to the cvs2svn-dev mailing list.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: Fwd: [RFC/FR] Should "git checkout (-B|-b) branch master...branch" work?
From: Michael Haggerty @ 2012-12-21 21:59 UTC (permalink / raw)
To: Martin von Zweigbergk; +Cc: Junio C Hamano, git
In-Reply-To: <CANiSa6hcDHTpZnAXR3zxdv-H4r-yRjuSx_kgE5V1rSFk_pNhOA@mail.gmail.com>
On 12/21/2012 10:31 PM, Martin von Zweigbergk wrote:
> On Fri, Dec 21, 2012 at 11:43 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
>> On 12/21/2012 06:12 PM, Junio C Hamano wrote:
>>> side note: incidentally, now we have rev_cmdline_info support,
>>> we could start deprecating "diff A..B" syntax.
>>
>> I often find myself using "git diff A..B" syntax when using the command
>> line history because the previous command used "A..B"; e.g.,
>>
>> git log A..B
>> git diff A..B
>
> The problem with this, to me, if it wasn't clear, is that "git log
> A..B" shows you is new _since B branched off from A_, while "git diff
> A..B" shows you what has changed _between A and B_.
You are quite right, of course, though in many useful cases they are the
same. But I guess I should just buck myself up for the new orthodoxy :-)
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: Pushing symbolic references to remote repositories?
From: Shawn Pearce @ 2012-12-21 21:54 UTC (permalink / raw)
To: Dun Peal; +Cc: Git ML
In-Reply-To: <CAD03jn5ACZyxJM9LEOSJov3BsT3W1N0sV3WYwcerJciMSpmSPA@mail.gmail.com>
On Fri, Dec 21, 2012 at 11:53 AM, Dun Peal <dunpealer@gmail.com> wrote:
> I need to share a symbolic reference - essentially, a named pointer to
> another reference - among multiple repositories.
>
> As shown in the code below, I can successfully create a local
> symbolic-ref `foo_ptr` to branch `foo`, but can't push it to a remote,
> in this case `origin`:
>
> $ git branch foo; git symbolic-ref foo_ptr refs/heads/foo; git rev-parse foo_ptr
> fbfec27dc6d42d48ca5d5b178caa34c666a4c39b
> $ git push origin foo foo_ptr
> error: dst ref refs/heads/foo receives from more than one src.
>
> Is there a clean and reliable way to do that, or are symbolic
> references just not meant to be shared?
There is no support for symbolic references in the network protocol,
so they cannot currently be shared by git push or git fetch.
^ permalink raw reply
* Re: Fwd: [RFC/FR] Should "git checkout (-B|-b) branch master...branch" work?
From: Junio C Hamano @ 2012-12-21 21:45 UTC (permalink / raw)
To: Martin von Zweigbergk; +Cc: Michael Haggerty, git
In-Reply-To: <CANiSa6hcDHTpZnAXR3zxdv-H4r-yRjuSx_kgE5V1rSFk_pNhOA@mail.gmail.com>
> Off topic: I also find it hard to wrap my head around what diffing
> against a negative revision would mean. Looking at the result of
> running it, it seems to be the same as diffing against a positive one.
That is not an off-topic at all, but is the crux of "diff A..B" being
a hysterical raisins.
It is parsed as and converted to "diff ^A B" by the revision command
line parser in
setup_revisions(), and the caller *guesses* what the command line
originally said by
inspecting that there are two revs in rev.pending[] array, the first
one is negative and
the second one is positive, to infer that the user typed "diff A..B"
and then finally
decides to compare A and B.
This was done before we introduced rev.cmdline_info to record what was
given from
the command line to result in the set of commits in rev.pending array.
If we were
writing "git diff" UI from scratch today, we wouldn't be looking at
rev.pending but
would be looking at rev.cmdline_info and we can differenciate between
"A B", "^A B",
and "A..B" (and reject the latter two as nonsense).
^ permalink raw reply
* Re: Change in cvsps maintainership, abd a --fast-export option
From: Eric S. Raymond @ 2012-12-21 21:43 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git
In-Reply-To: <50D4B639.9000807@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu>:
> Perhaps your experience is with an older version of cvs2svn?
Well, it has been at least four years since I ran it on anything.
Maybe that counts as old.
I'm willing to believe it's working better now, but I've had to deal
with geological strata of nastiness older versions produced in various
Subversion repositories (cleaning up that crud was a major motivation
for reposurgeon) and I'm fairly sure I haven't seen the last such
fossils. Every sufficiently old Subversion repository seems to have
few.
> If not,
> please be specific rather than just making complaints that are too vague
> to be rebutted or fixed (whichever is appropriate). I put a *lot* of
> effort into getting cvs2svn to run correctly, and I take bug reports
> very seriously.
I can't be specific now, but that may change shortly. I'm putting
together a test suite for cvsps with the specific intention of
capturing as many odd corner cases as I can. (I just finished writing
a small Python framework for expressing interleaved CVS command
sequences on multiple checkouts in a way that can be easily run.)
It wouldn't be difficult for me to test whether these break cvs2svn.
You've established that someone over there is paying attention, so
I'll do that, I guess.
I'm willing to share my test suite as well. Do you have your own zoo
of odd cases I could test on?
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* Re: recommendation for patch maintenance
From: Manlio Perillo @ 2012-12-21 21:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vip7v1d96.fsf@alter.siamese.dyndns.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Il 21/12/2012 19:17, Junio C Hamano ha scritto:
> [...]
> Of course you can plan ahead (this is what I usually do when working
> on a series that is not "how about this" throw-away patch I send to
> this list all the time) and name the topic "topic-v1", fork the new
> round "topic-v2", "topic-v3", etc. and do things like
>
> $ sh -c 'git diff topic-v2~$1 topic-v3~$1' - 4
>
> (the point being that then you do ^P or whatever shell command
> history mechanism to recall that line, edit "4" to "3" and rerun the
> comparison for other corresponding ones).
>
Thanks, this seems fine.
Maybe topic-v2 --> topic/v2 (it looks better to me).
> On a related but different front, I've been thinking about improving
> the "format-patch --subject-prefix" mechanism to make it even easier
> to use.
>
> [...]
>
> What if we added another option, say --reroll $n (or -v$n), to let
> you write:
>
> $ git format-patch --cover-letter -v4 -o ./+mp master
>
> that produces output files named like:
>
> ./+mp/v4-0000-cover-letter.txt
> ./+mp/v4-0001-git-completion.bash.add-support-for-pa.txt
>
> with the subject '[PATCH v4]' prefix?
>
I think it is a good idea to reduce the things one have to do by hand.
I, too, was thinking something similar, with a -v$n option.
And, from these few days I have started to follow the mailing list, it
seems that '[PATCH v$n'] is the standard practice.
By the way, I would also like to be able to set the default value for
the --output option in config file; something like:
[format]
output = +mp/$(git symbolic-ref --short HEAD)
where the string will be processed by the shell:
sh -c 'printf "+mp/$(git symbolic-ref --short HEAD)'"
Note that printf is POSIX, and the standard suggests to use it instead
of echo:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/echo.html
I have read the affected source code, and it should not be too hard.
What do you think?
I should be able to hack the patch in the weekend, but I'm not sure it
will be accepted.
> Then you can transplant the cover letter material from the cover
> letter from the older iteration to the new cover letter in your
> editor, and sending them out will become
>
> $ git send-email ... ./+mp/v4-*.txt
>
> Hmm?
Seems good.
Regards Manlio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlDU1REACgkQscQJ24LbaUT5dgCgismeh+R3B26otuBIXRf/VUiq
+5gAoIR56wVfs8Vw8AAWtim4aor97MXN
=DfeG
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: Fwd: [RFC/FR] Should "git checkout (-B|-b) branch master...branch" work?
From: Martin von Zweigbergk @ 2012-12-21 21:31 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Junio C Hamano, git
In-Reply-To: <50D4BBDC.6030700@alum.mit.edu>
On Fri, Dec 21, 2012 at 11:43 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
> On 12/21/2012 06:12 PM, Junio C Hamano wrote:
>> "diff" is always about two endpoints, not the path that connects
>> these two endpoints (aka "range"), and when you want to "diff"
>> between two commits, you say "diff A B". "A..B" happens to be
>> accepted as such only by accident (e.g. the old command line parser
>> did not have a reliable way to tell "^A B" and "A..B" apart), not by
>> design.
Off topic: I also find it hard to wrap my head around what diffing
against a negative revision would mean. Looking at the result of
running it, it seems to be the same as diffing against a positive one.
>>
>> side note: incidentally, now we have rev_cmdline_info support,
>> we could start deprecating "diff A..B" syntax.
>
> I often find myself using "git diff A..B" syntax when using the command
> line history because the previous command used "A..B"; e.g.,
>
> git log A..B
> git diff A..B
The problem with this, to me, if it wasn't clear, is that "git log
A..B" shows you is new _since B branched off from A_, while "git diff
A..B" shows you what has changed _between A and B_.
>> Actually, in many places where the command line parser knows it
>> wants a single point, and never a range, we should be able to apply
>> the "A...B as a notation to specify a single point" rule.
>>
>> Of course you could come up with a symbol other than "..." for that
>> purpose, and migrate the current "git checkout A...B" special case
>> to use that other symbol, but that would be more work and also you
>> would need to retrain existing users.
>
> OTOH making A...B sometimes mean a range and sometimes a merge-base
> (depending on context) adds a confusing non-uniformity, and also has the
> disadvantage of making merge-base shorthand unavailable in contexts that
> allow a range.
And making it unavailable in contexts where the command was not
specifically implemented to support it. I'm sure there are many
scripts out there that use "git ... $(git merge-base A B) ..." that
could be simplified if rev-parse could resolve a merge base.
> OTOOH git already has so many notations that can be used on the command
> line; inventing yet another one would make it that much more overwhelming.
Agreed.
^ permalink raw reply
* Re: Opera release Git-splitter, a sub-modularizing tool for Git
From: Yngve Nysaeter Pettersen @ 2012-12-21 20:13 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Michael J Gruber, git
In-Reply-To: <vpqhanf2yny.fsf@grenoble-inp.fr>
On Fri, 21 Dec 2012 16:49:21 +0100, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> "Yngve Nysaeter Pettersen" <yngve@opera.com> writes:
>
>> The split command will create a new repository for all files foo in a
>> folder (path/foo) and their commit history.
>>
>> The replant command reverses that process, re-adding the path prefix
>> for each file. It may be possible to extend that process into one that
>> automatically reintegrates the new commits in the original history,
>> but I never had time to complete that work.
>>
>> I did originally add the "replant" functionality into my version of
>> the git-subtree script, but given the number of commits in the
>> original repository, git-subtree turned out to be inefficient, due to
>> the use of temporary files (tens of thousands of files IIRC).
>>
>> Those problems led to my development of git-splitter in Python
>> (bypassing the problem of temporary files), but just including the
>> functionality I needed, join was not one of those functions.
>
> That still doesn't answer the question: why did you need to write a new
> tool instead of extending git-subtree?
The primary problem with git-subtree was that I ended up with a temporary
file directory containing 100+K files, which I tracked back to being used
to manage the commit-to-tree mapping. On Windows, at least, that literally
slowed down the process to a crawl.
> If one doesn't use "replant", is your tool different from git-subtree?
No, it is not different. However, my tool will use RAM, not diskspace to
manage information.
--
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer Email: yngve@opera.com
Opera Software ASA http://www.opera.com/
Phone: +47 96 90 41 51 Fax: +47 23 69 24 01
********************************************************************
^ permalink raw reply
* Pushing symbolic references to remote repositories?
From: Dun Peal @ 2012-12-21 19:53 UTC (permalink / raw)
To: Git ML
Hi,
I need to share a symbolic reference - essentially, a named pointer to
another reference - among multiple repositories.
As shown in the code below, I can successfully create a local
symbolic-ref `foo_ptr` to branch `foo`, but can't push it to a remote,
in this case `origin`:
$ git branch foo; git symbolic-ref foo_ptr refs/heads/foo; git rev-parse foo_ptr
fbfec27dc6d42d48ca5d5b178caa34c666a4c39b
$ git push origin foo foo_ptr
error: dst ref refs/heads/foo receives from more than one src.
Is there a clean and reliable way to do that, or are symbolic
references just not meant to be shared?
Thanks, D.
^ permalink raw reply
* Re: Fwd: [RFC/FR] Should "git checkout (-B|-b) branch master...branch" work?
From: Michael Haggerty @ 2012-12-21 19:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Martin von Zweigbergk, git
In-Reply-To: <7vr4mj1g8j.fsf@alter.siamese.dyndns.org>
On 12/21/2012 06:12 PM, Junio C Hamano wrote:
> "diff" is always about two endpoints, not the path that connects
> these two endpoints (aka "range"), and when you want to "diff"
> between two commits, you say "diff A B". "A..B" happens to be
> accepted as such only by accident (e.g. the old command line parser
> did not have a reliable way to tell "^A B" and "A..B" apart), not by
> design.
>
> side note: incidentally, now we have rev_cmdline_info support,
> we could start deprecating "diff A..B" syntax.
I often find myself using "git diff A..B" syntax when using the command
line history because the previous command used "A..B"; e.g.,
git log A..B
git diff A..B
It's quick to recall the previous command, edit "log" -> "diff", and
press enter; having to remove the dots would require a few extra keypresses.
> Actually, in many places where the command line parser knows it
> wants a single point, and never a range, we should be able to apply
> the "A...B as a notation to specify a single point" rule.
>
> Of course you could come up with a symbol other than "..." for that
> purpose, and migrate the current "git checkout A...B" special case
> to use that other symbol, but that would be more work and also you
> would need to retrain existing users.
OTOH making A...B sometimes mean a range and sometimes a merge-base
(depending on context) adds a confusing non-uniformity, and also has the
disadvantage of making merge-base shorthand unavailable in contexts that
allow a range.
OTOOH git already has so many notations that can be used on the command
line; inventing yet another one would make it that much more overwhelming.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* [PATCH 2/2] learn to pick/revert into unborn branch
From: Martin von Zweigbergk @ 2012-12-21 19:10 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Ramkumar Ramachandra, Martin von Zweigbergk
In-Reply-To: <1356117013-20613-1-git-send-email-martinvonz@gmail.com>
>From the user's point of view, it seems natural to think that
cherry-picking into an unborn branch should work, so make it work,
with or without --ff.
Cherry-picking anything other than a commit that only adds files, will
naturally result in conflicts. Similarly, revert also works, but will
result in conflicts unless the specified revision only deletes files.
Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com>
---
The plan is to use this for fixing "git rebase --root" as discussed in
http://thread.gmane.org/gmane.comp.version-control.git/205796
Is there a better way of creating an unborn branch than what I do in
the test cases?
sequencer.c | 19 +++++++++++--------
t/t3501-revert-cherry-pick.sh | 9 +++++++++
t/t3506-cherry-pick-ff.sh | 8 ++++++++
3 files changed, 28 insertions(+), 8 deletions(-)
diff --git a/sequencer.c b/sequencer.c
index 2260490..1ac1ceb 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -186,14 +186,15 @@ static int error_dirty_index(struct replay_opts *opts)
return -1;
}
-static int fast_forward_to(const unsigned char *to, const unsigned char *from)
+static int fast_forward_to(const unsigned char *to, const unsigned char *from,
+ int unborn)
{
struct ref_lock *ref_lock;
read_cache();
if (checkout_fast_forward(from, to, 1))
exit(1); /* the callee should have complained already */
- ref_lock = lock_any_ref_for_update("HEAD", from, 0);
+ ref_lock = lock_any_ref_for_update("HEAD", unborn ? null_sha1 : from, 0);
return write_ref_sha1(ref_lock, to, "cherry-pick");
}
@@ -390,7 +391,7 @@ static int do_pick_commit(struct commit *commit, struct replay_opts *opts)
struct commit_message msg = { NULL, NULL, NULL, NULL, NULL };
char *defmsg = NULL;
struct strbuf msgbuf = STRBUF_INIT;
- int res;
+ int res, unborn = 0;
if (opts->no_commit) {
/*
@@ -402,9 +403,10 @@ static int do_pick_commit(struct commit *commit, struct replay_opts *opts)
if (write_cache_as_tree(head, 0, NULL))
die (_("Your index file is unmerged."));
} else {
- if (get_sha1("HEAD", head))
- return error(_("You do not have a valid HEAD"));
- if (index_differs_from("HEAD", 0))
+ unborn = get_sha1("HEAD", head);
+ if (unborn)
+ hashcpy(head, EMPTY_TREE_SHA1_BIN);
+ if (index_differs_from(unborn ? EMPTY_TREE_SHA1_HEX : "HEAD", 0))
return error_dirty_index(opts);
}
discard_cache();
@@ -435,8 +437,9 @@ static int do_pick_commit(struct commit *commit, struct replay_opts *opts)
else
parent = commit->parents->item;
- if (opts->allow_ff && parent && !hashcmp(parent->object.sha1, head))
- return fast_forward_to(commit->object.sha1, head);
+ if (opts->allow_ff &&
+ (parent && !hashcmp(parent->object.sha1, head) || !parent && unborn))
+ return fast_forward_to(commit->object.sha1, head, unborn);
if (parent && parse_commit(parent) < 0)
/* TRANSLATORS: The first %s will be "revert" or
diff --git a/t/t3501-revert-cherry-pick.sh b/t/t3501-revert-cherry-pick.sh
index 34c86e5..6f489e2 100755
--- a/t/t3501-revert-cherry-pick.sh
+++ b/t/t3501-revert-cherry-pick.sh
@@ -100,4 +100,13 @@ test_expect_success 'revert forbidden on dirty working tree' '
'
+test_expect_success 'chery-pick on unborn branch' '
+ git checkout --orphan unborn &&
+ git rm --cached -r . &&
+ rm -rf * &&
+ git cherry-pick initial &&
+ git diff --quiet initial &&
+ ! test_cmp_rev initial HEAD
+'
+
test_done
diff --git a/t/t3506-cherry-pick-ff.sh b/t/t3506-cherry-pick-ff.sh
index 51ca391..373aad6 100755
--- a/t/t3506-cherry-pick-ff.sh
+++ b/t/t3506-cherry-pick-ff.sh
@@ -105,4 +105,12 @@ test_expect_success 'cherry pick a root commit with --ff' '
test "$(git rev-parse --verify HEAD)" = "1df192cd8bc58a2b275d842cede4d221ad9000d1"
'
+test_expect_success 'chery-pick --ff on unborn branch' '
+ git checkout --orphan unborn &&
+ git rm --cached -r . &&
+ rm -rf * &&
+ git cherry-pick --ff first &&
+ test_cmp_rev first HEAD
+'
+
test_done
--
1.8.0.1.240.ge8a1f5a
^ permalink raw reply related
* Re: Change in cvsps maintainership, abd a --fast-export option
From: Michael Haggerty @ 2012-12-21 19:19 UTC (permalink / raw)
To: esr; +Cc: git
In-Reply-To: <20121221104437.GA5244@thyrsus.com>
On 12/21/2012 11:44 AM, Eric S. Raymond wrote:
> Michael Haggerty <mhagger@alum.mit.edu>:
>> If you haven't yet seen it, there is a writeup of the algorithm used by
>> cvs2git to infer the history of a CVS repository [1]. If your goal is
>> to make cvsps more robust, you might want to consider the ideas
>> described there.
>
> I shall do so. Their design ideas may well be interesting, even though I
> don't trust their code. I've seem cvs2svn drop far too many weird artifacts
> and just plain broken commits in the back history of Subversion repositories.
> I don't know if this is due to design problems, implementation bugs, or both.
If you have seen any problems with cvs2svn/cvs2git, please file bug
reports. In the past years there have been very few valid bugs
reported. We very often find that artifacts that users thought were
bugs are in fact intentional workarounds required to make the contents
of branches and tags in the target VCS agree with those in the CVS
repository.
Perhaps your experience is with an older version of cvs2svn? If not,
please be specific rather than just making complaints that are too vague
to be rebutted or fixed (whichever is appropriate). I put a *lot* of
effort into getting cvs2svn to run correctly, and I take bug reports
very seriously.
Michael
(the cvs2svn maintainer)
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* [PATCH 1/2] tests: move test_cmp_rev to test-lib-functions
From: Martin von Zweigbergk @ 2012-12-21 19:10 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Ramkumar Ramachandra, Martin von Zweigbergk
A function for checking that two given parameters refer to the same
revision was defined in several places, so move the definition to
test-lib-functions.sh instead.
Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com>
---
t/t1505-rev-parse-last.sh | 18 +++++-------------
t/t3404-rebase-interactive.sh | 6 ------
t/t3507-cherry-pick-conflict.sh | 6 ------
t/t3508-cherry-pick-many-commits.sh | 8 ++------
t/t3510-cherry-pick-sequence.sh | 6 ------
t/t6030-bisect-porcelain.sh | 4 +---
t/test-lib-functions.sh | 7 +++++++
7 files changed, 15 insertions(+), 40 deletions(-)
diff --git a/t/t1505-rev-parse-last.sh b/t/t1505-rev-parse-last.sh
index d709ecf..4969edb 100755
--- a/t/t1505-rev-parse-last.sh
+++ b/t/t1505-rev-parse-last.sh
@@ -32,32 +32,24 @@ test_expect_success 'setup' '
#
# and 'side' should be the last branch
-test_rev_equivalent () {
-
- git rev-parse "$1" > expect &&
- git rev-parse "$2" > output &&
- test_cmp expect output
-
-}
-
test_expect_success '@{-1} works' '
- test_rev_equivalent side @{-1}
+ test_cmp_rev side @{-1}
'
test_expect_success '@{-1}~2 works' '
- test_rev_equivalent side~2 @{-1}~2
+ test_cmp_rev side~2 @{-1}~2
'
test_expect_success '@{-1}^2 works' '
- test_rev_equivalent side^2 @{-1}^2
+ test_cmp_rev side^2 @{-1}^2
'
test_expect_success '@{-1}@{1} works' '
- test_rev_equivalent side@{1} @{-1}@{1}
+ test_cmp_rev side@{1} @{-1}@{1}
'
test_expect_success '@{-2} works' '
- test_rev_equivalent master @{-2}
+ test_cmp_rev master @{-2}
'
test_expect_success '@{-3} fails' '
diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index 32fdc99..8462be1 100755
--- a/t/t3404-rebase-interactive.sh
+++ b/t/t3404-rebase-interactive.sh
@@ -29,12 +29,6 @@ Initial setup:
. "$TEST_DIRECTORY"/lib-rebase.sh
-test_cmp_rev () {
- git rev-parse --verify "$1" >expect.rev &&
- git rev-parse --verify "$2" >actual.rev &&
- test_cmp expect.rev actual.rev
-}
-
set_fake_editor
# WARNING: Modifications to the initial repository can change the SHA ID used
diff --git a/t/t3507-cherry-pick-conflict.sh b/t/t3507-cherry-pick-conflict.sh
index c82f721..223b984 100755
--- a/t/t3507-cherry-pick-conflict.sh
+++ b/t/t3507-cherry-pick-conflict.sh
@@ -11,12 +11,6 @@ test_description='test cherry-pick and revert with conflicts
. ./test-lib.sh
-test_cmp_rev () {
- git rev-parse --verify "$1" >expect.rev &&
- git rev-parse --verify "$2" >actual.rev &&
- test_cmp expect.rev actual.rev
-}
-
pristine_detach () {
git checkout -f "$1^0" &&
git read-tree -u --reset HEAD &&
diff --git a/t/t3508-cherry-pick-many-commits.sh b/t/t3508-cherry-pick-many-commits.sh
index 340afc7..4e7136b 100755
--- a/t/t3508-cherry-pick-many-commits.sh
+++ b/t/t3508-cherry-pick-many-commits.sh
@@ -5,15 +5,11 @@ test_description='test cherry-picking many commits'
. ./test-lib.sh
check_head_differs_from() {
- head=$(git rev-parse --verify HEAD) &&
- arg=$(git rev-parse --verify "$1") &&
- test "$head" != "$arg"
+ ! test_cmp_rev HEAD "$1"
}
check_head_equals() {
- head=$(git rev-parse --verify HEAD) &&
- arg=$(git rev-parse --verify "$1") &&
- test "$head" = "$arg"
+ test_cmp_rev HEAD "$1"
}
test_expect_success setup '
diff --git a/t/t3510-cherry-pick-sequence.sh b/t/t3510-cherry-pick-sequence.sh
index b5fb527..7b7a89d 100755
--- a/t/t3510-cherry-pick-sequence.sh
+++ b/t/t3510-cherry-pick-sequence.sh
@@ -24,12 +24,6 @@ pristine_detach () {
git clean -d -f -f -q -x
}
-test_cmp_rev () {
- git rev-parse --verify "$1" >expect.rev &&
- git rev-parse --verify "$2" >actual.rev &&
- test_cmp expect.rev actual.rev
-}
-
test_expect_success setup '
git config advice.detachedhead false &&
echo unrelated >unrelated &&
diff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh
index 72e28ee..3e0e15f 100755
--- a/t/t6030-bisect-porcelain.sh
+++ b/t/t6030-bisect-porcelain.sh
@@ -676,9 +676,7 @@ test_expect_success 'bisect fails if tree is broken on trial commit' '
check_same()
{
echo "Checking $1 is the same as $2" &&
- git rev-parse "$1" > expected.same &&
- git rev-parse "$2" > expected.actual &&
- test_cmp expected.same expected.actual
+ test_cmp_rev "$1" "$2"
}
test_expect_success 'bisect: --no-checkout - start commit bad' '
diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
index 22a4f8f..fa62d01 100644
--- a/t/test-lib-functions.sh
+++ b/t/test-lib-functions.sh
@@ -602,6 +602,13 @@ test_cmp() {
$GIT_TEST_CMP "$@"
}
+# Tests that its two parameters refer to the same revision
+test_cmp_rev () {
+ git rev-parse --verify "$1" >expect.rev &&
+ git rev-parse --verify "$2" >actual.rev &&
+ test_cmp expect.rev actual.rev
+}
+
# Print a sequence of numbers or letters in increasing order. This is
# similar to GNU seq(1), but the latter might not be available
# everywhere (and does not do letters). It may be used like:
--
1.8.0.1.240.ge8a1f5a
^ permalink raw reply related
* Re: [PATCH v4] git-completion.bash: add support for path completion
From: Manlio Perillo @ 2012-12-21 19:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, szeder, felipe.contreras
In-Reply-To: <7vmwx71e2y.fsf@alter.siamese.dyndns.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Il 21/12/2012 18:59, Junio C Hamano ha scritto:
> Manlio Perillo <manlio.perillo@gmail.com> writes:
>
>> + case "$path" in
>> + ?*/*) echo "${path%%/*}/" ;;
>> + *) echo $path ;;
>
> $path unquoted???
>
Missed again, thanks.
I hope this is really the last one!
> [...]
>> +__git_index_files ()
>> +{
>> + local dir="$(__gitdir)"
>> +
>> + if [ -d "$dir" ]; then
>> + # NOTE: $1 is not quoted in order to support multiple options
>
> Good thinking to document this. Thanks.
>
> I take it that $1 never comes from the end user and it is known that
> it is correct to split them at $IFS? That is the way I read callers
> of this function in this patch, but I am just double-checking.
>
Yes, $1 is always set internally (but I will check again)
Probably there are better solutions.
>> @@ -998,7 +1093,13 @@ _git_commit ()
>> "
>> return
>> esac
>> - COMPREPLY=()
>> +
>> + if git rev-parse --verify --quiet HEAD 1>/dev/null; then
>
> s/1>/>/;
>
What is the reason?
Coding style?
>> + __git_complete_diff_index_file "HEAD"
>
> As this runs "git diff-index" without --cached,
>
> The completion will give only for paths that have difference between
> the working tree and the HEAD. If the user has a bogus contents
> that was "git add"ed earlier, (i.e. the index is different from
> HEAD), then realizes the mistake and fixes it in the working tree
> with his editor to match "HEAD" (i.e. the working tree is the same
> as HEAD):
>
> git commit the-prefix-to-that-file<TAB>
>
> to complete the filename will not give that file. I do not think it
> is a show-stopper, but it may puzzle the users when they encounter
> the situation.
>
Umh, I just checked this case.
0) git init test
1) Added a README file with "Hello World.", and committed.
2) Modified the README file with "Hello World!" and executed
git add README
3) Modified the README file with "Hello World." (the original content)
4) $ git diff HEAD:README README
$ git diff-index --name-only HEAD
README
git commit <TAB> shows the README file.
If I understand correctly the documentation of diff-index, it will
always compare the content of the index with HEAD.
If --cached is specified, it will ignore the stat state of the file on disk.
> I am wondering if reading from "git status --porcelain" might be a
> better alternative, or if it is too much trouble and slow things
> down to cover such a corner case.
>
It have considered it.
The problem is that the output of "git status --porcelain" is not
trivial to parse.
>> @@ -1362,7 +1464,14 @@ _git_mv ()
>> return
>> ;;
>> esac
>> - COMPREPLY=()
>> +
>> + if [ $cword -gt 2 ]; then
>> + # We need to show both cached and untracked files (including
>> + # empty directories) since this may not be the last argument.
>> + __git_complete_index_file "--cached --others --directory"
>> + else
>> + __git_complete_index_file "--cached"
>> + fi
>
> Is $cword affected by the presense of "-f" in "git mv [-f] foo bar"?
> Just being curious.
>
Yes, it is affected; I missed it, thanks.
It should count only non-option arguments.
> Other than that, I do not see anything majorly wrong from the coding
> and semantics point of view in the patch. As to the interaction
> with the rest of the completion machinery, I'll leave the review to
> the area experts CC'ed and wait for their comments.
>
> Thanks.
>
Thanks for your review.
Manlio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlDUsjwACgkQscQJ24LbaUSGuwCffon7/VGFo98CCBsZlmOdNYYE
91oAn3X8fbr5jtzMUOZkMp9CuGWCa7Cf
=Qzsv
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: Python version auditing followup
From: Junio C Hamano @ 2012-12-21 18:48 UTC (permalink / raw)
To: Joachim Schmitz; +Cc: git
In-Reply-To: <006101cddfab$2afb0cf0$80f126d0$@schmitz-digital.de>
"Joachim Schmitz" <jojo@schmitz-digital.de> writes:
>> From: Junio C Hamano [mailto:gitster@pobox.com]
>> Sent: Friday, December 21, 2012 7:28 PM
>> To: Joachim Schmitz
>> Cc: git@vger.kernel.org
>> Subject: Re: Python version auditing followup
>>
>> "Joachim Schmitz" <jojo@schmitz-digital.de> writes:
>>
>> >> > We have a working 2.4.2 for HP-NonStop and some major problems getting
>> >> > 2.7.3 to work.
>> >>
>> >> I do not think a platform that stops at 2.4.2 instead of going to
>> >> higher 2.4.X series deserves to be called "long term maintained by
>> >> their vendors". It sounds more like "attempted to supply 2.4.X and
>> >> abandoned the users once one port was done" to me.
>> >
>> > Well, not entirely wrong, but not all true at too.
>> > I guess I need to defend the vendor here: It is not really the
>> > Vendor (HP) that provided Python 2.4.2 or tries to provide 2.7.3,
>> > it is a volunteer and community effort. HP did sponsor the 2.4.2
>> > port though (by allowing an HP employee to do the port inn his
>> > regular working hours). It is not doing this any longer (since
>> > 2007). Since then it is a small group doing this on a purely
>> > voluntary basis in their spare time (one HP employee amongst them,
>> > me). Same goes for the git port BTW.
>>
>> For the purpose of "if we draw the line at 2.6, would it hurt many
>> people who have been happily using the existing release of Git that
>> was happy with 2.4", it is dubious HP-NonStop counts. It is not
>> like the users on that platform have been happily using Python based
>> Porcelain at the fringe of Git, and drawing the line at 2.6 will not
>> give them any regression.
>
> You asked for opions and obhections, you got mine ;-)
Yeah, duly noted, and appreciated.
^ permalink raw reply
* RE: Python version auditing followup
From: Joachim Schmitz @ 2012-12-21 18:44 UTC (permalink / raw)
To: 'Junio C Hamano'; +Cc: git
In-Reply-To: <7va9t71cqa.fsf@alter.siamese.dyndns.org>
> From: Junio C Hamano [mailto:gitster@pobox.com]
> Sent: Friday, December 21, 2012 7:28 PM
> To: Joachim Schmitz
> Cc: git@vger.kernel.org
> Subject: Re: Python version auditing followup
>
> "Joachim Schmitz" <jojo@schmitz-digital.de> writes:
>
> >> > We have a working 2.4.2 for HP-NonStop and some major problems getting
> >> > 2.7.3 to work.
> >>
> >> I do not think a platform that stops at 2.4.2 instead of going to
> >> higher 2.4.X series deserves to be called "long term maintained by
> >> their vendors". It sounds more like "attempted to supply 2.4.X and
> >> abandoned the users once one port was done" to me.
> >
> > Well, not entirely wrong, but not all true at too.
> > I guess I need to defend the vendor here: It is not really the
> > Vendor (HP) that provided Python 2.4.2 or tries to provide 2.7.3,
> > it is a volunteer and community effort. HP did sponsor the 2.4.2
> > port though (by allowing an HP employee to do the port inn his
> > regular working hours). It is not doing this any longer (since
> > 2007). Since then it is a small group doing this on a purely
> > voluntary basis in their spare time (one HP employee amongst them,
> > me). Same goes for the git port BTW.
>
> For the purpose of "if we draw the line at 2.6, would it hurt many
> people who have been happily using the existing release of Git that
> was happy with 2.4", it is dubious HP-NonStop counts. It is not
> like the users on that platform have been happily using Python based
> Porcelain at the fringe of Git, and drawing the line at 2.6 will not
> give them any regression.
You asked for opions and obhections, you got mine ;-)
^ permalink raw reply
* Re: [PATCH 0/3] Move api-command.txt from ./technical/ to ./howto
From: Junio C Hamano @ 2012-12-21 18:33 UTC (permalink / raw)
To: Thomas Ackermann; +Cc: git
In-Reply-To: <1595193006.286662.1356112971883.JavaMail.ngmail@webmail14.arcor-online.net>
Thomas Ackermann <th.acker@arcor.de> writes:
> "api-command.txt" describes a different kind of API than the other api-* documents.
> So better move it to the howto documents in ./Documentation/howto and rename
> to "new-command.txt".
>
> [PATCH 1/3] Move ./technical/api-command.txt to ./howto/new-command.txt
> [PATCH 2/3] Add new-command.txt to ./Documentation/Makefile
> [PATCH 3/3] Amend new-command.txt to be processed correctly by howto-index.sh
>
> Signed-off-by: Thomas Ackermann <th.acker@arcor.de>
Seems good from a cursory look, but I think this is better done in a
single patch. If you do not mind, I'll squash them into one.
Thanks.
^ permalink raw reply
* Re: Python version auditing followup
From: Junio C Hamano @ 2012-12-21 18:28 UTC (permalink / raw)
To: Joachim Schmitz; +Cc: git
In-Reply-To: <000d01cddf4c$8cbf2ca0$a63d85e0$@schmitz-digital.de>
"Joachim Schmitz" <jojo@schmitz-digital.de> writes:
>> > We have a working 2.4.2 for HP-NonStop and some major problems getting
>> > 2.7.3 to work.
>>
>> I do not think a platform that stops at 2.4.2 instead of going to
>> higher 2.4.X series deserves to be called "long term maintained by
>> their vendors". It sounds more like "attempted to supply 2.4.X and
>> abandoned the users once one port was done" to me.
>
> Well, not entirely wrong, but not all true at too.
> I guess I need to defend the vendor here: It is not really the
> Vendor (HP) that provided Python 2.4.2 or tries to provide 2.7.3,
> it is a volunteer and community effort. HP did sponsor the 2.4.2
> port though (by allowing an HP employee to do the port inn his
> regular working hours). It is not doing this any longer (since
> 2007). Since then it is a small group doing this on a purely
> voluntary basis in their spare time (one HP employee amongst them,
> me). Same goes for the git port BTW.
For the purpose of "if we draw the line at 2.6, would it hurt many
people who have been happily using the existing release of Git that
was happy with 2.4", it is dubious HP-NonStop counts. It is not
like the users on that platform have been happily using Python based
Porcelain at the fringe of Git, and drawing the line at 2.6 will not
give them any regression.
It does add more things that needs to be done to the volunteer
developers for that platform and the organization that may want to
support the platform (as they have to finish 2.6 port if we decide
to draw the line there), but that is a secondary consideration.
^ permalink raw reply
* Re: [PATCH] http.c: Avoid username prompt for certifcate credentials
From: Junio C Hamano @ 2012-12-21 18:19 UTC (permalink / raw)
To: Jeff King; +Cc: Rene Bredlau, git
In-Reply-To: <20121221170927.GA23574@sigill.intra.peff.net>
Thanks, both.
^ permalink raw reply
* Re: recommendation for patch maintenance
From: Junio C Hamano @ 2012-12-21 18:17 UTC (permalink / raw)
To: Manlio Perillo; +Cc: git
In-Reply-To: <50D49C81.5060007@gmail.com>
Manlio Perillo <manlio.perillo@gmail.com> writes:
> I lose the history of all the changes I have made to produce the final
> version of a patch.
>
> Since for every new version of a patch I do a commit --amend, I can not
> see, as an example, the changes I have made between x and y versions of
> a patch.
>
> Of course the commits are not really lost, but I have to search them
> using the reflog.
Yeah, these days with "rebase -i" that does not leave individual
steps as separate reflog entries, for an easy series, you can do
things like:
$ git rebase -i ;# work on polishing the series
$ git show-branch -g ;# view where it diverged
$ git diff HEAD~4 @{1}~4
Of course you can plan ahead (this is what I usually do when working
on a series that is not "how about this" throw-away patch I send to
this list all the time) and name the topic "topic-v1", fork the new
round "topic-v2", "topic-v3", etc. and do things like
$ sh -c 'git diff topic-v2~$1 topic-v3~$1' - 4
(the point being that then you do ^P or whatever shell command
history mechanism to recall that line, edit "4" to "3" and rerun the
comparison for other corresponding ones).
On a related but different front, I've been thinking about improving
the "format-patch --subject-prefix" mechanism to make it even easier
to use. With the current interface, when you prepare your reroll,
you would do:
$ git format-patch --cover-letter \
--subject-prefix='PATCH v4' -o ./+mp master
and end up overwriting the patches from the previous round (if their
subject did not change). You will always overwrite the cover
because its subject never changes and that is where the filename is
taken from.
What if we added another option, say --reroll $n (or -v$n), to let
you write:
$ git format-patch --cover-letter -v4 -o ./+mp master
that produces output files named like:
./+mp/v4-0000-cover-letter.txt
./+mp/v4-0001-git-completion.bash.add-support-for-pa.txt
with the subject '[PATCH v4]' prefix?
Then you can transplant the cover letter material from the cover
letter from the older iteration to the new cover letter in your
editor, and sending them out will become
$ git send-email ... ./+mp/v4-*.txt
Hmm?
^ permalink raw reply
* [PATCH 3/3] Amend new-command.txt to be processed correctly by howto-index.sh
From: Thomas Ackermann @ 2012-12-21 18:07 UTC (permalink / raw)
To: git; +Cc: th.acker
In-Reply-To: <1595193006.286662.1356112971883.JavaMail.ngmail@webmail14.arcor-online.net>
Signed-off-by: Thomas Ackermann <th.acker@arcor.de>
---
Documentation/howto/new-command.txt | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/Documentation/howto/new-command.txt b/Documentation/howto/new-command.txt
index d3b9781..36502f6 100644
--- a/Documentation/howto/new-command.txt
+++ b/Documentation/howto/new-command.txt
@@ -1,5 +1,10 @@
-Integrating new subcommands
-===========================
+From: Eric S. Raymond <esr@thyrsus.com>
+Abstract: This is how-to documentation for people who want to add extension
+ commands to git. It should be read alongside api-builtin.txt.
+Content-type: text/asciidoc
+
+How to integrate new subcommands
+================================
This is how-to documentation for people who want to add extension
commands to git. It should be read alongside api-builtin.txt.
--
1.8.0.msysgit.0
---
Thomas
^ permalink raw reply related
* [PATCH 2/3] Add new-command.txt to ./Documentation/Makefile
From: Thomas Ackermann @ 2012-12-21 18:06 UTC (permalink / raw)
To: git; +Cc: th.acker
In-Reply-To: <1595193006.286662.1356112971883.JavaMail.ngmail@webmail14.arcor-online.net>
Signed-off-by: Thomas Ackermann <th.acker@arcor.de>
---
Documentation/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 7df75d0..f3afcb6 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -21,6 +21,7 @@ ARTICLES += git-tools
ARTICLES += git-bisect-lk2009
# with their own formatting rules.
SP_ARTICLES = user-manual
+SP_ARTICLES += howto/new-command
SP_ARTICLES += howto/revert-branch-rebase
SP_ARTICLES += howto/using-merge-subtree
SP_ARTICLES += howto/using-signed-tag-in-pull-request
--
1.8.0.msysgit.0
---
Thomas
^ permalink raw reply related
* [PATCH 1/3] Move ./technical/api-command.txt to ./howto/new-command.txt
From: Thomas Ackermann @ 2012-12-21 18:05 UTC (permalink / raw)
To: git; +Cc: th.acker
In-Reply-To: <1595193006.286662.1356112971883.JavaMail.ngmail@webmail14.arcor-online.net>
Signed-off-by: Thomas Ackermann <th.acker@arcor.de>
---
Documentation/{technical/api-command.txt => howto/new-command.txt} | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename Documentation/{technical/api-command.txt => howto/new-command.txt} (100%)
diff --git a/Documentation/technical/api-command.txt b/Documentation/howto/new-command.txt
similarity index 100%
rename from Documentation/technical/api-command.txt
rename to Documentation/howto/new-command.txt
--
1.8.0.msysgit.0
---
Thomas
^ 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